Wiley:

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.

HTH

Victor

Huh?

You "see" this where?

Im confused.

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

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 149.137.0.0/17, 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

212.43.193.45 (metric 20) from 212.43.193.51 (212.43.193.51)

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

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

Originator: 212.43.193.63, Cluster list: 212.43.193.51

6461 3356 7922 13385 40385 40385 40385 40385 40385 40385

212.43.193.52 (metric 30) from 212.43.193.49 (212.43.193.49)

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

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

Originator: 212.43.193.52, Cluster list: 212.43.193.49

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:

http://noc.eu.clara.net/lg.php

https://www.dan.me.uk/bgplookup?asn=40385&include_downstream=on

Hello Wiley,

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

I see

sh ip bgp 149.137.0.0 255.255.0.0

BGP routing table entry for 149.137.0.0/16, version 152541288

Bestpath Modifiers: deterministic-med

Paths: (4 available, best #3)

Multipath: eBGP iBGP

Advertised to update-groups:

1

8968 3356 701 << missing your AS here !

Comcast is doing well.

BGP routing table entry for 149.137.0.0/17, version 153102736

Bestpath Modifiers: deterministic-med

Paths: (4 available, best #1)

Multipath: eBGP iBGP

Advertised to update-groups:

1

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

Edit:

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

Hope to help

Giuseppe

Wiley,

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.

Regards

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.

Wiley,

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.

Regards

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

Giuseppe

Giuseppe,

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.

Regards

Cheers!