Strange CEF Problem - For CEF experts, please help.

Answered Question
Sep 21st, 2010

Hi,

I just have two routes in a router as follows:

RR2#sh ip route | i 21.1.
B    21.1.22.0/24 [200/0] via 21.1.22.2, 00:00:03
B    21.1.22.0/19 [200/0] via 9.9.9.9, 00:30:40

The more specific route learnt via 21.1.22.2 is flushed every 30 seconds, that's why I inspected CEF table and found the following:

RR2#
*Mar  1 02:28:47.747: CEF-Table(Default-table): Event up 21.1.22.0/24 (rdbs:1, flags:A00000)
*Mar  1 02:28:47.751: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:28:47.751: CEF-IP: resolved 21.1.22.0/24 via 21.1.22.2 to 10.10.90.2 Serial1/2
*Mar  1 02:28:47.755: CEF-IP: Instantly resolved recursive entry 21.1.22.0/24
*Mar  1 02:28:47.755: CEF-IP: Checking dependencies of 21.1.22.0/19
*Mar  1 02:28:47.999: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:28:47.999: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:28:49.035: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:28:49.039: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:28:50.039: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:28:50.043: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:28:51.043: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:28:51.047: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:28:52.067: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:28:52.067: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:28:53.071: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:28:53.071: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:28:54.079: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:28:54.083: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:28:55.091: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:28:55.091: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:28:56.123: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:28:56.123: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:28:57.127: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:28:57.131: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:28:58.131: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:28:58.135: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:28:59.143: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:28:59.147: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:00.163: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:29:00.167: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:01.175: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:29:01.175: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:02.187: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:29:02.187: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:03.191: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:29:03.191: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:04.199: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:29:04.199: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:05.223: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:29:05.227: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:06.247: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:29:06.251: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:07.251: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:29:07.251: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:08.263: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:29:08.263: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:09.271: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:29:09.275: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:10.299: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:29:10.303: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:11.303: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:29:11.307: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:12.315: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:29:12.315: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:13.339: CEF-Table: attempting to resolve 21.1.22.0/24
*Mar  1 02:29:13.343: CEF-Table: no resolution for 21.1.22.0/24 via 21.1.22.2
*Mar  1 02:29:14.139: CEF-Table(Default-table): Event down 21.1.22.0/24 (rdbs:0, flags:A10000)
*Mar  1 02:29:14.139: CEF-Table: Flushing entry for 21.1.22.0/24, table 0

Apparently, the route 21.1.22.0/24 is installed for a moment and then CEF tried to verify it but it always fails! (This is my assumption)

Does anyone have an idea?

Thanks.

I have this problem too.
0 votes
Correct Answer by Peter Paluch about 6 years 2 months ago

Hello,

Note please that the next hop for the (BGP-learned) network 22.1.22.0/24 is inside the same network. Essentially, this routing entry recursively loops into itself. This the reason that this network is periodically flushed and readded into the routing table and consequently in the CEF.

You have a configuration problem in your BGP - it advertises a more specific route (/24) than you currently have in your routing table (/19). Because the next-hop of the more specific route accidently falls into that route itself, it creates an unresolvable entry in your routing table.

You will have to correct your BGP configuration. Ideally, for iBGP, you should peer your BGP speaker using loopback interfaces and have them advertised in your IGP protocol. Also, you should make sure that for every next-hop advertised via BGP, there is an IGP route that is more preferred than the BGP-learned routes.

You may want to read this article for further info:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800945fe.shtml

Also please note: there is no network 22.1.22.0/19, contrary to what you have indicated. The /19 mask would result in networks 22.1.0.0/19, 22.1.32.0/19, 22.1.64.0/19, etc...

Best regards,

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
Peter Paluch Tue, 09/21/2010 - 12:58

Hello,

Note please that the next hop for the (BGP-learned) network 22.1.22.0/24 is inside the same network. Essentially, this routing entry recursively loops into itself. This the reason that this network is periodically flushed and readded into the routing table and consequently in the CEF.

You have a configuration problem in your BGP - it advertises a more specific route (/24) than you currently have in your routing table (/19). Because the next-hop of the more specific route accidently falls into that route itself, it creates an unresolvable entry in your routing table.

You will have to correct your BGP configuration. Ideally, for iBGP, you should peer your BGP speaker using loopback interfaces and have them advertised in your IGP protocol. Also, you should make sure that for every next-hop advertised via BGP, there is an IGP route that is more preferred than the BGP-learned routes.

You may want to read this article for further info:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800945fe.shtml

Also please note: there is no network 22.1.22.0/19, contrary to what you have indicated. The /19 mask would result in networks 22.1.0.0/19, 22.1.32.0/19, 22.1.64.0/19, etc...

Best regards,

Peter

Actions

This Discussion