[177637] in North American Network Operators' Group
Re: look for BGP routes containing local AS#
daemon@ATHENA.MIT.EDU (Patrick Tracanelli)
Thu Jan 29 11:38:45 2015
X-Original-To: nanog@nanog.org
From: Patrick Tracanelli <eksffa@freebsdbrasil.com.br>
In-Reply-To: <54C98F0F.9000002@gmail.com>
Date: Thu, 29 Jan 2015 14:38:05 -0200
To: refresh.lsong@gmail.com
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On 28/01/2015, at 23:38, Song Li <refresh.lsong@gmail.com> wrote:
>=20
> Hi Patrick,
>=20
> 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.
>=20
> Thank you!
>=20
> 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=E2=80=99s not marked valid as you can see on a short summary:
flags: * =3D Valid, > =3D Selected, I =3D via IBGP, A =3D Announced, S =3D=
Stale
origin: i =3D IGP, e =3D EGP, ? =3D Incompleteflags destination =
gateway =20
lpref med aspath origin
177.10.159.0/24 187.1.94.17 100 0 28250 3549 7018 =
28640 61894 i
It=E2=80=99s 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 =E2=80=9Cvalid, best=E2=80=9D and on summary you have *> =
flags:
flags: * =3D Valid, > =3D Selected, I =3D via IBGP, A =3D Announced, S =3D=
Stale
origin: i =3D IGP, e =3D EGP, ? =3D 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:=20
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 =E2=80=9Cvalid, best=E2=80=9D 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?=20
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=E2=80=99s 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=E2=80=99s the same company. But sometimes this =
is just not possible immediately. Maybe you don=E2=80=99t 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=E2=80=99t have another backup circuit, City1 will =
reach City2 via eBGP and therefore the =E2=80=9Cwrong / unusual=E2=80=9D =
scenario will raise.
Maybe a multihop iBGP using eBGP session ("qualify via bgp=E2=80=9D on =
OpenBGP) might be more =E2=80=9Ccorrect=E2=80=9D from the BGP =
perspective, but=E2=80=A6 it=E2=80=99s 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=E2=80=99s 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=E2=80=99s AS path in my =
advertisement, this =E2=80=9Csomeone else=E2=80=9D 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.=20
So it makes much more urgent the sense that if by any reason you see =
your own as on prefixes you receive, and you =E2=80=9Cjust need it on =
FIB=E2=80=9D, 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!"
