look for BGP routes containing local AS#

Thu Jan 29 16:38:05 UTC 2015

> On 28/01/2015, at 23:38, Song Li <refresh.lsong at 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 at sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"