RE: bgp conditional route advertisement

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