From nanog at jima.us Sat Nov 1 01:03:50 2014 From: nanog at jima.us (Jima) Date: Fri, 31 Oct 2014 19:03:50 -0600 Subject: Hijacking machine: ASAS201640 / AS200002 In-Reply-To: <22155.1414797602@server1.tristatelogic.com> References: <22155.1414797602@server1.tristatelogic.com> Message-ID: <54543176.7080203@jima.us> On 2014-10-31 17:20, Ronald F. Guilmette wrote: > P.S. If anybody is able to look up _all_ of the route announcements > that have been made by AS201640 over the past few months, I for one would > definitely like to see those. Hello again, Ronald. I don't know for certain that it's all-inclusive, but I would look at https://stat.ripe.net/widget/routing-history#w.resource=AS201640 . Unlike last time, I don't have any contacts at the relevant ISPs. Shame. Jima From rfg at tristatelogic.com Sat Nov 1 03:57:09 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 31 Oct 2014 20:57:09 -0700 Subject: Hijacking machine: ASAS201640 / AS200002 In-Reply-To: <54542174.30809@ghostnet.de> Message-ID: <23227.1414814229@server1.tristatelogic.com> In message <54542174.30809 at ghostnet.de>, Armin Kneip wrote: >http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=201640 >http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=200002 > >or > >http://www.cidr-report.org/cgi-bin/as-report?as=AS201640&view=2.0 >http://www.cidr-report.org/cgi-bin/as-report?as=AS200002&view=2.0 Thank you. Unfortunately, the former pair of links only seems to provide data going back about one week, while the latter pair of links only seems to provide current data as of today. I am hoping to be able to find a list of all route announcements made by ASAS201640 going all the way back to its creation, which appears to possibly have occured on or about 2014-08-27. Regards, rfg From randy at psg.com Sat Nov 1 05:30:06 2014 From: randy at psg.com (Randy Bush) Date: Sat, 01 Nov 2014 14:30:06 +0900 Subject: Is it unusual to remove defunct rr objects? In-Reply-To: References: <20141031103423.615e1aea@cool.bendtel.com> <20141031173933.GA26681@puck.nether.net> Message-ID: > So who do we ask about making IRRs expire defunct objects you might start with a rigorous definition of defunct randy From deanperrine at gmail.com Sat Nov 1 06:15:49 2014 From: deanperrine at gmail.com (Dean Perrine) Date: Fri, 31 Oct 2014 23:15:49 -0700 Subject: Route Issue Level3 to GTT - Packet loss & Latency Message-ID: Hit a strange route issue earlier transiting Level3 network to GTT - Packet Loss & High Latency - caused some interruptions in critical traffic flow. Between Level3 hop 4.68.63.158 and GTT 144.136.105.226 - had a 20ms latency increase and packet loss. After about 1+ hours the route had shifted and latency dropped back down. Does anyone have details on this by any chance? Details below (If readable): *GOOD* *BAD* *route* *latency* *route* *latency* xe-11-1-2.bar2.houston1.level3.net [4.59.126.105] 53 xe-11-1-2.bar2.Houston1.Level3.net (4.59.126.105) 57.3 ae-2-3514.edge2.atlanta4.level3.net [4.69.150.165] 65 ae-2-3514.edge2.Atlanta4.Level3.net (4.69.63.158) 70.3 gtt-level3.atlanta4.level3.net [4.68.63.158] *65* gtt-level3.Atlanta4.level3.net (4.68.63.158) *70.3* xe-0-3-1.dal33.ip4.gtt.net [141.136.107.69] *70* xe-11-3-3.dal33.ip4.gtt.net (144.136.105.226) *98.3* gtt-gw.ip4.gtt.net [173.241.130.138] 70 gtt-gw.ip4.gtt.net (173.241.130.138) 97.1 66.171.224.26 70 66.171.224.34 97.8 Thanks, Dean From rmosher at he.net Sat Nov 1 06:24:56 2014 From: rmosher at he.net (Rob Mosher) Date: Sat, 01 Nov 2014 02:24:56 -0400 Subject: Hijacking machine: ASAS201640 / AS200002 In-Reply-To: <23227.1414814229@server1.tristatelogic.com> References: <23227.1414814229@server1.tristatelogic.com> Message-ID: <54547CB8.1070305@he.net> While it's not a thorough list of all announcements, here are nightly snapshots courtesy of http://bgp.he.net AS201640: http://pastebin.com/nvuVbnpn AS200002: http://pastebin.com/1JZnWadD -- Rob Mosher Senior Network and Software Engineer Hurricane Electric / AS6939 On 10/31/2014 11:57 PM, Ronald F. Guilmette wrote: > In message <54542174.30809 at ghostnet.de>, > Armin Kneip wrote: > >> http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=201640 >> http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=200002 >> >> or >> >> http://www.cidr-report.org/cgi-bin/as-report?as=AS201640&view=2.0 >> http://www.cidr-report.org/cgi-bin/as-report?as=AS200002&view=2.0 > > Thank you. > > Unfortunately, the former pair of links only seems to provide data > going back about one week, while the latter pair of links only seems > to provide current data as of today. > > I am hoping to be able to find a list of all route announcements > made by ASAS201640 going all the way back to its creation, which > appears to possibly have occured on or about 2014-08-27. > > > Regards, > rfg From wilhelm at ripe.net Sat Nov 1 10:43:31 2014 From: wilhelm at ripe.net (Rene Wilhelm) Date: Sat, 01 Nov 2014 11:43:31 +0100 Subject: Hijacking machine: ASAS201640 / AS200002 In-Reply-To: <54543176.7080203@jima.us> References: <22155.1414797602@server1.tristatelogic.com> <54543176.7080203@jima.us> Message-ID: <5454B953.6010306@ripe.net> On 11/1/14, 2:03 AM, Jima wrote: > On 2014-10-31 17:20, Ronald F. Guilmette wrote: >> P.S. If anybody is able to look up _all_ of the route announcements >> that have been made by AS201640 over the past few months, I for one >> would >> definitely like to see those. > > Hello again, Ronald. > > I don't know for certain that it's all-inclusive, but I would look at > https://stat.ripe.net/widget/routing-history#w.resource=AS201640 . Routing-history shows the prefixes which were observed in the 8-hourly RIB dumps from our collective of 13 RIS route collectors. Any short lived announcements which started after and ended before a full dump was taken will be missed by this widget. We do have a full record of all the BGP announcements observed with origin AS201640 in the last 90 days, but it requires some clicking and digging to extract the prefixes. See: https://stat.ripe.net/widget/bgp-update-activity#w.starttime=2014-08-03T00%3A00%3A00&w.endtime=2014-11-01T00%3A00%3A00&w.resource=AS201640 -- Rene From jared at puck.Nether.net Sat Nov 1 13:57:02 2014 From: jared at puck.Nether.net (Jared Mauch) Date: Sat, 1 Nov 2014 09:57:02 -0400 Subject: Hijacking machine: ASAS201640 / AS200002 In-Reply-To: <23227.1414814229@server1.tristatelogic.com> References: <54542174.30809@ghostnet.de> <23227.1414814229@server1.tristatelogic.com> Message-ID: <20141101135702.GA28565@puck.nether.net> On Fri, Oct 31, 2014 at 08:57:09PM -0700, Ronald F. Guilmette wrote: > > In message <54542174.30809 at ghostnet.de>, > Armin Kneip wrote: > > >http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=201640 > >http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=200002 > > > >or > > > >http://www.cidr-report.org/cgi-bin/as-report?as=AS201640&view=2.0 > >http://www.cidr-report.org/cgi-bin/as-report?as=AS200002&view=2.0 > > > Thank you. > > Unfortunately, the former pair of links only seems to provide data > going back about one week, while the latter pair of links only seems > to provide current data as of today. > > I am hoping to be able to find a list of all route announcements > made by ASAS201640 going all the way back to its creation, which > appears to possibly have occured on or about 2014-08-27. You have to parse the UPDATES data, eg: located at archive.routeviews.org or something else, not the rib snapshots. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From jared at puck.Nether.net Sat Nov 1 14:04:56 2014 From: jared at puck.Nether.net (Jared Mauch) Date: Sat, 1 Nov 2014 10:04:56 -0400 Subject: Is it unusual to remove defunct rr objects? In-Reply-To: References: <20141031103423.615e1aea@cool.bendtel.com> <20141031173933.GA26681@puck.nether.net> Message-ID: <20141101140456.GB28565@puck.nether.net> On Sat, Nov 01, 2014 at 02:30:06PM +0900, Randy Bush wrote: > > So who do we ask about making IRRs expire defunct objects > > you might start with a rigorous definition of defunct I have my own ideas on this topic, including routes that have not been seen for over 1 year. You may always miss the routes that are not 'seen' on the public internet though. I'm still reminded of the question on the internic forms in early 90s about "will you be connecting to the internet" when asking for address space. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From mysidia at gmail.com Sat Nov 1 15:57:34 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 1 Nov 2014 10:57:34 -0500 Subject: Is it unusual to remove defunct rr objects? In-Reply-To: <20141101140456.GB28565@puck.nether.net> References: <20141031103423.615e1aea@cool.bendtel.com> <20141031173933.GA26681@puck.nether.net> <20141101140456.GB28565@puck.nether.net> Message-ID: On Sat, Nov 1, 2014 at 9:04 AM, Jared Mauch wrote: > On Sat, Nov 01, 2014 at 02:30:06PM +0900, Randy Bush wrote: >> > So who do we ask about making IRRs expire defunct objects >> you might start with a rigorous definition of defunct > I have my own ideas on this topic, including routes that have > not been seen for over 1 year. You may always miss the routes that > are not 'seen' on the public internet though. I'm still reminded of > the question on the internic forms in early 90s about "will you be > connecting to the internet" when asking for address space. Do the internet route registries exist to track routes that are not to appear on the public internet? I think not. There should probably be an attribute provided for such objects, however, that would indicate "This route does not appear on the public internet". If not tagged like that in some manner, and a matching route does has not appeared on the public internet at any time during the past 6 to 12 months, then I would consider the registry object to be defunct. > - Jared -- -JH From cb.list6 at gmail.com Sat Nov 1 16:16:31 2014 From: cb.list6 at gmail.com (Ca By) Date: Sat, 1 Nov 2014 09:16:31 -0700 Subject: Is it unusual to remove defunct rr objects? In-Reply-To: <20141031173933.GA26681@puck.nether.net> References: <20141031103423.615e1aea@cool.bendtel.com> <20141031173933.GA26681@puck.nether.net> Message-ID: On Friday, October 31, 2014, Jared Mauch wrote: > On Fri, Oct 31, 2014 at 10:34:23AM -0700, Tim Howe wrote: > > I've since found a disturbing number of defunct objects that > > relate to my customers (and me) in a similar way, and I have mostly > > had success in getting them cleared up. If my relatively small > > customer base is any indication, there are more incorrect objects out > > there than correct ones. I feel this is something I should have been > > looking into sooner. > > People tend to treat things like IRR (eg: RADB, etc) as a > garbage pit you toss things into and never remove from. +1, it is a garbage pit Do whatever it takes to deploy today move on, dont look back or update, failover between isps fails, emergency update. Back to sleep If its not systematicly automated for grandma, it is broken and will only be patched by exception / interrupt > > Is this a non-issue that I shouldn't worry about? Doesn't the > > quality of this data effect Origin Validation efforts? > > Yes it does. This has a fairly severe impact for those that build > off the IRR data for filters. We have seen customers end up including > AS7018 in their AS-SET or as you noticed have other legacy routes appear. > > > > > Sorry that this turned out so long; I wanted to give some > > context. > > No worries. I've got a transient routing leak detector > that does find/fuzz these issues which has been running for a few > years now. I'm guessing you may see some of the related prefixes > there as a result. It's in need of a U/I redesign (code welcome) > but is located here: > > http://puck.nether.net/bgp/leakinfo.cgi > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > > clue++; | http://puck.nether.net/~jared/ My statements are only > mine. > From tim.h at bendtel.com Sat Nov 1 16:39:08 2014 From: tim.h at bendtel.com (Tim Howe) Date: Sat, 1 Nov 2014 09:39:08 -0700 Subject: Is it unusual to remove defunct rr objects? In-Reply-To: References: <20141031103423.615e1aea@cool.bendtel.com> <20141031173933.GA26681@puck.nether.net> Message-ID: <20141101093908.2b3ecdee@wind.dirtymonday.net> On Sat, 01 Nov 2014 14:30:06 +0900 Randy Bush wrote: > > So who do we ask about making IRRs expire defunct objects > > you might start with a rigorous definition of defunct I can come up with a number of examples, but the ones that concern me the most are route objects where the route should not (or should no longer) originate from the origin AS. Some of these that I found were probably never correct. I can detail what I think were the chain of events that led to their creation, but I'm not sure it would be On Topic. --TimH From tim.h at bendtel.com Sat Nov 1 16:57:55 2014 From: tim.h at bendtel.com (Tim Howe) Date: Sat, 1 Nov 2014 09:57:55 -0700 Subject: Is it unusual to remove defunct rr objects? In-Reply-To: References: <20141031103423.615e1aea@cool.bendtel.com> <20141031173933.GA26681@puck.nether.net> Message-ID: <20141101095755.51420ae6@wind.dirtymonday.net> On Fri, 31 Oct 2014 13:51:59 -0500 Jimmy Hess wrote: > On Fri, Oct 31, 2014 at 12:39 PM, Jared Mauch wrote: > [snip] > > People tend to treat things like IRR (eg: RADB, etc) as a > > garbage pit you toss things into and never remove from. > > So who do we ask about making IRRs expire defunct objects and/or > changing their system design to ensure that the legitimate resource holder > can remove references to their prefix from ASes they no longer > authorize to carry them, > > without requiring all sorts of assistance, cooperation, and > willingness from the AS maintainer? :) I have been asking the folks who manage the maintnr object in question. I have so far been mostly successful. I spend varying amounts of time explaining myself... /Sometimes/ simply pasting the object in an email to the right person is all that is needed. --TimH From bryan at digitalocean.com Sat Nov 1 19:07:04 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Sat, 1 Nov 2014 15:07:04 -0400 Subject: Hijacking machine: ASAS201640 / AS200002 In-Reply-To: <20141101135702.GA28565@puck.nether.net> References: <54542174.30809@ghostnet.de> <23227.1414814229@server1.tristatelogic.com> <20141101135702.GA28565@puck.nether.net> Message-ID: BGPlay found at https://stat.ripe.net/ is back and I find easier to look back at bgp tables and find events like another AS or more specific route appearing. Also if you never looked, bgpmon.net is a decent service to monitor import announcements and AS numbers to get near real time alerts of routing changes. Doesn't help this situation but can help you get alerted when it happens next. Bryan Socha Network Engineer DigitalOcean 646-450-0472 On Sat, Nov 1, 2014 at 9:57 AM, Jared Mauch wrote: > On Fri, Oct 31, 2014 at 08:57:09PM -0700, Ronald F. Guilmette wrote: > > > > In message <54542174.30809 at ghostnet.de>, > > Armin Kneip wrote: > > > > >http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=201640 > > >http://bgpupdates.potaroo.net/cgi-bin/generate_as_log?as=200002 > > > > > >or > > > > > >http://www.cidr-report.org/cgi-bin/as-report?as=AS201640&view=2.0 > > >http://www.cidr-report.org/cgi-bin/as-report?as=AS200002&view=2.0 > > > > > > Thank you. > > > > Unfortunately, the former pair of links only seems to provide data > > going back about one week, while the latter pair of links only seems > > to provide current data as of today. > > > > I am hoping to be able to find a list of all route announcements > > made by ASAS201640 going all the way back to its creation, which > > appears to possibly have occured on or about 2014-08-27. > > You have to parse the UPDATES data, eg: located at > archive.routeviews.org or something else, not the rib snapshots. > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only > mine. > From rs at seastrom.com Sat Nov 1 22:18:41 2014 From: rs at seastrom.com (Rob Seastrom) Date: Sat, 01 Nov 2014 18:18:41 -0400 Subject: Is it unusual to remove defunct rr objects? In-Reply-To: (Jimmy Hess's message of "Sat, 1 Nov 2014 10:57:34 -0500") References: <20141031103423.615e1aea@cool.bendtel.com> <20141031173933.GA26681@puck.nether.net> <20141101140456.GB28565@puck.nether.net> Message-ID: <8661eylg3i.fsf@valhalla.seastrom.com> Jimmy Hess writes: > Do the internet route registries exist to track routes that are not > to appear on the public internet? I think not. What's "the public Internet"? Does it mean "the DFZ as seen at Jimmy Hess' router, with his set of upstreams"? If so, I can assure you that there are plenty of routes that need to pass filters that are (or optimally would be) built off of IRR data that would not pass this test. > There should probably be an attribute provided for such objects, > however, that would indicate "This route does not appear on the > public internet". see above. :) > If not tagged like that in some manner, and a matching route does has > not appeared on the public internet at any time during the past 6 to > 12 months, then I would consider the registry object to be defunct. Where on the public Internet? Do networks run by organizations such as SITA, ARINC, BT Radianz, UK MOD, and US DOD that use globally unique space and may interconnect with each other in some way (and could hypothetically be using IRR-type structures to describe that routing policy though I don't think the military does that) get their objects unceremoniously booted? -r From mfidelman at meetinghouse.net Sat Nov 1 23:42:31 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 01 Nov 2014 19:42:31 -0400 Subject: =?UTF-8?Q?=e2=80=9cThe_Devil_had_possessed_his_netbook?= =?UTF-8?Q?=e2=80=9d=e2=80=94and_other_tales_of_IT_terror_?= In-Reply-To: <2311EAFF-9075-4E5B-AA5F-301C0D8BBCC0@meetinghouse.net> References: <2311EAFF-9075-4E5B-AA5F-301C0D8BBCC0@meetinghouse.net> Message-ID: <54556FE7.3030400@meetinghouse.net> A day late, but somewhat amusing..... http://arstechnica.com/information-technology/2014/10/the-devil-had-possessed-his-netbook-and-other-tales-of-it-terror/ From mkamal at noor.net Sun Nov 2 08:56:37 2014 From: mkamal at noor.net (Mohamed Kamal) Date: Sun, 02 Nov 2014 11:56:37 +0300 Subject: TE offline tools Message-ID: <5455F1C5.4000605@noor.net> Hello, I'm curious what is the "tools" for computing and validating TE tunnels over the network. I read on MPLS Enabled Applications that there are tools out there that can be used to do so. Anyone has a suggestion? Regards, -- Mohamed Kamal Network Engineer, Core Team NOOR Data Networks, SAE City Stars Capital 5 A4 Omar Ibn El Khattab Street Heliopolis, Cairo, Egypt Mobile GSM.: +2 0100 29 49 691 Land Line.: +20 2 16700 Ext.: 139 Fax.: +20 2 3748 2816 Email.: mkamal at noor.net From mkamal at noor.net Sun Nov 2 09:15:58 2014 From: mkamal at noor.net (Mohamed Kamal) Date: Sun, 02 Nov 2014 12:15:58 +0300 Subject: TE offline tools In-Reply-To: References: <5455F1C5.4000605@noor.net> Message-ID: <5455F64E.3050802@noor.net> I'm aware about the Cisco MATE software, but I'd prefer an open-source, vendor-agnostic one, something that in-house imporvements can also be achieved. On 11/2/2014 12:01 PM, mohamed Osama Saad Abo sree wrote: > You can use Caridan tool, Cisco own it currently and it does all the > computation needed and can draw your network topology Mohamed Kamal Core Network Engineer From baldur.norddahl at gmail.com Sun Nov 2 12:52:04 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 2 Nov 2014 13:52:04 +0100 Subject: Is it unusual to remove defunct rr objects? In-Reply-To: <8661eylg3i.fsf@valhalla.seastrom.com> References: <20141031103423.615e1aea@cool.bendtel.com> <20141031173933.GA26681@puck.nether.net> <20141101140456.GB28565@puck.nether.net> <8661eylg3i.fsf@valhalla.seastrom.com> Message-ID: On 1 November 2014 23:18, Rob Seastrom wrote: > Where on the public Internet? > > Do networks run by organizations such as SITA, ARINC, BT Radianz, UK > MOD, and US DOD that use globally unique space and may interconnect > with each other in some way (and could hypothetically be using > IRR-type structures to describe that routing policy though I don't > think the military does that) get their objects unceremoniously booted? > Why would I want routes from US DOD in my filters, if this stuff is not supposed to be on the public internet? That is a waste of everyones ressources. Regards, Baldur From colton.conor at gmail.com Sun Nov 2 17:02:44 2014 From: colton.conor at gmail.com (Colton Conor) Date: Sun, 2 Nov 2014 11:02:44 -0600 Subject: Cisco CCNA Training Message-ID: We have a couple of techs that want to learn cisco and networking in general. What do you recommend for learning and getting certified on Cisco? There seems to be a million different training courses, books, etc out there. From colton.conor at gmail.com Sun Nov 2 17:04:42 2014 From: colton.conor at gmail.com (Colton Conor) Date: Sun, 2 Nov 2014 11:04:42 -0600 Subject: Tail-F Message-ID: Is anyone using Tail-f software or know anything similar? We are looking for a solution that is vendor agnostic. Can do simple command like show interface so even non-network techs and CSR's can get basic is the port up or down type stats without having to directly login to the network. From eyeronic.design at gmail.com Sun Nov 2 17:38:04 2014 From: eyeronic.design at gmail.com (Mike Hale) Date: Sun, 2 Nov 2014 09:38:04 -0800 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: Depends on how the techs in question learn best, but I've found that a good CCNA book (like the Lammle one) combined with either a network simulator (I like Boson, but packet tracer and GNS3 are both good too) or, better yet, physical hardware they can play with. Alternatively, if you have a local community college nearby that has the Cisco Academy curriculum, that's a great option as well. - http://www.amazon.com/CCNA-Routing-Switching-Study-Guide/dp/1118749618/ref=sr_1_1?ie=UTF8&qid=1414949721&sr=8-1&keywords=lammle+ccna On Sun, Nov 2, 2014 at 9:02 AM, Colton Conor wrote: > We have a couple of techs that want to learn cisco and networking in > general. What do you recommend for learning and getting certified on Cisco? > There seems to be a million different training courses, books, etc out > there. -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From chris at aperturefiber.com Sun Nov 2 17:48:30 2014 From: chris at aperturefiber.com (Chris Garrett) Date: Sun, 2 Nov 2014 11:48:30 -0600 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: I have a couple of techs who have done well with the offical cisco books and another couple who have passed using video training from CBT Nuggets. Depends on the user really, it seems the younger folks soak up the video training a bit easier while the more senior techs preferred to read the material. > On Nov 2, 2014, at 11:38 AM, Mike Hale wrote: > > Depends on how the techs in question learn best, but I've found that a > good CCNA book (like the Lammle one) combined with either a network > simulator (I like Boson, but packet tracer and GNS3 are both good too) > or, better yet, physical hardware they can play with. Alternatively, > if you have a local community college nearby that has the Cisco > Academy curriculum, that's a great option as well. > > > - http://www.amazon.com/CCNA-Routing-Switching-Study-Guide/dp/1118749618/ref=sr_1_1?ie=UTF8&qid=1414949721&sr=8-1&keywords=lammle+ccna > > On Sun, Nov 2, 2014 at 9:02 AM, Colton Conor wrote: >> We have a couple of techs that want to learn cisco and networking in >> general. What do you recommend for learning and getting certified on Cisco? >> There seems to be a million different training courses, books, etc out >> there. > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > From mysidia at gmail.com Sun Nov 2 18:19:10 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 2 Nov 2014 12:19:10 -0600 Subject: Tail-F In-Reply-To: References: Message-ID: On Sun, Nov 2, 2014 at 11:04 AM, Colton Conor wrote: > Is anyone using Tail-f software or know anything similar? We are looking > for a solution that is vendor agnostic. Can do simple command like show I've only read of this, but my understanding is the Tail-F product is for configuration management and supporting provisioning automations anyways, monitoring configs sure. As far as I know they cannot monitor or show network operational status, so your use case may not overlap with their capabilities, and perhaps, what you are likely suggesting is something that unfortunately doesn't exist yet: a tool for both configuring and observing a detailed operational state of the network devices in a vendor-agnostic way. However, for simple bandwidth statistics and port Up/Down; for most devices, this information is available through SNMP based management tools. Basic Up/Down and statistics could generally be gathered by any good SNMP-based NMS / network monitoring product, there are thousands of these, or OSS such as Cacti, Zenoss, and proprietary ones such as HP OpenView, SolarWinds, InterMapper, Whatsup; also, just about every major network device vendor has their element management system. Various NMS can also be configured to run some selected code or offer up a GUI command for running a snmpwalk against the ifOperStatus or ifIn/Out Octets. > interface so even non-network techs and CSR's can get basic is the port up > or down type stats without having to directly login to the network. -- -JH From jgreco at ns.sol.net Sun Nov 2 19:09:37 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 2 Nov 2014 13:09:37 -0600 (CST) Subject: Industry standard bandwidth guarantee? In-Reply-To: <5453B55A.2040505@kanren.net> Message-ID: <201411021909.sA2J9blh018145@aurora.sol.net> > Consider a better analogy from the provider side: A customer bakes a > nice beautiful fruit cake for their Aunt Eddie in wilds of > Saskatchewan. The cake is 10 kg - but they want to make sure it gets > to Eddie properly, so they wrap it in foil, then bubble wrap, then put > it in a box. They have this 10kg cake and 1kg of packaging to get it to > up north. They then go to the ISP store to get it delivered - and are > surprised, that to get it there, they have to pay to ship 11kg. But the > cake is only 10kg! If they pay to ship 11kg for a 10kg cake, obviously > the ISP is trying to screw them. The ISP should deliver the 10kg cake at > the 10kg rate and eat the cost of the rest - no matter how many kg the > packaging is or how much space they actually have on the delivery truck. > > And then the customer goes to the Internet to decry the nerve of the ISP > for not explaining the concept of "packaging" up front and in big > letters. "Why they should tell you - to ship 10kg, buy 11kg up front! > Or better yet, they shouldn't calculate the box when weighing for > shipping! I should pay for the contents and the wrapping, no matter how > much it is, shouldn't even be considered! It's plain robbery. Harrumph". Perhaps that's because in the case of shipping, it is usual and customary to expect an item to be packaged carefully and that the packaging is counted as part of the shipped package. >From the provider side (bearing in mind I've been in that business for a few decades), usually what the customer wants is to understand what they're purchasing, and if you as a provider tell them that they're buying a 100Mbps circuit, they kinda expect that they can shovel 100Mbps down that circuit. No amount of "but you should expect that there's packaging and you should just /knoooooow/ (whine added for emphasis) that means only 80Mbps usable" is really going to change that. That's why I designed an analogy that is much more representative of reality than yours. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From surfer at mauigateway.com Sun Nov 2 20:43:57 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 2 Nov 2014 12:43:57 -0800 Subject: Tail-F Message-ID: <20141102124357.62357868@m0005299.ppops.net> --- colton.conor at gmail.com wrote: From: Colton Conor Can do simple command like show interface so even non-network techs and CSR's can get basic is the port up or down type stats without having to directly login to the network. ------------------------------------------------- Do an snmpget on the SNMP OIDs you want them to see. If they're not *nix savvy you could write a tiny shell script that'd do it for them. It won't be the output of sho int but the data will be the same. scott From bedard.phil at gmail.com Sun Nov 2 21:15:11 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Sun, 2 Nov 2014 16:15:11 -0500 Subject: Tail-F In-Reply-To: References: Message-ID: Tail-F's ConfD can operate as a front-end CLI and do the things he wants it to do in an operational sense but I would agree it may not be the easiest to use tool for simply monitoring and grabbing interface state/statistics. It's fairly flexible and can do a lot of abstracted things through its ConfD element but there is some backend work to make it happen. Not as much as doing it from scratch but still a bit of work. It can abstract different device CLIs so they all look the same and use the same commands and you can extend the CLI to do custom things as well if you want. The whole system is fairly powerful and very extensibe. There are monitoring elements built into it and It could be a full blown monitoring system, really just depends on the scale you need and how much work you want to put into it. Phil On Sun, Nov 2, 2014 at 1:19 PM, Jimmy Hess wrote: > On Sun, Nov 2, 2014 at 11:04 AM, Colton Conor > wrote: > > Is anyone using Tail-f software or know anything similar? We are looking > > for a solution that is vendor agnostic. Can do simple command like show > > I've only read of this, but my understanding is the Tail-F product is > for configuration management and supporting provisioning automations > anyways, monitoring configs sure. As far as I know they cannot > monitor or show network operational status, so your use case may not > overlap with their capabilities, and perhaps, what you are likely > suggesting is something that unfortunately doesn't exist yet: a tool > for both configuring and observing a detailed operational state of the > network devices in a vendor-agnostic way. > > However, for simple bandwidth statistics and port Up/Down; for most > devices, this information is available through SNMP based management > tools. > > Basic Up/Down and statistics could generally be gathered by any good > SNMP-based NMS / network monitoring product, there are thousands of > these, or OSS such as Cacti, Zenoss, and proprietary ones such as HP > OpenView, SolarWinds, InterMapper, Whatsup; also, just about every > major network device vendor has their element management system. > > Various NMS can also be configured to run some selected code or offer > up a GUI command for running a snmpwalk against the ifOperStatus or > ifIn/Out Octets. > > > > > > interface so even non-network techs and CSR's can get basic is the port > up > > or down type stats without having to directly login to the network. > -- > -JH > From colton.conor at gmail.com Sun Nov 2 23:56:40 2014 From: colton.conor at gmail.com (Colton Conor) Date: Sun, 2 Nov 2014 17:56:40 -0600 Subject: Tail-F In-Reply-To: References: Message-ID: I am aware that you can see if a port is up or down through SNMP. I guess that was a bad example. I want to see the entire output of a show interface command. For example, we have multiple types of access networks (GPON, DSL, Cisco ethernet switches). Some of the show interface commands are fairly basic, but others like on a DSL port show much more information like sync rate, signal loss, etc. The only way to get this information on some platforms is to run the show interface command for CLI I believe, or login to the access platform's GUI interface. Both of these task aren't so easy when you are dealing with multiple access platforms. On Sun, Nov 2, 2014 at 3:15 PM, Phil Bedard wrote: > Tail-F's ConfD can operate as a front-end CLI and do the things he wants > it to do in an operational sense but I would agree it may not be the > easiest to use tool for simply monitoring and grabbing interface > state/statistics. It's fairly flexible and can do a lot of abstracted > things through its ConfD element but there is some backend work to make it > happen. Not as much as doing it from scratch but still a bit of work. > It can abstract different device CLIs so they all look the same and use the > same commands and you can extend the CLI to do custom things as well if you > want. > > The whole system is fairly powerful and very extensibe. There are > monitoring elements built into it and It could be a full blown monitoring > system, really just depends on the scale you need and how much work you > want to put into it. > > Phil > > > > On Sun, Nov 2, 2014 at 1:19 PM, Jimmy Hess wrote: > >> On Sun, Nov 2, 2014 at 11:04 AM, Colton Conor >> wrote: >> > Is anyone using Tail-f software or know anything similar? We are looking >> > for a solution that is vendor agnostic. Can do simple command like show >> >> I've only read of this, but my understanding is the Tail-F product is >> for configuration management and supporting provisioning automations >> anyways, monitoring configs sure. As far as I know they cannot >> monitor or show network operational status, so your use case may not >> overlap with their capabilities, and perhaps, what you are likely >> suggesting is something that unfortunately doesn't exist yet: a tool >> for both configuring and observing a detailed operational state of the >> network devices in a vendor-agnostic way. >> >> However, for simple bandwidth statistics and port Up/Down; for most >> devices, this information is available through SNMP based management >> tools. >> >> Basic Up/Down and statistics could generally be gathered by any good >> SNMP-based NMS / network monitoring product, there are thousands of >> these, or OSS such as Cacti, Zenoss, and proprietary ones such as HP >> OpenView, SolarWinds, InterMapper, Whatsup; also, just about every >> major network device vendor has their element management system. >> >> Various NMS can also be configured to run some selected code or offer >> up a GUI command for running a snmpwalk against the ifOperStatus or >> ifIn/Out Octets. >> >> >> >> >> > interface so even non-network techs and CSR's can get basic is the port >> up >> > or down type stats without having to directly login to the network. >> -- >> -JH >> > > From rs at seastrom.com Mon Nov 3 01:08:38 2014 From: rs at seastrom.com (Rob Seastrom) Date: Sun, 02 Nov 2014 20:08:38 -0500 Subject: Is it unusual to remove defunct rr objects? In-Reply-To: (Baldur Norddahl's message of "Sun, 2 Nov 2014 13:52:04 +0100") References: <20141031103423.615e1aea@cool.bendtel.com> <20141031173933.GA26681@puck.nether.net> <20141101140456.GB28565@puck.nether.net> <8661eylg3i.fsf@valhalla.seastrom.com> Message-ID: <86oasp9jl5.fsf@valhalla.seastrom.com> Baldur Norddahl writes: > On 1 November 2014 23:18, Rob Seastrom wrote: > >> Where on the public Internet? >> >> Do networks run by organizations such as SITA, ARINC, BT Radianz, UK >> MOD, and US DOD that use globally unique space and may interconnect >> with each other in some way (and could hypothetically be using >> IRR-type structures to describe that routing policy though I don't >> think the military does that) get their objects unceremoniously booted? >> > > Why would I want routes from US DOD in my filters, if this stuff is not > supposed to be on the public internet? That is a waste of everyones > ressources. If you (and they) use the full capabilities of RPSL... you won't. -r From list at satchell.net Mon Nov 3 01:16:51 2014 From: list at satchell.net (Stephen Satchell) Date: Sun, 02 Nov 2014 17:16:51 -0800 Subject: Tail-F In-Reply-To: References: Message-ID: <5456D783.6000401@satchell.net> On 11/02/2014 03:56 PM, Colton Conor wrote: > Some of the show interface commands are fairly > basic, but others like on a DSL port show much more information like sync > rate, signal loss, etc. Yes, the information in SNMP is pretty well spread out, because a SNMP get request returns a single value. SO you have to find all the OIDs that return the information you want to see. Simple but sometimes very, very tedious. You then wrap your data collection in a application/webpage that displays it. Vendor agnostic. Not turn-key without spending lots and lots and lots of money. Another option: have you tried using Expect? From bedard.phil at gmail.com Mon Nov 3 02:22:54 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Sun, 02 Nov 2014 21:22:54 -0500 Subject: TE offline tools In-Reply-To: <5455F64E.3050802@noor.net> References: <5455F1C5.4000605@noor.net> <5455F64E.3050802@noor.net> Message-ID: You can look at tools like NS2/NS3 or OMNet++, but these are not going to do what you want out of the box, they are a framework for network simulation but you'll have to program them to do what you want, they are more used in academic settings. If you want a nice interface you are kind of stuck right now with the commercial offerings from Cariden, OpNet, WANDL (now Juniper), and Aria Networks. Most of those packages are extensible via scripting if you want to do additional things. Phil On 11/2/14, 3:15 AM, "Mohamed Kamal" wrote: > >I'm aware about the Cisco MATE software, but I'd prefer an open-source, >vendor-agnostic one, something that in-house imporvements can also be >achieved. > > On 11/2/2014 12:01 PM, mohamed Osama Saad Abo sree wrote: >> You can use Caridan tool, Cisco own it currently and it does all the >> computation needed and can draw your network topology > >Mohamed Kamal >Core Network Engineer > From swm at emanon.com Mon Nov 3 01:36:19 2014 From: swm at emanon.com (Scott Morris) Date: Sun, 2 Nov 2014 20:36:19 -0500 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: Depends on how quickly you want them trained, and how they tend to learn thingsŠ Reading is good, but can be boring and tedious and not always have all the answers. Standard ILT can be costly, but very quick and often standard (though I¹d shop around for who you have as an instructor since that can make or break the success)! Video-based training gives a good mix of things and there are options out there. I know there¹s been one other response for CBT Nuggets, which I would definitely recommend. Take that with a grain of salt (and I¹m ok with that) since I do some work for them now. However, I would have recommended them even before I started developing training for them. :) Jeremy Cioara teaches the CCNA courses for CBT, and he is quite animated and very knowledgeable. He will definitely get all the necessary points across. In addition to the certification courses you mentioned, there are also many ³real world² variants of materials as well, which give a different slant to the teachings that you may find useful for your group. And being a subscription cost, you can watch as many different things as you¹d like rather than being limited to one course. Something worth checking out. Don¹t take my word for it, go look for yourself (or have your group do that). Cheers, Scott -----Original Message----- From: Colton Conor Date: Sunday, November 2, 2014 at 1:02 PM To: NANOG Subject: Cisco CCNA Training >We have a couple of techs that want to learn cisco and networking in >general. What do you recommend for learning and getting certified on >Cisco? >There seems to be a million different training courses, books, etc out >there. From jmaslak at antelope.net Mon Nov 3 02:38:33 2014 From: jmaslak at antelope.net (Joel Maslak) Date: Sun, 2 Nov 2014 19:38:33 -0700 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: You might look at your local community college's offerings. Probably better bang for the buck than many other offerings. On Sun, Nov 2, 2014 at 10:02 AM, Colton Conor wrote: > We have a couple of techs that want to learn cisco and networking in > general. What do you recommend for learning and getting certified on Cisco? > There seems to be a million different training courses, books, etc out > there. > From jeroen at massar.ch Mon Nov 3 12:33:36 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 03 Nov 2014 13:33:36 +0100 Subject: HTTP 302 with multiple Location: headers? Message-ID: <54577620.1070708@massar.ch> Ignoring the fact that Akamai IPv6 is broken on random nodes, thus you get either a working response or not from the same IP as some of the nodes are borked and thus just hang the connection.. (could be pmtu, hard to say without peeking inside the cluster).... see amongst others: https://www.sixxs.net/forum/?msg=general-12378937 But on a non-IPv4 note for once, I just noticed this funny one: $ telnet -4 www.akamai.com 80 Trying 95.101.216.85... Connected to e8921.dscx.akamaiedge.net. Escape character is '^]'. GET /html/technology/nocc.html HTTP/1.1 Host: www.akamai.com HTTP/1.1 302 Moved Temporarily Content-Length: 153 Content-Type: text/html Location: /esi/ui/html_head.html Location: /esi/ui/header.html Location: /esi/ui/technology-nav.html Location: /esi/ui/footer.html Location: /esi/ui/footer_js.html Location: /esi/webtrends.html Location: /esi/google-tag-manager.html Set-Cookie: cm_sessionid=47d4fed5001b00007c7457540ff80400b7650000; path=/ Set-Cookie: x_hd= Set-Cookie: x_hd= Set-Cookie: x_hd= Set-Cookie: x_hd= Set-Cookie: x_hd= Set-Cookie: x_hd= Set-Cookie: x_hd= ETag: "4c08f-206b-50353850ddb40" Cache-Control: max-age=70369 Date: Mon, 03 Nov 2014 12:26:36 GMT Connection: keep-alive Error Page An error (302 Moved Temporarily) has occured in response to this request. Connection closed by foreign host. Multiple Location: headers, really? and for head/footer/etc? Really? :) Chrome reports: --- Error code: ERR_RESPONSE_HEADERS_MULTIPLE_LOCATION --- Firefox: --- Corrupted Content Error The page you are trying to view cannot be shown because an error in the data transmission was detected. --- Note the irony in googling for Akamai NOC and getting such a page. I think there are a couple of b0rked nodes in the cluster that is attempting to serve me... Greets, Jeroen From askoorb+nanog at gmail.com Mon Nov 3 12:50:51 2014 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Mon, 3 Nov 2014 12:50:51 +0000 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: Hi, On Mon, Nov 3, 2014 at 2:38 AM, Joel Maslak wrote: > You might look at your local community college's offerings. Probably > better bang for the buck than many other offerings. > > On Sun, Nov 2, 2014 at 10:02 AM, Colton Conor > wrote: > >> We have a couple of techs that want to learn cisco and networking in >> general. What do you recommend for learning and getting certified on Cisco? >> There seems to be a million different training courses, books, etc out >> there. >> I would agree with considering face-to-face offerings; especially if it is run with evening classes or at times the employee can access without affecting work. It's how I first started my CCNA and I really appreciated having access to a real physical lab, library, instructors and other students. Though this was way back before Cisco's all-singing all-dancing website with it's 'online' lab. Quite often you can also use CCNA courses at a real college as part of a more general qualification and they often offer other courses that it can be handy for staff to have, like CompTIA's Security+ if you are doing any MOD or Federal contracting. And as has been said they are normally quite cheap for what you get. However, have you considered actually asking the techs how they learn best? Alex From nanog at me.net.ng Mon Nov 3 13:23:22 2014 From: nanog at me.net.ng (Joseph Okoegwale) Date: Mon, 3 Nov 2014 14:23:22 +0100 Subject: ISP Performance Metrics and Performance Measurement tools Message-ID: Dear all - Kindly share commonly used metrics for benchmarking ISPs and available tools (preferably open source) that are used for tracking and reporting these metrics. thanks for your help and regards, Joseph From hannigan at gmail.com Mon Nov 3 13:47:58 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 3 Nov 2014 14:47:58 +0100 Subject: HTTP 302 with multiple Location: headers? In-Reply-To: <54577620.1070708@massar.ch> References: <54577620.1070708@massar.ch> Message-ID: Thanks Jeroen, We'll get on this and if we need more information we'll reach out. Much appreciated. Best, -M< On Mon, Nov 3, 2014 at 1:33 PM, Jeroen Massar > wrote: > Ignoring the fact that Akamai IPv6 is broken on random nodes, thus you > get either a working response or not from the same IP as some of the > nodes are borked and thus just hang the connection.. (could be pmtu, > hard to say without peeking inside the cluster).... see amongst others: > https://www.sixxs.net/forum/?msg=general-12378937 > > > But on a non-IPv4 note for once, I just noticed this funny one: > > $ telnet -4 www.akamai.com 80 > Trying 95.101.216.85... > Connected to e8921.dscx.akamaiedge.net. > Escape character is '^]'. > GET /html/technology/nocc.html HTTP/1.1 > Host: www.akamai.com > > HTTP/1.1 302 Moved Temporarily > Content-Length: 153 > Content-Type: text/html > Location: /esi/ui/html_head.html > Location: /esi/ui/header.html > Location: /esi/ui/technology-nav.html > Location: /esi/ui/footer.html > Location: /esi/ui/footer_js.html > Location: /esi/webtrends.html > Location: /esi/google-tag-manager.html > Set-Cookie: cm_sessionid=47d4fed5001b00007c7457540ff80400b7650000; path=/ > Set-Cookie: x_hd= > Set-Cookie: x_hd= > Set-Cookie: x_hd= > Set-Cookie: x_hd= > Set-Cookie: x_hd= > Set-Cookie: x_hd= > Set-Cookie: x_hd= > ETag: "4c08f-206b-50353850ddb40" > Cache-Control: max-age=70369 > Date: Mon, 03 Nov 2014 12:26:36 GMT > Connection: keep-alive > > > > Error Page > > > An error (302 Moved Temporarily) has occured in response to this request. > > > Connection closed by foreign host. > > > Multiple Location: headers, really? and for head/footer/etc? Really? :) > > Chrome reports: > --- > Error code: ERR_RESPONSE_HEADERS_MULTIPLE_LOCATION > --- > > Firefox: > --- > Corrupted Content Error > > The page you are trying to view cannot be shown because an error in the > data transmission was detected. > --- > > > Note the irony in googling for Akamai NOC and getting such a page. > > I think there are a couple of b0rked nodes in the cluster that is > attempting to serve me... > > Greets, > Jeroen From jeremy.knapp at gmail.com Mon Nov 3 14:48:44 2014 From: jeremy.knapp at gmail.com (Jeremy Knapp) Date: Mon, 3 Nov 2014 07:48:44 -0700 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: https://learningnetwork.cisco.com/docs/DOC-20499 The learning lab looks like very good option. On Nov 3, 2014 5:52 AM, "Alex Brooks" wrote: > Hi, > > On Mon, Nov 3, 2014 at 2:38 AM, Joel Maslak wrote: > > You might look at your local community college's offerings. Probably > > better bang for the buck than many other offerings. > > > > On Sun, Nov 2, 2014 at 10:02 AM, Colton Conor > > wrote: > > > >> We have a couple of techs that want to learn cisco and networking in > >> general. What do you recommend for learning and getting certified on > Cisco? > >> There seems to be a million different training courses, books, etc out > >> there. > >> > > I would agree with considering face-to-face offerings; especially if > it is run with evening classes or at times the employee can access > without affecting work. It's how I first started my CCNA and I really > appreciated having access to a real physical lab, library, instructors > and other students. Though this was way back before Cisco's > all-singing all-dancing website with it's 'online' lab. > > Quite often you can also use CCNA courses at a real college as part of > a more general qualification and they often offer other courses that > it can be handy for staff to have, like CompTIA's Security+ if you are > doing any MOD or Federal contracting. And as has been said they are > normally quite cheap for what you get. > > However, have you considered actually asking the techs how they learn best? > > Alex > From bmanning at isi.edu Mon Nov 3 16:48:02 2014 From: bmanning at isi.edu (manning bill) Date: Mon, 3 Nov 2014 08:48:02 -0800 Subject: Fwd: Survey on Smart Data Pricing for Affordable Internet access References: Message-ID: <4AFCB803-DB22-4181-9FF4-7D96CF9BF08A@isi.edu> The IRTF is looking for data… /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 Begin forwarded message: > From: Arjuna Sathiaseelan > Subject: Survey on Smart Data Pricing for Affordable Internet access > Date: November 3, 2014 at 1:56:30 PST > To: irtf-discuss at irtf.org > Cc: ietf at ietf.org > > All, > > As part of the newly formed IRTF GAIA RG, we are conducting a research > study to better understand how > innovative pricing models for "data" can help bring Internet access to > the millions of people in the world who have so far been left > disconnected. We wish to ask several questions about how pricing > models for "data" would be most attractive to network operators, as > well as the challenges that might come with them. > > We would appreciate if this can be filled by the network operators, > VNOs, the community wireless network operators etc in the mailing > list. Incase you know of any other NOs, could you please forward this > to them. The deadline for filling the form is November 12th. It will > be great to get the survey done by many NOs as possible for us to > decipher the benefits of SDP on enabling affordable Internet access. > > The questionnaire should take no longer than 10 minutes, and all data > will be anonymous, private and exclusively used for non-commercial > purposes. > > The survey is here: > https://docs.google.com/forms/d/1B-Vtl3mYJ2TJMWiFXxHySMrKSqxrhy0EzVNDlXKhPew/viewform > > Regards > > -- > Arjuna Sathiaseelan | http://www.cl.cam.ac.uk/~as2330/ > From jra at baylink.com Mon Nov 3 17:20:27 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 03 Nov 2014 12:20:27 -0500 Subject: Fwd: Level 3 Acquires tw telecom In-Reply-To: <6703751e689f4b9299d28410aaaea5c7@2310> References: <6703751e689f4b9299d28410aaaea5c7@2310> Message-ID: <214535CA-B271-45A1-ABD4-9F203D672C05@baylink.com> L3 announcement from this morning's mail. Cheers, -- jra -------- Original Message -------- From: Level 3 Communications Sent: November 3, 2014 12:15:41 PM EST To: jra at baylink.com Subject: Level 3 Acquires tw telecom View on Mobile Phone View as Web Page A special message to our valued customers, We are excited to bring tw telecom and Level 3 together as we work to become the premier provider of communications services globally. The combination of tw telecom and Level 3 offers our customers, an advanced operating environment that delivers local to global advanced network solutions. Current Level 3 customers will benefit from thousands of new connected buildings, which will enable a higher quality, more reliable on-net experience. And tw telecom customers will benefit from Level 3’s extensive local-to-global footprint in more than 60 countries, substantial undersea networks and access to our data centers around the world. Along with the additions to our global infrastructure, existing and prospective customers will benefit from an expanded product portfolio, targeted at helping enterprises, government agencies and carriers manage their networks efficiently and securely. There will be some changes ahead, but one thing you can be assured won’t change is our commitment to you. Whether you are a tw telecom customer, a Level 3 customer, or both -- we remain intensely focused on solving the challenges you face as your business’ communications requirements grow. As we work to integrate our teams, your current account teams will remain the same. I encourage you to connect with your account team if you have any questions or concerns about day-to-day business. Moving forward, any changes that affect you will be communicated to you in a clear and timely manner. Our commitment is that we will continue to take end-to-end responsibility for the secure, reliable network experience we provide to you. That means we will be easy to do business with, responsive and will deliver on our promises. We appreciate your business and confidence, and look forward to serving your needs now and in the future. Welcome to the new Level 3 Communications. To learn more about the acquisition click here . Sincerely, John Blount Regional President, North America and APAC This email message may be considered an advertisement or solicitation. Level 3 Communications, 1025 Eldorado Blvd., Broomfield, CO, 80021 Unsubscribe http://app.your.level3.com/e/u.aspx?s=2310&elq=6703751e689f4b9299d28410aaaea5c7 Privacy http://www.level3.com/en/privacy/?elq=6703751e689f4b9299d28410aaaea5c7&elqCampaignId=1328 Legal http://www.level3.com/en/legal/?elq=6703751e689f4b9299d28410aaaea5c7&elqCampaignId=1328 © by Level 3 Communications, LLC. All rights reserved -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From tim at bobbroadband.com Mon Nov 3 17:35:35 2014 From: tim at bobbroadband.com (Huffman, Timothy) Date: Mon, 3 Nov 2014 17:35:35 +0000 Subject: ISP Performance Metrics and Performance Measurement tools In-Reply-To: References: Message-ID: <403E423F9B5CB4499965EDE05C50BF1DA72F1B@CWWAPP471.windstream.com> We use Cacti (http://www.cacti.net/) and Intermapper (http://www.helpsystems.com/intermapper). Smokeping is pretty common, too. -- Tim Huffman -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joseph Okoegwale Sent: Monday, November 03, 2014 7:23 AM To: nanog at nanog.org Subject: ISP Performance Metrics and Performance Measurement tools Dear all - Kindly share commonly used metrics for benchmarking ISPs and available tools (preferably open source) that are used for tracking and reporting these metrics. thanks for your help and regards, Joseph From lists.nanog at monmotha.net Mon Nov 3 17:41:41 2014 From: lists.nanog at monmotha.net (Brandon Martin) Date: Mon, 03 Nov 2014 12:41:41 -0500 Subject: BGP process torture Message-ID: <5457BE55.2010505@monmotha.net> I'm attempting to help somebody re-produce a possible glitch that relies on heavily loading the BGP process on their router. Anybody know a good/pre-canned way to synthesize, preferably with some knobs to control behavior, a couple of full-table edge-like session in terms of number of routes as well as amount of churn? -- Brandon Martin From chip.gwyn at gmail.com Mon Nov 3 17:47:52 2014 From: chip.gwyn at gmail.com (chip) Date: Mon, 3 Nov 2014 12:47:52 -0500 Subject: BGP process torture In-Reply-To: <5457BE55.2010505@monmotha.net> References: <5457BE55.2010505@monmotha.net> Message-ID: Exabgp should be able to help you out here. Great for doing fun things with BGP. https://github.com/Exa-Networks/exabgp --chip On Mon, Nov 3, 2014 at 12:41 PM, Brandon Martin wrote: > I'm attempting to help somebody re-produce a possible glitch that relies > on heavily loading the BGP process on their router. Anybody know a > good/pre-canned way to synthesize, preferably with some knobs to control > behavior, a couple of full-table edge-like session in terms of number of > routes as well as amount of churn? > > -- > Brandon Martin > -- Just my $.02, your mileage may vary, batteries not included, etc.... From g.tyson at qmul.ac.uk Mon Nov 3 09:31:15 2014 From: g.tyson at qmul.ac.uk (Gareth Tyson) Date: Mon, 3 Nov 2014 09:31:15 +0000 Subject: Smart Data Pricing Questionnaire Message-ID: <1415007076709.92628@qmul.ac.uk> Hi everybody, We're doing some research into the use of smart data pricing for enabling cheaper Internet access for the millions in the world who remain disconnected. We basically wish to understand which pricing models for data would be most attractive to network operators, as well as the challenges that might come with them. If you have a spare 10 minutes, it would be great if you could fill out the following questionnaire: https://docs.google.com/forms/d/1B-Vtl3mYJ2TJMWiFXxHySMrKSqxrhy0EzVNDlXKhPew/viewform Many thanks! Best regards, Gareth. --- Dr. Gareth Tyson, CS 404 (Not Found), Electronic Engineering and Computer Science, Queen Mary University of London. From alex.deljen at gmail.com Mon Nov 3 13:50:06 2014 From: alex.deljen at gmail.com (Alex Deljen) Date: Mon, 3 Nov 2014 08:50:06 -0500 Subject: Now Hiring: Network Engineers at KINBER to work on PennREN Message-ID: The folks at KINBER are looking for network engineers to work on PennREN. Pennsylvania's Research and Education network. Please see the url above for job description. Big network in PA that connects the major higher-eds and others. Cheers. http://goo.gl/nK6W27 www.kinber.org From prdpvaghela at gmail.com Mon Nov 3 14:15:10 2014 From: prdpvaghela at gmail.com (pradip vaghela) Date: Mon, 3 Nov 2014 19:45:10 +0530 Subject: ISP Performance Metrics and Performance Measurement tools In-Reply-To: References: Message-ID: Hi, Usually below metrics are used to benchmark any SP. 1. Availability 2. Latency 3. Jitters Open tools used to measure above matrics are mrtg or cacti (not sure about jitter) Regards Pradip On 3 Nov 2014 18:55, "Joseph Okoegwale" wrote: > Dear all - > > Kindly share commonly used metrics for benchmarking ISPs and available > tools (preferably open source) that are used for tracking and reporting > these metrics. > > thanks for your help and regards, > > Joseph > From paigeadele at gmail.com Mon Nov 3 21:15:15 2014 From: paigeadele at gmail.com (Paige Thompson) Date: Mon, 03 Nov 2014 21:15:15 +0000 Subject: Learning about the internet Message-ID: <5457F063.8040704@gmail.com> Hi, I was just reading about transatlantic cabling in some hopes that I would be able to find an answer as to why the latency between here in greece and Los Angeles is roughly ~250ms. This seems to be a really common thing, although I'd like to understand why and the articles on transatlantic cabling as near as I can tell indicate that I am getting screwed if anything (not enough information?) (from Los Angeles to my house) Konsole output Konsole output gw~ #mtr --report-wide xxxxxxxxxxxxxxx.access.hol.gr Start: Mon Nov 3 13:04:02 2014 HOST: gw Loss% Snt Last Avg Best Wrst StDev 1.|-- 208.79.92.65 10.0% 10 1.5 3.6 1.2 15.5 4.6 2.|-- s7.lax.arpnetworks.com 0.0% 10 0.8 10.9 0.8 54.2 20.7 3.|-- vlan953.car2.LosAngeles1.Level3.net 30.0% 10 10.5 10.3 10.1 10.8 0.0 4.|-- ae-27-27.edge6.LosAngeles1.Level3.net 30.0% 10 21.8 16.2 8.6 47.6 14.7 5.|-- ae-4-90.edge1.LosAngeles6.Level3.net 80.0% 10 9.0 8.9 8.7 9.0 0.0 6.|-- be3036.ccr21.lax04.atlas.cogentco.com 10.0% 10 1.7 2.1 1.4 4.3 0.7 7.|-- be2076.mpd22.lax01.atlas.cogentco.com 10.0% 10 1.6 1.9 1.6 3.2 0.0 8.|-- be2068.ccr22.iah01.atlas.cogentco.com 0.0% 10 37.7 37.7 37.3 39.0 0.3 9.|-- be2173.ccr42.atl01.atlas.cogentco.com 0.0% 10 51.6 52.4 51.5 57.5 1.7 10.|-- be2171.mpd22.dca01.atlas.cogentco.com 0.0% 10 62.6 62.7 62.4 63.3 0.0 11.|-- be2112.ccr41.iad02.atlas.cogentco.com 0.0% 10 155.5 155.8 155.5 156.1 0.0 12.|-- be2268.ccr42.par01.atlas.cogentco.com 0.0% 10 152.6 152.7 152.5 153.5 0.0 13.|-- be2278.ccr42.fra03.atlas.cogentco.com 0.0% 10 155.3 155.4 155.1 155.5 0.0 14.|-- be2229.ccr22.muc01.atlas.cogentco.com 0.0% 10 161.2 161.1 160.9 161.3 0.0 15.|-- be2223.ccr21.vie01.atlas.cogentco.com 0.0% 10 164.9 165.1 164.9 165.2 0.0 16.|-- be2046.ccr21.sof02.atlas.cogentco.com 0.0% 10 189.5 189.4 189.3 189.9 0.0 17.|-- be2118.rcr11.ath01.atlas.cogentco.com 0.0% 10 197.5 197.6 197.4 197.7 0.0 18.|-- 149.11.120.38 0.0% 10 202.7 202.2 200.3 204.2 1.4 19.|-- 62.38.97.113 80.0% 10 208.5 209.8 208.5 211.1 1.7 20.|-- gigaeth04-13.krs00.ar.hol.gr 60.0% 10 211.3 213.0 211.2 218.2 3.4 21.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 22.|-- xxxxxxxxxxxxxxxx.access.hol.gr 40.0% 10 231.3 231.4 231.2 231.7 0.0 gw~ # And to be more clear: I am hoping to learn about the complex trials that these packets are going through and how time is being lost if the latency across the transatlantic cable is really capable of less the 60ms of latency? Sure over capacity (3.2Tbits/s wow jeez) is one answer, but what are some other possibilities for loss of time? Also it seems with my VPN (OpenVPN) tunnel I get the most reliable connection (fewest drops) with: Konsole output mssfix 576 fragment 576 Although this could be a false positive as it only *seems* to help with reliability since I changed it. Even then but less often than before I still experience drops but I want to believe that's possibly due to my ISP at that point.. but assuming my ISP was absolutely perfect and never a problem what else there to consider? Any and all insight is appreciated. -Paige From joelja at bogus.com Mon Nov 3 21:57:22 2014 From: joelja at bogus.com (joel jaeggli) Date: Mon, 03 Nov 2014 13:57:22 -0800 Subject: Learning about the internet In-Reply-To: <5457F063.8040704@gmail.com> References: <5457F063.8040704@gmail.com> Message-ID: <5457FA42.6040900@bogus.com> looks about right in the neighborhood of 9k miles... from lax or therebouts. Upstream Intf Nexthop Sent Loss Min Avg Max Dev cogent x x 10 0.0% 194.814 210.255 240.989 16.518 comcast x x 10 0.0% 201.723 213.942 239.47 13.205 l3 x x 10 0.0% 195.51 208.189 226.971 10.455 telia x x 10 0.0% 194.552 207.392 225.792 10.321 On 11/3/14 1:15 PM, Paige Thompson wrote: > Hi, > > I was just reading about transatlantic cabling in some hopes that I > would be able to find an answer as to why the latency between here in > greece and Los Angeles is roughly ~250ms. This seems to be a really > common thing, although I'd like to understand why and the articles on > transatlantic cabling as near as I can tell indicate that I am getting > screwed if anything (not enough information?) > > (from Los Angeles to my house) > Konsole output > > Konsole output > gw~ #mtr --report-wide xxxxxxxxxxxxxxx.access.hol.gr > Start: Mon Nov 3 13:04:02 2014 > HOST: gw Loss% Snt Last Avg > Best Wrst StDev > 1.|-- 208.79.92.65 10.0% 10 1.5 3.6 > 1.2 15.5 4.6 > 2.|-- s7.lax.arpnetworks.com 0.0% 10 0.8 10.9 > 0.8 54.2 20.7 > 3.|-- vlan953.car2.LosAngeles1.Level3.net 30.0% 10 10.5 10.3 > 10.1 10.8 0.0 > 4.|-- ae-27-27.edge6.LosAngeles1.Level3.net 30.0% 10 21.8 16.2 > 8.6 47.6 14.7 > 5.|-- ae-4-90.edge1.LosAngeles6.Level3.net 80.0% 10 9.0 8.9 > 8.7 9.0 0.0 > 6.|-- be3036.ccr21.lax04.atlas.cogentco.com 10.0% 10 1.7 2.1 > 1.4 4.3 0.7 > 7.|-- be2076.mpd22.lax01.atlas.cogentco.com 10.0% 10 1.6 1.9 > 1.6 3.2 0.0 > 8.|-- be2068.ccr22.iah01.atlas.cogentco.com 0.0% 10 37.7 37.7 > 37.3 39.0 0.3 > 9.|-- be2173.ccr42.atl01.atlas.cogentco.com 0.0% 10 51.6 52.4 > 51.5 57.5 1.7 > 10.|-- be2171.mpd22.dca01.atlas.cogentco.com 0.0% 10 62.6 62.7 > 62.4 63.3 0.0 > 11.|-- be2112.ccr41.iad02.atlas.cogentco.com 0.0% 10 155.5 155.8 > 155.5 156.1 0.0 > 12.|-- be2268.ccr42.par01.atlas.cogentco.com 0.0% 10 152.6 152.7 > 152.5 153.5 0.0 > 13.|-- be2278.ccr42.fra03.atlas.cogentco.com 0.0% 10 155.3 155.4 > 155.1 155.5 0.0 > 14.|-- be2229.ccr22.muc01.atlas.cogentco.com 0.0% 10 161.2 161.1 > 160.9 161.3 0.0 > 15.|-- be2223.ccr21.vie01.atlas.cogentco.com 0.0% 10 164.9 165.1 > 164.9 165.2 0.0 > 16.|-- be2046.ccr21.sof02.atlas.cogentco.com 0.0% 10 189.5 189.4 > 189.3 189.9 0.0 > 17.|-- be2118.rcr11.ath01.atlas.cogentco.com 0.0% 10 197.5 197.6 > 197.4 197.7 0.0 > 18.|-- 149.11.120.38 0.0% 10 202.7 202.2 > 200.3 204.2 1.4 > 19.|-- 62.38.97.113 80.0% 10 208.5 209.8 > 208.5 211.1 1.7 > 20.|-- gigaeth04-13.krs00.ar.hol.gr 60.0% 10 211.3 213.0 > 211.2 218.2 3.4 > 21.|-- ??? 100.0 10 0.0 0.0 > 0.0 0.0 0.0 > 22.|-- xxxxxxxxxxxxxxxx.access.hol.gr 40.0% 10 231.3 231.4 > 231.2 231.7 0.0 > gw~ # > > > > And to be more clear: I am hoping to learn about the complex trials that > these packets are going through and how time is being lost if the > latency across the transatlantic cable is really capable of less the > 60ms of latency? Sure over capacity (3.2Tbits/s wow jeez) is one answer, > but what are some other possibilities for loss of time? > > Also it seems with my VPN (OpenVPN) tunnel I get the most reliable > connection (fewest drops) with: > > Konsole output > mssfix 576 > fragment 576 > > Although this could be a false positive as it only *seems* to help with > reliability since I changed it. Even then but less often than before I > still experience drops but I want to believe that's possibly due to my > ISP at that point.. but assuming my ISP was absolutely perfect and never > a problem what else there to consider? > > Any and all insight is appreciated. > > -Paige > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From bill at herrin.us Mon Nov 3 22:14:45 2014 From: bill at herrin.us (William Herrin) Date: Mon, 3 Nov 2014 17:14:45 -0500 Subject: Learning about the internet In-Reply-To: <5457F063.8040704@gmail.com> References: <5457F063.8040704@gmail.com> Message-ID: On Mon, Nov 3, 2014 at 4:15 PM, Paige Thompson wrote: > I > would be able to find an answer as to why the latency between here in > greece and Los Angeles is roughly ~250ms. > 10.|-- be2171.mpd22.dca01.atlas.cogentco.com 0.0% 10 62.6 62.7 > 62.4 63.3 0.0 > 11.|-- be2112.ccr41.iad02.atlas.cogentco.com 0.0% 10 155.5 155.8 > 155.5 156.1 0.0 ^^ There's the largest part part of your answer. IAD and DCA are both Northern VA airports; there should be perhaps 4ms of latency between these locations. A more smug answer is, "Cogent." Google "cogent congestion," "Cogent peering," and similar search terms. Other parts of the answer include: 1. The routers are mostly doing store and forward which means each must receive your entire packet before it can forward it onward to the next router. This will take more or less time depending on the link speed. 2. There are layer 2 devices doing the same thing in between some of the routers. Layer 2 is invisible to the layer 3 traceroute. There may also be MPLS systems in there with the same impact. 3. Greece and LA are more than 11,000 km apart as the crow flies. This means round-trip packets travel something like 25,000 km. There is some signal propagation delay involved. U.S. East Coast to Hawaii (about 80% of that distance) is typically 120 ms. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From DMelancon at venyu.com Mon Nov 3 22:25:29 2014 From: DMelancon at venyu.com (Dustin Melancon) Date: Mon, 3 Nov 2014 22:25:29 +0000 Subject: Learning about the internet In-Reply-To: <5457F063.8040704@gmail.com> References: <5457F063.8040704@gmail.com> Message-ID: Hey Paige, That¹s going to be extremely common when traversing transatlantic cable. Hopefully I can help explain. Most of your latency comes from simple speed of light limitations through optical fiber (~35% slower than vacuum) combined with the fact that the fiber must take a somewhat indirect path to your destination. Additionally, a small percentage of latency will be added for all of the switching/routing/regeneration nodes that must convert the fiber signals from optical back to electrical (for processing / regeneration) then back to optical. In your case, your packets are taking the following path: Los Angeles (Arp Networks to Level3 to Cogent) -> Houston -> Atlanta -> Washington DC -> Paris -> Frankfurt -> Munich -> Austria -> Bulgaria -> Athens -> Hellas Essentially it¹s taking 60ms round trip to get to DC, then another 95ms to get to Paris, plus 60ms to get to Hellas, then another 20ms to traverse the local ³last mile² access network to your destination. If you had a *direct* fiber from LAX to Hellas Greece, that would be ~22,000km of round trip fiber. Working out some simple math, that would yield approximately 110ms of round trip latency no matter how much bandwidth you have. Now, add in all of the indirect fiber paths through major cities plus all of the routing/switching hops and you can see why you¹re getting 200ms+ latency. Hope this helps! Thanks, Dustin Melancon, Sr. Network Engineer 225-214-3864 Direct ::: 866-978-3698 Toll-Free ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ VENYU : Your Data Made Invincible : www.venyu.com ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ Read our latest blog post: blog.venyu.com On 11/3/14, 3:15 PM, "Paige Thompson" wrote: >Hi, > >I was just reading about transatlantic cabling in some hopes that I >would be able to find an answer as to why the latency between here in >greece and Los Angeles is roughly ~250ms. This seems to be a really >common thing, although I'd like to understand why and the articles on >transatlantic cabling as near as I can tell indicate that I am getting >screwed if anything (not enough information?) > >(from Los Angeles to my house) >Konsole output > >Konsole output >gw~ #mtr --report-wide xxxxxxxxxxxxxxx.access.hol.gr >Start: Mon Nov 3 13:04:02 2014 >HOST: gw Loss% Snt Last Avg > Best Wrst StDev > 1.|-- 208.79.92.65 10.0% 10 1.5 3.6 > 1.2 15.5 4.6 > 2.|-- s7.lax.arpnetworks.com 0.0% 10 0.8 10.9 > 0.8 54.2 20.7 > 3.|-- vlan953.car2.LosAngeles1.Level3.net 30.0% 10 10.5 10.3 > 10.1 10.8 0.0 > 4.|-- ae-27-27.edge6.LosAngeles1.Level3.net 30.0% 10 21.8 16.2 > 8.6 47.6 14.7 > 5.|-- ae-4-90.edge1.LosAngeles6.Level3.net 80.0% 10 9.0 8.9 > 8.7 9.0 0.0 > 6.|-- be3036.ccr21.lax04.atlas.cogentco.com 10.0% 10 1.7 2.1 > 1.4 4.3 0.7 > 7.|-- be2076.mpd22.lax01.atlas.cogentco.com 10.0% 10 1.6 1.9 > 1.6 3.2 0.0 > 8.|-- be2068.ccr22.iah01.atlas.cogentco.com 0.0% 10 37.7 37.7 > 37.3 39.0 0.3 > 9.|-- be2173.ccr42.atl01.atlas.cogentco.com 0.0% 10 51.6 52.4 > 51.5 57.5 1.7 >10.|-- be2171.mpd22.dca01.atlas.cogentco.com 0.0% 10 62.6 62.7 > 62.4 63.3 0.0 >11.|-- be2112.ccr41.iad02.atlas.cogentco.com 0.0% 10 155.5 155.8 >155.5 156.1 0.0 >12.|-- be2268.ccr42.par01.atlas.cogentco.com 0.0% 10 152.6 152.7 >152.5 153.5 0.0 >13.|-- be2278.ccr42.fra03.atlas.cogentco.com 0.0% 10 155.3 155.4 >155.1 155.5 0.0 >14.|-- be2229.ccr22.muc01.atlas.cogentco.com 0.0% 10 161.2 161.1 >160.9 161.3 0.0 >15.|-- be2223.ccr21.vie01.atlas.cogentco.com 0.0% 10 164.9 165.1 >164.9 165.2 0.0 >16.|-- be2046.ccr21.sof02.atlas.cogentco.com 0.0% 10 189.5 189.4 >189.3 189.9 0.0 >17.|-- be2118.rcr11.ath01.atlas.cogentco.com 0.0% 10 197.5 197.6 >197.4 197.7 0.0 >18.|-- 149.11.120.38 0.0% 10 202.7 202.2 >200.3 204.2 1.4 >19.|-- 62.38.97.113 80.0% 10 208.5 209.8 >208.5 211.1 1.7 >20.|-- gigaeth04-13.krs00.ar.hol.gr 60.0% 10 211.3 213.0 >211.2 218.2 3.4 >21.|-- ??? 100.0 10 0.0 0.0 > 0.0 0.0 0.0 >22.|-- xxxxxxxxxxxxxxxx.access.hol.gr 40.0% 10 231.3 231.4 >231.2 231.7 0.0 >gw~ # > > > >And to be more clear: I am hoping to learn about the complex trials that >these packets are going through and how time is being lost if the >latency across the transatlantic cable is really capable of less the >60ms of latency? Sure over capacity (3.2Tbits/s wow jeez) is one answer, >but what are some other possibilities for loss of time? > >Also it seems with my VPN (OpenVPN) tunnel I get the most reliable >connection (fewest drops) with: > >Konsole output >mssfix 576 >fragment 576 > >Although this could be a false positive as it only *seems* to help with >reliability since I changed it. Even then but less often than before I >still experience drops but I want to believe that's possibly due to my >ISP at that point.. but assuming my ISP was absolutely perfect and never >a problem what else there to consider? > >Any and all insight is appreciated. > >-Paige > > From brian at aereo.com Mon Nov 3 22:33:09 2014 From: brian at aereo.com (Brian Loveland) Date: Mon, 3 Nov 2014 17:33:09 -0500 Subject: Learning about the internet In-Reply-To: References: <5457F063.8040704@gmail.com> Message-ID: Isn't this most likely a side effect of MPLS tunneling and the 93ms jump there is actually the trans-atlantic segment? All the european hops following it are very close in latency to hop 11. On Mon, Nov 3, 2014 at 5:14 PM, William Herrin wrote: > On Mon, Nov 3, 2014 at 4:15 PM, Paige Thompson > wrote: > > I > > would be able to find an answer as to why the latency between here in > > greece and Los Angeles is roughly ~250ms. > > > 10.|-- be2171.mpd22.dca01.atlas.cogentco.com 0.0% 10 62.6 62.7 > > 62.4 63.3 0.0 > > 11.|-- be2112.ccr41.iad02.atlas.cogentco.com 0.0% 10 155.5 155.8 > > 155.5 156.1 0.0 > > ^^ There's the largest part part of your answer. IAD and DCA are both > Northern VA airports; there should be perhaps 4ms of latency between these > locations. > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > May I solve your unusual networking challenges? > From DMelancon at venyu.com Mon Nov 3 22:36:29 2014 From: DMelancon at venyu.com (Dustin Melancon) Date: Mon, 3 Nov 2014 22:36:29 +0000 Subject: Learning about the internet In-Reply-To: References: <5457F063.8040704@gmail.com> Message-ID: Yeap, that's what I was typing up. More than likely what we're seeing is just the far of the link from IAD to Paris. This is evident from the fact that the next hop to Frankfurt is only an additional 3ms beyond what is reported as IAD. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brian Loveland Sent: Monday, November 3, 2014 4:33 PM To: William Herrin Cc: nanog at nanog.org Subject: Re: Learning about the internet Isn't this most likely a side effect of MPLS tunneling and the 93ms jump there is actually the trans-atlantic segment? All the european hops following it are very close in latency to hop 11. On Mon, Nov 3, 2014 at 5:14 PM, William Herrin wrote: > On Mon, Nov 3, 2014 at 4:15 PM, Paige Thompson > wrote: > > I > > would be able to find an answer as to why the latency between here > > in greece and Los Angeles is roughly ~250ms. > > > 10.|-- be2171.mpd22.dca01.atlas.cogentco.com 0.0% 10 62.6 62.7 > > 62.4 63.3 0.0 > > 11.|-- be2112.ccr41.iad02.atlas.cogentco.com 0.0% 10 155.5 155.8 > > 155.5 156.1 0.0 > > ^^ There's the largest part part of your answer. IAD and DCA are both > Northern VA airports; there should be perhaps 4ms of latency between > these locations. > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: May > I solve your unusual networking challenges? > From marka at isc.org Mon Nov 3 23:10:28 2014 From: marka at isc.org (Mark Andrews) Date: Tue, 04 Nov 2014 10:10:28 +1100 Subject: Fwd: FW: NIST NTP Server List In-Reply-To: Your message of "Mon, 03 Nov 2014 09:02:25 -0700." <5457A711.1080604@nist.gov> References: <383666204cd0477198fe6d155b8d7637@CY1PR09MB0217.namprd09.prod.outlook.com> <5457A711.1080604@nist.gov> Message-ID: <20141103231028.56503230AA94@rock.dv.isc.org> http://time.gov/HTML5/ over IPv6 is broken. % fetch -6v http://time.gov/HTML5/ looking up time.gov connecting to time.gov:80 requesting http://time.gov/HTML5/ 404 Not Found Not Found The requested URL /HTML5/ was not found on this server. fetch: http://time.gov/HTML5/: Not Found % fetch -4v http://time.gov/HTML5/ looking up time.gov connecting to time.gov:80 requesting http://time.gov/HTML5/ remote size / mtime: 10438 / 1414696016 fetch.out 100% of 10 kB 104 MBps % Mark In message <5457A711.1080604 at nist.gov>, Andrew Novick writes: > > Hello - can you tell me what this pertains to, or if I can help? > > Andrew Novick > NIST > > > -----Original Message----- > From: Mark Andrews [mailto:marka at isc.org] > Sent: Thursday, October 30, 2014 8:22 PM > To: Pete Carah > Cc: nanog at nanog.org; do-webmaster > Subject: Re: NIST NTP Server List > > > In message <5452D146.4080307 at altadena.net>, Pete Carah writes: > > On 10/30/2014 06:27 PM, Mark Andrews wrote: > > > IPv6 is production. Report the problem. > > > > > Sorry for reporting it here, but there seems to be more than one > > problem (the link resulting from clicking on "nist time". > > What does reporting a 404 to nanog do? The network to them is UP. Since the > front page is up and actually has a address for reporting web problems I wou > ld expect that you would report the problem there (I've cc'd the address). > > If the front page wasn't up you should do a whois lookup and use those contac > t details except this a .gov domain where whois is a farce. So you also need > to contact your federal representative and complain about that. > > Nist can put contact details on their web page: > > Public Inquiries Unit > NIST, 100 Bureau Drive, Stop 1070, Gaithersburg, MD 20899-1070 > Email: inquiries at nist.gov > Phone: (301) 975-NIST (6478) or Federal Relay Service (800) 877-8339 (TTY) > > But the whois give this farcical response: > > % DOTGOV WHOIS Server ready > Domain Name: NIST.GOV > Status: ACTIVE > > >>> Last update of whois database: 2014-10-31T00:16:27Z <<< > Please be advised that this whois server only contains information pertaining > to the .GOV domain. For information for other domains please use the whois s > erver at RS.INTERNIC.NET. > > > I get the nist front page fine on v6, then click on the time link and > > get a 404 looking for a strange url: > > "hxxp://time.gov/HTML5" (which could be fine but does look a little > > strange.) > > > > -- Pete > > > > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > > > --------------090806090301080104060605 > Content-Type: text/html; charset="ISO-8859-1" > Content-Transfer-Encoding: 7bit > > > > > > > > Hello - can you tell me what this pertains to, or if I can help?
>
> Andrew Novick
> NIST
>

>
> 
> -----Original Message-----
> From: Mark Andrews [mailto:marka at isc.org] 
> Sent: Thursday, October 30, 2014 8:22 PM
> To: Pete Carah
> Cc: nanog at n
> anog.org; do-webmaster
> Subject: Re: NIST NTP Server List
> 
> 
> In message <5452D146.4080307 at altadena.net>, Pete Carah writes:
> > On 10/30/2014 06:27 PM, Mark Andrews wrote:
> > > IPv6 is production.  Report the problem.
> > >
> > Sorry for reporting it here, but there seems to be more than one 
> > problem (the link resulting from clicking on "nist time".
> 
> What does reporting a 404 to nanog do?  The network to them is UP.  Since the
>  front page is up and actually has a address for reporting web problems I wou
> ld expect that you would report the problem there (I've cc'd the address).
> 
> If the front page wasn't up you should do a whois lookup and use those contac
> t details except this a .gov domain where whois is a farce.  So you also need
>  to contact your federal representative and complain about that.
> 
> Nist can put contact details on their web page:
> 
> Public Inquiries Unit
> NIST, 100 Bureau Drive, Stop 1070, Gaithersburg, MD 20899-1070
> Email: i
> nquiries at nist.gov
> Phone: (301) 975-NIST (6478) or Federal Relay Service (800) 877-8339 (TTY)
> 
> But the whois give this farcical response:
> 
> % DOTGOV WHOIS Server ready
>    Domain Name: NIST.GOV
>    Status: ACTIVE
> 
> >>> Last update of whois database: 2014-10-31T00:16:27Z <<<
> Please be advised that this whois server only contains information pertaining
>  to the .GOV domain. For information for other domains please use the whois s
> erver at RS.INTERNIC.NET.
>  
> > I get the nist front page fine on v6, then click on the time link and 
> > get a 404 looking for a strange url:
> > "hxxp://time.gov/HTML5" (which could be fine but does look a little
> > strange.)
> > 
> > -- Pete
> > 
> > 
> > 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> 
>
>
>
>
> > > > --------------090806090301080104060605-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From plucena at coopergeneral.com Tue Nov 4 02:12:43 2014 From: plucena at coopergeneral.com (Pablo Lucena) Date: Mon, 3 Nov 2014 21:12:43 -0500 Subject: BGP process torture In-Reply-To: References: <5457BE55.2010505@monmotha.net> Message-ID: Cisco's Pagent (a modified IOS image with numerous testing capabilities) can also be used to do this. *Pablo Lucena* On Mon, Nov 3, 2014 at 12:47 PM, chip wrote: > Exabgp should be able to help you out here. Great for doing fun things > with BGP. > > https://github.com/Exa-Networks/exabgp > > --chip > > On Mon, Nov 3, 2014 at 12:41 PM, Brandon Martin > wrote: > > > I'm attempting to help somebody re-produce a possible glitch that relies > > on heavily loading the BGP process on their router. Anybody know a > > good/pre-canned way to synthesize, preferably with some knobs to control > > behavior, a couple of full-table edge-like session in terms of number of > > routes as well as amount of churn? > > > > -- > > Brandon Martin > > > > > > -- > Just my $.02, your mileage may vary, batteries not included, etc.... > From larrysheldon at cox.net Tue Nov 4 02:42:41 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 03 Nov 2014 20:42:41 -0600 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: <54583D21.60409@cox.net> On 11/2/2014 11:02, Colton Conor wrote: > We have a couple of techs that want to learn cisco and networking in > general. What do you recommend for learning and getting certified on Cisco? > There seems to be a million different training courses, books, etc out > there. > My personal opinion, worth what you paid for it: For learning--work beside an Old Hand that knows it and has a good record. For certification, sign up for the cheapest one. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From listas at esds.com.br Tue Nov 4 03:03:07 2014 From: listas at esds.com.br (Eduardo Schoedler) Date: Tue, 4 Nov 2014 01:03:07 -0200 Subject: BGP process torture In-Reply-To: <5457BE55.2010505@monmotha.net> References: <5457BE55.2010505@monmotha.net> Message-ID: Have you tried exabgp? -- Eduardo Schoedler 2014-11-03 15:41 GMT-02:00 Brandon Martin : > I'm attempting to help somebody re-produce a possible glitch that relies on > heavily loading the BGP process on their router. Anybody know a > good/pre-canned way to synthesize, preferably with some knobs to control > behavior, a couple of full-table edge-like session in terms of number of > routes as well as amount of churn? > > -- > Brandon Martin -- Eduardo Schoedler From amlweems at gmail.com Tue Nov 4 03:57:50 2014 From: amlweems at gmail.com (Anthony Weems) Date: Mon, 3 Nov 2014 21:57:50 -0600 Subject: BGP Security Research Question Message-ID: I'm a student in college learning about networking and, specifically, BGP. Does anyone have any statistics on the use of S-BGP or soBGP in the wild? I've read a few papers / RFCs on the subject (from Cisco and the like), but I haven't been able to find any information about actual usage. Additionally, do people scan BGP speakers in the same sense that researchers perform scans of the Internet (e.g. zmap)? -- Anthony Weems From rdobbins at arbor.net Tue Nov 4 11:02:47 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 04 Nov 2014 18:02:47 +0700 Subject: BGP Security Research Question In-Reply-To: References: Message-ID: <27B373CC-D215-4729-9E2D-C97E123124B4@arbor.net> On 4 Nov 2014, at 10:57, Anthony Weems wrote: > I'm a student in college learning about networking and, specifically, > BGP. > Does anyone have any statistics on the use of S-BGP or soBGP in the > wild? Take a look at rPKI. > Additionally, do people scan BGP speakers in the same sense that > researchers perform scans of the Internet (e.g. zmap)? Everything on the Internet is scanned (or, at least attempts to scan everything on the Internet are made), constantly. If network operators have configured their BGP speakers properly, with BCPs such as iACLs and GTSM, then they can't be touched by anything except configured peers. TCP/179 scanning of BGP speakers which haven't implemented the BCPs isn't generally going to return much in the way of useful results beyond identifying the BGP speakers themselves, as the scanners aren't configured as peers (it may be possible to fingerprint some BGP speakers via scanning a la nmap or zmap or masscan, perhaps someone else can comment on this). That being said, attackers will scan routers that they're interested in DDoSing or subverting; implementing the relevant BCPs is strongly recommended. Networks which haven't implemented the BCPs sometimes find their BGP peering sessions disrupted via DDoS attacks against the routers themselves; SYN-floods and the like against TCP/179 are sometimes used to disrupt BGP sessions in such scenarios, for example. Aggressive scanning per the above against BGP speakers which haven't implemented the BCPs could result in inadvertent disruption of BGP sessions. ----------------------------------- Roland Dobbins From yuri at yurisk.info Tue Nov 4 12:06:35 2014 From: yuri at yurisk.info (Yuri Slobodyanyuk) Date: Tue, 4 Nov 2014 14:06:35 +0200 Subject: BGP Security Research Question In-Reply-To: References: Message-ID: Having seen few hundreds BGP peerings with internal clients as well as with uplink providers cannot recall anyone ever even trying to use such features. And given that both were created back in late 90s early 2000s we can safely assume these technologies (S-BGP/soBGP) will stay just that - blue-sky academic research (but who can tell the future on the other hand ...) In real life people use - bgp ttl security, md5 passwords, control plane protection of 179 port, inbound/outbound routes filters. So far this has been enough. On Tue, Nov 4, 2014 at 5:57 AM, Anthony Weems wrote: > I'm a student in college learning about networking and, specifically, BGP. > Does anyone have any statistics on the use of S-BGP or soBGP in the wild? > I've read a few papers / RFCs on the subject (from Cisco and the like), but > I haven't been able to find any information about actual usage. > > Additionally, do people scan BGP speakers in the same sense that > researchers perform scans of the Internet (e.g. zmap)? > > -- > Anthony Weems > -- Taking challenges one by one. http://yurisk.info From sthaug at nethelp.no Tue Nov 4 12:38:14 2014 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 04 Nov 2014 13:38:14 +0100 (CET) Subject: BGP Security Research Question In-Reply-To: References: Message-ID: <20141104.133814.74685217.sthaug@nethelp.no> > In real life people use - bgp ttl security, md5 passwords, control plane > protection of 179 port, inbound/outbound routes filters. So far this has > been enough. These mechanisms do little or nothing to protect against unauthorized origination of routing information. There are plenty of examples which say it has *not* been enough, see for instance the Pakistan Telecom - Youtube incident in 2008. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From nick at foobar.org Tue Nov 4 13:00:45 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 04 Nov 2014 13:00:45 +0000 Subject: BGP Security Research Question In-Reply-To: <20141104.133814.74685217.sthaug@nethelp.no> References: <20141104.133814.74685217.sthaug@nethelp.no> Message-ID: <5458CDFD.90708@foobar.org> On 04/11/2014 12:38, sthaug at nethelp.no wrote: > These mechanisms do little or nothing to protect against unauthorized > origination of routing information. There are plenty of examples which > say it has *not* been enough, see for instance the Pakistan Telecom - > Youtube incident in 2008. mis-origination and related problems are all policy problems rather than technical transport issues. Policy implies human input at some stage along the chain, so probably the only way we'll ever see the end of unintended prefix leaks is to completely eliminate human input in all aspects of routing policy management. Nick From sandy at tislabs.com Tue Nov 4 13:34:52 2014 From: sandy at tislabs.com (Sandra Murphy) Date: Tue, 4 Nov 2014 08:34:52 -0500 Subject: BGP Security Research Question In-Reply-To: <5458CDFD.90708@foobar.org> References: <20141104.133814.74685217.sthaug@nethelp.no> <5458CDFD.90708@foobar.org> Message-ID: On Nov 4, 2014, at 8:00 AM, Nick Hilliard wrote: > On 04/11/2014 12:38, sthaug at nethelp.no wrote: >> These mechanisms do little or nothing to protect against unauthorized >> origination of routing information. There are plenty of examples which >> say it has *not* been enough, see for instance the Pakistan Telecom - >> Youtube incident in 2008. > > mis-origination and related problems are all policy problems rather than > technical transport issues. Policy implies human input at some stage along > the chain, so probably the only way we'll ever see the end of unintended > prefix leaks is to completely eliminate human input in all aspects of > routing policy management. > > Nick I see a distinction between policy and authorization. Policy is something the ISP decides for themselves - "I make my own routing policy as to what is my best path". BGP was created to make it possible for operators to have that policy decision. Authorization is something else. Prefix holders want to say "I authorize the origination of this prefix". Operators can decide to enforce that authorization in their policy or not, but at least the prefix holder gets to make the determination of what is authorized. (See IRR route objects, RPKI ROAs) There are those who call route leaks an authorization problem. [[[I think.]]]] They want to be able to say "I authorize my neighbor to propagate this announcement with the following constraints (no peers, no transit, customers only, etc)." [[[I think.]]] Again, operators could decide to enforce that authorization in their policy or not, but those wanting to stop route leaks want to make the determination of what is authorized. Policy is local. Authorization is global. (And so it relies on global access to a statement of the authorization, aye, there's the rub.) --Sandy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Patrick.Darden at p66.com Tue Nov 4 13:35:31 2014 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Tue, 4 Nov 2014 07:35:31 -0600 Subject: BGP Security Research Question In-Reply-To: References: Message-ID: I don't think anyone uses S-BGB or soBGP in the wild--except on Internet2 (debatable whether I2 is in the wild). Mostly just labs and classrooms...? We get zmap/nmap/xmap scans on our BGP speakers constantly. However, most people do a tight lockdown on anything internet-exposed, limiting useful information for most speakers to whatever their prime function is (routing, gathering, reflecting, etc.) --Patrick Darden -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Anthony Weems Sent: Monday, November 03, 2014 9:58 PM To: NANOG Subject: [EXTERNAL]BGP Security Research Question I'm a student in college learning about networking and, specifically, BGP. Does anyone have any statistics on the use of S-BGP or soBGP in the wild? I've read a few papers / RFCs on the subject (from Cisco and the like), but I haven't been able to find any information about actual usage. Additionally, do people scan BGP speakers in the same sense that researchers perform scans of the Internet (e.g. zmap)? -- Anthony Weems From yuri at yurisk.info Tue Nov 4 13:45:40 2014 From: yuri at yurisk.info (Yuri Slobodyanyuk) Date: Tue, 4 Nov 2014 15:45:40 +0200 Subject: BGP Security Research Question In-Reply-To: <20141104.133814.74685217.sthaug@nethelp.no> References: <20141104.133814.74685217.sthaug@nethelp.no> Message-ID: Let me disagree - Pakistan Youtube was possible only because their uplink provider did NOT implement inbound route filters . As always the weakest link is human factor - and no super-duper newest technology is ever to help here . As regards to S-bgp/soBGP from technical point of view , wait for the day when the vulnerability gets published (SSL-heartbleed style) that invalidates all this PKI stuff ... Yuri On Tue, Nov 4, 2014 at 2:38 PM, wrote: > > In real life people use - bgp ttl security, md5 passwords, control plane > > protection of 179 port, inbound/outbound routes filters. So far this has > > been enough. > > These mechanisms do little or nothing to protect against unauthorized > origination of routing information. There are plenty of examples which > say it has *not* been enough, see for instance the Pakistan Telecom - > Youtube incident in 2008. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > -- Taking challenges one by one. http://yurisk.info From russw at riw.us Tue Nov 4 13:53:27 2014 From: russw at riw.us (Russ White) Date: Tue, 4 Nov 2014 08:53:27 -0500 Subject: BGP Security Research Question In-Reply-To: References: <20141104.133814.74685217.sthaug@nethelp.no> <5458CDFD.90708@foobar.org> Message-ID: <021b01cff836$b62b30c0$22819240$@riw.us> > Authorization is global. (And so it relies on global access to a statement of > the authorization, aye, there's the rub.) The real rub is -- What are you authorizing? Or perhaps -- what can you actually authorize in BGP, or any other routing protocol? This is the question that (as of yet) hasn't even been asked, from what I can see. Russ From sandy at tislabs.com Tue Nov 4 13:54:58 2014 From: sandy at tislabs.com (Sandra Murphy) Date: Tue, 4 Nov 2014 08:54:58 -0500 Subject: BGP Security Research Question In-Reply-To: References: <20141104.133814.74685217.sthaug@nethelp.no> Message-ID: On Nov 4, 2014, at 8:45 AM, Yuri Slobodyanyuk wrote: > Let me disagree - Pakistan Youtube was possible only because their uplink > provider did NOT implement inbound route filters . As always the weakest > link is human factor - and no super-duper newest technology is ever to help > here . One problem with route filters is that the protection relies on the place closest to the problem to detect the leak. Further on in the network, not as effective. > As regards to S-bgp/soBGP from technical point of view , wait for the day > when the vulnerability gets published (SSL-heartbleed style) that > invalidates all this PKI stuff … Or the IRRs on which the route filters are built. (No need for publication of a vulnerability. See recent msgs about already known problems with IRRs.) --Sandy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sthaug at nethelp.no Tue Nov 4 14:03:00 2014 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 04 Nov 2014 15:03:00 +0100 (CET) Subject: BGP Security Research Question In-Reply-To: References: <20141104.133814.74685217.sthaug@nethelp.no> Message-ID: <20141104.150300.41698041.sthaug@nethelp.no> > Let me disagree - Pakistan Youtube was possible only because their uplink > provider did NOT implement inbound route filters . As always the weakest > link is human factor - and no super-duper newest technology is ever to help > here . Agreed, the uplink absolutely should have implemented prefix filtering. However, if the Youtube prefixes had been protected with RPKI, ISPs far away could have verified the announcements themselves - and would have found that the Pakistan Telecom originated prefixes were invalid (and would presumably have found the original Youtube prefixes to be valid). As least that's how I understand RPKI. I want *both* prefix filtering and a system like RPKI. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From alex.buie at frozenfeline.net Tue Nov 4 14:08:38 2014 From: alex.buie at frozenfeline.net (Alex Buie) Date: Tue, 4 Nov 2014 09:08:38 -0500 Subject: Cisco CCNA Training In-Reply-To: <54583D21.60409@cox.net> References: <54583D21.60409@cox.net> Message-ID: On Mon, Nov 3, 2014 at 9:42 PM, Larry Sheldon wrote: > For learning--work beside an Old Hand that knows it and has a good record. Speaking of that, I've been wondering for a while if there are ever network engineer "apprenticeships," so to speak, or if you guys knew of any people or companies who do things like that. Based on my observations, the flat "knowledge" of everything will take you only so far; there's a lot of tips, tricks, non-conforming platform behavior/bugs and "unwritten rules"/"best practices" that really only come with the time of being a net admin. I was envisioning something like the electrician or plumber-type things where you learn the technique from a master artisan of the craft. It seems like a job where the best training *is* that hands on where you get to see all the big/fun equipment and learn from production decisions that were made, strange hardware/configuration problems, etc, but I'd never really seen anyone/company who does these types of things, and I'd really like to get more experience in the field. (everybody I look for that wants a network engineer wants a network engineer, with experience already) Finally, just more of a general question, what else would you recommend to someone who wants to get into the network engineer/operations roles? This could be anything, from books to classes, to whatever. I do already have my CCNA and A+ from while in high school, (my networking I-IV prof was adjunct at the local CC, so we could dual enroll in the local CC and get them to pay for our cert tests :D) and most of a bachelors in Networking and Systems Administration from RIT that I'll be finishing up over the next little bit. I also love radio (K2FUR! :)), so something with cellular really fascinates me, although any sort of networking/ops/disaster recovery really is my passion. Anyway, thanks for your time and potential suggestions! Alex From Valdis.Kletnieks at vt.edu Tue Nov 4 17:17:21 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 04 Nov 2014 12:17:21 -0500 Subject: BGP Security Research Question In-Reply-To: Your message of "Tue, 04 Nov 2014 18:02:47 +0700." <27B373CC-D215-4729-9E2D-C97E123124B4@arbor.net> References: <27B373CC-D215-4729-9E2D-C97E123124B4@arbor.net> Message-ID: <5269.1415121441@turing-police.cc.vt.edu> On Tue, 04 Nov 2014 18:02:47 +0700, "Roland Dobbins" said: > Networks which haven't implemented the BCPs sometimes find their BGP > peering sessions disrupted via DDoS attacks against the routers > themselves; SYN-floods and the like against TCP/179 are sometimes used > to disrupt BGP sessions in such scenarios, for example. Aggressive > scanning per the above against BGP speakers which haven't implemented > the BCPs could result in inadvertent disruption of BGP sessions. Am I the only guy wondering how many boxes out there are *still* vulnerable to forged RST packets? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From rdobbins at arbor.net Tue Nov 4 17:21:09 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 05 Nov 2014 00:21:09 +0700 Subject: BGP Security Research Question In-Reply-To: <5269.1415121441@turing-police.cc.vt.edu> References: <27B373CC-D215-4729-9E2D-C97E123124B4@arbor.net> <5269.1415121441@turing-police.cc.vt.edu> Message-ID: <9185F745-6C5D-4A8D-98A8-DDA62AEF4CDA@arbor.net> On 5 Nov 2014, at 0:17, Valdis.Kletnieks at vt.edu wrote: > Am I the only guy wondering how many boxes out there are *still* > vulnerable to forged RST packets? That's covered by ' . . . and the like . . . ' ;> ----------------------------------- Roland Dobbins From berry at gadsdenst.org Tue Nov 4 17:47:21 2014 From: berry at gadsdenst.org (Berry Mobley) Date: Tue, 04 Nov 2014 12:47:21 -0500 Subject: Default routes on BGP routers with full feeds Message-ID: I'm wondering how many of you who are multihomed also add default routes pointing to your providers from whom you are receiving full feeds. If so, why? If not, why not? Thanks, Berry From lou.ashtonhurst at gmail.com Tue Nov 4 14:51:07 2014 From: lou.ashtonhurst at gmail.com (Lou Ashtonhurst) Date: Tue, 4 Nov 2014 14:51:07 +0000 Subject: Cisco CCNA Training In-Reply-To: References: <54583D21.60409@cox.net> Message-ID: If you're not too bothered about vendor specific, I'd recommend the following coursera course: https://www.coursera.org/course/comnetworks On 4 November 2014 14:08, Alex Buie wrote: > On Mon, Nov 3, 2014 at 9:42 PM, Larry Sheldon > wrote: > > > For learning--work beside an Old Hand that knows it and has a good > record. > > Speaking of that, I've been wondering for a while if there are ever > network engineer "apprenticeships," so to speak, or if you guys knew > of any people or companies who do things like that. Based on my > observations, the flat "knowledge" of everything will take you only so > far; there's a lot of tips, tricks, non-conforming platform > behavior/bugs and "unwritten rules"/"best practices" that really only > come with the time of being a net admin. I was envisioning something > like the electrician or plumber-type things where you learn the > technique from a master artisan of the craft. > > > It seems like a job where the best training *is* that hands on where > you get to see all the big/fun equipment and learn from production > decisions that were made, strange hardware/configuration problems, > etc, but I'd never really seen anyone/company who does these types of > things, and I'd really like to get more experience in the field. > (everybody I look for that wants a network engineer wants a network > engineer, with experience already) > > Finally, just more of a general question, what else would you > recommend to someone who wants to get into the network > engineer/operations roles? This could be anything, from books to > classes, to whatever. I do already have my CCNA and A+ from while in > high school, (my networking I-IV prof was adjunct at the local CC, so > we could dual enroll in the local CC and get them to pay for our cert > tests :D) and most of a bachelors in Networking and Systems > Administration from RIT that I'll be finishing up over the next little > bit. I also love radio (K2FUR! :)), so something with cellular really > fascinates me, although any sort of networking/ops/disaster recovery > really is my passion. > > > Anyway, thanks for your time and potential suggestions! > > Alex > From evan.fox at empire.ca Tue Nov 4 17:18:08 2014 From: evan.fox at empire.ca (Evan Fox) Date: Tue, 4 Nov 2014 12:18:08 -0500 Subject: WestJet, Expedia or SoftVoyage Contacts Message-ID: Could someone from WestJet, Expedia, or SoftVoyage please contact me off list regarding a backend problem? Thanks, Evan The content of this message is subject to our e-mail confidentiality policy. http://www.empire.ca/docs/email/conf Le contenu de ce message est assujetti à notre politique en matière de confidentialité des courriels. http://www.empire.ca/docs/email/conf From Peter.teStrake at tradingscreen.com Tue Nov 4 17:55:28 2014 From: Peter.teStrake at tradingscreen.com (Peter teStrake) Date: Tue, 4 Nov 2014 17:55:28 +0000 Subject: Tail-F In-Reply-To: References: , Message-ID: <8C5ED6AE-9351-4BBE-805F-C6B6005DDA33@tradingscreen.com> Conor, Tail-f will give you a global view of your network configurations, and will keep the local database in sync with the devices. This gives you the ability to search and update config across devices. If you want to see the live status, then you can compile an snmp mib and attach that to the device, so your team can see both config and status via a single CLI. Really though, it's about service provisioning and orchestration across multiple vendors, but there can be a fair amount of work there depending on what you are trying to achieve. There is a also a REST interface that makes it pretty simple to access anything in the database and present it in a web page. Cheers Pete Sent from my iPhone > On 2 Nov 2014, at 23:58, Colton Conor wrote: > > I am aware that you can see if a port is up or down through SNMP. I guess > that was a bad example. I want to see the entire output of a show interface > command. For example, we have multiple types of access networks (GPON, DSL, > Cisco ethernet switches). Some of the show interface commands are fairly > basic, but others like on a DSL port show much more information like sync > rate, signal loss, etc. The only way to get this information on some > platforms is to run the show interface command for CLI I believe, or login > to the access platform's GUI interface. Both of these task aren't so easy > when you are dealing with multiple access platforms. > > >> On Sun, Nov 2, 2014 at 3:15 PM, Phil Bedard wrote: >> >> Tail-F's ConfD can operate as a front-end CLI and do the things he wants >> it to do in an operational sense but I would agree it may not be the >> easiest to use tool for simply monitoring and grabbing interface >> state/statistics. It's fairly flexible and can do a lot of abstracted >> things through its ConfD element but there is some backend work to make it >> happen. Not as much as doing it from scratch but still a bit of work. >> It can abstract different device CLIs so they all look the same and use the >> same commands and you can extend the CLI to do custom things as well if you >> want. >> >> The whole system is fairly powerful and very extensibe. There are >> monitoring elements built into it and It could be a full blown monitoring >> system, really just depends on the scale you need and how much work you >> want to put into it. >> >> Phil >> >> >> >>> On Sun, Nov 2, 2014 at 1:19 PM, Jimmy Hess wrote: >>> >>> On Sun, Nov 2, 2014 at 11:04 AM, Colton Conor >>> wrote: >>>> Is anyone using Tail-f software or know anything similar? We are looking >>>> for a solution that is vendor agnostic. Can do simple command like show >>> >>> I've only read of this, but my understanding is the Tail-F product is >>> for configuration management and supporting provisioning automations >>> anyways, monitoring configs sure. As far as I know they cannot >>> monitor or show network operational status, so your use case may not >>> overlap with their capabilities, and perhaps, what you are likely >>> suggesting is something that unfortunately doesn't exist yet: a tool >>> for both configuring and observing a detailed operational state of the >>> network devices in a vendor-agnostic way. >>> >>> However, for simple bandwidth statistics and port Up/Down; for most >>> devices, this information is available through SNMP based management >>> tools. >>> >>> Basic Up/Down and statistics could generally be gathered by any good >>> SNMP-based NMS / network monitoring product, there are thousands of >>> these, or OSS such as Cacti, Zenoss, and proprietary ones such as HP >>> OpenView, SolarWinds, InterMapper, Whatsup; also, just about every >>> major network device vendor has their element management system. >>> >>> Various NMS can also be configured to run some selected code or offer >>> up a GUI command for running a snmpwalk against the ifOperStatus or >>> ifIn/Out Octets. >>> >>> >>> >>> >>>> interface so even non-network techs and CSR's can get basic is the port >>> up >>>> or down type stats without having to directly login to the network. >>> -- >>> -JH >> >> From blake at ispn.net Tue Nov 4 18:17:23 2014 From: blake at ispn.net (Blake Hudson) Date: Tue, 04 Nov 2014 12:17:23 -0600 Subject: Default routes on BGP routers with full feeds In-Reply-To: <20141104174736.763842D4208@mail.nanog.org> References: <20141104174736.763842D4208@mail.nanog.org> Message-ID: <54591833.9080608@ispn.net> I often opt to leave one or more default routes configured with low priority (lower than BGP). The thinking is that if there is a fault with BGP, the router will still operate and the fault can be corrected remotely (in-band). The downside is that I might pass traffic for non-existing destinations an additional hop and put the load of generating an ICMP unreachable on someone else's router. --Blake Berry Mobley wrote on 11/4/2014 11:47 AM: > I'm wondering how many of you who are multihomed also add default > routes pointing to your providers from whom you are receiving full feeds. > > If so, why? If not, why not? > > Thanks, > > Berry > From mwalter at 3z.net Tue Nov 4 18:25:35 2014 From: mwalter at 3z.net (Mike Walter) Date: Tue, 4 Nov 2014 18:25:35 +0000 Subject: Default routes on BGP routers with full feeds In-Reply-To: <20141104174736.2600B2D42A7@mail.nanog.org> References: <20141104174736.2600B2D42A7@mail.nanog.org> Message-ID: I have 5 providers and we get the default from all of them and full routing tables. I have seen cases where if there is no default route, the traffic didn't know where to go, even with full routes from all my providers. -Mike -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Berry Mobley Sent: Tuesday, November 04, 2014 12:47 PM To: nanog at nanog.org Subject: Default routes on BGP routers with full feeds I'm wondering how many of you who are multihomed also add default routes pointing to your providers from whom you are receiving full feeds. If so, why? If not, why not? Thanks, Berry From SNaslund at medline.com Tue Nov 4 19:24:31 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 4 Nov 2014 19:24:31 +0000 Subject: Default routes on BGP routers with full feeds In-Reply-To: <20141104174737.D19682D4308@mail.nanog.org> References: <20141104174737.D19682D4308@mail.nanog.org> Message-ID: <9578293AE169674F9A048B2BC9A081B401571EDC89@MUNPRDMBXA1.medline.com> I can tell you that I do not do that. Typically if my BGP connectivity to a carrier fails I would prefer we don't route anything their way until we get that resolved because it might indicate a circuit that is up but unable to pass traffic (very common with carrier Ethernet especially). It does not guarantee anything but the BGP session is at least showing me that the last mile connectivity is good. In our MPLS VPN network we use BGP passwords that provide a bit of protection in case the carrier dumps one of our circuits into the wrong VRF (it does happen) and loss of the BGP session helps ensure that I don't route traffic into a MPLS VPN that is not ours. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Berry Mobley Sent: Tuesday, November 04, 2014 11:47 AM To: nanog at nanog.org Subject: Default routes on BGP routers with full feeds I'm wondering how many of you who are multihomed also add default routes pointing to your providers from whom you are receiving full feeds. If so, why? If not, why not? Thanks, Berry From jleq96 at gmail.com Tue Nov 4 21:06:04 2014 From: jleq96 at gmail.com (John LeCoque) Date: Tue, 4 Nov 2014 15:06:04 -0600 Subject: Seeking clueful Comcast contact re static IP address info Message-ID: Hello all, Sorry to take such a basic issue all the way to NANOG, but my team has nearly 16 hours into this issue via phone / e-mail with no results. We just need the IP address information for our recently installed DOCSIS service at a location in Tallahassee, FL. Unfortunately we have had no luck with support (after many attempts), and our sales rep has made it very clear that he does not care. Is there anyone from Comcast here who could contact me off-list to help us get this resolved? I am very grateful for any assistance. Thank you, John From jared at puck.nether.net Tue Nov 4 21:31:50 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 4 Nov 2014 16:31:50 -0500 Subject: Default routes on BGP routers with full feeds In-Reply-To: References: <20141104174736.2600B2D42A7@mail.nanog.org> Message-ID: <1A3154E5-12DF-416B-BED8-CD540B5C2DCC@puck.nether.net> > On Nov 4, 2014, at 1:25 PM, Mike Walter wrote: > > I have 5 providers and we get the default from all of them and full routing tables. > > I have seen cases where if there is no default route, the traffic didn't know where to go, even with full routes from all my providers. We put some efforts into our default origination service a few years back to prevent default from being announced if the pop became isolated for some catastrophic reason. I recall once when someone upgraded the route processor of two different routers in a pop at the same time resulting in isolation until the configs were placed on the new RE for other devices in the site. Things happen and preparing for them is the first step to survive. - Jared From bill at herrin.us Tue Nov 4 22:30:01 2014 From: bill at herrin.us (William Herrin) Date: Tue, 4 Nov 2014 17:30:01 -0500 Subject: Default routes on BGP routers with full feeds In-Reply-To: <20141104174735.C85252D40FD@mail.nanog.org> References: <20141104174735.C85252D40FD@mail.nanog.org> Message-ID: On Tue, Nov 4, 2014 at 12:47 PM, Berry Mobley wrote: > I'm wondering how many of you who are > multihomed also add default routes pointing > to your providers from whom you are receiving full feeds. Back when I was in the ISP world I installed a default route pointing to a data capture machine. This let me detect which customers had port-scanning worms so I could identify them ahead of the abuse complaint (and ahead of the "why is my Internet so slow complaint). The scanners rip through unrouted space as often as they rip through routed space, so they were pretty easy to catch. Unfortunately, dealing with Grandma's virus laden machine was never easy. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From owen at delong.com Tue Nov 4 22:39:37 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 4 Nov 2014 14:39:37 -0800 Subject: Default routes on BGP routers with full feeds In-Reply-To: <20141104174736.CE5E32D42C7@mail.nanog.org> References: <20141104174736.CE5E32D42C7@mail.nanog.org> Message-ID: Usually, when this is done, it is an adjunct to providing connectivity fast while the table is loading on a connection reset. Owen > On Nov 4, 2014, at 9:47 AM, Berry Mobley wrote: > > I'm wondering how many of you who are multihomed also add default routes pointing to your providers from whom you are receiving full feeds. > > If so, why? If not, why not? > > Thanks, > > Berry From owen at delong.com Tue Nov 4 22:42:18 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 4 Nov 2014 14:42:18 -0800 Subject: Default routes on BGP routers with full feeds In-Reply-To: References: <20141104174736.2600B2D42A7@mail.nanog.org> Message-ID: <56BDEBF3-2577-4021-B9F1-51128E51CAFB@delong.com> It seems in such a case, the traffic still doesn’t know where to go, but you don’t realize it because you have a default. Then you pass the traffic to one of the providers who doesn’t have a route for it and they drop it instead of you. If you see something different, then, by definition, said provider is not feeding you a full set of their tables, or, they, too, are depending on a default and are not receiving a full set of tables. Owen > On Nov 4, 2014, at 10:25 AM, Mike Walter wrote: > > I have 5 providers and we get the default from all of them and full routing tables. > > I have seen cases where if there is no default route, the traffic didn't know where to go, even with full routes from all my providers. > > -Mike > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Berry Mobley > Sent: Tuesday, November 04, 2014 12:47 PM > To: nanog at nanog.org > Subject: Default routes on BGP routers with full feeds > > I'm wondering how many of you who are multihomed also add default > routes pointing to your providers from whom you are receiving full feeds. > > If so, why? If not, why not? > > Thanks, > > Berry From surfer at mauigateway.com Tue Nov 4 23:06:22 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 4 Nov 2014 15:06:22 -0800 Subject: Cisco CCNA Training Message-ID: <20141104150622.623531BC@m0005298.ppops.net> For vendor agnostic netgeek training there is always the NANOG Education Series: https://www.nanog.org/meetings/education/home scott From jleq96 at gmail.com Wed Nov 5 00:25:25 2014 From: jleq96 at gmail.com (John LeCoque) Date: Tue, 4 Nov 2014 18:25:25 -0600 Subject: Seeking clueful Comcast contact re static IP address info In-Reply-To: References: Message-ID: Thanks all. I am in touch with Comcast, and we are getting the issue sorted out. On Tue, Nov 4, 2014 at 3:06 PM, John LeCoque wrote: > Hello all, > > Sorry to take such a basic issue all the way to NANOG, but my team has > nearly 16 hours into this issue via phone / e-mail with no results. We just > need the IP address information for our recently installed DOCSIS service > at a location in Tallahassee, FL. > > Unfortunately we have had no luck with support (after many attempts), and > our sales rep has made it very clear that he does not care. > > Is there anyone from Comcast here who could contact me off-list to help us > get this resolved? I am very grateful for any assistance. > > Thank you, > John > From crogers at inerail.net Wed Nov 5 01:41:43 2014 From: crogers at inerail.net (Chris Rogers) Date: Tue, 4 Nov 2014 20:41:43 -0500 Subject: Default routes on BGP routers with full feeds In-Reply-To: <56BDEBF3-2577-4021-B9F1-51128E51CAFB@delong.com> References: <20141104174736.2600B2D42A7@mail.nanog.org> <56BDEBF3-2577-4021-B9F1-51128E51CAFB@delong.com> Message-ID: We don't accept a default from anyone, but will send one to a customer when specifically requested. We heavily filter all incoming routes (bogon, 1918, and many others). We don't want data resorting to 0/0 and ::/0 when we specifically rejected the matching route at the import policy. Additionally, if your upstream isn't announcing a route to you, where are they going to send your traffic anyway? Regards, Chris Rogers +1.302.357.3696 x2110 http://inerail.net/ On Tue, Nov 4, 2014 at 5:42 PM, Owen DeLong wrote: > It seems in such a case, the traffic still doesn’t know where to go, but > you don’t realize it because you have a default. > > Then you pass the traffic to one of the providers who doesn’t have a route > for it and they drop it instead of you. > > If you see something different, then, by definition, said provider is not > feeding you a full set of their tables, or, they, too, are depending on a > default and are not receiving a full set of tables. > > Owen > > > On Nov 4, 2014, at 10:25 AM, Mike Walter wrote: > > > > I have 5 providers and we get the default from all of them and full > routing tables. > > > > I have seen cases where if there is no default route, the traffic didn't > know where to go, even with full routes from all my providers. > > > > -Mike > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Berry Mobley > > Sent: Tuesday, November 04, 2014 12:47 PM > > To: nanog at nanog.org > > Subject: Default routes on BGP routers with full feeds > > > > I'm wondering how many of you who are multihomed also add default > > routes pointing to your providers from whom you are receiving full feeds. > > > > If so, why? If not, why not? > > > > Thanks, > > > > Berry > > From mark.tinka at seacom.mu Wed Nov 5 05:50:03 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 5 Nov 2014 07:50:03 +0200 Subject: Default routes on BGP routers with full feeds In-Reply-To: <20141104174738.70B382D4328@mail.nanog.org> References: <20141104174738.70B382D4328@mail.nanog.org> Message-ID: <201411050750.04077.mark.tinka@seacom.mu> On Tuesday, November 04, 2014 07:47:21 PM Berry Mobley wrote: > I'm wondering how many of you who are multihomed also add > default routes pointing to your providers from whom you > are receiving full feeds. > > If so, why? If not, why not? We filter out default routes from our upstreams, but many of our customers request it so we send them both full + default routes. We have not yet been in a position where a default route to an upstream would have come in handy, as we do a lot of peering (close to 70% of our Internet traffic) and have a reasonable number of upstreams. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From adrian at changeover.za.net Wed Nov 5 06:15:16 2014 From: adrian at changeover.za.net (Adrian Moisey) Date: Wed, 5 Nov 2014 08:15:16 +0200 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: This guy got funding and made a free series that teaches CCNA. I'm not sure how good it is, but it's free. https://www.youtube.com/playlist?list=PLmdYg02XJt6QRQfYjyQcMPfS3mrSnFbRC http://www.reddit.com/r/sysadmin/comments/25mmoo/a_year_ago_i_asked_for_help_to_produce_a_free/ On Sun, Nov 2, 2014 at 7:02 PM, Colton Conor wrote: > We have a couple of techs that want to learn cisco and networking in > general. What do you recommend for learning and getting certified on Cisco? > There seems to be a million different training courses, books, etc out > there. From andreas.larsen at ip-only.se Wed Nov 5 06:49:39 2014 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Wed, 5 Nov 2014 06:49:39 +0000 Subject: Default routes on BGP routers with full feeds In-Reply-To: References: <20141104174736.2600B2D42A7@mail.nanog.org> <56BDEBF3-2577-4021-B9F1-51128E51CAFB@delong.com> Message-ID: There is one setup where you would need default route from your provider. If you have no IBGP between two sites and your prefix is a large /16 on side and maybe a /18 from that /16 on another site. These site would not be able to talk to each other if you orginate from the same AS. Other than that I see not harm in having both default and a full table since longest prefix match will always win even if you have 2 or more transits. // Andreas Med vänlig hälsning Andreas Larsen IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Besöksadress: S:t Persgatan 6, Uppsala | Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 www.ip-only.se 5 nov 2014 kl. 02:41 skrev Chris Rogers >: We don't accept a default from anyone, but will send one to a customer when specifically requested. We heavily filter all incoming routes (bogon, 1918, and many others). We don't want data resorting to 0/0 and ::/0 when we specifically rejected the matching route at the import policy. Additionally, if your upstream isn't announcing a route to you, where are they going to send your traffic anyway? Regards, Chris Rogers +1.302.357.3696 x2110 http://inerail.net/ On Tue, Nov 4, 2014 at 5:42 PM, Owen DeLong wrote: It seems in such a case, the traffic still doesn’t know where to go, but you don’t realize it because you have a default. Then you pass the traffic to one of the providers who doesn’t have a route for it and they drop it instead of you. If you see something different, then, by definition, said provider is not feeding you a full set of their tables, or, they, too, are depending on a default and are not receiving a full set of tables. Owen On Nov 4, 2014, at 10:25 AM, Mike Walter wrote: I have 5 providers and we get the default from all of them and full routing tables. I have seen cases where if there is no default route, the traffic didn't know where to go, even with full routes from all my providers. -Mike -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Berry Mobley Sent: Tuesday, November 04, 2014 12:47 PM To: nanog at nanog.org Subject: Default routes on BGP routers with full feeds I'm wondering how many of you who are multihomed also add default routes pointing to your providers from whom you are receiving full feeds. If so, why? If not, why not? Thanks, Berry From mstorck at voipgate.com Wed Nov 5 11:52:58 2014 From: mstorck at voipgate.com (Marc Storck) Date: Wed, 5 Nov 2014 11:52:58 +0000 Subject: Default routes on BGP routers with full feeds In-Reply-To: References: <20141104174736.2600B2D42A7@mail.nanog.org> <56BDEBF3-2577-4021-B9F1-51128E51CAFB@delong.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 5, 2014, at 7:49 AM, Andreas Larsen wrote: There is one setup where you would need default route from your provider. If you have no IBGP between two sites and your prefix is a large /16 on side and maybe a /18 from that /16 on another site. These site would not be able to talk to each other if you orginate from the same AS. Other than that I see not harm in having both default and a full table since longest prefix match will always win even if you have 2 or more transits. I think in that case you would use “allowas-in”. Regards, Marc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJUWg8PAAoJEBqZdpQUXtTCkr8P/j/V0nsJwS6UOhEBU0Cpvrlf BnhGgBy3exIiMq87IqO472P5Gkwsx52a/P5zUfuRDd3GKs1kNx4cyM6MH+XUFti0 f7kkKxDJ5hAne2Bg+KYLK/oLJUFC9gjSJM5AL8fjTb7qr+X2Wc2Wuqm/F346V3gQ cpO8lTuctM9pmBguAk8hCggKrsQBjDZJ7aF6qEebSdZHEG4JuONzx/2xFwq9vZMW 1lh+hyoGiVmb5dglma3525N0SbfJBbRgIFjcd7kQTq7toyRUytGecjpmXjCdomkG Y07Atj9T02w4M3h3dUpsAfXPRZhHuXBhDV24n0eBOnaJEwbEkdz5qfYjbXLVAItH 8yo8gtEYjzhPyfivdJ4YiZ97Yd4BID7boaiuyEBxczLfZ77Fm7XxPqbD+9K5+DJv VnyIt1adZkIcnoNSOOfJPswNT8Tfmz6r5F3l0+xa+ZnmCUgKZ8XtcHoLPYGR5ZMs mU6W7SsLSeX4QgO/2Ae+hmfV+jWcyNnt/Vs9MNqFkAbyjsjXX4H7gc88UKpPzvIq kkMzlKrk5hlXhZ6bQJWwIgX3PaDxD+YLa/nmq6/sgqA8rIKNiOVtNYWMbEkve5JJ l+RAA7foh22Sz0zCce6Rf/jmibBRAZ3GBD/UxV5bH+XB+vStlBZ8B8EHe22fwBaX BThfag88mErUm+MXKbar =qJ44 -----END PGP SIGNATURE----- From maillist at webjogger.net Wed Nov 5 14:22:45 2014 From: maillist at webjogger.net (Adam Greene) Date: Wed, 5 Nov 2014 09:22:45 -0500 Subject: Default routes on BGP routers with full feeds In-Reply-To: References: <20141104174736.2600B2D42A7@mail.nanog.org> <56BDEBF3-2577-4021-B9F1-51128E51CAFB@delong.com> Message-ID: <013401cff903$f7d87550$e7895ff0$@webjogger.net> We receive full routes and a default so we can perform traffic engineering within our network. We have links to multiple carriers, via multiple routers. We inject a default route into OSPF from distinct segments of our network, based on receiving the default route on that segment via eBGP. If the default route goes down, the default injected from another segment assumes priority and traffic routes out through that segment's carrier. It's easier to manage this kind of failover (for us) using default routes, so we don't have to carry full routes on all our core routers. We also prefer using a default route over engineering things based on some other arbitrary route learned from eBGP. Thanks, Adam -----Original Message----- From: NANOG [mailto:nanog-bounces+maillist=webjogger.net at nanog.org] On Behalf Of Marc Storck Sent: Wednesday, November 05, 2014 6:53 AM To: nanog at nanog.org Subject: Re: Default routes on BGP routers with full feeds -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 5, 2014, at 7:49 AM, Andreas Larsen wrote: There is one setup where you would need default route from your provider. If you have no IBGP between two sites and your prefix is a large /16 on side and maybe a /18 from that /16 on another site. These site would not be able to talk to each other if you orginate from the same AS. Other than that I see not harm in having both default and a full table since longest prefix match will always win even if you have 2 or more transits. I think in that case you would use “allowas-in”. Regards, Marc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJUWg8PAAoJEBqZdpQUXtTCkr8P/j/V0nsJwS6UOhEBU0Cpvrlf BnhGgBy3exIiMq87IqO472P5Gkwsx52a/P5zUfuRDd3GKs1kNx4cyM6MH+XUFti0 f7kkKxDJ5hAne2Bg+KYLK/oLJUFC9gjSJM5AL8fjTb7qr+X2Wc2Wuqm/F346V3gQ cpO8lTuctM9pmBguAk8hCggKrsQBjDZJ7aF6qEebSdZHEG4JuONzx/2xFwq9vZMW 1lh+hyoGiVmb5dglma3525N0SbfJBbRgIFjcd7kQTq7toyRUytGecjpmXjCdomkG Y07Atj9T02w4M3h3dUpsAfXPRZhHuXBhDV24n0eBOnaJEwbEkdz5qfYjbXLVAItH 8yo8gtEYjzhPyfivdJ4YiZ97Yd4BID7boaiuyEBxczLfZ77Fm7XxPqbD+9K5+DJv VnyIt1adZkIcnoNSOOfJPswNT8Tfmz6r5F3l0+xa+ZnmCUgKZ8XtcHoLPYGR5ZMs mU6W7SsLSeX4QgO/2Ae+hmfV+jWcyNnt/Vs9MNqFkAbyjsjXX4H7gc88UKpPzvIq kkMzlKrk5hlXhZ6bQJWwIgX3PaDxD+YLa/nmq6/sgqA8rIKNiOVtNYWMbEkve5JJ l+RAA7foh22Sz0zCce6Rf/jmibBRAZ3GBD/UxV5bH+XB+vStlBZ8B8EHe22fwBaX BThfag88mErUm+MXKbar =qJ44 -----END PGP SIGNATURE----- From lists.nanog at monmotha.net Wed Nov 5 15:56:00 2014 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 05 Nov 2014 10:56:00 -0500 Subject: BGP process torture In-Reply-To: References: <5457BE55.2010505@monmotha.net> Message-ID: <545A4890.5060302@monmotha.net> On 11/03/2014 12:47 PM, chip wrote: > Exabgp should be able to help you out here. Great for doing fun things > with BGP. > > https://github.com/Exa-Networks/exabgp You find a new tool every day. Thanks for the heads up on that particular swiss army knife. Looks like it would make this pretty straightforward. -- Brandon Martin From mailing-lists at brianraaen.com Wed Nov 5 15:59:50 2014 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Wed, 5 Nov 2014 10:59:50 -0500 Subject: Issues with SNMP monitoring over a GRE tunnel. Message-ID: I have two different customers where I am unable to monitor their networks due to GRE MTU issues. This is monitoring cable modems so I can't change the MTU of the end device. The problem I am having is that the modems are producing frames that appear to be larger than some kind of MTU limit in the system (we do not control the customer routers in either case). One that I am looking at is dropping anything larger than 1472, and I have let to tune down on the other one. In one case the customer endpoint is a Cisco ASR1K router and the other is a ASR9K. because these are UDP packets I can't use a mss to clamp things down. Also I have been unable to replicate the issue in my lab, so I can't send them a list of commands to help fix the issue on their end. -- Brian Christopher Raaen Network Architect Zcorum From owen at delong.com Wed Nov 5 17:48:00 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 5 Nov 2014 09:48:00 -0800 Subject: Default routes on BGP routers with full feeds In-Reply-To: References: <20141104174736.2600B2D42A7@mail.nanog.org> <56BDEBF3-2577-4021-B9F1-51128E51CAFB@delong.com> Message-ID: > On Nov 4, 2014, at 10:49 PM, Andreas Larsen wrote: > > There is one setup where you would need default route from your provider. That may be true, but this isn’t it… > If you have no IBGP between two sites and your prefix is a large /16 on side and maybe a /18 from that /16 on another site. These site would not be able to talk to each other if you orginate from the same AS. 1. Don’t do this. No, really, this is like the old joke about “Doctor, Doctor, it hurts when I do this!”. Just get a second AS. Supposed definition of an AS: “A collection of prefixes with a common routing policy”. If you have a /18 advertised from group A and a /17 and a /18 advertised from group B (even if you’re pretending it’s a /16 and including the covered separate /18), then you have 3 (or pretending 2) prefixes which have different routing policies. 2. If you are going to do this, then you’re better off building a tunnel between the sites and setting up iBGP across the tunnel. 3. Another option is to coerce your BGP into accepting routes with your own AS in the AS PATH. This circumvents BGP loop detection, but if you’re two sites are stub sites (and I can’t imagine a scenario where you would do this with transit sites), then that is a pretty low risk. Further, you can filter out the potential loop routes pretty easily since you know which ones are local to each site, making that particular loop detection irrelevant). > Other than that I see not harm in having both default and a full table since longest prefix match will always win even if you have 2 or more transits. The harm is that instead of dropping traffic that can’t go anywhere, you’re passing it to someone else to drop for you. I suppose as long as you’re paying for the bandwidth used, it’s not a big deal, but it also breaks your ability to implement things like BCP38. Owen > > // Andreas > Med vänlig hälsning > Andreas Larsen > > IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Besöksadress: S:t Persgatan 6, Uppsala | > Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 > www.ip-only.se >> 5 nov 2014 kl. 02:41 skrev Chris Rogers >: >> >> We don't accept a default from anyone, but will send one to a customer when >> specifically requested. >> >> We heavily filter all incoming routes (bogon, 1918, and many others). We >> don't want data resorting to 0/0 and ::/0 when we specifically rejected the >> matching route at the import policy. >> >> Additionally, if your upstream isn't announcing a route to you, where are >> they going to send your traffic anyway? >> >> Regards, >> Chris Rogers >> +1.302.357.3696 x2110 >> http://inerail.net/ >> >> On Tue, Nov 4, 2014 at 5:42 PM, Owen DeLong wrote: >> >>> It seems in such a case, the traffic still doesn’t know where to go, but >>> you don’t realize it because you have a default. >>> >>> Then you pass the traffic to one of the providers who doesn’t have a route >>> for it and they drop it instead of you. >>> >>> If you see something different, then, by definition, said provider is not >>> feeding you a full set of their tables, or, they, too, are depending on a >>> default and are not receiving a full set of tables. >>> >>> Owen >>> >>>> On Nov 4, 2014, at 10:25 AM, Mike Walter wrote: >>>> >>>> I have 5 providers and we get the default from all of them and full >>> routing tables. >>>> >>>> I have seen cases where if there is no default route, the traffic didn't >>> know where to go, even with full routes from all my providers. >>>> >>>> -Mike >>>> >>>> -----Original Message----- >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Berry Mobley >>>> Sent: Tuesday, November 04, 2014 12:47 PM >>>> To: nanog at nanog.org >>>> Subject: Default routes on BGP routers with full feeds >>>> >>>> I'm wondering how many of you who are multihomed also add default >>>> routes pointing to your providers from whom you are receiving full feeds. >>>> >>>> If so, why? If not, why not? >>>> >>>> Thanks, >>>> >>>> Berry >>> >>> > From jwalter at weebly.com Wed Nov 5 18:36:43 2014 From: jwalter at weebly.com (Jeff Walter) Date: Wed, 5 Nov 2014 10:36:43 -0800 Subject: Issues with SNMP monitoring over a GRE tunnel. In-Reply-To: References: Message-ID: I think the simple solution here is to query for fewer OIDs to get the packet size (in both directions) down below the MTU. It'll take more requests and thus longer, but if that's what solves the problem... well, that's what solves the problem. On Wed, Nov 5, 2014 at 7:59 AM, Brian Christopher Raaen < mailing-lists at brianraaen.com> wrote: > I have two different customers where I am unable to monitor their networks > due to GRE MTU issues. This is monitoring cable modems so I can't change > the MTU of the end device. The problem I am having is that the modems are > producing frames that appear to be larger than some kind of MTU limit in > the system (we do not control the customer routers in either case). One > that I am looking at is dropping anything larger than 1472, and I have let > to tune down on the other one. In one case the customer endpoint is a > Cisco ASR1K router and the other is a ASR9K. because these are UDP packets > I can't use a mss to clamp things down. Also I have been unable to > replicate the issue in my lab, so I can't send them a list of commands to > help fix the issue on their end. > > -- > Brian Christopher Raaen > Network Architect > Zcorum > From gmoberg at logmatrix.com Wed Nov 5 18:49:55 2014 From: gmoberg at logmatrix.com (Gregory Moberg) Date: Wed, 5 Nov 2014 13:49:55 -0500 Subject: Issues with SNMP monitoring over a GRE tunnel. In-Reply-To: References: Message-ID: This would be a good approach. In SNMP the request initiator (the one sending the SNMP 'Get' or 'GetNext' or 'GetBulk' ) can anticipate the size of the outgoing request will be small(er) by asking for fewer variables at a time. (Each variable is a 'varbind' and each is specified in the outgoing request packet as an OID.) But it sometime impossible to know how large the return size will be. The SNMP Agent responding the to request will load up the return UDP packet with the required data and this could be quite large - depending on what is being requested. Thus, it is good to ask for fewer variables at a time thus hopefully keeping the SNMP Agent from responding with something that will prove too large to the MTU barrier that is being hit somewhere along the transitioned network path. 'GetBulk' would seem to be the worst enemy regarding this. Of course some returns are very small per-variable. 'ifInOctets' is a 32bit integer. 'ifHCInOctets' is a 64bit integer. Etc. These are not likely the problem. Issues will occur when fetching octet strings such as 'ifDescr' or 'sysLocation' - there can be times when these values have been loaded up the remote SNMP Agent with quite a substantial response. On Wed, Nov 5, 2014 at 1:36 PM, Jeff Walter wrote: > I think the simple solution here is to query for fewer OIDs to get the > packet size (in both directions) down below the MTU. It'll take more > requests and thus longer, but if that's what solves the problem... well, > that's what solves the problem. > > On Wed, Nov 5, 2014 at 7:59 AM, Brian Christopher Raaen < > mailing-lists at brianraaen.com> wrote: > > > I have two different customers where I am unable to monitor their > networks > > due to GRE MTU issues. This is monitoring cable modems so I can't change > > the MTU of the end device. The problem I am having is that the modems > are > > producing frames that appear to be larger than some kind of MTU limit in > > the system (we do not control the customer routers in either case). One > > that I am looking at is dropping anything larger than 1472, and I have > let > > to tune down on the other one. In one case the customer endpoint is a > > Cisco ASR1K router and the other is a ASR9K. because these are UDP > packets > > I can't use a mss to clamp things down. Also I have been unable to > > replicate the issue in my lab, so I can't send them a list of commands to > > help fix the issue on their end. > > > > -- > > Brian Christopher Raaen > > Network Architect > > Zcorum > > > -- Greg Moberg, Director, NerveCenter Engineering LogMatrix, Inc | http://www.logmatrix.com/ | CommunityForum | Blog Telephone: +1 (800)892-3646 From bill at herrin.us Wed Nov 5 19:39:16 2014 From: bill at herrin.us (William Herrin) Date: Wed, 5 Nov 2014 14:39:16 -0500 Subject: Default routes on BGP routers with full feeds In-Reply-To: <20141104174735.C85252D40FD@mail.nanog.org> References: <20141104174735.C85252D40FD@mail.nanog.org> Message-ID: On Tue, Nov 4, 2014 at 12:47 PM, Berry Mobley wrote: > I'm wondering how many of you who are multihomed > also add default routes pointing to your providers > from whom you are receiving full feeds. > > If so, why? If not, why not? Back when I worked for the DNC we ran into a problem with the TCAM size. Given the DNC's focus on the U.S., network reliability to the /8's operated out of the APNIC and RIPE regions was much less important to us. So, we filtered BGP announcements from within those /8's and relied on covering routes to get our packets there instead. I used covering /8's instead of a default, but a default would have been as effective. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From copraphage at gmail.com Wed Nov 5 20:10:46 2014 From: copraphage at gmail.com (Chris McDonald) Date: Wed, 5 Nov 2014 15:10:46 -0500 Subject: hawaiian telcom Message-ID: if there is a commercial contact from hawaiian telcom lurking here, can you please ping me offlist? thanks, chris From rfg at tristatelogic.com Wed Nov 5 21:59:17 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 05 Nov 2014 13:59:17 -0800 Subject: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud Message-ID: <81757.1415224757@server1.tristatelogic.com> I already posted about this rogue AS days ago, but nothing has really changed much, since then, with respect to its hijacking of IP space. Well, at least Brian Krebs was kind anough to write about it: http://krebsonsecurity.com/2014/11/still-spamming-after-all-these-years/ (Please note that that is a convicted felon spamming from the hijacked IP space. He's not allowed to own firearms, but he _can_ apparently own a keyboard.) As of today, AS201640 is still hijacking a total of eleven routes to IP space scattered all over the world... none of which appears to belong to anybody in or near Bulgaria. In fact, it would appear that the organization that is the registrant of AS201640 currently has exactly -zero- IP addresses to call its own. Nobody in a postion to _do_ anything about this gives a darn? As of today: 36.0.56.0/21 41.92.206.0/23 41.198.80.0/20 41.198.224.0/20 61.242.128.0/19 119.227.224.0/19 123.29.96.0/19 177.22.117.0/24 177.46.48.0/22 187.189.158.0/23 202.39.112.0/20 From hugo at slabnet.com Wed Nov 5 22:46:34 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 5 Nov 2014 14:46:34 -0800 Subject: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud In-Reply-To: <81757.1415224757@server1.tristatelogic.com> References: <81757.1415224757@server1.tristatelogic.com> Message-ID: <20141105224634.GC7323@stargate.ca> >From our view of the table, it looks like it would be up to either 200002 (not likely to happen) or GTT. They've lined the IIRs to pass 201640 through 200002 via AS-HereHost. Anyone from GTT able to comment? -- Hugo -----Original Message----- >Date: Wed, 5 Nov 2014 13:59:17 -0800 >From: "Ronald F. Guilmette" >To: nanog at nanog.org >Subject: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud > > >I already posted about this rogue AS days ago, but nothing has really >changed much, since then, with respect to its hijacking of IP space. > >Well, at least Brian Krebs was kind anough to write about it: > > http://krebsonsecurity.com/2014/11/still-spamming-after-all-these-years/ > >(Please note that that is a convicted felon spamming from the hijacked >IP space. He's not allowed to own firearms, but he _can_ apparently >own a keyboard.) > >As of today, AS201640 is still hijacking a total of eleven routes to >IP space scattered all over the world... none of which appears to >belong to anybody in or near Bulgaria. In fact, it would appear that >the organization that is the registrant of AS201640 currently has >exactly -zero- IP addresses to call its own. > >Nobody in a postion to _do_ anything about this gives a darn? > > >As of today: > >36.0.56.0/21 >41.92.206.0/23 >41.198.80.0/20 >41.198.224.0/20 >61.242.128.0/19 >119.227.224.0/19 >123.29.96.0/19 >177.22.117.0/24 >177.46.48.0/22 >187.189.158.0/23 >202.39.112.0/20 > From fred at web2objects.com Tue Nov 4 18:37:36 2014 From: fred at web2objects.com (Fred) Date: Tue, 04 Nov 2014 19:37:36 +0100 Subject: Default routes on BGP routers with full feeds In-Reply-To: <54591833.9080608@ispn.net> References: <20141104174736.763842D4208@mail.nanog.org> <54591833.9080608@ispn.net> Message-ID: <54591CF0.1070107@web2objects.com> Long time I had the same opinion, however, if someone operates a network with multiple upstream providers the operator should be able to afford a proper out of band console access which solves this issue completely. I would only accept a default route on Uplinks where I am only receiving a partial table for rescue purpose. Blake Hudson: > I often opt to leave one or more default routes configured with low > priority (lower than BGP). The thinking is that if there is a fault with > BGP, the router will still operate and the fault can be corrected > remotely (in-band). The downside is that I might pass traffic for > non-existing destinations an additional hop and put the load of > generating an ICMP unreachable on someone else's router. > > --Blake > > > Berry Mobley wrote on 11/4/2014 11:47 AM: >> I'm wondering how many of you who are multihomed also add default >> routes pointing to your providers from whom you are receiving full feeds. >> >> If so, why? If not, why not? >> >> Thanks, >> >> Berry >> > From jwillie4020 at gmail.com Wed Nov 5 00:01:43 2014 From: jwillie4020 at gmail.com (scottie mac) Date: Wed, 05 Nov 2014 11:01:43 +1100 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: <545968E7.8040806@gmail.com> This course has 25 hours of video, I haven't started it yet but I've watched many of Laz's videos on Youtube, and he explains stuff very well. It is $399 though. They could share the Udemy account, and watch them in their free time. *I'm not affiliated with Udemy* https://www.udemy.com/the-complete-ccna-200-120-course From 86 at tacorp.us Wed Nov 5 18:02:08 2014 From: 86 at tacorp.us (Jason) Date: Wed, 05 Nov 2014 10:02:08 -0800 Subject: Shipping bulk hardware via freight Message-ID: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> I'm interested in talking with someone who has experience shipping hardware that has been pulled from a working environment. The assumption is that it would not use a normal carriers such as UPS of Fedex, but via private freight. Assuming that 20 x 1U switches and a handful of 10U chassis's were to be shipped, has anyone found a productive way to package them in something other than the boxes they come in? Has anyone tried to crate / pallet pack them or something more efficient? If so, please contact me offline if you are willing to share your experience. Jason From israel.lugo at lugosys.com Thu Nov 6 01:57:14 2014 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Thu, 06 Nov 2014 01:57:14 +0000 Subject: [curiosity] Internet's first router, 1969 Message-ID: <545AD57A.10202@lugosys.com> Old days... :) http://www.snotr.com/video/14338/In_Honor_Of_The_Internet_Turning_45_Today__Here_Is_Its_First_Router From faisal at snappytelecom.net Thu Nov 6 02:22:01 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 6 Nov 2014 02:22:01 +0000 (GMT) Subject: Shipping bulk hardware via freight In-Reply-To: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> References: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> Message-ID: <532928780.404164.1415240521495.JavaMail.zimbra@snappytelecom.net> My suggestion would be to leave the packing & shipping to professionals.... Take it to you local UPS store or similar, they can pack it and ship it ( 1u switches, no big deal, but the 10u chassis, most likely best if they are palatalized) Doing it any other way would be greatly dependent on what facilities are available to you.. i.e. can you palatalize it ? Shrink wrap it and have a freight carrier pick it up.. (the are picky about doing that from a location that does not have dock height warehouse / ramp. You might be able to find a "consolidator" freight forwarder who may have the facilities to palatalize and shrink wrap.. You can also take the do it your-self approach, get / find some pallets, buy some strapping, and shrink wrap rolls, while not hard to do..... but make sure you have the resources to do so (pallet jack, space, tools etc). Regards 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: Support at Snappytelecom.net ----- Original Message ----- > From: "Jason" <86 at tacorp.us> > To: nanog at nanog.org > Sent: Wednesday, November 5, 2014 1:02:08 PM > Subject: Shipping bulk hardware via freight > > > I'm interested in talking with someone who has experience shipping hardware > that has been pulled from a working environment. The assumption is that it > would not use a normal carriers such as UPS of Fedex, but via private > freight. > > Assuming that 20 x 1U switches and a handful of 10U chassis's were to be > shipped, has anyone found a productive way to package them in something > other than the boxes they come in? Has anyone tried to crate / pallet pack > them or something more efficient? > > > If so, please contact me offline if you are willing to share your experience. > > > Jason > > > > From ops.lists at gmail.com Thu Nov 6 02:29:52 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 6 Nov 2014 07:59:52 +0530 Subject: Shipping bulk hardware via freight In-Reply-To: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> References: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> Message-ID: If you are planning to scrap it after retiring it from production, talk to nsrc @ uoregon, they'll pick it up and ship it to developing countries that could use it. On Nov 6, 2014 4:45 AM, "Jason" <86 at tacorp.us> wrote: > > I'm interested in talking with someone who has experience shipping > hardware that has been pulled from a working environment. The assumption > is that it would not use a normal carriers such as UPS of Fedex, but via > private freight. > > Assuming that 20 x 1U switches and a handful of 10U chassis's were to be > shipped, has anyone found a productive way to package them in something > other than the boxes they come in? Has anyone tried to crate / pallet pack > them or something more efficient? > > > If so, please contact me offline if you are willing to share your > experience. > > > Jason > > > > From gary.buhrmaster at gmail.com Thu Nov 6 02:54:49 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 6 Nov 2014 02:54:49 +0000 Subject: Shipping bulk hardware via freight In-Reply-To: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> References: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> Message-ID: On Wed, Nov 5, 2014 at 6:02 PM, Jason <86 at tacorp.us> wrote: ..... > If so, please contact me offline if you are willing to share your experience. If you no longer have the original packing boxes (most manufactures have a part number for their boxes, you can order and ship them to the DC, but they are not cheap), and you are relocating for future use, call professional movers that specialize in data centers. They know how to do it. Not cheap, but the equipment makes it to the other end in operational condition (rather than the router that had a fork lift hole in the side of the box (only bent the sheet metal, fortunately), or the entire rack that now had a 15 degree tilt, and for which the inserted disk drives no longer really fit into the metal shell, both "issues" showing up at the other end, and no one knowing how it happened, or the time our "in house" shipping expert(???) packed a large router power supply using packing peanuts, and it arrived with the corners bent (although after a bit of pliers and hammer work, it could be forced into the router, and it worked). And, if a professional data center mover screws up (and, occasionally, everyone does), their insurance covers the repair/replacement (and if you write the contract right, the cost of loss of service, if that is important to you). For our most recent smaller move, we ordered the boxes from the manufacturer (note that the lead times can sometimes be surprisingly long for just the box), and for the last bigger move we got the professional movers. Good luck. From bill at herrin.us Thu Nov 6 04:11:23 2014 From: bill at herrin.us (William Herrin) Date: Wed, 5 Nov 2014 23:11:23 -0500 Subject: Shipping bulk hardware via freight In-Reply-To: References: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> Message-ID: On Wed, Nov 5, 2014 at 9:54 PM, Gary Buhrmaster wrote: > (rather than the router that had a fork lift hole in the side of the box (only > bent the sheet metal, fortunately), or the entire rack that now had a 15 > degree tilt, and for which the inserted disk drives no longer really fit into > the metal shell, both "issues" showing up at the other end Ah yes, I recall watching them decommission the old Control Data Cyber 990 back at Georgia Tech. The mover slipped trying to get it on the liftgate and the whole cabinet dropped about a foot to the ground with a nice solid thud. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From bzs at world.std.com Thu Nov 6 04:18:04 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 5 Nov 2014 23:18:04 -0500 Subject: [curiosity] Internet's first router, 1969 In-Reply-To: <545AD57A.10202@lugosys.com> References: <545AD57A.10202@lugosys.com> Message-ID: <21594.63100.859663.764076@world.std.com> On November 6, 2014 at 01:57 israel.lugo at lugosys.com (Israel G. Lugo) wrote: > > Old days... :) > > http://www.snotr.com/video/14338/In_Honor_Of_The_Internet_Turning_45_Today__Here_Is_Its_First_Router You'll probably love this: A Conversation with Steve Crocker (Chairman, ICANN, author RFC #1, etc) and Leonard Kleinrock (in the video linked above) a couple of weeks ago: http://la51.icann.org/en/schedule/mon-crocker-kleinrock I was there, it was fun. Or as Abraham Lincoln would say: For people who like this sort of thing this is probably the sort of thing they will like. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From mfidelman at meetinghouse.net Thu Nov 6 04:38:10 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 05 Nov 2014 23:38:10 -0500 Subject: [curiosity] Internet's first router, 1969 In-Reply-To: <21594.63100.859663.764076@world.std.com> References: <545AD57A.10202@lugosys.com> <21594.63100.859663.764076@world.std.com> Message-ID: <545AFB32.9010806@meetinghouse.net> > On November 6, 2014 at 01:57 israel.lugo at lugosys.com (Israel G. Lugo) wrote: > > > > Old days... :) > > > > http://www.snotr.com/video/14338/In_Honor_Of_The_Internet_Turning_45_Today__Here_Is_Its_First_Router > > Except, it's the ARPANET that's 45 years old, and the video of is an IMP. :-) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From patrick at ianai.net Thu Nov 6 16:12:27 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 6 Nov 2014 11:12:27 -0500 Subject: Cogent admits to QoSing down streaming Message-ID: This is interesting. And it will be detrimental to network neutrality supporters. Cogent admits that while they were publicly complaining about other networks congesting links, they were using QoS to make the problem look worse. One of the problems in "tech" is most people do not realize tone is important, not just substance. There was - still is! - congestion in many places where consumers have one or at most two choice of providers. Even in places where there are two providers, both are frequently congested. Instead of discussing the fact there is no functioning market, no choice for the average end user, and how to fix it, we will now spend a ton of time arguing whether anything is wrong at all because Cogent did this. Wouldn't you rather be discussing whether 4 Mbps is really broadband? (Anyone else have flashbacks to "640K is enough for anyone!"?) Or how many people have more than one choice at 25 Mbps? Or whether a company with a terminating access monopoly can intentionally congest its edge to charge monopoly rents on the content providers their paying customers are trying to access? I know I would. Instead, we'll be talking about how things are not really bad, Cogent just made it look bad on purpose. The subtlety of "it _IS_ bad, Cogent just shifted some of the burden from VoIP to streaming" is not something that plays well in a 30 second sound bite, or at congressional hearings. It's enough to make one consider giving up the idea of having a functioning, useful Internet. -- TTFN, patrick From jared at puck.nether.net Thu Nov 6 16:23:51 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 6 Nov 2014 11:23:51 -0500 Subject: Cogent admits to QoSing down streaming In-Reply-To: References: Message-ID: <5E8C5920-0323-4B51-925A-A1067DF55DE9@puck.nether.net> > On Nov 6, 2014, at 11:12 AM, Patrick W. Gilmore wrote: > > > > This is interesting. And it will be detrimental to network neutrality supporters. Cogent admits that while they were publicly complaining about other networks congesting links, they were using QoS to make the problem look worse. > > One of the problems in "tech" is most people do not realize tone is important, not just substance. There was - still is! - congestion in many places where consumers have one or at most two choice of providers. Even in places where there are two providers, both are frequently congested. Instead of discussing the fact there is no functioning market, no choice for the average end user, and how to fix it, we will now spend a ton of time arguing whether anything is wrong at all because Cogent did this. > > Wouldn't you rather be discussing whether 4 Mbps is really broadband? (Anyone else have flashbacks to "640K is enough for anyone!"?) Or how many people have more than one choice at 25 Mbps? Or whether a company with a terminating access monopoly can intentionally congest its edge to charge monopoly rents on the content providers their paying customers are trying to access? I know I would. > > Instead, we'll be talking about how things are not really bad, Cogent just made it look bad on purpose. The subtlety of "it _IS_ bad, Cogent just shifted some of the burden from VoIP to streaming" is not something that plays well in a 30 second sound bite, or at congressional hearings. > > It's enough to make one consider giving up the idea of having a functioning, useful Internet. Network SLAs are usually on-net. Deciding how to queue packets down a congested link is certainly something many places have done for years, including when people did Random Early Discard(RED), Weighted RED or even more advanced AQM when there may be one-way congestion (Eg: cable/dsl uplink) at the home. Some people are trying to document/improve this with ideas, such as: https://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel As a technical issue I always want to see congestion addressed promptly with either changes in the traffic pattern or network upgrades. If you have customers on a fixed monthly plan regardless of usage and your capital model doesn’t address that, or you hide the network costs in other ‘bundles’ it may become harder to do the accounting necessary to fund those upgrades. I do wish it were easier to get symmetric speeds on DOCSIS/xDSL technologies. - Jared From Jason_Livingood at cable.comcast.com Thu Nov 6 16:30:18 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 6 Nov 2014 16:30:18 +0000 Subject: Mutually Agreed Norms for Routing Security (MANRS) Message-ID: Of interest to this list – see http://www.internetsociety.org/news/network-operators-around-world-demonstrate-their-commitment-secure-and-resilient-internet and http://www.routingmanifesto.org/ - Jason From Jason_Livingood at cable.comcast.com Thu Nov 6 17:02:25 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 6 Nov 2014 17:02:25 +0000 Subject: Cogent admits to QoSing down streaming In-Reply-To: References: Message-ID: I noticed that Cogent has a Net Neutrality statement. If I understand what they disclosed on the M-Lab list it does not seem to jive with this. The second sentence seems like what they said they are doing, right? http://www.cogentco.com/en/component/content/article/82 "Cogent practices net neutrality. We do not prioritize packet transmissions on the basis of the content of the packet, the customer or network that is the source of the packet, or the customer or network that is the recipient of the packet. It is Cogent's belief that both the customer and the Internet as a whole are best served if the application layer remains independent from the network. Innovation in the development of new applications is fueled by the individual's ability to reach as many people as possible without regard to complicated gating factors such as tiered pricing or bandwidth structures used by legacy service providers. Applications proliferate in a free market economy which is the Internet today." - JL On 11/6/14, 11:12 AM, "Patrick W. Gilmore" > wrote: This is interesting. And it will be detrimental to network neutrality supporters. Cogent admits that while they were publicly complaining about other networks congesting links, they were using QoS to make the problem look worse. One of the problems in "tech" is most people do not realize tone is important, not just substance. There was - still is! - congestion in many places where consumers have one or at most two choice of providers. Even in places where there are two providers, both are frequently congested. Instead of discussing the fact there is no functioning market, no choice for the average end user, and how to fix it, we will now spend a ton of time arguing whether anything is wrong at all because Cogent did this. Wouldn't you rather be discussing whether 4 Mbps is really broadband? (Anyone else have flashbacks to "640K is enough for anyone!"?) Or how many people have more than one choice at 25 Mbps? Or whether a company with a terminating access monopoly can intentionally congest its edge to charge monopoly rents on the content providers their paying customers are trying to access? I know I would. Instead, we'll be talking about how things are not really bad, Cogent just made it look bad on purpose. The subtlety of "it _IS_ bad, Cogent just shifted some of the burden from VoIP to streaming" is not something that plays well in a 30 second sound bite, or at congressional hearings. It's enough to make one consider giving up the idea of having a functioning, useful Internet. -- TTFN, patrick From jared at puck.nether.net Thu Nov 6 17:04:17 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 6 Nov 2014 12:04:17 -0500 Subject: Cogent admits to QoSing down streaming In-Reply-To: References: Message-ID: > On Nov 6, 2014, at 12:02 PM, Livingood, Jason wrote: > > "Cogent practices net neutrality. We do not prioritize packet transmissions on the basis of the content of the packet, the customer or network that is the source of the packet, or the customer or network that is the recipient of the packet. Transmission != Drop - Jared From mikea at mikea.ath.cx Thu Nov 6 17:41:38 2014 From: mikea at mikea.ath.cx (Mike A) Date: Thu, 6 Nov 2014 11:41:38 -0600 Subject: Cogent admits to QoSing down streaming In-Reply-To: References: Message-ID: <20141106174138.GA18593@mikea.ath.cx> On Thu, Nov 06, 2014 at 12:04:17PM -0500, Jared Mauch wrote: > > > On Nov 6, 2014, at 12:02 PM, Livingood, Jason wrote: > > > > "Cogent practices net neutrality. We do not prioritize packet transmissions on the basis of the content of the packet, the customer or network that is the source of the packet, or the customer or network that is the recipient of the packet. > > Transmission != Drop That's logic-chopping worthy of a Jesuit. ;=) So they're de-prioritizing it on the basis of content, source, or recipient, all the way to priority "NEVER". That means they're prioritizing everything else ahead of it. => they're prioritizing "packet transmissions on the basis of the content of the packet, the customer or network that is the source of the packet, or the customer or network that is the recipient of the packet.", for all the other packets, Q.E.D. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From Valdis.Kletnieks at vt.edu Thu Nov 6 18:07:50 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 06 Nov 2014 13:07:50 -0500 Subject: Shipping bulk hardware via freight In-Reply-To: Your message of "Wed, 05 Nov 2014 23:11:23 -0500." References: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> Message-ID: <6692.1415297270@turing-police.cc.vt.edu> On Wed, 05 Nov 2014 23:11:23 -0500, William Herrin said: > Ah yes, I recall watching them decommission the old Control Data Cyber 990 > back at Georgia Tech. The mover slipped trying to get it on the liftgate > and the whole cabinet dropped about a foot to the ground with a nice solid > thud. I know of a case where somebody managed to drop an IBM Shark storage array off a forklift. Amazingly enough, it still kinda sorta worked after that.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From blake at ispn.net Thu Nov 6 18:12:43 2014 From: blake at ispn.net (Blake Hudson) Date: Thu, 06 Nov 2014 12:12:43 -0600 Subject: Cogent admits to QoSing down streaming In-Reply-To: References: Message-ID: <545BBA1B.4010906@ispn.net> If I were a Cogent customer I would like to have seen more transparency (an announcement at least). However, I don't see anything wrong with their practice of giving some customers "Silver" service and others "Bronze" service while reserving "Gold" for themselves. Even if applications like VoIP do not function well with a Bronze service level. Now, a customer that was under the impression they were receiving equal treatment with other customers may not be happy to know they were receiving a lower class of service than expected. This is not a net neutrality matter, it's a matter of expectations and possibly false or deceptive advertising. I would much rather see an environment where the customer gets to choose Gold, Silver, and Bronze levels of service for his or her traffic as opposed to an environment where the provider chooses fast/slow lane applications at their own discretion. --Blake Patrick W. Gilmore wrote on 11/6/2014 10:12 AM: > > > This is interesting. And it will be detrimental to network neutrality supporters. Cogent admits that while they were publicly complaining about other networks congesting links, they were using QoS to make the problem look worse. > > One of the problems in "tech" is most people do not realize tone is important, not just substance. There was - still is! - congestion in many places where consumers have one or at most two choice of providers. Even in places where there are two providers, both are frequently congested. Instead of discussing the fact there is no functioning market, no choice for the average end user, and how to fix it, we will now spend a ton of time arguing whether anything is wrong at all because Cogent did this. > > Wouldn't you rather be discussing whether 4 Mbps is really broadband? (Anyone else have flashbacks to "640K is enough for anyone!"?) Or how many people have more than one choice at 25 Mbps? Or whether a company with a terminating access monopoly can intentionally congest its edge to charge monopoly rents on the content providers their paying customers are trying to access? I know I would. > > Instead, we'll be talking about how things are not really bad, Cogent just made it look bad on purpose. The subtlety of "it _IS_ bad, Cogent just shifted some of the burden from VoIP to streaming" is not something that plays well in a 30 second sound bite, or at congressional hearings. > > It's enough to make one consider giving up the idea of having a functioning, useful Internet. > From owen at delong.com Thu Nov 6 18:10:21 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Nov 2014 10:10:21 -0800 Subject: Cogent admits to QoSing down streaming In-Reply-To: References: Message-ID: <9BFCA2CC-3ED0-4E77-97D5-FE0729DB88F6@delong.com> The way I read it was that Cogent actually made things look artificially better for M-Labs while simultaneously making it much worse for one subset of their users and somewhat better for others. I would suggest that if we get the educational process right, we should be able to explain that the point where you’re having to select traffic to prioritize is the point where your network is inadequate to the task at hand and should be upgraded. I don’t see any reason we shouldn’t be able to use this article as a prime example of a provider doing the wrong thing instead of fixing the real problem — Congestion at exchange points. Owen > On Nov 6, 2014, at 8:12 AM, Patrick W. Gilmore wrote: > > > > This is interesting. And it will be detrimental to network neutrality supporters. Cogent admits that while they were publicly complaining about other networks congesting links, they were using QoS to make the problem look worse. > > One of the problems in "tech" is most people do not realize tone is important, not just substance. There was - still is! - congestion in many places where consumers have one or at most two choice of providers. Even in places where there are two providers, both are frequently congested. Instead of discussing the fact there is no functioning market, no choice for the average end user, and how to fix it, we will now spend a ton of time arguing whether anything is wrong at all because Cogent did this. > > Wouldn't you rather be discussing whether 4 Mbps is really broadband? (Anyone else have flashbacks to "640K is enough for anyone!"?) Or how many people have more than one choice at 25 Mbps? Or whether a company with a terminating access monopoly can intentionally congest its edge to charge monopoly rents on the content providers their paying customers are trying to access? I know I would. > > Instead, we'll be talking about how things are not really bad, Cogent just made it look bad on purpose. The subtlety of "it _IS_ bad, Cogent just shifted some of the burden from VoIP to streaming" is not something that plays well in a 30 second sound bite, or at congressional hearings. > > It's enough to make one consider giving up the idea of having a functioning, useful Internet. > > -- > TTFN, > patrick From dorian at blackrose.org Thu Nov 6 18:16:13 2014 From: dorian at blackrose.org (Dorian Kim) Date: Thu, 6 Nov 2014 13:16:13 -0500 Subject: Cogent admits to QoSing down streaming In-Reply-To: <545BBA1B.4010906@ispn.net> References: <545BBA1B.4010906@ispn.net> Message-ID: <8CC26633-FBDD-4309-AA7A-C37DF448189E@blackrose.org> Personally I hope that such an environment never happens. Fast/slow lanes are pretty meaningless. Such service differentiation only has meaning when there’s persistent congestion and I’d rather that networks work out ways to scale past demand rather than throttle them. -dorian > On Nov 6, 2014, at 1:12 PM, Blake Hudson wrote: > > If I were a Cogent customer I would like to have seen more transparency (an announcement at least). However, I don't see anything wrong with their practice of giving some customers "Silver" service and others "Bronze" service while reserving "Gold" for themselves. Even if applications like VoIP do not function well with a Bronze service level. > > Now, a customer that was under the impression they were receiving equal treatment with other customers may not be happy to know they were receiving a lower class of service than expected. This is not a net neutrality matter, it's a matter of expectations and possibly false or deceptive advertising. > > I would much rather see an environment where the customer gets to choose Gold, Silver, and Bronze levels of service for his or her traffic as opposed to an environment where the provider chooses fast/slow lane applications at their own discretion. > > --Blake > > Patrick W. Gilmore wrote on 11/6/2014 10:12 AM: >> >> >> This is interesting. And it will be detrimental to network neutrality supporters. Cogent admits that while they were publicly complaining about other networks congesting links, they were using QoS to make the problem look worse. >> >> One of the problems in "tech" is most people do not realize tone is important, not just substance. There was - still is! - congestion in many places where consumers have one or at most two choice of providers. Even in places where there are two providers, both are frequently congested. Instead of discussing the fact there is no functioning market, no choice for the average end user, and how to fix it, we will now spend a ton of time arguing whether anything is wrong at all because Cogent did this. >> >> Wouldn't you rather be discussing whether 4 Mbps is really broadband? (Anyone else have flashbacks to "640K is enough for anyone!"?) Or how many people have more than one choice at 25 Mbps? Or whether a company with a terminating access monopoly can intentionally congest its edge to charge monopoly rents on the content providers their paying customers are trying to access? I know I would. >> >> Instead, we'll be talking about how things are not really bad, Cogent just made it look bad on purpose. The subtlety of "it _IS_ bad, Cogent just shifted some of the burden from VoIP to streaming" is not something that plays well in a 30 second sound bite, or at congressional hearings. >> >> It's enough to make one consider giving up the idea of having a functioning, useful Internet. >> From yanf787 at gmail.com Thu Nov 6 18:46:03 2014 From: yanf787 at gmail.com (Yan Filyurin) Date: Thu, 6 Nov 2014 13:46:03 -0500 Subject: TE offline tools In-Reply-To: References: <5455F1C5.4000605@noor.net> <5455F64E.3050802@noor.net> Message-ID: And Open Source tool called TOTEM (Toolbox of Traffic Engineering Methods) exists. It has not been maintained since 2008 and was done as a university research project. You can do some things with it that you can do with the likes of Cariden and WANDL and it takes XML files. It is a bit of a pain to use, but can be extended. Another Open Source tool with similar issues and no GUI is CSPF simulator, which runs some algorithms and you can give it topology and demands and it can give you optimal LSP placement. Again, requires a learning curve and was actually Cisco side project a while ago. And finally, if you can program, you can take Python NetworkX library which provides SPF algorithm, which can be adopted for CSPF and you can look up some popular algorithms on the Internet and implement them. And then use some tool to create graphs. But in reality Cariden and WANDL are actually pretty vendor agnostic, and you can easily adapt them for anything. There are people who run Juniper networks and use Cariden and Cisco NSPs that use WANDL. And they are entering DC underlay world as well. They cost money, but you do get what you pay for. Yan On Sun, Nov 2, 2014 at 9:22 PM, Phil Bedard wrote: > You can look at tools like NS2/NS3 or OMNet++, but these are not going to > do what you want out of the box, they are a framework for network > simulation but you'll have to program them to do what you want, they are > more used in academic settings. > > If you want a nice interface you are kind of stuck right now with the > commercial offerings from Cariden, OpNet, WANDL (now Juniper), and Aria > Networks. Most of those packages are extensible via scripting if you want > to do additional things. > > > Phil > > On 11/2/14, 3:15 AM, "Mohamed Kamal" wrote: > > > > >I'm aware about the Cisco MATE software, but I'd prefer an open-source, > >vendor-agnostic one, something that in-house imporvements can also be > >achieved. > > > > On 11/2/2014 12:01 PM, mohamed Osama Saad Abo sree wrote: > >> You can use Caridan tool, Cisco own it currently and it does all the > >> computation needed and can draw your network topology > > > >Mohamed Kamal > >Core Network Engineer > > > > > From gary.buhrmaster at gmail.com Thu Nov 6 18:49:55 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 6 Nov 2014 18:49:55 +0000 Subject: Shipping bulk hardware via freight In-Reply-To: <6692.1415297270@turing-police.cc.vt.edu> References: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> <6692.1415297270@turing-police.cc.vt.edu> Message-ID: On Thu, Nov 6, 2014 at 6:07 PM, wrote: > On Wed, 05 Nov 2014 23:11:23 -0500, William Herrin said: > >> Ah yes, I recall watching them decommission the old Control Data Cyber 990 >> back at Georgia Tech. The mover slipped trying to get it on the liftgate >> and the whole cabinet dropped about a foot to the ground with a nice solid >> thud. > > I know of a case where somebody managed to drop an IBM Shark storage > array off a forklift. > > Amazingly enough, it still kinda sorta worked after that.... And in the "good ol' days" (before the shark, actually) the IBM CE assigned to your site would have worked day and night getting it to work (and had fun doing it), replacing every part one by one if needed while still wearing the white shirts. But I date myself. From web at typo.org Thu Nov 6 18:57:54 2014 From: web at typo.org (Wayne E Bouchard) Date: Thu, 6 Nov 2014 11:57:54 -0700 Subject: Cogent admits to QoSing down streaming In-Reply-To: <545BBA1B.4010906@ispn.net> References: <545BBA1B.4010906@ispn.net> Message-ID: <20141106185754.GA11872@wakko.typo.org> I agree. There's nothing wrong with it at all.... unless you claim you're not doing that and then do it secretly in order to forward an agenda. On Thu, Nov 06, 2014 at 12:12:43PM -0600, Blake Hudson wrote: > If I were a Cogent customer I would like to have seen more transparency > (an announcement at least). However, I don't see anything wrong with > their practice of giving some customers "Silver" service and others > "Bronze" service while reserving "Gold" for themselves. Even if > applications like VoIP do not function well with a Bronze service level. > > Now, a customer that was under the impression they were receiving equal > treatment with other customers may not be happy to know they were > receiving a lower class of service than expected. This is not a net > neutrality matter, it's a matter of expectations and possibly false or > deceptive advertising. > > I would much rather see an environment where the customer gets to choose > Gold, Silver, and Bronze levels of service for his or her traffic as > opposed to an environment where the provider chooses fast/slow lane > applications at their own discretion. > > --Blake > > Patrick W. Gilmore wrote on 11/6/2014 10:12 AM: > > > > > >This is interesting. And it will be detrimental to network neutrality > >supporters. Cogent admits that while they were publicly complaining about > >other networks congesting links, they were using QoS to make the problem > >look worse. > > > >One of the problems in "tech" is most people do not realize tone is > >important, not just substance. There was - still is! - congestion in many > >places where consumers have one or at most two choice of providers. Even > >in places where there are two providers, both are frequently congested. > >Instead of discussing the fact there is no functioning market, no choice > >for the average end user, and how to fix it, we will now spend a ton of > >time arguing whether anything is wrong at all because Cogent did this. > > > >Wouldn't you rather be discussing whether 4 Mbps is really broadband? > >(Anyone else have flashbacks to "640K is enough for anyone!"?) Or how many > >people have more than one choice at 25 Mbps? Or whether a company with a > >terminating access monopoly can intentionally congest its edge to charge > >monopoly rents on the content providers their paying customers are trying > >to access? I know I would. > > > >Instead, we'll be talking about how things are not really bad, Cogent just > >made it look bad on purpose. The subtlety of "it _IS_ bad, Cogent just > >shifted some of the burden from VoIP to streaming" is not something that > >plays well in a 30 second sound bite, or at congressional hearings. > > > >It's enough to make one consider giving up the idea of having a > >functioning, useful Internet. > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From amitchell at isipp.com Thu Nov 6 20:21:29 2014 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 6 Nov 2014 13:21:29 -0700 Subject: Need Contacts at ISPs and ESPs in Ireland Message-ID: All, I'm currently in Ireland, and would very much like to connect with both ISPs and ESPs while I'm here. Any contacts that you can pass along would be greatly appreciated! Anne Anne P. Mitchell, Esq. CEO/President ISIPP SuretyMail Email Accreditation & Certification Author: Section 6 of the Federal CAN-SPAM Act of 2003 Member, California Bar Cyberspace Law Committee Ret. Professor of Law, Lincoln Law School of San Jose https://www.linkedin.com/in/annemitchell 303-731-2121 | amitchell at isipp.com | @AnnePMitchell | Facebook/AnnePMitchell From blake at ispn.net Thu Nov 6 20:32:44 2014 From: blake at ispn.net (Blake Hudson) Date: Thu, 06 Nov 2014 14:32:44 -0600 Subject: Cogent admits to QoSing down streaming In-Reply-To: <9BFCA2CC-3ED0-4E77-97D5-FE0729DB88F6@delong.com> References: <9BFCA2CC-3ED0-4E77-97D5-FE0729DB88F6@delong.com> Message-ID: <545BDAEC.6080604@ispn.net> Owen, should providers be able to over subscribe their networks? If so, at what tier level (tier 1, 2, 3, residential ISP)? Is it acceptable for a provider to permit frequent congestion if they choose to? Or should they be forced to take action that may (potentially) lead to increased customer rates or reduced customer bandwidth? I do think that Cogent's customers likely expect to receive their full subscription rate, without congestion, nearly 100% of the time (at least within the Cogent network). This would mean that having congestion is a problem and QoS is not a solution to congestion. However, I don't think all customers of all IP transit providers have this expectation. For example, residential customers may be happy with "up to X Mbps" if the costs associated are 1/10th that of a "guaranteed X Mbps" service. This is essentially the difference between "Bronze" and "Silver" service levels. As long as market choice exists, I see no problem with a provider choosing to operate a slow, inconsistent, or unreliable network as long as the internet as a whole, being a piece of critical communications infrastructure, remains available and reliable. Effectively, this would mean that tier 1 and 2 transit providers (including Cogent) would need to be consistent and reliable. While regional transit providers and ISPs would be given much more flexibility. Regardless, I think letting transit providers/ISPs pick winners and losers is a losing strategy in the long term. --Blake Owen DeLong wrote on 11/6/2014 12:10 PM: > The way I read it was that Cogent actually made things look artificially better for M-Labs while simultaneously making it much worse for one subset of their users and somewhat better for others. > > I would suggest that if we get the educational process right, we should be able to explain that the point where you’re having to select traffic to prioritize is the point where your network is inadequate to the task at hand and should be upgraded. > > I don’t see any reason we shouldn’t be able to use this article as a prime example of a provider doing the wrong thing instead of fixing the real problem — Congestion at exchange points. > > Owen > >> On Nov 6, 2014, at 8:12 AM, Patrick W. Gilmore wrote: >> >> >> >> This is interesting. And it will be detrimental to network neutrality supporters. Cogent admits that while they were publicly complaining about other networks congesting links, they were using QoS to make the problem look worse. >> >> One of the problems in "tech" is most people do not realize tone is important, not just substance. There was - still is! - congestion in many places where consumers have one or at most two choice of providers. Even in places where there are two providers, both are frequently congested. Instead of discussing the fact there is no functioning market, no choice for the average end user, and how to fix it, we will now spend a ton of time arguing whether anything is wrong at all because Cogent did this. >> >> Wouldn't you rather be discussing whether 4 Mbps is really broadband? (Anyone else have flashbacks to "640K is enough for anyone!"?) Or how many people have more than one choice at 25 Mbps? Or whether a company with a terminating access monopoly can intentionally congest its edge to charge monopoly rents on the content providers their paying customers are trying to access? I know I would. >> >> Instead, we'll be talking about how things are not really bad, Cogent just made it look bad on purpose. The subtlety of "it _IS_ bad, Cogent just shifted some of the burden from VoIP to streaming" is not something that plays well in a 30 second sound bite, or at congressional hearings. >> >> It's enough to make one consider giving up the idea of having a functioning, useful Internet. >> >> -- >> TTFN, >> patrick From nanog at nq4i.com Thu Nov 6 21:04:33 2014 From: nanog at nq4i.com (Bobby Lacey) Date: Thu, 6 Nov 2014 16:04:33 -0500 Subject: SFPs in Seattle Message-ID: Sorry for the bandwidth, but we're kind of in a desperate situation to find two HP single mode SFPs. We ordered some yesterday, but it's looking like they won't be delivered today. Would anyone in the Seattle KeyArena area be able to help? If you think you could help today, could you please call Vick @ (404) 561-2608 Thanks for any help! Bobby From streiner at cluebyfour.org Thu Nov 6 22:44:02 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 6 Nov 2014 17:44:02 -0500 (EST) Subject: Cogent admits to QoSing down streaming In-Reply-To: <545BDAEC.6080604@ispn.net> References: <9BFCA2CC-3ED0-4E77-97D5-FE0729DB88F6@delong.com> <545BDAEC.6080604@ispn.net> Message-ID: On Thu, 6 Nov 2014, Blake Hudson wrote: > Owen, should providers be able to over subscribe their networks? If so, at > what tier level (tier 1, 2, 3, residential ISP)? Is it acceptable for a > provider to permit frequent congestion if they choose to? Or should they be > forced to take action that may (potentially) lead to increased customer rates > or reduced customer bandwidth? Tier levels are marketing terms - irrelevant to technical/operational discussions. Every provider oversubscribes to some level, whether they're in the last mile serving residential users, or a carrier of carriers. It's just a question of what amount of oversubscription is acceptable, and what the risks are when customers blow that oversubscription model out of the water, either in the short term (streaming major sporting events, etc), or in the longer term (increased prevalence of streaming video, rich content, etc). Congestion due to short-term spikes is often seen as an acceptable risk. Congestion due to long-term shifts in customer network usage habits requires the oversubscription model to be re-worked, or the provider (and by extension... their customers) accepts a reputation of not dealing proactively with congestion. jms From owen at delong.com Thu Nov 6 23:55:44 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 6 Nov 2014 15:55:44 -0800 Subject: Cogent admits to QoSing down streaming In-Reply-To: <545BDAEC.6080604@ispn.net> References: <9BFCA2CC-3ED0-4E77-97D5-FE0729DB88F6@delong.com> <545BDAEC.6080604@ispn.net> Message-ID: <5558738F-48CC-4285-8EE2-AECC7A99CD5C@delong.com> > On Nov 6, 2014, at 12:32 PM, Blake Hudson wrote: > > Owen, should providers be able to over subscribe their networks? If so, at what tier level (tier 1, 2, 3, residential ISP)? Is it acceptable for a provider to permit frequent congestion if they choose to? Or should they be forced to take action that may (potentially) lead to increased customer rates or reduced customer bandwidth? Oversubscribe, of course. Overrun with persistent congestion, no. 1. Yes. 2. Any. 3. No, not really. 4. Yes. > I do think that Cogent's customers likely expect to receive their full subscription rate, without congestion, nearly 100% of the time (at least within the Cogent network). This would mean that having congestion is a problem and QoS is not a solution to congestion. However, I don't think all customers of all IP transit providers have this expectation. For example, residential customers may be happy with "up to X Mbps" if the costs associated are 1/10th that of a "guaranteed X Mbps" service. This is essentially the difference between "Bronze" and "Silver" service levels. As long as market choice exists, I see no problem with a provider choosing to operate a slow, inconsistent, or unreliable network as long as the internet as a whole, being a piece of critical communications infrastructure, remains available and reliable. Effectively, this would mean that tier 1 and 2 transit providers (including Cogent) would need to be consistent and reliable. While regional transit providers and ISPs would be given much more flexibility. Regardless, I think letting transit providers/ISPs pick winners and losers is a losing strategy in the long term. Cogent is not a residential ISP. They are a business to business provider. As such, it should be possible to assume that their customers reasonably understand what they are buying and if they do not, the rules of caveat emptor should apply. Cogent’s failure to upgrade their peering (and their generally poor attitude towards peering overall) are one issue. The bigger issue in this discussion is their lack of transparency in secretly prioritizing traffic in order to further an agenda. IMHO, such conduct is unethical at best. Owen > > --Blake > > Owen DeLong wrote on 11/6/2014 12:10 PM: >> The way I read it was that Cogent actually made things look artificially better for M-Labs while simultaneously making it much worse for one subset of their users and somewhat better for others. >> >> I would suggest that if we get the educational process right, we should be able to explain that the point where you’re having to select traffic to prioritize is the point where your network is inadequate to the task at hand and should be upgraded. >> >> I don’t see any reason we shouldn’t be able to use this article as a prime example of a provider doing the wrong thing instead of fixing the real problem — Congestion at exchange points. >> >> Owen >> >>> On Nov 6, 2014, at 8:12 AM, Patrick W. Gilmore wrote: >>> >>> >>> >>> This is interesting. And it will be detrimental to network neutrality supporters. Cogent admits that while they were publicly complaining about other networks congesting links, they were using QoS to make the problem look worse. >>> >>> One of the problems in "tech" is most people do not realize tone is important, not just substance. There was - still is! - congestion in many places where consumers have one or at most two choice of providers. Even in places where there are two providers, both are frequently congested. Instead of discussing the fact there is no functioning market, no choice for the average end user, and how to fix it, we will now spend a ton of time arguing whether anything is wrong at all because Cogent did this. >>> >>> Wouldn't you rather be discussing whether 4 Mbps is really broadband? (Anyone else have flashbacks to "640K is enough for anyone!"?) Or how many people have more than one choice at 25 Mbps? Or whether a company with a terminating access monopoly can intentionally congest its edge to charge monopoly rents on the content providers their paying customers are trying to access? I know I would. >>> >>> Instead, we'll be talking about how things are not really bad, Cogent just made it look bad on purpose. The subtlety of "it _IS_ bad, Cogent just shifted some of the burden from VoIP to streaming" is not something that plays well in a 30 second sound bite, or at congressional hearings. >>> >>> It's enough to make one consider giving up the idea of having a functioning, useful Internet. >>> >>> -- >>> TTFN, >>> patrick From larrysheldon at cox.net Fri Nov 7 03:43:29 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 06 Nov 2014 21:43:29 -0600 Subject: Shipping bulk hardware via freight In-Reply-To: References: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> Message-ID: <545C3FE1.1030000@cox.net> On 11/6/2014 12:07, Valdis.Kletnieks at vt.edu wrote: > On Wed, 05 Nov 2014 23:11:23 -0500, William Herrin said: > >> Ah yes, I recall watching them decommission the old Control Data Cyber 990 >> back at Georgia Tech. The mover slipped trying to get it on the liftgate >> and the whole cabinet dropped about a foot to the ground with a nice solid >> thud. > > I know of a case where somebody managed to drop an IBM Shark storage > array off a forklift. > > Amazingly enough, it still kinda sorta worked after that.... I no longer can recall the name of the company (his trucks were United Fan Lines colors but he had split off or something and had a license to use the colors)--all he (and crew) did was big computers. In the years I dealt with him the highlights were a) the time he and crew loaded a 1783 Drum (Several thousand pounds, I think, and top-heavy) into a truck parked against the curb or a street that has a moderately radical slope. Rolling it off the lift gate they lost it and it slammed against the down-hill wall pretty sternly. The truck tilted a bit into the street light pole which made the pole whip, flinging the glass cover down on the truck. Activity eventually stopped with the truck leaning (and immobilized) against the pole. I don't remember the resolution. b) the time they Johnson-barred an 1110 CPU into an open hole in the raised floor. Seems like the ripped out a lot of floor before deciding the strategy was not working. Seems like the used several Rol-a-lifts, a lot of canvas strapping and Johnson Bar handles recovering it. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From carlos at race.com Fri Nov 7 07:31:18 2014 From: carlos at race.com (Carlos Alcantar) Date: Fri, 7 Nov 2014 07:31:18 +0000 Subject: Shipping bulk hardware via freight In-Reply-To: <545C3FE1.1030000@cox.net> References: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> <545C3FE1.1030000@cox.net> Message-ID: I really wish we could do emoji¹s in email. Totally fitting! http://www.iemoji.com/view/emoji/26/people/face-with-tears-of-joy Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com On 11/6/14, 7:43 PM, "Larry Sheldon" wrote: >On 11/6/2014 12:07, Valdis.Kletnieks at vt.edu wrote: >> On Wed, 05 Nov 2014 23:11:23 -0500, William Herrin said: >> >>> Ah yes, I recall watching them decommission the old Control Data Cyber >>>990 >>> back at Georgia Tech. The mover slipped trying to get it on the >>>liftgate >>> and the whole cabinet dropped about a foot to the ground with a nice >>>solid >>> thud. >> >> I know of a case where somebody managed to drop an IBM Shark storage >> array off a forklift. >> >> Amazingly enough, it still kinda sorta worked after that.... > >I no longer can recall the name of the company (his trucks were United >Fan Lines colors but he had split off or something and had a license to >use the colors)--all he (and crew) did was big computers. > >In the years I dealt with him the highlights were a) the time he and >crew loaded a 1783 Drum (Several thousand pounds, I think, and >top-heavy) into a truck parked against the curb or a street that has a >moderately radical slope. Rolling it off the lift gate they lost it and >it slammed against the down-hill wall pretty sternly. The truck tilted >a bit into the street light pole which made the pole whip, flinging the >glass cover down on the truck. Activity eventually stopped with the >truck leaning (and immobilized) against the pole. I don't remember the >resolution. > > >b) the time they Johnson-barred an 1110 CPU into an open hole in the >raised floor. Seems like the ripped out a lot of floor before deciding >the strategy was not working. Seems like the used several Rol-a-lifts, >a lot of canvas strapping and Johnson Bar handles recovering it. > > > >-- >The unique Characteristics of System Administrators: > >The fact that they are infallible; and, > >The fact that they learn from their mistakes. > > >Quis custodiet ipsos custodes > From ahebert at pubnix.net Fri Nov 7 12:04:38 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 07 Nov 2014 07:04:38 -0500 Subject: Shipping bulk hardware via freight In-Reply-To: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> References: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> Message-ID: <545CB556.3020305@pubnix.net> On 11/05/14 13:02, Jason wrote: > I'm interested in talking with someone who has experience shipping hardware that has been pulled from a working environment. The assumption is that it would not use a normal carriers such as UPS of Fedex, but via private freight. > > Assuming that 20 x 1U switches and a handful of 10U chassis's were to be shipped, has anyone found a productive way to package them in something other than the boxes they come in? Has anyone tried to crate / pallet pack them or something more efficient? > > > If so, please contact me offline if you are willing to share your experience. > > > Jason Had a bunch (9) Dell C1100 shipped from Cali to Mtl on a 1/4 pallet thru UPS LTE. Cost barely $900 and 4h of import/export paperwork. To my surprise it arrived on a wooden pallet, which is fine... but each servers was just stacked on it, wrap with packing film, and 1 plastic strap and a bit of cardboard on the corners. I can only praise the driver and the handlers... none where beat up. TLDR: Shipping on pallet is fine, most carrier (at least the guys i dealt with) are professional, just do your own packing =D From cra at WPI.EDU Fri Nov 7 12:34:14 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 7 Nov 2014 07:34:14 -0500 Subject: outages list down? Lightower, Worcester, MA fiber cut Message-ID: <20141107123413.GM8489@angus.ind.WPI.EDU> I can't get to the mailing list page, and neither can downforeveryoneorjustme.com: http://downforeveryoneorjustme.com/puck.nether.net I've sent a couple new email messages there and they haven't been delivered either. Here is the latest message I sent regarding the Lightower, Worcester, MA fiber cut: Date: Fri, 7 Nov 2014 07:26:55 -0500 From: Chuck Anderson To: outages at outages.org Subject: Re: [outages] Lightower, Worcester, MA fiber cut Update as of 06:05:16 -0500: "Status has remained the same Lightower has two (2) 288 cables that were burnt through in a National Grid enclosure. National Grid has informed us that there is an exposed high tension power line in this enclosure and there will be no access granted in the near future. National Grid has deemed this manhole unsafe at this time. Lightower is working on an alternate solution that will re-route fibers around the affected man hole still NO ETTR at this time. We apologize for this inconvenience." On Fri, Nov 07, 2014 at 04:04:27AM -0500, Chuck Anderson wrote: > Updates as of 01:41:40 -0500 and 02:58:11 -0500: > > "We have two (2) 288 cables that were burnt through in this National > Grid enclosure. National Grid has informed us that there is an exposed > high tension power line in this enclosure and there will no access > granted in the near future. National Grid has deemed this manhole > unsafe at this time. Lightower is working on an alternate solution > that will re-route fibers around the affected man hole. NO ETTR at > this time." > > My initial outage time was exactly 18:58:54 EST on two circuits. > > On Thu, Nov 06, 2014 at 08:49:16PM -0500, Chuck Anderson via Outages wrote: > > We lost several dark fiber circuits out of Lightower in Worcester, MA. > > There is a manhole fire down the street at Main St. & Highland > > St. that is most likely the cause. Smoke is billowing out of several > > manholes. NGrid, NStar, police & fire are on the scene. Lightower > > has dispatched techs. No ETR yet. > > > > One other of my circuits that leaves the building via a diverse path > > is still up luckily, or we'd be off the net entirely. From jared at puck.nether.net Fri Nov 7 13:43:57 2014 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 7 Nov 2014 08:43:57 -0500 Subject: outages list down? Lightower, Worcester, MA fiber cut In-Reply-To: <20141107123413.GM8489@angus.ind.WPI.EDU> References: <20141107123413.GM8489@angus.ind.WPI.EDU> Message-ID: <7AD38715-F2CA-478E-A7BC-26567845679A@puck.nether.net> RFO: underlying filesystem issues on the hypervisor caused the system to “freak out” (yes, that’s the technical term). After a reboot, some fighting with java iKVM the system is back up. Sorry for the trouble. OT: (you can delete if you don’t care about my random stuff) I have some bigger plans to start to split the various parts of puck into more distributed systems (e.g.: DNS services, mail lists, etc) of time, including the various open.*project sites and databases). Last hardware refresh was in fall of 2011, so with the falling prices of SSD, etc it’s likely time to transition. - Jared > On Nov 7, 2014, at 7:34 AM, Chuck Anderson wrote: > > I can't get to the mailing list page, and neither can > downforeveryoneorjustme.com: > > http://downforeveryoneorjustme.com/puck.nether.net > > I've sent a couple new email messages there and they haven't been > delivered either. > > Here is the latest message I sent regarding the Lightower, Worcester, > MA fiber cut: > > Date: Fri, 7 Nov 2014 07:26:55 -0500 > From: Chuck Anderson > To: outages at outages.org > Subject: Re: [outages] Lightower, Worcester, MA fiber cut > > Update as of 06:05:16 -0500: > > "Status has remained the same Lightower has two (2) 288 cables that > were burnt through in a National Grid enclosure. National Grid has > informed us that there is an exposed high tension power line in this > enclosure and there will be no access granted in the near > future. National Grid has deemed this manhole unsafe at this > time. Lightower is working on an alternate solution that will re-route > fibers around the affected man hole still NO ETTR at this time. We > apologize for this inconvenience." > > On Fri, Nov 07, 2014 at 04:04:27AM -0500, Chuck Anderson wrote: >> Updates as of 01:41:40 -0500 and 02:58:11 -0500: >> >> "We have two (2) 288 cables that were burnt through in this National >> Grid enclosure. National Grid has informed us that there is an exposed >> high tension power line in this enclosure and there will no access >> granted in the near future. National Grid has deemed this manhole >> unsafe at this time. Lightower is working on an alternate solution >> that will re-route fibers around the affected man hole. NO ETTR at >> this time." >> >> My initial outage time was exactly 18:58:54 EST on two circuits. >> >> On Thu, Nov 06, 2014 at 08:49:16PM -0500, Chuck Anderson via Outages wrote: >>> We lost several dark fiber circuits out of Lightower in Worcester, MA. >>> There is a manhole fire down the street at Main St. & Highland >>> St. that is most likely the cause. Smoke is billowing out of several >>> manholes. NGrid, NStar, police & fire are on the scene. Lightower >>> has dispatched techs. No ETR yet. >>> >>> One other of my circuits that leaves the building via a diverse path >>> is still up luckily, or we'd be off the net entirely. From cscora at apnic.net Fri Nov 7 18:12:01 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 Nov 2014 04:12:01 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201411071812.sA7IC1Cd031739@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 08 Nov, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 523431 Prefixes after maximum aggregation: 199835 Deaggregation factor: 2.62 Unique aggregates announced to Internet: 253728 Total ASes present in the Internet Routing Table: 48493 Prefixes per ASN: 10.79 Origin-only ASes present in the Internet Routing Table: 36280 Origin ASes announcing only one prefix: 16320 Transit ASes present in the Internet Routing Table: 6192 Transit-only ASes present in the Internet Routing Table: 169 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 68 Max AS path prepend of ASN ( 55644) 61 Prefixes from unregistered ASNs in the Routing Table: 1788 Unregistered ASNs in the Routing Table: 434 Number of 32-bit ASNs allocated by the RIRs: 7832 Number of 32-bit ASNs visible in the Routing Table: 6021 Prefixes from 32-bit ASNs in the Routing Table: 21417 Number of bogon 32-bit ASNs visible in the Routing Table: 5 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 371 Number of addresses announced to Internet: 2713875332 Equivalent to 161 /8s, 194 /16s and 115 /24s Percentage of available address space announced: 73.3 Percentage of allocated address space announced: 73.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.9 Total number of prefixes smaller than registry allocations: 177009 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 133276 Total APNIC prefixes after maximum aggregation: 36928 APNIC Deaggregation factor: 3.61 Prefixes being announced from the APNIC address blocks: 137306 Unique aggregates announced from the APNIC address blocks: 53553 APNIC Region origin ASes present in the Internet Routing Table: 4985 APNIC Prefixes per ASN: 27.54 APNIC Region origin ASes announcing only one prefix: 1198 APNIC Region transit ASes present in the Internet Routing Table: 866 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 68 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1160 Number of APNIC addresses announced to Internet: 737099840 Equivalent to 43 /8s, 239 /16s and 64 /24s Percentage of available APNIC address space announced: 86.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 172029 Total ARIN prefixes after maximum aggregation: 85452 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 173896 Unique aggregates announced from the ARIN address blocks: 81551 ARIN Region origin ASes present in the Internet Routing Table: 16391 ARIN Prefixes per ASN: 10.61 ARIN Region origin ASes announcing only one prefix: 6081 ARIN Region transit ASes present in the Internet Routing Table: 1705 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 251 Number of ARIN addresses announced to Internet: 1053335744 Equivalent to 62 /8s, 200 /16s and 160 /24s Percentage of available ARIN address space announced: 55.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 125663 Total RIPE prefixes after maximum aggregation: 63695 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 131171 Unique aggregates announced from the RIPE address blocks: 82803 RIPE Region origin ASes present in the Internet Routing Table: 17789 RIPE Prefixes per ASN: 7.37 RIPE Region origin ASes announcing only one prefix: 8177 RIPE Region transit ASes present in the Internet Routing Table: 2914 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3177 Number of RIPE addresses announced to Internet: 691660420 Equivalent to 41 /8s, 57 /16s and 230 /24s Percentage of available RIPE address space announced: 100.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 58707 Total LACNIC prefixes after maximum aggregation: 10832 LACNIC Deaggregation factor: 5.42 Prefixes being announced from the LACNIC address blocks: 67577 Unique aggregates announced from the LACNIC address blocks: 30704 LACNIC Region origin ASes present in the Internet Routing Table: 2376 LACNIC Prefixes per ASN: 28.44 LACNIC Region origin ASes announcing only one prefix: 656 LACNIC Region transit ASes present in the Internet Routing Table: 470 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1370 Number of LACNIC addresses announced to Internet: 168403968 Equivalent to 10 /8s, 9 /16s and 164 /24s Percentage of available LACNIC address space announced: 100.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12244 Total AfriNIC prefixes after maximum aggregation: 2884 AfriNIC Deaggregation factor: 4.25 Prefixes being announced from the AfriNIC address blocks: 13110 Unique aggregates announced from the AfriNIC address blocks: 4787 AfriNIC Region origin ASes present in the Internet Routing Table: 732 AfriNIC Prefixes per ASN: 17.91 AfriNIC Region origin ASes announcing only one prefix: 208 AfriNIC Region transit ASes present in the Internet Routing Table: 151 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 63 Number of AfriNIC addresses announced to Internet: 59895296 Equivalent to 3 /8s, 145 /16s and 238 /24s Percentage of available AfriNIC address space announced: 59.5 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5547 4190 71 China Education and Research 4766 2952 11584 925 Korea Telecom 17974 2825 903 77 PT Telekomunikasi Indonesia 7545 2441 336 126 TPG Telecom Limited 4755 1915 411 187 TATA Communications formerly 9829 1671 1322 37 National Internet Backbone 4812 1520 2098 109 China Telecom (Group) 9808 1478 6639 15 Guangdong Mobile Communicatio 4808 1423 2213 429 CNCGROUP IP network China169 9583 1362 112 561 Sify Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2894 3688 51 BellSouth.net Inc. 22773 2851 2956 144 Cox Communications Inc. 18566 2045 379 184 MegaPath Corporation 7029 2000 1960 317 Windstream Communications Inc 20115 1819 1797 476 Charter Communications 4323 1636 1052 409 tw telecom holdings, inc. 6983 1581 867 250 ITC^Deltacom 30036 1488 309 611 Mediacom Communications Corp 701 1428 11265 708 MCI Communications Services, 22561 1313 409 242 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 34984 1842 298 356 TELLCOM ILETISIM HIZMETLERI A 20940 1496 579 1104 Akamai International B.V. 8402 1328 544 15 OJSC "Vimpelcom" 31148 1045 45 21 Freenet Ltd. 13188 1028 100 36 TOV "Bank-Inform" 8551 952 373 43 Bezeq International-Ltd 6849 829 356 26 JSC "Ukrtelecom" 9198 798 346 32 JSC Kazakhtelecom 6830 790 2339 437 Liberty Global Operations B.V 12479 765 786 96 France Telecom Espana SA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3032 493 237 Telmex Colombia S.A. 28573 2500 2317 107 NET Servi�os de Comunica��o S 7303 1766 1171 241 Telecom Argentina S.A. 6147 1713 374 30 Telefonica del Peru S.A.A. 8151 1480 3021 426 Uninet S.A. de C.V. 6503 1203 433 58 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 914 2325 35 Tim Celular S.A. 27947 909 130 52 Telconet S.A 3816 891 383 149 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1395 958 13 TE-AS 24863 958 280 26 Link Egypt (Link.NET) 6713 680 763 35 Office National des Postes et 36992 359 824 29 ETISALAT MISR 24835 308 144 9 Vodafone Data 3741 249 920 212 Internet Solutions 29571 245 22 17 Cote d'Ivoire Telecom 37054 233 19 6 Data Telecom Service 37457 187 161 7 Telkom SA Ltd. 36947 179 807 13 Telecom Algeria Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5547 4190 71 China Education and Research 10620 3032 493 237 Telmex Colombia S.A. 4766 2952 11584 925 Korea Telecom 6389 2894 3688 51 BellSouth.net Inc. 22773 2851 2956 144 Cox Communications Inc. 17974 2825 903 77 PT Telekomunikasi Indonesia 28573 2500 2317 107 NET Servi�os de Comunica��o S 7545 2441 336 126 TPG Telecom Limited 18566 2045 379 184 MegaPath Corporation 7029 2000 1960 317 Windstream Communications Inc Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2894 2843 BellSouth.net Inc. 10620 3032 2795 Telmex Colombia S.A. 17974 2825 2748 PT Telekomunikasi Indonesia 22773 2851 2707 Cox Communications Inc. 28573 2500 2393 NET Servi�os de Comunica��o S 7545 2441 2315 TPG Telecom Limited 4766 2952 2027 Korea Telecom 18566 2045 1861 MegaPath Corporation 4755 1915 1728 TATA Communications formerly 7029 2000 1683 Windstream Communications Inc Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.252.224.0/20 62502 Xnet Media LLC 23.252.224.0/21 62502 Xnet Media LLC 23.252.232.0/21 62502 Xnet Media LLC 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:31 /11:90 /12:262 /13:500 /14:1012 /15:1718 /16:13041 /17:7249 /18:12076 /19:25510 /20:36567 /21:38018 /22:55828 /23:49160 /24:279415 /25:1101 /26:1059 /27:705 /28:17 /29:19 /30:11 /31:1 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2065 2851 Cox Communications Inc. 18566 2000 2045 MegaPath Corporation 6389 1674 2894 BellSouth.net Inc. 30036 1335 1488 Mediacom Communications Corp 6147 1333 1713 Telefonica del Peru S.A.A. 6983 1266 1581 ITC^Deltacom 7029 1219 2000 Windstream Communications Inc 34984 1162 1842 TELLCOM ILETISIM HIZMETLERI A 11492 1144 1195 CABLE ONE, INC. 10620 1067 3032 Telmex Colombia S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1348 2:677 3:3 4:16 5:1193 6:21 8:772 12:1838 13:4 14:1183 15:17 16:2 17:42 18:21 20:51 23:957 24:1754 27:1817 31:1342 32:40 33:2 34:5 36:157 37:1817 38:1012 39:15 40:238 41:2955 42:348 43:603 44:20 45:80 46:2062 47:28 49:749 50:799 52:12 54:59 55:4 56:8 57:32 58:1197 59:717 60:438 61:1737 62:1242 63:1837 64:4415 65:2284 66:4182 67:2045 68:1092 69:3234 70:876 71:486 72:1986 74:2601 75:374 76:398 77:1603 78:901 79:773 80:1323 81:1287 82:807 83:663 84:713 85:1362 86:429 87:1172 88:500 89:1809 90:138 91:5812 92:804 93:1656 94:1929 95:1303 96:426 97:340 98:1091 99:48 100:67 101:783 103:6058 104:527 105:163 106:187 107:710 108:599 109:1984 110:1069 111:1443 112:733 113:900 114:800 115:1246 116:1213 117:1010 118:1587 119:1373 120:449 121:1021 122:2216 123:1699 124:1477 125:1601 128:644 129:387 130:377 131:933 132:422 133:164 134:322 135:82 136:325 137:317 138:385 139:202 140:229 141:419 142:598 143:445 144:512 145:110 146:676 147:555 148:1053 149:413 150:515 151:642 152:477 153:241 154:396 155:623 156:381 157:331 158:279 159:928 160:332 161:608 162:1856 163:371 164:648 165:669 166:363 167:690 168:1128 169:120 170:1428 171:215 172:60 173:1649 174:699 175:609 176:1518 177:3727 178:2087 179:812 180:1808 181:1809 182:1695 183:565 184:711 185:2321 186:2981 187:1659 188:2019 189:1538 190:7942 191:795 192:7748 193:5562 194:4048 195:3628 196:1662 197:795 198:5321 199:5482 200:6472 201:2910 202:9604 203:9016 204:4681 205:2665 206:3025 207:2962 208:3922 209:3799 210:3657 211:2035 212:2424 213:2197 214:861 215:84 216:5648 217:1710 218:718 219:549 220:1295 221:770 222:685 223:617 End of report From bzs at world.std.com Fri Nov 7 19:09:26 2014 From: bzs at world.std.com (Barry Shein) Date: Fri, 7 Nov 2014 14:09:26 -0500 Subject: Shipping bulk hardware via freight In-Reply-To: <545C3FE1.1030000@cox.net> References: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> <545C3FE1.1030000@cox.net> Message-ID: <21597.6374.484817.466622@world.std.com> I remember when we got our SGI Challenge XL delivered. It was around 1200lbs and the trucker refused to do an inside delivery even though we'd specified that, we were on the second floor (up one flight of stairs tho a few more to get to the stairs.) Their excuse was that we didn't have a proper way to do that. That is, there were three steps before the elevator and whatever else they think of not to do it. So rather than fuss with them and leaving the $500K system on the sidewalk outside I called: Death Wish Movers They're a company in Boston which specializes in moving big pianos and similar. The Travel Channel (I think it was) made a reality series about them briefly. Four guys showed up and decided they didn't even want to use the elevator, too small or something. They just hauled that thing up the stairs with your usual ONE...TWO...THREE...LIFT! ONE...TWO...THREE...LIFT!... I forget the cost but it wasn't a lot, maybe $300? Needless to say I recommend them. http://www.deathwishpiano.com -b From bkain1 at ford.com Fri Nov 7 19:21:36 2014 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Fri, 7 Nov 2014 19:21:36 +0000 Subject: Shipping bulk hardware via freight In-Reply-To: <21597.6374.484817.466622@world.std.com> References: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> <545C3FE1.1030000@cox.net> <21597.6374.484817.466622@world.std.com> Message-ID: <7DB845D64966DC44A1CC592780539B4B0120ACCF@nafmbx47.exchange.ford.com> That has to be one of the funniest things I've ever seen -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Barry Shein Sent: Friday, November 07, 2014 2:09 PM To: Larry Sheldon Cc: nanog at nanog.org Subject: Re: Shipping bulk hardware via freight I remember when we got our SGI Challenge XL delivered. It was around 1200lbs and the trucker refused to do an inside delivery even though we'd specified that, we were on the second floor (up one flight of stairs tho a few more to get to the stairs.) Their excuse was that we didn't have a proper way to do that. That is, there were three steps before the elevator and whatever else they think of not to do it. So rather than fuss with them and leaving the $500K system on the sidewalk outside I called: Death Wish Movers They're a company in Boston which specializes in moving big pianos and similar. The Travel Channel (I think it was) made a reality series about them briefly. Four guys showed up and decided they didn't even want to use the elevator, too small or something. They just hauled that thing up the stairs with your usual ONE...TWO...THREE...LIFT! ONE...TWO...THREE...LIFT!... I forget the cost but it wasn't a lot, maybe $300? Needless to say I recommend them. http://www.deathwishpiano.com -b From patrick at ianai.net Fri Nov 7 19:32:07 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 7 Nov 2014 14:32:07 -0500 Subject: Shipping bulk hardware via freight In-Reply-To: <21597.6374.484817.466622@world.std.com> References: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> <545C3FE1.1030000@cox.net> <21597.6374.484817.466622@world.std.com> Message-ID: Holy crap. I've actually used Death Wish. Small world. They were awesome. Of course, I moved something far less interesting - a piano. But I called them on a Tuesday and said "I need a piano moved by 1 PM tomorrow". They did it, no fuss, no muss, very professional, and reasonably priced. Highly recommended. -- TTFN, patrick On Nov 07, 2014, at 14:09 , Barry Shein wrote: > > I remember when we got our SGI Challenge XL delivered. It was around > 1200lbs and the trucker refused to do an inside delivery even though > we'd specified that, we were on the second floor (up one flight of > stairs tho a few more to get to the stairs.) Their excuse was that we > didn't have a proper way to do that. That is, there were three steps > before the elevator and whatever else they think of not to do it. > > So rather than fuss with them and leaving the $500K system on the > sidewalk outside I called: > > Death Wish Movers > > They're a company in Boston which specializes in moving big pianos and > similar. The Travel Channel (I think it was) made a reality series > about them briefly. > > Four guys showed up and decided they didn't even want to use the > elevator, too small or something. > > They just hauled that thing up the stairs with your usual > ONE...TWO...THREE...LIFT! ONE...TWO...THREE...LIFT!... > > I forget the cost but it wasn't a lot, maybe $300? > > Needless to say I recommend them. > > http://www.deathwishpiano.com > > -b From Joshua_Sholes at cable.comcast.com Fri Nov 7 20:28:03 2014 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Fri, 7 Nov 2014 20:28:03 +0000 Subject: Shipping bulk hardware via freight In-Reply-To: <21597.6374.484817.466622@world.std.com> References: <149811eed1f.d20ad1a647405.1525029215402083936@tacorp.us> <545C3FE1.1030000@cox.net> <21597.6374.484817.466622@world.std.com> Message-ID: Back a few jobs ago, I had a similar problem with a trucker refusing to do inside delivery on a 5kVa UPS unit that clocked in around 450lbs, and my town didn't have any similar moving company willing to schlep that thing up two flights of stairs on no notice. However, it turns out that you can disassemble that particular model of 5kVa UPS into pieces such that the biggest one weighs a little over 200 lbs. It also apparently turns out I can carry a 200lb battery up two flights of stairs. I like to think I'm smarter now than I was then, on at least three specific counts. -- Josh On 11/7/14, 2:09 PM, "Barry Shein" wrote: > >I remember when we got our SGI Challenge XL delivered. It was around >1200lbs and the trucker refused to do an inside delivery even though >we'd specified that, we were on the second floor (up one flight of >stairs tho a few more to get to the stairs.) Their excuse was that we >didn't have a proper way to do that. That is, there were three steps >before the elevator and whatever else they think of not to do it. > >So rather than fuss with them and leaving the $500K system on the >sidewalk outside I called: > > Death Wish Movers > >They're a company in Boston which specializes in moving big pianos and >similar. The Travel Channel (I think it was) made a reality series >about them briefly. > >Four guys showed up and decided they didn't even want to use the >elevator, too small or something. > >They just hauled that thing up the stairs with your usual >ONE...TWO...THREE...LIFT! ONE...TWO...THREE...LIFT!... > >I forget the cost but it wasn't a lot, maybe $300? > >Needless to say I recommend them. > > http://www.deathwishpiano.com > > -b > From johnl at iecc.com Fri Nov 7 21:03:00 2014 From: johnl at iecc.com (John Levine) Date: 7 Nov 2014 21:03:00 -0000 Subject: Shipping bulk hardware via freight In-Reply-To: Message-ID: <20141107210300.8836.qmail@ary.lan> In article you write: >Holy crap. I've actually used Death Wish. Small world. > >They were awesome. If you have a typical old Boston house and a piano, there isn't much alternative. BTDT, John From cidr-report at potaroo.net Fri Nov 7 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Nov 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201411072200.sA7M00O8016054@wattle.apnic.net> This report has been generated at Fri Nov 7 21:14:21 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 31-10-14 525536 289154 01-11-14 527072 289170 02-11-14 526955 289137 03-11-14 526861 289197 04-11-14 526595 290028 05-11-14 526922 292340 06-11-14 536547 292355 07-11-14 528597 291942 AS Summary 48763 Number of ASes in routing system 19597 Number of ASes announcing only one prefix 5565 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center,CN 120193024 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 07Nov14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 529293 291876 237417 44.9% All ASes AS4538 5565 2047 3518 63.2% ERX-CERNET-BKB China Education and Research Network Center,CN AS6389 2894 116 2778 96.0% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2825 83 2742 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS22773 2854 164 2690 94.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS28573 2490 285 2205 88.6% NET Servi�os de Comunica��o S.A.,BR AS4766 2953 1333 1620 54.9% KIXS-AS-KR Korea Telecom,KR AS6147 1713 107 1606 93.8% Telefonica del Peru S.A.A.,PE AS10620 3032 1526 1506 49.7% Telmex Colombia S.A.,CO AS7303 1770 290 1480 83.6% Telecom Argentina S.A.,AR AS9808 1478 53 1425 96.4% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS8402 1310 27 1283 97.9% CORBINA-AS OJSC "Vimpelcom",RU AS4755 1913 640 1273 66.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS20115 1821 557 1264 69.4% CHARTER-NET-HKY-NC - Charter Communications,US AS4323 1644 411 1233 75.0% TWTC - tw telecom holdings, inc.,US AS7545 2454 1245 1209 49.3% TPG-INTERNET-AP TPG Telecom Limited,AU AS9498 1314 110 1204 91.6% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2044 869 1175 57.5% MEGAPATH5-US - MegaPath Corporation,US AS6983 1581 423 1158 73.2% ITCDELTA - Earthlink, Inc.,US AS7552 1208 53 1155 95.6% VIETEL-AS-AP Viettel Corporation,VN AS7029 2161 1132 1029 47.6% WINDSTREAM - Windstream Communications Inc,US AS34984 1843 824 1019 55.3% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS4812 1523 507 1016 66.7% CHINANET-SH-AP China Telecom (Group),CN AS22561 1313 362 951 72.4% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS38285 978 131 847 86.6% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4788 1092 250 842 77.1% TMNET-AS-AP TM Net, Internet Service Provider,MY AS24560 1182 350 832 70.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS31148 1045 261 784 75.0% FREENET-AS Freenet Ltd.,UA AS8151 1486 703 783 52.7% Uninet S.A. de C.V.,MX AS26615 914 133 781 85.4% Tim Celular S.A.,BR Total 57399 15075 42324 73.7% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.160.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.164.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.168.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.172.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.176.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.180.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.184.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.188.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.224.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.228.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.232.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.236.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.23.192.0/19 AS6939 HURRICANE - Hurricane Electric, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 68.170.160.0/20 AS6939 HURRICANE - Hurricane Electric, Inc.,US 70.34.48.0/20 AS6939 HURRICANE - Hurricane Electric, Inc.,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.220.84.0/24 AS5577 ROOT root SA,LU 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN 103.10.222.0/24 AS13189 103.14.231.0/24 AS58680 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.56.0/24 AS13239 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.228.132.0/22 AS4826 VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.251.244.0/22 AS55536 PSWITCH-HK Pacswitch Colocation & Datacentre,HK 104.232.192.0/19 AS62874 WEB2OBJECTS-LLC - Web2Objects LLC,US 104.237.48.0/20 AS18450 WEBNX - WebNX, Inc.,US 104.244.56.0/21 AS40193 AS-TRIT - Trit Networks, LLC,US 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.240.160.0/20 AS6939 HURRICANE - Hurricane Electric, Inc.,US 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.153.99.0/24 AS3313 INET-AS BT Italia S.p.A.,IT 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.6.0.0/24 AS32768 routability-tests,MU 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.254.0/24 AS32768 routability-tests,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.7.160.0/21 AS13703 BROADRIVER-13703 - BroadRiver Communication Corp.,US 199.7.162.0/24 AS22626 -Reserved AS-,ZZ 199.7.167.0/24 AS22626 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.116.212.0/22 AS53704 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.241.34.0/23 AS10970 LIGHTEDGE - LightEdge Solutions,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.161.184.0/24 AS9328 GLOBALCENTER-AU Datacom Victoria,AU 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.91.104.0/21 AS6939 HURRICANE - Hurricane Electric, Inc.,US 208.92.152.0/21 AS6939 HURRICANE - Hurricane Electric, Inc.,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 209.239.224.0/19 AS5033 AS5033 - Key Information Systems, Inc.,US 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.21.24.0/21 AS6939 HURRICANE - Hurricane Electric, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Nov 7 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Nov 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201411072200.sA7M011r016072@wattle.apnic.net> BGP Update Report Interval: 30-Oct-14 -to- 06-Nov-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14287 399233 9.1% 66538.8 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 2 - AS23752 198523 4.5% 1965.6 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS7545 172069 3.9% 80.5 -- TPG-INTERNET-AP TPG Telecom Limited,AU 4 - AS9829 161433 3.7% 145.4 -- BSNL-NIB National Internet Backbone,IN 5 - AS12897 143079 3.2% 4471.2 -- HEAGMEDIANET HSE Medianet GmbH,DE 6 - AS3816 49561 1.1% 96.6 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 7 - AS27738 32552 0.7% 41.7 -- Ecuadortelecom S.A.,EC 8 - AS3313 32485 0.7% 10828.3 -- INET-AS BT Italia S.p.A.,IT 9 - AS9808 30902 0.7% 26.5 -- CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN 10 - AS8402 28525 0.7% 53.6 -- CORBINA-AS OJSC "Vimpelcom",RU 11 - AS6713 27862 0.6% 44.4 -- IAM-AS,MA 12 - AS48159 27319 0.6% 98.6 -- TIC-AS Telecommunication Infrastructure Company,IR 13 - AS28573 25645 0.6% 17.6 -- NET Servi�os de Comunica��o S.A.,BR 14 - AS45899 25081 0.6% 57.0 -- VNPT-AS-VN VNPT Corp,VN 15 - AS23342 22220 0.5% 22220.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 16 - AS10620 20754 0.5% 8.4 -- Telmex Colombia S.A.,CO 17 - AS25003 19893 0.5% 1989.3 -- INTERNET_BINAT Internet Binat Ltd,IL 18 - AS4134 19833 0.5% 126.3 -- CHINANET-BACKBONE No.31,Jin-rong Street,CN 19 - AS13489 19479 0.4% 46.9 -- EPM Telecomunicaciones S.A. E.S.P.,CO 20 - AS22773 19470 0.4% 4.5 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14287 399233 9.1% 66538.8 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 2 - AS23342 22220 0.5% 22220.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 3 - AS61039 16767 0.4% 16767.0 -- ZMZ OAO ZMZ,RU 4 - AS18135 12424 0.3% 12424.0 -- BTV BTV Cable television,JP 5 - AS3313 32485 0.7% 10828.3 -- INET-AS BT Italia S.p.A.,IT 6 - AS47680 6477 0.1% 6477.0 -- NHCS EOBO Limited,IE 7 - AS3 18160 0.4% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 8 - AS62174 6033 0.1% 6033.0 -- INTERPAN-AS INTERPAN LTD.,BG 9 - AS24768 4849 0.1% 4849.0 -- ALMOUROLTEC ALMOUROLTEC SERVICOS DE INFORMATICA E INTERNET LDA,PT 10 - AS12897 143079 3.2% 4471.2 -- HEAGMEDIANET HSE Medianet GmbH,DE 11 - AS51314 4321 0.1% 4321.0 -- TEVIANT-AS LLC Joint Small Enterprise "Teviant",UA 12 - AS53823 3066 0.1% 3066.0 -- SMTA - Scio Mutual Telephone Association,US 13 - AS56636 2928 0.1% 2928.0 -- ASVEDARU VEDA Ltd.,RU 14 - AS60725 16553 0.4% 2758.8 -- O3B-AS O3b Limited,JE 15 - AS35093 4473 0.1% 2236.5 -- RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 16 - AS25003 19893 0.5% 1989.3 -- INTERNET_BINAT Internet Binat Ltd,IL 17 - AS23752 198523 4.5% 1965.6 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 18 - AS61051 1834 0.0% 1834.0 -- DEKARD Dekard LLC,RU 19 - AS3 1716 0.0% 5517.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 20 - AS47805 3355 0.1% 1677.5 -- MCIT Ministry of Communications and Information,SA TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 99367 2.2% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 98016 2.1% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 208.70.20.0/22 79857 1.7% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 4 - 208.78.116.0/22 79845 1.7% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 5 - 208.73.244.0/22 79843 1.7% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 6 - 208.88.232.0/22 79841 1.7% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 7 - 216.162.0.0/20 79841 1.7% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 8 - 64.29.130.0/24 22220 0.5% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 9 - 94.16.80.0/20 20461 0.4% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 10 - 185.9.28.0/22 20434 0.4% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 11 - 94.16.72.0/21 20433 0.4% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 12 - 94.16.64.0/21 20417 0.4% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 13 - 194.127.204.0/23 20402 0.4% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 14 - 194.99.108.0/23 20400 0.4% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 15 - 194.45.104.0/23 20368 0.4% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 16 - 192.115.44.0/22 19883 0.4% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 17 - 130.0.192.0/21 18136 0.4% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 18 - 91.235.169.0/24 16767 0.4% AS61039 -- ZMZ OAO ZMZ,RU 19 - 71.19.134.0/23 16604 0.4% AS3313 -- INET-AS BT Italia S.p.A.,IT 20 - 194.153.99.0/24 15878 0.3% AS3313 -- INET-AS BT Italia S.p.A.,IT Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From tknchris at gmail.com Fri Nov 7 23:24:07 2014 From: tknchris at gmail.com (chris) Date: Fri, 7 Nov 2014 18:24:07 -0500 Subject: Clueful Jive Communications Contact? Message-ID: Sorry for the noise but If anyone from Jive Communications is on the list or if anyone has any clueful technical contacts please contact me offlist. I have a very frustrated mutual customer we provide network services to who utilizes Jive for their voice and we can see that there is intermittent reachability problems and all attempts to go through normal support with the information we have provided are going nowhere. Thanks chris From andy at mbrez.com Sat Nov 8 04:40:46 2014 From: andy at mbrez.com (Andy Brezinsky) Date: Fri, 07 Nov 2014 22:40:46 -0600 Subject: NYC logistics issue Message-ID: <545D9ECE.8080601@mbrez.com> Due to a comedy of errors, I have a pallet of gear sitting in Elizabeth NJ that needs to get to the 9th floor of 60 Hudson by EOD Monday that can't seem to get delivered due to no company having a COI on file with the building. We did have UPS freight lined up to pick it up from the original shipper tonight and deliver it on Monday but there was an "issue" and the driver left without the pallet. Does have any contacts at courier companies that could possibly break down 600lbs of gear (48"x48"x44" pallet with 14 boxes ranging from 10 to 75lbs) at the warehouse and deliver it to the building? Any other suggestions for how to deal with this problem? Replies off-list are fine. Thanks in advance. -- Andy Brezinsky From Bryan at bryanfields.net Sat Nov 8 05:23:23 2014 From: Bryan at bryanfields.net (Bryan Fields) Date: Sat, 08 Nov 2014 00:23:23 -0500 Subject: Clueful Jive Communications Contact? In-Reply-To: References: Message-ID: <545DA8CB.8060706@bryanfields.net> On 11/7/14, 6:24 PM, chris wrote: > I have a very frustrated mutual customer we provide network services to who > utilizes Jive for their voice and we can see that there is intermittent > reachability problems and all attempts to go through normal support with > the information we have provided are going nowhere. Where's June Cleaver when you need her.. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From johnstong at westmancom.com Thu Nov 6 21:47:45 2014 From: johnstong at westmancom.com (Graham Johnston) Date: Thu, 6 Nov 2014 21:47:45 +0000 Subject: Chicago Colo and IX Message-ID: <49EE1A35457387418410F97564A3752B01364D6616@MSG6.westman.int> We are looking to expand our network and establish a POP in Chicago; it is expect that we will focus on 350 East Cermak. Can anyone provide recommendations on Colo providers? We will only really need enough space to deploy a modest router and the power it requires. As we won't be able to do work on site, given its remote location to us, a colo provider who provides a remote hands service is a requirement. I'm also curious if anyone can comment on the Equinix IX that is there. Our only experience today with an IX is with TorIX, which has been extremely positive, and I'm not sure what significant differences I should expect if any. Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. From twakefield at stcloudstate.edu Fri Nov 7 18:09:16 2014 From: twakefield at stcloudstate.edu (Wakefield, Thad M.) Date: Fri, 7 Nov 2014 18:09:16 +0000 Subject: Cisco CCNA Training In-Reply-To: <545968E7.8040806@gmail.com> References: <545968E7.8040806@gmail.com> Message-ID: Until midnight Monday this course is on sale for $24: https://www.udemy.com/collection/thankyou-400-24deal > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of scottie mac > Sent: Tuesday, November 04, 2014 6:02 PM > To: nanog at nanog.org > Subject: Re: Cisco CCNA Training > > This course has 25 hours of video, I haven't started it yet but I've watched > many of Laz's videos on Youtube, and he explains stuff very well. > It is $399 though. > They could share the Udemy account, and watch them in their free time. > *I'm not affiliated with Udemy* > > https://www.udemy.com/the-complete-ccna-200-120-course From srn.nanog at prgmr.com Fri Nov 7 18:56:47 2014 From: srn.nanog at prgmr.com (srn.nanog at prgmr.com) Date: Fri, 07 Nov 2014 10:56:47 -0800 Subject: Reporting DDOS reflection attacks Message-ID: <545D15EF.8080509@prgmr.com> Like most small providers, we occasionally get hit by DoS attacks. We got hammered by an SSDP reflection attack (udp port 1900) last week. We took a 27 second log and from there extracted about 160k unique IPs. It is really difficult to find abuse emails for 160k IPs. We know about abuse.net but abuse.net requires hostnames, not IPs for lookups and not all IP addresses have valid DNS entries. The only other way we know of to report problems is to grab the abuse email addresses is whois. However, whois is not structured and is not set up to deal with this number of requests - even caching whois data based on subnets will result in many thousands of lookups. Long term it seems like structured data and some kind of authentication would be ideal for reporting attacks. But right now how should we be doing it? From mstaudinger at elnk.com Fri Nov 7 23:49:31 2014 From: mstaudinger at elnk.com (Staudinger, Malcolm) Date: Fri, 7 Nov 2014 23:49:31 +0000 Subject: Contact @ harvard.edu? Message-ID: <46c492e99dcd484da72bc0d767a86c38@EDGMBXV05.marvel.elnk.net> If anyone from Harvard IT (preferably network/netsec, but I'll take anyone at this point) is on this list, please drop me a line regarding a DoS from your network. I haven't had any luck getting past your student help desk/ticket system. Malcolm Staudinger Information Security Analyst II | EIS EarthLink E: mstaudinger at elnk.com M: 360-936-5957 [http://www.earthlinkmarketingservices.com/email_logo_sm.png] From rdobbins at arbor.net Sat Nov 8 07:00:59 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 08 Nov 2014 14:00:59 +0700 Subject: Reporting DDOS reflection attacks In-Reply-To: <545D15EF.8080509@prgmr.com> References: <545D15EF.8080509@prgmr.com> Message-ID: <51804DD4-CB63-463B-BFB5-EF5679F744ED@arbor.net> On 8 Nov 2014, at 1:56, srn.nanog at prgmr.com wrote: > But right now how should we be doing it? ----------------------------------- Roland Dobbins From paul.w.bennett at gmail.com Sat Nov 8 07:20:05 2014 From: paul.w.bennett at gmail.com (Paul Bennett) Date: Sat, 8 Nov 2014 02:20:05 -0500 Subject: Reporting DDOS reflection attacks In-Reply-To: <51804DD4-CB63-463B-BFB5-EF5679F744ED@arbor.net> References: <545D15EF.8080509@prgmr.com> <51804DD4-CB63-463B-BFB5-EF5679F744ED@arbor.net> Message-ID: On Sat, Nov 8, 2014 at 2:00 AM, Roland Dobbins wrote: > > On 8 Nov 2014, at 1:56, srn.nanog at prgmr.com wrote: > >> But right now how should we be doing it? > > Once you get the ASN or at least the domain name of the ISP providing service to the reflecting host, several major reputable ISPs (including my employer, who I can't name because I'm not an official spokesperson) will welcome RFC 5070 "IODEF" reports for general network abuse and RFC 5965 "MARF" format for email abuse, directed to abuse@ the main domain for that ISP. http://www.ietf.org/rfc/rfc5070.txt http://www.ietf.org/rfc/rfc5965.txt -- Paul W Bennett From mcdonald.richards at gmail.com Sat Nov 8 10:09:54 2014 From: mcdonald.richards at gmail.com (McDonald Richards) Date: Sat, 8 Nov 2014 21:09:54 +1100 Subject: Reporting DDOS reflection attacks In-Reply-To: References: <545D15EF.8080509@prgmr.com> <51804DD4-CB63-463B-BFB5-EF5679F744ED@arbor.net> Message-ID: Out of curiosity, have any of you had luck reporting the sources of attacks to the admins of the origin ASNs? Any failure or success stories you can share? Macca On Sat, Nov 8, 2014 at 6:20 PM, Paul Bennett wrote: > On Sat, Nov 8, 2014 at 2:00 AM, Roland Dobbins wrote: > > > > On 8 Nov 2014, at 1:56, srn.nanog at prgmr.com wrote: > > > >> But right now how should we be doing it? > > > > > > Once you get the ASN or at least the domain name of the ISP providing > service to the reflecting host, several major reputable ISPs > (including my employer, who I can't name because I'm not an official > spokesperson) will welcome RFC 5070 "IODEF" reports for general > network abuse and RFC 5965 "MARF" format for email abuse, directed to > abuse@ the main domain for that ISP. > > http://www.ietf.org/rfc/rfc5070.txt > > http://www.ietf.org/rfc/rfc5965.txt > > > > -- > Paul W Bennett > From rdobbins at arbor.net Sat Nov 8 10:14:02 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 08 Nov 2014 17:14:02 +0700 Subject: Reporting DDOS reflection attacks In-Reply-To: References: <545D15EF.8080509@prgmr.com> <51804DD4-CB63-463B-BFB5-EF5679F744ED@arbor.net> Message-ID: On 8 Nov 2014, at 17:09, McDonald Richards wrote: > Any failure or success stories you can share? In my experience, it's the generally broadband access operators who will sometimes respond, when contacted about reflection/amplification attacks leveraging misconfigured, abusable CPE. Generally speaking, networks running misconfigured, abusable devices by definition aren't very actively managed - and so those operators don't often respond, unless one has personal contacts within the relevant group(s). YMMV, of course. ----------------------------------- Roland Dobbins From ruairi.carroll at gmail.com Sat Nov 8 11:30:54 2014 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Sat, 8 Nov 2014 11:30:54 +0000 Subject: Reporting DDOS reflection attacks In-Reply-To: <545D15EF.8080509@prgmr.com> References: <545D15EF.8080509@prgmr.com> Message-ID: Hey, We've been hit on/off with large scale amplification attacks over the last few years. We found looking up src ASN of the attack and reporting is not super helpful, as many blocks come from sub allocations and you'll just get redirected to someone else. This will just cause more overhead and legwork for you in the long run. Whois data *seems* to be a little more reliable, and there's an abuseEmail script out there that helps automate the abuse contact lookup ( http://abuseemail.sourceforge.net/ ). We've added a bit of logic in front of this to aggregate the flows per destination abuse email, then send a report with all listed flows + timestamp. Feel free to ping me offlist if you want some more info on this. /Ruairi On 7 November 2014 18:56, wrote: > Like most small providers, we occasionally get hit by DoS attacks. We got > hammered by an SSDP > reflection attack (udp port 1900) last week. We took a 27 second log and > from there extracted > about 160k unique IPs. > > It is really difficult to find abuse emails for 160k IPs. > > We know about abuse.net but abuse.net requires hostnames, not IPs for > lookups and not all IP > addresses have valid DNS entries. > > The only other way we know of to report problems is to grab the abuse > email addresses is whois. > However, whois is not structured and is not set up to deal with this > number of requests - even > caching whois data based on subnets will result in many thousands of > lookups. > > Long term it seems like structured data and some kind of authentication > would be ideal for reporting > attacks. But right now how should we be doing it? > From mfidelman at meetinghouse.net Sat Nov 8 13:50:15 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 08 Nov 2014 08:50:15 -0500 Subject: Reporting DDOS reflection attacks In-Reply-To: References: <545D15EF.8080509@prgmr.com> <51804DD4-CB63-463B-BFB5-EF5679F744ED@arbor.net> Message-ID: <545E1F97.10504@meetinghouse.net> I can offer an indirect story, and not quite a reflection attack, but a DDoS one. We happen to have a host that had an IPMI board exposed to the net, that got compromised, and became a vector for a DDoS attack. The target reported the attack to at least some of the sources, including Windstream/Hosted Solutions, where this particular server is located. They contacted me, and I dealt with things with about a 1-hour turn-around from when a trouble ticket hit my inbox (well, still dealing with things - that IPMI card is offline until I get around to securing it, and it's the occasional reboot-by-phone-call until then). So at least one small success. Miles Fidelman McDonald Richards wrote: > Out of curiosity, have any of you had luck reporting the sources of attacks > to the admins of the origin ASNs? > > Any failure or success stories you can share? > > Macca > > > On Sat, Nov 8, 2014 at 6:20 PM, Paul Bennett > wrote: > >> On Sat, Nov 8, 2014 at 2:00 AM, Roland Dobbins wrote: >>> On 8 Nov 2014, at 1:56, srn.nanog at prgmr.com wrote: >>> >>>> But right now how should we be doing it? >>> >> Once you get the ASN or at least the domain name of the ISP providing >> service to the reflecting host, several major reputable ISPs >> (including my employer, who I can't name because I'm not an official >> spokesperson) will welcome RFC 5070 "IODEF" reports for general >> network abuse and RFC 5965 "MARF" format for email abuse, directed to >> abuse@ the main domain for that ISP. >> >> http://www.ietf.org/rfc/rfc5070.txt >> >> http://www.ietf.org/rfc/rfc5965.txt >> >> >> >> -- >> Paul W Bennett >> -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From srn.nanog at prgmr.com Sat Nov 8 16:58:15 2014 From: srn.nanog at prgmr.com (srn.nanog at prgmr.com) Date: Sat, 08 Nov 2014 08:58:15 -0800 Subject: Reporting DDOS reflection attacks In-Reply-To: References: <545D15EF.8080509@prgmr.com> <51804DD4-CB63-463B-BFB5-EF5679F744ED@arbor.net> Message-ID: <545E4BA7.8060501@prgmr.com> On 11/07/2014 11:20 PM, Paul Bennett wrote: > On Sat, Nov 8, 2014 at 2:00 AM, Roland Dobbins wrote: >> >> On 8 Nov 2014, at 1:56, srn.nanog at prgmr.com wrote: >> >>> But right now how should we be doing it? >> >> > > Once you get the ASN or at least the domain name of the ISP providing > service to the reflecting host, several major reputable ISPs > (including my employer, who I can't name because I'm not an official > spokesperson) will welcome RFC 5070 "IODEF" reports for general > network abuse and RFC 5965 "MARF" format for email abuse, directed to > abuse@ the main domain for that ISP. > > http://www.ietf.org/rfc/rfc5070.txt > > http://www.ietf.org/rfc/rfc5965.txt Thanks, the IP->subnet/ASN lookup and rfc5070 look like exactly what we need to start with. I'm fairly certain it would have gotten us the same contact for all the IPs we reported last week. Since IODEF is so flexible, are there any exact guidelines or examples on how to use it to report a DDOS? For example, should there be a separate XML document for each prefix or one for the entire list? What I found was https://tools.ietf.org/html/draft-ietf-mile-iodef-guidance-03#page-21 but it could use some more explanation. From tknchris at gmail.com Sat Nov 8 17:24:37 2014 From: tknchris at gmail.com (chris) Date: Sat, 8 Nov 2014 12:24:37 -0500 Subject: Clueful Jive Communications Contact? In-Reply-To: References: Message-ID: Thanks to all replies off-list. Contact has been made with all the right people in the right places. It really is amazing to see how active the nanog community is and all the great players involved. Chris On Fri, Nov 7, 2014 at 6:24 PM, chris wrote: > Sorry for the noise but If anyone from Jive Communications is on the list > or if anyone has any clueful technical contacts please contact me offlist. > > I have a very frustrated mutual customer we provide network services to > who utilizes Jive for their voice and we can see that there is intermittent > reachability problems and all attempts to go through normal support with > the information we have provided are going nowhere. > > Thanks > chris > From srn.nanog at prgmr.com Sat Nov 8 18:04:21 2014 From: srn.nanog at prgmr.com (srn.nanog at prgmr.com) Date: Sat, 08 Nov 2014 10:04:21 -0800 Subject: Reporting DDOS reflection attacks In-Reply-To: References: <545D15EF.8080509@prgmr.com> Message-ID: <545E5B25.4010307@prgmr.com> On 11/08/2014 03:30 AM, Ruairi Carroll wrote: > Whois data *seems* to be a little more reliable, and there's an abuseEmail script out there that > helps automate the abuse contact lookup ( http://abuseemail.sourceforge.net/ ). I believe this script is out of date and I would not use this script without doing a thorough review/update. For example, 100.43.102.0/24 is reported to be reserved but whois clearly shows that it is allocated to Xplornet Communications Inc. Then when I remove the reserved allocation from the script, the abuse email returned is arin.net rather than xplornet.com. Using dig +short 102.43.100.origin.asn.cymru.com TXT and then whois as22995 would have gotten me the same abuse email address as what I originally found. From damian at google.com Sat Nov 8 22:48:47 2014 From: damian at google.com (Damian Menscher) Date: Sat, 8 Nov 2014 14:48:47 -0800 Subject: Reporting DDOS reflection attacks In-Reply-To: <545D15EF.8080509@prgmr.com> References: <545D15EF.8080509@prgmr.com> Message-ID: I've used https://abusix.com/contactdb.html Be prepared for a lot of backscatter. You'll get autoresponders, automated ticketing systems sending frequent updates, bounce messages (from full abuse@ inboxes), and be surveyed for how well they're not performing. Also, be prepared for ISPs / hosting providers to ask for additional information, like logs proving the attack came from their customer. Oh, and be prepared to feel sorry for their customers whose VMs are deleted for "hacking", rather than being informed of their misconfiguration. On the bright side, some 10% will actually correct the problem, thereby costing the attacker a few minutes of work to re-scan for active amplifiers. :P Damian Professional Pessimist On Fri, Nov 7, 2014 at 10:56 AM, wrote: > Like most small providers, we occasionally get hit by DoS attacks. We got > hammered by an SSDP > reflection attack (udp port 1900) last week. We took a 27 second log and > from there extracted > about 160k unique IPs. > > It is really difficult to find abuse emails for 160k IPs. > > We know about abuse.net but abuse.net requires hostnames, not IPs for > lookups and not all IP > addresses have valid DNS entries. > > The only other way we know of to report problems is to grab the abuse > email addresses is whois. > However, whois is not structured and is not set up to deal with this > number of requests - even > caching whois data based on subnets will result in many thousands of > lookups. > > Long term it seems like structured data and some kind of authentication > would be ideal for reporting > attacks. But right now how should we be doing it? > From pete at altadena.net Sat Nov 8 22:55:51 2014 From: pete at altadena.net (Pete Carah) Date: Sat, 08 Nov 2014 17:55:51 -0500 Subject: v6 cdn problems Message-ID: <545E9F77.90504@altadena.net> Prefix this - I'm on fios in the Baltimore area, using a HE tunnel terminating in ashburn. (*still* no native v6 on fios :-( Speedtest shows little or no congestion, and didn't change significantly when I reduced mtu by 8. (interestingly, speedtest.net usually reads faster than verizon's internal speedtest, and rarely averages less than my billed speed.) I've recently had problems (started a few weeks ago with www.att.com, 4-5 days ago with *.google.com) which unfortunately happy eyeballs doesn't help. att.com uses akamai, google uses their own cdn (per dns; I don't know if there are any connections behind the scenes.) This occurs on several google sites, all of which resolve to the same netblocks from here (maps.google.com, www.google.com, maps.gstatic.com, and at least one of the ad servers). Symptom with akamai is that it connects immediately then data transfer times out. With google, symptom involves both slow connection, and data transfer timing out. I don't know if chrome's happy eyeballs is working since if it was, and absent address caching, I shouldn't see the slow connection. v6 connections to my hosts in Los Angeles (not on HE address space, but we do peer with them on any2) work fine transferring graphics and large database files both ways, so I'm pretty sure I don't have an mtu problem nor some other fios or HE problem. Just to be sure, I dropped the 1500 to 1492 on the fios link and did the same adjustment to the mtu on my tunnel (becomes 1472). No change on my hosts. att.com appears a little better, though still very slow. Google shows no change at all. I saw some of the same problem yesterday from Frederick on comcast (only to google, didn't look at att), but couldn't take the time to do traceroutes. If desired, I'm likely to go out there tomorrow and can do that too. (we use a freebsd+pf router there). Is this a provisioning problem where v6 eyeballs are outstripping cdn provisioning (since win7 and 8 both default to v6)? Or is something else going on. Since this seems to affect more than one cdn, it seems odd. I run my own resolver locally instead of using verizon's. (and my own (vyatta) router instead of theirs. Actually I'm still using theirs as a bridge to talk to the set-top box (I don't know if Motorola still makes the coax terminal that would bridge it directly...) Resolve and traceroutes of relevant sites: [pete at port5 ~]$ host www.att.com www.att.com is an alias for prod-www.zr-att.com.akadns.net. prod-www.zr-att.com.akadns.net is an alias for www.att.com.edgekey.net. www.att.com.edgekey.net is an alias for e2318.dscb.akamaiedge.net. e2318.dscb.akamaiedge.net has address 23.76.217.145 e2318.dscb.akamaiedge.net has IPv6 address 2600:807:320:202:9200::90e e2318.dscb.akamaiedge.net has IPv6 address 2600:807:320:202:8600::90e Traceroute (v4) to this shows it is in Newark or environs: [pete at port5 ~]$ traceroute e2318.dscb.akamaiedge.net traceroute to e2318.dscb.akamaiedge.net (23.76.217.145), 30 hops max, 60 byte packets 1 rtr.east.altadena.net (192.168.170.1) 2.008 ms 2.450 ms 3.091 ms 2 L300.BLTMMD-VFTTP-64.verizon-gni.net (108.3.150.1) 9.021 ms 9.054 ms 9.045 ms 3 G0-7-4-5.BLTMMD-LCR-21.verizon-gni.net (100.41.195.94) 10.670 ms 10.683 ms 10.677 ms 4 ae4-0.RES-BB-RTR2.verizon-gni.net (130.81.209.230) 9.002 ms ae20-0.RES-BB-RTR1.verizon-gni.net (130.81.151.112) 8.995 ms so-1-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.199.2) 8.953 ms 5 * * * 6 * * * 7 0.xe-5-0-4.XL3.EWR6.ALTER.NET (140.222.225.73) 51.202 ms 41.102 ms 40.345 ms 8 0.ae1.XL4.EWR6.ALTER.NET (140.222.228.41) 33.065 ms TenGigE0-6-0-3.GW8.EWR6.ALTER.NET (152.63.19.158) 11.550 ms TenGigE0-6-0-6.GW8.EWR6.ALTER.NET (152.63.25.10) 11.659 ms 9 TenGigE0-7-0-1.GW8.EWR6.ALTER.NET (152.63.19.166) 19.854 ms akamai-gw.customer.alter.net (152.179.185.126) 1766.402 ms TenGigE0-7-0-7.GW8.EWR6.ALTER.NET (152.63.25.30) 18.227 ms 10 akamai-gw.customer.alter.net (152.179.185.126) 1747.269 ms a23-76-217-145.deploy.static.akamaitechnologies.com (23.76.217.145) 10.672 ms 11.263 ms Traceroute6 to it appears to be local (but is hard to tell. Next-to-last hop looks like either a router or load-balancer is overloaded. Same for the v4 traceroute... [pete at port5 ~]$ traceroute6 www.att.com traceroute to www.att.com (2600:807:320:202:9200::90e), 30 hops max, 80 byte packets 1 rtr.east.altadena.net (2001:470:e160:1::1) 5.182 ms 5.274 ms 5.254 ms 2 altadenamd-1.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:126::1) 11.452 ms 15.040 ms 18.592 ms 3 ge4-12.core1.ash1.he.net (2001:470:0:90::1) 20.273 ms 20.574 ms 20.567 ms 4 eqx.br6.iad8.verizonbusiness.com (2001:504:0:2::701:1) 20.522 ms 20.232 ms 20.475 ms 5 * * * 6 2600:802:44f::2 (2600:802:44f::2) 1283.113 ms 1296.115 ms 1296.181 ms 7 2600:807:320:200::1743:f397 (2600:807:320:200::1743:f397) 20.181 ms 16.169 ms 14.073 ms [pete at port5 ~]$ host www.google.com www.google.com has address 74.125.228.16 www.google.com has address 74.125.228.20 www.google.com has address 74.125.228.17 www.google.com has address 74.125.228.19 www.google.com has address 74.125.228.18 www.google.com has IPv6 address 2607:f8b0:4004:800::1012 Traceroute (v4) to this shows something odd, but I don't know where "burl" is for verizon. Also I appear to hit two nodes for the terminal. At least one google node appears to be ashburn (or environs) : [pete at port5 ~]$ traceroute www.google.com traceroute to www.google.com (74.125.228.20), 30 hops max, 60 byte packets 1 rtr.east.altadena.net (192.168.170.1) 2.646 ms 2.816 ms 3.536 ms 2 L300.BLTMMD-VFTTP-64.verizon-gni.net (108.3.150.1) 4.109 ms 4.194 ms 4.186 ms 3 G0-7-4-4.BLTMMD-LCR-22.verizon-gni.net (130.81.170.84) 7.928 ms 8.096 ms 8.088 ms 4 ae20-0.PHIL-BB-RTR1.verizon-gni.net (130.81.151.120) 10.881 ms ae20-0.PHIL-BB-RTR2.verizon-gni.net (130.81.151.124) 11.074 ms so-6-1-0-0.PHIL-BB-RTR2.verizon-gni.net (130.81.199.4) 11.047 ms 5 0.xe-7-0-2.XL2.IAD8.ALTER.NET (152.63.4.93) 14.872 ms 0.xe-3-0-1.XL3.IAD8.ALTER.NET (152.63.3.61) 37.703 ms 12.268 ms 6 0.xe-9-2-0.GW9.IAD8.ALTER.NET (152.63.36.30) 12.866 ms 0.xe-11-2-1.GW9.IAD8.ALTER.NET (152.63.42.2) 14.442 ms 0.xe-9-2-0.GW9.IAD8.ALTER.NET (152.63.36.30) 11.918 ms 7 * 0.xe-10-1-1.GW9.IAD8.ALTER.NET (152.63.35.113) 16.901 ms pool-96-236-104-66.burl.east.verizon.net (96.236.104.66) 136.110 ms 8 pool-96-236-104-66.burl.east.verizon.net (96.236.104.66) 137.977 ms 216.239.46.248 (216.239.46.248) 13.875 ms pool-96-236-104-66.burl.east.verizon.net (96.236.104.66) 134.602 ms 9 216.239.46.248 (216.239.46.248) 15.918 ms 10.708 ms 10.162 ms 10 72.14.238.173 (72.14.238.173) 11.347 ms 12.111 ms iad23s05-in-f20.1e100.net (74.125.228.20) 12.769 ms Corresponding traceroute6 (shows lack of reverse on most hits...): [pete at port5 ~]$ traceroute6 www.google.com traceroute to www.google.com (2607:f8b0:4004:800::1011), 30 hops max, 80 byte packets 1 rtr.east.altadena.net (2001:470:e160:1::1) 1.640 ms 1.811 ms 1.801 ms 2 altadenamd-1.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:126::1) 11.977 ms 15.279 ms 19.265 ms 3 ge4-12.core1.ash1.he.net (2001:470:0:90::1) 19.779 ms 20.776 ms 22.303 ms 4 2001:4860:1:1:0:1b1b:0:d (2001:4860:1:1:0:1b1b:0:d) 22.267 ms 22.514 ms 22.507 ms 5 2001:4860::1:0:9ff (2001:4860::1:0:9ff) 22.508 ms 22.471 ms 22.455 ms 6 2001:4860:0:1::551 (2001:4860:0:1::551) 22.467 ms 19.139 ms 19.116 ms 7 2607:f8b0:8000:18::c (2607:f8b0:8000:18::c) 19.054 ms 2607:f8b0:8000:18::f (2607:f8b0:8000:18::f) 7.716 ms 2607:f8b0:4004:800::1b (2607:f8b0:4004:800::1b) 8.379 ms Again shows multiple terminals for the given address. Ping works fine to all of the addresses, both v4 and v6, and the att one always connects immediately. The google one doesn't always. When I disable the HE tunnel, (and restart the browser - apparently happy-eyeballs caches), everything works just fine, so the problem does appear to relate to v6. For reference, I mostly use chrome in linux. My daughter sees the same problem with google, mostly using chrome in win 7. I see the problem with firefox (in linux) also (to both sites). -- Pete From hslabbert at stargate.ca Sat Nov 8 23:00:51 2014 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Sat, 8 Nov 2014 23:00:51 +0000 Subject: v6 cdn problems In-Reply-To: <545E9F77.90504@altadena.net> References: <545E9F77.90504@altadena.net> Message-ID: Possibly https://puck.nether.net/pipermail/outages/2014-November/007421.html ? -- Hugo Slabbert Network Specialist Phone: 604.606.4448 Email: hslabbert at stargate.ca Stargate Connections Inc. http://www.stargate.ca On Nov 8, 2014, at 14:56, "Pete Carah" > wrote: Prefix this - I'm on fios in the Baltimore area, using a HE tunnel terminating in ashburn. (*still* no native v6 on fios :-( Speedtest shows little or no congestion, and didn't change significantly when I reduced mtu by 8. (interestingly, speedtest.net usually reads faster than verizon's internal speedtest, and rarely averages less than my billed speed.) I've recently had problems (started a few weeks ago with www.att.com, 4-5 days ago with *.google.com) which unfortunately happy eyeballs doesn't help. att.com uses akamai, google uses their own cdn (per dns; I don't know if there are any connections behind the scenes.) This occurs on several google sites, all of which resolve to the same netblocks from here (maps.google.com, www.google.com, maps.gstatic.com, and at least one of the ad servers). Symptom with akamai is that it connects immediately then data transfer times out. With google, symptom involves both slow connection, and data transfer timing out. I don't know if chrome's happy eyeballs is working since if it was, and absent address caching, I shouldn't see the slow connection. v6 connections to my hosts in Los Angeles (not on HE address space, but we do peer with them on any2) work fine transferring graphics and large database files both ways, so I'm pretty sure I don't have an mtu problem nor some other fios or HE problem. Just to be sure, I dropped the 1500 to 1492 on the fios link and did the same adjustment to the mtu on my tunnel (becomes 1472). No change on my hosts. att.com appears a little better, though still very slow. Google shows no change at all. I saw some of the same problem yesterday from Frederick on comcast (only to google, didn't look at att), but couldn't take the time to do traceroutes. If desired, I'm likely to go out there tomorrow and can do that too. (we use a freebsd+pf router there). Is this a provisioning problem where v6 eyeballs are outstripping cdn provisioning (since win7 and 8 both default to v6)? Or is something else going on. Since this seems to affect more than one cdn, it seems odd. I run my own resolver locally instead of using verizon's. (and my own (vyatta) router instead of theirs. Actually I'm still using theirs as a bridge to talk to the set-top box (I don't know if Motorola still makes the coax terminal that would bridge it directly...) Resolve and traceroutes of relevant sites: [pete at port5 ~]$ host www.att.com www.att.com is an alias for prod-www.zr-att.com.akadns.net. prod-www.zr-att.com.akadns.net is an alias for www.att.com.edgekey.net. www.att.com.edgekey.net is an alias for e2318.dscb.akamaiedge.net. e2318.dscb.akamaiedge.net has address 23.76.217.145 e2318.dscb.akamaiedge.net has IPv6 address 2600:807:320:202:9200::90e e2318.dscb.akamaiedge.net has IPv6 address 2600:807:320:202:8600::90e Traceroute (v4) to this shows it is in Newark or environs: [pete at port5 ~]$ traceroute e2318.dscb.akamaiedge.net traceroute to e2318.dscb.akamaiedge.net (23.76.217.145), 30 hops max, 60 byte packets 1 rtr.east.altadena.net (192.168.170.1) 2.008 ms 2.450 ms 3.091 ms 2 L300.BLTMMD-VFTTP-64.verizon-gni.net (108.3.150.1) 9.021 ms 9.054 ms 9.045 ms 3 G0-7-4-5.BLTMMD-LCR-21.verizon-gni.net (100.41.195.94) 10.670 ms 10.683 ms 10.677 ms 4 ae4-0.RES-BB-RTR2.verizon-gni.net (130.81.209.230) 9.002 ms ae20-0.RES-BB-RTR1.verizon-gni.net (130.81.151.112) 8.995 ms so-1-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.199.2) 8.953 ms 5 * * * 6 * * * 7 0.xe-5-0-4.XL3.EWR6.ALTER.NET (140.222.225.73) 51.202 ms 41.102 ms 40.345 ms 8 0.ae1.XL4.EWR6.ALTER.NET (140.222.228.41) 33.065 ms TenGigE0-6-0-3.GW8.EWR6.ALTER.NET (152.63.19.158) 11.550 ms TenGigE0-6-0-6.GW8.EWR6.ALTER.NET (152.63.25.10) 11.659 ms 9 TenGigE0-7-0-1.GW8.EWR6.ALTER.NET (152.63.19.166) 19.854 ms akamai-gw.customer.alter.net (152.179.185.126) 1766.402 ms TenGigE0-7-0-7.GW8.EWR6.ALTER.NET (152.63.25.30) 18.227 ms 10 akamai-gw.customer.alter.net (152.179.185.126) 1747.269 ms a23-76-217-145.deploy.static.akamaitechnologies.com (23.76.217.145) 10.672 ms 11.263 ms Traceroute6 to it appears to be local (but is hard to tell. Next-to-last hop looks like either a router or load-balancer is overloaded. Same for the v4 traceroute... [pete at port5 ~]$ traceroute6 www.att.com traceroute to www.att.com (2600:807:320:202:9200::90e), 30 hops max, 80 byte packets 1 rtr.east.altadena.net (2001:470:e160:1::1) 5.182 ms 5.274 ms 5.254 ms 2 altadenamd-1.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:126::1) 11.452 ms 15.040 ms 18.592 ms 3 ge4-12.core1.ash1.he.net (2001:470:0:90::1) 20.273 ms 20.574 ms 20.567 ms 4 eqx.br6.iad8.verizonbusiness.com (2001:504:0:2::701:1) 20.522 ms 20.232 ms 20.475 ms 5 * * * 6 2600:802:44f::2 (2600:802:44f::2) 1283.113 ms 1296.115 ms 1296.181 ms 7 2600:807:320:200::1743:f397 (2600:807:320:200::1743:f397) 20.181 ms 16.169 ms 14.073 ms [pete at port5 ~]$ host www.google.com www.google.com has address 74.125.228.16 www.google.com has address 74.125.228.20 www.google.com has address 74.125.228.17 www.google.com has address 74.125.228.19 www.google.com has address 74.125.228.18 www.google.com has IPv6 address 2607:f8b0:4004:800::1012 Traceroute (v4) to this shows something odd, but I don't know where "burl" is for verizon. Also I appear to hit two nodes for the terminal. At least one google node appears to be ashburn (or environs) : [pete at port5 ~]$ traceroute www.google.com traceroute to www.google.com (74.125.228.20), 30 hops max, 60 byte packets 1 rtr.east.altadena.net (192.168.170.1) 2.646 ms 2.816 ms 3.536 ms 2 L300.BLTMMD-VFTTP-64.verizon-gni.net (108.3.150.1) 4.109 ms 4.194 ms 4.186 ms 3 G0-7-4-4.BLTMMD-LCR-22.verizon-gni.net (130.81.170.84) 7.928 ms 8.096 ms 8.088 ms 4 ae20-0.PHIL-BB-RTR1.verizon-gni.net (130.81.151.120) 10.881 ms ae20-0.PHIL-BB-RTR2.verizon-gni.net (130.81.151.124) 11.074 ms so-6-1-0-0.PHIL-BB-RTR2.verizon-gni.net (130.81.199.4) 11.047 ms 5 0.xe-7-0-2.XL2.IAD8.ALTER.NET (152.63.4.93) 14.872 ms 0.xe-3-0-1.XL3.IAD8.ALTER.NET (152.63.3.61) 37.703 ms 12.268 ms 6 0.xe-9-2-0.GW9.IAD8.ALTER.NET (152.63.36.30) 12.866 ms 0.xe-11-2-1.GW9.IAD8.ALTER.NET (152.63.42.2) 14.442 ms 0.xe-9-2-0.GW9.IAD8.ALTER.NET (152.63.36.30) 11.918 ms 7 * 0.xe-10-1-1.GW9.IAD8.ALTER.NET (152.63.35.113) 16.901 ms pool-96-236-104-66.burl.east.verizon.net (96.236.104.66) 136.110 ms 8 pool-96-236-104-66.burl.east.verizon.net (96.236.104.66) 137.977 ms 216.239.46.248 (216.239.46.248) 13.875 ms pool-96-236-104-66.burl.east.verizon.net (96.236.104.66) 134.602 ms 9 216.239.46.248 (216.239.46.248) 15.918 ms 10.708 ms 10.162 ms 10 72.14.238.173 (72.14.238.173) 11.347 ms 12.111 ms iad23s05-in-f20.1e100.net (74.125.228.20) 12.769 ms Corresponding traceroute6 (shows lack of reverse on most hits...): [pete at port5 ~]$ traceroute6 www.google.com traceroute to www.google.com (2607:f8b0:4004:800::1011), 30 hops max, 80 byte packets 1 rtr.east.altadena.net (2001:470:e160:1::1) 1.640 ms 1.811 ms 1.801 ms 2 altadenamd-1.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:126::1) 11.977 ms 15.279 ms 19.265 ms 3 ge4-12.core1.ash1.he.net (2001:470:0:90::1) 19.779 ms 20.776 ms 22.303 ms 4 2001:4860:1:1:0:1b1b:0:d (2001:4860:1:1:0:1b1b:0:d) 22.267 ms 22.514 ms 22.507 ms 5 2001:4860::1:0:9ff (2001:4860::1:0:9ff) 22.508 ms 22.471 ms 22.455 ms 6 2001:4860:0:1::551 (2001:4860:0:1::551) 22.467 ms 19.139 ms 19.116 ms 7 2607:f8b0:8000:18::c (2607:f8b0:8000:18::c) 19.054 ms 2607:f8b0:8000:18::f (2607:f8b0:8000:18::f) 7.716 ms 2607:f8b0:4004:800::1b (2607:f8b0:4004:800::1b) 8.379 ms Again shows multiple terminals for the given address. Ping works fine to all of the addresses, both v4 and v6, and the att one always connects immediately. The google one doesn't always. When I disable the HE tunnel, (and restart the browser - apparently happy-eyeballs caches), everything works just fine, so the problem does appear to relate to v6. For reference, I mostly use chrome in linux. My daughter sees the same problem with google, mostly using chrome in win 7. I see the problem with firefox (in linux) also (to both sites). -- Pete From frnkblk at iname.com Sat Nov 8 23:02:23 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 8 Nov 2014 17:02:23 -0600 Subject: v6 cdn problems In-Reply-To: <545E9F77.90504@altadena.net> References: <545E9F77.90504@altadena.net> Message-ID: <000001cffba8$0e87ebe0$2b97c3a0$@iname.com> The Google angle is also being discussed on outages. Initial suspicions are PTB packets not flowing through tunneled connections. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Pete Carah Sent: Saturday, November 08, 2014 4:56 PM To: nanog at nanog.org Subject: v6 cdn problems Prefix this - I'm on fios in the Baltimore area, using a HE tunnel terminating in ashburn. (*still* no native v6 on fios :-( Speedtest shows little or no congestion, and didn't change significantly when I reduced mtu by 8. (interestingly, speedtest.net usually reads faster than verizon's internal speedtest, and rarely averages less than my billed speed.) I've recently had problems (started a few weeks ago with www.att.com, 4-5 days ago with *.google.com) which unfortunately happy eyeballs doesn't help. att.com uses akamai, google uses their own cdn (per dns; I don't know if there are any connections behind the scenes.) This occurs on several google sites, all of which resolve to the same netblocks from here (maps.google.com, www.google.com, maps.gstatic.com, and at least one of the ad servers). Symptom with akamai is that it connects immediately then data transfer times out. With google, symptom involves both slow connection, and data transfer timing out. I don't know if chrome's happy eyeballs is working since if it was, and absent address caching, I shouldn't see the slow connection. v6 connections to my hosts in Los Angeles (not on HE address space, but we do peer with them on any2) work fine transferring graphics and large database files both ways, so I'm pretty sure I don't have an mtu problem nor some other fios or HE problem. Just to be sure, I dropped the 1500 to 1492 on the fios link and did the same adjustment to the mtu on my tunnel (becomes 1472). No change on my hosts. att.com appears a little better, though still very slow. Google shows no change at all. I saw some of the same problem yesterday from Frederick on comcast (only to google, didn't look at att), but couldn't take the time to do traceroutes. If desired, I'm likely to go out there tomorrow and can do that too. (we use a freebsd+pf router there). Is this a provisioning problem where v6 eyeballs are outstripping cdn provisioning (since win7 and 8 both default to v6)? Or is something else going on. Since this seems to affect more than one cdn, it seems odd. I run my own resolver locally instead of using verizon's. (and my own (vyatta) router instead of theirs. Actually I'm still using theirs as a bridge to talk to the set-top box (I don't know if Motorola still makes the coax terminal that would bridge it directly...) Resolve and traceroutes of relevant sites: [pete at port5 ~]$ host www.att.com www.att.com is an alias for prod-www.zr-att.com.akadns.net. prod-www.zr-att.com.akadns.net is an alias for www.att.com.edgekey.net. www.att.com.edgekey.net is an alias for e2318.dscb.akamaiedge.net. e2318.dscb.akamaiedge.net has address 23.76.217.145 e2318.dscb.akamaiedge.net has IPv6 address 2600:807:320:202:9200::90e e2318.dscb.akamaiedge.net has IPv6 address 2600:807:320:202:8600::90e Traceroute (v4) to this shows it is in Newark or environs: [pete at port5 ~]$ traceroute e2318.dscb.akamaiedge.net traceroute to e2318.dscb.akamaiedge.net (23.76.217.145), 30 hops max, 60 byte packets 1 rtr.east.altadena.net (192.168.170.1) 2.008 ms 2.450 ms 3.091 ms 2 L300.BLTMMD-VFTTP-64.verizon-gni.net (108.3.150.1) 9.021 ms 9.054 ms 9.045 ms 3 G0-7-4-5.BLTMMD-LCR-21.verizon-gni.net (100.41.195.94) 10.670 ms 10.683 ms 10.677 ms 4 ae4-0.RES-BB-RTR2.verizon-gni.net (130.81.209.230) 9.002 ms ae20-0.RES-BB-RTR1.verizon-gni.net (130.81.151.112) 8.995 ms so-1-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.199.2) 8.953 ms 5 * * * 6 * * * 7 0.xe-5-0-4.XL3.EWR6.ALTER.NET (140.222.225.73) 51.202 ms 41.102 ms 40.345 ms 8 0.ae1.XL4.EWR6.ALTER.NET (140.222.228.41) 33.065 ms TenGigE0-6-0-3.GW8.EWR6.ALTER.NET (152.63.19.158) 11.550 ms TenGigE0-6-0-6.GW8.EWR6.ALTER.NET (152.63.25.10) 11.659 ms 9 TenGigE0-7-0-1.GW8.EWR6.ALTER.NET (152.63.19.166) 19.854 ms akamai-gw.customer.alter.net (152.179.185.126) 1766.402 ms TenGigE0-7-0-7.GW8.EWR6.ALTER.NET (152.63.25.30) 18.227 ms 10 akamai-gw.customer.alter.net (152.179.185.126) 1747.269 ms a23-76-217-145.deploy.static.akamaitechnologies.com (23.76.217.145) 10.672 ms 11.263 ms Traceroute6 to it appears to be local (but is hard to tell. Next-to-last hop looks like either a router or load-balancer is overloaded. Same for the v4 traceroute... [pete at port5 ~]$ traceroute6 www.att.com traceroute to www.att.com (2600:807:320:202:9200::90e), 30 hops max, 80 byte packets 1 rtr.east.altadena.net (2001:470:e160:1::1) 5.182 ms 5.274 ms 5.254 ms 2 altadenamd-1.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:126::1) 11.452 ms 15.040 ms 18.592 ms 3 ge4-12.core1.ash1.he.net (2001:470:0:90::1) 20.273 ms 20.574 ms 20.567 ms 4 eqx.br6.iad8.verizonbusiness.com (2001:504:0:2::701:1) 20.522 ms 20.232 ms 20.475 ms 5 * * * 6 2600:802:44f::2 (2600:802:44f::2) 1283.113 ms 1296.115 ms 1296.181 ms 7 2600:807:320:200::1743:f397 (2600:807:320:200::1743:f397) 20.181 ms 16.169 ms 14.073 ms [pete at port5 ~]$ host www.google.com www.google.com has address 74.125.228.16 www.google.com has address 74.125.228.20 www.google.com has address 74.125.228.17 www.google.com has address 74.125.228.19 www.google.com has address 74.125.228.18 www.google.com has IPv6 address 2607:f8b0:4004:800::1012 Traceroute (v4) to this shows something odd, but I don't know where "burl" is for verizon. Also I appear to hit two nodes for the terminal. At least one google node appears to be ashburn (or environs) : [pete at port5 ~]$ traceroute www.google.com traceroute to www.google.com (74.125.228.20), 30 hops max, 60 byte packets 1 rtr.east.altadena.net (192.168.170.1) 2.646 ms 2.816 ms 3.536 ms 2 L300.BLTMMD-VFTTP-64.verizon-gni.net (108.3.150.1) 4.109 ms 4.194 ms 4.186 ms 3 G0-7-4-4.BLTMMD-LCR-22.verizon-gni.net (130.81.170.84) 7.928 ms 8.096 ms 8.088 ms 4 ae20-0.PHIL-BB-RTR1.verizon-gni.net (130.81.151.120) 10.881 ms ae20-0.PHIL-BB-RTR2.verizon-gni.net (130.81.151.124) 11.074 ms so-6-1-0-0.PHIL-BB-RTR2.verizon-gni.net (130.81.199.4) 11.047 ms 5 0.xe-7-0-2.XL2.IAD8.ALTER.NET (152.63.4.93) 14.872 ms 0.xe-3-0-1.XL3.IAD8.ALTER.NET (152.63.3.61) 37.703 ms 12.268 ms 6 0.xe-9-2-0.GW9.IAD8.ALTER.NET (152.63.36.30) 12.866 ms 0.xe-11-2-1.GW9.IAD8.ALTER.NET (152.63.42.2) 14.442 ms 0.xe-9-2-0.GW9.IAD8.ALTER.NET (152.63.36.30) 11.918 ms 7 * 0.xe-10-1-1.GW9.IAD8.ALTER.NET (152.63.35.113) 16.901 ms pool-96-236-104-66.burl.east.verizon.net (96.236.104.66) 136.110 ms 8 pool-96-236-104-66.burl.east.verizon.net (96.236.104.66) 137.977 ms 216.239.46.248 (216.239.46.248) 13.875 ms pool-96-236-104-66.burl.east.verizon.net (96.236.104.66) 134.602 ms 9 216.239.46.248 (216.239.46.248) 15.918 ms 10.708 ms 10.162 ms 10 72.14.238.173 (72.14.238.173) 11.347 ms 12.111 ms iad23s05-in-f20.1e100.net (74.125.228.20) 12.769 ms Corresponding traceroute6 (shows lack of reverse on most hits...): [pete at port5 ~]$ traceroute6 www.google.com traceroute to www.google.com (2607:f8b0:4004:800::1011), 30 hops max, 80 byte packets 1 rtr.east.altadena.net (2001:470:e160:1::1) 1.640 ms 1.811 ms 1.801 ms 2 altadenamd-1.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:126::1) 11.977 ms 15.279 ms 19.265 ms 3 ge4-12.core1.ash1.he.net (2001:470:0:90::1) 19.779 ms 20.776 ms 22.303 ms 4 2001:4860:1:1:0:1b1b:0:d (2001:4860:1:1:0:1b1b:0:d) 22.267 ms 22.514 ms 22.507 ms 5 2001:4860::1:0:9ff (2001:4860::1:0:9ff) 22.508 ms 22.471 ms 22.455 ms 6 2001:4860:0:1::551 (2001:4860:0:1::551) 22.467 ms 19.139 ms 19.116 ms 7 2607:f8b0:8000:18::c (2607:f8b0:8000:18::c) 19.054 ms 2607:f8b0:8000:18::f (2607:f8b0:8000:18::f) 7.716 ms 2607:f8b0:4004:800::1b (2607:f8b0:4004:800::1b) 8.379 ms Again shows multiple terminals for the given address. Ping works fine to all of the addresses, both v4 and v6, and the att one always connects immediately. The google one doesn't always. When I disable the HE tunnel, (and restart the browser - apparently happy-eyeballs caches), everything works just fine, so the problem does appear to relate to v6. For reference, I mostly use chrome in linux. My daughter sees the same problem with google, mostly using chrome in win 7. I see the problem with firefox (in linux) also (to both sites). -- Pete From jeroen at massar.ch Sat Nov 8 23:10:20 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Sun, 09 Nov 2014 00:10:20 +0100 Subject: v6 cdn problems In-Reply-To: <545E9F77.90504@altadena.net> References: <545E9F77.90504@altadena.net> Message-ID: <545EA2DC.4080800@massar.ch> On 2014-11-08 23:55, Pete Carah wrote: [..] > Symptom with akamai is that it connects immediately then data transfer > times out. > With google, symptom involves both slow connection, and data transfer > timing out. See amongst others: https://forums.he.net/index.php?topic=3281.0 https://www.sixxs.net/forum/?msg=general-12378937 https://www.sixxs.net/forum/?msg=general-12626989 and already reported in various places, eg ipv6-ops@ etc. Akamai is working on it as they have noted in various places already, (thanks to Marty etc). Google does not seem to be home. They used to have a handy ipv6 at google.com address, but alas, that does not exist anymore. And it does not look their own employees actually use IPv6 otherwise they would have noticed it themselves, or like you know their monitoring systems showing that lots of connections are hanging and never actually properly finishing. > I don't know if chrome's happy eyeballs is working since if > it was, and absent address caching, I shouldn't see the slow connection. Chrome's Happy Eyeballs does not work when the TCP session has been made. (At least that is what it looks like on OSX). Hence, when the session gets stuck it is waiting for the TCP timeout to happen before it retries. It then does seem to remember that that connections is broken. [..] > Is this a provisioning problem where v6 eyeballs are outstripping cdn > provisioning (since win7 and 8 both default to v6)? Or is something > else going on. Since this seems to affect more than one cdn, it seems odd. Coincidence it seems. [..] > When I disable the HE tunnel, (and restart the browser - apparently > happy-eyeballs caches), everything works just fine, so the problem does > appear to relate to v6. *TEMPORARY* null routing the relevant prefixes on your *CPE* resolves the problems you are seeing as then your local router reports !N and your browser falls back to IPv4, which then works again. Greets, Jeroen From frnkblk at iname.com Sat Nov 8 23:19:56 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 8 Nov 2014 17:19:56 -0600 Subject: Reporting DDOS reflection attacks In-Reply-To: <545D15EF.8080509@prgmr.com> References: <545D15EF.8080509@prgmr.com> Message-ID: <000201cffbaa$82416690$86c433b0$@iname.com> Do you know if third-parties such as SANS ISC or ShadowServer take lists of IPs? Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of srn.nanog at prgmr.com Sent: Friday, November 07, 2014 12:57 PM To: nanog at nanog.org Subject: Reporting DDOS reflection attacks Like most small providers, we occasionally get hit by DoS attacks. We got hammered by an SSDP reflection attack (udp port 1900) last week. We took a 27 second log and from there extracted about 160k unique IPs. It is really difficult to find abuse emails for 160k IPs. We know about abuse.net but abuse.net requires hostnames, not IPs for lookups and not all IP addresses have valid DNS entries. The only other way we know of to report problems is to grab the abuse email addresses is whois. However, whois is not structured and is not set up to deal with this number of requests - even caching whois data based on subnets will result in many thousands of lookups. Long term it seems like structured data and some kind of authentication would be ideal for reporting attacks. But right now how should we be doing it? From yardiel at gmail.com Sat Nov 8 23:46:08 2014 From: yardiel at gmail.com (Yardiel D. Fuentes) Date: Sat, 8 Nov 2014 18:46:08 -0500 Subject: Reporting DDOS reflection attacks In-Reply-To: <000201cffbaa$82416690$86c433b0$@iname.com> References: <545D15EF.8080509@prgmr.com> <000201cffbaa$82416690$86c433b0$@iname.com> Message-ID: <8F12CCCA-6B91-44B6-B0D8-8AEF0E1BC7E9@gmail.com> Another DDoS/DoS email thread in progress, ah?... these seem to occur often lately... So....Perfect timing to remind all in the list that there is a NANOG BCOP in the works on this topic. Some of us have been working on documenting our collective knowledge about real practices that can help our community deal with this annoying networking decease...in a vendor agnostic manner... Our DDoS/DoS attack Best Common Ops Practices doc seeks to provide community-wide guidelines on what to do before, during and after a DDoS/DoS attack. If any of you want to contribute and join us to help the community on what we have documented so far, please check out the document below and/or drop me a note... http://bcop.nanog.org/index.php/BCOP_Drafts Yardiel Fuentes yardiel at gmail.com twitter: #techguane On Nov 8, 2014, at 6:19 PM, Frank Bulk wrote: > Do you know if third-parties such as SANS ISC or ShadowServer take lists of IPs? > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of srn.nanog at prgmr.com > Sent: Friday, November 07, 2014 12:57 PM > To: nanog at nanog.org > Subject: Reporting DDOS reflection attacks > > Like most small providers, we occasionally get hit by DoS attacks. We got hammered by an SSDP > reflection attack (udp port 1900) last week. We took a 27 second log and from there extracted > about 160k unique IPs. > > It is really difficult to find abuse emails for 160k IPs. > > We know about abuse.net but abuse.net requires hostnames, not IPs for lookups and not all IP > addresses have valid DNS entries. > > The only other way we know of to report problems is to grab the abuse email addresses is whois. > However, whois is not structured and is not set up to deal with this number of requests - even > caching whois data based on subnets will result in many thousands of lookups. > > Long term it seems like structured data and some kind of authentication would be ideal for reporting > attacks. But right now how should we be doing it? > > From eric at ericheather.com Sun Nov 9 01:10:12 2014 From: eric at ericheather.com (Eric C. Miller) Date: Sun, 9 Nov 2014 01:10:12 +0000 Subject: DDOS, IDS, RTBH, and Rate limiting Message-ID: Today, we experienced (3) separate DDoS attacks from Eastern Asia, all generating > 2Gbps towards a single IP address in our network. All 3 attacks targeted different IP addresses with dst UDP 19, and the attacks lasted for about 5 minutes and stopped as fast as they started. Does anyone have any suggestions for mitigating these type of attacks? A couple of things that we've done already... We set up BGP communities with our upstreams, and tested that RTBH can be set and it does work. However, by the time that we are able to trigger the black hole, the attack is almost always over. For now, we've blocked UDP 19 incoming at our edge, so that if future, similar attacks occur, it doesn't affect our internal links. What I think that I need is an IDS that can watch our edge traffic and automatically trigger a block hole advertisement for any internal IP beginning to receive > 100Mbps of traffic. A few searches are initially coming up dry... Eric Miller, CCNP Network Engineering Consultant (407) 257-5115 From pete at altadena.net Sun Nov 9 01:13:12 2014 From: pete at altadena.net (Pete Carah) Date: Sat, 08 Nov 2014 20:13:12 -0500 Subject: v6 cdn problems In-Reply-To: <545EA2DC.4080800@massar.ch> References: <545E9F77.90504@altadena.net> <545EA2DC.4080800@massar.ch> Message-ID: <545EBFA8.9070606@altadena.net> On 11/08/2014 06:10 PM, Jeroen Massar wrote: > On 2014-11-08 23:55, Pete Carah wrote: > [..] >> Symptom with akamai is that it connects immediately then data transfer >> times out. >> With google, symptom involves both slow connection, and data transfer >> timing out. > See amongst others: > > https://forums.he.net/index.php?topic=3281.0 > https://www.sixxs.net/forum/?msg=general-12378937 > https://www.sixxs.net/forum/?msg=general-12626989 > > and already reported in various places, eg ipv6-ops@ etc. Another list to subscribe... > *TEMPORARY* null routing the relevant prefixes on your *CPE* resolves > the problems you are seeing as then your local router reports !N and > your browser falls back to IPv4, which then works again. DIsgusting but necessary. At least I don't have to do this on verizon's actiontec :-) -- Pete > > Greets, > Jeroen > > From pete at altadena.net Sun Nov 9 01:17:19 2014 From: pete at altadena.net (Pete Carah) Date: Sat, 08 Nov 2014 20:17:19 -0500 Subject: v6 cdn problems In-Reply-To: <545EA2DC.4080800@massar.ch> References: <545E9F77.90504@altadena.net> <545EA2DC.4080800@massar.ch> Message-ID: <545EC09F.2050607@altadena.net> On 11/08/2014 06:10 PM, Jeroen Massar wrote: > On 2014-11-08 23:55, Pete Carah wrote: > [..] >> Symptom with akamai is that it connects immediately then data transfer >> times out. >> With google, symptom involves both slow connection, and data transfer >> timing out. > See amongst others: > > https://forums.he.net/index.php?topic=3281.0 > https://www.sixxs.net/forum/?msg=general-12378937 > https://www.sixxs.net/forum/?msg=general-12626989 > ... > *TEMPORARY* null routing the relevant prefixes on your *CPE* resolves > the problems you are seeing as then your local router reports !N and > your browser falls back to IPv4, which then works again. So, I can do this fine. How do we get my proverbial grandmother to do it? (or even my daughter, who at least knows what a router is, but only that it contains suitable magic). -- Pete From mfidelman at meetinghouse.net Sun Nov 9 01:23:09 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 08 Nov 2014 20:23:09 -0500 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: Message-ID: <545EC1FD.5030801@meetinghouse.net> Eric C. Miller wrote: > Today, we experienced (3) separate DDoS attacks from Eastern Asia, all generating > 2Gbps towards a single IP address in our network. All 3 attacks targeted different IP addresses with dst UDP 19, and the attacks lasted for about 5 minutes and stopped as fast as they started. > > Does anyone have any suggestions for mitigating these type of attacks? > The phrase automated offensive cyber counter-attack has been coming to mind rather frequently, of late. I wonder if DARPA might fund some work in this area. :-) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From raphael.timothy at gmail.com Sun Nov 9 01:38:09 2014 From: raphael.timothy at gmail.com (Tim Raphael) Date: Sun, 9 Nov 2014 09:38:09 +0800 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: Message-ID: Check out Arbour Networks, they produce a range of DDoS scrubbing appliances that do pretty much what you want. Regards, Tim Raphael > On 9 Nov 2014, at 9:10 am, Eric C. Miller wrote: > > Today, we experienced (3) separate DDoS attacks from Eastern Asia, all generating > 2Gbps towards a single IP address in our network. All 3 attacks targeted different IP addresses with dst UDP 19, and the attacks lasted for about 5 minutes and stopped as fast as they started. > > Does anyone have any suggestions for mitigating these type of attacks? > > A couple of things that we've done already... > > We set up BGP communities with our upstreams, and tested that RTBH can be set and it does work. However, by the time that we are able to trigger the black hole, the attack is almost always over. > > For now, we've blocked UDP 19 incoming at our edge, so that if future, similar attacks occur, it doesn't affect our internal links. > > What I think that I need is an IDS that can watch our edge traffic and automatically trigger a block hole advertisement for any internal IP beginning to receive > 100Mbps of traffic. A few searches are initially coming up dry... > > > > Eric Miller, CCNP > Network Engineering Consultant > (407) 257-5115 > > > From frnkblk at iname.com Sun Nov 9 01:59:45 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 8 Nov 2014 19:59:45 -0600 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: Message-ID: <001201cffbc0$d6730af0$835920d0$@iname.com> Here's a thought-provoking video on what Brocade has done with its SDN software load on the MLX: http://vimeo.com/87476840 (demo at ~15 minute mark) I've written it before: if there was a software feature in routers where I could specify the maximum rate any prefix size (up to /32) could receive, that would be very helpful. If my fastest speed (residential) customer was 100 Mbps and I specified that 200 Mbps was the highest, I would never see high-rate attacks enter our network. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric C. Miller Sent: Saturday, November 08, 2014 7:10 PM To: NANOG (nanog at nanog.org) Subject: DDOS, IDS, RTBH, and Rate limiting Today, we experienced (3) separate DDoS attacks from Eastern Asia, all generating > 2Gbps towards a single IP address in our network. All 3 attacks targeted different IP addresses with dst UDP 19, and the attacks lasted for about 5 minutes and stopped as fast as they started. Does anyone have any suggestions for mitigating these type of attacks? A couple of things that we've done already... We set up BGP communities with our upstreams, and tested that RTBH can be set and it does work. However, by the time that we are able to trigger the black hole, the attack is almost always over. For now, we've blocked UDP 19 incoming at our edge, so that if future, similar attacks occur, it doesn't affect our internal links. What I think that I need is an IDS that can watch our edge traffic and automatically trigger a block hole advertisement for any internal IP beginning to receive > 100Mbps of traffic. A few searches are initially coming up dry... Eric Miller, CCNP Network Engineering Consultant (407) 257-5115 From rdobbins at arbor.net Sun Nov 9 02:25:50 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 09 Nov 2014 09:25:50 +0700 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: Message-ID: <6BD1ED23-1851-49EA-9A2A-8F7C78719B50@arbor.net> On 9 Nov 2014, at 8:10, Eric C. Miller wrote: > Does anyone have any suggestions for mitigating these type of attacks? You can start with S/RTBH (or flowspec, if your platform supports it): Here's a preso which discusses reflection/amplification attacks, including chargen reflection/amplification attacks such as the one you describe: ----------------------------------- Roland Dobbins From rdobbins at arbor.net Sun Nov 9 02:28:10 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 09 Nov 2014 09:28:10 +0700 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <001201cffbc0$d6730af0$835920d0$@iname.com> References: <001201cffbc0$d6730af0$835920d0$@iname.com> Message-ID: On 9 Nov 2014, at 8:59, Frank Bulk wrote: > I've written it before: if there was a software feature in routers > where I > could specify the maximum rate any prefix size (up to /32) could > receive, > that would be very helpful. QoS generally isn't a suitable mechanism for DDoS mitigation, as the programmatically-generated attack traffic ends up 'crowding out' legitimate traffic. S/RTBH, flowspec, and other methods tend to produce better results. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Sun Nov 9 02:33:06 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 09 Nov 2014 09:33:06 +0700 Subject: Reporting DDOS reflection attacks In-Reply-To: <8F12CCCA-6B91-44B6-B0D8-8AEF0E1BC7E9@gmail.com> References: <545D15EF.8080509@prgmr.com> <000201cffbaa$82416690$86c433b0$@iname.com> <8F12CCCA-6B91-44B6-B0D8-8AEF0E1BC7E9@gmail.com> Message-ID: On 9 Nov 2014, at 6:46, Yardiel D. Fuentes wrote: > http://bcop.nanog.org/index.php/BCOP_Drafts There are some good general recommendations in this document (Word format? Really?), but this is incorrect and harmful, and should be removed: iii. Consider dropping any DNS reply packets which are larger than 512 Bytes – these are commonly found in DNS DoS Amplification attacks. This *breaks the Internet*. Don't do it. ----------------------------------- Roland Dobbins From frnkblk at iname.com Sun Nov 9 02:42:38 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 8 Nov 2014 20:42:38 -0600 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <001201cffbc0$d6730af0$835920d0$@iname.com> Message-ID: <001901cffbc6$d35f5390$7a1dfab0$@iname.com> There's no doubt, rate-limiting is a poor-man's way of getting the job done, but for small operators who aren't as well instrumented (whether that due to staff or resources), a simple rule such as: access-list 100 ip host 0.0.0.0 0.0.0.0 rate-limit 200000 access-list 100 ip host 0.0.0.0 0.0.0.255 rate-limit 5000000 int vlan 10 description Internet uplink ip access-group 100 in ! would be great. Yes, the /32 under attack would essentially be out of service, but at least the downstream network doesn't get congested and more customers affected. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins Sent: Saturday, November 08, 2014 8:28 PM To: NANOG Subject: Re: DDOS, IDS, RTBH, and Rate limiting On 9 Nov 2014, at 8:59, Frank Bulk wrote: > I've written it before: if there was a software feature in routers > where I > could specify the maximum rate any prefix size (up to /32) could > receive, > that would be very helpful. QoS generally isn't a suitable mechanism for DDoS mitigation, as the programmatically-generated attack traffic ends up 'crowding out' legitimate traffic. S/RTBH, flowspec, and other methods tend to produce better results. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Sun Nov 9 02:49:51 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 09 Nov 2014 09:49:51 +0700 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <001901cffbc6$d35f5390$7a1dfab0$@iname.com> References: <001201cffbc0$d6730af0$835920d0$@iname.com> <001901cffbc6$d35f5390$7a1dfab0$@iname.com> Message-ID: <8ADF2AFD-321C-4CAB-9EA8-C03E06BF8EB7@arbor.net> On 9 Nov 2014, at 9:42, Frank Bulk wrote: > There's no doubt, rate-limiting is a poor-man's way of getting the job > done, > but for small operators who aren't as well instrumented (whether that > due to > staff or resources) You might as well just D/RTBH the victim and have done with it, heh. This is applicable: ----------------------------------- Roland Dobbins From srn.nanog at prgmr.com Sun Nov 9 02:56:28 2014 From: srn.nanog at prgmr.com (srn.nanog at prgmr.com) Date: Sat, 08 Nov 2014 18:56:28 -0800 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: Message-ID: <545ED7DC.3030003@prgmr.com> http://www.andrisoft.com/software/wanguard/ddos-mitigation-protection https://bitbucket.org/tortoiselabs/ddosmon https://github.com/FastVPSEestiOu/fastnetmon I have no idea if any of them actually work. On 11/08/2014 05:10 PM, Eric C. Miller wrote: > Today, we experienced (3) separate DDoS attacks from Eastern Asia, all generating > 2Gbps towards a single IP address in our network. All 3 attacks targeted different IP addresses with dst UDP 19, and the attacks lasted for about 5 minutes and stopped as fast as they started. > > Does anyone have any suggestions for mitigating these type of attacks? > > A couple of things that we've done already... > > We set up BGP communities with our upstreams, and tested that RTBH can be set and it does work. However, by the time that we are able to trigger the black hole, the attack is almost always over. > > For now, we've blocked UDP 19 incoming at our edge, so that if future, similar attacks occur, it doesn't affect our internal links. > > What I think that I need is an IDS that can watch our edge traffic and automatically trigger a block hole advertisement for any internal IP beginning to receive > 100Mbps of traffic. A few searches are initially coming up dry... > > > > Eric Miller, CCNP > Network Engineering Consultant > (407) 257-5115 > > > From jlewis at lewis.org Sun Nov 9 03:12:41 2014 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 8 Nov 2014 22:12:41 -0500 (EST) Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <545EC1FD.5030801@meetinghouse.net> References: <545EC1FD.5030801@meetinghouse.net> Message-ID: On Sat, 8 Nov 2014, Miles Fidelman wrote: >> Does anyone have any suggestions for mitigating these type of attacks? > > The phrase automated offensive cyber counter-attack has been coming to mind > rather frequently, of late. I wonder if DARPA might fund some work in this > area. :-) When you're being hit with one of the UDP reflection DDoS's, attacking the world in response isn't likely to work too well. In theory, you could write something that takes flow data from your transit routers, and in either near or real time, looks at that data and triggers an RTBH route for any IP that is responsible for more than a certain defined threshold of inbound traffic. In practice, it gets a little more complicated than that, as you'll likely want to whitelist some IPs and/or maybe be able to set different thresholds for different IPs. But it's not that complicated a problem to solve. Have a default threshold, and a table of networks and thresholds. Once a minute, look at the top X local destinations over the past minute. For each one, check to see if it has a custom threshold. If it doesn't, it gets the default. Then see if it's over its threshold. If it is, generate an RTBH route and email your NOC. The tricky part is when to remove the route...since you can't tell if the attack has ended while the target is black holed by your upstreams. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rdobbins at arbor.net Sun Nov 9 03:27:27 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 09 Nov 2014 10:27:27 +0700 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <545EC1FD.5030801@meetinghouse.net> Message-ID: <3BC5D475-C2E0-46D3-A418-88BEFAD45F4E@arbor.net> On 9 Nov 2014, at 10:12, Jon Lewis wrote: > The tricky part is when to remove the route...since you can't tell if > the attack has ended while the target is black holed by your > upstreams. You can with NetFlow, if you've D/RTBHed the IP in question on your own infrastructure. NetFlow reports statistics on dropped traffic (except on a few platforms with implementation deficiencies). But this kind of thing punishes the victim. It's far better to do everything possible to *protect* the target(s) of an attack, and only use D/RTBH as a last resort. ----------------------------------- Roland Dobbins From tfarrell at riotgames.com Sun Nov 9 03:32:32 2014 From: tfarrell at riotgames.com (Trent Farrell) Date: Sat, 8 Nov 2014 19:32:32 -0800 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <545EC1FD.5030801@meetinghouse.net> Message-ID: A quick and dirty win is to get your upstream(s) to kill anything UDP 19 to your prefixes at their ingress points if it becomes a common thing. You lose visibility as to when you're getting targeted by that type of attack again though, which could matter depending on your network. On Saturday, November 8, 2014, Jon Lewis wrote: > On Sat, 8 Nov 2014, Miles Fidelman wrote: > > Does anyone have any suggestions for mitigating these type of attacks? >>> >> >> The phrase automated offensive cyber counter-attack has been coming to >> mind rather frequently, of late. I wonder if DARPA might fund some work in >> this area. :-) >> > > When you're being hit with one of the UDP reflection DDoS's, attacking the > world in response isn't likely to work too well. > > In theory, you could write something that takes flow data from your > transit routers, and in either near or real time, looks at that data and > triggers an RTBH route for any IP that is responsible for more than a > certain defined threshold of inbound traffic. In practice, it gets a > little more complicated than that, as you'll likely want to whitelist some > IPs and/or maybe be able to set different thresholds for different IPs. But > it's not that complicated a problem to solve. Have a default threshold, > and a table of networks and thresholds. Once a minute, look at the top X > local destinations over the past minute. For each one, check to see if it > has a custom threshold. If it doesn't, it gets the default. Then see if > it's over its threshold. If it is, generate an RTBH route and email your > NOC. > > The tricky part is when to remove the route...since you can't tell if the > attack has ended while the target is black holed by your upstreams. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarrell at riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro From jlewis at lewis.org Sun Nov 9 03:37:45 2014 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 8 Nov 2014 22:37:45 -0500 (EST) Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <3BC5D475-C2E0-46D3-A418-88BEFAD45F4E@arbor.net> References: <545EC1FD.5030801@meetinghouse.net> <3BC5D475-C2E0-46D3-A418-88BEFAD45F4E@arbor.net> Message-ID: On Sun, 9 Nov 2014, Roland Dobbins wrote: > > On 9 Nov 2014, at 10:12, Jon Lewis wrote: > >> The tricky part is when to remove the route...since you can't tell if the >> attack has ended while the target is black holed by your upstreams. > > You can with NetFlow, if you've D/RTBHed the IP in question on your own > infrastructure. NetFlow reports statistics on dropped traffic (except on a > few platforms with implementation deficiencies). I'm assuming from the OP's comment: "We set up BGP communities with our upstreams, and tested that RTBH can be set and it does work." that they have their upstreams null routing the traffic, so they no longer see the attack traffic. > But this kind of thing punishes the victim. It's far better to do everything > possible to *protect* the target(s) of an attack, and only use D/RTBH as a > last resort. I'm sure it's not always the case, but in my experience as a SP, the victim virtually always did something to instigate the attack, and is usually someone you don't want as a customer. When I worked for a cloud hosting provider, the DDoS "victims" tended to be fraudulent signups who were doing malicious or anti-social things on the net and were not paying customers anyway. As someone else mentioned, it's better to sacrifice the one target and end the impact quickly than to piss off all or even some subset of your customers. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jlewis at lewis.org Sun Nov 9 03:41:17 2014 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 8 Nov 2014 22:41:17 -0500 (EST) Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <545EC1FD.5030801@meetinghouse.net> Message-ID: How many holes are you going to stick fingers in to stop the flows? Good luck getting your provider to put in such a filter and make it anything more than temporary...and then there's still DNS, NTP, SNMP, and other protocols an attacker can easily utilize when they find that chargen isn't getting the job done. On Sat, 8 Nov 2014, Trent Farrell wrote: > A quick and dirty win is to get your upstream(s) to kill anything UDP 19 to > your prefixes at their ingress points if it becomes a common thing. You > lose visibility as to when you're getting targeted by that type of attack > again though, which could matter depending on your network. > > > On Saturday, November 8, 2014, Jon Lewis wrote: > >> On Sat, 8 Nov 2014, Miles Fidelman wrote: >> >> Does anyone have any suggestions for mitigating these type of attacks? >>>> >>> >>> The phrase automated offensive cyber counter-attack has been coming to >>> mind rather frequently, of late. I wonder if DARPA might fund some work in >>> this area. :-) >>> >> >> When you're being hit with one of the UDP reflection DDoS's, attacking the >> world in response isn't likely to work too well. >> >> In theory, you could write something that takes flow data from your >> transit routers, and in either near or real time, looks at that data and >> triggers an RTBH route for any IP that is responsible for more than a >> certain defined threshold of inbound traffic. In practice, it gets a >> little more complicated than that, as you'll likely want to whitelist some >> IPs and/or maybe be able to set different thresholds for different IPs. But >> it's not that complicated a problem to solve. Have a default threshold, >> and a table of networks and thresholds. Once a minute, look at the top X >> local destinations over the past minute. For each one, check to see if it >> has a custom threshold. If it doesn't, it gets the default. Then see if >> it's over its threshold. If it is, generate an RTBH route and email your >> NOC. >> >> The tricky part is when to remove the route...since you can't tell if the >> attack has ended while the target is black holed by your upstreams. >> >> ---------------------------------------------------------------------- >> Jon Lewis, MCP :) | I route >> | therefore you are >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ >> > > > -- > > *Trent Farrell* > > *Riot Games* > > *IP Network Engineer* > > E: tfarrell at riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 > > Summoner name: Foro > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rdobbins at arbor.net Sun Nov 9 03:50:42 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 09 Nov 2014 10:50:42 +0700 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <545EC1FD.5030801@meetinghouse.net> <3BC5D475-C2E0-46D3-A418-88BEFAD45F4E@arbor.net> Message-ID: On 9 Nov 2014, at 10:37, Jon Lewis wrote: > I'm sure it's not always the case, but in my experience as a SP, the > victim virtually always did something to instigate the attack, and is > usually someone you don't want as a customer. This may be a reflection of your experience and customer base, but it isn't a valid generalization. Legitimate customers are attacked all the time, for various reasons - including unknowingly having their servers compromised and used as C&Cs by miscreants, who're then attacked by other miscreants. But to say that attacks are 'virtually always' provoked by customers themselves simply isn't true. DDoS extortion, ideologically-motivated DDoS attacks, maskirovkas intended as a distraction away from other activities, simple nihilism, et. al. are, unfortunately, quite common. > When I worked for a cloud hosting provider, the DDoS "victims" tended > to be fraudulent signups who were doing malicious or anti-social > things on the net and were not paying customers anyway. Many DDoS attacks are miscreant-vs.-miscreant, that's certainly true. Compromised machines are 'attractive nuisances', which is yet another reason it's important to have visibility into your network traffic (it's easy to get started with NetFlow and open-source tools). ----------------------------------- Roland Dobbins From tfarrell at riotgames.com Sun Nov 9 04:19:51 2014 From: tfarrell at riotgames.com (Trent Farrell) Date: Sat, 8 Nov 2014 20:19:51 -0800 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <545EC1FD.5030801@meetinghouse.net> Message-ID: I wouldn't have suggested it if I hadn't successfully made these requests myself. Most attacks don't last long enough to put a dent on billing so it's in everyone best interest to cull it quickly. Providing the upstream network is big enough and your attacks aren't huge pipefills, they will usually place the acl on your customer port first, which in those cases should be enough. For smaller attacks you can try to drop at your router/absorb it/ scrub it inside your border if you have the kit - but anything significant like the NTP reflection attacks earlier in the year, you come up against the "bandwidth arms race" problem. There are services out there like Prolexic/Black Lotus offer where they can scrub traffic for you, but I've never used one first hand so can't comment. On Saturday, November 8, 2014, Jon Lewis wrote: > How many holes are you going to stick fingers in to stop the flows? Good > luck getting your provider to put in such a filter and make it anything > more than temporary...and then there's still DNS, NTP, SNMP, and other > protocols an attacker can easily utilize when they find that chargen isn't > getting the job done. > > On Sat, 8 Nov 2014, Trent Farrell wrote: > > A quick and dirty win is to get your upstream(s) to kill anything UDP 19 >> to >> your prefixes at their ingress points if it becomes a common thing. You >> lose visibility as to when you're getting targeted by that type of attack >> again though, which could matter depending on your network. >> >> >> On Saturday, November 8, 2014, Jon Lewis wrote: >> >> On Sat, 8 Nov 2014, Miles Fidelman wrote: >>> >>> Does anyone have any suggestions for mitigating these type of attacks? >>> >>>> >>>>> >>>> The phrase automated offensive cyber counter-attack has been coming to >>>> mind rather frequently, of late. I wonder if DARPA might fund some >>>> work in >>>> this area. :-) >>>> >>>> >>> When you're being hit with one of the UDP reflection DDoS's, attacking >>> the >>> world in response isn't likely to work too well. >>> >>> In theory, you could write something that takes flow data from your >>> transit routers, and in either near or real time, looks at that data and >>> triggers an RTBH route for any IP that is responsible for more than a >>> certain defined threshold of inbound traffic. In practice, it gets a >>> little more complicated than that, as you'll likely want to whitelist >>> some >>> IPs and/or maybe be able to set different thresholds for different IPs. >>> But >>> it's not that complicated a problem to solve. Have a default threshold, >>> and a table of networks and thresholds. Once a minute, look at the top X >>> local destinations over the past minute. For each one, check to see if >>> it >>> has a custom threshold. If it doesn't, it gets the default. Then see if >>> it's over its threshold. If it is, generate an RTBH route and email your >>> NOC. >>> >>> The tricky part is when to remove the route...since you can't tell if the >>> attack has ended while the target is black holed by your upstreams. >>> >>> ---------------------------------------------------------------------- >>> Jon Lewis, MCP :) | I route >>> | therefore you are >>> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ >>> >>> >> >> -- >> >> *Trent Farrell* >> >> *Riot Games* >> >> *IP Network Engineer* >> >> E: tfarrell at riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 >> >> Summoner name: Foro >> >> > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarrell at riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro From mpalmer at hezmatt.org Sun Nov 9 05:13:21 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sun, 9 Nov 2014 16:13:21 +1100 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <545EC1FD.5030801@meetinghouse.net> <3BC5D475-C2E0-46D3-A418-88BEFAD45F4E@arbor.net> Message-ID: <20141109051321.GB9751@hezmatt.org> On Sat, Nov 08, 2014 at 10:37:45PM -0500, Jon Lewis wrote: > On Sun, 9 Nov 2014, Roland Dobbins wrote: > >But this kind of thing punishes the victim. It's far better to do > >everything possible to *protect* the target(s) of an attack, and > >only use D/RTBH as a last resort. > > I'm sure it's not always the case, but in my experience as a SP, the > victim virtually always did something to instigate the attack Like have the temerity to have a successful online store. Or be featured in the mainstream media for providing information during a natural disaster. The bastards. I've dealt with far more DDoS attacks that were for the purposes of extortion or lulz than were due to the recipient "instigating the attack". Perhaps that's a function of not attempting to cater to the lowest common denominator. - Matt From joelja at bogus.com Sun Nov 9 05:22:05 2014 From: joelja at bogus.com (joel jaeggli) Date: Sat, 08 Nov 2014 21:22:05 -0800 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <001201cffbc0$d6730af0$835920d0$@iname.com> Message-ID: <545EF9FD.4050400@bogus.com> On 11/8/14 6:28 PM, Roland Dobbins wrote: > > On 9 Nov 2014, at 8:59, Frank Bulk wrote: > >> I've written it before: if there was a software feature in routers >> where I >> could specify the maximum rate any prefix size (up to /32) could receive, >> that would be very helpful. > > QoS generally isn't a suitable mechanism for DDoS mitigation, as the > programmatically-generated attack traffic ends up 'crowding out' > legitimate traffic. if you can identify attack traffic well enough to police it reliably then you can also drop it on the floor. > S/RTBH, flowspec, and other methods tend to produce better results. yup. > ----------------------------------- > Roland Dobbins > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From frnkblk at iname.com Sun Nov 9 05:31:31 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 8 Nov 2014 23:31:31 -0600 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <545EF9FD.4050400@bogus.com> References: <001201cffbc0$d6730af0$835920d0$@iname.com> <545EF9FD.4050400@bogus.com> Message-ID: <002301cffbde$6b5110a0$41f331e0$@iname.com> But that's my point: many small operators don't have tools and/or staff to identify flows in order to police and/or drop the traffic, and definitely not a NOC that can intervene in under 5 minutes. How much simpler if there was a generic rule that said "no one IP can receive more than 200 Mbps", log on that, and then if it takes 30 or 90 minutes for someone to react, that's fine, but in the meantime other customers weren't affected. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of joel jaeggli Sent: Saturday, November 08, 2014 11:22 PM To: Roland Dobbins; NANOG Subject: Re: DDOS, IDS, RTBH, and Rate limiting On 11/8/14 6:28 PM, Roland Dobbins wrote: > > On 9 Nov 2014, at 8:59, Frank Bulk wrote: > >> I've written it before: if there was a software feature in routers >> where I >> could specify the maximum rate any prefix size (up to /32) could receive, >> that would be very helpful. > > QoS generally isn't a suitable mechanism for DDoS mitigation, as the > programmatically-generated attack traffic ends up 'crowding out' > legitimate traffic. if you can identify attack traffic well enough to police it reliably then you can also drop it on the floor. > S/RTBH, flowspec, and other methods tend to produce better results. yup. > ----------------------------------- > Roland Dobbins > From Jason_Livingood at cable.comcast.com Sun Nov 9 05:46:35 2014 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Sun, 9 Nov 2014 05:46:35 +0000 Subject: FW: M-Lab-Related PCAPs Message-ID: FYI to this list since I suspect few of you are on the M-Lab Discuss list. Srikanth from ICSI has kindly taken on consolidating some PCAPs. If anyone wishes to send any to him, he is at srknth.s at gmail.com. JL On 11/6/14, 7:24 PM, "Srikanth S" > wrote: So it looks as though marking is not done for all MLab traffic. Also, some web traffic (to CNN) is marked at a lower priority than streaming (Netflix), which is strange as web traffic is likely more sensitive to degradation than streaming (?). Here are the traces: http://www1.icsi.berkeley.edu/~srikanth/pcaps/google.pcap http://www1.icsi.berkeley.edu/~srikanth/pcaps/youtube-image.pcap http://www1.icsi.berkeley.edu/~srikanth/pcaps/cnn.pcap http://www1.icsi.berkeley.edu/~srikanth/pcaps/netflix-streaming.pcap On Tuesday, November 4, 2014 1:29:16 PM UTC-8, Jason Livingood wrote: Another follow-up. Someone emailed me a PCAP off-list from an enterprise type of customer. Their PCAP was somewhat incomplete (so I still need more) but they noticed that some traffic at the next priority down from 0x48 at 0x28 (priority). And some other traffic was marked with the next priority down again at 0x00 (routine). So it appears there are three DSCP / ToS markings in use rather than just two (0x00, 0x28, 0x48). So safe to say more research is needed here – anyone collecting PCAPs should IMHO continue. :-) Jason From contact at winterei.se Sun Nov 9 13:42:57 2014 From: contact at winterei.se (Paul S.) Date: Sun, 09 Nov 2014 22:42:57 +0900 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <545ED7DC.3030003@prgmr.com> References: <545ED7DC.3030003@prgmr.com> Message-ID: <545F6F61.30808@winterei.se> I've used the first one, and hacked on the second. WANGuard, when deployed properly, works amazingly well. ddosmon is only useful if you have netflow v5 flows (or sflow that can get converted to nfv5), but also works well when coupled with exabgp / openbgpd. I added some per ip limiting / exemption features to it (which may or may not work, I no longer use it. We've moved to something in house) -- available on this fork (https://github.com/Wintereise/ddosmon-mod) The atheme framework it's built on is fairly easy to extend as well. But yeah, automated rtbh is really easy (and cheap!) to do these days. On 11/9/2014 午前 11:56, srn.nanog at prgmr.com wrote: > http://www.andrisoft.com/software/wanguard/ddos-mitigation-protection > > https://bitbucket.org/tortoiselabs/ddosmon > > https://github.com/FastVPSEestiOu/fastnetmon > > I have no idea if any of them actually work. > > On 11/08/2014 05:10 PM, Eric C. Miller wrote: >> Today, we experienced (3) separate DDoS attacks from Eastern Asia, all generating > 2Gbps towards a single IP address in our network. All 3 attacks targeted different IP addresses with dst UDP 19, and the attacks lasted for about 5 minutes and stopped as fast as they started. >> >> Does anyone have any suggestions for mitigating these type of attacks? >> >> A couple of things that we've done already... >> >> We set up BGP communities with our upstreams, and tested that RTBH can be set and it does work. However, by the time that we are able to trigger the black hole, the attack is almost always over. >> >> For now, we've blocked UDP 19 incoming at our edge, so that if future, similar attacks occur, it doesn't affect our internal links. >> >> What I think that I need is an IDS that can watch our edge traffic and automatically trigger a block hole advertisement for any internal IP beginning to receive > 100Mbps of traffic. A few searches are initially coming up dry... >> >> >> >> Eric Miller, CCNP >> Network Engineering Consultant >> (407) 257-5115 >> >> >> From mfidelman at meetinghouse.net Sun Nov 9 14:32:18 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 09 Nov 2014 09:32:18 -0500 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <545EC1FD.5030801@meetinghouse.net> <3BC5D475-C2E0-46D3-A418-88BEFAD45F4E@arbor.net> Message-ID: <545F7AF2.4060208@meetinghouse.net> Roland Dobbins wrote: > > On 9 Nov 2014, at 10:37, Jon Lewis wrote: > >> I'm sure it's not always the case, but in my experience as a SP, the >> victim virtually always did something to instigate the attack, and is >> usually someone you don't want as a customer. > > This may be a reflection of your experience and customer base, but it > isn't a valid generalization. Legitimate customers are attacked all > the time, for various reasons - including unknowingly having their > servers compromised and used as C&Cs by miscreants, who're then > attacked by other miscreants. > > But to say that attacks are 'virtually always' provoked by customers > themselves simply isn't true. DDoS extortion, ideologically-motivated > DDoS attacks, maskirovkas intended as a distraction away from other > activities, simple nihilism, et. al. are, unfortunately, quite common. > >> When I worked for a cloud hosting provider, the DDoS "victims" tended >> to be fraudulent signups who were doing malicious or anti-social >> things on the net and were not paying customers anyway. > > Many DDoS attacks are miscreant-vs.-miscreant, that's certainly true. > Compromised machines are 'attractive nuisances', which is yet another > reason it's important to have visibility into your network traffic > (it's easy to get started with NetFlow and open-source tools). > > Granted, a sample size of 1 - but the most recent event where we were the vector for a reflection attack, the target was a game hosting system. Based on some interaction with their sysadmin, it became pretty clear that this is fairly common for them, and the motivations had more to do with hacking gameplay than anything else. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From brak at gameservers.com Sun Nov 9 17:31:39 2014 From: brak at gameservers.com (Brian Rak) Date: Sun, 09 Nov 2014 12:31:39 -0500 Subject: Reporting DDOS reflection attacks In-Reply-To: References: <545D15EF.8080509@prgmr.com> Message-ID: <545FA4FB.9000900@gameservers.com> Also, abusix is not completely accurate (and they've never responded to my emails reporting problems). For example, any IPs from apnic and nic.ad.jp return the registry's abuse address, which doesn't do anything. Don't forget about all the providers with incorrect abuse contacts, or providers that require you to fill out some form, or providers that auto-respond with messages saying it's not their IP space (I'm looking at you charter... 71.90.222.x is definitely your space, despite what your abuse system thinks). Some tips: 1) Verify the servers are still vulnerable. This is pretty straightforward, and saves everyone involved some time 2) Your abuse emails should include tcpdump-like output (or you'll get tons of replies asking for logs) 3) Sticking to one abusive IP per email seems to get the best response rate (or you confuse all the automated systems for parsing these) 4) We provide instructions for fixing the issue for some common software... this seems to help some of the people who have no idea what they are doing. 5) Make sure you don't send this from your email address. It should definitely be it's own mailbox due to volume of bounces and autoreplies you'll see. Don't expect that sending abuse emails is going to have any noticeable effect on the size of the attacks you see. The openresolverproject stats show the scope of the issue: http://openresolverproject.org/breakdown.cgi On 11/8/2014 5:48 PM, Damian Menscher wrote: > I've used https://abusix.com/contactdb.html > > Be prepared for a lot of backscatter. You'll get autoresponders, automated > ticketing systems sending frequent updates, bounce messages (from full > abuse@ inboxes), and be surveyed for how well they're not performing. > > Also, be prepared for ISPs / hosting providers to ask for additional > information, like logs proving the attack came from their customer. > > Oh, and be prepared to feel sorry for their customers whose VMs are deleted > for "hacking", rather than being informed of their misconfiguration. > > On the bright side, some 10% will actually correct the problem, thereby > costing the attacker a few minutes of work to re-scan for active > amplifiers. :P > > Damian > Professional Pessimist > > On Fri, Nov 7, 2014 at 10:56 AM, wrote: > >> Like most small providers, we occasionally get hit by DoS attacks. We got >> hammered by an SSDP >> reflection attack (udp port 1900) last week. We took a 27 second log and >> from there extracted >> about 160k unique IPs. >> >> It is really difficult to find abuse emails for 160k IPs. >> >> We know about abuse.net but abuse.net requires hostnames, not IPs for >> lookups and not all IP >> addresses have valid DNS entries. >> >> The only other way we know of to report problems is to grab the abuse >> email addresses is whois. >> However, whois is not structured and is not set up to deal with this >> number of requests - even >> caching whois data based on subnets will result in many thousands of >> lookups. >> >> Long term it seems like structured data and some kind of authentication >> would be ideal for reporting >> attacks. But right now how should we be doing it? >> From srn.nanog at prgmr.com Sun Nov 9 17:43:47 2014 From: srn.nanog at prgmr.com (srn.nanog at prgmr.com) Date: Sun, 09 Nov 2014 09:43:47 -0800 Subject: Reporting DDOS reflection attacks In-Reply-To: <545FA4FB.9000900@gameservers.com> References: <545D15EF.8080509@prgmr.com> <545FA4FB.9000900@gameservers.com> Message-ID: <545FA7D3.9040908@prgmr.com> On 11/09/2014 09:31 AM, Brian Rak wrote: > Some tips: > 1) Verify the servers are still vulnerable. This is pretty straightforward, and saves everyone > involved some time For a DDOS, I'd be concerned that the provider would now think my activity was malicious. > 2) Your abuse emails should include tcpdump-like output (or you'll get tons of replies asking for logs) Is the output from nfdump close enough? > 3) Sticking to one abusive IP per email seems to get the best response rate (or you confuse all the > automated systems for parsing these) The smallest email abuse report I sent last week contained over 15,000 IPs. Is it really better to send that many emails? From jchisolm at computer.org Sun Nov 9 07:13:37 2014 From: jchisolm at computer.org (Joe Chisolm) Date: Sun, 09 Nov 2014 01:13:37 -0600 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: Message-ID: <545F1421.6060307@computer.org> Look at the products from RioRey (www.riorey.com). IMHO I think their technology is much better than some of the other players out here. On 11/08/2014 07:10 PM, Eric C. Miller wrote: > Today, we experienced (3) separate DDoS attacks from Eastern Asia, all generating > 2Gbps towards a single IP address in our network. All 3 attacks targeted different IP addresses with dst UDP 19, and the attacks lasted for about 5 minutes and stopped as fast as they started. > > Does anyone have any suggestions for mitigating these type of attacks? > > A couple of things that we've done already... > > We set up BGP communities with our upstreams, and tested that RTBH can be set and it does work. However, by the time that we are able to trigger the black hole, the attack is almost always over. > > For now, we've blocked UDP 19 incoming at our edge, so that if future, similar attacks occur, it doesn't affect our internal links. > > What I think that I need is an IDS that can watch our edge traffic and automatically trigger a block hole advertisement for any internal IP beginning to receive > 100Mbps of traffic. A few searches are initially coming up dry... > > > > Eric Miller, CCNP > Network Engineering Consultant > (407) 257-5115 > > > > -- Joe Chisolm Computer Translations, Inc. Marble Falls, Tx. 830-265-8018 Public Key Available at www.sks-keyservers.net From dougb at dougbarton.us Sun Nov 9 19:40:26 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 09 Nov 2014 11:40:26 -0800 Subject: Reporting DDOS reflection attacks In-Reply-To: References: <545D15EF.8080509@prgmr.com> <000201cffbaa$82416690$86c433b0$@iname.com> <8F12CCCA-6B91-44B6-B0D8-8AEF0E1BC7E9@gmail.com> Message-ID: <545FC32A.9020200@dougbarton.us> On 11/8/14 6:33 PM, Roland Dobbins wrote: > this is incorrect and harmful, and should be removed: > > iii. Consider dropping any DNS reply packets which are larger > than 512 Bytes – these are commonly found in DNS DoS Amplification attacks. > > This *breaks the Internet*. Don't do it. +1 From bmanning at isi.edu Sun Nov 9 19:52:58 2014 From: bmanning at isi.edu (manning bill) Date: Sun, 9 Nov 2014 11:52:58 -0800 Subject: Reporting DDOS reflection attacks In-Reply-To: <545FC32A.9020200@dougbarton.us> References: <545D15EF.8080509@prgmr.com> <000201cffbaa$82416690$86c433b0$@iname.com> <8F12CCCA-6B91-44B6-B0D8-8AEF0E1BC7E9@gmail.com> <545FC32A.9020200@dougbarton.us> Message-ID: <16E4DB7D-507D-46A3-BA62-1559149DC3E0@isi.edu> On 9November2014Sunday, at 11:40, Doug Barton wrote: > On 11/8/14 6:33 PM, Roland Dobbins wrote: >> this is incorrect and harmful, and should be removed: >> >> iii. Consider dropping any DNS reply packets which are larger >> than 512 Bytes – these are commonly found in DNS DoS Amplification attacks. >> >> This *breaks the Internet*. Don't do it. > > +1 actually, if you think this will help you, by all means drop any DNS packets which are gt. 512bytes, not UDP, and not IPv4. /bill From joelja at bogus.com Sun Nov 9 21:53:42 2014 From: joelja at bogus.com (joel jaeggli) Date: Sun, 09 Nov 2014 11:53:42 -1000 Subject: v6 cdn problems In-Reply-To: <000001cffba8$0e87ebe0$2b97c3a0$@iname.com> References: <545E9F77.90504@altadena.net> <000001cffba8$0e87ebe0$2b97c3a0$@iname.com> Message-ID: <545FE266.8060107@bogus.com> On 11/8/14 1:02 PM, Frank Bulk wrote: > The Google angle is also being discussed on outages. Initial suspicions are PTB packets not flowing through tunneled connections. you can also have problems in the other direction e.g. if your tunnel ingress sends a ptb towards a load balanced service it may not arrive. https://tools.ietf.org/html/draft-v6ops-pmtud-ecmp-problem-00 if you're tunneled it does help a lot if your mss reflects the cost of the tunnel you know exists. > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Pete Carah > Sent: Saturday, November 08, 2014 4:56 PM > To: nanog at nanog.org > Subject: v6 cdn problems > > Prefix this - I'm on fios in the Baltimore area, using a HE tunnel > terminating in ashburn. > (*still* no native v6 on fios :-( Speedtest shows little or no > congestion, and didn't change significantly when I reduced mtu by 8. > (interestingly, speedtest.net usually reads faster than verizon's > internal speedtest, and rarely averages less than my billed speed.) > > I've recently had problems (started a few weeks ago with www.att.com, > 4-5 days ago with *.google.com) > which unfortunately happy eyeballs doesn't help. > att.com uses akamai, google uses their own cdn (per dns; I don't know if > there are any connections > behind the scenes.) This occurs on several google sites, all of which > resolve to the same netblocks from here (maps.google.com, > www.google.com, maps.gstatic.com, and at least one of the ad servers). > > Symptom with akamai is that it connects immediately then data transfer > times out. > With google, symptom involves both slow connection, and data transfer > timing out. I don't know if chrome's happy eyeballs is working since if > it was, and absent address caching, I shouldn't see the slow connection. > > v6 connections to my hosts in Los Angeles (not on HE address space, but > we do peer with them on > any2) work fine transferring graphics and large database files both > ways, so I'm pretty sure I don't have an mtu problem nor some other fios > or HE problem. Just to be sure, I dropped the 1500 to 1492 on the fios > link and did the same adjustment to the mtu on my tunnel (becomes > 1472). No change on my hosts. att.com appears a little better, though > still very slow. Google shows no change at all. > > I saw some of the same problem yesterday from Frederick on comcast (only > to google, didn't look at att), but couldn't take the time to do > traceroutes. If desired, I'm likely to go out there tomorrow and can do > that too. (we use a freebsd+pf router there). > > Is this a provisioning problem where v6 eyeballs are outstripping cdn > provisioning (since win7 and 8 both default to v6)? Or is something > else going on. Since this seems to affect more than one cdn, it seems odd. > > I run my own resolver locally instead of using verizon's. (and my own > (vyatta) router instead of theirs. Actually I'm still using theirs as a > bridge to talk to the set-top box (I don't know if Motorola still makes the > coax terminal that would bridge it directly...) > > Resolve and traceroutes of relevant sites: > > [pete at port5 ~]$ host www.att.com > www.att.com is an alias for prod-www.zr-att.com.akadns.net. > prod-www.zr-att.com.akadns.net is an alias for www.att.com.edgekey.net. > www.att.com.edgekey.net is an alias for e2318.dscb.akamaiedge.net. > e2318.dscb.akamaiedge.net has address 23.76.217.145 > e2318.dscb.akamaiedge.net has IPv6 address 2600:807:320:202:9200::90e > e2318.dscb.akamaiedge.net has IPv6 address 2600:807:320:202:8600::90e > > Traceroute (v4) to this shows it is in Newark or environs: > [pete at port5 ~]$ traceroute e2318.dscb.akamaiedge.net > traceroute to e2318.dscb.akamaiedge.net (23.76.217.145), 30 hops max, 60 byte packets > 1 rtr.east.altadena.net (192.168.170.1) 2.008 ms 2.450 ms 3.091 ms > 2 L300.BLTMMD-VFTTP-64.verizon-gni.net (108.3.150.1) 9.021 ms 9.054 ms 9.045 ms > 3 G0-7-4-5.BLTMMD-LCR-21.verizon-gni.net (100.41.195.94) 10.670 ms 10.683 ms 10.677 ms > 4 ae4-0.RES-BB-RTR2.verizon-gni.net (130.81.209.230) 9.002 ms ae20-0.RES-BB-RTR1.verizon-gni.net (130.81.151.112) 8.995 ms so-1-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.199.2) 8.953 ms > 5 * * * > 6 * * * > 7 0.xe-5-0-4.XL3.EWR6.ALTER.NET (140.222.225.73) 51.202 ms 41.102 ms 40.345 ms > 8 0.ae1.XL4.EWR6.ALTER.NET (140.222.228.41) 33.065 ms TenGigE0-6-0-3.GW8.EWR6.ALTER.NET (152.63.19.158) 11.550 ms TenGigE0-6-0-6.GW8.EWR6.ALTER.NET (152.63.25.10) 11.659 ms > 9 TenGigE0-7-0-1.GW8.EWR6.ALTER.NET (152.63.19.166) 19.854 ms akamai-gw.customer.alter.net (152.179.185.126) 1766.402 ms TenGigE0-7-0-7.GW8.EWR6.ALTER.NET (152.63.25.30) 18.227 ms > 10 akamai-gw.customer.alter.net (152.179.185.126) 1747.269 ms a23-76-217-145.deploy.static.akamaitechnologies.com (23.76.217.145) 10.672 ms 11.263 ms > > Traceroute6 to it appears to be local (but is hard to tell. Next-to-last hop looks like either a router or > load-balancer is overloaded. Same for the v4 traceroute... > > [pete at port5 ~]$ traceroute6 www.att.com > traceroute to www.att.com (2600:807:320:202:9200::90e), 30 hops max, 80 byte packets > 1 rtr.east.altadena.net (2001:470:e160:1::1) 5.182 ms 5.274 ms 5.254 ms > 2 altadenamd-1.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:126::1) 11.452 ms 15.040 ms 18.592 ms > 3 ge4-12.core1.ash1.he.net (2001:470:0:90::1) 20.273 ms 20.574 ms 20.567 ms > 4 eqx.br6.iad8.verizonbusiness.com (2001:504:0:2::701:1) 20.522 ms 20.232 ms 20.475 ms > 5 * * * > 6 2600:802:44f::2 (2600:802:44f::2) 1283.113 ms 1296.115 ms 1296.181 ms > 7 2600:807:320:200::1743:f397 (2600:807:320:200::1743:f397) 20.181 ms 16.169 ms 14.073 ms > > > [pete at port5 ~]$ host www.google.com > www.google.com has address 74.125.228.16 > www.google.com has address 74.125.228.20 > www.google.com has address 74.125.228.17 > www.google.com has address 74.125.228.19 > www.google.com has address 74.125.228.18 > www.google.com has IPv6 address 2607:f8b0:4004:800::1012 > > Traceroute (v4) to this shows something odd, but I don't know where "burl" is for verizon. Also I appear to > hit two nodes for the terminal. At least one google node appears to be ashburn (or environs) > : > [pete at port5 ~]$ traceroute www.google.com > traceroute to www.google.com (74.125.228.20), 30 hops max, 60 byte packets > 1 rtr.east.altadena.net (192.168.170.1) 2.646 ms 2.816 ms 3.536 ms > 2 L300.BLTMMD-VFTTP-64.verizon-gni.net (108.3.150.1) 4.109 ms 4.194 ms 4.186 ms > 3 G0-7-4-4.BLTMMD-LCR-22.verizon-gni.net (130.81.170.84) 7.928 ms 8.096 ms 8.088 ms > 4 ae20-0.PHIL-BB-RTR1.verizon-gni.net (130.81.151.120) 10.881 ms ae20-0.PHIL-BB-RTR2.verizon-gni.net (130.81.151.124) 11.074 ms so-6-1-0-0.PHIL-BB-RTR2.verizon-gni.net (130.81.199.4) 11.047 ms > 5 0.xe-7-0-2.XL2.IAD8.ALTER.NET (152.63.4.93) 14.872 ms 0.xe-3-0-1.XL3.IAD8.ALTER.NET (152.63.3.61) 37.703 ms 12.268 ms > 6 0.xe-9-2-0.GW9.IAD8.ALTER.NET (152.63.36.30) 12.866 ms 0.xe-11-2-1.GW9.IAD8.ALTER.NET (152.63.42.2) 14.442 ms 0.xe-9-2-0.GW9.IAD8.ALTER.NET (152.63.36.30) 11.918 ms > 7 * 0.xe-10-1-1.GW9.IAD8.ALTER.NET (152.63.35.113) 16.901 ms pool-96-236-104-66.burl.east.verizon.net (96.236.104.66) 136.110 ms > 8 pool-96-236-104-66.burl.east.verizon.net (96.236.104.66) 137.977 ms 216.239.46.248 (216.239.46.248) 13.875 ms pool-96-236-104-66.burl.east.verizon.net (96.236.104.66) 134.602 ms > 9 216.239.46.248 (216.239.46.248) 15.918 ms 10.708 ms 10.162 ms > 10 72.14.238.173 (72.14.238.173) 11.347 ms 12.111 ms iad23s05-in-f20.1e100.net (74.125.228.20) 12.769 ms > > Corresponding traceroute6 (shows lack of reverse on most hits...): > [pete at port5 ~]$ traceroute6 www.google.com > traceroute to www.google.com (2607:f8b0:4004:800::1011), 30 hops max, 80 byte packets > 1 rtr.east.altadena.net (2001:470:e160:1::1) 1.640 ms 1.811 ms 1.801 ms > 2 altadenamd-1.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:126::1) 11.977 ms 15.279 ms 19.265 ms > 3 ge4-12.core1.ash1.he.net (2001:470:0:90::1) 19.779 ms 20.776 ms 22.303 ms > 4 2001:4860:1:1:0:1b1b:0:d (2001:4860:1:1:0:1b1b:0:d) 22.267 ms 22.514 ms 22.507 ms > 5 2001:4860::1:0:9ff (2001:4860::1:0:9ff) 22.508 ms 22.471 ms 22.455 ms > 6 2001:4860:0:1::551 (2001:4860:0:1::551) 22.467 ms 19.139 ms 19.116 ms > 7 2607:f8b0:8000:18::c (2607:f8b0:8000:18::c) 19.054 ms 2607:f8b0:8000:18::f (2607:f8b0:8000:18::f) 7.716 ms 2607:f8b0:4004:800::1b (2607:f8b0:4004:800::1b) 8.379 ms > > Again shows multiple terminals for the given address. > > > Ping works fine to all of the addresses, both v4 and v6, and the att one > always connects immediately. The google one doesn't always. > > When I disable the HE tunnel, (and restart the browser - apparently > happy-eyeballs caches), everything works just fine, so the problem does > appear to relate to v6. > > For reference, I mostly use chrome in linux. My daughter sees the same > problem with google, mostly using chrome in win 7. I see the problem > with firefox (in linux) also (to both sites). > > -- Pete > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From morrowc.lists at gmail.com Sun Nov 9 22:00:47 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 9 Nov 2014 17:00:47 -0500 Subject: v6 cdn problems In-Reply-To: <545EA2DC.4080800@massar.ch> References: <545E9F77.90504@altadena.net> <545EA2DC.4080800@massar.ch> Message-ID: On Sat, Nov 8, 2014 at 6:10 PM, Jeroen Massar wrote: > Google does not seem to be home. to be clear, folk who care do know about the problem and are working on a solution... From jwillie4020 at gmail.com Mon Nov 10 00:38:42 2014 From: jwillie4020 at gmail.com (scottie mac) Date: Mon, 10 Nov 2014 11:38:42 +1100 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: <54600912.70802@gmail.com> Holy molly, thankyou!! I just enrolled. On 08/11/14 23:00, nanog-request at nanog.org wrote: > From: "Wakefield, Thad M." To: > "nanog at nanog.org" Subject: RE: Cisco CCNA Training > Message-ID: > > Content-Type: text/plain; charset="utf-8" Until midnight Monday this > course is on sale for $24: > https://www.udemy.com/collection/thankyou-400-24deal >> >-----Original Message----- >> >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of scottie mac >> >Sent: Tuesday, November 04, 2014 6:02 PM >> >To:nanog at nanog.org >> >Subject: Re: Cisco CCNA Training >> > >> >This course has 25 hours of video, I haven't started it yet but I've watched >> >many of Laz's videos on Youtube, and he explains stuff very well. >> >It is $399 though. >> >They could share the Udemy account, and watch them in their free time. >> >*I'm not affiliated with Udemy* >> > >> >https://www.udemy.com/the-complete-ccna-200-120-course From larrysheldon at cox.net Mon Nov 10 01:23:32 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Sun, 09 Nov 2014 19:23:32 -0600 Subject: Reporting DDOS reflection attacks In-Reply-To: References: <545D15EF.8080509@prgmr.com> <000201cffbaa$82416690$86c433b0$@iname.com> <8F12CCCA-6B91-44B6-B0D8-8AEF0E1BC7E9@gmail.com> Message-ID: <54601394.2020309@cox.net> On 11/9/2014 13:40, Doug Barton wrote: > On 11/8/14 6:33 PM, Roland Dobbins wrote: >> this is incorrect and harmful, and should be removed: >> >> iii. Consider dropping any DNS reply packets which are larger >> than 512 Bytes – these are commonly found in DNS DoS Amplification >> attacks. >> >> This *breaks the Internet*. Don't do it. > > +1 > The whole thing> Really? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From rdobbins at arbor.net Mon Nov 10 01:25:54 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 10 Nov 2014 08:25:54 +0700 Subject: Reporting DDOS reflection attacks In-Reply-To: <54601394.2020309@cox.net> References: <545D15EF.8080509@prgmr.com> <000201cffbaa$82416690$86c433b0$@iname.com> <8F12CCCA-6B91-44B6-B0D8-8AEF0E1BC7E9@gmail.com> <54601394.2020309@cox.net> Message-ID: <2C37F5C8-8418-4A3C-8D16-A5D7B640C4DD@arbor.net> On 10 Nov 2014, at 8:23, Larry Sheldon wrote: > The whole thing> Really? Breaking DNS for your customers pretty much breaks the Internet for them, yes. ----------------------------------- Roland Dobbins From lorell at hathcock.org Mon Nov 10 02:18:15 2014 From: lorell at hathcock.org (Lorell Hathcock) Date: Sun, 9 Nov 2014 20:18:15 -0600 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? Message-ID: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> All: A job opportunity just came my way to work with 26 miles of dark fiber in and around a city in Texas. The intent is for me to deliver internet and private network services to business customers in this area. I relish the thought of starting from scratch to build a network right from the start instead of inheriting and fixing someone else's mess. That being said, what suggestions does the group have for building a new network using existing dark fiber? MPLS backbone? Like all businesses these days, I will likely have to build the lit backbone as I add customers. So how would you recommend scaling the network? I have six strands of SMF that connect within municipal facilities. Each new customer will be a new build out from the nearest point. Because of having only six strands, I don't anticipate selling dark fiber. I believe I need to conserve fibers so that it would be lit services that I offer to customers. I would like to offer speeds up to 10 GB. Thoughts are appreciated! Sincerely, Lorell Hathcock From srikanth at gatech.edu Mon Nov 10 02:31:18 2014 From: srikanth at gatech.edu (Srikanth Sundaresan) Date: Sun, 09 Nov 2014 18:31:18 -0800 Subject: FW: M-Lab-Related PCAPs In-Reply-To: References: Message-ID: <54602376.7010205@gatech.edu> Thanks Jason. I've tried to organize them here: http://www1.icsi.berkeley.edu/~srikanth/tos.html So please send along any interesting traces, any ideas for tests, or comments! - Srikanth On 11/8/14 9:46 PM, Livingood, Jason wrote: > FYI to this list since I suspect few of you are on the M-Lab Discuss list. > > Srikanth from ICSI has kindly taken on consolidating some PCAPs. If anyone wishes to send any to him, he is at srknth.s at gmail.com. > > JL > > > On 11/6/14, 7:24 PM, "Srikanth S" > wrote: > So it looks as though marking is not done for all MLab traffic. Also, some web traffic (to CNN) is marked at a lower priority than streaming (Netflix), which is strange as web traffic is likely more sensitive to degradation than streaming (?). > > > Here are the traces: > http://www1.icsi.berkeley.edu/~srikanth/pcaps/google.pcap > http://www1.icsi.berkeley.edu/~srikanth/pcaps/youtube-image.pcap > http://www1.icsi.berkeley.edu/~srikanth/pcaps/cnn.pcap > http://www1.icsi.berkeley.edu/~srikanth/pcaps/netflix-streaming.pcap > > On Tuesday, November 4, 2014 1:29:16 PM UTC-8, Jason Livingood wrote: > Another follow-up. Someone emailed me a PCAP off-list from an enterprise type of customer. Their PCAP was somewhat incomplete (so I still need more) but they noticed that some traffic at the next priority down from 0x48 at 0x28 (priority). And some other traffic was marked with the next priority down again at 0x00 (routine). > > So it appears there are three DSCP / ToS markings in use rather than just two (0x00, 0x28, 0x48). > > So safe to say more research is needed here – anyone collecting PCAPs should IMHO continue. :-) > > Jason > From fkittred at gwi.net Mon Nov 10 02:56:08 2014 From: fkittred at gwi.net (Fletcher Kittredge) Date: Sun, 9 Nov 2014 21:56:08 -0500 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> Message-ID: The below is a really sad story. Condolences on the coming trainwreck. I hope you get someone on staff or on consult that understands outside plant architecture, because it is much more important and complex topic than you seem to realize. On Sun, Nov 9, 2014 at 9:18 PM, Lorell Hathcock wrote: > All: > > A job opportunity just came my way to work with 26 miles of dark fiber in > and around a city in Texas. > > The intent is for me to deliver internet and private network services to > business customers in this area. > > I relish the thought of starting from scratch to build a network right > from the start instead of inheriting and fixing someone else's mess. > > That being said, what suggestions does the group have for building a new > network using existing dark fiber? > > MPLS backbone? Like all businesses these days, I will likely have to > build the lit backbone as I add customers. So how would you recommend > scaling the network? > > I have six strands of SMF that connect within municipal facilities. Each > new customer will be a new build out from the nearest point. Because of > having only six strands, I don't anticipate selling dark fiber. I believe I > need to conserve fibers so that it would be lit services that I offer to > customers. > > I would like to offer speeds up to 10 GB. > > Thoughts are appreciated! > > Sincerely, > > Lorell Hathcock -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From baldur.norddahl at gmail.com Mon Nov 10 03:06:53 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 10 Nov 2014 04:06:53 +0100 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> Message-ID: Hi, 26 miles is not a long distance when working with fiber. I would have just one active POPs (or two for redundancy). Use DWDM to expand your 6 strands into as many links as you need. You could also use GPON with splitters, although that will only deliver 1 Gbps (on a shared 2.4 Gbps) at this time. DWDM allows you to sell "colored links" to customers, that they can do anything with. MPLS might be overdoing it or not, depending on your background and experience. Using VLANs or layer 3 routing might get you the same thing. I would say the proposed network is small enough that you could get away with just about anything. Just remember that you need to protect your network from customers. Eg. you are using STP and the customer enables STP, you could very well end up with a disaster if not careful. Many network protocols have zero security and many switch configurations are vulnerable to simple mistakes by default. Regards, Baldur From faisal at snappytelecom.net Mon Nov 10 03:14:29 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 10 Nov 2014 03:14:29 +0000 (GMT) Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> Message-ID: <408485736.424491.1415589269215.JavaMail.zimbra@snappytelecom.net> WoW !.. that was a rather cruel and un-called for ! How does that saying go.....Don't say anything, if you cannot say anything nice ! Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Fletcher Kittredge" > To: "Lorell Hathcock" > Cc: nanog at nanog.org > Sent: Sunday, November 9, 2014 9:56:08 PM > Subject: Re: I am about to inherit 26 miles of dark fiber. What do I do with it? > > The below is a really sad story. Condolences on the coming trainwreck. I > hope you get someone on staff or on consult that understands outside plant > architecture, because it is much more important and complex topic than you > seem to realize. > > > On Sun, Nov 9, 2014 at 9:18 PM, Lorell Hathcock wrote: > > > All: > > > > A job opportunity just came my way to work with 26 miles of dark fiber in > > and around a city in Texas. > > > > The intent is for me to deliver internet and private network services to > > business customers in this area. > > > > I relish the thought of starting from scratch to build a network right > > from the start instead of inheriting and fixing someone else's mess. > > > > That being said, what suggestions does the group have for building a new > > network using existing dark fiber? > > > > MPLS backbone? Like all businesses these days, I will likely have to > > build the lit backbone as I add customers. So how would you recommend > > scaling the network? > > > > I have six strands of SMF that connect within municipal facilities. Each > > new customer will be a new build out from the nearest point. Because of > > having only six strands, I don't anticipate selling dark fiber. I believe I > > need to conserve fibers so that it would be lit services that I offer to > > customers. > > > > I would like to offer speeds up to 10 GB. > > > > Thoughts are appreciated! > > > > Sincerely, > > > > Lorell Hathcock > > > > > -- > Fletcher Kittredge > GWI > 8 Pomerleau Street > Biddeford, ME 04005-9457 > 207-602-1134 > From baldur.norddahl at gmail.com Mon Nov 10 03:15:42 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 10 Nov 2014 04:15:42 +0100 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> Message-ID: Hey come on. Yes it is complex but not impossible to learn "on the job". You have absolutely no knowledge of his skills and know almost nothing about the project. How can you say anything about the impossibility of overcoming the challenges ahead? One thing that amazes me about NANOG is that while you often do get valuable advice, you also get a ton of hatemail from daring to ask or voice an opinion. Regards, Baldur On 10 November 2014 03:56, Fletcher Kittredge wrote: > The below is a really sad story. Condolences on the coming trainwreck. I > hope you get someone on staff or on consult that understands outside plant > architecture, because it is much more important and complex topic than you > seem to realize. > > > On Sun, Nov 9, 2014 at 9:18 PM, Lorell Hathcock > wrote: > > > All: > > > > A job opportunity just came my way to work with 26 miles of dark fiber in > > and around a city in Texas. > > > > The intent is for me to deliver internet and private network services to > > business customers in this area. > > > > I relish the thought of starting from scratch to build a network right > > from the start instead of inheriting and fixing someone else's mess. > > > > That being said, what suggestions does the group have for building a new > > network using existing dark fiber? > > > > MPLS backbone? Like all businesses these days, I will likely have to > > build the lit backbone as I add customers. So how would you recommend > > scaling the network? > > > > I have six strands of SMF that connect within municipal facilities. Each > > new customer will be a new build out from the nearest point. Because of > > having only six strands, I don't anticipate selling dark fiber. I > believe I > > need to conserve fibers so that it would be lit services that I offer to > > customers. > > > > I would like to offer speeds up to 10 GB. > > > > Thoughts are appreciated! > > > > Sincerely, > > > > Lorell Hathcock > > > > > -- > Fletcher Kittredge > GWI > 8 Pomerleau Street > Biddeford, ME 04005-9457 > 207-602-1134 > From streiner at cluebyfour.org Mon Nov 10 03:18:11 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 9 Nov 2014 22:18:11 -0500 (EST) Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> Message-ID: On Sun, 9 Nov 2014, Lorell Hathcock wrote: > A job opportunity just came my way to work with 26 miles of dark fiber > in and around a city in Texas. How is the outside plant being built and supported? Who fixes fiber cuts? Who manages the fiber-cut-fixers? Who monitors the network and handles initial triage to determine if there is a fiber cut, as opposed to a hardware/optic failure? Those questions lead to many others, such as who has documentation and as-built drawings for the fiber plant? Are all of the access agreements, insurance certificates, letters of agency, etc. up to date and accurate? jms From faisal at snappytelecom.net Mon Nov 10 03:25:46 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 10 Nov 2014 03:25:46 +0000 (GMT) Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> Message-ID: <260979806.424530.1415589946529.JavaMail.zimbra@snappytelecom.net> I would suggest that you do some rapid field deployment education in regards to fiber networks. You might consider joining WISPA and or FISPA (two industry associations), where you have folks building out fiber networks, who are very willing to share their experience and tell you what is working and what is not working. Working with Dark fiber can be as simple as you like, or as complicated as you want it to be. However this is one area that it is not un-common to make things appear a lot more expensive and complicated then what they have to be... Depending on what you are inheriting, and what you have to be responsible for, I would suggest that you spend some time on the web, local library, and some of the OSP related publications to get a good understanding of what is done and why....before just falling for industry jargon. I should be fun... :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Lorell Hathcock" > To: nanog at nanog.org > Sent: Sunday, November 9, 2014 9:18:15 PM > Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? > > All: > > A job opportunity just came my way to work with 26 miles of dark fiber in and > around a city in Texas. > > The intent is for me to deliver internet and private network services to > business customers in this area. > > I relish the thought of starting from scratch to build a network right from > the start instead of inheriting and fixing someone else's mess. > > That being said, what suggestions does the group have for building a new > network using existing dark fiber? > > MPLS backbone? Like all businesses these days, I will likely have to build > the lit backbone as I add customers. So how would you recommend scaling the > network? > > I have six strands of SMF that connect within municipal facilities. Each new > customer will be a new build out from the nearest point. Because of having > only six strands, I don't anticipate selling dark fiber. I believe I need to > conserve fibers so that it would be lit services that I offer to customers. > > I would like to offer speeds up to 10 GB. > > Thoughts are appreciated! > > Sincerely, > > Lorell Hathcock From surfer at mauigateway.com Mon Nov 10 03:49:03 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 9 Nov 2014 19:49:03 -0800 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? Message-ID: <20141109194903.80F285B7@m0005311.ppops.net> --- fkittred at gwi.net wrote: From: Fletcher Kittredge The below is a really sad story. Condolences on the coming trainwreck. I hope you get someone on staff or on consult that understands outside plant architecture, because it is much more important and complex topic than you seem to realize. ----------------------------------------- Help guide and build knowledge instead of publicly beat down. scott From lorell at hathcock.org Mon Nov 10 04:19:01 2014 From: lorell at hathcock.org (Lorell Hathcock) Date: Sun, 9 Nov 2014 22:19:01 -0600 Subject: I am about to inherit 26 miles of dark fiber Message-ID: Ah, the famous good-will of NANOG. I knew I would get some interesting responses. I was part of the Field Ops group of Enron Broadband years ago. We deployed DWDM extensively. Admittedly it has been a while. This 26 miles of dark fiber is deployed by a municipality in and around their fair city. Part of a deal with this new firm is that the firm will use the aforementioned six strands. So the fiber is deployed throughout this city that has been largely under-serviced. By lack of resources, the city could not deploy services to businesses/enterprises. So as I ponder the opportunity, I seek to tap the creative juices of NANOG. Thanks, Lorell Hathcock From itg at itechgeek.com Mon Nov 10 04:22:42 2014 From: itg at itechgeek.com (ITechGeek) Date: Sun, 9 Nov 2014 23:22:42 -0500 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: <260979806.424530.1415589946529.JavaMail.zimbra@snappytelecom.net> References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> <260979806.424530.1415589946529.JavaMail.zimbra@snappytelecom.net> Message-ID: I would say the OP is starting out right by reaching out to people who can give advice and point him in the right direction. I would say the first place to start would be budget. I don't think calling this is a trainwreck before it even leaves paper isn't very helpful. One option might be to start in phases, if his POPs can provide decent coverage, maybe start out w/ a wireless solution to start getting customers on the system and start getting revenue coming in (or if this is a city/town backed venture, get voters to see how useful this can be to maybe get more budget for future rollout). Also talk to business customers to see if you extend fiber to them, what kind of services will they want. If you can get large customers to say "Yes, I will or would like to purchase a gig of bandwidth between two office or a gig of Internet access", that should help w/ either city or private finance backing to show there will be demand. You might even be able to get help from some companies (If you contact corporate or gov't sales for Cisco/Nortel/etc., they can probably have some techs bring in some equipment for small scale shows). If this is a city trying to do this, reach out to places like Chattanooga, TN or Lafayette, LA or any number of other cities (mostly in foreign countries) that have successfully done this. http://en.wikipedia.org/wiki/LUSFiber http://en.wikipedia.org/wiki/EPB On a final note, the Stockholm model I've always thought was the best idea (even before I heard Stockholm invested in it) - Stockholm owns the infrastructure and private companies provide the actual customer services across the city owned infrastructure (let true competition happen instead of the monopoly and duopoly in most cities and if it doesn't work out, you can always start selling services later if true competition doesn't work). http://cis471.blogspot.com/2009/04/why-is-connectivty-in-stockholm-so-much.html (This was the most up to date page I could find in English doing a comparison). ----------------------------------------------------------------------------------------------- -ITG (ITechGeek) ITG at ITechGeek.Com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net On Sun, Nov 9, 2014 at 10:25 PM, Faisal Imtiaz wrote: > I would suggest that you do some rapid field deployment education in > regards to fiber networks. > > You might consider joining WISPA and or FISPA (two industry > associations), where you have folks building out fiber networks, who are > very willing to share their experience and tell you what is working and > what is not working. > > Working with Dark fiber can be as simple as you like, or as complicated as > you want it to be. However this is one area that it is not un-common to > make things appear a lot more expensive and complicated then what they have > to be... > > Depending on what you are inheriting, and what you have to be responsible > for, I would suggest that you spend some time on the web, local library, > and some of the OSP related publications to get a good understanding of > what is done and why....before just falling for industry jargon. > > I should be fun... :) > > Faisal Imtiaz > Snappy Internet & Telecom > > > ----- Original Message ----- > > From: "Lorell Hathcock" > > To: nanog at nanog.org > > Sent: Sunday, November 9, 2014 9:18:15 PM > > Subject: I am about to inherit 26 miles of dark fiber. What do I do with > it? > > > > All: > > > > A job opportunity just came my way to work with 26 miles of dark fiber > in and > > around a city in Texas. > > > > The intent is for me to deliver internet and private network services to > > business customers in this area. > > > > I relish the thought of starting from scratch to build a network right > from > > the start instead of inheriting and fixing someone else's mess. > > > > That being said, what suggestions does the group have for building a new > > network using existing dark fiber? > > > > MPLS backbone? Like all businesses these days, I will likely have to > build > > the lit backbone as I add customers. So how would you recommend scaling > the > > network? > > > > I have six strands of SMF that connect within municipal facilities. Each > new > > customer will be a new build out from the nearest point. Because of > having > > only six strands, I don't anticipate selling dark fiber. I believe I > need to > > conserve fibers so that it would be lit services that I offer to > customers. > > > > I would like to offer speeds up to 10 GB. > > > > Thoughts are appreciated! > > > > Sincerely, > > > > Lorell Hathcock > From surfer at mauigateway.com Mon Nov 10 05:42:55 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 9 Nov 2014 21:42:55 -0800 Subject: I am about to inherit 26 miles of dark fiber Message-ID: <20141109214255.80F287AD@m0005311.ppops.net> :: Ah, the famous good-will of NANOG. But you got more of the good than the other. :: I knew I would get some interesting responses. And you got more of that than non-interesting... :-) scott From jeroen at massar.ch Mon Nov 10 05:51:35 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 10 Nov 2014 06:51:35 +0100 Subject: v6 cdn problems In-Reply-To: References: <545E9F77.90504@altadena.net> <545EA2DC.4080800@massar.ch> Message-ID: <54605267.2060706@massar.ch> On 2014-11-09 23:00, Christopher Morrow wrote: > On Sat, Nov 8, 2014 at 6:10 PM, Jeroen Massar wrote: >> Google does not seem to be home. Note that you skipped the rest: "Google does not seem to be home. They used to have a handy ipv6 at google.com address, but alas, that does not exist anymore." There used to be a handy ipv6 at google address for reporting things. This nowadays bounces. > to be clear, folk who care do know about the problem and are working > on a solution... The problem Google was having was already resolved according to Damian as noted on the outages list. Seems those archives don't update at the moment, hence: http://permalink.gmane.org/gmane.org.operators.ipv6/10232 Greets, Jeroen From morrowc.lists at gmail.com Mon Nov 10 08:10:18 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 10 Nov 2014 03:10:18 -0500 Subject: v6 cdn problems In-Reply-To: <54605267.2060706@massar.ch> References: <545E9F77.90504@altadena.net> <545EA2DC.4080800@massar.ch> <54605267.2060706@massar.ch> Message-ID: On Mon, Nov 10, 2014 at 12:51 AM, Jeroen Massar wrote: > There used to be a handy ipv6 at google address for reporting things. This > nowadays bounces. yes, it changed to noc@ I think. and yup, damian (and a few other folk) beat the mtu issue with a cold trout. From jeroen at massar.ch Mon Nov 10 08:17:08 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 10 Nov 2014 09:17:08 +0100 Subject: v6 cdn problems In-Reply-To: References: <545E9F77.90504@altadena.net> <545EA2DC.4080800@massar.ch> <54605267.2060706@massar.ch> Message-ID: <54607484.8060701@massar.ch> On 2014-11-10 09:10, Christopher Morrow wrote: > On Mon, Nov 10, 2014 at 12:51 AM, Jeroen Massar wrote: >> There used to be a handy ipv6 at google address for reporting things. This >> nowadays bounces. > > yes, it changed to noc@ I think. Thus, in case of an IPv6 issue, contacting noc at google.com is the right thing to do? Good to hear that the folks there are aware of IPv6. > and yup, damian (and a few other folk) beat the mtu issue with a cold trout. Thanks for that. >From a message by Lorenzo: http://lists.cluenet.de/pipermail/ipv6-ops/2014-November/010278.html it seems Google is breaking PMTUD on purpose preferring to force the MSS to a minimum value instead. But the problem there is not PMTUD, but what is described in: https://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem-01 Which makes sense on a Google-scale of connections. I am not sure that breaking PTMUD and forcing MSS is the correct answer though. Forcing MSS is likely a good intermediary step, actually fixing the load-balancer is a better one though. I am now wondering if that is what is hitting Akamai too, as that would explain the problem being seen: contacting the same IP sometimes works and sometimes does not; which could be a result of the real endnode not always seeing the correct ICMP and thus knowing the correct MTU. Greets, Jeroen From jeroen at massar.ch Mon Nov 10 10:35:12 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 10 Nov 2014 11:35:12 +0100 Subject: Fwd: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-01) In-Reply-To: <54609418.5030503@massar.ch> References: <54609418.5030503@massar.ch> Message-ID: <546094E0.2030202@massar.ch> Forwarding this so that everybody can comment on this nasty proposal ;) Forcing replies to v6ops at ietf.org where they likely should be taking place as that is where recently the mentioned draft was accepted as a WG item. Greets, Jeroen -------- Forwarded Message -------- Subject: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-01) Date: Mon, 10 Nov 2014 11:31:52 +0100 From: Jeroen Massar Organization: Massar To: ipv6 at ietf.org, v6ops at ietf.org Hola folks (and folks in BCC ;), With the recent Google and Akamai outages (latter still ongoing afaik), it came to light that the cause is likely the model and problem described here: https://tools.ietf.org/html/draft-v6ops-pmtud-ecmp-problem-01 which previously was: https://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem-01 Or shortly described: terminating an IP address at different hosts and having the balancer box not knowing where to deliver the ICMP PTBs that get send for large packets. One of the suggestions there is to lower the MSS for every connection by forcing it (either on the loadbalancer or on the final host) to a value that "works everywhere": the one for an MTU of 1280. MSS only applies to TCP, and people like Google are coming out with QUIC and other schemes. As we really do not want an Internet at an MTU of 1280, why don't we indicate in the packet what the MTU is when it is diverting from the norm? What if we instead let a router that sources a packet from a link or is going to transmit a packet over a link < 1500 indicate with that packet that that packet came from/is going to is a link with a MTU < 1500. We can't use an additional extension header, as adding anything would mean we might hit the MTU of the packet and we have other issues. As our least-known-used field is the FlowLabel field, we could abuse that and have enough bits there to stuff our data. What if we define that when the first 4 bits are set to 0xF (all one) that the rest (16bits) defines the MTU of the link (MTU 0 - 65k)? (We could even use a 'base of 1280' and thus 0xf0000 = 1280 MTU, but possibly it is better to state "value of < 0xf0500 is invalid") Thus allowing when the first 4 bits are not set to all-1 that the flowlabel field is a "normal flowlabel" field ala RFC6437. We could even state "Only set this MTU option when the FlowLabel field == 0" to avoid incompatibility (though I do not expect any as I rarely see packets with the field non-0...) Thus given a network like: [H1] 2001:db8:1500::1/64 | mtu = 1500 2001:db8:1500::a/64 [RA] 2001:db8:1501::a/64 | mtu = 1500 2001:db8:1501::b/64 [RB] 2001:db8:1480::b/64 | mtu = 1480 2001:db8:1480::c/64 [RC] 2001:db8:1280::c/64 | mtu = 1280 2001:db8:1280::d/64 [RD] 2001:db8:9000::d/64 | mtu = 9000 2001:db8:9000::2/64 [H2] RA receives packet, src+dst interface are MTU=1500, thus does nothing RB receives packet, src = 1500, dst = 1480, thus sets FL = 0xf05c8 RC receives packet, src = 1480, dst = 1280, thus sets FL = 0xf0500 RD receives packet, src = 1280, dst = 9000, thus sets FL = 0xf0500 (again, just set is quicker than checking) Now even if H2 is a loadbalancer, if the flow is just forwarded (without TTL change btw...) the destination receives it correctly. The disadvantage is of course that you lose the ability to balance based on the FlowLabel, but if we go with "only change when not 0 then there was one anyway. Also you got src+dst which is 256bits, which should be pretty good already and optionally next-header + the contents of the header if you want that. Note that as we have no checksum in IPv6, there is little overhead to do this kind of forwarding, HopLimit already needs updating, this is just another field to update. In another model from the above, we could even just let every hop set the known lowest MTU. In that case, H1 would set 0xf05dc in the packet, and then it gets lowered automatically. Which would also mean that a pure 9000 path would nicely work suddenly as everybody knows that 9000 will fit :) Greets, Jeroen _______________________________________________ v6ops mailing list v6ops at ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fkittred at gwi.net Mon Nov 10 12:13:02 2014 From: fkittred at gwi.net (Fletcher Kittredge) Date: Mon, 10 Nov 2014 07:13:02 -0500 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: <20141109194903.80F285B7@m0005311.ppops.net> References: <20141109194903.80F285B7@m0005311.ppops.net> Message-ID: OutSide Plant design(OSP) is a specialized field worthy of significant study. The consequences of getting a OSP design wrong are much harder to fix than getting a network design wrong. You are designing for *20 years*. If you are at the point of asking a mailing list NANOG, which, um, is not focused on OSP expertise, it is a really, really good idea to concentrate on hiring the best consultant. I have viewed this train wreck too many times. On Sun, Nov 9, 2014 at 10:49 PM, Scott Weeks wrote: > > > --- fkittred at gwi.net wrote: > From: Fletcher Kittredge > > The below is a really sad story. Condolences on the coming trainwreck. I > hope you get someone on staff or on consult that understands outside plant > architecture, because it is much more important and complex topic than you > seem to realize. > ----------------------------------------- > > > Help guide and build knowledge instead of publicly beat down. > > scott > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From fkittred at gwi.net Mon Nov 10 12:40:30 2014 From: fkittred at gwi.net (Fletcher Kittredge) Date: Mon, 10 Nov 2014 07:40:30 -0500 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> <260979806.424530.1415589946529.JavaMail.zimbra@snappytelecom.net> Message-ID: Gah! Municipal fiber networks can be total failures or the best investment a community can make. It all depends on the implementation. There are eight steps one needs to get right: 1) public policy goals, 2) technical goals meet the public policy goals, 3) survey community demographics and existing network assets, 4) build community consensus, 5) select the right business plan and obtain funding, 6) technical design of OSP and operating structure, 7) RFI/RFP, 8)select EPC vendors and fanatically oversee construction. Steps 1-5 are the most important and the level of success will depend on the quality of their implementation. If a half-assed job is done at any step, the outcome will not be good. This discussion has been focused on step 6: technical design. It is impossible to do a good technical design if you don't understand the problem you are trying to solve. There are vast differences between different municipalities public policy goals and business plans. It doesn't make sense to copy Chattanooga's implementation because their situation is different than yours (you have an existing fiber network, which is always a warning sign. They are serving all residents and businesses and you imply you are focused on businesses.) Focus on developing a deep understanding of what problem the city leaders are trying to solve, then figure out how to hire a competent OSP design person and make them do a good job. This is a hard task in and of itself. The failure of one municipal broadband system reflects badly on all municipal broadband systems. Good luck. On Sun, Nov 9, 2014 at 11:22 PM, ITechGeek wrote: > I would say the OP is starting out right by reaching out to people who can > give advice and point him in the right direction. I would say the first > place to start would be budget. > > I don't think calling this is a trainwreck before it even leaves paper > isn't very helpful. > > One option might be to start in phases, if his POPs can provide decent > coverage, maybe start out w/ a wireless solution to start getting customers > on the system and start getting revenue coming in (or if this is a > city/town backed venture, get voters to see how useful this can be to maybe > get more budget for future rollout). > > Also talk to business customers to see if you extend fiber to them, what > kind of services will they want. If you can get large customers to say > "Yes, I will or would like to purchase a gig of bandwidth between two > office or a gig of Internet access", that should help w/ either city or > private finance backing to show there will be demand. > > You might even be able to get help from some companies (If you contact > corporate or gov't sales for Cisco/Nortel/etc., they can probably have some > techs bring in some equipment for small scale shows). > > If this is a city trying to do this, reach out to places like Chattanooga, > TN or Lafayette, LA or any number of other cities (mostly in foreign > countries) that have successfully done this. > http://en.wikipedia.org/wiki/LUSFiber > http://en.wikipedia.org/wiki/EPB > > On a final note, the Stockholm model I've always thought was the best idea > (even before I heard Stockholm invested in it) - Stockholm owns the > infrastructure and private companies provide the actual customer services > across the city owned infrastructure (let true competition happen instead > of the monopoly and duopoly in most cities and if it doesn't work out, you > can always start selling services later if true competition doesn't work). > > http://cis471.blogspot.com/2009/04/why-is-connectivty-in-stockholm-so-much.html > (This was the most up to date page I could find in English doing a > comparison). > > > > ----------------------------------------------------------------------------------------------- > -ITG (ITechGeek) > ITG at ITechGeek.Com > https://itg.nu/ > GPG Keys: https://itg.nu/contact/gpg-key > Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A > Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: > http://fb.me/Jbwa.Net > > On Sun, Nov 9, 2014 at 10:25 PM, Faisal Imtiaz > wrote: > > > I would suggest that you do some rapid field deployment education in > > regards to fiber networks. > > > > You might consider joining WISPA and or FISPA (two industry > > associations), where you have folks building out fiber networks, who are > > very willing to share their experience and tell you what is working and > > what is not working. > > > > Working with Dark fiber can be as simple as you like, or as complicated > as > > you want it to be. However this is one area that it is not un-common to > > make things appear a lot more expensive and complicated then what they > have > > to be... > > > > Depending on what you are inheriting, and what you have to be responsible > > for, I would suggest that you spend some time on the web, local library, > > and some of the OSP related publications to get a good understanding of > > what is done and why....before just falling for industry jargon. > > > > I should be fun... :) > > > > Faisal Imtiaz > > Snappy Internet & Telecom > > > > > > ----- Original Message ----- > > > From: "Lorell Hathcock" > > > To: nanog at nanog.org > > > Sent: Sunday, November 9, 2014 9:18:15 PM > > > Subject: I am about to inherit 26 miles of dark fiber. What do I do > with > > it? > > > > > > All: > > > > > > A job opportunity just came my way to work with 26 miles of dark fiber > > in and > > > around a city in Texas. > > > > > > The intent is for me to deliver internet and private network services > to > > > business customers in this area. > > > > > > I relish the thought of starting from scratch to build a network right > > from > > > the start instead of inheriting and fixing someone else's mess. > > > > > > That being said, what suggestions does the group have for building a > new > > > network using existing dark fiber? > > > > > > MPLS backbone? Like all businesses these days, I will likely have to > > build > > > the lit backbone as I add customers. So how would you recommend scaling > > the > > > network? > > > > > > I have six strands of SMF that connect within municipal facilities. > Each > > new > > > customer will be a new build out from the nearest point. Because of > > having > > > only six strands, I don't anticipate selling dark fiber. I believe I > > need to > > > conserve fibers so that it would be lit services that I offer to > > customers. > > > > > > I would like to offer speeds up to 10 GB. > > > > > > Thoughts are appreciated! > > > > > > Sincerely, > > > > > > Lorell Hathcock > > > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From itg at itechgeek.com Mon Nov 10 13:06:40 2014 From: itg at itechgeek.com (ITechGeek) Date: Mon, 10 Nov 2014 08:06:40 -0500 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> <260979806.424530.1415589946529.JavaMail.zimbra@snappytelecom.net> Message-ID: I never said copy Chattanooga's implementation, I just said reach out to them. While every city is different, he might be able to find out problems other cities had and how they got around those issues. Maybe he might get a few problems/fixes from Chattanooga that might help, maybe a few from Lafayette, maybe none. Maybe he might find something in one of those cities implementations that he thinks would help his, maybe not. Maybe one of them had good or bad experiences w/ a consultant that he might want to use or stay away from. Taking a few extra days to learn about people's successes (Hell, I would even call the cities that failed to see someone can say why they failed) might help the OP out. It never hurts to call or email them. ----------------------------------------------------------------------------------------------- -ITG (ITechGeek) ITG at ITechGeek.Com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net On Mon, Nov 10, 2014 at 7:40 AM, Fletcher Kittredge wrote: > > Gah! > > Municipal fiber networks can be total failures or the best investment a > community can make. It all depends on the implementation. > > There are eight steps one needs to get right: 1) public policy goals, 2) > technical goals meet the public policy goals, 3) survey community > demographics and existing network assets, 4) build community consensus, 5) > select the right business plan and obtain funding, 6) technical design of > OSP and operating structure, 7) RFI/RFP, 8)select EPC vendors and > fanatically oversee construction. > > Steps 1-5 are the most important and the level of success will depend on > the quality of their implementation. If a half-assed job is done at any > step, the outcome will not be good. This discussion has been focused on > step 6: technical design. It is impossible to do a good technical design if > you don't understand the problem you are trying to solve. > > There are vast differences between different municipalities public policy > goals and business plans. It doesn't make sense to copy Chattanooga's > implementation because their situation is different than yours (you have an > existing fiber network, which is always a warning sign. They are serving > all residents and businesses and you imply you are focused on businesses.) > > Focus on developing a deep understanding of what problem the city leaders > are trying to solve, then figure out how to hire a competent OSP design > person and make them do a good job. This is a hard task in and of itself. > > The failure of one municipal broadband system reflects badly on all > municipal broadband systems. Good luck. > > > > On Sun, Nov 9, 2014 at 11:22 PM, ITechGeek wrote: > >> I would say the OP is starting out right by reaching out to people who can >> give advice and point him in the right direction. I would say the first >> place to start would be budget. >> >> I don't think calling this is a trainwreck before it even leaves paper >> isn't very helpful. >> >> One option might be to start in phases, if his POPs can provide decent >> coverage, maybe start out w/ a wireless solution to start getting >> customers >> on the system and start getting revenue coming in (or if this is a >> city/town backed venture, get voters to see how useful this can be to >> maybe >> get more budget for future rollout). >> >> Also talk to business customers to see if you extend fiber to them, what >> kind of services will they want. If you can get large customers to say >> "Yes, I will or would like to purchase a gig of bandwidth between two >> office or a gig of Internet access", that should help w/ either city or >> private finance backing to show there will be demand. >> >> You might even be able to get help from some companies (If you contact >> corporate or gov't sales for Cisco/Nortel/etc., they can probably have >> some >> techs bring in some equipment for small scale shows). >> >> If this is a city trying to do this, reach out to places like Chattanooga, >> TN or Lafayette, LA or any number of other cities (mostly in foreign >> countries) that have successfully done this. >> http://en.wikipedia.org/wiki/LUSFiber >> http://en.wikipedia.org/wiki/EPB >> >> On a final note, the Stockholm model I've always thought was the best idea >> (even before I heard Stockholm invested in it) - Stockholm owns the >> infrastructure and private companies provide the actual customer services >> across the city owned infrastructure (let true competition happen instead >> of the monopoly and duopoly in most cities and if it doesn't work out, you >> can always start selling services later if true competition doesn't work). >> >> http://cis471.blogspot.com/2009/04/why-is-connectivty-in-stockholm-so-much.html >> (This was the most up to date page I could find in English doing a >> comparison). >> >> >> >> ----------------------------------------------------------------------------------------------- >> -ITG (ITechGeek) >> ITG at ITechGeek.Com >> https://itg.nu/ >> GPG Keys: https://itg.nu/contact/gpg-key >> Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A >> Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: >> http://fb.me/Jbwa.Net >> >> On Sun, Nov 9, 2014 at 10:25 PM, Faisal Imtiaz >> wrote: >> >> > I would suggest that you do some rapid field deployment education in >> > regards to fiber networks. >> > >> > You might consider joining WISPA and or FISPA (two industry >> > associations), where you have folks building out fiber networks, who are >> > very willing to share their experience and tell you what is working and >> > what is not working. >> > >> > Working with Dark fiber can be as simple as you like, or as complicated >> as >> > you want it to be. However this is one area that it is not un-common to >> > make things appear a lot more expensive and complicated then what they >> have >> > to be... >> > >> > Depending on what you are inheriting, and what you have to be >> responsible >> > for, I would suggest that you spend some time on the web, local library, >> > and some of the OSP related publications to get a good understanding of >> > what is done and why....before just falling for industry jargon. >> > >> > I should be fun... :) >> > >> > Faisal Imtiaz >> > Snappy Internet & Telecom >> > >> > >> > ----- Original Message ----- >> > > From: "Lorell Hathcock" >> > > To: nanog at nanog.org >> > > Sent: Sunday, November 9, 2014 9:18:15 PM >> > > Subject: I am about to inherit 26 miles of dark fiber. What do I do >> with >> > it? >> > > >> > > All: >> > > >> > > A job opportunity just came my way to work with 26 miles of dark fiber >> > in and >> > > around a city in Texas. >> > > >> > > The intent is for me to deliver internet and private network services >> to >> > > business customers in this area. >> > > >> > > I relish the thought of starting from scratch to build a network right >> > from >> > > the start instead of inheriting and fixing someone else's mess. >> > > >> > > That being said, what suggestions does the group have for building a >> new >> > > network using existing dark fiber? >> > > >> > > MPLS backbone? Like all businesses these days, I will likely have to >> > build >> > > the lit backbone as I add customers. So how would you recommend >> scaling >> > the >> > > network? >> > > >> > > I have six strands of SMF that connect within municipal facilities. >> Each >> > new >> > > customer will be a new build out from the nearest point. Because of >> > having >> > > only six strands, I don't anticipate selling dark fiber. I believe I >> > need to >> > > conserve fibers so that it would be lit services that I offer to >> > customers. >> > > >> > > I would like to offer speeds up to 10 GB. >> > > >> > > Thoughts are appreciated! >> > > >> > > Sincerely, >> > > >> > > Lorell Hathcock >> > >> > > > > -- > Fletcher Kittredge > GWI > 8 Pomerleau Street > Biddeford, ME 04005-9457 > 207-602-1134 > From ruairi.carroll at gmail.com Mon Nov 10 13:18:35 2014 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Mon, 10 Nov 2014 14:18:35 +0100 Subject: Equinix Virginia - Ethernet OOB suggestions Message-ID: Dear List, I've got an upcoming deployment in Equinix (DC10) and I'm struggling to find a provider who can give me a 100Mbit port (With a commit of about 5-10Mbit) with a /23 or /24 of public space , for OOB purposes. We had hoped to use Equinixs services, however they're limiting us to a single public IP. I'm also open to other solutions - xDSL or similar, but emphasis is on cheap and on-net. Cheers /Ruairi From magicsata at gmail.com Mon Nov 10 13:38:55 2014 From: magicsata at gmail.com (Alistair Mackenzie) Date: Mon, 10 Nov 2014 13:38:55 +0000 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: References: Message-ID: Couldn't you put a router or VPN system on the single IP they are giving you and use RFC1918 addressing space? OOB doesn't normally justify a /24 let alone a /23. On 10 November 2014 13:18, Ruairi Carroll wrote: > Dear List, > > I've got an upcoming deployment in Equinix (DC10) and I'm struggling to > find a provider who can give me a 100Mbit port (With a commit of about > 5-10Mbit) with a /23 or /24 of public space , for OOB purposes. We had > hoped to use Equinixs services, however they're limiting us to a single > public IP. > > I'm also open to other solutions - xDSL or similar, but emphasis is on > cheap and on-net. > > Cheers > /Ruairi > From ruairi.carroll at gmail.com Mon Nov 10 14:00:53 2014 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Mon, 10 Nov 2014 15:00:53 +0100 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: References: Message-ID: Hey, VPN setup is not really a viable option (for us) in this scenario. Honestly, I'd prefer to just call it done already and have a VPN but due to certain restraints, we have to go down this route. /Ruairi On 10 November 2014 14:38, Alistair Mackenzie wrote: > Couldn't you put a router or VPN system on the single IP they are giving > you and use RFC1918 addressing space? > > OOB doesn't normally justify a /24 let alone a /23. > > On 10 November 2014 13:18, Ruairi Carroll > wrote: > >> Dear List, >> >> I've got an upcoming deployment in Equinix (DC10) and I'm struggling to >> find a provider who can give me a 100Mbit port (With a commit of about >> 5-10Mbit) with a /23 or /24 of public space , for OOB purposes. We had >> hoped to use Equinixs services, however they're limiting us to a single >> public IP. >> >> I'm also open to other solutions - xDSL or similar, but emphasis is on >> cheap and on-net. >> >> Cheers >> /Ruairi >> > > From contact at winterei.se Mon Nov 10 14:06:49 2014 From: contact at winterei.se (Paul S.) Date: Mon, 10 Nov 2014 23:06:49 +0900 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: References: Message-ID: <5460C679.5090005@winterei.se> I'd be doubtful if anyone will feel like offering a /23 with OOB as justification these days, sadly. Good luck nonetheless. On 11/10/2014 午後 11:00, Ruairi Carroll wrote: > Hey, > > VPN setup is not really a viable option (for us) in this scenario. > Honestly, I'd prefer to just call it done already and have a VPN but due to > certain restraints, we have to go down this route. > > /Ruairi > > On 10 November 2014 14:38, Alistair Mackenzie wrote: > >> Couldn't you put a router or VPN system on the single IP they are giving >> you and use RFC1918 addressing space? >> >> OOB doesn't normally justify a /24 let alone a /23. >> >> On 10 November 2014 13:18, Ruairi Carroll >> wrote: >> >>> Dear List, >>> >>> I've got an upcoming deployment in Equinix (DC10) and I'm struggling to >>> find a provider who can give me a 100Mbit port (With a commit of about >>> 5-10Mbit) with a /23 or /24 of public space , for OOB purposes. We had >>> hoped to use Equinixs services, however they're limiting us to a single >>> public IP. >>> >>> I'm also open to other solutions - xDSL or similar, but emphasis is on >>> cheap and on-net. >>> >>> Cheers >>> /Ruairi >>> >> From Patrick.Darden at p66.com Mon Nov 10 14:08:43 2014 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Mon, 10 Nov 2014 08:08:43 -0600 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> Message-ID: Misc thoughts... Legal I don't know your background, but I recommend you get with the EFF and/or SANS and get a good idea of possible legal ramifications, e.g. if you choose to be an internet provider vs. an internet services provider vs. a private network provider or a telecommunications service or some mixture. These choices can really change the legal (and business) landscape for you. Security If you have a CISSP or equivalent, then you probably know what you are doing from a security standpoint. If not, then I recommend you proceed with caution--maybe take an intensive general course: physical security, protecting your customers, providing extra security services (IPS, DDOS protection, etc.). Maintenance Throw some money in the pot for monthly emergencies. Road work. Backhoes. Fibre splicing. Bad pink boxen. Converters. FX modules. Extra switches for fast swap-outs. A fast car and a fast technician who is fast with duct tape and bubble gum. Network Diagnostics You'll be doing a lot of proving "it isn't me." Get a fast laptop with an outstanding NIC and make sure you are up to speed with Wireshark and presentations. If you aren't a wizard with Wireshark, then take the 4-12 hours it takes to become one: memorize the hot keys, figure out the advanced filtering, etc. NMAP and SOCAT as well--you'll want to be able to show that your voodoo works, and perhaps even point the finger towards the real problems. A Nice Suit Don't underestimate the power of a nice suit. It reassures your customers. And that'll be 50% of your job. It's all about professionalism until they get to know you. Your Audience If your audience is 90% gamers, you might consider putting together a gamer's NOC. Web page showing pings and lag for various games... traffic flows, bandwidth, switch utilization, the most popular servers, info. Maybe host some games on local servers. Put together a small VMWare Cloud just for that. If your audience is 90% online retail, maybe put in a Secure Zone, a DMZ they can host behind, maybe some Palo Alto firewalls that do WAP (web app protection) and SQL Protection and etc. Or just use an active IPS. Etc. Good luck! --p -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lorell Hathcock Sent: Sunday, November 09, 2014 8:18 PM To: nanog at nanog.org Subject: [EXTERNAL]I am about to inherit 26 miles of dark fiber. What do I do with it? All: A job opportunity just came my way to work with 26 miles of dark fiber in and around a city in Texas. The intent is for me to deliver internet and private network services to business customers in this area. I relish the thought of starting from scratch to build a network right from the start instead of inheriting and fixing someone else's mess. That being said, what suggestions does the group have for building a new network using existing dark fiber? MPLS backbone? Like all businesses these days, I will likely have to build the lit backbone as I add customers. So how would you recommend scaling the network? I have six strands of SMF that connect within municipal facilities. Each new customer will be a new build out from the nearest point. Because of having only six strands, I don't anticipate selling dark fiber. I believe I need to conserve fibers so that it would be lit services that I offer to customers. I would like to offer speeds up to 10 GB. Thoughts are appreciated! Sincerely, Lorell Hathcock From Patrick.Darden at p66.com Mon Nov 10 14:11:40 2014 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Mon, 10 Nov 2014 08:11:40 -0600 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: <260979806.424530.1415589946529.JavaMail.zimbra@snappytelecom.net> References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> <260979806.424530.1415589946529.JavaMail.zimbra@snappytelecom.net> Message-ID: +1 to what Faisal said. And before you take possession I recommend you do a thorough fibre test. Check for all aspects of the fibre--signal deterioration and etc. "Shoot the fibre" and map it out, it's strengths and weaknesses, so you know what you are dealing with. --Patrick Darden -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal Imtiaz Sent: Sunday, November 09, 2014 9:26 PM To: Lorell Hathcock Cc: nanog at nanog.org Subject: [EXTERNAL]Re: I am about to inherit 26 miles of dark fiber. What do I do with it? I would suggest that you do some rapid field deployment education in regards to fiber networks. You might consider joining WISPA and or FISPA (two industry associations), where you have folks building out fiber networks, who are very willing to share their experience and tell you what is working and what is not working. Working with Dark fiber can be as simple as you like, or as complicated as you want it to be. However this is one area that it is not un-common to make things appear a lot more expensive and complicated then what they have to be... Depending on what you are inheriting, and what you have to be responsible for, I would suggest that you spend some time on the web, local library, and some of the OSP related publications to get a good understanding of what is done and why....before just falling for industry jargon. I should be fun... :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Lorell Hathcock" > To: nanog at nanog.org > Sent: Sunday, November 9, 2014 9:18:15 PM > Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? > > All: > > A job opportunity just came my way to work with 26 miles of dark fiber > in and around a city in Texas. > > The intent is for me to deliver internet and private network services > to business customers in this area. > > I relish the thought of starting from scratch to build a network right > from the start instead of inheriting and fixing someone else's mess. > > That being said, what suggestions does the group have for building a > new network using existing dark fiber? > > MPLS backbone? Like all businesses these days, I will likely have to > build the lit backbone as I add customers. So how would you recommend > scaling the network? > > I have six strands of SMF that connect within municipal facilities. > Each new customer will be a new build out from the nearest point. > Because of having only six strands, I don't anticipate selling dark > fiber. I believe I need to conserve fibers so that it would be lit services that I offer to customers. > > I would like to offer speeds up to 10 GB. > > Thoughts are appreciated! > > Sincerely, > > Lorell Hathcock From jgreco at ns.sol.net Mon Nov 10 14:20:44 2014 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 10 Nov 2014 08:20:44 -0600 (CST) Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: Message-ID: <201411101420.sAAEKije071474@aurora.sol.net> > Hey, > > VPN setup is not really a viable option (for us) in this scenario. > Honestly, I'd prefer to just call it done already and have a VPN but due to > certain restraints, we have to go down this route. Without explaining the "restraints," this kinda boils down to "'cuz we want it," which stopped being good justification many years ago. I doubt you'll find many takers who would want to provide you with a circuit for a few Mbps with a /23 for OOB purposes "'just cuz." I note that we're present in Equinix Ashburn and could do it, and that this is basically a nonstarter for us. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jeroen at massar.ch Mon Nov 10 14:26:38 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 10 Nov 2014 15:26:38 +0100 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: <201411101420.sAAEKije071474@aurora.sol.net> References: <201411101420.sAAEKije071474@aurora.sol.net> Message-ID: <5460CB1E.4070202@massar.ch> On 2014-11-10 15:20, Joe Greco wrote: >> Hey, >> >> VPN setup is not really a viable option (for us) in this scenario. >> Honestly, I'd prefer to just call it done already and have a VPN but due to >> certain restraints, we have to go down this route. > > Without explaining the "restraints," this kinda boils down to "'cuz we > want it," which stopped being good justification many years ago. > > I doubt you'll find many takers who would want to provide you with a > circuit for a few Mbps with a /23 for OOB purposes "'just cuz." "just cuz" ack'ing packets for the spam we are sending will be possible then. Is likely what goes through most people's minds... Greets, Jeroen From rs at seastrom.com Mon Nov 10 14:35:46 2014 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 10 Nov 2014 09:35:46 -0500 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: <408485736.424491.1415589269215.JavaMail.zimbra@snappytelecom.net> (Faisal Imtiaz's message of "Mon, 10 Nov 2014 03:14:29 +0000 (GMT)") References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> <408485736.424491.1415589269215.JavaMail.zimbra@snappytelecom.net> Message-ID: <86ioint96l.fsf@valhalla.seastrom.com> While short and to the point, what Fletcher said is likely to be the best advice in this thread. Getting someone on staff who understands *both* outside plant architecture and balance sheets... and can co-develop a business model that involves the lateral build-out from the six POPs around town without going broke is the hard part. "Six POPs, six strands, MPLS backbone vs. selling waves" could be the concept for the opening lines to a sad country song where the protagonist doesn't realize that the long pole in the tent is the making the edge work (someone please run with this and get a musical lightning talk at San Antonio!) -r Faisal Imtiaz writes: > WoW !.. that was a rather cruel and un-called for ! > > How does that saying go.....Don't say anything, if you cannot say anything nice ! > > > > Faisal Imtiaz > Snappy Internet & Telecom > > ----- Original Message ----- >> From: "Fletcher Kittredge" >> To: "Lorell Hathcock" >> Cc: nanog at nanog.org >> Sent: Sunday, November 9, 2014 9:56:08 PM >> Subject: Re: I am about to inherit 26 miles of dark fiber. What do I do with it? >> >> The below is a really sad story. Condolences on the coming trainwreck. I >> hope you get someone on staff or on consult that understands outside plant >> architecture, because it is much more important and complex topic than you >> seem to realize. >> >> >> On Sun, Nov 9, 2014 at 9:18 PM, Lorell Hathcock wrote: >> >> > All: >> > >> > A job opportunity just came my way to work with 26 miles of dark fiber in >> > and around a city in Texas. >> > >> > The intent is for me to deliver internet and private network services to >> > business customers in this area. >> > >> > I relish the thought of starting from scratch to build a network right >> > from the start instead of inheriting and fixing someone else's mess. >> > >> > That being said, what suggestions does the group have for building a new >> > network using existing dark fiber? >> > >> > MPLS backbone? Like all businesses these days, I will likely have to >> > build the lit backbone as I add customers. So how would you recommend >> > scaling the network? >> > >> > I have six strands of SMF that connect within municipal facilities. Each >> > new customer will be a new build out from the nearest point. Because of >> > having only six strands, I don't anticipate selling dark fiber. I believe I >> > need to conserve fibers so that it would be lit services that I offer to >> > customers. >> > >> > I would like to offer speeds up to 10 GB. >> > >> > Thoughts are appreciated! >> > >> > Sincerely, >> > >> > Lorell Hathcock >> >> >> >> >> -- >> Fletcher Kittredge >> GWI >> 8 Pomerleau Street >> Biddeford, ME 04005-9457 >> 207-602-1134 >> From ruairi.carroll at gmail.com Mon Nov 10 14:39:46 2014 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Mon, 10 Nov 2014 15:39:46 +0100 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: <201411101420.sAAEKije071474@aurora.sol.net> References: <201411101420.sAAEKije071474@aurora.sol.net> Message-ID: On 10 November 2014 15:20, Joe Greco wrote: > > Hey, > > > > VPN setup is not really a viable option (for us) in this scenario. > > Honestly, I'd prefer to just call it done already and have a VPN but due > to > > certain restraints, we have to go down this route. > > Without explaining the "restraints," this kinda boils down to "'cuz we > want it," which stopped being good justification many years ago. > Well, I was hoping that I could get some good pointers about where to look to open up the sales discussion and what is possible for us (With some trickery, we could probably do under > I doubt you'll find many takers who would want to provide you with a > circuit for a few Mbps with a /23 for OOB purposes "'just cuz." > > I note that we're present in Equinix Ashburn and could do it, and that > this is basically a nonstarter for us. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] > then I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > From jeroen at massar.ch Mon Nov 10 14:40:54 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Mon, 10 Nov 2014 15:40:54 +0100 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: <86ioint96l.fsf@valhalla.seastrom.com> References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> <408485736.424491.1415589269215.JavaMail.zimbra@snappytelecom.net> <86ioint96l.fsf@valhalla.seastrom.com> Message-ID: <5460CE76.2070807@massar.ch> On 2014-11-10 15:35, Rob Seastrom wrote: > > While short and to the point, what Fletcher said is likely to be the > best advice in this thread. > > Getting someone on staff who understands *both* outside plant > architecture and balance sheets... and can co-develop a business > model that involves the lateral build-out from the six POPs around > town without going broke is the hard part. > > "Six POPs, six strands, MPLS backbone vs. selling waves" could be the > concept for the opening lines to a sad country song where the > protagonist doesn't realize that the long pole in the tent is the > making the edge work (someone please run with this and get a musical > lightning talk at San Antonio!) +1 on both the good advice and the proposal of the musical talk :) Greets, Jeroen From mstaudinger at elnk.com Mon Nov 10 14:56:37 2014 From: mstaudinger at elnk.com (Staudinger, Malcolm) Date: Mon, 10 Nov 2014 14:56:37 +0000 Subject: Contact @ harvard.edu? In-Reply-To: <46c492e99dcd484da72bc0d767a86c38@EDGMBXV05.marvel.elnk.net> References: <46c492e99dcd484da72bc0d767a86c38@EDGMBXV05.marvel.elnk.net> Message-ID: Thanks for all of the lines everyone dropped me, issue is resolved. Malcolm Staudinger Information Security Analyst II | EIS EarthLink E: mstaudinger at elnk.com M: 360-936-5957 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Staudinger, Malcolm Sent: Friday, November 07, 2014 3:50 PM To: NANOG Subject: Contact @ harvard.edu? If anyone from Harvard IT (preferably network/netsec, but I'll take anyone at this point) is on this list, please drop me a line regarding a DoS from your network. I haven't had any luck getting past your student help desk/ticket system. Malcolm Staudinger Information Security Analyst II | EIS EarthLink E: mstaudinger at elnk.com M: 360-936-5957 [http://www.earthlinkmarketingservices.com/email_logo_sm.png] From rbf+nanog at panix.com Mon Nov 10 15:38:09 2014 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Mon, 10 Nov 2014 09:38:09 -0600 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: <201411101420.sAAEKije071474@aurora.sol.net> References: <201411101420.sAAEKije071474@aurora.sol.net> Message-ID: <20141110153809.GA13685@panix.com> On Mon, Nov 10, 2014 at 08:20:44AM -0600, Joe Greco wrote: > > Hey, > > > > VPN setup is not really a viable option (for us) in this scenario. > > Honestly, I'd prefer to just call it done already and have a VPN but due to > > certain restraints, we have to go down this route. > > Without explaining the "restraints," this kinda boils down to "'cuz we > want it," which stopped being good justification many years ago. Not to ARIN, which isn't in the business of deciding what uses are valid and what uses are not valid (only that there is, in fact, use). With the recent reduction in minimum allocation sizes, he could get PI space for this directly from ARIN (depending on his previous allocations and efficient utilization thereof, of course). > I doubt you'll find many takers who would want to provide you with a > circuit for a few Mbps with a /23 for OOB purposes "'just cuz." > > I note that we're present in Equinix Ashburn and could do it, and that > this is basically a nonstarter for us. Not an unreasonable business decision. His challange will be finding a provider large enough that they can easily allocate a /23 but small enough that they're interested in a 10(ish) Mbps connection that isn't likely to grow much. -- Brett From fkittred at gwi.net Mon Nov 10 15:39:30 2014 From: fkittred at gwi.net (Fletcher Kittredge) Date: Mon, 10 Nov 2014 10:39:30 -0500 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> <260979806.424530.1415589946529.JavaMail.zimbra@snappytelecom.net> Message-ID: "Goodwill" != "nice". Goodwill is respect, honesty and a genuine concern for a positive outcome. "nice" is frequently concentrating more on avoiding conflict than on a good outcome. I care more than most about the outcome than most because I will share your failure. I will be sitting on some panel having to explain why the failure of your town's system isn't indicative of the failure of all municipal broadband, just as I now have to explain Provo, UT, Burlington, VT, Monticello, Minn; and Dunnellon and Quincy, Fla . Patrick Darden's comments on getting good legal advice and security design are great points. Municipal broadband is governed by federal, state and municipal laws. The last two vary widely... Fiber ownership, overlash rights, additional pole attachment. Stay in telecommunications space and out of electrical space if you can. Join the FTTH Council; it is very cheap for what you get. The resources available to members are extensive; concentrate on the public policy and business resources (disclaimer: I speak at their conferences on financing). www.muninetworks.org is another, though it comes with a perspective. Any technical advice from this forum is suspect because not enough has been shared about the goals of the project to make any technical choices. However, there are some general technical goals that all projects should examine, if only to discard them: 1) Expandability: We are in the early days of gigabit fiber networks and your network should last at least 20 years. Design in such a way that your network can grow significantly. Issues include fiber count, connection architecture, slack loops for many modifications. If you are building a "business only" network, think through how it would be expanded to all residential customers at a later date. By definition infrastructure is a shared resource and the more users the greater the value and the lower cost per user. Plan to share any infrastructure you design with everyone. 2) Flexibility: don't assume today's uses will be tomorrow's uses. Can you switch from passive to active if that is required later? You inherited a fiber plant that I bet you are going to find is insufficient to the task. Learn from that and don't pass on the same mess to later generations. 3) Open access, preferably dark fiber. Long discussion, but I think there is a compelling case that the best systems are usually open access dark fiber. See "flexibility" and "expandability" above and "network consolidation" below. 4) Plan for network consolidation. Every other network built in the past has gone through a network consolidation phase: telegraph, railroads, electrical, telephone, cable. The network economies of scale are so enormous that no single, small network can match them. Plan for that future and use a standard OSP design that matches the networks around you. On Mon, Nov 10, 2014 at 7:40 AM, Fletcher Kittredge wrote: > > Gah! > > Municipal fiber networks can be total failures or the best investment a > community can make. It all depends on the implementation. > > There are eight steps one needs to get right: 1) public policy goals, 2) > technical goals meet the public policy goals, 3) survey community > demographics and existing network assets, 4) build community consensus, 5) > select the right business plan and obtain funding, 6) technical design of > OSP and operating structure, 7) RFI/RFP, 8)select EPC vendors and > fanatically oversee construction. > > Steps 1-5 are the most important and the level of success will depend on > the quality of their implementation. If a half-assed job is done at any > step, the outcome will not be good. This discussion has been focused on > step 6: technical design. It is impossible to do a good technical design if > you don't understand the problem you are trying to solve. > > There are vast differences between different municipalities public policy > goals and business plans. It doesn't make sense to copy Chattanooga's > implementation because their situation is different than yours (you have an > existing fiber network, which is always a warning sign. They are serving > all residents and businesses and you imply you are focused on businesses.) > > Focus on developing a deep understanding of what problem the city leaders > are trying to solve, then figure out how to hire a competent OSP design > person and make them do a good job. This is a hard task in and of itself. > > The failure of one municipal broadband system reflects badly on all > municipal broadband systems. Good luck. > > > > On Sun, Nov 9, 2014 at 11:22 PM, ITechGeek wrote: > >> I would say the OP is starting out right by reaching out to people who can >> give advice and point him in the right direction. I would say the first >> place to start would be budget. >> >> I don't think calling this is a trainwreck before it even leaves paper >> isn't very helpful. >> >> One option might be to start in phases, if his POPs can provide decent >> coverage, maybe start out w/ a wireless solution to start getting >> customers >> on the system and start getting revenue coming in (or if this is a >> city/town backed venture, get voters to see how useful this can be to >> maybe >> get more budget for future rollout). >> >> Also talk to business customers to see if you extend fiber to them, what >> kind of services will they want. If you can get large customers to say >> "Yes, I will or would like to purchase a gig of bandwidth between two >> office or a gig of Internet access", that should help w/ either city or >> private finance backing to show there will be demand. >> >> You might even be able to get help from some companies (If you contact >> corporate or gov't sales for Cisco/Nortel/etc., they can probably have >> some >> techs bring in some equipment for small scale shows). >> >> If this is a city trying to do this, reach out to places like Chattanooga, >> TN or Lafayette, LA or any number of other cities (mostly in foreign >> countries) that have successfully done this. >> http://en.wikipedia.org/wiki/LUSFiber >> http://en.wikipedia.org/wiki/EPB >> >> On a final note, the Stockholm model I've always thought was the best idea >> (even before I heard Stockholm invested in it) - Stockholm owns the >> infrastructure and private companies provide the actual customer services >> across the city owned infrastructure (let true competition happen instead >> of the monopoly and duopoly in most cities and if it doesn't work out, you >> can always start selling services later if true competition doesn't work). >> >> http://cis471.blogspot.com/2009/04/why-is-connectivty-in-stockholm-so-much.html >> (This was the most up to date page I could find in English doing a >> comparison). >> >> >> >> ----------------------------------------------------------------------------------------------- >> -ITG (ITechGeek) >> ITG at ITechGeek.Com >> https://itg.nu/ >> GPG Keys: https://itg.nu/contact/gpg-key >> Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A >> Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: >> http://fb.me/Jbwa.Net >> >> On Sun, Nov 9, 2014 at 10:25 PM, Faisal Imtiaz >> wrote: >> >> > I would suggest that you do some rapid field deployment education in >> > regards to fiber networks. >> > >> > You might consider joining WISPA and or FISPA (two industry >> > associations), where you have folks building out fiber networks, who are >> > very willing to share their experience and tell you what is working and >> > what is not working. >> > >> > Working with Dark fiber can be as simple as you like, or as complicated >> as >> > you want it to be. However this is one area that it is not un-common to >> > make things appear a lot more expensive and complicated then what they >> have >> > to be... >> > >> > Depending on what you are inheriting, and what you have to be >> responsible >> > for, I would suggest that you spend some time on the web, local library, >> > and some of the OSP related publications to get a good understanding of >> > what is done and why....before just falling for industry jargon. >> > >> > I should be fun... :) >> > >> > Faisal Imtiaz >> > Snappy Internet & Telecom >> > >> > >> > ----- Original Message ----- >> > > From: "Lorell Hathcock" >> > > To: nanog at nanog.org >> > > Sent: Sunday, November 9, 2014 9:18:15 PM >> > > Subject: I am about to inherit 26 miles of dark fiber. What do I do >> with >> > it? >> > > >> > > All: >> > > >> > > A job opportunity just came my way to work with 26 miles of dark fiber >> > in and >> > > around a city in Texas. >> > > >> > > The intent is for me to deliver internet and private network services >> to >> > > business customers in this area. >> > > >> > > I relish the thought of starting from scratch to build a network right >> > from >> > > the start instead of inheriting and fixing someone else's mess. >> > > >> > > That being said, what suggestions does the group have for building a >> new >> > > network using existing dark fiber? >> > > >> > > MPLS backbone? Like all businesses these days, I will likely have to >> > build >> > > the lit backbone as I add customers. So how would you recommend >> scaling >> > the >> > > network? >> > > >> > > I have six strands of SMF that connect within municipal facilities. >> Each >> > new >> > > customer will be a new build out from the nearest point. Because of >> > having >> > > only six strands, I don't anticipate selling dark fiber. I believe I >> > need to >> > > conserve fibers so that it would be lit services that I offer to >> > customers. >> > > >> > > I would like to offer speeds up to 10 GB. >> > > >> > > Thoughts are appreciated! >> > > >> > > Sincerely, >> > > >> > > Lorell Hathcock >> > >> > > > > -- > Fletcher Kittredge > GWI > 8 Pomerleau Street > Biddeford, ME 04005-9457 > 207-602-1134 > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From lists at netrogenic.com Mon Nov 10 16:57:10 2014 From: lists at netrogenic.com (Jay Ess) Date: Mon, 10 Nov 2014 17:57:10 +0100 Subject: Problem reaching AS794 (Oracle) Through Level3 (Stockholm / Sweden). Message-ID: <5460EE66.2060902@netrogenic.com> I have had problems reaching www.mysql.com (AS794 Oracle) from AS39651 (Comhem Stockholm Sweden) for about a week now. Looking glass from Level3 and Telia shows me error as well. Can give login to a linux shell for troubleshooting. Traceroute : Host Loss% Snt Last Avg Best Wrst StDev 1. om-doc-1-bu30.comhem.se 0.0% 16 6.5 9.7 6.5 19.5 4.0 2. 213.200.164.203 0.0% 16 8.1 9.9 7.1 17.7 3.2 3. 213.200.163.81 0.0% 16 9.0 10.1 7.3 18.3 2.8 4. s-b5-link.telia.net 0.0% 16 9.1 11.7 7.9 20.5 4.9 5. s-bb4-link.telia.net 0.0% 16 9.0 12.8 8.2 30.3 6.2 6. s-b6-link.telia.net 0.0% 16 8.9 12.5 8.2 23.4 4.8 7. level3-ic-155475-s-b2.c.telia.net 25.0% 16 9.3 8.6 7.4 9.6 0.8 8. ae-4-90.edge5.Dallas3.Level3.net 12.5% 16 159.6 164.1 157.1 210.7 13.9 9. ae-4-90.edge5.Dallas3.Level3.net 12.5% 16 158.7 163.9 157.5 181.7 7.6 10. ??? From jeffshultz at sctcweb.com Mon Nov 10 19:37:37 2014 From: jeffshultz at sctcweb.com (Jeff Shultz) Date: Mon, 10 Nov 2014 11:37:37 -0800 Subject: Cisco CCNA Training In-Reply-To: <54600912.70802@gmail.com> References: <54600912.70802@gmail.com> Message-ID: <54611401.8010703@sctcweb.com> Let me second those thanks.... On 11/9/2014 4:38 PM, scottie mac wrote: > Holy molly, thankyou!! I just enrolled. > > > On 08/11/14 23:00, nanog-request at nanog.org wrote: >> From: "Wakefield, Thad M." To: >> "nanog at nanog.org" Subject: RE: Cisco CCNA Training >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" Until midnight Monday this >> course is on sale for $24: >> https://www.udemy.com/collection/thankyou-400-24deal >>> >-----Original Message----- >>> >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of scottie mac >>> >Sent: Tuesday, November 04, 2014 6:02 PM >>> >To:nanog at nanog.org >>> >Subject: Re: Cisco CCNA Training >>> > >>> >This course has 25 hours of video, I haven't started it yet but I've >>> watched >>> >many of Laz's videos on Youtube, and he explains stuff very well. >>> >It is $399 though. >>> >They could share the Udemy account, and watch them in their free time. >>> >*I'm not affiliated with Udemy* >>> > >>> >https://www.udemy.com/the-complete-ccna-200-120-course > -- Jeff Shultz From max.clark at gmail.com Mon Nov 10 20:39:02 2014 From: max.clark at gmail.com (Max Clark) Date: Mon, 10 Nov 2014 12:39:02 -0800 Subject: Tech Laptop with DB9 Message-ID: Hi all, DB9 ports seem to be a nearly extinct feature on laptops. Any suggestions on a cheap laptop for use in field support (with an onboard DB9)? Thanks, Max From Patrick.Darden at p66.com Mon Nov 10 20:53:59 2014 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Mon, 10 Nov 2014 14:53:59 -0600 Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: Get a cheap usb--serial converter. Check amazon for trend usb rs-232 db9 serial converter, tu-s9. Then you can just use whatever laptop. --p -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Clark Sent: Monday, November 10, 2014 2:39 PM To: nanog at nanog.org Subject: [EXTERNAL]Tech Laptop with DB9 Hi all, DB9 ports seem to be a nearly extinct feature on laptops. Any suggestions on a cheap laptop for use in field support (with an onboard DB9)? Thanks, Max From kate at quadranet.com Mon Nov 10 20:54:49 2014 From: kate at quadranet.com (Kate Gerry) Date: Mon, 10 Nov 2014 12:54:49 -0800 Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: <4B4120B1642DCF48ACA84E4F82C8E1F601A7E827BC6E@EXCH> If you are able to carry a USB cable I've actually found that these work PERFECTLY: http://www.amazon.com/dp/B004ETETZK I've never had an issue, I currently have an OOB console server set up with the 4 head version of this and haven't had an issue. They're rock solid. -- Kate      -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Clark Sent: Monday, November 10, 2014 12:39 PM To: nanog at nanog.org Subject: Tech Laptop with DB9 Hi all, DB9 ports seem to be a nearly extinct feature on laptops. Any suggestions on a cheap laptop for use in field support (with an onboard DB9)? Thanks, Max From streiner at cluebyfour.org Mon Nov 10 20:55:22 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 10 Nov 2014 15:55:22 -0500 (EST) Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: On Mon, 10 Nov 2014, Max Clark wrote: > DB9 ports seem to be a nearly extinct feature on laptops. Any suggestions on > a cheap laptop for use in field support (with an onboard DB9)? You might be able to pick up something like an old Dell Latitute D800 series pretty cheaply. Built-in RS232 serial ports are very tough to find on current laptops, however USB serial drivers have come a long way in the last several years, depending on your OS. jms From job at instituut.net Mon Nov 10 20:55:38 2014 From: job at instituut.net (Job Snijders) Date: Mon, 10 Nov 2014 21:55:38 +0100 Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: <20141110205538.GL1631@Vurt.local> On Mon, Nov 10, 2014 at 12:39:02PM -0800, Max Clark wrote: > DB9 ports seem to be a nearly extinct feature on laptops. Any > suggestions on a cheap laptop for use in field support (with an > onboard DB9)? Might be easier to get an "Aten UC232A" converter to do USB<>DB9, you are right that DB9 directly on laptops is a dying breed. Do you have a specific application that would prohibit the use of USB? Kind regards, Job From max.clark at gmail.com Mon Nov 10 20:57:49 2014 From: max.clark at gmail.com (Max Clark) Date: Mon, 10 Nov 2014 12:57:49 -0800 Subject: Tech Laptop with DB9 In-Reply-To: <20141110205538.GL1631@Vurt.local> References: <20141110205538.GL1631@Vurt.local> Message-ID: On Mon, Nov 10, 2014 at 12:55 PM, Job Snijders wrote: > Do you have a specific application that would prohibit the use of USB? > It's purely for convenience and forgetfulness. From eugen at imacandi.net Mon Nov 10 20:59:32 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Mon, 10 Nov 2014 22:59:32 +0200 Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: On Mon, Nov 10, 2014 at 10:39 PM, Max Clark wrote: > Hi all, > > DB9 ports seem to be a nearly extinct feature on laptops. Any suggestions > on a cheap laptop for use in field support (with an onboard DB9)? > You can look at older Dell Latitudes such as D620 or any Prolific based USB-to-Serial adapter (If running those on Windows, you can set the driver so that it will report the same COM port even if it's plugged in different USB ports). From joelja at bogus.com Mon Nov 10 21:05:39 2014 From: joelja at bogus.com (joel jaeggli) Date: Mon, 10 Nov 2014 11:05:39 -1000 Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: <546128A3.6050908@bogus.com> ftdi chipsets work on both mac and windows devices. http://www.amazon.com/Serial-Console-Rollover-Cable-Routers/dp/B00M2SAKMG/ref=sr_1_16?s=electronics&ie=UTF8&qid=1415653377&sr=1-16&keywords=ftdi+serial On 11/10/14 10:39 AM, Max Clark wrote: > Hi all, > > DB9 ports seem to be a nearly extinct feature on laptops. Any > suggestions on a cheap laptop for use in field support (with an onboard > DB9)? > > Thanks, > Max > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From srn.nanog at prgmr.com Mon Nov 10 21:07:17 2014 From: srn.nanog at prgmr.com (srn.nanog at prgmr.com) Date: Mon, 10 Nov 2014 13:07:17 -0800 Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: <54612905.5070809@prgmr.com> If USB is banned, ask about expansion cards. The HP 650 G1 has a serial port, but it's not cheap. On 11/10/2014 12:39 PM, Max Clark wrote: > Hi all, > > DB9 ports seem to be a nearly extinct feature on laptops. Any suggestions on a cheap laptop for use > in field support (with an onboard DB9)? > > Thanks, > Max > > From alexander at neilson.net.nz Mon Nov 10 21:11:56 2014 From: alexander at neilson.net.nz (Alexander Neilson) Date: Tue, 11 Nov 2014 10:11:56 +1300 Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: <827EAAF0-3B70-451E-90EE-037839B7FF1C@neilson.net.nz> I have found Air Console to be amazing: http://www.get-console.com/airconsole/ I have one that comes with me in my bag everywhere. I also have purchased a couple of their 1.8M USB to Cisco Rollover Cables which include the USB to Serial converter in the USB Plug. The cable can be adapted to serial and null modem with the end adapters (may not work in every situation) The FDDI chip in these cables has strong driver availability across all OS’s and is also installed by default in some OS’s (including OS X - my personal preference for direct interaction machine) This way as long as you have USB ports and Wifi you have an awesome tool set. The Air Console can even bridge traffic for monitoring / wireshark over Wifi (obvious bandwidth limitations) so I really enjoy having it with me. Regards Alexander Alexander Neilson Neilson Productions Limited alexander at neilson.net.nz 021 329 681 022 456 2326 > On 11/11/2014, at 9:39 am, Max Clark wrote: > > Hi all, > > DB9 ports seem to be a nearly extinct feature on laptops. Any suggestions on a cheap laptop for use in field support (with an onboard DB9)? > > Thanks, > Max > > From amekkaoui at mektel.ca Mon Nov 10 21:33:45 2014 From: amekkaoui at mektel.ca (A Mekkaoui) Date: Mon, 10 Nov 2014 16:33:45 -0500 Subject: Hosted IP telephony Message-ID: <00a301cffd2e$03e00650$0ba012f0$@ca> Hi, We are an Internet and IP telephony provider in Canada and looking for options to reduce our costs. We are exploring hosted IP telephony option to see how it can help us reducing cost and operational headaches. We have few hundred of phone adapters to register and this number increases from day to day. If you provide this type of solutions or know providers of this type of solutions please contact me. Your help will be appreciated. Thank you Karim From alvarezp at alvarezp.ods.org Mon Nov 10 21:34:09 2014 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Mon, 10 Nov 2014 13:34:09 -0800 Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: <54612F51.1060507@alvarezp.ods.org> On 10/11/14 12:53, Darden, Patrick wrote: > Get a cheap usb--serial converter. Check amazon for trend usb rs-232 > db9 serial converter, tu-s9. Then you can just use whatever laptop. I've seen some cheap RS-232 converters fail with some devices. I was last bitten by one that just refused to work with Cisco Aironet APs 2600. I can't say if it was the device or the driver. I never knew what the problem ultimately was. Using a different model or brand worked. Just to have the precaution. O. From r.engehausen at gmail.com Mon Nov 10 21:35:33 2014 From: r.engehausen at gmail.com (Roy) Date: Mon, 10 Nov 2014 13:35:33 -0800 Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: <54612FA5.6060107@gmail.com> I had a cheap one. Worked great but never worked on Windows 7 This is the one I recommend. http://www.amazon.com/Manhattan-Serial-Converter-Connects-205146/dp/B0007OWNYA On 11/10/2014 12:53 PM, Darden, Patrick wrote: > Get a cheap usb--serial converter. Check amazon for trend usb rs-232 db9 serial converter, tu-s9. Then you can just use whatever laptop. > > --p > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Max Clark > Sent: Monday, November 10, 2014 2:39 PM > To: nanog at nanog.org > Subject: [EXTERNAL]Tech Laptop with DB9 > > Hi all, > > DB9 ports seem to be a nearly extinct feature on laptops. Any suggestions on a cheap laptop for use in field support (with an onboard DB9)? > > Thanks, > Max > > > From lists.nanog at monmotha.net Mon Nov 10 21:45:32 2014 From: lists.nanog at monmotha.net (Brandon Martin) Date: Mon, 10 Nov 2014 16:45:32 -0500 Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: <546131FC.8050203@monmotha.net> On 11/10/2014 03:59 PM, Eugeniu Patrascu wrote: > Prolific based USB-to-Serial adapter Anecodotally, I recommend against Prolific-based solutions. While doing some embedded dev work, I quite unintentionally found a specific data pattern that would reliably get corrupted by the Prolific cable I had. After several hours of debugging my software, finally resorting to a 'scope to verify that the data on the line was correct, I chucked it in the trash after I found that it worked fine with my 1st-party FTDI cable. Probably should have kept it and tried to isolate a minimal test case, but meh. 1st party FTDI cables can be had with bare wire ends on them. With a little effort, you can crimp an 8P8C directly on and have yourself a Cisco-style cable that's very reliable and includes traffic indicator lights in the USB molded housing. I think you can also get them pre-wired to DE9 connectors. They've got RS-485 and RS-422 options, too. I buy them from Digi-Key - not the cheapest place by any means, but you know for sure that they're real. I've had good luck with FTDI on all OSes. No drivers needed on (modern) Linux, and the drivers are easy to work with on all versions of Windows that I've used with them (XP, 7). Dunno about MacOSX, but I think there's at least options. YMMV, of course. FTDI got in some hot water recently by intentionally bricking 3rd party clones of their stuff in a Windows driver update. -- Brandon Martin From jschiel at flowtools.net Mon Nov 10 22:30:37 2014 From: jschiel at flowtools.net (John Schiel) Date: Mon, 10 Nov 2014 15:30:37 -0700 Subject: Tech Laptop with DB9 In-Reply-To: <546128A3.6050908@bogus.com> References: <546128A3.6050908@bogus.com> Message-ID: <54613C8D.7010806@flowtools.net> On 11/10/2014 02:05 PM, joel jaeggli wrote: > ftdi chipsets work on both mac and windows devices. I'd be careful with FTDI chipsets, you want to make sure you get the real chip. If they decide to move forward with bricking counterfeit chips, you'll be wasting your $$. --John > > http://www.amazon.com/Serial-Console-Rollover-Cable-Routers/dp/B00M2SAKMG/ref=sr_1_16?s=electronics&ie=UTF8&qid=1415653377&sr=1-16&keywords=ftdi+serial > > On 11/10/14 10:39 AM, Max Clark wrote: >> Hi all, >> >> DB9 ports seem to be a nearly extinct feature on laptops. Any >> suggestions on a cheap laptop for use in field support (with an onboard >> DB9)? >> >> Thanks, >> Max >> >> > From baconzombie at gmail.com Mon Nov 10 22:43:34 2014 From: baconzombie at gmail.com (Bacon Zombie) Date: Mon, 10 Nov 2014 22:43:34 +0000 Subject: Tech Laptop with DB9 In-Reply-To: <54613C8D.7010806@flowtools.net> References: <546128A3.6050908@bogus.com> <54613C8D.7010806@flowtools.net> Message-ID: You mean like they did with the last driver update pushed via Windows Update? http://hackaday.com/2014/10/22/watch-that-windows-update-ftdi-drivers-are-killing-fake-chips/ On 10 Nov 2014 23:32, "John Schiel" wrote: > > On 11/10/2014 02:05 PM, joel jaeggli wrote: > >> ftdi chipsets work on both mac and windows devices. >> > > I'd be careful with FTDI chipsets, you want to make sure you get the real > chip. If they decide to move forward with bricking counterfeit chips, > you'll be wasting your $$. > > > --John > > >> http://www.amazon.com/Serial-Console-Rollover-Cable- >> Routers/dp/B00M2SAKMG/ref=sr_1_16?s=electronics&ie=UTF8& >> qid=1415653377&sr=1-16&keywords=ftdi+serial >> >> On 11/10/14 10:39 AM, Max Clark wrote: >> >>> Hi all, >>> >>> DB9 ports seem to be a nearly extinct feature on laptops. Any >>> suggestions on a cheap laptop for use in field support (with an onboard >>> DB9)? >>> >>> Thanks, >>> Max >>> >>> >>> >> > From morrowc.lists at gmail.com Mon Nov 10 23:00:54 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 10 Nov 2014 18:00:54 -0500 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: <5460C679.5090005@winterei.se> References: <5460C679.5090005@winterei.se> Message-ID: On Mon, Nov 10, 2014 at 9:06 AM, Paul S. wrote: > I'd be doubtful if anyone will feel like offering a /23 with OOB as > justification these days, sadly. why thought? Justification is really about having a use for the ips, right? and if you have 500 servers/network-devices ... then you have justification for a /23 ... it seems to me. > > Good luck nonetheless. > > > On 11/10/2014 午後 11:00, Ruairi Carroll wrote: >> >> Hey, >> >> VPN setup is not really a viable option (for us) in this scenario. >> Honestly, I'd prefer to just call it done already and have a VPN but due >> to >> certain restraints, we have to go down this route. >> >> /Ruairi >> >> On 10 November 2014 14:38, Alistair Mackenzie wrote: >> >>> Couldn't you put a router or VPN system on the single IP they are giving >>> you and use RFC1918 addressing space? >>> >>> OOB doesn't normally justify a /24 let alone a /23. >>> >>> On 10 November 2014 13:18, Ruairi Carroll >>> wrote: >>> >>>> Dear List, >>>> >>>> I've got an upcoming deployment in Equinix (DC10) and I'm struggling to >>>> find a provider who can give me a 100Mbit port (With a commit of about >>>> 5-10Mbit) with a /23 or /24 of public space , for OOB purposes. We had >>>> hoped to use Equinixs services, however they're limiting us to a single >>>> public IP. >>>> >>>> I'm also open to other solutions - xDSL or similar, but emphasis is on >>>> cheap and on-net. >>>> >>>> Cheers >>>> /Ruairi >>>> >>> > From kate at quadranet.com Mon Nov 10 23:15:38 2014 From: kate at quadranet.com (Kate Gerry) Date: Mon, 10 Nov 2014 15:15:38 -0800 Subject: Tech Laptop with DB9 In-Reply-To: References: <546128A3.6050908@bogus.com> <54613C8D.7010806@flowtools.net> Message-ID: <4B4120B1642DCF48ACA84E4F82C8E1F601A7E827BC7E@EXCH> The bonus about the adapter that I linked is that they use legit chips. I went through the FTDI driver update without a problem.      -----Original Message----- From: NANOG [mailto:nanog-bounces+kate=quadranet.com at nanog.org] On Behalf Of Bacon Zombie Sent: Monday, November 10, 2014 2:44 PM To: John Schiel Cc: nanog at nanog.org Subject: Re: Tech Laptop with DB9 You mean like they did with the last driver update pushed via Windows Update? http://hackaday.com/2014/10/22/watch-that-windows-update-ftdi-drivers-are-killing-fake-chips/ On 10 Nov 2014 23:32, "John Schiel" wrote: > > On 11/10/2014 02:05 PM, joel jaeggli wrote: > >> ftdi chipsets work on both mac and windows devices. >> > > I'd be careful with FTDI chipsets, you want to make sure you get the > real chip. If they decide to move forward with bricking counterfeit > chips, you'll be wasting your $$. > > > --John > > >> http://www.amazon.com/Serial-Console-Rollover-Cable- >> Routers/dp/B00M2SAKMG/ref=sr_1_16?s=electronics&ie=UTF8& >> qid=1415653377&sr=1-16&keywords=ftdi+serial >> >> On 11/10/14 10:39 AM, Max Clark wrote: >> >>> Hi all, >>> >>> DB9 ports seem to be a nearly extinct feature on laptops. Any >>> suggestions on a cheap laptop for use in field support (with an >>> onboard DB9)? >>> >>> Thanks, >>> Max >>> >>> >>> >> > From mpalmer at hezmatt.org Mon Nov 10 23:22:39 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Tue, 11 Nov 2014 10:22:39 +1100 Subject: Tech Laptop with DB9 In-Reply-To: <546128A3.6050908@bogus.com> References: <546128A3.6050908@bogus.com> Message-ID: <20141110232239.GS3175@hezmatt.org> On Mon, Nov 10, 2014 at 11:05:39AM -1000, joel jaeggli wrote: > ftdi chipsets work on both mac and windows devices. As long as it's FTDI and not "FTDI"... - Matt -- "Once one has achieved full endarkenment, one is happy to have an entirely nonfunctional computer" -- Steve VanDevender, ASR From mpalmer at hezmatt.org Mon Nov 10 23:23:40 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Tue, 11 Nov 2014 10:23:40 +1100 Subject: Tech Laptop with DB9 In-Reply-To: References: <20141110205538.GL1631@Vurt.local> Message-ID: <20141110232340.GT3175@hezmatt.org> On Mon, Nov 10, 2014 at 12:57:49PM -0800, Max Clark wrote: > On Mon, Nov 10, 2014 at 12:55 PM, Job Snijders wrote: > > Do you have a specific application that would prohibit the use of USB? > > It's purely for convenience and forgetfulness. Cable ties. They're my forget-me-not. - Matt -- "Alas, slideware often reduces the analytical quality of presentations. In particular, the popular PowerPoint templates (ready-made designs) usually weaken verbal and spatial reasoning, and almost always corrupt statistical analysis." -- http://www.edwardtufte.com/tufte/books_pp From codygrosskopf at gmail.com Mon Nov 10 23:29:45 2014 From: codygrosskopf at gmail.com (Cody Grosskopf) Date: Mon, 10 Nov 2014 15:29:45 -0800 Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: I have a box of the db9 to USB converters from monoprice, cheap as dirt and work great with the prolific and open source version as well. Cody On Nov 10, 2014 12:52 PM, "Max Clark" wrote: > Hi all, > > DB9 ports seem to be a nearly extinct feature on laptops. Any suggestions > on a cheap laptop for use in field support (with an onboard DB9)? > > Thanks, > Max > > > From mpalmer at hezmatt.org Mon Nov 10 23:32:48 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Tue, 11 Nov 2014 10:32:48 +1100 Subject: Tech Laptop with DB9 In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F601A7E827BC7E@EXCH> References: <546128A3.6050908@bogus.com> <54613C8D.7010806@flowtools.net> <4B4120B1642DCF48ACA84E4F82C8E1F601A7E827BC7E@EXCH> Message-ID: <20141110233248.GV3175@hezmatt.org> On Mon, Nov 10, 2014 at 03:15:38PM -0800, Kate Gerry wrote: > The bonus about the adapter that I linked is that they use legit chips. If only supply chain security were that easy. - Matt From jbfixurpc at gmail.com Mon Nov 10 23:34:47 2014 From: jbfixurpc at gmail.com (Joe) Date: Mon, 10 Nov 2014 17:34:47 -0600 Subject: Kind of sad Message-ID: Kind of sad that the state govs don't curtail telnet,,, [root at bighughness ~]# telnet 167.240.254.155 623 Trying 167.240.254.155... Connected to external-dns1.state.mi.us (167.240.254.155). Escape character is '^]'. Username:root Password: From michael at supermathie.net Mon Nov 10 23:41:47 2014 From: michael at supermathie.net (Michael Brown) Date: Mon, 10 Nov 2014 18:41:47 -0500 Subject: Tech Laptop with DB9 In-Reply-To: <546128A3.6050908@bogus.com> References: <546128A3.6050908@bogus.com> Message-ID: <20141110234147.22921363.62386.16333@supermathie.net> Also worth mentioning: in a pinch they work great on Android and BlackBerry (Z30) devices with USB OTG support. >From memory I believe both pl2303 and FTDI work. Another laptop option is an ExpressCard to serial adapter: ‎http://www.brainboxes.com/serial-expresscard Disclaimer: this was merely the first Google result. ‎M.   Original Message   From: joel jaeggli Sent: Monday, November 10, 2014 16:19 To: Max Clark; nanog at nanog.org Subject: Re: Tech Laptop with DB9 ftdi chipsets work on both mac and windows devices. http://www.amazon.com/Serial-Console-Rollover-Cable-Routers/dp/B00M2SAKMG/ref=sr_1_16?s=electronics&ie=UTF8&qid=1415653377&sr=1-16&keywords=ftdi+serial On 11/10/14 10:39 AM, Max Clark wrote: > Hi all, > > DB9 ports seem to be a nearly extinct feature on laptops. Any > suggestions on a cheap laptop for use in field support (with an onboard > DB9)? > > Thanks, > Max > > From marine64 at gmail.com Mon Nov 10 23:48:08 2014 From: marine64 at gmail.com (Brian Henson) Date: Mon, 10 Nov 2014 18:48:08 -0500 Subject: Kind of sad In-Reply-To: References: Message-ID: Generally speaking its a bad idea to show you hacking into a server. Makes it to easy to prosecute those who do. From Nichole.K.Boscia at nasa.gov Mon Nov 10 21:11:03 2014 From: Nichole.K.Boscia at nasa.gov (Nichole K. Boscia) Date: Mon, 10 Nov 2014 13:11:03 -0800 (PST) Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: We recently bought some HP 6570b laptops. They come standard with a DB9 in the back. On Mon, 10 Nov 2014, Max Clark wrote: > Date: Mon, 10 Nov 2014 12:39:02 -0800 > From: Max Clark > To: nanog at nanog.org > Subject: Tech Laptop with DB9 > > Hi all, > > DB9 ports seem to be a nearly extinct feature on laptops. Any suggestions on > a cheap laptop for use in field support (with an onboard DB9)? > > Thanks, > Max > > From matt at spectrum.com.au Mon Nov 10 21:32:56 2014 From: matt at spectrum.com.au (Matt Perkins) Date: Tue, 11 Nov 2014 08:32:56 +1100 Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: <54612F08.5010400@spectrum.com.au> You can pick up an old toughbook on eBay that have serial ports for reasonable prices. Put in flash disk and run linux for a reasonable experience. But for the height of convenience you cant go past an Air Console. http://www.get-console.com/airconsole/ Nothing beats being able to plug it in deep inside a rack and then walk back to a comfortable seat to work. Beats the cold data center floor any day! Matt /* Matt Perkins Direct 1300 137 379 Spectrum Networks Ptd. Ltd. Office 1300 133 299 matt at spectrum.com.au Fax 1300 133 255 Level 6, 350 George Street Sydney 2000 SIP 1300137379 at sip.spectrum.com.au ABN 66 090 112 913 PGP/GNUPG Public Key can be found at http://pgp.mit.edu */ On 11/11/2014 7:39 am, Max Clark wrote: > Hi all, > > DB9 ports seem to be a nearly extinct feature on laptops. Any > suggestions on a cheap laptop for use in field support (with an > onboard DB9)? > > Thanks, > Max > From lobna_gouda at hotmail.com Mon Nov 10 21:49:08 2014 From: lobna_gouda at hotmail.com (lobna gouda) Date: Mon, 10 Nov 2014 21:49:08 +0000 Subject: cheap laptop with 32G or 64G recommendations Message-ID: Hello, Any recommendation, not looking for anything fantasy, my understanding it should be quardcore, with more than DIMM0 slot so each can have 8G. wind7-64bits to work. I want to use it as a server or practice logical routers From eyeronic.design at gmail.com Mon Nov 10 23:58:37 2014 From: eyeronic.design at gmail.com (Mike Hale) Date: Mon, 10 Nov 2014 15:58:37 -0800 Subject: Kind of sad In-Reply-To: References: Message-ID: That's a far, far cry from hacking... On Mon, Nov 10, 2014 at 3:48 PM, Brian Henson wrote: > Generally speaking its a bad idea to show you hacking into a server. Makes > it to easy to prosecute those who do. -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From izaac at setec.org Tue Nov 11 00:24:46 2014 From: izaac at setec.org (Izaac) Date: Mon, 10 Nov 2014 19:24:46 -0500 Subject: cheap laptop with 32G or 64G recommendations In-Reply-To: References: Message-ID: On November 10, 2014 4:49:08 PM EST, lobna gouda wrote: >Hello, >Any recommendation, not looking for anything fantasy, my understanding >it should be quardcore, with more than DIMM0 slot so each can have 8G. >wind7-64bits to work. I want to use it as a server or practice logical >routers "Cheap" and "64GiB of RAM" are incompatible concepts in laptops. There is no earthly reason you should need to carry a machine like that anyway. If for some reason you need something so equipped, get yourself a cloud instance and connect to it. That's how you save money. If you're stuck working in a completely isolated environment, then work it into the contract. That's the cost of being on an island. -- Izaac From drohan at gmail.com Tue Nov 11 00:26:41 2014 From: drohan at gmail.com (Daniel Rohan) Date: Mon, 10 Nov 2014 16:26:41 -0800 Subject: 10Gb iPerf kit? Message-ID: We're looking for a semi-portable solution to validate 10Gb customer circuits and hitting walls surrounding PCI lanes and the amount of data laptops can push via their busses. We'd prefer to not have techs lugging around server equipment for these tests. Anyone out there testing 10gbE with iPerf? If so, what are you using? Thanks, Dan From rcarpen at network1.net Tue Nov 11 00:35:19 2014 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 10 Nov 2014 19:35:19 -0500 (EST) Subject: 10Gb iPerf kit? In-Reply-To: <960646944.74409.1415666050031.JavaMail.zimbra@network1.net> References: Message-ID: <1473327677.74410.1415666119022.JavaMail.zimbra@network1.net> I have not tried doing that myself, but the only thing that would even be possible that I know of is thunderbolt. A new MacBook Pro and one of these maybe: http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html -Randy ----- On Nov 10, 2014, at 7:26 PM, Daniel Rohan drohan at gmail.com wrote: > We're looking for a semi-portable solution to validate 10Gb customer > circuits and hitting walls surrounding PCI lanes and the amount of data > laptops can push via their busses. We'd prefer to not have techs lugging > around server equipment for these tests. > > Anyone out there testing 10gbE with iPerf? If so, what are you using? > > Thanks, > > > Dan From morrowc.lists at gmail.com Tue Nov 11 00:38:11 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 10 Nov 2014 19:38:11 -0500 Subject: 10Gb iPerf kit? In-Reply-To: <1473327677.74410.1415666119022.JavaMail.zimbra@network1.net> References: <960646944.74409.1415666050031.JavaMail.zimbra@network1.net> <1473327677.74410.1415666119022.JavaMail.zimbra@network1.net> Message-ID: why doesn't a tbird do this for you? On Mon, Nov 10, 2014 at 7:35 PM, Randy Carpenter wrote: > > I have not tried doing that myself, but the only thing that would even be possible that I know of is thunderbolt. > > A new MacBook Pro and one of these maybe: http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html > > > -Randy > > > ----- On Nov 10, 2014, at 7:26 PM, Daniel Rohan drohan at gmail.com wrote: > >> We're looking for a semi-portable solution to validate 10Gb customer >> circuits and hitting walls surrounding PCI lanes and the amount of data >> laptops can push via their busses. We'd prefer to not have techs lugging >> around server equipment for these tests. >> >> Anyone out there testing 10gbE with iPerf? If so, what are you using? >> >> Thanks, >> >> >> Dan From lyndon at orthanc.ca Tue Nov 11 00:40:16 2014 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 10 Nov 2014 16:40:16 -0800 Subject: cheap laptop with 32G or 64G recommendations In-Reply-To: References: Message-ID: On Nov 10, 2014, at 4:24 PM, Izaac wrote: > If you're stuck working in a completely isolated environment, then work it into the contract. That's the cost of being on an island. This is the argument being made against all the citizens who have the temerity to live in British Columbia, yet not within the borders of a sanctioned municipality. Izaac, spend a year getting shot at in Surrey, then get back to us. --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From contact at winterei.se Tue Nov 11 00:47:30 2014 From: contact at winterei.se (Paul S.) Date: Tue, 11 Nov 2014 09:47:30 +0900 Subject: Contact at internode / iiNet (AS4739)? Message-ID: <54615CA2.1070709@winterei.se> Hey, If anyone from the routing / peering team of Internode / iiNet happens to frequent this list, could you reach me off-list? I've been having routing problems with my peering session to you for a few months already, and haven't been able to get a response off the helpdesk. Thanks, and sorry for the noise. From corey.touchet at corp.totalserversolutions.com Tue Nov 11 00:47:37 2014 From: corey.touchet at corp.totalserversolutions.com (Corey Touchet) Date: Tue, 11 Nov 2014 00:47:37 +0000 Subject: 10Gb iPerf kit? In-Reply-To: References: Message-ID: You really want one of these http://www.jdsu.com/en-us/Test-and-Measurement/products/a-z-product-list/Pa ges/tb-6000.aspx#.VGFcetZ65PI Or it¹s larger 9000 series that can scale to 100Gb. On 11/10/14, 7:26 PM, "Daniel Rohan" wrote: >We're looking for a semi-portable solution to validate 10Gb customer >circuits and hitting walls surrounding PCI lanes and the amount of data >laptops can push via their busses. We'd prefer to not have techs lugging >around server equipment for these tests. > >Anyone out there testing 10gbE with iPerf? If so, what are you using? > >Thanks, > > >Dan From jason at lixfeld.ca Tue Nov 11 00:49:55 2014 From: jason at lixfeld.ca (Jason Lixfeld) Date: Mon, 10 Nov 2014 19:49:55 -0500 Subject: 10Gb iPerf kit? In-Reply-To: References: <960646944.74409.1415666050031.JavaMail.zimbra@network1.net> <1473327677.74410.1415666119022.JavaMail.zimbra@network1.net> Message-ID: I gotta wonder. How reliable is iPerf over something like RFC2544 or Y.1564? Especially at those speeds? I just picked up a couple of Accedian’s RFC2544/Y.1564 boxes to use as loopbacks to our field Exfos. We’ll probably wind up buying a few more Accedian boxes for the field where we don’t need to spend the money on an Exfo. One of the Accedian boxes is arguably less than what you’d pay for a TB MBP and that Sonnet adapter. > On Nov 10, 2014, at 7:38 PM, Christopher Morrow wrote: > > why doesn't a tbird do this for you? > > On Mon, Nov 10, 2014 at 7:35 PM, Randy Carpenter wrote: >> >> I have not tried doing that myself, but the only thing that would even be possible that I know of is thunderbolt. >> >> A new MacBook Pro and one of these maybe: http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html >> >> >> -Randy >> >> >> ----- On Nov 10, 2014, at 7:26 PM, Daniel Rohan drohan at gmail.com wrote: >> >>> We're looking for a semi-portable solution to validate 10Gb customer >>> circuits and hitting walls surrounding PCI lanes and the amount of data >>> laptops can push via their busses. We'd prefer to not have techs lugging >>> around server equipment for these tests. >>> >>> Anyone out there testing 10gbE with iPerf? If so, what are you using? >>> >>> Thanks, >>> >>> >>> Dan From aaron at heyaaron.com Tue Nov 11 01:14:37 2014 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Mon, 10 Nov 2014 17:14:37 -0800 Subject: Kind of sad In-Reply-To: References: Message-ID: On Mon, Nov 10, 2014 at 3:58 PM, Mike Hale wrote: > That's a far, far cry from hacking... Maybe in your opinion, but not the opinion of the very same people who were stupid enough to keep telnet open. ...and those same people have armies with guns. So my opinion and your opinion don't really matter. ;) -A From mfidelman at meetinghouse.net Tue Nov 11 01:35:31 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 10 Nov 2014 20:35:31 -0500 Subject: Kind of sad In-Reply-To: References: Message-ID: <546167E3.8060702@meetinghouse.net> Aaron C. de Bruyn wrote: > On Mon, Nov 10, 2014 at 3:58 PM, Mike Hale wrote: >> That's a far, far cry from hacking... > Maybe in your opinion, but not the opinion of the very same people who > were stupid enough to keep telnet open. ...and those same people have > armies with guns. So my opinion and your opinion don't really matter. > ;) > > -A Not sure I'd be all that worried about state.mi.us's Army. On the other hand, I might try to sell them some penetration testing and security hardening services :-) From jmkeller at houseofzen.org Tue Nov 11 01:40:32 2014 From: jmkeller at houseofzen.org (James Michael Keller) Date: Mon, 10 Nov 2014 20:40:32 -0500 Subject: Kind of sad In-Reply-To: References: Message-ID: <54616910.4050107@houseofzen.org> On 11/10/2014 06:34 PM, Joe wrote: > Kind of sad that the state govs don't curtail telnet,,, > > [root at bighughness ~]# telnet 167.240.254.155 623 > Trying 167.240.254.155... > Connected to external-dns1.state.mi.us (167.240.254.155). > Escape character is '^]'. > Username:root > Password: > Hopefully a honeypot / synthetic response from an IPS unit.... -- -James From george.herbert at gmail.com Tue Nov 11 01:41:10 2014 From: george.herbert at gmail.com (George Herbert) Date: Mon, 10 Nov 2014 17:41:10 -0800 Subject: cheap laptop with 32G or 64G recommendations In-Reply-To: References: Message-ID: "Nobody will ever need more than 64K...M...G..." George William Herbert Sent from my iPhone > On Nov 10, 2014, at 4:24 PM, Izaac wrote: > >> On November 10, 2014 4:49:08 PM EST, lobna gouda wrote: >> Hello, >> Any recommendation, not looking for anything fantasy, my understanding >> it should be quardcore, with more than DIMM0 slot so each can have 8G. >> wind7-64bits to work. I want to use it as a server or practice logical >> routers > > "Cheap" and "64GiB of RAM" are incompatible concepts in laptops. > > There is no earthly reason you should need to carry a machine like that anyway. If for some reason you need something so equipped, get yourself a cloud instance and connect to it. That's how you save money. > > If you're stuck working in a completely isolated environment, then work it into the contract. That's the cost of being on an island. > > -- > Izaac From surfer at mauigateway.com Tue Nov 11 01:44:33 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 10 Nov 2014 17:44:33 -0800 Subject: Kind of sad Message-ID: <20141110174433.80F2C920@m0005311.ppops.net> --- jmkeller at houseofzen.org wrote: From: James Michael Keller On 11/10/2014 06:34 PM, Joe wrote: > Kind of sad that the state govs don't curtail telnet,,, > > [root at bighughness ~]# telnet 167.240.254.155 623 > Trying 167.240.254.155... > Connected to external-dns1.state.mi.us (167.240.254.155). > Escape character is '^]'. > Username:root > Password: > Hopefully a honeypot / synthetic response from an IPS unit.... -------------------------------------------------- State gov't. I doubt it. I've seen the horrors that happen in those places... :-) scott From woody at pch.net Tue Nov 11 00:53:53 2014 From: woody at pch.net (Bill Woodcock) Date: Mon, 10 Nov 2014 16:53:53 -0800 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: References: <5460C679.5090005@winterei.se> Message-ID: Why use IPv4 for OOB? Seems a little late in the day for that. -Bill > On Nov 10, 2014, at 15:02, "Christopher Morrow" wrote: > >> On Mon, Nov 10, 2014 at 9:06 AM, Paul S. wrote: >> I'd be doubtful if anyone will feel like offering a /23 with OOB as >> justification these days, sadly. > > why thought? Justification is really about having a use for the ips, > right? and if you have 500 servers/network-devices ... then you have > justification for a /23 ... it seems to me. > >> >> Good luck nonetheless. >> >> >>> On 11/10/2014 午後 11:00, Ruairi Carroll wrote: >>> >>> Hey, >>> >>> VPN setup is not really a viable option (for us) in this scenario. >>> Honestly, I'd prefer to just call it done already and have a VPN but due >>> to >>> certain restraints, we have to go down this route. >>> >>> /Ruairi >>> >>>> On 10 November 2014 14:38, Alistair Mackenzie wrote: >>>> >>>> Couldn't you put a router or VPN system on the single IP they are giving >>>> you and use RFC1918 addressing space? >>>> >>>> OOB doesn't normally justify a /24 let alone a /23. >>>> >>>> On 10 November 2014 13:18, Ruairi Carroll >>>> wrote: >>>> >>>>> Dear List, >>>>> >>>>> I've got an upcoming deployment in Equinix (DC10) and I'm struggling to >>>>> find a provider who can give me a 100Mbit port (With a commit of about >>>>> 5-10Mbit) with a /23 or /24 of public space , for OOB purposes. We had >>>>> hoped to use Equinixs services, however they're limiting us to a single >>>>> public IP. >>>>> >>>>> I'm also open to other solutions - xDSL or similar, but emphasis is on >>>>> cheap and on-net. >>>>> >>>>> Cheers >>>>> /Ruairi >> From morrowc.lists at gmail.com Tue Nov 11 02:36:17 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 10 Nov 2014 21:36:17 -0500 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: References: <5460C679.5090005@winterei.se> Message-ID: because a /23 of ipv6 is very large.... :) also, it's hard to use ipv6 when your last miile provider doesn't offer it... #fios On Mon, Nov 10, 2014 at 7:53 PM, Bill Woodcock wrote: > Why use IPv4 for OOB? Seems a little late in the day for that. > > > -Bill > > >> On Nov 10, 2014, at 15:02, "Christopher Morrow" wrote: >> >>> On Mon, Nov 10, 2014 at 9:06 AM, Paul S. wrote: >>> I'd be doubtful if anyone will feel like offering a /23 with OOB as >>> justification these days, sadly. >> >> why thought? Justification is really about having a use for the ips, >> right? and if you have 500 servers/network-devices ... then you have >> justification for a /23 ... it seems to me. >> >>> >>> Good luck nonetheless. >>> >>> >>>> On 11/10/2014 午後 11:00, Ruairi Carroll wrote: >>>> >>>> Hey, >>>> >>>> VPN setup is not really a viable option (for us) in this scenario. >>>> Honestly, I'd prefer to just call it done already and have a VPN but due >>>> to >>>> certain restraints, we have to go down this route. >>>> >>>> /Ruairi >>>> >>>>> On 10 November 2014 14:38, Alistair Mackenzie wrote: >>>>> >>>>> Couldn't you put a router or VPN system on the single IP they are giving >>>>> you and use RFC1918 addressing space? >>>>> >>>>> OOB doesn't normally justify a /24 let alone a /23. >>>>> >>>>> On 10 November 2014 13:18, Ruairi Carroll >>>>> wrote: >>>>> >>>>>> Dear List, >>>>>> >>>>>> I've got an upcoming deployment in Equinix (DC10) and I'm struggling to >>>>>> find a provider who can give me a 100Mbit port (With a commit of about >>>>>> 5-10Mbit) with a /23 or /24 of public space , for OOB purposes. We had >>>>>> hoped to use Equinixs services, however they're limiting us to a single >>>>>> public IP. >>>>>> >>>>>> I'm also open to other solutions - xDSL or similar, but emphasis is on >>>>>> cheap and on-net. >>>>>> >>>>>> Cheers >>>>>> /Ruairi >>> From jbfixurpc at gmail.com Tue Nov 11 03:43:09 2014 From: jbfixurpc at gmail.com (Joe) Date: Mon, 10 Nov 2014 21:43:09 -0600 Subject: Kind of sad In-Reply-To: References: Message-ID: Generally speaking its best you do what your good at and this is not it. Exposing there is a window open to a gov agency is not hacking, trust me. I would say go back to fathering children and once you have a few more years under your belt feel free to join in. On Mon, Nov 10, 2014 at 5:48 PM, Brian Henson wrote: > Generally speaking its a bad idea to show you hacking into a server. Makes > it to easy to prosecute those who do. > From jhellenthal at dataix.net Tue Nov 11 03:58:45 2014 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Mon, 10 Nov 2014 21:58:45 -0600 Subject: Kind of sad In-Reply-To: References: Message-ID: Ha ya know what they say... Don't ever trust someone that says "trust me..." -- Jason Hellenthal Mobile: +1 (616) 953-0176 jhellenthal at DataIX.net JJH48-ARIN On Nov 10, 2014, at 21:43, Joe wrote: Generally speaking its best you do what your good at and this is not it. Exposing there is a window open to a gov agency is not hacking, trust me. I would say go back to fathering children and once you have a few more years under your belt feel free to join in. > On Mon, Nov 10, 2014 at 5:48 PM, Brian Henson wrote: > > Generally speaking its a bad idea to show you hacking into a server. Makes > it to easy to prosecute those who do. > From ju at netzwerklabor.at Tue Nov 11 04:04:55 2014 From: ju at netzwerklabor.at (Jutta Zalud) Date: Tue, 11 Nov 2014 05:04:55 +0100 Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: <54618AE7.6080401@netzwerklabor.at> On 2014-11-10 21:55, Justin M. Streiner wrote: > On Mon, 10 Nov 2014, Max Clark wrote: > >> DB9 ports seem to be a nearly extinct feature on laptops. Any >> suggestions on a cheap laptop for use in field support (with an >> onboard DB9)? My HP EliteBook 8570p has a DB9 port. (I bought it last year, so it may still be available.) When I searched for notebooks with DB9 port last year, I also found 2 models by fujitsu-siemens and some in the "rugged"/outdoor sector. (Depends on what you call cheap, though). Sorry, the links are in German, mostly. HTH, jutta http://de.fujitsu.com/ps2/aktionsmodelle/g/notebooks/e782.html http://business.panasonic.de/computerloesungen/panasonic-computer-product-solutions-produktsortiment/unser-produktsortiment-panasonic-toughbook/semi-ruggedized-notebooks http://www.durabook.com/en/compare2.php?no=88&return_link=product.php%3Fno%3D88 From larrysheldon at cox.net Tue Nov 11 04:16:04 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 10 Nov 2014 22:16:04 -0600 Subject: Undefined terms overload Message-ID: <54618D84.7030809@cox.net> I was able to ignore it for a while, but now I have run into one in two unrelated threads. What does "bikeshedding" mean here? And, what does "OOB" mean here--the decodes with which I am familiar do not seem to fit: Out of Bounds, Out Of Body, Out of Bed, Out of Business, Open Of Business (used to see this one many times daily), Out Of Bullets, Out Of Band (also familiar from telephone days). -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From morrowc.lists at gmail.com Tue Nov 11 04:23:14 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 10 Nov 2014 23:23:14 -0500 Subject: Undefined terms overload In-Reply-To: <54618D84.7030809@cox.net> References: <54618D84.7030809@cox.net> Message-ID: On Mon, Nov 10, 2014 at 11:16 PM, Larry Sheldon wrote: > I was able to ignore it for a while, but now I have run into one in two > unrelated threads. > > What does "bikeshedding" mean here? en.wikipedia.org/wiki/Parkinson's_law_of_triviality > And, what does "OOB" mean here--the decodes with which I am familiar do not 'out of band' - ideally: "Access the console of my equipment without having to use the network my equipment is supporting" > seem to fit: Out of Bounds, Out Of Body, Out of Bed, Out of Business, Open > Of Business (used to see this one many times daily), Out Of Bullets, Out Of > Band (also familiar from telephone days). > -- > The unique Characteristics of System Administrators: > > The fact that they are infallible; and, > > The fact that they learn from their mistakes. > > > Quis custodiet ipsos custodes From larrysheldon at cox.net Tue Nov 11 04:46:00 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 10 Nov 2014 22:46:00 -0600 Subject: Undefined terms overload In-Reply-To: References: <54618D84.7030809@cox.net> Message-ID: <54619488.5000305@cox.net> On 11/10/2014 22:23, Christopher Morrow wrote: Thanks--I've received several useful offers of help. >> What does "bikeshedding" mean here? > > en.wikipedia.org/wiki/Parkinson's_law_of_triviality I'd forgotten the Parkinson's discussion and the term didn't stir anything up. I have current experience with the concept. >> And, what does "OOB" mean here--the decodes with which I am familiar do not > > 'out of band' - ideally: "Access the console of my equipment without > having to use the network my equipment is supporting" From another helpful message I was able to connect to the old telephone term that had the same functional definition in a different physical implementation. Thanks, all. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From mark.tinka at seacom.mu Tue Nov 11 06:27:12 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 11 Nov 2014 08:27:12 +0200 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: References: <5460C679.5090005@winterei.se> Message-ID: <201411110827.12462.mark.tinka@seacom.mu> On Tuesday, November 11, 2014 01:00:54 AM Christopher Morrow wrote: > why thought? Justification is really about having a use > for the ips, right? and if you have 500 > servers/network-devices ... then you have justification > for a /23 ... it seems to me. Unless Equinix have an actual product called OoB, in which case it automatically comes with a /30, or /126. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From ongbh at ispworkshop.com Tue Nov 11 07:47:49 2014 From: ongbh at ispworkshop.com (Ong Beng Hui) Date: Tue, 11 Nov 2014 15:47:49 +0800 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: <86ioint96l.fsf@valhalla.seastrom.com> References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> <408485736.424491.1415589269215.JavaMail.zimbra@snappytelecom.net> <86ioint96l.fsf@valhalla.seastrom.com> Message-ID: <5461BF25.80302@ispworkshop.com> That's pretty much the best honest answer. If all else fail, sell it or leased it to someone whom can do that. On 10/11/14 10:35 pm, Rob Seastrom wrote: > While short and to the point, what Fletcher said is likely to be the > best advice in this thread. > > Getting someone on staff who understands *both* outside plant > architecture and balance sheets... and can co-develop a business > model that involves the lateral build-out from the six POPs around > town without going broke is the hard part. > > "Six POPs, six strands, MPLS backbone vs. selling waves" could be the > concept for the opening lines to a sad country song where the > protagonist doesn't realize that the long pole in the tent is the > making the edge work (someone please run with this and get a musical > lightning talk at San Antonio!) > > -r > > Faisal Imtiaz writes: > >> WoW !.. that was a rather cruel and un-called for ! >> >> How does that saying go.....Don't say anything, if you cannot say anything nice ! >> >> >> >> Faisal Imtiaz >> Snappy Internet & Telecom >> >> ----- Original Message ----- >>> From: "Fletcher Kittredge" >>> To: "Lorell Hathcock" >>> Cc: nanog at nanog.org >>> Sent: Sunday, November 9, 2014 9:56:08 PM >>> Subject: Re: I am about to inherit 26 miles of dark fiber. What do I do with it? >>> >>> The below is a really sad story. Condolences on the coming trainwreck. I >>> hope you get someone on staff or on consult that understands outside plant >>> architecture, because it is much more important and complex topic than you >>> seem to realize. >>> >>> >>> On Sun, Nov 9, 2014 at 9:18 PM, Lorell Hathcock wrote: >>> >>>> All: >>>> >>>> A job opportunity just came my way to work with 26 miles of dark fiber in >>>> and around a city in Texas. >>>> >>>> The intent is for me to deliver internet and private network services to >>>> business customers in this area. >>>> >>>> I relish the thought of starting from scratch to build a network right >>>> from the start instead of inheriting and fixing someone else's mess. >>>> >>>> That being said, what suggestions does the group have for building a new >>>> network using existing dark fiber? >>>> >>>> MPLS backbone? Like all businesses these days, I will likely have to >>>> build the lit backbone as I add customers. So how would you recommend >>>> scaling the network? >>>> >>>> I have six strands of SMF that connect within municipal facilities. Each >>>> new customer will be a new build out from the nearest point. Because of >>>> having only six strands, I don't anticipate selling dark fiber. I believe I >>>> need to conserve fibers so that it would be lit services that I offer to >>>> customers. >>>> >>>> I would like to offer speeds up to 10 GB. >>>> >>>> Thoughts are appreciated! >>>> >>>> Sincerely, >>>> >>>> Lorell Hathcock >>> >>> >>> >>> -- >>> Fletcher Kittredge >>> GWI >>> 8 Pomerleau Street >>> Biddeford, ME 04005-9457 >>> 207-602-1134 >>> From javier at advancedmachines.us Tue Nov 11 08:32:13 2014 From: javier at advancedmachines.us (Javier J) Date: Tue, 11 Nov 2014 03:32:13 -0500 Subject: Kind of sad In-Reply-To: References: Message-ID: Is there a vulnerability in telnet to be exploited? If not it might be on purpose. I know of switching gear that is publicly accessible via telnet. On Mon, Nov 10, 2014 at 10:58 PM, Jason Hellenthal wrote: > Ha ya know what they say... Don't ever trust someone that says "trust > me..." > > -- > Jason Hellenthal > Mobile: +1 (616) 953-0176 > jhellenthal at DataIX.net > JJH48-ARIN > > On Nov 10, 2014, at 21:43, Joe wrote: > > Generally speaking its best you do what your good at and this is not it. > > Exposing there is a window open to a gov agency is not hacking, trust me. I > would say go back to fathering children and once you have a few more years > under your belt feel free to join in. > > On Mon, Nov 10, 2014 at 5:48 PM, Brian Henson > wrote: > > > > Generally speaking its a bad idea to show you hacking into a server. > Makes > > it to easy to prosecute those who do. > > > From kauer at biplane.com.au Tue Nov 11 09:05:08 2014 From: kauer at biplane.com.au (Karl Auer) Date: Tue, 11 Nov 2014 20:05:08 +1100 Subject: Kind of sad In-Reply-To: References: Message-ID: <1415696708.11568.96.camel@karl> On Tue, 2014-11-11 at 03:32 -0500, Javier J wrote: > Is there a vulnerability in telnet to be exploited? If not it might be on > purpose. I know of switching gear that is publicly accessible via telnet. telnet does not of itself encrypt anything. If you log in somewhere via telnet, everything that passes between you and the remote end is passing in clear text. That is true for all data sent to you or from you during the whole session, but especially for the username and password you may have used to log in with. Unless you have secured the channel by some other means (an encrypted tunnel, for example) or you own and control and can vouch for every piece of the infrastructure between you and the remote end, using telnet is just about the most insecure thing you can do short of mailing stuff to yourself on postcards. Someone who puts a real switch doing real work on the Internet with working telnet access is asking to have at least the switch compromised very quickly. A plaything, a honeypot, or a teaching tool - maybe. Anything else, probably a bad idea. Remember that if I own your switch, I own all the data sent to or from any system connected to that switch... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A From twh at megagroup.ru Tue Nov 11 09:34:23 2014 From: twh at megagroup.ru (Stepan Kucherenko) Date: Tue, 11 Nov 2014 12:34:23 +0300 Subject: Tech Laptop with DB9 In-Reply-To: <827EAAF0-3B70-451E-90EE-037839B7FF1C@neilson.net.nz> References: <827EAAF0-3B70-451E-90EE-037839B7FF1C@neilson.net.nz> Message-ID: <5461D81F.80702@megagroup.ru> I want to reiterate on AirConsole because it IS amazing. I don't even grab a laptop when I go onsite anymore, just an AirConsole, its usb-serial cable and a tablet. Laptop can be a requirement if you need more than a serial, but using serial-over-wifi and a tablet is an incredible quality of life upgrade if you only need a quick reconfigure most of the time. Even if you have to use a laptop, it's so much better to not be attached to the rack so you can find a more comfortable place to work. Although it's kinda strange that Andoid app is free but IOS one isn't. Also I wish I could use their wifi as a simple bridge without its own DHCP while using a serial, it'd be even more nice for troubleshooting. From eugen at imacandi.net Tue Nov 11 09:40:17 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Tue, 11 Nov 2014 11:40:17 +0200 Subject: Kind of sad In-Reply-To: References: Message-ID: On Tue, Nov 11, 2014 at 1:58 AM, Mike Hale wrote: > That's a far, far cry from hacking... Remember that CFAA has a very vague definition of "unauthorized computer access". From javier at advancedmachines.us Tue Nov 11 11:05:37 2014 From: javier at advancedmachines.us (Javier J) Date: Tue, 11 Nov 2014 06:05:37 -0500 Subject: Kind of sad In-Reply-To: <1415696708.11568.96.camel@karl> References: <1415696708.11568.96.camel@karl> Message-ID: I agree with you 100 percent. But my point is. Telnet in and of itself isn't broken. Not that I would want to leave it open to the world. He.net has a router you can log into over telnet with no auth. Forgot URL but you can find it on their site. On Nov 11, 2014 4:05 AM, "Karl Auer" wrote: > On Tue, 2014-11-11 at 03:32 -0500, Javier J wrote: > > Is there a vulnerability in telnet to be exploited? If not it might be on > > purpose. I know of switching gear that is publicly accessible via telnet. > > telnet does not of itself encrypt anything. If you log in somewhere via > telnet, everything that passes between you and the remote end is passing > in clear text. That is true for all data sent to you or from you during > the whole session, but especially for the username and password you may > have used to log in with. > > Unless you have secured the channel by some other means (an encrypted > tunnel, for example) or you own and control and can vouch for every > piece of the infrastructure between you and the remote end, using telnet > is just about the most insecure thing you can do short of mailing stuff > to yourself on postcards. > > Someone who puts a real switch doing real work on the Internet with > working telnet access is asking to have at least the switch compromised > very quickly. A plaything, a honeypot, or a teaching tool - maybe. > Anything else, probably a bad idea. Remember that if I own your switch, > I own all the data sent to or from any system connected to that > switch... > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 > Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A > > > From javier at advancedmachines.us Tue Nov 11 11:07:25 2014 From: javier at advancedmachines.us (Javier J) Date: Tue, 11 Nov 2014 06:07:25 -0500 Subject: Kind of sad In-Reply-To: References: <1415696708.11568.96.camel@karl> Message-ID: Found it. telnet://route-server.he.net On Nov 11, 2014 6:05 AM, "Javier J" wrote: > I agree with you 100 percent. But my point is. Telnet in and of itself > isn't broken. Not that I would want to leave it open to the world. He.net > has a router you can log into over telnet with no auth. Forgot URL but you > can find it on their site. > On Nov 11, 2014 4:05 AM, "Karl Auer" wrote: > >> On Tue, 2014-11-11 at 03:32 -0500, Javier J wrote: >> > Is there a vulnerability in telnet to be exploited? If not it might be >> on >> > purpose. I know of switching gear that is publicly accessible via >> telnet. >> >> telnet does not of itself encrypt anything. If you log in somewhere via >> telnet, everything that passes between you and the remote end is passing >> in clear text. That is true for all data sent to you or from you during >> the whole session, but especially for the username and password you may >> have used to log in with. >> >> Unless you have secured the channel by some other means (an encrypted >> tunnel, for example) or you own and control and can vouch for every >> piece of the infrastructure between you and the remote end, using telnet >> is just about the most insecure thing you can do short of mailing stuff >> to yourself on postcards. >> >> Someone who puts a real switch doing real work on the Internet with >> working telnet access is asking to have at least the switch compromised >> very quickly. A plaything, a honeypot, or a teaching tool - maybe. >> Anything else, probably a bad idea. Remember that if I own your switch, >> I own all the data sent to or from any system connected to that >> switch... >> >> Regards, K. >> >> -- >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Karl Auer (kauer at biplane.com.au) >> http://www.biplane.com.au/kauer >> http://twitter.com/kauer389 >> >> GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 >> Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A >> >> >> From ariel at post.tau.ac.il Tue Nov 11 12:29:49 2014 From: ariel at post.tau.ac.il (Ariel Biener) Date: Tue, 11 Nov 2014 14:29:49 +0200 Subject: Kind of sad In-Reply-To: References: <1415696708.11568.96.camel@karl> Message-ID: <5462013D.9000702@post.tau.ac.il> From Patrick.Darden at p66.com Tue Nov 11 13:21:16 2014 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Tue, 11 Nov 2014 07:21:16 -0600 Subject: cheap laptop with 32G or 64G recommendations In-Reply-To: References: Message-ID: If there is a cheap quad-core laptop with 64GB of ram and no huge downsides... then sign me up! I expect that will be the standard in 5 years, but right now that is a hoss. Izaac's suggestion of using the cloud is good, if you can do it. Cloud services have come a long way--fast and easy to set up complex environments. Great article comparing performance and costs: http://www.infoworld.com/article/2610403/cloud-computing/ultimate-cloud-speed-tests--amazon-vs--google-vs--windows-azure.html --p -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Izaac Sent: Monday, November 10, 2014 6:25 PM To: NANOG Subject: [EXTERNAL]Re: cheap laptop with 32G or 64G recommendations On November 10, 2014 4:49:08 PM EST, lobna gouda wrote: >Hello, >Any recommendation, not looking for anything fantasy, my understanding >it should be quardcore, with more than DIMM0 slot so each can have 8G. >wind7-64bits to work. I want to use it as a server or practice logical >routers "Cheap" and "64GiB of RAM" are incompatible concepts in laptops. There is no earthly reason you should need to carry a machine like that anyway. If for some reason you need something so equipped, get yourself a cloud instance and connect to it. That's how you save money. If you're stuck working in a completely isolated environment, then work it into the contract. That's the cost of being on an island. -- Izaac From colton.conor at gmail.com Tue Nov 11 14:59:30 2014 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 11 Nov 2014 08:59:30 -0600 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: Does CBT or any of these other subscription based learning courses include a Cisco IOS simulator so we don't have to buy a Cisco lab or equipment? On Sun, Nov 2, 2014 at 7:36 PM, Scott Morris wrote: > Depends on how quickly you want them trained, and how they tend to learn > thingsŠ > > Reading is good, but can be boring and tedious and not always have all the > answers. > Standard ILT can be costly, but very quick and often standard (though I¹d > shop around for who you have as an instructor since that can make or break > the success)! > Video-based training gives a good mix of things and there are options out > there. I know there¹s been one other response for CBT Nuggets, which I > would definitely recommend. > > Take that with a grain of salt (and I¹m ok with that) since I do some work > for them now. However, I would have recommended them even before I > started developing training for them. :) > > Jeremy Cioara teaches the CCNA courses for CBT, and he is quite animated > and very knowledgeable. He will definitely get all the necessary points > across. In addition to the certification courses you mentioned, there are > also many ³real world² variants of materials as well, which give a > different slant to the teachings that you may find useful for your group. > > And being a subscription cost, you can watch as many different things as > you¹d like rather than being limited to one course. Something worth > checking out. Don¹t take my word for it, go look for yourself (or have > your group do that). > > Cheers, > > Scott > > -----Original Message----- > From: Colton Conor > Date: Sunday, November 2, 2014 at 1:02 PM > To: NANOG > Subject: Cisco CCNA Training > > >We have a couple of techs that want to learn cisco and networking in > >general. What do you recommend for learning and getting certified on > >Cisco? > >There seems to be a million different training courses, books, etc out > >there. > > > From swm at emanon.com Tue Nov 11 15:06:38 2014 From: swm at emanon.com (Scott Morris) Date: Tue, 11 Nov 2014 10:06:38 -0500 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: You can grab GNS separately and for free, which will allow you to build the topologies that you are looking for. That is what is used to demonstrate most of the Cisco courses between the trainers. Scott From: Colton Conor Date: Tuesday, November 11, 2014 at 9:59 AM To: Scott Morris Cc: NANOG Subject: Re: Cisco CCNA Training Does CBT or any of these other subscription based learning courses include a Cisco IOS simulator so we don't have to buy a Cisco lab or equipment? On Sun, Nov 2, 2014 at 7:36 PM, Scott Morris wrote: Depends on how quickly you want them trained, and how they tend to learn thingsŠ Reading is good, but can be boring and tedious and not always have all the answers. Standard ILT can be costly, but very quick and often standard (though I¹d shop around for who you have as an instructor since that can make or break the success)! Video-based training gives a good mix of things and there are options out there. I know there¹s been one other response for CBT Nuggets, which I would definitely recommend. Take that with a grain of salt (and I¹m ok with that) since I do some work for them now. However, I would have recommended them even before I started developing training for them. :) Jeremy Cioara teaches the CCNA courses for CBT, and he is quite animated and very knowledgeable. He will definitely get all the necessary points across. In addition to the certification courses you mentioned, there are also many ³real world² variants of materials as well, which give a different slant to the teachings that you may find useful for your group. And being a subscription cost, you can watch as many different things as you¹d like rather than being limited to one course. Something worth checking out. Don¹t take my word for it, go look for yourself (or have your group do that). Cheers, Scott -----Original Message----- From: Colton Conor Date: Sunday, November 2, 2014 at 1:02 PM To: NANOG Subject: Cisco CCNA Training >We have a couple of techs that want to learn cisco and networking in >general. What do you recommend for learning and getting certified on >Cisco? >There seems to be a million different training courses, books, etc out >there. From contact at winterei.se Tue Nov 11 15:07:52 2014 From: contact at winterei.se (Paul S.) Date: Wed, 12 Nov 2014 00:07:52 +0900 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: <54622648.8000702@winterei.se> GNS3, while unofficial, is what I'd recommend for that. On 11/11/2014 午後 11:59, Colton Conor wrote: > Does CBT or any of these other subscription based learning courses include > a Cisco IOS simulator so we don't have to buy a Cisco lab or equipment? > > On Sun, Nov 2, 2014 at 7:36 PM, Scott Morris wrote: > >> Depends on how quickly you want them trained, and how they tend to learn >> thingsŠ >> >> Reading is good, but can be boring and tedious and not always have all the >> answers. >> Standard ILT can be costly, but very quick and often standard (though I¹d >> shop around for who you have as an instructor since that can make or break >> the success)! >> Video-based training gives a good mix of things and there are options out >> there. I know there¹s been one other response for CBT Nuggets, which I >> would definitely recommend. >> >> Take that with a grain of salt (and I¹m ok with that) since I do some work >> for them now. However, I would have recommended them even before I >> started developing training for them. :) >> >> Jeremy Cioara teaches the CCNA courses for CBT, and he is quite animated >> and very knowledgeable. He will definitely get all the necessary points >> across. In addition to the certification courses you mentioned, there are >> also many ³real world² variants of materials as well, which give a >> different slant to the teachings that you may find useful for your group. >> >> And being a subscription cost, you can watch as many different things as >> you¹d like rather than being limited to one course. Something worth >> checking out. Don¹t take my word for it, go look for yourself (or have >> your group do that). >> >> Cheers, >> >> Scott >> >> -----Original Message----- >> From: Colton Conor >> Date: Sunday, November 2, 2014 at 1:02 PM >> To: NANOG >> Subject: Cisco CCNA Training >> >>> We have a couple of techs that want to learn cisco and networking in >>> general. What do you recommend for learning and getting certified on >>> Cisco? >>> There seems to be a million different training courses, books, etc out >>> there. >> >> From mike at mtcc.com Tue Nov 11 15:44:04 2014 From: mike at mtcc.com (Michael Thomas) Date: Tue, 11 Nov 2014 07:44:04 -0800 Subject: Kind of sad In-Reply-To: <1415696708.11568.96.camel@karl> References: <1415696708.11568.96.camel@karl> Message-ID: <54622EC4.6060205@mtcc.com> On 11/11/2014 01:05 AM, Karl Auer wrote: > Someone who puts a real switch doing real work on the Internet with > working telnet access is asking to have at least the switch > compromised very quickly. A plaything, a honeypot, or a teaching tool > - maybe. Anything else, probably a bad idea. Remember that if I own > your switch, I own all the data sent to or from any system connected > to that switch... Regards, K. How so? Assuming that you're using password auth, the real vulnerability is somebody figuring out the password and owning the box. SSH certainly helps here immensely with rsa auth, but only if you use it. An active MITM attack or passive snooping on telnet streams seems like it would be orders of magnitude less dangerous on a list of threats. SSH is definitely a Good Thing, but it's not a sliver bullet. Mike From rafael at gav.ufsc.br Tue Nov 11 16:01:14 2014 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Tue, 11 Nov 2014 10:01:14 -0600 Subject: Kind of sad In-Reply-To: References: Message-ID: There are thousands of devices out there with vulns that'd make you feel sick to the stomach. You can be a good samaritan and alert the appropriate contacts, but simply bringing into public doesn't really fix the issue. On Mon, Nov 10, 2014 at 5:34 PM, Joe wrote: > Kind of sad that the state govs don't curtail telnet,,, > > [root at bighughness ~]# telnet 167.240.254.155 623 > Trying 167.240.254.155... > Connected to external-dns1.state.mi.us (167.240.254.155). > Escape character is '^]'. > Username:root > Password: > From mike.hyde1 at gmail.com Tue Nov 11 16:19:17 2014 From: mike.hyde1 at gmail.com (Mike Hyde) Date: Tue, 11 Nov 2014 10:19:17 -0600 Subject: Tech Laptop with DB9 In-Reply-To: <5461D81F.80702@megagroup.ru> References: <827EAAF0-3B70-451E-90EE-037839B7FF1C@neilson.net.nz> <5461D81F.80702@megagroup.ru> Message-ID: <54623705.9060002@gmail.com> Another vote for AirConsole. I have the updated version that uses bluetooth so that I can use the WiFi at the same time. Works great. Our shop uses USB to Serial adapters, but we had to get ones with static protection. We move between multiple boxes (older PBX systems) and every so often we would have the adapter and/or OS lock up due to static. Never had problems since getting the new ones. > Stepan Kucherenko > November 11, 2014 at 3:34 AM > I want to reiterate on AirConsole because it IS amazing. I don't even > grab a laptop when I go onsite anymore, just an AirConsole, its > usb-serial cable and a tablet. > > Laptop can be a requirement if you need more than a serial, but using > serial-over-wifi and a tablet is an incredible quality of life upgrade > if you only need a quick reconfigure most of the time. > > Even if you have to use a laptop, it's so much better to not be attached > to the rack so you can find a more comfortable place to work. > > Although it's kinda strange that Andoid app is free but IOS one isn't. > Also I wish I could use their wifi as a simple bridge without its own > DHCP while using a serial, it'd be even more nice for troubleshooting. > > > > Alexander Neilson > November 10, 2014 at 3:11 PM > I have found Air Console to be amazing: > > http://www.get-console.com/airconsole/ > > I have one that comes with me in my bag everywhere. > > I also have purchased a couple of their 1.8M USB to Cisco Rollover > Cables which include the USB to Serial converter in the USB Plug. The > cable can be adapted to serial and null modem with the end adapters > (may not work in every situation) > > The FDDI chip in these cables has strong driver availability across > all OS’s and is also installed by default in some OS’s (including OS X > - my personal preference for direct interaction machine) > > This way as long as you have USB ports and Wifi you have an awesome > tool set. The Air Console can even bridge traffic for monitoring / > wireshark over Wifi (obvious bandwidth limitations) so I really enjoy > having it with me. > > Regards > Alexander > > Alexander Neilson > Neilson Productions Limited > > alexander at neilson.net.nz > 021 329 681 > 022 456 2326 > > > Max Clark > November 10, 2014 at 2:39 PM > Hi all, > > DB9 ports seem to be a nearly extinct feature on laptops. Any > suggestions on a cheap laptop for use in field support (with an > onboard DB9)? > > Thanks, > Max > > From andrius at andrius.org Tue Nov 11 16:27:49 2014 From: andrius at andrius.org (Andrius Kasparavicius) Date: Tue, 11 Nov 2014 16:27:49 +0000 Subject: Inside China GFW - basic dedicated server or cloud instance Message-ID: <1415723269271.63621@andrius.org> Business needs some permanent basic browser/tcp/ip view from *inside China great firewall* (Hong Kong or unfirewalled locations not good) for connectivity testing, troubleshooting for customers in China. Ideally just a dedicated windows box/server. Are there any simple providers with self-provisioning VPS or similar low cost solutions. Best to have it on ChinaTel network. No hosting or content would be shared from this box. Thanks From ariel at post.tau.ac.il Tue Nov 11 16:38:59 2014 From: ariel at post.tau.ac.il (Ariel Biener) Date: Tue, 11 Nov 2014 18:38:59 +0200 Subject: Kind of sad In-Reply-To: <54622EC4.6060205@mtcc.com> References: <1415696708.11568.96.camel@karl> <54622EC4.6060205@mtcc.com> Message-ID: <54623BA3.9090209@post.tau.ac.il> From lists at mtin.net Tue Nov 11 16:39:55 2014 From: lists at mtin.net (Justin Wilson) Date: Tue, 11 Nov 2014 11:39:55 -0500 Subject: I am about to inherit 26 miles of dark fiber. What do I do with it? In-Reply-To: <260979806.424530.1415589946529.JavaMail.zimbra@snappytelecom.net> References: <5878C0A5-A727-4C8F-A2C1-5B8DFC220C8A@hathcock.org> <260979806.424530.1415589946529.JavaMail.zimbra@snappytelecom.net> Message-ID: +1 There are several guys doing Fiber. WISPA has workshops and such as well. Justin -- Justin Wilson http://www.mtin.net Managed Services ­ xISP Solutions ­ Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering ­ Transit ­ Internet Exchange On 11/9/14, 10:25 PM, "Faisal Imtiaz" wrote: >I would suggest that you do some rapid field deployment education in >regards to fiber networks. > >You might consider joining WISPA and or FISPA (two industry >associations), where you have folks building out fiber networks, who are >very willing to share their experience and tell you what is working and >what is not working. > >Working with Dark fiber can be as simple as you like, or as complicated >as you want it to be. However this is one area that it is not un-common >to make things appear a lot more expensive and complicated then what they >have to be... > >Depending on what you are inheriting, and what you have to be responsible >for, I would suggest that you spend some time on the web, local library, >and some of the OSP related publications to get a good understanding of >what is done and why....before just falling for industry jargon. > >I should be fun... :) > >Faisal Imtiaz >Snappy Internet & Telecom > > >----- Original Message ----- >> From: "Lorell Hathcock" >> To: nanog at nanog.org >> Sent: Sunday, November 9, 2014 9:18:15 PM >> Subject: I am about to inherit 26 miles of dark fiber. What do I do >>with it? >> >> All: >> >> A job opportunity just came my way to work with 26 miles of dark fiber >>in and >> around a city in Texas. >> >> The intent is for me to deliver internet and private network services to >> business customers in this area. >> >> I relish the thought of starting from scratch to build a network right >>from >> the start instead of inheriting and fixing someone else's mess. >> >> That being said, what suggestions does the group have for building a new >> network using existing dark fiber? >> >> MPLS backbone? Like all businesses these days, I will likely have to >>build >> the lit backbone as I add customers. So how would you recommend scaling >>the >> network? >> >> I have six strands of SMF that connect within municipal facilities. >>Each new >> customer will be a new build out from the nearest point. Because of >>having >> only six strands, I don't anticipate selling dark fiber. I believe I >>need to >> conserve fibers so that it would be lit services that I offer to >>customers. >> >> I would like to offer speeds up to 10 GB. >> >> Thoughts are appreciated! >> >> Sincerely, >> >> Lorell Hathcock > From shortdudey123 at gmail.com Tue Nov 11 17:05:36 2014 From: shortdudey123 at gmail.com (Grant Ridder) Date: Tue, 11 Nov 2014 09:05:36 -0800 Subject: Inside China GFW - basic dedicated server or cloud instance In-Reply-To: <1415723269271.63621@andrius.org> References: <1415723269271.63621@andrius.org> Message-ID: You can try AWS China, but I think you need an ICP license for that. -Grant On Tue, Nov 11, 2014 at 8:27 AM, Andrius Kasparavicius wrote: > Business needs some permanent basic browser/tcp/ip view from *inside China > great firewall* (Hong Kong or unfirewalled locations not good) for > connectivity testing, troubleshooting for customers in China. Ideally just > a dedicated windows box/server. Are there any simple providers with > self-provisioning VPS or similar low cost solutions. Best to have it on > ChinaTel network. No hosting or content would be shared from this box. > Thanks > From Valdis.Kletnieks at vt.edu Tue Nov 11 17:27:02 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 11 Nov 2014 12:27:02 -0500 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: Your message of "Mon, 10 Nov 2014 21:36:17 -0500." References: <5460C679.5090005@winterei.se> Message-ID: <9003.1415726822@turing-police.cc.vt.edu> On Mon, 10 Nov 2014 21:36:17 -0500, Christopher Morrow said: > also, it's hard to use ipv6 when your last miile provider doesn't offer it... I hear the chaps at Hurricane Electric can help you with a nice tunnel for that... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From streiner at cluebyfour.org Tue Nov 11 17:31:16 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 11 Nov 2014 12:31:16 -0500 (EST) Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: <9003.1415726822@turing-police.cc.vt.edu> References: <5460C679.5090005@winterei.se> <9003.1415726822@turing-police.cc.vt.edu> Message-ID: On Tue, 11 Nov 2014, Valdis.Kletnieks at vt.edu wrote: > On Mon, 10 Nov 2014 21:36:17 -0500, Christopher Morrow said: > >> also, it's hard to use ipv6 when your last miile provider doesn't offer it... > > I hear the chaps at Hurricane Electric can help you with a nice tunnel > for that... Indeed. I've had one in place for probably two years. Works like a charm. Kudos to Owen & co :) jms From ryan.landry at gmail.com Tue Nov 11 17:35:10 2014 From: ryan.landry at gmail.com (ryanL) Date: Tue, 11 Nov 2014 09:35:10 -0800 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: <9003.1415726822@turing-police.cc.vt.edu> References: <5460C679.5090005@winterei.se> <9003.1415726822@turing-police.cc.vt.edu> Message-ID: just last week i was able to get a /23 from $ISP as part of my transit purchase with them for one location, but you still have to explain and justify your use to $ISP (who in-turn has to explain/justify to ARIN). if you can't do that, it really is "just cuz i want it". like someone else said previously, that just doesn't work nowadays. so, due the diligence, or rethink your design. if you can legit justify it, and particularly if you are doing bgp, there's really no reason why any worthwhile transit provider won't give you a /24. From bzs at world.std.com Tue Nov 11 19:39:09 2014 From: bzs at world.std.com (Barry Shein) Date: Tue, 11 Nov 2014 14:39:09 -0500 Subject: Tech Laptop with DB9 [REALLY Equinox SST] In-Reply-To: References: Message-ID: <21602.26077.19205.445729@world.std.com> Executive Summary: Anyone have an updated linux driver for an Equinox/Avocent SST-128? I've used an Equinox SST-128 for serial ports for years. It's a PCI card with a cable to panels with up to 128 serial ports (RJ-45.) It's been very handy, never given me trouble, just plugging in a piece of CAT-5 has almost always worked (there are RJ-45 to DB9 and DB15 adapters.) Just connect some terminal emulator or similar to the device (something like /dev/ttyAG), I've used eterm for no deep reason other than it "just worked", it's an odd fork or rewrite of xterm. But any vendor support is long gone. I think Equinox sold it to Avocent or changed their name and the newest Linux driver is about 5 years old and won't run on anything newer than, well, pretty old, SuSE 9.3, the newest didn't "just build" on 10.x and that's pretty old, 2.6 kernel. And of course the one system I was using it on just died, everything else here has too-new Linux, typically openSuSE 13.1. I'd hate to have to rebuild a 5+ year old linux just to run this one card. SO BEFORE I dig in and try to port the driver I was wondering if anyone else has done this already? -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From blakangel at gmail.com Tue Nov 11 20:13:09 2014 From: blakangel at gmail.com (blakangel at gmail.com) Date: Tue, 11 Nov 2014 12:13:09 -0800 Subject: cheap laptop with 32G or 64G recommendations In-Reply-To: References: Message-ID: <54626DD5.2090701@gmail.com> I have an almost two-year old Lenovo W530 with 32G ram. I've been happy with it. I don't find myself taking advantage of the ram (w/ VMWare Workstation) as much as I thought I would. http://shop.lenovo.com/us/en/laptops/thinkpad/w-series/w530/ -Keith Darden, Patrick wrote: > If there is a cheap quad-core laptop with 64GB of ram and no huge downsides... then sign me up! I expect that will be the standard in 5 years, but right now that is a hoss. > > Izaac's suggestion of using the cloud is good, if you can do it. Cloud services have come a long way--fast and easy to set up complex environments. Great article comparing performance and costs: > > http://www.infoworld.com/article/2610403/cloud-computing/ultimate-cloud-speed-tests--amazon-vs--google-vs--windows-azure.html > > --p > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Izaac > Sent: Monday, November 10, 2014 6:25 PM > To: NANOG > Subject: [EXTERNAL]Re: cheap laptop with 32G or 64G recommendations > > On November 10, 2014 4:49:08 PM EST, lobna gouda wrote: >> Hello, >> Any recommendation, not looking for anything fantasy, my understanding >> it should be quardcore, with more than DIMM0 slot so each can have 8G. >> wind7-64bits to work. I want to use it as a server or practice logical >> routers > > "Cheap" and "64GiB of RAM" are incompatible concepts in laptops. > > There is no earthly reason you should need to carry a machine like that anyway. If for some reason you need something so equipped, get yourself a cloud instance and connect to it. That's how you save money. > > If you're stuck working in a completely isolated environment, then work it into the contract. That's the cost of being on an island. > > -- > Izaac From izaac at setec.org Tue Nov 11 20:18:44 2014 From: izaac at setec.org (Izaac) Date: Tue, 11 Nov 2014 15:18:44 -0500 Subject: cheap laptop with 32G or 64G recommendations In-Reply-To: References: Message-ID: <20141111T201322Z@localhost> On Mon, Nov 10, 2014 at 04:40:16PM -0800, Lyndon Nerenberg wrote: > > If you're stuck working in a completely isolated environment, then > > work it into the contract. That's the cost of being on an island. > > This is the argument being made against all the citizens who have the > temerity to live in British Columbia, yet not within the borders of a > sanctioned municipality. I speak of an isolated network, i.e. an island. A network from which our initial correspondent may not be able to access large amounts of computing iron remotely. In such cases, whoever is operating the island ought to be expected to provide or bear the cost of providing those resources. I have no idea what citizenship in British Columbia -- urban or otherwise -- has to do with anything. > Izaac, spend a year getting shot at in Surrey, then get back to us. Pardon, sir, you seem to have a chip on your shoulder which is affecting the 'professionalism' part of your brain. I'm reasonably sure it doesn't have my name on it. As such, I'll politely decline to place myself in mortal danger as you suggest. And further point out that there are far less scenic parts of the world than a Canadian suburb in which I may have had people try and shoot at me. - Izaac From kauer at biplane.com.au Tue Nov 11 21:22:05 2014 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 12 Nov 2014 08:22:05 +1100 Subject: Kind of sad In-Reply-To: <54622EC4.6060205@mtcc.com> References: <1415696708.11568.96.camel@karl> <54622EC4.6060205@mtcc.com> Message-ID: <1415740925.11568.157.camel@karl> On Tue, 2014-11-11 at 07:44 -0800, Michael Thomas wrote: > On 11/11/2014 01:05 AM, Karl Auer wrote: > > Someone who puts a real switch doing real work on the Internet with > > working telnet access is asking to have at least the switch > > compromised very quickly. > > How so? Assuming that you're using password auth, the real > vulnerability is somebody figuring out the password and owning the > box. SSH certainly helps here immensely with rsa auth, but only if you > use it. Well - yes. That's sort of my point. If you are going to send a password over a network, make sure it's encrypted. Telnet isn't encrypted. > An active MITM attack or passive snooping on telnet streams seems like > it would be orders of magnitude less dangerous on a list of threats. > SSH is definitely a Good Thing, but it's not a sliver bullet. I didn't say it was. I just said that sending passwords in clear text over the network is a very bad idea. Telnet does that, so using telnet is a very bad idea. Use ssh, and the problem is gone. There are other ways to make the problem disappear, and obviously neither they nor ssh will protect you if you do any of a dozen other silly things. Don't use telnet access for management of anything valuable unless you own every inch of the path from you to it, or unless you can encrypt the channel via other means. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A From jfbeam at gmail.com Tue Nov 11 21:37:37 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 11 Nov 2014 16:37:37 -0500 Subject: Kind of sad In-Reply-To: References: Message-ID: On Mon, 10 Nov 2014 22:43:09 -0500, Joe wrote: > Generally speaking its best you do what your good at and this is not it. > > Exposing there is a window open to a gov agency is not hacking, trust > me. I would say go back to fathering children and once you have a few > more years under your belt feel free to join in. And you, sir, should consult a lawyer before publicly slinging insults. I'm not a lawyer, but I have worked with one in this area. What you have post *is* evidence of a crime under the Computer and Fraud Abuse Act. The wording of that law is horrible, but it is what it is; the bar for of "unauthorized access" is *very* low. How you found it is irrelevant. You connected it to it -- knowing full well you are not authorized -- and proceeded to attempt to login, even if in jest. (Government agencies have zero sense of humor. And judges have next to no understanding of technology. Merely being charged can be a career killer.) From randy at psg.com Wed Nov 12 00:43:48 2014 From: randy at psg.com (Randy Bush) Date: Tue, 11 Nov 2014 14:43:48 -1000 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: <9003.1415726822@turing-police.cc.vt.edu> References: <5460C679.5090005@winterei.se> <9003.1415726822@turing-police.cc.vt.edu> Message-ID: > I hear the chaps at Hurricane Electric can help you with a nice tunnel > for that... there is no such thing as a nice tunnel From morrowc.lists at gmail.com Wed Nov 12 00:56:10 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 11 Nov 2014 19:56:10 -0500 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: <9003.1415726822@turing-police.cc.vt.edu> References: <5460C679.5090005@winterei.se> <9003.1415726822@turing-police.cc.vt.edu> Message-ID: On Tue, Nov 11, 2014 at 12:27 PM, wrote: > On Mon, 10 Nov 2014 21:36:17 -0500, Christopher Morrow said: > >> also, it's hard to use ipv6 when your last miile provider doesn't offer it... > > I hear the chaps at Hurricane Electric can help you with a nice tunnel for that... yea.. because when the sh*t hits the fan I REALLY need a dependency upon a wonky tunnel server made of cheese and mouse parts to be in the middle of my work process? From ops.lists at gmail.com Wed Nov 12 01:05:06 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 12 Nov 2014 06:35:06 +0530 Subject: Inside China GFW - basic dedicated server or cloud instance In-Reply-To: References: <1415723269271.63621@andrius.org> Message-ID: The other thing is, it is pretty much useless to measure connectivity speed, or path through the gfw from a colo box when your users in the mainland are using broadband or maybe dedicated leased lines. On Nov 11, 2014 10:37 PM, "Grant Ridder" wrote: > You can try AWS China, but I think you need an ICP license for that. > > -Grant > > On Tue, Nov 11, 2014 at 8:27 AM, Andrius Kasparavicius < > andrius at andrius.org> > wrote: > > > Business needs some permanent basic browser/tcp/ip view from *inside > China > > great firewall* (Hong Kong or unfirewalled locations not good) for > > connectivity testing, troubleshooting for customers in China. Ideally > just > > a dedicated windows box/server. Are there any simple providers with > > self-provisioning VPS or similar low cost solutions. Best to have it on > > ChinaTel network. No hosting or content would be shared from this box. > > Thanks > > > From Lee at asgard.org Wed Nov 12 02:02:37 2014 From: Lee at asgard.org (Lee Howard) Date: Tue, 11 Nov 2014 16:02:37 -1000 Subject: IPv6 Operations Message-ID: As a co-chair of the IETF v6ops Working Group, I thought I'd share my notes about yesterday's meeting with you, as actual operators, and ask for more input. Deprecating 6to4 Brian Carpenter discussed draft-ietf-v6ops-6to4-to-historic , specifically questions about whether to deprecate it completely, or just the version based on RFC3068 (which relies on anycast relays), and leave RFC3056 (useful for peer-to-peer kinds of connections) alone. That was the consensus. Relatedly, there was consensus to recommend filtering the anycast prefix 192.88.99.0/24, but not the related IPv6 version. Data Center Translation: SIIT-DC Tore Anderson presented (remotely‹very cool) his idea for statelessly translating from the IPv4 Internet to an IPv6-only data center. There was clear consensus that we should continue working on this as a working group, although it needs a better name, and Tore is looking for co-authors. If you have data center expertise and have ever wanted your name on an RFC, this is your chance. Read draft-anderson-v6ops-siit-dc and draft-anderson-v6ops-siit-dc-2xlat and contact Tore. DHCPV6/SLAAC Interaction Bing Liu provided an update on two related documents, draft-ietf-v6ops-dhcpv6-slaac-problem and draft-liu-v6ops-dhcpv6-slaac-guidance . The discussion focussed on whether the behavior in the presence of both DHCPv6 and SLAAC is simply ambiguous (and therefore dependent on implementation) or broken. If it's ambiguous, we can clarify. If it's broken, we probably need a specification update (and, in fact, the DHC working group is working on revising rfc3315). We determined that the Problem Statement document (which may need to be renamed) should focus on behaviors in real implementations, and come back to the Guidance document later. Considerations for Using ULAs Bing also updated us on draft-ietf-v6ops-ula-usage-recommendations , but there was little discussion other than making sure it was consistent with current work in the Homenet WG. Considerations for Running Multiple IPv6 Prefixes Sheng Jiang updated us on draft-liu-v6ops-running-multiple-prefixes , but it wasn't clear how useful it will be given ongoing work in the MIF WG, and whether NAT/NPT uses were relevant. We may revisit it later, if people want further discussion. IPv6 Vulnerability Test Program in Japan Ruri Hiromi described the IPv6 vulnerability test program in Japan , and asked for more participation and support. This has the potential for being very useful work; check it out. IPv6 Extension Headers Fernando Gont detailed his ongoing work on IPv6 Extension Headers in the Real World . The authors found that packets with IPv6 EH are often dropped: € 20% drop rate for fragments € 10% drops for Destination Options € 40% drops for Hop-by-Hop options € 25% for fragmented traffic € 20-60% of drops occur at an AS other than Destination AS There was general agreement that this was bad, and he described several ramifications, including DOS vulnerabilities. Fernando said that applications relying on EH will need a fallback mechanism, but there was consensus that dropping EH packets is the problem, not the protocol design. We may work on a document providing recommendations on how to configure. This seems like a great topic for NANOG members to chime in on; do you drop packets with Extension Headers, and if so, why? Design Choices for IPv6 Networks Victor Kuarsingh presented Design Choices for IPv6 Networks , and got consensus that the title and abstract needed a tighter scope, and the document should mention a couple of other design alternatives that are documented in other internet-drafts and RFCs. This document would also greatly benefit from review from NANOG participants, as it is intended for this audience. IPv4 Literals Break in NAT64 Osamu proposed A Special Purpose TLD to resolve IPv4 Address Literal on DNS64/NAT64 environments . There was good discussion, but not consensus that this was the right solution. Considerations on IPv6-only DNS Development Linjiang Song talked about Considerations on IPv6-only DNS Development . Discussion focussed on the need for support for EDNS0, especially in Android. IPv6 Considerations for NFV Hui Deng described IPv6 Considerations for Network Function Virtualization (NFV) , which was enlightening for people like me who have not been deeply involved in OpenStack or NFV generally. There is a lot of work needed to get good IPv6 networking support. There are several other internet drafts related to OpenStack: go to https://datatracker.ietf.org/doc / and search for "openstack." If any of these topics look interesting to you, there are a couple of things you can and should do: 1. Subscribe to the v6ops mailing list: https://www.ietf.org/mailman/listinfo/v6ops 2. Read the full draft, and send comments and questions to the v6ops mailing list Please note that if you reply here, some people will see your comments: if you do not clearly intend your statements not to be IETF Contributions, they may be considered as such‹in other words, read the Note Well . I hope this summary is interesting and useful. I would really like to see more operator input to our work. Thanks, Lee From larrysheldon at cox.net Wed Nov 12 02:25:17 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 11 Nov 2014 20:25:17 -0600 Subject: Kind of sad In-Reply-To: References: Message-ID: <5462C50D.5030208@cox.net> On 11/11/2014 15:37, Ricky Beam wrote: > On Mon, 10 Nov 2014 22:43:09 -0500, Joe wrote: >> Generally speaking its best you do what your good at and this is not it. >> >> Exposing there is a window open to a gov agency is not hacking, trust >> me. I would say go back to fathering children and once you have a few >> more years under your belt feel free to join in. > > And you, sir, should consult a lawyer before publicly slinging insults. > > I'm not a lawyer, but I have worked with one in this area. What you have > post *is* evidence of a crime under the Computer and Fraud Abuse Act. > The wording of that law is horrible, but it is what it is; the bar for > of "unauthorized access" is *very* low. How you found it is irrelevant. > You connected it to it -- knowing full well you are not authorized -- > and proceeded to attempt to login, even if in jest. > > (Government agencies have zero sense of humor. And judges have next to > no understanding of technology. Merely being charged can be a career > killer.) As an ex-admin I completely--we took action for such things. My understanding is that you can get a nasty lead overdose for standing next to a car with a Slim Jim, or trying doors to houses and warehouses to see if they are locked. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From mpalmer at hezmatt.org Wed Nov 12 04:06:59 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 12 Nov 2014 15:06:59 +1100 Subject: Tech Laptop with DB9 In-Reply-To: <5461D81F.80702@megagroup.ru> References: <827EAAF0-3B70-451E-90EE-037839B7FF1C@neilson.net.nz> <5461D81F.80702@megagroup.ru> Message-ID: <20141112040659.GH3175@hezmatt.org> On Tue, Nov 11, 2014 at 12:34:23PM +0300, Stepan Kucherenko wrote: > I want to reiterate on AirConsole because it IS amazing. I don't even > grab a laptop when I go onsite anymore, just an AirConsole, its > usb-serial cable and a tablet. My, that *is* a rather snazzy piece of kit. I'm almost sad that I don't really deal with serial console kit any more. *Almost*. - Matt -- Debian is geared towards building long-term stable systems; this really only comes at the expense of newbie user-friendliness. It's the same reason that building a treehouse is easy, but building a steel-reinforced-concrete bunker is hard. -- Don Werve From lobna_gouda at hotmail.com Wed Nov 12 00:54:47 2014 From: lobna_gouda at hotmail.com (lobna gouda) Date: Wed, 12 Nov 2014 00:54:47 +0000 Subject: cheap laptop with 32G or 64G recommendations In-Reply-To: <54626DD5.2090701@gmail.com> References: , , , <54626DD5.2090701@gmail.com> Message-ID: Thanks all for your reply, lenovo seems decent almost all the pc ( lenovo and hp) are decent with the 16G.somebody mentioned with 16g it is a bit slow; Keith here is saying the 32G he had no issue. i intend to buy my own memory just to save on the costi agree 64 will be sky expensive and cloud will do, then.By the way W530 is replaced by W540, donot see much benefit for my case. Brgds, Lobna Gouda > Date: Tue, 11 Nov 2014 12:13:09 -0800 > From: blakangel at gmail.com > To: nanog at nanog.org > Subject: Re: cheap laptop with 32G or 64G recommendations > > I have an almost two-year old Lenovo W530 with 32G ram. I've been happy > with it. I don't find myself taking advantage of the ram (w/ VMWare > Workstation) as much as I thought I would. > > http://shop.lenovo.com/us/en/laptops/thinkpad/w-series/w530/ > > -Keith > > Darden, Patrick wrote: > > If there is a cheap quad-core laptop with 64GB of ram and no huge downsides... then sign me up! I expect that will be the standard in 5 years, but right now that is a hoss. > > > > Izaac's suggestion of using the cloud is good, if you can do it. Cloud services have come a long way--fast and easy to set up complex environments. Great article comparing performance and costs: > > > > http://www.infoworld.com/article/2610403/cloud-computing/ultimate-cloud-speed-tests--amazon-vs--google-vs--windows-azure.html > > > > --p > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Izaac > > Sent: Monday, November 10, 2014 6:25 PM > > To: NANOG > > Subject: [EXTERNAL]Re: cheap laptop with 32G or 64G recommendations > > > > On November 10, 2014 4:49:08 PM EST, lobna gouda wrote: > >> Hello, > >> Any recommendation, not looking for anything fantasy, my understanding > >> it should be quardcore, with more than DIMM0 slot so each can have 8G. > >> wind7-64bits to work. I want to use it as a server or practice logical > >> routers > > > > "Cheap" and "64GiB of RAM" are incompatible concepts in laptops. > > > > There is no earthly reason you should need to carry a machine like that anyway. If for some reason you need something so equipped, get yourself a cloud instance and connect to it. That's how you save money. > > > > If you're stuck working in a completely isolated environment, then work it into the contract. That's the cost of being on an island. > > > > -- > > Izaac > From davejodhan at gmail.com Tue Nov 11 15:14:41 2014 From: davejodhan at gmail.com (Dave Jodhan) Date: Tue, 11 Nov 2014 10:14:41 -0500 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: Many of these subscription based courses do not include a Cisco IOS simulator. That's a Cisco IOS licensing hot potato that's generally more trouble than value added to the course. Not to mention having to build and maintain it. For a CCNA level lab, the equipment is cheap off E-Bay, 2 x 2950's 2 x 1841's approx $300 If your really really looking to cut costs and are dead set on a simulator here are some of your options: You can look into GNS3 , however you will have to provide your own IOS images. It's the de-facto standard for router emulation all non-Cisco Network Academy students. Switching functionality has recently been added, but I haven't tried it , so can't vouch for it's usefulness. Or you can purchase the Boson network simulator. Cisco has one of their own that is provided to their Network Academy students, which of course, requires that you enroll in a Cisco Network Academy program. (at a participating learning center ) Worth it, the 4 or so semesters usually covers more than just the exam objectives. On Tue, Nov 11, 2014 at 9:59 AM, Colton Conor wrote: > Does CBT or any of these other subscription based learning courses include > a Cisco IOS simulator so we don't have to buy a Cisco lab or equipment? > > On Sun, Nov 2, 2014 at 7:36 PM, Scott Morris wrote: > > > Depends on how quickly you want them trained, and how they tend to learn > > thingsŠ > > > > Reading is good, but can be boring and tedious and not always have all > the > > answers. > > Standard ILT can be costly, but very quick and often standard (though I¹d > > shop around for who you have as an instructor since that can make or > break > > the success)! > > Video-based training gives a good mix of things and there are options out > > there. I know there¹s been one other response for CBT Nuggets, which I > > would definitely recommend. > > > > Take that with a grain of salt (and I¹m ok with that) since I do some > work > > for them now. However, I would have recommended them even before I > > started developing training for them. :) > > > > Jeremy Cioara teaches the CCNA courses for CBT, and he is quite animated > > and very knowledgeable. He will definitely get all the necessary points > > across. In addition to the certification courses you mentioned, there > are > > also many ³real world² variants of materials as well, which give a > > different slant to the teachings that you may find useful for your group. > > > > And being a subscription cost, you can watch as many different things as > > you¹d like rather than being limited to one course. Something worth > > checking out. Don¹t take my word for it, go look for yourself (or have > > your group do that). > > > > Cheers, > > > > Scott > > > > -----Original Message----- > > From: Colton Conor > > Date: Sunday, November 2, 2014 at 1:02 PM > > To: NANOG > > Subject: Cisco CCNA Training > > > > >We have a couple of techs that want to learn cisco and networking in > > >general. What do you recommend for learning and getting certified on > > >Cisco? > > >There seems to be a million different training courses, books, etc out > > >there. > > > > > > > From g at 1337.io Wed Nov 12 07:56:02 2014 From: g at 1337.io (g at 1337.io) Date: Tue, 11 Nov 2014 23:56:02 -0800 Subject: Tech Laptop with DB9 In-Reply-To: References: Message-ID: <54631292.1000302@1337.io> My CF-19 does the trick quite nicely On 11/10/14 12:39 PM, Max Clark wrote: > Hi all, > > DB9 ports seem to be a nearly extinct feature on laptops. Any > suggestions on a cheap laptop for use in field support (with an onboard > DB9)? > > Thanks, > Max > > From me at geordish.org Wed Nov 12 11:22:02 2014 From: me at geordish.org (Dave Bell) Date: Wed, 12 Nov 2014 11:22:02 +0000 Subject: Cisco CCNA Training In-Reply-To: References: Message-ID: The CSR1000v (http://www.cisco.com/c/en/us/products/routers/cloud-services-router-1000v-series/index.html) runs on normal VM infrastructure, and will do (almost?) everything required from a routing perspective to pass everything up to the CCIE R&S. It requires a license to use it for proper traffic loads, but is free to use for lab purposes. More info on how this can be done under VMWare can be found here: http://www.rogerperkin.co.uk/ccie/index.php/ccie-version-5/ccie-virtual-rack-csr-1000v-routers/ On 11 November 2014 15:14, Dave Jodhan wrote: > Many of these subscription based courses do not include a Cisco IOS > simulator. > That's a Cisco IOS licensing hot potato that's generally more trouble than > value added to the course. > Not to mention having to build and maintain it. > For a CCNA level lab, the equipment is cheap off E-Bay, > 2 x 2950's > 2 x 1841's > approx $300 > > If your really really looking to cut costs and are dead set on a simulator > here are some of your options: > You can look into GNS3 , however you will have to provide your own IOS > images. > It's the de-facto standard for router emulation all non-Cisco Network > Academy students. > Switching functionality has recently been added, but I haven't tried it , > so can't vouch for it's usefulness. > > Or you can purchase the Boson network simulator. > > Cisco has one of their own that is provided to their Network Academy > students, which of course, requires that you enroll in a Cisco Network > Academy program. (at a participating learning center ) > Worth it, the 4 or so semesters usually covers more than just the exam > objectives. > > > On Tue, Nov 11, 2014 at 9:59 AM, Colton Conor > wrote: > >> Does CBT or any of these other subscription based learning courses include >> a Cisco IOS simulator so we don't have to buy a Cisco lab or equipment? >> >> On Sun, Nov 2, 2014 at 7:36 PM, Scott Morris wrote: >> >> > Depends on how quickly you want them trained, and how they tend to learn >> > thingsŠ >> > >> > Reading is good, but can be boring and tedious and not always have all >> the >> > answers. >> > Standard ILT can be costly, but very quick and often standard (though I¹d >> > shop around for who you have as an instructor since that can make or >> break >> > the success)! >> > Video-based training gives a good mix of things and there are options out >> > there. I know there¹s been one other response for CBT Nuggets, which I >> > would definitely recommend. >> > >> > Take that with a grain of salt (and I¹m ok with that) since I do some >> work >> > for them now. However, I would have recommended them even before I >> > started developing training for them. :) >> > >> > Jeremy Cioara teaches the CCNA courses for CBT, and he is quite animated >> > and very knowledgeable. He will definitely get all the necessary points >> > across. In addition to the certification courses you mentioned, there >> are >> > also many ³real world² variants of materials as well, which give a >> > different slant to the teachings that you may find useful for your group. >> > >> > And being a subscription cost, you can watch as many different things as >> > you¹d like rather than being limited to one course. Something worth >> > checking out. Don¹t take my word for it, go look for yourself (or have >> > your group do that). >> > >> > Cheers, >> > >> > Scott >> > >> > -----Original Message----- >> > From: Colton Conor >> > Date: Sunday, November 2, 2014 at 1:02 PM >> > To: NANOG >> > Subject: Cisco CCNA Training >> > >> > >We have a couple of techs that want to learn cisco and networking in >> > >general. What do you recommend for learning and getting certified on >> > >Cisco? >> > >There seems to be a million different training courses, books, etc out >> > >there. >> > >> > >> > >> From Joshua_Sholes at cable.comcast.com Wed Nov 12 15:27:13 2014 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Wed, 12 Nov 2014 15:27:13 +0000 Subject: Kind of sad In-Reply-To: <5462C50D.5030208@cox.net> References: <5462C50D.5030208@cox.net> Message-ID: On 11/11/14, 9:25 PM, "Larry Sheldon" wrote: >On 11/11/2014 15:37, Ricky Beam wrote: >> On Mon, 10 Nov 2014 22:43:09 -0500, Joe wrote: >>> Generally speaking its best you do what your good at and this is not >>>it. >>> >>> Exposing there is a window open to a gov agency is not hacking, trust >>> me. I would say go back to fathering children and once you have a few >>> more years under your belt feel free to join in. >> >> And you, sir, should consult a lawyer before publicly slinging insults. >> >> I'm not a lawyer, but I have worked with one in this area. What you have >> post *is* evidence of a crime under the Computer and Fraud Abuse Act. >> The wording of that law is horrible, but it is what it is; the bar for >> of "unauthorized access" is *very* low. How you found it is irrelevant. >> You connected it to it -- knowing full well you are not authorized -- >> and proceeded to attempt to login, even if in jest. >> >> (Government agencies have zero sense of humor. And judges have next to >> no understanding of technology. Merely being charged can be a career >> killer.) > >As an ex-admin I completely--we took action for such things. I concur. I was recently an admin/ITSO for a defense contractor, and from a network logging standpoint it is VERY difficult to tell the difference between what you posted and a really subtle social-engineering-enabled attack--and EVERY attacker these days has to be assumed to be subtle. --Josh From streiner at cluebyfour.org Wed Nov 12 15:57:59 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 12 Nov 2014 10:57:59 -0500 (EST) Subject: Kind of sad In-Reply-To: References: <5462C50D.5030208@cox.net> Message-ID: On Wed, 12 Nov 2014, Sholes, Joshua wrote: > I concur. I was recently an admin/ITSO for a defense contractor, and > from a network logging standpoint it is VERY difficult to tell the > difference between what you posted and a really subtle > social-engineering-enabled attack--and EVERY attacker these days has to be > assumed to be subtle. Agree completely. While the OP's intentions might be honorable, even if he notified the organization directly, they might not react the way he would want: "Thank you for bringing this to our attention! We will get it fixed immediately." I am not a lawyer, but I would strongly advise against randomly logging into hosts on a network where I don't have a formal business relationship that includes explicit authorization to do pen-testing and other [insert-color-here]-hat activities. Being a good Samaritan and the current state of computer crime laws do not always line up very nicely with each other. Bottom line: Tread carefully. jms From mark at bernoullinetworks.com Wed Nov 12 16:39:35 2014 From: mark at bernoullinetworks.com (Mark Leonard) Date: Wed, 12 Nov 2014 09:39:35 -0700 Subject: Cisco CCNA Training In-Reply-To: <54622648.8000702@winterei.se> References: <54622648.8000702@winterei.se> Message-ID: YYC Net Lab (of which I am a co-founder) went through the trouble of forming a not-for-profit company and gaining access to Cisco's official Network Academy content. The process is a little painful to setup, but you get access to all the content including Packet Tracer. I still use GNS3 because not all functionality is present in Packet Tracer. If you're just looking for CCNA material, Packet Tracer is enough to get you your cert. If anyone is interested in learning more about the process to get access to NetAcad content, feel free to contact me off list. On Tue, Nov 11, 2014 at 8:07 AM, Paul S. wrote: > GNS3, while unofficial, is what I'd recommend for that. > > On 11/11/2014 午後 11:59, Colton Conor wrote: > >> Does CBT or any of these other subscription based learning courses include >> a Cisco IOS simulator so we don't have to buy a Cisco lab or equipment? >> >> On Sun, Nov 2, 2014 at 7:36 PM, Scott Morris wrote: >> >> Depends on how quickly you want them trained, and how they tend to learn >>> thingsŠ >>> >>> Reading is good, but can be boring and tedious and not always have all >>> the >>> answers. >>> Standard ILT can be costly, but very quick and often standard (though I¹d >>> shop around for who you have as an instructor since that can make or >>> break >>> the success)! >>> Video-based training gives a good mix of things and there are options out >>> there. I know there¹s been one other response for CBT Nuggets, which I >>> would definitely recommend. >>> >>> Take that with a grain of salt (and I¹m ok with that) since I do some >>> work >>> for them now. However, I would have recommended them even before I >>> started developing training for them. :) >>> >>> Jeremy Cioara teaches the CCNA courses for CBT, and he is quite animated >>> and very knowledgeable. He will definitely get all the necessary points >>> across. In addition to the certification courses you mentioned, there >>> are >>> also many ³real world² variants of materials as well, which give a >>> different slant to the teachings that you may find useful for your group. >>> >>> And being a subscription cost, you can watch as many different things as >>> you¹d like rather than being limited to one course. Something worth >>> checking out. Don¹t take my word for it, go look for yourself (or have >>> your group do that). >>> >>> Cheers, >>> >>> Scott >>> >>> -----Original Message----- >>> From: Colton Conor >>> Date: Sunday, November 2, 2014 at 1:02 PM >>> To: NANOG >>> Subject: Cisco CCNA Training >>> >>> We have a couple of techs that want to learn cisco and networking in >>>> general. What do you recommend for learning and getting certified on >>>> Cisco? >>>> There seems to be a million different training courses, books, etc out >>>> there. >>>> >>> >>> >>> > From randy at psg.com Wed Nov 12 18:17:30 2014 From: randy at psg.com (Randy Bush) Date: Wed, 12 Nov 2014 08:17:30 -1000 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: References: <5460C679.5090005@winterei.se> <9003.1415726822@turing-police.cc.vt.edu> Message-ID: >> I hear the chaps at Hurricane Electric can help you with a nice >> tunnel for that... > yea.. because when the sh*t hits the fan I REALLY need a dependency > upon a wonky tunnel server made of cheese and mouse parts to be in the > middle of my work process? wait a sec! there's cheese? where? randy, who may have to rethink tunnels From jschiel at flowtools.net Wed Nov 12 19:33:46 2014 From: jschiel at flowtools.net (John Schiel) Date: Wed, 12 Nov 2014 12:33:46 -0700 Subject: cheap laptop with 32G or 64G recommendations In-Reply-To: References: , , , <54626DD5.2090701@gmail.com> Message-ID: <5463B61A.6020100@flowtools.net> On 11/11/2014 05:54 PM, lobna gouda wrote: > Thanks all for your reply, lenovo seems decent almost all the pc ( lenovo and hp) are decent with the 16G.somebody mentioned with 16g it is a bit slow; Keith here is saying the 32G he had no issue. i intend to buy my own memory just to save on the costi agree 64 will be sky expensive and cloud will do, then.By the way W530 is replaced by W540, donot see much benefit for my case. Be careful with Lenovo, some folks think it has a bad security reputation. Why? *shrug*, not sure but maybe because it's a Chinese company with ties to the PRC and IIRC, there was a BIOS flaw. --John > Brgds, > Lobna Gouda >> Date: Tue, 11 Nov 2014 12:13:09 -0800 >> From: blakangel at gmail.com >> To: nanog at nanog.org >> Subject: Re: cheap laptop with 32G or 64G recommendations >> >> I have an almost two-year old Lenovo W530 with 32G ram. I've been happy >> with it. I don't find myself taking advantage of the ram (w/ VMWare >> Workstation) as much as I thought I would. >> >> http://shop.lenovo.com/us/en/laptops/thinkpad/w-series/w530/ >> >> -Keith >> >> Darden, Patrick wrote: >>> If there is a cheap quad-core laptop with 64GB of ram and no huge downsides... then sign me up! I expect that will be the standard in 5 years, but right now that is a hoss. >>> >>> Izaac's suggestion of using the cloud is good, if you can do it. Cloud services have come a long way--fast and easy to set up complex environments. Great article comparing performance and costs: >>> >>> http://www.infoworld.com/article/2610403/cloud-computing/ultimate-cloud-speed-tests--amazon-vs--google-vs--windows-azure.html >>> >>> --p >>> >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Izaac >>> Sent: Monday, November 10, 2014 6:25 PM >>> To: NANOG >>> Subject: [EXTERNAL]Re: cheap laptop with 32G or 64G recommendations >>> >>> On November 10, 2014 4:49:08 PM EST, lobna gouda wrote: >>>> Hello, >>>> Any recommendation, not looking for anything fantasy, my understanding >>>> it should be quardcore, with more than DIMM0 slot so each can have 8G. >>>> wind7-64bits to work. I want to use it as a server or practice logical >>>> routers >>> "Cheap" and "64GiB of RAM" are incompatible concepts in laptops. >>> >>> There is no earthly reason you should need to carry a machine like that anyway. If for some reason you need something so equipped, get yourself a cloud instance and connect to it. That's how you save money. >>> >>> If you're stuck working in a completely isolated environment, then work it into the contract. That's the cost of being on an island. >>> >>> -- >>> Izaac > From morrowc.lists at gmail.com Wed Nov 12 19:49:28 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 12 Nov 2014 14:49:28 -0500 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: References: <5460C679.5090005@winterei.se> <9003.1415726822@turing-police.cc.vt.edu> Message-ID: On Wed, Nov 12, 2014 at 1:17 PM, Randy Bush wrote: >>> I hear the chaps at Hurricane Electric can help you with a nice >>> tunnel for that... >> yea.. because when the sh*t hits the fan I REALLY need a dependency >> upon a wonky tunnel server made of cheese and mouse parts to be in the >> middle of my work process? > > wait a sec! there's cheese? where? I understand that it is ashburn equinix. > randy, who may have to rethink tunnels :) From dougb at dougbarton.us Wed Nov 12 19:50:51 2014 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 12 Nov 2014 11:50:51 -0800 Subject: Equinix Virginia - Ethernet OOB suggestions In-Reply-To: References: <5460C679.5090005@winterei.se> <9003.1415726822@turing-police.cc.vt.edu> Message-ID: <5463BA1B.8000300@dougbarton.us> On 11/12/14 11:49 AM, Christopher Morrow wrote: > On Wed, Nov 12, 2014 at 1:17 PM, Randy Bush wrote: >>>> I hear the chaps at Hurricane Electric can help you with a nice >>>> tunnel for that... >>> yea.. because when the sh*t hits the fan I REALLY need a dependency >>> upon a wonky tunnel server made of cheese and mouse parts to be in the >>> middle of my work process? >> >> wait a sec! there's cheese? where? > > I understand that it is ashburn equinix. > >> randy, who may have to rethink tunnels > > :) cheese++ From baconzombie at gmail.com Wed Nov 12 20:59:20 2014 From: baconzombie at gmail.com (Bacon Zombie) Date: Wed, 12 Nov 2014 21:59:20 +0100 Subject: cheap laptop with 32G or 64G recommendations In-Reply-To: <5463B61A.6020100@flowtools.net> References: <54626DD5.2090701@gmail.com> <5463B61A.6020100@flowtools.net> Message-ID: I'd say 60% of laptops at security conferences I've been to are Lenovo, 30% Apple and 10% Dell/other. On 12 Nov 2014 20:35, "John Schiel" wrote: > > On 11/11/2014 05:54 PM, lobna gouda wrote: > >> Thanks all for your reply, lenovo seems decent almost all the pc ( lenovo >> and hp) are decent with the 16G.somebody mentioned with 16g it is a bit >> slow; Keith here is saying the 32G he had no issue. i intend to buy my own >> memory just to save on the costi agree 64 will be sky expensive and cloud >> will do, then.By the way W530 is replaced by W540, donot see much benefit >> for my case. >> > > Be careful with Lenovo, some folks think it has a bad security reputation. > Why? *shrug*, not sure but maybe because it's a Chinese company with ties > to the PRC and IIRC, there was a BIOS flaw. > > --John > > Brgds, >> Lobna Gouda >> >>> Date: Tue, 11 Nov 2014 12:13:09 -0800 >>> From: blakangel at gmail.com >>> To: nanog at nanog.org >>> Subject: Re: cheap laptop with 32G or 64G recommendations >>> >>> I have an almost two-year old Lenovo W530 with 32G ram. I've been happy >>> with it. I don't find myself taking advantage of the ram (w/ VMWare >>> Workstation) as much as I thought I would. >>> >>> http://shop.lenovo.com/us/en/laptops/thinkpad/w-series/w530/ >>> >>> -Keith >>> >>> Darden, Patrick wrote: >>> >>>> If there is a cheap quad-core laptop with 64GB of ram and no huge >>>> downsides... then sign me up! I expect that will be the standard in 5 >>>> years, but right now that is a hoss. >>>> >>>> Izaac's suggestion of using the cloud is good, if you can do it. Cloud >>>> services have come a long way--fast and easy to set up complex >>>> environments. Great article comparing performance and costs: >>>> >>>> http://www.infoworld.com/article/2610403/cloud- >>>> computing/ultimate-cloud-speed-tests--amazon-vs-- >>>> google-vs--windows-azure.html >>>> >>>> --p >>>> >>>> >>>> -----Original Message----- >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Izaac >>>> Sent: Monday, November 10, 2014 6:25 PM >>>> To: NANOG >>>> Subject: [EXTERNAL]Re: cheap laptop with 32G or 64G recommendations >>>> >>>> On November 10, 2014 4:49:08 PM EST, lobna gouda < >>>> lobna_gouda at hotmail.com> wrote: >>>> >>>>> Hello, >>>>> Any recommendation, not looking for anything fantasy, my understanding >>>>> it should be quardcore, with more than DIMM0 slot so each can have 8G. >>>>> wind7-64bits to work. I want to use it as a server or practice logical >>>>> routers >>>>> >>>> "Cheap" and "64GiB of RAM" are incompatible concepts in laptops. >>>> >>>> There is no earthly reason you should need to carry a machine like that >>>> anyway. If for some reason you need something so equipped, get yourself a >>>> cloud instance and connect to it. That's how you save money. >>>> >>>> If you're stuck working in a completely isolated environment, then work >>>> it into the contract. That's the cost of being on an island. >>>> >>>> -- >>>> Izaac >>>> >>> >> > > From james at freedomnet.co.nz Wed Nov 12 21:16:45 2014 From: james at freedomnet.co.nz (james jones) Date: Wed, 12 Nov 2014 16:16:45 -0500 Subject: Zayo opinions Message-ID: I am current going through some vendor selection for tier 1 providers. I was trying get some opinions on Zayo. I have personally never heard of them. Thoughts? From joelja at bogus.com Wed Nov 12 21:23:20 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 12 Nov 2014 11:23:20 -1000 Subject: Zayo opinions In-Reply-To: References: Message-ID: <5463CFC8.4070400@bogus.com> On 11/12/14 11:16 AM, james jones wrote: > I am current going through some vendor selection for tier 1 providers. I > was trying get some opinions on Zayo. I have personally never heard of > them. Thoughts? Think abovenet... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From jof at thejof.com Wed Nov 12 21:30:50 2014 From: jof at thejof.com (Jonathan Lassoff) Date: Wed, 12 Nov 2014 13:30:50 -0800 Subject: Zayo opinions In-Reply-To: References: Message-ID: Zayo owns what used to be Abovenet. In my experience, your experience will vary from market to market, depending on the network you're based on. As of late, we've had repeated capacity issues and packet loss in the San Francisco Bay Area, however other metros have been perfectly stable. On Wed, Nov 12, 2014 at 1:16 PM, james jones wrote: > I am current going through some vendor selection for tier 1 providers. I > was trying get some opinions on Zayo. I have personally never heard of > them. Thoughts? > From josh at 2cold.net Wed Nov 12 21:31:22 2014 From: josh at 2cold.net (Joshua McDonald) Date: Wed, 12 Nov 2014 16:31:22 -0500 Subject: Zayo opinions In-Reply-To: <5463CFC8.4070400@bogus.com> References: <5463CFC8.4070400@bogus.com> Message-ID: <0852EAF1-ECA3-49F4-B9BB-899F693C2097@2cold.net> I have a 10Gig to Abovenet and have not been really impressed. It was a royal pain to get turned up, as their fiber docs didn’t seem to exist. Have had issues using it to access AWS and EC2. Pushing the traffic back to Level3 or XO seems to resolve the problem. Trouble tickets seem to be filed in the circular file. Josh > On Nov 12, 2014, at 4:23 PM, joel jaeggli wrote: > > On 11/12/14 11:16 AM, james jones wrote: >> I am current going through some vendor selection for tier 1 providers. I >> was trying get some opinions on Zayo. I have personally never heard of >> them. Thoughts? > > Think abovenet... > > From ryan at deadfrog.net Wed Nov 12 21:33:08 2014 From: ryan at deadfrog.net (Ryan Wilkins) Date: Wed, 12 Nov 2014 16:33:08 -0500 Subject: Zayo opinions In-Reply-To: References: Message-ID: I don’t know the history on Zayo but they acquired Abovenet of which I’m a customer. Quite frankly, I haven’t been impressed. The support went to shit. The last two tickets that I’ve opened with them have had mixed results. The first ticket they called me back 5 days after opening a ticket for a DDoS block request and the second they never called back for another DDoS block request. Next time I call them I’m going to demand to speak with someone immediately. Otherwise, the network seems to be fine. Ryan > On Nov 12, 2014, at 4:16 PM, james jones wrote: > > I am current going through some vendor selection for tier 1 providers. I > was trying get some opinions on Zayo. I have personally never heard of > them. Thoughts? From drohan at gmail.com Wed Nov 12 22:08:52 2014 From: drohan at gmail.com (Daniel Rohan) Date: Wed, 12 Nov 2014 14:08:52 -0800 Subject: Zayo opinions In-Reply-To: References: Message-ID: We've leased several 10G circuits from them and they perform adequately and NOC has been responsive. Pacific Northwest Region. -Dan On Wed, Nov 12, 2014 at 1:33 PM, Ryan Wilkins wrote: > I don’t know the history on Zayo but they acquired Abovenet of which I’m a > customer. > > Quite frankly, I haven’t been impressed. The support went to shit. The > last two tickets that I’ve opened with them have had mixed results. The > first ticket they called me back 5 days after opening a ticket for a DDoS > block request and the second they never called back for another DDoS block > request. Next time I call them I’m going to demand to speak with someone > immediately. > > Otherwise, the network seems to be fine. > > Ryan > > > > On Nov 12, 2014, at 4:16 PM, james jones wrote: > > > > I am current going through some vendor selection for tier 1 providers. I > > was trying get some opinions on Zayo. I have personally never heard of > > them. Thoughts? > > From ryan.landry at gmail.com Wed Nov 12 22:15:32 2014 From: ryan.landry at gmail.com (ryanL) Date: Wed, 12 Nov 2014 17:15:32 -0500 Subject: Zayo opinions In-Reply-To: References: Message-ID: when zayo acquired abovenet, we shortly thereafter terminated transit with them for various unsatisfactory reasons. abovenet was great. miss them. On Wed, Nov 12, 2014 at 5:08 PM, Daniel Rohan wrote: > We've leased several 10G circuits from them and they perform adequately and > NOC has been responsive. Pacific Northwest Region. > > -Dan > > On Wed, Nov 12, 2014 at 1:33 PM, Ryan Wilkins wrote: > > > I don’t know the history on Zayo but they acquired Abovenet of which I’m > a > > customer. > > > > Quite frankly, I haven’t been impressed. The support went to shit. The > > last two tickets that I’ve opened with them have had mixed results. The > > first ticket they called me back 5 days after opening a ticket for a DDoS > > block request and the second they never called back for another DDoS > block > > request. Next time I call them I’m going to demand to speak with someone > > immediately. > > > > Otherwise, the network seems to be fine. > > > > Ryan > > > > > > > On Nov 12, 2014, at 4:16 PM, james jones > wrote: > > > > > > I am current going through some vendor selection for tier 1 providers. > I > > > was trying get some opinions on Zayo. I have personally never heard of > > > them. Thoughts? > > > > > From lobna_gouda at hotmail.com Wed Nov 12 22:51:50 2014 From: lobna_gouda at hotmail.com (lobna gouda) Date: Wed, 12 Nov 2014 22:51:50 +0000 Subject: cheap laptop with 32G or 64G recommendations In-Reply-To: References: , , , <54626DD5.2090701@gmail.com>, , <5463B61A.6020100@flowtools.net>, Message-ID: lenovo not a must , I am looking for the cheapest, I am even looking in ebay Brgds, Lobna Gouda > Date: Wed, 12 Nov 2014 21:59:20 +0100 > Subject: Re: cheap laptop with 32G or 64G recommendations > From: baconzombie at gmail.com > To: jschiel at flowtools.net > CC: nanog at nanog.org > > I'd say 60% of laptops at security conferences I've been to are Lenovo, 30% > Apple and 10% Dell/other. > On 12 Nov 2014 20:35, "John Schiel" wrote: > > > > > On 11/11/2014 05:54 PM, lobna gouda wrote: > > > >> Thanks all for your reply, lenovo seems decent almost all the pc ( lenovo > >> and hp) are decent with the 16G.somebody mentioned with 16g it is a bit > >> slow; Keith here is saying the 32G he had no issue. i intend to buy my own > >> memory just to save on the costi agree 64 will be sky expensive and cloud > >> will do, then.By the way W530 is replaced by W540, donot see much benefit > >> for my case. > >> > > > > Be careful with Lenovo, some folks think it has a bad security reputation. > > Why? *shrug*, not sure but maybe because it's a Chinese company with ties > > to the PRC and IIRC, there was a BIOS flaw. > > > > --John > > > > Brgds, > >> Lobna Gouda > >> > >>> Date: Tue, 11 Nov 2014 12:13:09 -0800 > >>> From: blakangel at gmail.com > >>> To: nanog at nanog.org > >>> Subject: Re: cheap laptop with 32G or 64G recommendations > >>> > >>> I have an almost two-year old Lenovo W530 with 32G ram. I've been happy > >>> with it. I don't find myself taking advantage of the ram (w/ VMWare > >>> Workstation) as much as I thought I would. > >>> > >>> http://shop.lenovo.com/us/en/laptops/thinkpad/w-series/w530/ > >>> > >>> -Keith > >>> > >>> Darden, Patrick wrote: > >>> > >>>> If there is a cheap quad-core laptop with 64GB of ram and no huge > >>>> downsides... then sign me up! I expect that will be the standard in 5 > >>>> years, but right now that is a hoss. > >>>> > >>>> Izaac's suggestion of using the cloud is good, if you can do it. Cloud > >>>> services have come a long way--fast and easy to set up complex > >>>> environments. Great article comparing performance and costs: > >>>> > >>>> http://www.infoworld.com/article/2610403/cloud- > >>>> computing/ultimate-cloud-speed-tests--amazon-vs-- > >>>> google-vs--windows-azure.html > >>>> > >>>> --p > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Izaac > >>>> Sent: Monday, November 10, 2014 6:25 PM > >>>> To: NANOG > >>>> Subject: [EXTERNAL]Re: cheap laptop with 32G or 64G recommendations > >>>> > >>>> On November 10, 2014 4:49:08 PM EST, lobna gouda < > >>>> lobna_gouda at hotmail.com> wrote: > >>>> > >>>>> Hello, > >>>>> Any recommendation, not looking for anything fantasy, my understanding > >>>>> it should be quardcore, with more than DIMM0 slot so each can have 8G. > >>>>> wind7-64bits to work. I want to use it as a server or practice logical > >>>>> routers > >>>>> > >>>> "Cheap" and "64GiB of RAM" are incompatible concepts in laptops. > >>>> > >>>> There is no earthly reason you should need to carry a machine like that > >>>> anyway. If for some reason you need something so equipped, get yourself a > >>>> cloud instance and connect to it. That's how you save money. > >>>> > >>>> If you're stuck working in a completely isolated environment, then work > >>>> it into the contract. That's the cost of being on an island. > >>>> > >>>> -- > >>>> Izaac > >>>> > >>> > >> > > > > From cnielsen at pobox.com Wed Nov 12 23:22:09 2014 From: cnielsen at pobox.com (Christopher Nielsen) Date: Wed, 12 Nov 2014 15:22:09 -0800 Subject: Zayo opinions In-Reply-To: References: Message-ID: We had circuits with Abovenet in San Jose and Ashburn when Zayo bought them. Abovenet was very responsive, and their IP folks showed some expertise. Since Zayo acquired them, the quality and responsiveness has decreased significantly. We've not experienced any packet loss, but the quality of customer service has declined significantly. On Wed, Nov 12, 2014 at 1:16 PM, james jones wrote: > I am current going through some vendor selection for tier 1 providers. I > was trying get some opinions on Zayo. I have personally never heard of > them. Thoughts? -- Christopher Nielsen "They who can give up essential liberty for temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "The tree of liberty must be refreshed from time to time with the blood of patriots & tyrants." --Thomas Jefferson From jschiel at flowtools.net Wed Nov 12 23:32:23 2014 From: jschiel at flowtools.net (John Schiel) Date: Wed, 12 Nov 2014 16:32:23 -0700 Subject: cheap laptop with 32G or 64G recommendations In-Reply-To: References: <54626DD5.2090701@gmail.com> <5463B61A.6020100@flowtools.net> Message-ID: <5463EE07.2090104@flowtools.net> On 11/12/2014 01:59 PM, Bacon Zombie wrote: Bacon and Zombies, 2 of my favorite things !!! > I'd say 60% of laptops at security conferences I've been to are > Lenovo, 30% Apple and 10% Dell/other. > Not advocating either way just bringing up the nugget of info that I'm aware of. --John > On 12 Nov 2014 20:35, "John Schiel" > wrote: > > > On 11/11/2014 05:54 PM, lobna gouda wrote: > > Thanks all for your reply, lenovo seems decent almost all the > pc ( lenovo and hp) are decent with the 16G.somebody mentioned > with 16g it is a bit slow; Keith here is saying the 32G he had > no issue. i intend to buy my own memory just to save on the > costi agree 64 will be sky expensive and cloud will do, > then.By the way W530 is replaced by W540, donot see much > benefit for my case. > > > Be careful with Lenovo, some folks think it has a bad security > reputation. Why? *shrug*, not sure but maybe because it's a > Chinese company with ties to the PRC and IIRC, there was a BIOS flaw. > > --John > > Brgds, > Lobna Gouda > > Date: Tue, 11 Nov 2014 12:13:09 -0800 > From: blakangel at gmail.com > To: nanog at nanog.org > Subject: Re: cheap laptop with 32G or 64G recommendations > > I have an almost two-year old Lenovo W530 with 32G ram. > I've been happy > with it. I don't find myself taking advantage of the ram > (w/ VMWare > Workstation) as much as I thought I would. > > http://shop.lenovo.com/us/en/laptops/thinkpad/w-series/w530/ > > -Keith > > Darden, Patrick wrote: > > If there is a cheap quad-core laptop with 64GB of ram > and no huge downsides... then sign me up! I expect > that will be the standard in 5 years, but right now > that is a hoss. > > Izaac's suggestion of using the cloud is good, if you > can do it. Cloud services have come a long way--fast > and easy to set up complex environments. Great > article comparing performance and costs: > > http://www.infoworld.com/article/2610403/cloud-computing/ultimate-cloud-speed-tests--amazon-vs--google-vs--windows-azure.html > > --p > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org > ] On Behalf Of Izaac > Sent: Monday, November 10, 2014 6:25 PM > To: NANOG > Subject: [EXTERNAL]Re: cheap laptop with 32G or 64G > recommendations > > On November 10, 2014 4:49:08 PM EST, lobna gouda > > wrote: > > Hello, > Any recommendation, not looking for anything > fantasy, my understanding > it should be quardcore, with more than DIMM0 slot > so each can have 8G. > wind7-64bits to work. I want to use it as a server > or practice logical > routers > > "Cheap" and "64GiB of RAM" are incompatible concepts > in laptops. > > There is no earthly reason you should need to carry a > machine like that anyway. If for some reason you need > something so equipped, get yourself a cloud instance > and connect to it. That's how you save money. > > If you're stuck working in a completely isolated > environment, then work it into the contract. That's > the cost of being on an island. > > -- > Izaac > > > From contact at winterei.se Thu Nov 13 00:58:22 2014 From: contact at winterei.se (Paul S.) Date: Thu, 13 Nov 2014 09:58:22 +0900 Subject: Zayo opinions In-Reply-To: References: Message-ID: <5464022E.7050103@winterei.se> Agree, cuustomer service is really not upto par these days. All my other carriers do better from that standpoint, but the network performance isn't all that bad. Just pray that nothing breaks... On 11/13/2014 午前 08:22, Christopher Nielsen wrote: > We had circuits with Abovenet in San Jose and Ashburn when Zayo bought > them. Abovenet was very responsive, and their IP folks showed some > expertise. Since Zayo acquired them, the quality and responsiveness > has decreased significantly. We've not experienced any packet loss, > but the quality of customer service has declined significantly. > > On Wed, Nov 12, 2014 at 1:16 PM, james jones wrote: >> I am current going through some vendor selection for tier 1 providers. I >> was trying get some opinions on Zayo. I have personally never heard of >> them. Thoughts? > > From cb.list6 at gmail.com Thu Nov 13 01:45:58 2014 From: cb.list6 at gmail.com (Ca By) Date: Wed, 12 Nov 2014 17:45:58 -0800 Subject: Zayo opinions In-Reply-To: References: Message-ID: On Wed, Nov 12, 2014 at 2:08 PM, Daniel Rohan wrote: > We've leased several 10G circuits from them and they perform adequately and > NOC has been responsive. Pacific Northwest Region. > > -Dan > > +1 Zayo has been as good if not better than my other providers. I have service with them in multiple markets. CB On Wed, Nov 12, 2014 at 1:33 PM, Ryan Wilkins wrote: > > > I don’t know the history on Zayo but they acquired Abovenet of which I’m > a > > customer. > > > > Quite frankly, I haven’t been impressed. The support went to shit. The > > last two tickets that I’ve opened with them have had mixed results. The > > first ticket they called me back 5 days after opening a ticket for a DDoS > > block request and the second they never called back for another DDoS > block > > request. Next time I call them I’m going to demand to speak with someone > > immediately. > > > > Otherwise, the network seems to be fine. > > > > Ryan > > > > > > > On Nov 12, 2014, at 4:16 PM, james jones > wrote: > > > > > > I am current going through some vendor selection for tier 1 providers. > I > > > was trying get some opinions on Zayo. I have personally never heard of > > > them. Thoughts? > > > > > From seth.mos at dds.nl Thu Nov 13 13:26:28 2014 From: seth.mos at dds.nl (Seth Mos) Date: Thu, 13 Nov 2014 14:26:28 +0100 Subject: Mozilla performing pdf.js DNS queries? Message-ID: <5464B184.7050801@dds.nl> Hi, Whilst rummaging through some DNS (dnsmasq) logs I've noticed quite a decent amount of queries for pdf.js from what appear to be mozilla browsers. Seems rather odd that it is performing DNS queries for a internal PDF viewer. Has anyone else come across these lookups? Kind regards, Seth From david at mailplus.nl Thu Nov 13 13:39:23 2014 From: david at mailplus.nl (David Hofstee) Date: Thu, 13 Nov 2014 14:39:23 +0100 Subject: Mozilla performing pdf.js DNS queries? In-Reply-To: <5464B184.7050801@dds.nl> References: <5464B184.7050801@dds.nl> Message-ID: <78C35D6C1A82D243B830523B4193CF5F75CB1CAC55@SBS1.blinker.local> Pdf is quite a standard. One might wonder what it cannot do. One could call it evil. http://superuser.com/questions/368486/link-to-image-within-pdf-and-have-the-image-displayed David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Seth Mos Verzonden: Thursday, November 13, 2014 2:26 PM Aan: NANOG list Onderwerp: Mozilla performing pdf.js DNS queries? Hi, Whilst rummaging through some DNS (dnsmasq) logs I've noticed quite a decent amount of queries for pdf.js from what appear to be mozilla browsers. Seems rather odd that it is performing DNS queries for a internal PDF viewer. Has anyone else come across these lookups? Kind regards, Seth From seth.mos at dds.nl Thu Nov 13 14:27:50 2014 From: seth.mos at dds.nl (Seth Mos) Date: Thu, 13 Nov 2014 15:27:50 +0100 Subject: Mozilla performing pdf.js DNS queries? In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F75CB1CAC55@SBS1.blinker.local> References: <5464B184.7050801@dds.nl> <78C35D6C1A82D243B830523B4193CF5F75CB1CAC55@SBS1.blinker.local> Message-ID: <5464BFE6.9060706@dds.nl> David Hofstee schreef op 13-11-2014 14:39: > Pdf is quite a standard. One might wonder what it cannot do. One could call it evil. > > http://superuser.com/questions/368486/link-to-image-within-pdf-and-have-the-image-displayed Ah yes, a image within a PDF could definitely do this I suppose. I just thought it odd that the browser would leak this out. dnsmasq[3151]: query[A] pdf.js from 10.6.24.11 dnsmasq[3151]: query[AAAA] pdf.js from 10.6.24.11 dnsmasq[3151]: query[A] pdf.js from 10.6.24.11 dnsmasq[3151]: query[AAAA] pdf.js from 10.6.24.11 This could become a whole can of worms if a .js TLD ever makes it to the internet and registers this domain name. We see this from Ubuntu terminals running Mozilla Firefox 33.0 Best regards, Seth > > > > David Hofstee > > Deliverability Management > MailPlus B.V. Netherlands (ESP) > > > -----Oorspronkelijk bericht----- > Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Seth Mos > Verzonden: Thursday, November 13, 2014 2:26 PM > Aan: NANOG list > Onderwerp: Mozilla performing pdf.js DNS queries? > > Hi, > > Whilst rummaging through some DNS (dnsmasq) logs I've noticed quite a decent amount of queries for pdf.js from what appear to be mozilla browsers. > > Seems rather odd that it is performing DNS queries for a internal PDF viewer. > > Has anyone else come across these lookups? > > Kind regards, > > Seth > > From Valdis.Kletnieks at vt.edu Thu Nov 13 17:00:56 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 13 Nov 2014 12:00:56 -0500 Subject: Mozilla performing pdf.js DNS queries? In-Reply-To: Your message of "Thu, 13 Nov 2014 14:26:28 +0100." <5464B184.7050801@dds.nl> References: <5464B184.7050801@dds.nl> Message-ID: <3353.1415898056@turing-police.cc.vt.edu> On Thu, 13 Nov 2014 14:26:28 +0100, Seth Mos said: > Whilst rummaging through some DNS (dnsmasq) logs I've noticed quite a > decent amount of queries for pdf.js from what appear to be mozilla browsers. > > Seems rather odd that it is performing DNS queries for a internal PDF > viewer. Totally wild shot in the dark - recent Mozilla have an onboard PDF viewer written in javascript called pdf.js http://en.wikipedia.org/wiki/PDF.js It's callable from within other javascript via chrome:// or resource:// references, but sometimes people don't get it right: http://superuser.com/questions/614002/how-to-open-pdf-js-in-firefox-via-chrome-url My guess is that somebody else didn't quite get it right, and is trying to get to the hostname when they intended to get to the javascript..... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From math at sizone.org Thu Nov 13 18:42:42 2014 From: math at sizone.org (Ken Chase) Date: Thu, 13 Nov 2014 13:42:42 -0500 Subject: Mozilla performing pdf.js DNS queries? In-Reply-To: <3353.1415898056@turing-police.cc.vt.edu> References: <5464B184.7050801@dds.nl> <3353.1415898056@turing-police.cc.vt.edu> Message-ID: <20141113184242.GC32643@sizone.org> <@darq> 17:40 < ircperson> oof. apparently .prod is a TLD now <@darq> 17:40 < ircperson> and a friend's environment is basically on fire. <@darq> HAHAHA /kc On Thu, Nov 13, 2014 at 12:00:56PM -0500, Valdis.Kletnieks at vt.edu said: >On Thu, 13 Nov 2014 14:26:28 +0100, Seth Mos said: > >> Whilst rummaging through some DNS (dnsmasq) logs I've noticed quite a >> decent amount of queries for pdf.js from what appear to be mozilla browsers. >> >> Seems rather odd that it is performing DNS queries for a internal PDF >> viewer. > >Totally wild shot in the dark - recent Mozilla have an onboard PDF viewer >written in javascript called pdf.js > >http://en.wikipedia.org/wiki/PDF.js > >It's callable from within other javascript via chrome:// or resource:// >references, but sometimes people don't get it right: > >http://superuser.com/questions/614002/how-to-open-pdf-js-in-firefox-via-chrome-url > >My guess is that somebody else didn't quite get it right, and is trying to >get to the hostname when they intended to get to the javascript..... -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From cjp at 0x1.net Thu Nov 13 19:52:45 2014 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Thu, 13 Nov 2014 14:52:45 -0500 Subject: AS7381 clue listening? Message-ID: We have the appropriate tickets and formalities in flight, but wondering if someone of clueful status from AS7381 is listening. We are seeing indications your interface to AS3356 in CHI may be reaching congestion. We are getting the "we'll have an engineer call you back" treatment most of the day. Off list please. From drc at virtualized.org Thu Nov 13 20:05:42 2014 From: drc at virtualized.org (David Conrad) Date: Thu, 13 Nov 2014 10:05:42 -1000 Subject: Mozilla performing pdf.js DNS queries? In-Reply-To: <20141113184242.GC32643@sizone.org> References: <5464B184.7050801@dds.nl> <3353.1415898056@turing-police.cc.vt.edu> <20141113184242.GC32643@sizone.org> Message-ID: <40CF361E-B542-4BD1-9CD3-B32AA170211C@virtualized.org> On Nov 13, 2014, at 8:42 AM, Ken Chase wrote: > <@darq> 17:40 < ircperson> oof. apparently .prod is a TLD now > <@darq> 17:40 < ircperson> and a friend's environment is basically on fire. > <@darq> HAHAHA https://www.icann.org/resources/pages/name-collision-2013-12-06-en Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From reed at reedloden.com Thu Nov 13 20:38:00 2014 From: reed at reedloden.com (Reed Loden) Date: Thu, 13 Nov 2014 12:38:00 -0800 Subject: Mozilla performing pdf.js DNS queries? In-Reply-To: <5464B184.7050801@dds.nl> References: <5464B184.7050801@dds.nl> Message-ID: https://bugzilla.mozilla.org/show_bug.cgi?id=1098415 has been filed to track this issue. ~reed On Thu, Nov 13, 2014 at 5:26 AM, Seth Mos wrote: > Hi, > > Whilst rummaging through some DNS (dnsmasq) logs I've noticed quite a > decent amount of queries for pdf.js from what appear to be mozilla > browsers. > > Seems rather odd that it is performing DNS queries for a internal PDF > viewer. > > Has anyone else come across these lookups? > > Kind regards, > > Seth > From nanog at data102.com Thu Nov 13 23:51:05 2014 From: nanog at data102.com (randal k) Date: Thu, 13 Nov 2014 16:51:05 -0700 Subject: AS4826 leaking at Any2 LA? Message-ID: We're seeing ~2000+ routes leaking at Any2 LA, originating from AS4826. Our traceroutes to Microsoft were going to LA->New Zealand and back O_o. We filtered them out, but thought other folks should know just in case. I also did call their NOC & send them a copy of my notes - just thought I'd throw this out there! Regards, Randal From larrysheldon at cox.net Fri Nov 14 02:12:02 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 13 Nov 2014 20:12:02 -0600 Subject: Mozilla performing pdf.js DNS queries? In-Reply-To: References: <5464B184.7050801@dds.nl> <78C35D6C1A82D243B830523B4193CF5F75CB1CAC55@SBS1.blinker.local> Message-ID: <546564F2.5030801@cox.net> On 11/13/2014 08:27, Seth Mos wrote: > We see this from Ubuntu terminals running Mozilla Firefox 33.0 I have personally declared FF33 to be a pinnacle disaster in a long string of disasters. I don't have the wherewithal, time, or desire to sort out what new breakages there are and which are "just" unfortunate coincidences. Most annoying is that with either FF or TB running, my windows 8.1 machine hangs for minutes at a time. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From nanog at data102.com Fri Nov 14 03:38:02 2014 From: nanog at data102.com (randal k) Date: Thu, 13 Nov 2014 20:38:02 -0700 Subject: AS4826 leaking at Any2 LA? In-Reply-To: References: Message-ID: Kudos where due - Vocus' NOC picked up and knowledgeably directed me where to go, Craig is on here advising within 20 minutes, and I received a separate note from another Vocus network engineer who provided an insightful explanation and resolution. Good work, and thanks for your quick responses! Randal On Thu, Nov 13, 2014 at 5:27 PM, Craig Spiers wrote: > Hi Randal, > > I have put an interim solution in place to stop this - a more permanent > solution requires some customer involvement. > > For the time being - you can consider this issue closed. > > Cheers > > > Kind regards, > > > *Craig Spiers* > * | Senior Network Engineer * > > *M*: +64 21 511 523 *D*: +64 9 913 9672 *E*: craig.spiers at vocus.co.nz > > *P*: 0800 VOCUS NZ or +64 9 912 8899 *W*: vocus.co.nz > *A*: 7a Parkhead Place, Albany, Auckland > 0632, NZ > > > > On 14 November 2014 at 12:57:07 pm, randal k (nanog at data102.com) wrote: > > We're seeing ~2000+ routes leaking at Any2 LA, originating from AS4826. > > Our traceroutes to Microsoft were going to LA->New Zealand and back O_o. > We > filtered them out, but thought other folks should know just in case. > > I also did call their NOC & send them a copy of my notes - just thought > I'd > throw this out there! > > Regards, > Randal > > From eliezer at ngtech.co.il Thu Nov 13 17:09:30 2014 From: eliezer at ngtech.co.il (Eliezer Croitoru) Date: Thu, 13 Nov 2014 19:09:30 +0200 Subject: Linux router traffic monitoring, how? netflow? Message-ID: <5464E5CA.5030309@ngtech.co.il> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all, I have a tiny linux router based on ubuntu and sometimes I get a massive load of UDP traffic because of one of the PCs in the network. Usually I handle the situation with a strict block using iptables. The main issue is to find it due to the load. For now I am monitoring the traffic load using MRTG but it won't notify me. I can try to use nagios to monitor traffic load for a period of time but before I start working on it I want another person opinion and options. I have seen netflow in the past but never actually used it. Thanks in advance, Eliezer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUZOXKAAoJENxnfXtQ8ZQUnCcIAJn/3LQa1CKl1mBGiWHUvrEZ GZIPYKDlDWscVaq2VhJQH/ZcUqX5466YTSLsFQBaCEynLfc4vgk5gBZzyLK9TI1R MSDXAQNYvqRGnDG5rBrthCCvSA8UZyqVH9feSXw+U8aiwZcmQz4SSVv86yy288qP eFlerXq43QvSzXgMPFFrzwVzcwY3UVg0VMxlqIRIl+sB8dfg6ofau61/lax9ALQ4 cfxE674vxKtQsf319lJTmq/3JMvANzZNYbX0+XnLNIDaCciM/GTT/Xvasq+oigm2 IE4T0098KMUyBdJx5ewX5d+rawI2283euiY0Co5UnfCYzBnJTj4xZR32Tip53lM= =gZaZ -----END PGP SIGNATURE----- From looperz at gmail.com Thu Nov 13 18:13:21 2014 From: looperz at gmail.com (Adam Born) Date: Thu, 13 Nov 2014 12:13:21 -0600 Subject: Tech Laptop with DB9 In-Reply-To: <54631292.1000302@1337.io> References: <54631292.1000302@1337.io> Message-ID: AirCable is also good if you have Bluetooth available. I use that for Bluetooth and AirConsole with a tablet. https://www.aircable.net/products/serial5x.php On Wed, Nov 12, 2014 at 1:56 AM, g at 1337.io wrote: > My CF-19 does the trick quite nicely > > On 11/10/14 12:39 PM, Max Clark wrote: > > Hi all, > > > > DB9 ports seem to be a nearly extinct feature on laptops. Any > > suggestions on a cheap laptop for use in field support (with an onboard > > DB9)? > > > > Thanks, > > Max > > > > > From craig.spiers at vocus.co.nz Fri Nov 14 00:09:36 2014 From: craig.spiers at vocus.co.nz (Craig Spiers) Date: Fri, 14 Nov 2014 00:09:36 +0000 Subject: AS4826 leaking at Any2 LA? In-Reply-To: References: Message-ID: Hi Randal, I’m taking a look at this for you right now. Cheers Kind regards, Craig Spiers | Senior Network Engineer M: +64 21 511 523 D: +64 9 913 9672 E: craig.spiers at vocus.co.nz P: 0800 VOCUS NZ or +64 9 912 8899 W: vocus.co.nz A: 7a Parkhead Place, Albany, Auckland 0632, NZ [Description: http://www.vocus.com.au/esig/Vocus_Email_Signature_Logo.png] On 14 November 2014 at 12:57:07 pm, randal k (nanog at data102.com) wrote: We're seeing ~2000+ routes leaking at Any2 LA, originating from AS4826. Our traceroutes to Microsoft were going to LA->New Zealand and back O_o. We filtered them out, but thought other folks should know just in case. I also did call their NOC & send them a copy of my notes - just thought I'd throw this out there! Regards, Randal -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png at 01CFACB3.94A9E780 Type: application/octet-stream Size: 6708 bytes Desc: image001.png at 01CFACB3.94A9E780 URL: From craig.spiers at vocus.co.nz Fri Nov 14 00:27:09 2014 From: craig.spiers at vocus.co.nz (Craig Spiers) Date: Fri, 14 Nov 2014 00:27:09 +0000 Subject: AS4826 leaking at Any2 LA? In-Reply-To: References: Message-ID: Hi Randal, I have put an interim solution in place to stop this - a more permanent solution requires some customer involvement. For the time being - you can consider this issue closed. Cheers Kind regards, Craig Spiers | Senior Network Engineer M: +64 21 511 523 D: +64 9 913 9672 E: craig.spiers at vocus.co.nz P: 0800 VOCUS NZ or +64 9 912 8899 W: vocus.co.nz A: 7a Parkhead Place, Albany, Auckland 0632, NZ [Description: http://www.vocus.com.au/esig/Vocus_Email_Signature_Logo.png] On 14 November 2014 at 12:57:07 pm, randal k (nanog at data102.com) wrote: We're seeing ~2000+ routes leaking at Any2 LA, originating from AS4826. Our traceroutes to Microsoft were going to LA->New Zealand and back O_o. We filtered them out, but thought other folks should know just in case. I also did call their NOC & send them a copy of my notes - just thought I'd throw this out there! Regards, Randal -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png at 01CFACB3.94A9E780 Type: application/octet-stream Size: 6708 bytes Desc: image001.png at 01CFACB3.94A9E780 URL: From ggrabow62 at gmail.com Fri Nov 14 04:41:16 2014 From: ggrabow62 at gmail.com (Greg Grabowski) Date: Thu, 13 Nov 2014 20:41:16 -0800 Subject: Route Science Message-ID: Does anyone still have a Route Science box running out there? Our enterprise still has a box running and working. Just curious..;-) From mkaipov at outlook.com Fri Nov 14 07:35:44 2014 From: mkaipov at outlook.com (Murat Kaipov) Date: Fri, 14 Nov 2014 10:35:44 +0300 Subject: Linux router traffic monitoring, how? netflow? In-Reply-To: <5464E5CA.5030309@ngtech.co.il> References: <5464E5CA.5030309@ngtech.co.il> Message-ID: Hello Eliezer. Netflow will be the best solution to find the host that's generate load. First you need decide what netflow analyzer you'll use. I know about some plugin to Cacti. Than you need install IPT-NETFLOW to your Ubuntu router. Also you have another way, you can monitor (snmp traffic) all ports on switches and then find analyze. B.R. Murat -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eliezer Croitoru Sent: Thursday, November 13, 2014 8:10 PM To: nanog at nanog.org Subject: Linux router traffic monitoring, how? netflow? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all, I have a tiny linux router based on ubuntu and sometimes I get a massive load of UDP traffic because of one of the PCs in the network. Usually I handle the situation with a strict block using iptables. The main issue is to find it due to the load. For now I am monitoring the traffic load using MRTG but it won't notify me. I can try to use nagios to monitor traffic load for a period of time but before I start working on it I want another person opinion and options. I have seen netflow in the past but never actually used it. Thanks in advance, Eliezer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUZOXKAAoJENxnfXtQ8ZQUnCcIAJn/3LQa1CKl1mBGiWHUvrEZ GZIPYKDlDWscVaq2VhJQH/ZcUqX5466YTSLsFQBaCEynLfc4vgk5gBZzyLK9TI1R MSDXAQNYvqRGnDG5rBrthCCvSA8UZyqVH9feSXw+U8aiwZcmQz4SSVv86yy288qP eFlerXq43QvSzXgMPFFrzwVzcwY3UVg0VMxlqIRIl+sB8dfg6ofau61/lax9ALQ4 cfxE674vxKtQsf319lJTmq/3JMvANzZNYbX0+XnLNIDaCciM/GTT/Xvasq+oigm2 IE4T0098KMUyBdJx5ewX5d+rawI2283euiY0Co5UnfCYzBnJTj4xZR32Tip53lM= =gZaZ -----END PGP SIGNATURE----- From linkconnect at googlemail.com Fri Nov 14 07:39:51 2014 From: linkconnect at googlemail.com (Wayne Lee) Date: Fri, 14 Nov 2014 02:39:51 -0500 Subject: Linux router traffic monitoring, how? netflow? In-Reply-To: References: <5464E5CA.5030309@ngtech.co.il> Message-ID: Hello I've used ntop in the past with great success. ntop.org Regards Wayne On 14 November 2014 02:35, Murat Kaipov wrote: > Hello Eliezer. > Netflow will be the best solution to find the host that's generate load. > First you need decide what netflow analyzer you'll use. I know about some > plugin to Cacti. Than you need install IPT-NETFLOW to your Ubuntu router. > Also you have another way, you can monitor (snmp traffic) all ports on > switches and then find analyze. > B.R. Murat > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eliezer Croitoru > Sent: Thursday, November 13, 2014 8:10 PM > To: nanog at nanog.org > Subject: Linux router traffic monitoring, how? netflow? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey all, > > I have a tiny linux router based on ubuntu and sometimes I get a massive > load of UDP traffic because of one of the PCs in the network. > Usually I handle the situation with a strict block using iptables. > The main issue is to find it due to the load. > For now I am monitoring the traffic load using MRTG but it won't notify me. > I can try to use nagios to monitor traffic load for a period of time but > before I start working on it I want another person opinion and options. > > I have seen netflow in the past but never actually used it. > > Thanks in advance, > Eliezer > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJUZOXKAAoJENxnfXtQ8ZQUnCcIAJn/3LQa1CKl1mBGiWHUvrEZ > GZIPYKDlDWscVaq2VhJQH/ZcUqX5466YTSLsFQBaCEynLfc4vgk5gBZzyLK9TI1R > MSDXAQNYvqRGnDG5rBrthCCvSA8UZyqVH9feSXw+U8aiwZcmQz4SSVv86yy288qP > eFlerXq43QvSzXgMPFFrzwVzcwY3UVg0VMxlqIRIl+sB8dfg6ofau61/lax9ALQ4 > cfxE674vxKtQsf319lJTmq/3JMvANzZNYbX0+XnLNIDaCciM/GTT/Xvasq+oigm2 > IE4T0098KMUyBdJx5ewX5d+rawI2283euiY0Co5UnfCYzBnJTj4xZR32Tip53lM= > =gZaZ > -----END PGP SIGNATURE----- > From rnalrd at gmail.com Fri Nov 14 08:34:29 2014 From: rnalrd at gmail.com (Leonardo Arena) Date: Fri, 14 Nov 2014 09:34:29 +0100 Subject: Linux router traffic monitoring, how? netflow? In-Reply-To: <5464E5CA.5030309@ngtech.co.il> References: <5464E5CA.5030309@ngtech.co.il> Message-ID: <1415954069.26147.16.camel@df1844j> On gio, 2014-11-13 at 19:09 +0200, Eliezer Croitoru wrote: > Hey all, > > I have a tiny linux router based on ubuntu and sometimes I get a > massive load of UDP traffic because of one of the PCs in the network. > Usually I handle the situation with a strict block using iptables. > The main issue is to find it due to the load. > For now I am monitoring the traffic load using MRTG but it won't > notify me. > I can try to use nagios to monitor traffic load for a period of time > but before I start working on it I want another person opinion and > options. > > I have seen netflow in the past but never actually used it. > > Thanks in advance, > Eliezer NFDump [1] also is good if you look at a less fancy analyzer (cmdline based) but very customizable. You search for that data the you want in the time slot that you want. I know there are other projects which can read captured data and present it in a GUI but I haven't used them myself. Regards, leonardo [1] http://nfdump.sourceforge.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From jmamodio at gmail.com Fri Nov 14 12:12:17 2014 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 14 Nov 2014 06:12:17 -0600 Subject: TWC IPv6 access ... Message-ID: Hi There, anybody seeing problems with TWC broadband access and IPv6? After a brief outage this morning I no longer have IPv6 in my residential line and don't see any IPv6 neighbor at the other end of the coax :-( -Jorge From david at davidcoulson.net Fri Nov 14 12:29:59 2014 From: david at davidcoulson.net (David Coulson) Date: Fri, 14 Nov 2014 07:29:59 -0500 Subject: TWC IPv6 access ... In-Reply-To: References: Message-ID: <5465F5C7.9080401@davidcoulson.net> Which market are you in? Working for me in Cleveland, OH. fw-1:/root # ping6 -I eth7 fe80::201:5cff:fe66:fe46 PING fe80::201:5cff:fe66:fe46(fe80::201:5cff:fe66:fe46) from fe80::21a:8cff:fe17:6c47 eth7: 56 data bytes 64 bytes from fe80::201:5cff:fe66:fe46: icmp_seq=1 ttl=64 time=19.2 ms 64 bytes from fe80::201:5cff:fe66:fe46: icmp_seq=2 ttl=64 time=9.27 ms ^C --- fe80::201:5cff:fe66:fe46 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 9.270/14.278/19.287/5.009 ms On 11/14/14, 7:12 AM, Jorge Amodio wrote: > Hi There, > > anybody seeing problems with TWC broadband access and IPv6? > > After a brief outage this morning I no longer have IPv6 in my residential > line and don't see any IPv6 neighbor at the other end of the coax :-( > > -Jorge From jmamodio at gmail.com Fri Nov 14 12:34:42 2014 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 14 Nov 2014 06:34:42 -0600 Subject: TWC IPv6 access ... In-Reply-To: <5465F5C7.9080401@davidcoulson.net> References: <5465F5C7.9080401@davidcoulson.net> Message-ID: Hey David, thanks for your msg. I'm in San Antonio, TX. Got a brief response via FB: "There is currently an area issue ongoing. We are working to restore services as soon as possible. My apologies for any inconvenience." BTW, after the brief outage the DHCP served assigned a different IPv4 address. -J On Fri, Nov 14, 2014 at 6:29 AM, David Coulson wrote: > Which market are you in? > > Working for me in Cleveland, OH. > > fw-1:/root # ping6 -I eth7 fe80::201:5cff:fe66:fe46 > PING fe80::201:5cff:fe66:fe46(fe80::201:5cff:fe66:fe46) from > fe80::21a:8cff:fe17:6c47 eth7: 56 data bytes > 64 bytes from fe80::201:5cff:fe66:fe46: icmp_seq=1 ttl=64 time=19.2 ms > 64 bytes from fe80::201:5cff:fe66:fe46: icmp_seq=2 ttl=64 time=9.27 ms > ^C > --- fe80::201:5cff:fe66:fe46 ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1001ms > rtt min/avg/max/mdev = 9.270/14.278/19.287/5.009 ms > > > > > On 11/14/14, 7:12 AM, Jorge Amodio wrote: > >> Hi There, >> >> anybody seeing problems with TWC broadband access and IPv6? >> >> After a brief outage this morning I no longer have IPv6 in my residential >> line and don't see any IPv6 neighbor at the other end of the coax :-( >> >> -Jorge >> > > From jloiacon at csc.com Fri Nov 14 13:50:11 2014 From: jloiacon at csc.com (Joe Loiacono) Date: Fri, 14 Nov 2014 08:50:11 -0500 Subject: Linux router traffic monitoring, how? netflow? In-Reply-To: References: <5464E5CA.5030309@ngtech.co.il> Message-ID: If you go the netflow route you might consider FlowViewer/SiLK for the collector/analyzer. It is web driven and allows you to easily establish traffic thresholds which will generate an alert email. https://sourceforge.net/projects/flowviewer Joe "NANOG" wrote on 11/14/2014 02:35:44 AM: > From: Murat Kaipov > To: "'Eliezer Croitoru'" , > Date: 11/14/2014 02:37 AM > Subject: RE: Linux router traffic monitoring, how? netflow? > Sent by: "NANOG" > > Hello Eliezer. > Netflow will be the best solution to find the host that's generate > load. First you need decide what netflow analyzer you'll use. I know > about some plugin to Cacti. Than you need install IPT-NETFLOW to > your Ubuntu router. > Also you have another way, you can monitor (snmp traffic) all ports > on switches and then find analyze. > B.R. Murat > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eliezer Croitoru > Sent: Thursday, November 13, 2014 8:10 PM > To: nanog at nanog.org > Subject: Linux router traffic monitoring, how? netflow? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey all, > > I have a tiny linux router based on ubuntu and sometimes I get a > massive load of UDP traffic because of one of the PCs in the network. > Usually I handle the situation with a strict block using iptables. > The main issue is to find it due to the load. > For now I am monitoring the traffic load using MRTG but it won't notify me. > I can try to use nagios to monitor traffic load for a period of time > but before I start working on it I want another person opinion and options. > > I have seen netflow in the past but never actually used it. > > Thanks in advance, > Eliezer > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJUZOXKAAoJENxnfXtQ8ZQUnCcIAJn/3LQa1CKl1mBGiWHUvrEZ > GZIPYKDlDWscVaq2VhJQH/ZcUqX5466YTSLsFQBaCEynLfc4vgk5gBZzyLK9TI1R > MSDXAQNYvqRGnDG5rBrthCCvSA8UZyqVH9feSXw+U8aiwZcmQz4SSVv86yy288qP > eFlerXq43QvSzXgMPFFrzwVzcwY3UVg0VMxlqIRIl+sB8dfg6ofau61/lax9ALQ4 > cfxE674vxKtQsf319lJTmq/3JMvANzZNYbX0+XnLNIDaCciM/GTT/Xvasq+oigm2 > IE4T0098KMUyBdJx5ewX5d+rawI2283euiY0Co5UnfCYzBnJTj4xZR32Tip53lM= > =gZaZ > -----END PGP SIGNATURE----- From brandon at burn.net Fri Nov 14 14:27:08 2014 From: brandon at burn.net (Brandon Applegate) Date: Fri, 14 Nov 2014 09:27:08 -0500 Subject: TWC IPv6 access ... In-Reply-To: References: Message-ID: <996AD626-3FD5-4D06-BF97-986CAE2A7422@burn.net> > On Nov 14, 2014, at 7:12 AM, Jorge Amodio wrote: > > Hi There, > > anybody seeing problems with TWC broadband access and IPv6? > > After a brief outage this morning I no longer have IPv6 in my residential > line and don't see any IPv6 neighbor at the other end of the coax :-( > > -Jorge Southwest OH (Cincinnati) here. I woke up earlier this week and saw that I had been seemingly ‘renumbered’. I.e. my DHCP PD prefix had changed (so did my IA /128). PD was renumbered out of a totally different /32 at that. I’m using wide client on Ubuntu. wide seemed to do okay with the change, but the kernel forgot it’s RA def gw so I had to go full Windows and reboot the firewall :) -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 830B 4802 1DD4 F4F9 63FE B966 C0A7 189E 9EC0 3A74 "SH1-0151. This is the serial number, of our orbital gun." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From peter.phaal at gmail.com Fri Nov 14 15:16:36 2014 From: peter.phaal at gmail.com (Peter Phaal) Date: Fri, 14 Nov 2014 07:16:36 -0800 Subject: Linux router traffic monitoring, how? netflow? In-Reply-To: <5464E5CA.5030309@ngtech.co.il> References: <5464E5CA.5030309@ngtech.co.il> Message-ID: You might want to take a look at the Host sFlow SourceForge project: http://host-sflow.sourceforge.net/ The hsflowd agent used the sFlow protocol to export interface counters, host performance statistics and packet flows (collected using iptables ULOG). Peter On Thu, Nov 13, 2014 at 9:09 AM, Eliezer Croitoru wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey all, > > I have a tiny linux router based on ubuntu and sometimes I get a > massive load of UDP traffic because of one of the PCs in the network. > Usually I handle the situation with a strict block using iptables. > The main issue is to find it due to the load. > For now I am monitoring the traffic load using MRTG but it won't > notify me. > I can try to use nagios to monitor traffic load for a period of time > but before I start working on it I want another person opinion and > options. > > I have seen netflow in the past but never actually used it. > > Thanks in advance, > Eliezer > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJUZOXKAAoJENxnfXtQ8ZQUnCcIAJn/3LQa1CKl1mBGiWHUvrEZ > GZIPYKDlDWscVaq2VhJQH/ZcUqX5466YTSLsFQBaCEynLfc4vgk5gBZzyLK9TI1R > MSDXAQNYvqRGnDG5rBrthCCvSA8UZyqVH9feSXw+U8aiwZcmQz4SSVv86yy288qP > eFlerXq43QvSzXgMPFFrzwVzcwY3UVg0VMxlqIRIl+sB8dfg6ofau61/lax9ALQ4 > cfxE674vxKtQsf319lJTmq/3JMvANzZNYbX0+XnLNIDaCciM/GTT/Xvasq+oigm2 > IE4T0098KMUyBdJx5ewX5d+rawI2283euiY0Co5UnfCYzBnJTj4xZR32Tip53lM= > =gZaZ > -----END PGP SIGNATURE----- From alan at clegg.com Fri Nov 14 16:11:42 2014 From: alan at clegg.com (Alan Clegg) Date: Fri, 14 Nov 2014 11:11:42 -0500 Subject: TWC IPv6 access ... In-Reply-To: References: Message-ID: <546629BE.9070909@clegg.com> On 11/14/14, 7:12 AM, Jorge Amodio wrote: > Hi There, > > anybody seeing problems with TWC broadband access and IPv6? > > After a brief outage this morning I no longer have IPv6 in my residential > line and don't see any IPv6 neighbor at the other end of the coax :-( Apex, NC. Been out for about a week. I get a /128 for my router, but no prefix delegation. AlanC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: OpenPGP digital signature URL: From twakefield at stcloudstate.edu Fri Nov 14 17:04:59 2014 From: twakefield at stcloudstate.edu (Wakefield, Thad M.) Date: Fri, 14 Nov 2014 17:04:59 +0000 Subject: Cisco CCNA Training (Udemy Discounted Training) Message-ID: Since there was some interest in the Udemy CCNA training, I'll risk forwarding these additional discounts: Remember that this is ONLY for the month of NOVEMBER! *** CCNA Course is now $24 with coupon code: THANKS24 https://www.udemy.com/the-complete-ccna-200-120-course/?couponCode=THANKS24 *** ROUTING Course is now $14 with coupon code: THANKS14 https://www.udemy.com/routing-configuration-router-administration/?couponCode=THANKS14 *** SWITCHING Course is now $9 with coupon code: THANKS9 https://www.udemy.com/layer-2-switching-vlans/?couponCode=THANKS9 *** IPv4 Course is now $9 with coupon code: THANKS9 https://www.udemy.com/everything-you-need-to-know-about-ipv4-and-its-configuration/?couponCode=THANKS9 *** IPv6 Course is now $9 with coupon code: THANKS9 https://www.udemy.com/the_abcs_of_ipv6/?couponCode=THANKS9 *** VLANs Course is now $5 with coupon code: THANKS5 https://www.udemy.com/overview-of-vlans-access-list-nat-bonus-material/?couponCode=THANKS5 *** OSPF Course is now $14 with coupon code: THANKS14 https://www.udemy.com/ospf-breakdown/?couponCode=THANKS14 *** HEX Course is FREE *** use coupon code: THANKSFREE https://www.udemy.com/learn-how-to-do-hex-conversions-in-under-30-seconds/?couponCode=THANKSFREE From cscora at apnic.net Fri Nov 14 18:12:04 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Nov 2014 04:12:04 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201411141812.sAEIC4ua014820@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 15 Nov, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 523387 Prefixes after maximum aggregation: 200080 Deaggregation factor: 2.62 Unique aggregates announced to Internet: 254079 Total ASes present in the Internet Routing Table: 48571 Prefixes per ASN: 10.78 Origin-only ASes present in the Internet Routing Table: 36287 Origin ASes announcing only one prefix: 16326 Transit ASes present in the Internet Routing Table: 6207 Transit-only ASes present in the Internet Routing Table: 172 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 78 Max AS path prepend of ASN ( 55644) 71 Prefixes from unregistered ASNs in the Routing Table: 1609 Unregistered ASNs in the Routing Table: 432 Number of 32-bit ASNs allocated by the RIRs: 7908 Number of 32-bit ASNs visible in the Routing Table: 6077 Prefixes from 32-bit ASNs in the Routing Table: 21732 Number of bogon 32-bit ASNs visible in the Routing Table: 2 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 385 Number of addresses announced to Internet: 2713710468 Equivalent to 161 /8s, 191 /16s and 239 /24s Percentage of available address space announced: 73.3 Percentage of allocated address space announced: 73.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.9 Total number of prefixes smaller than registry allocations: 176898 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 133068 Total APNIC prefixes after maximum aggregation: 37013 APNIC Deaggregation factor: 3.60 Prefixes being announced from the APNIC address blocks: 137428 Unique aggregates announced from the APNIC address blocks: 53664 APNIC Region origin ASes present in the Internet Routing Table: 4988 APNIC Prefixes per ASN: 27.55 APNIC Region origin ASes announcing only one prefix: 1204 APNIC Region transit ASes present in the Internet Routing Table: 864 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 78 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1169 Number of APNIC addresses announced to Internet: 737090368 Equivalent to 43 /8s, 239 /16s and 27 /24s Percentage of available APNIC address space announced: 86.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 171939 Total ARIN prefixes after maximum aggregation: 85566 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 173830 Unique aggregates announced from the ARIN address blocks: 81757 ARIN Region origin ASes present in the Internet Routing Table: 16398 ARIN Prefixes per ASN: 10.60 ARIN Region origin ASes announcing only one prefix: 6088 ARIN Region transit ASes present in the Internet Routing Table: 1705 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 257 Number of ARIN addresses announced to Internet: 1053686464 Equivalent to 62 /8s, 205 /16s and 250 /24s Percentage of available ARIN address space announced: 55.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 125891 Total RIPE prefixes after maximum aggregation: 63703 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 131484 Unique aggregates announced from the RIPE address blocks: 82809 RIPE Region origin ASes present in the Internet Routing Table: 17803 RIPE Prefixes per ASN: 7.39 RIPE Region origin ASes announcing only one prefix: 8184 RIPE Region transit ASes present in the Internet Routing Table: 2931 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3196 Number of RIPE addresses announced to Internet: 691635332 Equivalent to 41 /8s, 57 /16s and 132 /24s Percentage of available RIPE address space announced: 100.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 58329 Total LACNIC prefixes after maximum aggregation: 10882 LACNIC Deaggregation factor: 5.36 Prefixes being announced from the LACNIC address blocks: 67079 Unique aggregates announced from the LACNIC address blocks: 30727 LACNIC Region origin ASes present in the Internet Routing Table: 2370 LACNIC Prefixes per ASN: 28.30 LACNIC Region origin ASes announcing only one prefix: 643 LACNIC Region transit ASes present in the Internet Routing Table: 472 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1391 Number of LACNIC addresses announced to Internet: 167846400 Equivalent to 10 /8s, 1 /16s and 34 /24s Percentage of available LACNIC address space announced: 100.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12329 Total AfriNIC prefixes after maximum aggregation: 2872 AfriNIC Deaggregation factor: 4.29 Prefixes being announced from the AfriNIC address blocks: 13181 Unique aggregates announced from the AfriNIC address blocks: 4778 AfriNIC Region origin ASes present in the Internet Routing Table: 733 AfriNIC Prefixes per ASN: 17.98 AfriNIC Region origin ASes announcing only one prefix: 207 AfriNIC Region transit ASes present in the Internet Routing Table: 152 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 64 Number of AfriNIC addresses announced to Internet: 60012544 Equivalent to 3 /8s, 147 /16s and 184 /24s Percentage of available AfriNIC address space announced: 59.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5620 4190 71 China Education and Research 4766 2962 11585 932 Korea Telecom 17974 2841 903 77 PT Telekomunikasi Indonesia 7545 2458 336 126 TPG Telecom Limited 4755 1923 412 190 TATA Communications formerly 9829 1670 1322 37 National Internet Backbone 4812 1522 2098 110 China Telecom (Group) 9808 1487 6655 16 Guangdong Mobile Communicatio 4808 1425 2213 427 CNCGROUP IP network China169 9583 1362 112 561 Sify Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2894 3688 51 BellSouth.net Inc. 22773 2838 2956 144 Cox Communications Inc. 18566 2045 379 184 MegaPath Corporation 20115 1821 1796 479 Charter Communications 7029 1711 2180 363 Windstream Communications Inc 4323 1640 1052 412 tw telecom holdings, inc. 6983 1595 867 250 ITC^Deltacom 30036 1494 311 604 Mediacom Communications Corp 701 1430 11266 710 MCI Communications Services, 22561 1314 409 242 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 34984 1839 296 355 TELLCOM ILETISIM HIZMETLERI A 20940 1502 582 1107 Akamai International B.V. 8402 1343 544 15 OJSC "Vimpelcom" 31148 1045 45 21 Freenet Ltd. 13188 1018 99 38 TOV "Bank-Inform" 8551 948 373 43 Bezeq International-Ltd 6849 828 356 26 JSC "Ukrtelecom" 9198 803 346 32 JSC Kazakhtelecom 6830 795 2339 438 Liberty Global Operations B.V 12479 767 785 96 France Telecom Espana SA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3034 492 244 Telmex Colombia S.A. 28573 2450 2256 111 NET Servi�os de Comunica��o S 7303 1766 1171 241 Telecom Argentina S.A. 8151 1475 3015 428 Uninet S.A. de C.V. 6147 1368 374 30 Telefonica del Peru S.A.A. 6503 1133 433 58 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 27947 916 130 52 Telconet S.A 26615 914 2325 35 Tim Celular S.A. 3816 891 383 151 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1399 958 13 TE-AS 24863 956 280 26 Link Egypt (Link.NET) 6713 586 762 34 Office National des Postes et 36992 359 824 29 ETISALAT MISR 24835 308 144 9 Vodafone Data 37492 280 125 63 Orange Tunisie 3741 249 920 212 Internet Solutions 29571 245 22 17 Cote d'Ivoire Telecom 37054 242 19 6 Data Telecom Service 37457 187 161 7 Telkom SA Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5620 4190 71 China Education and Research 10620 3034 492 244 Telmex Colombia S.A. 4766 2962 11585 932 Korea Telecom 6389 2894 3688 51 BellSouth.net Inc. 17974 2841 903 77 PT Telekomunikasi Indonesia 22773 2838 2956 144 Cox Communications Inc. 7545 2458 336 126 TPG Telecom Limited 28573 2450 2256 111 NET Servi�os de Comunica��o S 18566 2045 379 184 MegaPath Corporation 4755 1923 412 190 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2894 2843 BellSouth.net Inc. 10620 3034 2790 Telmex Colombia S.A. 17974 2841 2764 PT Telekomunikasi Indonesia 22773 2838 2694 Cox Communications Inc. 28573 2450 2339 NET Servi�os de Comunica��o S 7545 2458 2332 TPG Telecom Limited 4766 2962 2030 Korea Telecom 18566 2045 1861 MegaPath Corporation 4755 1923 1733 TATA Communications formerly 9829 1670 1633 National Internet Backbone Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.252.224.0/20 62502 Xnet Media LLC 23.252.224.0/21 62502 Xnet Media LLC 23.252.232.0/21 62502 Xnet Media LLC 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:31 /11:90 /12:262 /13:500 /14:1010 /15:1721 /16:13041 /17:7247 /18:12079 /19:25517 /20:36643 /21:37904 /22:55948 /23:48983 /24:279399 /25:1127 /26:1094 /27:705 /28:15 /29:19 /30:11 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2056 2838 Cox Communications Inc. 18566 2000 2045 MegaPath Corporation 6389 1674 2894 BellSouth.net Inc. 30036 1340 1494 Mediacom Communications Corp 6983 1279 1595 ITC^Deltacom 34984 1162 1839 TELLCOM ILETISIM HIZMETLERI A 11492 1161 1214 CABLE ONE, INC. 10620 1074 3034 Telmex Colombia S.A. 8402 1008 1343 OJSC "Vimpelcom" 22561 1005 1314 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1353 2:681 3:3 4:16 5:1180 6:22 8:769 12:1850 13:4 14:1192 15:17 16:2 17:42 18:21 20:51 23:961 24:1758 27:1816 31:1352 32:39 33:2 34:5 36:161 37:1823 38:1012 39:15 40:236 41:2984 42:283 43:633 44:20 45:81 46:2106 47:30 49:758 50:808 52:12 54:59 55:6 56:8 57:32 58:1203 59:720 60:442 61:1732 62:1310 63:1841 64:4425 65:2281 66:4171 67:2030 68:1087 69:3261 70:885 71:458 72:1989 74:2633 75:363 76:410 77:1621 78:916 79:779 80:1324 81:1286 82:811 83:665 84:718 85:1358 86:419 87:1170 88:504 89:1805 90:140 91:5869 92:801 93:1665 94:1930 95:1295 96:416 97:342 98:1071 99:48 100:67 101:754 103:6077 104:563 105:160 106:188 107:712 108:607 109:1982 110:1068 111:1435 112:741 113:917 114:805 115:1222 116:1244 117:1007 118:1603 119:1368 120:446 121:1023 122:2217 123:1697 124:1476 125:1601 128:656 129:389 130:380 131:950 132:427 133:164 134:320 135:82 136:326 137:307 138:387 139:199 140:228 141:422 142:599 143:452 144:504 145:111 146:688 147:561 148:1042 149:413 150:517 151:651 152:479 153:242 154:415 155:631 156:379 157:331 158:281 159:926 160:334 161:622 162:1826 163:371 164:648 165:670 166:309 167:693 168:1115 169:122 170:1430 171:215 172:60 173:1613 174:713 175:581 176:1525 177:3745 178:2108 179:796 180:1812 181:1585 182:1669 183:565 184:707 185:2333 186:2975 187:1655 188:2018 189:1503 190:7709 191:799 192:7785 193:5553 194:4050 195:3629 196:1653 197:817 198:5335 199:5485 200:6495 201:2887 202:9677 203:8991 204:4673 205:2671 206:3036 207:2956 208:3936 209:3817 210:3660 211:2036 212:2480 213:2184 214:843 215:86 216:5645 217:1713 218:716 219:550 220:1303 221:773 222:687 223:615 End of report From srn.nanog at prgmr.com Fri Nov 14 18:38:55 2014 From: srn.nanog at prgmr.com (srn.nanog at prgmr.com) Date: Fri, 14 Nov 2014 10:38:55 -0800 Subject: Linux router traffic monitoring, how? netflow? In-Reply-To: <5464E5CA.5030309@ngtech.co.il> References: <5464E5CA.5030309@ngtech.co.il> Message-ID: <54664C3F.9060500@prgmr.com> fprobe is a linux-based netflow probe that uses libpcap (as does tcpdump) and is already in the ubuntu universe repository. There is an ipv4-only iptables based version too called fprobe-ulog. For collectors, it looks like the ones already available in ubuntu are nfcapd from nfdump and flow-capture from flow-tools. For analysis/alerts, cacti with the thold and flowview plugins might do the job. On 11/13/2014 09:09 AM, Eliezer Croitoru wrote: > Hey all, > > I have a tiny linux router based on ubuntu and sometimes I get a > massive load of UDP traffic because of one of the PCs in the network. > Usually I handle the situation with a strict block using iptables. > The main issue is to find it due to the load. > For now I am monitoring the traffic load using MRTG but it won't > notify me. > I can try to use nagios to monitor traffic load for a period of time > but before I start working on it I want another person opinion and > options. > > I have seen netflow in the past but never actually used it. > > Thanks in advance, > Eliezer > From adrian.minta at gmail.com Fri Nov 14 19:08:42 2014 From: adrian.minta at gmail.com (Adrian Minta) Date: Fri, 14 Nov 2014 21:08:42 +0200 Subject: Linux router traffic monitoring, how? netflow? In-Reply-To: <54664C3F.9060500@prgmr.com> References: <5464E5CA.5030309@ngtech.co.il> <54664C3F.9060500@prgmr.com> Message-ID: <5466533A.2010300@gmail.com> Softflowd is also nice, supports "Netflow versions 1, 5 and 9 and is fully IPv6-capable". The package is included on ubuntu & debian. On 14.11.2014 20:38, srn.nanog at prgmr.com wrote: > fprobe is a linux-based netflow probe that uses libpcap (as does tcpdump) and is already in the > ubuntu universe repository. There is an ipv4-only iptables based version too called fprobe-ulog. > > For collectors, it looks like the ones already available in ubuntu are nfcapd from nfdump and > flow-capture from flow-tools. For analysis/alerts, cacti with the thold and flowview plugins might > do the job. > > -- Best regards, Adrian Minta From cidr-report at potaroo.net Fri Nov 14 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Nov 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201411142200.sAEM00Lv097365@wattle.apnic.net> This report has been generated at Fri Nov 14 21:14:18 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 07-11-14 528597 291888 08-11-14 529295 291872 09-11-14 528850 291914 10-11-14 528865 291936 11-11-14 529156 292033 12-11-14 529114 291833 13-11-14 528626 292350 14-11-14 529142 292356 AS Summary 48845 Number of ASes in routing system 19622 Number of ASes announcing only one prefix 5632 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center,CN 120193024 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 14Nov14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 529166 292346 236820 44.8% All ASes AS4538 5632 2094 3538 62.8% ERX-CERNET-BKB China Education and Research Network Center,CN AS6389 2894 116 2778 96.0% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2841 83 2758 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS22773 2841 165 2676 94.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS28573 2450 285 2165 88.4% NET Servi�os de Comunica��o S.A.,BR AS4766 2963 1341 1622 54.7% KIXS-AS-KR Korea Telecom,KR AS10620 3034 1549 1485 48.9% Telmex Colombia S.A.,CO AS7303 1770 290 1480 83.6% Telecom Argentina S.A.,AR AS9808 1483 54 1429 96.4% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS8402 1322 28 1294 97.9% CORBINA-AS OJSC "Vimpelcom",RU AS4755 1923 641 1282 66.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS6147 1368 104 1264 92.4% Telefonica del Peru S.A.A.,PE AS20115 1822 560 1262 69.3% CHARTER-NET-HKY-NC - Charter Communications,US AS4323 1648 414 1234 74.9% TWTC - tw telecom holdings, inc.,US AS7545 2470 1253 1217 49.3% TPG-INTERNET-AP TPG Telecom Limited,AU AS9498 1315 110 1205 91.6% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2044 869 1175 57.5% MEGAPATH5-US - MegaPath Corporation,US AS7552 1208 54 1154 95.5% VIETEL-AS-AP Viettel Corporation,VN AS6983 1594 459 1135 71.2% ITCDELTA - Earthlink, Inc.,US AS34984 1840 823 1017 55.3% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS4812 1525 509 1016 66.6% CHINANET-SH-AP China Telecom (Group),CN AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS7029 1881 978 903 48.0% WINDSTREAM - Windstream Communications Inc,US AS22561 1315 426 889 67.6% AS22561 - CenturyTel Internet Holdings, Inc.,US AS4788 1106 258 848 76.7% TMNET-AS-AP TM Net, Internet Service Provider,MY AS38285 975 130 845 86.7% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS24560 1184 349 835 70.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS31148 1045 260 785 75.1% FREENET-AS Freenet Ltd.,UA AS26615 914 133 781 85.4% Tim Celular S.A.,BR AS8151 1482 703 779 52.6% Uninet S.A. de C.V.,MX Total 56888 15121 41767 73.4% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.160.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.164.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.168.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.172.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.176.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.180.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.184.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.188.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.224.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.228.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.232.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.236.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.220.84.0/24 AS5577 ROOT root SA,LU 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN 103.10.222.0/24 AS13189 103.14.231.0/24 AS58680 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.56.0/24 AS13239 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.228.132.0/22 AS4826 VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.251.244.0/22 AS55536 PSWITCH-HK Pacswitch Colocation & Datacentre,HK 104.243.32.0/20 AS20473 AS-CHOOPA - Choopa, LLC,US 104.244.157.0/24 AS29761 AS-QUADRANET - QuadraNet, Inc,US 104.244.158.0/24 AS31863 DACEN-2 - Centrilogic, Inc.,US 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 162.210.240.0/24 AS17246 -Reserved AS-,ZZ 162.210.241.0/24 AS17246 -Reserved AS-,ZZ 162.210.244.0/24 AS17246 -Reserved AS-,ZZ 162.210.245.0/24 AS17246 -Reserved AS-,ZZ 162.210.246.0/24 AS17246 -Reserved AS-,ZZ 162.210.247.0/24 AS17246 -Reserved AS-,ZZ 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 162.244.140.0/24 AS17246 -Reserved AS-,ZZ 162.244.141.0/24 AS17246 -Reserved AS-,ZZ 162.244.142.0/24 AS17246 -Reserved AS-,ZZ 162.244.143.0/24 AS17246 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 185.77.12.0/24 AS20136 WIMIONLINE WimiOnline BVBA,BE 185.77.13.0/24 AS20136 WIMIONLINE WimiOnline BVBA,BE 185.77.14.0/23 AS20136 WIMIONLINE WimiOnline BVBA,BE 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.107.1.0/24 AS59377 ELE-MAGIC-TRANSIT 6 Bingshantang Industrial Park, Shawan, Longgang District, Shenzhen, China,CN 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.52.0/23 AS14455 SUNGARD-RECOVERY - Sungard Network Solutions, Inc.,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.6.0.0/24 AS32768 routability-tests,MU 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.254.0/24 AS32768 routability-tests,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.7.160.0/21 AS13703 BROADRIVER-13703 - BroadRiver Communication Corp.,US 199.7.162.0/24 AS22626 -Reserved AS-,ZZ 199.7.167.0/24 AS22626 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.161.184.0/24 AS9328 GLOBALCENTER-AU Datacom Victoria,AU 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Nov 14 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Nov 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201411142200.sAEM01Ur097378@wattle.apnic.net> BGP Update Report Interval: 06-Nov-14 -to- 13-Nov-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS12897 1515794 26.4% 126316.2 -- HEAGMEDIANET HSE Medianet GmbH,DE 2 - AS14287 367120 6.4% 61186.7 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 3 - AS23752 200084 3.5% 2041.7 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - AS9829 156940 2.7% 133.0 -- BSNL-NIB National Internet Backbone,IN 5 - AS22773 53468 0.9% 12.7 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 6 - AS48159 40890 0.7% 145.0 -- TIC-AS Telecommunication Infrastructure Company,IR 7 - AS27738 39110 0.7% 50.1 -- Ecuadortelecom S.A.,EC 8 - AS17974 27330 0.5% 19.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 9 - AS8402 25267 0.4% 85.9 -- CORBINA-AS OJSC "Vimpelcom",RU 10 - AS3 24068 0.4% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 11 - AS28642 23749 0.4% 698.5 -- Contato Internet Ltda EPP,BR 12 - AS14840 22845 0.4% 692.3 -- COMMCORP COMUNICACOES LTDA,BR 13 - AS23342 22257 0.4% 4451.4 -- UNITEDLAYER - Unitedlayer, Inc.,US 14 - AS28573 21917 0.4% 8.0 -- NET Servi�os de Comunica��o S.A.,BR 15 - AS25003 20008 0.3% 1818.9 -- INTERNET_BINAT Internet Binat Ltd,IL 16 - AS23693 18680 0.3% 196.6 -- TELKOMSEL-ASN-ID PT. Telekomunikasi Selular,ID 17 - AS12066 17844 0.3% 93.4 -- TRICOM,DO 18 - AS3313 17661 0.3% 327.1 -- INET-AS BT Italia S.p.A.,IT 19 - AS13188 17493 0.3% 24.6 -- BANKINFORM-AS CONTENT DELIVERY NETWORK LTD,UA 20 - AS6713 17413 0.3% 24.8 -- IAM-AS,MA TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS12897 1515794 26.4% 126316.2 -- HEAGMEDIANET HSE Medianet GmbH,DE 2 - AS14287 367120 6.4% 61186.7 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 3 - AS3 24068 0.4% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 4 - AS18135 12169 0.2% 12169.0 -- BTV BTV Cable television,JP 5 - AS61039 6890 0.1% 6890.0 -- ZMZ OAO ZMZ,RU 6 - AS47680 6251 0.1% 6251.0 -- NHCS EOBO Limited,IE 7 - AS62174 5782 0.1% 5782.0 -- INTERPAN-AS INTERPAN LTD.,BG 8 - AS23342 22257 0.4% 4451.4 -- UNITEDLAYER - Unitedlayer, Inc.,US 9 - AS60725 16065 0.3% 4016.2 -- O3B-AS O3b Limited,JE 10 - AS56636 2671 0.1% 2671.0 -- ASVEDARU VEDA Ltd.,RU 11 - AS53823 2406 0.0% 2406.0 -- SMTA - Scio Mutual Telephone Association,US 12 - AS23752 200084 3.5% 2041.7 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 13 - AS25003 20008 0.3% 1818.9 -- INTERNET_BINAT Internet Binat Ltd,IL 14 - AS30944 1712 0.0% 1712.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD",LT 15 - AS2 6234 0.1% 2423.0 -- UDEL-DCN - University of Delaware,US 16 - AS11728 1549 0.0% 1549.0 -- INTERNETXT - Internet Exchange Technology, Inc.,US 17 - AS22048 1379 0.0% 1379.0 -- WHOLE-FOODS - Whole Foods Market, Inc.,US 18 - AS53249 2696 0.1% 1348.0 -- LAWA-AS - Los Angeles World Airport,US 19 - AS6629 10227 0.2% 1278.4 -- NOAA-AS - NOAA,US 20 - AS38808 1246 0.0% 1246.0 -- IMZAK-TRANSIT-AS-AP DSL Service Provider Servers,PK TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 94.16.72.0/21 216945 3.6% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 2 - 94.16.80.0/20 216916 3.6% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 3 - 94.16.64.0/21 216747 3.6% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 4 - 185.9.28.0/22 216560 3.6% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 5 - 194.127.204.0/23 216282 3.6% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 6 - 194.99.108.0/23 216243 3.6% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 7 - 194.45.104.0/23 216096 3.6% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 8 - 202.70.88.0/21 101699 1.7% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 9 - 202.70.64.0/21 96915 1.6% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 10 - 208.70.20.0/22 73429 1.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 11 - 208.78.116.0/22 73421 1.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 12 - 208.73.244.0/22 73421 1.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 13 - 216.162.0.0/20 73421 1.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 14 - 208.88.232.0/22 73419 1.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 15 - 130.0.192.0/21 24068 0.4% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 16 - 64.29.130.0/24 22160 0.4% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 17 - 192.115.44.0/22 19988 0.3% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 18 - 42.83.48.0/20 12169 0.2% AS18135 -- BTV BTV Cable television,JP 19 - 71.19.134.0/23 11137 0.2% AS3313 -- INET-AS BT Italia S.p.A.,IT 20 - 192.58.232.0/24 10195 0.2% AS6629 -- NOAA-AS - NOAA,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From baconzombie at gmail.com Fri Nov 14 22:05:42 2014 From: baconzombie at gmail.com (Bacon Zombie) Date: Fri, 14 Nov 2014 23:05:42 +0100 Subject: Cisco CCNA Training (Udemy Discounted Training) In-Reply-To: References: Message-ID: Is that the codes can only be used during November or access to the training? On 14 Nov 2014 18:07, "Wakefield, Thad M." wrote: > Since there was some interest in the Udemy CCNA training, I'll risk > forwarding these additional discounts: > > Remember that this is ONLY for the month of NOVEMBER! > *** CCNA Course is now $24 with coupon code: THANKS24 > https://www.udemy.com/the-complete-ccna-200-120-course/?couponCode=THANKS24 > *** ROUTING Course is now $14 with coupon code: THANKS14 > > https://www.udemy.com/routing-configuration-router-administration/?couponCode=THANKS14 > *** SWITCHING Course is now $9 with coupon code: THANKS9 > https://www.udemy.com/layer-2-switching-vlans/?couponCode=THANKS9 > *** IPv4 Course is now $9 with coupon code: THANKS9 > > https://www.udemy.com/everything-you-need-to-know-about-ipv4-and-its-configuration/?couponCode=THANKS9 > *** IPv6 Course is now $9 with coupon code: THANKS9 > https://www.udemy.com/the_abcs_of_ipv6/?couponCode=THANKS9 > *** VLANs Course is now $5 with coupon code: THANKS5 > > https://www.udemy.com/overview-of-vlans-access-list-nat-bonus-material/?couponCode=THANKS5 > *** OSPF Course is now $14 with coupon code: THANKS14 > https://www.udemy.com/ospf-breakdown/?couponCode=THANKS14 > *** HEX Course is FREE *** use coupon code: THANKSFREE > > https://www.udemy.com/learn-how-to-do-hex-conversions-in-under-30-seconds/?couponCode=THANKSFREE > > From Bryan at bryanfields.net Fri Nov 14 22:43:18 2014 From: Bryan at bryanfields.net (Bryan Fields) Date: Fri, 14 Nov 2014 17:43:18 -0500 Subject: Google contact Message-ID: <54668586.6080907@bryanfields.net> I'm desperately in need of a Google postmaster contact. I've exhausted all their automated tools and received no reply or fix. Can some one hit me up off list? Thank you, -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From brandon.galbraith at gmail.com Fri Nov 14 18:34:16 2014 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 14 Nov 2014 12:34:16 -0600 Subject: Wireless Connectivity - Heber City, UT area Message-ID: Hello NANOG! I'm doing some research regarding short-term (~1 week) high speed (~10-15Mb down/at least 5Mbps up) wireless connectivity in the Heber City, UT area. The only provider I found was Blaze (http://www.blazewifi.com) (besides ILECs/incumbents). Does anyone have any experience with them? I'm also open to other provider suggestions I might be missing. The potential usage site is about 10 miles LOS east/south-east from downtown Heber City. Thank you! Brandon From zach at zachunderwood.me Fri Nov 14 23:58:46 2014 From: zach at zachunderwood.me (Zach Underwood) Date: Fri, 14 Nov 2014 18:58:46 -0500 Subject: Wireless Connectivity - Heber City, UT area In-Reply-To: References: Message-ID: To find a WISP look at https://www.goubiquiti.com/ http://www.towercoverage.com/northamericamap.asp http://www.wispa.org/find-a-wisp On Fri, Nov 14, 2014 at 1:34 PM, Brandon Galbraith < brandon.galbraith at gmail.com> wrote: > Hello NANOG! > > I'm doing some research regarding short-term (~1 week) high speed (~10-15Mb > down/at least 5Mbps up) wireless connectivity in the Heber City, UT area. > > The only provider I found was Blaze (http://www.blazewifi.com) (besides > ILECs/incumbents). Does anyone have any experience with them? I'm also open > to other provider suggestions I might be missing. The potential usage site > is about 10 miles LOS east/south-east from downtown Heber City. > > Thank you! > Brandon > -- Zach Underwood (RHCE,RHCSA,RHCT,UACA) greenvilletowers.com My website From nanog at jima.us Sat Nov 15 05:08:44 2014 From: nanog at jima.us (Jima) Date: Fri, 14 Nov 2014 22:08:44 -0700 Subject: Wireless Connectivity - Heber City, UT area In-Reply-To: References: Message-ID: <5466DFDC.2090709@jima.us> On 2014-11-14 11:34, Brandon Galbraith wrote: > I'm doing some research regarding short-term (~1 week) high speed (~10-15Mb > down/at least 5Mbps up) wireless connectivity in the Heber City, UT area. > > The only provider I found was Blaze (http://www.blazewifi.com) (besides > ILECs/incumbents). Does anyone have any experience with them? I'm also open > to other provider suggestions I might be missing. The potential usage site > is about 10 miles LOS east/south-east from downtown Heber City. Not to get too political, but is this for the Rainbow Family Gathering? (First thought based on location/duration.) I haven't dealt with Blaze, but depending on your event's tax status (NPO/charity?), you might be able to get some help from local-ish business. I know some of the ISPs in the Salt Lake valley have been known to do some pro bono work; I'm not sure about Utah County. (Google Fiber in Provo springs to mind, but I don't imagine there's any way you could get a signal down Provo Canyon or over the mountains.) Otherwise, Zach's suggestion aside, I'd see whether any businesses in Heber proper might be able to lend/sublet you bandwidth, and look into point-to-point wireless. Jima From tech-lists at packet-labs.net Sat Nov 15 16:34:31 2014 From: tech-lists at packet-labs.net (Jeremy Sliwinski) Date: Sat, 15 Nov 2014 11:34:31 -0500 Subject: TWC IPv6 access ... In-Reply-To: <546629BE.9070909@clegg.com> References: <546629BE.9070909@clegg.com> Message-ID: <54678097.5040802@packet-labs.net> On 11/14/2014 11:11 AM, Alan Clegg wrote: > On 11/14/14, 7:12 AM, Jorge Amodio wrote: >> Hi There, >> >> anybody seeing problems with TWC broadband access and IPv6? >> >> After a brief outage this morning I no longer have IPv6 in my residential >> line and don't see any IPv6 neighbor at the other end of the coax :-( > Apex, NC. Been out for about a week. I get a /128 for my router, but > no prefix delegation. > > AlanC > Raleigh, NC. I saw the same issue here. Restarted the IPv6 DHCP client on our Cisco router and PD came back immediately. -jay From me at anuragbhatia.com Sat Nov 15 22:41:16 2014 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sun, 16 Nov 2014 04:11:16 +0530 Subject: Route Science In-Reply-To: References: Message-ID: What is that? Never heard of that before. Some kind of routing data collection project? > On 14-Nov-2014, at 10:11 am, Greg Grabowski wrote: > > Does anyone still have a Route Science box running out there? Our > enterprise still has a box running and working. Just curious..;-) -- Anurag Bhatia http://anuragbhatia.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 872 bytes Desc: Message signed with OpenPGP using GPGMail URL: From clayton at MNSi.Net Sat Nov 15 22:44:44 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Sat, 15 Nov 2014 17:44:44 -0500 Subject: Route Science In-Reply-To: References: Message-ID: <1416091486_82690@surgemail.mnsi.net> http://www.computerweekly.com/news/2240046663/Google-chooses-RouteScience-Internet-technology At 05:41 PM 15/11/2014, Anurag Bhatia wrote: >What is that? Never heard of that before. Some kind of routing data >collection project? > > > > > > On 14-Nov-2014, at 10:11 am, Greg Grabowski wrote: > > > > Does anyone still have a Route Science box running out there? Our > > enterprise still has a box running and working. Just curious..;-) > > > > >-- >Anurag Bhatia >http://anuragbhatia.com > > > > > > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From mysidia at gmail.com Sun Nov 16 03:03:22 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 15 Nov 2014 21:03:22 -0600 Subject: Route Science In-Reply-To: <1416091486_82690@surgemail.mnsi.net> References: <1416091486_82690@surgemail.mnsi.net> Message-ID: On Sat, Nov 15, 2014 at 4:44 PM, Clayton Zekelman wrote: I would also wonder if someone has more details about how useful and good the Avaya/Routescience are in practice after significant time in deployment in the real world on a large network, were they worth whatever the price tag was to get and maintain ? Oh, and how about Border6 ? I believe they have marketing language claiming to be able to achieve some similar things, in regards to automatic path optimizations and rerouting. :) > > http://www.computerweekly.com/news/2240046663/Google-chooses-RouteScience-Internet-technology Yeah, there are always great news stories. But media tends to exagerate things, and I think when it comes to enterprise products it's strictly promotional. When was the last time you heard a followup news story on one of those sorts of things 1yr later about BigCo dropped "Vendor X" product because they felt it's no longer worth it, the savings were less than expected and did not exceed the cost of the product, the actual thing fell short of marketing claims, or didn't actually work out so well, etc, etc. > -- -JH From nogs at border6.com Sun Nov 16 10:34:36 2014 From: nogs at border6.com (Pawel Rybczyk) Date: Sun, 16 Nov 2014 11:34:36 +0100 Subject: Route Science In-Reply-To: <3799-b6.nogs.nanog-16112014031002-63@news.border6.com> References: <1416091486_82690@surgemail.mnsi.net> <3799-b6.nogs.nanog-16112014031002-63@news.border6.com> Message-ID: <54687DBC.3000003@border6.com> Hi, Thanks for mentioning our name. Our platform does routing optimization but also includes plug & play monitoring and reporting tools for network troubleshooting and planning. You can check our brochure at: http://www.border6.com/files/Border6_NSI_en.pdf Do not hesitate to contact me off-list, I’ll provide documentation and can run live demo. -- Regards, Pawel Rybczyk Regional Manager BORDER 6 sp. z o.o. pawel.rybczyk at border6.com office: +48 22 242 89 51 (ext.103) mobile: +48 664 300 375 On 11/16/2014 04:03 AM, Jimmy Hess wrote: > On Sat, Nov 15, 2014 at 4:44 PM, Clayton Zekelman wrote: > > I would also wonder if someone has more details about how useful and > good the Avaya/Routescience are in practice after significant time in > deployment in the real world on a large network, were they worth > whatever the price tag was to get and maintain ? > > Oh, and how about Border6 ? I believe they have marketing language > claiming to be able to achieve some similar things, in regards to > automatic path optimizations and rerouting. :) > >> >> http://www.computerweekly.com/news/2240046663/Google-chooses-RouteScience-Internet-technology > > Yeah, there are always great news stories. But media tends to > exagerate things, and I think when it comes to enterprise products > it's strictly promotional. When was the last time you heard a > followup news story on one of those sorts of things 1yr later about > BigCo dropped "Vendor X" product because they felt it's no longer > worth it, the savings were less than expected and did not exceed the > cost of the product, the actual thing fell short of marketing claims, > or didn't actually work out so well, etc, etc. > > > >> > -- > -JH > From eliezer at ngtech.co.il Sun Nov 16 13:14:49 2014 From: eliezer at ngtech.co.il (Eliezer Croitoru) Date: Sun, 16 Nov 2014 15:14:49 +0200 Subject: Linux router traffic monitoring, how? netflow? In-Reply-To: References: <5464E5CA.5030309@ngtech.co.il> Message-ID: <5468A349.8070803@ngtech.co.il> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks Wayne, I have used ntop in the past but was not very happy with the results and now I tried it once again and I am happy about it. It works and looks very nice. Eliezer On 11/14/2014 09:39 AM, Wayne Lee wrote: > Hello > > > I've used ntop in the past with great success. > > ntop.org > > > Regards > > Wayne -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUaKNJAAoJENxnfXtQ8ZQUp6IH/i9B0GgtpGa2humQediDs9E4 EdOEj0Wd1/0+U7KqiYZhHMmBDueCVRkekJ/MseisqmiRUzrcVY5YB3M5slXrRes2 7/6XVhovjdYIahzGeUf5sMmMJ8LBV3dQdCPndOwo0gh8HT+ZDJOjjjgQn55wsgtE kCcsW6fNGiSksXGD98jJty4O+WPSro6GPI5As+LV/jEfqJHDVH0dGeRIHlwRg1X6 BMlEU0NX/cSyLcYX4iktCZHDf9FgaNGtfjKBMwl/rIXgqSnoXUGOlUEi2auFQA8H 5U+GQeH7wQ2R/2SKUq8ajPY/vmS3O/Ig7z7OmjyOWtK6UbtWtetuw/EQW85cP3U= =7Q7D -----END PGP SIGNATURE----- From bedard.phil at gmail.com Sun Nov 16 15:42:27 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Sun, 16 Nov 2014 10:42:27 -0500 Subject: Route Science In-Reply-To: References: <1416091486_82690@surgemail.mnsi.net> Message-ID: <2C1C4FE0-62B6-4FDB-B2A3-F9D8B7DA519F@gmail.com> Didn't Avaya completely drop the old Route Science line at this point? Internap still sells their FCP appliance which does similar things and of course Internap has their own MIRO system they have been using for probably 15+ years now to optimize paths out of their own datacenters/colos. Like the fellow from Border6 mentioned you can get a wealth of information out of the systems along with the path optimization. Phil On 11/16/14, 3:03 AM, "Jimmy Hess" wrote: >On Sat, Nov 15, 2014 at 4:44 PM, Clayton Zekelman >wrote: > >I would also wonder if someone has more details about how useful and >good the Avaya/Routescience are in practice after significant time in >deployment in the real world on a large network, were they worth >whatever the price tag was to get and maintain ? > >Oh, and how about Border6 ? I believe they have marketing language >claiming to be able to achieve some similar things, in regards to >automatic path optimizations and rerouting. :) > >> >> >>http://www.computerweekly.com/news/2240046663/Google-chooses-RouteScience >>-Internet-technology > >Yeah, there are always great news stories. But media tends to >exagerate things, and I think when it comes to enterprise products >it's strictly promotional. When was the last time you heard a >followup news story on one of those sorts of things 1yr later about >BigCo dropped "Vendor X" product because they felt it's no longer >worth it, the savings were less than expected and did not exceed the >cost of the product, the actual thing fell short of marketing claims, >or didn't actually work out so well, etc, etc. > > > >> >-- >-JH From contact at winterei.se Sun Nov 16 15:48:41 2014 From: contact at winterei.se (Paul S.) Date: Mon, 17 Nov 2014 00:48:41 +0900 Subject: Route Science In-Reply-To: <2C1C4FE0-62B6-4FDB-B2A3-F9D8B7DA519F@gmail.com> References: <1416091486_82690@surgemail.mnsi.net> <2C1C4FE0-62B6-4FDB-B2A3-F9D8B7DA519F@gmail.com> Message-ID: <5468C759.1020104@winterei.se> There's another option called the Noction IRP. I've been told that it's a cheaper FCP replacement. On 11/17/2014 午前 12:42, Phil Bedard wrote: > Didn't Avaya completely drop the old Route Science line at this point? > > Internap still sells their FCP appliance which does similar things and of > course Internap has their own MIRO system they have been using for > probably 15+ years now to optimize paths out of their own > datacenters/colos. Like the fellow from Border6 mentioned you can get a > wealth of information out of the systems along with the path optimization. > > > Phil > > > > > On 11/16/14, 3:03 AM, "Jimmy Hess" wrote: > >> On Sat, Nov 15, 2014 at 4:44 PM, Clayton Zekelman >> wrote: >> >> I would also wonder if someone has more details about how useful and >> good the Avaya/Routescience are in practice after significant time in >> deployment in the real world on a large network, were they worth >> whatever the price tag was to get and maintain ? >> >> Oh, and how about Border6 ? I believe they have marketing language >> claiming to be able to achieve some similar things, in regards to >> automatic path optimizations and rerouting. :) >> >>> >>> http://www.computerweekly.com/news/2240046663/Google-chooses-RouteScience >>> -Internet-technology >> Yeah, there are always great news stories. But media tends to >> exagerate things, and I think when it comes to enterprise products >> it's strictly promotional. When was the last time you heard a >> followup news story on one of those sorts of things 1yr later about >> BigCo dropped "Vendor X" product because they felt it's no longer >> worth it, the savings were less than expected and did not exceed the >> cost of the product, the actual thing fell short of marketing claims, >> or didn't actually work out so well, etc, etc. >> >> >> >> -- >> -JH From tom at ninjabadger.net Sun Nov 16 23:54:39 2014 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 16 Nov 2014 23:54:39 +0000 Subject: 10Gb iPerf kit? In-Reply-To: References: <960646944.74409.1415666050031.JavaMail.zimbra@network1.net> <1473327677.74410.1415666119022.JavaMail.zimbra@network1.net> Message-ID: <5469393F.8060208@ninjabadger.net> On 11/11/14 00:49, Jason Lixfeld wrote: > I gotta wonder. How reliable is iPerf over something like RFC2544 or > Y.1564? Especially at those speeds? Apples and oranges? iperf tests a TCP connection (over v4 or v6) and 2544 runs Ethernet tests. Yes, both test throughput, but in very different ways. Arguably you only need one or the other -- but you work with what you have. > Anyone out there testing 10gbE with iPerf? If so, what are you using? As you say, server hardware is heavy to lug around -- but you can fit quite a lot of CPU in a Mini-ITX/uATX board these days, and newer boards even come with PCI-E 3.0 capable chipsets (Intel Z87). Given the right NIC (Intel, if I was buying one) and a recent Linux distro... I'd be surprised if a recent quad core CPU couldn't generate 10G based on what I've seen our servers do. -- Tom From jerome at ceriz.fr Mon Nov 17 18:11:48 2014 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Mon, 17 Nov 2014 19:11:48 +0100 Subject: A case against vendor-locking optical modules Message-ID: <546A3A64.6070705@ceriz.fr> Hello, I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules. My points are : - I need specific modules, mostly *WDM and BiDi, some still unavailable in their product line - I run at least two other vendors on every locations and can't stack up every spare optics for each of them, neither could remote-hands safely re-program optics to match a specific vendor when needed. - I have an established relationship with a trusted optics supplier, providing support, warranty and re-coding hardware for their entire (impressive) lineup. And this supplier is still 2-5x times cheaper than any vendor-labeled optics even with NFR-like discounts. Based on these points, I discourage every customers of ever using locked-in equipments, and forbid them on my own network. Of course, Arista can't be pleased because their hardware never stepped chord in my customer's networks. But they seem to deliberatly miss my points every time the subject comes up. What are other arguments against vendor lock-in ? Is there any argument FOR such locks (please spare me the support issues, if you can't read specs and SNMP, you shouldn't even try networking) ? Did you ever experience a shift in a vendor's position regarding the use of compatible modules ? Thanks ! -- Jérôme Nicolle +33 6 19 31 27 14 From SNaslund at medline.com Mon Nov 17 18:20:09 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 17 Nov 2014 18:20:09 +0000 Subject: A case against vendor-locking optical modules In-Reply-To: <546A3A64.6070705@ceriz.fr> References: <546A3A64.6070705@ceriz.fr> Message-ID: <9578293AE169674F9A048B2BC9A081B401572054A0@MUNPRDMBXA1.medline.com> Let talk about the 800 pound gorilla in the room and the #1 reason to hate vendor locked optics. Some vendors (yes, Cisco I'm looking at you) want to charge ridiculously high prices for optic that are identical to generic optics other than the vendor lock. Maybe a better tactic would be to have the vendor explain to you why the vendor lock is necessary. You are after all the customer and don't owe them any explanations. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jérôme Nicolle Sent: Monday, November 17, 2014 12:12 PM To: nanog at nanog.org Subject: A case against vendor-locking optical modules Hello, I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules. My points are : - I need specific modules, mostly *WDM and BiDi, some still unavailable in their product line - I run at least two other vendors on every locations and can't stack up every spare optics for each of them, neither could remote-hands safely re-program optics to match a specific vendor when needed. - I have an established relationship with a trusted optics supplier, providing support, warranty and re-coding hardware for their entire (impressive) lineup. And this supplier is still 2-5x times cheaper than any vendor-labeled optics even with NFR-like discounts. Based on these points, I discourage every customers of ever using locked-in equipments, and forbid them on my own network. Of course, Arista can't be pleased because their hardware never stepped chord in my customer's networks. But they seem to deliberatly miss my points every time the subject comes up. What are other arguments against vendor lock-in ? Is there any argument FOR such locks (please spare me the support issues, if you can't read specs and SNMP, you shouldn't even try networking) ? Did you ever experience a shift in a vendor's position regarding the use of compatible modules ? Thanks ! -- Jérôme Nicolle +33 6 19 31 27 14 From faisal at snappytelecom.net Mon Nov 17 18:28:48 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Mon, 17 Nov 2014 18:28:48 +0000 (GMT) Subject: A case against vendor-locking optical modules In-Reply-To: <9578293AE169674F9A048B2BC9A081B401572054A0@MUNPRDMBXA1.medline.com> References: <546A3A64.6070705@ceriz.fr> <9578293AE169674F9A048B2BC9A081B401572054A0@MUNPRDMBXA1.medline.com> Message-ID: <1545079773.489926.1416248928171.JavaMail.zimbra@snappytelecom.net> Vendor Lock's... this is nothing new, it has been in practice since the beginning of the IT / Computer Industry... We have seen this with Cables (old old days, Vax/PDP 11/ IBM Mainframes, well into the PC cycle), Floppy Drives, Hard Drivers etc etc etc... To the best of my knowledge, none of this was ever won by argument with the vendor...This always changed with time... When more and more people started deploying generic / non oem items, the vendors were forced to either turn a blind eye or forced to reconsider... The big carrot or stick, the vendors always held with the Customers / Consumers, was the warranty and or support. If history has any advice to offer, it would be, if you are not dependent on warranty or support issues from the Vendor, then go forward, do what you please, .. :) Regards. Faisal Imtiaz ----- Original Message ----- > From: "Steve Naslund" > To: nanog at nanog.org > Sent: Monday, November 17, 2014 1:20:09 PM > Subject: RE: A case against vendor-locking optical modules > > Let talk about the 800 pound gorilla in the room and the #1 reason to hate > vendor locked optics. Some vendors (yes, Cisco I'm looking at you) want to > charge ridiculously high prices for optic that are identical to generic > optics other than the vendor lock. Maybe a better tactic would be to have > the vendor explain to you why the vendor lock is necessary. You are after > all the customer and don't owe them any explanations. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jérôme Nicolle > Sent: Monday, November 17, 2014 12:12 PM > To: nanog at nanog.org > Subject: A case against vendor-locking optical modules > > Hello, > > I'm having a discussion with Arista, trying to explain to them why I _can't_ > buy any hardware unable to run with compatible optical modules. > > My points are : > > - I need specific modules, mostly *WDM and BiDi, some still unavailable in > their product line > > - I run at least two other vendors on every locations and can't stack up > every spare optics for each of them, neither could remote-hands safely > re-program optics to match a specific vendor when needed. > > - I have an established relationship with a trusted optics supplier, > providing support, warranty and re-coding hardware for their entire > (impressive) lineup. And this supplier is still 2-5x times cheaper than any > vendor-labeled optics even with NFR-like discounts. > > Based on these points, I discourage every customers of ever using locked-in > equipments, and forbid them on my own network. Of course, Arista can't be > pleased because their hardware never stepped chord in my customer's > networks. But they seem to deliberatly miss my points every time the subject > comes up. > > What are other arguments against vendor lock-in ? Is there any argument FOR > such locks (please spare me the support issues, if you can't read specs and > SNMP, you shouldn't even try networking) ? > > Did you ever experience a shift in a vendor's position regarding the use of > compatible modules ? > > Thanks ! > > -- > Jérôme Nicolle > +33 6 19 31 27 14 > From bill at herrin.us Mon Nov 17 18:54:11 2014 From: bill at herrin.us (William Herrin) Date: Mon, 17 Nov 2014 13:54:11 -0500 Subject: A case against vendor-locking optical modules In-Reply-To: <546A3A64.6070705@ceriz.fr> References: <546A3A64.6070705@ceriz.fr> Message-ID: On Mon, Nov 17, 2014 at 1:11 PM, Jérôme Nicolle wrote: > I'm having a discussion with Arista, trying to explain to them why I > _can't_ buy any hardware unable to run with compatible optical modules. Hi Jérôme, Change "can't" to "won't", because you find it inconvenient and insulting to work around artificial and costly problems created by your vendor. If you can't use their equipment then they haven't lost any business but if you _won't_ then they have. Then schedule a call with the CEO, not your salesman. The CEO probably doesn't understand it, probably caused it, and probably won't understand it when you're done talking. He will understand "customer ditching us over some subordinate's stupid behavior," and will assign someone more technical with instructions to redress the error. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From jerome at ceriz.fr Mon Nov 17 19:12:10 2014 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Mon, 17 Nov 2014 20:12:10 +0100 Subject: A case against vendor-locking optical modules In-Reply-To: <1545079773.489926.1416248928171.JavaMail.zimbra@snappytelecom.net> References: <546A3A64.6070705@ceriz.fr> <9578293AE169674F9A048B2BC9A081B401572054A0@MUNPRDMBXA1.medline.com> <1545079773.489926.1416248928171.JavaMail.zimbra@snappytelecom.net> Message-ID: <546A488A.3090400@ceriz.fr> Le 17/11/2014 19:28, Faisal Imtiaz a écrit : > If history has any advice to offer, it would be, if you are not > dependent on warranty or support issues from the Vendor, then go > forward, do what you please, .. Well, I could go on and re-code the optics, at least by simply cloning a few OEMs. But there is still the spare items issue. No datacenter remote-hands will accept any lyability in operating a recoder (wich, when not operated properly, can easily fry the module). So I have to keep multiple spares per module type, each beeing recoded and labelled for different vendors. Le 17/11/2014 19:54, William Herrin a écrit : > Change "can't" to "won't", because you find it inconvenient and > insulting to work around artificial and costly problems created by > your vendor. If you can't use their equipment then they haven't lost > any business but if you _won't_ then they have. Let's talk about the £800 gorilla in the room then : it's not an issue for a $20 LX SFP, it may be doable for a $120 LR SFP+, it's certainly not an option for an ER-DWDM SFP+ 8-40 waves set ($800 each). You're right about how inconvinient and insulting such restrictions feel, but my main concern is about costs, efficiency and logistics. Having to stock more spare optics, one per vendor, has its cost. Having to cheat the restriction by recoding the optics, also has costs in terms of time, tools and complexity. At the end of the day, everyone loses. Because it's absurd and induce more costs and complexity, I _can't_ fall into such trap. Because it's insulting and bordeline moronic to begin with, I certainly _won't_. Now, about discussing with a CEO, I'm not really sure it could be reached. Salesmen on the other hand have their own interest in both selling OEM modules to the corporate market, and unlocked equipments to the SP/telco market, to whom they won't sell anything otherwise. Is it unrealistic to hope for enough salesmen pressure on the corporate ladder to make such moronic attitude be reversed in the short term ? Best regards, -- Jérôme Nicolle +33 6 19 31 27 14 From Patrick.Darden at p66.com Mon Nov 17 19:13:47 2014 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Mon, 17 Nov 2014 13:13:47 -0600 Subject: A case against vendor-locking optical modules In-Reply-To: <546A3A64.6070705@ceriz.fr> References: <546A3A64.6070705@ceriz.fr> Message-ID: You say lock in, they say loyalty.... Tell them loyalty is two ways, and you need them to help you remain a loyal customer. To start with, a fantastic CLA. Make sure it includes 15 minute new optics delivery in case of failure (since you can't keep spares on-site as they are too expensive.) Technicians available without wait time to help you focus/finish/program them. Not instant response to take a ticket, followed by a call within 4 hours, but instant response by a knowledgeable tech who finishes the call by filling out a ticket. Etc. If they want vendor focused thinking on your part with concomitant committing of resources ($$), they need customer focused thinking on theirs. They want your loyalty, awesome... let them know what it will take. Remind them of how much money you will spend this year if they can get your lock in. I'm just singing here. --p -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jérôme Nicolle Sent: Monday, November 17, 2014 12:12 PM To: nanog at nanog.org Subject: [EXTERNAL]A case against vendor-locking optical modules Hello, I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules. My points are : - I need specific modules, mostly *WDM and BiDi, some still unavailable in their product line - I run at least two other vendors on every locations and can't stack up every spare optics for each of them, neither could remote-hands safely re-program optics to match a specific vendor when needed. - I have an established relationship with a trusted optics supplier, providing support, warranty and re-coding hardware for their entire (impressive) lineup. And this supplier is still 2-5x times cheaper than any vendor-labeled optics even with NFR-like discounts. Based on these points, I discourage every customers of ever using locked-in equipments, and forbid them on my own network. Of course, Arista can't be pleased because their hardware never stepped chord in my customer's networks. But they seem to deliberatly miss my points every time the subject comes up. What are other arguments against vendor lock-in ? Is there any argument FOR such locks (please spare me the support issues, if you can't read specs and SNMP, you shouldn't even try networking) ? Did you ever experience a shift in a vendor's position regarding the use of compatible modules ? Thanks ! -- Jérôme Nicolle +33 6 19 31 27 14 From bill at herrin.us Mon Nov 17 19:28:31 2014 From: bill at herrin.us (William Herrin) Date: Mon, 17 Nov 2014 14:28:31 -0500 Subject: A case against vendor-locking optical modules In-Reply-To: <546A488A.3090400@ceriz.fr> References: <546A3A64.6070705@ceriz.fr> <9578293AE169674F9A048B2BC9A081B401572054A0@MUNPRDMBXA1.medline.com> <1545079773.489926.1416248928171.JavaMail.zimbra@snappytelecom.net> <546A488A.3090400@ceriz.fr> Message-ID: On Mon, Nov 17, 2014 at 2:12 PM, Jérôme Nicolle wrote: > Le 17/11/2014 19:54, William Herrin a écrit : > > Change "can't" to "won't", because you find it inconvenient and > > insulting to work around artificial and costly problems created by > > your vendor. If you can't use their equipment then they haven't lost > > any business but if you _won't_ then they have. > > > Let's talk about the £800 gorilla in the room then : it's not an issue > for a $20 LX SFP, it may be doable for a $120 LR SFP+, it's certainly > not an option for an ER-DWDM SFP+ 8-40 waves set ($800 each). > > You're right about how inconvinient and insulting such restrictions > feel, but my main concern is about costs, efficiency and logistics. > > Having to stock more spare optics, one per vendor, has its cost. Having > to cheat the restriction by recoding the optics, also has costs in terms > of time, tools and complexity. At the end of the day, everyone loses. > > Because it's absurd and induce more costs and complexity, I _can't_ fall > into such trap. Because it's insulting and bordeline moronic to begin > with, I certainly _won't_. Have they had a bad quarter because they carelessly induced indirect costs which priced them out of the market? This is something their CEO would like to know about. > Now, about discussing with a CEO, I'm not really sure it could be > reached. Salesmen on the other hand have their own interest in both > selling OEM modules to the corporate market, and unlocked equipments to > the SP/telco market, to whom they won't sell anything otherwise. You'd be surprised how reachable CEOs are, but if you have any trouble making an appointment, call the CFO instead. CFO's are lonely. Almost nobody ever calls them. The CFO will take the call from a customer/investor, and unlike your salesman the CFO has the CEO's ear. And if he's had a bad quarter, the CFO is even more in tune with the idea that an indirect cost (which makes them no direct money) caused you not to buy. > Is it unrealistic to hope for enough salesmen pressure on the corporate > ladder to make such moronic attitude be reversed in the short term ? Your salesman is not a corporate warrior. He spends his time working the lowest hanging fruit he can find. Unless you have a *lot* of money to spend, that isn't a customer who requires a change to corporate policy. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From svoll.voip at gmail.com Mon Nov 17 19:49:11 2014 From: svoll.voip at gmail.com (Scott Voll) Date: Mon, 17 Nov 2014 11:49:11 -0800 Subject: A case against vendor-locking optical modules In-Reply-To: <546A3A64.6070705@ceriz.fr> References: <546A3A64.6070705@ceriz.fr> Message-ID: I've asked the same question and got the answer that there is a REAL BIG chip manufacture that was having huge system issue and told the vendor that they were going to rip out all the manufactures routing / switching equipment if they didn't get it fixed. after the manufacture send engineering staff on site they found that the problem was not the routers or switches but the SFP's that the Chip manufacture had purchased. After replacing the SFP's they had no problems. So if you were the router manufacture you might also put in the locks....... Just say'n I hate it also, but I also really like a stable network. I also know that there are some OEM's for even Cisco that I have used in the past. Just my two cents. Scott On Mon, Nov 17, 2014 at 10:11 AM, Jérôme Nicolle wrote: > Hello, > > I'm having a discussion with Arista, trying to explain to them why I > _can't_ buy any hardware unable to run with compatible optical modules. > > My points are : > > - I need specific modules, mostly *WDM and BiDi, some still unavailable > in their product line > > - I run at least two other vendors on every locations and can't stack up > every spare optics for each of them, neither could remote-hands safely > re-program optics to match a specific vendor when needed. > > - I have an established relationship with a trusted optics supplier, > providing support, warranty and re-coding hardware for their entire > (impressive) lineup. And this supplier is still 2-5x times cheaper than > any vendor-labeled optics even with NFR-like discounts. > > Based on these points, I discourage every customers of ever using > locked-in equipments, and forbid them on my own network. Of course, > Arista can't be pleased because their hardware never stepped chord in my > customer's networks. But they seem to deliberatly miss my points every > time the subject comes up. > > What are other arguments against vendor lock-in ? Is there any argument > FOR such locks (please spare me the support issues, if you can't read > specs and SNMP, you shouldn't even try networking) ? > > Did you ever experience a shift in a vendor's position regarding the use > of compatible modules ? > > Thanks ! > > -- > Jérôme Nicolle > +33 6 19 31 27 14 > From clayton at MNSi.Net Mon Nov 17 19:57:34 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Mon, 17 Nov 2014 14:57:34 -0500 Subject: A case against vendor-locking optical modules In-Reply-To: References: <546A3A64.6070705@ceriz.fr> Message-ID: <1416254255_96623@surgemail.mnsi.net> At 02:49 PM 17/11/2014, Scott Voll wrote: >I've asked the same question and got the answer that there is a REAL BIG >chip manufacture that was having huge system issue and told the vendor that >they were going to rip out all the manufactures routing / switching >equipment if they didn't get it fixed. > >after the manufacture send engineering staff on site they found that the >problem was not the routers or switches but the SFP's that the Chip >manufacture had purchased. After replacing the SFP's they had no problems. > I've heard that explanation a number of times in various forms. I suspect it was an explanation crafted to counter the argument. Regardless, it should have been simple enough to rule out the optics with proper diagnostics and swapping out of suspect units. The real reason of course is margin http://www.lightreading.com/optical/optical-components/ciscos-secret-franchise/d/d-id/631651 --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From SNaslund at medline.com Mon Nov 17 19:59:49 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 17 Nov 2014 19:59:49 +0000 Subject: A case against vendor-locking optical modules In-Reply-To: References: <546A3A64.6070705@ceriz.fr> Message-ID: <9578293AE169674F9A048B2BC9A081B401572055E9@MUNPRDMBXA1.medline.com> That is their most popular argument. However this is no different from putting a NIC card. RAM, or hard drives in a server platform. For that matter, do you blame the network vendor if you have a faulty optical cable? In your example, can you be sure that the SFP was the issue? You can't be because someone obviously did not follow the standards for the SFP interface, was it the network gear or the SFP itself. Just because brand X does not work with switch Y does not make it brand Xs fault. Obviously if there is a flaw in the NIC, the server guys should not get blamed. Just as there are standards for USB, PCI, SATA, and other, there are standards for SFP and SFP+ interfaces. If the optic vendor is not compliant, that's their problem and if your network gear does not accept any optic that complies with the standard that is the network gear's fault. Consider how you would feel if HP servers only accepted HP hard drives or would not accept an Intel NIC, would you accept that? Steven Naslund Chicago IL >I've asked the same question and got the answer that there is a REAL BIG chip manufacture that was having huge system issue and told the vendor that they were going to rip out all the manufactures routing / switching equipment if >they didn't get it fixed. >after the manufacture send engineering staff on site they found that the problem was not the routers or switches but the SFP's that the Chip manufacture had purchased. After replacing the SFP's they had no problems. >So if you were the router manufacture you might also put in the locks....... Just say'n >I hate it also, but I also really like a stable network. I also know that there are some OEM's for even Cisco that I have used in the past. >Just my two cents. >Scott From ryan.landry at gmail.com Mon Nov 17 20:09:21 2014 From: ryan.landry at gmail.com (ryanL) Date: Mon, 17 Nov 2014 12:09:21 -0800 Subject: A case against vendor-locking optical modules In-Reply-To: <9578293AE169674F9A048B2BC9A081B401572055E9@MUNPRDMBXA1.medline.com> References: <546A3A64.6070705@ceriz.fr> <9578293AE169674F9A048B2BC9A081B401572055E9@MUNPRDMBXA1.medline.com> Message-ID: there's a reason why cisco introduced "service unsupported-transceiver", which still remains an undocumented command. i have arista gear as well. kinda wish they had a similar undocumented command. From drew.weaver at thenap.com Mon Nov 17 20:24:28 2014 From: drew.weaver at thenap.com (Drew Weaver) Date: Mon, 17 Nov 2014 20:24:28 +0000 Subject: Route Science In-Reply-To: References: Message-ID: As someone that used the routescience/avaya product for 6-7 years and then also demoed the IRP I can tell you that the IRP has a lot of similar functionality that the routescience/avaya CNA product had. The nice thing about the Noction product (the demo at least?) is that you aren't locked into an ancient IBM xServer with a 32 bit kernel like you were with the Avaya product. You can install it on your own machines, so in theory it should be possible to scale it. Scaling was the only reason we decommissioned our CNA, otherwise we'd still be using it. -Drew -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Greg Grabowski Sent: Thursday, November 13, 2014 11:41 PM To: nanog at nanog.org Subject: Route Science Does anyone still have a Route Science box running out there? Our enterprise still has a box running and working. Just curious..;-) From streiner at cluebyfour.org Mon Nov 17 20:31:31 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 17 Nov 2014 15:31:31 -0500 (EST) Subject: A case against vendor-locking optical modules In-Reply-To: <546A3A64.6070705@ceriz.fr> References: <546A3A64.6070705@ceriz.fr> Message-ID: On Mon, 17 Nov 2014, Jérôme Nicolle wrote: > What are other arguments against vendor lock-in ? Is there any argument > FOR such locks (please spare me the support issues, if you can't read > specs and SNMP, you shouldn't even try networking) ? > > Did you ever experience a shift in a vendor's position regarding the use > of compatible modules ? In the case of some vendors (yes, you again, Cisco), the shift has been in the wrong direction. Some vendors treat optics as just a tool to do a job, and price accordingly. Those vendors tend to have fairly relaxed policies re: working with non-$vendor optics, as well. Other vendors treat optics as a cash cow^H^H^H^H^H^H^H^Hprofit center, and also price accordingly. Those vendors tend to scream bloody murder if a non-$vendor optic is encountered. Beyond that, I'd say you've covered all of the logical reasons why vendor lock-in is a bad idea, but as others have mentioned in this thread, those attitudes tend to change at a ridiculously slow pace, and only when forced by market conditions. jms From streiner at cluebyfour.org Mon Nov 17 20:34:50 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 17 Nov 2014 15:34:50 -0500 (EST) Subject: A case against vendor-locking optical modules In-Reply-To: <546A488A.3090400@ceriz.fr> References: <546A3A64.6070705@ceriz.fr> <9578293AE169674F9A048B2BC9A081B401572054A0@MUNPRDMBXA1.medline.com> <1545079773.489926.1416248928171.JavaMail.zimbra@snappytelecom.net> <546A488A.3090400@ceriz.fr> Message-ID: On Mon, 17 Nov 2014, Jérôme Nicolle wrote: > Is it unrealistic to hope for enough salesmen pressure on the corporate > ladder to make such moronic attitude be reversed in the short term ? No salesperson is likely to do that for you. They know only to well that eliminating vendor lock-in means they will lose sales on artificially costly optics from $vendor to a lower-cost rival. Less sales = less commission for the affected sales person. jms From Valdis.Kletnieks at vt.edu Mon Nov 17 20:44:59 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 17 Nov 2014 15:44:59 -0500 Subject: A case against vendor-locking optical modules In-Reply-To: Your message of "Mon, 17 Nov 2014 15:34:50 -0500." References: <546A3A64.6070705@ceriz.fr> <9578293AE169674F9A048B2BC9A081B401572054A0@MUNPRDMBXA1.medline.com> <1545079773.489926.1416248928171.JavaMail.zimbra@snappytelecom.net> <546A488A.3090400@ceriz.fr> Message-ID: <80801.1416257099@turing-police.cc.vt.edu> On Mon, 17 Nov 2014 15:34:50 -0500, "Justin M. Streiner" said: > No salesperson is likely to do that for you. They know only to well that > eliminating vendor lock-in means they will lose sales on artificially > costly optics from $vendor to a lower-cost rival. Less sales = less > commission for the affected sales person. I suspect that losing the commission on a few $6digit chassis sales is worse than losing the commission on a $3digit optic? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From streiner at cluebyfour.org Mon Nov 17 20:50:08 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 17 Nov 2014 15:50:08 -0500 (EST) Subject: A case against vendor-locking optical modules In-Reply-To: <80801.1416257099@turing-police.cc.vt.edu> References: <546A3A64.6070705@ceriz.fr> <9578293AE169674F9A048B2BC9A081B401572054A0@MUNPRDMBXA1.medline.com> <1545079773.489926.1416248928171.JavaMail.zimbra@snappytelecom.net> <546A488A.3090400@ceriz.fr> <80801.1416257099@turing-police.cc.vt.edu> Message-ID: On Mon, 17 Nov 2014, Valdis.Kletnieks at vt.edu wrote: > On Mon, 17 Nov 2014 15:34:50 -0500, "Justin M. Streiner" said: > >> No salesperson is likely to do that for you. They know only to well that >> eliminating vendor lock-in means they will lose sales on artificially >> costly optics from $vendor to a lower-cost rival. Less sales = less >> commission for the affected sales person. > > I suspect that losing the commission on a few $6digit chassis sales is worse > than losing the commission on a $3digit optic? That turns into a forest > trees problem. Many salescritters don't think about the larger picture, or the responsible business units don't care about what affects other business units. Also, in the 10G-and-up world, most of those optics are a lot more than $3digits. jms From jradke at canbytel.com Mon Nov 17 21:11:11 2014 From: jradke at canbytel.com (Radke, Justin) Date: Mon, 17 Nov 2014 13:11:11 -0800 Subject: DNS Lookup - Filter "localhost" Message-ID: This past weekend we started receiving bursts of lookups on our DNS server for "localhost." We blocked our subscriber abusing this lookup (most assuredly malware and not intentional) but curious what safeguards you put in place for DOS attacks on your DNS servers. 1. As an ISP do you see a problem with blocking localhost on your DNS servers? (we don't see any validity to these requests but checking with you to see if we've overlooked something). 2. Do you have an actual localhost zone that issues 127.0.0.1? 3. Do you block >512 Bytes DNS requests? 4. Do you block non-UDP DNS requests or rate-limit requests? 5. Anything else you block/filter on your DNS servers? -=JGR From nick at foobar.org Mon Nov 17 21:19:48 2014 From: nick at foobar.org (Nick Hilliard) Date: Mon, 17 Nov 2014 21:19:48 +0000 Subject: A case against vendor-locking optical modules In-Reply-To: <546A3A64.6070705@ceriz.fr> References: <546A3A64.6070705@ceriz.fr> Message-ID: <546A6674.3080407@foobar.org> On 17/11/2014 18:11, Jérôme Nicolle wrote: > What are other arguments against vendor lock-in ? Is there any argument > FOR such locks (please spare me the support issues, if you can't read > specs and SNMP, you shouldn't even try networking) ? there have been documented cases in the past where transceivers have had serious problems working on kit, where those problems have ranged from the transceivers simply not working correctly to the network devices crashing and rebooting. The kit vendor gets the blame in all situations, even though it's not always their fault. Ultimately, transceivers are devices which need device drivers to work properly. I haven't seen any driver code for handling them, but if you take a look at any other device driver, you'll probably notice that a good chunk of the code is spend dealing with quirks and device-specific weirdness. From talking to vendors, I understand that the situation is much the same with optical transceivers. So there are some technical reasons for being cautious about this, particular at the early stage of transceiver development. Having said that, most vendors use transceiver lock-out for strictly commercial purposes and will refuse to enable full functionality on third party kit as a matter of policy. Bear it in mind that for every customer who doesn't accept this, the vendor will make 10x as much cash with this policy by applying it to enterprise and public sector. > Did you ever experience a shift in a vendor's position regarding the use > of compatible modules ? No, but I've never had the opportunity to wave $100m at a vendor either. These days I buy blank transceivers from a reputable third party vendor, and recode them in-house as appropriate for whatever kit we need to use them in. This works well for me, but other people will have different policies which work well for them. Nick From jethro.binks at strath.ac.uk Mon Nov 17 21:37:22 2014 From: jethro.binks at strath.ac.uk (Jethro R Binks) Date: Mon, 17 Nov 2014 21:37:22 +0000 (GMT) Subject: A case against vendor-locking optical modules In-Reply-To: <9578293AE169674F9A048B2BC9A081B401572054A0@MUNPRDMBXA1.medline.com> References: <546A3A64.6070705@ceriz.fr> <9578293AE169674F9A048B2BC9A081B401572054A0@MUNPRDMBXA1.medline.com> Message-ID: On Mon, 17 Nov 2014, Naslund, Steve wrote: > Let talk about the 800 pound gorilla in the room and the #1 reason to > hate vendor locked optics. Some vendors (yes, Cisco I'm looking at you) > want to charge ridiculously high prices for optic that are identical to > generic optics other than the vendor lock. Maybe a better tactic would > be to have the vendor explain to you why the vendor lock is necessary. > You are after all the customer and don't owe them any explanations. The Packetpushers recently discussed this issue: http://packetpushers.net/ps-show-35-oem-sfp-qsfp-modules-work/ Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. From list at satchell.net Mon Nov 17 22:06:17 2014 From: list at satchell.net (Stephen Satchell) Date: Mon, 17 Nov 2014 14:06:17 -0800 Subject: DNS Lookup - Filter "localhost" In-Reply-To: References: Message-ID: <546A7159.90806@satchell.net> On 11/17/2014 01:11 PM, Radke, Justin wrote: > This past weekend we started receiving bursts of lookups on our DNS server > for "localhost." We blocked our subscriber abusing this lookup (most > assuredly malware and not intentional) but curious what safeguards you put > in place for DOS attacks on your DNS servers. > > 1. As an ISP do you see a problem with blocking localhost on your DNS > servers? (we don't see any validity to these requests but checking with you > to see if we've overlooked something). Not really > 2. Do you have an actual localhost zone that issues 127.0.0.1? Yes > 3. Do you block >512 Bytes DNS requests? No. > 4. Do you block non-UDP DNS requests or rate-limit requests? Yes > 5. Anything else you block/filter on your DNS servers? block/limit "any" queries block/limit "root NS" queries block anycast/broadcast source address packets block fragmented packets From matlockken at gmail.com Mon Nov 17 22:37:08 2014 From: matlockken at gmail.com (Ken Matlock) Date: Mon, 17 Nov 2014 15:37:08 -0700 Subject: A case against vendor-locking optical modules In-Reply-To: References: <546A3A64.6070705@ceriz.fr> <9578293AE169674F9A048B2BC9A081B401572055E9@MUNPRDMBXA1.medline.com> Message-ID: On Mon, Nov 17, 2014 at 1:09 PM, ryanL wrote: > there's a reason why cisco introduced "service unsupported-transceiver", > which still remains an undocumented command. i have arista gear as well. > kinda wish they had a similar undocumented command. > Arista does have it (at least in older codes, no idea if it still works). http://serverfault.com/questions/281534/what-is-the-command-to-enable-3rd-party-sfp-transceivers-on-arista-switch One note: I did not have to reboot the switch for it to work. That took care of *most* 3rd-party optics, but I seem to recall it didn't cover 100%. Ken From jerome at ceriz.fr Mon Nov 17 22:56:45 2014 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Mon, 17 Nov 2014 23:56:45 +0100 Subject: A case against vendor-locking optical modules In-Reply-To: References: <546A3A64.6070705@ceriz.fr> <9578293AE169674F9A048B2BC9A081B401572055E9@MUNPRDMBXA1.medline.com> Message-ID: <546A7D2D.20707@ceriz.fr> Le 17/11/2014 21:09, ryanL a écrit : > kinda wish they had a similar undocumented command. Well, there is a command, and you can automate it's application. See https://gist.github.com/agh/932bbd1f74d312573925 . Can't tell if DOM is supported on 3rd party. -- Jérôme Nicolle +33 6 19 31 27 14 From patrick at ianai.net Mon Nov 17 23:17:27 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 17 Nov 2014 18:17:27 -0500 Subject: A case against vendor-locking optical modules In-Reply-To: <546A6674.3080407@foobar.org> References: <546A3A64.6070705@ceriz.fr> <546A6674.3080407@foobar.org> Message-ID: <6F314212-743E-4A2D-B0A2-B9D4FDA6098D@ianai.net> This is an interesting thread, but the actual winning strategy was only tangentially mentioned. Q: How do you get a vendor to change? A: Everyone stop buying that vendor's gear. It's a simple business decision. If the profit dollars of the people who stick around with locked optics are greater than the profit dollars of everyone buying without, guess what a vendor will do? (I'm ignoring a ton of second-order effects, such as having enough kit in production to be considered ubiquitous, since most companies can't think that far ahead.) You like Arista for price, density, etc.? Then factor in the cost (OpEx & CapEx) of vendor-specific optics and see if they still make sense. Don't just look at the per-port cost of the blade. See, it's a simple business decision for you too. Besides, what's wrong with using something (as Nick mentioned) like FlexOptics programmable optics? Haven't tried it in Arista, but other kit works fine. -- TTFN, patrick > On Nov 17, 2014, at 16:19 , Nick Hilliard wrote: > > On 17/11/2014 18:11, Jérôme Nicolle wrote: >> What are other arguments against vendor lock-in ? Is there any argument >> FOR such locks (please spare me the support issues, if you can't read >> specs and SNMP, you shouldn't even try networking) ? > > there have been documented cases in the past where transceivers have had > serious problems working on kit, where those problems have ranged from the > transceivers simply not working correctly to the network devices crashing > and rebooting. The kit vendor gets the blame in all situations, even > though it's not always their fault. > > Ultimately, transceivers are devices which need device drivers to work > properly. I haven't seen any driver code for handling them, but if you > take a look at any other device driver, you'll probably notice that a good > chunk of the code is spend dealing with quirks and device-specific > weirdness. From talking to vendors, I understand that the situation is > much the same with optical transceivers. So there are some technical > reasons for being cautious about this, particular at the early stage of > transceiver development. > > Having said that, most vendors use transceiver lock-out for strictly > commercial purposes and will refuse to enable full functionality on third > party kit as a matter of policy. Bear it in mind that for every customer > who doesn't accept this, the vendor will make 10x as much cash with this > policy by applying it to enterprise and public sector. > >> Did you ever experience a shift in a vendor's position regarding the use >> of compatible modules ? > > No, but I've never had the opportunity to wave $100m at a vendor either. > > These days I buy blank transceivers from a reputable third party vendor, > and recode them in-house as appropriate for whatever kit we need to use > them in. This works well for me, but other people will have different > policies which work well for them. > > Nick From anders at abundo.se Mon Nov 17 22:49:00 2014 From: anders at abundo.se (=?UTF-8?B?QW5kZXJzIEzDtndpbmdlcg==?=) Date: Mon, 17 Nov 2014 23:49:00 +0100 Subject: DNS Lookup - Filter "localhost" In-Reply-To: <546A7159.90806@satchell.net> References: <546A7159.90806@satchell.net> Message-ID: <546A7B5C.3050104@abundo.se> >> 4. Do you block non-UDP DNS requests or rate-limit requests? > > Yes Why? RFC5966 DNS Transport over TCP - Implementation Requirements You make it very hard for DNSSEC >> 5. Anything else you block/filter on your DNS servers? > > block fragmented packets Why? You then block EDNS0, which DNSSEC uses. (UDP packets up to 4096 bytes, then TCP) /Anders From jerome at ceriz.fr Tue Nov 18 00:02:42 2014 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Tue, 18 Nov 2014 01:02:42 +0100 Subject: A case against vendor-locking optical modules In-Reply-To: <6F314212-743E-4A2D-B0A2-B9D4FDA6098D@ianai.net> References: <546A3A64.6070705@ceriz.fr> <546A6674.3080407@foobar.org> <6F314212-743E-4A2D-B0A2-B9D4FDA6098D@ianai.net> Message-ID: <546A8CA2.2090006@ceriz.fr> Hello Patrick, Le 18/11/2014 00:17, Patrick W. Gilmore a écrit : > You like Arista for price, density, etc.? Then factor in the cost > (OpEx & CapEx) of vendor-specific optics and see if they still make > sense. Don't just look at the per-port cost of the blade. See, it's a > simple business decision for you too. You got my point : I do care about per-port cost, but the actual cost is a composite of : - kit price - licences - optics - spare optics - power per port over expected run time - collocation space > Besides, what's wrong with using something (as Nick mentioned) like > FlexOptics programmable optics? Haven't tried it in Arista, but other > kit works fine. Programmable optics are fine, but then you'd have to keep your programming gear available and train your techniciens on it, or keep pre-coded spares for every locked manufacturers. It's probably fine in a pure DC environment with few locations and only one SFP+ type, but it's rapidly a total mess when you have to manage 40 channels for 3 module types over dozens of locations AND the added manufacturer specific pain-in-the-ass. -- Jérôme Nicolle +33 6 19 31 27 14 From SNaslund at medline.com Tue Nov 18 00:39:50 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 18 Nov 2014 00:39:50 +0000 Subject: A case against vendor-locking optical modules In-Reply-To: References: <546A3A64.6070705@ceriz.fr> <9578293AE169674F9A048B2BC9A081B401572055E9@MUNPRDMBXA1.medline.com>, Message-ID: <5B990071-0507-43AC-87DA-980F81FE809F@medline.com> Our experience using that command has been mixed enough to be unreliable for production. Problems include error disabled interfaces refusing to come back online and the command not surviving a power cycle. Use with caution. Steven Naslund Chicago IL > On Nov 17, 2014, at 2:11 PM, "ryanL" wrote: > > there's a reason why cisco introduced "service unsupported-transceiver", > which still remains an undocumented command. i have arista gear as well. > kinda wish they had a similar undocumented command. From drc at virtualized.org Tue Nov 18 00:46:03 2014 From: drc at virtualized.org (David Conrad) Date: Mon, 17 Nov 2014 16:46:03 -0800 Subject: DNS Lookup - Filter "localhost" In-Reply-To: <546A7159.90806@satchell.net> References: <546A7159.90806@satchell.net> Message-ID: <719DE5DC-7CE7-4B48-A108-4B9C4C0CB068@virtualized.org> >> 3. Do you block >512 Bytes DNS requests? How many > 512 byte DNS requests are people seeing? Perhaps the requester meant > 512 byte DNS responses? Blocking > 512 byte responses would be ... unfortunate. >> 4. Do you block non-UDP DNS requests or rate-limit requests? > Yes I presume (hope) the "yes" applies rate limiting? Blocking non-UDP DNS is a bad idea. As RFC 5966 states: "... it should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) may result in resolution failure and/or application-level timeouts." > block anycast/broadcast source address packets How do you know if a source address is an anycast address? > block fragmented packets Why would you want to block fragmented packets? Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dot at dotat.at Tue Nov 18 10:25:28 2014 From: dot at dotat.at (Tony Finch) Date: Tue, 18 Nov 2014 10:25:28 +0000 Subject: DNS Lookup - Filter "localhost" In-Reply-To: References: Message-ID: Radke, Justin wrote: > > 2. Do you have an actual localhost zone that issues 127.0.0.1? Yes. I think this is best practice though it isn't required by RFC 6303 and isn't set up by default in BIND like the empty reverse DNS zones. > 3. Do you block >512 Bytes DNS requests? 512 byte requests are unlikely to be valid. Blocking >512 byte answers breaks the DNS. > 4. Do you block non-UDP DNS requests or rate-limit requests? Blocking TCP requests breaks the DNS. See RFC 5966. > 5. Anything else you block/filter on your DNS servers? Have a look at these slides, especially the last 12 on mitigating abuse of recursive servers. http://www.isc.org/wp-content/uploads/2014/11/DNS-RRL-LISA14.pdf Tony. -- f.anthony.n.finch http://dotat.at/ Northeast Viking, North Utsire: Southeasterly becoming variable, 3 or 4. Slight or moderate. Showers. Good. From rdobbins at arbor.net Tue Nov 18 16:32:38 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 18 Nov 2014 23:32:38 +0700 Subject: Brian Krebs' new book is out. Message-ID: <9E39C60C-E718-49CE-8786-67D5A2991896@arbor.net> This is an important book - well worth your time, and, more importantly, accessible to non-specialists (such as BDMs): 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. ----------------------------------- Roland Dobbins From maxtul at netassist.ua Mon Nov 17 18:24:56 2014 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 17 Nov 2014 20:24:56 +0200 Subject: A case against vendor-locking optical modules In-Reply-To: <546A3A64.6070705@ceriz.fr> References: <546A3A64.6070705@ceriz.fr> Message-ID: <546A3D78.1030605@netassist.ua> Hello, TheWorldMainBusinessRule says: "Don't work with morons!!!" Never. In any way. Even if it seems for the first look they give you prices and offers times better than normal people. Just don't even think. :) On 17.11.14 20:11, Jérôme Nicolle wrote: > Hello, > > I'm having a discussion with Arista, trying to explain to them why I > _can't_ buy any hardware unable to run with compatible optical modules. > > My points are : > > - I need specific modules, mostly *WDM and BiDi, some still unavailable > in their product line > > - I run at least two other vendors on every locations and can't stack up > every spare optics for each of them, neither could remote-hands safely > re-program optics to match a specific vendor when needed. > > - I have an established relationship with a trusted optics supplier, > providing support, warranty and re-coding hardware for their entire > (impressive) lineup. And this supplier is still 2-5x times cheaper than > any vendor-labeled optics even with NFR-like discounts. > > Based on these points, I discourage every customers of ever using > locked-in equipments, and forbid them on my own network. Of course, > Arista can't be pleased because their hardware never stepped chord in my > customer's networks. But they seem to deliberatly miss my points every > time the subject comes up. > > What are other arguments against vendor lock-in ? Is there any argument > FOR such locks (please spare me the support issues, if you can't read > specs and SNMP, you shouldn't even try networking) ? > > Did you ever experience a shift in a vendor's position regarding the use > of compatible modules ? > > Thanks ! > From baldur.norddahl at gmail.com Tue Nov 18 18:40:31 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 18 Nov 2014 19:40:31 +0100 Subject: A case against vendor-locking optical modules In-Reply-To: <546A3D78.1030605@netassist.ua> References: <546A3A64.6070705@ceriz.fr> <546A3D78.1030605@netassist.ua> Message-ID: If they really wanted to lock you in, they would have triangular modules instead of square... Or I suppose the vendors like to be able to shop around for modules, before they relabel and sell them to you at a 10x markup. From SNaslund at medline.com Tue Nov 18 19:05:07 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 18 Nov 2014 19:05:07 +0000 Subject: A case against vendor-locking optical modules In-Reply-To: References: <546A3A64.6070705@ceriz.fr> <546A3D78.1030605@netassist.ua>, Message-ID: <23296590-4175-4148-B16C-2D550BDC176E@medline.com> They want the ability to buy off the shelf components when they manufacture. They just don't want you to have the same privilege when you purchase. Your switches and routers are made of a bunch of OEM components with some custom programmed ASICS and some secret sauce. If they used non standard interface specs their costs would go through the roof as their power supplies, memory, storage, and NICS would be all custom development. Steven Naslund Chicago IL > On Nov 18, 2014, at 12:42 PM, "Baldur Norddahl" wrote: > > If they really wanted to lock you in, they would have triangular modules > instead of square... > > Or I suppose the vendors like to be able to shop around for modules, before > they relabel and sell them to you at a 10x markup. From rpug at lp0.org Tue Nov 18 21:18:01 2014 From: rpug at lp0.org (Ryan Pugatch) Date: Tue, 18 Nov 2014 16:18:01 -0500 Subject: A case against vendor-locking optical modules In-Reply-To: <546A8CA2.2090006@ceriz.fr> References: <546A3A64.6070705@ceriz.fr> <546A6674.3080407@foobar.org> <6F314212-743E-4A2D-B0A2-B9D4FDA6098D@ianai.net> <546A8CA2.2090006@ceriz.fr> Message-ID: <1416345481.388186.192608309.3428F5F5@webmail.messagingengine.com> On Mon, Nov 17, 2014, at 07:02 PM, Jérôme Nicolle wrote: > > It's probably fine in a pure DC environment with few locations and only > one SFP+ type, but it's rapidly a total mess when you have to manage 40 > channels for 3 module types over dozens of locations AND the added > manufacturer specific pain-in-the-ass. > > -- > Jérôme Nicolle > +33 6 19 31 27 14 So my question is, to Patrick's point, if you factor in the costs of managing this versus the costs of going with someone else who does not lock you in, is it worth it? Insert comment about TCO and ROI here, etc. -- Ryan Pugatch rpug at lp0.org Boston, MA on the web: www.ryanp.com (homepage) www.lp0.org (blog) From mike-nanog at tiedyenetworks.com Wed Nov 19 00:58:24 2014 From: mike-nanog at tiedyenetworks.com (Mike) Date: Tue, 18 Nov 2014 16:58:24 -0800 Subject: abuse reporting tools Message-ID: <546BEB30.9040207@tiedyenetworks.com> Hello, 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. I have good 'consumer broadband' filtering rules in place which make sense and protect against quite a lot of obviously ddos oriented traffic streams. The next step I want to engage, for those types of traffic which I can positively identify as not spoofed, is to send out abuse reports to owners of ip ranges used to launch these attacks. Ideally I'd like to be able to write up some form letter describing the attack, the source ip(s) of note, some disassembled sample packets, and then feed a list of IP source addresses and have it mail it out to the abuse contact at each source network. I am wondering if anyone has a pointer or reference to any tools which might help facillitate this? Thank you. Mike- From michael at supermathie.net Wed Nov 19 01:11:13 2014 From: michael at supermathie.net (Michael Brown) Date: Tue, 18 Nov 2014 20:11:13 -0500 Subject: abuse reporting tools In-Reply-To: <546BEB30.9040207@tiedyenetworks.com> References: <546BEB30.9040207@tiedyenetworks.com> Message-ID: <20141119011113.6647956.37754.16688@supermathie.net> We need to come up with some sort of international Abuse Reduction and Reporting Engagement Suite of Tools as a Service. M.   Original Message   From: Mike Sent: Tuesday, November 18, 2014 19:59 To: nanog at nanog.org Subject: abuse reporting tools Hello, 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. I have good 'consumer broadband' filtering rules in place which make sense and protect against quite a lot of obviously ddos oriented traffic streams. The next step I want to engage, for those types of traffic which I can positively identify as not spoofed, is to send out abuse reports to owners of ip ranges used to launch these attacks. Ideally I'd like to be able to write up some form letter describing the attack, the source ip(s) of note, some disassembled sample packets, and then feed a list of IP source addresses and have it mail it out to the abuse contact at each source network. I am wondering if anyone has a pointer or reference to any tools which might help facillitate this? Thank you. Mike- From rdrake at direcpath.com Wed Nov 19 01:41:29 2014 From: rdrake at direcpath.com (Robert Drake) Date: Tue, 18 Nov 2014 20:41:29 -0500 Subject: abuse reporting tools In-Reply-To: <20141119011113.6647956.37754.16688@supermathie.net> References: <546BEB30.9040207@tiedyenetworks.com> <20141119011113.6647956.37754.16688@supermathie.net> Message-ID: <546BF549.4010605@direcpath.com> On 11/18/2014 8:11 PM, Michael Brown wrote: > We need to come up with some sort of international Abuse Reduction and Reporting Engagement Suite of Tools as a Service. > > M. > I've been considering a post for a couple of weeks but decided most of my complaints were petty. I've been getting lots of "ssh attacks against my network" emails from various people on the internet. All of them have no standard for what logs they show or what format they show them in, or what format the whole email is in, so frequently I'm being told "Trust me, based on this one connection attempt to this non-qualified hostname that occured on this non-TZ timestamp, you need to stop your users abuse." Immediately thereafter they tell me the IP address has already been blocked in their firewall for an unspecified length of time and give no routes for amelioration. So I'm left with a very unsatisfactory feeling of either shutting down a possibly innocent customer based on a machines word, or attempting to start a dialog with random_script_user_99 at hotmail.com. I suspect someone is going to pipe up in a second and say that there is a suite of tools, but the real problem is that nobody is using it. Robert From rafael at gav.ufsc.br Wed Nov 19 02:19:01 2014 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Tue, 18 Nov 2014 20:19:01 -0600 Subject: abuse reporting tools In-Reply-To: <546BEB30.9040207@tiedyenetworks.com> References: <546BEB30.9040207@tiedyenetworks.com> Message-ID: Some folks might disagree with this, but if it's an important service that I have running on a network, I will block a series of garbage AS's (closer to /8 the better) at the firewall (not at the edge) and that reduces the headaches by 50%. This isn't practical at the edge, but for system administration is the only way I have found to minimize the problem. A lot of times the owners of these IPs don't really care and won't take action. For example, the amount of garbage that comes out of FDC Servers in Chicago at times and not much is done. On Tue, Nov 18, 2014 at 6:58 PM, Mike wrote: > Hello, > > 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. I have > good 'consumer broadband' filtering rules in place which make sense and > protect against quite a lot of obviously ddos oriented traffic streams. > The next step I want to engage, for those types of traffic which I can > positively identify as not spoofed, is to send out abuse reports to > owners of ip ranges used to launch these attacks. Ideally I'd like to be > able to write up some form letter describing the attack, the source > ip(s) of note, some disassembled sample packets, and then feed a list of > IP source addresses and have it mail it out to the abuse contact at each > source network. I am wondering if anyone has a pointer or reference to > any tools which might help facillitate this? > > Thank you. > > Mike- > From math at sizone.org Wed Nov 19 02:43:59 2014 From: math at sizone.org (Ken Chase) Date: Tue, 18 Nov 2014 21:43:59 -0500 Subject: abuse reporting tools In-Reply-To: References: <546BEB30.9040207@tiedyenetworks.com> Message-ID: <20141119024358.GV4848@sizone.org> Just wait for GigE-everywhere. I am almost sure that these new Gig-to-the-toaster residential installs have very little rate filtering (or abuse response); let's hope that oversubscription solves the issue handily as it has traditionally. /kc On Tue, Nov 18, 2014 at 08:19:01PM -0600, Rafael Possamai said: >Some folks might disagree with this, but if it's an important service that >I have running on a network, I will block a series of garbage AS's (closer >to /8 the better) at the firewall (not at the edge) and that reduces the >headaches by 50%. This isn't practical at the edge, but for system >administration is the only way I have found to minimize the problem. A lot >of times the owners of these IPs don't really care and won't take action. >For example, the amount of garbage that comes out of FDC Servers in Chicago >at times and not much is done. > >On Tue, Nov 18, 2014 at 6:58 PM, Mike wrote: > >> Hello, >> >> 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. I have >> good 'consumer broadband' filtering rules in place which make sense and >> protect against quite a lot of obviously ddos oriented traffic streams. >> The next step I want to engage, for those types of traffic which I can >> positively identify as not spoofed, is to send out abuse reports to >> owners of ip ranges used to launch these attacks. Ideally I'd like to be >> able to write up some form letter describing the attack, the source >> ip(s) of note, some disassembled sample packets, and then feed a list of >> IP source addresses and have it mail it out to the abuse contact at each >> source network. I am wondering if anyone has a pointer or reference to >> any tools which might help facillitate this? >> >> Thank you. >> >> Mike- >> -- Ken Chase - math at sizone.org From glen.kent at gmail.com Wed Nov 19 07:03:02 2014 From: glen.kent at gmail.com (Glen Kent) Date: Wed, 19 Nov 2014 12:33:02 +0530 Subject: Overlay as a link Message-ID: 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 From ops.lists at gmail.com Wed Nov 19 07:53:43 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 19 Nov 2014 13:23:43 +0530 Subject: Level3 rwhois broken Message-ID: Anybody? Makes it a pain to perform surgical spam blocking when this happens :) suresh at samwise 01:52:24 <~> $ telnet rwhois.level3.net 4321 Trying 209.244.1.179... ^C -- Suresh Ramasubramanian (ops.lists at gmail.com) From dhubbard at dino.hostasaurus.com Wed Nov 19 15:13:13 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 19 Nov 2014 10:13:13 -0500 Subject: FYI, Level 3 issues in Dallas Message-ID: 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 From jeroen at massar.ch Wed Nov 19 15:31:01 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 19 Nov 2014 16:31:01 +0100 Subject: FYI, Level 3 issues in Dallas In-Reply-To: References: Message-ID: <546CB7B5.4050502@massar.ch> 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 From garya at completeweb.net Wed Nov 19 15:46:31 2014 From: garya at completeweb.net (garya at completeweb.net) Date: Wed, 19 Nov 2014 10:46:31 -0500 Subject: FYI, Level 3 issues in Dallas In-Reply-To: References: Message-ID: <4ec106559cbe838350f3ad35a3bea7a8.squirrel@mail.completeweb.net> 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 > From bedard.phil at gmail.com Wed Nov 19 16:17:20 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Wed, 19 Nov 2014 11:17:20 -0500 Subject: Overlay as a link In-Reply-To: References: Message-ID: <546cc29b.68278c0a.03e7.fffff0de@mx.google.com> 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" Sent: ‎11/‎19/‎2014 2:04 AM To: "nanog at 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 From jtk at cymru.com Wed Nov 19 17:14:19 2014 From: jtk at cymru.com (John Kristoff) Date: Wed, 19 Nov 2014 11:14:19 -0600 Subject: abuse reporting tools In-Reply-To: <546BEB30.9040207@tiedyenetworks.com> References: <546BEB30.9040207@tiedyenetworks.com> Message-ID: <20141119111419.2877e52e@localhost> On Tue, 18 Nov 2014 16:58:24 -0800 Mike 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 IETF RFC 5965 An Extensible Format for Email Feedback Reports IETF RFC 6650 Creation and Use of Email Feedback Reports Network Abuse Reporting 2.0 Net::Abuse::Utils John From paul.w.bennett at gmail.com Wed Nov 19 17:32:58 2014 From: paul.w.bennett at gmail.com (Paul Bennett) Date: Wed, 19 Nov 2014 12:32:58 -0500 Subject: abuse reporting tools In-Reply-To: <20141119111419.2877e52e@localhost> References: <546BEB30.9040207@tiedyenetworks.com> <20141119111419.2877e52e@localhost> Message-ID: On Wed, Nov 19, 2014 at 12:14 PM, John Kristoff wrote: > On Tue, 18 Nov 2014 16:58:24 -0800 > Mike 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 From paul.w.bennett at gmail.com Wed Nov 19 17:37:12 2014 From: paul.w.bennett at gmail.com (Paul Bennett) Date: Wed, 19 Nov 2014 12:37:12 -0500 Subject: abuse reporting tools In-Reply-To: References: <546BEB30.9040207@tiedyenetworks.com> <20141119111419.2877e52e@localhost> Message-ID: > Don't forget IETF RFC 5970 "IODEF" Sorry, that's 5070, not 5970. Slip of the finger. -- Paul W Bennett From ttauber at 1-4-5.net Wed Nov 19 17:42:54 2014 From: ttauber at 1-4-5.net (Tony Tauber) Date: Wed, 19 Nov 2014 12:42:54 -0500 Subject: Overlay as a link In-Reply-To: References: Message-ID: Hi Glen, Perhaps I'm stating the obvious or something that's out of scope for what you have in mind. However, one property where they differ is that a physical link has a physical capacity for carrying traffic (i.e., bandwidth). A virtual interface inherits it's capacity from the physical link(s) that underlie it. Some may be locally attached but most will be indirect. Hence it's not possible to know how near it is to its limits. Again, maybe outside what you're thinking about, but you asked "what can possibly be the difference". Cheers, Tony On Wed, Nov 19, 2014 at 2:03 AM, Glen Kent wrote: > 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 > From fmartin at linkedin.com Wed Nov 19 18:19:50 2014 From: fmartin at linkedin.com (Franck Martin) Date: Wed, 19 Nov 2014 18:19:50 +0000 Subject: abuse reporting tools In-Reply-To: <20141119111419.2877e52e@localhost> References: <546BEB30.9040207@tiedyenetworks.com> <20141119111419.2877e52e@localhost> Message-ID: <4E950EB3-13B7-4C48-8E6D-A9BB1BD122E7@linkedin.com> On Nov 19, 2014, at 9:14 AM, John Kristoff wrote: > On Tue, 18 Nov 2014 16:58:24 -0800 > Mike 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 > > > IETF RFC 5965 An Extensible Format for Email Feedback Reports > > > IETF RFC 6650 Creation and Use of Email Feedback Reports > > > Network Abuse Reporting 2.0 > > > 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From coolhandluke at coolhandluke.org Wed Nov 19 16:22:40 2014 From: coolhandluke at coolhandluke.org (Cool Hand Luke) Date: Wed, 19 Nov 2014 11:22:40 -0500 Subject: level3 issue in chicago (was: FYI, Level 3 issues in Dallas) In-Reply-To: <4ec106559cbe838350f3ad35a3bea7a8.squirrel@mail.completeweb.net> References: <4ec106559cbe838350f3ad35a3bea7a8.squirrel@mail.completeweb.net> Message-ID: <546CC3D0.6080507@coolhandluke.org> 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, garya at 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 >> > > From lists at mtin.net Wed Nov 19 20:40:56 2014 From: lists at mtin.net (Justin Wilson) Date: Wed, 19 Nov 2014 15:40:56 -0500 Subject: Outbound traffic on a circuit? Message-ID: 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 http://www.mtin.net Managed Services ­ xISP Solutions ­ Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering ­ Transit ­ Internet Exchange From faisal at snappytelecom.net Wed Nov 19 21:00:51 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Wed, 19 Nov 2014 21:00:51 +0000 (GMT) Subject: Outbound traffic on a circuit? In-Reply-To: References: Message-ID: <1194876969.556940.1416430851056.JavaMail.zimbra@snappytelecom.net> 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: Support at Snappytelecom.net ----- Original Message ----- > From: "Justin Wilson" > To: nanog at 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 > http://www.mtin.net > Managed Services ­ xISP Solutions ­ Data Centers > http://www.thebrotherswisp.com > Podcast about xISP topics > http://www.midwest-ix.com > Peering ­ Transit ­ Internet Exchange > > > > From SNaslund at medline.com Wed Nov 19 22:23:32 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 19 Nov 2014 22:23:32 +0000 Subject: Outbound traffic on a circuit? In-Reply-To: <1194876969.556940.1416430851056.JavaMail.zimbra@snappytelecom.net> References: <1194876969.556940.1416430851056.JavaMail.zimbra@snappytelecom.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40157207D96@MUNPRDMBXA1.medline.com> 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" > To: nanog at 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 > http://www.mtin.net Managed Services ­ xISP > Solutions ­ Data Centers http://www.thebrotherswisp.com Podcast about > xISP topics http://www.midwest-ix.com Peering ­ Transit ­ Internet > Exchange > > > > From ssaner at hubris.net Wed Nov 19 22:31:09 2014 From: ssaner at hubris.net (Steven Saner) Date: Wed, 19 Nov 2014 16:31:09 -0600 Subject: Outbound traffic on a circuit? In-Reply-To: <9578293AE169674F9A048B2BC9A081B40157207D96@MUNPRDMBXA1.medline.com> References: <1194876969.556940.1416430851056.JavaMail.zimbra@snappytelecom.net> <9578293AE169674F9A048B2BC9A081B40157207D96@MUNPRDMBXA1.medline.com> Message-ID: <546D1A2D.4050305@hubris.net> 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 Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communications http://www.hubris.net From jra at baylink.com Thu Nov 20 00:29:09 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 19 Nov 2014 19:29:09 -0500 (EST) Subject: Brian Krebs' new book is out. In-Reply-To: <9E39C60C-E718-49CE-8786-67D5A2991896@arbor.net> Message-ID: <23839514.619.1416443349759.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Roland Dobbins" > This is an important book - well worth your time, and, more > importantly, accessible to non-specialists (such as BDMs): > > > > > 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 jra at 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 From dhubbard at dino.hostasaurus.com Thu Nov 20 00:29:26 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 19 Nov 2014 19:29:26 -0500 Subject: level3 issue in chicago (was: FYI, Level 3 issues in Dallas) References: <4ec106559cbe838350f3ad35a3bea7a8.squirrel@mail.completeweb.net> <546CC3D0.6080507@coolhandluke.org> Message-ID: 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-bounces at nanog.org] On Behalf Of Cool Hand Luke Sent: Wednesday, November 19, 2014 11:23 AM To: nanog at 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, garya at 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 >> > > From joelja at bogus.com Thu Nov 20 01:40:55 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 19 Nov 2014 17:40:55 -0800 Subject: Outbound traffic on a circuit? In-Reply-To: References: Message-ID: <546D46A7.7020105@bogus.com> 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 > http://www.mtin.net > Managed Services ­ xISP Solutions ­ Data Centers > http://www.thebrotherswisp.com > Podcast about xISP topics > http://www.midwest-ix.com > Peering ­ Transit ­ Internet Exchange > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From coolhandluke at coolhandluke.org Thu Nov 20 07:42:23 2014 From: coolhandluke at coolhandluke.org (cool hand luke) Date: Thu, 20 Nov 2014 02:42:23 -0500 Subject: level3 issue in chicago In-Reply-To: References: <4ec106559cbe838350f3ad35a3bea7a8.squirrel@mail.completeweb.net> <546CC3D0.6080507@coolhandluke.org> Message-ID: <546D9B5F.8040909@coolhandluke.org> 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 From paul.w.bennett at gmail.com Thu Nov 20 11:44:44 2014 From: paul.w.bennett at gmail.com (Paul Bennett) Date: Thu, 20 Nov 2014 06:44:44 -0500 Subject: abuse reporting tools In-Reply-To: <4E950EB3-13B7-4C48-8E6D-A9BB1BD122E7@linkedin.com> References: <546BEB30.9040207@tiedyenetworks.com> <20141119111419.2877e52e@localhost> <4E950EB3-13B7-4C48-8E6D-A9BB1BD122E7@linkedin.com> Message-ID: Inspired by this thread (and other recent similar ones about how hard it is to report abuse in the right format to the right people), I've decided I'm going to start work on the Perl module presumed by this gist ... https://gist.github.com/PWBENNETT/18970413677c5df79c6a Reporting network abuse should be *EASY*. Say it with me ... *EASY*. No promises, at this stage, but I thought some of you would like to know that this project is at least in the pre-planning stages. -- Paul W Bennett From coolhandluke at coolhandluke.org Thu Nov 20 12:32:10 2014 From: coolhandluke at coolhandluke.org (cool hand luke) Date: Thu, 20 Nov 2014 07:32:10 -0500 Subject: level3 issue in chicago In-Reply-To: <546D9B5F.8040909@coolhandluke.org> References: <4ec106559cbe838350f3ad35a3bea7a8.squirrel@mail.completeweb.net> <546CC3D0.6080507@coolhandluke.org> <546D9B5F.8040909@coolhandluke.org> Message-ID: <546DDF4A.8020306@coolhandluke.org> fyi: On 11/20/2014 02:42 AM, cool hand luke wrote: > 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. routing issue experienced from 06:37 - 11:02 utc. notes from level 3: "11/20/2014 11:30:19 GMT - After investigating the issue I found that this circuit was affected by an outage on our network. A non-service affecting maintenance had unintended results causing routing problems in the Chicago area. All traffic through the Chicago area was affected by this issue. If you have any additional destinations that are still seeing issues please contact us as soon as possible as the issue may not be completely resolved yet." /chl From larry at elucidations.net Thu Nov 20 14:09:34 2014 From: larry at elucidations.net (Larry Krone) Date: Thu, 20 Nov 2014 09:09:34 -0500 Subject: Need Godaddy Contact Message-ID: <008901d004cb$9d122a70$d7367f50$@elucidations.net> I have a question that Godaddy support will not answer. My son moved a word press site to Godaddy from another host. Apparently, unbeknowest to him, the original wordpress site was also the email host. The mail was moved from the old server to the new server but the email was never properly set up via the GoDaddy Cpanel Question for a Godaddy Guru. if we set up the email through the cpanel, will it erase any mail currently in the accounts on the linux wordpress machine, or even acknowledge that the exist email is there? Any help would be GREATLY appreciated and Thanks.. Larry From josh at imaginenetworksllc.com Thu Nov 20 14:17:58 2014 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 20 Nov 2014 09:17:58 -0500 Subject: Need Godaddy Contact In-Reply-To: <008901d004cb$9d122a70$d7367f50$@elucidations.net> References: <008901d004cb$9d122a70$d7367f50$@elucidations.net> Message-ID: It won't do anything to another server. You won't get copies of messages transferred with DNS changes. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Nov 20, 2014 9:10 AM, "Larry Krone" wrote: > I have a question that Godaddy support will not answer. > > > > My son moved a word press site to Godaddy from another host. > > > > Apparently, unbeknowest to him, the original wordpress site was also the > email host. > > > > The mail was moved from the old server to the new server but the email was > never properly set up via the GoDaddy Cpanel > > > > Question for a Godaddy Guru. > > > > if we set up the email through the cpanel, will it erase any mail currently > in the accounts on the linux wordpress machine, or even acknowledge that > the > exist email is there? > > > > Any help would be GREATLY appreciated and Thanks.. > > > > > > Larry > > > > From mfidelman at meetinghouse.net Thu Nov 20 14:55:15 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 20 Nov 2014 09:55:15 -0500 Subject: Need Godaddy Contact In-Reply-To: <008901d004cb$9d122a70$d7367f50$@elucidations.net> References: <008901d004cb$9d122a70$d7367f50$@elucidations.net> Message-ID: <546E00D3.7080209@meetinghouse.net> Larry Krone wrote: > I have a question that Godaddy support will not answer. That actually seems odd - I've usually found them helpful. But that's neither here nor there. See below... > > > > My son moved a word press site to Godaddy from another host. > > > > Apparently, unbeknowest to him, the original wordpress site was also the > email host. > > > > The mail was moved from the old server to the new server but the email was > never properly set up via the GoDaddy Cpanel > > > > Question for a Godaddy Guru. > > > > if we set up the email through the cpanel, will it erase any mail currently > in the accounts on the linux wordpress machine, or even acknowledge that the > exist email is there? > > As previously noted, what you do on the GoDaddy site will have no effect on the other server (assuming it's not also on GoDaddy, of course). What will change things is propagation of DNS record changes. For a period, mail will flow to both the old and new server, until the new DNS records get everywhere. What I'd recommend is something like this: - check the expiration period for the old DNS record - monitor both sites for mail for at least the timeout on the old record; keep monitoring the old site until you're sure no more mail is getting there - maybe, put a .forward file on the old site to catch any mail that leads through (but only after you're sure the old site has the updated DNS record! - you can't use a physical IP address for forwarding to GoDaddy, because everything there is via virtual hosts) - transfer all mail from the old site to the new site (if you use IMAP, that's pretty easy, or tar up your mail directory) - then decommission the old site Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From pavel.odintsov at gmail.com Thu Nov 20 21:36:07 2014 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Fri, 21 Nov 2014 01:36:07 +0400 Subject: DDOS, IDS, RTBH, and Rate limiting Message-ID: Hello, folks! I'm author of fastnetmon, thank you for some PR for my toolkit :) I use this tool for similar type of attacks and we do analyze all traffic from uplinks ports using port mirroring. You can look at this network diagram: https://raw.githubusercontent.com/FastVPSEestiOu/fastnetmon/master/network_map.png I tried to use netflow many years ago but it's not accurate enough and not so fast enough and produce big overhead on middle class network routers. It's because I wrote this tool and do every packet analyze. It can detect attack in 2 seconds max and call BGP blackhole as quick as thought. It can detect three types of attacks: 1) Speed attack for certain IP (we ban every IP which exceed 1 Gbps) 2) Packet per second attack for certain IP (we ban every IP which exceed 100 000 ppps) 3) And flow flood (very useful mode in networks with big bandwidth/pps per client) FastNetMon can handle 2-3 million of packets per second and ~20Gbps on standard i7 2600 Linux box with Intel 82599 NIC. If you need any help or suggestions you can email me directly or ask via GitHub. Thank you! -- Sincerely yours, Pavel Odintsov From jwalter at weebly.com Thu Nov 20 21:49:34 2014 From: jwalter at weebly.com (Jeff Walter) Date: Thu, 20 Nov 2014 13:49:34 -0800 Subject: Level3 rwhois broken In-Reply-To: References: Message-ID: It's nice to see someone is using RWHOIS. Back when I wrote the RWHOIS daemon for HE I spoke with Mark Kosters (one of the authors of RFC 2167). I wish I still had the emails because at the time he was shocked anyone would create software for something that no one really uses. I seem to recall him calling it a waste of time ;-) That said... I'm seeing Level 3's RWHOIS down as well. And to be honest, they're probably not monitoring it. On Tue, Nov 18, 2014 at 11:53 PM, Suresh Ramasubramanian < ops.lists at gmail.com> wrote: > Anybody? Makes it a pain to perform surgical spam blocking when this > happens :) > > suresh at samwise 01:52:24 <~> $ telnet rwhois.level3.net 4321 > Trying 209.244.1.179... > > ^C > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > From rdobbins at arbor.net Thu Nov 20 21:59:18 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 21 Nov 2014 04:59:18 +0700 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: Message-ID: <3CC1B73E-75BB-4BF3-88A3-D373D1D540E3@arbor.net> On 21 Nov 2014, at 4:36, Pavel Odintsov wrote: > I tried to use netflow many years ago but it's not accurate enough and > not so fast enough and produce big overhead on middle class network > routers. These statements are not supported by the facts. NetFlow (and other varieties of flow telemetry) has been used for many years for traffic engineering-related analysis, capacity planning, and security purposes. I've never seen the CPU utilization on even a modest mid-range router rise above single-digits, except once due to a bug (which was fixed quickly). Flow telemetry scales and provides invaluable edge-to-edge traceback information. NetFlow telemetry is accurate enough to be used for all the purposes noted above by network operators across the world, from the smallest to the largest networks in the world. There are several excellent open-source NetFlow analysis tools which allow folks to benefit from NetFlow analysis without spending a lot of money. Some of these projects have been maintained and enhanced for many years; their authors would not do that if NetFlow analytics weren't sufficient to needs. Packet-based analysis is certainly useful, but does not scale and does not provide traceback information. > FastNetMon can handle 2-3 million of packets per second and ~20Gbps on > standard i7 2600 Linux box with Intel 82599 NIC. See the comments above with regards to scale. This is inadequate for a network of any size, it does not provide traceback information, and it does not lend itself to broad deployment across a network of any size. I'm sure FastNetMon is a fine tool, and it's very good of you to spend the time and effort to develop it and to make it available. However, making demonstrably-inaccurate statements about other technologies which are in wide use by network operators and which have a proven track record in the field is probably not the best way to encourage folks to try FastNetMon. ----------------------------------- Roland Dobbins From contact at nullivex.com Thu Nov 20 22:43:24 2014 From: contact at nullivex.com (Bryan Tong) Date: Thu, 20 Nov 2014 15:43:24 -0700 Subject: Level3 rwhois broken In-Reply-To: References: Message-ID: I put together a protocol framework in Node.js https://www.npmjs.org/package/rwhois Its still useful for some companies. On Thu, Nov 20, 2014 at 2:49 PM, Jeff Walter wrote: > It's nice to see someone is using RWHOIS. Back when I wrote the RWHOIS > daemon for HE I spoke with Mark Kosters (one of the authors of RFC 2167). I > wish I still had the emails because at the time he was shocked anyone would > create software for something that no one really uses. I seem to recall him > calling it a waste of time ;-) > > That said... I'm seeing Level 3's RWHOIS down as well. And to be honest, > they're probably not monitoring it. > > On Tue, Nov 18, 2014 at 11:53 PM, Suresh Ramasubramanian < > ops.lists at gmail.com> wrote: > > > Anybody? Makes it a pain to perform surgical spam blocking when this > > happens :) > > > > suresh at samwise 01:52:24 <~> $ telnet rwhois.level3.net 4321 > > Trying 209.244.1.179... > > > > ^C > > > > > > -- > > Suresh Ramasubramanian (ops.lists at gmail.com) > > > -- eSited LLC (701) 390-9638 From joesox at gmail.com Thu Nov 20 22:57:55 2014 From: joesox at gmail.com (JoeSox) Date: Thu, 20 Nov 2014 14:57:55 -0800 Subject: USA Power Grid compromised? Message-ID: Am I the only Network Admin wondering how this can happen and why its still an issue if it was discovered in 2011? Now I never worked in the Energy field so I am in the dark (pun intended I guess) on how serious the Public utilities address these issues. They should have redundant systems so they can clean (reimage, etc) whatever is there and be done with it?? ref: NSA chief admits China could cripple U.S. power grid, financial networks http://www.zdnet.com/nsa-chief-admits-china-could-cripple-u-s-power-grid-financial-networks-7000036025/ http://abcnews.go.com/US/trojan-horse-bug-lurking-vital-us-computers-2011/story?id=26737476 -- Later, Joe From jra at baylink.com Thu Nov 20 23:07:09 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 20 Nov 2014 18:07:09 -0500 Subject: Anyone heard from Jared lately? Message-ID: <006E5A4C-0022-47B7-B819-A5A772B73567@baylink.com> He generally provides same-day service on email, but... Hope all is well. Cheers, -- jra Moderator @ outages -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From job at instituut.net Thu Nov 20 23:09:19 2014 From: job at instituut.net (Job Snijders) Date: Fri, 21 Nov 2014 00:09:19 +0100 Subject: Anyone heard from Jared lately? In-Reply-To: <006E5A4C-0022-47B7-B819-A5A772B73567@baylink.com> References: <006E5A4C-0022-47B7-B819-A5A772B73567@baylink.com> Message-ID: <20141120230919.GI45106@Vurt.local> On Thu, Nov 20, 2014 at 06:07:09PM -0500, Jay Ashworth wrote: > He generally provides same-day service on email, but... > > Hope all is well. Don't worry, he is alive and well. puck.nether.net is having some disk issues hene a backlog on email. - Job From denys at visp.net.lb Thu Nov 20 23:22:56 2014 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Fri, 21 Nov 2014 01:22:56 +0200 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <3CC1B73E-75BB-4BF3-88A3-D373D1D540E3@arbor.net> References: <3CC1B73E-75BB-4BF3-88A3-D373D1D540E3@arbor.net> Message-ID: <55756125a9cfc9f7e20232aa2ad098d3@visp.net.lb> On 2014-11-20 23:59, Roland Dobbins wrote: > On 21 Nov 2014, at 4:36, Pavel Odintsov wrote: > >> I tried to use netflow many years ago but it's not accurate enough and >> not so fast enough and produce big overhead on middle class network >> routers. > > These statements are not supported by the facts. NetFlow (and other > varieties of flow telemetry) has been used for many years for traffic > engineering-related analysis, capacity planning, and security > purposes. I've never seen the CPU utilization on even a modest > mid-range router rise above single-digits, except once due to a bug > (which was fixed quickly). > > Flow telemetry scales and provides invaluable edge-to-edge traceback > information. NetFlow telemetry is accurate enough to be used for all > the purposes noted above by network operators across the world, from > the smallest to the largest networks in the world. > > There are several excellent open-source NetFlow analysis tools which > allow folks to benefit from NetFlow analysis without spending a lot of > money. Some of these projects have been maintained and enhanced for > many years; their authors would not do that if NetFlow analytics > weren't sufficient to needs. > > Packet-based analysis is certainly useful, but does not scale and does > not provide traceback information. > >> FastNetMon can handle 2-3 million of packets per second and ~20Gbps on >> standard i7 2600 Linux box with Intel 82599 NIC. > > See the comments above with regards to scale. This is inadequate for > a network of any size, it does not provide traceback information, and > it does not lend itself to broad deployment across a network of any > size. > > I'm sure FastNetMon is a fine tool, and it's very good of you to spend > the time and effort to develop it and to make it available. However, > making demonstrably-inaccurate statements about other technologies > which are in wide use by network operators and which have a proven > track record in the field is probably not the best way to encourage > folks to try FastNetMon. Netflow is stateful stuff, and just to run it on wirespeed, on hardware, you need to utilise significant part of TCAM, i am not talking that on some hardware it is just impossible to run it. So everything about netflow are built on assumption that hosting or ISP can run it. And based on some observations, majority of small/middle hosting providers are using minimal,just BGP capable L3 switch as core, and cheapest but reliable L2/L3 on aggregation, and both are capable in best case to run sampled sFlow. And last thing, from one of public papers, netflow delaying factors: 1. Flow record expiration 2. Exporting process • Typical delay: 15-60 sec. So for a small hosting(up to 10G), i believe, FastNetMon is best solution. Faster, and no significant investments to equipment. Bigger hosting providers might reuse their existing servers, segment the network, and implement inexpensive monitoring on aggregation switches without any additional cost again. Ah, and there is one more huge problem with netflow vs FastNetMon - netflow just by design cannot be adapted to run pattern matching, while it is trivial to patch FastNetMon for that, turning it to mini-IDS for free. --- Best regards, Denys From David.Siegel at Level3.com Thu Nov 20 23:42:27 2014 From: David.Siegel at Level3.com (Siegel, David) Date: Thu, 20 Nov 2014 23:42:27 +0000 Subject: Level3 rwhois broken In-Reply-To: References: Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC0730AF75E@USIDCWVEMBX10.corp.global.level3.com> We decommissioned our rwhois server, but apparently we didn't get DNS cleaned up (which we'll do in the near future). The closest thing we have to that is our whois server rr.level3.net, or if that doesn't quite meet your needs, you can contact our security department at abuse at level3.net. Dave -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jeff Walter Sent: Thursday, November 20, 2014 2:50 PM To: Suresh Ramasubramanian Cc: nanog at nanog.org Subject: Re: Level3 rwhois broken It's nice to see someone is using RWHOIS. Back when I wrote the RWHOIS daemon for HE I spoke with Mark Kosters (one of the authors of RFC 2167). I wish I still had the emails because at the time he was shocked anyone would create software for something that no one really uses. I seem to recall him calling it a waste of time ;-) That said... I'm seeing Level 3's RWHOIS down as well. And to be honest, they're probably not monitoring it. On Tue, Nov 18, 2014 at 11:53 PM, Suresh Ramasubramanian < ops.lists at gmail.com> wrote: > Anybody? Makes it a pain to perform surgical spam blocking when this > happens :) > > suresh at samwise 01:52:24 <~> $ telnet rwhois.level3.net 4321 Trying > 209.244.1.179... > > ^C > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > From ops.lists at gmail.com Fri Nov 21 00:59:55 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 21 Nov 2014 00:59:55 +0000 Subject: Level3 rwhois broken References: <970945E55BFD8C4EA4CAD74B647A9DC0730AF75E@USIDCWVEMBX10.corp.global.level3.com> Message-ID: Works for me, thanks. I forgot exactly which IPs this was about right now though :) On Fri, 21 Nov 2014 at 05:12 Siegel, David wrote: > > We decommissioned our rwhois server, but apparently we didn't get DNS > cleaned up (which we'll do in the near future). > > The closest thing we have to that is our whois server rr.level3.net, or > if that doesn't quite meet your needs, you can contact our security > department at abuse at level3.net. > > Dave > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jeff Walter > Sent: Thursday, November 20, 2014 2:50 PM > To: Suresh Ramasubramanian > Cc: nanog at nanog.org > Subject: Re: Level3 rwhois broken > > It's nice to see someone is using RWHOIS. Back when I wrote the RWHOIS > daemon for HE I spoke with Mark Kosters (one of the authors of RFC 2167). I > wish I still had the emails because at the time he was shocked anyone would > create software for something that no one really uses. I seem to recall him > calling it a waste of time ;-) > > That said... I'm seeing Level 3's RWHOIS down as well. And to be honest, > they're probably not monitoring it. > > On Tue, Nov 18, 2014 at 11:53 PM, Suresh Ramasubramanian < > ops.lists at gmail.com> wrote: > > > Anybody? Makes it a pain to perform surgical spam blocking when this > > happens :) > > > > suresh at samwise 01:52:24 <~> $ telnet rwhois.level3.net 4321 Trying > > 209.244.1.179... > > > > ^C > > > > > > -- > > Suresh Ramasubramanian (ops.lists at gmail.com) > > > From rdobbins at arbor.net Fri Nov 21 01:12:13 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 21 Nov 2014 08:12:13 +0700 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <55756125a9cfc9f7e20232aa2ad098d3@visp.net.lb> References: <3CC1B73E-75BB-4BF3-88A3-D373D1D540E3@arbor.net> <55756125a9cfc9f7e20232aa2ad098d3@visp.net.lb> Message-ID: On 21 Nov 2014, at 6:22, Denys Fedoryshchenko wrote: > Netflow is stateful stuff, This is factually incorrect; NetFlow flows are unidirectional in nature, and in any event have no effect on processing of data-plane traffic. > and just to run it on wirespeed, on hardware, you need to utilise > significant part of TCAM, Again, this is factually incorrect. > i am not talking that on some hardware it is just impossible to run > it. This is also factually incorrect. Some platforms/linecards do not in fact support NetFlow (or other varieties of flow telemetry) due to hardware limitations. > And last thing, from one of public papers, netflow delaying factors: > 1. Flow record expiration This is tunable. > • Typical delay: 15-60 sec. This is an entirely subjective assessment, and does not reflect operational realities. These are typically *maximum values* - and they are well within operationally-useful timeframes. Also, the effect of NetFlow cache size and resultant FIFOing of flow records is not taken into account, nor is the effect on flow termination and flow-record export of TCP FIN or RST flags denoting TCP traffic taken into account. > So for a small hosting(up to 10G), i believe, FastNetMon is best > solution. This is a gross over-generalization unsupported by facts. Many years of operational experience with NetFlow and other forms of flow telemetry by large numbers of network operators of all sizes and varieties contract this over-generalization. It is generally unwise to make sweeping statements regarding operational impact which are not borne out by significant operational experience in production networks. > Faster, and no significant investments to equipment. This statement indicates a lack of understanding of opex costs, irrespective of capex costs. > Bigger hosting providers might reuse their existing servers, segment > the network, and implement inexpensive monitoring on aggregation > switches without any additional cost again. This statement indicates a lack of operational experience in networks of even minimal scale. > Ah, and there is one more huge problem with netflow vs FastNetMon - > netflow just by design cannot be adapted to run pattern matching, > while it is trivial to patch FastNetMon for that, turning it to > mini-IDS for free. This statement betrays a lack of understanding of NetFlow-based (and other flow telemetry-based) detection and classification, as well as the undesirability and negative operational impact of stateful IDS/'IPS' deployments in production networks. You should also note that FastNetMon is far from unique; there are multiple other open-source tools which provide the same type of functionality, and none of them have replaced flow telemetry, either. Tools such as FastNetMon supplement flow telemetry, in situations in which such tools can be deployed. They do not begin to replace flow telemetry, and they are not inherently superior to flow telemetry. Again, I'm sure FastNetMon is a useful tool in many circumstances. But it would be a much better idea to define FastNetMon positively in terms of its own inherent value, rather than attempting to define it based upon factually incorrect negative 'comparisons' to other well-established, widely-used technologies which have demonstrable track records within the global operational community. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Fri Nov 21 02:37:01 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 21 Nov 2014 09:37:01 +0700 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <3CC1B73E-75BB-4BF3-88A3-D373D1D540E3@arbor.net> <55756125a9cfc9f7e20232aa2ad098d3@visp.net.lb> Message-ID: <05746E25-B823-46B2-A535-B924633D4C49@arbor.net> On 21 Nov 2014, at 9:19, Robert Duffy wrote: > What open-source NetFlow analysis tools would you recommend for > quickly > detecting a DDoS attack? I generally recommend that folks get started with something like nfdump/nfsen or ntop. There are other, more sophisticated tools out there, but these allow one to get up and running quickly, and to gain valuable operational experience with which to evaluate more sophisticated tools, if they're needed. ----------------------------------- Roland Dobbins From jackson.tim at gmail.com Fri Nov 21 02:50:14 2014 From: jackson.tim at gmail.com (Tim Jackson) Date: Thu, 20 Nov 2014 18:50:14 -0800 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <05746E25-B823-46B2-A535-B924633D4C49@arbor.net> References: <3CC1B73E-75BB-4BF3-88A3-D373D1D540E3@arbor.net> <55756125a9cfc9f7e20232aa2ad098d3@visp.net.lb> <05746E25-B823-46B2-A535-B924633D4C49@arbor.net> Message-ID: I highly recommend pmacct and it's in-memory tables. Lightweight, easy to query and super fast. You can also easily run multiple aggregates of traffic to find what you are interested in, tag common interface types to easily filter traffic.. Or you can use pmacct to insert this into whatever database you want, AMQP or MongoDB.. My current favorite is using an IMT table for DoS detection and another for aggregates for interesting traffic types and querying this every X minutes and inserting it into ElasticSearch. Kibana makes the most powerful netflow dashboard ever. -- Tim On Nov 20, 2014 6:39 PM, "Roland Dobbins" wrote: > > On 21 Nov 2014, at 9:19, Robert Duffy wrote: > > What open-source NetFlow analysis tools would you recommend for quickly >> detecting a DDoS attack? >> > > I generally recommend that folks get started with something like > nfdump/nfsen or ntop. There are other, more sophisticated tools out there, > but these allow one to get up and running quickly, and to gain valuable > operational experience with which to evaluate more sophisticated tools, if > they're needed. > > ----------------------------------- > Roland Dobbins > From tknchris at gmail.com Fri Nov 21 02:51:20 2014 From: tknchris at gmail.com (chris) Date: Thu, 20 Nov 2014 21:51:20 -0500 Subject: Clueful Jive Communications Contact? In-Reply-To: References: Message-ID: Sounds about on par with my experience so far. We have a client who uses jive and we manage their network and when this client opens tickets with jive, they get copy+pasted the exact same email every time telling the client to make sure sip alg is disabled, check firewall, etc. We have repeatedly told them that theres no filtering of outbound traffic and we've stated many times that all their recommendations are already in affect. We also ran into a similar adtran situation to yours, when the customer contacted Jive to open the first support ticket, Jive automatically started CC-ing the IT company who is a Jive reseller and doesn't have any staff familiar with cisco ios and insisted that they put in a adtran. The reseller came out and dismantled the network and I advised Jive we are applying QoS to standard VOIP ports in our base config but I told them if there is anything outside the normal sip and rtp ports to give it me to me to be added and they still haven't. At one point our client got real upset and Jive started "monitoring" the WAN link which is dedicated for their voice traffic only and then started telling the customer to call the ISP. The irony here is that I'm almost postivie that their perceived "loss" is just that when the link is fully utilized we obviously don't prioritize ICMP and also I have a hunch that they are using more ports than the typical ones in which case that traffic will suffer also because they will not tell me what traffic to prioritize. This support rep now refuses to proceed until the customer calls the ISP so we switched their voice traffic to another WAN link completely just to demonstrate at which point the support rep said they saw loss still at which point I explained that if we had the info necessary to QoS everything properly their traffic should be unaffected even when there is congestion. Which is more likely at fault: A) Having the exact same set of problems with 2 different diverse ISP's B) Their "monitoring" traffic being drop as expected, when link is congested and router is applying QoS exactly as it should and dropping the non prioritized traffic. Of course when some traffic is prioritized that automatically means non prioritized traffic is penalized. This is exactly how we want it. Needless to say, the client is frustrated because support is stuck at "call isp" and insist they see "voice loss". Hopefully your experience is not quite as bad but I have to say that of all the different voice service providers we've worked with we've never spent as much time The contact who reached out to me was Michael Martinez ( mmartinez at getjive.com), he is a member of this list and appears to be a network engineer managing their core network. Hope this helps or if you are still evaluating Jive maybe this experience will help give you an idea of what to expect chris On Thu, Nov 20, 2014 at 9:07 PM, Sean Sinay wrote: > Would also appreciate the clueful contact as I have the same experience > with going through the normal support escalation. Primarily interested in > the networking folk who are intimately familiar with the Adtran CPE they > ship to customers. The 'Engineers' shipped two devices with no gateways > configured.. > > On Sat, Nov 8, 2014 at 11:24 AM, chris wrote: > >> Thanks to all replies off-list. Contact has been made with all the right >> people in the right places. It really is amazing to see how active the >> nanog community is and all the great players involved. >> >> Chris >> >> On Fri, Nov 7, 2014 at 6:24 PM, chris wrote: >> >> > Sorry for the noise but If anyone from Jive Communications is on the >> list >> > or if anyone has any clueful technical contacts please contact me >> offlist. >> > >> > I have a very frustrated mutual customer we provide network services to >> > who utilizes Jive for their voice and we can see that there is >> intermittent >> > reachability problems and all attempts to go through normal support >> with >> > the information we have provided are going nowhere. >> > >> > Thanks >> > chris >> > >> > > From datazone at gmail.com Fri Nov 21 01:07:01 2014 From: datazone at gmail.com (Data Zone) Date: Thu, 20 Nov 2014 19:07:01 -0600 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: Message-ID: What happens when someone spoofs legitimate hosts that your customers use? On Thu, Nov 20, 2014 at 3:36 PM, Pavel Odintsov wrote: > Hello, folks! > > I'm author of fastnetmon, thank you for some PR for my toolkit :) > > I use this tool for similar type of attacks and we do analyze all > traffic from uplinks ports using port mirroring. You can look at this > network diagram: > > https://raw.githubusercontent.com/FastVPSEestiOu/fastnetmon/master/network_map.png > > I tried to use netflow many years ago but it's not accurate enough and > not so fast enough and produce big overhead on middle class network > routers. It's because I wrote this tool and do every packet analyze. > It can detect attack in 2 seconds max and call BGP blackhole as quick > as thought. > > It can detect three types of attacks: > 1) Speed attack for certain IP (we ban every IP which exceed 1 Gbps) > 2) Packet per second attack for certain IP (we ban every IP which > exceed 100 000 ppps) > 3) And flow flood (very useful mode in networks with big bandwidth/pps > per client) > > FastNetMon can handle 2-3 million of packets per second and ~20Gbps on > standard i7 2600 Linux box with Intel 82599 NIC. > > If you need any help or suggestions you can email me directly or ask via > GitHub. > > Thank you! > > -- > Sincerely yours, Pavel Odintsov > From smsinay at gmail.com Fri Nov 21 02:07:56 2014 From: smsinay at gmail.com (Sean Sinay) Date: Thu, 20 Nov 2014 20:07:56 -0600 Subject: Clueful Jive Communications Contact? In-Reply-To: References: Message-ID: Would also appreciate the clueful contact as I have the same experience with going through the normal support escalation. Primarily interested in the networking folk who are intimately familiar with the Adtran CPE they ship to customers. The 'Engineers' shipped two devices with no gateways configured.. On Sat, Nov 8, 2014 at 11:24 AM, chris wrote: > Thanks to all replies off-list. Contact has been made with all the right > people in the right places. It really is amazing to see how active the > nanog community is and all the great players involved. > > Chris > > On Fri, Nov 7, 2014 at 6:24 PM, chris wrote: > > > Sorry for the noise but If anyone from Jive Communications is on the list > > or if anyone has any clueful technical contacts please contact me > offlist. > > > > I have a very frustrated mutual customer we provide network services to > > who utilizes Jive for their voice and we can see that there is > intermittent > > reachability problems and all attempts to go through normal support with > > the information we have provided are going nowhere. > > > > Thanks > > chris > > > From rob at esecuredata.com Fri Nov 21 02:19:31 2014 From: rob at esecuredata.com (Robert Duffy) Date: Thu, 20 Nov 2014 18:19:31 -0800 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <3CC1B73E-75BB-4BF3-88A3-D373D1D540E3@arbor.net> <55756125a9cfc9f7e20232aa2ad098d3@visp.net.lb> Message-ID: Roland, you seem to have a lot of experience with these kinds of tools. What open-source NetFlow analysis tools would you recommend for quickly detecting a DDoS attack? On Thu, Nov 20, 2014 at 5:12 PM, Roland Dobbins wrote: > > On 21 Nov 2014, at 6:22, Denys Fedoryshchenko wrote: > > Netflow is stateful stuff, >> > > This is factually incorrect; NetFlow flows are unidirectional in nature, > and in any event have no effect on processing of data-plane traffic. > > and just to run it on wirespeed, on hardware, you need to utilise >> significant part of TCAM, >> > > Again, this is factually incorrect. > > i am not talking that on some hardware it is just impossible to run it. >> > > This is also factually incorrect. Some platforms/linecards do not in fact > support NetFlow (or other varieties of flow telemetry) due to hardware > limitations. > > And last thing, from one of public papers, netflow delaying factors: >> 1. Flow record expiration >> > > This is tunable. > > • Typical delay: 15-60 sec. >> > > This is an entirely subjective assessment, and does not reflect > operational realities. These are typically *maximum values* - and they are > well within operationally-useful timeframes. Also, the effect of NetFlow > cache size and resultant FIFOing of flow records is not taken into account, > nor is the effect on flow termination and flow-record export of TCP FIN or > RST flags denoting TCP traffic taken into account. > > So for a small hosting(up to 10G), i believe, FastNetMon is best solution. >> > > This is a gross over-generalization unsupported by facts. Many years of > operational experience with NetFlow and other forms of flow telemetry by > large numbers of network operators of all sizes and varieties contract this > over-generalization. > > It is generally unwise to make sweeping statements regarding operational > impact which are not borne out by significant operational experience in > production networks. > > Faster, and no significant investments to equipment. >> > > This statement indicates a lack of understanding of opex costs, > irrespective of capex costs. > > Bigger hosting providers might reuse their existing servers, segment the >> network, and implement inexpensive monitoring on aggregation switches >> without any additional cost again. >> > > This statement indicates a lack of operational experience in networks of > even minimal scale. > > Ah, and there is one more huge problem with netflow vs FastNetMon - >> netflow just by design cannot be adapted to run pattern matching, while it >> is trivial to patch FastNetMon for that, turning it to mini-IDS for free. >> > > This statement betrays a lack of understanding of NetFlow-based (and other > flow telemetry-based) detection and classification, as well as the > undesirability and negative operational impact of stateful IDS/'IPS' > deployments in production networks. > > You should also note that FastNetMon is far from unique; there are > multiple other open-source tools which provide the same type of > functionality, and none of them have replaced flow telemetry, either. > > Tools such as FastNetMon supplement flow telemetry, in situations in which > such tools can be deployed. They do not begin to replace flow telemetry, > and they are not inherently superior to flow telemetry. > > Again, I'm sure FastNetMon is a useful tool in many circumstances. But it > would be a much better idea to define FastNetMon positively in terms of its > own inherent value, rather than attempting to define it based upon > factually incorrect negative 'comparisons' to other well-established, > widely-used technologies which have demonstrable track records within the > global operational community. > > ----------------------------------- > Roland Dobbins > -- Regards, Rob ------------------------------------------------------------ -------------------- Robert Duffy eSecureData.com Inc. 1478 Hartley Ave. Coquitlam, BC V3K 7A1 T: (800) 620-1985 F: (800) 620-1986 This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal and or privileged information. Please contact the sender immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on the contents herein. Any communication received in error, or subsequent reply, should be deleted or destroyed. From rob at esecuredata.com Fri Nov 21 03:00:49 2014 From: rob at esecuredata.com (Robert Duffy) Date: Thu, 20 Nov 2014 19:00:49 -0800 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <3CC1B73E-75BB-4BF3-88A3-D373D1D540E3@arbor.net> <55756125a9cfc9f7e20232aa2ad098d3@visp.net.lb> <05746E25-B823-46B2-A535-B924633D4C49@arbor.net> Message-ID: I've been using NTOP for couple of years. I'm mostly looking for something that can quickly detect DDoS attacks in a datacenter environment. Thanks for the suggestions. I"ll check them out. On Thu, Nov 20, 2014 at 6:50 PM, Tim Jackson wrote: > I highly recommend pmacct and it's in-memory tables. Lightweight, easy to > query and super fast. > > You can also easily run multiple aggregates of traffic to find what you are > interested in, tag common interface types to easily filter traffic.. > > Or you can use pmacct to insert this into whatever database you want, AMQP > or MongoDB.. > > My current favorite is using an IMT table for DoS detection and another for > aggregates for interesting traffic types and querying this every X minutes > and inserting it into ElasticSearch. Kibana makes the most powerful netflow > dashboard ever. > > -- > Tim > On Nov 20, 2014 6:39 PM, "Roland Dobbins" wrote: > > > > > On 21 Nov 2014, at 9:19, Robert Duffy wrote: > > > > What open-source NetFlow analysis tools would you recommend for quickly > >> detecting a DDoS attack? > >> > > > > I generally recommend that folks get started with something like > > nfdump/nfsen or ntop. There are other, more sophisticated tools out > there, > > but these allow one to get up and running quickly, and to gain valuable > > operational experience with which to evaluate more sophisticated tools, > if > > they're needed. > > > > ----------------------------------- > > Roland Dobbins > > > -- Regards, Rob ------------------------------------------------------------ -------------------- Robert Duffy eSecureData.com Inc. 1478 Hartley Ave. Coquitlam, BC V3K 7A1 T: (800) 620-1985 F: (800) 620-1986 This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal and or privileged information. Please contact the sender immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on the contents herein. Any communication received in error, or subsequent reply, should be deleted or destroyed. From Curtis.Parish at mtsu.edu Thu Nov 20 22:00:47 2014 From: Curtis.Parish at mtsu.edu (Curtis L. Parish) Date: Thu, 20 Nov 2014 22:00:47 +0000 Subject: Multi-homing with multiple ASNs Message-ID: <848A0CCBF45ABC49B103A3733FA46C506427FB@MTEXMBC01.fsa.mtsu.edu> Greetings, We have recently added a second ISP (third if you count I2). Our first "ISP" is actually a private state network that peers with two Tier 1 providers. We own an AS number and our IP space but at the last minute learned our state network is advertising our network using two different ASNs (neither ours) so they can load balance their connections. If you hit the right looking glass server you can see our network advertised by three different ASNs. We were told by the new ISP that this is a problem but the state network says it is not. Looking for opinions and words of wisdom on this split advertising issue. Thanks curtis Curtis Parish Senior Network Engineer Middle Tennessee State University From freedman at freedman.net Fri Nov 21 04:45:27 2014 From: freedman at freedman.net (Avi Freedman) Date: Thu, 20 Nov 2014 23:45:27 -0500 (EST) Subject: DDOS, IDS, RTBH, and Rate limiting Message-ID: <20141121044527.AE78455000085@freedman.net> > Netflow is stateful stuff, and just to run it on wirespeed, on hardware, > you need to utilise significant part of TCAM, Cisco ASRs and MXs with inline jflow can do hundreds of K flows/second without affecting packet forwarding. > i am not talking that on some hardware it is just impossible to run it. > So everything about netflow are built on assumption that hosting or ISP > can run it. And based on some observations, majority of small/middle > hosting providers are using minimal,just BGP capable L3 switch as core, > and cheapest but reliable L2/L3 on aggregation, and both are capable in > best case to run sampled sFlow. Actually, sFlow from many vendors is pretty good (per your points about flow burstiness and delays), and is good enough for dDoS detection. Not for security forensics, or billing at 99.99% accuracy, but good enough for traffic visibility, peering analytics, and (d)DoS detection. > So for a small hosting(up to 10G), i believe, FastNetMon is best > solution. Faster, and no significant investments to equipment. Bigger > hosting providers might reuse their existing servers, segment the > network, and implement inexpensive monitoring on aggregation switches > without any additional cost again. It can be useful to have a 10G network monitoring box of course... And with the right setup you can run FastNetMon or other tools in addition to generating flow that can be of use for other purposes as well... > Ah, and there is one more huge problem with netflow vs FastNetMon - > netflow just by design cannot be adapted to run pattern matching, while > it is trivial to patch FastNetMon for that, turning it to mini-IDS for > free. It's true, having a network tap can be useful for doing PCAP-y stuff. But taps can be difficult or at least time consuming for people to put in at scale. Even, we've seen, for folks with 10G networks. Often because they can get 90% of what they need for 4 different business purposes from just flow :) > Best regards, > Denys Avi Freedman | Your flow has something to show you; can you see it? | CEO, CloudHelix | (avi at cloudhelix dot com) | my name one word on skype | From contact at winterei.se Fri Nov 21 05:08:12 2014 From: contact at winterei.se (Paul S.) Date: Fri, 21 Nov 2014 14:08:12 +0900 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <3CC1B73E-75BB-4BF3-88A3-D373D1D540E3@arbor.net> <55756125a9cfc9f7e20232aa2ad098d3@visp.net.lb> <05746E25-B823-46B2-A535-B924633D4C49@arbor.net> Message-ID: <546EC8BC.5060007@winterei.se> WANguard from andrisoft has worked well on this for us. It supports flow telemetry and mirrored ports both (We use flows strictly), and does what it says it does. No complaints. On 11/21/2014 午後 12:00, Robert Duffy wrote: > I've been using NTOP for couple of years. I'm mostly looking for something > that can quickly detect DDoS attacks in a datacenter environment. Thanks > for the suggestions. I"ll check them out. > > On Thu, Nov 20, 2014 at 6:50 PM, Tim Jackson wrote: > >> I highly recommend pmacct and it's in-memory tables. Lightweight, easy to >> query and super fast. >> >> You can also easily run multiple aggregates of traffic to find what you are >> interested in, tag common interface types to easily filter traffic.. >> >> Or you can use pmacct to insert this into whatever database you want, AMQP >> or MongoDB.. >> >> My current favorite is using an IMT table for DoS detection and another for >> aggregates for interesting traffic types and querying this every X minutes >> and inserting it into ElasticSearch. Kibana makes the most powerful netflow >> dashboard ever. >> >> -- >> Tim >> On Nov 20, 2014 6:39 PM, "Roland Dobbins" wrote: >> >>> On 21 Nov 2014, at 9:19, Robert Duffy wrote: >>> >>> What open-source NetFlow analysis tools would you recommend for quickly >>>> detecting a DDoS attack? >>>> >>> I generally recommend that folks get started with something like >>> nfdump/nfsen or ntop. There are other, more sophisticated tools out >> there, >>> but these allow one to get up and running quickly, and to gain valuable >>> operational experience with which to evaluate more sophisticated tools, >> if >>> they're needed. >>> >>> ----------------------------------- >>> Roland Dobbins >>> > > From rdobbins at arbor.net Fri Nov 21 06:40:58 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 21 Nov 2014 13:40:58 +0700 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <546EC8BC.5060007@winterei.se> References: <3CC1B73E-75BB-4BF3-88A3-D373D1D540E3@arbor.net> <55756125a9cfc9f7e20232aa2ad098d3@visp.net.lb> <05746E25-B823-46B2-A535-B924633D4C49@arbor.net> <546EC8BC.5060007@winterei.se> Message-ID: <8D0B14D4-16CA-42BE-8AE8-1800CCCDB67A@arbor.net> On 21 Nov 2014, at 12:08, Paul S. wrote: > WANguard from andrisoft has worked well on this for us. I believe the thread was focusing on open-source tools. ----------------------------------- Roland Dobbins From denys at visp.net.lb Fri Nov 21 08:17:00 2014 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Fri, 21 Nov 2014 10:17:00 +0200 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <3CC1B73E-75BB-4BF3-88A3-D373D1D540E3@arbor.net> <55756125a9cfc9f7e20232aa2ad098d3@visp.net.lb> Message-ID: On 2014-11-21 03:12, Roland Dobbins wrote: > On 21 Nov 2014, at 6:22, Denys Fedoryshchenko wrote: > >> Netflow is stateful stuff, > > This is factually incorrect; NetFlow flows are unidirectional in > nature, and in any event have no effect on processing of data-plane > traffic. Word stateful has nothing common with stateful firewall.Stateful protocol. "a protocol which requires keeping of the internal state on the server is known as a stateful protocol." And sure unidirectional/bidirectional is totally unrelated. > >> and just to run it on wirespeed, on hardware, you need to utilise >> significant part of TCAM, > > Again, this is factually incorrect. http://en.wikipedia.org/wiki/NetFlow#NetFlow_support Proof, that majority of solutions runs *flow not in software. Cisco 65xx (yes, they are obsolete, but they run stuff wirespeed) Aug 24 12:30:53: %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM Utilization [97%] This is best example. Also on many Cisco's if you use UBRL, then you cannot use NetFlow, just because they use same part of TCAM resources. Others, for example Juniper, are using sampling (read - missing data), just to not overflow resources, and has various limitations, such as RE-DPC communication pps limit, licensing limit. For example MS-DPC is pretty good one, few million flows in hardware, 7-8Gbps of traffic, and... cost $120000. > >> i am not talking that on some hardware it is just impossible to run >> it. > > This is also factually incorrect. Some platforms/linecards do not in > fact support NetFlow (or other varieties of flow telemetry) due to > hardware limitations. But still they can run fine mirroring, and fastnetmon will do it's job. > >> And last thing, from one of public papers, netflow delaying factors: >> 1. Flow record expiration > > This is tunable. In certain limits. You can't set flow-active-timeout less than 60 seconds in Junos 14 for example. On some platforms even if you can, you just run in the limits of platforms again (forwarding - management communications). > >> • Typical delay: 15-60 sec. > > This is an entirely subjective assessment, and does not reflect > operational realities. These are typically *maximum values* - and > they are well within operationally-useful timeframes. Also, the > effect of NetFlow cache size and resultant FIFOing of flow records is > not taken into account, nor is the effect on flow termination and > flow-record export of TCP FIN or RST flags denoting TCP traffic taken > into account. > >> So for a small hosting(up to 10G), i believe, FastNetMon is best >> solution. > > This is a gross over-generalization unsupported by facts. Many years > of operational experience with NetFlow and other forms of flow > telemetry by large numbers of network operators of all sizes and > varieties contract this over-generalization. Fastnetmon and similar tools popularity says for itself. > > It is generally unwise to make sweeping statements regarding > operational impact which are not borne out by significant operational > experience in production networks. "What can be asserted without evidence can be dismissed without evidence." > >> Faster, and no significant investments to equipment. > > This statement indicates a lack of understanding of opex costs, > irrespective of capex costs. Sweet marketing buzzwords, that is used together with some unclear calculations, to sell suffering hosting providers various expensive tools, that is not necessary for them. OPEX of fastnetmon is a small fee for qualified sysadmin, and often not required, because already hosting operator should have him. > >> Bigger hosting providers might reuse their existing servers, segment >> the network, and implement inexpensive monitoring on aggregation >> switches without any additional cost again. > > This statement indicates a lack of operational experience in networks > of even minimal scale. > >> Ah, and there is one more huge problem with netflow vs FastNetMon - >> netflow just by design cannot be adapted to run pattern matching, >> while it is trivial to patch FastNetMon for that, turning it to >> mini-IDS for free. > > This statement betrays a lack of understanding of NetFlow-based (and > other flow telemetry-based) detection and classification, as well as > the undesirability and negative operational impact of stateful > IDS/'IPS' deployments in production networks. > > You should also note that FastNetMon is far from unique; there are > multiple other open-source tools which provide the same type of > functionality, and none of them have replaced flow telemetry, either. Thats a power of opensource. Since FastNetMon is not only tool, worth to mention others, people here will benefit from using it, for free. And i'm sure, author of FastNetMon will not feel offended at all. > > Tools such as FastNetMon supplement flow telemetry, in situations in > which such tools can be deployed. They do not begin to replace flow > telemetry, and they are not inherently superior to flow telemetry. > > Again, I'm sure FastNetMon is a useful tool in many circumstances. > But it would be a much better idea to define FastNetMon positively in > terms of its own inherent value, rather than attempting to define it > based upon factually incorrect negative 'comparisons' to other > well-established, widely-used technologies which have demonstrable > track records within the global operational community. I can agree only that arguing about this subject is waste of time. FastNetMon has it's narrow specific purpose - detecting very quickly DDoS attacks on <10G bandwidth, where netflow just by design cannot outperform it. But FastNetMon cannot be used for telemetry, and such stuff. --- Best regards, Denys From denys at visp.net.lb Fri Nov 21 09:03:54 2014 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Fri, 21 Nov 2014 11:03:54 +0200 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <20141121044527.AE78455000085@freedman.net> References: <20141121044527.AE78455000085@freedman.net> Message-ID: <3c9ecc2195ee0b41c8d577e15a04a3e5@visp.net.lb> On 2014-11-21 06:45, freedman at freedman.net wrote: >> Netflow is stateful stuff, and just to run it on wirespeed, on >> hardware, >> you need to utilise significant part of TCAM, > > Cisco ASRs and MXs with inline jflow can do hundreds of K flows/second > without affecting packet forwarding. Yes, i agree,those are good for netflow, but when they already exist in network. Does it worth to buy ASR, if L3 switch already doing the job (BGP/ACL/rate-limit/routing)? > >> i am not talking that on some hardware it is just impossible to run >> it. >> So everything about netflow are built on assumption that hosting or >> ISP >> can run it. And based on some observations, majority of small/middle >> hosting providers are using minimal,just BGP capable L3 switch as >> core, >> and cheapest but reliable L2/L3 on aggregation, and both are capable >> in >> best case to run sampled sFlow. > > Actually, sFlow from many vendors is pretty good (per your points about > flow > burstiness and delays), and is good enough for dDoS detection. Not for > security forensics, or billing at 99.99% accuracy, but good enough for > traffic visibility, peering analytics, and (d)DoS detection. Well, if it is available, except hardware limitations, there is second obstacle, software licensing cost. On latest JunOS, for example on EX2200, you need to purchase license (EFL), and if am not wrong it is $3000 for 48port units. So if only sFlow feature is on stake, it worth to think, to purchase license, or to purchase server. Prices for JFlow license on MX, just for 5/10G is way above cost of very decent server. > > > >> So for a small hosting(up to 10G), i believe, FastNetMon is best >> solution. Faster, and no significant investments to equipment. Bigger >> hosting providers might reuse their existing servers, segment the >> network, and implement inexpensive monitoring on aggregation switches >> without any additional cost again. > > It can be useful to have a 10G network monitoring box of course... > > And with the right setup you can run FastNetMon or other tools in > addition to generating flow that can be of use for other purposes > as well... Technically there is ipt_NETFLOW, that can generate netflow on same box, for statistical/telemetry purposes. But i am not sure it is possible to run them together. > >> Ah, and there is one more huge problem with netflow vs FastNetMon - >> netflow just by design cannot be adapted to run pattern matching, >> while >> it is trivial to patch FastNetMon for that, turning it to mini-IDS for >> free. > > It's true, having a network tap can be useful for doing PCAP-y stuff. > > But taps can be difficult or at least time consuming for people to > put in at scale. Even, we've seen, for folks with 10G networks. > Often because they can get 90% of what they need for 4 different > business purposes from just flow :) About scaling, i guess it depends on proper deployment strategy and sysadmins/developers capabilities. For example to deploy new ruleset for my pcap-based "homemade" analyser to 150 probes across the country - is just one click. --- Best regards, Denys From mark.tinka at seacom.mu Fri Nov 21 09:07:49 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 21 Nov 2014 11:07:49 +0200 Subject: Multi-homing with multiple ASNs In-Reply-To: <848A0CCBF45ABC49B103A3733FA46C506427FB@MTEXMBC01.fsa.mtsu.edu> References: <848A0CCBF45ABC49B103A3733FA46C506427FB@MTEXMBC01.fsa.mtsu.edu> Message-ID: <201411211107.50085.mark.tinka@seacom.mu> On Friday, November 21, 2014 12:00:47 AM Curtis L. Parish wrote: > We have recently added a second ISP (third if you count > I2). Our first "ISP" is actually a private state > network that peers with two Tier 1 providers. We own an > AS number and our IP space but at the last minute > learned our state network is advertising our network > using two different ASNs (neither ours) so they can load > balance their connections. If you hit the right > looking glass server you can see our network advertised > by three different ASNs. We were told by the new ISP > that this is a problem but the state network says it is > not. > > Looking for opinions and words of wisdom on this split > advertising issue. Why aren't you originating your own prefixes and ASN by yourselves, since you own both? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From ww at styx.org Fri Nov 21 10:06:38 2014 From: ww at styx.org (William Waites) Date: Fri, 21 Nov 2014 10:06:38 +0000 (GMT) Subject: Multi-homing with multiple ASNs In-Reply-To: <201411211107.50085.mark.tinka@seacom.mu> References: <848A0CCBF45ABC49B103A3733FA46C506427FB@MTEXMBC01.fsa.mtsu.edu> <201411211107.50085.mark.tinka@seacom.mu> Message-ID: <20141121.100638.1719679148275869114.ww@styx.org> On Fri, 21 Nov 2014 11:07:49 +0200, Mark Tinka said: >> We own an AS number and our IP space but at the last minute >> learned our state network is advertising our network using two >> different ASNs (neither ours) This will work, as in the BGP path selection algorithm will work as designed in this situation. But it also means that the routing policy is out of your control which is kind of the point of having an ASN! It also makes it harder to track down who is operationally responsible for that address space since it appears to the outside world to be in two (or three! different places). I'd say don't do this unless you really have no choice. > Why aren't you originating your own prefixes and ASN by > yourselves, since you own both? Good question. We (AS60241) almost ended up doing similarly for a while. Because of a close association with the universities in Scotland, we discussed the possibility of transit via JANET. This turned out to be difficult because they run a whole bunch of private ASNs internally -- unlike in North America where universities typically have their own real one. So it would have been us -> private stuff -> AS786 and for some reason that I forget they were unable to remove private ASNs from the path. The best that might have been possible would be to have had them announce our networks with synchronisation on, which would have meant the outside world would have seen them originating in both AS786 and AS60241. Icky. We (mutually) decided against this. Just to say that there are strange, but not completely unreasonable circumstances in which this can happen... -w -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From bill at herrin.us Fri Nov 21 10:23:43 2014 From: bill at herrin.us (William Herrin) Date: Fri, 21 Nov 2014 05:23:43 -0500 Subject: Multi-homing with multiple ASNs In-Reply-To: <848A0CCBF45ABC49B103A3733FA46C506427FB@MTEXMBC01.fsa.mtsu.edu> References: <848A0CCBF45ABC49B103A3733FA46C506427FB@MTEXMBC01.fsa.mtsu.edu> Message-ID: On Thu, Nov 20, 2014 at 5:00 PM, Curtis L. Parish wrote: > We have recently added a second ISP (third if you count I2). > Our first "ISP" is actually a private state network that peers with > two Tier 1 providers. We own an AS number and our IP space > but at the last minute learned our state network is advertising > our network using two different ASNs (neither ours) so they can > load balance their connections. If you hit the right looking glass > server you can see our network advertised by three different > ASNs. We were told by the new ISP that this is a problem but > the state network says it is not. Howdy, If you drop your connection to the state network, do the routes with their AS numbers drop out of the looking glasses? If not, then there's a problem. If you depreference your connection to the state network by prepending your AS number, do comparable prepends appear at the looking glasses or does the state network continue to give its advertisement of your address space top billing? If the state network's behavior strips your ability to load balance your network then there's a problem. Conventionally, the state network should be adding its AS number after yours, not stripping your AS number. More often than not, this convention is also the technically correct course of action. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From rdobbins at arbor.net Fri Nov 21 12:50:39 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 21 Nov 2014 19:50:39 +0700 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <3CC1B73E-75BB-4BF3-88A3-D373D1D540E3@arbor.net> <55756125a9cfc9f7e20232aa2ad098d3@visp.net.lb> Message-ID: On 21 Nov 2014, at 15:17, Denys Fedoryshchenko wrote: > Word stateful has nothing common with stateful firewall.Stateful > protocol. "a protocol which requires keeping of the internal state on > the server is known as a stateful protocol." Correct - and NetFlow is not stateful, by this definition. > And sure unidirectional/bidirectional is totally unrelated. On the contrary, it is quite relevant. > Cisco 65xx (yes, they are obsolete, but they run stuff wirespeed) They are not obsolete - they perform very well with Sup2T and EARL8-based linecards. > Aug 24 12:30:53: %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold > exceeded, TCAM Utilization [97%] This is from a 6500 with either an EARL6 or EARL7 ASIC, which had many caveats with regards to NetFlow, including a lack of packet-sampled control of flow creation - i.e., sampled NetFlow. As part of the extended team which defined requirements for the EARL8 ASIC, which is utilized in the Sup2T and DFC-4 enabled linecards, I can assure you that this is no longer an issue with 6500s running EARL8-based Sups and linecards. > Also on many Cisco's if you use UBRL, then you cannot use NetFlow, > just because they use same part of TCAM resources. This is where TCAM carving comes into play. Also, it is not so much an issue with newer hardware, per the above. Also, URBL is not commonly used in ISP networks. > Others, for example Juniper, are using sampling (read - missing data), The largest networks in the world use sampled NetFlow every hour of every day for many purposes, including DDoS detection/classification/traceback. It works quite well for all those purposes. > just to not overflow resources, and has various limitations, such as > RE-DPC communication pps limit, licensing limit. > For example MS-DPC is pretty good one, few million flows in hardware, > 7-8Gbps of traffic, and... cost $120000. You get what you pay for. > But still they can run fine mirroring, and fastnetmon will do it's > job. On the contrary - SPAN nee port mirroring cuts into the frames-per-second budget of linecards, as the traffic is in essence being duplicated. It is not 'free', and it has a profound impact on the the switch's data-plane traffic forwarding capacity. Unlike NetFlow. > In certain limits. You can't set flow-active-timeout less than 60 > seconds in Junos 14 for example. Platforms vary, this is true. However, I have never run into an issue with an active flow timer of 60s, nor have I ever run into anyone who has done so. > On some platforms even if you can, you just run in the limits of > platforms again (forwarding - management communications). This is incorrect. > Fastnetmon and similar tools popularity says for itself. Yes, it does - they are far less popular that NetFlow, because they do not scale on networks of any size, nor do they provide traceback (given your lack of comments on traceback elsewhere in this thread, it appears that you aren't familiar with this concept). > "What can be asserted without evidence can be dismissed without > evidence." You make my point very well, thank you. There is overwhelming evidence that NetFlow and similar forms of flow telemetry scale well and provide real, measurable, actionable operational value on networks of all types and sizes. The reason for the popularity of flow telemetry is that it is low-opex (no probes to deply); low-capex (no probes to deploy); scales to tb/sec speeds; is practicable for large networks (no probes to deploy); provides instantaneous traceback (probes can't do this); and provides statistics on dropped traffic (probes can't do this, either). > Sweet marketing buzzwords, It's pretty obvious which half of this 'conversation' is focused on marketing; and it isn't mine. > that is used together with some unclear calculations, No calculations have been discussed during the course of this 'conversation'. > to sell suffering hosting providers various expensive tools, I'm uninterested in selling anyone anything. What I'm interested in doing is correcting the misinformation you are promulgating regarding the utility of flow telemetry coupled with open-source flow analysis systems. There has been no mention of any commercial systems or products in my half of this 'conversation'. > that is not necessary for them. Again, the benefits of flow telemetry are quite clear for networks of any size. > OPEX of fastnetmon is a small fee for qualified sysadmin, and often > not required, because already hosting operator should have him. You obviously do not know what the term opex actually means, nor what it encompasses. > I can agree only that arguing about this subject is waste of time. Yes, it isn't a profitable use of time to argue with someone who does not have the degree of operational expertise nor experience to back his demonstrably incorrect assertions. > where netflow just by design cannot outperform it Again, this is a completely unsupported statement with no basis in fact, and it totally ignores the inherent characteristics of flow telemetry (instantaneous traceback, statistics on dropped traffic, scalability, low opex) which make it eminently suitable for these various applications. To be clear - the particular tool you are doing such a poor job of advocating is in no way unique, and is completely orthogonal to the utility, capabilities, and scalability of flow telemetry. If such tools were so superior to flow telemetry, they would've eclipsed flow telemetry as the preferred mechanism for achieving visibility into network traffic many years ago. I am going to stop replying to your trolling, because you obviously do not have the requisite operational experience and depth/breadth of knowledge to even try to plausibly support your demonstrably-incorrect assertions. One can only hope that such a potentially useful tool as FastNetMon isn't tarnished in the view of those who have read this thread due to such uninformed, erroneous misadvocacy. ----------------------------------- Roland Dobbins From denys at visp.net.lb Fri Nov 21 14:42:40 2014 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Fri, 21 Nov 2014 16:42:40 +0200 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <3CC1B73E-75BB-4BF3-88A3-D373D1D540E3@arbor.net> <55756125a9cfc9f7e20232aa2ad098d3@visp.net.lb> Message-ID: <0b4ffd2d69f256e0b63e65604c04b5c2@visp.net.lb> On 2014-11-21 14:50, Roland Dobbins wrote: > On 21 Nov 2014, at 15:17, Denys Fedoryshchenko wrote: > >> Word stateful has nothing common with stateful firewall.Stateful >> protocol. "a protocol which requires keeping of the internal state on >> the server is known as a stateful protocol." > > Correct - and NetFlow is not stateful, by this definition. Not stateful, if you pick on "server" word. To be able to make bytes/packets accounting for a flow, you need to keep this specific flow previous state. To be able to differentiate between flows with same src/dst ip+ports (if one is ended, next is started with same data) you need to track it's state, again. And just to keep track of _flows_ in packet switched network you need states. Surprising lack of knowledge. > >> And sure unidirectional/bidirectional is totally unrelated. > > On the contrary, it is quite relevant. > >> Cisco 65xx (yes, they are obsolete, but they run stuff wirespeed) > > They are not obsolete - they perform very well with Sup2T and > EARL8-based linecards. Seems yes, i'm wrong on that point, i was not successful to run netflow reliable way , but it was before CSCul90377 and CSCui17732 fixed. > >> Others, for example Juniper, are using sampling (read - missing data), > > The largest networks in the world use sampled NetFlow every hour of > every day for many purposes, including DDoS > detection/classification/traceback. It works quite well for all those > purposes. Use case of fastnetmon is not largest networks. Sampled netflow is useless for per-traffic billing purpose for example. > >> just to not overflow resources, and has various limitations, such as >> RE-DPC communication pps limit, licensing limit. >> For example MS-DPC is pretty good one, few million flows in hardware, >> 7-8Gbps of traffic, and... cost $120000. > > You get what you pay for. While i can pay $1500 for a server, and get netflow and ~3second BGP blackholing with fastnetmon. > >> But still they can run fine mirroring, and fastnetmon will do it's >> job. > > On the contrary - SPAN nee port mirroring cuts into the > frames-per-second budget of linecards, as the traffic is in essence > being duplicated. It is not 'free', and it has a profound impact on > the the switch's data-plane traffic forwarding capacity. > > Unlike NetFlow. In hosting case mirroring usually done for uplink port, but i have to agree, it might be a problem. > Yes, it does - they are far less popular that NetFlow, because they do > not scale on networks of any size, nor do they provide traceback > (given your lack of comments on traceback elsewhere in this thread, it > appears that you aren't familiar with this concept). > You make my point very well, thank you. There is overwhelming > evidence that NetFlow and similar forms of flow telemetry scale well > and provide real, measurable, actionable operational value on networks > of all types and sizes. The reason for the popularity of flow > telemetry is that it is low-opex (no probes to deply); low-capex (no > probes to deploy); scales to tb/sec speeds; is practicable for large > networks (no probes to deploy); provides instantaneous traceback > (probes can't do this); and provides statistics on dropped traffic > (probes can't do this, either). And again and again we are going to tb/s. I don't need TB/s, i dont need traceback,nor on relatively small ISP nor on VDS provider i dont need all that above. I just need inexpensive way to block attacked ip and/or announce it from different location within minimal timeframe, to minimize impact on other customers. You might be highly professional with large scale operators, but small guys needs and capabilities are very different. I had developed tool similar to fastnetmon for almost same purpose, detecting attacks and switching affected network by BGP to "protected" backbone. After calculating "OPEX/CAPEX", capable server turned to be much cheaper alternative in short and long term than buying netflow capable hardware (and support for it) just for netflow purposes, and buying hardware for netflow collector. Let's talk numbers. My case is small hosting, 4G, C4948-10G, one 10G uplink, one 10G port is free. Switch is not capable to run sFlow or Netflow. Decent server is available already, since it is hosting company, so the only expenses are 10G 82599 card, which is around $500. Even in case server is not available, based on data from fastnetmon author still total cost is within $1500. Deployment time - hours from installing hardware, without distrupting existing traffic. "Major" expenses - tuning server according author recommendations, and writing shell script that will send to 4948 command to blackhope IP. For qualified sysadmin it is 2 hours of work, and $500 max as a "labor" cost. Thats it. What can be cheaper than $2000 in this case? I guess i wont get answer. > I'm uninterested in selling anyone anything. What I'm interested in > doing is correcting the misinformation you are promulgating regarding > the utility of flow telemetry coupled with open-source flow analysis > systems. There has been no mention of any commercial systems or > products in my half of this 'conversation'. I didn't meant you at all, but i meant when i'm hearing OPEX/CAPEX, often it is not real detailed calculations, but some very well unrealistic mangled numbers, that surprisingly looks for good marketed product, and bad for competing products. > I am going to stop replying to your trolling, because you obviously do > not have the requisite operational experience and depth/breadth of > knowledge to even try to plausibly support your demonstrably-incorrect > assertions. One can only hope that such a potentially useful tool as > FastNetMon isn't tarnished in the view of those who have read this > thread due to such uninformed, erroneous misadvocacy. So much arrogance. But on something i have to agree, again, it is perfect idea to stop this useless flamewar. --- Best regards, Denys From Curtis.Parish at mtsu.edu Fri Nov 21 14:49:17 2014 From: Curtis.Parish at mtsu.edu (Curtis L. Parish) Date: Fri, 21 Nov 2014 14:49:17 +0000 Subject: Multi-homing with multiple ASNs In-Reply-To: References: <848A0CCBF45ABC49B103A3733FA46C506427FB@MTEXMBC01.fsa.mtsu.edu> Message-ID: <848A0CCBF45ABC49B103A3733FA46C5064467F@MTEXMBC01.fsa.mtsu.edu> Thanks for all the responses. I will answer a few questions that have come on and off list. (Sorry for length) We advertise our ASN into the state network with more specific routes that we advertise via ISP2 via our ASN. This is done because the state (vendor managed) network runs stateful firewalls and we have to force other multi-home entities on the state network to use our state connection instead of ISP2. Our network has been removed from the state firewall due to previous problems with asymmetric routing with our I2 circuit. I am told the state network does drop our network from their advertisements when our network is unreachable. That has not been explained or tested. What we did not realize until about a week before turning up ISP2 was the state was consolidating all state networks to use two of the vendor’s ASNs when it peers with their two ISPs. Our ASN is not part of the path. We had no choice but to turn up ISP2 due to bandwidth reasons. Miraculously we achieved almost a 50/50 balance of traffic. Bandwidth will be increased on ISP2 as demand grows so we will need the ability to prepend on the state network to make ISP2 look more desirable. I believe the state will modify their advertisements to add our ASN to the path but changes to advertising via the state network has to go through a design and change management process and then be scheduled into maintenance windows. Any attempts to balance the traffic via prepending will take weeks. As long as the traffic stays balanced we are OK. When replaying BGP route changes I normally see our network only advertised out one of state ASNs but occasionally I see it with two so traffic balance may be impacted depending on which ISP the state is egressing. Here is a question. I know that having one network advertised by multiple ASNs is unconventional and thus it will probably be harder to get help troubleshooting routing problems when they arise. Do you see a situation where our network might be caught in a loop or black hole due to asymmetric routing and conflicting advertisements? Thanks again. New to the list but have already learned much by reading the archives. Curtis Curtis Parish Senior Network Engineer Middle Tennessee State University Subject: Re: Multi-homing with multiple ASNs Howdy, If you drop your connection to the state network, do the routes with their AS numbers drop out of the looking glasses? If not, then there's a problem. If you depreference your connection to the state network by prepending your AS number, do comparable prepends appear at the looking glasses or does the state network continue to give its advertisement of your address space top billing? If the state network's behavior strips your ability to load balance your network then there's a problem. Conventionally, the state network should be adding its AS number after yours, not stripping your AS number. More often than not, this convention is also the technically correct course of action. From fergdawgster at mykolab.com Fri Nov 21 14:59:07 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Fri, 21 Nov 2014 06:59:07 -0800 Subject: Transit, Exchange Point Agreements, and Acceptable Use? Message-ID: <546F533B.4090807@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'll apologize up front if this offends anyone's sensitivities as to what is relevant for list conversation... but one sentence in this Channel4 News story (from what I understand, Channel4 is a very popular news source in the UK) struck me as perhaps in violation of some sort of peering and/or transit agreement. Cable and Wireless: "...even went as far as providing traffic from a rival foreign communications company, handing information sent by millions of internet users worldwide over to spies." The entire article is here: http://www.channel4.com/news/spy-cable-revealed-how-telecoms-firm-worked-with-gchq My question is this: Do willful actions such as these violate peering, transit, and/or exchange agreements in any way? Thanks, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlRvUzsACgkQKJasdVTchbKc3AD+OBNKXfYJ/Vjsa2pYL7+ewvql 629C4Ie5jzPgIpAgrToA/1gdeKQX69OHOc79RwsI6uUq99cRoDsHOSf3zTDnwsZy =7Xps -----END PGP SIGNATURE----- From corbe at corbe.net Fri Nov 21 15:07:36 2014 From: corbe at corbe.net (Daniel Corbe) Date: Fri, 21 Nov 2014 10:07:36 -0500 Subject: Transit, Exchange Point Agreements, and Acceptable Use? In-Reply-To: <546F533B.4090807@mykolab.com> (Paul Ferguson's message of "Fri, 21 Nov 2014 06:59:07 -0800") References: <546F533B.4090807@mykolab.com> Message-ID: Paul Ferguson writes: > I'll apologize up front if this offends anyone's sensitivities as to > what is relevant for list conversation... but one sentence in this > Channel4 News story (from what I understand, Channel4 is a very > popular news source in the UK) struck me as perhaps in violation of > some sort of peering and/or transit agreement. Cable and Wireless: > > "...even went as far as providing traffic from a rival foreign > communications company, handing information sent by millions of > internet users worldwide over to spies." > > The entire article is here: > > http://www.channel4.com/news/spy-cable-revealed-how-telecoms-firm-worked-with-gchq > > My question is this: Do willful actions such as these violate peering, > transit, and/or exchange agreements in any way? > > Thanks, > > - ferg Welcome to the modern age of communications. The privacy nuts and tinfoil hat types turned out to be correct. Assume that you have no privacy and encrypt everything you do. Or just stop caring about privacy all together. Either way, not much has actually changed. From David.Siegel at Level3.com Fri Nov 21 15:09:55 2014 From: David.Siegel at Level3.com (Siegel, David) Date: Fri, 21 Nov 2014 15:09:55 +0000 Subject: Transit, Exchange Point Agreements, and Acceptable Use? In-Reply-To: <546F533B.4090807@mykolab.com> References: <546F533B.4090807@mykolab.com> Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC0730B0611@USIDCWVEMBX10.corp.global.level3.com> Most written peering agreements have a clause that says you can't provide that data unless required to by authorities and only in compliance with applicable local law. The article says that's still an open question: "Channel 4 News has been unable to establish whether Reliance Communications was served with a warrant to authorise this and the company has not responded to our calls." Dave -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul Ferguson Sent: Friday, November 21, 2014 7:59 AM To: NANOG Subject: Transit, Exchange Point Agreements, and Acceptable Use? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'll apologize up front if this offends anyone's sensitivities as to what is relevant for list conversation... but one sentence in this Channel4 News story (from what I understand, Channel4 is a very popular news source in the UK) struck me as perhaps in violation of some sort of peering and/or transit agreement. Cable and Wireless: "...even went as far as providing traffic from a rival foreign communications company, handing information sent by millions of internet users worldwide over to spies." The entire article is here: http://www.channel4.com/news/spy-cable-revealed-how-telecoms-firm-worked-with-gchq My question is this: Do willful actions such as these violate peering, transit, and/or exchange agreements in any way? Thanks, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlRvUzsACgkQKJasdVTchbKc3AD+OBNKXfYJ/Vjsa2pYL7+ewvql 629C4Ie5jzPgIpAgrToA/1gdeKQX69OHOc79RwsI6uUq99cRoDsHOSf3zTDnwsZy =7Xps -----END PGP SIGNATURE----- From fergdawgster at mykolab.com Fri Nov 21 15:12:48 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Fri, 21 Nov 2014 07:12:48 -0800 Subject: Transit, Exchange Point Agreements, and Acceptable Use? In-Reply-To: References: <546F533B.4090807@mykolab.com> Message-ID: <546F5670.7070600@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/21/2014 7:07 AM, Daniel Corbe wrote: > > Paul Ferguson writes: > >> I'll apologize up front if this offends anyone's sensitivities as >> to what is relevant for list conversation... but one sentence in >> this Channel4 News story (from what I understand, Channel4 is a >> very popular news source in the UK) struck me as perhaps in >> violation of some sort of peering and/or transit agreement. Cable >> and Wireless: >> >> "...even went as far as providing traffic from a rival foreign >> communications company, handing information sent by millions of >> internet users worldwide over to spies." >> >> The entire article is here: >> >> http://www.channel4.com/news/spy-cable-revealed-how-telecoms-firm-worked-with-gchq >> >> >> My question is this: Do willful actions such as these violate peering, >> transit, and/or exchange agreements in any way? >> >> Thanks, >> >> - ferg > > Welcome to the modern age of communications. The privacy nuts and > tinfoil hat types turned out to be correct. Assume that you have > no privacy and encrypt everything you do. Or just stop caring > about privacy all together. Either way, not much has actually > changed. > Well, yes, of course I understand that you should encrypt any & every thing that you wish to protect, and believe me -- I (more than most) understand the long tug of war between telecommunications companies and national intelligence services. But you did not address my question... ;-) Cheers, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlRvVnAACgkQKJasdVTchbIviwEAk1UQEY/sCwGi0Qua15lCzdPv NWHofFXWJkk+GEjGYMMA/RuOJcL4r+DCr526WsFU/8lGYk80M78pB7rhogN9pgs2 =Oxw/ -----END PGP SIGNATURE----- From fergdawgster at mykolab.com Fri Nov 21 15:13:40 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Fri, 21 Nov 2014 07:13:40 -0800 Subject: Transit, Exchange Point Agreements, and Acceptable Use? In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC0730B0611@USIDCWVEMBX10.corp.global.level3.com> References: <546F533B.4090807@mykolab.com> <970945E55BFD8C4EA4CAD74B647A9DC0730B0611@USIDCWVEMBX10.corp.global.level3.com> Message-ID: <546F56A4.4040806@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/21/2014 7:09 AM, Siegel, David wrote: > Most written peering agreements have a clause that says you can't > provide that data unless required to by authorities and only in > compliance with applicable local law. > > The article says that's still an open question: > > "Channel 4 News has been unable to establish whether Reliance > Communications was served with a warrant to authorise this and the > company has not responded to our calls." > Right, I noticed that bit. :-) Cheers, - - ferg > Dave > > > -----Original Message----- From: NANOG > [mailto:nanog-bounces at nanog.org] On Behalf Of Paul Ferguson Sent: > Friday, November 21, 2014 7:59 AM To: NANOG Subject: Transit, > Exchange Point Agreements, and Acceptable Use? > > I'll apologize up front if this offends anyone's sensitivities as > to what is relevant for list conversation... but one sentence in > this Channel4 News story (from what I understand, Channel4 is a > very popular news source in the UK) struck me as perhaps in > violation of some sort of peering and/or transit agreement. Cable > and Wireless: > > "...even went as far as providing traffic from a rival foreign > communications company, handing information sent by millions of > internet users worldwide over to spies." > > The entire article is here: > > http://www.channel4.com/news/spy-cable-revealed-how-telecoms-firm-worked-with-gchq > > My question is this: Do willful actions such as these violate > peering, transit, and/or exchange agreements in any way? > > Thanks, > > - ferg > > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlRvVqQACgkQKJasdVTchbJ6kgEAi3mOTZJ0FxEOg0b/x049hwyE CdrWUHXSsxRlu4P5KZUA/0KT0XzPzvH0O/ZUhjT8xL+gWxGXPQcwSNk1slJ6oQE4 =tXZ4 -----END PGP SIGNATURE----- From Thijs.Stuurman at is.nl Fri Nov 21 15:52:00 2014 From: Thijs.Stuurman at is.nl (Thijs Stuurman) Date: Fri, 21 Nov 2014 15:52:00 +0000 Subject: Incident notification Message-ID: Nanog list members, I was looking at some statistic and noticed we are sending out a massive amount of SMS messages from our monitoring systems. This left me wondering if there isn't a better (and cheaper) alternative to this, something just as reliant but IP based. We all have smartphones these days anyway. Therefore my question, what are you using to notify admins of incidents? Kind regards / Met vriendelijke groet, Thijs Stuurman [IS Logo] ________________________________ IS Group Wielingenstraat 8 T +31 (0)299 476 185 info at is.nl 1441 ZR Purmerend F +31 (0)299 476 288 www.is.nl ________________________________ IS Group is ISO 9001:2008, ISO/IEC 27001:2005, ISO 20.000-1:2005, ISAE 3402 certified. De datacenters zijn PCI DSS en ISO 14001 compliant. From mhuff at ox.com Fri Nov 21 15:56:49 2014 From: mhuff at ox.com (Matthew Huff) Date: Fri, 21 Nov 2014 15:56:49 +0000 Subject: Incident notification In-Reply-To: References: Message-ID: <56d90aa95fd74351bc94cae17ce1aba5@pur-vm-exch13n2.ox.com> The advantage of SMS is that it is out of band. Any smtp or other IP based solution requires a stable and working network environment, which is what the alert may be trying to tell you is down. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 aim: matthewbhuff        | Fax:   914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Thijs Stuurman Sent: Friday, November 21, 2014 10:52 AM To: nanog at nanog.org Subject: Incident notification Nanog list members, I was looking at some statistic and noticed we are sending out a massive amount of SMS messages from our monitoring systems. This left me wondering if there isn't a better (and cheaper) alternative to this, something just as reliant but IP based. We all have smartphones these days anyway. Therefore my question, what are you using to notify admins of incidents? Kind regards / Met vriendelijke groet, Thijs Stuurman [IS Logo] ________________________________ IS Group Wielingenstraat 8 T +31 (0)299 476 185 info at is.nl 1441 ZR Purmerend F +31 (0)299 476 288 www.is.nl ________________________________ IS Group is ISO 9001:2008, ISO/IEC 27001:2005, ISO 20.000-1:2005, ISAE 3402 certified. De datacenters zijn PCI DSS en ISO 14001 compliant. From josh at imaginenetworksllc.com Fri Nov 21 15:57:10 2014 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 21 Nov 2014 10:57:10 -0500 Subject: Incident notification In-Reply-To: References: Message-ID: Pagerduty for phone calls. Can do SMS as well, I believe. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Nov 21, 2014 at 10:52 AM, Thijs Stuurman wrote: > Nanog list members, > > I was looking at some statistic and noticed we are sending out a massive > amount of SMS messages from our monitoring systems. > This left me wondering if there isn't a better (and cheaper) alternative > to this, something just as reliant but IP based. We all have smartphones > these days anyway. > > Therefore my question, what are you using to notify admins of incidents? > > Kind regards / Met vriendelijke groet, > > Thijs Stuurman > > > > [IS Logo] > > > ________________________________ > > IS Group > > Wielingenstraat 8 > > T > > +31 (0)299 476 185 > > info at is.nl > > 1441 ZR Purmerend > > F > > +31 (0)299 476 288 > > www.is.nl > > ________________________________ > > IS Group is ISO 9001:2008, ISO/IEC 27001:2005, ISO 20.000-1:2005, ISAE > 3402 certified. De datacenters zijn PCI DSS en ISO 14001 compliant. > > > From Derek.Andrew at usask.ca Fri Nov 21 15:56:49 2014 From: Derek.Andrew at usask.ca (Derek Andrew) Date: Fri, 21 Nov 2014 09:56:49 -0600 Subject: Incident notification In-Reply-To: <7d505a64b2cb49bda61beeb3b11f63d8@CAMPUSCAS4.usask.ca> References: <7d505a64b2cb49bda61beeb3b11f63d8@CAMPUSCAS4.usask.ca> Message-ID: While we do not do this ourseleves, I wonder why we would not use Twitter. You can receive SMS, or texts in the app on a smart phone, or look at a webpage. You can make them private and have lots of subscribers. I find Twitter more reliable that our local SMS providers too. d On Fri, Nov 21, 2014 at 9:52 AM, Thijs Stuurman wrote: > Nanog list members, > > I was looking at some statistic and noticed we are sending out a massive > amount of SMS messages from our monitoring systems. > This left me wondering if there isn't a better (and cheaper) alternative > to this, something just as reliant but IP based. We all have smartphones > these days anyway. > > Therefore my question, what are you using to notify admins of incidents? > > Kind regards / Met vriendelijke groet, > > Thijs Stuurman > > > > [IS Logo] > > > ________________________________ > > IS Group > > Wielingenstraat 8 > > T > > +31 (0)299 476 185 > > info at is.nl > > 1441 ZR Purmerend > > F > > +31 (0)299 476 288 > > www.is.nl > > ________________________________ > > IS Group is ISO 9001:2008, ISO/IEC 27001:2005, ISO 20.000-1:2005, ISAE > 3402 certified. De datacenters zijn PCI DSS en ISO 14001 compliant. > > > -- Copyright 2014 Derek Andrew (excluding quotations) +1 306 966 4808 Information Systems University of Saskatchewan Peterson 120; 54 Innovation Boulevard Saskatoon,Saskatchewan,Canada. S7N 2V3 Timezone GMT-6 Typed but not read. From Thijs.Stuurman at is.nl Fri Nov 21 15:59:47 2014 From: Thijs.Stuurman at is.nl (Thijs Stuurman) Date: Fri, 21 Nov 2014 15:59:47 +0000 Subject: Incident notification In-Reply-To: <56d90aa95fd74351bc94cae17ce1aba5@pur-vm-exch13n2.ox.com> References: <56d90aa95fd74351bc94cae17ce1aba5@pur-vm-exch13n2.ox.com> Message-ID: > The advantage of SMS is that it is out of band. Any smtp or other IP based solution requires a stable and working network environment, which is what the alert may be trying to tell you is down. I do not worry so much about that, part of the monitoring solution is out of band for that reason. Kind regards / Met vriendelijke groet, Thijs Stuurman From alter3d at alter3d.ca Fri Nov 21 16:04:03 2014 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Fri, 21 Nov 2014 11:04:03 -0500 Subject: Incident notification In-Reply-To: References: Message-ID: <546F6273.6030400@alter3d.ca> We use OpsGenie for notifications (and on-call scheduling, etc). There are other similar options such as PagerDuty, etc, as well. Notifications can be submitted to the service in a variety of ways (email, web API, etc), has a variety of integrations with other tools (Nagios, Pingdom, etc) to aggregate all of your alerts, and there is a callback mechanism where the user can trigger custom actions right from the app (for example, I wrote an interface for it such that when we get an alert, the on-call person can choose to restart the affected service -- or even reboot the entire VM hosting it -- right from within the OpsGenie app). Each user can choose their method of contact (notification to the smartphone app, SMS, phone call, email, whatever), and on-call schedules (and exceptions) are easily managed. It works for us... YMMV. ;) - Peter On 11/21/2014 10:52 AM, Thijs Stuurman wrote: > Nanog list members, > > I was looking at some statistic and noticed we are sending out a massive amount of SMS messages from our monitoring systems. > This left me wondering if there isn't a better (and cheaper) alternative to this, something just as reliant but IP based. We all have smartphones these days anyway. > > Therefore my question, what are you using to notify admins of incidents? > > Kind regards / Met vriendelijke groet, > > Thijs Stuurman > > > > [IS Logo] > > > ________________________________ > > IS Group > > Wielingenstraat 8 > > T > > +31 (0)299 476 185 > > info at is.nl > > 1441 ZR Purmerend > > F > > +31 (0)299 476 288 > > www.is.nl > > ________________________________ > > IS Group is ISO 9001:2008, ISO/IEC 27001:2005, ISO 20.000-1:2005, ISAE 3402 certified. De datacenters zijn PCI DSS en ISO 14001 compliant. > > From digitallystoned at gmail.com Fri Nov 21 16:29:02 2014 From: digitallystoned at gmail.com (N M) Date: Fri, 21 Nov 2014 10:29:02 -0600 Subject: Level3 NOC contact Message-ID: Could a NOC engineer from Level3 contact me off list? I am having issues out of Dallas on a circuit with traffic on your network -- Latency above 100ms --- My peer claims the issue is fixed but I am still seeing the same problem -- Thanks *Nathan Mallory* *Network Engineer* Opelika Power Services 600 Fox Run Pkwy Opelika, Al 36801 Office: (334) 705-1601 From peter.phaal at gmail.com Fri Nov 21 16:41:41 2014 From: peter.phaal at gmail.com (Peter Phaal) Date: Fri, 21 Nov 2014 08:41:41 -0800 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <3c9ecc2195ee0b41c8d577e15a04a3e5@visp.net.lb> References: <20141121044527.AE78455000085@freedman.net> <3c9ecc2195ee0b41c8d577e15a04a3e5@visp.net.lb> Message-ID: >> Actually, sFlow from many vendors is pretty good (per your points about >> flow >> burstiness and delays), and is good enough for dDoS detection. Not for >> security forensics, or billing at 99.99% accuracy, but good enough for >> traffic visibility, peering analytics, and (d)DoS detection. > > Well, if it is available, except hardware limitations, there is second > obstacle, > software licensing cost. On latest JunOS, for example on EX2200, you need > to purchase license (EFL), and if am not wrong it is $3000 for 48port units. > So if only sFlow feature is on stake, it worth to think, to purchase > license, > or to purchase server. Juniper no longer charges for sFlow on the EX2200 (as of Junos 11.2): http://www.juniper.net/techpubs/en_US/junos11.2/information-products/topic-collections/release-notes/11.2/junos-release-notes-11.2.pdf I am not aware of any vendor requiring an additional license to enable sFlow. sFlow (packet sampling) works extremely well for the DDoS flood detection / mitigation use case. The measurements are build into low cost commodity switch hardware and can be enabled operationally without adversely impacting switch performance. A flood attack generates high packet rates and sampling a 10G port at 1-in-10,000 will reliably detect flood attacks within seconds. For most use cases, it is much less expensive to use switches to perform measurement than to attach taps / mirror port probes. If your switches don't already support sFlow, you can buy a 10G capable white box switch for a few thousand dollars that will let you monitor 1.2 Terabits/sec. If you go with an open platform such as Cumulus Linux, you could even run your DDoS mitigation software on the switch and dispense with the external server. Embedded instrumentation is simple to deploy and reduces operational complexity and cost when compared to add on probe solutions. Peter Phaal InMon Corp. From skhosla at neutraldata.com Fri Nov 21 17:02:46 2014 From: skhosla at neutraldata.com (Sameer Khosla) Date: Fri, 21 Nov 2014 17:02:46 +0000 Subject: Incident notification In-Reply-To: References: Message-ID: <49A81EB09F493442B6D259E36251192C01520001C2@ndcc-exch1.neutraldata.com> I know of a firend that is using Growl / Prowl to push out the notifications to their phones, even to their TV's at home. Sk. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Thijs Stuurman Sent: Friday, November 21, 2014 10:52 AM To: nanog at nanog.org Subject: Incident notification Nanog list members, I was looking at some statistic and noticed we are sending out a massive amount of SMS messages from our monitoring systems. This left me wondering if there isn't a better (and cheaper) alternative to this, something just as reliant but IP based. We all have smartphones these days anyway. Therefore my question, what are you using to notify admins of incidents? Kind regards / Met vriendelijke groet, Thijs Stuurman [IS Logo] ________________________________ IS Group Wielingenstraat 8 T +31 (0)299 476 185 info at is.nl 1441 ZR Purmerend F +31 (0)299 476 288 www.is.nl ________________________________ IS Group is ISO 9001:2008, ISO/IEC 27001:2005, ISO 20.000-1:2005, ISAE 3402 certified. De datacenters zijn PCI DSS en ISO 14001 compliant. From denys at visp.net.lb Fri Nov 21 17:06:54 2014 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Fri, 21 Nov 2014 19:06:54 +0200 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <20141121044527.AE78455000085@freedman.net> <3c9ecc2195ee0b41c8d577e15a04a3e5@visp.net.lb> Message-ID: <152f858caf81487786df0e986a573b1c@visp.net.lb> On 2014-11-21 18:41, Peter Phaal wrote: >>> Actually, sFlow from many vendors is pretty good (per your points >>> about >>> flow >>> burstiness and delays), and is good enough for dDoS detection. Not >>> for >>> security forensics, or billing at 99.99% accuracy, but good enough >>> for >>> traffic visibility, peering analytics, and (d)DoS detection. >> >> Well, if it is available, except hardware limitations, there is second >> obstacle, >> software licensing cost. On latest JunOS, for example on EX2200, you >> need >> to purchase license (EFL), and if am not wrong it is $3000 for 48port >> units. >> So if only sFlow feature is on stake, it worth to think, to purchase >> license, >> or to purchase server. > > Juniper no longer charges for sFlow on the EX2200 (as of Junos 11.2): > > http://www.juniper.net/techpubs/en_US/junos11.2/information-products/topic-collections/release-notes/11.2/junos-release-notes-11.2.pdf > > I am not aware of any vendor requiring an additional license to enable > sFlow. > > sFlow (packet sampling) works extremely well for the DDoS flood > detection / mitigation use case. The measurements are build into low > cost commodity switch hardware and can be enabled operationally > without adversely impacting switch performance. A flood attack > generates high packet rates and sampling a 10G port at 1-in-10,000 > will reliably detect flood attacks within seconds. > > For most use cases, it is much less expensive to use switches to > perform measurement than to attach taps / mirror port probes. If your > switches don't already support sFlow, you can buy a 10G capable white > box switch for a few thousand dollars that will let you monitor 1.2 > Terabits/sec. If you go with an open platform such as Cumulus Linux, > you could even run your DDoS mitigation software on the switch and > dispense with the external server. Embedded instrumentation is simple > to deploy and reduces operational complexity and cost when compared to > add on probe solutions. > > Peter Phaal > InMon Corp. Wow, that's great news then, i'm using mostly Cisco gear now, but seems will have to take a look to Juniper, thanks for information. If it is free, then if EX2200 available, it is much easier to run sFlow and write custom collector for it, than installing custom probe(in most common cases). --- Best regards, Denys From amitchell at isipp.com Fri Nov 21 17:17:07 2014 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Fri, 21 Nov 2014 10:17:07 -0700 Subject: Need Godaddy Contac In-Reply-To: References: Message-ID: <76FE9735-593A-4784-B624-9E151802B6B1@isipp.com> Larry, please contact me offlist and we'll ping one of our GD contacts for you. Anne Anne P. Mitchell, Esq. CEO/President ISIPP SuretyMail Email Accreditation & Certification Your mail system + SuretyMail accreditation = delivered to their inbox! http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Author: Section 6 of the Federal CAN-SPAM Act of 2003 Member, California Bar Cyberspace Law Committee Ret. Professor of Law, Lincoln Law School of San Jose https://www.linkedin.com/in/annemitchell 303-731-2121 | amitchell at isipp.com | @AnnePMitchell | Facebook/AnnePMitchell > I have a question that Godaddy support will not answer. > > > > My son moved a word press site to Godaddy from another host. > > > > Apparently, unbeknowest to him, the original wordpress site was also the > email host. > > > > The mail was moved from the old server to the new server but the email was > never properly set up via the GoDaddy Cpanel > > > > Question for a Godaddy Guru. > > > > if we set up the email through the cpanel, will it erase any mail currently > in the accounts on the linux wordpress machine, or even acknowledge that the > exist email is there? > > > > Any help would be GREATLY appreciated and Thanks.. > > From cscora at apnic.net Fri Nov 21 18:11:37 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Nov 2014 04:11:37 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201411211811.sALIBbJS023029@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 22 Nov, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 517859 Prefixes after maximum aggregation: 200304 Deaggregation factor: 2.59 Unique aggregates announced to Internet: 254592 Total ASes present in the Internet Routing Table: 48629 Prefixes per ASN: 10.65 Origin-only ASes present in the Internet Routing Table: 36296 Origin ASes announcing only one prefix: 16305 Transit ASes present in the Internet Routing Table: 6210 Transit-only ASes present in the Internet Routing Table: 176 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 78 Max AS path prepend of ASN ( 55644) 71 Prefixes from unregistered ASNs in the Routing Table: 1631 Unregistered ASNs in the Routing Table: 439 Number of 32-bit ASNs allocated by the RIRs: 7978 Number of 32-bit ASNs visible in the Routing Table: 6123 Prefixes from 32-bit ASNs in the Routing Table: 21952 Number of bogon 32-bit ASNs visible in the Routing Table: 6 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 391 Number of addresses announced to Internet: 2712292420 Equivalent to 161 /8s, 170 /16s and 76 /24s Percentage of available address space announced: 73.3 Percentage of allocated address space announced: 73.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.9 Total number of prefixes smaller than registry allocations: 176514 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 127765 Total APNIC prefixes after maximum aggregation: 37043 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 132174 Unique aggregates announced from the APNIC address blocks: 53894 APNIC Region origin ASes present in the Internet Routing Table: 4990 APNIC Prefixes per ASN: 26.49 APNIC Region origin ASes announcing only one prefix: 1200 APNIC Region transit ASes present in the Internet Routing Table: 869 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 78 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1178 Number of APNIC addresses announced to Internet: 737083776 Equivalent to 43 /8s, 239 /16s and 1 /24s Percentage of available APNIC address space announced: 86.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 171222 Total ARIN prefixes after maximum aggregation: 85507 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 173175 Unique aggregates announced from the ARIN address blocks: 81727 ARIN Region origin ASes present in the Internet Routing Table: 16386 ARIN Prefixes per ASN: 10.57 ARIN Region origin ASes announcing only one prefix: 6073 ARIN Region transit ASes present in the Internet Routing Table: 1702 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 264 Number of ARIN addresses announced to Internet: 1053889472 Equivalent to 62 /8s, 209 /16s and 19 /24s Percentage of available ARIN address space announced: 55.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 126263 Total RIPE prefixes after maximum aggregation: 63842 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 132022 Unique aggregates announced from the RIPE address blocks: 83090 RIPE Region origin ASes present in the Internet Routing Table: 17812 RIPE Prefixes per ASN: 7.41 RIPE Region origin ASes announcing only one prefix: 8177 RIPE Region transit ASes present in the Internet Routing Table: 2936 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3221 Number of RIPE addresses announced to Internet: 691982468 Equivalent to 41 /8s, 62 /16s and 208 /24s Percentage of available RIPE address space announced: 100.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 58181 Total LACNIC prefixes after maximum aggregation: 10865 LACNIC Deaggregation factor: 5.35 Prefixes being announced from the LACNIC address blocks: 66917 Unique aggregates announced from the LACNIC address blocks: 30719 LACNIC Region origin ASes present in the Internet Routing Table: 2378 LACNIC Prefixes per ASN: 28.14 LACNIC Region origin ASes announcing only one prefix: 648 LACNIC Region transit ASes present in the Internet Routing Table: 474 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1391 Number of LACNIC addresses announced to Internet: 167915392 Equivalent to 10 /8s, 2 /16s and 47 /24s Percentage of available LACNIC address space announced: 100.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12364 Total AfriNIC prefixes after maximum aggregation: 3002 AfriNIC Deaggregation factor: 4.12 Prefixes being announced from the AfriNIC address blocks: 13180 Unique aggregates announced from the AfriNIC address blocks: 4810 AfriNIC Region origin ASes present in the Internet Routing Table: 733 AfriNIC Prefixes per ASN: 17.98 AfriNIC Region origin ASes announcing only one prefix: 207 AfriNIC Region transit ASes present in the Internet Routing Table: 148 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 69 Number of AfriNIC addresses announced to Internet: 60038400 Equivalent to 3 /8s, 148 /16s and 29 /24s Percentage of available AfriNIC address space announced: 59.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2959 11585 932 Korea Telecom 17974 2846 904 77 PT Telekomunikasi Indonesia 7545 2460 336 127 TPG Telecom Limited 4755 1929 416 191 TATA Communications formerly 9829 1670 1322 37 National Internet Backbone 4538 1550 4190 71 China Education and Research 9808 1485 6655 16 Guangdong Mobile Communicatio 4808 1425 2213 427 CNCGROUP IP network China169 9583 1363 112 562 Sify Limited 9498 1316 334 94 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2894 3688 51 BellSouth.net Inc. 22773 2850 2956 144 Cox Communications Inc. 18566 2044 379 183 MegaPath Corporation 20115 1822 1797 479 Charter Communications 4323 1642 1053 413 tw telecom holdings, inc. 6983 1625 867 251 EarthLink, Inc. 30036 1496 311 605 Mediacom Communications Corp 701 1427 11265 707 MCI Communications Services, 22561 1311 411 244 CenturyTel Internet Holdings, 11492 1214 212 534 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 34984 1896 298 356 TELLCOM ILETISIM HIZMETLERI A 20940 1504 585 1111 Akamai International B.V. 8402 1380 544 15 OJSC "Vimpelcom" 31148 1045 45 21 Freenet Ltd. 13188 1025 100 35 TOV "Bank-Inform" 8551 899 373 44 Bezeq International-Ltd 6849 834 356 26 JSC "Ukrtelecom" 9198 807 346 32 JSC Kazakhtelecom 6830 804 2339 439 Liberty Global Operations B.V 12479 776 788 97 France Telecom Espana SA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3035 492 242 Telmex Colombia S.A. 28573 2377 2260 110 NET Servi�os de Comunica��o S 7303 1766 1171 241 Telecom Argentina S.A. 8151 1474 3019 429 Uninet S.A. de C.V. 6147 1299 374 30 Telefonica del Peru S.A.A. 6503 1228 433 58 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 914 2325 35 Tim Celular S.A. 3816 906 394 146 COLOMBIA TELECOMUNICACIONES S 27947 887 130 51 Telconet S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1407 958 13 TE-AS 24863 957 280 26 Link Egypt (Link.NET) 36903 388 196 125 Office National des Postes et 36992 359 824 29 ETISALAT MISR 24835 308 144 9 Vodafone Data 37492 289 125 60 Orange Tunisie 3741 249 920 212 Internet Solutions 29571 245 22 17 Cote d'Ivoire Telecom 37054 238 19 6 Data Telecom Service 6713 195 709 34 Office National des Postes et Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3035 492 242 Telmex Colombia S.A. 4766 2959 11585 932 Korea Telecom 6389 2894 3688 51 BellSouth.net Inc. 22773 2850 2956 144 Cox Communications Inc. 17974 2846 904 77 PT Telekomunikasi Indonesia 7545 2460 336 127 TPG Telecom Limited 28573 2377 2260 110 NET Servi�os de Comunica��o S 18566 2044 379 183 MegaPath Corporation 4755 1929 416 191 TATA Communications formerly 34984 1896 298 356 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2894 2843 BellSouth.net Inc. 17974 2846 2769 PT Telekomunikasi Indonesia 22773 2850 2706 Cox Communications Inc. 7545 2460 2333 TPG Telecom Limited 28573 2377 2267 NET Servi�os de Comunica��o S 4766 2959 2027 Korea Telecom 18566 2044 1861 MegaPath Corporation 4755 1929 1738 TATA Communications formerly 9829 1670 1633 National Internet Backbone 34984 1896 1540 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.252.224.0/20 62502 Xnet Media LLC 23.252.224.0/21 62502 Xnet Media LLC 23.252.232.0/21 62502 Xnet Media LLC 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:31 /11:90 /12:262 /13:500 /14:996 /15:1720 /16:13030 /17:7135 /18:11916 /19:24761 /20:35350 /21:37488 /22:55560 /23:48330 /24:277707 /25:1106 /26:1087 /27:705 /28:15 /29:19 /30:11 /31:0 /32:12 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2063 2850 Cox Communications Inc. 18566 1999 2044 MegaPath Corporation 6389 1674 2894 BellSouth.net Inc. 30036 1342 1496 Mediacom Communications Corp 6983 1307 1625 EarthLink, Inc. 34984 1203 1896 TELLCOM ILETISIM HIZMETLERI A 11492 1162 1214 CABLE ONE, INC. 10620 1074 3035 Telmex Colombia S.A. 8402 1045 1380 OJSC "Vimpelcom" 22561 1003 1311 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1358 2:679 3:3 4:16 5:1207 6:22 8:769 12:1848 13:4 14:1195 15:17 16:2 17:42 18:21 20:51 23:970 24:1669 27:1805 31:1386 32:45 33:2 34:5 36:155 37:1838 38:975 39:16 40:225 41:2997 42:274 43:664 44:18 45:80 46:2116 47:30 49:758 50:794 52:12 54:60 55:6 56:6 57:31 58:1155 59:661 60:445 61:1703 62:1311 63:1846 64:4406 65:2280 66:4110 67:2006 68:1049 69:3257 70:885 71:433 72:1983 74:2608 75:323 76:407 77:1622 78:958 79:780 80:1324 81:1277 82:820 83:670 84:670 85:1365 86:425 87:1184 88:500 89:1813 90:140 91:5884 92:804 93:1669 94:1948 95:1311 96:422 97:341 98:1034 99:48 100:66 101:746 103:6117 104:595 105:163 106:189 107:761 108:609 109:1991 110:1057 111:1443 112:736 113:915 114:795 115:1218 116:1233 117:1004 118:1599 119:1367 120:440 121:987 122:2211 123:1701 124:1461 125:1545 128:656 129:390 130:381 131:965 132:429 133:164 134:325 135:82 136:327 137:297 138:388 139:162 140:225 141:422 142:603 143:444 144:511 145:111 146:696 147:563 148:1057 149:397 150:518 151:643 152:482 153:244 154:411 155:631 156:379 157:331 158:279 159:926 160:335 161:621 162:1791 163:373 164:640 165:672 166:299 167:699 168:1132 169:130 170:1425 171:215 172:60 173:1583 174:711 175:582 176:1561 177:3704 178:2112 179:774 180:1818 181:1559 182:1661 183:568 184:706 185:2381 186:2912 187:1672 188:2000 189:1529 190:7667 191:802 192:7802 193:5567 194:4058 195:3612 196:1630 197:833 198:5328 199:5472 200:6496 201:2872 202:9401 203:8996 204:4679 205:2677 206:2994 207:2950 208:3922 209:3801 210:3468 211:1847 212:2467 213:2187 214:855 215:87 216:5632 217:1723 218:649 219:398 220:1301 221:773 222:438 223:662 End of report From digitallystoned at gmail.com Fri Nov 21 18:19:57 2014 From: digitallystoned at gmail.com (N M) Date: Fri, 21 Nov 2014 12:19:57 -0600 Subject: Level3 NOC contact In-Reply-To: References: Message-ID: A NOC engineer has reached out -- Thanks for the quick response *Nathan Mallory* *Network Engineer* Opelika Power Services 600 Fox Run Pkwy Opelika, Al 36801 Office: (334) 705-1601 On Fri, Nov 21, 2014 at 10:29 AM, N M wrote: > Could a NOC engineer from Level3 contact me off list? I am having issues > out of Dallas on a circuit with traffic on your network -- Latency above > 100ms --- My peer claims the issue is fixed but I am still seeing the same > problem -- Thanks > > > *Nathan Mallory* > > *Network Engineer* > Opelika Power Services > 600 Fox Run Pkwy > Opelika, Al 36801 > Office: (334) 705-1601 > From jackson.tim at gmail.com Fri Nov 21 18:32:32 2014 From: jackson.tim at gmail.com (Tim Jackson) Date: Fri, 21 Nov 2014 10:32:32 -0800 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <152f858caf81487786df0e986a573b1c@visp.net.lb> References: <20141121044527.AE78455000085@freedman.net> <3c9ecc2195ee0b41c8d577e15a04a3e5@visp.net.lb> <152f858caf81487786df0e986a573b1c@visp.net.lb> Message-ID: pmacct includes sfacctd which is an sflow collector.. Accessible via the same methods as it's nfacctd collector or pcap based collector.. -- Tim On Fri, Nov 21, 2014 at 9:06 AM, Denys Fedoryshchenko wrote: > On 2014-11-21 18:41, Peter Phaal wrote: >>>> >>>> Actually, sFlow from many vendors is pretty good (per your points about >>>> flow >>>> burstiness and delays), and is good enough for dDoS detection. Not for >>>> security forensics, or billing at 99.99% accuracy, but good enough for >>>> traffic visibility, peering analytics, and (d)DoS detection. >>> >>> >>> Well, if it is available, except hardware limitations, there is second >>> obstacle, >>> software licensing cost. On latest JunOS, for example on EX2200, you need >>> to purchase license (EFL), and if am not wrong it is $3000 for 48port >>> units. >>> So if only sFlow feature is on stake, it worth to think, to purchase >>> license, >>> or to purchase server. >> >> >> Juniper no longer charges for sFlow on the EX2200 (as of Junos 11.2): >> >> >> http://www.juniper.net/techpubs/en_US/junos11.2/information-products/topic-collections/release-notes/11.2/junos-release-notes-11.2.pdf >> >> I am not aware of any vendor requiring an additional license to enable >> sFlow. >> >> sFlow (packet sampling) works extremely well for the DDoS flood >> detection / mitigation use case. The measurements are build into low >> cost commodity switch hardware and can be enabled operationally >> without adversely impacting switch performance. A flood attack >> generates high packet rates and sampling a 10G port at 1-in-10,000 >> will reliably detect flood attacks within seconds. >> >> For most use cases, it is much less expensive to use switches to >> perform measurement than to attach taps / mirror port probes. If your >> switches don't already support sFlow, you can buy a 10G capable white >> box switch for a few thousand dollars that will let you monitor 1.2 >> Terabits/sec. If you go with an open platform such as Cumulus Linux, >> you could even run your DDoS mitigation software on the switch and >> dispense with the external server. Embedded instrumentation is simple >> to deploy and reduces operational complexity and cost when compared to >> add on probe solutions. >> >> Peter Phaal >> InMon Corp. > > Wow, that's great news then, i'm using mostly Cisco gear now, but seems will > have to take a look to Juniper, thanks for information. > If it is free, then if EX2200 available, it is much easier to run sFlow and > write custom collector for it, than installing custom probe(in most common > cases). > > --- > Best regards, > Denys From bill at herrin.us Fri Nov 21 18:56:50 2014 From: bill at herrin.us (William Herrin) Date: Fri, 21 Nov 2014 13:56:50 -0500 Subject: Incident notification In-Reply-To: <56d90aa95fd74351bc94cae17ce1aba5@pur-vm-exch13n2.ox.com> References: <56d90aa95fd74351bc94cae17ce1aba5@pur-vm-exch13n2.ox.com> Message-ID: On Fri, Nov 21, 2014 at 10:56 AM, Matthew Huff wrote: > The advantage of SMS is that it is out of band. Any smtp > or other IP based solution requires a stable and working > network environment, which is what the alert may be > trying to tell you is down. Which is why you locate a small NMS outside your network (on a VM somewhere) whose only job is to start alerting when it can't reach the NMS inside your network. That also helps when your interior NMS system gets gummed up or when a general emergency in your locality damages your infrastructure at the same time as the SMS provider's infrastructure. If your monitoring system is structured well to begin with, email has efficacy comparable to sms. A smartphone app expecting heartbeats via your in-band infrastructure has effectiveness superior to both. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From denys at visp.net.lb Fri Nov 21 19:18:57 2014 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Fri, 21 Nov 2014 21:18:57 +0200 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <20141121044527.AE78455000085@freedman.net> <3c9ecc2195ee0b41c8d577e15a04a3e5@visp.net.lb> <152f858caf81487786df0e986a573b1c@visp.net.lb> Message-ID: Thanks! Most important there is plugin API,so it is easy to write custom code to do some analysis and on events - actions. On 2014-11-21 20:32, Tim Jackson wrote: > pmacct includes sfacctd which is an sflow collector.. Accessible via > the same methods as it's nfacctd collector or pcap based collector.. > > -- > Tim > > On Fri, Nov 21, 2014 at 9:06 AM, Denys Fedoryshchenko > wrote: >> On 2014-11-21 18:41, Peter Phaal wrote: >>>>> >>>>> Actually, sFlow from many vendors is pretty good (per your points >>>>> about >>>>> flow >>>>> burstiness and delays), and is good enough for dDoS detection. Not >>>>> for >>>>> security forensics, or billing at 99.99% accuracy, but good enough >>>>> for >>>>> traffic visibility, peering analytics, and (d)DoS detection. >>>> >>>> >>>> Well, if it is available, except hardware limitations, there is >>>> second >>>> obstacle, >>>> software licensing cost. On latest JunOS, for example on EX2200, you >>>> need >>>> to purchase license (EFL), and if am not wrong it is $3000 for >>>> 48port >>>> units. >>>> So if only sFlow feature is on stake, it worth to think, to purchase >>>> license, >>>> or to purchase server. >>> >>> >>> Juniper no longer charges for sFlow on the EX2200 (as of Junos 11.2): >>> >>> >>> http://www.juniper.net/techpubs/en_US/junos11.2/information-products/topic-collections/release-notes/11.2/junos-release-notes-11.2.pdf >>> >>> I am not aware of any vendor requiring an additional license to >>> enable >>> sFlow. >>> >>> sFlow (packet sampling) works extremely well for the DDoS flood >>> detection / mitigation use case. The measurements are build into low >>> cost commodity switch hardware and can be enabled operationally >>> without adversely impacting switch performance. A flood attack >>> generates high packet rates and sampling a 10G port at 1-in-10,000 >>> will reliably detect flood attacks within seconds. >>> >>> For most use cases, it is much less expensive to use switches to >>> perform measurement than to attach taps / mirror port probes. If your >>> switches don't already support sFlow, you can buy a 10G capable white >>> box switch for a few thousand dollars that will let you monitor 1.2 >>> Terabits/sec. If you go with an open platform such as Cumulus Linux, >>> you could even run your DDoS mitigation software on the switch and >>> dispense with the external server. Embedded instrumentation is simple >>> to deploy and reduces operational complexity and cost when compared >>> to >>> add on probe solutions. >>> >>> Peter Phaal >>> InMon Corp. >> >> Wow, that's great news then, i'm using mostly Cisco gear now, but >> seems will >> have to take a look to Juniper, thanks for information. >> If it is free, then if EX2200 available, it is much easier to run >> sFlow and >> write custom collector for it, than installing custom probe(in most >> common >> cases). >> >> --- >> Best regards, >> Denys --- Best regards, Denys From lists at mtin.net Fri Nov 21 19:42:14 2014 From: lists at mtin.net (Justin Wilson) Date: Fri, 21 Nov 2014 14:42:14 -0500 Subject: Outbound traffic on a circuit? In-Reply-To: <546D46A7.7020105@bogus.com> References: <546D46A7.7020105@bogus.com> Message-ID: But I am buying 1 Gig on a 1 Gig circuit. I could see if it were burstable but it was being billed as 1Gig on a Gig circuit. Justin -- Justin Wilson http://www.mtin.net Managed Services ­ xISP Solutions ­ Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering ­ Transit ­ Internet Exchange On 11/19/14, 8:40 PM, "joel jaeggli" wrote: >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 >> http://www.mtin.net >> Managed Services ­ xISP Solutions ­ Data Centers >> http://www.thebrotherswisp.com >> Podcast about xISP topics >> http://www.midwest-ix.com >> Peering ­ Transit ­ Internet Exchange >> >> >> >> > > From cidr-report at potaroo.net Fri Nov 21 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Nov 2014 22:00:01 GMT Subject: The Cidr Report Message-ID: <201411212200.sALM01e0053239@wattle.apnic.net> This report has been generated at Fri Nov 21 21:14:20 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 14-11-14 529142 292269 15-11-14 529099 292324 16-11-14 528626 292487 17-11-14 529189 292529 18-11-14 525180 291108 19-11-14 524073 291010 20-11-14 523781 290774 21-11-14 524001 290386 AS Summary 48906 Number of ASes in routing system 19638 Number of ASes announcing only one prefix 3041 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120110336 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 21Nov14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 523120 290391 232729 44.5% All ASes AS6389 2894 126 2768 95.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2846 83 2763 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS22773 2853 176 2677 93.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS28573 2372 284 2088 88.0% NET Servi�os de Comunica��o S.A.,BR AS4766 2960 1341 1619 54.7% KIXS-AS-KR Korea Telecom,KR AS7303 1770 290 1480 83.6% Telecom Argentina S.A.,AR AS10620 3041 1574 1467 48.2% Telmex Colombia S.A.,CO AS9808 1485 55 1430 96.3% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS8402 1365 29 1336 97.9% CORBINA-AS OJSC "Vimpelcom",RU AS4755 1928 646 1282 66.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS20115 1823 560 1263 69.3% CHARTER-NET-HKY-NC - Charter Communications,US AS4323 1650 414 1236 74.9% TWTC - tw telecom holdings, inc.,US AS7545 2472 1246 1226 49.6% TPG-INTERNET-AP TPG Telecom Limited,AU AS9498 1316 112 1204 91.5% BBIL-AP BHARTI Airtel Ltd.,IN AS6147 1300 102 1198 92.2% Telefonica del Peru S.A.A.,PE AS18566 2043 868 1175 57.5% MEGAPATH5-US - MegaPath Corporation,US AS6983 1625 484 1141 70.2% ITCDELTA - Earthlink, Inc.,US AS34984 1896 860 1036 54.6% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS7552 1080 53 1027 95.1% VIETEL-AS-AP Viettel Corporation,VN AS22561 1311 334 977 74.5% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS38285 975 130 845 86.7% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS24560 1180 347 833 70.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS31148 1045 234 811 77.6% FREENET-AS Freenet Ltd.,UA AS8151 1481 697 784 52.9% Uninet S.A. de C.V.,MX AS26615 914 133 781 85.4% Tim Celular S.A.,BR AS4780 1047 281 766 73.2% SEEDNET Digital United Inc.,TW AS18101 955 194 761 79.7% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS855 799 57 742 92.9% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS17908 834 97 737 88.4% TCISL Tata Communications,IN Total 50259 11890 38369 76.3% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.224.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.228.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.232.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.236.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.220.84.0/24 AS5577 ROOT root SA,LU 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN 103.10.222.0/24 AS13189 103.14.231.0/24 AS58680 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.228.132.0/22 AS4826 VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.251.244.0/22 AS55536 PSWITCH-HK Pacswitch Colocation & Datacentre,HK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.118.0.0/23 AS37340 Spectranet,NG 154.118.2.0/23 AS37340 Spectranet,NG 154.118.4.0/23 AS37340 Spectranet,NG 154.118.6.0/23 AS37340 Spectranet,NG 154.118.122.0/23 AS37340 Spectranet,NG 154.118.124.0/23 AS37340 Spectranet,NG 154.118.126.0/23 AS37340 Spectranet,NG 160.176.0.0/21 AS36903 MT-MPLS,MA 160.176.8.0/21 AS36903 MT-MPLS,MA 160.176.16.0/21 AS36903 MT-MPLS,MA 160.176.24.0/21 AS36903 MT-MPLS,MA 160.176.32.0/21 AS36903 MT-MPLS,MA 160.176.40.0/21 AS36903 MT-MPLS,MA 160.176.48.0/21 AS36903 MT-MPLS,MA 160.176.56.0/21 AS36903 MT-MPLS,MA 160.176.64.0/21 AS36903 MT-MPLS,MA 160.176.72.0/21 AS36903 MT-MPLS,MA 160.176.80.0/21 AS36903 MT-MPLS,MA 160.176.88.0/21 AS36903 MT-MPLS,MA 160.176.96.0/21 AS36903 MT-MPLS,MA 160.176.104.0/21 AS36903 MT-MPLS,MA 160.176.112.0/21 AS36903 MT-MPLS,MA 160.176.120.0/21 AS36903 MT-MPLS,MA 160.176.128.0/21 AS36903 MT-MPLS,MA 160.176.136.0/21 AS36903 MT-MPLS,MA 160.176.144.0/21 AS36903 MT-MPLS,MA 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 169.255.4.0/24 AS32782 169.255.5.0/24 AS15964 CAMNET-AS,CM 169.255.6.0/24 AS15964 CAMNET-AS,CM 169.255.7.0/24 AS32782 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 185.78.60.0/22 AS19893 CSB-ASN C&S Breitband GmbH,DE 185.78.76.0/22 AS48172 OVERSUN Oversun Ltd,RU 185.78.84.0/24 AS43260 ROUTERGATE DGN TEKNOLOJI BILISIM YAYINCILIK SANAYI VE LIMITED SIRKETI,TR 185.78.85.0/24 AS43260 ROUTERGATE DGN TEKNOLOJI BILISIM YAYINCILIK SANAYI VE LIMITED SIRKETI,TR 185.78.86.0/24 AS43260 ROUTERGATE DGN TEKNOLOJI BILISIM YAYINCILIK SANAYI VE LIMITED SIRKETI,TR 185.78.87.0/24 AS43260 ROUTERGATE DGN TEKNOLOJI BILISIM YAYINCILIK SANAYI VE LIMITED SIRKETI,TR 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.38.0.0/18 AS62228 DMAR-AS Decision Marketing LTD,BG 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.6.0.0/24 AS32768 routability-tests,MU 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.254.0/24 AS32768 routability-tests,MU 196.223.144.0/21 AS37095 AF-21,ZZ 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 210.79.128.0/18 AS62228 DMAR-AS Decision Marketing LTD,BG 210.87.64.0/18 AS62228 DMAR-AS Decision Marketing LTD,BG 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Nov 21 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Nov 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201411212200.sALM02vj053253@wattle.apnic.net> BGP Update Report Interval: 13-Nov-14 -to- 20-Nov-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS12897 1723660 29.3% 246237.1 -- HEAGMEDIANET HSE Medianet GmbH,DE 2 - AS23752 278395 4.7% 2899.9 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS9829 193219 3.3% 153.8 -- BSNL-NIB National Internet Backbone,IN 4 - AS7029 79518 1.4% 36.4 -- WINDSTREAM - Windstream Communications Inc,US 5 - AS53249 73466 1.2% 36733.0 -- LAWA-AS - Los Angeles World Airport,US 6 - AS9587 56535 1.0% 1949.5 -- DTACNETWORK-TH-AP 26th Floor 333/3 Moo 14 Chai Building,TH 7 - AS48159 38843 0.7% 125.3 -- TIC-AS Telecommunication Infrastructure Company,IR 8 - AS28885 36232 0.6% 218.3 -- OMANTEL-NAP-AS OmanTel NAP,OM 9 - AS8402 36115 0.6% 22.9 -- CORBINA-AS OJSC "Vimpelcom",RU 10 - AS38197 35819 0.6% 35.0 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 11 - AS37693 30493 0.5% 272.3 -- TUNISIANA,TN 12 - AS42337 28878 0.5% 178.3 -- RESPINA-AS Respina Networks & Beyond PJSC,IR 13 - AS14420 28436 0.5% 118.5 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP,EC 14 - AS3816 26128 0.4% 51.8 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 15 - AS3 23691 0.4% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 16 - AS23342 21980 0.4% 21980.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 17 - AS10620 21295 0.4% 10.7 -- Telmex Colombia S.A.,CO 18 - AS60725 20028 0.3% 4005.6 -- O3B-AS O3b Limited,JE 19 - AS25003 20025 0.3% 667.5 -- INTERNET_BINAT Internet Binat Ltd,IL 20 - AS45899 19807 0.3% 45.6 -- VNPT-AS-VN VNPT Corp,VN TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS12897 1723660 29.3% 246237.1 -- HEAGMEDIANET HSE Medianet GmbH,DE 2 - AS53249 73466 1.2% 36733.0 -- LAWA-AS - Los Angeles World Airport,US 3 - AS23342 21980 0.4% 21980.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 4 - AS3 23691 0.4% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 5 - AS18135 10850 0.2% 10850.0 -- BTV BTV Cable television,JP 6 - AS62174 4107 0.1% 4107.0 -- INTERPAN-AS INTERPAN LTD.,BG 7 - AS60725 20028 0.3% 4005.6 -- O3B-AS O3b Limited,JE 8 - AS23752 278395 4.7% 2899.9 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 9 - AS10674 2629 0.0% 2629.0 -- GRUCOM - Gainesville Regional Utilities,US 10 - AS56636 2230 0.0% 2230.0 -- ASVEDARU VEDA Ltd.,RU 11 - AS4 2067 0.0% 1465.0 -- ISI-AS - University of Southern California,US 12 - AS12521 3930 0.1% 1965.0 -- NOVA_INTERNET_AS12521 Nova Internet Network,ES 13 - AS9587 56535 1.0% 1949.5 -- DTACNETWORK-TH-AP 26th Floor 333/3 Moo 14 Chai Building,TH 14 - AS35093 3604 0.1% 1802.0 -- RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 15 - AS38808 1721 0.0% 1721.0 -- IMZAK-TRANSIT-AS-AP DSL Service Provider Servers,PK 16 - AS30944 1657 0.0% 1657.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD",LT 17 - AS3328 15997 0.3% 1599.7 -- -Reserved AS-,ZZ 18 - AS11728 1424 0.0% 1424.0 -- INTERNETXT - Internet Exchange Technology, Inc.,US 19 - AS56133 8072 0.1% 1345.3 -- TASMANET-AS-AP Tasmanet Pty Ltd,AU 20 - AS61708 1257 0.0% 1257.0 -- INFOCAT INFORM�TICA LTDA,BR TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 94.16.64.0/21 247495 4.0% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 2 - 94.16.80.0/20 247386 4.0% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 3 - 94.16.72.0/21 247305 4.0% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 4 - 185.9.28.0/22 246034 4.0% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 5 - 194.127.204.0/23 245774 4.0% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 6 - 194.99.108.0/23 245433 4.0% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 7 - 194.45.104.0/23 244233 4.0% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 8 - 202.70.64.0/21 142246 2.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 9 - 202.70.88.0/21 135152 2.2% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 10 - 198.140.114.0/24 36755 0.6% AS53249 -- LAWA-AS - Los Angeles World Airport,US 11 - 198.140.115.0/24 36711 0.6% AS53249 -- LAWA-AS - Los Angeles World Airport,US 12 - 130.0.192.0/21 23689 0.4% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 13 - 64.29.130.0/24 21980 0.4% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 14 - 192.115.44.0/22 19956 0.3% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 15 - 111.84.20.0/24 14443 0.2% AS10089 -- DTNCORP-TH-AP Total Access Communication PLC.,TH AS9587 -- DTACNETWORK-TH-AP 26th Floor 333/3 Moo 14 Chai Building,TH 16 - 111.84.22.0/24 14140 0.2% AS10089 -- DTNCORP-TH-AP Total Access Communication PLC.,TH AS9587 -- DTACNETWORK-TH-AP 26th Floor 333/3 Moo 14 Chai Building,TH 17 - 111.84.24.0/24 14065 0.2% AS10089 -- DTNCORP-TH-AP Total Access Communication PLC.,TH AS9587 -- DTACNETWORK-TH-AP 26th Floor 333/3 Moo 14 Chai Building,TH 18 - 162.249.183.0/24 11018 0.2% AS60725 -- O3B-AS O3b Limited,JE 19 - 42.83.48.0/20 10850 0.2% AS18135 -- BTV BTV Cable television,JP 20 - 192.58.232.0/24 10619 0.2% AS6629 -- NOAA-AS - NOAA,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From mysidia at gmail.com Sat Nov 22 00:58:14 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 21 Nov 2014 18:58:14 -0600 Subject: abuse reporting tools In-Reply-To: <546BF549.4010605@direcpath.com> References: <546BEB30.9040207@tiedyenetworks.com> <20141119011113.6647956.37754.16688@supermathie.net> <546BF549.4010605@direcpath.com> Message-ID: On Tue, Nov 18, 2014 at 7:41 PM, Robert Drake wrote: > On 11/18/2014 8:11 PM, Michael Brown wrote: [snip] > amelioration. So I'm left with a very unsatisfactory feeling of either > shutting down a possibly innocent customer based on a machines word, or > attempting to start a dialog with random_script_user_99 at hotmail.com. Under those circumstances, how do you know it's not a social-engineering based DoS being attempted? Preferably, take no action to shutdown services without decent confirmation; as malicious reports of a fraudulent, bogus, dramatized, or otherwise misleading nature are sometimes used by malicious actors to target a legitimate user. My suggestion would be table the report of a single SSH connection and really do nothing with it. If there is actually abuse being conducted, you should either be able to independently verify the actual abuse, e.g. by checking packet level data or netflow data, or you should begin to receive a pattern of complaints; more unique contacts, that you can investigate and verify are legit. contacts from unique networks. If neither occurs, then just keep a log as an unconfirmed abuse report, which if unconfirmed for a few days may be forwarded to the end user for their information/records. -- -JH > Robert From freedman at freedman.net Sat Nov 22 15:49:32 2014 From: freedman at freedman.net (Avi Freedman) Date: Sat, 22 Nov 2014 10:49:32 -0500 (EST) Subject: DDOS, IDS, RTBH, and Rate limiting Message-ID: <20141122154932.E3DC055000087@freedman.net> > > On the contrary - SPAN nee port mirroring cuts into the > > frames-per-second budget of linecards, as the traffic is in essence > > being duplicated. It is not 'free', and it has a profound impact on > > the the switch's data-plane traffic forwarding capacity. > > > > Unlike NetFlow. > > In hosting case mirroring usually done for uplink port, but i have to > agree, it might be a problem. Have you seen any issues with SPANning? We usually advise something like a $1k netoptis tap or to be cheaper there are actually $50 fiber cables with 30/70 taps embedded (so two such, one for RX tap and one for TX tap). Of course, that only grabs a single 10gig whereas with SPAN you can potentially do more - but the issues we've seen across vendors is that if you try to send more traffic into a SPAN port than its size, bad things can happen. Head of line blocking, random congestion, and other strange failures. And you trade off potential catastrophic downtime for SPAN-related network destabilization, for guaranteed downtime to bring links down to tap them. > "Major" expenses - tuning server according author recommendations, and > writing shell script that will send to 4948 command to blackhope IP. For > qualified sysadmin it is 2 hours of work, and $500 max as a "labor" > cost. Thats it. What can be cheaper than $2000 in this case? I guess i > wont get answer. I think the issue is not with your providing the info about fastnetmon, its genesis, and what you see as the great use cases for it - more around the statements on flow as an unusable source of data for various purposes. Things seem to have died down around that though, which is good :) > --- > Best regards, > Denys Avi Freedman | Your flow has something to show you; can you see it? | CEO, CloudHelix | (avi at cloudhelix dot com) | my name one word on skype | From freedman at freedman.net Sat Nov 22 16:00:52 2014 From: freedman at freedman.net (Avi Freedman) Date: Sat, 22 Nov 2014 11:00:52 -0500 (EST) Subject: DDOS, IDS, RTBH, and Rate limiting Message-ID: <20141122160052.4EB8855000087@freedman.net> > > Cisco ASRs and MXs with inline jflow can do hundreds of K flows/second > > without affecting packet forwarding. > > Yes, i agree,those are good for netflow, but when they already exist in > network. > > Does it worth to buy ASR, if L3 switch already doing the job > (BGP/ACL/rate-limit/routing)? Not suggesting that anyone should change out their gear though per my other message, I've seen SPAN make things go wonky on almost every vendor that ISPs use for switching. > Well, if it is available, except hardware limitations, there is second > obstacle, software licensing cost. On latest JunOS, for example on EX2200, > you need to purchase license (EFL), and if am not wrong it is $3000 for > 48port units. > > So if only sFlow feature is on stake, it worth to think, to purchase license, > or to purchase server. Prices for JFlow license on MX, just for 5/10G is way > above cost of very decent server. I believe that smaller MXs can run it for free. Larger providers we've worked with often have magic cookies they can call in to get it enabled, but I understand you're talking about the smaller-provider (or at least ~ 10gig per POP across multiple POPs) case. We see a lot of Brocade for switching in hosting providers, which makes sFlow easy, of course. > > And with the right setup you can run FastNetMon or other tools in > > addition to generating flow that can be of use for other purposes > > as well... > > Technically there is ipt_NETFLOW, that can generate netflow on same box, > for statistical/telemetry purposes. But i am not sure it is possible to > run them together. At frac 10gig you can just open pcap on a 10gig interface on a Linux box getting a tap, of course. What we did was use myricom cards and the myri_snf drivers and take from the single-consumer ring buffers into large in-RAM ring buffers, and make those ring buffers available via LD_PRELOAD or cli tools to allow flow, snort, p0f, tcpdump, etc to all be run at the same time at 10gig. The key for that is not going through the kernel IP stack, though. > > But taps can be difficult or at least time consuming for people to > > put in at scale. Even, we've seen, for folks with 10G networks. > > Often because they can get 90% of what they need for 4 different > > business purposes from just flow :) > > About scaling, i guess it depends on proper deployment strategy and > sysadmins/developers capabilities. For example to deploy new ruleset > for my pcap-based "homemade" analyser to 150 probes across the country - > is just one click. Sounds cool. You should write up that use case. Hopefully you've secured the metadata/command push channel well enough :) > Best regards, > Denys Avi Freedman | Your flow has something to show you; can you see it? | CEO, CloudHelix | (avi at cloudhelix dot com) | my name one word on skype | From denys at visp.net.lb Sat Nov 22 16:18:02 2014 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Sat, 22 Nov 2014 18:18:02 +0200 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: <20141122160052.4EB8855000087@freedman.net> References: <20141122160052.4EB8855000087@freedman.net> Message-ID: On 2014-11-22 18:00, freedman at freedman.net wrote: >> > Cisco ASRs and MXs with inline jflow can do hundreds of K flows/second >> > without affecting packet forwarding. >> >> Yes, i agree,those are good for netflow, but when they already exist >> in >> network. >> >> Does it worth to buy ASR, if L3 switch already doing the job >> (BGP/ACL/rate-limit/routing)? > > Not suggesting that anyone should change out their gear though per my > other > message, I've seen SPAN make things go wonky on almost every vendor > that > ISPs use for switching. Well, i always try to stay on safe side. Additionally, sure, i do mirror for RX only, RX+TX often can exceed interface rate too :) > >> Well, if it is available, except hardware limitations, there is second >> obstacle, software licensing cost. On latest JunOS, for example on >> EX2200, >> you need to purchase license (EFL), and if am not wrong it is $3000 >> for >> 48port units. >> >> So if only sFlow feature is on stake, it worth to think, to purchase >> license, >> or to purchase server. Prices for JFlow license on MX, just for 5/10G >> is way >> above cost of very decent server. > > I believe that smaller MXs can run it for free. Larger providers we've > worked with often have magic cookies they can call in to get it > enabled, > but I understand you're talking about the smaller-provider (or at least > ~ > 10gig per POP across multiple POPs) case. > > We see a lot of Brocade for switching in hosting providers, which makes > sFlow easy, of course. Oh, Brocade, recent experience with ServerIron taught me new lesson, that i can't do bonding on ports as i want, it has limitations about even/odd port numbers and etc. Most amazing part i just forgot, that i have this ServerIron, and it is a place where i run DDoS protection (but it works perfectly over "tap" way). Thanks for reminding about this vendor :) > >> > And with the right setup you can run FastNetMon or other tools in >> > addition to generating flow that can be of use for other purposes >> > as well... >> >> Technically there is ipt_NETFLOW, that can generate netflow on same >> box, >> for statistical/telemetry purposes. But i am not sure it is possible >> to >> run them together. > > At frac 10gig you can just open pcap on a 10gig interface on a Linux > box getting a tap, of course. > > What we did was use myricom cards and the myri_snf drivers and take > from > the single-consumer ring buffers into large in-RAM ring buffers, and > make those ring buffers available via LD_PRELOAD or cli tools to allow > flow, snort, p0f, tcpdump, etc to all be run at the same time at 10gig. > > The key for that is not going through the kernel IP stack, though. Ntop's pf_ring, which is basically same idea, but can run on Intel cards. Just maybe because never had myricom in hands, and it is difficult to obtain them here. > >> > But taps can be difficult or at least time consuming for people to >> > put in at scale. Even, we've seen, for folks with 10G networks. >> > Often because they can get 90% of what they need for 4 different >> > business purposes from just flow :) >> >> About scaling, i guess it depends on proper deployment strategy and >> sysadmins/developers capabilities. For example to deploy new ruleset >> for my pcap-based "homemade" analyser to 150 probes across the country >> - >> is just one click. > > Sounds cool. You should write up that use case. Hopefully you've > secured > the metadata/command push channel well enough :) For servers it is ssh with key authentication, and push system doesn't contain private key, it is forwarded over ssh agent from developer pc. Sure, it is better also to sign by assymmetric crypto update also, keep keys on smartcard, but in this case it is not necessary. --- Best regards, Denys From brak at gameservers.com Sat Nov 22 23:53:09 2014 From: brak at gameservers.com (Brian Rak) Date: Sat, 22 Nov 2014 18:53:09 -0500 Subject: DDOS, IDS, RTBH, and Rate limiting In-Reply-To: References: <20141122160052.4EB8855000087@freedman.net> Message-ID: <547121E5.4050401@gameservers.com> On 11/22/2014 11:18 AM, Denys Fedoryshchenko wrote: > On 2014-11-22 18:00, freedman at freedman.net wrote: >> We see a lot of Brocade for switching in hosting providers, which makes >> sFlow easy, of course. > Oh, Brocade, recent experience with ServerIron taught me new lesson, > that i can't > do bonding on ports as i want, it has limitations about even/odd port > numbers and > etc. > Most amazing part i just forgot, that i have this ServerIron, and it > is a place where > i run DDoS protection (but it works perfectly over "tap" way). Thanks > for reminding > about this vendor :) I just hope you're not talking FCX's.... if you upgrade those to 8.x firmware, you'll lose sflow on the 10gb ports. Once you upgrade, they send a corrupted sflow packet, and at *far* less then the rate that you configure. Even if you adjust your parser to compensate for the corrupt packet, they're still dropping the large majority of samples, making sflow pretty much useless. It's been several months since we reported this, and we're still waiting on a fix. From joelja at bogus.com Sun Nov 23 03:26:16 2014 From: joelja at bogus.com (joel jaeggli) Date: Sat, 22 Nov 2014 19:26:16 -0800 Subject: Outbound traffic on a circuit? In-Reply-To: References: <546D46A7.7020105@bogus.com> Message-ID: <547153D8.7060805@bogus.com> On 11/21/14 11:42 AM, Justin Wilson wrote: > But I am buying 1 Gig on a 1 Gig circuit. I could see if it were > burstable but it was being billed as 1Gig on a Gig circuit. If you're buying 1Gig commit then you're buying 1gig commit. That's not the contract you described. > Justin > > > -- > Justin Wilson > http://www.mtin.net > Managed Services ­ xISP Solutions ­ Data Centers > http://www.thebrotherswisp.com > Podcast about xISP topics > http://www.midwest-ix.com > Peering ­ Transit ­ Internet Exchange > > > > > > > On 11/19/14, 8:40 PM, "joel jaeggli" wrote: > >> 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 >>> http://www.mtin.net >>> Managed Services ­ xISP Solutions ­ Data Centers >>> http://www.thebrotherswisp.com >>> Podcast about xISP topics >>> http://www.midwest-ix.com >>> Peering ­ Transit ­ Internet Exchange >>> >>> >>> >>> >> >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From joelja at bogus.com Sun Nov 23 19:20:52 2014 From: joelja at bogus.com (joel jaeggli) Date: Sun, 23 Nov 2014 11:20:52 -0800 Subject: Multi-homing with multiple ASNs In-Reply-To: <201411211107.50085.mark.tinka@seacom.mu> References: <848A0CCBF45ABC49B103A3733FA46C506427FB@MTEXMBC01.fsa.mtsu.edu> <201411211107.50085.mark.tinka@seacom.mu> Message-ID: <54723394.5000009@bogus.com> On 11/21/14 1:07 AM, Mark Tinka wrote: > On Friday, November 21, 2014 12:00:47 AM Curtis L. Parish > wrote: > >> We have recently added a second ISP (third if you count >> I2). Our first "ISP" is actually a private state >> network that peers with two Tier 1 providers. We own an >> AS number and our IP space but at the last minute >> learned our state network is advertising our network >> using two different ASNs (neither ours) so they can load >> balance their connections. If you hit the right >> looking glass server you can see our network advertised >> by three different ASNs. We were told by the new ISP >> that this is a problem but the state network says it is >> not. >> >> Looking for opinions and words of wisdom on this split >> advertising issue. > > Why aren't you originating your own prefixes and ASN by > yourselves, since you own both? The practical problem here is that the control of prefix origination is distributed. so if there is a need to withdraw it from the state network or advertise it no export for some reason (e.g. performance problem maintenance etc) you likely can't. Their grasp of load-balancing seems a bit shallow also. > Mark. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From matthew at corp.crocker.com Sun Nov 23 22:55:16 2014 From: matthew at corp.crocker.com (Matthew Crocker) Date: Sun, 23 Nov 2014 17:55:16 -0500 Subject: Help, need Verizon fiber outage phone number Message-ID: Does anyone have a phone number for Verizon-NE (Massachusetts)? I have a fiber outage between two Verizon COs and their stupid VTAG system is worthless. I can’t get a trouble ticket entered to save my life. All of the numbers I have either go nowhere or get stuck in music on hold hell then disconnect. Thanks -Matt -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matthew at crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com From bill at herrin.us Sun Nov 23 23:57:15 2014 From: bill at herrin.us (William Herrin) Date: Sun, 23 Nov 2014 18:57:15 -0500 Subject: Multi-homing with multiple ASNs In-Reply-To: <848A0CCBF45ABC49B103A3733FA46C5064467F@MTEXMBC01.fsa.mtsu.edu> References: <848A0CCBF45ABC49B103A3733FA46C506427FB@MTEXMBC01.fsa.mtsu.edu> <848A0CCBF45ABC49B103A3733FA46C5064467F@MTEXMBC01.fsa.mtsu.edu> Message-ID: On Fri, Nov 21, 2014 at 9:49 AM, Curtis L. Parish wrote: > We advertise our ASN into the state network with more specific routes > that we advertise via ISP2 via our ASN. This is done because the > state (vendor managed) network runs stateful firewalls and we have > to force other multi-home entities on the state network to use our > state connection instead of ISP2. Our network has been removed > from the state firewall due to previous problems with asymmetric > routing with our I2 circuit. Hi Curtis, As you've already noted, the presence of a stateful firewall beyond your BGP border is inimical to BGP multihoming. Traffic between two multihomed networks must never cross a stateful firewall that is outside both networks' borders. Practically speaking, there will asymmetry, path flapping, per-packet load balancing and other quirks at locations outside your control. The Internet DFZ is a chaotic system. Over time you won't be able to make the packets reliably transit the firewall. It sounds like this is a learning experience for both you and the folks at the state network. If you have a friendly relationship with them, now would be a good time to visit and talk about what are likely to be significant changes to their network architecture to make multihomed users feasible. Preferably with a the help of a local consultant who has BGP expertise. If that doesn't sound like it would be a productive conversation then I suggest you consider three different options: 1. Return to the state network alone, 2. Replace your state network connection with another commercial ISP, 3. Add an additional commercial ISP for the sake of your Internet access needs, drop the BGP advertisements with the state network and then implement resources which should only transit the state network using IP addresses assigned by the state network rather than your BGP addresses. > Here is a question. I know that having one network advertised by multiple ASNs > is unconventional and thus it will probably be harder to get help troubleshooting > routing problems when they arise. Do you see a situation where our network > might be caught in a loop or black hole due to asymmetric routing and conflicting advertisements? Yes. And frequently. You have this thing balanced on the head of a pin. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From mysidia at gmail.com Mon Nov 24 00:49:29 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 23 Nov 2014 18:49:29 -0600 Subject: Multi-homing with multiple ASNs In-Reply-To: <848A0CCBF45ABC49B103A3733FA46C5064467F@MTEXMBC01.fsa.mtsu.edu> References: <848A0CCBF45ABC49B103A3733FA46C506427FB@MTEXMBC01.fsa.mtsu.edu> <848A0CCBF45ABC49B103A3733FA46C5064467F@MTEXMBC01.fsa.mtsu.edu> Message-ID: On Fri, Nov 21, 2014 at 8:49 AM, Curtis L. Parish wrote: > I believe the state will modify their advertisements to add our ASN to the path > but changes to advertising via the state network has to go through a design > and change management process and then be scheduled into maintenance > windows. Any attempts to balance the traffic via prepending will take weeks. [snip] In other words, you are in effect not in control of the advertisement of your prefix, therefore you practically don't actually have an autonomous system, you have the number technically, but not the administrative division that is intended to exist. An appropriate amount of time to push out any change needed to an announcement should be no more than 1 business day, but less than 2 hours in an emergency, to add extra impending or pull an announcement. I would call a change management process that requires any longer unacceptable, or not reflecting the reality of the importance of well-maintained optimal properly functioning network connectivity. You have what seems to be something very fragile, and you have very low configuration agility, since you cannot change your announcements as needed out through the state as you need them to. A stateful firewall, has no correct place outside the border of a multihomed network; by definition, to have a stateful firewall, there must be a single point of failure (on the stateful firewall element) at least for each unique load-balancing tuple. So I would call (in this case), the origination of your prefix by multiple ASes a bad thing. The protocol allows this, but the other constraints related to the situation are serious impediments that make the solidity multihoming seem improper or potentially precarious, in terms of the true originating AS' ability to function as an AS and manage their network -- -JH From marine64 at gmail.com Mon Nov 24 03:41:21 2014 From: marine64 at gmail.com (Brian Henson) Date: Sun, 23 Nov 2014 22:41:21 -0500 Subject: Craigslist hacked? Message-ID: Is anyone else seeing their local craigslist redirected to another site other than craigslist? I see it loading http://digitalgangster.com/5um. From auser at mind.net Mon Nov 24 03:43:46 2014 From: auser at mind.net (aUser) Date: Sun, 23 Nov 2014 19:43:46 -0800 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: I can't reach my local one or the Fresno one. Server unreachable. Sent from my iPhone 5S. > On Nov 23, 2014, at 7:41 PM, Brian Henson wrote: > > Is anyone else seeing their local craigslist redirected to another site > other than craigslist? I see it loading http://digitalgangster.com/5um. From contact at nullivex.com Mon Nov 24 03:45:21 2014 From: contact at nullivex.com (Bryan Tong) Date: Sun, 23 Nov 2014 20:45:21 -0700 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: Not here, spyware maybe? On Sun, Nov 23, 2014 at 8:41 PM, Brian Henson wrote: > Is anyone else seeing their local craigslist redirected to another site > other than craigslist? I see it loading http://digitalgangster.com/5um. > -- eSited LLC (701) 390-9638 From chaim.rieger at gmail.com Mon Nov 24 03:45:35 2014 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Sun, 23 Nov 2014 19:45:35 -0800 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: Comes up normal for me in LA, on twc. On Nov 23, 2014 7:43 PM, "Brian Henson" wrote: > Is anyone else seeing their local craigslist redirected to another site > other than craigslist? I see it loading http://digitalgangster.com/5um. > From w3yni1 at gmail.com Mon Nov 24 03:45:57 2014 From: w3yni1 at gmail.com (Charles Mills) Date: Sun, 23 Nov 2014 22:45:57 -0500 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: Not seeing that here The local site and the general http;// www.craigslist.org both look to be going to the correct site. On Sun, Nov 23, 2014 at 10:41 PM, Brian Henson wrote: > Is anyone else seeing their local craigslist redirected to another site > other than craigslist? I see it loading http://digitalgangster.com/5um. > From marine64 at gmail.com Mon Nov 24 03:47:58 2014 From: marine64 at gmail.com (Brian Henson) Date: Sun, 23 Nov 2014 22:47:58 -0500 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: strange when I go to Boise.craigslist or dayton.craigslist.org I get a site that shows digital Gangster for life as the title. so do some of the other tools outside my network. On Sun, Nov 23, 2014 at 10:45 PM, Charles Mills wrote: > Not seeing that here The local site and the general http;// > www.craigslist.org both look to be going to the correct site. > > On Sun, Nov 23, 2014 at 10:41 PM, Brian Henson wrote: > >> Is anyone else seeing their local craigslist redirected to another site >> other than craigslist? I see it loading http://digitalgangster.com/5um. >> > > From brian at artschwager.com Mon Nov 24 03:48:03 2014 From: brian at artschwager.com (Brian Artschwager) Date: Sun, 23 Nov 2014 22:48:03 -0500 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: Same here, New Jersey. On Sun, Nov 23, 2014 at 10:43 PM, aUser wrote: > I can't reach my local one or the Fresno one. Server unreachable. > > Sent from my iPhone 5S. > > > On Nov 23, 2014, at 7:41 PM, Brian Henson wrote: > > > > Is anyone else seeing their local craigslist redirected to another site > > other than craigslist? I see it loading http://digitalgangster.com/5um. > -- -- Brian From jason at rice.edu Mon Nov 24 00:11:20 2014 From: jason at rice.edu (Jason Bothe) Date: Sun, 23 Nov 2014 18:11:20 -0600 Subject: Multi-homing with multiple ASNs In-Reply-To: References: <848A0CCBF45ABC49B103A3733FA46C506427FB@MTEXMBC01.fsa.mtsu.edu> <848A0CCBF45ABC49B103A3733FA46C5064467F@MTEXMBC01.fsa.mtsu.edu> Message-ID: <5E180A99-E2D0-44CD-A06A-47A41E51AB5D@rice.edu> Agreed. You could still recieve their routes and no/export your as but I wouldn't go beyond the firewall. Jason Bothe, Manager of Networking Rice University o +1 713 348 5500 m +1 713 703 3552 jason at rice.edu > On Nov 23, 2014, at 17:57, William Herrin wrote: > > On Fri, Nov 21, 2014 at 9:49 AM, Curtis L. Parish > wrote: >> We advertise our ASN into the state network with more specific routes >> that we advertise via ISP2 via our ASN. This is done because the >> state (vendor managed) network runs stateful firewalls and we have >> to force other multi-home entities on the state network to use our >> state connection instead of ISP2. Our network has been removed >> from the state firewall due to previous problems with asymmetric >> routing with our I2 circuit. > > Hi Curtis, > > As you've already noted, the presence of a stateful firewall beyond your > BGP border is inimical to BGP multihoming. Traffic between two multihomed > networks must never cross a stateful firewall that is outside both > networks' borders. Practically speaking, there will asymmetry, path > flapping, per-packet load balancing and other quirks at locations outside > your control. The Internet DFZ is a chaotic system. Over time you won't be > able to make the packets reliably transit the firewall. > > It sounds like this is a learning experience for both you and the folks at > the state network. If you have a friendly relationship with them, now would > be a good time to visit and talk about what are likely to be significant > changes to their network architecture to make multihomed users feasible. > Preferably with a the help of a local consultant who has BGP expertise. > > If that doesn't sound like it would be a productive conversation then I > suggest you consider three different options: > > 1. Return to the state network alone, > > 2. Replace your state network connection with another commercial ISP, > > 3. Add an additional commercial ISP for the sake of your Internet access > needs, drop the BGP advertisements with the state network and then > implement resources which should only transit the state network using IP > addresses assigned by the state network rather than your BGP addresses. > > > >> Here is a question. I know that having one network advertised by > multiple ASNs >> is unconventional and thus it will probably be harder to get help > troubleshooting >> routing problems when they arise. Do you see a situation where our > network >> might be caught in a loop or black hole due to asymmetric routing and > conflicting advertisements? > > Yes. And frequently. You have this thing balanced on the head of a pin. > > Regards, > Bill Herrin > > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > May I solve your unusual networking challenges? > From marine64 at gmail.com Mon Nov 24 03:50:52 2014 From: marine64 at gmail.com (Brian Henson) Date: Sun, 23 Nov 2014 22:50:52 -0500 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: Maybe an area based issue. tons of reports here http://www.isitdownrightnow.com/craigslist.org.html On Sun, Nov 23, 2014 at 10:48 PM, Brian Artschwager wrote: > Same here, New Jersey. > > On Sun, Nov 23, 2014 at 10:43 PM, aUser wrote: > >> I can't reach my local one or the Fresno one. Server unreachable. >> >> Sent from my iPhone 5S. >> >> > On Nov 23, 2014, at 7:41 PM, Brian Henson wrote: >> > >> > Is anyone else seeing their local craigslist redirected to another site >> > other than craigslist? I see it loading http://digitalgangster.com/5um. >> > > > > -- > > -- > Brian > From math at sizone.org Mon Nov 24 03:53:21 2014 From: math at sizone.org (Ken Chase) Date: Sun, 23 Nov 2014 22:53:21 -0500 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: <20141124035321.GS4848@sizone.org> down for me and http://www.downforeveryoneorjustme.com/craigslist.org /kc On Sun, Nov 23, 2014 at 07:45:35PM -0800, Chaim Rieger said: >Comes up normal for me in LA, on twc. >On Nov 23, 2014 7:43 PM, "Brian Henson" wrote: > >> Is anyone else seeing their local craigslist redirected to another site >> other than craigslist? I see it loading http://digitalgangster.com/5um. >> -- Ken Chase - math at sizone.org Toronto Canada From lyndon at orthanc.ca Mon Nov 24 03:54:05 2014 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 23 Nov 2014 19:54:05 -0800 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: On Nov 23, 2014, at 7:41 PM, Brian Henson wrote: > Is anyone else seeing their local craigslist redirected to another site > other than craigslist? I see it loading http://digitalgangster.com/5um. *.craigslist.ca and *.craigslist.org have been offline since about 16:40 Pacific Standard Time from at least three different networks I have access to. From the limited poking around I've done it looks like it could be a DNS hijacking. I haven't seen anything about it on the outages list yet ... --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mfidelman at meetinghouse.net Mon Nov 24 03:54:44 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 23 Nov 2014 22:54:44 -0500 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: <5472AC04.4000009@meetinghouse.net> Boston is just fine, and all the links from there, to other craigslist sites seem to be working as well. Chaim Rieger wrote: > Comes up normal for me in LA, on twc. > On Nov 23, 2014 7:43 PM, "Brian Henson" wrote: > >> Is anyone else seeing their local craigslist redirected to another site >> other than craigslist? I see it loading http://digitalgangster.com/5um. >> -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From lostinmoscow at gmail.com Mon Nov 24 03:57:15 2014 From: lostinmoscow at gmail.com (Quinn Kuzmich) Date: Sun, 23 Nov 2014 20:57:15 -0700 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: CoSprings list is coming up fine. On Sun, Nov 23, 2014 at 8:41 PM, Brian Henson wrote: > Is anyone else seeing their local craigslist redirected to another site > other than craigslist? I see it loading http://digitalgangster.com/5um. > From marine64 at gmail.com Mon Nov 24 03:59:35 2014 From: marine64 at gmail.com (Brian Henson) Date: Sun, 23 Nov 2014 22:59:35 -0500 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: Im seeing it resolve to 74.63.219.135 on my network and on http://whois.domaintools.com/craigslist.org On Sun, Nov 23, 2014 at 10:57 PM, Quinn Kuzmich wrote: > CoSprings list is coming up fine. > > On Sun, Nov 23, 2014 at 8:41 PM, Brian Henson wrote: > >> Is anyone else seeing their local craigslist redirected to another site >> other than craigslist? I see it loading http://digitalgangster.com/5um. >> > > From mehmet at akcin.net Mon Nov 24 04:06:17 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 23 Nov 2014 20:06:17 -0800 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: yes it's been hijacked thru registrar level and someone was able to change name servers, now it's back to normal but you will need to clear your caches and perhaps your ISP too. (if you are using 8.8.8.8 , they have already cleared the caches) Sponsoring Registrar:Network Solutions, LLC (R63-LROR) seems to be registrar, would be fun to read the post-mortem. On Sun, Nov 23, 2014 at 7:48 PM, Brian Artschwager wrote: > Same here, New Jersey. > > On Sun, Nov 23, 2014 at 10:43 PM, aUser wrote: > > > I can't reach my local one or the Fresno one. Server unreachable. > > > > Sent from my iPhone 5S. > > > > > On Nov 23, 2014, at 7:41 PM, Brian Henson wrote: > > > > > > Is anyone else seeing their local craigslist redirected to another site > > > other than craigslist? I see it loading http://digitalgangster.com/5um > . > > > > > > -- > > -- > Brian > From ml-nanog090304q at elcsplace.com Mon Nov 24 04:08:51 2014 From: ml-nanog090304q at elcsplace.com (Ted Cooper) Date: Mon, 24 Nov 2014 14:08:51 +1000 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: <5472AF53.50208@elcsplace.com> On 24/11/14 13:41, Brian Henson wrote: > Is anyone else seeing their local craigslist redirected to another site > other than craigslist? I see it loading http://digitalgangster.com/5um. > Over on [dns-operations]: > On 24/11/14 13:38, Brad Volz wrote:> >> The craigslist account at one of our registrars was compromised and the >> NS records migrated away from their rightful home. That issue has since >> been corrected, but the various caches around the Internet are still >> holding the old data. >> >> If you could take a look at your caches to see if craigslist.org >> has the following NS records: >> >> ns1p.craigslist.org >> ns2p.craigslist.org >> ns1f.craigslist.org >> ns2f.craigslist.org >> >> If you see something else there, then you have a poisoned cache. >> >> Thank you for your assistance in this matter. >> >> Brad Volz >> Network Engineer From marine64 at gmail.com Mon Nov 24 04:15:25 2014 From: marine64 at gmail.com (Brian Henson) Date: Sun, 23 Nov 2014 23:15:25 -0500 Subject: Craigslist hacked? In-Reply-To: <20141124035321.GS4848@sizone.org> References: <20141124035321.GS4848@sizone.org> Message-ID: I did a cache flush at googledns and it started resolving to a different IP than the one earlier. Thinking the DNS may have been compromised somewhere. New IP is 208.91.197.27 old one was 74.63.219.135 On Sun, Nov 23, 2014 at 10:53 PM, Ken Chase wrote: > down for me and http://www.downforeveryoneorjustme.com/craigslist.org > > /kc > > > On Sun, Nov 23, 2014 at 07:45:35PM -0800, Chaim Rieger said: > >Comes up normal for me in LA, on twc. > >On Nov 23, 2014 7:43 PM, "Brian Henson" wrote: > > > >> Is anyone else seeing their local craigslist redirected to another > site > >> other than craigslist? I see it loading > http://digitalgangster.com/5um. > >> > > -- > Ken Chase - math at sizone.org Toronto Canada > From nanog at konadogs.net Mon Nov 24 04:45:50 2014 From: nanog at konadogs.net (Nate Itkin) Date: Sun, 23 Nov 2014 18:45:50 -1000 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: <20141124044550.GA10580@li92-81.konadogs.net> Looking at San Diego. Suspecting an issue with Google DNS. Google--> dig @8.8.8.8 cities.l.craigslist.org. +short 74.63.219.135 My resolver--> dig cities.l.craigslist.org. +short 208.82.238.226 Authoritative--> dig @208.82.236.210 cities.l.craigslist.org. +short +norec 208.82.236.242 On Sun, Nov 23, 2014 at 10:59:35PM -0500, Brian Henson wrote: > Im seeing it resolve to 74.63.219.135 on my network and on > http://whois.domaintools.com/craigslist.org > > On Sun, Nov 23, 2014 at 10:57 PM, Quinn Kuzmich > wrote: > > > CoSprings list is coming up fine. > > > > On Sun, Nov 23, 2014 at 8:41 PM, Brian Henson wrote: > > > >> Is anyone else seeing their local craigslist redirected to another site > >> other than craigslist? I see it loading http://digitalgangster.com/5um. > >> > > > > From randy at psg.com Mon Nov 24 04:51:38 2014 From: randy at psg.com (Randy Bush) Date: Mon, 24 Nov 2014 13:51:38 +0900 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: and what tasty things did the hijacker's web site serve? randy From josh at imaginenetworksllc.com Mon Nov 24 05:03:19 2014 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 24 Nov 2014 00:03:19 -0500 Subject: Craigslist hacked? In-Reply-To: References: <20141124035321.GS4848@sizone.org> Message-ID: I get the favicon.ico but Chrome says Error code: ERR_CONNECTION_TIMED_OUT Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sun, Nov 23, 2014 at 11:15 PM, Brian Henson wrote: > I did a cache flush at googledns and it started resolving to a different IP > than the one earlier. Thinking the DNS may have been compromised somewhere. > New IP is 208.91.197.27 old one was 74.63.219.135 > > On Sun, Nov 23, 2014 at 10:53 PM, Ken Chase wrote: > > > down for me and http://www.downforeveryoneorjustme.com/craigslist.org > > > > /kc > > > > > > On Sun, Nov 23, 2014 at 07:45:35PM -0800, Chaim Rieger said: > > >Comes up normal for me in LA, on twc. > > >On Nov 23, 2014 7:43 PM, "Brian Henson" wrote: > > > > > >> Is anyone else seeing their local craigslist redirected to another > > site > > >> other than craigslist? I see it loading > > http://digitalgangster.com/5um. > > >> > > > > -- > > Ken Chase - math at sizone.org Toronto Canada > > > From lyndon at orthanc.ca Mon Nov 24 05:27:52 2014 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 23 Nov 2014 21:27:52 -0800 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: On Nov 23, 2014, at 8:51 PM, Randy Bush wrote: > and what tasty things did the hijacker's web site serve? Firefox on my Mac started acting very strangely after encountering one of the 'unresponsive' versions of craigslist.ca. Apparent browser hangs, javascript script timeouts, and odd things related to the browser history. I restored ~/Library/Application\ Support/Firefox from a Time Machine snapshot taken just before the Craigslist hack, and all appears fine now. I have to diff between the two versions of that directory before I claim the website hack had anything to do with it, but for now Mac Firefox users might want to be wary ... (Note: Mac OS 10.9.5 and Firefox 33.1 are what I was running.) --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From morrowc.lists at gmail.com Mon Nov 24 06:04:58 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 24 Nov 2014 01:04:58 -0500 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: On Sun, Nov 23, 2014 at 11:51 PM, Randy Bush wrote: > and what tasty things did the hijacker's web site serve? probably not much for very long... :( CL traffic is a bit crushy. From hhoffman at ip-solutions.net Mon Nov 24 13:06:51 2014 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Mon, 24 Nov 2014 08:06:51 -0500 Subject: Craigslist hacked? Message-ID: <20141124130656.165161FC28@pb-smtp1.pobox.com> Probably a good time to remind folks of HTTPS everywhere plugin for Chrome and Firefox :-) Cheers, Harry On Nov 24, 2014 1:04 AM, Christopher Morrow wrote: > > On Sun, Nov 23, 2014 at 11:51 PM, Randy Bush wrote: > > and what tasty things did the hijacker's web site serve? > > probably not much for very long... :( CL traffic is a bit crushy. From randy at psg.com Mon Nov 24 13:19:48 2014 From: randy at psg.com (Randy Bush) Date: Mon, 24 Nov 2014 22:19:48 +0900 Subject: Craigslist hacked? In-Reply-To: <20141124130656.165161FC28@pb-smtp1.pobox.com> References: <20141124130656.165161FC28@pb-smtp1.pobox.com> Message-ID: > Probably a good time to remind folks of HTTPS everywhere plugin for > Chrome and Firefox :-) what? and deter natural selection? i have hope for this really being improved next year https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web randy From Curtis.Parish at mtsu.edu Mon Nov 24 15:14:31 2014 From: Curtis.Parish at mtsu.edu (Curtis L. Parish) Date: Mon, 24 Nov 2014 15:14:31 +0000 Subject: Multi-homing with multiple ASNs In-Reply-To: <54723394.5000009@bogus.com> References: <848A0CCBF45ABC49B103A3733FA46C506427FB@MTEXMBC01.fsa.mtsu.edu> <201411211107.50085.mark.tinka@seacom.mu> <54723394.5000009@bogus.com> Message-ID: <848A0CCBF45ABC49B103A3733FA46C50649ECD@MTEXMBC01.fsa.mtsu.edu> Thanks to everyone for your input on our less than desirable BGP situation. I do want to make sure I add that the state network we are a part of serves everything from elementary schools, to universities. to the traffic cameras on the interstate. Many of these are in rural locations and in the past each state entity had created their own network including two separate state university networks. The state vendor managed network was created to save money and provide higher level services than just an ISP. Among other things it serves as the private WAN for some state agencies. As our internet redundancy and bandwidth demands have increased we have outgrown the need for the high touch services offered by the state network but we must participate in order to maintain WAN access to other state universities. Thanks again for the feedback. Curtis Curtis Parish Senior Network Engineer Middle Tennessee State University -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of joel jaeggli Sent: Sunday, November 23, 2014 1:21 PM To: mark.tinka at seacom.mu; nanog at nanog.org Subject: Re: Multi-homing with multiple ASNs On 11/21/14 1:07 AM, Mark Tinka wrote: > On Friday, November 21, 2014 12:00:47 AM Curtis L. Parish > wrote: > >> We have recently added a second ISP (third if you count I2). Our >> first "ISP" is actually a private state network that peers with two >> Tier 1 providers. We own an AS number and our IP space but at the >> last minute learned our state network is advertising our network >> using two different ASNs (neither ours) so they can load >> balance their connections. If you hit the right >> looking glass server you can see our network advertised >> by three different ASNs. We were told by the new ISP >> that this is a problem but the state network says it is not. >> >> Looking for opinions and words of wisdom on this split advertising >> issue. > > Why aren't you originating your own prefixes and ASN by yourselves, > since you own both? The practical problem here is that the control of prefix origination is distributed. so if there is a need to withdraw it from the state network or advertise it no export for some reason (e.g. performance problem maintenance etc) you likely can't. Their grasp of load-balancing seems a bit shallow also. > Mark. > From ahebert at pubnix.net Mon Nov 24 16:41:57 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 24 Nov 2014 11:41:57 -0500 Subject: Craigslist hacked? In-Reply-To: References: Message-ID: <54735FD5.7040708@pubnix.net> Well, NetSol? Is it just me or they came up a few times lately (past year) in high profil case of DNS Hijacking? On 11/23/14 23:06, Mehmet Akcin wrote: > yes it's been hijacked thru registrar level and someone was able to change > name servers, now it's back to normal but you will need to clear your > caches and perhaps your ISP too. (if you are using 8.8.8.8 , they have > already cleared the caches) > > Sponsoring Registrar:Network Solutions, LLC (R63-LROR) seems to be > registrar, would be fun to read the post-mortem. > > On Sun, Nov 23, 2014 at 7:48 PM, Brian Artschwager > wrote: > >> Same here, New Jersey. >> >> On Sun, Nov 23, 2014 at 10:43 PM, aUser wrote: >> >>> I can't reach my local one or the Fresno one. Server unreachable. >>> >>> Sent from my iPhone 5S. >>> >>>> On Nov 23, 2014, at 7:41 PM, Brian Henson wrote: >>>> >>>> Is anyone else seeing their local craigslist redirected to another site >>>> other than craigslist? I see it loading http://digitalgangster.com/5um >> . >> >> >> -- >> >> -- >> Brian >> From list at satchell.net Mon Nov 24 16:52:14 2014 From: list at satchell.net (Stephen Satchell) Date: Mon, 24 Nov 2014 08:52:14 -0800 Subject: Craigslist hacked? In-Reply-To: <54735FD5.7040708@pubnix.net> References: <54735FD5.7040708@pubnix.net> Message-ID: <5473623E.80402@satchell.net> On 11/24/2014 08:41 AM, Alain Hebert wrote: > Well, > > NetSol? > > Is it just me or they came up a few times lately (past year) in high > profil case of DNS Hijacking? > Someone was kind enough to break into one of my domains at Register.com -- and to their credit Register.com detected the intrusion and reported it to me so I could go fix the problem. Perp added DNS records to my zone file, which I deleted, and reported the incident to the owner of the IP address. Yes, I changed the passwords. From dhc2 at dcrocker.net Mon Nov 24 16:58:37 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Mon, 24 Nov 2014 08:58:37 -0800 Subject: Multi-homing with multiple ASNs In-Reply-To: <54723394.5000009@bogus.com> References: <848A0CCBF45ABC49B103A3733FA46C506427FB@MTEXMBC01.fsa.mtsu.edu> <201411211107.50085.mark.tinka@seacom.mu> <54723394.5000009@bogus.com> Message-ID: <547363BD.8040908@dcrocker.net> On 11/23/2014 11:20 AM, joel jaeggli wrote: > Their grasp of load-balancing seems a > bit shallow also. Are there discussion/guidance papers that one can point to, to improve the depth of understanding, or at least get better configuration choices? (Those are independent points of improvement...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ccosta92630 at gmail.com Mon Nov 24 20:08:11 2014 From: ccosta92630 at gmail.com (Chris Costa) Date: Mon, 24 Nov 2014 12:08:11 -0800 Subject: eBGP Graceful-Restart and GR Helper Mode with external networks. Message-ID: Is there a BCOP (or substantiated opinion) for negotiating eBGP Graceful-Restart and Graceful-Restart Helper-Mode with external networks? Implementation looks varied across a few larger transit providers, and in some cases implemented inconsistently within the same provider. Seeing most IX peers with GR disabled, although I don't see they've disabled GR Helper Mode. Apparently, Junos (12.3, at least) doesn't offer disabling GR Helper Mode for BGP. Thanks. From mark.tinka at seacom.mu Mon Nov 24 20:31:21 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 24 Nov 2014 22:31:21 +0200 Subject: eBGP Graceful-Restart and GR Helper Mode with external networks. In-Reply-To: References: Message-ID: <201411242231.21404.mark.tinka@seacom.mu> On Monday, November 24, 2014 10:08:11 PM Chris Costa wrote: > Is there a BCOP (or substantiated opinion) for > negotiating eBGP Graceful-Restart and Graceful-Restart > Helper-Mode with external networks? Implementation looks > varied across a few larger transit providers, and in > some cases implemented inconsistently within the same > provider. Seeing most IX peers with GR disabled, > although I don't see they've disabled GR Helper Mode. > Apparently, Junos (12.3, at least) doesn't offer > disabling GR Helper Mode for BGP. We generally disable GR on eBGP sessions because different peers (be they customers, upstreams or peers) have different hardware/software that could make this tricky. Internally, we run NSR on boxes with dual control planes. This is recent, as several of your garden-variety (and exotic) service provider network protocols and services are now reasonably supported that it makes sense to migrate from GR to NSR. We don't generally run GR on boxes with single control planes, as there could be operational impact when BFD is involved under some circumstances. That said, GR Helper mode tends to always be available even when GR is not enabled. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mvoity at uvm.edu Mon Nov 24 22:08:39 2014 From: mvoity at uvm.edu (Michael T. Voity) Date: Mon, 24 Nov 2014 17:08:39 -0500 Subject: Craigslist hacked? In-Reply-To: <5473623E.80402@satchell.net> References: <54735FD5.7040708@pubnix.net> <5473623E.80402@satchell.net> Message-ID: <5473AC67.4010108@uvm.edu> I hate to say this, But I think that Network Operators have not see the last of of this DNS Hijacking. Craigslist might have been a test to see how far they could get and how long it would take for it to be discovered. I hope the FBI and the other Federal agencies out there are involved with Craigslist to determine how this happened and put in safeguards in place to help prevent this from happening again. -Mike Michael T. Voity Network Engineer University of Vermont On 11/24/2014 11:52 AM, Stephen Satchell wrote: > On 11/24/2014 08:41 AM, Alain Hebert wrote: >> Well, >> >> NetSol? >> >> Is it just me or they came up a few times lately (past year) in high >> profil case of DNS Hijacking? >> > Someone was kind enough to break into one of my domains at Register.com > -- and to their credit Register.com detected the intrusion and reported > it to me so I could go fix the problem. Perp added DNS records to my > zone file, which I deleted, and reported the incident to the owner of > the IP address. > > Yes, I changed the passwords. From marine64 at gmail.com Mon Nov 24 22:14:48 2014 From: marine64 at gmail.com (Brian Henson) Date: Mon, 24 Nov 2014 17:14:48 -0500 Subject: Craigslist hacked? In-Reply-To: <5473AC67.4010108@uvm.edu> References: <54735FD5.7040708@pubnix.net> <5473623E.80402@satchell.net> <5473AC67.4010108@uvm.edu> Message-ID: It still seems broken in some areas. Mail is bouncing from Hotmail to craigslist. On Mon, Nov 24, 2014 at 5:08 PM, Michael T. Voity wrote: > I hate to say this, But I think that Network Operators have not see the > last of of this DNS Hijacking. Craigslist might have been a test to see how > far they could get and how long it would take for it to be discovered. I > hope the FBI and the other Federal agencies out there are involved with > Craigslist to determine how this happened and put in safeguards in place to > help prevent this from happening again. > > -Mike > > Michael T. Voity > Network Engineer > University of Vermont > > > On 11/24/2014 11:52 AM, Stephen Satchell wrote: > >> On 11/24/2014 08:41 AM, Alain Hebert wrote: >> >>> Well, >>> >>> NetSol? >>> >>> Is it just me or they came up a few times lately (past year) in high >>> profil case of DNS Hijacking? >>> >>> Someone was kind enough to break into one of my domains at Register.com >> -- and to their credit Register.com detected the intrusion and reported >> it to me so I could go fix the problem. Perp added DNS records to my >> zone file, which I deleted, and reported the incident to the owner of >> the IP address. >> >> Yes, I changed the passwords. >> > > From nanog at hostleasing.net Mon Nov 24 22:17:04 2014 From: nanog at hostleasing.net (Randy Epstein) Date: Mon, 24 Nov 2014 17:17:04 -0500 Subject: Craigslist hacked? In-Reply-To: <5473AC67.4010108@uvm.edu> References: <54735FD5.7040708@pubnix.net> <5473623E.80402@satchell.net> <5473AC67.4010108@uvm.edu> Message-ID: On 11/24/14, 5:08 PM, "Michael T. Voity" wrote: >I hate to say this, But I think that Network Operators have not see the >last of of this DNS Hijacking. Craigslist might have been a test to see >how far they could get and how long it would take for it to be >discovered. I hope the FBI and the other Federal agencies out there >are involved with Craigslist to determine how this happened and put in >safeguards in place to help prevent this from happening again. > >-Mike > >Michael T. Voity >Network Engineer >University of Vermont Anyone heard from Eugene Kashpureff lately? Hello 1996. :) From jra at baylink.com Tue Nov 25 00:14:11 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 24 Nov 2014 19:14:11 -0500 (EST) Subject: It's 7pm. Do you know where *your* domains are? (was Re: Craigslist hacked?) In-Reply-To: Message-ID: <9588795.1145.1416874451937.JavaMail.root@benjamin.baylink.com> In light of the CL domain hijacking, it seems like a good time to ask if everyone has an inventory system that keeps track of all the details (including renewal dates) for their domain registy and SSL certificate accounts. If you use a tool to keep track of this, which one? Do you have things set up in your monitoring system to watch for changes in this stuff? Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From george.herbert at gmail.com Tue Nov 25 00:16:07 2014 From: george.herbert at gmail.com (George Herbert) Date: Mon, 24 Nov 2014 16:16:07 -0800 Subject: Craigslist hacked? In-Reply-To: References: <54735FD5.7040708@pubnix.net> <5473623E.80402@satchell.net> <5473AC67.4010108@uvm.edu> Message-ID: He didn't hack the registry, he hijacked its records. And this is far from the first time a registry account was hacked. But, yeah, *still* not secure enough. George William Herbert Sent from my iPhone > On Nov 24, 2014, at 2:17 PM, Randy Epstein wrote: > >> On 11/24/14, 5:08 PM, "Michael T. Voity" wrote: >> >> I hate to say this, But I think that Network Operators have not see the >> last of of this DNS Hijacking. Craigslist might have been a test to see >> how far they could get and how long it would take for it to be >> discovered. I hope the FBI and the other Federal agencies out there >> are involved with Craigslist to determine how this happened and put in >> safeguards in place to help prevent this from happening again. >> >> -Mike >> >> Michael T. Voity >> Network Engineer >> University of Vermont > > Anyone heard from Eugene Kashpureff lately? > > Hello 1996. :) > > From josh at imaginenetworksllc.com Tue Nov 25 00:18:32 2014 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 24 Nov 2014 19:18:32 -0500 Subject: It's 7pm. Do you know where *your* domains are? (was Re: Craigslist hacked?) In-Reply-To: <9588795.1145.1416874451937.JavaMail.root@benjamin.baylink.com> References: <9588795.1145.1416874451937.JavaMail.root@benjamin.baylink.com> Message-ID: Xymon has a built in test to check SSL cert expiration. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Nov 24, 2014 7:14 PM, "Jay Ashworth" wrote: > In light of the CL domain hijacking, it seems like a good time to ask > if everyone has an inventory system that keeps track of all the details > (including renewal dates) for their domain registy and SSL certificate > accounts. > > If you use a tool to keep track of this, which one? > > Do you have things set up in your monitoring system to watch for changes > in this stuff? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at 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 > From nanog at hostleasing.net Tue Nov 25 00:18:29 2014 From: nanog at hostleasing.net (Randy Epstein) Date: Mon, 24 Nov 2014 19:18:29 -0500 Subject: Craigslist hacked? In-Reply-To: References: <54735FD5.7040708@pubnix.net> <5473623E.80402@satchell.net> <5473AC67.4010108@uvm.edu> Message-ID: On 11/24/14, 7:16 PM, "George Herbert" wrote: > >He didn't hack the registry, he hijacked its records. And this is far >from the first time a registry account was hacked. But, yeah, *still* >not secure enough. Actually, he didn’t hack its records either. He exploited a bug in BIND. >George William Herbert >Sent from my iPhone > >> On Nov 24, 2014, at 2:17 PM, Randy Epstein >>wrote: >> >>> On 11/24/14, 5:08 PM, "Michael T. Voity" wrote: >>> >>> I hate to say this, But I think that Network Operators have not see the >>> last of of this DNS Hijacking. Craigslist might have been a test to see >>> how far they could get and how long it would take for it to be >>> discovered. I hope the FBI and the other Federal agencies out there >>> are involved with Craigslist to determine how this happened and put in >>> safeguards in place to help prevent this from happening again. >>> >>> -Mike >>> >>> Michael T. Voity >>> Network Engineer >>> University of Vermont >> >> Anyone heard from Eugene Kashpureff lately? >> >> Hello 1996. :) >> >> From george.herbert at gmail.com Tue Nov 25 00:18:57 2014 From: george.herbert at gmail.com (George Herbert) Date: Mon, 24 Nov 2014 16:18:57 -0800 Subject: Craigslist hacked? In-Reply-To: References: <54735FD5.7040708@pubnix.net> <5473623E.80402@satchell.net> <5473AC67.4010108@uvm.edu> Message-ID: And that was July 1997 not 96, though that does nothing to make me feel younger ... George William Herbert Sent from my iPhone > On Nov 24, 2014, at 4:16 PM, George Herbert wrote: > > > He didn't hack the registry, he hijacked its records. And this is far from the first time a registry account was hacked. But, yeah, *still* not secure enough. > > > George William Herbert > Sent from my iPhone > >>> On Nov 24, 2014, at 2:17 PM, Randy Epstein wrote: >>> >>> On 11/24/14, 5:08 PM, "Michael T. Voity" wrote: >>> >>> I hate to say this, But I think that Network Operators have not see the >>> last of of this DNS Hijacking. Craigslist might have been a test to see >>> how far they could get and how long it would take for it to be >>> discovered. I hope the FBI and the other Federal agencies out there >>> are involved with Craigslist to determine how this happened and put in >>> safeguards in place to help prevent this from happening again. >>> >>> -Mike >>> >>> Michael T. Voity >>> Network Engineer >>> University of Vermont >> >> Anyone heard from Eugene Kashpureff lately? >> >> Hello 1996. :) >> >> From mfidelman at meetinghouse.net Tue Nov 25 00:20:56 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 24 Nov 2014 19:20:56 -0500 Subject: It's 7pm. Do you know where *your* domains are? (was Re: Craigslist hacked?) In-Reply-To: <9588795.1145.1416874451937.JavaMail.root@benjamin.baylink.com> References: <9588795.1145.1416874451937.JavaMail.root@benjamin.baylink.com> Message-ID: <5473CB68.2080804@meetinghouse.net> Jay Ashworth wrote: > In light of the CL domain hijacking, it seems like a good time to ask > if everyone has an inventory system that keeps track of all the details > (including renewal dates) for their domain registy and SSL certificate > accounts. > > If you use a tool to keep track of this, which one? > > Do you have things set up in your monitoring system to watch for changes > in this stuff? > > And a registrar that has an API compatible with the tool! Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nanog at hostleasing.net Tue Nov 25 00:27:11 2014 From: nanog at hostleasing.net (Randy Epstein) Date: Mon, 24 Nov 2014 19:27:11 -0500 Subject: Craigslist hacked? In-Reply-To: References: <54735FD5.7040708@pubnix.net> <5473623E.80402@satchell.net> <5473AC67.4010108@uvm.edu> Message-ID: On 11/24/14, 7:18 PM, "George Herbert" wrote: >And that was July 1997 not 96, though that does nothing to make me feel >younger ... http://archive.wired.com/politics/law/news/1997/07/5325 Yep. He did it to one of my domains (besides internic.net). >George William Herbert >Sent from my iPhone > >> On Nov 24, 2014, at 4:16 PM, George Herbert >>wrote: >> >> >> He didn't hack the registry, he hijacked its records. And this is far >>from the first time a registry account was hacked. But, yeah, *still* >>not secure enough. >> >> >> George William Herbert >> Sent from my iPhone >> >>>> On Nov 24, 2014, at 2:17 PM, Randy Epstein >>>>wrote: >>>> >>>> On 11/24/14, 5:08 PM, "Michael T. Voity" wrote: >>>> >>>> I hate to say this, But I think that Network Operators have not see >>>>the >>>> last of of this DNS Hijacking. Craigslist might have been a test to >>>>see >>>> how far they could get and how long it would take for it to be >>>> discovered. I hope the FBI and the other Federal agencies out there >>>> are involved with Craigslist to determine how this happened and put in >>>> safeguards in place to help prevent this from happening again. >>>> >>>> -Mike >>>> >>>> Michael T. Voity >>>> Network Engineer >>>> University of Vermont >>> >>> Anyone heard from Eugene Kashpureff lately? >>> >>> Hello 1996. :) >>> >>> From george.herbert at gmail.com Tue Nov 25 00:30:20 2014 From: george.herbert at gmail.com (George Herbert) Date: Mon, 24 Nov 2014 16:30:20 -0800 Subject: Craigslist hacked? In-Reply-To: References: <54735FD5.7040708@pubnix.net> <5473623E.80402@satchell.net> <5473AC67.4010108@uvm.edu> Message-ID: > On Nov 24, 2014, at 4:18 PM, Randy Epstein wrote: > > Actually, he didn’t hack its records either. He exploited a bug in BIND. ...returned a legit response plus a tacked-on glue record for www.internic.net anytime you queried his nameserver, which he tricked people into doing with mixtures of sending you mail, hitting open DNS servers with queries for his domain, and another thing I still don't want to talk about. Paul was more widely quoted and knew his BIND vulnerability better; he can always out-pedant me on this one. I did get a few press quotes, though. Your fu is weak, Randyhopper. Train harder! ;-) George William Herbert Sent from my iPhone From marka at isc.org Tue Nov 25 00:51:23 2014 From: marka at isc.org (Mark Andrews) Date: Tue, 25 Nov 2014 11:51:23 +1100 Subject: Craigslist hacked? In-Reply-To: Your message of "Mon, 24 Nov 2014 19:18:29 -0500." References: <54735FD5.7040708@pubnix.net> <5473623E.80402@satchell.net> <5473AC67.4010108@uvm.edu> Message-ID: <20141125005124.0C4BF243AC29@rock.dv.isc.org> In message , Randy Epstein writes: > On 11/24/14, 7:16 PM, "George Herbert" wrote: > > > > >He didn't hack the registry, he hijacked its records. And this is far > >from the first time a registry account was hacked. But, yeah, *still* > >not secure enough. > > Actually, he didn’t hack its records either. He exploited a bug in BIND. And your evidence for that is what? Feel free to send to security-officer at isc.org. Mark > >George William Herbert > >Sent from my iPhone > > > >> On Nov 24, 2014, at 2:17 PM, Randy Epstein > >>wrote: > >> > >>> On 11/24/14, 5:08 PM, "Michael T. Voity" wrote: > >>> > >>> I hate to say this, But I think that Network Operators have not see > the > >>> last of of this DNS Hijacking. Craigslist might have been a test to > see > >>> how far they could get and how long it would take for it to be > >>> discovered. I hope the FBI and the other Federal agencies out there > >>> are involved with Craigslist to determine how this happened and put in > >>> safeguards in place to help prevent this from happening again. > >>> > >>> -Mike > >>> > >>> Michael T. Voity > >>> Network Engineer > >>> University of Vermont > >> > >> Anyone heard from Eugene Kashpureff lately? > >> > >> Hello 1996. :) > >> > >> > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From eyeronic.design at gmail.com Tue Nov 25 00:52:44 2014 From: eyeronic.design at gmail.com (Mike Hale) Date: Mon, 24 Nov 2014 16:52:44 -0800 Subject: It's 7pm. Do you know where *your* domains are? (was Re: Craigslist hacked?) In-Reply-To: <5473CB68.2080804@meetinghouse.net> References: <9588795.1145.1416874451937.JavaMail.root@benjamin.baylink.com> <5473CB68.2080804@meetinghouse.net> Message-ID: It's pretty easy to roll out a Nagios box that checks on your domains, NS results and SSL status. On Mon, Nov 24, 2014 at 4:20 PM, Miles Fidelman wrote: > Jay Ashworth wrote: >> >> In light of the CL domain hijacking, it seems like a good time to ask >> if everyone has an inventory system that keeps track of all the details >> (including renewal dates) for their domain registy and SSL certificate >> accounts. >> >> If you use a tool to keep track of this, which one? >> >> Do you have things set up in your monitoring system to watch for changes >> in this stuff? >> >> > > And a registrar that has an API compatible with the tool! > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From nanog at hostleasing.net Tue Nov 25 00:55:35 2014 From: nanog at hostleasing.net (Randy Epstein) Date: Mon, 24 Nov 2014 19:55:35 -0500 Subject: Craigslist hacked? In-Reply-To: <20141125005124.0C4BF243AC29@rock.dv.isc.org> References: <54735FD5.7040708@pubnix.net> <5473623E.80402@satchell.net> <5473AC67.4010108@uvm.edu> <20141125005124.0C4BF243AC29@rock.dv.isc.org> Message-ID: On 11/24/14, 7:51 PM, "Mark Andrews" wrote: > >In message , Randy Epstein writes: >> On 11/24/14, 7:16 PM, "George Herbert" wrote: >> >> > >> >He didn't hack the registry, he hijacked its records. And this is far >> >from the first time a registry account was hacked. But, yeah, *still* >> >not secure enough. >> >> Actually, he didnâ•˙t hack its records either. He exploited a bug in >>BIND. > >And your evidence for that is what? Feel free to send to >security-officer at isc.org. > >Mark I could be wrong. This is what was reported by a few back in 1997. If not true, so be it. I have no further details from something that occurred 17 years ago. > >> >George William Herbert >> >Sent from my iPhone >> > >> >> On Nov 24, 2014, at 2:17 PM, Randy Epstein >> >>wrote: >> >> >> >>> On 11/24/14, 5:08 PM, "Michael T. Voity" wrote: >> >>> >> >>> I hate to say this, But I think that Network Operators have not see >> the >> >>> last of of this DNS Hijacking. Craigslist might have been a test to >> see >> >>> how far they could get and how long it would take for it to be >> >>> discovered. I hope the FBI and the other Federal agencies out >>there >> >>> are involved with Craigslist to determine how this happened and put >>in >> >>> safeguards in place to help prevent this from happening again. >> >>> >> >>> -Mike >> >>> >> >>> Michael T. Voity >> >>> Network Engineer >> >>> University of Vermont >> >> >> >> Anyone heard from Eugene Kashpureff lately? >> >> >> >> Hello 1996. :) >> >> >> >> >> >> > >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Tue Nov 25 01:00:05 2014 From: marka at isc.org (Mark Andrews) Date: Tue, 25 Nov 2014 12:00:05 +1100 Subject: Craigslist hacked? In-Reply-To: Your message of "Mon, 24 Nov 2014 16:30:20 -0800." References: <54735FD5.7040708@pubnix.net> <5473623E.80402@satchell.net> <5473AC67.4010108@uvm.edu> Message-ID: <20141125010005.689F7243ADEB@rock.dv.isc.org> In message , George Herbert writes: > > On Nov 24, 2014, at 4:18 PM, Randy Epstein > wrote: > > > > Actually, he didn’t hack its records either. He exploited a bug in > BIND. > > > ...returned a legit response plus a tacked-on glue record for > www.internic.net anytime you queried his nameserver, which he tricked > people into doing with mixtures of sending you mail, hitting open DNS > servers with queries for his domain, and another thing I still don't want > to talk about. > > > Paul was more widely quoted and knew his BIND vulnerability better; he > can always out-pedant me on this one. More a protocol bug which lead to DNSSEC, which allows you to accept a answer from anywhere so long as it is signed and validates as secure, which most of you have yet to deploy. > I did get a few press quotes, though. > > Your fu is weak, Randyhopper. Train harder! ;-) > > George William Herbert > Sent from my iPhone -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Tue Nov 25 01:02:28 2014 From: marka at isc.org (Mark Andrews) Date: Tue, 25 Nov 2014 12:02:28 +1100 Subject: Craigslist hacked? In-Reply-To: Your message of "Tue, 25 Nov 2014 11:51:23 +1100." <20141125005124.0C4BF243AC29@rock.dv.isc.org> References: <54735FD5.7040708@pubnix.net> <5473623E.80402@satchell.net> <5473AC67.4010108@uvm.edu> <20141125005124.0C4BF243AC29@rock.dv.isc.org> Message-ID: <20141125010228.396B9243AF11@rock.dv.isc.org> In message <20141125005124.0C4BF243AC29 at rock.dv.isc.org>, Mark Andrews writes: > > In message , Randy Epstein writes: > > On 11/24/14, 7:16 PM, "George Herbert" wrote: > > > > > > > >He didn't hack the registry, he hijacked its records. And this is far > > >from the first time a registry account was hacked. But, yeah, *still* > > >not secure enough. > > > > Actually, he didn’t hack its records either. He exploited a bug in BIND. Ignore. Lost track of context. Mark > And your evidence for that is what? Feel free to send to > security-officer at isc.org. > > Mark > > > >George William Herbert > > >Sent from my iPhone > > > > > >> On Nov 24, 2014, at 2:17 PM, Randy Epstein > > >>wrote: > > >> > > >>> On 11/24/14, 5:08 PM, "Michael T. Voity" wrote: > > >>> > > >>> I hate to say this, But I think that Network Operators have not see > > the > > >>> last of of this DNS Hijacking. Craigslist might have been a test to > > see > > >>> how far they could get and how long it would take for it to be > > >>> discovered. I hope the FBI and the other Federal agencies out there > > >>> are involved with Craigslist to determine how this happened and put in > > >>> safeguards in place to help prevent this from happening again. > > >>> > > >>> -Mike > > >>> > > >>> Michael T. Voity > > >>> Network Engineer > > >>> University of Vermont > > >> > > >> Anyone heard from Eugene Kashpureff lately? > > >> > > >> Hello 1996. :) > > >> > > >> > > > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From paul.w.bennett at gmail.com Tue Nov 25 12:42:44 2014 From: paul.w.bennett at gmail.com (Paul Bennett) Date: Tue, 25 Nov 2014 07:42:44 -0500 Subject: abuse reporting tools In-Reply-To: References: <546BEB30.9040207@tiedyenetworks.com> <20141119111419.2877e52e@localhost> <4E950EB3-13B7-4C48-8E6D-A9BB1BD122E7@linkedin.com> Message-ID: On Thu, Nov 20, 2014 at 6:44 AM, Paul Bennett wrote: > Inspired by this thread (and other recent similar ones about how hard > it is to report abuse in the right format to the right people), I've > decided I'm going to start work on [a] Perl module Well ... preliminary ground work has started. It's not much, yet, but it's out there _just_ enough to (hopefully) prove I'm serious about this https://github.com/PWBENNETT/Net-Abuse-Reporter Patches / collaboration more than welcome, if you think you can glean what's going on inside my head (related to this project, at least). -- Paul W Bennett From m4rtntns at gmail.com Tue Nov 25 15:36:47 2014 From: m4rtntns at gmail.com (Martin T) Date: Tue, 25 Nov 2014 17:36:47 +0200 Subject: determine relationship between the operators based on import and export statements in aut-num object? Message-ID: Hi, bit weird question, but is it possible to determine relationship(Internet transit, settlement-free peering, etc) between the operators based on import and export statements in aut-num object? Often aut-num objects in RIR database contain the remarks which describe such relationships. However, for example here I have following import and export attributes from an aut-num object of an ISP: import: from AS65133 action pref=100; accept ANY import: from AS65798 accept AS65798 import: from AS65084 accept AS65084 import: from AS65485 action pref=100; accept ANY import: from AS65751 accept AS65751 import: from AS65059 action pref=100; accept ANY import: from AS65128 accept AS65128 export: to AS65133 announce AS-SET export: to AS65798 announce ANY export: to AS65084 announce ANY export: to AS65485 announce AS-SET export: to AS65751 announce ANY export: to AS650835 announce AS-SET export: to AS65128 announce ANY Am I correct that it is safe to say that probably AS65133, AS65485 and AS65059 are the uplink providers and AS65798, AS65084, AS65751 and AS65128 are the customers of this ISP? Last but not least, maybe there is altogether a more reliable way to understand the relationship between the operators than aut-num objects(often not updated) in RIR database? thanks, Martin From baldur.norddahl at gmail.com Tue Nov 25 16:21:28 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 25 Nov 2014 17:21:28 +0100 Subject: How do I handle a supplier that delivered a faulty product? Message-ID: Hello, We are a small FTTH provider and our main business is selling 1000/1000 internet. Our network is GPON based. We recently made the mistake of buying a large shipment of Zhone 2301 modems (ONU). We did test this device before purchase, but unfortunately we failed to notice a severe fault with the product. Soon after putting it into production we got many complaints from customers that the modem would crash daily. Turns out that the device can not handle download streams at or near 1000 Mbps. Especially if the download originates with a server that is 10G connected. GPON downstream is actually 2.4 Gbps. The modem has to deliver on an ordinary 1 Gbps ethernet port. This means the packets can arrive faster than the modem can hand it off on the ethernet side. And when that happens, it will simply crash. The vendor then told us to limit download speed to 750 Mbps with a small buffer of 50 KB. Any faster and the modem can crash amongst other issues. When I told them I do not think I can sell 1000/1000 Mbps internet if I limit the modems to 750 Mbps, as that would be false advertising, I was simply told that the 2301 is a low cost solution, so deal with it. They are not going to work more on fixing the issue. The website and the datasheet does not say anything that would warn you that this product can only handle 750 Mbps: http://www.zhone.com/products/ZNID-GPON-2301/ZNID-GPON-2301.pdf So what do I do now? I am thinking Zhone needs to resolve this in a satisfactory way, which is to either return my money or switch the product to something, that actually delivers what was promised. We have some of their 24xx series and that works perfectly well. So we know it is just the 2301 that is bad. Unfortunately we are apparently to small a customer to them. As this is an USA supplier, will suing them help me any? Yes I know, don't ask for legal advice on a mailing list, and I am not - I just want to know some opinions if that is even worth considering. Or if I will just have to eat it and drive the whole shipment into the harbor. Regards, Baldur From Valdis.Kletnieks at vt.edu Tue Nov 25 16:45:43 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 25 Nov 2014 11:45:43 -0500 Subject: determine relationship between the operators based on import and export statements in aut-num object? In-Reply-To: Your message of "Tue, 25 Nov 2014 17:36:47 +0200." References: Message-ID: <3210.1416933943@turing-police.cc.vt.edu> On Tue, 25 Nov 2014 17:36:47 +0200, Martin T said: > bit weird question, but is it possible to determine > relationship(Internet transit, settlement-free peering, etc) between > the operators based on import and export statements in aut-num object? You can determine who is "upstream" and "downstream" from that. You can't tell if it's paid transit or free peering, because technically they're the same on the wire. All that's different is the economic motivations that allow/cause the routing jocks from the two sites involved to connect a pipe and put it in production. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From ww at styx.org Tue Nov 25 16:58:05 2014 From: ww at styx.org (William Waites) Date: Tue, 25 Nov 2014 16:58:05 +0000 (GMT) Subject: determine relationship between the operators based on import and export statements in aut-num object? In-Reply-To: References: Message-ID: <20141125.165805.515784595415975214.ww@styx.org> On Tue, 25 Nov 2014 17:36:47 +0200, Martin T said: > Last but not least, maybe there is altogether a more reliable > way to understand the relationship between the operators than > aut-num objects(often not updated) in RIR database? The first thing to do is look and see if the policy of, e.g. AS65133 is consistent with what you see there. I suspect you'll find a lot of mismatches but I don't know if that has been studied systematically, but it should be simple to do. Next, much more data intensive, is trawl through the route views data and see to what extent the actual updates seen are consistent with the RIR objects, and also see what (topological, not financial as Valdis points out) relationships they imply that are not present in the RIR database. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From mfidelman at meetinghouse.net Tue Nov 25 17:15:31 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 25 Nov 2014 12:15:31 -0500 Subject: How do I handle a supplier that delivered a faulty product? In-Reply-To: References: Message-ID: <5474B933.90209@meetinghouse.net> Baldur Norddahl wrote: > Hello, > > We are a small FTTH provider and our main business is selling 1000/1000 > internet. Our network is GPON based. > > We recently made the mistake of buying a large shipment of Zhone 2301 > modems (ONU). We did test this device before purchase, but unfortunately we > failed to notice a severe fault with the product. Soon after putting it > into production we got many complaints from customers that the modem would > crash daily. > > Turns out that the device can not handle download streams at or near 1000 > Mbps. Especially if the download originates with a server that is 10G > connected. > > GPON downstream is actually 2.4 Gbps. The modem has to deliver on an > ordinary 1 Gbps ethernet port. This means the packets can arrive faster > than the modem can hand it off on the ethernet side. And when that happens, > it will simply crash. > > The vendor then told us to limit download speed to 750 Mbps with a small > buffer of 50 KB. Any faster and the modem can crash amongst other issues. > > When I told them I do not think I can sell 1000/1000 Mbps internet if I > limit the modems to 750 Mbps, as that would be false advertising, I was > simply told that the 2301 is a low cost solution, so deal with it. They are > not going to work more on fixing the issue. > > The website and the datasheet does not say anything that would warn you > that this product can only handle 750 Mbps: > http://www.zhone.com/products/ZNID-GPON-2301/ZNID-GPON-2301.pdf > > So what do I do now? I am thinking Zhone needs to resolve this in a > satisfactory way, which is to either return my money or switch the product > to something, that actually delivers what was promised. We have some of > their 24xx series and that works perfectly well. So we know it is just the > 2301 that is bad. Unfortunately we are apparently to small a customer to > them. > > As this is an USA supplier, will suing them help me any? Yes I know, don't > ask for legal advice on a mailing list, and I am not - I just want to know > some opinions if that is even worth considering. Or if I will just have to > eat it and drive the whole shipment into the harbor. > > If it doesn't deliver to spec, that certainly seems like a warranty claim, followed by a lawsuit (yes - talk to a lawyer). Also, define "large shipment" and total dollars involved. You might be able to take them to small claims court (much simpler process, but generally for $10,000 or under). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From streiner at cluebyfour.org Tue Nov 25 17:39:57 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 25 Nov 2014 12:39:57 -0500 (EST) Subject: How do I handle a supplier that delivered a faulty product? In-Reply-To: <5474B933.90209@meetinghouse.net> References: <5474B933.90209@meetinghouse.net> Message-ID: On Tue, 25 Nov 2014, Miles Fidelman wrote: > If it doesn't deliver to spec, that certainly seems like a warranty claim, > followed by a lawsuit (yes - talk to a lawyer). > > Also, define "large shipment" and total dollars involved. You might be able > to take them to small claims court (much simpler process, but generally for > $10,000 or under). Disclaimer: I am not a lawyer, and I don't play one on TV. Don't be afraid to march this up the chain at Zhone, if you're dealing with a salescritter. You might be able to get better responses from VPs or CxOs. Keep the lawsuit option in your back pocket if you need it. Many companies don't want the PR black eye that comes with a customer filing suit against them, so the threat of beating them with a stick can be just as effective actually carrying out that threat. If you have a lawyer on retainer already, maybe have them on the phone with you when you speak to the CxO at Zhone. If their product is advertised as providing a service that it can't/won't actually provide, whether it's positioned as a low-cost product or not is irrelevant. If their data sheets make no mention of the limitations that have been found, that's more ammunition for the cannon. Before anyone comes back with something like "So if I buy an entry level car, but I expect it to perform like a high-end sports car, does that mean I can sue the entry-level car maker for false advertising when it doesn't perform like a high-end sports car?" No, it doesn't. There are reasonable expectations. Expecting an entry-level car to perform like a high-end sports car isn't reasonable. Expecting a GPON modem to be able to forward wire-speed gigabit Ethernet in this day and age is perfectly reasonable. jms From colton.conor at gmail.com Tue Nov 25 18:47:01 2014 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 25 Nov 2014 12:47:01 -0600 Subject: Buying IP Bandwidth Across a Peering Exchange Message-ID: I know typically peering exchanges are made for peering traffic between providers, but can you buy IP transit from a provider on an exchange? An example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple providers on the exchange, and buy 5Gbps of IP transit from others on the exchange? Some might ask why not get a cross connect to the provider. It is cheaper to buy an port on the exchange (which includes the cross connect to the exchange) than buy multiple cross connects. Plus we are planning on getting a wave to the exchange, and not having any physical routers or switches at the datacenter where the exchange/wave terminates at. Is this possible? From nanog at hostleasing.net Tue Nov 25 18:50:53 2014 From: nanog at hostleasing.net (Randy Epstein) Date: Tue, 25 Nov 2014 13:50:53 -0500 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: References: Message-ID: On 11/25/14, 1:47 PM, "Colton Conor" wrote: >I know typically peering exchanges are made for peering traffic between >providers, but can you buy IP transit from a provider on an exchange? An >example, buy a 10G port on an exchange, peer 5Gbps of traffic with >multiple >providers on the exchange, and buy 5Gbps of IP transit from others on the >exchange? > >Some might ask why not get a cross connect to the provider. It is cheaper >to buy an port on the exchange (which includes the cross connect to the >exchange) than buy multiple cross connects. Plus we are planning on >getting >a wave to the exchange, and not having any physical routers or switches at >the datacenter where the exchange/wave terminates at. Is this possible? Depends on the exchange. Some allow it, some don’t. Some don’t have a policy. Some providers offer it, some don’t. Randy From nick at foobar.org Tue Nov 25 18:51:54 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 25 Nov 2014 18:51:54 +0000 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: References: Message-ID: <5474CFCA.8030700@foobar.org> On 25/11/2014 18:47, Colton Conor wrote: > Is this possible? it depends. Some transit providers will decline to do this because it can impact on their margin. Most IXPs don't have a problem with it, but some do - although it's not clear how they can tell which packets are transit and which are peering. Nick From woody at pch.net Tue Nov 25 18:56:06 2014 From: woody at pch.net (Bill Woodcock) Date: Tue, 25 Nov 2014 10:56:06 -0800 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: References: Message-ID: On Nov 25, 2014, at 10:47 AM, Colton Conor wrote: > I know typically peering exchanges are made for peering traffic between > providers, but can you buy IP transit from a provider on an exchange? An > example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple > providers on the exchange, and buy 5Gbps of IP transit from others on the > exchange? Some IXPs have a rule that explicitly disallows this, others encourage it, most don’t care. I don’t know of any that have a mechanism to enforce a rule prohibiting it. PCH’s guidance in the IXP formation process is to avoid creating rules which are, practically, unenforceable. So we generally counsel IXPs against having a rule precluding transit across the switch fabric. That said, a crossconnect is a _much better idea_. > Some might ask why not get a cross connect to the provider. It is cheaper > to buy an port on the exchange (which includes the cross connect to the > exchange) than buy multiple cross connects. Plus we are planning on getting > a wave to the exchange, and not having any physical routers or switches at > the datacenter where the exchange/wave terminates at. Is this possible? Yes, it’s possible, but what you describe is a pretty fragile setup. Lots of common points of failure between peering and transit; places where screwing one up would screw both up. If all of this is really tangential to whatever you’re doing, and you don’t mind looking a little out-of-step with best practices, and you don’t mind it all being down at once, any time anything breaks, then it may be a reasonable economy. If you’re planning on actually depending on it, you need to do better engineering, and either spend more money, or allocate your money more conservatively. Doing everything the cheapest possible way, regardless of the fragility or complexity, is very short-sighted, and is unlikely to be an economy in the long run. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From crogers at inerail.net Tue Nov 25 18:56:56 2014 From: crogers at inerail.net (Chris Rogers) Date: Tue, 25 Nov 2014 13:56:56 -0500 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: <5474CFCA.8030700@foobar.org> References: <5474CFCA.8030700@foobar.org> Message-ID: I know a couple networks that offer to sell transit over exchanges that permit it, but require that you take a private VLAN on the exchange. Some exchanges offer private VLANs, others don't. Regards, Chris Rogers +1.302.357.3696 x2110 http://inerail.net/ On Tue, Nov 25, 2014 at 1:51 PM, Nick Hilliard wrote: > On 25/11/2014 18:47, Colton Conor wrote: > > Is this possible? > > it depends. Some transit providers will decline to do this because it can > impact on their margin. Most IXPs don't have a problem with it, but some > do - although it's not clear how they can tell which packets are transit > and which are peering. > > Nick > > From richard.hesse at weebly.com Tue Nov 25 18:59:02 2014 From: richard.hesse at weebly.com (Richard Hesse) Date: Tue, 25 Nov 2014 18:59:02 +0000 Subject: A case against vendor-locking optical modules In-Reply-To: <23296590-4175-4148-B16C-2D550BDC176E@medline.com> References: <546A3A64.6070705@ceriz.fr> <546A3D78.1030605@netassist.ua> <23296590-4175-4148-B16C-2D550BDC176E@medline.com> Message-ID: I've found the best method of dealing with vendors like this is to treat them the same way they treat you. If they won't listen to technical arguments and act like stubborn children, then I act the same way. Threaten to take your ball and go home. Or buy everything used or from grey market vendors. It works pretty well. The vendor/client relationship is a two-way street, and they should be reminded of that. Especially when dealing with commodity whitebox switch vendors like Arista...who can easily be replaced with another whitebox switch vendor and $networkOS. -richard On Tue, Nov 18, 2014 at 7:05 PM, Naslund, Steve wrote: > They want the ability to buy off the shelf components when they > manufacture. They just don't want you to have the same privilege when you > purchase. Your switches and routers are made of a bunch of OEM components > with some custom programmed ASICS and some secret sauce. If they used non > standard interface specs their costs would go through the roof as their > power supplies, memory, storage, and NICS would be all custom development. > > Steven Naslund > Chicago IL > > > > On Nov 18, 2014, at 12:42 PM, "Baldur Norddahl" < > baldur.norddahl at gmail.com> wrote: > > > > If they really wanted to lock you in, they would have triangular modules > > instead of square... > > > > Or I suppose the vendors like to be able to shop around for modules, > before > > they relabel and sell them to you at a 10x markup. > From tony at wicks.co.nz Tue Nov 25 19:46:45 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Wed, 26 Nov 2014 08:46:45 +1300 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: References: <5474CFCA.8030700@foobar.org> Message-ID: <002501d008e8$8c2a9460$a47fbd20$@wicks.co.nz> I have seen this work well when the exchange allows more than one MAC address to be presented at layer2. This way you can have two separate sub interfaces presented, one for peering and one for your private cross connect/transit. That way the routing all stays clean and manageable. It's still a little messy, but is a much better solution than getting peering and transit over a single layer3 interface. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris Rogers Sent: Wednesday, 26 November 2014 7:57 a.m. To: Nick Hilliard Cc: NANOG Subject: Re: Buying IP Bandwidth Across a Peering Exchange I know a couple networks that offer to sell transit over exchanges that permit it, but require that you take a private VLAN on the exchange. Some exchanges offer private VLANs, others don't. Regards, Chris Rogers +1.302.357.3696 x2110 http://inerail.net/ From colton.conor at gmail.com Tue Nov 25 19:51:47 2014 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 25 Nov 2014 13:51:47 -0600 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: <23DD7F07-FD46-46D3-805F-E5548DFFF5DB@fastreturn.net> References: <23DD7F07-FD46-46D3-805F-E5548DFFF5DB@fastreturn.net> Message-ID: The exchange in question is Equinix. Their sales team is leading me to believe there are multiple exchange products. One where you can peer with providers (Google, Netflix for example) and then one where you can create virtual private layer 2 vlans between providers. Then there is also the traditional cross connect fee of $350 if you want to go from one cage/rack to the other. So in a situation where we are getting a 10Gig transport wave to Equinix, we would ideally like to split this wave's use to 5Gbps of traffic going to the peering exchange for traffic going directly to Google, Netflix, and other CDN's, and then 5Gbps of pure IP transit going to a low cost provider like HE.net. Of course providers like HE.NET are also peers on the peering exchange, so it seems possible that we could just opening a peering conenction with them. I think the way most providers would do this would be to get a rack and power with Equinix. Pay a cross connect fee from the wave provider to our rack. Pay for an exchange port (which includes a cross connect to the exchange) for the 5GBPS of traffic going to Netflix, Google, etc. And then pay for yet another cross connect going to HE.net's cage to get pure IP from them. If I can buy transit directly I avoid the expenses of having to pay for space, power, another router/switch, plus a second cross connect. Thats quite a bit of money saved. Are exchanges really that unreliable compared to a traditional cross connect? On Tue, Nov 25, 2014 at 12:52 PM, Ammar Zuberi wrote: > Hi Conor, > > I know this is possible since Hurricane Electric does it for IPv6 transit, > however, I'm not sure if it violates any exchange rules or if it's even a > good idea. > > > On 25 Nov 2014, at 10:47 pm, Colton Conor > wrote: > > > > I know typically peering exchanges are made for peering traffic between > > providers, but can you buy IP transit from a provider on an exchange? An > > example, buy a 10G port on an exchange, peer 5Gbps of traffic with > multiple > > providers on the exchange, and buy 5Gbps of IP transit from others on the > > exchange? > > > > Some might ask why not get a cross connect to the provider. It is cheaper > > to buy an port on the exchange (which includes the cross connect to the > > exchange) than buy multiple cross connects. Plus we are planning on > getting > > a wave to the exchange, and not having any physical routers or switches > at > > the datacenter where the exchange/wave terminates at. Is this possible? > From drew.weaver at thenap.com Tue Nov 25 20:11:43 2014 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 25 Nov 2014 20:11:43 +0000 Subject: abuse reporting tools In-Reply-To: References: <546BEB30.9040207@tiedyenetworks.com> <20141119011113.6647956.37754.16688@supermathie.net> <546BF549.4010605@direcpath.com> Message-ID: <81dc9cb3ddaf4dbcb9459dc3670f3dea@EXCHANGE2K13.thenap.com> On Tue, Nov 18, 2014 at 7:41 PM, Robert Drake wrote: > On 11/18/2014 8:11 PM, Michael Brown wrote: [snip] > amelioration. So I'm left with a very unsatisfactory feeling of > either shutting down a possibly innocent customer based on a machines > word, or attempting to start a dialog with random_script_user_99 at hotmail.com. >>Under those circumstances, how do you know it's not a >>social-engineering based DoS being attempted? Preferably, take no >>action to shutdown services without decent confirmation; as malicious reports of a fraudulent, bogus, dramatized, or otherwise misleading nature are sometimes used by malicious actors to target a legitimate user. >>My suggestion would be table the report of a single SSH connection and >>really do nothing with it. If there is actually abuse being >>conducted, you should either be able to independently verify the actual abuse, e.g. by checking packet level data or netflow data, or you should begin to receive a pattern of complaints; more unique contacts, that you can investigate and verify are legit. contacts >>from unique networks. If you know the destination IP address that the traffic is supposedly going to you can also just ACL it, that way if it's a customer of a customer you don't shut down the customer's entire business over something one person downstream is doing and you 'fix' the issue at the same time. The right answer really depends on how responsive your customer is to the complaints in the first place. -Drew From cgrundemann at gmail.com Tue Nov 25 20:32:16 2014 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 25 Nov 2014 13:32:16 -0700 Subject: Seeking IPv6 Security Resources Message-ID: Hail NANOG! I am looking for IPv6 security resources to add to: http://www.internetsociety.org/deploy360/ipv6/security/ These could be best current practice documents, case-studies, lessons-learned/issues-found, research/evaluations, RFCs, or anything else focused on IPv6 security really. I'm not requesting that anyone do any new work, just that you point me to solid public documents that already exist. Feel free to share on-list or privately, both documents you may have authored and those you have found helpful. Thanks! ~Chris Note: Not every document shared will get posted to the Deploy360 site. -- @ChrisGrundemann http://chrisgrundemann.com From bob at FiberInternetCenter.com Tue Nov 25 21:03:16 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 25 Nov 2014 13:03:16 -0800 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: References: Message-ID: <170781d2460f12c180d3bb3fe8557f13.squirrel@66.201.44.180> I agree with Bill...going it on the cheap is risky. DOn't consider it for primary. It may be good for backup. I have sold small amounts of transit to non-ISP companies on exchanges (100-200 meg). It's a good extra backup for ISPs, if you setup your local pref, MED and then prepend your AS an extra time or two to the prefixes you transmit. Then if you ever need to use it, it's sitting there waiting to send and receive traffic. I let ISPs customers do that with us for real low cost backup fees. Bob Evans > > On Nov 25, 2014, at 10:47 AM, Colton Conor wrote: >> I know typically peering exchanges are made for peering traffic between >> providers, but can you buy IP transit from a provider on an exchange? An >> example, buy a 10G port on an exchange, peer 5Gbps of traffic with >> multiple >> providers on the exchange, and buy 5Gbps of IP transit from others on >> the >> exchange? > > Some IXPs have a rule that explicitly disallows this, others encourage it, > most don’t care. I don’t know of any that have a mechanism to enforce a > rule prohibiting it. > > PCH’s guidance in the IXP formation process is to avoid creating rules > which are, practically, unenforceable. So we generally counsel IXPs > against having a rule precluding transit across the switch fabric. That > said, a crossconnect is a _much better idea_. > >> Some might ask why not get a cross connect to the provider. It is >> cheaper >> to buy an port on the exchange (which includes the cross connect to the >> exchange) than buy multiple cross connects. Plus we are planning on >> getting >> a wave to the exchange, and not having any physical routers or switches >> at >> the datacenter where the exchange/wave terminates at. Is this possible? > > Yes, it’s possible, but what you describe is a pretty fragile setup. Lots > of common points of failure between peering and transit; places where > screwing one up would screw both up. If all of this is really tangential > to whatever you’re doing, and you don’t mind looking a little out-of-step > with best practices, and you don’t mind it all being down at once, any > time anything breaks, then it may be a reasonable economy. If you’re > planning on actually depending on it, you need to do better engineering, > and either spend more money, or allocate your money more conservatively. > > Doing everything the cheapest possible way, regardless of the fragility or > complexity, is very short-sighted, and is unlikely to be an economy in the > long run. > > -Bill > > > > > From surfer at mauigateway.com Tue Nov 25 21:24:09 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 25 Nov 2014 13:24:09 -0800 Subject: Seeking IPv6 Security Resources Message-ID: <20141125132409.8107A4C7@m0005297.ppops.net> --- cgrundemann at gmail.com wrote: From: Chris Grundemann I am looking for IPv6 security resources to add to: http://www.internetsociety.org/deploy360/ipv6/security/ These could be best current practice documents, case-studies, lessons-learned/issues-found, research/evaluations, RFCs, or anything else focused on IPv6 security really. I'm not requesting that anyone do any new work, just that you point me to solid public documents that already exist. Feel free to share on-list or privately, both documents you may have authored and those you have found helpful. ------------------------------ http://www.si6networks.com/tools/ipv6toolkit/index.html List of Tools •addr6: An IPv6 address analysis and manipulation tool. •flow6: A tool to perform a security asseessment of the IPv6 Flow Label. •frag6: A tool to perform IPv6 fragmentation-based attacks and to perform a security assessment of a number of fragmentation-related aspects. •icmp6: A tool to perform attacks based on ICMPv6 error messages. •jumbo6: A tool to assess potential flaws in the handling of IPv6 Jumbograms. •na6: A tool to send arbitrary Neighbor Advertisement messages. •ni6: A tool to send arbitrary ICMPv6 Node Information messages, and assess possible flaws in the processing of such packets. •ns6: A tool to send arbitrary Neighbor Solicitation messages. •ra6: A tool to send arbitrary Router Advertisement messages. •rd6: A tool to send arbitrary ICMPv6 Redirect messages. •rs6: A tool to send arbitrary Router Solicitation messages. •scan6: An IPv6 address scanning tool. •tcp6: A tool to send arbitrary TCP segments and perform a variety of TCP-based attacks. scott From faisal at snappytelecom.net Tue Nov 25 21:29:17 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 25 Nov 2014 21:29:17 +0000 (GMT) Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: References: <23DD7F07-FD46-46D3-805F-E5548DFFF5DB@fastreturn.net> Message-ID: <1371979136.601571.1416950957016.JavaMail.zimbra@snappytelecom.net> Hi Colton, The primary challenge in buying IP Transit across a Peering Exchange is not so much of a technical configuration challenge, but rather a 'how do we keep track of how much IP Transit you are using' ..a billing challenge. and additionally, one is making the assumption that there is capacity to do so on the IP Transit Providers Peering Port Connection. While it is possible to deal with such issue, but you need someone willing and able to do so, on the other side. ------------------------ > I think the way most providers would do this would be to get a rack and > power with Equinix. Pay a cross connect fee from the wave provider to our > rack. Pay for an exchange port (which includes a cross connect to the > exchange) for the 5GBPS of traffic going to Netflix, Google, etc. And then > pay for yet another cross connect going to HE.net's cage to get pure IP > from them. ------------------------- Yes, you are right, this is the traditional way of doing so, and yes, it can get expensive.. For this exact reason, folks such as us and others who are willing to provide access via their existing resources at different facilities. We are facilitating flexible connectivity needs of folks who are running remote (from major metro areas) such as yours, in Miami, Atlanta, and I know others who are doing so in Equinox Chicago, one in Texas and a couple of the West Coast. Feel free to ping me off list if you are interested in additional details. Regards 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: Support at Snappytelecom.net ----- Original Message ----- > From: "Colton Conor" > To: "Ammar Zuberi" > Cc: "NANOG" > Sent: Tuesday, November 25, 2014 2:51:47 PM > Subject: Re: Buying IP Bandwidth Across a Peering Exchange > > The exchange in question is Equinix. Their sales team is leading me > to believe there are multiple exchange products. One where you can peer > with providers (Google, Netflix for example) and then one where you can > create virtual private layer 2 vlans between providers. Then there is also > the traditional cross connect fee of $350 if you want to go from one > cage/rack to the other. > > So in a situation where we are getting a 10Gig transport wave to Equinix, > we would ideally like to split this wave's use to 5Gbps of traffic going to > the peering exchange for traffic going directly to Google, Netflix, and > other CDN's, and then 5Gbps of pure IP transit going to a low cost provider > like HE.net. Of course providers like HE.NET are also peers on the peering > exchange, so it seems possible that we could just opening a peering > conenction with them. > > I think the way most providers would do this would be to get a rack and > power with Equinix. Pay a cross connect fee from the wave provider to our > rack. Pay for an exchange port (which includes a cross connect to the > exchange) for the 5GBPS of traffic going to Netflix, Google, etc. And then > pay for yet another cross connect going to HE.net's cage to get pure IP > from them. > > If I can buy transit directly I avoid the expenses of having to pay for > space, power, another router/switch, plus a second cross connect. Thats > quite a bit of money saved. > > Are exchanges really that unreliable compared to a traditional cross > connect? > > On Tue, Nov 25, 2014 at 12:52 PM, Ammar Zuberi wrote: > > > Hi Conor, > > > > I know this is possible since Hurricane Electric does it for IPv6 transit, > > however, I'm not sure if it violates any exchange rules or if it's even a > > good idea. > > > > > On 25 Nov 2014, at 10:47 pm, Colton Conor > > wrote: > > > > > > I know typically peering exchanges are made for peering traffic between > > > providers, but can you buy IP transit from a provider on an exchange? An > > > example, buy a 10G port on an exchange, peer 5Gbps of traffic with > > multiple > > > providers on the exchange, and buy 5Gbps of IP transit from others on the > > > exchange? > > > > > > Some might ask why not get a cross connect to the provider. It is cheaper > > > to buy an port on the exchange (which includes the cross connect to the > > > exchange) than buy multiple cross connects. Plus we are planning on > > getting > > > a wave to the exchange, and not having any physical routers or switches > > at > > > the datacenter where the exchange/wave terminates at. Is this possible? > > > From ammar at fastreturn.net Tue Nov 25 18:52:54 2014 From: ammar at fastreturn.net (Ammar Zuberi) Date: Tue, 25 Nov 2014 22:52:54 +0400 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: References: Message-ID: <23DD7F07-FD46-46D3-805F-E5548DFFF5DB@fastreturn.net> Hi Conor, I know this is possible since Hurricane Electric does it for IPv6 transit, however, I'm not sure if it violates any exchange rules or if it's even a good idea. > On 25 Nov 2014, at 10:47 pm, Colton Conor wrote: > > I know typically peering exchanges are made for peering traffic between > providers, but can you buy IP transit from a provider on an exchange? An > example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple > providers on the exchange, and buy 5Gbps of IP transit from others on the > exchange? > > Some might ask why not get a cross connect to the provider. It is cheaper > to buy an port on the exchange (which includes the cross connect to the > exchange) than buy multiple cross connects. Plus we are planning on getting > a wave to the exchange, and not having any physical routers or switches at > the datacenter where the exchange/wave terminates at. Is this possible? From eric at atlantech.net Tue Nov 25 20:34:14 2014 From: eric at atlantech.net (Eric Van Tol) Date: Tue, 25 Nov 2014 15:34:14 -0500 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: References: Message-ID: <2C05E949E19A9146AF7BDF9D44085B86711F9B3AED@exchange.aoihq.local> >Plus we are planning on getting >a wave to the exchange, and not having any physical routers or switches at >the datacenter where the exchange/wave terminates at. Is this possible? It's been a while since I've checked the Equinix Customer Agreement and Policies documents, but I know at one time they required a physical presence in the in the IDC for an Exchange cross-connect. This may have changed in the past several years. -evt From khuon at NEEBU.Net Wed Nov 26 01:12:38 2014 From: khuon at NEEBU.Net (Jake Khuon) Date: Tue, 25 Nov 2014 17:12:38 -0800 Subject: How do I handle a supplier that delivered a faulty product? In-Reply-To: References: <5474B933.90209@meetinghouse.net> Message-ID: <54752906.7010402@NEEBU.Net> On 25/11/14 09:39, Justin M. Streiner wrote: > > Before anyone comes back with something like "So if I buy an entry level > car, but I expect it to perform like a high-end sports car, does that > mean I can sue the entry-level car maker for false advertising when it > doesn't perform like a high-end sports car?" No, it doesn't. There are > reasonable expectations. Expecting an entry-level car to perform like a > high-end sports car isn't reasonable. Expecting a GPON modem to be able > to forward wire-speed gigabit Ethernet in this day and age is perfectly > reasonable. Actually, this situation is as if you bought a low-end car that claims it can go 60MPH just like a high-end sports car which also claims to go 60MPH. But when the low-end car fails to achieve 60MPH and in fact blows up when you try to reach that speed, you do have grounds to cry false advertising. According to the spec-sheet pointed to by the OP: "GPON Rx - Downstream data rate 2.488Gbps" So the fact that the device fails to survive much less achieve the claimed rate is, I would expect, false advertisement... especially when the manufacturer acknowledges the discrepancy and refuses to take measures to remedy the situation. At this point, the OP may be at risk to his customers as well so it would be really in his best interest to pursue this as far as possible which may include legal action. -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From lists at mtin.net Wed Nov 26 01:23:09 2014 From: lists at mtin.net (Justin Wilson) Date: Tue, 25 Nov 2014 20:23:09 -0500 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: <1371979136.601571.1416950957016.JavaMail.zimbra@snappytelecom.net> References: <23DD7F07-FD46-46D3-805F-E5548DFFF5DB@fastreturn.net> <1371979136.601571.1416950957016.JavaMail.zimbra@snappytelecom.net> Message-ID: The way our exchange works is 2 different products in regards to this. 1.Peering on the exchange. This is a BGP exchange. 2.Private VLAN. Each side gets a private VLAN between the two. Either way you buy capacity on the exchange and it¹s up to you how you use it. I have some Equinix documents on their exchange port offerings if you are interested. Justin -- Justin Wilson http://www.mtin.net Managed Services ­ xISP Solutions ­ Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering ­ Transit ­ Internet Exchange On 11/25/14, 4:29 PM, "Faisal Imtiaz" wrote: >Hi Colton, > >The primary challenge in buying IP Transit across a Peering Exchange is >not so much of a technical configuration challenge, but rather a 'how do >we keep track of how much IP Transit you are using' ..a billing challenge. > >and additionally, one is making the assumption that there is capacity to >do so on the IP Transit Providers Peering Port Connection. > >While it is possible to deal with such issue, but you need someone >willing and able to do so, on the other side. > > >------------------------ >> I think the way most providers would do this would be to get a rack and >> power with Equinix. Pay a cross connect fee from the wave provider to >>our >> rack. Pay for an exchange port (which includes a cross connect to the >> exchange) for the 5GBPS of traffic going to Netflix, Google, etc. And >>then >> pay for yet another cross connect going to HE.net's cage to get pure IP >> from them. >------------------------- > >Yes, you are right, this is the traditional way of doing so, and yes, it >can get expensive.. For this exact reason, folks such as us and others >who are willing to provide access via their existing resources at >different facilities. > >We are facilitating flexible connectivity needs of folks who are running >remote (from major metro areas) such as yours, in Miami, Atlanta, and I >know others who are doing so in Equinox Chicago, one in Texas and a >couple of the West Coast. > >Feel free to ping me off list if you are interested in additional details. > > >Regards > >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: Support at Snappytelecom.net > >----- Original Message ----- >> From: "Colton Conor" >> To: "Ammar Zuberi" >> Cc: "NANOG" >> Sent: Tuesday, November 25, 2014 2:51:47 PM >> Subject: Re: Buying IP Bandwidth Across a Peering Exchange >> >> The exchange in question is Equinix. Their sales team is leading me >> to believe there are multiple exchange products. One where you can peer >> with providers (Google, Netflix for example) and then one where you can >> create virtual private layer 2 vlans between providers. Then there is >>also >> the traditional cross connect fee of $350 if you want to go from one >> cage/rack to the other. >> >> So in a situation where we are getting a 10Gig transport wave to >>Equinix, >> we would ideally like to split this wave's use to 5Gbps of traffic >>going to >> the peering exchange for traffic going directly to Google, Netflix, and >> other CDN's, and then 5Gbps of pure IP transit going to a low cost >>provider >> like HE.net. Of course providers like HE.NET are also peers on the >>peering >> exchange, so it seems possible that we could just opening a peering >> conenction with them. >> >> I think the way most providers would do this would be to get a rack and >> power with Equinix. Pay a cross connect fee from the wave provider to >>our >> rack. Pay for an exchange port (which includes a cross connect to the >> exchange) for the 5GBPS of traffic going to Netflix, Google, etc. And >>then >> pay for yet another cross connect going to HE.net's cage to get pure IP >> from them. >> >> If I can buy transit directly I avoid the expenses of having to pay for >> space, power, another router/switch, plus a second cross connect. Thats >> quite a bit of money saved. >> >> Are exchanges really that unreliable compared to a traditional cross >> connect? >> >> On Tue, Nov 25, 2014 at 12:52 PM, Ammar Zuberi >>wrote: >> >> > Hi Conor, >> > >> > I know this is possible since Hurricane Electric does it for IPv6 >>transit, >> > however, I'm not sure if it violates any exchange rules or if it's >>even a >> > good idea. >> > >> > > On 25 Nov 2014, at 10:47 pm, Colton Conor >> > wrote: >> > > >> > > I know typically peering exchanges are made for peering traffic >>between >> > > providers, but can you buy IP transit from a provider on an >>exchange? An >> > > example, buy a 10G port on an exchange, peer 5Gbps of traffic with >> > multiple >> > > providers on the exchange, and buy 5Gbps of IP transit from others >>on the >> > > exchange? >> > > >> > > Some might ask why not get a cross connect to the provider. It is >>cheaper >> > > to buy an port on the exchange (which includes the cross connect to >>the >> > > exchange) than buy multiple cross connects. Plus we are planning on >> > getting >> > > a wave to the exchange, and not having any physical routers or >>switches >> > at >> > > the datacenter where the exchange/wave terminates at. Is this >>possible? >> > >> > From bill at herrin.us Wed Nov 26 01:34:11 2014 From: bill at herrin.us (William Herrin) Date: Tue, 25 Nov 2014 20:34:11 -0500 Subject: How do I handle a supplier that delivered a faulty product? In-Reply-To: <54752906.7010402@NEEBU.Net> References: <5474B933.90209@meetinghouse.net> <54752906.7010402@NEEBU.Net> Message-ID: On Tue, Nov 25, 2014 at 8:12 PM, Jake Khuon wrote: > Actually, this situation is as if you bought a low-end car that claims > it can go 60MPH just like a high-end sports car which also claims to go > 60MPH. But when the low-end car fails to achieve 60MPH and in fact > blows up when you try to reach that speed, you do have grounds to cry > false advertising. If we're going to pick analogies, let's pick a good one. This is a car advertised to go 60 mph. But it turns out the car only goes 60 mph down hill... On a 1 degree incline it tops out at 45. And yeah, that's a lemon. If the vendor has not supplied a technically appropriate solution within a reasonable amount of time, they're in breach of the implied contract of fitness for purpose. Unless of course you -signed- a contract which says otherwise or their shrink-wrap contract has effect (only Virginia or Maryland). You may be entitled to more than a refund, such as any business losses from the failure of the product to perform as advertised, including lost customer good will and employee man hours. Baldur, I advise you to consult a lawyer. This is where a -letter- from your lawyer to their lawyer (no lawsuit just yet) will yield action. It'll make it clear to the folks on the business end that the technical end has let them (and you) down more seriously than the normal bug complaints. That letter won't cost you more than a couple hundred bucks. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From fmartin at linkedin.com Wed Nov 26 02:44:02 2014 From: fmartin at linkedin.com (Franck Martin) Date: Wed, 26 Nov 2014 02:44:02 +0000 Subject: Seeking IPv6 Security Resources In-Reply-To: References: Message-ID: <24CDAEB9-F997-46BA-8E84-E560A3B2DE1E@linkedin.com> On Nov 25, 2014, at 12:32 PM, Chris Grundemann wrote: > Hail NANOG! > > I am looking for IPv6 security resources to add to: > http://www.internetsociety.org/deploy360/ipv6/security/ > > These could be best current practice documents, case-studies, > lessons-learned/issues-found, research/evaluations, RFCs, or anything else > focused on IPv6 security really. https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf From gregg at tocici.com Wed Nov 26 04:45:46 2014 From: gregg at tocici.com (Gregg Berkholtz) Date: Tue, 25 Nov 2014 20:45:46 -0800 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: References: Message-ID: <86AB07A0-139E-4381-85BA-12033F62B5E1@tocici.com> Be careful joining an IX just to peer with Google (AS15169) and a few others...especially if your exchange doesn’t have route servers established. Some companies, such as NetFlix, have a truly open peering policy; establishing a bilateral BGP session with them is super-straightforward. On the other hand, Google’s actively-enforced policy requires you already exchange 100Mbps+ w/ their netblocks: upon requesting a session they’ll monitor/check related traffic for a few weeks before following up on your initial request. More details: https://peering.google.com/about/peering_policy.html As for transit across IX fabric, I know that HE.net is at least willing to discuss such a possibility (just started this exact discussion with their NOC last night), although they discourage it for reasons pointed out by others in this thread. On the other hand, with a willing transit provider, if you prepend your AS a few times…an IX's fabric makes a very cost-effective failover. Gregg Berkholtz > On Nov 25, 2014, at 10:47 AM, Colton Conor wrote: > > I know typically peering exchanges are made for peering traffic between > providers, but can you buy IP transit from a provider on an exchange? An > example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple > providers on the exchange, and buy 5Gbps of IP transit from others on the > exchange? > > Some might ask why not get a cross connect to the provider. It is cheaper > to buy an port on the exchange (which includes the cross connect to the > exchange) than buy multiple cross connects. Plus we are planning on getting > a wave to the exchange, and not having any physical routers or switches at > the datacenter where the exchange/wave terminates at. Is this possible? From nick at pelagiris.org Wed Nov 26 05:41:08 2014 From: nick at pelagiris.org (Nick B) Date: Wed, 26 Nov 2014 00:41:08 -0500 Subject: How do I handle a supplier that delivered a faulty product? In-Reply-To: References: <5474B933.90209@meetinghouse.net> <54752906.7010402@NEEBU.Net> Message-ID: At no point does that spec say a single thing about speed. The closest part I could find was "Upstream data rate 1.244Gbps", but I think it's pretty clear that that is the link speed, not the actual data rate. It's worth wringing them out over the issue, maybe you can shame them into taking the units back, but I don't think you will have much luck pinning them down legally on some nebulous belief that it would run at wire rate gigabit. Nick On Tue, Nov 25, 2014 at 8:34 PM, William Herrin wrote: > On Tue, Nov 25, 2014 at 8:12 PM, Jake Khuon wrote: > > Actually, this situation is as if you bought a low-end car that claims > > it can go 60MPH just like a high-end sports car which also claims to go > > 60MPH. But when the low-end car fails to achieve 60MPH and in fact > > blows up when you try to reach that speed, you do have grounds to cry > > false advertising. > > If we're going to pick analogies, let's pick a good one. This is a car > advertised to go 60 mph. But it turns out the car only goes 60 mph down > hill... On a 1 degree incline it tops out at 45. > > And yeah, that's a lemon. If the vendor has not supplied a technically > appropriate solution within a reasonable amount of time, they're in breach > of the implied contract of fitness for purpose. Unless of course you > -signed- a contract which says otherwise or their shrink-wrap contract has > effect (only Virginia or Maryland). You may be entitled to more than a > refund, such as any business losses from the failure of the product to > perform as advertised, including lost customer good will and employee man > hours. > > Baldur, I advise you to consult a lawyer. This is where a -letter- from > your lawyer to their lawyer (no lawsuit just yet) will yield action. It'll > make it clear to the folks on the business end that the technical end has > let them (and you) down more seriously than the normal bug complaints. That > letter won't cost you more than a couple hundred bucks. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > May I solve your unusual networking challenges? > From marka at isc.org Wed Nov 26 06:06:59 2014 From: marka at isc.org (Mark Andrews) Date: Wed, 26 Nov 2014 17:06:59 +1100 Subject: How do I handle a supplier that delivered a faulty product? In-Reply-To: Your message of "Wed, 26 Nov 2014 00:41:08 -0500." References: <5474B933.90209@meetinghouse.net> <54752906.7010402@NEEBU.Net> Message-ID: <20141126060659.BC4AA245688D@rock.dv.isc.org> In message , Nick B writes: > At no point does that spec say a single thing about speed. The closest > part I could find was "Upstream data rate 1.244Gbps", but I think it's > pretty clear that that is the link speed, not the actual data rate. It's > worth wringing them out over the issue, maybe you can shame them into > taking the units back, but I don't think you will have much luck pinning > them down legally on some nebulous belief that it would run at wire rate > gigabit. > Nick Any router/modem that *crashes* when the input rate exceeds the output rate is broken. A router/modem shouldn't crash regardless of the data input rate. It might drop packets but not crash. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dougb at dougbarton.us Wed Nov 26 06:22:04 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 25 Nov 2014 22:22:04 -0800 Subject: How do I handle a supplier that delivered a faulty product? In-Reply-To: <20141126060659.BC4AA245688D@rock.dv.isc.org> References: <5474B933.90209@meetinghouse.net> <54752906.7010402@NEEBU.Net> <20141126060659.BC4AA245688D@rock.dv.isc.org> Message-ID: <5475718C.5000304@dougbarton.us> On 11/25/14 10:06 PM, Mark Andrews wrote: > Any router/modem that*crashes* when the input rate exceeds the > output rate is broken. A router/modem shouldn't crash regardless > of the data input rate. It might drop packets but not crash. Maybe the bit-bucket got full? From tagno25 at gmail.com Wed Nov 26 06:30:43 2014 From: tagno25 at gmail.com (Philip Dorr) Date: Wed, 26 Nov 2014 00:30:43 -0600 Subject: How do I handle a supplier that delivered a faulty product? In-Reply-To: <5475718C.5000304@dougbarton.us> References: <5474B933.90209@meetinghouse.net> <54752906.7010402@NEEBU.Net> <20141126060659.BC4AA245688D@rock.dv.isc.org> <5475718C.5000304@dougbarton.us> Message-ID: On Wed, Nov 26, 2014 at 12:22 AM, Doug Barton wrote: > > Maybe the bit-bucket got full? Then the new packets should be dropped, but this seems like a potential vulnerability. What it seems like to me is that the bit-bucket is not size limited, and proceeds to overwrite other memory, quickly killing the OS. From gregg at tocici.com Wed Nov 26 06:38:53 2014 From: gregg at tocici.com (Gregg Berkholtz) Date: Tue, 25 Nov 2014 22:38:53 -0800 Subject: abuse reporting tools In-Reply-To: <546BEB30.9040207@tiedyenetworks.com> References: <546BEB30.9040207@tiedyenetworks.com> Message-ID: <4A8A0374-24F5-4D7D-A66D-4475D2FA36E0@tocici.com> First please filter the source addr on all egress traffic, please. Please. Second, please don’t be the network admin whom emails: “… To: notOurOrgAbuseEmail at tocici.com From: cluelessAdmin at example.com Subject: An attempt of intrusion comes from your ip . …” Just in case you missed the obvious: message body was empty, $cluelessAdmin didn’t do a basic whois for our OrgAbuseEmail, and $cluelessAdmin ASSumed we knew which of our 2,048 IPs apparently started WWIII while providing absolutely zero collaborating evidence (attaching or linking to raw tcpdump is very nice, “-d” is Ok too). We often receive dozens of these totally useless/blank emails, in clusters of a few minutes. Tricks like that earn an instant 144-hour null route badge for whichever sending company’s entire presumed netblock (if we can’t find an obvious AS), repeat offenses earn longer and more colorful badges. All get a personal voicemail to the $cluelessAdmin company’s exec(s)/admin(s). I deliver these voicemails roughly three times a week now. Teh Stupid leaves burn marks on our NOC techs, and the poor geeks can only take so much! Other suggestions, such as watching and responding to s/NetFlow spikes, or tracking/linking multiple complaining networks before even attempting to look at origins…these sometimes warrant a followup depending upon volume and frequency (easily tracked with an SQLLite + PHP-based tool/api). We’ve found things are more-often just fat fingers, someone more bored than harmful, or someone that hasn’t figured out zmap options yet. As for a genuine DDoS, with a spoofed-source - can you really do much about this? For years we’ve just automatically null-routed (+RTBH) the ingress target (and, if obvious, any egress source) for a shortish random() period, and everyone typically gets bored shortly thereafter. Our current null-route based homegrown DDoS mitigation platform requires barely ~10 seconds from detection/onset to mitigation, so we tend to elimianate most fun and drama pretty quickly. For more business-focused clients, services like CloudFlare typically keeps DDoS attacks off ingress IPs. (BTW: in addition business sites, we host Minecraft, Teamspeak, and other "l33t hax0r” targeted services) Gregg Berkholtz > On Nov 18, 2014, at 4:58 PM, Mike wrote: > > Hello, > > 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. I have > good 'consumer broadband' filtering rules in place which make sense and > protect against quite a lot of obviously ddos oriented traffic streams. > The next step I want to engage, for those types of traffic which I can > positively identify as not spoofed, is to send out abuse reports to > owners of ip ranges used to launch these attacks. Ideally I'd like to be > able to write up some form letter describing the attack, the source > ip(s) of note, some disassembled sample packets, and then feed a list of > IP source addresses and have it mail it out to the abuse contact at each > source network. I am wondering if anyone has a pointer or reference to > any tools which might help facillitate this? > > Thank you. > > Mike- From gregg at tocici.com Wed Nov 26 06:56:25 2014 From: gregg at tocici.com (Gregg Berkholtz) Date: Tue, 25 Nov 2014 22:56:25 -0800 Subject: It's 7pm. Do you know where *your* domains are? (was Re: Craigslist hacked?) In-Reply-To: References: <9588795.1145.1416874451937.JavaMail.root@benjamin.baylink.com> <5473CB68.2080804@meetinghouse.net> Message-ID: <2DF1B71E-8772-4487-BA12-49D9C04249AA@tocici.com> A half-day with SQLite, memcached and PHP solved this need for us (auto-configures Nagios). Tracking a few hundred domains at this point. Gosh, I really need to cleanup sources, and punt some of these little tools onto GitHub. Gregg Berkholtz > On Nov 24, 2014, at 4:52 PM, Mike Hale wrote: > > It's pretty easy to roll out a Nagios box that checks on your domains, > NS results and SSL status. > > On Mon, Nov 24, 2014 at 4:20 PM, Miles Fidelman > wrote: >> Jay Ashworth wrote: >>> >>> In light of the CL domain hijacking, it seems like a good time to ask >>> if everyone has an inventory system that keeps track of all the details >>> (including renewal dates) for their domain registy and SSL certificate >>> accounts. >>> >>> If you use a tool to keep track of this, which one? >>> >>> Do you have things set up in your monitoring system to watch for changes >>> in this stuff? >>> >>> >> >> And a registrar that has an API compatible with the tool! >> >> Miles Fidelman >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From bill at herrin.us Wed Nov 26 08:16:53 2014 From: bill at herrin.us (William Herrin) Date: Wed, 26 Nov 2014 03:16:53 -0500 Subject: How do I handle a supplier that delivered a faulty product? In-Reply-To: References: <5474B933.90209@meetinghouse.net> <54752906.7010402@NEEBU.Net> Message-ID: On Wed, Nov 26, 2014 at 12:41 AM, Nick B wrote: > At no point does that spec say a single thing about speed. The closest > part I could find was "Upstream data rate 1.244Gbps", but I think it's > pretty clear that that is the link speed, not the actual data rate. It's > worth wringing them out over the issue, maybe you can shame them into > taking the units back, but I don't think you will have much luck pinning > them down legally on some nebulous belief that it would run at wire rate > gigabit. Hi Nick, That's the beauty of the implied warranty of fitness for particular purpose. The seller doesn't have to give any specs at all. He just has to lead you to believe that the product is suitable for some purpose, such as providing gige to customers. Sometimes, even the fact that the seller was aware of the buyer's intended use and failed to warn him is enough. If it then proves unsuitable for that purpose for any reason, the seller is on the hook. IANAL and I think Baldur should consult one before taking any action, but unless Baldur's use obviously and significantly differed from Zhone's advertised intended use Baldur probably has a case. http://www.law.cornell.edu/ucc/2/2-315 Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From arturo.servin at gmail.com Wed Nov 26 09:28:10 2014 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 26 Nov 2014 09:28:10 +0000 Subject: Seeking IPv6 Security Resources References: Message-ID: Chris Some that come to my mind: draft-ietf-v6ops-balanced-ipv6-security and (not sure how up to date is this one) RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service RFC 5157 IPv6 Implications for Network Scanning and draft-ietf-opsec-ipv6-host-scanning RFC 6104, 6105, 7113 All about Router Advertisement Guard (RA-Guard) draft-ietf-opsec-v6 RFC 6583 Operational Neighbor Discovery Problems Regards as On Tue Nov 25 2014 at 8:34:16 PM Chris Grundemann wrote: > Hail NANOG! > > I am looking for IPv6 security resources to add to: > http://www.internetsociety.org/deploy360/ipv6/security/ > > These could be best current practice documents, case-studies, > lessons-learned/issues-found, research/evaluations, RFCs, or anything else > focused on IPv6 security really. > > I'm not requesting that anyone do any new work, just that you point me to > solid public documents that already exist. Feel free to share on-list or > privately, both documents you may have authored and those you have found > helpful. > > Thanks! > ~Chris > > Note: Not every document shared will get posted to the Deploy360 site. > > -- > @ChrisGrundemann > http://chrisgrundemann.com > From mdavids at forfun.net Wed Nov 26 12:33:39 2014 From: mdavids at forfun.net (Marco Davids) Date: Wed, 26 Nov 2014 13:33:39 +0100 Subject: Seeking IPv6 Security Resources In-Reply-To: References: Message-ID: <5475C8A3.7040001@forfun.net> Hi, Perhaps https://tools.ietf.org/html/rfc7217 might also fit in the list. -- Marco Arturo Servin schreef op 26-11-14 om 10:28: > Chris > > Some that come to my mind: > > draft-ietf-v6ops-balanced-ipv6-security and (not sure how up to date is > this one) RFC 6092 Recommended Simple Security Capabilities in Customer > Premises Equipment (CPE) for Providing Residential IPv6 Internet Service > RFC 5157 IPv6 Implications for Network Scanning and > draft-ietf-opsec-ipv6-host-scanning > RFC 6104, 6105, 7113 All about Router Advertisement Guard (RA-Guard) > draft-ietf-opsec-v6 > RFC 6583 Operational Neighbor Discovery Problems > > Regards > as > > On Tue Nov 25 2014 at 8:34:16 PM Chris Grundemann > wrote: > >> Hail NANOG! >> >> I am looking for IPv6 security resources to add to: >> http://www.internetsociety.org/deploy360/ipv6/security/ >> >> These could be best current practice documents, case-studies, >> lessons-learned/issues-found, research/evaluations, RFCs, or anything else >> focused on IPv6 security really. >> >> I'm not requesting that anyone do any new work, just that you point me to >> solid public documents that already exist. Feel free to share on-list or >> privately, both documents you may have authored and those you have found >> helpful. >> >> Thanks! >> ~Chris >> >> Note: Not every document shared will get posted to the Deploy360 site. >> >> -- >> @ChrisGrundemann >> http://chrisgrundemann.com >> -- Marco Davids -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4219 bytes Desc: S/MIME-cryptografische ondertekening URL: From mark.tinka at seacom.mu Wed Nov 26 12:36:39 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 26 Nov 2014 14:36:39 +0200 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: References: <23DD7F07-FD46-46D3-805F-E5548DFFF5DB@fastreturn.net> Message-ID: <201411261436.42993.mark.tinka@seacom.mu> On Tuesday, November 25, 2014 09:51:47 PM Colton Conor wrote: > Are exchanges really that unreliable compared to a > traditional cross connect? Not necessarily. It's just that when money is changing hands, folk tend to find (passive) x-connects within the data centre to be far more reliable (even though they are not infallible) than passing traffic across another (active) system being run by someone else in the same physical facility. Plus, some service providers will drastically reduce or eliminate SLA's (for whatever they may be worth) if there is another active system in between you and their service. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Wed Nov 26 12:38:23 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 26 Nov 2014 14:38:23 +0200 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B86711F9B3AED@exchange.aoihq.local> References: <2C05E949E19A9146AF7BDF9D44085B86711F9B3AED@exchange.aoihq.local> Message-ID: <201411261438.24202.mark.tinka@seacom.mu> On Tuesday, November 25, 2014 10:34:14 PM Eric Van Tol wrote: > It's been a while since I've checked the Equinix Customer > Agreement and Policies documents, but I know at one time > they required a physical presence in the in the IDC for > an Exchange cross-connect. This may have changed in the > past several years. Several exchange points now support some kind of resale model, where peering members are transported into the exchange point via network, without the need for physical presence at the exchange point location. I'm not sure whether Equinix's exchange points do this. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Wed Nov 26 12:41:04 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 26 Nov 2014 14:41:04 +0200 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: <170781d2460f12c180d3bb3fe8557f13.squirrel@66.201.44.180> References: <170781d2460f12c180d3bb3fe8557f13.squirrel@66.201.44.180> Message-ID: <201411261441.04558.mark.tinka@seacom.mu> On Tuesday, November 25, 2014 11:03:16 PM Bob Evans wrote: > I agree with Bill...going it on the cheap is risky. DOn't > consider it for primary. It may be good for backup. I > have sold small amounts of transit to non-ISP companies > on exchanges (100-200 meg). It's a good extra backup for > ISPs, if you setup your local pref, MED and then prepend > your AS an extra time or two to the prefixes you > transmit. Then if you ever need to use it, it's sitting > there waiting to send and receive traffic. I let ISPs > customers do that with us for real low cost backup fees. We don't support that, for example, for reasons stated by many before. Even if we did, we typically don't offer customer services on peering routers. So physically, it would be a nightmare trying to terminate an IP Transit service from a peering member when the only path between us and them is a peering router. Yes, tunneling works, but tunnels . Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From ammar at fastreturn.net Wed Nov 26 12:42:39 2014 From: ammar at fastreturn.net (Ammar Zuberi) Date: Wed, 26 Nov 2014 16:42:39 +0400 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: <201411261438.24202.mark.tinka@seacom.mu> References: <2C05E949E19A9146AF7BDF9D44085B86711F9B3AED@exchange.aoihq.local> <201411261438.24202.mark.tinka@seacom.mu> Message-ID: Hi, I’m pretty sure IX Reach can take you into an Equinix exchange, so it is probably possible that they allow this kind of stuff to happen. Ammar. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. > On Nov 26, 2014, at 4:38 PM, Mark Tinka wrote: > > On Tuesday, November 25, 2014 10:34:14 PM Eric Van Tol > wrote: > >> It's been a while since I've checked the Equinix Customer >> Agreement and Policies documents, but I know at one time >> they required a physical presence in the in the IDC for >> an Exchange cross-connect. This may have changed in the >> past several years. > > Several exchange points now support some kind of resale > model, where peering members are transported into the > exchange point via network, without the need for physical > presence at the exchange point location. > > I'm not sure whether Equinix's exchange points do this. > > Mark. From mark.tinka at seacom.mu Wed Nov 26 12:55:18 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 26 Nov 2014 14:55:18 +0200 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: References: <201411261438.24202.mark.tinka@seacom.mu> Message-ID: <201411261455.18411.mark.tinka@seacom.mu> On Wednesday, November 26, 2014 02:42:39 PM Ammar Zuberi wrote: > I’m pretty sure IX Reach can take you into an Equinix > exchange, so it is probably possible that they allow > this kind of stuff to happen. I meant in terms of a reseller model between the exchange point and preferred service providers on behalf of the exchange point members. Of course, anyone can transport anyone anywhere, as long as the right people are paid. But exchange points have been getting into reseller models with transport providers as a way to discount what would be a normal transport service between two or more points. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From Valdis.Kletnieks at vt.edu Wed Nov 26 14:45:39 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 26 Nov 2014 09:45:39 -0500 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: Your message of "Tue, 25 Nov 2014 15:34:14 -0500." <2C05E949E19A9146AF7BDF9D44085B86711F9B3AED@exchange.aoihq.local> References: <2C05E949E19A9146AF7BDF9D44085B86711F9B3AED@exchange.aoihq.local> Message-ID: <42391.1417013139@turing-police.cc.vt.edu> On Tue, 25 Nov 2014 15:34:14 -0500, Eric Van Tol said: > but I know at one time they required a physical presence in the in the IDC > for an Exchange cross-connect. At the risk of being snarky, if somebody doesn't have a presence where do you connect the other end of the cross-connect cable? :) (Note that's different than "I'm in a PoP on the west side of town, and the logical place to land my uplink is blade 2, port 3 of a router belonging to $upstream over on the east side of town" - that's an external connection not a cross-connect) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From colton.conor at gmail.com Wed Nov 26 15:15:16 2014 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 26 Nov 2014 09:15:16 -0600 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: <42391.1417013139@turing-police.cc.vt.edu> References: <2C05E949E19A9146AF7BDF9D44085B86711F9B3AED@exchange.aoihq.local> <42391.1417013139@turing-police.cc.vt.edu> Message-ID: Well, we would have a BGP router in another town. Then get a wave from a transport provider from the other town to the town that equinix or the peering exchange was located at. The cross connect would go from the transport providers Z location to the port on the exchange. I have confirmed that Equinix is willing to sell us a port on the exchange even if we don't have a physical presence there. On Wed, Nov 26, 2014 at 8:45 AM, wrote: > On Tue, 25 Nov 2014 15:34:14 -0500, Eric Van Tol said: > > but I know at one time they required a physical presence in the in the > IDC > > for an Exchange cross-connect. > > At the risk of being snarky, if somebody doesn't have a presence where do > you connect the other end of the cross-connect cable? :) > > (Note that's different than "I'm in a PoP on the west side of town, and > the logical place to land my uplink is blade 2, port 3 of a router > belonging > to $upstream over on the east side of town" - that's an external connection > not a cross-connect) > From Valdis.Kletnieks at vt.edu Wed Nov 26 15:58:13 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 26 Nov 2014 10:58:13 -0500 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: Your message of "Wed, 26 Nov 2014 09:15:16 -0600." References: <2C05E949E19A9146AF7BDF9D44085B86711F9B3AED@exchange.aoihq.local> <42391.1417013139@turing-police.cc.vt.edu> Message-ID: <4602.1417017493@turing-police.cc.vt.edu> > peering exchange was located at. The cross connect would go from the > transport providers Z location to the port on the exchange. I have In which case the cross connect is between the target and Z, who *has* a physical presence at the exchange.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From javier at advancedmachines.us Wed Nov 26 17:41:07 2014 From: javier at advancedmachines.us (Javier J) Date: Wed, 26 Nov 2014 12:41:07 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 Message-ID: Name: thepiratebay.se Address: 194.71.107.27 Its reachable from some places and not others. Is it being filtered? Is it being hijacked? Email to them bounced from google apps. Are we now officially living in a police state? mtr dies at hop 2 for me: 2. l100.nwrknj-vfttp-134.verizon-gni.net ( 173.70.26.1 ) Is verizon now censoring the internet for me? From josh at imaginenetworksllc.com Wed Nov 26 17:43:33 2014 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 26 Nov 2014 12:43:33 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: References: Message-ID: Works for me Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Nov 26, 2014 at 12:41 PM, Javier J wrote: > Name: thepiratebay.se > Address: 194.71.107.27 > > Its reachable from some places and not others. > > Is it being filtered? > > Is it being hijacked? > > Email to them bounced from google apps. > > Are we now officially living in a police state? > > mtr dies at hop 2 for me: > > 2. l100.nwrknj-vfttp-134.verizon-gni.net ( 173.70.26.1 ) > > Is verizon now censoring the internet for me? > From magicsata at gmail.com Wed Nov 26 17:44:49 2014 From: magicsata at gmail.com (Alistair Mackenzie) Date: Wed, 26 Nov 2014 17:44:49 +0000 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: References: Message-ID: All good from hibernia's network (AS5580). On 26 Nov 2014 17:43, "Javier J" wrote: > Name: thepiratebay.se > Address: 194.71.107.27 > > Its reachable from some places and not others. > > Is it being filtered? > > Is it being hijacked? > > Email to them bounced from google apps. > > Are we now officially living in a police state? > > mtr dies at hop 2 for me: > > 2. l100.nwrknj-vfttp-134.verizon-gni.net ( 173.70.26.1 ) > > Is verizon now censoring the internet for me? > From math at sizone.org Wed Nov 26 17:47:12 2014 From: math at sizone.org (Ken Chase) Date: Wed, 26 Nov 2014 12:47:12 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: References: Message-ID: <20141126174712.GF25218@sizone.org> im hitting 30 hops tracing from one location, and 30 from some EC2s. another shows 4. v638.core1.tor1.he.net 5. 100ge1-2.core1.nyc4.he.net 6. 100ge7-2.core1.lon2.he.net 7. 100ge3-2.core1.ams1.he.net 8. 100ge5-1.core1.fra1.he.net 9. rrbone.dus.ecix.net 10. te-2-1-800.bbr-dtm-01.de.infra.rrbone.net 11. ??? 12. xe-3-2.r02.dsdfge01.de.bb.gin.ntt.net 13. xe-0-1-0-20.r02.amstnl02.nl.bb.gin.ntt.net 14. 129.250.9.50 15. sl-bb21-ams-.sprintlink.net 16. sl-crs2-lon-0-8-3-0.sprintlink.net 17. sl-crs2-lon-.sprintlink.net 18. sl-crs1-nyc-0-5-2-0.sprintlink.net 19. 144.232.5.216 20. 144.232.18.59 21. 144.232.1.73 22. 144.232.11.17 23. 144.232.12.41 24. 144.232.7.124 25. sl-st20-sj-0-0-0.sprintlink.net 26. sl-china6-192107-0.sprintlink.net 27. 219.158.32.174 28. 175.45.177.217 29. ??? with some 1/2 ping times by the end. that's quite the trip around the world, hitting nyc twice. (no he<>sprintlink peering?) /kc On Wed, Nov 26, 2014 at 12:41:07PM -0500, Javier J said: >Name: thepiratebay.se >Address: 194.71.107.27 > >Its reachable from some places and not others. > >Is it being filtered? > >Is it being hijacked? > >Email to them bounced from google apps. > >Are we now officially living in a police state? > >mtr dies at hop 2 for me: > >2. l100.nwrknj-vfttp-134.verizon-gni.net ( 173.70.26.1 ) > >Is verizon now censoring the internet for me? -- Ken Chase - math at sizone.org Toronto From javier at advancedmachines.us Wed Nov 26 17:49:42 2014 From: javier at advancedmachines.us (Javier J) Date: Wed, 26 Nov 2014 12:49:42 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: <20141126174712.GF25218@sizone.org> References: <20141126174712.GF25218@sizone.org> Message-ID: Here is one from an EC2 instance in Sydney. 2. 100.68.201.19 0.0% 24 0.5 0.6 0.4 4.3 0.8 3. 100.68.201.41 0.0% 24 0.4 0.5 0.4 0.6 0.1 4. 100.67.166.5 0.0% 24 0.4 0.4 0.3 0.5 0.1 5. 100.67.164.126 0.0% 24 8.7 3.0 0.9 9.8 3.0 6. 100.64.134.79 0.0% 24 1.0 4.7 0.8 13.6 4.6 7. 100.64.129.14 0.0% 24 1.9 2.5 0.8 15.0 3.7 8. 100.64.57.64 0.0% 24 0.8 0.6 0.3 3.8 0.7 9. 100.64.24.69 0.0% 24 1.0 1.2 0.8 1.8 0.3 10. ec2-54-252-0-16.ap-southeast-2.compute.amazonaws.com 0.0% 24 0.4 8.8 0.3 49.3 17.1 11. 54.240.192.108 0.0% 23 2.2 2.2 2.0 3.6 0.4 12. 54.240.192.78 0.0% 23 2.3 3.5 1.9 21.3 4.0 13. 202.68.70.5 0.0% 23 1.7 1.7 1.3 4.1 0.5 14. xe-3-1-0.r00.sydnau02.au.bb.gin.ntt.net 0.0% 23 1.5 1.5 1.4 1.7 0.1 15. as-0.r22.tokyjp01.jp.bb.gin.ntt.net 0.0% 23 133.8 115.9 112.8 133.8 6.0 16. ae-8.r25.tokyjp05.jp.bb.gin.ntt.net 0.0% 23 113.0 117.9 112.8 138.5 7.3 17. ae-1.r22.amstnl02.nl.bb.gin.ntt.net 0.0% 23 382.1 382.3 381.4 389.4 2.0 18. ae-1.r02.amstnl02.nl.bb.gin.ntt.net 0.0% 23 370.8 369.5 368.8 370.8 0.5 19. ae7.edge6.Amsterdam.Level3.net 0.0% 23 380.7 381.1 380.7 381.6 0.3 20. ae-232-3608.edge4.Amsterdam1.Level3.net 0.0% 23 380.0 381.2 380.0 387.9 2.2 21. AS5580.edge4.Amsterdam1.Level3.net 0.0% 23 342.5 343.1 342.1 353.3 2.2 22. eth5-4.core1.ams1.nl.as5580.net 0.0% 23 342.1 342.6 342.0 344.4 0.6 23. eth4-1.r1.dus1.de.as5580.net 0.0% 23 345.6 346.4 341.4 355.4 4.6 24. 78.152.56.135 9.1% 23 346.5 347.0 345.5 351.3 1.4 25. te-2-1-800.bbr-dtm-01.de.infra.rrbone.net 0.0% 23 349.5 348.4 347.5 349.5 0.6 26. ??? 27. xe-3-2.r02.dsdfge01.de.bb.gin.ntt.net 0.0% 23 347.7 348.3 347.3 349.2 0.6 28. xe-0-1-0-20.r02.amstnl02.nl.bb.gin.ntt.net 4.3% 23 348.6 348.7 347.5 349.5 0.5 29. 129.250.9.50 0.0% 23 354.3 354.4 353.6 355.3 0.5 30. sl-bb21-ams-.sprintlink.net 4.5% 23 356.5 356.2 355.3 357.3 0.6 On Wed, Nov 26, 2014 at 12:47 PM, Ken Chase wrote: > im hitting 30 hops tracing from one location, and 30 from some EC2s. > another shows > > 4. v638.core1.tor1.he.net > 5. 100ge1-2.core1.nyc4.he.net > 6. 100ge7-2.core1.lon2.he.net > 7. 100ge3-2.core1.ams1.he.net > 8. 100ge5-1.core1.fra1.he.net > 9. rrbone.dus.ecix.net > 10. te-2-1-800.bbr-dtm-01.de.infra.rrbone.net > 11. ??? > 12. xe-3-2.r02.dsdfge01.de.bb.gin.ntt.net > 13. xe-0-1-0-20.r02.amstnl02.nl.bb.gin.ntt.net > 14. 129.250.9.50 > 15. sl-bb21-ams-.sprintlink.net > 16. sl-crs2-lon-0-8-3-0.sprintlink.net > 17. sl-crs2-lon-.sprintlink.net > 18. sl-crs1-nyc-0-5-2-0.sprintlink.net > 19. 144.232.5.216 > 20. 144.232.18.59 > 21. 144.232.1.73 > 22. 144.232.11.17 > 23. 144.232.12.41 > 24. 144.232.7.124 > 25. sl-st20-sj-0-0-0.sprintlink.net > 26. sl-china6-192107-0.sprintlink.net > 27. 219.158.32.174 > 28. 175.45.177.217 > 29. ??? > > with some 1/2 ping times by the end. that's quite the trip around the > world, > hitting nyc twice. (no he<>sprintlink peering?) > > /kc > > > On Wed, Nov 26, 2014 at 12:41:07PM -0500, Javier J said: > >Name: thepiratebay.se > >Address: 194.71.107.27 > > > >Its reachable from some places and not others. > > > >Is it being filtered? > > > >Is it being hijacked? > > > >Email to them bounced from google apps. > > > >Are we now officially living in a police state? > > > >mtr dies at hop 2 for me: > > > >2. l100.nwrknj-vfttp-134.verizon-gni.net ( 173.70.26.1 ) > > > >Is verizon now censoring the internet for me? > > -- > Ken Chase - math at sizone.org Toronto > From tshaw at oitc.com Wed Nov 26 17:49:58 2014 From: tshaw at oitc.com (TR Shaw) Date: Wed, 26 Nov 2014 12:49:58 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: References: Message-ID: <12217E2B-E3FF-41DF-8D41-AAB87DBB3E4F@oitc.com> From FL I die at xe-3-2.r02.dsdfge01.de.bb.gin.ntt.net (129.250.5.174) 172.519 ms 155.386 ms 187.235 ms On Nov 26, 2014, at 12:43 PM, Josh Luthman wrote: > Works for me > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Wed, Nov 26, 2014 at 12:41 PM, Javier J > wrote: > >> Name: thepiratebay.se >> Address: 194.71.107.27 >> >> Its reachable from some places and not others. >> >> Is it being filtered? >> >> Is it being hijacked? >> >> Email to them bounced from google apps. >> >> Are we now officially living in a police state? >> >> mtr dies at hop 2 for me: >> >> 2. l100.nwrknj-vfttp-134.verizon-gni.net ( 173.70.26.1 ) >> >> Is verizon now censoring the internet for me? >> From db at rrbone.net Wed Nov 26 17:51:52 2014 From: db at rrbone.net (Dominik Bay) Date: Wed, 26 Nov 2014 18:51:52 +0100 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: References: Message-ID: <54761338.3010808@rrbone.net> On 11/26/2014 06:41 PM, Javier J wrote: > Its reachable from some places and not others. Maybe a partial outage. From magicsata at gmail.com Wed Nov 26 17:55:56 2014 From: magicsata at gmail.com (Alistair Mackenzie) Date: Wed, 26 Nov 2014 17:55:56 +0000 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: <20141126174712.GF25218@sizone.org> References: <20141126174712.GF25218@sizone.org> Message-ID: They do some wacky routing with internal IP addresses and AS prepending to make it seem like that they see hosted in Korea. I have no idea why anyone would but they do. On 26 Nov 2014 17:54, "Ken Chase" wrote: > im hitting 30 hops tracing from one location, and 30 from some EC2s. > another shows > > 4. v638.core1.tor1.he.net > 5. 100ge1-2.core1.nyc4.he.net > 6. 100ge7-2.core1.lon2.he.net > 7. 100ge3-2.core1.ams1.he.net > 8. 100ge5-1.core1.fra1.he.net > 9. rrbone.dus.ecix.net > 10. te-2-1-800.bbr-dtm-01.de.infra.rrbone.net > 11. ??? > 12. xe-3-2.r02.dsdfge01.de.bb.gin.ntt.net > 13. xe-0-1-0-20.r02.amstnl02.nl.bb.gin.ntt.net > 14. 129.250.9.50 > 15. sl-bb21-ams-.sprintlink.net > 16. sl-crs2-lon-0-8-3-0.sprintlink.net > 17. sl-crs2-lon-.sprintlink.net > 18. sl-crs1-nyc-0-5-2-0.sprintlink.net > 19. 144.232.5.216 > 20. 144.232.18.59 > 21. 144.232.1.73 > 22. 144.232.11.17 > 23. 144.232.12.41 > 24. 144.232.7.124 > 25. sl-st20-sj-0-0-0.sprintlink.net > 26. sl-china6-192107-0.sprintlink.net > 27. 219.158.32.174 > 28. 175.45.177.217 > 29. ??? > > with some 1/2 ping times by the end. that's quite the trip around the > world, > hitting nyc twice. (no he<>sprintlink peering?) > > /kc > > > On Wed, Nov 26, 2014 at 12:41:07PM -0500, Javier J said: > >Name: thepiratebay.se > >Address: 194.71.107.27 > > > >Its reachable from some places and not others. > > > >Is it being filtered? > > > >Is it being hijacked? > > > >Email to them bounced from google apps. > > > >Are we now officially living in a police state? > > > >mtr dies at hop 2 for me: > > > >2. l100.nwrknj-vfttp-134.verizon-gni.net ( 173.70.26.1 ) > > > >Is verizon now censoring the internet for me? > > -- > Ken Chase - math at sizone.org Toronto > From joly at punkcast.com Wed Nov 26 17:57:48 2014 From: joly at punkcast.com (Joly MacFie) Date: Wed, 26 Nov 2014 12:57:48 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: <20141126174712.GF25218@sizone.org> References: <20141126174712.GF25218@sizone.org> Message-ID: Failing for me from NYC FiOS http://traceroute.monitis.com/index.jsp?url=thepiratebay.se&testId=545087 > > > On Wed, Nov 26, 2014 at 12:41:07PM -0500, Javier J said: > >Name: thepiratebay.se > >Address: 194.71.107.27 > > > >Its reachable from some places and not others. > > > >Is it being filtered? > > > >Is it being hijacked? > > > >Email to them bounced from google apps. > > > >Are we now officially living in a police state? > > > >mtr dies at hop 2 for me: > > > >2. l100.nwrknj-vfttp-134.verizon-gni.net ( 173.70.26.1 ) > > > >Is verizon now censoring the internet for me? > > -- > Ken Chase - math at sizone.org Toronto > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From AOsgood at Streamline-Solutions.net Wed Nov 26 18:02:35 2014 From: AOsgood at Streamline-Solutions.net (Aaron D. Osgood) Date: Wed, 26 Nov 2014 13:02:35 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: <12217E2B-E3FF-41DF-8D41-AAB87DBB3E4F@oitc.com> References: <12217E2B-E3FF-41DF-8D41-AAB87DBB3E4F@oitc.com> Message-ID: <029001d009a3$29f892e0$7de9b8a0$@Streamline-Solutions.net> Perhaps it has something to do with Verizon' huge fiber cut in LA? Vandalism this morning Aaron D. Osgood Streamline Solutions L.L.C 274 E. Eau Gallie Blvd. #336 Indian Harbour Beach, FL 32937 TEL: 207-518-8455 MOBILE: 207-831-5829 GTalk: aaron.osgood AOsgood at Streamline-Solutions.net www.Streamline-Solutions.net www.WMDaWARe.com Introducing Efficiency to Business since 1986  -----Original Message----- From: NANOG [mailto:nanog-bounces+aosgood=streamline-solutions.net at nanog.org] On Behalf Of TR Shaw Sent: November 26, 2014 12:50 To: Josh Luthman Cc: nanog at nanog.org Subject: Re: Anyone else having trouble reaching thepiratebay.se? AS39138 >From FL I die at xe-3-2.r02.dsdfge01.de.bb.gin.ntt.net (129.250.5.174) 172.519 ms 155.386 ms 187.235 ms On Nov 26, 2014, at 12:43 PM, Josh Luthman wrote: > Works for me > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Wed, Nov 26, 2014 at 12:41 PM, Javier J > wrote: > >> Name: thepiratebay.se >> Address: 194.71.107.27 >> >> Its reachable from some places and not others. >> >> Is it being filtered? >> >> Is it being hijacked? >> >> Email to them bounced from google apps. >> >> Are we now officially living in a police state? >> >> mtr dies at hop 2 for me: >> >> 2. l100.nwrknj-vfttp-134.verizon-gni.net ( 173.70.26.1 ) >> >> Is verizon now censoring the internet for me? >> From rs at seastrom.com Wed Nov 26 18:13:34 2014 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 26 Nov 2014 13:13:34 -0500 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: (Colton Conor's message of "Tue, 25 Nov 2014 12:47:01 -0600") References: Message-ID: <867fyhrfsh.fsf@valhalla.seastrom.com> Colton Conor writes: > Some might ask why not get a cross connect to the provider. It is cheaper > to buy an port on the exchange (which includes the cross connect to the > exchange) than buy multiple cross connects. Plus we are planning on getting > a wave to the exchange, and not having any physical routers or switches at > the datacenter where the exchange/wave terminates at. Is this possible? "Technically possible" and "advisable" are two different things. If you enjoy finger-pointing on the occasions where you are trying to smoke out performance issues, I encourage as many third, fourth, and fifth-party-managed network layers in the mix as possible. A wave with no way to test to the handoff point would of course be the icing on the cake. Are you sure you can't afford to sublet a few ru of space from someone and pay for a couple extra cross connects? -r From javier at advancedmachines.us Wed Nov 26 18:14:22 2014 From: javier at advancedmachines.us (Javier J) Date: Wed, 26 Nov 2014 13:14:22 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: <029001d009a3$29f892e0$7de9b8a0$@Streamline-Solutions.net> References: <12217E2B-E3FF-41DF-8D41-AAB87DBB3E4F@oitc.com> <029001d009a3$29f892e0$7de9b8a0$@Streamline-Solutions.net> Message-ID: I heard about that vandalism. Can anyone confirm that is the issue? But I am in the NY area so why would traffic destined to Europe go to LA? On Wed, Nov 26, 2014 at 1:02 PM, Aaron D. Osgood < AOsgood at streamline-solutions.net> wrote: > Perhaps it has something to do with Verizon' huge fiber cut in LA? > Vandalism > this morning > > > Aaron D. Osgood > > Streamline Solutions L.L.C > > 274 E. Eau Gallie Blvd. #336 > Indian Harbour Beach, FL 32937 > > TEL: 207-518-8455 > MOBILE: 207-831-5829 > GTalk: aaron.osgood > AOsgood at Streamline-Solutions.net > www.Streamline-Solutions.net > www.WMDaWARe.com > > > Introducing Efficiency to Business since 1986 > > > -----Original Message----- > From: NANOG > [mailto:nanog-bounces+aosgood=streamline-solutions.net at nanog.org] On > Behalf > Of TR Shaw > Sent: November 26, 2014 12:50 > To: Josh Luthman > Cc: nanog at nanog.org > Subject: Re: Anyone else having trouble reaching thepiratebay.se? AS39138 > > From FL I die at > > xe-3-2.r02.dsdfge01.de.bb.gin.ntt.net (129.250.5.174) 172.519 ms 155.386 > ms 187.235 ms > > On Nov 26, 2014, at 12:43 PM, Josh Luthman > wrote: > > > Works for me > > > > > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > > > On Wed, Nov 26, 2014 at 12:41 PM, Javier J > > wrote: > > > >> Name: thepiratebay.se > >> Address: 194.71.107.27 > >> > >> Its reachable from some places and not others. > >> > >> Is it being filtered? > >> > >> Is it being hijacked? > >> > >> Email to them bounced from google apps. > >> > >> Are we now officially living in a police state? > >> > >> mtr dies at hop 2 for me: > >> > >> 2. l100.nwrknj-vfttp-134.verizon-gni.net ( 173.70.26.1 ) > >> > >> Is verizon now censoring the internet for me? > >> > > > From javier at advancedmachines.us Wed Nov 26 18:43:38 2014 From: javier at advancedmachines.us (Javier J) Date: Wed, 26 Nov 2014 13:43:38 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: References: <12217E2B-E3FF-41DF-8D41-AAB87DBB3E4F@oitc.com> <029001d009a3$29f892e0$7de9b8a0$@Streamline-Solutions.net> Message-ID: I confirmed It is also blocked for Comcast users. Even Comcast business users. This is starting to look like censorship to me. On Wed, Nov 26, 2014 at 1:14 PM, Javier J wrote: > I heard about that vandalism. Can anyone confirm that is the issue? But I > am in the NY area so why would traffic destined to Europe go to LA? > > On Wed, Nov 26, 2014 at 1:02 PM, Aaron D. Osgood < > AOsgood at streamline-solutions.net> wrote: > >> Perhaps it has something to do with Verizon' huge fiber cut in LA? >> Vandalism >> this morning >> >> >> Aaron D. Osgood >> >> Streamline Solutions L.L.C >> >> 274 E. Eau Gallie Blvd. #336 >> Indian Harbour Beach, FL 32937 >> >> TEL: 207-518-8455 >> MOBILE: 207-831-5829 >> GTalk: aaron.osgood >> AOsgood at Streamline-Solutions.net >> www.Streamline-Solutions.net >> www.WMDaWARe.com >> >> >> Introducing Efficiency to Business since 1986 >> >> >> -----Original Message----- >> From: NANOG >> [mailto:nanog-bounces+aosgood=streamline-solutions.net at nanog.org] On >> Behalf >> Of TR Shaw >> Sent: November 26, 2014 12:50 >> To: Josh Luthman >> Cc: nanog at nanog.org >> Subject: Re: Anyone else having trouble reaching thepiratebay.se? AS39138 >> >> From FL I die at >> >> xe-3-2.r02.dsdfge01.de.bb.gin.ntt.net (129.250.5.174) 172.519 ms >> 155.386 >> ms 187.235 ms >> >> On Nov 26, 2014, at 12:43 PM, Josh Luthman >> wrote: >> >> > Works for me >> > >> > >> > Josh Luthman >> > Office: 937-552-2340 >> > Direct: 937-552-2343 >> > 1100 Wayne St >> > Suite 1337 >> > Troy, OH 45373 >> > >> > On Wed, Nov 26, 2014 at 12:41 PM, Javier J >> > wrote: >> > >> >> Name: thepiratebay.se >> >> Address: 194.71.107.27 >> >> >> >> Its reachable from some places and not others. >> >> >> >> Is it being filtered? >> >> >> >> Is it being hijacked? >> >> >> >> Email to them bounced from google apps. >> >> >> >> Are we now officially living in a police state? >> >> >> >> mtr dies at hop 2 for me: >> >> >> >> 2. l100.nwrknj-vfttp-134.verizon-gni.net ( 173.70.26.1 ) >> >> >> >> Is verizon now censoring the internet for me? >> >> >> >> >> > From eric-list at truenet.com Wed Nov 26 19:01:26 2014 From: eric-list at truenet.com (eric-list at truenet.com) Date: Wed, 26 Nov 2014 14:01:26 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: References: <12217E2B-E3FF-41DF-8D41-AAB87DBB3E4F@oitc.com> <029001d009a3$29f892e0$7de9b8a0$@Streamline-Solutions.net> Message-ID: <00dd01d009ab$613930e0$23ab92a0$@truenet.com> Javier, I can't get to www.rrbone.net, an upstream provider to the IP I was given for thepiratebay.se. I tested on VZ FiOS and Wireless in Philadelphia area and both die within the VZ network. For Comcast, it looks like the space isn't showing up in the BGP table: route-server.newyork.ny.ibone>show ip bgp 194.71.107.27 % Network not in table No clue what the cause is, but it bigger than just the PirateBay. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Javier J Sent: Wednesday, November 26, 2014 1:44 PM To: nanog at nanog.org Subject: Re: Anyone else having trouble reaching thepiratebay.se? AS39138 I confirmed It is also blocked for Comcast users. Even Comcast business users. This is starting to look like censorship to me. From courtneysmith at comcast.net Wed Nov 26 19:11:03 2014 From: courtneysmith at comcast.net (courtneysmith at comcast.net) Date: Wed, 26 Nov 2014 19:11:03 +0000 (UTC) Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: <872480570.5671157.1417028841652.JavaMail.zimbra@comcast.net> Message-ID: <162472710.5673666.1417029063060.JavaMail.zimbra@comcast.net> Only one of their /24's is in TATA's(AS6453) table. http://bgp.he.net/AS51040#_prefixes http://lg.as6453.net Router: gin-aeq-tcore1 Site: US, Ashburn, AEQ Command: show route protocol bgp 194.71.107.0/24 terse exact {master} Router: gin-aeq-tcore1 Site: US, Ashburn, AEQ Command: show route protocol bgp 194.14.56.0/24 terse exact inet.0: 520187 destinations, 3597636 routes (519993 active, 9 holddown, 1053 hidden) Restart Complete + = Active Route, - = Last Active, * = Both A V Destination P Prf Metric 1 Metric 2 Next hop AS path * ? 194.14.56.0/24 B 197595 51040 I unverified >216.6.87.1 ? B 197595 51040 I unverified >216.6.87.1 ? B 197595 51040 I unverified >216.6.87.1 ? B 1239 1257 197595 51040 I unverified >144.232.7.61 {master} On 11/26/14, 2:01 PM, " eric-list at truenet.com " < eric-list at truenet.com > wrote: Javier, I can't get to www.rrbone.net, an upstream provider to the IP I was given for thepiratebay.se. I tested on VZ FiOS and Wireless in Philadelphia area and both die within the VZ network. For Comcast, it looks like the space isn't showing up in the BGP table: route-server.newyork.ny.ibone>show ip bgp 194.71.107.27 % Network not in table No clue what the cause is, but it bigger than just the PirateBay. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 -----Original Message----- From: NANOG [ mailto:nanog-bounces at nanog.org ] On Behalf Of Javier J Sent: Wednesday, November 26, 2014 1:44 PM To: nanog at nanog.org Subject: Re: Anyone else having trouble reaching thepiratebay.se? AS39138 I confirmed It is also blocked for Comcast users. Even Comcast business users. This is starting to look like censorship to me. From javier at advancedmachines.us Wed Nov 26 19:35:59 2014 From: javier at advancedmachines.us (Javier J) Date: Wed, 26 Nov 2014 14:35:59 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: <00dd01d009ab$613930e0$23ab92a0$@truenet.com> References: <12217E2B-E3FF-41DF-8D41-AAB87DBB3E4F@oitc.com> <029001d009a3$29f892e0$7de9b8a0$@Streamline-Solutions.net> <00dd01d009ab$613930e0$23ab92a0$@truenet.com> Message-ID: I can get to www.rrbone.net via ipv6 (HE.net tunnel) but on ipv4, it dies on hop 2, same as thepiratebay.se on Verizon Fios. On Wed, Nov 26, 2014 at 2:01 PM, wrote: > Javier, > > I can't get to www.rrbone.net, an upstream provider to the IP I was given > for thepiratebay.se. > I tested on VZ FiOS and Wireless in Philadelphia area and both die within > the VZ network. > > For Comcast, it looks like the space isn't showing up in the BGP table: > route-server.newyork.ny.ibone>show ip bgp 194.71.107.27 > % Network not in table > > No clue what the cause is, but it bigger than just the PirateBay. > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Javier J > Sent: Wednesday, November 26, 2014 1:44 PM > To: nanog at nanog.org > Subject: Re: Anyone else having trouble reaching thepiratebay.se? AS39138 > > I confirmed It is also blocked for Comcast users. Even Comcast business > users. This is starting to look like censorship to me. > > > From m.hallgren at free.fr Wed Nov 26 22:12:27 2014 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 26 Nov 2014 23:12:27 +0100 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: <54761338.3010808@rrbone.net> References: <54761338.3010808@rrbone.net> Message-ID: <5476504B.5050504@free.fr> Le 26/11/2014 18:51, Dominik Bay a écrit : > On 11/26/2014 06:41 PM, Javier J wrote: >> Its reachable from some places and not others. > Maybe a partial outage. >From France: mh at home:~$ mtr --report thepiratebay.org Start: Wed Nov 26 23:09:31 2014 HOST: home Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.254 0.0% 10 0.3 0.3 0.3 0.4 0.0 29.|-- sl-st20-sj-0-0-0.sprintli 10.0% 10 215.3 216.2 213.1 219.6 2.3 30.|-- sl-china6-192107-0.sprint 10.0% 10 455.9 461.0 455.9 464.5 3.0 mh at home:~$ Cheers, mh From jsklein at gmail.com Wed Nov 26 13:54:07 2014 From: jsklein at gmail.com (Joe Klein) Date: Wed, 26 Nov 2014 08:54:07 -0500 Subject: Seeking IPv6 Security Resources In-Reply-To: References: Message-ID: Chris, Are you aware IPv6 has 3 or arguably 4 major generations of standards? Each generation requires nuanced defense strategies, based on which clauses ("must" and "should") were implemented. Some of the derived security works, do not reflect, and in some cases contradict current security recommendations. The perceived newness of the technology, and ambiguities of recommendations have resulted in 'pushback' by the security community to implement IPv6. This has forced us to continue with the implement of IPv6 and 'trust' the vender recommendations, based on the limitations of that venders products. In the cracks, between the standards and implementation of these standards, are where security vulnerabilities exist, compromises lay, and defenses crumble. Joe Klein "Inveniam viam aut faciam" On Tue, Nov 25, 2014 at 3:32 PM, Chris Grundemann wrote: > Hail NANOG! > > I am looking for IPv6 security resources to add to: > http://www.internetsociety.org/deploy360/ipv6/security/ > > These could be best current practice documents, case-studies, > lessons-learned/issues-found, research/evaluations, RFCs, or anything else > focused on IPv6 security really. > > I'm not requesting that anyone do any new work, just that you point me to > solid public documents that already exist. Feel free to share on-list or > privately, both documents you may have authored and those you have found > helpful. > > Thanks! > ~Chris > > Note: Not every document shared will get posted to the Deploy360 site. > > -- > @ChrisGrundemann > http://chrisgrundemann.com > From tb at tburke.us Wed Nov 26 18:01:06 2014 From: tb at tburke.us (Tim Burke) Date: Wed, 26 Nov 2014 18:01:06 +0000 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: References: Message-ID: Reachable from 32748. tim-macbookair:~ tim$ curl -I thepiratebay.se | head -n 2 HTTP/1.1 200 OK Server: nginx/1.6.0 tim-macbookair:~ tim$ traceroute thepiratebay.se traceroute to thepiratebay.se (194.71.107.27), 64 hops max, 52 byte packets 1 ip253 (208.100.33.253) 4.519 ms 3.744 ms 7.527 ms 2 xe-0-0-1.core4.chi02.steadfast.net (208.100.32.54) 4.327 ms 3.609 ms 4.261 ms 3 equinix-chicago.r1.chi1.us.as5580.net (206.223.119.45) 1.949 ms 2.118 ms 2.739 ms 4 eth1-4.core1.nyc1.us.as5580.net (78.152.34.149) 27.405 ms 29.265 ms 27.324 ms 5 eth1-5.core1.lon1.uk.as5580.net (78.152.44.134) 112.885 ms 111.443 ms 115.038 ms 6 eth13-1.core1.ams2.nl.as5580.net (78.152.44.239) 117.769 ms 117.290 ms 117.682 ms 7 eth1-7.core1.ams1.nl.as5580.net (78.152.34.13) 119.281 ms 117.476 ms 119.076 ms 8 eth4-1.r1.dus1.de.as5580.net (78.152.35.81) 127.028 ms 129.374 ms 121.328 ms 9 78.152.56.135 (78.152.56.135) 120.359 ms 120.729 ms 122.419 ms 10 te-2-1-800.bbr-dtm-01.de.infra.rrbone.net (31.172.1.10) 125.505 ms 126.621 ms 124.002 ms 11 * * * 12 xe-3-2.r02.dsdfge01.de.bb.gin.ntt.net (129.250.5.174) 128.702 ms 123.925 ms 124.836 ms 13 xe-0-1-0-20.r02.amstnl02.nl.bb.gin.ntt.net (129.250.2.64) 128.228 ms 128.397 ms 127.411 ms 14 129.250.9.50 (129.250.9.50) 129.909 ms 129.704 ms 129.277 ms 15 sl-bb21-ams-.sprintlink.net (217.149.32.206) 131.034 ms 128.477 ms 134.101 ms 16 sl-crs2-lon-0-8-3-0.sprintlink.net (213.206.129.143) 141.237 ms 144.952 ms 140.634 ms 17 sl-crs2-lon-.sprintlink.net (213.206.128.184) 143.750 ms 143.616 ms * 18 sl-crs1-nyc-0-5-2-0.sprintlink.net (144.232.9.163) 203.638 ms 203.826 ms 201.930 ms 19 144.232.5.216 (144.232.5.216) 289.414 ms 226.218 ms 223.651 ms 20 144.232.18.59 (144.232.18.59) 225.157 ms 225.886 ms 241.369 ms 21 144.232.1.73 (144.232.1.73) 303.248 ms * 432.785 ms 22 144.232.11.17 (144.232.11.17) 272.401 ms 434.872 ms 269.220 ms 23 * * * 24 *^C On 11/26/14, 5:41 PM, "Javier J" wrote: >Name: thepiratebay.se >Address: 194.71.107.27 > >Its reachable from some places and not others. > >Is it being filtered? > >Is it being hijacked? > >Email to them bounced from google apps. > >Are we now officially living in a police state? > >mtr dies at hop 2 for me: > >2. l100.nwrknj-vfttp-134.verizon-gni.net ( 173.70.26.1 ) > >Is verizon now censoring the internet for me? From jayfar at jayfar.com Thu Nov 27 00:27:17 2014 From: jayfar at jayfar.com (Jay Farrell) Date: Wed, 26 Nov 2014 19:27:17 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: References: Message-ID: Network unreachable from Vz DSL in Philly: $ traceroute 194.71.107.27 traceroute to 194.71.107.27 (194.71.107.27), 64 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 1.064 ms 0.709 ms 0.699 ms 2 10.7.120.1 (10.7.120.1) 24.135 ms 24.033 ms 23.911 ms 3 g0-5-4-2.phlapa-lcr-21.verizon-gni.net (130.81.196.51) 27.534 ms !N * 28.486 ms !N On Wed, Nov 26, 2014 at 1:01 PM, Tim Burke wrote: > Reachable from 32748. > > tim-macbookair:~ tim$ curl -I thepiratebay.se | head -n 2 > HTTP/1.1 200 OK > Server: nginx/1.6.0 > > tim-macbookair:~ tim$ traceroute thepiratebay.se > traceroute to thepiratebay.se (194.71.107.27), 64 hops max, 52 byte > packets > 1 ip253 (208.100.33.253) 4.519 ms 3.744 ms 7.527 ms > 2 xe-0-0-1.core4.chi02.steadfast.net (208.100.32.54) 4.327 ms 3.609 ms > 4.261 ms > 3 equinix-chicago.r1.chi1.us.as5580.net (206.223.119.45) 1.949 ms > 2.118 ms 2.739 ms > 4 eth1-4.core1.nyc1.us.as5580.net (78.152.34.149) 27.405 ms 29.265 ms > 27.324 ms > 5 eth1-5.core1.lon1.uk.as5580.net (78.152.44.134) 112.885 ms 111.443 > ms 115.038 ms > 6 eth13-1.core1.ams2.nl.as5580.net (78.152.44.239) 117.769 ms 117.290 > ms 117.682 ms > 7 eth1-7.core1.ams1.nl.as5580.net (78.152.34.13) 119.281 ms 117.476 ms > 119.076 ms > 8 eth4-1.r1.dus1.de.as5580.net (78.152.35.81) 127.028 ms 129.374 ms > 121.328 ms > 9 78.152.56.135 (78.152.56.135) 120.359 ms 120.729 ms 122.419 ms > 10 te-2-1-800.bbr-dtm-01.de.infra.rrbone.net (31.172.1.10) 125.505 ms > 126.621 ms 124.002 ms > 11 * * * > 12 xe-3-2.r02.dsdfge01.de.bb.gin.ntt.net (129.250.5.174) 128.702 ms > 123.925 ms 124.836 ms > 13 xe-0-1-0-20.r02.amstnl02.nl.bb.gin.ntt.net (129.250.2.64) 128.228 ms > 128.397 ms 127.411 ms > 14 129.250.9.50 (129.250.9.50) 129.909 ms 129.704 ms 129.277 ms > 15 sl-bb21-ams-.sprintlink.net (217.149.32.206) 131.034 ms 128.477 ms > 134.101 ms > 16 sl-crs2-lon-0-8-3-0.sprintlink.net (213.206.129.143) 141.237 ms > 144.952 ms 140.634 ms > 17 sl-crs2-lon-.sprintlink.net (213.206.128.184) 143.750 ms 143.616 ms > * > 18 sl-crs1-nyc-0-5-2-0.sprintlink.net (144.232.9.163) 203.638 ms > 203.826 ms 201.930 ms > 19 144.232.5.216 (144.232.5.216) 289.414 ms 226.218 ms 223.651 ms > 20 144.232.18.59 (144.232.18.59) 225.157 ms 225.886 ms 241.369 ms > 21 144.232.1.73 (144.232.1.73) 303.248 ms * 432.785 ms > 22 144.232.11.17 (144.232.11.17) 272.401 ms 434.872 ms 269.220 ms > 23 * * * > 24 *^C > > > > On 11/26/14, 5:41 PM, "Javier J" wrote: > > >Name: thepiratebay.se > >Address: 194.71.107.27 > > > >Its reachable from some places and not others. > > > >Is it being filtered? > > > >Is it being hijacked? > > > >Email to them bounced from google apps. > > > >Are we now officially living in a police state? > > > >mtr dies at hop 2 for me: > > > >2. l100.nwrknj-vfttp-134.verizon-gni.net ( 173.70.26.1 ) > > > >Is verizon now censoring the internet for me? > From erey at ernw.de Thu Nov 27 00:21:09 2014 From: erey at ernw.de (Enno Rey) Date: Thu, 27 Nov 2014 01:21:09 +0100 Subject: Seeking IPv6 Security Resources In-Reply-To: References: Message-ID: <20141127002109.GJ52779@ernw.de> Hi, On Wed, Nov 26, 2014 at 08:54:07AM -0500, Joe Klein wrote: > Chris, > > Are you aware IPv6 has 3 or arguably 4 major generations of standards? > > Each generation requires nuanced defense strategies, based on which clauses > ("must" and "should") were implemented. Some of the derived security works, > do not reflect, and in some cases contradict current security > recommendations. both very good points, Joe, which I fully second. This is - to some degree - discussed in this talk: https://www.ernw.de/download/TROOPERS_IPv6SecSummit_ERNW_IPv6_Structural_Deficits.pdf which I suggest to add to the resource list in compilation. [disclaimer: I'm the author] best Enno The perceived newness of the technology, and ambiguities > of recommendations have resulted in 'pushback' by the security community to > implement IPv6. This has forced us to continue with the implement of IPv6 > and 'trust' the vender recommendations, based on the limitations of that > venders products. > > In the cracks, between the standards and implementation of these standards, > are where security vulnerabilities exist, compromises lay, and defenses > crumble. > > Joe Klein > "Inveniam viam aut faciam" > > On Tue, Nov 25, 2014 at 3:32 PM, Chris Grundemann > wrote: > > > Hail NANOG! > > > > I am looking for IPv6 security resources to add to: > > http://www.internetsociety.org/deploy360/ipv6/security/ > > > > These could be best current practice documents, case-studies, > > lessons-learned/issues-found, research/evaluations, RFCs, or anything else > > focused on IPv6 security really. > > > > I'm not requesting that anyone do any new work, just that you point me to > > solid public documents that already exist. Feel free to share on-list or > > privately, both documents you may have authored and those you have found > > helpful. > > > > Thanks! > > ~Chris > > > > Note: Not every document shared will get posted to the Deploy360 site. > > > > -- > > @ChrisGrundemann > > http://chrisgrundemann.com > > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From courtneysmith at comcast.net Thu Nov 27 02:18:01 2014 From: courtneysmith at comcast.net (Courtney Smith) Date: Wed, 26 Nov 2014 21:18:01 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: <5D1C0F5E-DAF6-4F7A-AEBF-EEFEE14EE230@truenet.com> References: <162472710.5673666.1417029063060.JavaMail.zimbra@comcast.net> <5D1C0F5E-DAF6-4F7A-AEBF-EEFEE14EE230@truenet.com> Message-ID: I just posted TATA as a single example. This route is missing from multiple networks. I could not find the specific /24 on, Sprint(1239) AT&T(7018) and Centurylink either. rviews at route-server.ip.att.net> show route 194.71.107.0/24 rviews at route-server.ip.att.net> from https://www.sprint.net/lg/lg_start.php Query Results: Sprint Source Region: New York, NY (sl-gw27-nyc) Performing: Show Route % Network not in table Completed - Wed Nov 26 21:11:51 EST 2014 Basic troubleshooting of your two example ASN's. Notice the community 174:991 on the Cogent path? Go look that up in Cogent's community guide. Level3's looking glass actually does the translation of communities for you. I'm not going to try to map out all the possible paths this prefix could be reach. At the moment, the /24 is not reachable from several networks. Either an outage or a change at AS51040 or their upstreams has caused the traffic engineering of one of the networks upstream of 51040 to break connectivity for a group of networks. from http://www.cogentco.com/en/network/looking-glass BGP routing table entry for 194.71.107.0/24, version 2977032097 Paths: (1 available, best #1, table Default-IP-Routing-Table) 5580 39138 22351 2.207 51040 38.104.73.58 (metric 10111041) from 154.54.66.76 (154.54.66.76) Origin IGP, metric 0, localpref 130, valid, internal, best Community: 174:991 174:10004 174:20999 174:21001 174:22013 Originator: 66.28.1.248, Cluster list: 154.54.66.76, 66.28.1.69, 66.28.1.103, 66.28.1.9, 154.54.66.49 Route results for 194.71.107.0/24 from Atlanta, GA BGP routing table entry for 194.71.107.0/24 Paths: (2 available, best #1) 5580 39138 22351 23456 51040 AS-path translation: { ATRATO-IP OPENAP-WIRELESS-NETWORKS-AS INTELSAT AS23456 PIRATE-AS } ear1.Atlanta2 (metric 20000) Origin IGP, metric 0, localpref 100, valid, internal, best Community: North_America Lclprf_100 Level3_Customer United_States Atlanta Level3:10074 5580:25215 Suppress_to_Peers Originator: ear1.Atlanta2 5580 39138 22351 23456 51040 AS-path translation: { ATRATO-IP OPENAP-WIRELESS-NETWORKS-AS INTELSAT AS23456 PIRATE-AS } ear1.Atlanta2 (metric 20000) Origin IGP, metric 0, localpref 100, valid, internal Community: North_America Lclprf_100 Level3_Customer United_States Atlanta Level3:10074 5580:25215 Suppress_to_Peers Originator: ear1.Atlanta2 On Nov 26, 2014, at 7:32 PM, Eric Tykwinski wrote: > Courtney, > > No offense, and I can’t really verify Comcast’s network. But Verizon peers with the same ASNs I do 3356 and 174 which both have routes to thepiratebay’s prefixes, and I can almost guarantee that Comcast has those routes within your network. What’s up really? Just because TATA is blocking routes shouldn’t effect the whole internet, or this whole thing would have been screwed a long time ago. > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > >> On Nov 26, 2014, at 2:11 PM, courtneysmith at comcast.net wrote: >> >> Only one of their /24's is in TATA's(AS6453) table. >> >> http://bgp.he.net/AS51040#_prefixes >> >> >> http://lg.as6453.net >> >> Router: gin-aeq-tcore1 >> Site: US, Ashburn, AEQ >> Command: show route protocol bgp 194.71.107.0/24 terse exact >> >> >> {master} >> >> >> Router: gin-aeq-tcore1 >> Site: US, Ashburn, AEQ >> Command: show route protocol bgp 194.14.56.0/24 terse exact >> >> >> inet.0: 520187 destinations, 3597636 routes (519993 active, 9 holddown, 1053 hidden) >> Restart Complete >> + = Active Route, - = Last Active, * = Both >> >> A V Destination P Prf Metric 1 Metric 2 Next hop AS path >> * ? 194.14.56.0/24 B 197595 51040 I >> unverified >216.6.87.1 >> ? B 197595 51040 I >> unverified >216.6.87.1 >> ? B 197595 51040 I >> unverified >216.6.87.1 >> ? B 1239 1257 197595 51040 I >> unverified >144.232.7.61 >> >> {master} >> >> >> >> >> >> >> On 11/26/14, 2:01 PM, " eric-list at truenet.com " < eric-list at truenet.com > wrote: >> >> >> Javier, >> >> >> I can't get to www.rrbone.net, an upstream provider to the IP I was given for thepiratebay.se. >> I tested on VZ FiOS and Wireless in Philadelphia area and both die within the VZ network. >> >> >> For Comcast, it looks like the space isn't showing up in the BGP table: >> route-server.newyork.ny.ibone>show ip bgp 194.71.107.27 >> % Network not in table >> >> >> No clue what the cause is, but it bigger than just the PirateBay. >> >> >> Sincerely, >> >> >> Eric Tykwinski >> TrueNet, Inc. >> P: 610-429-8300 >> F: 610-429-3222 >> >> >> >> >> -----Original Message----- >> From: NANOG [ mailto:nanog-bounces at nanog.org ] On Behalf Of Javier J >> Sent: Wednesday, November 26, 2014 1:44 PM >> To: nanog at nanog.org >> Subject: Re: Anyone else having trouble reaching thepiratebay.se? AS39138 >> >> >> I confirmed It is also blocked for Comcast users. Even Comcast business users. This is starting to look like censorship to me. > > Courtney Smith courtneysmith at comcast.net I wanna devise a virus To bring dire straits to your environment Crush your corporations with a mild touch Trash your whole computer system and revert you to papyrus From oz at columbus.rr.com Thu Nov 27 02:18:49 2014 From: oz at columbus.rr.com (oz at columbus.rr.com) Date: Thu, 27 Nov 2014 2:18:49 +0000 Subject: kohls.com issues Message-ID: <20141127021849.809VE.109299.root@dnvrco-web01> Anyone know what’s up ? Looks like they are still working thru issues where I am. Not sure if their domain was hijacked or what exactly. If someone has a list where this is already being discussed id appreciate that info. Thanks, Steve From tony at wicks.co.nz Thu Nov 27 02:24:45 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Thu, 27 Nov 2014 15:24:45 +1300 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: References: <162472710.5673666.1417029063060.JavaMail.zimbra@comcast.net> <5D1C0F5E-DAF6-4F7A-AEBF-EEFEE14EE230@truenet.com> Message-ID: <01a201d009e9$4feb6040$efc220c0$@wicks.co.nz> No problem here in New Zealand tonyw at vrhost1-w> show route 194.71.107.0/24 icore1-w.inet.0: 519451 destinations, 525214 routes (519437 active, 14 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 194.71.107.0/24 *[BGP/170] 10:25:44, MED 0, localpref 90 AS path: 4826 5580 39138 22351 131279 51040 I, validation-state: unverified > to 175.45.102.9 via ae1.526 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Courtney Smith Sent: Thursday, 27 November 2014 3:18 p.m. To: Eric Tykwinski Cc: nanog at nanog.org Subject: Re: Anyone else having trouble reaching thepiratebay.se? AS39138 I just posted TATA as a single example. This route is missing from multiple networks. I could not find the specific /24 on, Sprint(1239) AT&T(7018) and Centurylink either. rviews at route-server.ip.att.net> show route 194.71.107.0/24 rviews at route-server.ip.att.net> From shortdudey123 at gmail.com Thu Nov 27 02:25:41 2014 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 26 Nov 2014 18:25:41 -0800 Subject: kohls.com issues In-Reply-To: <20141127021849.809VE.109299.root@dnvrco-web01> References: <20141127021849.809VE.109299.root@dnvrco-web01> Message-ID: http://www.kohls.com/ comes up for me fine on the west coast. -Grant On Wed, Nov 26, 2014 at 6:18 PM, wrote: > Anyone know what’s up ? > > Looks like they are still working thru issues where I am. > > Not sure if their domain was hijacked or what exactly. > > If someone has a list where this is already being discussed id appreciate > that info. > > Thanks, > Steve > From oz at columbus.rr.com Thu Nov 27 02:44:27 2014 From: oz at columbus.rr.com (oz at columbus.rr.com) Date: Thu, 27 Nov 2014 2:44:27 +0000 Subject: kohls.com issues Message-ID: <20141127024427.7GHCY.109447.root@dnvrco-web01> Thanks - it's good now. Just earlier seemed to be some issues. http://www.isitdownrightnow.com/kohls.com.html Guess it could have been a hosting issue. From: Javier J Date: Wednesday, November 26, 2014 at 9:25 PM To: Steven Parsons Subject: Re: kohls.com issues Works for me on FIOS in the NYC area. On Wed, Nov 26, 2014 at 9:18 PM, wrote: Anyone know what’s up ? Looks like they are still working thru issues where I am. Not sure if their domain was hijacked or what exactly. If someone has a list where this is already being discussed id appreciate that info. Thanks, Steve From contact at winterei.se Thu Nov 27 03:06:25 2014 From: contact at winterei.se (Paul S.) Date: Thu, 27 Nov 2014 12:06:25 +0900 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: <01a201d009e9$4feb6040$efc220c0$@wicks.co.nz> References: <162472710.5673666.1417029063060.JavaMail.zimbra@comcast.net> <5D1C0F5E-DAF6-4F7A-AEBF-EEFEE14EE230@truenet.com> <01a201d009e9$4feb6040$efc220c0$@wicks.co.nz> Message-ID: <54769531.7050601@winterei.se> No problem here in Los Angeles either, but seeing a lone route through Atrato only. flags destination gateway lpref med aspath origin *> 194.71.107.0/24 <> 100 0 3491 5580 39138 22351 2.207 51040 i * 194.71.107.0/24 <> 100 0 174 5580 39138 22351 2.207 51040 i On 11/27/2014 午前 11:24, Tony Wicks wrote: > No problem here in New Zealand > > tonyw at vrhost1-w> show route 194.71.107.0/24 > > icore1-w.inet.0: 519451 destinations, 525214 routes (519437 active, 14 > holddown, 0 hidden) > + = Active Route, - = Last Active, * = Both > > 194.71.107.0/24 *[BGP/170] 10:25:44, MED 0, localpref 90 > AS path: 4826 5580 39138 22351 131279 51040 I, > validation-state: unverified > > to 175.45.102.9 via ae1.526 > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Courtney Smith > Sent: Thursday, 27 November 2014 3:18 p.m. > To: Eric Tykwinski > Cc: nanog at nanog.org > Subject: Re: Anyone else having trouble reaching thepiratebay.se? AS39138 > > I just posted TATA as a single example. This route is missing from multiple > networks. I could not find the specific /24 on, Sprint(1239) AT&T(7018) and > Centurylink either. > > rviews at route-server.ip.att.net> show route 194.71.107.0/24 > > rviews at route-server.ip.att.net> > From javier at advancedmachines.us Thu Nov 27 05:14:50 2014 From: javier at advancedmachines.us (Javier J) Date: Thu, 27 Nov 2014 00:14:50 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: <54769531.7050601@winterei.se> References: <162472710.5673666.1417029063060.JavaMail.zimbra@comcast.net> <5D1C0F5E-DAF6-4F7A-AEBF-EEFEE14EE230@truenet.com> <01a201d009e9$4feb6040$efc220c0$@wicks.co.nz> <54769531.7050601@winterei.se> Message-ID: Paul, I think this is isolated to ISP providers in the US. It seems this is affecting Comcast, ATT U-Verse and Verizon FIOS customers. Here is some interesting info: http://www.reddit.com/r/AskTechnology/comments/2ni118/is_att_uverse_blocking_the_pirate_bay/ On Wed, Nov 26, 2014 at 10:06 PM, Paul S. wrote: > No problem here in Los Angeles either, but seeing a lone route through > Atrato only. > > flags destination gateway lpref med aspath origin > *> 194.71.107.0/24 <> 100 0 3491 5580 39138 22351 2.207 > 51040 i > * 194.71.107.0/24 <> 100 0 174 5580 39138 22351 2.207 > 51040 i > > > > On 11/27/2014 午前 11:24, Tony Wicks wrote: > >> No problem here in New Zealand >> >> tonyw at vrhost1-w> show route 194.71.107.0/24 >> >> icore1-w.inet.0: 519451 destinations, 525214 routes (519437 active, 14 >> holddown, 0 hidden) >> + = Active Route, - = Last Active, * = Both >> >> 194.71.107.0/24 *[BGP/170] 10:25:44, MED 0, localpref 90 >> AS path: 4826 5580 39138 22351 131279 51040 I, >> validation-state: unverified >> > to 175.45.102.9 via ae1.526 >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Courtney Smith >> Sent: Thursday, 27 November 2014 3:18 p.m. >> To: Eric Tykwinski >> Cc: nanog at nanog.org >> Subject: Re: Anyone else having trouble reaching thepiratebay.se? AS39138 >> >> I just posted TATA as a single example. This route is missing from >> multiple >> networks. I could not find the specific /24 on, Sprint(1239) AT&T(7018) >> and >> Centurylink either. >> >> rviews at route-server.ip.att.net> show route 194.71.107.0/24 >> >> rviews at route-server.ip.att.net> >> >> > From courtneysmith at comcast.net Thu Nov 27 05:31:13 2014 From: courtneysmith at comcast.net (Courtney Smith) Date: Thu, 27 Nov 2014 00:31:13 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 Message-ID: From courtneysmith at comcast.net Thu Nov 27 05:45:42 2014 From: courtneysmith at comcast.net (Courtney Smith) Date: Thu, 27 Nov 2014 00:45:42 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 Message-ID: > No problem here in Los Angeles either, but seeing a lone route through Atrato only. > > flags destination          gateway          lpref   med aspath origin > *>    194.71.107.0/24      <>     100     0 3491 5580 39138 22351 2.207 51040 i > *     194.71.107.0/24      <>       100     0 174 5580 39138 22351 2.207 51040 i > > > On 11/27/2014 午前 11:24, Tony Wicks wrote: >> >> No problem here in New Zealand >> >> tonyw at vrhost1-w> show route 194.71.107.0/24 >> >> icore1-w.inet.0: 519451 destinations, 525214 routes (519437 active, 14 >> holddown, 0 hidden) >> + = Active Route, - = Last Active, * = Both >> >> 194.71.107.0/24    *[BGP/170] 10:25:44, MED 0, localpref 90 >>                        AS path: 4826 5580 39138 22351 131279 51040 I, >> validation-state: unverified >>                      > to 175.45.102.9 via ae1.526 >> Hopefully the body cones thru this time.  The issue isn't city or country based.  In my last post I pointed out the do not announce to peers community AS5580 was sending to Cogent, Level3 and who knows who else.   So any ASN that is not a customer of Cogent or Level3 wont learn the 5580 path from them. When I checked a few hours ago, Comcast, Centurylink, AT&T, TATA, and possibly Sprint were not seeing the /24 based on their public looking glasses or route servers.  Have not had time to run bgplay  to see if routeviews data shows how they previously saw the /24 in past 30 days.   Finding the ASN(s) they used to see from would shed light on why they stopped seeing.   Checking bgplay and contacting AS51040 to reach out to their upstreams is my suggestion. From fernando at gont.com.ar Thu Nov 27 07:21:02 2014 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 27 Nov 2014 04:21:02 -0300 Subject: Seeking IPv6 Security Resources In-Reply-To: References: Message-ID: <5476D0DE.4060709@gont.com.ar> Hi, Chris, On 11/25/2014 05:32 PM, Chris Grundemann wrote: > Hail NANOG! > > I am looking for IPv6 security resources to add to: > http://www.internetsociety.org/deploy360/ipv6/security/ This is stuff that I've authored or that I've been involved in: **** Tools **** * (Open Source) IPv6 Security Toolkit: **** Articles **** This site links all the articles that I've written so far: . They tend to cover stuff that I've covered in IETF RFCs, but in a more synthetic and human-readable way. Note while stuffed with some adds (Techtarget has to make money somehow), the full content of the articles is online, without the requirement of creating an account or anything.... just scroll down. **** IETF RFCs & Internet Drafts **** Most of what I've published at the IETF in the last few years is IPv6-securty related. Please check: Of particular interest would be: * draft-ietf-6man-ipv6-address-generation-privacy * draft-ietf-opsec-ipv6-host-scanning * RFC6980 * RFC7112 * RFC7113 * RFC7123 * RFC7217 * RFC7359 **** Presentations (slides & videos) **** * Slides: (More to be uploaded soon... please re-check in a week or so) * Videos: **** On-line communities **** * IPv6 Hackers mailing-list: * IPv6 Hackers web site: This site includes the slideware (and videos) of the first (and so far only) IPv6 hackers meeting in Berlin 2013. Thanks! Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From james at freedomnet.co.nz Thu Nov 27 09:51:59 2014 From: james at freedomnet.co.nz (james jones) Date: Thu, 27 Nov 2014 04:51:59 -0500 Subject: NTT NOC Contact Message-ID: Looking to discuss a routing issue going through NTT's link to JP. From job at instituut.net Thu Nov 27 09:56:14 2014 From: job at instituut.net (Job Snijders) Date: Thu, 27 Nov 2014 10:56:14 +0100 Subject: NTT NOC Contact In-Reply-To: References: Message-ID: <20141127095614.GG1746@Hanna.local> On Thu, Nov 27, 2014 at 04:51:59AM -0500, james jones wrote: > Looking to discuss a routing issue going through NTT's link to JP. Feel free to contact me off-list with the details. Kind regards, Job From james at freedomnet.co.nz Thu Nov 27 09:58:59 2014 From: james at freedomnet.co.nz (james jones) Date: Thu, 27 Nov 2014 04:58:59 -0500 Subject: NTT NOC Contact In-Reply-To: <20141127095614.GG1746@Hanna.local> References: <20141127095614.GG1746@Hanna.local> Message-ID: We are getting a huge amount of traffic loss while sending to JP. I am trying to figure out if the problem is with cogent or NTT. Thoughts? Here is a MTR trace: login02.bal (0.0.0.0) Thu Nov 27 01:58:22 2014 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Last Avg Best Wrst StDev 1. v122-router.bal 0.0% 0.2 0.3 0.2 3.7 0.5 2. netscaler3.bal 0.0% 0.1 0.1 0.1 0.2 0.0 3. gw1.bal.brightcove.com 0.0% 0.6 1.9 0.2 12.4 3.2 4. border1.te9-1.brightcoveinc-2.chg004.pnap.net 2.1% 0.9 2.1 0.4 36.5 6.5 5. core1.te2-2-bbnet2.chg.pnap.net 0.0% 2.1 2.1 1.8 3.5 0.4 6. te0-5-0-33.ccr21.ord03.atlas.cogentco.com 0.0% 1.9 2.5 1.8 16.2 2.5 7. be2003.ccr42.ord01.atlas.cogentco.com 0.0% 2.4 2.5 2.3 3.7 0.3 8. be2157.ccr22.mci01.atlas.cogentco.com 0.0% 14.4 14.3 14.1 17.4 0.5 9. be2133.ccr22.sfo01.atlas.cogentco.com 0.0% 52.0 52.1 51.7 54.0 0.4 10. be2165.ccr22.sjc01.atlas.cogentco.com 23.4% 52.7 52.8 52.6 53.3 0.2 11. be2047.ccr21.sjc03.atlas.cogentco.com 67.4% 53.5 53.5 53.4 53.8 0.1 12. verio.iad01.atlas.cogentco.com 29.8% 53.1 53.2 53.0 54.6 0.4 13. ae-6.r20.snjsca04.us.bb.gin.ntt.net 67.4% 53.3 59.3 53.0 82.3 10.1 14. ae-4.r20.tokyjp05.jp.bb.gin.ntt.net 29.8% 138.2 140.6 138.1 173.9 7.6 15. ae-1.ocn.tokyjp05.jp.bb.gin.ntt.net 69.6% 153.8 153.9 153.8 154.0 0.0 16. 60.37.27.92 97.8% 154.1 154.1 154.1 154.1 0.0 17. 114.147.63.70 36.2% 194.0 167.0 155.0 203.5 16.7 18. 118.23.13.2 63.0% 155.8 155.9 155.8 156.1 0.1 19. 118.23.14.66 100.0 0.0 0.0 0.0 0.0 0.0 20. p3044-ipngnfx01marunouchi.tokyo.ocn.ne.jp 97.8% 150.8 150.8 150.8 150.8 0.0 On Thu, Nov 27, 2014 at 4:56 AM, Job Snijders wrote: > On Thu, Nov 27, 2014 at 04:51:59AM -0500, james jones wrote: > > Looking to discuss a routing issue going through NTT's link to JP. > > Feel free to contact me off-list with the details. > > Kind regards, > > Job > From javier at advancedmachines.us Thu Nov 27 14:47:04 2014 From: javier at advancedmachines.us (Javier J) Date: Thu, 27 Nov 2014 09:47:04 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: <20141127054551.4BFCF2C0054@mail.nanog.org> References: <20141127054551.4BFCF2C0054@mail.nanog.org> Message-ID: Looks like its working now (on FIOS anyway) Curious to know why the major networks stopped seeing it yesterday as well. On Thu, Nov 27, 2014 at 12:45 AM, Courtney Smith wrote: > > > No problem here in Los Angeles either, but seeing a lone route through > Atrato only. > > > > flags destination gateway lpref med aspath origin > > *> 194.71.107.0/24 <> 100 0 3491 5580 39138 22351 2.207 > 51040 i > > * 194.71.107.0/24 <> 100 0 174 5580 39138 22351 > 2.207 51040 i > > > > > > On 11/27/2014 午前 11:24, Tony Wicks wrote: > >> > >> No problem here in New Zealand > >> > >> tonyw at vrhost1-w> show route 194.71.107.0/24 > >> > >> icore1-w.inet.0: 519451 destinations, 525214 routes (519437 active, 14 > >> holddown, 0 hidden) > >> + = Active Route, - = Last Active, * = Both > >> > >> 194.71.107.0/24 *[BGP/170] 10:25:44, MED 0, localpref 90 > >> AS path: 4826 5580 39138 22351 131279 51040 I, > >> validation-state: unverified > >> > to 175.45.102.9 via ae1.526 > >> > > Hopefully the body cones thru this time. The issue isn't city or country > based. In my last post I pointed out the do not announce to peers > community AS5580 was sending to Cogent, Level3 and who knows who else. So > any ASN that is not a customer of Cogent or Level3 wont learn the 5580 path > from them. > > When I checked a few hours ago, Comcast, Centurylink, AT&T, TATA, and > possibly Sprint were not seeing the /24 based on their public looking > glasses or route servers. Have not had time to run bgplay to see if > routeviews data shows how they previously saw the /24 in past 30 days. > Finding the ASN(s) they used to see from would shed light on why they > stopped seeing. Checking bgplay and contacting AS51040 to reach out to > their upstreams is my suggestion. From jared at puck.Nether.net Thu Nov 27 16:00:32 2014 From: jared at puck.Nether.net (Jared Mauch) Date: Thu, 27 Nov 2014 11:00:32 -0500 Subject: Cogent (was Re: NTT NOC Contact) In-Reply-To: References: <20141127095614.GG1746@Hanna.local> Message-ID: <20141127160032.GB16527@puck.nether.net> Seems your MTR sees loss within the Cogent (174) network prior to reaching the NTT network. I think you perhaps need cogent assistance? - Jared On Thu, Nov 27, 2014 at 04:58:59AM -0500, james jones wrote: > We are getting a huge amount of traffic loss while sending to JP. I am > trying to figure out if the problem is with cogent or NTT. Thoughts? Here > is a MTR trace: > > login02.bal (0.0.0.0) > Thu Nov 27 01:58:22 2014 > > Keys: Help Display mode Restart statistics Order of fields quit > > > Packets Pings > > Host > Loss% Last Avg Best Wrst StDev > > 1. v122-router.bal > 0.0% 0.2 0.3 0.2 3.7 0.5 > > 2. netscaler3.bal > 0.0% 0.1 0.1 0.1 0.2 0.0 > > 3. gw1.bal.brightcove.com > 0.0% 0.6 1.9 0.2 12.4 3.2 > > 4. border1.te9-1.brightcoveinc-2.chg004.pnap.net > 2.1% 0.9 2.1 0.4 36.5 6.5 > > 5. core1.te2-2-bbnet2.chg.pnap.net > 0.0% 2.1 2.1 1.8 3.5 0.4 > > 6. te0-5-0-33.ccr21.ord03.atlas.cogentco.com > 0.0% 1.9 2.5 1.8 16.2 2.5 > > 7. be2003.ccr42.ord01.atlas.cogentco.com > 0.0% 2.4 2.5 2.3 3.7 0.3 > > 8. be2157.ccr22.mci01.atlas.cogentco.com > 0.0% 14.4 14.3 14.1 17.4 0.5 > > 9. be2133.ccr22.sfo01.atlas.cogentco.com > 0.0% 52.0 52.1 51.7 54.0 0.4 > > 10. be2165.ccr22.sjc01.atlas.cogentco.com > 23.4% 52.7 52.8 52.6 53.3 0.2 > > 11. be2047.ccr21.sjc03.atlas.cogentco.com > 67.4% 53.5 53.5 53.4 53.8 0.1 > > 12. verio.iad01.atlas.cogentco.com > 29.8% 53.1 53.2 53.0 54.6 0.4 > > 13. ae-6.r20.snjsca04.us.bb.gin.ntt.net > 67.4% 53.3 59.3 53.0 82.3 10.1 > > 14. ae-4.r20.tokyjp05.jp.bb.gin.ntt.net > 29.8% 138.2 140.6 138.1 173.9 7.6 > > 15. ae-1.ocn.tokyjp05.jp.bb.gin.ntt.net > 69.6% 153.8 153.9 153.8 154.0 0.0 > > 16. 60.37.27.92 > 97.8% 154.1 154.1 154.1 154.1 0.0 > > 17. 114.147.63.70 > 36.2% 194.0 167.0 155.0 203.5 16.7 > > 18. 118.23.13.2 > 63.0% 155.8 155.9 155.8 156.1 0.1 > > 19. 118.23.14.66 > 100.0 0.0 0.0 0.0 0.0 0.0 > > 20. p3044-ipngnfx01marunouchi.tokyo.ocn.ne.jp > 97.8% 150.8 150.8 150.8 150.8 0.0 > > > > > > > On Thu, Nov 27, 2014 at 4:56 AM, Job Snijders wrote: > > > On Thu, Nov 27, 2014 at 04:51:59AM -0500, james jones wrote: > > > Looking to discuss a routing issue going through NTT's link to JP. > > > > Feel free to contact me off-list with the details. > > > > Kind regards, > > > > Job > > -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From job at instituut.net Thu Nov 27 16:11:00 2014 From: job at instituut.net (Job Snijders) Date: Thu, 27 Nov 2014 17:11:00 +0100 Subject: Cogent (was Re: NTT NOC Contact) In-Reply-To: <20141127160032.GB16527@puck.nether.net> References: <20141127095614.GG1746@Hanna.local> <20141127160032.GB16527@puck.nether.net> Message-ID: <20141127161100.GO1746@Hanna.local> On Thu, Nov 27, 2014 at 11:00:32AM -0500, Jared Mauch wrote: > Seems your MTR sees loss within the Cogent (174) network prior > to reaching the NTT network. > > I think you perhaps need cogent assistance? This was resolved off-list. James is now engaging with his supplier. For future reference: When assistance is needed from NTT, please reach out directly to noc at ntt.net. That mailbox is guarded 24/7 by good people. Kind regards, Job From math at sizone.org Thu Nov 27 16:39:07 2014 From: math at sizone.org (Ken Chase) Date: Thu, 27 Nov 2014 11:39:07 -0500 Subject: bidirectional traceroute (was Re: Cogent (was Re: NTT NOC Contact)) In-Reply-To: <20141127160032.GB16527@puck.nether.net> References: <20141127095614.GG1746@Hanna.local> <20141127160032.GB16527@puck.nether.net> Message-ID: <20141127163906.GU25218@sizone.org> Never assume symetric routing (though Im almost old enough to remember the days of.) Wish there was some kinda bidirect traceroute protocol widely supported. Mostly we only have lg's via www if they happen to have been setup for such occasions :( I know there were a few small projects with this kinda idea, but I am not sure if any of them really got anywhere. /kc On Thu, Nov 27, 2014 at 11:00:32AM -0500, Jared Mauch said: > Seems your MTR sees loss within the Cogent (174) network prior >to reaching the NTT network. > > I think you perhaps need cogent assistance? > > - Jared > > >On Thu, Nov 27, 2014 at 04:58:59AM -0500, james jones wrote: >> We are getting a huge amount of traffic loss while sending to JP. I am >> trying to figure out if the problem is with cogent or NTT. Thoughts? Here >> is a MTR trace: >> >> login02.bal (0.0.0.0) >> Thu Nov 27 01:58:22 2014 >> >> Keys: Help Display mode Restart statistics Order of fields quit >> >> >> Packets Pings >> >> Host >> Loss% Last Avg Best Wrst StDev >> >> 1. v122-router.bal >> 0.0% 0.2 0.3 0.2 3.7 0.5 >> >> 2. netscaler3.bal >> 0.0% 0.1 0.1 0.1 0.2 0.0 >> >> 3. gw1.bal.brightcove.com >> 0.0% 0.6 1.9 0.2 12.4 3.2 >> >> 4. border1.te9-1.brightcoveinc-2.chg004.pnap.net >> 2.1% 0.9 2.1 0.4 36.5 6.5 >> >> 5. core1.te2-2-bbnet2.chg.pnap.net >> 0.0% 2.1 2.1 1.8 3.5 0.4 >> >> 6. te0-5-0-33.ccr21.ord03.atlas.cogentco.com >> 0.0% 1.9 2.5 1.8 16.2 2.5 >> >> 7. be2003.ccr42.ord01.atlas.cogentco.com >> 0.0% 2.4 2.5 2.3 3.7 0.3 >> >> 8. be2157.ccr22.mci01.atlas.cogentco.com >> 0.0% 14.4 14.3 14.1 17.4 0.5 >> >> 9. be2133.ccr22.sfo01.atlas.cogentco.com >> 0.0% 52.0 52.1 51.7 54.0 0.4 >> >> 10. be2165.ccr22.sjc01.atlas.cogentco.com >> 23.4% 52.7 52.8 52.6 53.3 0.2 >> >> 11. be2047.ccr21.sjc03.atlas.cogentco.com >> 67.4% 53.5 53.5 53.4 53.8 0.1 >> >> 12. verio.iad01.atlas.cogentco.com >> 29.8% 53.1 53.2 53.0 54.6 0.4 >> >> 13. ae-6.r20.snjsca04.us.bb.gin.ntt.net >> 67.4% 53.3 59.3 53.0 82.3 10.1 >> >> 14. ae-4.r20.tokyjp05.jp.bb.gin.ntt.net >> 29.8% 138.2 140.6 138.1 173.9 7.6 >> >> 15. ae-1.ocn.tokyjp05.jp.bb.gin.ntt.net >> 69.6% 153.8 153.9 153.8 154.0 0.0 >> >> 16. 60.37.27.92 >> 97.8% 154.1 154.1 154.1 154.1 0.0 >> >> 17. 114.147.63.70 >> 36.2% 194.0 167.0 155.0 203.5 16.7 >> >> 18. 118.23.13.2 >> 63.0% 155.8 155.9 155.8 156.1 0.1 >> >> 19. 118.23.14.66 >> 100.0 0.0 0.0 0.0 0.0 0.0 >> >> 20. p3044-ipngnfx01marunouchi.tokyo.ocn.ne.jp >> 97.8% 150.8 150.8 150.8 150.8 0.0 >> >> >> >> >> >> >> On Thu, Nov 27, 2014 at 4:56 AM, Job Snijders wrote: >> >> > On Thu, Nov 27, 2014 at 04:51:59AM -0500, james jones wrote: >> > > Looking to discuss a routing issue going through NTT's link to JP. >> > >> > Feel free to contact me off-list with the details. >> > >> > Kind regards, >> > >> > Job >> > > >-- >Jared Mauch | pgp key available via finger from jared at puck.nether.net >clue++; | http://puck.nether.net/~jared/ My statements are only mine. -- Ken Chase - math at sizone.org Toronto From bedard.phil at gmail.com Thu Nov 27 19:06:52 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Thu, 27 Nov 2014 14:06:52 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: References: <20141127054551.4BFCF2C0054@mail.nanog.org> Message-ID: <7999F719-4469-463F-8E7D-A016CCA408B6@gmail.com> In the post you quoted it says: "In my last post I pointed out the do not announce to peers community AS5580 was sending to Cogent, Level3 and who knows who else. So any ASN that is not a customer of Cogent or Level3 wont learn the 5580 path from them." Verizon, ATT, and the rest of those networks are Tier-1 networks meaning if 5580 was tagging the route with do-not-advertise to their transit providers (Level3 & Cogent) the other Tier-1s wouldn't have another route to it. Looking at routing updates there were a lot of them yesterday for that prefix, for whatever reason. The lack of reachability was completely due to Atrato, had nothing to do with the ISPs in the US. It was reachable for me yesterday on our network, but we peer directly with Atrato. It's possible they did it to stop a DDoS, some other kind of attack, or any number of reasons. Phil On 11/27/14, 2:47 PM, "Javier J" wrote: >Looks like its working now (on FIOS anyway) > >Curious to know why the major networks stopped seeing it yesterday as >well. > >On Thu, Nov 27, 2014 at 12:45 AM, Courtney Smith > >wrote: > >> >> > No problem here in Los Angeles either, but seeing a lone route through >> Atrato only. >> > >> > flags destination gateway lpref med aspath origin >> > *> 194.71.107.0/24 <> 100 0 3491 5580 39138 22351 >>2.207 >> 51040 i >> > * 194.71.107.0/24 <> 100 0 174 5580 39138 22351 >> 2.207 51040 i >> > >> > >> > On 11/27/2014 午前 11:24, Tony Wicks wrote: >> >> >> >> No problem here in New Zealand >> >> >> >> tonyw at vrhost1-w> show route 194.71.107.0/24 >> >> >> >> icore1-w.inet.0: 519451 destinations, 525214 routes (519437 active, >>14 >> >> holddown, 0 hidden) >> >> + = Active Route, - = Last Active, * = Both >> >> >> >> 194.71.107.0/24 *[BGP/170] 10:25:44, MED 0, localpref 90 >> >> AS path: 4826 5580 39138 22351 131279 51040 I, >> >> validation-state: unverified >> >> > to 175.45.102.9 via ae1.526 >> >> >> >> Hopefully the body cones thru this time. The issue isn't city or >>country >> based. In my last post I pointed out the do not announce to peers >> community AS5580 was sending to Cogent, Level3 and who knows who else. >> So >> any ASN that is not a customer of Cogent or Level3 wont learn the 5580 >>path >> from them. >> >> When I checked a few hours ago, Comcast, Centurylink, AT&T, TATA, and >> possibly Sprint were not seeing the /24 based on their public looking >> glasses or route servers. Have not had time to run bgplay to see if >> routeviews data shows how they previously saw the /24 in past 30 days. >> Finding the ASN(s) they used to see from would shed light on why they >> stopped seeing. Checking bgplay and contacting AS51040 to reach out to >> their upstreams is my suggestion. From javier at advancedmachines.us Thu Nov 27 19:16:12 2014 From: javier at advancedmachines.us (Javier J) Date: Thu, 27 Nov 2014 14:16:12 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: <7999F719-4469-463F-8E7D-A016CCA408B6@gmail.com> References: <20141127054551.4BFCF2C0054@mail.nanog.org> <7999F719-4469-463F-8E7D-A016CCA408B6@gmail.com> Message-ID: It was working for me a few hours ago, and now dead at hop 3 on FIOS again. If they have 2 prefixes being advertised from AS51040 http://bgp.he.net/AS51040#_prefixes Why can I traceroute to 1 but not the other? [root at tor-proxy network-scripts]# mtr --report -c 5 194.14.56.1 HOST: tor-proxy.home Loss% Snt Last Avg Best Wrst StDev 1. pfsense.home 0.0% 5 0.5 1.0 0.4 2.7 1.0 2. L100.NWRKNJ-VFTTP-134.verizo 0.0% 5 1.3 6.0 1.3 20.6 8.3 3. G0-5-3-4.NWRKNJ-LCR-22.veriz 0.0% 5 3.2 4.6 3.2 6.7 1.4 4. ae0-0.NWRK-BB-RTR2.verizon-g 0.0% 5 5.9 8.4 4.9 20.7 6.8 5. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 6. 0.ae2.BR3.NYC4.ALTER.NET 0.0% 5 6.8 6.7 6.6 6.9 0.1 7. 204.255.169.234 0.0% 5 5.4 5.7 5.2 7.1 0.8 8. ae-2.r23.nycmny01.us.bb.gin. 0.0% 5 6.2 7.1 5.9 11.0 2.2 9. ae-6.r21.frnkge03.de.bb.gin. 60.0% 5 94.5 92.6 90.7 94.5 2.7 10. ae-1.r02.frnkge03.de.bb.gin. 0.0% 5 95.2 94.3 93.1 95.6 1.1 11. 213.198.77.214 0.0% 5 92.7 93.4 92.7 94.1 0.5 12. et030-4.RT.TC1.STO.SE.retn.n 0.0% 5 109.2 109.4 109.0 110.9 0.8 13. GW-ObeNetwork.retn.net 0.0% 5 116.0 190.0 111.1 341.8 100.4 14. moria-cr-3.piratpartiet.se 20.0% 5 110.1 111.6 109.9 116.1 2.9 [root at tor-proxy network-scripts]# mtr --report -c 5 194.71.107.27 HOST: tor-proxy.home Loss% Snt Last Avg Best Wrst StDev 1. pfsense.home 0.0% 5 0.6 0.4 0.3 0.6 0.1 2. L100.NWRKNJ-VFTTP-134.verizo 0.0% 5 1.4 7.1 1.4 29.1 12.3 3. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 The site works 100 % fine over vpn or proxy. So I don't think this is related to any DDOS attack. On Thu, Nov 27, 2014 at 2:06 PM, Phil Bedard wrote: > In the post you quoted it says: > > "In my last post I pointed out the do not announce to peers > community AS5580 was sending to Cogent, Level3 and who knows who else. So > any ASN that is not a customer of Cogent or Level3 wont learn the 5580 path > from them." > > Verizon, ATT, and the rest of those networks are Tier-1 networks meaning > if 5580 was tagging the route with do-not-advertise to their transit > providers (Level3 & Cogent) the other Tier-1s wouldn't have another route > to it. Looking at routing updates there were a lot of them yesterday for > that prefix, for whatever reason. The lack of reachability was completely > due to Atrato, had nothing to do with the ISPs in the US. > > It was reachable for me yesterday on our network, but we peer directly > with Atrato. > > It's possible they did it to stop a DDoS, some other kind of attack, or > any number of reasons. > > Phil > > > > > > > On 11/27/14, 2:47 PM, "Javier J" wrote: > > >Looks like its working now (on FIOS anyway) > > > >Curious to know why the major networks stopped seeing it yesterday as > >well. > > > >On Thu, Nov 27, 2014 at 12:45 AM, Courtney Smith > > > >wrote: > > > >> > >> > No problem here in Los Angeles either, but seeing a lone route through > >> Atrato only. > >> > > >> > flags destination gateway lpref med aspath origin > >> > *> 194.71.107.0/24 <> 100 0 3491 5580 39138 22351 > >>2.207 > >> 51040 i > >> > * 194.71.107.0/24 <> 100 0 174 5580 39138 22351 > >> 2.207 51040 i > >> > > >> > > >> > On 11/27/2014 午前 11:24, Tony Wicks wrote: > >> >> > >> >> No problem here in New Zealand > >> >> > >> >> tonyw at vrhost1-w> show route 194.71.107.0/24 > >> >> > >> >> icore1-w.inet.0: 519451 destinations, 525214 routes (519437 active, > >>14 > >> >> holddown, 0 hidden) > >> >> + = Active Route, - = Last Active, * = Both > >> >> > >> >> 194.71.107.0/24 *[BGP/170] 10:25:44, MED 0, localpref 90 > >> >> AS path: 4826 5580 39138 22351 131279 51040 I, > >> >> validation-state: unverified > >> >> > to 175.45.102.9 via ae1.526 > >> >> > >> > >> Hopefully the body cones thru this time. The issue isn't city or > >>country > >> based. In my last post I pointed out the do not announce to peers > >> community AS5580 was sending to Cogent, Level3 and who knows who else. > >> So > >> any ASN that is not a customer of Cogent or Level3 wont learn the 5580 > >>path > >> from them. > >> > >> When I checked a few hours ago, Comcast, Centurylink, AT&T, TATA, and > >> possibly Sprint were not seeing the /24 based on their public looking > >> glasses or route servers. Have not had time to run bgplay to see if > >> routeviews data shows how they previously saw the /24 in past 30 days. > >> Finding the ASN(s) they used to see from would shed light on why they > >> stopped seeing. Checking bgplay and contacting AS51040 to reach out to > >> their upstreams is my suggestion. > > From sean at rentul.net Thu Nov 27 19:30:49 2014 From: sean at rentul.net (Sean Lutner) Date: Thu, 27 Nov 2014 14:30:49 -0500 Subject: MediaTemple/GoDaddy contact? Message-ID: Anyone from media temple/godaddy around? I have a site hosted in mediatemple that a customer can't reach and normal support has been not helpful thus far. Off-list is fine, much appreciated. -- Sean From joelja at bogus.com Thu Nov 27 19:54:15 2014 From: joelja at bogus.com (joel jaeggli) Date: Thu, 27 Nov 2014 11:54:15 -0800 Subject: Transparent hijacking of SMTP submission... Message-ID: <54778167.7080808@bogus.com> I don't see this in my home market, but I do see it in someone else's... I kind of expect this for port 25 but... J at mb-aye:~$telnet 147.28.0.81 587 Trying 147.28.0.81... Connected to nagasaki.bogus.com. Escape character is '^]'. 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 19:17:44 GMT ehlo bogus.com 250-nagasaki.bogus.com Hello XXXXXXXXXXXXXXX.wa.comcast.net [XXX.XXX.XXX.XXX], pleased to meet you 250 ENHANCEDSTATUSCODES J at mb-aye:~$telnet 2001:418:1::81 587 Trying 2001:418:1::81... Connected to nagasaki.bogus.com. Escape character is '^]'. 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 19:18:33 GMT ehlo bogus.com 250-nagasaki.bogus.com Hello [IPv6:2601:7:2380:XXXX:XXXX:XXXX:c1ae:7d73], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN 250-STARTTLS 250-DELIVERBY 250 HELP that's essentially a downgrade attack on my ability to use encryption which seems to be in pretty poor taste frankly. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From bedard.phil at gmail.com Thu Nov 27 20:30:46 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Thu, 27 Nov 2014 15:30:46 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: References: <20141127054551.4BFCF2C0054@mail.nanog.org> <7999F719-4469-463F-8E7D-A016CCA408B6@gmail.com> Message-ID: <26E6ACB4-BFA1-4949-8CA4-66D83F9E9A27@gmail.com> It looks like they use different upstream providers for each prefix, probably hosted in different locations. The 194.71.107.0/24 prefix on my network was withdrawn by Ataro, and is now reachable via this path: 194.71.107.0/24 *[BGP/170] 00:04:34 AS path: 3356 3320 3320 24961 24961 24961 24961 39138 22351 131279 51040 I, validation-state: unverified The 4 minutes isn't really a good thing. This is the other prefix, via RETN who we also peer with. 194.14.56.0/24 *[BGP/170] 1d 07:15:42, MED 0 AS path: 9002 197595 51040 I AS 24961 is myLoc.de who could be their hosting provider and may have had issues with Atrato, who is now Hibernia. Who knows it looks like normal BGP/Internet issues to me, if you are looking for some kind of conspiracy nothing is going on. Phil From: Javier J Date: Thursday, November 27, 2014 at 2:16 PM To: Phil B Cc: Courtney Smith , "nanog at nanog.org" Subject: Re: Anyone else having trouble reaching thepiratebay.se? AS39138 It was working for me a few hours ago, and now dead at hop 3 on FIOS again. If they have 2 prefixes being advertised from AS51040 http://bgp.he.net/AS51040#_prefixes Why can I traceroute to 1 but not the other? [root at tor-proxy network-scripts]# mtr --report -c 5 194.14.56.1 HOST: tor-proxy.home Loss% Snt Last Avg Best Wrst StDev 1. pfsense.home 0.0% 5 0.5 1.0 0.4 2.7 1.0 2. L100.NWRKNJ-VFTTP-134.verizo 0.0% 5 1.3 6.0 1.3 20.6 8.3 3. G0-5-3-4.NWRKNJ-LCR-22.veriz 0.0% 5 3.2 4.6 3.2 6.7 1.4 4. ae0-0.NWRK-BB-RTR2.verizon-g 0.0% 5 5.9 8.4 4.9 20.7 6.8 5. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 6. 0.ae2.BR3.NYC4.ALTER.NET 0.0% 5 6.8 6.7 6.6 6.9 0.1 7. 204.255.169.234 0.0% 5 5.4 5.7 5.2 7.1 0.8 8. ae-2.r23.nycmny01.us.bb.gin. 0.0% 5 6.2 7.1 5.9 11.0 2.2 9. ae-6.r21.frnkge03.de.bb.gin. 60.0% 5 94.5 92.6 90.7 94.5 2.7 10. ae-1.r02.frnkge03.de.bb.gin. 0.0% 5 95.2 94.3 93.1 95.6 1.1 11. 213.198.77.214 0.0% 5 92.7 93.4 92.7 94.1 0.5 12. et030-4.RT.TC1.STO.SE.retn.n 0.0% 5 109.2 109.4 109.0 110.9 0.8 13. GW-ObeNetwork.retn.net 0.0% 5 116.0 190.0 111.1 341.8 100.4 14. moria-cr-3.piratpartiet.se 20.0% 5 110.1 111.6 109.9 116.1 2.9 [root at tor-proxy network-scripts]# mtr --report -c 5 194.71.107.27 HOST: tor-proxy.home Loss% Snt Last Avg Best Wrst StDev 1. pfsense.home 0.0% 5 0.6 0.4 0.3 0.6 0.1 2. L100.NWRKNJ-VFTTP-134.verizo 0.0% 5 1.4 7.1 1.4 29.1 12.3 3. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 The site works 100 % fine over vpn or proxy. So I don't think this is related to any DDOS attack. On Thu, Nov 27, 2014 at 2:06 PM, Phil Bedard wrote: In the post you quoted it says: "In my last post I pointed out the do not announce to peers community AS5580 was sending to Cogent, Level3 and who knows who else. So any ASN that is not a customer of Cogent or Level3 wont learn the 5580 path from them." Verizon, ATT, and the rest of those networks are Tier-1 networks meaning if 5580 was tagging the route with do-not-advertise to their transit providers (Level3 & Cogent) the other Tier-1s wouldn't have another route to it. Looking at routing updates there were a lot of them yesterday for that prefix, for whatever reason. The lack of reachability was completely due to Atrato, had nothing to do with the ISPs in the US. It was reachable for me yesterday on our network, but we peer directly with Atrato. It's possible they did it to stop a DDoS, some other kind of attack, or any number of reasons. Phil On 11/27/14, 2:47 PM, "Javier J" wrote: >Looks like its working now (on FIOS anyway) > >Curious to know why the major networks stopped seeing it yesterday as >well. > >On Thu, Nov 27, 2014 at 12:45 AM, Courtney Smith > >wrote: > >> >> > No problem here in Los Angeles either, but seeing a lone route through >> Atrato only. >> > >> > flags destination gateway lpref med aspath origin >> > *> 194.71.107.0/24 <> 100 0 3491 5580 39138 22351 >>2.207 >> 51040 i >> > * 194.71.107.0/24 <> 100 0 174 5580 39138 22351 >> 2.207 51040 i >> > >> > >> > On 11/27/2014 午前 11:24, Tony Wicks wrote: >> >> >> >> No problem here in New Zealand >> >> >> >> tonyw at vrhost1-w> show route 194.71.107.0/24 >> >> >> >> icore1-w.inet.0: 519451 destinations, 525214 routes (519437 active, >>14 >> >> holddown, 0 hidden) >> >> + = Active Route, - = Last Active, * = Both >> >> >> >> 194.71.107.0/24 *[BGP/170] 10:25:44, MED 0, localpref 90 >> >> AS path: 4826 5580 39138 22351 131279 51040 I, >> >> validation-state: unverified >> >> > to 175.45.102.9 via ae1.526 >> >> >> >> Hopefully the body cones thru this time. The issue isn't city or >>country >> based. In my last post I pointed out the do not announce to peers >> community AS5580 was sending to Cogent, Level3 and who knows who else. >> So >> any ASN that is not a customer of Cogent or Level3 wont learn the 5580 >>path >> from them. >> >> When I checked a few hours ago, Comcast, Centurylink, AT&T, TATA, and >> possibly Sprint were not seeing the /24 based on their public looking >> glasses or route servers. Have not had time to run bgplay to see if >> routeviews data shows how they previously saw the /24 in past 30 days. >> Finding the ASN(s) they used to see from would shed light on why they >> stopped seeing. Checking bgplay and contacting AS51040 to reach out to >> their upstreams is my suggestion. From marka at isc.org Thu Nov 27 20:38:38 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 28 Nov 2014 07:38:38 +1100 Subject: Transparent hijacking of SMTP submission... In-Reply-To: Your message of "Thu, 27 Nov 2014 11:54:15 -0800." <54778167.7080808@bogus.com> References: <54778167.7080808@bogus.com> Message-ID: <20141127203838.0F02724729DB@rock.dv.isc.org> Which is why your MTA should always be setup to require the use of STARTTLS. Additionally the CERT presented should also match the name of the server. There is absolutely no reason for a ISP / hotspot to inspect submission traffic. The "stopping spam" argument doesn't wash with submission. Mark In message <54778167.7080808 at bogus.com>, joel jaeggli writes: > > I don't see this in my home market, but I do see it in someone else's... > I kind of expect this for port 25 but... > > J at mb-aye:~$telnet 147.28.0.81 587 > Trying 147.28.0.81... > Connected to nagasaki.bogus.com. > Escape character is '^]'. > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 > 19:17:44 GMT > ehlo bogus.com > 250-nagasaki.bogus.com Hello XXXXXXXXXXXXXXX.wa.comcast.net > [XXX.XXX.XXX.XXX], pleased to meet you > 250 ENHANCEDSTATUSCODES > > J at mb-aye:~$telnet 2001:418:1::81 587 > Trying 2001:418:1::81... > Connected to nagasaki.bogus.com. > Escape character is '^]'. > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 > 19:18:33 GMT > ehlo bogus.com > 250-nagasaki.bogus.com Hello > [IPv6:2601:7:2380:XXXX:XXXX:XXXX:c1ae:7d73], pleased to meet you > 250-ENHANCEDSTATUSCODES > 250-PIPELINING > 250-8BITMIME > 250-SIZE > 250-DSN > 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN > 250-STARTTLS > 250-DELIVERBY > 250 HELP > > that's essentially a downgrade attack on my ability to use encryption > which seems to be in pretty poor taste frankly. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ops.lists at gmail.com Fri Nov 28 00:10:03 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 28 Nov 2014 05:40:03 +0530 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <20141127203838.0F02724729DB@rock.dv.isc.org> References: <54778167.7080808@bogus.com> <20141127203838.0F02724729DB@rock.dv.isc.org> Message-ID: Yes. Till that hotspots IP space gets blackholed by a major freemail because of all the nigerians and hijacked devices emitting bot traffic through stolen auth credentials. There's other ways to stop this but they take actual hard work and rather more gear than a rusted up old asa you pull out of your closet as like as not. On Nov 28, 2014 2:10 AM, "Mark Andrews" wrote: > > Which is why your MTA should always be setup to require the use of > STARTTLS. Additionally the CERT presented should also match the > name of the server. > > There is absolutely no reason for a ISP / hotspot to inspect > submission traffic. The "stopping spam" argument doesn't wash with > submission. > > Mark > > In message <54778167.7080808 at bogus.com>, joel jaeggli writes: > > > > I don't see this in my home market, but I do see it in someone else's... > > I kind of expect this for port 25 but... > > > > J at mb-aye:~$telnet 147.28.0.81 587 > > Trying 147.28.0.81... > > Connected to nagasaki.bogus.com. > > Escape character is '^]'. > > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 > > 19:17:44 GMT > > ehlo bogus.com > > 250-nagasaki.bogus.com Hello XXXXXXXXXXXXXXX.wa.comcast.net > > [XXX.XXX.XXX.XXX], pleased to meet you > > 250 ENHANCEDSTATUSCODES > > > > J at mb-aye:~$telnet 2001:418:1::81 587 > > Trying 2001:418:1::81... > > Connected to nagasaki.bogus.com. > > Escape character is '^]'. > > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 > > 19:18:33 GMT > > ehlo bogus.com > > 250-nagasaki.bogus.com Hello > > [IPv6:2601:7:2380:XXXX:XXXX:XXXX:c1ae:7d73], pleased to meet you > > 250-ENHANCEDSTATUSCODES > > 250-PIPELINING > > 250-8BITMIME > > 250-SIZE > > 250-DSN > > 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN > > 250-STARTTLS > > 250-DELIVERBY > > 250 HELP > > > > that's essentially a downgrade attack on my ability to use encryption > > which seems to be in pretty poor taste frankly. > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From marka at isc.org Fri Nov 28 00:38:24 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 28 Nov 2014 11:38:24 +1100 Subject: Transparent hijacking of SMTP submission... In-Reply-To: Your message of "Fri, 28 Nov 2014 05:40:03 +0530." References: <54778167.7080808@bogus.com> <20141127203838.0F02724729DB@rock.dv.isc.org> Message-ID: <20141128003824.8D49924783E0@rock.dv.isc.org> In message , Suresh Ramasubramanian writes: > > Yes. Till that hotspots IP space gets blackholed by a major freemail > because of all the nigerians and hijacked devices emitting bot traffic > through stolen auth credentials. Why would it black hole the address rather than the block the compromised credentials? The whole point of submission is to authenticate the submitter and to be able to trace spam back to the submitter and deal with the issue at that level of granuality. Blocking at that level also stop the credentials being used from anywhere. scalpel vs chainsaw. Just because you provide free email doesn't give you the right to not do the service properly. You encouraged people to use your service. You should resource it to deal with the resulting load and that includes dealing with spam and scans being sent with stolen credentials. As a free email provider you have the plain text. Mark > There's other ways to stop this but they take actual hard work and rather > more gear than a rusted up old asa you pull out of your closet as like as > not. > On Nov 28, 2014 2:10 AM, "Mark Andrews" wrote: > > > > > Which is why your MTA should always be setup to require the use of > > STARTTLS. Additionally the CERT presented should also match the > > name of the server. > > > > There is absolutely no reason for a ISP / hotspot to inspect > > submission traffic. The "stopping spam" argument doesn't wash with > > submission. > > > > Mark > > > > In message <54778167.7080808 at bogus.com>, joel jaeggli writes: > > > > > > I don't see this in my home market, but I do see it in someone else's... > > > I kind of expect this for port 25 but... > > > > > > J at mb-aye:~$telnet 147.28.0.81 587 > > > Trying 147.28.0.81... > > > Connected to nagasaki.bogus.com. > > > Escape character is '^]'. > > > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 > > > 19:17:44 GMT > > > ehlo bogus.com > > > 250-nagasaki.bogus.com Hello XXXXXXXXXXXXXXX.wa.comcast.net > > > [XXX.XXX.XXX.XXX], pleased to meet you > > > 250 ENHANCEDSTATUSCODES > > > > > > J at mb-aye:~$telnet 2001:418:1::81 587 > > > Trying 2001:418:1::81... > > > Connected to nagasaki.bogus.com. > > > Escape character is '^]'. > > > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 > > > 19:18:33 GMT > > > ehlo bogus.com > > > 250-nagasaki.bogus.com Hello > > > [IPv6:2601:7:2380:XXXX:XXXX:XXXX:c1ae:7d73], pleased to meet you > > > 250-ENHANCEDSTATUSCODES > > > 250-PIPELINING > > > 250-8BITMIME > > > 250-SIZE > > > 250-DSN > > > 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN > > > 250-STARTTLS > > > 250-DELIVERBY > > > 250 HELP > > > > > > that's essentially a downgrade attack on my ability to use encryption > > > which seems to be in pretty poor taste frankly. > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > --bcaec517c6c01f783d0508e015a5 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > >

Yes. Till that hotspots IP space gets blackholed by a major = > freemail because of all the nigerians and hijacked devices emitting bot tra= > ffic through stolen auth credentials.

>

There's other ways to stop this but they take actual har= > d work and rather more gear than a rusted up old asa you pull out of your c= > loset as like as not.
>

>
On Nov 28, 2014 2:10 AM, "Mark Andrews"= > ; <marka at isc.org> wrote:
=3D"attribution">
ex;border-left:1px #ccc solid;padding-left:1ex">
> Which is why your MTA should always be setup to require the use of
> STARTTLS.=C2=A0 Additionally the CERT presented should also match the
> name of the server.
>
> There is absolutely no reason for a ISP / hotspot to inspect
> submission traffic.=C2=A0 The "stopping spam" argument doesn'= > t wash with
> submission.
>
> Mark
>
> In message <54778167.70808= > 08 at bogus.com>, joel jaeggli writes:
> >
> > I don't see this in my home market, but I do see it in someone els= > e's...
> > I kind of expect this for port 25 but...
> >
> > J at mb-aye:~$telnet 147.28.0.81 587
> > Trying 147.28.0.81...
> > Connected to n= > agasaki.bogus.com.
> > Escape character is '^]'.
> > 220 nagasaki.b= > ogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014
> > 19:17:44 GMT
> > ehlo bogus.com
> > 250-nagasa= > ki.bogus.com Hello rget=3D"_blank">XXXXXXXXXXXXXXX.wa.comcast.net
> > [XXX.XXX.XXX.XXX], pleased to meet you
> > 250 ENHANCEDSTATUSCODES
> >
> > J at mb-aye:~$telnet 2001:418:1::81 587
> > Trying 2001:418:1::81...
> > Connected to n= > agasaki.bogus.com.
> > Escape character is '^]'.
> > 220 nagasaki.b= > ogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014
> > 19:18:33 GMT
> > ehlo bogus.com
> > 250-nagasa= > ki.bogus.com Hello
> > [IPv6:2601:7:2380:XXXX:XXXX:XXXX:c1ae:7d73], pleased to meet you
> > 250-ENHANCEDSTATUSCODES
> > 250-PIPELINING
> > 250-8BITMIME
> > 250-SIZE
> > 250-DSN
> > 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN
> > 250-STARTTLS
> > 250-DELIVERBY
> > 250 HELP
> >
> > that's essentially a downgrade attack on my ability to use encrypt= > ion
> > which seems to be in pretty poor taste frankly.
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= > =A0 =C2=A0INTERNET: marka at isc.org
>
> > --bcaec517c6c01f783d0508e015a5-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bill at herrin.us Fri Nov 28 00:42:20 2014 From: bill at herrin.us (William Herrin) Date: Thu, 27 Nov 2014 19:42:20 -0500 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <54778167.7080808@bogus.com> References: <54778167.7080808@bogus.com> Message-ID: On Thu, Nov 27, 2014 at 2:54 PM, joel jaeggli wrote: > I don't see this in my home market, but I do see it in someone else's... > I kind of expect this for port 25 but... > > J at mb-aye:~$telnet 147.28.0.81 587 > Trying 147.28.0.81... > Connected to nagasaki.bogus.com. > Escape character is '^]'. > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 > 19:17:44 GMT > ehlo bogus.com > 250-nagasaki.bogus.com Hello XXXXXXXXXXXXXXX.wa.comcast.net > [XXX.XXX.XXX.XXX], pleased to meet you > 250 ENHANCEDSTATUSCODES > > J at mb-aye:~$telnet 2001:418:1::81 587 > Trying 2001:418:1::81... > Connected to nagasaki.bogus.com. > Escape character is '^]'. > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 > 19:18:33 GMT > ehlo bogus.com > 250-nagasaki.bogus.com Hello > [IPv6:2601:7:2380:XXXX:XXXX:XXXX:c1ae:7d73], pleased to meet you > 250-ENHANCEDSTATUSCODES > 250-PIPELINING > 250-8BITMIME > 250-SIZE > 250-DSN > 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN > 250-STARTTLS > 250-DELIVERBY > 250 HELP > > that's essentially a downgrade attack on my ability to use encryption > which seems to be in pretty poor taste frankly. Hi Joel, I'm not sure I follow your complaint here. Are you saying that Comcast or a Comcast customer in Washington state stripped the STARTTLS verb from the IPv4 port 587 SMTP submission connection between you and a third party? Thanks, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From ops.lists at gmail.com Fri Nov 28 01:13:52 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 28 Nov 2014 06:43:52 +0530 Subject: Transparent hijacking of SMTP submission... In-Reply-To: References: <54778167.7080808@bogus.com> Message-ID: No. He is a comcast customer. And some third party wifi access point blocked his smtp submission over TLS by setting up an asa device to inspect 587 as well. On Nov 28, 2014 6:16 AM, "William Herrin" wrote: > On Thu, Nov 27, 2014 at 2:54 PM, joel jaeggli wrote: > > I don't see this in my home market, but I do see it in someone else's... > > I kind of expect this for port 25 but... > > > > J at mb-aye:~$telnet 147.28.0.81 587 > > Trying 147.28.0.81... > > Connected to nagasaki.bogus.com. > > Escape character is '^]'. > > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 > > 19:17:44 GMT > > ehlo bogus.com > > 250-nagasaki.bogus.com Hello XXXXXXXXXXXXXXX.wa.comcast.net > > [XXX.XXX.XXX.XXX], pleased to meet you > > 250 ENHANCEDSTATUSCODES > > > > J at mb-aye:~$telnet 2001:418:1::81 587 > > Trying 2001:418:1::81... > > Connected to nagasaki.bogus.com. > > Escape character is '^]'. > > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 > > 19:18:33 GMT > > ehlo bogus.com > > 250-nagasaki.bogus.com Hello > > [IPv6:2601:7:2380:XXXX:XXXX:XXXX:c1ae:7d73], pleased to meet you > > 250-ENHANCEDSTATUSCODES > > 250-PIPELINING > > 250-8BITMIME > > 250-SIZE > > 250-DSN > > 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN > > 250-STARTTLS > > 250-DELIVERBY > > 250 HELP > > > > that's essentially a downgrade attack on my ability to use encryption > > which seems to be in pretty poor taste frankly. > > > Hi Joel, > > I'm not sure I follow your complaint here. Are you saying that Comcast or a > Comcast customer in Washington state stripped the STARTTLS verb from the > IPv4 port 587 SMTP submission connection between you and a third party? > > Thanks, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > May I solve your unusual networking challenges? > From ops.lists at gmail.com Fri Nov 28 01:13:52 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 28 Nov 2014 06:43:52 +0530 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <20141128003824.8D49924783E0@rock.dv.isc.org> References: <54778167.7080808@bogus.com> <20141127203838.0F02724729DB@rock.dv.isc.org> <20141128003824.8D49924783E0@rock.dv.isc.org> Message-ID: Oh it depends on the numbers. Just how many legitimate smtp submission attempts do you get from say an access point at Joes diner in nowhere, OH? Versus just how many password cracking and malware relay attempts across how many of your users, from an unpatched xp box the guy is using for a billing app? At the scale of the problem a provider with any kind of userbase faces, you need a chainsaw, not a scalpel, given that you're out to cut a tree rather than perform plastic surgery. On Nov 28, 2014 6:08 AM, "Mark Andrews" wrote: > > In message 2qLcvb29i07OaX-yqg at mail.gmail.com> > , Suresh Ramasubramanian writes: > > > > Yes. Till that hotspots IP space gets blackholed by a major freemail > > because of all the nigerians and hijacked devices emitting bot traffic > > through stolen auth credentials. > > Why would it black hole the address rather than the block the > compromised credentials? The whole point of submission is to > authenticate the submitter and to be able to trace spam back to the > submitter and deal with the issue at that level of granuality. > > Blocking at that level also stop the credentials being used from > anywhere. > > scalpel vs chainsaw. > > Just because you provide free email doesn't give you the right to > not do the service properly. You encouraged people to use your > service. You should resource it to deal with the resulting load > and that includes dealing with spam and scans being sent with stolen > credentials. As a free email provider you have the plain text. > > Mark > > > There's other ways to stop this but they take actual hard work and rather > > more gear than a rusted up old asa you pull out of your closet as like as > > not. > > On Nov 28, 2014 2:10 AM, "Mark Andrews" wrote: > > > > > > > > Which is why your MTA should always be setup to require the use of > > > STARTTLS. Additionally the CERT presented should also match the > > > name of the server. > > > > > > There is absolutely no reason for a ISP / hotspot to inspect > > > submission traffic. The "stopping spam" argument doesn't wash with > > > submission. > > > > > > Mark > > > > > > In message <54778167.7080808 at bogus.com>, joel jaeggli writes: > > > > > > > > I don't see this in my home market, but I do see it in someone > else's... > > > > I kind of expect this for port 25 but... > > > > > > > > J at mb-aye:~$telnet 147.28.0.81 587 > > > > Trying 147.28.0.81... > > > > Connected to nagasaki.bogus.com. > > > > Escape character is '^]'. > > > > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov > 2014 > > > > 19:17:44 GMT > > > > ehlo bogus.com > > > > 250-nagasaki.bogus.com Hello XXXXXXXXXXXXXXX.wa.comcast.net > > > > [XXX.XXX.XXX.XXX], pleased to meet you > > > > 250 ENHANCEDSTATUSCODES > > > > > > > > J at mb-aye:~$telnet 2001:418:1::81 587 > > > > Trying 2001:418:1::81... > > > > Connected to nagasaki.bogus.com. > > > > Escape character is '^]'. > > > > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov > 2014 > > > > 19:18:33 GMT > > > > ehlo bogus.com > > > > 250-nagasaki.bogus.com Hello > > > > [IPv6:2601:7:2380:XXXX:XXXX:XXXX:c1ae:7d73], pleased to meet you > > > > 250-ENHANCEDSTATUSCODES > > > > 250-PIPELINING > > > > 250-8BITMIME > > > > 250-SIZE > > > > 250-DSN > > > > 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN > > > > 250-STARTTLS > > > > 250-DELIVERBY > > > > 250 HELP > > > > > > > > that's essentially a downgrade attack on my ability to use encryption > > > > which seems to be in pretty poor taste frankly. > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > > > > --bcaec517c6c01f783d0508e015a5 > > Content-Type: text/html; charset=UTF-8 > > Content-Transfer-Encoding: quoted-printable > > > >

Yes. Till that hotspots IP space gets blackholed by a > major = > > freemail because of all the nigerians and hijacked devices emitting bot > tra= > > ffic through stolen auth credentials.

> >

There's other ways to stop this but they take actual > har= > > d work and rather more gear than a rusted up old asa you pull out of > your c= > > loset as like as not.
> >

> >
On Nov 28, 2014 2:10 AM, "Mark > Andrews"= > > ; <marka at isc.org> wrote:
type= > > =3D"attribution">
.8= > > ex;border-left:1px #ccc solid;padding-left:1ex">
> > Which is why your MTA should always be setup to require the use of
> > STARTTLS.=C2=A0 Additionally the CERT presented should also match the
> > name of the server.
> >
> > There is absolutely no reason for a ISP / hotspot to inspect
> > submission traffic.=C2=A0 The "stopping spam" argument > doesn'= > > t wash with
> > submission.
> >
> > Mark
> >
> > In message < ">54778167.70808= > > 08 at bogus.com>, joel jaeggli writes:
> > >
> > > I don't see this in my home market, but I do see it in someone > els= > > e's...
> > > I kind of expect this for port 25 but...
> > >
> > > J at mb-aye:~$telnet 147.28.0.81 587
> > > Trying 147.28.0.81...
> > > Connected to target=3D"_blank">n= > > agasaki.bogus.com.
> > > Escape character is '^]'.
> > > 220 target=3D"_blank">nagasaki.b= > > ogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014
> > > 19:17:44 GMT
> > > ehlo bogus.com >
> > > target=3D"_blank">250-nagasa= > > ki.bogus.com Hello ta= > > rget=3D"_blank">XXXXXXXXXXXXXXX.wa.comcast.net
> > > [XXX.XXX.XXX.XXX], pleased to meet you
> > > 250 ENHANCEDSTATUSCODES
> > >
> > > J at mb-aye:~$telnet 2001:418:1::81 587
> > > Trying 2001:418:1::81...
> > > Connected to target=3D"_blank">n= > > agasaki.bogus.com.
> > > Escape character is '^]'.
> > > 220 target=3D"_blank">nagasaki.b= > > ogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014
> > > 19:18:33 GMT
> > > ehlo bogus.com >
> > > target=3D"_blank">250-nagasa= > > ki.bogus.com Hello
> > > [IPv6:2601:7:2380:XXXX:XXXX:XXXX:c1ae:7d73], pleased to meet you
> > > 250-ENHANCEDSTATUSCODES
> > > 250-PIPELINING
> > > 250-8BITMIME
> > > 250-SIZE
> > > 250-DSN
> > > 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN
> > > 250-STARTTLS
> > > 250-DELIVERBY
> > > 250 HELP
> > >
> > > that's essentially a downgrade attack on my ability to use > encrypt= > > ion
> > > which seems to be in pretty poor taste frankly.
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2= > > =A0 =C2=A0INTERNET: marka at isc.org >
> >
> > > > --bcaec517c6c01f783d0508e015a5-- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From jra at baylink.com Fri Nov 28 02:51:56 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 27 Nov 2014 21:51:56 -0500 (EST) Subject: Transparent hijacking of SMTP submission... In-Reply-To: Message-ID: <17944163.1511.1417143116212.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > > that's essentially a downgrade attack on my ability to use > > encryption > > which seems to be in pretty poor taste frankly. > > I'm not sure I follow your complaint here. Are you saying that Comcast > or a > Comcast customer in Washington state stripped the STARTTLS verb from > the > IPv4 port 587 SMTP submission connection between you and a third > party? Yup; that's what he's saying. This was in the technical press earlier this week -- or the end of last. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From jra at baylink.com Fri Nov 28 02:54:54 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 27 Nov 2014 21:54:54 -0500 (EST) Subject: Transparent hijacking of SMTP submission... In-Reply-To: Message-ID: <9670034.1513.1417143294388.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > I'm not sure I follow your complaint here. Are you saying that Comcast > or a > Comcast customer in Washington state stripped the STARTTLS verb from > the > IPv4 port 587 SMTP submission connection between you and a third > party? And, of course, *just* as I hit send, I remembered it was in RISKS, linking to EFF: https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks Note that's dated 11 November, so this is a couple weeks old now. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From javier at advancedmachines.us Fri Nov 28 05:10:47 2014 From: javier at advancedmachines.us (Javier J) Date: Fri, 28 Nov 2014 00:10:47 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: <26E6ACB4-BFA1-4949-8CA4-66D83F9E9A27@gmail.com> References: <20141127054551.4BFCF2C0054@mail.nanog.org> <7999F719-4469-463F-8E7D-A016CCA408B6@gmail.com> <26E6ACB4-BFA1-4949-8CA4-66D83F9E9A27@gmail.com> Message-ID: Thanks Phil. I guess the confusion is that during the outages, it was reachable from everywhere except Comcast, Verizon and ATT-U-verse all at the same time. Every proxy, vpn etc tested worked fine. Also the fact that the traces dropped immediately and not far off on a far network. In addition to that. Other users on other ISP in the local area (cable-vision / optimum, NYC) had no problem. obviously not all providers are using the same routes to the same destination. Just that when a controversial site becomes inaccessible, questions start to be raised. I think it was also mentioned somewhere on some site that as far as the pirate bay was concerned, everything on their end was operating normally. On Thu, Nov 27, 2014 at 3:30 PM, Phil Bedard wrote: > It looks like they use different upstream providers for each prefix, > probably hosted in different locations. > > The 194.71.107.0/24 prefix on my network was withdrawn by Ataro, and is > now reachable via this path: > > 194.71.107.0/24 *[BGP/170] 00:04:34 > AS path: 3356 3320 3320 24961 24961 24961 24961 > 39138 22351 131279 51040 I, validation-state: unverified > > The 4 minutes isn't really a good thing. > > This is the other prefix, via RETN who we also peer with. > > 194.14.56.0/24 *[BGP/170] 1d 07:15:42, MED 0 > AS path: 9002 197595 51040 I > > AS 24961 is myLoc.de who could be their hosting provider and may have had > issues with Atrato, who is now Hibernia. Who knows it looks like normal > BGP/Internet issues to me, if you are looking for some kind of conspiracy > nothing is going on. > > > Phil > > From: Javier J > Date: Thursday, November 27, 2014 at 2:16 PM > To: Phil B > Cc: Courtney Smith , "nanog at nanog.org" < > nanog at nanog.org> > Subject: Re: Anyone else having trouble reaching thepiratebay.se? AS39138 > > It was working for me a few hours ago, and now dead at hop 3 on FIOS again. > > If they have 2 prefixes being advertised from AS51040 > http://bgp.he.net/AS51040#_prefixes Why can I traceroute to 1 but not > the other? > > [root at tor-proxy network-scripts]# mtr --report -c 5 194.14.56.1 > HOST: tor-proxy.home Loss% Snt Last Avg Best Wrst > StDev > 1. pfsense.home 0.0% 5 0.5 1.0 0.4 2.7 > 1.0 > 2. L100.NWRKNJ-VFTTP-134.verizo 0.0% 5 1.3 6.0 1.3 20.6 > 8.3 > 3. G0-5-3-4.NWRKNJ-LCR-22.veriz 0.0% 5 3.2 4.6 3.2 6.7 > 1.4 > 4. ae0-0.NWRK-BB-RTR2.verizon-g 0.0% 5 5.9 8.4 4.9 20.7 > 6.8 > 5. ??? 100.0 5 0.0 0.0 0.0 0.0 > 0.0 > 6. 0.ae2.BR3.NYC4.ALTER.NET 0.0% 5 6.8 6.7 6.6 6.9 > 0.1 > 7. 204.255.169.234 0.0% 5 5.4 5.7 5.2 7.1 > 0.8 > 8. ae-2.r23.nycmny01.us.bb.gin. 0.0% 5 6.2 7.1 5.9 11.0 > 2.2 > 9. ae-6.r21.frnkge03.de.bb.gin. 60.0% 5 94.5 92.6 90.7 94.5 > 2.7 > 10. ae-1.r02.frnkge03.de.bb.gin. 0.0% 5 95.2 94.3 93.1 95.6 > 1.1 > 11. 213.198.77.214 0.0% 5 92.7 93.4 92.7 94.1 > 0.5 > 12. et030-4.RT.TC1.STO.SE.retn.n 0.0% 5 109.2 109.4 109.0 110.9 > 0.8 > 13. GW-ObeNetwork.retn.net 0.0% 5 116.0 190.0 111.1 341.8 > 100.4 > 14. moria-cr-3.piratpartiet.se 20.0% 5 110.1 111.6 109.9 116.1 > 2.9 > > > [root at tor-proxy network-scripts]# mtr --report -c 5 194.71.107.27 > HOST: tor-proxy.home Loss% Snt Last Avg Best Wrst > StDev > 1. pfsense.home 0.0% 5 0.6 0.4 0.3 0.6 > 0.1 > 2. L100.NWRKNJ-VFTTP-134.verizo 0.0% 5 1.4 7.1 1.4 29.1 > 12.3 > 3. ??? 100.0 5 0.0 0.0 0.0 0.0 > 0.0 > > > The site works 100 % fine over vpn or proxy. So I don't think this is > related to any DDOS attack. > > > > > On Thu, Nov 27, 2014 at 2:06 PM, Phil Bedard > wrote: > >> In the post you quoted it says: >> >> "In my last post I pointed out the do not announce to peers >> community AS5580 was sending to Cogent, Level3 and who knows who else. So >> any ASN that is not a customer of Cogent or Level3 wont learn the 5580 >> path >> from them." >> >> Verizon, ATT, and the rest of those networks are Tier-1 networks meaning >> if 5580 was tagging the route with do-not-advertise to their transit >> providers (Level3 & Cogent) the other Tier-1s wouldn't have another route >> to it. Looking at routing updates there were a lot of them yesterday for >> that prefix, for whatever reason. The lack of reachability was completely >> due to Atrato, had nothing to do with the ISPs in the US. >> >> It was reachable for me yesterday on our network, but we peer directly >> with Atrato. >> >> It's possible they did it to stop a DDoS, some other kind of attack, or >> any number of reasons. >> >> Phil >> >> >> >> >> >> >> On 11/27/14, 2:47 PM, "Javier J" wrote: >> >> >Looks like its working now (on FIOS anyway) >> > >> >Curious to know why the major networks stopped seeing it yesterday as >> >well. >> > >> >On Thu, Nov 27, 2014 at 12:45 AM, Courtney Smith >> > >> >wrote: >> > >> >> >> >> > No problem here in Los Angeles either, but seeing a lone route >> through >> >> Atrato only. >> >> > >> >> > flags destination gateway lpref med aspath origin >> >> > *> 194.71.107.0/24 <> 100 0 3491 5580 39138 22351 >> >>2.207 >> >> 51040 i >> >> > * 194.71.107.0/24 <> 100 0 174 5580 39138 22351 >> >> 2.207 51040 i >> >> > >> >> > >> >> > On 11/27/2014 午前 11:24, Tony Wicks wrote: >> >> >> >> >> >> No problem here in New Zealand >> >> >> >> >> >> tonyw at vrhost1-w> show route 194.71.107.0/24 >> >> >> >> >> >> icore1-w.inet.0: 519451 destinations, 525214 routes (519437 active, >> >>14 >> >> >> holddown, 0 hidden) >> >> >> + = Active Route, - = Last Active, * = Both >> >> >> >> >> >> 194.71.107.0/24 *[BGP/170] 10:25:44, MED 0, localpref 90 >> >> >> AS path: 4826 5580 39138 22351 131279 51040 >> I, >> >> >> validation-state: unverified >> >> >> > to 175.45.102.9 via ae1.526 >> >> >> >> >> >> >> Hopefully the body cones thru this time. The issue isn't city or >> >>country >> >> based. In my last post I pointed out the do not announce to peers >> >> community AS5580 was sending to Cogent, Level3 and who knows who else. >> >> So >> >> any ASN that is not a customer of Cogent or Level3 wont learn the 5580 >> >>path >> >> from them. >> >> >> >> When I checked a few hours ago, Comcast, Centurylink, AT&T, TATA, and >> >> possibly Sprint were not seeing the /24 based on their public looking >> >> glasses or route servers. Have not had time to run bgplay to see if >> >> routeviews data shows how they previously saw the /24 in past 30 days. >> >> Finding the ASN(s) they used to see from would shed light on why they >> >> stopped seeing. Checking bgplay and contacting AS51040 to reach out >> to >> >> their upstreams is my suggestion. >> >> > From maxtul at netassist.ua Thu Nov 27 17:21:17 2014 From: maxtul at netassist.ua (Max Tulyev) Date: Thu, 27 Nov 2014 19:21:17 +0200 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: References: Message-ID: <54775D8D.1020406@netassist.ua> Work for me, but with awful trace. Is it possible to arrange the direct peering with AS39138? Please contact me off-list if there are admins of AS39138. On 26.11.14 19:41, Javier J wrote: > Name: thepiratebay.se > Address: 194.71.107.27 > > Its reachable from some places and not others. > > Is it being filtered? > > Is it being hijacked? > > Email to them bounced from google apps. > > Are we now officially living in a police state? > > mtr dies at hop 2 for me: > > 2. l100.nwrknj-vfttp-134.verizon-gni.net ( 173.70.26.1 ) > > Is verizon now censoring the internet for me? > From joly at punkcast.com Fri Nov 28 05:38:00 2014 From: joly at punkcast.com (Joly MacFie) Date: Fri, 28 Nov 2014 00:38:00 -0500 Subject: Anyone else having trouble reaching thepiratebay.se? AS39138 In-Reply-To: References: <20141127054551.4BFCF2C0054@mail.nanog.org> <7999F719-4469-463F-8E7D-A016CCA408B6@gmail.com> <26E6ACB4-BFA1-4949-8CA4-66D83F9E9A27@gmail.com> Message-ID: Working for me now on FiOS in NYC. -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From m.waehlisch at fu-berlin.de Fri Nov 28 10:08:07 2014 From: m.waehlisch at fu-berlin.de (Matthias Waehlisch) Date: Fri, 28 Nov 2014 11:08:07 +0100 Subject: Call for input: RPKI Browser Message-ID: Hi, we started with the development of a browser that provides a graphical user interface to the objects of the distributed RPKI repository. A very preliminary version is available here http://rpki-browser.realmv6.org/. As we think such a tool could be useful for the community, we are asking for input at a very early stage. Please let me know which features you would like to see in such kind of tool. Some more details are described here https://labs.ripe.net/Members/waehlisch/call-for-input-rpki-browser Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch at ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From charles at thefnf.org Fri Nov 28 14:07:00 2014 From: charles at thefnf.org (Charles N Wyble) Date: Fri, 28 Nov 2014 08:07:00 -0600 Subject: Incident notification In-Reply-To: References: Message-ID: <7fdd106b-9e90-4808-82c0-4fa61d95707d@email.android.com> Pushover and email to sms from both an inband and off site monitoring vm. On November 21, 2014 9:52:00 AM CST, Thijs Stuurman wrote: >Nanog list members, > >I was looking at some statistic and noticed we are sending out a >massive amount of SMS messages from our monitoring systems. >This left me wondering if there isn't a better (and cheaper) >alternative to this, something just as reliant but IP based. We all >have smartphones these days anyway. > >Therefore my question, what are you using to notify admins of >incidents? > >Kind regards / Met vriendelijke groet, > >Thijs Stuurman > > > >[IS Logo] > > >________________________________ > >IS Group > >Wielingenstraat 8 > >T > >+31 (0)299 476 185 > >info at is.nl > >1441 ZR Purmerend > >F > >+31 (0)299 476 288 > >www.is.nl > >________________________________ > >IS Group is ISO 9001:2008, ISO/IEC 27001:2005, ISO 20.000-1:2005, ISAE >3402 certified. De datacenters zijn PCI DSS en ISO 14001 compliant. > > > >!DSPAM:546f5ff6238696356864932! -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From keefe-af at ethoplex.com Fri Nov 28 15:24:07 2014 From: keefe-af at ethoplex.com (Keefe John) Date: Fri, 28 Nov 2014 09:24:07 -0600 Subject: Barracuda Central Contact Message-ID: <54789397.9060609@ethoplex.com> Is there anyone here from Barracuda that could help with a bulk delisting? We got a new IP block and almost all of the IPs are blacklisted by Barracuda. Thanks! Keefe John From javier at advancedmachines.us Fri Nov 28 15:27:25 2014 From: javier at advancedmachines.us (Javier J) Date: Fri, 28 Nov 2014 10:27:25 -0500 Subject: Incident notification In-Reply-To: References: Message-ID: Multiple nagios servers directly sending via amazon web services SES to pager duty. Unlikely SES would go completely down. Nagios boxes monitor eachother from different continents. On Nov 21, 2014 10:52 AM, "Thijs Stuurman" wrote: > Nanog list members, > > I was looking at some statistic and noticed we are sending out a massive > amount of SMS messages from our monitoring systems. > This left me wondering if there isn't a better (and cheaper) alternative > to this, something just as reliant but IP based. We all have smartphones > these days anyway. > > Therefore my question, what are you using to notify admins of incidents? > > Kind regards / Met vriendelijke groet, > > Thijs Stuurman > > > > [IS Logo] > > > ________________________________ > > IS Group > > Wielingenstraat 8 > > T > > +31 (0)299 476 185 > > info at is.nl > > 1441 ZR Purmerend > > F > > +31 (0)299 476 288 > > www.is.nl > > ________________________________ > > IS Group is ISO 9001:2008, ISO/IEC 27001:2005, ISO 20.000-1:2005, ISAE > 3402 certified. De datacenters zijn PCI DSS en ISO 14001 compliant. > > > From frnkblk at iname.com Fri Nov 28 15:28:00 2014 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 28 Nov 2014 09:28:00 -0600 Subject: Barracuda Central Contact In-Reply-To: <54789397.9060609@ethoplex.com> References: <54789397.9060609@ethoplex.com> Message-ID: <000601d00b1f$e500c8f0$af025ad0$@iname.com> http://www.barracudacentral.org/rbl/removal-request Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Keefe John Sent: Friday, November 28, 2014 9:24 AM To: NANOG Subject: Barracuda Central Contact Is there anyone here from Barracuda that could help with a bulk delisting? We got a new IP block and almost all of the IPs are blacklisted by Barracuda. Thanks! Keefe John From jfmezei_nanog at vaxination.ca Fri Nov 28 15:46:03 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 28 Nov 2014 10:46:03 -0500 Subject: Phasing out of copper Message-ID: <547898BB.80002@vaxination.ca> Currently in the midst of a CRTC policy hearing in Canada on future of competition in ISPs. Incumbents claim they have no plans to retire their copper plant after deploying FTTP/FTTH. (strategically to convince regulator that keeping ISPs on copper is fine and no need to let them access FTTP). For my reply I am trying to get more authoritative info to show that incumbents do have plans to retire the copper plant once enough customers have migrated to FTTP ( I heard that 80% migration is the tip-ver where they convert the rest of customers to FTTP to be able to shutddown the copper). Anyone have pointers to documents or experiences that would help me convince the regulator that incumbents deploy FTTP with eventual goal to be able to shutdown their old copper instead of perpetually maintaining both systems ? Also being discussed is removing regulations for access to ULL (unbundled local loops). In areas being upgraded to FTTP, are there services that really need copper ULLs and do not have an FTTP equivalent ? (home alarm systems ?). When an incumbent states for the record that "retiring copper is not in their current plans", I know that it means that it isn't in their short term plans. But I need some evidence of what other telcos do to help show the incumbent is "spinning". Any help appreciated. From keefe-af at ethoplex.com Fri Nov 28 16:00:29 2014 From: keefe-af at ethoplex.com (Keefe John) Date: Fri, 28 Nov 2014 10:00:29 -0600 Subject: Barracuda Central Contact In-Reply-To: <000601d00b1f$e500c8f0$af025ad0$@iname.com> References: <54789397.9060609@ethoplex.com> <000601d00b1f$e500c8f0$af025ad0$@iname.com> Message-ID: <54789C1D.3090707@ethoplex.com> I need a whole /20 removed. That form only takes individual IPs. Keefe On 11/28/2014 9:28 AM, Frank Bulk wrote: > http://www.barracudacentral.org/rbl/removal-request > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Keefe John > Sent: Friday, November 28, 2014 9:24 AM > To: NANOG > Subject: Barracuda Central Contact > > Is there anyone here from Barracuda that could help with a bulk > delisting? We got a new IP block and almost all of the IPs are > blacklisted by Barracuda. > > Thanks! > > Keefe John > > From hugo at slabnet.com Fri Nov 28 16:35:20 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 28 Nov 2014 08:35:20 -0800 Subject: Phasing out of copper In-Reply-To: <547898BB.80002@vaxination.ca> References: <547898BB.80002@vaxination.ca> Message-ID: <20141128162854.GA23849@bamboo.slabnet.com> Have some of the events around this topic going on in the US been brought up? I'm thinking specifically of things like NY/NJ, post-Sandy plans to just not replace copper and switch people to wireless or fiber instead, letting copper deployments in existing markets degrade and pushing people to FiO...fiber. Those would seem to be examples where there don't need to be an explicit "plans to retire their copper plant" while still effectively retiring them through failure to maintain. -- Hugo On Fri 2014-Nov-28 10:46:03 -0500, Jean-Francois Mezei wrote: >Currently in the midst of a CRTC policy hearing in Canada on future of >competition in ISPs. > >Incumbents claim they have no plans to retire their copper plant after >deploying FTTP/FTTH. (strategically to convince regulator that keeping >ISPs on copper is fine and no need to let them access FTTP). > >For my reply I am trying to get more authoritative info to show that >incumbents do have plans to retire the copper plant once enough >customers have migrated to FTTP ( I heard that 80% migration is the >tip-ver where they convert the rest of customers to FTTP to be able to >shutddown the copper). > >Anyone have pointers to documents or experiences that would help me >convince the regulator that incumbents deploy FTTP with eventual goal to >be able to shutdown their old copper instead of perpetually maintaining >both systems ? > >Also being discussed is removing regulations for access to ULL >(unbundled local loops). In areas being upgraded to FTTP, are there >services that really need copper ULLs and do not have an FTTP equivalent >? (home alarm systems ?). > > > > >When an incumbent states for the record that "retiring copper is not in >their current plans", I know that it means that it isn't in their short >term plans. But I need some evidence of what other telcos do to help >show the incumbent is "spinning". > >Any help appreciated. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From cra at WPI.EDU Fri Nov 28 17:26:37 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 28 Nov 2014 12:26:37 -0500 Subject: Phasing out of copper In-Reply-To: <547898BB.80002@vaxination.ca> References: <547898BB.80002@vaxination.ca> Message-ID: <20141128172637.GV16805@angus.ind.WPI.EDU> Verizon in MA removes copper upon FiOS installation. My dad cancels his phone service every year when he migrates south for the winter. Upon returning home a few years ago, he requested reactivation of his phone line. Verizon refused to activate the copper, instead switching him to FiOS Voice. I believe they removed the copper lines at that time. On Fri, Nov 28, 2014 at 10:46:03AM -0500, Jean-Francois Mezei wrote: > Currently in the midst of a CRTC policy hearing in Canada on future of > competition in ISPs. > > Incumbents claim they have no plans to retire their copper plant after > deploying FTTP/FTTH. (strategically to convince regulator that keeping > ISPs on copper is fine and no need to let them access FTTP). > > For my reply I am trying to get more authoritative info to show that > incumbents do have plans to retire the copper plant once enough > customers have migrated to FTTP ( I heard that 80% migration is the > tip-ver where they convert the rest of customers to FTTP to be able to > shutddown the copper). > > Anyone have pointers to documents or experiences that would help me > convince the regulator that incumbents deploy FTTP with eventual goal to > be able to shutdown their old copper instead of perpetually maintaining > both systems ? > > Also being discussed is removing regulations for access to ULL > (unbundled local loops). In areas being upgraded to FTTP, are there > services that really need copper ULLs and do not have an FTTP equivalent > ? (home alarm systems ?). > > > > > When an incumbent states for the record that "retiring copper is not in > their current plans", I know that it means that it isn't in their short > term plans. But I need some evidence of what other telcos do to help > show the incumbent is "spinning". > > Any help appreciated. From cscora at apnic.net Fri Nov 28 18:11:41 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 Nov 2014 04:11:41 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201411281811.sASIBfW4010725@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 29 Nov, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 519301 Prefixes after maximum aggregation: 200376 Deaggregation factor: 2.59 Unique aggregates announced to Internet: 254950 Total ASes present in the Internet Routing Table: 48708 Prefixes per ASN: 10.66 Origin-only ASes present in the Internet Routing Table: 36301 Origin ASes announcing only one prefix: 16312 Transit ASes present in the Internet Routing Table: 6231 Transit-only ASes present in the Internet Routing Table: 178 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 73 Max AS path prepend of ASN ( 55644) 66 Prefixes from unregistered ASNs in the Routing Table: 1637 Unregistered ASNs in the Routing Table: 425 Number of 32-bit ASNs allocated by the RIRs: 8032 Number of 32-bit ASNs visible in the Routing Table: 6176 Prefixes from 32-bit ASNs in the Routing Table: 22081 Number of bogon 32-bit ASNs visible in the Routing Table: 6 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 357 Number of addresses announced to Internet: 2713210500 Equivalent to 161 /8s, 184 /16s and 78 /24s Percentage of available address space announced: 73.3 Percentage of allocated address space announced: 73.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.0 Total number of prefixes smaller than registry allocations: 176990 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 127927 Total APNIC prefixes after maximum aggregation: 37096 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 132411 Unique aggregates announced from the APNIC address blocks: 54049 APNIC Region origin ASes present in the Internet Routing Table: 4994 APNIC Prefixes per ASN: 26.51 APNIC Region origin ASes announcing only one prefix: 1201 APNIC Region transit ASes present in the Internet Routing Table: 872 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 73 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1193 Number of APNIC addresses announced to Internet: 737464576 Equivalent to 43 /8s, 244 /16s and 209 /24s Percentage of available APNIC address space announced: 86.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 171629 Total ARIN prefixes after maximum aggregation: 85549 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 173623 Unique aggregates announced from the ARIN address blocks: 82104 ARIN Region origin ASes present in the Internet Routing Table: 16388 ARIN Prefixes per ASN: 10.59 ARIN Region origin ASes announcing only one prefix: 6078 ARIN Region transit ASes present in the Internet Routing Table: 1712 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 268 Number of ARIN addresses announced to Internet: 1054144704 Equivalent to 62 /8s, 212 /16s and 248 /24s Percentage of available ARIN address space announced: 55.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 126322 Total RIPE prefixes after maximum aggregation: 63818 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 132057 Unique aggregates announced from the RIPE address blocks: 82786 RIPE Region origin ASes present in the Internet Routing Table: 17826 RIPE Prefixes per ASN: 7.41 RIPE Region origin ASes announcing only one prefix: 8181 RIPE Region transit ASes present in the Internet Routing Table: 2933 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3235 Number of RIPE addresses announced to Internet: 692427396 Equivalent to 41 /8s, 69 /16s and 154 /24s Percentage of available RIPE address space announced: 100.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 58799 Total LACNIC prefixes after maximum aggregation: 10857 LACNIC Deaggregation factor: 5.42 Prefixes being announced from the LACNIC address blocks: 67561 Unique aggregates announced from the LACNIC address blocks: 30814 LACNIC Region origin ASes present in the Internet Routing Table: 2378 LACNIC Prefixes per ASN: 28.41 LACNIC Region origin ASes announcing only one prefix: 644 LACNIC Region transit ASes present in the Internet Routing Table: 472 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1406 Number of LACNIC addresses announced to Internet: 167660608 Equivalent to 9 /8s, 254 /16s and 76 /24s Percentage of available LACNIC address space announced: 99.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12415 Total AfriNIC prefixes after maximum aggregation: 3012 AfriNIC Deaggregation factor: 4.12 Prefixes being announced from the AfriNIC address blocks: 13292 Unique aggregates announced from the AfriNIC address blocks: 4879 AfriNIC Region origin ASes present in the Internet Routing Table: 738 AfriNIC Prefixes per ASN: 18.01 AfriNIC Region origin ASes announcing only one prefix: 208 AfriNIC Region transit ASes present in the Internet Routing Table: 155 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 74 Number of AfriNIC addresses announced to Internet: 60115456 Equivalent to 3 /8s, 149 /16s and 74 /24s Percentage of available AfriNIC address space announced: 59.7 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2957 11585 931 Korea Telecom 17974 2840 904 77 PT Telekomunikasi Indonesia 7545 2466 337 129 TPG Telecom Limited 4755 1930 416 192 TATA Communications formerly 9829 1671 1323 28 National Internet Backbone 4538 1547 4190 71 China Education and Research 9808 1495 6655 16 Guangdong Mobile Communicatio 4808 1429 2213 427 CNCGROUP IP network China169 9583 1365 112 563 Sify Limited 9498 1318 334 95 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2892 3688 51 BellSouth.net Inc. 22773 2851 2956 144 Cox Communications Inc. 18566 2044 379 183 MegaPath Corporation 20115 1827 1805 472 Charter Communications 4323 1643 1053 412 tw telecom holdings, inc. 6983 1629 867 251 EarthLink, Inc. 30036 1503 312 594 Mediacom Communications Corp 701 1424 11265 704 MCI Communications Services, 22561 1310 411 244 CenturyTel Internet Holdings, 11492 1227 217 532 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 34984 1898 298 356 TELLCOM ILETISIM HIZMETLERI A 20940 1509 588 1114 Akamai International B.V. 8402 1377 544 15 OJSC "Vimpelcom" 31148 1045 45 21 Freenet Ltd. 13188 997 95 60 TOV "Bank-Inform" 8551 900 373 44 Bezeq International-Ltd 6849 834 356 26 JSC "Ukrtelecom" 9198 824 346 32 JSC Kazakhtelecom 6830 817 2339 439 Liberty Global Operations B.V 12479 777 788 94 France Telecom Espana SA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3046 494 247 Telmex Colombia S.A. 28573 2322 2263 110 NET Servi�os de Comunica��o S 6147 1806 374 30 Telefonica del Peru S.A.A. 7303 1733 1123 242 Telecom Argentina S.A. 8151 1481 3031 423 Uninet S.A. de C.V. 6503 1228 433 58 Axtel, S.A.B. de C.V. 7738 999 1882 41 Telemar Norte Leste S.A. 26615 914 2325 35 Tim Celular S.A. 3816 907 394 146 COLOMBIA TELECOMUNICACIONES S 27947 886 129 50 Telconet S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1410 958 13 TE-AS 24863 958 280 26 Link Egypt (Link.NET) 36903 415 209 129 Office National des Postes et 36992 368 824 29 ETISALAT MISR 24835 308 144 9 Vodafone Data 37492 291 133 61 Orange Tunisie 37054 257 19 6 Data Telecom Service 3741 249 920 212 Internet Solutions 29571 245 22 17 Cote d'Ivoire Telecom 37457 185 160 4 Telkom SA Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3046 494 247 Telmex Colombia S.A. 4766 2957 11585 931 Korea Telecom 6389 2892 3688 51 BellSouth.net Inc. 22773 2851 2956 144 Cox Communications Inc. 17974 2840 904 77 PT Telekomunikasi Indonesia 7545 2466 337 129 TPG Telecom Limited 28573 2322 2263 110 NET Servi�os de Comunica��o S 18566 2044 379 183 MegaPath Corporation 4755 1930 416 192 TATA Communications formerly 34984 1898 298 356 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2892 2841 BellSouth.net Inc. 17974 2840 2763 PT Telekomunikasi Indonesia 22773 2851 2707 Cox Communications Inc. 7545 2466 2337 TPG Telecom Limited 28573 2322 2212 NET Servi�os de Comunica��o S 4766 2957 2026 Korea Telecom 18566 2044 1861 MegaPath Corporation 6147 1806 1776 Telefonica del Peru S.A.A. 4755 1930 1738 TATA Communications formerly 9829 1671 1643 National Internet Backbone Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.252.224.0/20 62502 Xnet Media LLC 23.252.224.0/21 62502 Xnet Media LLC 23.252.232.0/21 62502 Xnet Media LLC 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:31 /11:92 /12:264 /13:500 /14:999 /15:1726 /16:13044 /17:7143 /18:11921 /19:24778 /20:35343 /21:37591 /22:55689 /23:48420 /24:278771 /25:1110 /26:1089 /27:704 /28:16 /29:19 /30:11 /31:0 /32:12 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2063 2851 Cox Communications Inc. 18566 1999 2044 MegaPath Corporation 6389 1672 2892 BellSouth.net Inc. 6147 1357 1806 Telefonica del Peru S.A.A. 30036 1349 1503 Mediacom Communications Corp 6983 1309 1629 EarthLink, Inc. 34984 1205 1898 TELLCOM ILETISIM HIZMETLERI A 11492 1172 1227 CABLE ONE, INC. 10620 1077 3046 Telmex Colombia S.A. 8402 1042 1377 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1364 2:676 3:3 4:16 5:1226 6:23 8:770 12:1845 13:5 14:1193 15:17 16:2 17:42 18:21 20:51 23:1022 24:1671 27:1805 31:1407 32:39 33:2 34:5 36:153 37:1851 38:976 39:14 40:225 41:2998 42:272 43:695 44:19 45:84 46:2104 47:30 49:762 50:795 52:12 54:60 55:6 56:6 57:31 58:1158 59:661 60:449 61:1706 62:1303 63:1843 64:4397 65:2282 66:4109 67:2007 68:1046 69:3263 70:873 71:434 72:1982 74:2601 75:321 76:410 77:1522 78:956 79:782 80:1328 81:1278 82:816 83:672 84:673 85:1356 86:448 87:1190 88:507 89:1827 90:140 91:5832 92:797 93:1667 94:1948 95:1305 96:426 97:341 98:1030 99:48 100:67 101:759 103:6173 104:745 105:171 106:190 107:866 108:609 109:1998 110:1054 111:1426 112:732 113:917 114:802 115:1220 116:1233 117:1008 118:1596 119:1363 120:442 121:989 122:2209 123:1704 124:1460 125:1544 128:653 129:391 130:382 131:987 132:429 133:164 134:324 135:83 136:332 137:303 138:388 139:162 140:225 141:423 142:636 143:435 144:508 145:112 146:694 147:561 148:1059 149:400 150:519 151:646 152:482 153:247 154:413 155:640 156:386 157:332 158:251 159:935 160:335 161:616 162:1819 163:373 164:645 165:674 166:300 167:702 168:1162 169:130 170:1423 171:215 172:60 173:1583 174:708 175:585 176:1550 177:3690 178:2109 179:790 180:1813 181:1637 182:1672 183:527 184:705 185:2408 186:2925 187:1667 188:2018 189:1531 190:7925 191:818 192:7846 193:5563 194:4064 195:3616 196:1653 197:842 198:5340 199:5466 200:6536 201:2949 202:9453 203:9006 204:4687 205:2680 206:3003 207:2972 208:3924 209:3809 210:3465 211:1846 212:2452 213:2207 214:833 215:87 216:5610 217:1716 218:650 219:398 220:1298 221:773 222:439 223:662 End of report From jra at baylink.com Fri Nov 28 20:06:18 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 28 Nov 2014 15:06:18 -0500 (EST) Subject: Phasing out of copper In-Reply-To: <20141128172637.GV16805@angus.ind.WPI.EDU> Message-ID: <2349647.1583.1417205178266.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Chuck Anderson" > Verizon in MA removes copper upon FiOS installation. They do, and that's caused problems for some people who had competitive DSL on their Verizontal copper POTS: They've had FiOS installed, and had the DSL circuit mysteriously quit, only to find VZN had physically yanked the demarc off the outside wall and reclaimed the drop. I think there mighta been some lawsuits... Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From tim.h at bendtel.com Fri Nov 28 20:40:44 2014 From: tim.h at bendtel.com (Tim Howe) Date: Fri, 28 Nov 2014 12:40:44 -0800 Subject: Phasing out of copper In-Reply-To: <547898BB.80002@vaxination.ca> References: <547898BB.80002@vaxination.ca> Message-ID: <20141128124044.5e5e8a4e@wind.dirtymonday.net> On Fri, 28 Nov 2014 10:46:03 -0500 Jean-Francois Mezei wrote: > For my reply I am trying to get more authoritative info to show that > incumbents do have plans to retire the copper plant once enough > customers have migrated to FTTP ( I heard that 80% migration is the > tip-ver where they convert the rest of customers to FTTP to be able to > shutddown the copper). This probably isn't exactly what you are looking for, but... As a CLEC in Oregon we connect to Century Link's ATM network to resell ADSL service. They have, for a while, maintained both fiber and copper facilities to these nodes. CL uses the fiber and we access the nodes through some number of T1s on the legacy ATM network (which usually provides inadequate bandwidth). They have been removing the ATM access to the nodes -- giving us about 2 weeks notice to warn and prepare any customers we have on them. We can resell the new DSL service (under higher rates), but CL gives us no way of providing access to these customers from our network now. The rates get even higher with static IPs (which we always provided at no cost). --TimH From cidr-report at potaroo.net Fri Nov 28 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Nov 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201411282200.sASM00r8003016@wattle.apnic.net> This report has been generated at Fri Nov 28 21:14:20 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 21-11-14 524001 290523 22-11-14 523100 290584 23-11-14 523197 290567 24-11-14 523502 290865 25-11-14 523905 291163 26-11-14 524287 291501 27-11-14 525048 291651 28-11-14 525097 291936 AS Summary 48979 Number of ASes in routing system 19666 Number of ASes announcing only one prefix 3047 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120175872 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 28Nov14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 525162 291946 233216 44.4% All ASes AS6389 2892 124 2768 95.7% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2840 83 2757 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS22773 2854 176 2678 93.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS28573 2322 294 2028 87.3% NET Servi�os de Comunica��o S.A.,BR AS6147 1805 167 1638 90.7% Telefonica del Peru S.A.A.,PE AS4766 2960 1340 1620 54.7% KIXS-AS-KR Korea Telecom,KR AS10620 3047 1584 1463 48.0% Telmex Colombia S.A.,CO AS7303 1737 296 1441 83.0% Telecom Argentina S.A.,AR AS9808 1495 55 1440 96.3% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS8402 1354 26 1328 98.1% CORBINA-AS OJSC "Vimpelcom",RU AS4755 1929 646 1283 66.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS20115 1828 553 1275 69.7% CHARTER-NET-HKY-NC - Charter Communications,US AS4323 1652 414 1238 74.9% TWTC - tw telecom holdings, inc.,US AS7545 2477 1244 1233 49.8% TPG-INTERNET-AP TPG Telecom Limited,AU AS9498 1318 113 1205 91.4% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2043 868 1175 57.5% MEGAPATH5-US - MegaPath Corporation,US AS6983 1629 495 1134 69.6% ITCDELTA - Earthlink, Inc.,US AS7552 1099 51 1048 95.4% VIETEL-AS-AP Viettel Corporation,VN AS34984 1898 861 1037 54.6% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS22561 1311 358 953 72.7% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS38285 982 127 855 87.1% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS24560 1181 348 833 70.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS31148 1045 256 789 75.5% FREENET-AS Freenet Ltd.,UA AS26615 914 133 781 85.4% Tim Celular S.A.,BR AS8151 1487 707 780 52.5% Uninet S.A. de C.V.,MX AS4780 1055 285 770 73.0% SEEDNET Digital United Inc.,TW AS18101 956 193 763 79.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS17908 834 97 737 88.4% TCISL Tata Communications,IN AS855 789 57 732 92.8% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA Total 50732 12034 38698 76.3% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.224.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.228.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.232.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 45.236.0.0/14 AS28000 LACNIC - Latin American and Caribbean IP address,UY 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.220.84.0/24 AS5577 ROOT root SA,LU 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 102.12.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 102.36.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 102.53.0.0/16 AS59790 H3S Helge Sczepanek trading as H3S medien services,DE 103.6.108.0/22 AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN 103.10.222.0/24 AS13189 103.14.231.0/24 AS58680 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.27.144.0/22 AS18097 DCN D.C.N. Corporation,JP 103.241.48.0/22 AS24544 PANGNET-AS-AP Pang International Limited-AS number,HK 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.251.140.0/22 AS55536 PSWITCH-HK Pacswitch Colocation & Datacentre,HK 103.251.244.0/22 AS55536 PSWITCH-HK Pacswitch Colocation & Datacentre,HK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.6.0.0/24 AS32768 routability-tests,MU 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.254.0/24 AS32768 routability-tests,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Nov 28 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Nov 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201411282200.sASM024G003029@wattle.apnic.net> BGP Update Report Interval: 20-Nov-14 -to- 27-Nov-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS12897 1394574 20.6% 199224.9 -- HEAGMEDIANET HSE Medianet GmbH,DE 2 - AS23752 300478 4.4% 2659.1 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS9829 266609 3.9% 169.1 -- BSNL-NIB National Internet Backbone,IN 4 - AS53249 78168 1.2% 39084.0 -- LAWA-AS - Los Angeles World Airport,US 5 - AS28642 63900 0.9% 1879.4 -- Contato Internet Ltda EPP,BR 6 - AS14840 60699 0.9% 1785.3 -- COMMCORP COMUNICACOES LTDA,BR 7 - AS20940 49912 0.7% 102.9 -- AKAMAI-ASN1 Akamai International B.V.,US 8 - AS23688 44891 0.7% 760.9 -- LINK3-TECH-AS-BD-AP Link3 Technologies Ltd.,BD 9 - AS52828 44476 0.7% 1482.5 -- Netpal Internet Palmares Ltda.,BR 10 - AS8402 43028 0.6% 29.3 -- CORBINA-AS OJSC "Vimpelcom",RU 11 - AS5 38861 0.6% 7.0 -- SYMBOLICS - Symbolics, Inc.,US 12 - AS28573 37224 0.6% 27.0 -- NET Servi�os de Comunica��o S.A.,BR 13 - AS46573 36961 0.6% 82.1 -- GLOBAL-FRAG-SERVERS - Global Frag Networks,US 14 - AS7545 32539 0.5% 13.4 -- TPG-INTERNET-AP TPG Telecom Limited,AU 15 - AS35819 32391 0.5% 60.3 -- MOBILY-AS Etihad Etisalat Company (Mobily),SA 16 - AS45271 31119 0.5% 103.4 -- ICLNET-AS-AP Idea Cellular Limited,IN 17 - AS3 30043 0.4% 3185.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 18 - AS53175 30030 0.4% 968.7 -- Unetvale Servicos e Equipamentos LTDA,BR 19 - AS38197 28599 0.4% 27.4 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 20 - AS39891 27349 0.4% 98.0 -- ALJAWWALSTC-AS Saudi Telecom Company JSC,SA TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS12897 1394574 20.6% 199224.9 -- HEAGMEDIANET HSE Medianet GmbH,DE 2 - AS53249 78168 1.2% 39084.0 -- LAWA-AS - Los Angeles World Airport,US 3 - AS23342 22191 0.3% 22191.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 4 - AS3181 10938 0.2% 10938.0 -- ASN-MATRIXMOBILE CJSC "Matrix Mobile",RU 5 - AS18135 9065 0.1% 9065.0 -- BTV BTV Cable television,JP 6 - AS3 23868 0.3% 1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 7 - AS37425 15898 0.2% 7949.0 -- Somcable,SO 8 - AS60725 22790 0.3% 7596.7 -- O3B-AS O3b Limited,JE 9 - AS62174 4824 0.1% 4824.0 -- INTERPAN-AS INTERPAN LTD.,BG 10 - AS25003 19994 0.3% 3998.8 -- INTERNET_BINAT Internet Binat Ltd,IL 11 - AS16065 2702 0.0% 2702.0 -- AS16065 Redimi AS,NL 12 - AS23752 300478 4.4% 2659.1 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 13 - AS5 38861 0.6% 7.0 -- SYMBOLICS - Symbolics, Inc.,US 14 - AS55657 2147 0.0% 2147.0 -- XNS-AS-ID Xtreme Network System, PT,ID 15 - AS4 21237 0.3% 871.0 -- ISI-AS - University of Southern California,US 16 - AS28642 63900 0.9% 1879.4 -- Contato Internet Ltda EPP,BR 17 - AS58599 5559 0.1% 1853.0 -- CYBERGATE-BD Cybergate Limited,BD 18 - AS14840 60699 0.9% 1785.3 -- COMMCORP COMUNICACOES LTDA,BR 19 - AS4 5345 0.1% 1437.0 -- ISI-AS - University of Southern California,US 20 - AS4 8784 0.1% 2303.0 -- ISI-AS - University of Southern California,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 94.16.72.0/21 200960 2.9% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 2 - 94.16.64.0/21 200914 2.9% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 3 - 94.16.80.0/20 200901 2.9% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 4 - 194.99.108.0/23 199280 2.9% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 5 - 194.127.204.0/23 199121 2.9% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 6 - 194.45.104.0/23 197850 2.9% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 7 - 185.9.28.0/22 195548 2.8% AS12897 -- HEAGMEDIANET HSE Medianet GmbH,DE 8 - 202.70.88.0/21 150476 2.2% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 9 - 202.70.64.0/21 146967 2.1% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 10 - 198.140.114.0/24 39116 0.6% AS53249 -- LAWA-AS - Los Angeles World Airport,US 11 - 198.140.115.0/24 39052 0.6% AS53249 -- LAWA-AS - Los Angeles World Airport,US 12 - 196.43.157.0/24 38349 0.6% AS5 -- SYMBOLICS - Symbolics, Inc.,US 13 - 130.0.192.0/21 23862 0.3% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 14 - 64.29.130.0/24 22191 0.3% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 15 - 192.115.44.0/22 19986 0.3% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 16 - 162.249.183.0/24 11921 0.2% AS60725 -- O3B-AS O3b Limited,JE 17 - 5.8.168.0/23 10938 0.2% AS3181 -- ASN-MATRIXMOBILE CJSC "Matrix Mobile",RU 18 - 185.26.155.0/24 10851 0.2% AS60725 -- O3B-AS O3b Limited,JE 19 - 14.0.59.0/24 10546 0.1% AS36408 -- CDNETWORKSUS-02 - CDNetworks Inc.,US 20 - 192.58.232.0/24 10407 0.1% AS6629 -- NOAA-AS - NOAA,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From ammar at fastreturn.net Sat Nov 29 13:54:37 2014 From: ammar at fastreturn.net (Ammar Zuberi) Date: Sat, 29 Nov 2014 17:54:37 +0400 Subject: TeliaSonera IC Contacts Message-ID: Hi all, Does anyone have a contact for an account manager at TeliaSonera IC? We’ve sent at least 3 requests for a quote through their website over a month or so and haven’t got a single reply except for the automated “we’ve received your query” email. We’re looking for IP transit in Amsterdam, NL. Best Regards, Ammar Zuberi FastReturn, Inc Email: ammar at fastreturn.net This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From sander at steffann.nl Sat Nov 29 15:25:37 2014 From: sander at steffann.nl (Sander Steffann) Date: Sat, 29 Nov 2014 19:25:37 +0400 Subject: TeliaSonera IC Contacts In-Reply-To: References: Message-ID: Hi, > Does anyone have a contact for an account manager at TeliaSonera IC? We’ve sent at least 3 requests for a quote through their website over a month or so and haven’t got a single reply except for the automated “we’ve received your query” email. And you still want to buy from them?!? Sander From randy at psg.com Sat Nov 29 15:37:56 2014 From: randy at psg.com (Randy Bush) Date: Sat, 29 Nov 2014 10:37:56 -0500 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <54778167.7080808@bogus.com> References: <54778167.7080808@bogus.com> Message-ID: > I don't see this in my home market, but I do see it in someone else's... > I kind of expect this for port 25 but... > > J at mb-aye:~$telnet 147.28.0.81 587 > Trying 147.28.0.81... > Connected to nagasaki.bogus.com. > Escape character is '^]'. > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 > 19:17:44 GMT > ehlo bogus.com > 250-nagasaki.bogus.com Hello XXXXXXXXXXXXXXX.wa.comcast.net > [XXX.XXX.XXX.XXX], pleased to meet you > 250 ENHANCEDSTATUSCODES > > J at mb-aye:~$telnet 2001:418:1::81 587 > Trying 2001:418:1::81... > Connected to nagasaki.bogus.com. > Escape character is '^]'. > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 > 19:18:33 GMT > ehlo bogus.com > 250-nagasaki.bogus.com Hello > [IPv6:2601:7:2380:XXXX:XXXX:XXXX:c1ae:7d73], pleased to meet you > 250-ENHANCEDSTATUSCODES > 250-PIPELINING > 250-8BITMIME > 250-SIZE > 250-DSN > 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN > 250-STARTTLS > 250-DELIVERBY > 250 HELP > > that's essentially a downgrade attack on my ability to use encryption > which seems to be in pretty poor taste frankly. i think of it as an intentional traffic hijack. i would be talking to a lawyer. randy, who plans to test next time he is behind comcast From bill at herrin.us Sat Nov 29 15:44:35 2014 From: bill at herrin.us (William Herrin) Date: Sat, 29 Nov 2014 10:44:35 -0500 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <17944163.1511.1417143116212.JavaMail.root@benjamin.baylink.com> References: <17944163.1511.1417143116212.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Nov 27, 2014 at 9:51 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "William Herrin" > > I'm not sure I follow your complaint here. Are you saying that Comcast > > or a > > Comcast customer in Washington state stripped the STARTTLS verb from > > the > > IPv4 port 587 SMTP submission connection between you and a third > > party? > > Yup; that's what he's saying. This was in the technical press earlier this > week -- or the end of last. > Hi Jay, Seems to me that if an ISP is altering the contents of its users' packets (not just blocking them, altering them) then that ISP should be named and shamed, if not worse. Unless the customer contracted for special account type where that was a desired and intended feature, such behavior is inexcusable. If it's a customer of that ISP, on the other hand, then it's just the normal idiocy and paranoia, no different than the retarded behavior by amateur sysadmins that block all ICMP because they don't want to be pinged (see PMTUD and its effects on TCP). Anyway, I was curious which accusation was being leveled. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From ammar at fastreturn.net Sat Nov 29 16:06:05 2014 From: ammar at fastreturn.net (Ammar Zuberi) Date: Sat, 29 Nov 2014 20:06:05 +0400 Subject: TeliaSonera IC Contacts In-Reply-To: References: Message-ID: <4AEB9804-7B47-4DA8-8B73-426BEFCA85ED@fastreturn.net> Hi Sander, It's more of a "have to buy from them" as opposed to a "want to buy from them." I'd much prefer NTT, but they are nowhere near where we are unfortunately. Ammar. > On 29 Nov 2014, at 7:25 pm, Sander Steffann wrote: > > Hi, > >> Does anyone have a contact for an account manager at TeliaSonera IC? We’ve sent at least 3 requests for a quote through their website over a month or so and haven’t got a single reply except for the automated “we’ve received your query” email. > > And you still want to buy from them?!? > Sander > From sander at steffann.nl Sat Nov 29 16:07:02 2014 From: sander at steffann.nl (Sander Steffann) Date: Sat, 29 Nov 2014 20:07:02 +0400 Subject: Transparent hijacking of SMTP submission... In-Reply-To: References: <54778167.7080808@bogus.com> Message-ID: <84B714C0-D429-4245-96D0-33BFF0D62CF1@steffann.nl> Op 29 nov. 2014, om 19:37 heeft Randy Bush het volgende geschreven: > i think of it as an intentional traffic hijack. i would be talking to a > lawyer. > > randy, who plans to test next time he is behind comcast I am so glad that our Dutch net neutrality laws state that "providers of Internet access services may not hinder or delay any services or applications on the Internet" (unless [...], but those exceptions make sense) Cheers, Sander From sander at steffann.nl Sat Nov 29 16:08:17 2014 From: sander at steffann.nl (Sander Steffann) Date: Sat, 29 Nov 2014 20:08:17 +0400 Subject: TeliaSonera IC Contacts In-Reply-To: <4AEB9804-7B47-4DA8-8B73-426BEFCA85ED@fastreturn.net> References: <4AEB9804-7B47-4DA8-8B73-426BEFCA85ED@fastreturn.net> Message-ID: <08901EA4-B6E2-4A43-844D-9523AB57540C@steffann.nl> Hi, > It's more of a "have to buy from them" as opposed to a "want to buy from them." I'd much prefer NTT, but they are nowhere near where we are unfortunately. You were talking about Amsterdam, right? There are plenty of transits you can buy from. Cheers, Sander From jfmezei_nanog at vaxination.ca Sat Nov 29 17:26:59 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 29 Nov 2014 12:26:59 -0500 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <84B714C0-D429-4245-96D0-33BFF0D62CF1@steffann.nl> References: <54778167.7080808@bogus.com> <84B714C0-D429-4245-96D0-33BFF0D62CF1@steffann.nl> Message-ID: <547A01E3.1030702@vaxination.ca> On 14-11-29 11:07, Sander Steffann wrote: > I am so glad that our Dutch net neutrality laws state that "providers of Internet access services may not hinder or delay any services or applications on the Internet" (unless [...], but those exceptions make sense) However, in the case of SMTP, due to the amount of spam, most ISPs break "network neutrality" by blocking outbound port 25 for instance, and their SMTP servers will block much incoming emails (spam). However, SMTP is a layer or two above the network. But blocking port 25 is at the network level. I have seen wi-fi systems where you ask to connect to 20.21.22.23 port 25, and you get connected to 50.51.52.53 port 25. (the ISPs own SMTP server). I would rather they just block it than redirect you without warning to an SMTP server of their own where they can look and your outbound email, pretend to acccept it, and never deliver it. From morrowc.lists at gmail.com Sat Nov 29 18:46:05 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 29 Nov 2014 13:46:05 -0500 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <547A01E3.1030702@vaxination.ca> References: <54778167.7080808@bogus.com> <84B714C0-D429-4245-96D0-33BFF0D62CF1@steffann.nl> <547A01E3.1030702@vaxination.ca> Message-ID: backing up a bit in the conversation, perhaps this is just in some regions of comcastlandia? I don't see this in Northern Virginia... $ openssl s_client -starttls smtp -connect my-mailserver.net:587 CONNECTED(00000003) depth=0 description = kVjtrCL8rUdvd00q, C = US, CN = my-mailserver.net, emailAddress = my-emailaddrss.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 description = kVjtrCL8rUdvd00q, C = US, CN = my-mailsever.net, emailAddress = my-emailaddress.com verify error:num=27:certificate not trusted verify return:1 depth=0 description = kVjtrCL8rUdvd00q, C = US, CN = my-mailserver.net, emailAddress = my-emailaddress.com verify error:num=21:unable to verify the first certificate verify return:1 ... Certificate chain 0 s:/description=kVjtrCL8rUdvd00q/C=US/CN=my-mailserver.net/emailAddress=y-emailaddress.com i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA ... New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: FC3E47AF2A2A96BF6DE6E11F96B02A0C41A6542864271F2901F09594DE9A48FA Session-ID-ctx: Master-Key: BE7FB76EF5C0A9BA507B175026F73E67080D6442201FDF28F536FA38197A9B1353D644EEAF8D0D264328F94B2EF5742C Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1417286582 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- 250 DSN ehlo me 250-my-mailserver.net 250-PIPELINING On Sat, Nov 29, 2014 at 12:26 PM, Jean-Francois Mezei wrote: > On 14-11-29 11:07, Sander Steffann wrote: > >> I am so glad that our Dutch net neutrality laws state that "providers of Internet access services may not hinder or delay any services or applications on the Internet" (unless [...], but those exceptions make sense) > > > However, in the case of SMTP, due to the amount of spam, most ISPs break > "network neutrality" by blocking outbound port 25 for instance, and > their SMTP servers will block much incoming emails (spam). However, > SMTP is a layer or two above the network. But blocking port 25 is at the > network level. > > I have seen wi-fi systems where you ask to connect to 20.21.22.23 port > 25, and you get connected to 50.51.52.53 port 25. (the ISPs own SMTP > server). I would rather they just block it than redirect you without > warning to an SMTP server of their own where they can look and your > outbound email, pretend to acccept it, and never deliver it. > > > From johnl at iecc.com Sat Nov 29 20:09:16 2014 From: johnl at iecc.com (John Levine) Date: 29 Nov 2014 20:09:16 -0000 Subject: Transparent hijacking of SMTP submission... In-Reply-To: Message-ID: <20141129200916.30021.qmail@ary.lan> In article you write: >backing up a bit in the conversation, perhaps this is just in some >regions of comcastlandia? I don't see this in Northern Virginia... I don't see it in New Jersey, either. Is this a direct connection, or a coffee shop sharing a cable connection or something like that? From johnl at iecc.com Sat Nov 29 20:17:45 2014 From: johnl at iecc.com (John Levine) Date: 29 Nov 2014 20:17:45 -0000 Subject: Transparent hijacking of SMTP submission... In-Reply-To: Message-ID: <20141129201745.30066.qmail@ary.lan> >i think of it as an intentional traffic hijack. i would be talking to a >lawyer. If the lawyer says anything other than that 47 USC 230(c)(2)(A) provides broad immunity for ISP content filtering, even if the filters sometimes screw up, you need a new lawyer. Filtering STARTTLS on port 587 is pretty stupid, but not everything that's stupid is illegal. R's, John PS: I know enough technical people at Comcast that I would be extremely surprised if it were Comcast doing this. There's plenty not to like about the corporation, but the technical staff are quite competent. From larrysheldon at cox.net Sat Nov 29 20:24:55 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Sat, 29 Nov 2014 14:24:55 -0600 Subject: Transparent hijacking of SMTP submission... In-Reply-To: References: Message-ID: <547A2B97.4040801@cox.net> On 11/29/2014 14:09, John Levine wrote: > In article you write: >> backing up a bit in the conversation, perhaps this is just in some >> regions of comcastlandia? I don't see this in Northern Virginia... > > I don't see it in New Jersey, either. > > Is this a direct connection, or a coffee shop sharing a cable connection or > something like that? I am a little confused but have note yet had time and interest at the same time to back through the thread.... I thought when it started that the complaint was somebody using a public wiffy had been victimized by something I read about recently (and thought it was here that I had red it) where somebody sets up a fraudulent server on the wiffy that advertises a false-flag email "server" that strips out the security stuff and then sends the traffic to an accomplice-site that eventually gets the stripped traffic to its original destination. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From randy at psg.com Sat Nov 29 20:45:06 2014 From: randy at psg.com (Randy Bush) Date: Sat, 29 Nov 2014 15:45:06 -0500 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <20141129201745.30066.qmail@ary.lan> References: <20141129201745.30066.qmail@ary.lan> Message-ID: The STARTTLS filter was merely a tool used to divert and tap the traffic. It is the latter which is over the line. randy, on a teensy non-computer On Nov 29, 2014, at 15:17, John Levine wrote: >> i think of it as an intentional traffic hijack. i would be talking to a >> lawyer. > > If the lawyer says anything other than that 47 USC 230(c)(2)(A) > provides broad immunity for ISP content filtering, even if the filters > sometimes screw up, you need a new lawyer. > > Filtering STARTTLS on port 587 is pretty stupid, but not everything > that's stupid is illegal. > > R's, > John > > PS: I know enough technical people at Comcast that I would be > extremely surprised if it were Comcast doing this. There's plenty not > to like about the corporation, but the technical staff are quite > competent. From saper at saper.info Sat Nov 29 21:43:33 2014 From: saper at saper.info (Marcin Cieslak) Date: Sat, 29 Nov 2014 21:43:33 +0000 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <54778167.7080808@bogus.com> References: <54778167.7080808@bogus.com> Message-ID: On Thu, 27 Nov 2014, joel jaeggli wrote: > I don't see this in my home market, but I do see it in someone else's... > I kind of expect this for port 25 but... > > J at mb-aye:~$telnet 147.28.0.81 587 > Trying 147.28.0.81... > Connected to nagasaki.bogus.com. > Escape character is '^]'. > 220 nagasaki.bogus.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 27 Nov 2014 > 19:17:44 GMT > ehlo bogus.com > 250-nagasaki.bogus.com Hello XXXXXXXXXXXXXXX.wa.comcast.net > [XXX.XXX.XXX.XXX], pleased to meet you > 250 ENHANCEDSTATUSCODES Seen some anti-virus software (on Windows) doing this. You might not be running Windows though. Some home router with some "security improvement" ? //Marcin From mansaxel at besserwisser.org Sat Nov 29 23:19:50 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 30 Nov 2014 00:19:50 +0100 Subject: Phasing out of copper In-Reply-To: <547898BB.80002@vaxination.ca> References: <547898BB.80002@vaxination.ca> Message-ID: <20141129231949.GA32236@besserwisser.org> Subject: Phasing out of copper Date: Fri, Nov 28, 2014 at 10:46:03AM -0500 Quoting Jean-Francois Mezei (jfmezei_nanog at vaxination.ca): > Currently in the midst of a CRTC policy hearing in Canada on future of > competition in ISPs. > > Incumbents claim they have no plans to retire their copper plant after > deploying FTTP/FTTH. (strategically to convince regulator that keeping > ISPs on copper is fine and no need to let them access FTTP). Maintaining copper plant is expensive. It will be retired as soon as buy-in on FTTH is high enough. Telia Sonera is doing it in Sweden, so the trend is global. (OTOH, in Sweden, young people moving out from their parents, if they can find somewhere to rent, usually only get a fixed connection for Internet access. Telephony is all mobile.) -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Four thousand different MAGNATES, MOGULS & NABOBS are romping in my gothic solarium!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From cdaniel at nurve.com.au Sun Nov 30 00:05:05 2014 From: cdaniel at nurve.com.au (Cameron Daniel) Date: Sun, 30 Nov 2014 10:05:05 +1000 Subject: Phasing out of copper In-Reply-To: <20141129231949.GA32236@besserwisser.org> References: <547898BB.80002@vaxination.ca> <20141129231949.GA32236@besserwisser.org> Message-ID: <2609cef2da6003a601602568de73df10@nurve.com.au> On 2014-11-30 9:19 am, Måns Nilsson wrote: > Maintaining copper plant is expensive. It will be retired as soon as > buy-in on FTTH is high enough. Telia Sonera is doing it in Sweden, > so the trend is global. (OTOH, in Sweden, young people moving out from > their parents, if they can find somewhere to rent, usually only get a > fixed connection for Internet access. Telephony is all mobile.) This is pretty common in other countries as well. At a $JOB-1 in Australia all our residential DSL services were provided over ULLs and came with a dial tone provided by us but only a tiny fraction of active lines ever made or received a call. From morrowc.lists at gmail.com Sun Nov 30 02:32:24 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 29 Nov 2014 21:32:24 -0500 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <20141129200916.30021.qmail@ary.lan> References: <20141129200916.30021.qmail@ary.lan> Message-ID: On Sat, Nov 29, 2014 at 3:09 PM, John Levine wrote: > In article you write: >>backing up a bit in the conversation, perhaps this is just in some >>regions of comcastlandia? I don't see this in Northern Virginia... > > I don't see it in New Jersey, either. > > Is this a direct connection, or a coffee shop sharing a cable connection or > something like that? my test was a home consumer cable link, not business grade and not shared (more than cable is). From joelja at bogus.com Sun Nov 30 03:27:06 2014 From: joelja at bogus.com (joel jaeggli) Date: Sat, 29 Nov 2014 19:27:06 -0800 Subject: Transparent hijacking of SMTP submission... In-Reply-To: References: <20141129200916.30021.qmail@ary.lan> Message-ID: <547A8E8A.3010203@bogus.com> On 11/29/14 6:32 PM, Christopher Morrow wrote: > On Sat, Nov 29, 2014 at 3:09 PM, John Levine wrote: >> In article you write: >>> backing up a bit in the conversation, perhaps this is just in some >>> regions of comcastlandia? I don't see this in Northern Virginia... >> >> I don't see it in New Jersey, either. >> >> Is this a direct connection, or a coffee shop sharing a cable connection or >> something like that? > > my test was a home consumer cable link, not business grade and not > shared (more than cable is). The phenomena I reported was observed on a consumer cable service (not my own). it is now no-longer in evidence with that same source ip. In answer an intermediate observation, the cpe and the devices on it are sufficiently well understood now to rule them out. from the mail servers vantage point... Nov 27 xxxxx nagasaki sm-mta[5698]: NOQUEUE: tcpwrappers ((reverse).wa.comcast.net, (ip) ) rejection given that the client gives up because it can't startssl and therefore won't attempt to auth. whereas a successful attempt with the same source ip is: Nov 26 xxxxx nagasaki sm-mta[397]: STARTTLS=server, relay=c-(reverse).wa.comcast.net [(ip)], version=TLSv1/SSLv3, verify=NOT, cipher=DHE-RSA-AES128-SHA, bits=128/128 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From morrowc.lists at gmail.com Sun Nov 30 04:43:37 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 29 Nov 2014 23:43:37 -0500 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <547A8E8A.3010203@bogus.com> References: <20141129200916.30021.qmail@ary.lan> <547A8E8A.3010203@bogus.com> Message-ID: On Sat, Nov 29, 2014 at 10:27 PM, joel jaeggli wrote: > On 11/29/14 6:32 PM, Christopher Morrow wrote: >> On Sat, Nov 29, 2014 at 3:09 PM, John Levine wrote: >>> In article you write: >>>> backing up a bit in the conversation, perhaps this is just in some >>>> regions of comcastlandia? I don't see this in Northern Virginia... >>> >>> I don't see it in New Jersey, either. >>> >>> Is this a direct connection, or a coffee shop sharing a cable connection or >>> something like that? >> >> my test was a home consumer cable link, not business grade and not >> shared (more than cable is). > > The phenomena I reported was observed on a consumer cable service (not > my own). it is now no-longer in evidence with that same source ip. In > answer an intermediate observation, the cpe and the devices on it are > sufficiently well understood now to rule them out. ah, phew. > > from the mail servers vantage point... > > Nov 27 xxxxx nagasaki sm-mta[5698]: NOQUEUE: tcpwrappers > ((reverse).wa.comcast.net, (ip) ) rejection > super odd, and telling. > given that the client gives up because it can't startssl and therefore > won't attempt to auth. > > whereas a successful attempt with the same source ip is: > > Nov 26 xxxxx nagasaki sm-mta[397]: STARTTLS=server, > relay=c-(reverse).wa.comcast.net [(ip)], version=TLSv1/SSLv3, > verify=NOT, cipher=DHE-RSA-AES128-SHA, bits=128/128 > perhaps comcast (technician) was trying to do the 'right thing' here and mistook 'but someone is operating a mailserver that the trust' vs 'spammer' from the situation with TLS being 'a good thing' and 'please do not subvert my tls, yo!' glad to see this returned to expected flows. From jra at baylink.com Sun Nov 30 05:09:40 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 30 Nov 2014 00:09:40 -0500 (EST) Subject: Phasing out of telco TDM Backbones (was: Phasing out of copper) In-Reply-To: <20141129231949.GA32236@besserwisser.org> Message-ID: <18221846.1693.1417324180226.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Måns Nilsson" > Maintaining copper plant is expensive. It will be retired as soon as > buy-in on FTTH is high enough. Telia Sonera is doing it in Sweden, > so the trend is global. (OTOH, in Sweden, young people moving out from > their parents, if they can find somewhere to rent, usually only get a > fixed connection for Internet access. Telephony is all mobile.) Absolutely: maintaining analog copper last-mile is expensive. But let us not conflate being ok with telcos replacing analog copper last-mile with being ok with telcos replacing PCM with VoIP, especially in trunking applications, and *especially* using non-dedicated backbones, as these are the directions the RBOCs appear to be going in, and those are much less acceptable ideas than the former. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From nathana at fsr.com Sun Nov 30 05:37:05 2014 From: nathana at fsr.com (Nathan Anderson) Date: Sat, 29 Nov 2014 21:37:05 -0800 Subject: Phasing out of telco TDM Backbones (was: Phasing out of copper) In-Reply-To: <18221846.1693.1417324180226.JavaMail.root@benjamin.baylink.com> References: <20141129231949.GA32236@besserwisser.org> <18221846.1693.1417324180226.JavaMail.root@benjamin.baylink.com> Message-ID: On Saturday, November 29, 2014 9:10 PM, Jay Ashworth <> wrote: > But let us not conflate being ok with telcos replacing analog copper > last-mile with being ok with telcos replacing PCM with VoIP, especially > in trunking applications, ... [snip] Let's also not conflate audio codecs with L2. "PCM" and "VoIP" are not mutually-exclusive things by any stretch. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From jra at baylink.com Sun Nov 30 05:59:58 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 30 Nov 2014 00:59:58 -0500 (EST) Subject: Phasing out of telco TDM Backbones (was: Phasing out of copper) In-Reply-To: Message-ID: <17948144.1695.1417327198223.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Nathan Anderson" kbones (was: Phasing out of copper) > On Saturday, November 29, 2014 9:10 PM, Jay Ashworth <> wrote: > > But let us not conflate being ok with telcos replacing analog copper > > last-mile with being ok with telcos replacing PCM with VoIP, > > especially > > in trunking applications, ... [snip] > > Let's also not conflate audio codecs with L2. "PCM" and "VoIP" are not > mutually-exclusive things by any stretch. Oh, sure. But my point is this: How many Erlangs can you fit through that clear-channel T-3? There's man-centuries of engineering in the design of the TDM backbone, and the people making the decisions about abandoning that design weren't even alive, in some cases, when that work was done, and don't know what "Notes On The Networks" is. Cheers, -- jr 'I can lay hands on my copy in 60 seconds' a -- Jay R. Ashworth Baylink jra at 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 From magicsata at gmail.com Sun Nov 30 06:01:45 2014 From: magicsata at gmail.com (Alistair Mackenzie) Date: Sun, 30 Nov 2014 06:01:45 +0000 Subject: TeliaSonera IC Contacts In-Reply-To: <08901EA4-B6E2-4A43-844D-9523AB57540C@steffann.nl> References: <4AEB9804-7B47-4DA8-8B73-426BEFCA85ED@fastreturn.net> <08901EA4-B6E2-4A43-844D-9523AB57540C@steffann.nl> Message-ID: I'd be inclined to not buy from them if they are not replying to sales emails. You've got to ask what their NOC will be like once you are a customer... On 29 November 2014 at 16:08, Sander Steffann wrote: > Hi, > > > It's more of a "have to buy from them" as opposed to a "want to buy from > them." I'd much prefer NTT, but they are nowhere near where we are > unfortunately. > > You were talking about Amsterdam, right? There are plenty of transits you > can buy from. > > Cheers, > Sander > > From tony at lavanauts.org Sun Nov 30 06:50:24 2014 From: tony at lavanauts.org (Antonio Querubin) Date: Sat, 29 Nov 2014 20:50:24 -1000 (HST) Subject: Phasing out of telco TDM Backbones (was: Phasing out of copper) In-Reply-To: <17948144.1695.1417327198223.JavaMail.root@benjamin.baylink.com> References: <17948144.1695.1417327198223.JavaMail.root@benjamin.baylink.com> Message-ID: On Sun, 30 Nov 2014, Jay Ashworth wrote: > Oh, sure. But my point is this: > > How many Erlangs can you fit through that clear-channel T-3? Personally I find the use of Erlangs in a packet-switched environment somewhat irrelevant. What has been more useful me in capacity planning and staying out of trouble has been statistical bandwidth peak usage data. Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From bill at herrin.us Sun Nov 30 09:03:33 2014 From: bill at herrin.us (William Herrin) Date: Sun, 30 Nov 2014 04:03:33 -0500 Subject: Transparent hijacking of SMTP submission... In-Reply-To: <547A8E8A.3010203@bogus.com> References: <20141129200916.30021.qmail@ary.lan> <547A8E8A.3010203@bogus.com> Message-ID: n Sat, Nov 29, 2014 at 10:27 PM, joel jaeggli wrote: > The phenomena I reported was observed on a consumer cable service (not > my own). it is now no-longer in evidence with that same source ip. In > answer an intermediate observation, the cpe and the devices on it are > sufficiently well understood now to rule them out. > Hope it's not law enforcement tapping your line. They'd be damn fools to make themselves so easily detectable. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: May I solve your unusual networking challenges? From mansaxel at besserwisser.org Sun Nov 30 09:30:57 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 30 Nov 2014 10:30:57 +0100 Subject: Phasing out of telco TDM Backbones (was: Phasing out of copper) In-Reply-To: <18221846.1693.1417324180226.JavaMail.root@benjamin.baylink.com> References: <20141129231949.GA32236@besserwisser.org> <18221846.1693.1417324180226.JavaMail.root@benjamin.baylink.com> Message-ID: <20141130093056.GB32236@besserwisser.org> Subject: Phasing out of telco TDM Backbones (was: Phasing out of copper) Date: Sun, Nov 30, 2014 at 12:09:40AM -0500 Quoting Jay Ashworth (jra at baylink.com): > ----- Original Message ----- > > From: "Måns Nilsson" > > > Maintaining copper plant is expensive. It will be retired as soon as > > buy-in on FTTH is high enough. Telia Sonera is doing it in Sweden, > > so the trend is global. (OTOH, in Sweden, young people moving out from > > their parents, if they can find somewhere to rent, usually only get a > > fixed connection for Internet access. Telephony is all mobile.) > > Absolutely: maintaining analog copper last-mile is expensive. > > But let us not conflate being ok with telcos replacing analog copper last-mile > with being ok with telcos replacing PCM with VoIP, especially in trunking > applications, and *especially* using non-dedicated backbones, as these are the > directions the RBOCs appear to be going in, and those are much less acceptable > ideas than the former. Sadly enough, those man-centuries need to be reread in the light of the fact that today, you can not buy most of those connections anymore. Voice circuits are almost entirely trunked on IP; and the telcos fight to decommission the carrier formats. From 2014-12-31, you can't keep your 128kbit ISDN anymore in Sweden. This is a big issue for me, since I work with radio broadcasting. There, 128kbit ISDN is a very common way to do remote broadcasting from sports or similar events. We've been frantically buying and building a new network to replace these circuits, and have built a quite nice system on top of IP. The old ISDN codec phones (essentially small pro mixer + A/D converter + MPEG codec + ISDN terminal) are being replaced by similar-looking specialised SIP phones sporting much higher sound quality. If the network permits (and, on those sites where we expect to do live music, it does permit so) we can do 48KHz 24bit uncompressed stereo -- which is around 2,6 Mbit without protection by FEC. Since the voice circuit is mostly being replaced by the Skype/FaceTime call, this is not only a special observation; it is, I believe, a general case. Our challenge thus lies not in preserving circuit-switching, but instead in building an open, standards-based voice infrastructure on top of IP. Viewed in that light, Skype and FaceTime are failures. I'm not certain their owners see it that way. /Måns, who *really* would like to have STM-64 frames instead of TenGig Ethernet for his long lines. Switched Ethernet is herded chaos. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ANN JILLIAN'S HAIR makes LONI ANDERSON'S HAIR look like RICARDO MONTALBAN'S HAIR! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From simon.leinen at switch.ch Sun Nov 30 13:57:07 2014 From: simon.leinen at switch.ch (Simon Leinen) Date: Sun, 30 Nov 2014 14:57:07 +0100 Subject: Low-numbered ASes being hijacked? [Re: BGP Update Report] In-Reply-To: <201411282200.sASM024G003029@wattle.apnic.net> (cidr-report@potaroo.net's message of "Fri, 28 Nov 2014 22:00:02 GMT") References: <201411282200.sASM024G003029@wattle.apnic.net> Message-ID: cidr-report writes: > BGP Update Report > Interval: 20-Nov-14 -to- 27-Nov-14 (7 days) > Observation Point: BGP Peering with AS131072 > TOP 20 Unstable Origin AS > Rank ASN Upds % Upds/Pfx AS-Name [...] > 11 - AS5 38861 0.6% 7.0 -- SYMBOLICS - Symbolics, Inc.,US Disappointing to see Symbolics (AS5) on this list. I would expect these Lisp Machines to have very stable BGP implementations, especially given the leisurely release rhythm for Genera for the past few decades. Has the size of the IPv4 unicast table started triggering global GCs? Seriously, all these low-numbered ASes in the report look fishy. I would have liked this to be an artifact of the reporting software (maybe an issue with 4-byte ASes?), but I do see some strange paths in the BGP table that make it look like (accidental or malicious) hi-hacking of these low-numbered ASes. Now the fact that these AS numbers are low makes me curious. If I wanted to hijack other folks' ASes deliberately, I would probably avoid such numbers because they stand out. Maybe these are just non-standard "private-use" ASes that are leaked? Some suspicious paths I'm seeing right now: 133439 5 197945 4 Hm, maybe 32-bit ASes do have something to do with this... Any ideas? -- Simon. (Just curious) [...] > 17 - AS3 30043 0.4% 3185.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US [...] > TOP 20 Unstable Origin AS (Updates per announced prefix) > Rank ASN Upds % Upds/Pfx AS-Name [...] > 13 - AS5 38861 0.6% 7.0 -- SYMBOLICS - Symbolics, Inc.,US [...] > 15 - AS4 21237 0.3% 871.0 -- ISI-AS - University of Southern California,US [...] > 19 - AS4 5345 0.1% 1437.0 -- ISI-AS - University of Southern California,US > 20 - AS4 8784 0.1% 2303.0 -- ISI-AS - University of Southern California,US From pf at tippete.net Sun Nov 30 14:24:03 2014 From: pf at tippete.net (Pierfrancesco Caci) Date: Sun, 30 Nov 2014 15:24:03 +0100 Subject: Low-numbered ASes being hijacked? [Re: BGP Update Report] In-Reply-To: (Simon Leinen's message of "Sun, 30 Nov 2014 14:57:07 +0100") References: <201411282200.sASM024G003029@wattle.apnic.net> Message-ID: <877fyc4vi4.fsf@snoopy.tippete.net> >>>>> "Simon" == Simon Leinen writes: Simon> Some suspicious paths I'm seeing right now: Simon> 133439 5 Simon> 197945 4 my bet is on someone using the syntax "prepend asnX timesY" on a router that instead wants "prepend asnX asnX...." -- Pierfrancesco Caci, ik5pvx From contact at winterei.se Sun Nov 30 15:53:07 2014 From: contact at winterei.se (Paul S.) Date: Mon, 01 Dec 2014 00:53:07 +0900 Subject: Low-numbered ASes being hijacked? [Re: BGP Update Report] In-Reply-To: <877fyc4vi4.fsf@snoopy.tippete.net> References: <201411282200.sASM024G003029@wattle.apnic.net> <877fyc4vi4.fsf@snoopy.tippete.net> Message-ID: <547B3D63.9080707@winterei.se> Do these people never check what exactly they end up originating outbound due to a config change, if that's really the case? On 11/30/2014 午後 11:24, Pierfrancesco Caci wrote: >>>>>> "Simon" == Simon Leinen writes: > Simon> Some suspicious paths I'm seeing right now: > > Simon> 133439 5 > Simon> 197945 4 > > my bet is on someone using the syntax "prepend asnX timesY" on a router > that instead wants "prepend asnX asnX...." > From hhoffman at ip-solutions.net Sun Nov 30 16:11:32 2014 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Sun, 30 Nov 2014 11:11:32 -0500 Subject: Low-numbered ASes being hijacked? [Re: BGP Update Report] Message-ID: <20141130161135.DBFD91F438@pb-smtp1.pobox.com> I'm currently looking into AS3 in an attempt to figure out what's going on. Always interested to hear what others have found out. Cheers, Harry On Nov 30, 2014 8:57 AM, Simon Leinen wrote: > > cidr-report  writes: > > BGP Update Report > > Interval: 20-Nov-14 -to- 27-Nov-14 (7 days) > > Observation Point: BGP Peering with AS131072 > > > TOP 20 Unstable Origin AS > > Rank ASN                Upds     %  Upds/Pfx    AS-Name > [...] > > 11 - AS5               38861  0.6%       7.0 -- SYMBOLICS - Symbolics, Inc.,US > > Disappointing to see Symbolics (AS5) on this list.  I would expect these > Lisp Machines to have very stable BGP implementations, especially given > the leisurely release rhythm for Genera for the past few decades.  Has > the size of the IPv4 unicast table started triggering global GCs? > > Seriously, all these low-numbered ASes in the report look fishy.  I > would have liked this to be an artifact of the reporting software (maybe > an issue with 4-byte ASes?), but I do see some strange paths in the BGP > table that make it look like (accidental or malicious) hi-hacking of > these low-numbered ASes. > > Now the fact that these AS numbers are low makes me curious.  If I > wanted to hijack other folks' ASes deliberately, I would probably avoid > such numbers because they stand out.  Maybe these are just non-standard > "private-use" ASes that are leaked? > > Some suspicious paths I'm seeing right now: > >   133439 5 >   197945 4 > > Hm, maybe 32-bit ASes do have something to do with this... > > Any ideas? > -- > Simon. (Just curious) > > [...] > > 17 - AS3               30043  0.4%    3185.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US > [...] > > > TOP 20 Unstable Origin AS (Updates per announced prefix) > > Rank ASN                Upds     %  Upds/Pfx    AS-Name > [...] > > 13 - AS5               38861  0.6%       7.0 -- SYMBOLICS - Symbolics, Inc.,US > [...] > > 15 - AS4               21237  0.3%     871.0 -- ISI-AS - University of Southern California,US > [...] > > 19 - AS4                5345  0.1%    1437.0 -- ISI-AS - University of Southern California,US > > 20 - AS4                8784  0.1%    2303.0 -- ISI-AS - University of Southern California,US From Valdis.Kletnieks at vt.edu Sun Nov 30 19:26:11 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 30 Nov 2014 14:26:11 -0500 Subject: Low-numbered ASes being hijacked? [Re: BGP Update Report] In-Reply-To: Your message of "Mon, 01 Dec 2014 00:53:07 +0900." <547B3D63.9080707@winterei.se> References: <201411282200.sASM024G003029@wattle.apnic.net> <877fyc4vi4.fsf@snoopy.tippete.net> <547B3D63.9080707@winterei.se> Message-ID: <248721.1417375571@turing-police.cc.vt.edu> On Mon, 01 Dec 2014 00:53:07 +0900, "Paul S." said: > Do these people never check what exactly they end up originating > outbound due to a config change, if that's really the case? You're new here, aren't you? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From nanog-post at rsuc.gweep.net Sun Nov 30 19:43:30 2014 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sun, 30 Nov 2014 14:43:30 -0500 Subject: Low-numbered ASes being hijacked? [Re: BGP Update Report] In-Reply-To: <547B3D63.9080707@winterei.se> References: <201411282200.sASM024G003029@wattle.apnic.net> <877fyc4vi4.fsf@snoopy.tippete.net> <547B3D63.9080707@winterei.se> Message-ID: <20141130194329.GA24727@gweep.net> On Mon, Dec 01, 2014 at 12:53:07AM +0900, Paul S. wrote: > Do these people never check what exactly they end up originating > outbound due to a config change, if that's really the case? Of course not because their neighbors are allowing it to pass; so as with all hijacks, deaggregation, and other unfiltered noise, the only care is traffic going in and out. QA (let alone automated sanity checks) are alien concepts to many, and "well it works" is the answer from some when contacted. It smells like this is as PF surmises and might just be folks amenable to fixing it when contacted. We'll see... Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG From list at satchell.net Sun Nov 30 19:54:34 2014 From: list at satchell.net (Stephen Satchell) Date: Sun, 30 Nov 2014 11:54:34 -0800 Subject: Low-numbered ASes being hijacked? [Re: BGP Update Report] In-Reply-To: <248721.1417375571@turing-police.cc.vt.edu> References: <201411282200.sASM024G003029@wattle.apnic.net> <877fyc4vi4.fsf@snoopy.tippete.net> <547B3D63.9080707@winterei.se> <248721.1417375571@turing-police.cc.vt.edu> Message-ID: <547B75FA.5030908@satchell.net> On 11/30/2014 11:26 AM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 01 Dec 2014 00:53:07 +0900, "Paul S." said: >> Do these people never check what exactly they end up originating >> outbound due to a config change, if that's really the case? > > You're new here, aren't you? :) Thank you, I needed the laugh. Sometimes, getting the idea that checking one's work is necessary proves to be a hard lesson to teach to some of those young whippersnappers. I live and work in Reno NV, so I put the lesson in terms they can understand: "A triple check beats a double-cross." This is sufficiently annoying to people that they do indeed check their work...so they don't have to listen to me spout this cliche when things get screwed up. From andree+nanog at toonk.nl Sun Nov 30 19:57:19 2014 From: andree+nanog at toonk.nl (Andree Toonk) Date: Sun, 30 Nov 2014 11:57:19 -0800 Subject: Low-numbered ASes being hijacked? [Re: BGP Update Report] In-Reply-To: <877fyc4vi4.fsf@snoopy.tippete.net> References: <201411282200.sASM024G003029@wattle.apnic.net> <877fyc4vi4.fsf@snoopy.tippete.net> Message-ID: <547B769F.4060702@toonk.nl> .-- My secret spy satellite informs me that at 2014-11-30 6:24 AM Pierfrancesco Caci wrote: >>>>>> "Simon" == Simon Leinen writes: > > Simon> Some suspicious paths I'm seeing right now: > > Simon> 133439 5 > Simon> 197945 4 > > my bet is on someone using the syntax "prepend asnX timesY" on a router > that instead wants "prepend asnX asnX...." I agree. When looking at distribution of ASns that appear to be hijacking prefixes, the lower number ASns stand out. AS1,2,3,4,5 are common. When looking closer, the next-hop AS is typically the 'expected' AS, which would confirm the prepend theory. 185.78.114.0/24 was announced as ".* 47551 5" and but now as ".* 47551". I guess they found out the 5x prepending didn't work as expected. AS3 (MIT) seems to be particularly popular, probably by folks who attempt to prepend 3 times. Here's a current example: 212.69.8.0/23 [BGP/170] 6d 05:45:32, MED 22007, localpref 100 AS path: 3356 15958 52116 3 I This is a prefix in Serbia, routes to Serbia and doesn't seem to be related to MIT (AS3) at all. Another example: AS35819, Etihad Etisalat was originating some of its prefixes as AS1 earlier this week as well. https://twitter.com/bgpmon/status/537062576002064385 Just a few examples. Cheers, Andree From colton.conor at gmail.com Sun Nov 30 20:14:21 2014 From: colton.conor at gmail.com (Colton Conor) Date: Sun, 30 Nov 2014 14:14:21 -0600 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: <867fyhrfsh.fsf@valhalla.seastrom.com> References: <867fyhrfsh.fsf@valhalla.seastrom.com> Message-ID: Yes, we could of course pay for some space and power with a shared hosting provider, but buying a full rack and power for a single router seems silly. The ideal person to buy the small amount of space and power from would be the transport provider that is transporting us to Equinix, but in most cases those are large providers like Level3 who aren't interested nor willing to sell us a quarter of a cabinet. If we were to get space directly with Equnix then we would have yet another cross connect from the transport provider to our rack. The whole point on getting to the exchange is to peer with providers like Netflix and Google as this would be for an eyeball network, but after you add up the cost of the rack, power, cross connects, exchange ports, etcs I am not seeing the value in doing so. Espically with some of the Tier 1's willing to sell us Gbps IP transit links for almost the cost of the transport back to an peering location. On Wed, Nov 26, 2014 at 12:13 PM, Rob Seastrom wrote: > > Colton Conor writes: > > > Some might ask why not get a cross connect to the provider. It is cheaper > > to buy an port on the exchange (which includes the cross connect to the > > exchange) than buy multiple cross connects. Plus we are planning on > getting > > a wave to the exchange, and not having any physical routers or switches > at > > the datacenter where the exchange/wave terminates at. Is this possible? > > "Technically possible" and "advisable" are two different things. If > you enjoy finger-pointing on the occasions where you are trying to > smoke out performance issues, I encourage as many third, fourth, and > fifth-party-managed network layers in the mix as possible. A wave > with no way to test to the handoff point would of course be the icing > on the cake. > > Are you sure you can't afford to sublet a few ru of space from someone > and pay for a couple extra cross connects? > > -r > > From jra at baylink.com Sun Nov 30 20:37:34 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 30 Nov 2014 15:37:34 -0500 (EST) Subject: Low-numbered ASes being hijacked? [Re: BGP Update Report] In-Reply-To: <20141130194329.GA24727@gweep.net> Message-ID: <19868845.1771.1417379854468.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joe Provo" > On Mon, Dec 01, 2014 at 12:53:07AM +0900, Paul S. wrote: > > Do these people never check what exactly they end up originating > > outbound due to a config change, if that's really the case? > > Of course not because their neighbors are allowing it to > pass; so as with all hijacks, deaggregation, and other > unfiltered noise, the only care is traffic going in and > out. QA (let alone automated sanity checks) are alien > concepts to many, and "well it works" is the answer from > some when contacted. That's sort of the BGP equivalent to BCP38 filtering, isn't it? Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From jason at rice.edu Sun Nov 30 20:57:31 2014 From: jason at rice.edu (Jason Bothe) Date: Sun, 30 Nov 2014 14:57:31 -0600 Subject: Low-numbered ASes being hijacked? [Re: BGP Update Report] In-Reply-To: <19868845.1771.1417379854468.JavaMail.root@benjamin.baylink.com> References: <19868845.1771.1417379854468.JavaMail.root@benjamin.baylink.com> Message-ID: I’m not new here but the thread caught my eye, as I am one of the lower ASs being mentioned. I guess there isn’t really anything one can do to prevent these things other than listening to route servers, etc. I guess it’s all on what the upstream decides to allow-in and re-advertise. Jason Jason Bothe, Manager of Networking o +1 713 348 5500 m +1 713 703 3552 jason at rice.edu On 30, Nov 2014, at 2:37 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Joe Provo" > >> On Mon, Dec 01, 2014 at 12:53:07AM +0900, Paul S. wrote: >>> Do these people never check what exactly they end up originating >>> outbound due to a config change, if that's really the case? >> >> Of course not because their neighbors are allowing it to >> pass; so as with all hijacks, deaggregation, and other >> unfiltered noise, the only care is traffic going in and >> out. QA (let alone automated sanity checks) are alien >> concepts to many, and "well it works" is the answer from >> some when contacted. > > That's sort of the BGP equivalent to BCP38 filtering, isn't it? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at 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 > From surfer at mauigateway.com Sun Nov 30 22:19:06 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 30 Nov 2014 14:19:06 -0800 Subject: Low-numbered ASes being hijacked? [Re: BGP Update Report] Message-ID: <20141130141906.81049E9D@m0005297.ppops.net> > ----- Original Message ----- >>> Do these people never check what exactly they end up originating >>> outbound due to a config change, if that's really the case? >> >> Of course not because their neighbors are allowing it to >> pass; so as with all hijacks, deaggregation, and other >> unfiltered noise, the only care is traffic going in and >> out. QA (let alone automated sanity checks) are alien >> concepts to many, and "well it works" is the answer from >> some when contacted. > > That's sort of the BGP equivalent to BCP38 filtering, isn't it? --- jason at rice.edu wrote: From: Jason Bothe I’m not new here but the thread caught my eye, as I am one of the lower ASs being mentioned. I guess there isn’t really anything one can do to prevent these things other than listening to route servers, etc. I guess it’s all on what the upstream decides to allow-in and re-advertise. ---------------------------------------------------------------- First, obviously, set BGP filters to allow only what you expect to send upstream. Then, look at what your routers are advertising to your upstreams using 'sho bgp advertised routes' type commands to make sure it's exactly what you're expecting to send. Last, look on route servers at various places around the internet to make sure everything is advertised to expectations . You can find a lot here: http://www.traceroute.org/#Route%20Servers Also, of course, all of this can be done on a regular basis using programs instead of being done manually. scott From clayton at mnsi.net Sun Nov 30 23:13:40 2014 From: clayton at mnsi.net (Clayton) Date: Sun, 30 Nov 2014 18:13:40 -0500 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: Message-ID: When we first lit our wavelength to Chicago, we had them terminate it in a cabinet at Equnix. We then had our transit provider terminate in the cabinet and we threw a patch cable in. No power ordered initially. It served its purpose for the interim, but we eventually put a switch in once we connected to Equnix's peering service too. During the period where we simply had a cross connect with no active equipment, we didn't really have any problems with it, but I agree it isn't the best situation. I was actually pretty amazed at how much traffic we had shift over to peering once we turned up - significant. I'd say that we now get 2/3 of our inbound by peering, the rest via transit. Netflix is the obvious reason... ----- Original Message --------------- Subject: Re: Buying IP Bandwidth Across a Peering Exchange From: Colton Conor Date: Sun, 30 Nov 2014 14:14:21 -0600 To: Rob Seastrom Cc: NANOG Yes, we could of course pay for some space and power with a shared hosting provider, but buying a full rack and power for a single router seems silly. The ideal person to buy the small amount of space and power from would be the transport provider that is transporting us to Equinix, but in most cases those are large providers like Level3 who aren't interested nor willing to sell us a quarter of a cabinet. If we were to get space directly with Equnix then we would have yet another cross connect from the transport provider to our rack. The whole point on getting to the exchange is to peer with providers like Netflix and Google as this would be for an eyeball network, but after you add up the cost of the rack, power, cross connects, exchange ports, etcs I am not seeing the value in doing so. Espically with some of the Tier 1's willing to sell us Gbps IP transit links for almost the cost of the transport back to an peering location. On Wed, Nov 26, 2014 at 12:13 PM, Rob Seastrom wrote: > > Colton Conor writes: > > > Some might ask why not get a cross connect to the provider. It is cheaper > > to buy an port on the exchange (which includes the cross connect to the > > exchange) than buy multiple cross connects. Plus we are planning on > getting > > a wave to the exchange, and not having any physical routers or switches > at > > the datacenter where the exchange/wave terminates at. Is this possible? > > "Technically possible" and "advisable" are two different things. If > you enjoy finger-pointing on the occasions where you are trying to > smoke out performance issues, I encourage as many third, fourth, and > fifth-party-managed network layers in the mix as possible. A wave > with no way to test to the handoff point would of course be the icing > on the cake. > > Are you sure you can't afford to sublet a few ru of space from someone > and pay for a couple extra cross connects? > > -r > > From lists at mtin.net Sun Nov 30 23:41:23 2014 From: lists at mtin.net (Justin Wilson) Date: Sun, 30 Nov 2014 18:41:23 -0500 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: References: Message-ID: Having run an exchange, I can speak to a couple of points. 1.An exchange is only as good as any other provider. If they don¹t have a redundant design then you have more room for failure. Same can be said about good staff behind it. If they know what they are doing and keep it simple, then it can be a very advantageous thing to you. 2.An exchange really shines in data centers where you have to pay for cross connects. I can buy 1 10 gig connection to an exchange in Chicago and peer with 30 other providers easy. If I were to run a cross connect to each provider directly that would cost me between 7 and 9 grand a month in an Equinix data center. Instead I am paying $1300 for the same thing. If I want a private vlan add on a little extra. 3.Some exchanges carry weight with the folks like Netflix and others. In most cases, they will peer with you easier on an exchange than a direct connection. Keep in mind switch ports cost money, especially in a dense data center. Justin -- Justin Wilson http://www.mtin.net Managed Services ­ xISP Solutions ­ Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering ­ Transit ­ Internet Exchange From clayton at mnsi.net Sun Nov 30 23:51:07 2014 From: clayton at mnsi.net (Clayton) Date: Sun, 30 Nov 2014 18:51:07 -0500 Subject: Buying IP Bandwidth Across a Peering Exchange In-Reply-To: Message-ID: We peer at TorIX and Equinix. I have to say that despite the fact that Equnix charges us more for our port, we're getting far more value from it than TorIX. Around double the traffic, and they don't have silly punative measures like locking your port if you leak a MAC address other than the one you registered with them (Equnix filters the MAC, but doesn't apply a 60 minute port shut down penalty if you leak like TorIX does). ----- Original Message --------------- Subject: Re: Buying IP Bandwidth Across a Peering Exchange From: Justin Wilson Date: Sun, 30 Nov 2014 18:41:23 -0500 To: NANOG Having run an exchange, I can speak to a couple of points. 1.An exchange is only as good as any other provider. If they don¹t have a redundant design then you have more room for failure. Same can be said about good staff behind it. If they know what they are doing and keep it simple, then it can be a very advantageous thing to you. 2.An exchange really shines in data centers where you have to pay for cross connects. I can buy 1 10 gig connection to an exchange in Chicago and peer with 30 other providers easy. If I were to run a cross connect to each provider directly that would cost me between 7 and 9 grand a month in an Equinix data center. Instead I am paying $1300 for the same thing. If I want a private vlan add on a little extra. 3.Some exchanges carry weight with the folks like Netflix and others. In most cases, they will peer with you easier on an exchange than a direct connection. Keep in mind switch ports cost money, especially in a dense data center. Justin -- Justin Wilson http://www.mtin.net Managed Services ­ xISP Solutions ­ Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering ­ Transit ­ Internet Exchange From joelja at bogus.com Sun Nov 30 23:55:16 2014 From: joelja at bogus.com (joel jaeggli) Date: Sun, 30 Nov 2014 15:55:16 -0800 Subject: Multi-homing with multiple ASNs In-Reply-To: <547363BD.8040908@dcrocker.net> References: <848A0CCBF45ABC49B103A3733FA46C506427FB@MTEXMBC01.fsa.mtsu.edu> <201411211107.50085.mark.tinka@seacom.mu> <54723394.5000009@bogus.com> <547363BD.8040908@dcrocker.net> Message-ID: <547BAE64.5060204@bogus.com> On 11/24/14 8:58 AM, Dave Crocker wrote: > On 11/23/2014 11:20 AM, joel jaeggli wrote: >> Their grasp of load-balancing seems a >> bit shallow also. > > > Are there discussion/guidance papers that one can point to, to improve > the depth of understanding, or at least get better configuration > choices? (Those are independent points of improvement...) Bassim Halabi's book is getting a bit long in the tooth, but it was my jumping-off point for my own forays into this space. http://www.amazon.com/Internet-Routing-Architectures-2nd-Halabi/dp/157870233X/ref=sr_1_1?ie=UTF8&qid=1417390786&sr=8-1&keywords=halabi+routing The nanog tutorials have been assiduous about updating the bgp materials https://www.nanog.org/resources/tutorials So there are several iterations of the practical materials. joel > d/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: