BGP Rib-Failures (7304s)

[kfarrington]

Guys/Girls,

Simple question.

We are migrating from 3745s to 7304s and on the new IOS, BGP does not show rib-failures with the "R" or when you do an individual show ip bgp <prefix> it does not show Rib-Failure at the top of the output.

Whilst this is not a problem, I am just wondering why some codes show this, and some dont.

I quite like it being shown as it is a clear indication that there is a better route or some other feature of the routing protocol that is stopping it from going into the RT.

If anyone could enlighten me.

Kind regards,

Ken

[ruwhite]

What IOS version are you moving from and to? I'm fairly certain this is a recent'ish feature, and won't be in all the trains for all platforms yet.

:-)

Russ.W

[Harold Ritter]

The original RIB failure behavior was implemented via CSCdp12004 and later brought back to pre CSCdp12004 behavior via CSCdy39249.

Chances are the IOS you use on 7304 incorporates CSCdy39249 while the one on the 3745 is implementing CSCdp12004.

Hope this helps,

[kfarrington]

Here are the specs guys,

Really apprciate you guys taking time to look at this :)

3745>sh hard

Cisco Internetwork Operating System Software

IOS (tm) 3700 Software (C3745-IS-M), Version 12.3(6b), RELEASE SOFTWARE (fc1)

Copyright (c) 1986-2004 by cisco Systems, Inc.

Compiled Wed 19-May-04 20:55 by dchih

Image text-base: 0x60008AF4, data-base: 0x61BA6000

ROM: System Bootstrap, Version 12.2(8r)T2, RELEASE SOFTWARE (fc1)

3745 uptime is 15 weeks, 5 days, 16 hours, 44 minutes

System returned to ROM by bus error at PC 0xD0D0D0D, address 0x0 at 17:25:30 BST Wed Jun 1 2005

System restarted at 17:26:39 BST Wed Jun 1 2005

System image file is "flash:c3745-is-mz.123-6b.bin"

cisco 3745 (R7000) processor (revision 2.0) with 236544K/25600K bytes of memory.

Processor board ID JPE082410VX

R7000 CPU at 350MHz, Implementation 39, Rev 3.3, 256KB L2, 2048KB L3 Cache

Bridging software.

X.25 software, Version 3.0.0.

SuperLAT software (copyright 1990 by Meridian Technology Corp).

4 FastEthernet/IEEE 802.3 interface(s)

DRAM configuration is 64 bits wide with parity disabled.

151K bytes of non-volatile configuration memory.

31360K bytes of ATA System CompactFlash (Read/Write)

62592K bytes of ATA Slot0 CompactFlash (Read/Write)

Configuration register is 0x2102

3745>

7304>sh hard

Cisco Internetwork Operating System Software

IOS (tm) 7300 Software (C7300-IS-M), Version 12.2(20)S8, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2005 by cisco Systems, Inc.

Compiled Thu 12-May-05 12:55 by ccai

Image text-base: 0x40008BF4, data-base: 0x4233A000

ROM: System Bootstrap, Version 12.1(12r)EX1, RELEASE SOFTWARE (fc1)

Currently running ROMMON from ROM 0

BOOTLDR: 7300 Software (C7300-IS-M), Version 12.2(20)S8, RELEASE SOFTWARE (fc1)

7304 uptime is 2 days, 16 hours, 55 minutes

System returned to ROM by reload at 16:46:22 BST Sat Sep 17 2005

System restarted at 16:47:28 BST Sat Sep 17 2005

System image file is "disk0:c7300-is-mz.122-20.S8.bin"

cisco 7300 (NSE100) processor (revision E) with 491520K/32768K bytes of memory.

Processor board ID SMQ0911N0HS

R7000 CPU at 350Mhz, Implementation 39, Rev 3.3, 256KB L2, 1024KB L3 Cache

4 slot midplane, Version 67.49

Last reset from software reset or reload

Bridging software.

X.25 software, Version 3.0.0.

PXF processor tmc0 'system:pxf/ucode1' is running ( v4.1 ).

PXF processor tmc1 'system:pxf/ucode1' is running ( v4.1 ).

1 FastEthernet/IEEE 802.3 interface(s)

6 Gigabit Ethernet/IEEE 802.3 interface(s)

509K bytes of non-volatile configuration memory.

31744K bytes of ATA compact flash in bootdisk (Sector size 512 bytes).

62592K bytes of ATA compact flash in disk0 (Sector size 512 bytes).

Configuration register is 0x2102

%NOTE: Line cards present violate configuration guidelines for this NSE.

7304>

[kfarrington]

Sorry guys,

One last thing, As this appears only to be cosmetic (correct me if that statement is incorrect), why dont people want to see it? I assume as you say it was brought back (or backed out) people did not like seeing the rib-failure indication (correct)?

Cheers dudes

Ken

[Harold Ritter · Accepted solution]

Ken,

CSCdp12004 is not simply a cosmetic. It doesn't advertise prefixes that cannot be installed in the RIB.

CSCdy39249 brought back the pre CSCdp12004 since this is basically what people were used to.

Note that the RIB failure is still reported in the output with the "r>" even after CSCdy39249.

Hope this helps,

[kfarrington]

cool. gottit dude :)

[Harold Ritter]

Ken,

12.3(6b) integrates CSCdp12004 and 12.2(20)S8 doesn't, which explains that you are seeing the rib failure with the former but not with the latter.

Just one more precision about my previous posting. although CSCdy39249 brought us back to a pre CSCdp12004 behavior in the sense that it will advertise a prefix to a peer even if that prefix cannot be installed in the RIB, the RIB failure is still reported in the output with the "r>".

Hope this helps,

[kfarrington]

Man, this is a BIG matter of discussion here at Barclays :)

So,

we had a look at both Bug IDs and we also had the 7304 guys in yesterday from the states (Matt Faulkner and Rich Dusome), and we were looking at the IOS roadmaps for the 7304s (SBC etc)

What we still donnot fully understand is BGP characteristics as we move onto these 7304s.

Also, the two bug IDs only one really matches :-

12004 details

When BGP learns a new route, selects the bestpath and tries to insert into the RIB, it may fail sometimes. The reasons for failure could be a memory

problem or higher admin distance route is already present or route-limit has been reached. Even when failed to insert into RIB, BGP will advertise

the route to its peers. This can lead to blackholing.

CSCdy39249 Bug Details

When a prefix is marked as RIB-failure(17), even if the conditions caused RIB-failure(17) is cleared, the prefix still stays in this state.

( i am really sorry if I have draged this out a bit )

OK,

We have tested on both h/w platforms and see the following characteristics (please see attached file)

When the 7304 has a better iBGP prefix than eBGP (and uses the IGP), the route does not show ribbed, but does not advertise it to any peers.

When the 3745 has a better iBGP prefix than eBGP (and uses the IGP), it DOES show a rib-failure but as above, does not advertise it to any BGP peer.

So, it looks like from these two platforms, that the 7304 and 3745 conform to RFC 1771 and if the prefix is not in the RIB, it will not advertise it to bgp peers.

(IE, what we were trying to acheive is receiving a best-path from iBGP as indicated in the file output and for BGP to re-advertise this backout to AS 11111 externally.)

So, what versions of code would advertise a prefix if it was ribbed out? (thus you could use the bgp suppress-inactive command?)

Hope you guys are cool with this. It is soo important that we ensure a smooth transition from the 3745 platforms onto the 7304s.

Kind regards,

Ken

ps attched file in next post

[kfarrington]

attachment for BGP routing

[Harold Ritter]

Ken,

Sorry for the confusion.

The image on the 3745 integrates CSCdy39249 and will therefore advertise the best path to a peer, even if it is flagged with RIB Failure.

The image on the 7304 never implemented the RIB failure behavior and will therefore advertise the best path whether it is installed in the RIB or not.

I just ran a quick test with both 12.3 and 12.2S and it works as expected.

What you are seeing in your test is probaly due to something different.

Hope this helps,

[kfarrington]

Hey mate, hope all is well :)

I just gotta say, that I see what you are seeing but dont undertsnad. (sorry dude). Both routers send the prefix to another external peer.

Please see the attachement.

Test 1. 7304 and 3745 are both peering to AS11111.

7304 received preifx 29.29.29.0/24 with med 1000, 3745 receives it with MED 2000. 3745 ribs route and asvertises it to AS10. 7304 also advertises it to AS10..

Test 2. 7304 now received MED of 2021 and this makes 3745 the better router to 29.29.29.0. We dont see the rib on the 7304 (as we would on the 3745) and it still advertises the route to AS10.3745 also advertises this prefix to AS10.

So regardless of IOS, both routers peering to AS11111 and AS10 receive the prefix 29.29.29.0/24 from AS11111 and send it to AS10 regardless of rib-failure reporting or not (that is why i see this as costmetic from our side as there is no difference.)

I can raise a TAC case or get out AS guys involved if you think this is nessecary and I wont bug you guys on this again :))

Tried test 1 again with the bgp suppress-inactive command on the 3745 and the 3745 (ribbed out) still advertises it to AS10.

Are we just saying here "regardless of rib failure or not, the prefix will always get advertised to a peer" and will this remain the same in all IOS? (this as you stated last year, will not conform to RFC 1771)

Please see attached output.

Really, thx for the help so far on this.

[Harold Ritter]

Hello Ken,

Happy to see that you get the right results now (ie: routes advertised even if it shows as RIB Failure).

From what I understand the only issue you have left is the BGP routes not installed in RIB but still getting advertised to eBGP peers although "suppress-inactive" is configured, right?

Have you tried doing a "clear ip bgp * soft out" after configuring "suppress-inactive".

I'm just curious about why you would want to configure the "suppress-inactive" when the standard IOS behavior has always been the opposite.

Hope this helps,