1. Home
  2. Cisco Systems
  3. Is this expected IBGP peer behaviour?

Is this expected IBGP peer behaviour?

Hello, I have a basic question and am just now learning BGP.

AS 330 AS 331

---------- ---------- RTR A-----ebgp-----RTR B | | ibgp ibgp 1.1.1.0/16 | | RTR C-----ebgp------RTR D

Facts:

-Synchronization is disabled in both ASes.

-OSPF is the IGP in both ASes.

-RTR A exports BGP into OSPF and OSPF to BGP

-RTR C exports OSPF into BGP

-The EBGP peers (A to B and C to D) are connected via passive OSPF interfaces.

-A specific route, 1.1.1.0/16, exists on the IBGP peer between RTR B and RTR D. This route is advertised by both B and D is and accepted by A and C. RTR A accepts it with a local preference of 101, RTR C accepts it with a local preference of 100.

-RTR A announces this route to RTR C with local preference of 101, RTR C announces this route to RTR A with local preference of 100.

-RTR A and RTR C both have in the BGP route table two routes to the

1.1.1.0/16 network, one route learned via EBGP, the other route learned via IBGP. Traffic originated in AS 330 destined for 1.1.1.0/16 therefore goes out through RTR A due to higher local preference.

Expected behaviour: If the EBGP peer between A and B is broken:

RTR A would have a single BGP route for the 1.1.1.0/16 learned via RTR C.

RTR C would not send out another update message to A advertising

1.1.1.0/16 because its BGP route table hasn't changed per se and is not advertising anything different.

Exhibited behaviour: If the EBGP peer between A and B is broken, A no longer has the

1.1.1.0/16 route in its BGP route table. C still has the route learned via RTR D in its BGP route table and indicates it has advertised it to A, but A does not indicate this. A sniffer capture shows A and C both sending out withdraw messages for that route, but the trace does not show an update coming from C to A for this route.

Issue: Is this expected behaviour for IBGP peers or is the software confused? If BGP to OSPF is disabled on RTR A and the A to B peer is broken, A still has it's route via C, and therefore the software wouldn't be an issue?

Thank you in advance. Charles

Reply to
p47
Loading thread data ...

Exporting in both directions like this can cause problems. It usually shouldn't be necessary to export BGP into OSPF.

C shouldn't announce the route to A. Only the best route is ever announced, and C's best route is the one it learned from A, not the one it learned from D. But you don't advertise a route back to where you learned it from, so C shouldn't advertise to A.

A should have the one route learned by EBGP. C should have two routes, one from IBGP and the other from EBGP.

I expect A to withdraw the route it sent to C, and then C will advertise its only remaining route back to A.

I have a feeling the problem may be related to the two-way exporting, but I'm not sure.

Reply to
Barry Margolin

Firstly, netmask for 1.1.1.0/16 is invalid. Do You mean 1.1.1.0/24? Anyway, it shouldn't be affecting anything as such...

Given that RTR C exports OSPF into BGP I think that it should have three

1.1.1.0/16 prefixes:

- one from RTR A with LocPref==101 (best route)

- another from RTR D with LocPref==100

- yet another locally originated (due to OSPF->BGP redistribution) with LocPref==100

BUT - as far as routing table is concerned, RTR C should have 1.1.1.0/16 OSPF route installed in it, not BGP, due to better AD. Let me explain: above three BGP routes are fed into BGP decision algorithm and the route from RTR A wins due to better LocPref. Now, when RTR A tries to install this iBGP route into routing table, it fails because iBGP AD==200 and OSPF AD==110. RTR A should have marked 1.1.1.0/16 as "RIB failure" in its BGP table.

Does RTR A have "bgp redistribute-internal" in the config? If YES then what could happen is:

-BGP session between RTR A and RTR B goes down

-RTR A withdraws 1.1.1.0/16 iBGP route (first withdrawal message on sniffer)

-RTR C selects locally originated 1.1.1.0/16 BGP route as best and advertises it to RTR A

-RTR A MaxAges its 1.1.1.0/16 OSPF route (originated due to eBGP->OSPF redistribution) and originates another 1.1.1.0/16 route due to iBGP->OSPF redistribution

-RTR C deletes old 1.1.1.0/16 OSPF route, deletes locally originated

1.1.1.0/16 BGP route and sends a withdrawal message for 1.1.1.0/16 to RTR A (second withdrawal message on sniffer).

-RTR C installs another 1.1.1.0/16 OSPF route. Thise route will be identical to previous one (different only in LSA sequence numbers).

-RTR C locally originates another 1.1.1.0/16 BGP route (best) and announces it to RTR A.

-RTR A accepts this route as best, installs into routing table and redistributes it into OSPF. Cycle repeats.

At this point RTR A should have 1.1.1.0/16 iBGP route from RTR C in its BGP table and routing table, RTR C should have 1.1.1.0/16 eBGP route from RTR D and 1.1.1.0/16 locally originated BGP route (best) in its BGP table+1.1.1.0/16 OSPF route in its routing table.

Routing loop is formed.

This way eBGP route from RTR D will never make it to RTR A. Is that what You are seeing?

HTH Cheers Alex

Reply to
Alex

Typos in my original post corrected,sorry for any inconvenience!

Firstly, netmask for 1.1.1.0/16 is invalid. Do You mean 1.1.1.0/24? Anyway, it shouldn't be affecting anything as such...

Given that RTR C exports OSPF into BGP I think that it should have three

1.1.1.0/16 prefixes:

- one from RTR A with LocPref==101 (best route)

- another from RTR D with LocPref==100

- yet another locally originated (due to OSPF->BGP redistribution) with LocPref==100

BUT - as far as RTR C routing table is concerned, RTR C should have

1.1.1.0/16 OSPF route installed there, not BGP, due to better AD. Let me explain: above three BGP routes are fed into BGP decision algorithm and the route from RTR A wins due to better LocPref. Now, when RTR C tries to install this iBGP route into routing table, it fails because iBGP AD==200 and OSPF AD==110. RTR C should have marked 1.1.1.0/16 as "RIB failure" in its BGP table.

Does RTR A have "bgp redistribute-internal" in the config? If YES then what could happen is:

-BGP session between RTR A and RTR B goes down

-RTR A withdraws 1.1.1.0/16 iBGP route (first withdrawal message on sniffer)

-RTR C selects locally originated 1.1.1.0/16 BGP route as best and advertises it to RTR A

-RTR A MaxAges its 1.1.1.0/16 OSPF route (originated due to eBGP->OSPF redistribution) and originates another 1.1.1.0/16 route due to iBGP->OSPF redistribution

-RTR C deletes old 1.1.1.0/16 OSPF route, deletes locally originated

1.1.1.0/16 BGP route and sends a withdrawal message for 1.1.1.0/16 to RTR A (second withdrawal message on sniffer).

-RTR C installs another 1.1.1.0/16 OSPF route. Thise route will be identical to previous one (different only in LSA sequence numbers).

-RTR C locally originates another 1.1.1.0/16 BGP route (best) and announces it to RTR A.

-RTR A accepts this route as best, installs into routing table and redistributes it into OSPF. Cycle repeats.

At this point RTR A should have 1.1.1.0/16 iBGP route from RTR C in its BGP table and routing table, RTR C should have 1.1.1.0/16 eBGP route from RTR D and 1.1.1.0/16 locally originated BGP route (best) in its BGP table+1.1.1.0/16 OSPF route in its routing table.

Routing loop is formed.

This way eBGP route from RTR D will never make it to RTR A. Is that what You are seeing?

HTH Cheers Alex

Reply to
Alex

Barry, Alex, Thanks much for the replies. I've been out of commission due to illness, but am back at it now.

The root of the problem resided with having BGP exported into OSPF on RTR A. If that is negated, and the RTR A to RTR B EBGP peer is somehow broken, then the correct BGP routes remain in RTR A's tables.

In regards to the 1.1.1.0/16, that was just a generic subnet, will be careful next time to post something realistics.

Kind regards, Charles

Reply to
p47

Barry, Alex, I posted this yesterday, but it hasn't appeared. Many thanks for the post. I've been out with illness and haven't responded sooner.

The problem is caused by having BGP export in to OSPF on RTR A. If this is turned off, there's no issues. When the RTR A to RTR B peer is broken, the BGP routes remain.

Thank you both for the assistance.

The 1.1.1.0/16 was just a generic network, will be careful to post a more realistic network in future posts.

Kind regards, Charles.

Reply to
p47

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.