Re: OSPF into iBGP with Sync [7:30126]
the first thing that comes to mind is that OSPF is the only other routing protocol where RID is an inherant part of the structure and the process. as to why this becomes an issue, since RIDs can change based upon reconfigurations and reloads and process clearing, I can see the code getting confused. add a loopback. clear the ospf process, the RID changes, but does not change for BGP because the process is stable. or visa versa. this is starting to tell me that maybe there is a RID routine in the IOS code that both BGP and OSPF reference when starting up. write it off as "cronkite" because "that's the way it is"? not a bug, but a feature? Chuck ""John Neiberger"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > We discovered something on the CCIE list recently and I'm > wondering if anyone might be able to explain the reasoning > behing this behavior. > > BGP synchronization rules require that if an iBGP peer is to > advertise a route learned via iBGP, it must have that prefix > *and* the next hop for that route in the routing table already. > > An interesting added complexity to this occurs if your IGP is > OSPF. If the router in question has learned these prefixes via > OSPF, then the advertising router ID in the OSPF database must > match the router ID of the iBGP peer that advertised the route. > > Has this behavior caused any problems for any of you? Do you > know why the synchronization rules have a special case for OSPF > and not other routing protocols? > > I was working with someone else on a practice lab and we ran > into this issue. We were both going nuts trying to figure out > why the iBGP routes weren't synchronizing and this turned out > to be the cause. > > Any thoughts? > > Thanks, > John > > > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30132&t=30126 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF into iBGP with Sync [7:30126]
To my knowledge, this is purely a cisco implementation issue and you'd need to look at the code or ask the coders what their particular intention was. OSPF didn't play much of a role in transit networks during the time when synchronization was a relevant option as far as I know so I doubt there was very extensive testing done on this particular feature. I would expect this was just an additional check to ensure route authenticity. Given this feature is many years antiquated, I'm surprised so many folks try and make it work. pete At 06:23 PM 12/26/2001 -0500, John Neiberger wrote: >We discovered something on the CCIE list recently and I'm >wondering if anyone might be able to explain the reasoning >behing this behavior. > >BGP synchronization rules require that if an iBGP peer is to >advertise a route learned via iBGP, it must have that prefix >*and* the next hop for that route in the routing table already. > >An interesting added complexity to this occurs if your IGP is >OSPF. If the router in question has learned these prefixes via >OSPF, then the advertising router ID in the OSPF database must >match the router ID of the iBGP peer that advertised the route. > >Has this behavior caused any problems for any of you? Do you >know why the synchronization rules have a special case for OSPF >and not other routing protocols? > >I was working with someone else on a practice lab and we ran >into this issue. We were both going nuts trying to figure out >why the iBGP routes weren't synchronizing and this turned out >to be the cause. > >Any thoughts? > >Thanks, >John > > >Get your own "800" number >Voicemail, fax, email, and a lot more >http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30145&t=30126 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF into iBGP with Sync [7:30126]
> the first thing that comes to mind is that OSPF is the only other routing > protocol where RID is an inherant part of the structure and the process. > > as to why this becomes an issue, since RIDs can change based upon > reconfigurations and reloads and process clearing, I can see the code > getting confused. add a loopback. clear the ospf process, the RID changes, > but does not change for BGP because the process is stable. or visa versa. > this is starting to tell me that maybe there is a RID routine in the IOS > code that both BGP and OSPF reference when starting up. > > write it off as "cronkite" because "that's the way it is"? not a bug, but a > feature? > the 'feature' is a pretty tricky deal. what the sync 'feature' required is the RID for the OSPF route match the RID of the BGP route. John came up with the solution, and it worked. The redistribution point also plays a key role - when redistributing OSPF into BGP, it worked best when done at a BGP router that was sync'ed. The additional complication was a route reflector preventing the real full iBGP mesh. It is a show-stopper if you don't get that match and try to get unsynced iBGP routes advertised to an eBGP neighbor. My conclusion: The additional sync requirement of matching OSPF RIDs (instead of just the routing table) is a real pain in the butt. > Chuck > > > ""John Neiberger"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > We discovered something on the CCIE list recently and I'm > > wondering if anyone might be able to explain the reasoning > > behing this behavior. > > > > BGP synchronization rules require that if an iBGP peer is to > > advertise a route learned via iBGP, it must have that prefix > > *and* the next hop for that route in the routing table already. > > > > An interesting added complexity to this occurs if your IGP is > > OSPF. If the router in question has learned these prefixes via > > OSPF, then the advertising router ID in the OSPF database must > > match the router ID of the iBGP peer that advertised the route. > > > > Has this behavior caused any problems for any of you? Do you > > know why the synchronization rules have a special case for OSPF > > and not other routing protocols? > > > > I was working with someone else on a practice lab and we ran > > into this issue. We were both going nuts trying to figure out > > why the iBGP routes weren't synchronizing and this turned out > > to be the cause. > > > > Any thoughts? > > > > Thanks, > > John > > > > > > Get your own "800" number > > Voicemail, fax, email, and a lot more > > http://www.ureach.com/reg/tag _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30282&t=30126 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF into iBGP with Sync [7:30126]
- Original Message - From: "Peter van Oene" To: Sent: Wednesday, December 26, 2001 7:47 PM Subject: Re: OSPF into iBGP with Sync [7:30126] > To my knowledge, this is purely a cisco implementation issue and you'd need > to look at the code or ask the coders what their particular intention > was. OSPF didn't play much of a role in transit networks during the time > when synchronization was a relevant option as far as I know so I doubt > there was very extensive testing done on this particular feature. I would > expect this was just an additional check to ensure route > authenticity. Given this feature is many years antiquated, I'm surprised > so many folks try and make it work. > unfortunately, if it were as simple as just that, I could just deal with it. However, when it affects my ability to propagate iBGP routes to an eBGP neighbor, and the restriction is sync on all but the route reflector router, a solution has to be figured out. If it were on the lab exam, I'd probably disable sync if I got desparate (and kiss some points goodbye) if I didn't know the answer. Therein lies a good point for the lab exam: Know what your contigency (backup) plan is if you can't figure out the solution that you're being pointed to so that you can at least get the darned thing running and you can move on to the next step. > pete > > > At 06:23 PM 12/26/2001 -0500, John Neiberger wrote: > >We discovered something on the CCIE list recently and I'm > >wondering if anyone might be able to explain the reasoning > >behing this behavior. > > > >BGP synchronization rules require that if an iBGP peer is to > >advertise a route learned via iBGP, it must have that prefix > >*and* the next hop for that route in the routing table already. > > > >An interesting added complexity to this occurs if your IGP is > >OSPF. If the router in question has learned these prefixes via > >OSPF, then the advertising router ID in the OSPF database must > >match the router ID of the iBGP peer that advertised the route. > > > >Has this behavior caused any problems for any of you? Do you > >know why the synchronization rules have a special case for OSPF > >and not other routing protocols? > > > >I was working with someone else on a practice lab and we ran > >into this issue. We were both going nuts trying to figure out > >why the iBGP routes weren't synchronizing and this turned out > >to be the cause. > > > >Any thoughts? > > > >Thanks, > >John > > > > > >Get your own "800" number > >Voicemail, fax, email, and a lot more > >http://www.ureach.com/reg/tag _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30283&t=30126 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF into iBGP with Sync [7:30126]
reflectors. The requirement for the BGP/OSPF identifier is stated in RFC 1364: "Varadhan[Page 4] RFC 1364 BGP OSPF InteractionSeptember 1992 3. BGP Identifier and OSPF router ID The BGP identifier must be the same as the OSPF router id at all times that the router is up. This characteristic is required for two reasons. i. Consider the scenario in which 3 routers, RT1, RT2, and RT3, belong to the same autonomous system. +-+ | RT3 | +-+ | Autonomous System running OSPF / \ +-+ +-+ | RT1 | | RT2 | +-+ +-+ Both RT1 and RT2 have routes to an external network X and import it into the OSPF routing domain. RT3 is advertising the route to network X to other external BGP speakers. RT3 must use the OSPF router ID to determine whether it is using RT1 or RT2 to forward packets to network X and hence build the correct AS_PATH to advertise to other external speakers. More precisely, RT3 must use the AS_PATH of the route announced by the ASBR, whose BGP Identifier is the same as the OSPF routerID corresponding to its route for network X. ii. It will be convenient for the network administrator looking at an ASBR to correlate different BGP and OSPF routes based on the identifier." Cisco issued a field notice on the problem where there was a route reflector. (Can't locate it in my pile(s)) In One Tech Note (BGP Best Path Selection Algorithm): "Paths marked as "not synchronized" in the show ip bgp output. If BGP synchronization is enabled, which it is by default in Cisco IOS. Software, there must be a match for the prefix in the IP routing table in order for an internal (iBGP) path to be considered a valid path. If the matching route is learned from an OSPF neighbor, its OSPF router ID must match the BGP router ID of the iBGP neighbor. Most users prefer to disable synchronization using the no synchronization BGP subcommand." The comparison can be done using the sh ip bgp xxx.yyy.zzz.aaa and show ip ospf data. HTH, Fred. John Neiberger wrote: > > We discovered something on the CCIE list recently and I'm > wondering if anyone might be able to explain the reasoning > behing this behavior. > > BGP synchronization rules require that if an iBGP peer is to > advertise a route learned via iBGP, it must have that prefix > *and* the next hop for that route in the routing table already. > > An interesting added complexity to this occurs if your IGP is > OSPF. If the router in question has learned these prefixes via > OSPF, then the advertising router ID in the OSPF database must > match the router ID of the iBGP peer that advertised the route. > > Has this behavior caused any problems for any of you? Do you > know why the synchronization rules have a special case for OSPF > and not other routing protocols? > > I was working with someone else on a practice lab and we ran > into this issue. We were both going nuts trying to figure out > why the iBGP routes weren't synchronizing and this turned out > to be the cause. > > Any thoughts? > > Thanks, > John > > > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30353&t=30126 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF into iBGP with Sync [7:30126]
Fred, Thanks, that's exactly what I was looking for, although it appears that the first part of your response was chopped off for some reason. John >>> "Fred Ingham" 12/28/01 12:19:59 PM >>> reflectors. The requirement for the BGP/OSPF identifier is stated in RFC 1364: "Varadhan[Page 4] RFC 1364 BGP OSPF InteractionSeptember 1992 3. BGP Identifier and OSPF router ID The BGP identifier must be the same as the OSPF router id at all times that the router is up. This characteristic is required for two reasons. i. Consider the scenario in which 3 routers, RT1, RT2, and RT3, belong to the same autonomous system. +-+ | RT3 | +-+ | Autonomous System running OSPF / \ +-+ +-+ | RT1 | | RT2 | +-+ +-+ Both RT1 and RT2 have routes to an external network X and import it into the OSPF routing domain. RT3 is advertising the route to network X to other external BGP speakers. RT3 must use the OSPF router ID to determine whether it is using RT1 or RT2 to forward packets to network X and hence build the correct AS_PATH to advertise to other external speakers. More precisely, RT3 must use the AS_PATH of the route announced by the ASBR, whose BGP Identifier is the same as the OSPF routerID corresponding to its route for network X. ii. It will be convenient for the network administrator looking at an ASBR to correlate different BGP and OSPF routes based on the identifier." Cisco issued a field notice on the problem where there was a route reflector. (Can't locate it in my pile(s)) In One Tech Note (BGP Best Path Selection Algorithm): "Paths marked as "not synchronized" in the show ip bgp output. If BGP synchronization is enabled, which it is by default in Cisco IOS. Software, there must be a match for the prefix in the IP routing table in order for an internal (iBGP) path to be considered a valid path. If the matching route is learned from an OSPF neighbor, its OSPF router ID must match the BGP router ID of the iBGP neighbor. Most users prefer to disable synchronization using the no synchronization BGP subcommand." The comparison can be done using the sh ip bgp xxx.yyy.zzz.aaa and show ip ospf data. HTH, Fred. John Neiberger wrote: > > We discovered something on the CCIE list recently and I'm > wondering if anyone might be able to explain the reasoning > behing this behavior. > > BGP synchronization rules require that if an iBGP peer is to > advertise a route learned via iBGP, it must have that prefix > *and* the next hop for that route in the routing table already. > > An interesting added complexity to this occurs if your IGP is > OSPF. If the router in question has learned these prefixes via > OSPF, then the advertising router ID in the OSPF database must > match the router ID of the iBGP peer that advertised the route. > > Has this behavior caused any problems for any of you? Do you > know why the synchronization rules have a special case for OSPF > and not other routing protocols? > > I was working with someone else on a practice lab and we ran > into this issue. We were both going nuts trying to figure out > why the iBGP routes weren't synchronizing and this turned out > to be the cause. > > Any thoughts? > > Thanks, > John > > > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30359&t=30126 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF into iBGP with Sync [7:30126]
Fred, this is fascinating reading ( ok, so I need a life :-> ) but I am failing to understand the "why" behind the requirement. Recognizing that there were real problems in real networks that those who wrote the RFC were trying to solve, is there something I am missing in the description? In the example below, all routers are in the same AS. When R3 advertises to an eBGP neighbor, the AS-PATH is going to be the same, no matter which of the other two routers is the next-hop... hhhm. if R1 were the actual recipient of the network X route, and via OSPF advertised it to R2, and then bothe R1 and R2 advertised the router to R3. m I'm still lost. espcially since this makes no difference in any other routing protocol vs BGP situation. I would think that R3 would be using the OSPF route because OSPF has a better admin distance than does iBGP but then that's just Cisco. Am I correct in thinking this is a solution that solved a problem revolving around the way routes are placed into routing tables? I keep forgetting that Cisco's way may not be the only way. ;-> Chuck ""Fred Ingham"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > reflectors. > > The requirement for the BGP/OSPF identifier is stated in RFC 1364: > > "Varadhan[Page > 4] > > RFC 1364 BGP OSPF InteractionSeptember 1992 > > > 3. BGP Identifier and OSPF router ID > >The BGP identifier must be the same as the OSPF router id at all >times that the router is up. > >This characteristic is required for two reasons. > > i. Consider the scenario in which 3 routers, RT1, RT2, and RT3, >belong to the same autonomous system. > > +-+ > | RT3 | > +-+ >| > > Autonomous System running OSPF > > / \ > +-+ +-+ > | RT1 | | RT2 | > +-+ +-+ > >Both RT1 and RT2 have routes to an external network X and import it >into the OSPF routing domain. RT3 is advertising the route to >network X to other external BGP speakers. RT3 must use the OSPF >router ID to determine whether it is using RT1 or RT2 to forward >packets to network X and hence build the correct AS_PATH to advertise >to other external speakers. > >More precisely, RT3 must use the AS_PATH of the route announced by >the ASBR, whose BGP Identifier is the same as the OSPF routerID >corresponding to its route for network X. > > ii. It will be convenient for the network administrator looking > at >an ASBR to correlate different BGP and OSPF routes based on >the identifier." > > > Cisco issued a field notice on the problem where there was a route > reflector. (Can't locate it in my pile(s)) > > In One Tech Note (BGP Best Path Selection Algorithm): > > "Paths marked as "not synchronized" in the show ip bgp > output. If BGP synchronization is enabled, which it is by default in > Cisco IOS. Software, there must be a match for the prefix in the IP > routing table in order for an internal (iBGP) path to be considered a > valid path. If the matching route is learned from an OSPF neighbor, its > OSPF router ID must match the BGP router ID of the iBGP neighbor. Most > users prefer to disable synchronization using the no synchronization BGP > subcommand." > > The comparison can be done using the sh ip bgp xxx.yyy.zzz.aaa and show > ip ospf data. > > HTH, Fred. > > John Neiberger wrote: > > > > We discovered something on the CCIE list recently and I'm > > wondering if anyone might be able to explain the reasoning > > behing this behavior. > > > > BGP synchronization rules require that if an iBGP peer is to > > advertise a route learned via iBGP, it must have that prefix > > *and* the next hop for that route in the routing table already. > > > > An interesting added complexity to this occurs if your IGP is > > OSPF. If the router in question has learned these prefixes via > > OSPF, then the advertising router ID in the OSPF database must > > match the router ID of the iBGP peer that advertised the route. > > > > Has this behavior caused any problems for any of you? Do you > > know why the synchronization rules have a special case for OSPF > > and not other routing protocols? > > > > I was working with someone else on a practice lab and we ran > > into this issue. We were both going nuts trying to figure out > > why the iBGP routes weren't synchronizing and this turned out > > to be the cause. > > > > Any thoughts? > > > > Thanks, > > John > > > > > > Get your own "800" number > > Voicemail, fax, email, and a lot more > > http://www.ureach.com/reg/tag
Re: OSPF into iBGP with Sync [7:30126]
BGP-OSPF interaction has specifically been made Historic by the IETF (i.e., obsolete). It's not in the current BGP documents, and there is an administrative document that obsoletes 1364. Sounds like Cisco meets the old RFC 1364, but new implementations won't have the restriction. >reflectors. > >The requirement for the BGP/OSPF identifier is stated in RFC 1364: > >"Varadhan[Page >4] > >RFC 1364 BGP OSPF InteractionSeptember 1992 > > >3. BGP Identifier and OSPF router ID > >The BGP identifier must be the same as the OSPF router id at all >times that the router is up. > >This characteristic is required for two reasons. > > i. Consider the scenario in which 3 routers, RT1, RT2, and RT3, >belong to the same autonomous system. > > +-+ > | RT3 | > +-+ >| > > Autonomous System running OSPF > > / \ > +-+ +-+ > | RT1 | | RT2 | > +-+ +-+ > >Both RT1 and RT2 have routes to an external network X and import it >into the OSPF routing domain. RT3 is advertising the route to >network X to other external BGP speakers. RT3 must use the OSPF >router ID to determine whether it is using RT1 or RT2 to forward >packets to network X and hence build the correct AS_PATH to advertise >to other external speakers. > >More precisely, RT3 must use the AS_PATH of the route announced by >the ASBR, whose BGP Identifier is the same as the OSPF routerID >corresponding to its route for network X. > > ii. It will be convenient for the network administrator looking >at >an ASBR to correlate different BGP and OSPF routes based on >the identifier." > > >Cisco issued a field notice on the problem where there was a route >reflector. (Can't locate it in my pile(s)) > >In One Tech Note (BGP Best Path Selection Algorithm): > >"Paths marked as "not synchronized" in the show ip bgp >output. If BGP synchronization is enabled, which it is by default in >Cisco IOS. Software, there must be a match for the prefix in the IP >routing table in order for an internal (iBGP) path to be considered a >valid path. If the matching route is learned from an OSPF neighbor, its >OSPF router ID must match the BGP router ID of the iBGP neighbor. Most >users prefer to disable synchronization using the no synchronization BGP >subcommand." > >The comparison can be done using the sh ip bgp xxx.yyy.zzz.aaa and show >ip ospf data. > >HTH, Fred. > >John Neiberger wrote: >> >> We discovered something on the CCIE list recently and I'm >> wondering if anyone might be able to explain the reasoning >> behing this behavior. >> >> BGP synchronization rules require that if an iBGP peer is to >> advertise a route learned via iBGP, it must have that prefix >> *and* the next hop for that route in the routing table already. >> >> An interesting added complexity to this occurs if your IGP is >> OSPF. If the router in question has learned these prefixes via >> OSPF, then the advertising router ID in the OSPF database must >> match the router ID of the iBGP peer that advertised the route. >> >> Has this behavior caused any problems for any of you? Do you >> know why the synchronization rules have a special case for OSPF >> and not other routing protocols? >> >> I was working with someone else on a practice lab and we ran >> into this issue. We were both going nuts trying to figure out >> why the iBGP routes weren't synchronizing and this turned out >> to be the cause. >> >> Any thoughts? >> >> Thanks, >> John >> >> >> Get your own "800" number >> Voicemail, fax, email, and a lot more >> http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30367&t=30126 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF into iBGP with Sync [7:30126]
Good find! Some additional info. Per rfc 3166, RFC 1403, which obsoletes 1364, has been moved to historic status since no one ever implemented it. This is likely because redistributing BGP into your IGP really isn't a great idea unless you'd like to see how fast you can dump your entire network as routers choke on 100k type 5's. Interesting thing to troubleshoot as well :) Pete At 02:19 PM 12/28/2001 -0500, you wrote: >reflectors. > >The requirement for the BGP/OSPF identifier is stated in RFC 1364: > >"Varadhan[Page >4] >RFC 1364 BGP OSPF InteractionSeptember 1992 > > >3. BGP Identifier and OSPF router ID > >The BGP identifier must be the same as the OSPF router id at all >times that the router is up. > >This characteristic is required for two reasons. > > i. Consider the scenario in which 3 routers, RT1, RT2, and RT3, >belong to the same autonomous system. > > +-+ > | RT3 | > +-+ >| > > Autonomous System running OSPF > > / \ > +-+ +-+ > | RT1 | | RT2 | > +-+ +-+ > >Both RT1 and RT2 have routes to an external network X and import it >into the OSPF routing domain. RT3 is advertising the route to >network X to other external BGP speakers. RT3 must use the OSPF >router ID to determine whether it is using RT1 or RT2 to forward >packets to network X and hence build the correct AS_PATH to advertise >to other external speakers. > >More precisely, RT3 must use the AS_PATH of the route announced by >the ASBR, whose BGP Identifier is the same as the OSPF routerID >corresponding to its route for network X. > > ii. It will be convenient for the network administrator looking >at >an ASBR to correlate different BGP and OSPF routes based on >the identifier." > > >Cisco issued a field notice on the problem where there was a route >reflector. (Can't locate it in my pile(s)) > >In One Tech Note (BGP Best Path Selection Algorithm): > >"Paths marked as "not synchronized" in the show ip bgp >output. If BGP synchronization is enabled, which it is by default in >Cisco IOS. Software, there must be a match for the prefix in the IP >routing table in order for an internal (iBGP) path to be considered a >valid path. If the matching route is learned from an OSPF neighbor, its >OSPF router ID must match the BGP router ID of the iBGP neighbor. Most >users prefer to disable synchronization using the no synchronization BGP >subcommand." > >The comparison can be done using the sh ip bgp xxx.yyy.zzz.aaa and show >ip ospf data. > >HTH, Fred. > >John Neiberger wrote: > > > > We discovered something on the CCIE list recently and I'm > > wondering if anyone might be able to explain the reasoning > > behing this behavior. > > > > BGP synchronization rules require that if an iBGP peer is to > > advertise a route learned via iBGP, it must have that prefix > > *and* the next hop for that route in the routing table already. > > > > An interesting added complexity to this occurs if your IGP is > > OSPF. If the router in question has learned these prefixes via > > OSPF, then the advertising router ID in the OSPF database must > > match the router ID of the iBGP peer that advertised the route. > > > > Has this behavior caused any problems for any of you? Do you > > know why the synchronization rules have a special case for OSPF > > and not other routing protocols? > > > > I was working with someone else on a practice lab and we ran > > into this issue. We were both going nuts trying to figure out > > why the iBGP routes weren't synchronizing and this turned out > > to be the cause. > > > > Any thoughts? > > > > Thanks, > > John > > > > > > Get your own "800" number > > Voicemail, fax, email, and a lot more > > http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30375&t=30126 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF into iBGP with Sync [7:30126]
Hmm.. Reading more, I think I made a mistake (there's a new one) Anyway, Routers 1, 2, and 3 are BGP peers, however they connect via an IGP domain that doesn't participate in BGP. RT3 will learn of prefix X 4 times. Once from each ASBR via BGP with full attributes intact. Once from each ASBR via OSPF. RT3 will prefer the OSPF route from the ASBR which resides closest to it. At that point, RT3 will attempt to advertise prefix X, but will need to know which of the two BGP announcements to pull attributes from. If the OSPF RID didn't match the BGP ID, RT3 might not know which ASBR it was using. If they do, its a simple comparison and the route gets properly advertised with the right attributes intact. I think that's what the goal was, but again, this is old stuff and you really needed to be there to get a feel for the limitations of the current networks. Pete At 03:17 PM 12/28/2001 -0500, you wrote: >Fred, this is fascinating reading ( ok, so I need a life :-> ) but I am >failing to understand the "why" behind the requirement. >Recognizing that there were real problems in real networks that those who >wrote the RFC were trying to solve, is there something I am missing in the >description? > >In the example below, all routers are in the same AS. When R3 advertises to >an eBGP neighbor, the AS-PATH is going to be the same, no matter which of >the other two routers is the next-hop... > >hhhm. if R1 were the actual recipient of the network X >route, and via OSPF advertised it to R2, and then bothe R1 and R2 >advertised the router to R3. > >m I'm still lost. espcially since this makes no difference >in any other routing protocol vs BGP situation. I would think that R3 would >be using the OSPF route because OSPF has a better admin distance than does >iBGP but then that's just Cisco. > >Am I correct in thinking this is a solution that solved a problem revolving >around the way routes are placed into routing tables? I keep forgetting that >Cisco's way may not be the only way. ;-> > >Chuck > > > > > >""Fred Ingham"" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > reflectors. > > > > The requirement for the BGP/OSPF identifier is stated in RFC 1364: > > > > > "Varadhan[Page > > 4] > > > > RFC 1364 BGP OSPF InteractionSeptember 1992 > > > > > > 3. BGP Identifier and OSPF router ID > > > >The BGP identifier must be the same as the OSPF router id at all > >times that the router is up. > > > >This characteristic is required for two reasons. > > > > i. Consider the scenario in which 3 routers, RT1, RT2, and RT3, > >belong to the same autonomous system. > > > > +-+ > > | RT3 | > > +-+ > >| > > > > Autonomous System running OSPF > > > > / \ > > +-+ +-+ > > | RT1 | | RT2 | > > +-+ +-+ > > > >Both RT1 and RT2 have routes to an external network X and import it > >into the OSPF routing domain. RT3 is advertising the route to > >network X to other external BGP speakers. RT3 must use the OSPF > >router ID to determine whether it is using RT1 or RT2 to forward > >packets to network X and hence build the correct AS_PATH to advertise > >to other external speakers. > > > >More precisely, RT3 must use the AS_PATH of the route announced by > >the ASBR, whose BGP Identifier is the same as the OSPF routerID > >corresponding to its route for network X. > > > > ii. It will be convenient for the network administrator looking > > at > >an ASBR to correlate different BGP and OSPF routes based on > >the identifier." > > > > > > Cisco issued a field notice on the problem where there was a route > > reflector. (Can't locate it in my pile(s)) > > > > In One Tech Note (BGP Best Path Selection Algorithm): > > > > "Paths marked as "not synchronized" in the show ip bgp > > output. If BGP synchronization is enabled, which it is by default in > > Cisco IOS. Software, there must be a match for the prefix in the IP > > routing table in order for an internal (iBGP) path to be considered a > > valid path. If the matching route is learned from an OSPF neighbor, its > > OSPF router ID must match the BGP router ID of the iBGP neighbor. Most > > users prefer to disable synchronization using the no synchronization BGP > > subcommand." > > > > The comparison can be done using the sh ip bgp xxx.yyy.zzz.aaa and show > > ip ospf data. > > > > HTH, Fred. > > > > John Neiberger wrote: > > > > > > We discovered something on the CCIE list recently and I'm > > > wondering if anyone might be able to explain the reasoning > >
Re: OSPF into iBGP with Sync [7:30126]
John et al: The first part of my message said that this is a particular problem with route reflectors. Don't know what I'm doing but the first line of my messages gets chopped frequently. Just didn't want people to think the BGP/OSPF requirement was arbitrary, though it seems to be based on an obsolete RFC. As you found, it is real in cisco BGP/OSPF configurations. Thanks to Howard and Pete for updating me on the RFC's. Cheers, Fred. John Neiberger wrote: > > Fred, > > Thanks, that's exactly what I was looking for, although it appears that > the first part of your response was chopped off for some reason. > > John > > >>> "Fred Ingham" 12/28/01 12:19:59 PM >>> > reflectors. > > The requirement for the BGP/OSPF identifier is stated in RFC 1364: > > "Varadhan[Page > 4] > > RFC 1364 BGP OSPF InteractionSeptember > 1992 > > > 3. BGP Identifier and OSPF router ID > >The BGP identifier must be the same as the OSPF router id at all >times that the router is up. > >This characteristic is required for two reasons. > > i. Consider the scenario in which 3 routers, RT1, RT2, and > RT3, >belong to the same autonomous system. > > +-+ > | RT3 | > +-+ >| > > Autonomous System running OSPF > > / \ > +-+ +-+ > | RT1 | | RT2 | > +-+ +-+ > >Both RT1 and RT2 have routes to an external network X and import it >into the OSPF routing domain. RT3 is advertising the route to >network X to other external BGP speakers. RT3 must use the OSPF >router ID to determine whether it is using RT1 or RT2 to forward >packets to network X and hence build the correct AS_PATH to > advertise >to other external speakers. > >More precisely, RT3 must use the AS_PATH of the route announced by >the ASBR, whose BGP Identifier is the same as the OSPF routerID >corresponding to its route for network X. > > ii. It will be convenient for the network administrator looking > at >an ASBR to correlate different BGP and OSPF routes based on >the identifier." > > Cisco issued a field notice on the problem where there was a route > reflector. (Can't locate it in my pile(s)) > > In One Tech Note (BGP Best Path Selection Algorithm): > > "Paths marked as "not synchronized" in the show ip bgp > output. If BGP synchronization is enabled, which it is by default in > Cisco IOS. Software, there must be a match for the prefix in the IP > routing table in order for an internal (iBGP) path to be considered a > valid path. If the matching route is learned from an OSPF neighbor, > its > OSPF router ID must match the BGP router ID of the iBGP neighbor. Most > users prefer to disable synchronization using the no synchronization > BGP > subcommand." > > The comparison can be done using the sh ip bgp xxx.yyy.zzz.aaa and > show > ip ospf data. > > HTH, Fred. > > John Neiberger wrote: > > > > We discovered something on the CCIE list recently and I'm > > wondering if anyone might be able to explain the reasoning > > behing this behavior. > > > > BGP synchronization rules require that if an iBGP peer is to > > advertise a route learned via iBGP, it must have that prefix > > *and* the next hop for that route in the routing table already. > > > > An interesting added complexity to this occurs if your IGP is > > OSPF. If the router in question has learned these prefixes via > > OSPF, then the advertising router ID in the OSPF database must > > match the router ID of the iBGP peer that advertised the route. > > > > Has this behavior caused any problems for any of you? Do you > > know why the synchronization rules have a special case for OSPF > > and not other routing protocols? > > > > I was working with someone else on a practice lab and we ran > > into this issue. We were both going nuts trying to figure out > > why the iBGP routes weren't synchronizing and this turned out > > to be the cause. > > > > Any thoughts? > > > > Thanks, > > John > > > > > > Get your own "800" number > > Voicemail, fax, email, and a lot more > > http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30409&t=30126 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
