Prepending with another ASN you don't own
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. 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. Solution: 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?" -- Andrew Imeson andrew@andrewimeson.com
Even in that case I believe you should encapsulate between two instances of your own ASN. Your example follows this but the text says only about the last one in the path, while having both last and at least one previous is better since you won't be implying that some other AS has connection to yet another AS, it's just you doing this. Rubens On Thu, Dec 15, 2016 at 4:54 PM, Andrew Imeson <andrew@andrewimeson.com> 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.
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.
Solution: 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?"
-- Andrew Imeson andrew@andrewimeson.com
this is called path poisoning. an italian friend used it in his phd thesis. a few friends and i used it to detect use of default across the internet. but 42 people will scream "that's my AS!" of course, as it is your prefix, that is ASinine :) ramdu
On Fri, 16 Dec 2016, Randy Bush wrote:
this is called path poisoning. an italian friend used it in his phd thesis. a few friends and i used it to detect use of default across the internet.
I've done this in the past as a work-around for insufficient BGP community support. Just prepending the AS I wanted to ignore the paths. But, if the problem is an anycast CDN choosing a sub-optimal path to reach you, you might try reaching out to them. They're probably just as, if not more interested, in getting their traffic to you as efficiently as possible. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
this is called path poisoning. an italian friend used it in his phd thesis. a few friends and i used it to detect use of default across the internet.
I've done this in the past as a work-around for insufficient BGP community support. Just prepending the AS I wanted to ignore the paths.
But, if the problem is an anycast CDN choosing a sub-optimal path to reach you, you might try reaching out to them. They're probably just as, if not more interested, in getting their traffic to you as efficiently as possible.
apologies. i should have been more explicit. both of the examples were using path poisoning for routing research. it is not a technique i would reccommend in normal operations. randy
Hi Andrew, 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 leak!
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.
Solution: 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. Kine regards, Job ps. Eric Loos once shared this piece of wisdom with me: "Whenever in doubt, use BGP Communities." ;-)
On 17 Dec 2016, at 0:13, Job Snijders wrote:
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.
+1 ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
participants (6)
-
Andrew Imeson -
Job Snijders -
Jon Lewis -
Randy Bush -
Roland Dobbins -
Rubens Kuhl