Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.) -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 Well done is better than well said. - Benjamin Franklin
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Thu, Nov 09, 2006, Robert Boyle wrote: You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.) Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days? Adrian
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
At 09:23 AM 11/9/2006, you wrote: On Thu, Nov 09, 2006, Robert Boyle wrote: You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.) Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days? We just maintain our own. I remember hearing about one a while ago, but we don't use it so I don't know any details. -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 Well done is better than well said. - Benjamin Franklin
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Thu, 9 Nov 2006, Adrian Chadd wrote: On Thu, Nov 09, 2006, Robert Boyle wrote: You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.) Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days? You probably want to have a look at http://www.cymru.com/BGP/bogon-rs.html jms
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Thursday 09 November 2006 08:26, Robert Boyle wrote: At 09:23 AM 11/9/2006, you wrote: On Thu, Nov 09, 2006, Robert Boyle wrote: You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.) Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days? We just maintain our own. I remember hearing about one a while ago, but we don't use it so I don't know any details. -Robert Believe you are thinking of Team Cmyru at http://www.cymru.com/Bogons/ They support BGP peering I believe. -- Larry Smith SysAd ECSIS.NET [EMAIL PROTECTED]
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Thu, Nov 09, 2006 at 09:26:13AM -0500, Robert Boyle wrote: At 09:23 AM 11/9/2006, you wrote: On Thu, Nov 09, 2006, Robert Boyle wrote: You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.) Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days? We just maintain our own. I remember hearing about one a while ago, but we don't use it so I don't know any details. I'd strongly advise against folks doing it statically.. there seems to be ongoing issues with stale filters each time new address space is released. Even with the best of intentions folks change role or employer and things can get left unmanaged. The craziest stuff that gets announced isnt in the reserved/unallocated realm anyway so the effort seems to be disproportional to the benefits... and most issues I read about with reserved space is packets coming FROM them not TO them Steve
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
[EMAIL PROTECTED] writes: On Thu, Nov 09, 2006 at 09:26:13AM -0500, Robert Boyle wrote: At 09:23 AM 11/9/2006, you wrote: On Thu, Nov 09, 2006, Robert Boyle wrote: You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.) Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days? We just maintain our own. I remember hearing about one a while ago, but we don't use it so I don't know any details. I'd strongly advise against folks doing it statically.. there seems to be ongoing issues with stale filters each time new address space is released. Even with the best of intentions folks change role or employer and things can get left unmanaged. The craziest stuff that gets announced isnt in the reserved/unallocated realm anyway so the effort seems to be disproportional to the benefits... and most issues I read about with reserved space is packets coming FROM them not TO them Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed. ---rob
RE: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
Robert E. Seastrom wrote: [EMAIL PROTECTED] writes: On Thu, Nov 09, 2006 at 09:26:13AM -0500, Robert Boyle wrote: At 09:23 AM 11/9/2006, you wrote: On Thu, Nov 09, 2006, Robert Boyle wrote: You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.) Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days? We just maintain our own. I remember hearing about one a while ago, but we don't use it so I don't know any details. I'd strongly advise against folks doing it statically.. there seems to be ongoing issues with stale filters each time new address space is released. Even with the best of intentions folks change role or employer and things can get left unmanaged. The craziest stuff that gets announced isnt in the reserved/unallocated realm anyway so the effort seems to be disproportional to the benefits... and most issues I read about with reserved space is packets coming FROM them not TO them Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed. Some people don't use condoms with hookers either. Just because they haven't caught anything yet doesn't make it a smart practice. Andrew
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
* [EMAIL PROTECTED] (Robert E. Seastrom) [Thu 09 Nov 2006, 16:02 CET]: [..] Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed. Yeah! This Principle of minimal privilege is totally not applicable to real, live networks... -- Niels.
RE: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed. Some people don't use condoms with hookers either. Just because they haven't caught anything yet doesn't make it a smart practice. Sorry I have to agree with Steve as well. I know I've left networks with Bogon lists in place and then gotten calls a year or more later asking why traffic can't isn't coming in from XYZ new client. Turns out the new admin never updated the bogon list. If this was done through a central repository and updated daily, or required the list to be refreshed periodically otherwise it timed out- fine. The problem is people leave these lists in and forget about them. If you are going to keep on top of them, and make sure to remove them when you leave- then that's great. But if you are going to do it half way- please don't bother. -Don
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point etherne t link]
Take a look at: http://www.cymru.com/Bogons/index.html - ferg -- Adrian Chadd [EMAIL PROTECTED] wrote: On Thu, Nov 09, 2006, Robert Boyle wrote: You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.) Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days? Adrian -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Thu, Nov 09, 2006 at 10:01:12AM -0500, [EMAIL PROTECTED] wrote: On Thu, 09 Nov 2006 14:47:12 GMT, [EMAIL PROTECTED] said: The craziest stuff that gets announced isnt in the reserved/unallocated realm OK, I'll bite - what's the craziest thing you've noticed go by in the recent past? To answer a slightly different question, I was actually thinking about the issues of address space hijacking. So this is where address space that has been legitimately allocated and is properly maintained in routing registries is announced unauthorized by a third party. Theres nothing weird about the BGP announcement or the address space, except your Yahoo traffic seems to traceroute to North Korea rather than California. Less nasty things would be caused by fat fingers, typos in prefixes, accidental announcment of supernets or subnets What I'm getting at here is that if someone announces 1.0.0.0/16 then when I spot it I'll raise an issue and alert whoever screwed up but does it break anything? Not normally. But if I accidentally redistribute my static routes to google.com into BGP my phone's going to get busy PDQ! Steve
RE: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Thu, 9 Nov 2006, Donald Stahl wrote: Sorry I have to agree with Steve as well. I know I've left networks with Bogon lists in place and then gotten calls a year or more later asking why traffic can't isn't coming in from XYZ new client. Turns out the new admin never updated the bogon list. This process can be automated. See my previous post. jms
RE: Verizon PSTN continued
On Tue, 7 Nov 2006, Chris L. Morrow wrote: Working with 2 other carriers on a similar issue, response I rec'd was congestion due to automated political dialers. Not sure if I believe that or not... you'd think they'd have systems monitoring that and trimming down the 'fat'? or can they do that? (legally I mean, sorta like QOS for the phone network I suppose) They can, and do. But SS7 interconnect battles between carriers are about as much fun as peering battles between ISPs, lots of finger pointing and blustering and more lawyers. If you lose SS7 links between carriers, and there is not enough SS7 capacity remaining, the SS7 systems start flapping (the SS7 folks probably use a different term, but it gives the IP folks some idea of what happens). It has happened a few times. I expect the SS7 vendors and protocol wizards are thinking up more clever ways to address it. It has nothing (essentially) to do with the type of calls being made, although high call volumes always make any problem worse. Another time it happened was just before Christmas a few years ago, during peak shopping time and the dialup credit card authorization numbers (and lots of other types of numbers) got jammed up during a SS7 incident as I found out doing my Christmas shopping that afternoon.
SprintLink peering issue in Chicago?
At around 1345 Central it was brought to my attention that we had lost access to a number of websites out on the 'net... Two big-name examples are Oracle, which has our development team screaming for my blood. The other that's come to light as well is, of course, Yahoo... which means the rest of the userbase hates me. Traceroutes like the two below for Oracle generally die after one of Sprint's routers or its peer with Level3. I've already opened a case with SprintLink's broadband group and the tech I've spoken to said that there have been an influx of calls about routing/website availability problems, but nothing had been identified inside Sprint yet. Just curious if anybody else is seeing this sort of action. [EMAIL PROTECTED] [/export/home/jolsen] $ traceroute www.oracle.com traceroute: Warning: Multiple interfaces found; using 10.2.2.230 @ ce0 traceroute to www.oracle.com (141.146.8.66), 30 hops max, 40 byte packets 1 core2-vlan1.obt.devry.edu (10.2.2.1) 0.407 ms 0.278 ms 0.265 ms 2 obtfw-virtual.obt.devry.edu (10.2.1.10) 1.413 ms 2.380 ms 2.400 ms 3 * * 205.240.70.2 (205.240.70.2) 5.209 ms 4 * * sl-gw32-chi-6-0-ts3.sprintlink.net (144.232.205.237) 10.738 ms 5 * sl-bb21-chi-4-2.sprintlink.net (144.232.26.33) 14.616 ms 32.739 ms 6 sl-bb20-chi-14-0.sprintlink.net (144.232.26.1) 16.901 ms 33.400 ms 27.028 ms 7 sl-st20-chi-12-0.sprintlink.net (144.232.8.219) 42.269 ms 6.190 ms 3.835 ms 8 * 209.0.225.21 (209.0.225.21) 9.971 ms 148.152 ms 9 * * * 10 * * * 11 * * * 12 * * * -- and -- [EMAIL PROTECTED] [/usr/local/sbin] # ./tcptraceroute www.oracle.com 80 Selected device ge0, address 10.2.2.4 for outgoing packets Tracing the path to www.oracle.com (141.146.8.66) on TCP port 80 (http), 30 hops max 1 10.2.2.1 (10.2.2.1) 0.289 ms 0.224 ms 0.208 ms 2 10.2.1.10 (10.2.1.10) 1.547 ms 1.502 ms 1.218 ms 3 205.240.70.2 (205.240.70.2) 2.555 ms 5.551 ms 6.408 ms 4 sl-gw32-chi-6-0-ts3.sprintlink.net (144.232.205.237) 4.120 ms 8.185 ms 6.024 ms 5 sl-bb21-chi-4-2.sprintlink.net (144.232.26.33) 5.470 ms 3.884 ms 6.889 ms 6 sl-bb20-chi-14-0.sprintlink.net (144.232.26.1) 8.851 ms 7.624 ms 5.671 ms 7 sl-st20-chi-12-0.sprintlink.net (144.232.8.219) 7.913 ms 7.283 ms 7.427 ms 8 209.0.225.21 (209.0.225.21) 4.730 ms 6.033 ms 7.925 ms 9 * * * 10 * * * 11 * * *
Re: SprintLink peering issue in Chicago?
On 11/9/06, Olsen, Jason [EMAIL PROTECTED] wrote: At around 1345 Central it was brought to my attention that we had lost access to a number of websites out on the 'net... Two big-name examples are Oracle, which has our development team screaming for my blood. The other that's come to light as well is, of course, Yahoo... which means the rest of the userbase hates me. Traceroutes like the two below for Oracle generally die after one of Sprint's routers or its peer with Level3. I've already opened a case with SprintLink's broadband group and the tech I've spoken to said that there have been an influx of calls about routing/website availability problems, but nothing had been identified inside Sprint yet. Just curious if anybody else is seeing this sort of action. Sprint has been made aware of the issue, as has Level3. Matt [EMAIL PROTECTED] [/export/home/jolsen] $ traceroute www.oracle.com traceroute: Warning: Multiple interfaces found; using 10.2.2.230 @ ce0 traceroute to www.oracle.com (141.146.8.66), 30 hops max, 40 byte packets 1 core2-vlan1.obt.devry.edu (10.2.2.1) 0.407 ms 0.278 ms 0.265 ms 2 obtfw-virtual.obt.devry.edu (10.2.1.10) 1.413 ms 2.380 ms 2.400 ms 3 * * 205.240.70.2 (205.240.70.2) 5.209 ms 4 * * sl-gw32-chi-6-0-ts3.sprintlink.net (144.232.205.237) 10.738 ms 5 * sl-bb21-chi-4-2.sprintlink.net (144.232.26.33) 14.616 ms 32.739 ms 6 sl-bb20-chi-14-0.sprintlink.net (144.232.26.1) 16.901 ms 33.400 ms 27.028 ms 7 sl-st20-chi-12-0.sprintlink.net (144.232.8.219) 42.269 ms 6.190 ms 3.835 ms 8 * 209.0.225.21 (209.0.225.21) 9.971 ms 148.152 ms 9 * * * 10 * * * 11 * * * 12 * * * -- and -- [EMAIL PROTECTED] [/usr/local/sbin] # ./tcptraceroute www.oracle.com 80 Selected device ge0, address 10.2.2.4 for outgoing packets Tracing the path to www.oracle.com (141.146.8.66) on TCP port 80 (http), 30 hops max 1 10.2.2.1 (10.2.2.1) 0.289 ms 0.224 ms 0.208 ms 2 10.2.1.10 (10.2.1.10) 1.547 ms 1.502 ms 1.218 ms 3 205.240.70.2 (205.240.70.2) 2.555 ms 5.551 ms 6.408 ms 4 sl-gw32-chi-6-0-ts3.sprintlink.net (144.232.205.237) 4.120 ms 8.185 ms 6.024 ms 5 sl-bb21-chi-4-2.sprintlink.net (144.232.26.33) 5.470 ms 3.884 ms 6.889 ms 6 sl-bb20-chi-14-0.sprintlink.net (144.232.26.1) 8.851 ms 7.624 ms 5.671 ms 7 sl-st20-chi-12-0.sprintlink.net (144.232.8.219) 7.913 ms 7.283 ms 7.427 ms 8 209.0.225.21 (209.0.225.21) 4.730 ms 6.033 ms 7.925 ms 9 * * * 10 * * * 11 * * *
Re: link between Sprint and Level3 Networks is down in Chicago
Does someone know if this is a *single* link down?? It seems bizarre to me that there would only be a single link (geographically) between those two. Whatever happened to redundancy? Deepak Dennis Dayman wrote: We received confirmation from Time Warner. The link between Sprint and Level3 Networks is down in Chicago. This has been an issue since 3:10 PM EST. Time Warner has a ticket open to address the issue. Not sure what it is yet. -Dennis
Re: link between Sprint and Level3 Networks is down in Chicago
On Thu, 9 Nov 2006, Deepak Jain wrote: Does someone know if this is a *single* link down?? It seems bizarre to me that there would only be a single link (geographically) between those two. Whatever happened to redundancy? Accounting. ;) - billn
Re: link between Sprint and Level3 Networks is down in Chicago
Whatever happened to redundancy? lost in the transition from reality to fantasy and conjecture? it's the sharp curves. randy
Re: link between Sprint and Level3 Networks is down in Chicago
On Thu, 9 Nov 2006, Randy Bush wrote: Whatever happened to redundancy? lost in the transition from reality to fantasy and conjecture? it's the sharp curves. also perhaps in other regions of their network they have connectivity, so it was expected to fail out of region properly?
Re: Yahoo! Mail Servers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Chuck! On Thu, 9 Nov 2006, chuck goolsbee wrote: I haven't heard a peep from any human being at Yahoo. +1 RGDS GARY - --- Gary E. Miller Rellim 20340 Empire Ave., Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFU7ET8KZibdeR3qURAjPXAJ0XjQbE1JChmDp5vGHmkHUWmVFm6ACgh7Dg xvQFg+MRXEn8SfO7VeP+WeU= =/luB -END PGP SIGNATURE-
Re: Yahoo! Mail Servers
I've filled it out and have yet to hear back as well. chuck goolsbee wroteth on 11/9/2006 2:46 PM: At 5:49 PM -0800 11/5/06, chuck goolsbee wrote: At 12:29 PM -0800 11/4/06, Dave Mitchell wrote: number of emails and being traffic shaped. To have your legitimate mailservers added to a white list, please refer to the following info. http://help.yahoo.com/help/us/mail/defer/defer-06.html I've filled in the form. And I'm pretty sure this is the second or third time I've done so. -dave p.s. Chuck, must be 'game on' in hell twice since Petach and I both work for Yahoo. :) I have my whistle skates, but won't drop the puck until my yahoo.com message backlogs sink to single digits, and/or a human being from yahoo!mail contacts me directly via the methods I outlined in the above referenced form. Just to follow up, six days has passed and other than one auto-reply promising: At 10:38 PM -0800 11/4/06, Yahoo! Customer Support wrote: Thank you for contacting Yahoo! Customer Care to answer your question. A support representative will get back to you within 48 hours regarding your issue. I haven't heard a peep from any human being at Yahoo. Has anyone else that filled in the placeb^X^X^X^X form heard back from them? Beuller? --chuck
Re: Yahoo! Mail Servers
I'm joining this thread rather late, and this may be somewhat OT, but... I have to ask: is this delay the result of the recent upswing in Spam worldwide? Can anyone at Yahoo or elsewhere comment? http://www.channelregister.co.uk/2006/10/31/botnet_spam_surge/page2.html Thanks, Ken S. Ryan [09/11/06 15:00 -0800]: I've filled it out and have yet to hear back as well. chuck goolsbee wroteth on 11/9/2006 2:46 PM: At 5:49 PM -0800 11/5/06, chuck goolsbee wrote: At 12:29 PM -0800 11/4/06, Dave Mitchell wrote: number of emails and being traffic shaped. To have your legitimate mailservers added to a white list, please refer to the following info. http://help.yahoo.com/help/us/mail/defer/defer-06.html I've filled in the form. And I'm pretty sure this is the second or third time I've done so. -dave p.s. Chuck, must be 'game on' in hell twice since Petach and I both work for Yahoo. :) I have my whistle skates, but won't drop the puck until my yahoo.com message backlogs sink to single digits, and/or a human being from yahoo!mail contacts me directly via the methods I outlined in the above referenced form. Just to follow up, six days has passed and other than one auto-reply promising: At 10:38 PM -0800 11/4/06, Yahoo! Customer Support wrote: Thank you for contacting Yahoo! Customer Care to answer your question. A support representative will get back to you within 48 hours regarding your issue. I haven't heard a peep from any human being at Yahoo. Has anyone else that filled in the placeb^X^X^X^X form heard back from them? Beuller? --chuck -- MailChannels: Reliable Email Delivery (TM) | http://mailchannels.com -- Suite 601, 602 West Hastings St. Vancouver, BC, V6B 1P2, Canada Office: +1-604-677-2978
Re: Yahoo! Mail Servers
chuck goolsbee wrote: I haven't heard a peep from any human being at Yahoo. Has anyone else that filled in the placeb^X^X^X^X form heard back from them? Beuller? I filled it out with the same results. Jeff
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
[EMAIL PROTECTED] writes: Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed. Some people don't use condoms with hookers either. Just because they haven't caught anything yet doesn't make it a smart practice. On the other hand, compulsive hand washing has never been shown to keep disease away, and may actually cause dry skin and other unintended side effects. ---Rob
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
Robert E. Seastrom wrote: [EMAIL PROTECTED] writes: Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed. Some people don't use condoms with hookers either. Just because they haven't caught anything yet doesn't make it a smart practice. On the other hand, compulsive hand washing has never been shown to keep disease away, and may actually cause dry skin and other unintended side effects. Speaking as someone with a degree in Molecular Biology (gasp!) the dry/damaged skin can actually be a way to increase the susceptibility to bacterium/virons. As for bogon filtering...when there is a perfectly good, perfectly responsible bogon source you can BGP peer with that is rigorous in its maintenance of good data... why fight it? Sanity check their feed, call it a day. Maintaining your own bogon list is a nightmare. Someone (years ago) said... why would I want to pay to move bogon traffic across my network when its only going to get dropped by the next hop anyway -- as a justification for filtering bogons. Deepak
Re: link between Sprint and Level3 Networks is down in Chicago
Chris L. Morrow wrote: On Thu, 9 Nov 2006, Randy Bush wrote: Whatever happened to redundancy? lost in the transition from reality to fantasy and conjecture? it's the sharp curves. also perhaps in other regions of their network they have connectivity, so it was expected to fail out of region properly? I think that is what I meant. If there is no other connect anywhere, I understand it being dead (though, except for accounting, I don't understand why there is only one). If its not failing over to use one of the other connects, methinks some clever noc fellows could make that work temporarily whilest the troublesome routers are addressed betwixt them. Everyone has been using such clever figurative speech I decided to get a little flowery too. Deepak
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
Niels Bakker [EMAIL PROTECTED] writes: * [EMAIL PROTECTED] (Robert E. Seastrom) [Thu 09 Nov 2006, 16:02 CET]: [..] Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed. Yeah! This Principle of minimal privilege is totally not applicable to real, live networks... I'm not sure what principle of minimal privilege has to do with filtering addresses that are known unissued. Seems to me that the principle of minimal privilege would allow connections only from addresses from which you are specifically expecting them, not from the internet at large minus a few blocks that aren't issued. Particularly in the case of spam abatement, where the vast majority of spam comes from compromised Windows hosts (which are probably *not* residing on unissued space), I can't see the point. We could get into some kind of meta-discussion about DoS attacks and the like, but at that point you probably want your upstream doing the filtering for you before it clogs your links. Bottom line: my gut feeling is that the threat that unissued bogon space poses pales in comparison to the Bad Neighborhood that is the Internet. I would welcome a pointer to some kind of actual research that shows this to be incorrect. Of course, bogon filtering is a fine security blanket for those whose scope of knowledge is not sufficient to perform a meaningful threat/risk assessment. As for me, I prefer to rivet horseshoes (open end up, to catch the good luck falling from above) to the cable tray above my racks. Oh yeah, religiously adhering to BCP-38 as well, that brings luck too. ---Rob
Re: link between Sprint and Level3 Networks is down in Chicago
On Thu, 9 Nov 2006, Deepak Jain wrote: I think that is what I meant. If there is no other connect anywhere, I understand it being dead (though, except for accounting, I don't understand why there is only one). If its not failing over to use one of the other connects, methinks some clever noc fellows could make that work temporarily whilest the troublesome routers are addressed betwixt them. So, I'm not sure how sprint/l3 are connected, I imagine they have more than one interconnect, in more than one region... It's possible something 'bad' happened and the paths didn't get removed :( It's hard to speculate from 2 as-hops away :) Everyone has been using such clever figurative speech I decided to get a little flowery too. haha :) pleae continue to be verbose and flowery.
Mobile Platform Internetworking
Hello; There has been discussion on the list before about the problems caused by placing IP networks on large mobile platforms (i.e., mobile platform internetworking, or MPI). Terry Davis and Will Ivancic are presenting on this to the NEMO WG at the IETF right now; we have created a mailing list and a web site devoted to this. Mailing list information and presentations and documents can be found at http://www.multicasttech.com/mpi/ If you interested, you are welcome to join and contribute. Regards Marshall Eubanks
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Thu, Nov 09, 2006 at 12:13:57PM -0500, Justin M. Streiner wrote: On Thu, 9 Nov 2006, Donald Stahl wrote: Sorry I have to agree with Steve as well. I know I've left networks with Bogon lists in place and then gotten calls a year or more later asking why traffic can't isn't coming in from XYZ new client. Turns out the new admin never updated the bogon list. This process can be automated. See my previous post. automatic systems are fine if you decide you want to do them, i was specifically responding to the author who suggested he would build the filters himself, my point was that this seemingly good intention is in fact causing real operational problems on The Internet right now as anyone receiving addresses from newly allocated blocks will attest to Steve
Re: link between Sprint and Level3 Networks is down in Chicago
Chris L. Morrow wrote: On Thu, 9 Nov 2006, Randy Bush wrote: Whatever happened to redundancy? lost in the transition from reality to fantasy and conjecture? it's the sharp curves. also perhaps in other regions of their network they have connectivity, so it was expected to fail out of region properly? I don't mind if something breaks occasionally, stuff happens. When something breaks and lies to me via BGP claiming that all is sweetness and light, that can be a very major annoyance. -- Jay Hennigan - CCIE #7880 - Network Administration - [EMAIL PROTECTED] NetLojix Communications, Inc. - http://www.netlojix.com/ WestNet: Connecting you to the planet. 805 884-6323 - WB6RDV
Re: link between Sprint and Level3 Networks is down in Chicago
On Thu, 9 Nov 2006, Dennis Dayman wrote: We received confirmation from Time Warner. The link between Sprint and Level3 Networks is down in Chicago. This has been an issue since 3:10 PM EST. Time Warner has a ticket open to address the issue. Not sure what it is yet. We started seeing problems as early as 2:05 PM EST, but saw substantial improvement at 3:30 PM. I would be interested in comparing notes with anybody else affected by the issue - or if anybody has heard an actual explanation from Sprint/L3. -- Charlie Watts [EMAIL PROTECTED]
Re: link between Sprint and Level3 Networks is down in Chicago
On 11/9/06, Deepak Jain [EMAIL PROTECTED] wrote: Does someone know if this is a *single* link down?? It seems bizarre to me that there would only be a single link (geographically) between those two. Whatever happened to redundancy? Deepak From the outside, this appeared to be more like a CEF consistency sort of thing; routes were still carrying packets to the interconnect, but the packets were not successfully making it across the interconnect. I would hazard a guess that had the link truly gone down in the classic sense, BGP would have done the more proper thing, and found a different path for the routes to propagate along. Again, this is speculation from the outside, based on the path packets were taking before dropping on the floor. Matt Dennis Dayman wrote: We received confirmation from Time Warner. The link between Sprint and Level3 Networks is down in Chicago. This has been an issue since 3:10 PM EST. Time Warner has a ticket open to address the issue. Not sure what it is yet. -Dennis
odd hijack
I recently brought up a prefix hijack that the NANOG community solved, the AS had accidentally started announcing their bogon list. Here is one that is somewhat the opposite, the AS announced a significant portion of IANA allocated space. Note, they are large blocks and as such probably did not cause much damage because most networks announce more specifics. My question to the community is, what kind of misconfiguration could cause this set of prefixes to be announced? I asked the AS responsible, but have not had a response. If you would like more information on the hijack, please see the Internet Alert Registry forums at http://cs.unm.edu/~karlinjf/IAR/ Following are the AS's announced prefixes during the ~10 minute hijack from earlier today: 11.0.0.0/8 12.0.0.0/7 121.0.0.0/8 122.0.0.0/7 124.0.0.0/7 126.0.0.0/8 128.0.0.0/3 15.0.0.0/8 151.99.190.0/24 16.0.0.0/6 160.0.0.0/5 168.0.0.0/6 172.0.0.0/8 188.0.0.0/8 189.0.0.0/8 190.0.0.0/8 191.0.0.0/8 192.0.0.0/8 193.0.0.0/8 194.0.0.0/7 196.0.0.0/8 198.0.0.0/8 199.0.0.0/8 20.0.0.0/7 200.0.0.0/8 201.0.0.0/8 202.0.0.0/7 204.0.0.0/7 206.0.0.0/7 208.0.0.0/8 209.0.0.0/8 210.0.0.0/7 210.170.0.0/18 212.0.0.0/7 214.0.0.0/7 216.0.0.0/8 217.0.0.0/8 218.0.0.0/7 22.0.0.0/8 220.0.0.0/7 222.0.0.0/8 24.0.0.0/8 25.0.0.0/8 26.0.0.0/8 28.0.0.0/7 30.0.0.0/8 32.0.0.0/6 32.1.21.168/32 38.0.0.0/8 40.0.0.0/8 41.0.0.0/8 43.0.0.0/8 44.0.0.0/6 48.0.0.0/6 56.0.0.0/7 58.0.0.0/8 59.0.0.0/8 6.0.0.0/8 60.0.0.0/7 62.0.0.0/8 63.0.0.0/8 64.0.0.0/5 72.0.0.0/7 74.0.0.0/7 76.0.0.0/8 77.0.0.0/8 78.0.0.0/7 8.0.0.0/7 80.0.0.0/7 82.0.0.0/8 82.143.0.0/18 82.143.0.0/20 82.143.0.0/21 82.143.10.0/23 82.143.12.0/24 82.143.16.0/20 82.143.32.0/19 82.143.32.0/24 82.143.33.0/25 82.143.8.0/23 83.0.0.0/8 84.0.0.0/6 88.0.0.0/7 90.0.0.0/8 91.0.0.0/8 96.0.0.0/6 Thanks, Josh
Re: odd hijack
On Thu, 9 Nov 2006, Josh Karlin wrote: Here is one that is somewhat the opposite, the AS announced a significant portion of IANA allocated space. Note, they are large blocks and as such probably did not cause much damage because most networks announce more specifics. My question to the community is, what kind of misconfiguration could cause this set of prefixes to be announced? I asked the AS responsible, but have not had a response. Misconfiguration? :-) That's a nice word for spammer. See Joe's PPT at: http://www.uoregon.edu/~joe/maawg8/maawg8.ppt AS29449 is not the problem. It is the upstreams of AS5602 (KPNQwest Italia) and AS286 (KPN) that let this crap leak. -Hank Nussbacher http://www.interall.co.il
Re: odd hijack
Wouldn't they want to hijack more specifics to spam? I doubt much of that space is going to correctly route for spamming purposes. On 11/9/06, Hank Nussbacher [EMAIL PROTECTED] wrote: On Thu, 9 Nov 2006, Josh Karlin wrote: Here is one that is somewhat the opposite, the AS announced a significant portion of IANA allocated space. Note, they are large blocks and as such probably did not cause much damage because most networks announce more specifics. My question to the community is, what kind of misconfiguration could cause this set of prefixes to be announced? I asked the AS responsible, but have not had a response. Misconfiguration? :-) That's a nice word for spammer. See Joe's PPT at: http://www.uoregon.edu/~joe/maawg8/maawg8.ppt AS29449 is not the problem. It is the upstreams of AS5602 (KPNQwest Italia) and AS286 (KPN) that let this crap leak. -Hank Nussbacher http://www.interall.co.il
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
At 06:58 PM 11/9/2006, you wrote: automatic systems are fine if you decide you want to do them, i was specifically responding to the author who suggested he would build the filters himself, my point was that this seemingly good intention is in fact causing real operational problems on The Internet right now as anyone receiving addresses from newly allocated blocks will attest to Since I am the OP, I never said that filtering bogons was a miracle cure all. If we put static bogon filters on customer routers, I would agree that would be stupid and would cause maintenance and routing problems. As an ISP several assignments from formerly bogon blocks, I agree and understand your point. However, we are religious about updating our bogon filters and we never block legitimate traffic or announcements. Bogon filtering is just one thing among many which I think should be done. Following BCP38 and filtering what comes in from customers and transit/peer connections all help to ensure that you aren't part of the problem to the community or to your own clients. The original poster who I replied to stated that it appeared that some traffic of unknown origin on a private address was being routed across his network between routers and he didn't have any routes for that network in his routing tables. My response was that those announcements and traffic should be filtered at his edge. This turned into a thread about whether filtering was a good thing or not which in my mind is absurd. However, if you run a network and want to accept traffic from bogon and RFC1918 space over your customer, peering, and transit connections then that's your problem. I just choose to not make it mine. -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 Well done is better than well said. - Benjamin Franklin
