[58013] in North American Network Operators' Group
RE: Who is announcing bogons?
daemon@ATHENA.MIT.EDU (David Luyer)
Tue Apr 29 09:01:25 2003
From: "David Luyer" <david@luyer.net>
To: <nanog@merit.edu>
Date: Tue, 29 Apr 2003 23:00:26 +1000
In-Reply-To: <200304290151.h3T1pec23500@ueno.egenius.org>
Errors-To: owner-nanog-outgoing@merit.edu
> Ahhh, but that was not the correct question to ask (I have not read =
the
> study). It is not whether ISP's filter inbound customer route=20
> announcements. It is how they filter them. If the customer goes and=20
> says I am going to announce 4.0.0.0/8 and the ISP just blindly adds
> that to the filter, we have a problem, but the ISP did answer that
> question truthfully. They are filtering.
That's one important question, but another other question is, are _ALL_
customers prefix filtered? How about major peers? Sure, the default,
new, small customer is prefix filtered.
In 2000 -- the same year that study was done -- we were adding prefixes
so quickly that iHug unfiltered us, and EPOCH unfiltered iHug, to =
prevent
the need for us to notify them of every single route change. At any one
time we only had around 150 prefixes maximum - there's just a lot of =
203.*
space which goes back and forward between ISPs in Australia resulting
in a lot of filter updates.
_After_ our circuit had been disconnected from iHug, for a brief period
long before 66.0.0.0/8 was allocated, I tested pushing the /8 to their
BGP peer we had in the US (multihop BGP as it was a satellite service).
In theory:
0. Our BGP session should have been shut down anyway, when our
satellite service was cancelled
1. Bogon filtering would catch it
2. Anyone using RADB would catch it
3. It wouldn't get far as no major network would pick it up
The result - all test sites I tried either saw the route, or default =
routed
to
someone who saw the route.
Here's an example of the non-optimal route taken from one site, but the =
fact
is it still made it to hop #16, after which it would have gone to us if =
our
satellite PVC was still active, and just from this example AARNet, =
Optus,
UUnet, BBN, EPOCH, Netgate and iHug all in some way would reach that =
clearly
bogus advertisement. Which says to me that at least in 2000, the big =
guys
weren't even applying simple bogon filters on routes received between =
each
other.
typhaon; traceroute 66.0.0.1
traceroute to 66.0.0.1 (66.0.0.1), 30 hops max, 40 byte packets
1 muchacho.uwa.edu.au (130.95.128.128) 1.515 ms 0.88 ms 1.702 ms
2 parnet-uwa.parnet.edu.au (203.19.110.17) 2.848 ms 2.664 ms 2.353 =
ms
3 ATM9-0-0-2.ia5.optus.net.au (192.65.88.189) 57.681 ms 57.819 ms
59.205 ms
4 GigEth12-0-0.rr2.optus.net.au (202.139.191.22) 57.83 ms 57.787 ms
57.658 ms
5 POS5-0-0.la1.optus.net.au (192.65.89.214) 368.02 ms 367.933 ms
368.018 ms
6 34.ATM0-0-0.GW1.LAX4.ALTER.NET (157.130.227.181) 373.831 ms =
373.879 ms
374.79 ms
7 121.ATM3-0.XR2.LAX4.ALTER.NET (146.188.248.110) 375.665 ms 374.306 =
ms
373.71 ms
8 193.at-1-1-0.TR1.LAX9.ALTER.NET (152.63.112.174) 373.284 ms 373.43 =
ms
372.938 ms
9 131.at-5-0-0.TR1.DFW9.ALTER.NET (152.63.3.161) 408.254 ms 429.138 =
ms
404.189 ms
10 289.at-1-0-0.XR1.DFW9.ALTER.NET (152.63.98.29) 404.381 ms 407.777 =
ms
410.8 ms
11 185.ATM6-0.BR3.DFW9.ALTER.NET (152.63.100.169) 406.129 ms 404.228 =
ms
404.08 ms
12 137.39.93.10 (137.39.93.10) 433.381 ms 415.909 ms 413.664 ms
13 pos10-0-0.lax-c100.gw.epoch.net (155.229.123.125) 416.909 ms 414 =
ms
416.23 ms
14 pos4-1.pao-c000.gw.epoch.net (155.229.120.49) 414.646 ms 416.578 =
ms
414.258 ms
15 pos8-0-0.npa-m100.gw.epoch.net (155.229.57.74) 417.329 ms 421.818 =
ms
600.575 ms
16 tig-us-pas-1.ihug.net (207.214.25.225) 420.169 ms 417.283 ms =
417.213
ms
17 202-49-88-201.ihug.net (202.49.88.201) 531.449 ms 532.27 ms =
530.245
ms
18 atm-5-0-0-2-netgate-akl.ihug.net (202.49.88.42) 531.121 ms 531.005 =
ms
530.884 ms
19 a0-0-0-2.tkbr1.netgate.net.nz (202.37.246.121) 534.236 ms 532.467 =
ms
530.545 ms
20 s1-1-1.labr1.netgate.net.nz (202.37.245.170) 767.038 ms 734.685 ms
768.571 ms
21 s5-0-0.lsanca1-cr1.bbnplanet.net (4.24.24.17) 681.512 ms 733.892 =
ms
751.962 ms
22 p2-1.lsanca1-ba1.bbnplanet.net (4.24.4.5) 765.545 ms 755.466 ms
680.472 ms
23 p7-0.lsanca1-br1.bbnplanet.net (4.24.4.2) 679.542 ms 766.558 ms
752.332 ms
24 p2-0.lsanca1-br2.bbnplanet.net (4.24.4.14) 750.405 ms 680.72 ms
765.398 ms
25 p1-0.crtntx1-ba1.bbnplanet.net (4.24.6.78) 808.366 ms 792.82 ms
806.672 ms
26 p1-0.crtntx1-ba2.bbnplanet.net (4.24.4.242) 786.897 ms 790.172 ms
770.245 ms
27 4.24.147.38 (4.24.147.38) 781.226 ms 782.357 ms 785.577 ms
28 pos10-0-0.lax-c100.gw.epoch.net (155.229.123.125) 850.728 ms =
782.862
ms 782.42 ms
29 pos4-1.pao-c000.gw.epoch.net (155.229.120.49) 788.301 ms 782.932 =
ms
786.786 ms
30 pos8-0-0.npa-m100.gw.epoch.net (155.229.57.74) 840.266 ms 841.006 =
ms
785.38 ms
2000 isn't very long ago. It would be interesting to see what a similar
unallocated route leaked into a significant provider would achieve =
today.
David.
