FYI, Level 3 issues in Dallas
We have some customers unable to access their websites, seeing this on the way to them: 4 ae-0-11.bar2.Tampa1.Level3.net (4.69.137.110) 0.343 ms 0.423 ms 0.406 ms 5 ae-12-12.ebr1.Dallas1.Level3.net (4.69.137.118) 23.940 ms 23.470 ms 23.426 ms 6 ae-71-71.csw2.Dallas1.Level3.net (4.69.151.137) 24.026 ms ae-81-81.csw3.Dallas1.Level3.net (4.69.151.149) 24.007 ms ae-61-61.csw1.Dallas1.Level3.net (4.69.151.125) 23.855 ms 7 ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 23.361 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 23.329 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 23.936 ms 8 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.378 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.387 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.963 ms 9 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 23.357 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 22.779 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 62.640 ms 10 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 24.179 ms 23.297 ms 23.403 ms 11 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 65.617 ms ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 23.286 ms ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 23.553 ms 12 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.303 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 24.027 ms 24.028 ms 13 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 24.018 ms ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 23.374 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 23.342 ms 14 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 24.068 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.361 ms 23.348 ms 15 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 24.023 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 22.740 ms ae-4-90.edge10.Dallas1.Level3.net (4.69.145.210) 23.963 ms 16 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.420 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.400 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 25.317 ms 17 ae-2-70.edge10.Dallas1.Level3.net (4.69.145.82) 23.985 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 23.476 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 51.762 ms 18 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 23.416 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 24.062 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 24.051 ms 19 ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 44.798 ms ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 22.856 ms ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 22.891 ms 20 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.433 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 25.333 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.367 ms 21 ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 23.475 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 23.476 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 64.753 ms 22 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 24.008 ms 24.043 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.508 ms 23 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 23.505 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 23.958 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 24.058 ms 24 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.429 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.623 ms 25.547 ms 25 ae-2-70.edge10.Dallas1.Level3.net (4.69.145.82) 23.491 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 23.551 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 24.078 ms 26 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 24.472 ms 24.144 ms 24.080 ms 27 ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 28.121 ms ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 22.848 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 24.090 ms 28 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 23.509 ms 24.056 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.522 ms 29 ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 24.161 ms 24.153 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 24.130 ms 30 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.606 ms 23.482 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.580 ms
Re: FYI, Level 3 issues in Dallas
On 2014-11-19 16:13, David Hubbard wrote: We have some customers unable to access their websites, seeing this on the way to them: What would be the source and destination? You got a nice routing loop there. Greets, Jeroen
Re: FYI, Level 3 issues in Dallas
Also peering problems in Chicago, had to drop BGP to them until they figure it out. Reported it 4 hours ago, no good response yet. Gary We have some customers unable to access their websites, seeing this on the way to them: 4 ae-0-11.bar2.Tampa1.Level3.net (4.69.137.110) 0.343 ms 0.423 ms 0.406 ms 5 ae-12-12.ebr1.Dallas1.Level3.net (4.69.137.118) 23.940 ms 23.470 ms 23.426 ms 6 ae-71-71.csw2.Dallas1.Level3.net (4.69.151.137) 24.026 ms ae-81-81.csw3.Dallas1.Level3.net (4.69.151.149) 24.007 ms ae-61-61.csw1.Dallas1.Level3.net (4.69.151.125) 23.855 ms 7 ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 23.361 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 23.329 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 23.936 ms 8 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.378 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.387 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.963 ms 9 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 23.357 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 22.779 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 62.640 ms 10 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 24.179 ms 23.297 ms 23.403 ms 11 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 65.617 ms ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 23.286 ms ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 23.553 ms 12 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.303 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 24.027 ms 24.028 ms 13 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 24.018 ms ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 23.374 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 23.342 ms 14 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 24.068 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.361 ms 23.348 ms 15 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 24.023 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 22.740 ms ae-4-90.edge10.Dallas1.Level3.net (4.69.145.210) 23.963 ms 16 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.420 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.400 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 25.317 ms 17 ae-2-70.edge10.Dallas1.Level3.net (4.69.145.82) 23.985 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 23.476 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 51.762 ms 18 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 23.416 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 24.062 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 24.051 ms 19 ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 44.798 ms ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 22.856 ms ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 22.891 ms 20 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.433 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 25.333 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.367 ms 21 ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 23.475 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 23.476 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 64.753 ms 22 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 24.008 ms 24.043 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.508 ms 23 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 23.505 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 23.958 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 24.058 ms 24 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.429 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.623 ms 25.547 ms 25 ae-2-70.edge10.Dallas1.Level3.net (4.69.145.82) 23.491 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 23.551 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 24.078 ms 26 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 24.472 ms 24.144 ms 24.080 ms 27 ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 28.121 ms ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 22.848 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 24.090 ms 28 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 23.509 ms 24.056 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.522 ms 29 ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 24.161 ms 24.153 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 24.130 ms 30 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.606 ms 23.482 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.580 ms
RE: Overlay as a link
There are certain protocols and mechanisms tied to a physical medium or MAC layer. If you are doing L3 tunneling you lose those options, if you are doing L2 tunneling you may lose less of them depending how transparent the tunnel is. Things like Ethernet pause frames or 802.3ah instead of BFD. So from a certain layer like L3+ it looks and behaves like a physical link but there are differences. Phil -Original Message- From: Glen Kent glen.k...@gmail.com Sent: 11/19/2014 2:04 AM To: nanog@nanog.org nanog@nanog.org Subject: Overlay as a link Hi, When youre doing overlay networking, i.e., you have tunnels from one virtual machine in a DC to another in another DC, then can i consider a tunnel between the two virtual machines as a physical link that exists in a regular network? I am wondering on what possibly can be the difference between a tunnel being considered as a link and a true physical link. I could run routing algorithms on both. The tunnel would only be considered as an interface. Or i could run BFD on both. Once difference that i can think of is that while you can send multiple frames together on a tunnel (for example if there are ECMP paths within the tunnel), you may not be able to send multiple frames at the same time on a physical link. Anything else? Glen
Re: abuse reporting tools
On Tue, 18 Nov 2014 16:58:24 -0800 Mike mike-na...@tiedyenetworks.com wrote: I provide broadband connectivity to mostly residential users. Over the past few years, instances of DDoS against the network - specfically targeting end users - has been on the rise, and today I can qualify many of these as simple acts of revenge where someone will engage a dos (possibly, services like 'booters' or similar) because they lost an online game or had some interactive in a forum they didn't like. Hi Mike, I certainly sympathize with you about dealing with this sort of activity. Since you seem to be willing to invest some effort into mitigating it, what would also be interesting is to compile a summary of this activity that you're seeing. Answering questions such as how often does it happen, the duration when it does, what games are most commonly associated with the attacks you're seeing, what are the attack characteristics and so on. Having good insight into these attacks in formulating responses or going off and performing their own research to get closer to the who, why and how so they can be mitigated in other ways too. If you ever attend a NANOG, a presentation about your experiences might be welcome, it would very likely be in the security track, which I sometimes help moderate if you want to consider it. I have good 'consumer broadband' filtering rules in place which make sense and protect against quite a lot of obviously ddos oriented traffic streams. Do you ever find that the attacks overwhelm your network or are they usually just big enough to disrupt your downstream customer? I am wondering if anyone has a pointer or reference to any tools which might help facillitate this? I can point you to some tools and references I'm aware of, but I can't talk about how effectively they are operationally or whether or not you should abide by or use them. AbuseHelper http://abusehelper.be/ IETF RFC 5965 An Extensible Format for Email Feedback Reports https://tools.ietf.org/html/rfc5965 IETF RFC 6650 Creation and Use of Email Feedback Reports https://tools.ietf.org/html/rfc6650 Network Abuse Reporting 2.0 http://www.x-arf.org/ Net::Abuse::Utils http://search.cpan.org/~mikegrb/Net-Abuse-Utils/ John
Re: abuse reporting tools
On Wed, Nov 19, 2014 at 12:14 PM, John Kristoff j...@cymru.com wrote: On Tue, 18 Nov 2014 16:58:24 -0800 Mike mike-na...@tiedyenetworks.com wrote: I provide broadband connectivity to mostly residential users. I can point you to some tools and references I'm aware of, but I can't talk about how effectively they are operationally or whether or not you should abide by or use them. Don't forget IETF RFC 5970 IODEF format as well. It provides a much more comprehensive and flexible reporting format than either X-ARF or RFC 5965 (both of which are really geared primarily towards single badguy / single incident). With that power comes greater complexity, though. I'll have to look at Net::Abuse::Utils since that's the first I've ever heard of it and I don't know what it can do. If it can't make IODEF, I'm a capable Perl programmer, so I can take a look, but no promises. -- Paul W Bennett
Re: abuse reporting tools
Don't forget IETF RFC 5970 IODEF Sorry, that's 5070, not 5970. Slip of the finger. -- Paul W Bennett
Re: abuse reporting tools
On Nov 19, 2014, at 9:14 AM, John Kristoff j...@cymru.com wrote: On Tue, 18 Nov 2014 16:58:24 -0800 Mike mike-na...@tiedyenetworks.com wrote: I am wondering if anyone has a pointer or reference to any tools which might help facillitate this? I can point you to some tools and references I'm aware of, but I can't talk about how effectively they are operationally or whether or not you should abide by or use them. AbuseHelper http://abusehelper.be/ IETF RFC 5965 An Extensible Format for Email Feedback Reports https://tools.ietf.org/html/rfc5965 IETF RFC 6650 Creation and Use of Email Feedback Reports https://tools.ietf.org/html/rfc6650 Network Abuse Reporting 2.0 http://www.x-arf.org/ Net::Abuse::Utils http://search.cpan.org/~mikegrb/Net-Abuse-Utils/ You can also use this facility to find the abuse email address of an IP https://abusix.com/contactdb.html And I wrote this tool, tailored for DMARC failure reports, but it has some code to report any email. Yo could hack the code easily for your own purposes: https://github.com/linkedin/lafayette/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: level3 issue in chicago (was: FYI, Level 3 issues in Dallas)
like david below, we've been getting reports this morning from customers unable to reach various web sites. investigating a number of these reports, the one commonality is level3 in chicago. sites are reachable from level3/cincinnati but not level3/chicago. traceroutes make it one hop past our bgp peer and seem to die there. for one particular remote web server (node1104.follett.com, and possibly others) traceroutes and pings from level3's looking glass (using chicago as the site) complete successfully, while neither does when ran from my gear through the same site. On 11/19/2014 10:46 AM, ga...@completeweb.net wrote: Also peering problems in Chicago, had to drop BGP to them until they figure it out. Reported it 4 hours ago, no good response yet. Gary We have some customers unable to access their websites, seeing this on the way to them: 4 ae-0-11.bar2.Tampa1.Level3.net (4.69.137.110) 0.343 ms 0.423 ms 0.406 ms 5 ae-12-12.ebr1.Dallas1.Level3.net (4.69.137.118) 23.940 ms 23.470 ms 23.426 ms 6 ae-71-71.csw2.Dallas1.Level3.net (4.69.151.137) 24.026 ms ae-81-81.csw3.Dallas1.Level3.net (4.69.151.149) 24.007 ms ae-61-61.csw1.Dallas1.Level3.net (4.69.151.125) 23.855 ms 7 ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 23.361 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 23.329 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 23.936 ms 8 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.378 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.387 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.963 ms 9 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 23.357 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 22.779 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 62.640 ms 10 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 24.179 ms 23.297 ms 23.403 ms 11 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 65.617 ms ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 23.286 ms ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 23.553 ms 12 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.303 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 24.027 ms 24.028 ms 13 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 24.018 ms ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 23.374 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 23.342 ms 14 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 24.068 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.361 ms 23.348 ms 15 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 24.023 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 22.740 ms ae-4-90.edge10.Dallas1.Level3.net (4.69.145.210) 23.963 ms 16 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.420 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.400 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 25.317 ms 17 ae-2-70.edge10.Dallas1.Level3.net (4.69.145.82) 23.985 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 23.476 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 51.762 ms 18 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 23.416 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 24.062 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 24.051 ms 19 ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 44.798 ms ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 22.856 ms ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 22.891 ms 20 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.433 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 25.333 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.367 ms 21 ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 23.475 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 23.476 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 64.753 ms 22 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 24.008 ms 24.043 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.508 ms 23 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 23.505 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 23.958 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 24.058 ms 24 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.429 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.623 ms 25.547 ms 25 ae-2-70.edge10.Dallas1.Level3.net (4.69.145.82) 23.491 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 23.551 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 24.078 ms 26 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 24.472 ms 24.144 ms 24.080 ms 27 ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 28.121 ms ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 22.848 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 24.090 ms 28 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 23.509 ms 24.056 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.522 ms 29 ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 24.161 ms 24.153 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 24.130 ms 30 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.606 ms 23.482 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.580 ms
Outbound traffic on a circuit?
I am looking at an order for a well known upstream provider. They are handing me a circuit at a data center. The contract reads if we use more than 50% of the outbound the price gets re-priced and almost doubles. How many folks have ran into this? Justin -- Justin Wilson j...@mtin.net http://www.mtin.net http://www.mtin.net/blog Managed Services xISP Solutions Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering Transit Internet Exchange
Re: Outbound traffic on a circuit?
It is un-usual but not un-believable or ridiculous. There are some context questions you will have to ask / answer ... 1) Are you getting 'A Deal' (or a 'steal of a deal' ?) 2) Looks like your upstream has some constraints that they are protecting themselves from. It will help in understanding what that constraint is. 3) What kind of circuit is this ? IP Transit ? or some other flavor of connectivity. 4) Is this condition real or left over some other template contract they copied from ? :) Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Justin Wilson li...@mtin.net To: nanog@nanog.org Sent: Wednesday, November 19, 2014 3:40:56 PM Subject: Outbound traffic on a circuit? I am looking at an order for a well known upstream provider. They are handing me a circuit at a data center. The contract reads if we use more than 50% of the outbound the price gets re-priced and almost doubles. How many folks have ran into this? Justin -- Justin Wilson j...@mtin.net http://www.mtin.net http://www.mtin.net/blog Managed Services xISP Solutions Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering Transit Internet Exchange
RE: Outbound traffic on a circuit?
The times I have seen this type of language they are usually aimed at residential type service where they are trying to prevent you from hosting content. This is not necessarily unfair depending on the pricing because most residential cost models include a lot of assumptions that the circuit will be idle most of the time. A business class model that punishes you over 50% is pretty aggregious if they are charging business class prices. The key language is 50% OUTBOUND. That implies that they don’t care how much you have inbound. That model allows a web surfer download all he wants up to circuit capacity but makes it painful for you to host Content that you are serving. Are you sure this circuit is correct for server hosting (I'm assuming that’s what you would be doing in a datacenter)? This contract sounds more residential user to me. If this unnamed provider is a cable provider, you need to make sure you are looking at business class service if you are hosting anything significant. Steven Naslund Chicago IL - Original Message - From: Justin Wilson li...@mtin.net To: nanog@nanog.org Sent: Wednesday, November 19, 2014 3:40:56 PM Subject: Outbound traffic on a circuit? I am looking at an order for a well known upstream provider. They are handing me a circuit at a data center. The contract reads if we use more than 50% of the outbound the price gets re-priced and almost doubles. How many folks have ran into this? Justin -- Justin Wilson j...@mtin.net http://www.mtin.net http://www.mtin.net/blog Managed Services xISP Solutions Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering Transit Internet Exchange
Re: Outbound traffic on a circuit?
On 11/19/2014 04:23 PM, Naslund, Steve wrote: I am looking at an order for a well known upstream provider. They are handing me a circuit at a data center. The contract reads if we use more than 50% of the outbound the price gets re-priced and almost doubles. How many folks have ran into this? We have contracts with two different well known Tier 1/2 providers that state that the the ratio of inbound to outbound traffic must stay above 2:1 or a price increase will be triggered. In one case that price increase is about 40%. In our case the ratio is closer to 20:1 so it isn't an issue. Steve -- -- Steven Saner ssa...@hubris.net Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communicationshttp://www.hubris.net
Re: Brian Krebs' new book is out.
- Original Message - From: Roland Dobbins rdobb...@arbor.net This is an important book - well worth your time, and, more importantly, accessible to non-specialists (such as BDMs): http://www.amazon.com/Spam-Nation-Organized-Cybercrime--Epidemic-ebook/dp/B00L5QGBL0/ http://www.amazon.com/Spam-Nation-Organized-Cybercrime--Epidemic/dp/1402295618/ It's not about spam, per se. It's about the global underground economy, and includes a lot of insight into internecine warfare amongst online criminals, including DDoS attacks with huge collateral damage footprints; and also talks about the origins of the Blue Security fiasco and subsequent DDoS, DDoS attacks against Spamhaus, etc. Krebs is pressing the book, of course; here's a link to Terry Gross' Fresh Air interview with him from earlier this week. http://www.npr.org/blogs/alltechconsidered/2014/11/18/364730954/how-a-feud-between-two-russian-companies-fueled-a-spam-nation Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
RE: level3 issue in chicago (was: FYI, Level 3 issues in Dallas)
Appears to have been resolved after seven hours. My ticket just says: We isolated the routing issue and resolved it. The issue was due to a misconfiguration on one our core routers. Now that the issue is corrected, interestingly enough, my trace goes from Tampa to Chicago instead of Dallas. David -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Cool Hand Luke Sent: Wednesday, November 19, 2014 11:23 AM To: nanog@nanog.org Subject: Re: level3 issue in chicago (was: FYI, Level 3 issues in Dallas) like david below, we've been getting reports this morning from customers unable to reach various web sites. investigating a number of these reports, the one commonality is level3 in chicago. sites are reachable from level3/cincinnati but not level3/chicago. traceroutes make it one hop past our bgp peer and seem to die there. for one particular remote web server (node1104.follett.com, and possibly others) traceroutes and pings from level3's looking glass (using chicago as the site) complete successfully, while neither does when ran from my gear through the same site. On 11/19/2014 10:46 AM, ga...@completeweb.net wrote: Also peering problems in Chicago, had to drop BGP to them until they figure it out. Reported it 4 hours ago, no good response yet. Gary We have some customers unable to access their websites, seeing this on the way to them: 4 ae-0-11.bar2.Tampa1.Level3.net (4.69.137.110) 0.343 ms 0.423 ms 0.406 ms 5 ae-12-12.ebr1.Dallas1.Level3.net (4.69.137.118) 23.940 ms 23.470 ms 23.426 ms 6 ae-71-71.csw2.Dallas1.Level3.net (4.69.151.137) 24.026 ms ae-81-81.csw3.Dallas1.Level3.net (4.69.151.149) 24.007 ms ae-61-61.csw1.Dallas1.Level3.net (4.69.151.125) 23.855 ms 7 ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 23.361 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 23.329 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 23.936 ms 8 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.378 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.387 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.963 ms 9 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 23.357 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 22.779 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 62.640 ms 10 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 24.179 ms 23.297 ms 23.403 ms 11 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 65.617 ms ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 23.286 ms ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 23.553 ms 12 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.303 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 24.027 ms 24.028 ms 13 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 24.018 ms ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 23.374 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 23.342 ms 14 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 24.068 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.361 ms 23.348 ms 15 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 24.023 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 22.740 ms ae-4-90.edge10.Dallas1.Level3.net (4.69.145.210) 23.963 ms 16 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.420 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.400 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 25.317 ms 17 ae-2-70.edge10.Dallas1.Level3.net (4.69.145.82) 23.985 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 23.476 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 51.762 ms 18 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 23.416 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 24.062 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 24.051 ms 19 ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 44.798 ms ae-3-80.edge10.Dallas1.Level3.net (4.69.145.146) 22.856 ms ae-1-60.edge10.Dallas1.Level3.net (4.69.145.18) 22.891 ms 20 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 23.433 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 25.333 ms vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.367 ms 21 ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 23.475 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 23.476 ms ae-1-60.edge9.Dallas1.Level3.net (4.69.145.16) 64.753 ms 22 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 24.008 ms 24.043 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.508 ms 23 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 23.505 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 23.958 ms ae-4-90.edge9.Dallas1.Level3.net (4.69.145.208) 24.058 ms 24 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 23.429 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 23.623 ms 25.547 ms 25 ae-2-70.edge10.Dallas1.Level3.net (4.69.145.82) 23.491 ms ae-3-80.edge9.Dallas1.Level3.net (4.69.145.144) 23.551 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 24.078 ms 26 vlan60.csw1.Dallas1.Level3.net
Re: Outbound traffic on a circuit?
On 11/19/14 12:40 PM, Justin Wilson wrote: I am looking at an order for a well known upstream provider. They are handing me a circuit at a data center. The contract reads if we use more than 50% of the outbound the price gets re-priced and almost doubles. How many folks have ran into this? if you're buying 500Mb/s commit 95th percentile on a 1Gb/s circuit or 5Gb/s on 10 then you can expect a contract to specify an upcharge accordingly if you bust your commit. I generally look for terms that provide a relavitily short notification window for uping my commit. e.g. 6 weeks or less. Justin -- Justin Wilson j...@mtin.net http://www.mtin.net http://www.mtin.net/blog Managed Services xISP Solutions Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering Transit Internet Exchange signature.asc Description: OpenPGP digital signature
Re: level3 issue in chicago
On 11/19/2014 07:29 PM, David Hubbard wrote: Appears to have been resolved after seven hours. My ticket just says: We isolated the routing issue and resolved it. The issue was due to a misconfiguration on one our core routers. Now that the issue is corrected, interestingly enough, my trace goes from Tampa to Chicago instead of Dallas. our issue was resolved around the same time but is apparently now occurring again, since 0638 utc -- routing issue affecting (for us) traffic on level3 between chicago, illinois, and cincinnati, ohio. i imagine it's affecting other locations as well. /chl
