On 28/01/2015, at 23:38, Song Li <refresh.lsong@gmail.com> wrote:
Hi Patrick,
We want to know what's the reason for the received routes containing local ASN. Hence we need real cases of those routes in the Internet. And any routes like that are welcome, whether they are on Juniper router or other BGP software.
Thank you!
Regards!
OK here you go. 1) Brazil import: Local ASN here: 61894 BGP routing table entry for 177.10.159.0/24 28250 3549 7018 28640 61894 Nexthop 187.1.94.17 (via 187.1.94.17) from Telbrax (187.1.95.241) Origin IGP, metric 0, localpref 100, weight 0, external, best Last update: 20:39:17 ago Communities: 3549:2473 3549:30840 Note that the above route is on my BGP RIB table but will never go into FIB, it’s not marked valid as you can see on a short summary: flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incompleteflags destination gateway lpref med aspath origin 177.10.159.0/24 187.1.94.17 100 0 28250 3549 7018 28640 61894 i It’s lacking * flag (valid). And how the same route when I enable allowas-in: BGP routing table entry for 177.10.159.0/24 28250 3549 7018 28640 61894 Nexthop 187.1.94.17 (via 187.1.94.17) from Telbrax (187.1.95.241) Origin IGP, metric 0, localpref 100, weight 0, external, valid, best Last update: 20:44:42 ago Communities: 3549:2473 3549:30840 Now you can see “valid, best” and on summary you have *> flags: flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin *> 177.10.159.0/24 187.1.94.17 100 0 28250 3549 7018 28640 61894 i 2) USA import: Local ASN here: 28640 Source ASN here: 61894 (same as local above) BGP routing table entry for 177.10.157.0/24 7018 3549 12989 28640 61894 Nexthop 12.122.120.7 (via 12.222.230.129) from 7018-ATT (12.122.120.7) Origin IGP, metric 0, localpref 100, weight 0, external, valid, best Last update: 20:59:52 ago As you can guess, due to “valid, best” this routing entry also has allowas-in. 3) USA import: Local ASN here: 28640 Source ASN here: 4.1392 Another sample is for a transit customer in Latin America from the USA perspective: BGP routing table entry for 191.5.130.0/23 7018 3549 12989 28640 4.1392 4.1392 4.1392 4.1392 Nexthop 12.122.120.7 (via 12.222.230.129) from 7018-ATT (12.122.120.7) Origin IGP, metric 0, localpref 100, weight 0, external, valid, best Last update: 21:21:24 ago I have more samples and scenarios which I can share on private anytime. Here I am using OpenBGP, and first scenario where route is on RIB but never goes on FIB is due to OpenBGP default loop control on route decision engine (RDE.) This is something you can not disable on OpenBGP, so, I had to add this feature to OpenBGP, my patch for it is available here: http://177.10.156.226/~eksffa/l/local-patch-openbgpd-allowas-in.c In the patch header I mention my understanding on how wrong are symptoms where you need to use it, so I will reproduce my understanding: This is a feature that should rarely be needed. Usually the need for this feature suggests something wrong on the current BGP setup. However in some particular setups it's just needed, and can be used without breaking BGP or adding loops. Cisco, Juniper and other BGP routing daemons do offer the same feature, sometimes with explicit control of how many times the AS number is accepted in the as-path. It does not help, the wrong setup will loop anyway Why this is a symptom for something wrong? First, one should not advertise a CIDR prefix on a different location using the same AS number. I know I am doing it wrong and I will fix it, I have a LACNIC assigned ASN, and started a process to get an ARIN assigned ASN. In a couple days I will have my ARIN assigned ASN and I will use it on ARIN locations, so, this scenario will be fixed and I will not see my own ASN in as-path anymore. Other scenarios I have faced, it’s not myself but some customers of mine, on different cities or different neighbors, and they contract independent upstream to the Internet. Say: City1 -> ATT -> Internet City2 -> Level3 -> Internet But city1 and city2 is the same company, and they need to be reached by each other (City1 -> Internet -> City2). What is wrong here is that this setup should have been done on iBGP as a primary option since it’s the same company. But sometimes this is just not possible immediately. Maybe you don’t have that cross connection, and maybe you are doing it right, you DO have an iBGP session but your fiber circuit or wireless circuit comes DOWN for any reason. If you don’t have another backup circuit, City1 will reach City2 via eBGP and therefore the “wrong / unusual” scenario will raise. Maybe a multihop iBGP using eBGP session ("qualify via bgp” on OpenBGP) might be more “correct” from the BGP perspective, but… it’s just the same original problem. The thing is, workarounds like using allowas-in should always be treated as temporary and is a symptom that something is strange, and a good setup should be aimed to stop having your own ASN on a RIB as-path. It’s also very important to notice that this loop prevention mechanism is also a security mechanism. This security mechanism is sometimes used for a good reason by network engineers. Say, if someone start to DDoS you w/ a good DDoS, with forged/spoofed IP addresses etc. I am not able to block by IP, source-as or anything like since I have no reliable information what's the DDoS real source. But with a little help from upstream providers and a few telemetry (flows) we can map the usual as-path for attacking packets to reach me. Therefore you may decide to manipulate your CIDR advertisements and include the AS number that is common path from the attacking vector to me. I confidently rely that when I add someone else’s AS path in my advertisement, this “someone else” will drop the route as a loop prevention when the announcement reaches their router. So, say, if you are attacked from an unknown spoofed source but you can check it is a certain East Europe or Asia or South America or Russian carrier as a common as-path, you can have the effect of blackholing your advertisement on those ASN hops without dealing with BGP communities or other mechanisms that have to be previously agreed and set among peers. So, on the other hand if you, somehow, disable this mechanism, like I just did with allowas-in, you have a potential security problem where someone announcing your CIDR with your ASN or just your ASN somewhere, and this advertisement happens to reach you, You can be victim of attack of different types, ranging from hijacking to other forms of denial of service. So it makes much more urgent the sense that if by any reason you see your own as on prefixes you receive, and you “just need it on FIB”, you must treat it as a temporary configuration and try to get rid of such workaround, getting yourself another ASN or full meshing iBGP among your locations, as the usual first moves to be taken. Regards, -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!"