17

A colleague is attempting to implement active/passive internet multihoming. The design entails sending communities (listed below) to the passive provider to lower the local preference at remote ASes for the advertised routes. The documentation states repeatedly that the communities are for customer use and we are not a customer of these providers. I would think that giving the internet-at-large the ability to alter local preference is a huge security risk. Would this have a snowball's chance in hell of actually working?

1273:70     cable and wireless plc local pref 70
2828:1507   xo local pref 70
3356:70     level3 local pref 70
3549:100    global crossing local pref 100
4323:80     twtelecom local pref 80
1299:50     teliasonera local pref 50
generalnetworkerror
  • 7,094
  • 6
  • 32
  • 65
Dennis Olvany
  • 2,435
  • 1
  • 17
  • 34
  • 1
    Is 'onestep' your backup provider itself? If so, then sure those should work just fine when advertised to 'onestep' and in my opinion is preferable design over prepend. Otherwise they are useless, even if your routes were passing them, it's unlikely they'd work from their peers. Does your direct neighbor not provide comparable list? – ytti Jun 01 '13 at 19:28
  • One Step is not our provider. From what I gather, One Step is not a provider at all. The direct neighbor may have such a list. I will have to do some research. – Dennis Olvany Jun 01 '13 at 22:52
  • 2
    OneStep is a consultancy that happens to aggregate community guides from all the NSPs. – generalnetworkerror Jun 02 '13 at 03:03
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer. – Ron Maupin Jan 03 '21 at 01:56

3 Answers3

15

It is unlikely (but not impossible) for the communities you tag on your routes to propagate past your upstream. Most providers will strip the communities out before readvertising routes up/downstream.

If you want to influence multiple remote ASes in this manner, you would need to use AS_PATH prepending. Prepend 2-3 times to your backup/passive provider, and then most/all traffic will flow down your active path until it fails. Then traffic should shift to your passive path once the failed route gets withdrawn.

Justin Seabrook-Rocha
  • 1,353
  • 10
  • 23
  • 4
    If customer A has transit from provider P1 and P2 and they prepend to P2. Then another customer B of P2 may local_pref routes received from P2 (maybe it's cheaper), i.e. prepending does not guarantee that all traffic will switch and there is no real way to guarantee this in BGP, apart from pulling the route from non-preferred or leaking more specifics to preferred partner, neither of which can be recommended. – ytti Jun 01 '13 at 19:18
  • 2
    Correct! Thus the eternal struggle of traffic engineering, how to influence a network you have no relationship with. I should probably have said "most" instead of "all", but prepending and more-specifics are really the only two options that can really have an affect in this case. – Justin Seabrook-Rocha Jun 01 '13 at 19:22
  • 3
    As ytti said, AS_PATH tricks are at best a suggestion. At the end of the day, the local admin preferences will win. If I want traffic to a specific network to cross a specific link, *it will*; there is nothing the internet can do to change my routing configuration. – Ricky Jun 01 '13 at 22:45
6

The provider should have a filter inbound to ensure these communities are only accepted from customers. If not, then that's the providers issue.

Some Tier1 providers do accept these sorts of communities from anywhere though. This is based on RFC 1998: https://www.rfc-editor.org/rfc/rfc1998.html

Community
  • 1
mellowd
  • 3,824
  • 19
  • 24
5

The best you can usually do is look for communities with your provider that allow you to indicate prepends per peer of your provider. This assumes your provider has such communities and has the peering relationships for this to work. Prepending your own announcements to your peer would have no variation upstream from your provider. Though this method does not alter localpref one AS removed from your provider, it has similar impact in making that path back to you less desirable. There is an exception to influencing localpref upstream that I'll describe at the bottom, though it's probably an edge case.

Some providers such as XO [AS2828] allow you to advertise your prefixes in such a way that your provider announces your routes with with specific prepends for certain peers of theirs.

For example, XO accepts:

2828:1108 prepends once for AT&T
2828:1207 prepends twice for Level3
2828:1303 preprends thrice for Sprint

On Savvis, the community is 3561:30151 which prepends once for AT&T.

These providers usually have communities to indicate the well-known communities of NO_EXPORT or NO_ADVERTISE to specific peers.

One Tier 2 provider I know, InterNAP, is able to influence localpref upstream because they buy transit, so they are a customer of the Tier 1's. They have communities that you could use where they attempt to translate those into specific Tier 1 communities for your upstream advertisements which set localpref to peer-, mid-, or high-level values. See http://www.onesc.net/communities/as6993/Internap-Customer-Guide-1.3.pdf.

Example References:
XO Communities that Change Customer Announcements to Certain Peers at AS2828 Border
Savvis Prepend Community Attributes

I have no affiliation with the providers used in the examples other than direct experience as a customer.

generalnetworkerror
  • 7,094
  • 6
  • 32
  • 65