Is this expected IBGP peer behaviour?
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
||||||||||||||||
|
Posted by p47 on December 23, 2005, 7:54 pm
Please log in for more thread options 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 | ||||||||||||||||
|
Posted by Barry Margolin on December 23, 2005, 10:14 pm
Please log in for more thread options Exporting in both directions like this can cause problems. It usually shouldn't be necessary to export BGP into OSPF. >
> -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. 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. > -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. A should have the one route learned by EBGP. C should have two routes, one from IBGP and the other from EBGP. >
> 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. I expect A to withdraw the route it sent to C, and then C will advertise its only remaining route back to A. >
> 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? I have a feeling the problem may be related to the two-way exporting, but I'm not sure. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group *** | ||||||||||||||||
|
Posted by Alex on December 24, 2005, 9:17 am
Please log in for more thread options 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... > -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. 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. > 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. 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 | ||||||||||||||||
|
Posted by Alex on December 24, 2005, 9:21 am
Please log in for more thread options 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... > -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. 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. > 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. 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
redistribution) and originates another 1.1.1.0/16 route due to iBGP->OSPF -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 | ||||||||||||||||
|
Posted by p47 on January 8, 2006, 6:25 am
Please log in for more thread options 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 | ||||||||||||||||
| Similar Threads | Posted |
| Is this expected IBGP peer behaviour? | December 23, 2005, 7:54 pm |
| VPN Peer:ISAKMP: Peer Info for * not found | January 6, 2006, 4:19 pm |
| PIX - loss of connection to it - and stopping peer to peer | October 22, 2006, 2:57 pm |
| Dynamic and peer-to-peer VPN on the same PIX | October 4, 2006, 12:59 pm |
| vpn traffic slower than expected | December 12, 2006, 10:40 am |
| Cisco reports better than expected profit | November 10, 2006, 4:56 am |
| - Boot image integrity check...Failed (CRC expected 0x00004e9d, not | November 9, 2005, 8:08 pm |
| Re: ARP behaviour | August 5, 2006, 8:57 pm |
| can ibgp be used behind nat? | September 16, 2005, 3:23 pm |
| iBGP Questions | June 26, 2007, 2:24 pm |
| iBGP Advertisements | November 8, 2007, 7:06 pm |
| iBGP question. | July 5, 2008, 5:09 pm |
| Re: iBGP question. | July 7, 2008, 1:56 am |
| Re: Rediculous IPSec behaviour | November 29, 2005, 6:38 pm |
| IP SoftPhone strange behaviour | April 14, 2006, 10:55 am |
> 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