Brian,
Thanx for the trick. Nice idea.. It resolves the issue when the bgp connection comes up and routes learned
What about the situation when the bgp connection goes down ? The route 2.2.2.2 may get withdrawn little earlier than 1.1.1.1 which would cause the similar problem... Are trick for this situation ?
Rgds
Bala.
-----Original Message-----
From: Tony Singh [mailto:mothafungla_at_gmail.com]
Sent: Friday, September 20, 2013 11:09 AM
To: Brian McGahan
Cc: BALAKRISHNAN Balaji; ccielab_at_groupstudy.com
Subject: Re: bgp conditional route advertisement
Thanks Brian nice trick
-- BR Sent from my iPhone on 3 On 18 Sep 2013, at 17:24, Brian McGahan <bmcgahan_at_ine.com> wrote: > I don't think changing the scanner is going to help you because the update/withdrawl process it event driven now, it doesn't use the scanner anymore. What you may be able to do is to introduce an additional delay through object tracking though. > > Something like this: > > track 1 ip route 1.1.1.1 255.255.255.255 reachability delay up 60 ! > ip route 3.3.3.3 255.255.255.255 1.1.1.1 track 1 > > This way if 1.1.1.1 is learned before 2.2.2.2, it still waits an additional 60 seconds before 1.1.1.1 is a valid condition to install 3.3.3.3 in the routing table. > > > > HTH, > > Brian McGahan, 4 x CCIE #8593 (R&S/SP/SC/DC), CCDE #2013::13 > bmcgahan_at_INE.com > > Internetwork Expert, Inc. > http://www.INE.com > > -----Original Message----- > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf > Of BALAKRISHNAN Balaji > Sent: Monday, September 16, 2013 3:12 PM > To: Tony Singh; Narbik Kocharians > Cc: ccielab_at_groupstudy.com > Subject: RE: bgp conditional route advertisement > > Tony, > Narbik, > > Thanx for your comments.. > This is a production issue that I am facing.. There is no OSPF here... > The router learns the routes ( 1.1.1.1 and 2.2.2.2) from the directly > connected ibgp peer and conditionally announces 3.3.3.3 to its ebgp > peers.. Though the route being withdrawn immediately, the update is > already getting propagated to rest of the network which is causing undesirable issues.. > Is there anyway, we can introduce a delay in triggering conditional > announcement ( giving enough time for bgp table to converge).. I tried > to play around with bgp scan timer but it did not help. > > Thanx for your help again.. > > Rgds > Bala. > > > From: Tony Singh [mailto:mothafungla_at_gmail.com] > Sent: Monday, September 16, 2013 3:12 PM > To: Narbik Kocharians > Cc: BALAKRISHNAN Balaji; ccielab_at_groupstudy.com > Subject: Re: bgp conditional route advertisement > > Good point, will lab up when I get a chance - cheers Narbik > -- > BR > > Tony > > Sent from my iPhone on 3 > > On 16 Sep 2013, at 19:38, Narbik Kocharians > <narbikk_at_gmail.com<mailto:narbikk_at_gmail.com>> wrote: > Thanks Tony, > > I have not labbed this up but just a thought and I could be wrong..... > what if OSPF is advertising the route to BGP and this is how BGP > router knows the route and this is why it advertises the route, and if > we configure "max-metric router-lsa wait-for-bgp" on the OSPF router > advertising the route, this will configure the router to advertise a > maximum metric until BGP routing tables has converged, I believe it > will wait for 10 minutes. It may work but it needs to be labbed up. Thinking out loud...... > > On Mon, Sep 16, 2013 at 11:15 AM, Tony Singh > <mothafungla_at_gmail.com<mailto:mothafungla_at_gmail.com>> wrote: > > Thanks Narbik nice and clear, I think the reservation that Balaji has > it that when the bgp process resets it causes host route 3.3.3.3 to be > advertised prior to bgp receiving all networks into its rib to me this > is an order of ops where bgp rib will install host route to 1.1.1.1 > into global and not yet learning the 2.2.2.2 route. > > Balaji if you're testing I'd imagine not much traffic being forwarded > to the > 3.3.3.3 network prior to the route being withdrawn. > > The answer is this is just the way the feature works. > > -- > BR > > Tony > > Sent from my iPad > > On 16 Sep 2013, at 18:47, Narbik Kocharians > <narbikk_at_gmail.com<mailto:narbikk_at_gmail.com>> wrote: > Have a look at this lab that I wrote, it might help you: > > http://micronics.nl/BGP-Conditional-Adv.pdf > > On Mon, Sep 16, 2013 at 10:12 AM, Tony Singh > <mothafungla_at_gmail.com<mailto:mothafungla_at_gmail.com>> wrote: > Hi Balaji > > This is a good question one which I have been scratching my head over, > can you confirm if this is in your production environment or is it on > gns/IOU or home lab if so please confirm platform/IOS version > > -- > BR > > Tony > > Sent from my iPad > > On 4 Sep 2013, at 14:58, BALAKRISHNAN Balaji > <Balaji.BALAKRISHNAN_at_swift.com<mailto:Balaji.BALAKRISHNAN_at_swift.com>> wrote: > >> All, >> >> >> >> Any suggestion ?.. Configuration is as below >> >> >> >> ip route 3.3.3.3 255.255.255.255 1.1.1.1 >> >> >> >> Router bgp 65000 >> >> Network 3.3.3.3 mask 255.255.255.255 >> >> neighbour 192.168.1.1 remote-as 65001 >> >> neighbour 192.168.1.1 advertise-map ADVERTISE non-exist-map NONEXIST >> >> ! >> >> Route-map ADVERTISE permit 10 >> >> Match ip address 50 >> >> ! >> >> Access-list 50 permit 3.3.3.3 >> >> ! >> >> Route-map NONEXIST permit 10 >> >> Match ip address 30 >> >> ! >> >> Access-list 30 permit 2.2.2.2 >> >> ! >> >> >> >> Thanx >> >> Balaji >> >> >> >> From: BALAKRISHNAN Balaji >> Sent: Tuesday, September 03, 2013 5:31 PM >> To: ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com> >> Subject: bgp conditional route advertisement >> >> >> >> Hello all, >> >> >> >> I have a scenario that I am struggling to address a specific issue >> and > would >> like to hear your recommendation >> >> >> >> Announce the route 3.3.3.3 to the bgp neighbour only under the >> following condition on the routes it receives from the backbone >> >> >> >> - Only if it has valid 1.1.1.1/32<http://1.1.1.1/32> route on the > bgp table but no >> valid route for 2.2.2.2/32<http://2.2.2.2/32> >> >> >> >> It works fine under the normal situation when both 1.1.1.1 and >> 2.2.2.2 > exist >> in the bgp table ( meaning conditional route does not get triggered) >> . But when the router bounces its bgp connection to the backbone, it >> learns the route 1.1.1.1/32<http://1.1.1.1/32> fraction of a second >> earlier than > 2.2.2.2/32<http://2.2.2.2/32>.. It causes >> the conditional advertisement to kick in momentarily before >> withdrawing immediately after which is causing some undesirable >> instability in the network.. Can you recommend any work around to resolve this issue. >> >> >> >> Rgds >> >> Balaji >> >> >> Blogs and organic groups at http://www.ccie.net >> >> _____________________________________________________________________ >> __ Subscription information may be found at: >> http://www.groupstudy.com/list/CCIELab.html > > > Blogs and organic groups at http://www.ccie.net > > ______________________________________________________________________ > _ Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html > > > > > > > > > > -- > Narbik Kocharians > CCSI#30832, CCIE# 12410 (R&S, SP, Security) > www.MicronicsTraining.com<http://www.micronicstraining.com/> > Sr. Technical Instructor > YES! We take Cisco Learning Credits! > A Cisco Learning Partner > > > > -- > Narbik Kocharians > CCSI#30832, CCIE# 12410 (R&S, SP, Security) > www.MicronicsTraining.com<http://www.micronicstraining.com/> > Sr. Technical Instructor > YES! We take Cisco Learning Credits! > A Cisco Learning Partner > > > Blogs and organic groups at http://www.ccie.net > > ______________________________________________________________________ > _ Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html Blogs and organic groups at http://www.ccie.netReceived on Wed Sep 25 2013 - 23:06:40 ART
This archive was generated by hypermail 2.2.0 : Tue Oct 01 2013 - 06:36:35 ART