Feedback on providers who offer communities that restrict route propagation
Hi, I'm looking at a number of transit providers in Europe who offer communities that will limit the scope of an announcement by geographic region. For example if you are AS1 you can tell upstream AS2 to propagate your announcements only to peers and neighbors within EU, but not those in the NA or AP regions. This helps networks with unique routing policies. (If you're curious what these might be, just ping me offlist) I'm looking for feedback from people who have done this before. All advice, experiences (preferably with what upstream ASNs) is helpful. Our concerns are basically that this puts a management and engineering aspect of our network into someone else's hands to not mess up. I already know we deal with peers who leak routes, but my guess is that since this is a business relationship with the upstream network they are less likely to bork it up and hopefully manage it programatically. Wishful thinking or sound practice/service offered by high-quality carriers? My questions are thus: 1) I'd this to find out how reliable it is/was (were your routes ever leaked)? 2) How effective it is/was (did it accomplish your goals)? 3) Advice you might have for someone who is considering doing this? Providers to shy away from? Providers who are pretty good? Thanks, David Ulevitch
David Ulevitch schrieb:
My questions are thus:
As a long term customer of AS702 UUnet / Worldcom / MCI / Verizon Business I have some experience using their community support documented here: http://www.verizonbusiness.com/uk/customer/bgp/ I guess other carrier have similar community support (I can tell that 1239, 1299 and 3549 do have, but I don't have public links).
1) I'd this to find out how reliable it is/was (were your routes ever leaked)?
It worked, but it has to be used carefully.
2) How effective it is/was (did it accomplish your goals)?
Partly. You can control mainly inbound traffic, for instance forcing traffic which normally flows from "Incumbent" -> 702 -> "You" a longer way like "Incumbent" -> 701 -> 702 -> "You". Which of course gives much longer latency, and it forces "Incumbent" to pay traffic towards 701, while traffic towards 702 would be free peering. However, in my case, traffic from "Incumbent" -> "You" wasn't considerable, but much more "You" -> "Incumbent", read outbound traffic. There is no community setting to force 702 using the longer path via 701. 702 will always drop the hot potato on the nearest exit (peering port towards incumbent).
3) Advice you might have for someone who is considering doing this? Providers to shy away from? Providers who are pretty good?
Play around with an unused / not yet used prefix (not a more specific) to find out the behaviour with remote LG etc. before using it in production. HTH, Fredy
participants (2)
-
David Ulevitch -
Fredy Kuenzler