RE: bgp best path compare-routerid implementation example
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:devan...@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
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:devan...@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 mailto:aust...@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:devan...@gmail.com<mailto:devan...@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
RE: Failover solution using BGP
If you don't have control over the other site my best advice would be to use the BGP communities your transit providers give you. If you setup your clients routes to a lower Local Perf on your transit provider's network, your transit provider will always pick the primary provider's routes first. The moment the primary site stops announcing the route your transit provider will immediately start announcing yours. This works better then AS prepend because almost all providers override the AS prepend with a higher local pref for free peers, local customers, etc. The only other issue would be, how to stop the primary network from advertising your client's routes automatically. This could be done by the client setting up BGP with the primary provider and then pulling the routes. If your client does not run BGP then it all depends on how the ips are setup on the primary side. My best advice is if they don't have BGP to tell them to set it up. Tell them to setup a private AS BGP session with their provider and just get a default route from them. This way they use just about any piece of networking equipment and they don't need their own external AS. Then they can either shutdown the port, BGP session, or pull the route (all they can do themselves) to have their provider pull the route from the internet. Use this link to find common communities: http://www.onesc.net/communities/ Otherwise, the customer could get around this whole issue by setting up some type global server load balancing. There are quite a few companies that have solutions for this. But it would take a lot more technical networking knowledge on the client side. Austin -Original Message- From: Naveen Nathan [mailto:nav...@calpop.com] Sent: Tuesday, December 30, 2008 5:09 PM To: nanog@nanog.org Subject: Failover solution using BGP Hi, I would appreciate insight and experience for the following situation. I have a client that would like to announce a /18 & /19 over BGP in Sacramento and LA, us being the second location in LA. Our location will be a failover location incase Sacramento goes down. They want failover for extreme cases when they're completly down in Sacramento. They have strict requirements so that traffic to their blocks should exclusively go to Sacramento or LA. This seems difficult to automate and they are aware of this. They will contact their provider to stop announcing the blocks and subsequently contact us to announce their routes. I am wondering is there a better way to approaching the situation without resorting to announcing the routes when the client calls us and tells us to failover. This seems to be the inherent problem aswell because the customer wants this to be a manual process. -- Naveen Nathan To understand the human mind, understand self-deception. - Anon
