[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Prepending with another ASN you don't own
- Subject: Prepending with another ASN you don't own
- From: job at ntt.net (Job Snijders)
- Date: Fri, 16 Dec 2016 18:13:50 +0100
- In-reply-to: <CAF2cQ[email protected]>
- References: <CAF2cQ[email protected]>
On Thu, Dec 15, 2016 at 01:54:34PM -0500, Andrew Imeson wrote:
> Is it acceptable to prepend using another networks ASN as long as your
> ASN is the last one in the path? I can think of a few scenarios where
> this is helpful.
Your milage may vary. You risk introducing breakage instead of the
desired optimisation. There are providers who inspect the AS_PATH's
contents and make decisions to reject (ignore) a route announcement or
not based on the presence of certain values.
An example: If NTT's backbone (AS 2914) receives a route announcement
from any of its adjacent ASN (customers and peering partners alike)
which contains AT&T's ASN (7018), _anywhere_ in the AS_PATH, the
announcement is considered invalid and rejected (except on the direct
2914 <> 7018 BGP sessions of course).
This concept is called 'Peerlocking'. NTT has enabled this for an
undisclosed number of ASNs. This is a highly effective measure against
route leaks. More information: https://www.youtube.com/watch?v=CSLpWBrHy10
So, where you initially targetted to manipulate one ASN's best path
selection, you could end up being unreachable from mulitple seemingly
unrelated ASNs because they consider the announcement part of a route
> One scenario: Anycast content provider with an ISP (who you aren't
> directly peering with) is choosing to send all traffic to a PoP on
> another continent.
> Prepend at the geographically-distant PoP so that the AS path looks
> like <ACME> <BAD-ISP> <ACME>, and thus that service provider
> (<BAD-ISP>) views it as a routing loop and chooses one of your other
> PoPs. Sure there are better solutions like communities, but why (if it
> is) would this be "bad?"
You are right that BGP Communities usually are a better method,
especially BGP Communities which are acted upon on "ibgp-in" rather then
"ebgp-out" (with per-region granularity). Communities which manipulate
the intermediate provider's best path selection can have a better effect
on keeping traffic local for anycasters then just suppressing
announcements on the far-end.
For instance, the community to "set lowest local preference, but only on
routers located outside the country I'm connected in" (2914:435 in NTT's
network) can in many cases replace the need for forging AS_PATHs. Such a
method also provides a safetynet: there always is a route, but during
normal operations its just highly unattractive. With AS_PATH forging you
don't automatically protect yourself against certain outage scenarios.
Finally, keep in mind that there are networks which have disabled
AS_PATH Loop Detection, or point default somewhere, so the forged
AS_PATH kludge might be in-effective.
ps. Eric Loos once shared this piece of wisdom with me: "Whenever in doubt, use BGP Communities." ;-)