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