Having trouble reaching route-views.linx.routeviews.org from AS3582. I'm assuming that some folks stopped carrying this particular linx.net address prefix as of this morning. ?!? $ whois -h whois.cymru.com " -v 195.66.241.146" AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 5459 | 195.66.241.146 | 195.66.240.0/22 | GB | ripencc | 1997-12-01 | LINX-AS London Internet Exchange Ltd. $ dig +short 146.241.66.195.peer.asn.cymru.com TXT "1299 2914 3257 10310 | 195.66.240.0/22 | GB | ripencc | 1997-12-01" -- John Kemp (kemp@routeviews.org) RouteViews Engineer NOC: noc@routeviews.org MAIL: help@routeviews.org WWW: http://www.routeviews.org
Hi John, On Apr 4, 2013, at 12:52 AM, John Kemp <kemp@network-services.uoregon.edu> wrote:
Having trouble reaching route-views.linx.routeviews.org from AS3582.
I'm assuming that some folks stopped carrying this particular linx.net address prefix as of this morning. ?!?
Indeed LINX has taken steps recently to reduce the scope and reach of their peering LAN prefix to partially mitigate some types of attack. I'd be happy to help you off-list to get some permanent connectivity back to the machine. Kind regards, Job
I noticed it too this morning from a AS3549 customer. Level 3 LG shows no route for 195.66.232.0/22 on North American sites. On Wed, Apr 3, 2013 at 6:52 PM, John Kemp <kemp@network-services.uoregon.edu> wrote:
Having trouble reaching route-views.linx.routeviews.org from AS3582.
I'm assuming that some folks stopped carrying this particular linx.net address prefix as of this morning. ?!?
$ whois -h whois.cymru.com " -v 195.66.241.146" AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 5459 | 195.66.241.146 | 195.66.240.0/22 | GB | ripencc | 1997-12-01 | LINX-AS London Internet Exchange Ltd.
$ dig +short 146.241.66.195.peer.asn.cymru.com TXT "1299 2914 3257 10310 | 195.66.240.0/22 | GB | ripencc | 1997-12-01"
-- John Kemp (kemp@routeviews.org) RouteViews Engineer NOC: noc@routeviews.org MAIL: help@routeviews.org WWW: http://www.routeviews.org
Yes. In the fallout from the Cloudflare attack of last week it was announced that several IXs were going to stop advertising the address space of their peering lan, which properly does not need to be advertised anyway. Yes, that will cause some minor problems for those who work for and with the companies that peer there, but they are *clients*, and should be able to have other similar arrangements made for them. Cheers, -- jra ----- Original Message -----
From: "Yang Yu" <yang.yu.list@gmail.com> To: kemp@network-services.uoregon.edu Cc: "NANOG list" <nanog@nanog.org> Sent: Wednesday, April 3, 2013 7:20:44 PM Subject: Re: route for linx.net in Level3? I noticed it too this morning from a AS3549 customer. Level 3 LG shows no route for 195.66.232.0/22 on North American sites.
On Wed, Apr 3, 2013 at 6:52 PM, John Kemp <kemp@network-services.uoregon.edu> wrote:
Having trouble reaching route-views.linx.routeviews.org from AS3582.
I'm assuming that some folks stopped carrying this particular linx.net address prefix as of this morning. ?!?
$ whois -h whois.cymru.com " -v 195.66.241.146" AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 5459 | 195.66.241.146 | 195.66.240.0/22 | GB | ripencc | 1997-12-01 | LINX-AS London Internet Exchange Ltd.
$ dig +short 146.241.66.195.peer.asn.cymru.com TXT "1299 2914 3257 10310 | 195.66.240.0/22 | GB | ripencc | 1997-12-01"
-- John Kemp (kemp@routeviews.org) RouteViews Engineer NOC: noc@routeviews.org MAIL: help@routeviews.org WWW: http://www.routeviews.org
-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
In a message written on Thu, Apr 04, 2013 at 02:57:11PM -0400, Jay Ashworth wrote:
Yes. In the fallout from the Cloudflare attack of last week it was announced that several IXs were going to stop advertising the address space of their peering lan, which properly does not need to be advertised anyway.
Well, now that's a big maybe. I was a big advocate for the peering exchanges each having their own ASN and announcing the peering block back in the day, and it seems people may have forgotten some of the issues with unadvertised peering exchange blocks. It breaks traceroute for many people: The ICMP TTL Unreachable will come from a non-routed network (the exchange LAN). If it crosses another network boundary doing uRPF, even in loose mode, those unreachables will be dropped. It also reduces the utility of a tool like MTR. Without the ICMP responese it won't know where to ping, and even if it receives the ICMP it's likely packets towards the LAN IP's will be dropped with no route to host. It has the potential to break PMTU discovery for many people: If a router is connected to the exchange and a lower MTU link a packet coming in with DF set will get an ICMP would-fragment reply. Most vendors source from the input interface, e.g. the exchange IP. Like the traceorute case, if crosses another network boundary doing uRPF, even in loose mode, those ICMP messages will be lost, resulting in a PMTU black hole. Some vendors have knobs to force the ICMP to be emitted from a loopback, but not all. People would have to turn it on. But hey, this is a good thing because a DDOS caused issues, right? Well, not so much. Even if the exchange does not advertise the exchange LAN, it's probably the case that it is in the IGP (or at least IBGP) of everyone connected to it, and by extension all of their customers with a default route pointed at them. For the most popular exchanges (AMS-IX, for instance) I suspect the percentage of end users who can reach the exchange LAN without it being explicitly routed to be well over 80%, perhaps into the upper 90% range. So when those boxes DDOS, they are going to all DDOS the LAN anyway. Security through obscurity does not work. This is going to annoy some people just trying to do their day job, and not make a statistical difference to the attackers trying to take out infrastructure. How about we all properly implement BCP 38 instead? -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Thu, Apr 4, 2013 at 12:29 PM, Leo Bicknell <bicknell@ufp.org> wrote:
But hey, this is a good thing because a DDOS caused issues, right? Well, not so much. Even if the exchange does not advertise the exchange LAN, it's probably the case that it is in the IGP (or at least IBGP) of everyone connected to it, and by extension all of their customers with a default route pointed at them. For the most popular exchanges (AMS-IX, for instance) I suspect the percentage of end users who can reach the exchange LAN without it being explicitly routed to be well over 80%, perhaps into the upper 90% range. So when those boxes DDOS, they are going to all DDOS the LAN anyway.
Yes, thats why everyone needs to set up some sanity in their networks. This was presented at an APNIC conference a little while back: http://conference.apnic.net/__data/assets/pdf_file/0018/50706/apnic34-mike-j... hundreds of networks are improperly set up and are being abused (and abusing) to the IXP LANs.
Security through obscurity does not work. This is going to annoy some people just trying to do their day job, and not make a statistical difference to the attackers trying to take out infrastructure.
This isn't security through obscurity. This is saving the IXP from getting 100's of G's over transit, which should just be for their corporate network.
How about we all properly implement BCP 38 instead?
Agree.
Even if the exchange does not advertise the exchange LAN, it's probably
First of all I agree with Leo that not advertising IX prefixes permanently causes more problems than it solves. the case that it is in the IGP (or at least IBGP) of everyone connected to it Well if I would peer with such an ISP at London and Frankfurt I could create a GRE tunnel from London to Frankfurt via the other ISP and use it to transport packets that would otherwise have to traverse my backbone. Or if my peer has a router at IX that happens to have full routing view I can just point a static default toward it and have a free transit. Check out: http://www.bcp38.info adam -----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Thursday, April 04, 2013 9:29 PM To: NANOG Subject: Re: route for linx.net in Level3? In a message written on Thu, Apr 04, 2013 at 02:57:11PM -0400, Jay Ashworth wrote:
Yes. In the fallout from the Cloudflare attack of last week it was announced that several IXs were going to stop advertising the address space of their peering lan, which properly does not need to be advertised anyway.
Well, now that's a big maybe. I was a big advocate for the peering exchanges each having their own ASN and announcing the peering block back in the day, and it seems people may have forgotten some of the issues with unadvertised peering exchange blocks. It breaks traceroute for many people: The ICMP TTL Unreachable will come from a non-routed network (the exchange LAN). If it crosses another network boundary doing uRPF, even in loose mode, those unreachables will be dropped. It also reduces the utility of a tool like MTR. Without the ICMP responese it won't know where to ping, and even if it receives the ICMP it's likely packets towards the LAN IP's will be dropped with no route to host. It has the potential to break PMTU discovery for many people: If a router is connected to the exchange and a lower MTU link a packet coming in with DF set will get an ICMP would-fragment reply. Most vendors source from the input interface, e.g. the exchange IP. Like the traceorute case, if crosses another network boundary doing uRPF, even in loose mode, those ICMP messages will be lost, resulting in a PMTU black hole. Some vendors have knobs to force the ICMP to be emitted from a loopback, but not all. People would have to turn it on. But hey, this is a good thing because a DDOS caused issues, right? Well, not so much. Even if the exchange does not advertise the exchange LAN, it's probably the case that it is in the IGP (or at least IBGP) of everyone connected to it, and by extension all of their customers with a default route pointed at them. For the most popular exchanges (AMS-IX, for instance) I suspect the percentage of end users who can reach the exchange LAN without it being explicitly routed to be well over 80%, perhaps into the upper 90% range. So when those boxes DDOS, they are going to all DDOS the LAN anyway. Security through obscurity does not work. This is going to annoy some people just trying to do their day job, and not make a statistical difference to the attackers trying to take out infrastructure. How about we all properly implement BCP 38 instead? -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Thu, Apr 4, 2013 at 1:26 PM, Adam Vitkovsky <adam.vitkovsky@swan.sk> wrote:
Check out: http://www.bcp38.info
Right on. :-) - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
Yeah, you wouldn't think that one should fall out. It is possible that my 195.66.241.146 really should be something sitting within: 195.66.232.0/22. I'll have to talk with some of the LINX folks to understand whether they are intending that 195.66.240.0/22 and 195.66.232.0/22 are treated differently. If that's the case, I may need to move off of 195.66.240.0/22. Thanks, John Kemp (kemp@routeviews.org) On 4/3/13 4:20 PM, Yang Yu wrote:
I noticed it too this morning from a AS3549 customer. Level 3 LG shows no route for 195.66.232.0/22 on North American sites.
On Wed, Apr 3, 2013 at 6:52 PM, John Kemp <kemp@network-services.uoregon.edu> wrote:
Having trouble reaching route-views.linx.routeviews.org from AS3582.
I'm assuming that some folks stopped carrying this particular linx.net address prefix as of this morning. ?!?
$ whois -h whois.cymru.com " -v 195.66.241.146" AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 5459 | 195.66.241.146 | 195.66.240.0/22 | GB | ripencc | 1997-12-01 | LINX-AS London Internet Exchange Ltd.
$ dig +short 146.241.66.195.peer.asn.cymru.com TXT "1299 2914 3257 10310 | 195.66.240.0/22 | GB | ripencc | 1997-12-01"
-- John Kemp (kemp@routeviews.org) RouteViews Engineer NOC: noc@routeviews.org MAIL: help@routeviews.org WWW: http://www.routeviews.org
participants (9)
-
Adam Vitkovsky
-
Jay Ashworth
-
Job Snijders
-
John Kemp
-
Leo Bicknell
-
Paul Ferguson
-
Randy Bush
-
Tom Paseka
-
Yang Yu