Solved: ibgp received prefix not best still advetrised to ebgp peer

sarahr202 · ‎12-26-2011

Hi everybody

Please consider the following set up:

In the above set-up, AS 1 is running rip for igp and bgp, while As 2 is running bgp

The issue is R1 i receives a prefix 2.0.0.0 from its ibgp peer R3.Though R1 does not regard it as its best bgp learned prefix but yet it advertises it to its ebgp peer R2 while there is no " network 2.0.0.0" configured under bgp at R1.

R3:

interface Loopback2

ip address 2.2.2.2 255.0.0.0

interface Serial0/0

ip address 200.200.200.3 255.255.255.0

clock rate 2000000

router rip

network 2.0.0.0

network 200.200.200.0

router bgp 1

no synchronization

bgp log-neighbor-changes

network 2.0.0.0

neighbor 200.200.200.1 remote-as 1

no auto-summary

R3#show ip bgp

BGP table version is 4, local router ID is 2.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 2.0.0.0 0.0.0.0 0 32768 i

R3#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 200.200.200.0/24 is directly connected, Serial0/0

R 199.199.199.0/24 [120/1] via 200.200.200.1, 00:00:27, Serial0/0

C 2.0.0.0/8 is directly connected, Loopback2

R3#

=========================================================================

R1:

interface Serial0/0

ip address 200.200.200.1 255.255.255.0

clock rate 2000000

interface Serial0/1

ip address 199.199.199.1 255.255.255.0

router rip

network 199.199.199.0

network 200.200.200.0

!

router bgp 1

no synchronization

bgp log-neighbor-changes

neighbor 199.199.199.2 remote-as 2

neighbor 200.200.200.3 remote-as 1

no auto-summary

R1#show ip bgp

BGP table version is 5, local router ID is 200.200.200.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

r>i2.0.0.0 200.200.200.3 0 100 0 i

R1#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 200.200.200.0/24 is directly connected, Serial0/0

C 199.199.199.0/24 is directly connected, Serial0/1

R 2.0.0.0/8 [120/1] via 200.200.200.3, 00:00:28, Serial0/0

question # 1

Why we do have "r" in the output of " show ip bgp" on R1?

==================================================================

R2(EBGP peer)

interface Loopback2

ip address 2.2.2.2 255.0.0.0

!

interface Serial0/0

ip address 199.199.199.2 255.255.255.0

clock rate 2000000

router bgp 2

no synchronization

bgp log-neighbor-changes

neighbor 199.199.199.1 remote-as 1

no auto-summary

R2#show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

199.199.199.1 4 1 40 39 3 0 0 00:35:47 1

R2#

R2#show ip bgp

BGP table version is 3, local router ID is 2.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

r> 2.0.0.0 199.199.199.1 0 1 i

R2#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 199.199.199.0/24 is directly connected, Serial0/0

C 2.0.0.0/8 is directly connected, Loopback2

R2#

Question # 2

My understanding is once a router learns a BGP route and concludes it is its best route ; it will advertise to its EBGP neighbor if R1 is allowed to advertise it by " network " command

Here R2 is learning 2.0.0.0 from R1( ebgp neighbor) as evident in output of " show ip bgp". My question is how can R1 advertise 2.0.0.0 to EBGp peer R2 when R1 did not consider the ibgp advertised prefix as its best route and still advertised it to R2 even when there was not" network 2.0.0.0" under bgp1 at R1?

Thanks and have a nice week

Peter Paluch · ‎12-26-2011

Hi Sarah,

question # 1

Why we do have "r" in the output of " show ip bgp" on R1?

It denotes a RIB failure, i.e. the inability of the BGP to enter its own best path candidate to the routing table - obviously because the of the administrative distance - the same network is learned by RIP as well with AD=120 while the iBGP-learned route is assigned the AD=200.

More explanation can be gained using the show ip bgp rib-failure command in similar occurances.

Question # 2

My understanding is once a router learns a BGP route and concludes it is its best route ; it will advertise to its EBGP neighbor if R1 is allowed to advertise it by " network " command

Here R2 is learning 2.0.0.0 from R1( ebgp neighbor) as evident in output of " show ip bgp". My question is how can R1 advertise 2.0.0.0 to EBGp peer R2 when R1 did not consider the ibgp advertised prefix as its best route and still advertised it to R2 even when there was not" network 2.0.0.0" under bgp1 at R1?

There is a difference between the BGP best-path and the router's best path present in the routing table. BGP itself knows about routes to a particular destination and may perform its own best path selection on them. The BGP best-path candidates are then offered to the routing table. However, there may be issues installing these BGP best-paths into the routing table - the RIB failure as you've experienced is a wonderful example. So while the BGP has chosen its own best-path candidate, it is not regarded as the overall best path from the routing table point of view because the RIP is considered more trustworthy.

Cisco's BGP implementation by default propagates even those BGP best-paths that ultimately did not make it into the routing table. In other words, the BGP lives something like an own life here - it computes its best paths and it advertises them further without really checking if these routes have been accepted by the routing table itself. This is what you are seeing here - the BGP best paths are advertised despite not being really used by the router.

This behavior can be changed, though. Use the bgp suppress-inactive command in your BGP configuration on the R1 - this should make sure that only those BGP best paths are advertised that are also installed in the router's routing table.

Best regards,

Peter

View solution in original post

Peter Paluch · ‎12-26-2011

Hello Sarah,

I am fine, thanks - how are you?

My question  if the apposite is also true i.e if  a router say R1 learns  a prefix from its IBGP peer,and concludes it is the best BGP route,  will R1 announce that prefix to its EBGP peer without the use of network  command ?

Yes, it will. You have described the process correctly.

The rules for dissemination of networks in BGP are not that different from IGP protocols: BGP advertises the best route for each network that has been injected into its database, either via a network command or learned via BGP. An additional rule is that if the route is learned via iBGP, it will not be advertised to other iBGP neighbors (except route reflectors). I do not, at this moment, recall any other important rule... perhaps it's just the late time here in Slovakia (1:00 am )

Best regards,

Peter

View solution in original post

Peter Paluch · ‎12-26-2011

Hi Sarah,

question # 1

Why we do have "r" in the output of " show ip bgp" on R1?

It denotes a RIB failure, i.e. the inability of the BGP to enter its own best path candidate to the routing table - obviously because the of the administrative distance - the same network is learned by RIP as well with AD=120 while the iBGP-learned route is assigned the AD=200.

More explanation can be gained using the show ip bgp rib-failure command in similar occurances.

Question # 2

My understanding is once a router learns a BGP route and concludes it is its best route ; it will advertise to its EBGP neighbor if R1 is allowed to advertise it by " network " command

Here R2 is learning 2.0.0.0 from R1( ebgp neighbor) as evident in output of " show ip bgp". My question is how can R1 advertise 2.0.0.0 to EBGp peer R2 when R1 did not consider the ibgp advertised prefix as its best route and still advertised it to R2 even when there was not" network 2.0.0.0" under bgp1 at R1?

There is a difference between the BGP best-path and the router's best path present in the routing table. BGP itself knows about routes to a particular destination and may perform its own best path selection on them. The BGP best-path candidates are then offered to the routing table. However, there may be issues installing these BGP best-paths into the routing table - the RIB failure as you've experienced is a wonderful example. So while the BGP has chosen its own best-path candidate, it is not regarded as the overall best path from the routing table point of view because the RIP is considered more trustworthy.

Cisco's BGP implementation by default propagates even those BGP best-paths that ultimately did not make it into the routing table. In other words, the BGP lives something like an own life here - it computes its best paths and it advertises them further without really checking if these routes have been accepted by the routing table itself. This is what you are seeing here - the BGP best paths are advertised despite not being really used by the router.

This behavior can be changed, though. Use the bgp suppress-inactive command in your BGP configuration on the R1 - this should make sure that only those BGP best paths are advertised that are also installed in the router's routing table.

Best regards,

Peter

sarahr202 · ‎12-26-2011

Hi Peter

How are you doing?

My understanding is if an EBGP peer say R1 learns a prefix from its EBGP peer and conclude it is the best BGP prefix, it will announce it to its IBGP peers without the use of network command under bgp at R1.

My question if the apposite is also true i.e if a router say R1 learns a prefix from its IBGP peer,and concludes it is the best BGP route, will R1 announce that prefix to its EBGP peer without the use of network command ?

Because in our case R1 learns 2.0.0.0 from its ibgp peer R3 ; R1 decides 2.0.0.0 as best bgp prefix and and advertises it to its EBGP peer R2.

Thanks and have a nice week

Peter Paluch · ‎12-26-2011

Hello Sarah,

I am fine, thanks - how are you?

My question  if the apposite is also true i.e if  a router say R1 learns  a prefix from its IBGP peer,and concludes it is the best BGP route,  will R1 announce that prefix to its EBGP peer without the use of network  command ?

Yes, it will. You have described the process correctly.

The rules for dissemination of networks in BGP are not that different from IGP protocols: BGP advertises the best route for each network that has been injected into its database, either via a network command or learned via BGP. An additional rule is that if the route is learned via iBGP, it will not be advertised to other iBGP neighbors (except route reflectors). I do not, at this moment, recall any other important rule... perhaps it's just the late time here in Slovakia (1:00 am )

Best regards,

Peter

sarahr202 · ‎12-26-2011

Thanks Peter.

Have a good sleep !