[117716] in North American Network Operators' Group
RE: bgp best path compare-routerid implementation example
daemon@ATHENA.MIT.EDU (Austin Wilson)
Fri Sep 25 14:21:58 2009
From: Austin Wilson <austinw@bandcon.com>
To: devang patel <devangnp@gmail.com>
Date: Fri, 25 Sep 2009 11:21:39 -0700
In-Reply-To: <d0fea3580909251107k65e72de2m70920372496e77ad@mail.gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Dev,
Yes, using that command, it will use the lowest routerid as its preferred t=
ie breaker path. Though, if all of your providers have different MEDs and y=
ou are using MEDs to engineer you traffic, your router should never have to=
tie break any traffic. Also any of the higher preference metrics will inte=
rfere with what you are trying to accomplish with a lower metric. Dani sugg=
ested changing the origin code so it wouldn't affect what you are trying to=
do with MEDs.
Everything else is dependent on how you want to manage your network.
Austin Wilson
From: devang patel [mailto:devangnp@gmail.com]
Sent: Friday, September 25, 2009 11:07 AM
To: Austin Wilson
Cc: nanog@nanog.org
Subject: Re: bgp best path compare-routerid implementation example
Hi...
So according to command it will select the path received from lowest router=
id right... so if you are sure about the path selection pattern then its g=
ood idea to use it...
And true that path selection change based on own network design...
is it good idea to set all received route attribute to particular origin co=
de "i" as Dani showed in presentation... well again I guess answer will be =
depends on network design...
Thanks,
Dev
On Fri, Sep 25, 2009 at 11:50 AM, Austin Wilson <austinw@bandcon.com<mailto=
:austinw@bandcon.com>> wrote:
Dev,
This is usually used to offset the oldest route metric. The problem is that=
when a link fails and comes back online, traffic can shift from one provid=
er to another in the middle of your billing cycle. This then could mean you=
get double billed for that traffic. People use the command to basically tu=
rn off the oldest route metric and use the routerid (not peering ip) to mak=
e the last decision on where to send your traffic. This is commonly called =
"tie breaker" traffic. If a peer fails with this command enabled, when the =
peer comes back online, traffic should be restored to the original level be=
fore the failure.
A possible issue with this command is that if a local peer's route/session =
flaps it could have more of an effect on your network/router as it will alw=
ays try move those routes back to the FIB. That's probably why they impleme=
nted this metric in the first place, the oldest route is the most stable. A=
nother issue is that you are at the mercy of vendor's routerid when your ro=
uter decides where to send your "tie breaker" traffic. Level3 gets most of =
this traffic since they have such low routeids.
There are ways to get around this problem and take back control of your tie=
breaker traffic. Dani did a pretty good tutorial on this issue and its loc=
ated here:
http://nanog.org/meetings/nanog46/abstracts.php?pt=3DMTM3MiZuYW5vZzQ2&nm=3D=
nanog46
Basically he suggests using MEDs to change the tie breaker as part of a com=
plete BGP traffic engineering solution. Doing the things listed there and e=
lsewhere will mean you won't even have to use this command.
Austin Wilson
-----Original Message-----
From: devang patel [mailto:devangnp@gmail.com<mailto:devangnp@gmail.com>]
Sent: Thursday, September 24, 2009 9:24 PM
To: nanog@nanog.org<mailto:nanog@nanog.org>
Subject: bgp best path compare-routerid implementation example
Hello Nanog,
I am looking for the *bgp best path compare*-*routerid* implementation
example? I know the function of it but looking for some scenario where its
been used...
Thanks,
Dev
