AS-prepending not working - because of peer local preference?

Unanswered Question
Mar 23rd, 2009

I am trying to split inbound traffic 70/30 (more or less!) for our network, with two providers, AS701 (Verizon) and AS13385 (Comcast). Since Verizon is originating our AS (AS40385) already, so far I have just fired up BGP with Comcast, so as to "take away" part of the traffic from AS701. However, I think I think we are running into a problem described here:

When I advertise our full /16 subnet to Comcast, even with 5 (!) as-prepends, all traffic is still attracted to Comcast. I think this may be (see above) because Comcast is requesting elevated local preference from their peers, and Comcast and Verizon have many peers in common.

The workaround is to advertise the first half of our subnet, Comcast gets, Verizon originates (And we still don't have to do BGP with Verizon.) This negates any as-prepending because the /17 route is more specific. I hate to engorge the routing table any further, but this seems to work for now. This Comcast AS does not offer any options via communities.

Is this very common? I guess you have to work with the vendor to fix it, that's why BGP stands for "Border Gateway Politics", eh? Or is there something here I'm not understanding because we are originating and Verizon is originating

Thanks in advance,

-w sanders

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Mohamad Qayoom Mon, 03/23/2009 - 14:48

What you are seeing is not very uncommon. Here is an excerpt fom rSam Halabi's BGP book:

Inbound traffic is affected by how the customer advertises its networks to the providers. To affect the providers' behavior dynamically, the customer can manipulate the AS path attribute by inserting bogus entries in the AS path to affect the AS path length. The providers will receive the same prefix information with different path length and will pick the path that has the shortest length (assuming that all higher-priority attributes are the same). Note that in a multiprovider environment, it is not enough to influence the direct provider only because there is no guarantee that the adjacent provider will itself receive traffic from other providers for that customer's networks. Path manipulation will have to influence providers all the way up to the exchange point because this is where the balance (as far as path length) will be tipped one way or the other."

Giuseppe Larosa Mon, 03/23/2009 - 15:19

Hello Wiley,

if I understand correctly you have got a public AS number without being really multihomed.

Verizon has made the job for you to create a with last AS = your AS number.

Then you have added a real eBGP session with a second provider comcast.

For example in europe RIPE doesn't allow this you need to be really multihomed to see accepted the request of a public AS number.

(just a note...)

Then in an attempt to get the desired load ratio you have announced a more specific route /17 to comcast.

Doing so all traffic belonging to /17 should come back via Comcast all traffic of the second half should come back via Verizon.

Well, let me say that your setup is a little uncommon this is not real multihoming unless Verizon has a dedicated router for you acting as your first border router (not necessary with some modern tricks like local-as).

Let me undestand you have stopped to advertise the /16 to comcast ?

It is so. I can see only the /17 coming from comcast

But you have found a solution but you are missing redundancy.

I would reconsider the whole solution thinking of using two routers you control and using two real eBGP peers one to verizon one to comcast.

I think in this other scenario things can be different.

Hope to help


lamav Mon, 03/23/2009 - 15:34


Oftentimes, SPs do NOT honor AS-Path prepends from their customers. They will filter them out to prevent a situation in which their customer is acting as a transient AS and servicing other ASs, which in turn has a domino effect on the SP. In other words, the SP does not want to forward traffic to support ASs that they are not contracted to support.

So, they will filter incoming AS-path prepends with an as-path access list that looks like this:

ip as-path access-list 10 permit ^[0-9]+$

This will prevent the customer from advertising prefixes with more than one AS number. Remember, the contract they have with their customer is that they are originating network advertisements for their own networks, so, in theory, there shouldnt be more than one AS.

The workaround is for you to beg, yes beg, your SP to change their inbound as-path access list filter to the following:

ip as-path access-list 10 permit ^([0-9]+)(_\1)*&

This will allow them to protect themselves by allowing multiple AS numbers in the path, AS LONG AS ITS THE SAME AS NUMBER. This way the SP knows that its just an as-path prepend deliberately set to manipulate inbound traffic and not a prefix advertisment that traverses more than one AS.



wsanders1 Mon, 03/23/2009 - 16:51

Thanks for the replies. The main question is, at a transit provider who peers with both our ISP's, when I send Comcast our /16 instead of our /17, I see:

BGP routing table entry for

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Not advertised to any peer

7922 13385 40385 40385 40385 40385 40385 40385 from (

Origin IGP, metric 0, localpref 100, valid, internal

when I send Comcast only our /17 I see:

BGP routing table entry for

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Not advertised to any peer

701 from (

Origin IGP, metric 128, localpref 80, valid, internal

So - what causes Verizon's lower local precendence over Comcast? If both routes are present, Comcast's will overrride the shorter one. Is this the ISP's policy, or is it a side effect of out lopsided peering, where we don't have eBGP set up with Verizon yet? Intreesting problem so far....

lamav Mon, 03/23/2009 - 16:58


You "see" this where?

Im confused.

You're advertising your prefixes and you are executing this command...where?

Mohamad Qayoom Mon, 03/23/2009 - 17:56

I think he is using some sort of looking glass to see BGP route.

Local-preference is not trasnsitive, which means that when a peer forwards a route, Local_preference value is not passed along.

This is what I see from another looking glass:

BGP routing table entry for, version 50341570

Paths: (2 available, best #1, table Default-IP-Routing-Table)

Not advertised to any peer

1299 3549 7922 13385 40385 40385 40385 40385 40385 40385 (metric 20) from (

Origin IGP, metric 0, localpref 400, valid, confed-internal, best

Community: 8975:598 8975:599 8975:10000 8975:12000 8975:12010

Originator:, Cluster list:

6461 3356 7922 13385 40385 40385 40385 40385 40385 40385 (metric 30) from (

Origin IGP, metric 0, localpref 400, valid, confed-internal

Community: 8975:599 8975:10000 8975:12000 8975:12030

Originator:, Cluster list:

What I see above is that you AS(40385) is being prepended and the best route is not chosen based on Local-Preference.

Can you make sure that you route-map is working as intended?

These two links can be helpful in solving this issue:

Giuseppe Larosa Tue, 03/24/2009 - 00:53

Hello Wiley,

from europe we see the /17 via comcast but Verizon is not prepending your AS number:

I see

sh ip bgp

BGP routing table entry for, version 152541288

Bestpath Modifiers: deterministic-med

Paths: (4 available, best #3)

Multipath: eBGP iBGP

Advertised to update-groups:


8968 3356 701 << missing your AS here !

Comcast is doing well.

BGP routing table entry for, version 153102736

Bestpath Modifiers: deterministic-med

Paths: (4 available, best #1)

Multipath: eBGP iBGP

Advertised to update-groups:


12874 6762 7922 13385 40385 40385 40385 40385 40385 40385

I see as the prefix is originated in AS 701 this is not correct if you registred with ARIN the prefix your AS is the only one that can advertise it.

You need to contact Verizon and to move to a real eBGP multihoming setup


Verizon is wrong in ARIN the prefix is regularly registered to your company as it is your As number

Hope to help


Harold Ritter Tue, 03/24/2009 - 07:31


The lower local preference of Verizon vs. Comcast is simply that this provider sees Comcast as a customer and Verizon (UUnet) as a peer and does assign them different local preference so that it will always prefer a route received from a customer over the same route received from a peer. Generally, the order of preference is as follow: customer route, peer route, transit route.


wsanders1 Tue, 03/24/2009 - 11:14

Thanks for the replies. Yes, I think that's the explanation. Probably 75% of our traffic originates in AS's directly adjacent to Verizon and Comcast. I'm in the process of getting our BGP session up with Verizon and when it's up I'll post back if the local preference magically increases to 100. I'll be surprised if it does, and so we'll continue to have to advertise two different subnets.

Harold Ritter Tue, 03/24/2009 - 18:39


Unfortunately there is currently very little you can do to ensure the path through one provider will be preferred all the way through the Internet.

I found the following document indicating that SAVVIS allows changing the local preference using the following BGP community format 3561:70. Assuming Comcast is not resetting the community on reception, you would be able to influence the local preference set on the path you send to SAVVIS via Comcast so the one received via Verizon is preferred. It is worth trying. If that does not work, the last resort would be to use conditional advertisement.

Also as Giuseppe indicated, it would be worth formalizing your BGP dual homed setup.


Giuseppe Larosa Tue, 03/24/2009 - 13:17

Hello Harold,

I still think Verizon is doing something wrong:

the /16 address block is registered in ARIN by Wiley's company.

So it should appear always as originated in St Mary's College AS number that appears in the Comcast advertisement and not originated by one AS of Verizon.

Wiley: moving to a real eBGP multihomed scenario is recommended current situation can be classified as an AS path inconsistency

Hope to help


Harold Ritter Tue, 03/24/2009 - 17:55


I agree with your recommendation. I was merely trying to explain the behavior Wiley was observing from the transit provider (SAVVIS not to name it) route server.

Note that this behavior will still happen even if Wiley moves to a formal dual homed scenario.


wsanders1 Tue, 03/24/2009 - 21:25

OK, everyone can celebrate - we have our BGP session up with Verizon now, and our paths are kosher. Nevertheless, whenever I advertise to Comcast (AS13385) all our inbound traffic is immediately drawn to them, and inbound through Verizon (AS701) drops to a trickle, regardless of how many AS-prepends I stick on the Comcast advertisement. So it was not a side effect of our bogus path. I think the Savvis example above is just typical of a few peers of Verizon and Comcast that happen to originate a lot of our traffic. We have two very small pipes (44M and 20M) for a community of 1500, so it's easy to jam one of them up with even a few flows.

Looking at some more distant looking glasses, I do see that our prepends are properly observed, and the local preference of both routes is 100.

We're still not really dual-homed, since in the event Verizon goes down, the won't have a place to go to. I'm not worried about that right now and yep I can fix it with conditional advertisement.

I'm going to open a ticket with Comcast to see if they are manipulating localpref with their peers. I'll also try advertising two /17s and see what happens. I'll report back. And thanks, Harold, I'll try sending a Savvis community and see what happens.

Thanks to all for your replies. Border Gateway Politics is fun!


This Discussion