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
On 25 Sep 2009, at 05:24, devang patel wrote:
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...
Hi, Devang This option is really only used in order to instruct a router to skip the option before it in best path selection algorithm (prefer the path learned from the older established session). I don't think you'd use it if you ran a normal network (or knew what you were doing ;-) ) because you'd typically use much more deterministic decisions to send traffic to specific and predictable paths, or you'd use hot-potato routing and send the traffic to the nearest equivalent exit ('prefer ebgp over ibgp' and 'prefer path with lowest igp metric' comes before 'use the oldest path'). Andy -- Regards, Andy Davidson +44 (0)20 7993 1700 www.netsumo.com NetSumo Specialist networks consultancy for ISPs, Whitelabel 24/7 NOC
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 provider 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 turn off the oldest route metric and use the routerid (not peering ip) to make 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 before 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 always try move those routes back to the FIB. That's probably why they implemented this metric in the first place, the oldest route is the most stable. Another issue is that you are at the mercy of vendor's routerid when your router 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 located here: http://nanog.org/meetings/nanog46/abstracts.php?pt=MTM3MiZuYW5vZzQ2&nm=nanog46 Basically he suggests using MEDs to change the tie breaker as part of a complete BGP traffic engineering solution. Doing the things listed there and elsewhere will mean you won't even have to use this command. Austin Wilson -----Original Message----- From: devang patel [mailto:devangnp@gmail.com] Sent: Thursday, September 24, 2009 9:24 PM To: 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
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 good 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 code "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> 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 provider 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 turn off the oldest route metric and use the routerid (not peering ip) to make 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 before 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 always try move those routes back to the FIB. That's probably why they implemented this metric in the first place, the oldest route is the most stable. Another issue is that you are at the mercy of vendor's routerid when your router 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 located here:
http://nanog.org/meetings/nanog46/abstracts.php?pt=MTM3MiZuYW5vZzQ2&nm=nanog46
Basically he suggests using MEDs to change the tie breaker as part of a complete BGP traffic engineering solution. Doing the things listed there and elsewhere will mean you won't even have to use this command.
Austin Wilson
-----Original Message----- From: devang patel [mailto:devangnp@gmail.com] Sent: Thursday, September 24, 2009 9:24 PM To: 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
Dev, Yes, using that command, it will use the lowest routerid as its preferred tie breaker path. Though, if all of your providers have different MEDs and you 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 interfere with what you are trying to accomplish with a lower metric. Dani suggested 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 good 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 code "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 provider 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 turn off the oldest route metric and use the routerid (not peering ip) to make 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 before 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 always try move those routes back to the FIB. That's probably why they implemented this metric in the first place, the oldest route is the most stable. Another issue is that you are at the mercy of vendor's routerid when your router 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 located here: http://nanog.org/meetings/nanog46/abstracts.php?pt=MTM3MiZuYW5vZzQ2&nm=nanog46 Basically he suggests using MEDs to change the tie breaker as part of a complete BGP traffic engineering solution. Doing the things listed there and elsewhere 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
BGP load-balancing appliances such as the old Routescience Pathcontrol provided a deterministic end-to-end solution by measuring the RTTs of the second and third packets of the TCP 3-way handshake between the commercial web site and user destination networks. A full BGP feed was required from each ISP in the commercial web site's border routers. Over time, by measuring the 3-way handshake's RTTs, Pathcontrol would statistically determine the best route to destination networks, and cause that route to be injected into the border router's BGP table using a BGP route-reflector configuration wherein the Pathcontrol was a route-reflector client that advertised the calculated best route. I think that this scientific approach to BGP load-balancing is intuitively and formally superior to other methods, although bandwidth scalability may be a drawback of the appliance load-balancing approach. -----Original Message----- From: Austin Wilson [mailto:austinw@bandcon.com] Sent: Friday, September 25, 2009 11:22 AM To: devang patel Cc: nanog@nanog.org Subject: RE: bgp best path compare-routerid implementation example Dev, Yes, using that command, it will use the lowest routerid as its preferred tie breaker path. Though, if all of your providers have different MEDs and you 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 interfere with what you are trying to accomplish with a lower metric. Dani suggested 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 good 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 code "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 provider 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 turn off the oldest route metric and use the routerid (not peering ip) to make 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 before 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 always try move those routes back to the FIB. That's probably why they implemented this metric in the first place, the oldest route is the most stable. Another issue is that you are at the mercy of vendor's routerid when your router 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 located here: http://nanog.org/meetings/nanog46/abstracts.php?pt=MTM3MiZuYW5vZzQ2&nm=n anog46 Basically he suggests using MEDs to change the tie breaker as part of a complete BGP traffic engineering solution. Doing the things listed there and elsewhere 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
participants (4)
-
Andy Davidson -
Austin Wilson -
devang patel -
Holmes,David A