From tstpierre at iweb.com Wed May 1 00:28:34 2013 From: tstpierre at iweb.com (Thomas St-Pierre) Date: Wed, 1 May 2013 00:28:34 +0000 Subject: Mitigating DNS amplification attacks In-Reply-To: <579A1E1F-9DBA-4EC3-80FD-4CAAF2D1F533@arbor.net> Message-ID: Hi! On 13-04-30 7:57 PM, "Dobbins, Roland" wrote: > >On May 1, 2013, at 6:43 AM, Thomas St-Pierre wrote: > >> We've been sending emails to our clients but as the servers are not >>managed by us, there's not much we can do at that level. > >Sure, there is - shut them down if they don't comply. Most ISPs have AUP >verbiage which would apply to a situation of this type. Unfortunately I somehow doubt management is going to look favourably on a request to shut down so many clients. :( The large majority of the servers being used in the attacks are not open resolvers. Just DNS servers that are authoritative for a few domains, and the default config of the dns application does referrals to root for anything else. Yes there are ways of protecting against this on the server itself, but I don't see it happening here given the complexity of many of the solutions. I hate to say it, but if it's not "next -> next -> next -> finish", or integrated as an option in one of the common web hosting panels (cPanel, Plesk, etc) people won't do it. We still struggle just getting people to close actual open resolvers, and that is easy to configure. > >> Has anyone ever tried mitigating/rate-limiting/etc these attacks in the >>network before? (vs at the server/application level) > >QoS doesn't work, as the programmatically-generated attack traffic >'crowds out' legitimate requests. > >> We have an Arbor peakflow device, but it's not really geared for this >>scenario I find. > >Peakflow SP is a NetFlow-based anomaly-detection system which performs >attack detection/classification/traceback. Please feel free to ping me >offlist about additional system elements which perform attack mitigation. Pinged off-list! Thanks! Thomas From damian at google.com Wed May 1 00:32:44 2013 From: damian at google.com (Damian Menscher) Date: Tue, 30 Apr 2013 17:32:44 -0700 Subject: Mitigating DNS amplification attacks In-Reply-To: References: <579A1E1F-9DBA-4EC3-80FD-4CAAF2D1F533@arbor.net> Message-ID: On Tue, Apr 30, 2013 at 5:28 PM, Thomas St-Pierre wrote: > On 13-04-30 7:57 PM, "Dobbins, Roland" wrote: > >On May 1, 2013, at 6:43 AM, Thomas St-Pierre wrote: > > > >> We've been sending emails to our clients but as the servers are not > >>managed by us, there's not much we can do at that level. > > > >Sure, there is - shut them down if they don't comply. Most ISPs have AUP > >verbiage which would apply to a situation of this type. > > Unfortunately I somehow doubt management is going to look favourably on a > request to shut down so many clients. :( The large majority of the servers > being used in the attacks are not open resolvers. Just DNS servers that > are authoritative for a few domains, and the default config of the dns > application does referrals to root for anything else. Offering a DNS service to your customers may allow you to provide a good alternative to push those customers onto. You can then manage it properly. But I think DNS isn't the real issue here, it's the fact you're receiving spoofed traffic. I'd start by tracking the attacks backwards through your upstreams, as obviously someone in the path isn't enforcing BCP 38. Stop the spoof capability and the attacks will stop. It requires less effort overall (vs your counterparts at every hosting provider needing to solve the problem for their networks) and provides the best benefit to the victims. Damian From jared at puck.nether.net Wed May 1 00:35:18 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 30 Apr 2013 20:35:18 -0400 Subject: Mitigating DNS amplification attacks In-Reply-To: References: Message-ID: <533A3ECD-145F-4FB8-8B52-D245717E8D98@puck.nether.net> Please look at something like rate limiting. Please look at preventing these spoofed packets from entering your network and report the issue. Please provide advice and insights as well as directing customers to the openresolverproject.org website. We want to close these down, if you need an accurate list of IPs in your ASN, please email me and I can give you very accurate data. Thanks! On Apr 30, 2013, at 7:43 PM, Thomas St-Pierre wrote: > Hi! > > I was wondering if anyone had any experience with dealing with open resolvers as a web hoster? We currently have some 40,000 ip's that respond to DNS in our AS, the majority of which are not "open" but do reply with a referral to the root zones. We've been sending emails to our clients but as the servers are not managed by us, there's not much we can do at that level. > > Recently we've seen a large increase in the number and volume of DNS amplification DDOS's that are being reflected off of our AS. Just today we've seen at least 6 different attacks with between 4 and 10gbps leaving our AS each time. It's not really causing us issues at the moment because we have the capacity, but I'd hate to be on the receiving side. (and indeed, have been on the receiving side in the past, so I know how much it can suck) > > Has anyone ever tried mitigating/rate-limiting/etc these attacks in the network before? (vs at the server/application level) > > We have an Arbor peakflow device, but it's not really geared for this scenario I find. It will detect the outgoing attack via the flows, but all we can really do is null-route the victims ip in our AS. Ideally we would need a way to rate-limit DNS packets based on source ip. Maybe a linux box that handles dropping packets from the same source-ip over 1000/sec with some policy-based routing sending the DNS traffic to it? Does such a box exist already? > > If anyone has any ideas or suggestions, then by all means! There must be a better way to do this, and I'd really like to avoid re-inventing the wheel if it's been invented already. :) > > Thanks! > Thomas From tstpierre at iweb.com Wed May 1 00:42:06 2013 From: tstpierre at iweb.com (Thomas St-Pierre) Date: Wed, 1 May 2013 00:42:06 +0000 Subject: Mitigating DNS amplification attacks In-Reply-To: Message-ID: Hi Damian! We offer a DNS hosted solution, most people still use their own servers though. (especially those with control panels such as cPanel or plesk, where it's built-in). As for BCP38, I would love to stop the spoofed packets, however with them coming from our upstreams, (Level3, Cogent, Tata, etc) I don't see how we can. Thanks!, Thomas From: Damian Menscher > Date: Tuesday, 30 April, 2013 8:32 PM To: "Thomas St.Pierre" > Cc: "Dobbins, Roland" >, NANOG list > Subject: Re: Mitigating DNS amplification attacks On Tue, Apr 30, 2013 at 5:28 PM, Thomas St-Pierre > wrote: On 13-04-30 7:57 PM, "Dobbins, Roland" > wrote: >On May 1, 2013, at 6:43 AM, Thomas St-Pierre wrote: > >> We've been sending emails to our clients but as the servers are not >>managed by us, there's not much we can do at that level. > >Sure, there is - shut them down if they don't comply. Most ISPs have AUP >verbiage which would apply to a situation of this type. Unfortunately I somehow doubt management is going to look favourably on a request to shut down so many clients. :( The large majority of the servers being used in the attacks are not open resolvers. Just DNS servers that are authoritative for a few domains, and the default config of the dns application does referrals to root for anything else. Offering a DNS service to your customers may allow you to provide a good alternative to push those customers onto. You can then manage it properly. But I think DNS isn't the real issue here, it's the fact you're receiving spoofed traffic. I'd start by tracking the attacks backwards through your upstreams, as obviously someone in the path isn't enforcing BCP 38. Stop the spoof capability and the attacks will stop. It requires less effort overall (vs your counterparts at every hosting provider needing to solve the problem for their networks) and provides the best benefit to the victims. Damian From rdobbins at arbor.net Wed May 1 00:45:25 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 1 May 2013 00:45:25 +0000 Subject: Mitigating DNS amplification attacks In-Reply-To: References: Message-ID: <2BCBD2A7-D666-4F73-B94B-03A57704C915@arbor.net> On May 1, 2013, at 7:42 AM, Thomas St-Pierre wrote: > As for BCP38, I would love to stop the spoofed packets, however with them coming from our upstreams, (Level3, Cogent, Tata, etc) I don't see how we can. Contact them on a case-by-case basis to report the spoofed traffic used to stimulate the servers into responding, including the layer-4 classification criteria, traffic rates, and timestamps available via flow telemetry. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rs at seastrom.com Wed May 1 01:13:28 2013 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 30 Apr 2013 21:13:28 -0400 Subject: Andros Island Connectivity? In-Reply-To: <8DAE6568-23F4-4D8A-B32A-CAE44ACD33E8@oitc.com> (TR Shaw's message of "Tue, 30 Apr 2013 16:47:57 -0400") References: <8DAE6568-23F4-4D8A-B32A-CAE44ACD33E8@oitc.com> Message-ID: <86k3nj5wp3.fsf@valhalla.seastrom.com> Protracted discussion (and promotion) has glossed over one key point: >> None of the people on-site are technical, and all their data is accessed >> via RDP on a server in the United States. They will not be happy with VSAT latency (typically 700ms though physics says you can never do better than 550, and that's for the space segment alone) if they are running RDP, VNC, Citrix, or similar technologies. Sorry for being a buzzkill, Warren. :) -r From wbailey at satelliteintelligencegroup.com Wed May 1 01:24:18 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 1 May 2013 01:24:18 +0000 Subject: Andros Island Connectivity? In-Reply-To: <86k3nj5wp3.fsf@valhalla.seastrom.com> Message-ID: BuzzzzzKilllll!!! Actually, we use some TCP ninja techniques to make Citrix/RDP work. Basically, we ack the packets on both sides to prevent the delay from occurring. It's kind of like acceleration, except there aren't really any devices in between the session. There is a single box at the transmit station (we call it a hub) and nothing on the other side. And for the record, you're never a buzzkill Rob. I live with latency every day, she's a decent girl when you treat her right.. ;) On 4/30/13 6:13 PM, "Rob Seastrom" wrote: > >Protracted discussion (and promotion) has glossed over one key point: > >>> None of the people on-site are technical, and all their data is >>>accessed >>> via RDP on a server in the United States. > >They will not be happy with VSAT latency (typically 700ms though >physics says you can never do better than 550, and that's for the >space segment alone) if they are running RDP, VNC, Citrix, or similar >technologies. Sorry for being a buzzkill, Warren. :) > >-r > > > > From ryan at deadfrog.net Wed May 1 01:29:19 2013 From: ryan at deadfrog.net (Ryan Wilkins) Date: Tue, 30 Apr 2013 21:29:19 -0400 Subject: Andros Island Connectivity? In-Reply-To: <86k3nj5wp3.fsf@valhalla.seastrom.com> References: <8DAE6568-23F4-4D8A-B32A-CAE44ACD33E8@oitc.com> <86k3nj5wp3.fsf@valhalla.seastrom.com> Message-ID: I was going to mention this but failed to do so. At the very least, do some testing first to make sure that the latency isn't going to introduce unforeseen issues. Case in point, the Chicago satellite-based network that I manage is sometimes used for Police / Fire / EMS dispatching. The City's Computer Aided Dispatch system ended up crashing during an early test when it was discovered that it couldn't handle the high latencies encountered on satellite links. This required the vendor to adjust the code to deal with these issues. Granted this is an extreme example, but the point is that the physics of satellite links can do all sorts of things to applications that one might not expect. Cheers, Ryan Wilkins On Apr 30, 2013, at 9:13 PM, Rob Seastrom wrote: > > They will not be happy with VSAT latency (typically 700ms though > physics says you can never do better than 550, and that's for the > space segment alone) if they are running RDP, VNC, Citrix, or similar > technologies. Sorry for being a buzzkill, Warren. :) From wbailey at satelliteintelligencegroup.com Wed May 1 01:33:50 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 1 May 2013 01:33:50 +0000 Subject: Andros Island Connectivity? In-Reply-To: Message-ID: http://www.xiplink.com is who we work with (and sell). Don't mean to advertise on NANOG, more of an FYI and place for those who care to learn something. I hate the fact that satellite is looked at like a white unicorn, it's a pretty cool solution that will perform day in and out for as long as you need it to. On 4/30/13 6:29 PM, "Ryan Wilkins" wrote: >I was going to mention this but failed to do so. > >At the very least, do some testing first to make sure that the latency >isn't going to introduce unforeseen issues. Case in point, the Chicago >satellite-based network that I manage is sometimes used for Police / Fire >/ EMS dispatching. The City's Computer Aided Dispatch system ended up >crashing during an early test when it was discovered that it couldn't >handle the high latencies encountered on satellite links. This required >the vendor to adjust the code to deal with these issues. Granted this is >an extreme example, but the point is that the physics of satellite links >can do all sorts of things to applications that one might not expect. > >Cheers, >Ryan Wilkins > >On Apr 30, 2013, at 9:13 PM, Rob Seastrom wrote: >> >> They will not be happy with VSAT latency (typically 700ms though >> physics says you can never do better than 550, and that's for the >> space segment alone) if they are running RDP, VNC, Citrix, or similar >> technologies. Sorry for being a buzzkill, Warren. :) > > > From ryan at deadfrog.net Wed May 1 01:50:10 2013 From: ryan at deadfrog.net (Ryan Wilkins) Date: Tue, 30 Apr 2013 21:50:10 -0400 Subject: Andros Island Connectivity? In-Reply-To: References: Message-ID: <89D1E9DC-FAE0-4046-860F-1E00FE383181@deadfrog.net> I've used them before on SCPC links. I discovered on a boat one time that the XipLink unit we were using wasn't exactly designed to handle vibrations from engines nor the constant pounding of a hull on water when in the ocean with large swells. Back then the boxes were 1U rackmount PCs running some variant of BSD, and we had issues with the Ethernet card coming out of the PCI slot after a few hours of operational use. Maybe they've migrated to something a little more robust now. Of course, most normal customers don't put them on boats to begin with. :-) I agree with your comment about satellite. It has its place. Some things it is particularly well suited for. Other things, maybe not so much. I often don't mention satellites when someone asks what I do because most people assume I'm a DirecTV installer which couldn't be further from the truth. On Apr 30, 2013, at 9:33 PM, Warren Bailey wrote: > http://www.xiplink.com is who we work with (and sell). Don't mean to > advertise on NANOG, more of an FYI and place for those who care to learn > something. I hate the fact that satellite is looked at like a white > unicorn, it's a pretty cool solution that will perform day in and out for > as long as you need it to. > From jms at opus1.com Wed May 1 02:02:01 2013 From: jms at opus1.com (Joel M Snyder) Date: Tue, 30 Apr 2013 19:02:01 -0700 Subject: Andros Island Connectivity? In-Reply-To: References: Message-ID: <51807799.5080506@opus1.com> > > Protracted discussion (and promotion) has glossed over one key point: > >>> None of the people on-site are technical, and all their data is accessed >>> via RDP on a server in the United States. > > They will not be happy with VSAT latency (typically 700ms though > physics says you can never do better than 550, and that's for the > space segment alone) if they are running RDP, VNC, Citrix, or similar > technologies. Sorry for being a buzzkill, Warren. :) Actually, Citrix (in particular) works quite well over satellite latencies. The network project I'm working on right now is wrapping up an app rollout to about 100 countries, many of which we can only reach via VSAT. Testing showed that Citrix performance is much better for AJAX-y web apps than pure HTTP. Citrix has a bunch of intelligence built-in specifically to deal with issues related to high-latency/low-bandwidth circuits, including local mouse, local echo, click/movement aggregation into large packets, and of course compression-before-encryption. It's not quite Memorex, but it's very usable. I'd be happy to share the data with anyone who is interested; I also showed that F5 Big-IP load balancers can make really horrible ERP apps (*ahem* Oracle eBusiness *cough* *cough* *cough*) work a lot better as well, if you decide not to use Citrix. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From rs at seastrom.com Wed May 1 02:08:25 2013 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 30 Apr 2013 22:08:25 -0400 Subject: Andros Island Connectivity? In-Reply-To: <51807799.5080506@opus1.com> (Joel M. Snyder's message of "Tue, 30 Apr 2013 19:02:01 -0700") References: <51807799.5080506@opus1.com> Message-ID: <86vc73v4di.fsf@valhalla.seastrom.com> Joel M Snyder writes: > Actually, Citrix (in particular) works quite well over satellite > latencies. The network project I'm working on right now is wrapping > up an app rollout to about 100 countries, many of which we can only > reach via VSAT. Testing showed that Citrix performance is much better > for AJAX-y web apps than pure HTTP. > > Citrix has a bunch of intelligence built-in specifically to deal with > issues related to high-latency/low-bandwidth circuits, including local > mouse, local echo, click/movement aggregation into large packets, and > of course compression-before-encryption. It's not quite Memorex, but > it's very usable. That's good to know that it's evolved so well. Painful, almost repressed memories suggest that it wasn't always so good. -r From wbailey at satelliteintelligencegroup.com Wed May 1 02:10:02 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 1 May 2013 02:10:02 +0000 Subject: Andros Island Connectivity? In-Reply-To: <51807799.5080506@opus1.com> Message-ID: Put that in your pipe and smoke it, Seastrom! ;) On 4/30/13 7:02 PM, "Joel M Snyder" wrote: >> >> Protracted discussion (and promotion) has glossed over one key point: >> >>>> None of the people on-site are technical, and all their data is >>>>accessed >>>> via RDP on a server in the United States. >> >> They will not be happy with VSAT latency (typically 700ms though >> physics says you can never do better than 550, and that's for the >> space segment alone) if they are running RDP, VNC, Citrix, or similar >> technologies. Sorry for being a buzzkill, Warren. :) > >Actually, Citrix (in particular) works quite well over satellite >latencies. The network project I'm working on right now is wrapping up >an app rollout to about 100 countries, many of which we can only reach >via VSAT. Testing showed that Citrix performance is much better for >AJAX-y web apps than pure HTTP. > >Citrix has a bunch of intelligence built-in specifically to deal with >issues related to high-latency/low-bandwidth circuits, including local >mouse, local echo, click/movement aggregation into large packets, and of >course compression-before-encryption. It's not quite Memorex, but it's >very usable. > >I'd be happy to share the data with anyone who is interested; I also >showed that F5 Big-IP load balancers can make really horrible ERP apps >(*ahem* Oracle eBusiness *cough* *cough* *cough*) work a lot better as >well, if you decide not to use Citrix. > >jms > >-- >Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 >Senior Partner, Opus One Phone: +1 520 324 0494 >jms at Opus1.COM http://www.opus1.com/jms > > From mysidia at gmail.com Wed May 1 02:56:29 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 30 Apr 2013 21:56:29 -0500 Subject: "It's the end of the world as we know it" -- REM In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FC65236@CHAXCH01.corp.arin.net> References: <8DA1853CE466B041B104C1CAEE00B3748FC5881F@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FC65236@CHAXCH01.corp.arin.net> Message-ID: On Tuesday, April 30, 2013, John Curran wrote: > On Apr 30, 2013, at 1:46 AM, Jimmy Hess > > wrote: > > > On 4/29/13, John Curran > wrote: > >> On Apr 29, 2013, at 2:46 PM, Lee Howard > > wrote: > >>> On 4/29/13 1:03 AM, "J?r?me Nicolle" > > wrote: > >> specified (based on being singly-homed or multi-homed.) These same > >> criteria now apply to receipt of an address block via transfer, so at > >> regional IPv4 free pool depletion may be _very_ difficult to satisfy. > > > > Huh? Where did that concept come from? > > Alas, NRPM 8.3 requires that "the recipient must demonstrate the need for > up > to a 24-month supply of IP address resources _under current ARIN policies_ > ..." > This says demonstrate the need for resources. The "under current policies" bit is redundant, because the transfer policy is referring to itself. Of course the current policies always apply; so this is some strange infinitely recursive oddity. It doesn't say the qualifications and requirements will be the same as if the transfer request was a request for a /20 allocation from the free pool, or as if the transfer were an assignment (things that it is not); only that the transfer policy asserts the requirement to demonstrate need, As long as the need can be demonstrated as explained in 4.1, then any 8.3 transfer should be approved, even if the criteria given in 4.2 for initial allocations are not met. Since there is not yet a policy there that addresses or places specific requirements for need determination for transferred resources, as-opposed to allocation requests The initial allocation rule should not be getting applied to 8.3 transfers in any case... -- -JH -- -Mysid From rs at seastrom.com Wed May 1 03:00:21 2013 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 30 Apr 2013 23:00:21 -0400 Subject: Andros Island Connectivity? In-Reply-To: (Warren Bailey's message of "Wed, 1 May 2013 02:10:02 +0000") References: Message-ID: <86bo8vieuy.fsf@valhalla.seastrom.com> Good 'ol Warren, sure knows how to make friends and influence people. -r Warren Bailey writes: > Put that in your pipe and smoke it, Seastrom! ;) > > On 4/30/13 7:02 PM, "Joel M Snyder" wrote: > >>> >>> Protracted discussion (and promotion) has glossed over one key point: >>> >>>>> None of the people on-site are technical, and all their data is >>>>>accessed >>>>> via RDP on a server in the United States. >>> >>> They will not be happy with VSAT latency (typically 700ms though >>> physics says you can never do better than 550, and that's for the >>> space segment alone) if they are running RDP, VNC, Citrix, or similar >>> technologies. Sorry for being a buzzkill, Warren. :) >> >>Actually, Citrix (in particular) works quite well over satellite >>latencies. The network project I'm working on right now is wrapping up >>an app rollout to about 100 countries, many of which we can only reach >>via VSAT. Testing showed that Citrix performance is much better for >>AJAX-y web apps than pure HTTP. >> >>Citrix has a bunch of intelligence built-in specifically to deal with >>issues related to high-latency/low-bandwidth circuits, including local >>mouse, local echo, click/movement aggregation into large packets, and of >>course compression-before-encryption. It's not quite Memorex, but it's >>very usable. >> >>I'd be happy to share the data with anyone who is interested; I also >>showed that F5 Big-IP load balancers can make really horrible ERP apps >>(*ahem* Oracle eBusiness *cough* *cough* *cough*) work a lot better as >>well, if you decide not to use Citrix. >> >>jms >> >>-- >>Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 >>Senior Partner, Opus One Phone: +1 520 324 0494 >>jms at Opus1.COM http://www.opus1.com/jms >> >> From wbailey at satelliteintelligencegroup.com Wed May 1 03:12:02 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 1 May 2013 03:12:02 +0000 Subject: Andros Island Connectivity? In-Reply-To: <86bo8vieuy.fsf@valhalla.seastrom.com> References: , <86bo8vieuy.fsf@valhalla.seastrom.com> Message-ID: <3rsc0r6btcd802dkjsfta8j0.1367377918686@email.android.com> The chicks certainly know my name.. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Rob Seastrom Date: 04/30/2013 8:00 PM (GMT-08:00) To: Warren Bailey Cc: Joel M Snyder ,nanog at nanog.org,aaron at heyaaron.com Subject: Re: Andros Island Connectivity? Good 'ol Warren, sure knows how to make friends and influence people. -r Warren Bailey writes: > Put that in your pipe and smoke it, Seastrom! ;) > > On 4/30/13 7:02 PM, "Joel M Snyder" wrote: > >>> >>> Protracted discussion (and promotion) has glossed over one key point: >>> >>>>> None of the people on-site are technical, and all their data is >>>>>accessed >>>>> via RDP on a server in the United States. >>> >>> They will not be happy with VSAT latency (typically 700ms though >>> physics says you can never do better than 550, and that's for the >>> space segment alone) if they are running RDP, VNC, Citrix, or similar >>> technologies. Sorry for being a buzzkill, Warren. :) >> >>Actually, Citrix (in particular) works quite well over satellite >>latencies. The network project I'm working on right now is wrapping up >>an app rollout to about 100 countries, many of which we can only reach >>via VSAT. Testing showed that Citrix performance is much better for >>AJAX-y web apps than pure HTTP. >> >>Citrix has a bunch of intelligence built-in specifically to deal with >>issues related to high-latency/low-bandwidth circuits, including local >>mouse, local echo, click/movement aggregation into large packets, and of >>course compression-before-encryption. It's not quite Memorex, but it's >>very usable. >> >>I'd be happy to share the data with anyone who is interested; I also >>showed that F5 Big-IP load balancers can make really horrible ERP apps >>(*ahem* Oracle eBusiness *cough* *cough* *cough*) work a lot better as >>well, if you decide not to use Citrix. >> >>jms >> >>-- >>Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 >>Senior Partner, Opus One Phone: +1 520 324 0494 >>jms at Opus1.COM http://www.opus1.com/jms >> >> From jcurran at arin.net Wed May 1 03:18:15 2013 From: jcurran at arin.net (John Curran) Date: Wed, 1 May 2013 03:18:15 +0000 Subject: "It's the end of the world as we know it" -- REM In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748FC5881F@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FC65236@CHAXCH01.corp.arin.net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FC791AB@CHAXCH01.corp.arin.net> On Apr 30, 2013, at 10:56 PM, Jimmy Hess > wrote: On Tuesday, April 30, 2013, John Curran wrote: On Apr 30, 2013, at 1:46 AM, Jimmy Hess > wrote: > On 4/29/13, John Curran > wrote: >> On Apr 29, 2013, at 2:46 PM, Lee Howard > wrote: >>> On 4/29/13 1:03 AM, "J?r?me Nicolle" > wrote: >> specified (based on being singly-homed or multi-homed.) These same >> criteria now apply to receipt of an address block via transfer, so at >> regional IPv4 free pool depletion may be _very_ difficult to satisfy. > > Huh? Where did that concept come from? Alas, NRPM 8.3 requires that "the recipient must demonstrate the need for up to a 24-month supply of IP address resources _under current ARIN policies_ ..." This says demonstrate the need for resources. The "under current policies" bit is redundant, because the transfer policy is referring to itself. Of course the current policies always apply; so this is some strange infinitely recursive oddity. Jimmy - Actually, I'm quite confident in the interpretation... Note that the reading that this language would require qualification under current IPv4 allocation policies was also confirmed in the Staff Assessment when the proposed NRPM 8.3 language was under consideration as a draft policy - It is easy enough to change if desired (and apparently some folks are looking at doing that per any earlier reply on this thread) but as it stands there is a chance that ISPs seeking to obtain IPv4 space from the transfer market will not be able to participate if they haven't made use of provider-assigned space first. FYI, /John John Curran President and CEO ARIN From owen at delong.com Wed May 1 03:18:51 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 30 Apr 2013 20:18:51 -0700 Subject: "It's the end of the world as we know it" -- REM In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748FC5881F@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FC65236@CHAXCH01.corp.arin.net> Message-ID: >> This says demonstrate the need for resources. > The "under current policies" bit is redundant, because the transfer policy > is referring to itself. Of course the current policies always apply; so > this is some strange infinitely recursive oddity. > Jimmy, With all due respect, this is a reference in section 8.3 to call out that the policies in section 4 regarding qualification of recipients are to be followed when determining eligibility for an 8.3 transfer. This is understood by the AC and by ARIN staff. I believe it is also well understood by the majority of the community. I would be happy to submit clarifying text as an editorial amendment if you feel it would be helpful. I would suggest that considering the expressed intent of the policy is more useful than attempting to nit-pick the most nonsensical possible interpretations of the particular wording. > It doesn't say the qualifications and requirements will be the same as if > the transfer request was a request for a /20 allocation from the free pool, > or as if the transfer were an assignment (things that it is not); only that > the transfer policy asserts the requirement to demonstrate need, > That is the express intent of that clause in the rationale and according to the authors during discussions of the policy text prior to its adoption. Further, it is (correctly, IMHO), the ARIN staff interpretation of the policy. > As long as the need can be demonstrated as explained in 4.1, then any > 8.3 transfer should be approved, even if the criteria given in 4.2 for > initial allocations are not met. 4.1 provides only general principles. In and of itself it is not a complete set of policies. In addition to the guidance provided by 4.1, one must qualify under 4.2 if one is an ISP/LIR or 4.3 if one is an end-user. There are exceptions provided in 4.4 et. seq. for certain special cases. > Since there is not yet a policy there that addresses or places specific > requirements for need determination for transferred resources, as-opposed > to allocation requests The text in section 8.3 effectively incorporates 4.2 et. seq. by reference, whether you like that fact or not. > The initial allocation rule should not be getting applied to 8.3 transfers > in any case... IMHO, your interpretation is contrary to the text and the intent of NRPM 8.3. It appears that staff agrees with me. The proposal that later became 8.3 was discussed in the community as it is currently interpreted by staff. At no point prior to your current objection was anything like your intended interpretation ever expressed as a viable outcome of the text in question. Owen From alejandroacostaalamo at gmail.com Wed May 1 04:15:07 2013 From: alejandroacostaalamo at gmail.com (alejandroacostaalamo at gmail.com) Date: Wed, 1 May 2013 04:15:07 +0000 Subject: Andros Island Connectivity? Message-ID: <85638102-1367381704-cardhu_decombobulator_blackberry.rim.net-584722641-@b25.c3.bise6.blackberry> Hi, Please also note that modern VSAT hubs (idirect, viasat) -some better than other- can emulate SCPC. They also support QoS, tcp spoofing and many other nice features. Regards, ------Original Message------ From: Rob Seastrom To: TR Shaw Cc: Aaron C. de Bruyn Cc: NANOG mailing list Subject: Re: Andros Island Connectivity? Sent: Apr 30, 2013 8:43 PM Protracted discussion (and promotion) has glossed over one key point: >> None of the people on-site are technical, and all their data is accessed >> via RDP on a server in the United States. They will not be happy with VSAT latency (typically 700ms though physics says you can never do better than 550, and that's for the space segment alone) if they are running RDP, VNC, Citrix, or similar technologies. Sorry for being a buzzkill, Warren. :) -r Este mensaje ha sido enviado gracias al servicio BlackBerry de Movilnet From joseph.snyder at gmail.com Wed May 1 05:23:39 2013 From: joseph.snyder at gmail.com (joseph.snyder at gmail.com) Date: Wed, 01 May 2013 01:23:39 -0400 Subject: Andros Island Connectivity? In-Reply-To: References: , Message-ID: <3cd09fee-866b-4112-90c7-c86a3cb2c64f@email.android.com> Doesn't cable Bahamas sell in andros Warren Bailey wrote: >I suggested VSAT. Probably the quickest and cheapest. > > >Sent from my T-Mobile 4G LTE Device > > > >-------- Original message -------- >From: Mike Lyon >Date: 04/30/2013 1:35 PM (GMT-08:00) >To: "Aaron C. de Bruyn" ,members at wispa.org >Cc: NANOG mailing list >Subject: Re: Andros Island Connectivity? > > >Aaron, > >Cross-posting this over to the WISPA list to see if there are any >Wireless >ISPs over there that can help you. > >-Mike > > > >On Tue, Apr 30, 2013 at 1:28 PM, Aaron C. de Bruyn >wrote: > >> I just had a client drop an interesting requirement on me. >> >> They are on Andros Island (Bahamas) for about a year. I'm working on >> getting an exact address from the adminisphere above me, but all I've >been >> told so far is they are 'near the naval base'. >> >> They just called and said "We need internet access yesterday". >> >> None of the people on-site are technical, and all their data is >accessed >> via RDP on a server in the United States. >> >> Having never been there, I have no idea if it's like downtown San >Francisco >> where the internet grows on trees, or if it's like the Sahara desert >which >> might require dragging your own fiber in on camelback... >> >> Does anyone have pointers on who to talk to or how I can get them >internet >> access? >> >> -A >> > > > >-- >Mike Lyon >408-621-4826 >mike.lyon at gmail.com > >http://www.linkedin.com/in/mlyon -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From mysidia at gmail.com Wed May 1 05:36:32 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 1 May 2013 00:36:32 -0500 Subject: "It's the end of the world as we know it" -- REM In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748FC5881F@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FC65236@CHAXCH01.corp.arin.net> Message-ID: On 4/30/13, Owen DeLong wrote: > With all due respect, this is a reference in section 8.3 to call out that > the policies in section 4 regarding qualification of recipients are to be > followed when determining eligibility for an 8.3 transfer. I don't read a reference to section 4 there. don't think it's a reasonable belief, that a network operator supplicating for transfer of IPv4 resources, would come to this conclusion -- there is no reason to select a specific section to apply because no section is mentioned, reading the policy on their own, and what you are seeing there -- may be a result of bias from your prior exposure to another interpretation of the language. Its also possible, that all of us who were reviewing the proposed transfer policy language read some rationale statement at one time or another, and just (incorrectly) assumed that the final language accomplished our intended effect. I don't think this issue should effect any network operators at this time, but nonetheless i'm concerned about the RIR policy having confusing, surprising, or hidden ramifications built into it, which are problematic and not previously considered. > I would suggest that considering the expressed intent of the policy is more > useful than attempting to nit-pick the most nonsensical possible I looked at the intent of the policy specifically, and it seems pretty obvious that 4.2.2.1.1 and 4.2.2.1.3 very clearly do not intend that they apply to transfers, or other situations where a /20 is not involved. If 8.3 says the current policy applies, then, that by definition imports also the intent and scope restriction in the other sections of the policy, not just the procedures or rules. Specific evidence of intent from 4.2.2.1.1 quote: " if an organization holds a smaller allocation, such as 12 /24s, from its upstream provider, the organization would not meet the minimum utilization requirements of a /20." Furthermore, the 8.3 transfer rule specifically states that the minimum is /24. And the stated requirement is demonstrated need, not "whatever constraints apply to other kinds of allocations/assignment". When the interpretation is intent, with these two statements taken together, we have here, a contradiction between the acceptance of a /24 that can only be resolved by refraining from applying 4.2.2.1.1 and 4.2.2.1.3, or the antecedent is false (you're not requesting a /20, so it follows that you don't need to meet the minimum utilization requirements of a /20). There _is_ a reasonable demonstrated need criteria, in 4.2, that could apply to transfers; though, it's 4.2.3. Reassignment of address space... The characterization of the transfer recipient as a "customer" for reassignment purposes, seems less-problematic than the characterization of a /24 as a /20, for imposing 4.2.2.1.1 , and carries no requirement for a prior upstream assignment. > That is the express intent of that clause in the rationale and according to > the authors during discussions of the policy text prior to its adoption. My expectation about 8.3 is that justification is still to be required. But not the application of /20 justification criterion to a /23 or smaller. Also, i'm not sure what bearing the author's intent may have, as a policy document has to be able to stand on its own, and different members of the community, may aparently have had a different understanding of some of the ramifications of the language. If the language doesn't convey the intent in a clear, at least discernible way, that can be shown through sufficient evidence in the document, then the supposed intent may as well not exist: I mean, it's like saying the developed policy didn't matter "just the author's intent"?. > 4.1 provides only general principles. In and of itself it is not a complete > set of policies. In addition to the guidance provided by 4.1, one must qualify > under 4.2 if one is an ISP/LIR or 4.3 if one is an end-user. There are > exceptions provided in 4.4 et. seq. for certain special cases. Yes; i'm not sure, what, if any relevance these distinctions really have or ought to have, with transfers, and a minimum size of /24, and /23s allowed as well, however. And I sure don't expect applicants for transfer applicants to sort all that out; the policy should be more explicit, and have conditions to clearly apply to the situation. -- -JH From matthew at matthew.at Wed May 1 07:51:08 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 01 May 2013 00:51:08 -0700 Subject: "It's the end of the world as we know it" -- REM In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748FC5881F@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FC65236@CHAXCH01.corp.arin.net> Message-ID: <5180C96C.1050709@matthew.at> On 4/30/2013 10:36 PM, Jimmy Hess wrote: > On 4/30/13, Owen DeLong wrote: > >> With all due respect, this is a reference in section 8.3 to call out that >> the policies in section 4 regarding qualification of recipients are to be >> followed when determining eligibility for an 8.3 transfer. > I don't read a reference to section 4 there. don't think it's a > reasonable belief, that a network operator supplicating for transfer > of IPv4 resources, would come to this conclusion -- there is no > reason to select a specific section to apply because no section is > mentioned, > reading the policy on their own, and what you are seeing there -- may > be a result of > bias from your prior exposure to another interpretation of the language. > > Its also possible, that all of us who were reviewing the proposed > transfer policy language read some rationale statement at one time or > another, and just (incorrectly) assumed that the final language > accomplished our intended effect. > > > I don't think this issue should effect any network operators at this > time, but nonetheless i'm concerned about the RIR policy having > confusing, surprising, or hidden ramifications built into it, which > are problematic and not previously considered. > > I was the original policy modification author. The first version I submitted said: "Add a subsection to Section 8 (Transfers) of the NRPM: "Justified Need" for resources associated with a transfer shall be determined using the "4.2.4 ISP Additional Requests" criteria applied as though the recipient has been a subscriber member of ARIN for at least one year (whether or not that is the case)." Then In a followup email I pointed out: "... Section 8.3 has NO language exempting itself from the 3 month rule. That's what I hear on the list, but I looked it up, and it isn't there. That's how I ended up writing this proposal, after all. The only exemption is in 4.2.4.4. That exemption ONLY works if you are not getting an initial assignment through transfer (a likely scenario for new orgs post-runout) AND you are not a new member who only recently got their initial 3 month supply (where you'd be restricted to using transfer in 3-month increments for the first year in order to grow). AND there's other bugs in that 4.2.2.1.1 and 4.2.2.1.3 and 4.2.2.2 (at the very least) call out specific block sizes that might be *smaller* than the block you're trying to qualify under transfer." I then followed up to that with some specific scenarios... "A. My hypothetical ISP provides service to a small town. I presently get two /24s of IPv4 space from my upstream provider and I'm using them at about 85%. ARIN has run completely out of addresses. A benefactor arrives and offers to transfer a /22 to me and pay for me to multihome. I attempt to use 4.2.2.2 (Initial Allocation to ISPs, Multihomed) for my justification. I need to demonstrate that I am efficiently using the two /24s. Done. I comply with 4.2.2.2.1 (SWIP). I attempt to comply with 4.2.2.2.2, but my growth shows that I won't really need more than a /23 for about 7 months. Transfer would be denied because 4.2.2.2.2 has a three month rule (as I claimed above). Benefactor takes his space elsewhere, and I lose out. B. My hypothetical ISP provides service to a single data center. I presently have a /20 that I was able to obtain from ARIN a few months ago, and I wasn't an ARIN subscriber member prior to this. I have the opportunity to acquire another ISP in town which has a /20 of its own, but which it isn't using very well because their growth plans failed after I opened up. I can demonstrate that my /20 and the second /20 from the acquisition would be filled within a year if I complete this transfer under section 8.2, but I'll only be able to fill out my existing /20 over the next three months. However, because I am under 4.2.4.3 (Subscriber Members Less Than One Year) my 8.2 transfer is denied, again because 4.2.4.3 has a three month rule (as I claimed above). on the flip side... C. My hypothetical ISP provides service to a small city that is served by only one transit provider, so I cannot multihome. It has been using a /20 from the upstream ISP and is efficiently using 16 /24s worth of space with reassignment documentation (satisfying 4.2.2.1.1 and 4.2.2.1.2). I provide detailed information showing that I can use a /20 within the next three months (satisfying 4.2.2.1.3). Now that I have met all the tests, I complete a section 8.3 transfer for a /14 worth of space (because I have loads of money I won in the lottery). As far as I can tell, there's nothing in the NRPM that blocks that transfer... because I've met all the tests in 4.2.2.1. " Then, after a bunch of comment and feedback (particularly around how end-users shouldn't be judged by the ISP criteria during a transfer), I created the simplified language: "Add to Section 8.3 "...they can justify under current ARIN policies showing how the addresses will be utilized within 12 months." Remove from 4.2.4.4: "This reduction does not apply to resources received via section 8.3. An organization receiving a transfer under section 8.3 may continue to request up to a 12-month supply of IP addresses." The *intent* of the Section 8.3 language was that it mean "can justify (using current ARIN policy for testing what 'need' means) showing how the addresses will be utilized within 12 months" and *not* "can justify (including all of the various gotchas in Section 4 that apply to allocation operations)" It was never my intent to, for instance, require the recipient of a specified transfer under 8.3 to be required to comply with 4.2.2.1.4 "Renumber and return" for instance. Now, the actual language that is in the NRPM says "The recipient must demonstrate the need for up to a 24-month supply* of IP address resources under current ARIN policies and sign an RSA." ... if someone thinks that "demonstrate the need...under current ARIN policies" means not just "demonstrate the need" but also "fall into compliance with every nuance of section 4 that might be applied if they were getting the addresses from ARIN" (ex. 4.2.1.5 requiring a /20 minimum for ISPs) then I guess we need another policy modification. Is that really how ARIN staff is interpreting it? And why is this discussion here and not on arin-ppml? Matthew Kaufman (* note that it is 24 months because I submitted another policy proposal that was considered at the same time to bump the 12 months up to 24, and both passed) From you at ugec.net Wed May 1 09:21:25 2013 From: you at ugec.net (ISHII, Yuji) Date: Wed, 01 May 2013 18:21:25 +0900 Subject: Could not send email to office 365 Message-ID: <20130501182123.2455.AEA43824@ugec.net> Hello folks, Have you ever seen DNS issues on Office 365? MX record of Office 365 is example.mail.eo.outlook.com. I can get the MX record, however, I could not get the A record of the MX record, got Timeout. Does anyone have the same issue? Sincerely, Yuji From schmid at dfn.de Wed May 1 09:40:33 2013 From: schmid at dfn.de (Thomas Schmid) Date: Wed, 01 May 2013 11:40:33 +0200 Subject: Tier1 blackholing policy? In-Reply-To: <517FEA88.5030605@bogus.com> References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org> <1367334447.31455.5.camel@hounddog> <517FE206.5070306@dfn.de> <517FEA88.5030605@bogus.com> Message-ID: <5180E311.4040209@dfn.de> Joel, Am 30.04.2013 18:00, schrieb joel jaeggli: > On 4/30/13 8:23 AM, Thomas Schmid wrote: >> On 30.04.2013 17:07, Chris Boyd wrote: >>> On Tue, 2013-04-30 at 10:59 -0400, ML wrote: >>>> 1) Do nothing - They're supposed deliver any and all bits >>>> (Disregarding >>>> a DoS or similiar situation which impedes said network) >>>> 2) Prefix filter - Don't be a party (at least in one direction) to the >>>> bad actors traffic. >>> >>> 3 - Deliver all packets unless I've signed up for an enhanced security >>> offering? >>> >> >> right - I see this really as something that should be decided at the >> edge >> of the internet (Tier2+) and not in the core. > You seem to have odd ideas about what it means to be a settlement free > provider. Most of their customers are not smaller internet service > providers. I know what it means to be a customer of $LargeGlobalISPthatsellsTransittootherISPs since 1995 and I have *never* seen one of these guys blackholing single IPs on their own (and I'm not talking about RTB, botnet controllers that threaten to kill the internet etc.). Now since a few weeks we get regular complaints about this. So something has changed. The sensitive approach would really be to make this an opt-in service for their customers and not a default service without opt-out option. In times of CGN and hundrets or thousands of websites behind one IP, blocking addresses is not the right answer to the phishing problem. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4589 bytes Desc: S/MIME Kryptografische Unterschrift URL: From jcurran at arin.net Wed May 1 10:03:47 2013 From: jcurran at arin.net (John Curran) Date: Wed, 1 May 2013 10:03:47 +0000 Subject: "It's the end of the world as we know it" -- REM In-Reply-To: <5180C96C.1050709@matthew.at> References: <8DA1853CE466B041B104C1CAEE00B3748FC5881F@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FC65236@CHAXCH01.corp.arin.net> <5180C96C.1050709@matthew.at> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FC814D5@CHAXCH01.corp.arin.net> On May 1, 2013, at 3:51 AM, Matthew Kaufman wrote: > Now, the actual language that is in the NRPM says "The recipient must demonstrate the need for up to a 24-month supply* of IP address resources under current ARIN policies and sign an RSA." ... if someone thinks that "demonstrate the need...under current ARIN policies" means not just "demonstrate the need" but also "fall into compliance with every nuance of section 4 that might be applied if they were getting the addresses from ARIN" (ex. 4.2.1.5 requiring a /20 minimum for ISPs) then I guess we need another policy modification. Correct, if one considers that a problem (particularly at runout) > Is that really how ARIN staff is interpreting it? Also correct; as noted in prior email and per the staff assessments since this language was first introduced, "demonstrate the need ... under current ARIN policies" first requires assessment against current ARIN policies (only with the longer horizon) to determine if one is a valid recipient. > And why is this discussion here and not on arin-ppml? Indeterminate; it appears to be follow-up to discussion about IPv4 runout in the region being potentially earlier than expected. arin-ppml is definitely a more appropriate list for such discussions. FYI, /John John Curran President and CEO ARIN From rdobbins at arbor.net Wed May 1 10:09:21 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 1 May 2013 10:09:21 +0000 Subject: Tier1 blackholing policy? In-Reply-To: <5180E311.4040209@dfn.de> References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org> <1367334447.31455.5.camel@hounddog> <517FE206.5070306@dfn.de> <517FEA88.5030605@bogus.com> <5180E311.4040209@dfn.de> Message-ID: <7D6DA41D-B29A-407A-A65B-17CA8C930FF4@arbor.net> On May 1, 2013, at 4:40 PM, Thomas Schmid wrote: > Now since a few weeks we get regular complaints about this. So something has changed. Yes, things have changed. There are reasons that some of the transit ISPs are performing this blocking. They aren't doing it for kicks. For example, there are non-insignificant numbers of servers/accounts which have been compromised and used to launch large-scale, high-impact DDoS attacks. The negative impact of allowing these servers to emit attack traffic far outweighs the inconvenience experienced by a few end-customers trying to access these servers (which are compromised, anyways, and therefore it isn't a good idea to try and access them in the first place). Suggest you ask the transit ISPs in question directly. You aren't likely to get an authoritative answer on a public email list. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jsw at inconcepts.biz Wed May 1 10:42:32 2013 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 1 May 2013 06:42:32 -0400 Subject: Mitigating DNS amplification attacks In-Reply-To: <533A3ECD-145F-4FB8-8B52-D245717E8D98@puck.nether.net> References: <533A3ECD-145F-4FB8-8B52-D245717E8D98@puck.nether.net> Message-ID: On Tue, Apr 30, 2013 at 8:35 PM, Jared Mauch wrote: > Please provide advice and insights as well as directing customers to the openresolverproject.org website. We want to close these down, if you need an accurate list of IPs in your ASN, please email me and I can give you very accurate data. I think that a public list of open-resolvers is probably overdue, and the only way to get them fixed. It is trivial to scan the entire IPv4 address space for DNS servers that do no throttling even without the resources of a malicious botnet. Smurf was only "fixed" because, as there were fewer networks not running `no ip directed-broadcast,` the remaining amplification sources were flooded with huge amounts of malicious traffic. The public list of smurf amplifiers turned out to be the only way to really deal with it. I predict the same will be true with DNS. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From rdobbins at arbor.net Wed May 1 10:53:27 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 1 May 2013 10:53:27 +0000 Subject: Mitigating DNS amplification attacks In-Reply-To: References: <533A3ECD-145F-4FB8-8B52-D245717E8D98@puck.nether.net> Message-ID: On May 1, 2013, at 5:42 PM, Jeff Wheeler wrote: > The public list of smurf amplifiers turned out to be the only way to really deal with it. It certainly helped; but the real solution was to get Cisco, et. al. to disable directed broadcasts by default. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rsk at gsp.org Wed May 1 11:44:35 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 1 May 2013 07:44:35 -0400 Subject: Tier1 blackholing policy? In-Reply-To: <6C023FA3-1159-4516-B593-43957425FD37@puck.nether.net> References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org> <1367334447.31455.5.camel@hounddog> <1F4BFF91-3B1E-4B27-98C8-0515E12B93E6@puck.nether.net> <517FE1A6.3030609@forthnetgroup.gr> <6C023FA3-1159-4516-B593-43957425FD37@puck.nether.net> Message-ID: <20130501114435.GA17671@gsp.org> On Tue, Apr 30, 2013 at 12:47:40PM -0400, Jared Mauch wrote: > If the phishing attack is against an enterprise that is also an ISP, > surely you can imagine a case where they might block traffic to prevent > folks from being phished. This is not an effective anti-phishing tactic, any more than "user education" is an effective anti-phishing tactic. (Let me quote Marcus Ranum on the latter: "if it was going to work, it would have worked by now." And let me observe: it's never worked; it's not working; it's never going to work.) > i think it's great that someone is blocking folks from being infected with either malware or giving up their private details improperly. One person's "malware" is merely an interesting collection of inert bits to someone else, just as "email virus" has no operational meaning to anyone clueful enough to run a sensible mail client on a sensible operating system. Thus one undesirable effect of such blocking is that it denies access to researchers who are at nearly zero risk of negative consequences *and* who might be the very people in a position to understand the threat (phishing, malware, etc.) and figure out how to mitigate it. Another is that it presents a false sense of security to the ignorant, the lazy, and the careless. While in the short term that may seem benevolent and useful, I think in the long term it has a deleterious effect on security as a whole. And if we've arrived at a point in time where people are actually considering making routing decisions based on longstanding design and implementation defects in consumer operating systems and applications, then I think "long term" equates to "right now". ---rsk From jared at puck.nether.net Wed May 1 11:53:06 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 1 May 2013 07:53:06 -0400 Subject: Tier1 blackholing policy? In-Reply-To: <20130501114435.GA17671@gsp.org> References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org> <1367334447.31455.5.camel@hounddog> <1F4BFF91-3B1E-4B27-98C8-0515E12B93E6@puck.nether.net> <517FE1A6.3030609@forthnetgroup.gr> <6C023FA3-1159-4516-B593-43957425FD37@puck.nether.net> <20130501114435.GA17671@gsp.org> Message-ID: On May 1, 2013, at 7:44 AM, Rich Kulawiec wrote: > On Tue, Apr 30, 2013 at 12:47:40PM -0400, Jared Mauch wrote: >> If the phishing attack is against an enterprise that is also an ISP, >> surely you can imagine a case where they might block traffic to prevent >> folks from being phished. > > This is not an effective anti-phishing tactic, any more than "user education" > is an effective anti-phishing tactic. (Let me quote Marcus Ranum on > the latter: "if it was going to work, it would have worked by now." > And let me observe: it's never worked; it's not working; it's never > going to work.) We're talking about denying access to what is typically a compromised end-host which is in violation of an AUP. Speaking about my employer, we typically don't see something null0'ed for more than a few hours until we have confirmed the host is offline being repaired. I don't know about other networks practices which is what started the thread. >> i think it's great that someone is blocking folks from being infected with either malware or giving up their private details improperly. > > One person's "malware" is merely an interesting collection of inert > bits to someone else, just as "email virus" has no operational meaning > to anyone clueful enough to run a sensible mail client on a sensible > operating system. > > Thus one undesirable effect of such blocking is that it denies access to > researchers who are at nearly zero risk of negative consequences *and* > who might be the very people in a position to understand the threat > (phishing, malware, etc.) and figure out how to mitigate it. Another is > that it presents a false sense of security to the ignorant, the lazy, > and the careless. While in the short term that may seem benevolent and > useful, I think in the long term it has a deleterious effect on security > as a whole. And if we've arrived at a point in time where people are > actually considering making routing decisions based on longstanding design > and implementation defects in consumer operating systems and applications, > then I think "long term" equates to "right now". I think many people understand these risks and tradeoffs. We could stop mitigating DDoS attacks or responding to security complaints as well with this line of reasoning as it could be interfering with law-enforcement actions, or a researcher. Just because the house has been broken into, doesn't mean as the provider of the roads that we're going to let everyone visit it until the owner has a chance to secure it properly. I don't like that role, but it becomes necessary at times. What you are suggesting is a slippery slope to no mitigation of any badness which will lead to a lack of trust and confidence in the market. That to me is a plain and simple reason to do the right thing, even if it causes a problem for a few hours or a day or two. - Jared From dmiller at tiggee.com Wed May 1 12:46:40 2013 From: dmiller at tiggee.com (David Miller) Date: Wed, 01 May 2013 08:46:40 -0400 Subject: Tier1 blackholing policy? In-Reply-To: <5180E311.4040209@dfn.de> References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org> <1367334447.31455.5.camel@hounddog> <517FE206.5070306@dfn.de> <517FEA88.5030605@bogus.com> <5180E311.4040209@dfn.de> Message-ID: <51810EB0.3030402@tiggee.com> On 05/01/2013 05:40 AM, Thomas Schmid wrote: > Joel, > > Am 30.04.2013 18:00, schrieb joel jaeggli: >> On 4/30/13 8:23 AM, Thomas Schmid wrote: >>> On 30.04.2013 17:07, Chris Boyd wrote: >>>> On Tue, 2013-04-30 at 10:59 -0400, ML wrote: >>>>> 1) Do nothing - They're supposed deliver any and all bits >>>>> (Disregarding >>>>> a DoS or similiar situation which impedes said network) >>>>> 2) Prefix filter - Don't be a party (at least in one direction) to >>>>> the >>>>> bad actors traffic. >>>> >>>> 3 - Deliver all packets unless I've signed up for an enhanced security >>>> offering? >>>> >>> >>> right - I see this really as something that should be decided at the >>> edge >>> of the internet (Tier2+) and not in the core. >> You seem to have odd ideas about what it means to be a settlement >> free provider. Most of their customers are not smaller internet >> service providers. > > I know what it means to be a customer of > $LargeGlobalISPthatsellsTransittootherISPs since > 1995 and I have *never* seen one of these guys blackholing > single IPs on their own (and I'm not talking about RTB, botnet > controllers that threaten to kill > the internet etc.). Now since a few weeks we get regular complaints > about this. So something has changed. > > The sensitive approach would really be to make this an opt-in service > for their customers > and not a default service without opt-out option. In times of CGN and > hundrets or thousands of > websites behind one IP, blocking addresses is not the right answer to > the phishing problem. > ... or perhaps on an internet where many network owners block / police / throttle packets by source or destination, implementing CGN or stacking thousands of websites behind one IP address are poor solutions to the connectivity problem. My only issue is the lack of information provided when blocks go into place. I would love to see networks provide information publicly that shows what is being blocked along with a description of why. A history that extends for a few days would be a bonus. -DMM From jabley at hopcount.ca Wed May 1 13:20:59 2013 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 1 May 2013 09:20:59 -0400 Subject: Andros Island Connectivity? In-Reply-To: <3cd09fee-866b-4112-90c7-c86a3cb2c64f@email.android.com> References: , <3cd09fee-866b-4112-90c7-c86a3cb2c64f@email.android.com> Message-ID: <1AD09BB0-9996-41B4-BCE9-0258C1B61A9C@hopcount.ca> On 2013-05-01, at 01:23, joseph.snyder at gmail.com wrote: > Doesn't cable Bahamas sell in andros BaTelCo has five retail stores on Andros too, which suggests they offer some kind of service there (whether wireline or wireless). For a list whose subscribers have generally more experience on the ground in the Caribbean, perhaps try . Joe From joesox at gmail.com Wed May 1 13:24:15 2013 From: joesox at gmail.com (JoeSox) Date: Wed, 1 May 2013 06:24:15 -0700 Subject: Could not send email to office 365 In-Reply-To: <20130501182123.2455.AEA43824@ugec.net> References: <20130501182123.2455.AEA43824@ugec.net> Message-ID: The company I work for has been having Outlook connectivity issues (intermittent for only a few end users) for the past 7 days for Office 365. We are in an upgrade status (on the 18th days or so; have been told it can last 30 days) and they changed our MX records without formal notification. We updated those on a Thursday or Friday and it worked until the following Monday where we observed it again, then magically fixed itself late afternoon that Monday. We had some more reports yesterday. The Microsoft technical support has not been helpful troubleshooting this for us. I am hoping it is related to our upgrade status but I cannot get an answer from anyone. -- Thanks, Joe On Wed, May 1, 2013 at 2:21 AM, ISHII, Yuji wrote: > Hello folks, > > Have you ever seen DNS issues on Office 365? > > MX record of Office 365 is example.mail.eo.outlook.com. > I can get the MX record, however, I could not get the A record of the MX > record, got Timeout. > > Does anyone have the same issue? > > Sincerely, > Yuji > > From ahebert at pubnix.net Wed May 1 13:36:41 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 01 May 2013 09:36:41 -0400 Subject: Mitigating DNS amplification attacks In-Reply-To: References: <533A3ECD-145F-4FB8-8B52-D245717E8D98@puck.nether.net> Message-ID: <51811A69.2090800@pubnix.net> Well, I was going more for a public list of ISP that refuse to BCP38 their networks. But that's just me =D On point: (If your corporation is massive enough) Basically: . Mirror DST Port 53; . Write some software to stats who's spamming the same DST IP with the same query; . Dynamic ACL them; then . Give a talk to your customers =D ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 05/01/13 06:42, Jeff Wheeler wrote: > On Tue, Apr 30, 2013 at 8:35 PM, Jared Mauch wrote: >> Please provide advice and insights as well as directing customers to the openresolverproject.org website. We want to close these down, if you need an accurate list of IPs in your ASN, please email me and I can give you very accurate data. > I think that a public list of open-resolvers is probably overdue, and > the only way to get them fixed. > > It is trivial to scan the entire IPv4 address space for DNS servers > that do no throttling even without the resources of a malicious > botnet. > > Smurf was only "fixed" because, as there were fewer networks not > running `no ip directed-broadcast,` the remaining amplification > sources were flooded with huge amounts of malicious traffic. The > public list of smurf amplifiers turned out to be the only way to > really deal with it. I predict the same will be true with DNS. > From jim at reptiles.org Wed May 1 14:22:19 2013 From: jim at reptiles.org (Jim Mercer) Date: Wed, 1 May 2013 10:22:19 -0400 Subject: Andros Island Connectivity? In-Reply-To: <1AD09BB0-9996-41B4-BCE9-0258C1B61A9C@hopcount.ca> References: <3cd09fee-866b-4112-90c7-c86a3cb2c64f@email.android.com> <1AD09BB0-9996-41B4-BCE9-0258C1B61A9C@hopcount.ca> Message-ID: <20130501142218.GB24897@reptiles.org> On Wed, May 01, 2013 at 09:20:59AM -0400, Joe Abley wrote: > On 2013-05-01, at 01:23, joseph.snyder at gmail.com wrote: > > > Doesn't cable Bahamas sell in andros > > BaTelCo has five retail stores on Andros too, which suggests they offer some kind of service there (whether wireline or wireless). its been a long time since i've done much in the caribbean, but i'd be quite surprised if the bahamas didn't have some decent amount of terrestrial connectivity by this time. back in the day when Cable and Wireless controlled everything, it was a pretty costly environment to work in. don't know if that's still the case. -- Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 "He who dies with the most toys is nonetheless dead" From ryan at finnesey.com Wed May 1 15:42:04 2013 From: ryan at finnesey.com (Ryan Finnesey) Date: Wed, 1 May 2013 15:42:04 +0000 Subject: Could not send email to office 365 In-Reply-To: References: <20130501182123.2455.AEA43824@ugec.net>, Message-ID: <536732d21d6a4d21b8183a8816320153@BY2PR05MB079.namprd05.prod.outlook.com> I am also having the some issues going on 3 weeks now. I cannot access my e-mail via Outlook and my MX records keep changing. It is nuts support has been unable to help. ________________________________________ From: JoeSox Sent: Wednesday, May 01, 2013 9:24 AM To: nanog at nanog.org Subject: Re: Could not send email to office 365 The company I work for has been having Outlook connectivity issues (intermittent for only a few end users) for the past 7 days for Office 365. We are in an upgrade status (on the 18th days or so; have been told it can last 30 days) and they changed our MX records without formal notification. We updated those on a Thursday or Friday and it worked until the following Monday where we observed it again, then magically fixed itself late afternoon that Monday. We had some more reports yesterday. The Microsoft technical support has not been helpful troubleshooting this for us. I am hoping it is related to our upgrade status but I cannot get an answer from anyone. -- Thanks, Joe On Wed, May 1, 2013 at 2:21 AM, ISHII, Yuji wrote: > Hello folks, > > Have you ever seen DNS issues on Office 365? > > MX record of Office 365 is example.mail.eo.outlook.com. > I can get the MX record, however, I could not get the A record of the MX > record, got Timeout. > > Does anyone have the same issue? > > Sincerely, > Yuji > > From blair.trosper at gmail.com Wed May 1 16:09:40 2013 From: blair.trosper at gmail.com (Blair Trosper) Date: Wed, 1 May 2013 09:09:40 -0700 Subject: Google Public DNS Problems? Message-ID: Is anyone else seeing this? From Santa Clara, CA, on Comcast Business...I'm getting SERVFAIL for any query I throw at 8.8.8.8 and 8.8.4.4... Level 3's own public resolvers are fine for me, as are OpenDNS's resolvers. Blair From wbailey at satelliteintelligencegroup.com Wed May 1 16:12:18 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 1 May 2013 16:12:18 +0000 Subject: Could not send email to office 365 In-Reply-To: References: <20130501182123.2455.AEA43824@ugec.net>, Message-ID: Just another day for them.. Office 365 has been broken for us for a long time. I've been thinking about a rackspace hosted exchange instead.. Have you guys looked into alternatives? Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: JoeSox Date: 05/01/2013 6:27 AM (GMT-08:00) To: nanog at nanog.org Subject: Re: Could not send email to office 365 The company I work for has been having Outlook connectivity issues (intermittent for only a few end users) for the past 7 days for Office 365. We are in an upgrade status (on the 18th days or so; have been told it can last 30 days) and they changed our MX records without formal notification. We updated those on a Thursday or Friday and it worked until the following Monday where we observed it again, then magically fixed itself late afternoon that Monday. We had some more reports yesterday. The Microsoft technical support has not been helpful troubleshooting this for us. I am hoping it is related to our upgrade status but I cannot get an answer from anyone. -- Thanks, Joe On Wed, May 1, 2013 at 2:21 AM, ISHII, Yuji wrote: > Hello folks, > > Have you ever seen DNS issues on Office 365? > > MX record of Office 365 is example.mail.eo.outlook.com. > I can get the MX record, however, I could not get the A record of the MX > record, got Timeout. > > Does anyone have the same issue? > > Sincerely, > Yuji > > From hhoffman at ip-solutions.net Wed May 1 16:15:49 2013 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Wed, 01 May 2013 12:15:49 -0400 Subject: Google Public DNS Problems? In-Reply-To: References: Message-ID: <51813FB5.30708@ip-solutions.net> Works fine from here, Philadelphia, PA .edu and FIOS networks Cheers, Harry On 05/01/2013 12:09 PM, Blair Trosper wrote: > Is anyone else seeing this? From Santa Clara, CA, on Comcast > Business...I'm getting SERVFAIL for any query I throw at 8.8.8.8 and > 8.8.4.4... > > Level 3's own public resolvers are fine for me, as are OpenDNS's resolvers. > > Blair > From joesox at gmail.com Wed May 1 16:27:54 2013 From: joesox at gmail.com (JoeSox) Date: Wed, 1 May 2013 09:27:54 -0700 Subject: Could not send email to office 365 In-Reply-To: <536732d21d6a4d21b8183a8816320153@BY2PR05MB079.namprd05.prod.outlook.com> References: <20130501182123.2455.AEA43824@ugec.net> <536732d21d6a4d21b8183a8816320153@BY2PR05MB079.namprd05.prod.outlook.com> Message-ID: Ryan, Is your Office 365 account also in an upgrade status? If not, have you completed the upgrade? -- Thanks, Joe On Wed, May 1, 2013 at 8:42 AM, Ryan Finnesey wrote: > I am also having the some issues going on 3 weeks now. I cannot access my > e-mail via Outlook and my MX records keep changing. It is nuts support has > been unable to help. > ________________________________________ > > > From jabley at hopcount.ca Wed May 1 16:34:01 2013 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 1 May 2013 12:34:01 -0400 Subject: Google Public DNS Problems? In-Reply-To: References: Message-ID: On 2013-05-01, at 12:09, Blair Trosper wrote: > Is anyone else seeing this? From Santa Clara, CA, on Comcast > Business...I'm getting SERVFAIL for any query I throw at 8.8.8.8 and > 8.8.4.4... > > Level 3's own public resolvers are fine for me, as are OpenDNS's resolvers. Google just turned on validation across the whole of 8.8.8.8 and 8.8.4.4. The expected behaviour in the case where a response does not validate is to return SERVFAIL to the client. You could check that the queries you are sending are not suffering from poor signing hygiene (e.g. use the handy-dandy dnsviz.net visualisation). If this is a repeatable, consistent problem even for unsigned zones (or for zones that you've verified are signed correctly) and especially if it's widespread you might want to call google on the nanog courtesy phone and have them look for collateral damage from their recent foray into 8.8.8.8 validation. Raw output from dig/drill and traceroutes to 8.8.8.8/8.8.4.4 are highly recommended if you need to take this further. Joe From blair.trosper at gmail.com Wed May 1 16:38:29 2013 From: blair.trosper at gmail.com (Blair Trosper) Date: Wed, 1 May 2013 09:38:29 -0700 Subject: Google Public DNS Problems? In-Reply-To: References: Message-ID: That's all well and good, but I certainly wouldn't expect "nslookup gmail.com" or for "nslookup google.com" to return SERVFAIL On Wed, May 1, 2013 at 9:34 AM, Joe Abley wrote: > > On 2013-05-01, at 12:09, Blair Trosper wrote: > > > Is anyone else seeing this? From Santa Clara, CA, on Comcast > > Business...I'm getting SERVFAIL for any query I throw at 8.8.8.8 and > > 8.8.4.4... > > > > Level 3's own public resolvers are fine for me, as are OpenDNS's > resolvers. > > Google just turned on validation across the whole of 8.8.8.8 and 8.8.4.4. > The expected behaviour in the case where a response does not validate is to > return SERVFAIL to the client. > > You could check that the queries you are sending are not suffering from > poor signing hygiene (e.g. use the handy-dandy dnsviz.net visualisation). > > If this is a repeatable, consistent problem even for unsigned zones (or > for zones that you've verified are signed correctly) and especially if it's > widespread you might want to call google on the nanog courtesy phone and > have them look for collateral damage from their recent foray into 8.8.8.8 > validation. > > Raw output from dig/drill and traceroutes to 8.8.8.8/8.8.4.4 are highly > recommended if you need to take this further. > > > Joe From scott at doc.net.au Wed May 1 16:55:48 2013 From: scott at doc.net.au (Scott Howard) Date: Wed, 1 May 2013 09:55:48 -0700 Subject: Google Public DNS Problems? In-Reply-To: References: Message-ID: No issues on Comcast cable in the bay area, either Comcast business or Comcast home. Scott $ nslookup gmail.com 8.8.4.4 Server: 8.8.4.4 Address: 8.8.4.4#53 Non-authoritative answer: Name: gmail.com Address: 74.125.239.149 Name: gmail.com Address: 74.125.239.150 On Wed, May 1, 2013 at 9:09 AM, Blair Trosper wrote: > Is anyone else seeing this? From Santa Clara, CA, on Comcast > Business...I'm getting SERVFAIL for any query I throw at 8.8.8.8 and > 8.8.4.4... > > Level 3's own public resolvers are fine for me, as are OpenDNS's resolvers. > > Blair > From casey at deccio.net Wed May 1 16:58:23 2013 From: casey at deccio.net (Casey Deccio) Date: Wed, 1 May 2013 09:58:23 -0700 Subject: Google Public DNS Problems? In-Reply-To: References: Message-ID: On Wed, May 1, 2013 at 9:38 AM, Blair Trosper wrote: > That's all well and good, but I certainly wouldn't expect "nslookup > gmail.com" or for "nslookup google.com" to return SERVFAIL > If you set the CD (checking disabled) in the request, a response that would normally be SERVFAIL due to DNSSEC validation failure will return with the non-authenticated answer. With dig the flag to add is "+cd". I don't know if there's an equivalent for nslookup. For example: dig +cd @8.8.8.8 google.com Casey From blair.trosper at gmail.com Wed May 1 17:07:44 2013 From: blair.trosper at gmail.com (Blair Trosper) Date: Wed, 1 May 2013 10:07:44 -0700 Subject: Google Public DNS Problems? In-Reply-To: References: Message-ID: Goes all the way up to the A root server before failing spectacularly. Europa:~ blair$ dig +cd @8.8.8.8 google.com A ; <<>> DiG 9.8.3-P1 <<>> +cd @8.8.8.8 google.com A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47332 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com. IN A ;; AUTHORITY SECTION: . 467 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2013050100 1800 900 604800 86400 ;; Query time: 46 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed May 1 10:05:46 2013 ;; MSG SIZE rcvd: 104 On Wed, May 1, 2013 at 9:58 AM, Casey Deccio wrote: > On Wed, May 1, 2013 at 9:38 AM, Blair Trosper > wrote: > > That's all well and good, but I certainly wouldn't expect "nslookup > > gmail.com" or for "nslookup google.com" to return SERVFAIL > > > > If you set the CD (checking disabled) in the request, a response that > would normally be SERVFAIL due to DNSSEC validation failure will > return with the non-authenticated answer. With dig the flag to add is > "+cd". I don't know if there's an equivalent for nslookup. For > example: > > dig +cd @8.8.8.8 google.com > > Casey > From blair.trosper at gmail.com Wed May 1 17:12:10 2013 From: blair.trosper at gmail.com (Blair Trosper) Date: Wed, 1 May 2013 10:12:10 -0700 Subject: Google Public DNS Problems? In-Reply-To: References: Message-ID: 8.8.4.4 is now replying SERVFAIL whereas 8.8.8.8 is suddenly working fine again... On Wed, May 1, 2013 at 10:07 AM, Blair Trosper wrote: > Goes all the way up to the A root server before failing spectacularly. > > Europa:~ blair$ dig +cd @8.8.8.8 google.com A > > ; <<>> DiG 9.8.3-P1 <<>> +cd @8.8.8.8 google.com A > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47332 > ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;google.com. IN A > > ;; AUTHORITY SECTION: > . 467 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2013050100 1800 > 900 604800 86400 > > ;; Query time: 46 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Wed May 1 10:05:46 2013 > ;; MSG SIZE rcvd: 104 > > > On Wed, May 1, 2013 at 9:58 AM, Casey Deccio wrote: > >> On Wed, May 1, 2013 at 9:38 AM, Blair Trosper >> wrote: >> > That's all well and good, but I certainly wouldn't expect "nslookup >> > gmail.com" or for "nslookup google.com" to return SERVFAIL >> > >> >> If you set the CD (checking disabled) in the request, a response that >> would normally be SERVFAIL due to DNSSEC validation failure will >> return with the non-authenticated answer. With dig the flag to add is >> "+cd". I don't know if there's an equivalent for nslookup. For >> example: >> >> dig +cd @8.8.8.8 google.com >> >> Casey >> > > From andrew.fried at gmail.com Wed May 1 17:17:18 2013 From: andrew.fried at gmail.com (Andrew Fried) Date: Wed, 01 May 2013 13:17:18 -0400 Subject: Google Public DNS Problems? In-Reply-To: References: Message-ID: <51814E1E.4070503@gmail.com> Your IPs may have been rate limited... Andy Andrew Fried andrew.fried at gmail.com On 5/1/13 12:38 PM, Blair Trosper wrote: > That's all well and good, but I certainly wouldn't expect "nslookup > gmail.com" or for "nslookup google.com" to return SERVFAIL > > > On Wed, May 1, 2013 at 9:34 AM, Joe Abley wrote: > >> >> On 2013-05-01, at 12:09, Blair Trosper wrote: >> >>> Is anyone else seeing this? From Santa Clara, CA, on Comcast >>> Business...I'm getting SERVFAIL for any query I throw at 8.8.8.8 and >>> 8.8.4.4... >>> >>> Level 3's own public resolvers are fine for me, as are OpenDNS's >> resolvers. >> >> Google just turned on validation across the whole of 8.8.8.8 and 8.8.4.4. >> The expected behaviour in the case where a response does not validate is to >> return SERVFAIL to the client. >> >> You could check that the queries you are sending are not suffering from >> poor signing hygiene (e.g. use the handy-dandy dnsviz.net visualisation). >> >> If this is a repeatable, consistent problem even for unsigned zones (or >> for zones that you've verified are signed correctly) and especially if it's >> widespread you might want to call google on the nanog courtesy phone and >> have them look for collateral damage from their recent foray into 8.8.8.8 >> validation. >> >> Raw output from dig/drill and traceroutes to 8.8.8.8/8.8.4.4 are highly >> recommended if you need to take this further. >> >> >> Joe From tony at swalter.com Wed May 1 17:19:16 2013 From: tony at swalter.com (Tony Patti) Date: Wed, 1 May 2013 13:19:16 -0400 Subject: Could not send email to office 365 In-Reply-To: <536732d21d6a4d21b8183a8816320153@BY2PR05MB079.namprd05.prod.outlook.com> References: <20130501182123.2455.AEA43824@ugec.net>, <536732d21d6a4d21b8183a8816320153@BY2PR05MB079.namprd05.prod.outlook.com> Message-ID: <09e301ce4690$0259fd50$070df7f0$@swalter.com> After our "upgrade", we started to see the body of received PLAIN TEXT emails truncated at less than 256 bytes, which frequently truncated emails in the middle of a word, the fix was a "setting change". Since being standardized in 1982 with RFC 822, you would think PLAIN TEXT emails would just work "out of the box". Tony -----Original Message----- From: Ryan Finnesey [mailto:ryan at finnesey.com] Sent: Wednesday, May 01, 2013 11:42 AM To: JoeSox; nanog at nanog.org Subject: RE: Could not send email to office 365 I am also having the some issues going on 3 weeks now. I cannot access my e-mail via Outlook and my MX records keep changing. It is nuts support has been unable to help. ________________________________________ From: JoeSox Sent: Wednesday, May 01, 2013 9:24 AM To: nanog at nanog.org Subject: Re: Could not send email to office 365 The company I work for has been having Outlook connectivity issues (intermittent for only a few end users) for the past 7 days for Office 365. We are in an upgrade status (on the 18th days or so; have been told it can last 30 days) and they changed our MX records without formal notification. We updated those on a Thursday or Friday and it worked until the following Monday where we observed it again, then magically fixed itself late afternoon that Monday. We had some more reports yesterday. The Microsoft technical support has not been helpful troubleshooting this for us. I am hoping it is related to our upgrade status but I cannot get an answer from anyone. -- Thanks, Joe On Wed, May 1, 2013 at 2:21 AM, ISHII, Yuji wrote: > Hello folks, > > Have you ever seen DNS issues on Office 365? > > MX record of Office 365 is example.mail.eo.outlook.com. > I can get the MX record, however, I could not get the A record of the > MX record, got Timeout. > > Does anyone have the same issue? > > Sincerely, > Yuji > > From dot at dotat.at Wed May 1 17:39:53 2013 From: dot at dotat.at (Tony Finch) Date: Wed, 1 May 2013 18:39:53 +0100 Subject: Google Public DNS Problems? In-Reply-To: References: Message-ID: Blair Trosper wrote: > Goes all the way up to the A root server before failing spectacularly. That is an extremely weird response. Are you sure your queries are not being intercepted by a middlebox? What happens if you use dig +vc ? Do you get a similar round-trip time when pinging 8.8.8.8 to the one reported by dig? > Europa:~ blair$ dig +cd @8.8.8.8 google.com A > > ; <<>> DiG 9.8.3-P1 <<>> +cd @8.8.8.8 google.com A > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47332 > ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;google.com. IN A > > ;; AUTHORITY SECTION: > . 467 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2013050100 1800 900 604800 86400 > > ;; Query time: 46 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Wed May 1 10:05:46 2013 > ;; MSG SIZE rcvd: 104 Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From owen at delong.com Wed May 1 17:54:32 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 1 May 2013 10:54:32 -0700 Subject: "It's the end of the world as we know it" -- REM In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748FC5881F@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FC65236@CHAXCH01.corp.arin.net> Message-ID: I believe Jimmy's confusion results primarily as follows: From NRPM 8.3: > 8.3. Transfers between Specified Recipients within the ARIN Region > > In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions. > Conditions on source of the transfer: > The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. > The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. > The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. > The minimum transfer size is a /24 > Conditions on recipient of the transfer: > The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA. > The resources transferred will be subject to current ARIN policies. Note that the minimum /24 restriction he so often references is a restriction on the minimum that a transferor can provide. It does not mean that there are not more specific restrictions on recipients. It is quite clear in the policy, as quoted above, that the only reference to a /24 is in the section controlling the source of the transfer. The only exception to the rest of ARIN policy for the recipient is that it allows a 24 month supply rather than the current 3 month (ISP) or 12 month (End-User) limitation when obtaining resources from the free pool. Owen From cmadams at hiwaay.net Wed May 1 18:14:31 2013 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 1 May 2013 13:14:31 -0500 Subject: Google Public DNS Problems? In-Reply-To: References: Message-ID: <20130501181431.GB4037@hiwaay.net> Once upon a time, Joe Abley said: > Raw output from dig/drill and traceroutes to 8.8.8.8/8.8.4.4 are highly recommended if you need to take this further. Does Google (and OpenDNS for that matter) support any "special" queries that identify the host/cluster/etc.? Something like BIND's CHAOS HOSTNAME.BIND (which also works for Unbound and some other servers), or UltraDNS's WHOAREYOU.ULTRADNS.NET. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jared at puck.nether.net Wed May 1 18:23:46 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 1 May 2013 14:23:46 -0400 Subject: Google Public DNS Problems? In-Reply-To: References: Message-ID: <35EE6F61-6847-4CEF-B996-4BF5574C7BEF@puck.nether.net> On May 1, 2013, at 1:39 PM, Tony Finch wrote: > Blair Trosper wrote: > >> Goes all the way up to the A root server before failing spectacularly. > > That is an extremely weird response. Are you sure your queries are not > being intercepted by a middlebox? What happens if you use dig +vc ? > Do you get a similar round-trip time when pinging 8.8.8.8 to the one > reported by dig? Some places like Wayport/attwifi intercept all udp/53 traffic and direct it to their local server. You won't notice this with a ping, but you will see it in the 0 or 1ms reply :) - Jared From blair.trosper at gmail.com Wed May 1 18:25:02 2013 From: blair.trosper at gmail.com (Blair Trosper) Date: Wed, 1 May 2013 11:25:02 -0700 Subject: Google Public DNS Problems? In-Reply-To: <35EE6F61-6847-4CEF-B996-4BF5574C7BEF@puck.nether.net> References: <35EE6F61-6847-4CEF-B996-4BF5574C7BEF@puck.nether.net> Message-ID: Traceroute is getting the right place and 8.8.8.8 is working, though :) On Wed, May 1, 2013 at 11:23 AM, Jared Mauch wrote: > > On May 1, 2013, at 1:39 PM, Tony Finch wrote: > > > Blair Trosper wrote: > > > >> Goes all the way up to the A root server before failing spectacularly. > > > > That is an extremely weird response. Are you sure your queries are not > > being intercepted by a middlebox? What happens if you use dig +vc ? > > Do you get a similar round-trip time when pinging 8.8.8.8 to the one > > reported by dig? > > Some places like Wayport/attwifi intercept all udp/53 traffic and direct > it to their local server. You won't notice this with a ping, but you will > see it in the 0 or 1ms reply :) > > - Jared From Jason_Livingood at cable.comcast.com Wed May 1 19:13:22 2013 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Wed, 1 May 2013 19:13:22 +0000 Subject: Google Public DNS Problems? In-Reply-To: <35EE6F61-6847-4CEF-B996-4BF5574C7BEF@puck.nether.net> Message-ID: <10229F86C86EB444898E629583FD4171884A95EA@PACDCEXMB06.cable.comcast.com> On 5/1/13 2:23 PM, "Jared Mauch" wrote: >On May 1, 2013, at 1:39 PM, Tony Finch wrote: >>Blair Trosper wrote: >> >>> Goes all the way up to the A root server before failing spectacularly. >> >> That is an extremely weird response. Are you sure your queries are not >> being intercepted by a middlebox? What happens if you use dig +vc ? >> Do you get a similar round-trip time when pinging 8.8.8.8 to the one >> reported by dig? > >Some places like Wayport/attwifi intercept all udp/53 traffic and direct >it to their local server. You won't notice this with a ping, but you >will see it in the 0 or 1ms reply :) FWIW, no DNS intercepts happen on the Comcast network? Jason (Comcast) From wbailey at satelliteintelligencegroup.com Wed May 1 19:23:45 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 1 May 2013 19:23:45 +0000 Subject: Data Center Installations Message-ID: Do any of you have a "go to" resource for materials used in installations? Tie wraps, cable management, blahblahblah? I have found several places, but I'm curious to know what the nanog ninja's have to say. //warren From joe at nethead.com Wed May 1 19:32:09 2013 From: joe at nethead.com (Joe Hamelin) Date: Wed, 1 May 2013 12:32:09 -0700 Subject: Data Center Installations In-Reply-To: References: Message-ID: Graybar. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Wed, May 1, 2013 at 12:23 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Do any of you have a "go to" resource for materials used in installations? > Tie wraps, cable management, blahblahblah? > > I have found several places, but I'm curious to know what the nanog > ninja's have to say. > > //warren > > From hhoffman at ip-solutions.net Wed May 1 19:33:12 2013 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Wed, 01 May 2013 15:33:12 -0400 Subject: Data Center Installations In-Reply-To: References: Message-ID: <51816DF8.6050703@ip-solutions.net> On the cheap Lowes/Home Depot are awesome, and they're everywhere. On 05/01/2013 03:23 PM, Warren Bailey wrote: > Do any of you have a "go to" resource for materials used in installations? Tie wraps, cable management, blahblahblah? > > I have found several places, but I'm curious to know what the nanog ninja's have to say. > > //warren > From phiber at phiber.org Wed May 1 19:36:08 2013 From: phiber at phiber.org (Christopher Rogers) Date: Wed, 1 May 2013 12:36:08 -0700 Subject: Data Center Installations In-Reply-To: References: Message-ID: I'm a huge fan of netig... they bend over backwards for you. -chris Do any of you have a "go to" resource for materials used in installations? Tie wraps, cable management, blahblahblah? I have found several places, but I'm curious to know what the nanog ninja's have to say. //warren From otis at ocosa.com Wed May 1 19:39:53 2013 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Wed, 1 May 2013 14:39:53 -0500 Subject: Data Center Installations In-Reply-To: References: Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B018626@ocsbs.ocosa.com> -----Original Message----- From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] Sent: Wednesday, May 01, 2013 2:24 PM To: nanog at nanog.org Subject: Data Center Installations >Do any of you have a "go to" resource for materials used in installations? Tie wraps, cable management, blahblahblah? > >I have found several places, but I'm curious to know what the nanog ninja's have to say. > >//warren We've used both CSC and Graybar, more frequently CSC better deals in our case. For very nice affordable Cat 5e/6A patch cords iofast.com we've never purchased a patch from anywhere else since we found them. From george.herbert at gmail.com Wed May 1 19:42:04 2013 From: george.herbert at gmail.com (George Herbert) Date: Wed, 1 May 2013 12:42:04 -0700 Subject: Data Center Installations In-Reply-To: References: Message-ID: Seconded Graybar. If necessary, in the absence of Graybar or for tiny stuff, a Frys or Home Depot or Lowes. On Wed, May 1, 2013 at 12:32 PM, Joe Hamelin wrote: > Graybar. > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > > On Wed, May 1, 2013 at 12:23 PM, Warren Bailey < > wbailey at satelliteintelligencegroup.com> wrote: > > > Do any of you have a "go to" resource for materials used in > installations? > > Tie wraps, cable management, blahblahblah? > > > > I have found several places, but I'm curious to know what the nanog > > ninja's have to say. > > > > //warren > > > > > -- -george william herbert george.herbert at gmail.com From mike.lyon at gmail.com Wed May 1 19:49:58 2013 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 1 May 2013 12:49:58 -0700 Subject: Data Center Installations In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B018626@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018626@ocsbs.ocosa.com> Message-ID: <-7467070935839738690@unknownmsgid> Tessco or Hutton. Lil pricey unless you buy in bulk. Good fit for you though since they carry RF and antenna stuff too. -mike Sent from my iPhone On May 1, 2013, at 12:45, "Otis L. Surratt, Jr." wrote: > -----Original Message----- > From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] > Sent: Wednesday, May 01, 2013 2:24 PM > To: nanog at nanog.org > Subject: Data Center Installations > >> Do any of you have a "go to" resource for materials used in > installations? Tie wraps, cable management, blahblahblah? >> >> I have found several places, but I'm curious to know what the nanog > ninja's have to say. >> >> //warren > > We've used both CSC and Graybar, more frequently CSC better deals in our > case. > For very nice affordable Cat 5e/6A patch cords iofast.com we've never > purchased a patch from anywhere else since we found them. > From michael at rancid.berkeley.edu Wed May 1 19:54:19 2013 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Wed, 01 May 2013 12:54:19 -0700 Subject: Comcast Launches IPv6 for Business Customers In-Reply-To: References: Message-ID: <518172EB.4080502@rancid.berkeley.edu> On 04/29/13 15:38, Brzozowski, John wrote: > FYI for folks that are interested: > > http://corporate.comcast.com/comcast-voices/comcast-launches-ipv6-for-business-customers Great news! Strangely, I (a Comcast Business customer at home) have noticed RAs coming across my wire for several months now. I use a Comcast-supplied Arris cable modem, with no extra routing functionality. About 4-5 months ago, I thought I'd see if there was a Comcast DHCPv6 server on that wire, and I sent it ia-na and ia-pd requests--and got responses back, and I have had a DHCPv6 client running ever since. (See the headers of this message for more info.) So from my perspective, IPv6 on Comcast Business Internet has been "just working" for at least 4 months. I have signed up for the pilot, as a /56 would be really useful so that I can run v6 on all of my networks (wireless, wired, etc.). Any idea how it will work with a simple Arris cable modem and a reclaimed Mac Mini running *BSD as the router, given that I have already proven that it works? :) thanks and keep up the good work... michael From dougb at dougbarton.us Wed May 1 20:01:59 2013 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 01 May 2013 13:01:59 -0700 Subject: Mitigating DNS amplification attacks In-Reply-To: References: Message-ID: <518174B7.6080901@dougbarton.us> On 04/30/2013 05:28 PM, Thomas St-Pierre wrote: > The large majority of the servers being used in the attacks are not > open resolvers. Just DNS servers that are authoritative for a few > domains, and the default config of the dns application does referrals > to root for anything else. It sounds like you're already aware that this is the default behavior for an authoritative-only server, and while the referral to the roots is a largeish response and has been used for amplification attacks, it's also rather difficult to mitigate against. A BIND server can be configured to not do that, but contacting each of your customers about it might not have a good ROI. See https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful for more information. Meanwhile, thank you very much for being proactive in this regard. Would that more SPs were as net.responsible as you. :) Doug From yang.yu.list at gmail.com Wed May 1 20:14:03 2013 From: yang.yu.list at gmail.com (Yang Yu) Date: Wed, 1 May 2013 16:14:03 -0400 Subject: Google Public DNS Problems? In-Reply-To: <51814E1E.4070503@gmail.com> References: <51814E1E.4070503@gmail.com> Message-ID: It is very courteous to reply a SERVFAIL for requests being rate limited. On Wed, May 1, 2013 at 1:17 PM, Andrew Fried wrote: > Your IPs may have been rate limited... > > Andy > > Andrew Fried > andrew.fried at gmail.com > > On 5/1/13 12:38 PM, Blair Trosper wrote: >> That's all well and good, but I certainly wouldn't expect "nslookup >> gmail.com" or for "nslookup google.com" to return SERVFAIL >> >> >> On Wed, May 1, 2013 at 9:34 AM, Joe Abley wrote: >> >>> >>> On 2013-05-01, at 12:09, Blair Trosper wrote: >>> >>>> Is anyone else seeing this? From Santa Clara, CA, on Comcast >>>> Business...I'm getting SERVFAIL for any query I throw at 8.8.8.8 and >>>> 8.8.4.4... >>>> >>>> Level 3's own public resolvers are fine for me, as are OpenDNS's >>> resolvers. >>> >>> Google just turned on validation across the whole of 8.8.8.8 and 8.8.4.4. >>> The expected behaviour in the case where a response does not validate is to >>> return SERVFAIL to the client. >>> >>> You could check that the queries you are sending are not suffering from >>> poor signing hygiene (e.g. use the handy-dandy dnsviz.net visualisation). >>> >>> If this is a repeatable, consistent problem even for unsigned zones (or >>> for zones that you've verified are signed correctly) and especially if it's >>> widespread you might want to call google on the nanog courtesy phone and >>> have them look for collateral damage from their recent foray into 8.8.8.8 >>> validation. >>> >>> Raw output from dig/drill and traceroutes to 8.8.8.8/8.8.4.4 are highly >>> recommended if you need to take this further. >>> >>> >>> Joe > From choprboy at dakotacom.net Wed May 1 20:16:53 2013 From: choprboy at dakotacom.net (Adrian) Date: Wed, 1 May 2013 13:16:53 -0700 Subject: Data Center Installations In-Reply-To: References: Message-ID: <201305011316.53665.choprboy@dakotacom.net> On Wednesday 01 May 2013 12:23, Warren Bailey wrote: > Do any of you have a "go to" resource for materials used in installations? > Tie wraps, cable management, blahblahblah? > > I have found several places, but I'm curious to know what the nanog ninja's > have to say. > Would largely depend on your definition of "datacenter" (customer or operator) and what your corporate policies are. Speaking as the small ISP datacenter maintainer: Tie wraps, misc hardware - HomeDepot/Lowes Patch cords/bulk cable - Monoprice Patch panels/punchdown/custom fiber - Gruber Electrical (equip)/fiber/wall enclosures - Graybar/Tesco Electrical (power) - Local electrical shops/Home depot Adrian From ryan at finnesey.com Wed May 1 20:35:06 2013 From: ryan at finnesey.com (Ryan Finnesey) Date: Wed, 1 May 2013 20:35:06 +0000 Subject: Could not send email to office 365 In-Reply-To: <09e301ce4690$0259fd50$070df7f0$@swalter.com> References: <20130501182123.2455.AEA43824@ugec.net>, <536732d21d6a4d21b8183a8816320153@BY2PR05MB079.namprd05.prod.outlook.com> <09e301ce4690$0259fd50$070df7f0$@swalter.com> Message-ID: We have fixed the problem. I had to complete a clear install of Outlook and remove the credentials that where on the computer in the control panel under credential manager. This may also fix/help with your issue. Cheers Ryan -----Original Message----- From: Tony Patti [mailto:tony at swalter.com] Sent: Wednesday, May 1, 2013 1:19 PM To: Ryan Finnesey; 'JoeSox'; nanog at nanog.org Subject: RE: Could not send email to office 365 After our "upgrade", we started to see the body of received PLAIN TEXT emails truncated at less than 256 bytes, which frequently truncated emails in the middle of a word, the fix was a "setting change". Since being standardized in 1982 with RFC 822, you would think PLAIN TEXT emails would just work "out of the box". Tony -----Original Message----- From: Ryan Finnesey [mailto:ryan at finnesey.com] Sent: Wednesday, May 01, 2013 11:42 AM To: JoeSox; nanog at nanog.org Subject: RE: Could not send email to office 365 I am also having the some issues going on 3 weeks now. I cannot access my e-mail via Outlook and my MX records keep changing. It is nuts support has been unable to help. ________________________________________ From: JoeSox Sent: Wednesday, May 01, 2013 9:24 AM To: nanog at nanog.org Subject: Re: Could not send email to office 365 The company I work for has been having Outlook connectivity issues (intermittent for only a few end users) for the past 7 days for Office 365. We are in an upgrade status (on the 18th days or so; have been told it can last 30 days) and they changed our MX records without formal notification. We updated those on a Thursday or Friday and it worked until the following Monday where we observed it again, then magically fixed itself late afternoon that Monday. We had some more reports yesterday. The Microsoft technical support has not been helpful troubleshooting this for us. I am hoping it is related to our upgrade status but I cannot get an answer from anyone. -- Thanks, Joe On Wed, May 1, 2013 at 2:21 AM, ISHII, Yuji wrote: > Hello folks, > > Have you ever seen DNS issues on Office 365? > > MX record of Office 365 is example.mail.eo.outlook.com. > I can get the MX record, however, I could not get the A record of the > MX record, got Timeout. > > Does anyone have the same issue? > > Sincerely, > Yuji > > From m.hallgren at free.fr Wed May 1 20:57:00 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 01 May 2013 22:57:00 +0200 Subject: Tier1 blackholing policy? In-Reply-To: <51810EB0.3030402@tiggee.com> References: <517FD5DD.9020305@dfn.de> <517FDC4C.9060104@kenweb.org> <1367334447.31455.5.camel@hounddog> <517FE206.5070306@dfn.de> <517FEA88.5030605@bogus.com> <5180E311.4040209@dfn.de> <51810EB0.3030402@tiggee.com> Message-ID: <5181819C.7050706@free.fr> Le 01/05/2013 14:46, David Miller a ?crit : > On 05/01/2013 05:40 AM, Thomas Schmid wrote: >> Joel, >> >> Am 30.04.2013 18:00, schrieb joel jaeggli: >>> On 4/30/13 8:23 AM, Thomas Schmid wrote: >>>> On 30.04.2013 17:07, Chris Boyd wrote: >>>>> On Tue, 2013-04-30 at 10:59 -0400, ML wrote: >>>>>> 1) Do nothing - They're supposed deliver any and all bits >>>>>> (Disregarding >>>>>> a DoS or similiar situation which impedes said network) >>>>>> 2) Prefix filter - Don't be a party (at least in one direction) to >>>>>> the >>>>>> bad actors traffic. >>>>> 3 - Deliver all packets unless I've signed up for an enhanced security >>>>> offering? >>>>> >>>> right - I see this really as something that should be decided at the >>>> edge >>>> of the internet (Tier2+) and not in the core. >>> You seem to have odd ideas about what it means to be a settlement >>> free provider. Most of their customers are not smaller internet >>> service providers. >> I know what it means to be a customer of >> $LargeGlobalISPthatsellsTransittootherISPs since >> 1995 and I have *never* seen one of these guys blackholing >> single IPs on their own (and I'm not talking about RTB, botnet >> controllers that threaten to kill >> the internet etc.). Now since a few weeks we get regular complaints >> about this. So something has changed. >> >> The sensitive approach would really be to make this an opt-in service >> for their customers >> and not a default service without opt-out option. In times of CGN and >> hundrets or thousands of >> websites behind one IP, blocking addresses is not the right answer to >> the phishing problem. >> > ... or perhaps on an internet where many network owners block / police / > throttle packets by source or destination, implementing CGN or stacking > thousands of websites behind one IP address are poor solutions to the > connectivity problem. > > My only issue is the lack of information provided when blocks go into > place. I would love to see networks provide information publicly that > shows what is being blocked along with a description of why. A history > that extends for a few days would be a bonus. I agree with that. While some blocking and policing may be judged "good thing" there is a well-known potential for "other kinds" of policing... Cheers, mh > > -DMM > > From westribble at gmail.com Wed May 1 21:03:00 2013 From: westribble at gmail.com (Wes Tribble) Date: Wed, 1 May 2013 16:03:00 -0500 Subject: Per Site QOS policy with Cisco IOS-XE Message-ID: I have a question for the QOS gurus out there. We are having some problems with packet loss for our smaller MPLS locations. This packet loss is due to the large speed differential on our Hub site(150mb/s) in comparison the the branch office locations(single T-1 to 4.5mb/s multilinks). This packet loss only seems to impact really bursty applications like our Web Proxy. I have been around and around with WindStream to give me some extra buffer or enable random early detection on the smaller interfaces in my MPLS network. So far they are unwilling to do a custom policy and none of their standard policies have enough buffer to handle the bursts. They do FIFO tail drop in every queue, so I can?t even choose a policy that has WRED implemented. I am looking for a way to solve the problem on my side. I can create a shaper for the proxy and match off an access-list to the smaller sites, but I am either forced to do bandwidth reservations for each site, or have multiple sites share the same shaper. Here is an example of what I was playing around with: ip access-list extended ProxyT1Sites permit tcp any host 10.x.x.x 10.x.x.x 0.0.0.255 permit tcp any host 10.x.x.x 10.x.x.x 0.0.0.255 class-map match-any ProxyShaperT1 match access-group name ProxyT1Sites policy-map WindStream class VOICE priority percent 25 set dscp ef class AF41 bandwidth percent 40 set dscp af41 queue-limit 1024 packets class ProxyShaperT1 shape average 1536 bandwidth percent 1 set dscp af21 queue-limit 1024 packets class class-default fair-queue set dscp af21 queue-limit 1024 packets Another Idea I had was to create a bunch of shaper classes all feeding the same child policy for priority queuing and bandwidth reservations based on DSCP markings. I?m just not exactly sure that this is allowed or supported. I also would run out of bandwidth allocation on the policy if I use the true bandwidth number of 150mb/s. It is on a Gig port so I could just take the bandwidth statement off of the interface to give myself enough room for all of the shaper allocations. Something like this(I am omitting the access-list that matches the branch subnet and class map for brevity): policy-map PerSiteShaper class FtSmith shape average 1536 bandwidth 1536 service policy Scheduler class Dallas shape average 4500 bandwidth 4500 service policy Scheduler class NYC shape average 100000 bandwidth 100000 service policy Scheduler class-default service-policy Scheduler policy-map Scheduler class VOICE priority percent 25 set dscp ef class AF41 bandwidth percent 40 set dscp af41 queue-limit 1024 packets class class-default fair-queue set dscp af21 queue-limit 1024 packets Just looking for some ideas that do not involve building tunnels to our remote offices. Thanks in advance, *Wes Tribble* From morrowc.lists at gmail.com Wed May 1 21:03:36 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 1 May 2013 17:03:36 -0400 Subject: Google Public DNS Problems? In-Reply-To: References: <51814E1E.4070503@gmail.com> Message-ID: On Wed, May 1, 2013 at 4:14 PM, Yang Yu wrote: > It is very courteous to reply a SERVFAIL for requests being rate limited. > > I believe the 'rate-limit' response is actually 'no response' ... though I haven't tested this myself :) > On Wed, May 1, 2013 at 1:17 PM, Andrew Fried > wrote: > > Your IPs may have been rate limited... > > > > Andy > > > > Andrew Fried > > andrew.fried at gmail.com > > > > On 5/1/13 12:38 PM, Blair Trosper wrote: > >> That's all well and good, but I certainly wouldn't expect "nslookup > >> gmail.com" or for "nslookup google.com" to return SERVFAIL > >> > >> > >> On Wed, May 1, 2013 at 9:34 AM, Joe Abley wrote: > >> > >>> > >>> On 2013-05-01, at 12:09, Blair Trosper > wrote: > >>> > >>>> Is anyone else seeing this? From Santa Clara, CA, on Comcast > >>>> Business...I'm getting SERVFAIL for any query I throw at 8.8.8.8 and > >>>> 8.8.4.4... > >>>> > >>>> Level 3's own public resolvers are fine for me, as are OpenDNS's > >>> resolvers. > >>> > >>> Google just turned on validation across the whole of 8.8.8.8 and > 8.8.4.4. > >>> The expected behaviour in the case where a response does not validate > is to > >>> return SERVFAIL to the client. > >>> > >>> You could check that the queries you are sending are not suffering from > >>> poor signing hygiene (e.g. use the handy-dandy dnsviz.netvisualisation). > >>> > >>> If this is a repeatable, consistent problem even for unsigned zones (or > >>> for zones that you've verified are signed correctly) and especially if > it's > >>> widespread you might want to call google on the nanog courtesy phone > and > >>> have them look for collateral damage from their recent foray into > 8.8.8.8 > >>> validation. > >>> > >>> Raw output from dig/drill and traceroutes to 8.8.8.8/8.8.4.4 are > highly > >>> recommended if you need to take this further. > >>> > >>> > >>> Joe > > > > From jra at baylink.com Wed May 1 21:48:54 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 1 May 2013 17:48:54 -0400 (EDT) Subject: Could not send email to office 365 In-Reply-To: <09e301ce4690$0259fd50$070df7f0$@swalter.com> Message-ID: <22026630.4782.1367444934539.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Tony Patti" > After our "upgrade", we started to see the body of received PLAIN TEXT > emails truncated at less than 256 bytes, > which frequently truncated emails in the middle of a word, the fix was > a "setting change". > > Since being standardized in 1982 with RFC 822, you would think PLAIN > TEXT emails would just work "out of the box". This is Microsoft, Tony. They don't understand text, and would prefer that all emails be a MIME attachment of a Word document. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From otis at ocosa.com Wed May 1 23:30:01 2013 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Wed, 1 May 2013 18:30:01 -0500 Subject: Data Center Installations In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B018626@ocsbs.ocosa.com> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B018629@ocsbs.ocosa.com> -----Original Message----- From: Blake Pfankuch - Mailing List [mailto:blake.mailinglist at pfankuch.me] Sent: Wednesday, May 01, 2013 6:18 PM To: Otis L. Surratt, Jr.; Warren Bailey; nanog at nanog.org Subject: RE: Data Center Installations >Along this same line of questioning... favorite Velcro? I used to get spools of about 500 8 inch strips for a reasonable amount however the vendor went out of business. The cloth tabs are nice, but then end >up getting in the way... > >Thanks, >Blake You should be able to get a roll from Graybar. Never checked with CSC for that. We bought a large roll from Graybar and simply cut what we need. It's not precut and pretty but it works. From mike.lyon at gmail.com Wed May 1 23:33:19 2013 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 1 May 2013 16:33:19 -0700 Subject: Data Center Installations In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B018629@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018626@ocsbs.ocosa.com> <5FE1FB6D43B8A647BBC821840C1AEA8B018629@ocsbs.ocosa.com> Message-ID: For bulk velcro, I found Uline to be fairly cheap. On Wed, May 1, 2013 at 4:30 PM, Otis L. Surratt, Jr. wrote: > -----Original Message----- > From: Blake Pfankuch - Mailing List > [mailto:blake.mailinglist at pfankuch.me] > Sent: Wednesday, May 01, 2013 6:18 PM > To: Otis L. Surratt, Jr.; Warren Bailey; nanog at nanog.org > Subject: RE: Data Center Installations > > >Along this same line of questioning... favorite Velcro? I used to get > spools of about 500 8 inch strips for a reasonable amount however the > vendor went out of business. The cloth tabs are nice, but then end >up > getting in the way... > > > >Thanks, > >Blake > > You should be able to get a roll from Graybar. Never checked with CSC > for that. We bought a large roll from Graybar and simply cut what we > need. It's not precut and pretty but it works. > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From mloftis at wgops.com Wed May 1 23:49:54 2013 From: mloftis at wgops.com (Michael Loftis) Date: Wed, 1 May 2013 16:49:54 -0700 Subject: Data Center Installations In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B018626@ocsbs.ocosa.com> <5FE1FB6D43B8A647BBC821840C1AEA8B018629@ocsbs.ocosa.com> Message-ID: On Wed, May 1, 2013 at 4:33 PM, Mike Lyon wrote: > For bulk velcro, I found Uline to be fairly cheap. I have to ask, is this an April fools joke? ULine isn't cheap for anything. Monoprice, $13, around $25 delivered depending on where you're at and how yu ship it, for 5x black hook and loop 5yd per roll... vs. ULine $28 (1x black hook and loop 75') and probably about same S&H. No easy way to get them to quote S&H but last time I ordered from them (they're about the only place to get some stuff) ULine is over 2x as much. Oh and Monoprice has it in quite a few colors if you don't care for black. If you're going for pre-made cable wrap type stuff it's a bit more, but still half or less than ULine. ULine is definitely a supplier of last resort, but they've got a lot of different stuff. From mike.lyon at gmail.com Wed May 1 23:55:37 2013 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 1 May 2013 16:55:37 -0700 Subject: Data Center Installations In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B018626@ocsbs.ocosa.com> <5FE1FB6D43B8A647BBC821840C1AEA8B018629@ocsbs.ocosa.com> Message-ID: Is hard to beat Monoprice :) But no, I have purchased velcro in bulk from ULine (not the kind for wrapping cable though) and found it to be cheaper and I usually got it the next day for not that much shipping. -Mike On Wed, May 1, 2013 at 4:49 PM, Michael Loftis wrote: > On Wed, May 1, 2013 at 4:33 PM, Mike Lyon wrote: > > For bulk velcro, I found Uline to be fairly cheap. > > I have to ask, is this an April fools joke? ULine isn't cheap for > anything. Monoprice, $13, around $25 delivered depending on where > you're at and how yu ship it, for 5x black hook and loop 5yd per > roll... vs. ULine $28 (1x black hook and loop 75') and probably about > same S&H. No easy way to get them to quote S&H but last time I > ordered from them (they're about the only place to get some stuff) > ULine is over 2x as much. Oh and Monoprice has it in quite a few > colors if you don't care for black. If you're going for pre-made > cable wrap type stuff it's a bit more, but still half or less than > ULine. > > ULine is definitely a supplier of last resort, but they've got a lot > of different stuff. > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From MGauvin at dryden.ca Wed May 1 23:57:54 2013 From: MGauvin at dryden.ca (Mark Gauvin) Date: Wed, 1 May 2013 18:57:54 -0500 Subject: Data Center Installations In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B018626@ocsbs.ocosa.com> <5FE1FB6D43B8A647BBC821840C1AEA8B018629@ocsbs.ocosa.com> Message-ID: Zip ties have no reason to be in a dc grr Sent from my iPhone On 2013-05-01, at 6:57 PM, "Mike Lyon" wrote: > Is hard to beat Monoprice :) > > But no, I have purchased velcro in bulk from ULine (not the kind for > wrapping cable though) and found it to be cheaper and I usually got it the > next day for not that much shipping. > > -Mike > > > > On Wed, May 1, 2013 at 4:49 PM, Michael Loftis wrote: > >> On Wed, May 1, 2013 at 4:33 PM, Mike Lyon wrote: >>> For bulk velcro, I found Uline to be fairly cheap. >> >> I have to ask, is this an April fools joke? ULine isn't cheap for >> anything. Monoprice, $13, around $25 delivered depending on where >> you're at and how yu ship it, for 5x black hook and loop 5yd per >> roll... vs. ULine $28 (1x black hook and loop 75') and probably about >> same S&H. No easy way to get them to quote S&H but last time I >> ordered from them (they're about the only place to get some stuff) >> ULine is over 2x as much. Oh and Monoprice has it in quite a few >> colors if you don't care for black. If you're going for pre-made >> cable wrap type stuff it's a bit more, but still half or less than >> ULine. >> >> ULine is definitely a supplier of last resort, but they've got a lot >> of different stuff. >> >> > > > -- > Mike Lyon > 408-621-4826 > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon From wbailey at satelliteintelligencegroup.com Thu May 2 00:04:06 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 2 May 2013 00:04:06 +0000 Subject: Data Center Installations In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B018626@ocsbs.ocosa.com> <5FE1FB6D43B8A647BBC821840C1AEA8B018629@ocsbs.ocosa.com> , Message-ID: Bring your lacing skills? Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Mark Gauvin Date: 05/01/2013 5:01 PM (GMT-08:00) To: Mike Lyon Cc: NANOG Subject: Re: Data Center Installations Zip ties have no reason to be in a dc grr Sent from my iPhone On 2013-05-01, at 6:57 PM, "Mike Lyon" wrote: > Is hard to beat Monoprice :) > > But no, I have purchased velcro in bulk from ULine (not the kind for > wrapping cable though) and found it to be cheaper and I usually got it the > next day for not that much shipping. > > -Mike > > > > On Wed, May 1, 2013 at 4:49 PM, Michael Loftis wrote: > >> On Wed, May 1, 2013 at 4:33 PM, Mike Lyon wrote: >>> For bulk velcro, I found Uline to be fairly cheap. >> >> I have to ask, is this an April fools joke? ULine isn't cheap for >> anything. Monoprice, $13, around $25 delivered depending on where >> you're at and how yu ship it, for 5x black hook and loop 5yd per >> roll... vs. ULine $28 (1x black hook and loop 75') and probably about >> same S&H. No easy way to get them to quote S&H but last time I >> ordered from them (they're about the only place to get some stuff) >> ULine is over 2x as much. Oh and Monoprice has it in quite a few >> colors if you don't care for black. If you're going for pre-made >> cable wrap type stuff it's a bit more, but still half or less than >> ULine. >> >> ULine is definitely a supplier of last resort, but they've got a lot >> of different stuff. >> >> > > > -- > Mike Lyon > 408-621-4826 > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon From jeff-kell at utc.edu Thu May 2 00:06:14 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 1 May 2013 20:06:14 -0400 Subject: Data Center Installations In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B018626@ocsbs.ocosa.com> <5FE1FB6D43B8A647BBC821840C1AEA8B018629@ocsbs.ocosa.com> Message-ID: <5181ADF6.7000400@utc.edu> On 5/1/2013 7:57 PM, Mark Gauvin wrote: > Zip ties have no reason to be in a dc grr They have their place, but decidedly not in data center racks where **nothing** is permanent/fixed very long :) Jeff From kmedcalf at dessus.com Thu May 2 00:56:51 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 01 May 2013 18:56:51 -0600 Subject: Could not send email to office 365 In-Reply-To: Message-ID: <765a8affa03935428fedc82170bc5219@mail.dessus.com> http://email-guru.com/ ? --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org > -----Original Message----- > From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] > Sent: Wednesday, 01 May, 2013 10:12 > To: JoeSox; nanog at nanog.org > Subject: Re: Could not send email to office 365 > > Just another day for them.. Office 365 has been broken for us for a long > time. I've been thinking about a rackspace hosted exchange instead.. Have > you guys looked into alternatives? > > > Sent from my T-Mobile 4G LTE Device > > > > -------- Original message -------- > From: JoeSox > Date: 05/01/2013 6:27 AM (GMT-08:00) > To: nanog at nanog.org > Subject: Re: Could not send email to office 365 > > > The company I work for has been having Outlook connectivity issues > (intermittent for only a few end users) for the past 7 days for Office > 365. > We are in an upgrade status (on the 18th days or so; have been told it can > last 30 days) and they changed our MX records without formal notification. > We updated those on a Thursday or Friday and it worked until the following > Monday where we observed it again, then magically fixed itself late > afternoon that Monday. We had some more reports yesterday. The Microsoft > technical support has not been helpful troubleshooting this for us. > I am hoping it is related to our upgrade status but I cannot get an answer > from anyone. > -- > Thanks, Joe > > > On Wed, May 1, 2013 at 2:21 AM, ISHII, Yuji wrote: > > > Hello folks, > > > > Have you ever seen DNS issues on Office 365? > > > > MX record of Office 365 is example.mail.eo.outlook.com. > > I can get the MX record, however, I could not get the A record of the MX > > record, got Timeout. > > > > Does anyone have the same issue? > > > > Sincerely, > > Yuji > > > > From rs at seastrom.com Thu May 2 01:03:38 2013 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 01 May 2013 21:03:38 -0400 Subject: Data Center Installations In-Reply-To: (Warren Bailey's message of "Wed, 1 May 2013 19:23:45 +0000") References: Message-ID: <86a9oejiqd.fsf@valhalla.seastrom.com> Warren Bailey writes: > Do any of you have a "go to" resource for materials used in > installations? Tie wraps, cable management, blahblahblah? For stuff that they carry, Deep Surplus has been acceptable quality and the price is generally right. Others have recommended monoprice but I've found them a bit variable on quality. http://deepsurplus.com -r From ler762 at gmail.com Thu May 2 01:36:36 2013 From: ler762 at gmail.com (Lee) Date: Wed, 1 May 2013 21:36:36 -0400 Subject: Per Site QOS policy with Cisco IOS-XE In-Reply-To: References: Message-ID: On 5/1/13, Wes Tribble wrote: > I have a question for the QOS gurus out there. cisco-nsp might be a better place to post your question. But in any case, this option looks right: > Another Idea I had was to create a bunch of shaper classes all feeding the > same child policy for priority queuing and bandwidth reservations based on > DSCP markings. I?m just not exactly sure that this is allowed or > supported. see http://puck.nether.net/pipermail/cisco-nsp/2007-October/044508.html So they just shaped at the hub towards the spoke to prevent overrunning the PE-CE link at the spoke. Another advantage was they didnt' waste hub-PE bandwidth for traffic that would be dropped at the spoke PE-CE link anyway. which has nothing to do with IOS-XE but does sound like what you're wanting to do. Regards, Lee > > We are having some problems with packet loss for our > smaller MPLS locations. This packet loss is due to the large speed > differential on our Hub site(150mb/s) in comparison the the branch office > locations(single T-1 to 4.5mb/s multilinks). This packet loss only seems > to impact really bursty applications like our Web Proxy. I have been > around and around with WindStream to give me some extra buffer or enable > random early detection on the smaller interfaces in my MPLS network. So > far they are unwilling to do a custom policy and none of their standard > policies have enough buffer to handle the bursts. They do FIFO tail drop > in every queue, so I can?t even choose a policy that has WRED implemented. > > > > I am looking for a way to solve the problem on my side. I > can create a shaper for the proxy and match off an access-list to the > smaller sites, but I am either forced to do bandwidth reservations for each > site, or have multiple sites share the same shaper. Here is an example of > what I was playing around with: > > > > ip access-list extended ProxyT1Sites > > permit tcp any host 10.x.x.x 10.x.x.x 0.0.0.255 > > permit tcp any host 10.x.x.x 10.x.x.x 0.0.0.255 > > > > class-map match-any ProxyShaperT1 > > match access-group name ProxyT1Sites > > > > policy-map WindStream > > class VOICE > > priority percent 25 > > set dscp ef > > class AF41 > > bandwidth percent 40 > > set dscp af41 > > queue-limit 1024 packets > > class ProxyShaperT1 > > shape average 1536 > > bandwidth percent 1 > > set dscp af21 > > queue-limit 1024 packets > > class class-default > > fair-queue > > set dscp af21 > > queue-limit 1024 packets > > > > > > Another Idea I had was to create a bunch of shaper classes all feeding the > same child policy for priority queuing and bandwidth reservations based on > DSCP markings. I?m just not exactly sure that this is allowed or > supported. I also would run out of bandwidth allocation on the policy if I > use the true bandwidth number of 150mb/s. It is on a Gig port so I could > just take the bandwidth statement off of the interface to give myself > enough room for all of the shaper allocations. > > > > Something like this(I am omitting the access-list that matches the branch > subnet and class map for brevity): > > > > policy-map PerSiteShaper > > class FtSmith > > shape average 1536 > > bandwidth 1536 > service policy Scheduler > class Dallas > > shape average 4500 > > bandwidth 4500 > service policy Scheduler > class NYC > > shape average 100000 > > bandwidth 100000 > service policy Scheduler > class-default > service-policy Scheduler > > policy-map Scheduler > class VOICE > > priority percent 25 > > set dscp ef > > class AF41 > > bandwidth percent 40 > > set dscp af41 > > queue-limit 1024 packets > > class class-default > > fair-queue > > set dscp af21 > > queue-limit 1024 packets > > > > > > > Just looking for some ideas that do not involve building tunnels to our > remote offices. Thanks in advance, > > > > *Wes Tribble* > From ikiris at gmail.com Thu May 2 03:28:25 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 1 May 2013 22:28:25 -0500 Subject: Data Center Installations In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B018626@ocsbs.ocosa.com> <5FE1FB6D43B8A647BBC821840C1AEA8B018629@ocsbs.ocosa.com> Message-ID: On Wed, May 1, 2013 at 7:04 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Bring your lacing skills Flex cross twist knot flex cross twist flex cross twist knot flex cross twist... -Blake From ag4ve.us at gmail.com Thu May 2 04:43:33 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 2 May 2013 00:43:33 -0400 Subject: Google Public DNS Problems? In-Reply-To: References: <51814E1E.4070503@gmail.com> Message-ID: On May 1, 2013 5:09 PM, "Christopher Morrow" wrote: > > On Wed, May 1, 2013 at 4:14 PM, Yang Yu wrote: > > > It is very courteous to reply a SERVFAIL for requests being rate limited. > > > > > I believe the 'rate-limit' response is actually 'no response' ... though I > haven't tested this myself :) > > Yes if someone has a misbehaving program or is trying to DOS you, you don't really want to reply with anything. > > On Wed, May 1, 2013 at 1:17 PM, Andrew Fried > > wrote: > > > Your IPs may have been rate limited... > > > > > > Andy > > > > > > Andrew Fried > > > andrew.fried at gmail.com > > > > > > On 5/1/13 12:38 PM, Blair Trosper wrote: > > >> That's all well and good, but I certainly wouldn't expect "nslookup > > >> gmail.com" or for "nslookup google.com" to return SERVFAIL > > >> > > >> > > >> On Wed, May 1, 2013 at 9:34 AM, Joe Abley wrote: > > >> > > >>> > > >>> On 2013-05-01, at 12:09, Blair Trosper > > wrote: > > >>> > > >>>> Is anyone else seeing this? From Santa Clara, CA, on Comcast > > >>>> Business...I'm getting SERVFAIL for any query I throw at 8.8.8.8 and > > >>>> 8.8.4.4... > > >>>> > > >>>> Level 3's own public resolvers are fine for me, as are OpenDNS's > > >>> resolvers. > > >>> > > >>> Google just turned on validation across the whole of 8.8.8.8 and > > 8.8.4.4. > > >>> The expected behaviour in the case where a response does not validate > > is to > > >>> return SERVFAIL to the client. > > >>> > > >>> You could check that the queries you are sending are not suffering from > > >>> poor signing hygiene (e.g. use the handy-dandy dnsviz.netvisualisation). > > >>> > > >>> If this is a repeatable, consistent problem even for unsigned zones (or > > >>> for zones that you've verified are signed correctly) and especially if > > it's > > >>> widespread you might want to call google on the nanog courtesy phone > > and > > >>> have them look for collateral damage from their recent foray into > > 8.8.8.8 > > >>> validation. > > >>> > > >>> Raw output from dig/drill and traceroutes to 8.8.8.8/8.8.4.4 are > > highly > > >>> recommended if you need to take this further. > > >>> > > >>> > > >>> Joe > > > > > > > From ryan at finnesey.com Thu May 2 04:51:14 2013 From: ryan at finnesey.com (Ryan Finnesey) Date: Thu, 2 May 2013 04:51:14 +0000 Subject: Could not send email to office 365 In-Reply-To: References: <20130501182123.2455.AEA43824@ugec.net>, Message-ID: Yes we are just working out our licensing agreement and moving Exchange back in house. From talking with people BPOS (Exchange 2007) was a mess. We were on Office 365 with Exchange 2010 without issue service worked very well. Then they upgraded us to Exchange 2013 and it is just broken we are unable to connect. I thought the problem is fixed but now it is back. -----Original Message----- From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] Sent: Wednesday, May 1, 2013 12:12 PM To: JoeSox; nanog at nanog.org Subject: Re: Could not send email to office 365 Just another day for them.. Office 365 has been broken for us for a long time. I've been thinking about a rackspace hosted exchange instead.. Have you guys looked into alternatives? Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: JoeSox Date: 05/01/2013 6:27 AM (GMT-08:00) To: nanog at nanog.org Subject: Re: Could not send email to office 365 The company I work for has been having Outlook connectivity issues (intermittent for only a few end users) for the past 7 days for Office 365. We are in an upgrade status (on the 18th days or so; have been told it can last 30 days) and they changed our MX records without formal notification. We updated those on a Thursday or Friday and it worked until the following Monday where we observed it again, then magically fixed itself late afternoon that Monday. We had some more reports yesterday. The Microsoft technical support has not been helpful troubleshooting this for us. I am hoping it is related to our upgrade status but I cannot get an answer from anyone. -- Thanks, Joe On Wed, May 1, 2013 at 2:21 AM, ISHII, Yuji wrote: > Hello folks, > > Have you ever seen DNS issues on Office 365? > > MX record of Office 365 is example.mail.eo.outlook.com. > I can get the MX record, however, I could not get the A record of the > MX record, got Timeout. > > Does anyone have the same issue? > > Sincerely, > Yuji > > From ryan at finnesey.com Thu May 2 04:51:17 2013 From: ryan at finnesey.com (Ryan Finnesey) Date: Thu, 2 May 2013 04:51:17 +0000 Subject: Data Center Installations In-Reply-To: References: Message-ID: <97cd9e3bdef74966b69501d5ac127aa5@BY2PR05MB079.namprd05.prod.outlook.com> Wish there was Frys in the east -----Original Message----- From: George Herbert [mailto:george.herbert at gmail.com] Sent: Wednesday, May 1, 2013 3:42 PM To: Joe Hamelin Cc: nanog at nanog.org Subject: Re: Data Center Installations Seconded Graybar. If necessary, in the absence of Graybar or for tiny stuff, a Frys or Home Depot or Lowes. On Wed, May 1, 2013 at 12:32 PM, Joe Hamelin wrote: > Graybar. > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > > On Wed, May 1, 2013 at 12:23 PM, Warren Bailey < > wbailey at satelliteintelligencegroup.com> wrote: > > > Do any of you have a "go to" resource for materials used in > installations? > > Tie wraps, cable management, blahblahblah? > > > > I have found several places, but I'm curious to know what the nanog > > ninja's have to say. > > > > //warren > > > > > -- -george william herbert george.herbert at gmail.com From ryan at finnesey.com Thu May 2 04:51:15 2013 From: ryan at finnesey.com (Ryan Finnesey) Date: Thu, 2 May 2013 04:51:15 +0000 Subject: Could not send email to office 365 In-Reply-To: References: <20130501182123.2455.AEA43824@ugec.net> <536732d21d6a4d21b8183a8816320153@BY2PR05MB079.namprd05.prod.outlook.com> Message-ID: <14ad09e4b1334dcd8d06f9ac6ce37098@BY2PR05MB079.namprd05.prod.outlook.com> It was in upgrade status for about 15 days. We had to open a separate ticket to fix the "upgrade" but even after they completed the upgrade I was unable to connect. -----Original Message----- From: JoeSox [mailto:joesox at gmail.com] Sent: Wednesday, May 1, 2013 12:28 PM To: nanog at nanog.org Subject: Re: Could not send email to office 365 Ryan, Is your Office 365 account also in an upgrade status? If not, have you completed the upgrade? -- Thanks, Joe On Wed, May 1, 2013 at 8:42 AM, Ryan Finnesey wrote: > I am also having the some issues going on 3 weeks now. I cannot > access my e-mail via Outlook and my MX records keep changing. It is > nuts support has been unable to help. > ________________________________________ > > > From ryan at finnesey.com Thu May 2 04:51:16 2013 From: ryan at finnesey.com (Ryan Finnesey) Date: Thu, 2 May 2013 04:51:16 +0000 Subject: Data Center Installations In-Reply-To: References: Message-ID: Graybar is great -----Original Message----- From: Joe Hamelin [mailto:joe at nethead.com] Sent: Wednesday, May 1, 2013 3:32 PM To: Warren Bailey Cc: nanog at nanog.org Subject: Re: Data Center Installations Graybar. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Wed, May 1, 2013 at 12:23 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Do any of you have a "go to" resource for materials used in installations? > Tie wraps, cable management, blahblahblah? > > I have found several places, but I'm curious to know what the nanog > ninja's have to say. > > //warren > > From ag4ve.us at gmail.com Thu May 2 05:05:43 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 2 May 2013 01:05:43 -0400 Subject: Data Center Installations In-Reply-To: <97cd9e3bdef74966b69501d5ac127aa5@BY2PR05MB079.namprd05.prod.outlook.com> References: <97cd9e3bdef74966b69501d5ac127aa5@BY2PR05MB079.namprd05.prod.outlook.com> Message-ID: I'm more impressed with MicroCenter than Frys (at least the Frys south if SF). If you need RF I used to order from Davis RF all the time. On May 2, 2013 12:57 AM, "Ryan Finnesey" wrote: > Wish there was Frys in the east > > -----Original Message----- > From: George Herbert [mailto:george.herbert at gmail.com] > Sent: Wednesday, May 1, 2013 3:42 PM > To: Joe Hamelin > Cc: nanog at nanog.org > Subject: Re: Data Center Installations > > Seconded Graybar. If necessary, in the absence of Graybar or for tiny > stuff, a Frys or Home Depot or Lowes. > > > On Wed, May 1, 2013 at 12:32 PM, Joe Hamelin wrote: > > > Graybar. > > > > -- > > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > > > > > On Wed, May 1, 2013 at 12:23 PM, Warren Bailey < > > wbailey at satelliteintelligencegroup.com> wrote: > > > > > Do any of you have a "go to" resource for materials used in > > installations? > > > Tie wraps, cable management, blahblahblah? > > > > > > I have found several places, but I'm curious to know what the nanog > > > ninja's have to say. > > > > > > //warren > > > > > > > > > > > > -- > -george william herbert > george.herbert at gmail.com > > From ryan at finnesey.com Thu May 2 05:13:23 2013 From: ryan at finnesey.com (Ryan Finnesey) Date: Thu, 2 May 2013 05:13:23 +0000 Subject: Data Center Installations In-Reply-To: References: <97cd9e3bdef74966b69501d5ac127aa5@BY2PR05MB079.namprd05.prod.outlook.com>, Message-ID: <08D1CB9A-A525-49A0-AB00-F6BD74F2D1CB@finnesey.com> Never been to MicroCenter Sent from my iPad mini On May 2, 2013, at 1:05 AM, "shawn wilson" > wrote: I'm more impressed with MicroCenter than Frys (at least the Frys south if SF). If you need RF I used to order from Davis RF all the time. On May 2, 2013 12:57 AM, "Ryan Finnesey" > wrote: Wish there was Frys in the east -----Original Message----- From: George Herbert [mailto:george.herbert at gmail.com] Sent: Wednesday, May 1, 2013 3:42 PM To: Joe Hamelin Cc: nanog at nanog.org Subject: Re: Data Center Installations Seconded Graybar. If necessary, in the absence of Graybar or for tiny stuff, a Frys or Home Depot or Lowes. On Wed, May 1, 2013 at 12:32 PM, Joe Hamelin > wrote: > Graybar. > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > > On Wed, May 1, 2013 at 12:23 PM, Warren Bailey < > wbailey at satelliteintelligencegroup.com> wrote: > > > Do any of you have a "go to" resource for materials used in > installations? > > Tie wraps, cable management, blahblahblah? > > > > I have found several places, but I'm curious to know what the nanog > > ninja's have to say. > > > > //warren > > > > > -- -george william herbert george.herbert at gmail.com From wbailey at satelliteintelligencegroup.com Thu May 2 06:31:21 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 2 May 2013 06:31:21 +0000 Subject: Data Center Installations In-Reply-To: <08D1CB9A-A525-49A0-AB00-F6BD74F2D1CB@finnesey.com> References: <97cd9e3bdef74966b69501d5ac127aa5@BY2PR05MB079.namprd05.prod.outlook.com>, , <08D1CB9A-A525-49A0-AB00-F6BD74F2D1CB@finnesey.com> Message-ID: Microcenter does have some rad install gear. They have quite a few tools if I remember too.. I thought maybe there was a secret place to get cool data center layer 1 stuff.. Monoprice delivers same day here if I recall (socal). Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Ryan Finnesey Date: 05/01/2013 10:18 PM (GMT-08:00) To: shawn wilson Cc: North American Network Operators Group Subject: Re: Data Center Installations Never been to MicroCenter Sent from my iPad mini On May 2, 2013, at 1:05 AM, "shawn wilson" > wrote: I'm more impressed with MicroCenter than Frys (at least the Frys south if SF). If you need RF I used to order from Davis RF all the time. On May 2, 2013 12:57 AM, "Ryan Finnesey" > wrote: Wish there was Frys in the east -----Original Message----- From: George Herbert [mailto:george.herbert at gmail.com] Sent: Wednesday, May 1, 2013 3:42 PM To: Joe Hamelin Cc: nanog at nanog.org Subject: Re: Data Center Installations Seconded Graybar. If necessary, in the absence of Graybar or for tiny stuff, a Frys or Home Depot or Lowes. On Wed, May 1, 2013 at 12:32 PM, Joe Hamelin > wrote: > Graybar. > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > > On Wed, May 1, 2013 at 12:23 PM, Warren Bailey < > wbailey at satelliteintelligencegroup.com> wrote: > > > Do any of you have a "go to" resource for materials used in > installations? > > Tie wraps, cable management, blahblahblah? > > > > I have found several places, but I'm curious to know what the nanog > > ninja's have to say. > > > > //warren > > > > > -- -george william herbert george.herbert at gmail.com From cathya at isc.org Thu May 2 06:42:06 2013 From: cathya at isc.org (Cathy Almond) Date: Thu, 02 May 2013 07:42:06 +0100 Subject: Could not send email to office 365 In-Reply-To: <20130501182123.2455.AEA43824@ugec.net> References: <20130501182123.2455.AEA43824@ugec.net> Message-ID: <51820ABE.4070000@isc.org> On 01/05/13 10:21, ISHII, Yuji wrote: > Hello folks, > > Have you ever seen DNS issues on Office 365? > > MX record of Office 365 is example.mail.eo.outlook.com. > I can get the MX record, however, I could not get the A record of the MX > record, got Timeout. > > Does anyone have the same issue? > > Sincerely, > Yuji > This may be a red herring, but I've heard of some dropping of DNS queries for the names within outlook.com domains where the queries are all coming from source port 53 (i.e. your recursive server doesn't use query source port randomization). Might be worth checking what the recursive server you're using is doing? See https://www.dns-oarc.net/oarc/services/porttest Cathy From jgreco at ns.sol.net Thu May 2 10:56:03 2013 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 2 May 2013 05:56:03 -0500 (CDT) Subject: Data Center Installations In-Reply-To: <97cd9e3bdef74966b69501d5ac127aa5@BY2PR05MB079.namprd05.prod.outlook.com> Message-ID: <201305021056.r42Au3AK058680@aurora.sol.net> > Wish there was Frys in the east=20 Micro Center is kind of like a less-insane Frys. Always seem to be somewhat inconveniently located though. ... 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 jgreco at ns.sol.net Thu May 2 11:21:26 2013 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 2 May 2013 06:21:26 -0500 (CDT) Subject: Data Center Installations In-Reply-To: Message-ID: <201305021121.r42BLSn8059074@aurora.sol.net> > I thought maybe there was a secret place to get cool data center layer 1 st= > uff.. Yeah, it's called "inventory" ... ;-) Seriously, there's a reason why it is common to maintain shelving in the data center, and/or storage lockers nearby. The stuff you use and find usable isn't the same stuff that I use and find usable, and while I don't know about you, I'm too cheap to pay top dollar for JIT style acquisition of the stuff I need, even assuming that there was someplace local that sold it. Easier to have it on-site. As for acquiring the stuff in the first place? Yeah, no good single source. We have a drawerful of current catalogs for various vendors, such as: ADI - low voltage distributors, often good pricing on bulk cable and UPS batteries C&H Distributors - General industrial equipment, workbenches, shelving, storage bins, etc. CablesToGo - KVM cables, PC and network cabling, power cords, etc DigiKey - Mostly electronics parts and connectors PI Manufacturing - All sorts of various inexpensive bits and pieces for networks and PC's, cables, adapters, etc. StayOnline - More obscure stuff for the data center, such as C13-to-C14 power Y's to mention some of the less-obvious ones, But these days there's a huge amount of purchasing that goes on entirely through online catalogs etc. ... 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 jabley at hopcount.ca Thu May 2 11:53:15 2013 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 2 May 2013 07:53:15 -0400 Subject: Could not send email to office 365 In-Reply-To: <51820ABE.4070000@isc.org> References: <20130501182123.2455.AEA43824@ugec.net> <51820ABE.4070000@isc.org> Message-ID: <2AEB6E00-1ECA-460F-A656-98085B5F053D@hopcount.ca> On 2013-05-02, at 02:42, Cathy Almond wrote: > This may be a red herring, but I've heard of some dropping of DNS > queries for the names within outlook.com domains where the queries are > all coming from source port 53 (i.e. your recursive server doesn't use > query source port randomization ... or there's a NAT or some other box in front of the recursive server which re-writes the source port... > ). Might be worth checking what the > recursive server you're using is doing? > > See https://www.dns-oarc.net/oarc/services/porttest Joe From jamie at photon.com Thu May 2 12:01:51 2013 From: jamie at photon.com (Jamie Bowden) Date: Thu, 2 May 2013 12:01:51 +0000 Subject: Data Center Installations In-Reply-To: References: Message-ID: <465966A5F5B867419F604CD3E604C1E53B0E1CA3@PRA-DCA-MAIL.pra.ray.com> > From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] > > Do any of you have a "go to" resource for materials used in installations? Tie > wraps, cable management, blahblahblah? > > I have found several places, but I'm curious to know what the nanog ninja's > have to say. I use Graybar for the most part. If it's something small or easy, MicroCenter probably has it, but when I need a couple thousand feet of cat[5|5e|6|whatever], a bag of 500 cable ties, a box RJ-48s, etc., it's straight to Graybar. If it's not already on the shelf they can get it quick and their pricing is pretty good. -- Jamie Bowden (jamie at photon.com) Sr. Sys. Admin. (703) 243-6613 x3848 Photon Research Associates 1616 Fort Myer Drive, Suite 1000 Arlington, VA 22209 From isomer at gmail.com Wed May 1 17:19:48 2013 From: isomer at gmail.com (Perry Lorier) Date: Wed, 1 May 2013 18:19:48 +0100 Subject: Google Public DNS Problems? In-Reply-To: <51814E1E.4070503@gmail.com> References: <51814E1E.4070503@gmail.com> Message-ID: On 5/1/13 12:38 PM, Blair Trosper wrote: > That's all well and good, but I certainly wouldn't expect "nslookup > gmail.com " or for "nslookup google.com" to return > SERVFAIL > > Do you have traceroutes to 8.8.8.8 and 8.8.4.4? From blake.mailinglist at pfankuch.me Wed May 1 23:17:39 2013 From: blake.mailinglist at pfankuch.me (Blake Pfankuch - Mailing List) Date: Wed, 1 May 2013 23:17:39 +0000 Subject: Data Center Installations In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B018626@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B018626@ocsbs.ocosa.com> Message-ID: Along this same line of questioning... favorite Velcro? I used to get spools of about 500 8 inch strips for a reasonable amount however the vendor went out of business. The cloth tabs are nice, but then end up getting in the way... Thanks, Blake -----Original Message----- From: Otis L. Surratt, Jr. [mailto:otis at ocosa.com] Sent: Wednesday, May 1, 2013 1:40 PM To: Warren Bailey; nanog at nanog.org Subject: RE: Data Center Installations -----Original Message----- From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] Sent: Wednesday, May 01, 2013 2:24 PM To: nanog at nanog.org Subject: Data Center Installations >Do any of you have a "go to" resource for materials used in installations? Tie wraps, cable management, blahblahblah? > >I have found several places, but I'm curious to know what the nanog ninja's have to say. > >//warren We've used both CSC and Graybar, more frequently CSC better deals in our case. For very nice affordable Cat 5e/6A patch cords iofast.com we've never purchased a patch from anywhere else since we found them. From blake.mailinglist at pfankuch.me Wed May 1 23:37:33 2013 From: blake.mailinglist at pfankuch.me (Blake Pfankuch - Mailing List) Date: Wed, 1 May 2013 23:37:33 +0000 Subject: Data Center Installations In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B018626@ocsbs.ocosa.com> <5FE1FB6D43B8A647BBC821840C1AEA8B018629@ocsbs.ocosa.com> Message-ID: We have been going with rolls and cut to fit, however looking for something precut that way we don't end up with a NOC monkey putting a 18 inch piece of Velcro on 4 cat5 cables... I do have pictures... If they only get 8 inch strips, it helps keep things cleaner, and then leave the cut to fit to the people who have "engineer" in their title. Mike, I was looking at them as well and will add them to the list to pay attention to. Thanks, for the suggestion, I will order a roll and have a look. Thanks, Blake From: Mike Lyon [mailto:mike.lyon at gmail.com] Sent: Wednesday, May 1, 2013 5:33 PM To: Otis L. Surratt, Jr. Cc: Blake Pfankuch - Mailing List; Warren Bailey; NANOG Subject: Re: Data Center Installations For bulk velcro, I found Uline to be fairly cheap. On Wed, May 1, 2013 at 4:30 PM, Otis L. Surratt, Jr. > wrote: -----Original Message----- From: Blake Pfankuch - Mailing List [mailto:blake.mailinglist at pfankuch.me] Sent: Wednesday, May 01, 2013 6:18 PM To: Otis L. Surratt, Jr.; Warren Bailey; nanog at nanog.org Subject: RE: Data Center Installations >Along this same line of questioning... favorite Velcro? I used to get spools of about 500 8 inch strips for a reasonable amount however the vendor went out of business. The cloth tabs are nice, but then end >up getting in the way... > >Thanks, >Blake You should be able to get a roll from Graybar. Never checked with CSC for that. We bought a large roll from Graybar and simply cut what we need. It's not precut and pretty but it works. -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From israel.lugo at lugosys.com Thu May 2 14:01:50 2013 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Thu, 02 May 2013 15:01:50 +0100 Subject: Problem reaching Wikipedia (AS43821) via Tele2 Message-ID: <518271CE.7010002@lugosys.com> Hello, Anyone else having problems reaching Wikipedia? I can't reach AS43821 (Wikimedia RIPE) from within the Portuguese NREN (AS1930), via Cogent (AS174) -> Tele2 (AS1257): traceroute to en.wikipedia.org (91.198.174.225), 30 hops max, 60 byte packets 1 Router3.10GE.Lisboa.fccn.pt (193.136.1.89) [AS1930] 0.953 ms 2 ROUTER10.10GE.Lisboa.fccn.pt (193.137.0.8) [AS1930] 0.939 ms 3 ROUTER4.10GE.Lisboa.fccn.pt (193.137.0.20) [AS1930] 1.000 ms 4 fccn.mx2.lis.pt.geant.net (62.40.124.97) [AS20965] 1.000 ms 5 xe-2-3-0.rt1.mad.es.geant.net (62.40.98.107) [AS20965] 13.926 ms 6 as2.rt1.gen.ch.geant2.net (62.40.112.25) [AS20965] 37.882 ms 7 ae3.mx1.gen.ch.geant.net (62.40.112.14) [AS20965] 37.874 ms 8 ae1.mx1.fra.de.geant.net (62.40.98.109) [AS20965] 44.154 ms 9 ae4.rt1.fra.de.geant.net (62.40.98.135) [AS20965] 43.935 ms 10 te0-4-0-2.mag21.fra03.atlas.cogentco.com (149.6.42.73) [AS174] 44.842 ms 11 fra36-peer-1.xe-1-2-0-unit0.tele2.net (130.244.200.41) [AS1257] 44.368 ms 12 fra36-core-1.bundle-ether2.tele2.net (130.244.64.186) [AS1257] 44.977 ms 13 * 14 ams13-peer-1.ae0-unit0.tele2.net (130.244.53.123) [AS1257] 50.299 ms 15 * 16 * 17 * 18 * 19 * 20 * Tele2's traceroute server (http://services.tele2net.at/traceroute.html) reaches the same IP without problems: 1 213.90.34.4 (213.90.34.4) 0.268 ms 0.124 ms 0.151 ms 2 213.90.1.20 (213.90.1.20) 0.430 ms 0.382 ms 0.303 ms 3 wat1-15-93.net.uta.at (62.218.15.93) 0.497 ms 0.368 ms 0.387 ms 4 c76wmode1-tengigE4-1.net.uta.at (212.152.192.206) 0.644 ms 0.572 ms 0.599 ms 5 wen1-core-2.tengige0-0-1-1.tele2.net (130.244.205.57) 0.836 ms 0.874 ms 0.737 ms 6 fra36-core-1.bundle-ether7.tele2.net (130.244.206.28) 13.683 ms 13.472 ms 13.817 ms 7 ams-core-2.bundle-ether4.tele2.net (130.244.64.201) 20.421 ms 20.482 ms 20.762 ms 8 ams13-peer-1.ae0-unit0.tele2.net (130.244.53.123) 19.972 ms 19.936 ms 19.962 ms 9 ge-2-5.br1-knams.wikimedia.org (130.244.6.250) 20.727 ms 20.641 ms 20.660 ms 10 wikipedia-lb.esams.wikimedia.org (91.198.174.225) 20.610 ms 20.539 ms 20.615 ms Trying from $HOME_ISP, via AS6453 (Globe) -> AS1299 (Telia) works fine. Regards, Israel G. Lugo From jra at baylink.com Thu May 2 14:32:47 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 2 May 2013 10:32:47 -0400 (EDT) Subject: Google Public DNS Problems? In-Reply-To: Message-ID: <18108268.4864.1367505167179.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Perry Lorier" > On 5/1/13 12:38 PM, Blair Trosper wrote: > > > That's all well and good, but I certainly wouldn't expect "nslookup > > gmail.com " or for "nslookup google.com" to return > > SERVFAIL > Do you have traceroutes to 8.8.8.8 and 8.8.4.4? Is that actually pertinent? 8.8 and 8.4 aren't *public zone servers* for Google's commercial domains, are they? I have been assuming they were only open recursive resolver nameservers... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From morrowc.lists at gmail.com Thu May 2 15:23:12 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 May 2013 11:23:12 -0400 Subject: Google Public DNS Problems? In-Reply-To: <18108268.4864.1367505167179.JavaMail.root@benjamin.baylink.com> References: <18108268.4864.1367505167179.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, May 2, 2013 at 10:32 AM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Perry Lorier" > > > On 5/1/13 12:38 PM, Blair Trosper wrote: > > > > > That's all well and good, but I certainly wouldn't expect "nslookup > > > gmail.com " or for "nslookup google.com" to return > > > SERVFAIL > > > Do you have traceroutes to 8.8.8.8 and 8.8.4.4? > > Is that actually pertinent? > > 8.8 and 8.4 aren't *public zone servers* for Google's commercial domains, > are they? I have been assuming they were only open recursive resolver > nameservers... > > I think perry's question is: "Can you show me which networks you traversed and which instance of the service you were talking to at the time of the problem?" (or 'now' if the problem is persisting) From jra at baylink.com Thu May 2 15:51:12 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 2 May 2013 11:51:12 -0400 (EDT) Subject: Google Public DNS Problems? In-Reply-To: Message-ID: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Christopher Morrow" > On Thu, May 2, 2013 at 10:32 AM, Jay Ashworth wrote: > > > ----- Original Message ----- > > > From: "Perry Lorier" > > > > > On 5/1/13 12:38 PM, Blair Trosper wrote: > > > > > > > That's all well and good, but I certainly wouldn't expect "nslookup > > > > gmail.com " or for "nslookup google.com" to > > > > return SERVFAIL > > > > > Do you have traceroutes to 8.8.8.8 and 8.8.4.4? > > > > Is that actually pertinent? > > > > 8.8 and 8.4 aren't *public zone servers* for Google's commercial domains, > > are they? I have been assuming they were only open recursive resolver > > nameservers... > I think perry's question is: "Can you show me which networks you traversed > and which instance of the service you were talking to at the time of > the problem?" (or 'now' if the problem is persisting) Sure, Chris. But since Perry's problem is *inability to resolve names in google's public zones*, the *path to the ZONE servers* is the thing diagnostics would require a trace to, no? If 8.8.8.8 doesn't *answer* for "google.com" (and no one's told me it has), then how you get there is irrelevant. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jabley at hopcount.ca Thu May 2 15:55:30 2013 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 2 May 2013 11:55:30 -0400 Subject: Google Public DNS Problems? In-Reply-To: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> References: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> Message-ID: <8E4F462A-B098-4958-B190-EE76AFED452A@hopcount.ca> On 2013-05-02, at 11:51, Jay Ashworth wrote: > But since Perry's problem is *inability to resolve names in google's > public zones*, the *path to the ZONE servers* is the thing diagnostics > would require a trace to, no? Blair's problem, I think. Perry was just being helpful. Blair's point was that if Google DNS is not able to resolve Google domains, then you know something is wrong. > If 8.8.8.8 doesn't *answer* for "google.com" (and no one's told me it > has), then how you get there is irrelevant. Well, if you're trying to troubleshoot the performance or functionality of a service that is deployed using anycast, knowing what anycast node is giving problems is pretty useful. I say this as someone who has to help troubleshoot problems with anycast DNS services pretty regularly. Since there's no obvious way (in the draft-jabley-dnsop-anycast-mapping sense) to identify a Google DNS anycast node in-band, traceroute and RTT are pretty much what we're left with. Joe From cgucker at onesc.net Thu May 2 15:59:22 2013 From: cgucker at onesc.net (Charles Gucker) Date: Thu, 2 May 2013 11:59:22 -0400 Subject: Google Public DNS Problems? In-Reply-To: <8E4F462A-B098-4958-B190-EE76AFED452A@hopcount.ca> References: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> <8E4F462A-B098-4958-B190-EE76AFED452A@hopcount.ca> Message-ID: Joe, That's not entirely true. You can easily do lookup for whoami.akamai.net and it will return the unicast address for the node in question (provided the local resolver is able to do the resolution). This is a frequent lookup that I do when I don't know what actual anycast node I'm using. charles On Thu, May 2, 2013 at 11:55 AM, Joe Abley wrote: > > On 2013-05-02, at 11:51, Jay Ashworth wrote: > >> But since Perry's problem is *inability to resolve names in google's >> public zones*, the *path to the ZONE servers* is the thing diagnostics >> would require a trace to, no? > > Blair's problem, I think. Perry was just being helpful. Blair's point was that if Google DNS is not able to resolve Google domains, then you know something is wrong. > >> If 8.8.8.8 doesn't *answer* for "google.com" (and no one's told me it >> has), then how you get there is irrelevant. > > Well, if you're trying to troubleshoot the performance or functionality of a service that is deployed using anycast, knowing what anycast node is giving problems is pretty useful. I say this as someone who has to help troubleshoot problems with anycast DNS services pretty regularly. > > Since there's no obvious way (in the draft-jabley-dnsop-anycast-mapping sense) to identify a Google DNS anycast node in-band, traceroute and RTT are pretty much what we're left with. > > > Joe From morrowc.lists at gmail.com Thu May 2 16:01:37 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 May 2013 12:01:37 -0400 Subject: Google Public DNS Problems? In-Reply-To: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> References: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, May 2, 2013 at 11:51 AM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Christopher Morrow" > > > On Thu, May 2, 2013 at 10:32 AM, Jay Ashworth wrote: > > > > > ----- Original Message ----- > > > > From: "Perry Lorier" > > > > > > > On 5/1/13 12:38 PM, Blair Trosper wrote: > > > > > > > > > That's all well and good, but I certainly wouldn't expect "nslookup > > > > > gmail.com " or for "nslookup google.com" to > > > > > return SERVFAIL > > > > > > > Do you have traceroutes to 8.8.8.8 and 8.8.4.4? > > > > > > Is that actually pertinent? > > > > > > 8.8 and 8.4 aren't *public zone servers* for Google's commercial > domains, > > > are they? I have been assuming they were only open recursive resolver > > > nameservers... > > > I think perry's question is: "Can you show me which networks you > traversed > > and which instance of the service you were talking to at the time of > > the problem?" (or 'now' if the problem is persisting) > > Sure, Chris. > > But since Perry's problem is *inability to resolve names in google's > s/perry/blair/ > public zones*, the *path to the ZONE servers* is the thing diagnostics > would require a trace to, no? > I think, from some troubleshooting with blair yesterday he was having some odd problems with queries to google-public-dns (gdns), where everything he asked came up servfail. I wasn't able to repro this, which was annoying ;( We (perry/others) were interested in verifying that something odd wasn't happening between blair and the server answering his question(s)... > > If 8.8.8.8 doesn't *answer* for "google.com" (and no one's told me it > has), then how you get there is irrelevant. > > 8.8.8.8 is just an open resolver... oh, jabley replied as well (alway a cogent reply from him) > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > From jabley at hopcount.ca Thu May 2 16:10:40 2013 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 2 May 2013 12:10:40 -0400 Subject: Google Public DNS Problems? In-Reply-To: References: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> <8E4F462A-B098-4958-B190-EE76AFED452A@hopcount.ca> Message-ID: <734DD68C-4AF2-47E0-9966-C31DAC6E4BCD@hopcount.ca> On 2013-05-02, at 11:59, Charles Gucker wrote: > That's not entirely true. You can easily do lookup for > whoami.akamai.net and it will return the unicast address for the node > in question (provided the local resolver is able to do the > resolution). This is a frequent lookup that I do when I don't know > what actual anycast node I'm using. Using 8.8.8.8 to tell me about whoami.akamai.net tells me what Akamai authoritative server Google last used to answer that query. If I can rely upon there being an Akamai auth server every place there's a Google 8.8.8.8 server, then that does seem fun and useful for identifying the Google node I'm using. Is that the case? (If I ask 8.8.8.8, which is somewhere 30ms from Toronto, about identity.l.root-servers.org/IN/TXT then the answer I get just now is "Paris, France". L-Root and Google/8.8.8.8 are not colocated. So the usefulness of this technique in general to identify Google nodes depends on deployment assumptions.) Joe From jabley at hopcount.ca Thu May 2 16:12:46 2013 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 2 May 2013 12:12:46 -0400 Subject: Google Public DNS Problems? In-Reply-To: <734DD68C-4AF2-47E0-9966-C31DAC6E4BCD@hopcount.ca> References: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> <8E4F462A-B098-4958-B190-EE76AFED452A@hopcount.ca> <734DD68C-4AF2-47E0-9966-C31DAC6E4BCD@hopcount.ca> Message-ID: <31BE8CEA-379B-4F8A-A3AB-586970EEF248@hopcount.ca> On 2013-05-02, at 12:10, Joe Abley wrote: > On 2013-05-02, at 11:59, Charles Gucker wrote: > >> That's not entirely true. You can easily do lookup for >> whoami.akamai.net and it will return the unicast address for the node >> in question (provided the local resolver is able to do the >> resolution). This is a frequent lookup that I do when I don't know >> what actual anycast node I'm using. > > Using 8.8.8.8 to tell me about whoami.akamai.net tells me what Akamai authoritative server Google last used to answer that query. Oh, now that I poke at it, it seems like whoami.akamai.net is telling me about the address of the resolver I used, rather than the address of the akamai node I hit. Never mind, I understand now :-) Joe From joesox at gmail.com Thu May 2 17:16:06 2013 From: joesox at gmail.com (JoeSox) Date: Thu, 2 May 2013 10:16:06 -0700 Subject: Could not send email to office 365 In-Reply-To: <2AEB6E00-1ECA-460F-A656-98085B5F053D@hopcount.ca> References: <20130501182123.2455.AEA43824@ugec.net> <51820ABE.4070000@isc.org> <2AEB6E00-1ECA-460F-A656-98085B5F053D@hopcount.ca> Message-ID: Our Technical Support is reporting a big jump in Outlook connectivity issues about 5-10 minutes ago. Our resolvers are testing fine. -- Thanks, Joe On Thu, May 2, 2013 at 4:53 AM, Joe Abley wrote: > > On 2013-05-02, at 02:42, Cathy Almond wrote: > > > This may be a red herring, but I've heard of some dropping of DNS > > queries for the names within outlook.com domains where the queries are > > all coming from source port 53 (i.e. your recursive server doesn't use > > query source port randomization > > ... or there's a NAT or some other box in front of the recursive server > which re-writes the source port... > > > ). Might be worth checking what the > > recursive server you're using is doing? > > > > See https://www.dns-oarc.net/oarc/services/porttest > > > Joe > From shortdudey123 at gmail.com Thu May 2 18:08:09 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Thu, 2 May 2013 13:08:09 -0500 Subject: Problem reaching Wikipedia (AS43821) via Tele2 In-Reply-To: <518271CE.7010002@lugosys.com> References: <518271CE.7010002@lugosys.com> Message-ID: <791AB073-4ACB-47C2-A864-1B63338CBF03@gmail.com> Looks like ge-2-5.br1-knams.wikimedia.org (130.244.6.250) is filtering you somehow. Grant Sent from my iPhone On May 2, 2013, at 9:01 AM, "Israel G. Lugo" wrote: > Hello, > > Anyone else having problems reaching Wikipedia? > > I can't reach AS43821 (Wikimedia RIPE) from within the Portuguese NREN > (AS1930), via Cogent (AS174) -> Tele2 (AS1257): > > traceroute to en.wikipedia.org (91.198.174.225), 30 hops max, 60 byte > packets > 1 Router3.10GE.Lisboa.fccn.pt (193.136.1.89) [AS1930] 0.953 ms > 2 ROUTER10.10GE.Lisboa.fccn.pt (193.137.0.8) [AS1930] 0.939 ms > 3 ROUTER4.10GE.Lisboa.fccn.pt (193.137.0.20) [AS1930] 1.000 ms > 4 fccn.mx2.lis.pt.geant.net (62.40.124.97) [AS20965] 1.000 ms > 5 xe-2-3-0.rt1.mad.es.geant.net (62.40.98.107) [AS20965] 13.926 ms > 6 as2.rt1.gen.ch.geant2.net (62.40.112.25) [AS20965] 37.882 ms > 7 ae3.mx1.gen.ch.geant.net (62.40.112.14) [AS20965] 37.874 ms > 8 ae1.mx1.fra.de.geant.net (62.40.98.109) [AS20965] 44.154 ms > 9 ae4.rt1.fra.de.geant.net (62.40.98.135) [AS20965] 43.935 ms > 10 te0-4-0-2.mag21.fra03.atlas.cogentco.com (149.6.42.73) [AS174] > 44.842 ms > 11 fra36-peer-1.xe-1-2-0-unit0.tele2.net (130.244.200.41) [AS1257] > 44.368 ms > 12 fra36-core-1.bundle-ether2.tele2.net (130.244.64.186) [AS1257] > 44.977 ms > 13 * > 14 ams13-peer-1.ae0-unit0.tele2.net (130.244.53.123) [AS1257] 50.299 ms > 15 * > 16 * > 17 * > 18 * > 19 * > 20 * > > Tele2's traceroute server (http://services.tele2net.at/traceroute.html) > reaches the same IP without problems: > > 1 213.90.34.4 (213.90.34.4) 0.268 ms 0.124 ms 0.151 ms > 2 213.90.1.20 (213.90.1.20) 0.430 ms 0.382 ms 0.303 ms > 3 wat1-15-93.net.uta.at (62.218.15.93) 0.497 ms 0.368 ms 0.387 ms > 4 c76wmode1-tengigE4-1.net.uta.at (212.152.192.206) 0.644 ms 0.572 ms > 0.599 ms > 5 wen1-core-2.tengige0-0-1-1.tele2.net (130.244.205.57) 0.836 ms 0.874 > ms 0.737 ms > 6 fra36-core-1.bundle-ether7.tele2.net (130.244.206.28) 13.683 ms 13.472 > ms 13.817 ms > 7 ams-core-2.bundle-ether4.tele2.net (130.244.64.201) 20.421 ms 20.482 > ms 20.762 ms > 8 ams13-peer-1.ae0-unit0.tele2.net (130.244.53.123) 19.972 ms 19.936 ms > 19.962 ms > 9 ge-2-5.br1-knams.wikimedia.org (130.244.6.250) 20.727 ms 20.641 ms > 20.660 ms > 10 wikipedia-lb.esams.wikimedia.org (91.198.174.225) 20.610 ms 20.539 ms > 20.615 ms > > Trying from $HOME_ISP, via AS6453 (Globe) -> AS1299 (Telia) works fine. > > Regards, > Israel G. Lugo > > From uwcableguy at gmail.com Thu May 2 18:08:23 2013 From: uwcableguy at gmail.com (Ben Bartsch) Date: Thu, 2 May 2013 13:08:23 -0500 Subject: BGP Route Recorder suggestions Message-ID: Hi all: I am curious what you RENs out there are using for BGP (and IGP) route recording. We did a demo of Packet Design's Route Explorer. While I loved the functionality and ease of use, we simply can not afford it. I am attracted to iBGPlay since we use the BGPlayer at routeviews all the time, but I can't seem to get a privacy statement from the software authors. Any other (cheap) route recorders out there? Any recommendations on what y'all are using that you like / don't like? Thanks in advance for any input. -ben From patrick at ianai.net Thu May 2 18:12:56 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 2 May 2013 14:12:56 -0400 Subject: whoami.akamai.net [was: Google Public DNS Problems?] In-Reply-To: <31BE8CEA-379B-4F8A-A3AB-586970EEF248@hopcount.ca> References: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> <8E4F462A-B098-4958-B190-EE76AFED452A@hopcount.ca> <734DD68C-4AF2-47E0-9966-C31DAC6E4BCD@hopcount.ca> <31BE8CEA-379B-4F8A-A3AB-586970EEF248@hopcount.ca> Message-ID: On May 02, 2013, at 12:12 , Joe Abley wrote: > On 2013-05-02, at 12:10, Joe Abley wrote: >> On 2013-05-02, at 11:59, Charles Gucker wrote: >>> That's not entirely true. You can easily do lookup for >>> whoami.akamai.net and it will return the unicast address for the node >>> in question (provided the local resolver is able to do the >>> resolution). This is a frequent lookup that I do when I don't know >>> what actual anycast node I'm using. >> >> Using 8.8.8.8 to tell me about whoami.akamai.net tells me what Akamai authoritative server Google last used to answer that query. > > Oh, now that I poke at it, it seems like whoami.akamai.net is telling me about the address of the resolver I used, rather than the address of the akamai node I hit. > > Never mind, I understand now :-) For clarity: Looking up the hostname "whoami.akamai.net" will return the IP address in the source field of the packet (DNS query) which reached the authoritative name server for Akamai.net. We use this to look for forwarding or proxying, which is frequently unknown / invisible to the end user. It has the side-effect that querying against an anycast server (e.g. 208.67.222.222 or 8.8.8.8) will show the unicast address of the anycast node which forwarded to our servers. In case anyone is wondering, we do not do any special logging or watching of this hostname. It is logged for a short time on the local hard drive the same as any other DNS query, but unless someone actually looks, we will not notice if you query for it. So feel free to use it for your own purposes as much as you like. We have a bit of spare DNS capacity. :) -- TTFN, patrick From mureninc at gmail.com Thu May 2 18:42:50 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 2 May 2013 11:42:50 -0700 Subject: whoami.akamai.net [was: Google Public DNS Problems?] In-Reply-To: References: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> <8E4F462A-B098-4958-B190-EE76AFED452A@hopcount.ca> <734DD68C-4AF2-47E0-9966-C31DAC6E4BCD@hopcount.ca> <31BE8CEA-379B-4F8A-A3AB-586970EEF248@hopcount.ca> Message-ID: On 2 May 2013 11:12, Patrick W. Gilmore wrote: > On May 02, 2013, at 12:12 , Joe Abley wrote: >> On 2013-05-02, at 12:10, Joe Abley wrote: >>> On 2013-05-02, at 11:59, Charles Gucker wrote: > >>>> That's not entirely true. You can easily do lookup for >>>> whoami.akamai.net and it will return the unicast address for the node >>>> in question (provided the local resolver is able to do the >>>> resolution). This is a frequent lookup that I do when I don't know >>>> what actual anycast node I'm using. >>> >>> Using 8.8.8.8 to tell me about whoami.akamai.net tells me what Akamai authoritative server Google last used to answer that query. >> >> Oh, now that I poke at it, it seems like whoami.akamai.net is telling me about the address of the resolver I used, rather than the address of the akamai node I hit. >> >> Never mind, I understand now :-) > > For clarity: Looking up the hostname "whoami.akamai.net" will return the IP address in the source field of the packet (DNS query) which reached the authoritative name server for Akamai.net. > > We use this to look for forwarding or proxying, which is frequently unknown / invisible to the end user. > > It has the side-effect that querying against an anycast server (e.g. 208.67.222.222 or 8.8.8.8) will show the unicast address of the anycast node which forwarded to our servers. > > In case anyone is wondering, we do not do any special logging or watching of this hostname. It is logged for a short time on the local hard drive the same as any other DNS query, but unless someone actually looks, we will not notice if you query for it. So feel free to use it for your own purposes as much as you like. We have a bit of spare DNS capacity. :) No IPv6 at akamai.net, huh? :p Cns# host whoami.akamai.net whoami.akamai.net has address 216.66.80.30 Cns# host 216.66.80.30 30.80.66.216.in-addr.arpa domain name pointer tserv1.fra1.he.net. Cns# Does anyone run a DNS whoami that's IPv6-ready? C. From patrick at ianai.net Thu May 2 18:47:05 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 2 May 2013 14:47:05 -0400 Subject: whoami.akamai.net [was: Google Public DNS Problems?] In-Reply-To: References: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> <8E4F462A-B098-4958-B190-EE76AFED452A@hopcount.ca> <734DD68C-4AF2-47E0-9966-C31DAC6E4BCD@hopcount.ca> <31BE8CEA-379B-4F8A-A3AB-586970EEF248@hopcount.ca> Message-ID: <5271935C-8822-4C82-A234-CC4F73CD1039@ianai.net> On May 02, 2013, at 14:42 , "Constantine A. Murenin" wrote: > On 2 May 2013 11:12, Patrick W. Gilmore wrote: >> For clarity: Looking up the hostname "whoami.akamai.net" will return the IP address in the source field of the packet (DNS query) which reached the authoritative name server for Akamai.net. >> >> We use this to look for forwarding or proxying, which is frequently unknown / invisible to the end user. >> >> It has the side-effect that querying against an anycast server (e.g. 208.67.222.222 or 8.8.8.8) will show the unicast address of the anycast node which forwarded to our servers. >> >> In case anyone is wondering, we do not do any special logging or watching of this hostname. It is logged for a short time on the local hard drive the same as any other DNS query, but unless someone actually looks, we will not notice if you query for it. So feel free to use it for your own purposes as much as you like. We have a bit of spare DNS capacity. :) > > No IPv6 at akamai.net, huh? :p No, sorry. We're working on it. Of course, v6 is available on most other Akamai products. And if someone wants to pay us for v6 on whomai..... :) -- TTFN, patrick > Cns# host whoami.akamai.net > whoami.akamai.net has address 216.66.80.30 > Cns# host 216.66.80.30 > 30.80.66.216.in-addr.arpa domain name pointer tserv1.fra1.he.net. > Cns# > > Does anyone run a DNS whoami that's IPv6-ready? > > C. > From morrowc.lists at gmail.com Thu May 2 18:57:46 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 May 2013 14:57:46 -0400 Subject: whoami.akamai.net [was: Google Public DNS Problems?] In-Reply-To: References: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> <8E4F462A-B098-4958-B190-EE76AFED452A@hopcount.ca> <734DD68C-4AF2-47E0-9966-C31DAC6E4BCD@hopcount.ca> <31BE8CEA-379B-4F8A-A3AB-586970EEF248@hopcount.ca> Message-ID: On Thu, May 2, 2013 at 2:12 PM, Patrick W. Gilmore wrote: > On May 02, 2013, at 12:12 , Joe Abley wrote: > > On 2013-05-02, at 12:10, Joe Abley wrote: > >> On 2013-05-02, at 11:59, Charles Gucker wrote: > > >>> That's not entirely true. You can easily do lookup for > >>> whoami.akamai.net and it will return the unicast address for the node > >>> in question (provided the local resolver is able to do the > >>> resolution). This is a frequent lookup that I do when I don't know > >>> what actual anycast node I'm using. > >> > >> Using 8.8.8.8 to tell me about whoami.akamai.net tells me what Akamai > authoritative server Google last used to answer that query. > > > > Oh, now that I poke at it, it seems like whoami.akamai.net is telling > me about the address of the resolver I used, rather than the address of the > akamai node I hit. > > > > Never mind, I understand now :-) > > For clarity: Looking up the hostname "whoami.akamai.net" will return the > IP address in the source field of the packet (DNS query) which reached the > authoritative name server for Akamai.net. > > We use this to look for forwarding or proxying, which is frequently > unknown / invisible to the end user. > > It has the side-effect that querying against an anycast server (e.g. > 208.67.222.222 or 8.8.8.8) will show the unicast address of the anycast > node which forwarded to our servers. > > 'the unicast address of the exit for upstream/cache-fill lookups' .. since the topology behind the anycast node isn't necessarily: internet -> anycast-ip -|host|- unicast-ip ... there could be some networking between |host| and the outside world, or other things going on. anyway... nit-picking-aside, cool that there's a way to figure this sort of thing out :) google has a similar method, which I can't find today :( From jcaffery at lsu.edu Thu May 2 17:35:05 2013 From: jcaffery at lsu.edu (John D Caffery) Date: Thu, 2 May 2013 17:35:05 +0000 Subject: Louisiana Optical Network Initiative In-Reply-To: <759366B15C91B844B1122B305C967A2A6505D5EC@BY2PRD0612MB671.namprd06.prod.outlook.com> References: <759366B15C91B844B1122B305C967A2A6505D5EC@BY2PRD0612MB671.namprd06.prod.outlook.com> Message-ID: <759366B15C91B844B1122B305C967A2A6505E374@BY2PRD0612MB671.namprd06.prod.outlook.com> I am sending this query on behalf of the University of New Orleans. For the past couple of weeks users on their campus are unable to get logged on to the Capital One Online Banking Secure Portal to do their online banking. The UNO AS number is 23666 and LONI, which I am part of, is their internet provider, AS number 32440. None of our other Louisiana Participants seem to have an issue getting there and every test I do from other locations in our network are successful. Users can get to the https://onlinebanking.capitalone.com site but after putting in their login credentials the site simply times out. Capital One peers with both Verizon and AT&T but when I go to the above site it is via Verizon. Does anyone know of or have this issue also? I have a ticket open with Verizon but have yet to get a response. I was speaking with a representative from Capital One but after leaving several voice mails I have yet to get a call back. Thank you in advance for anyone's assistance, John Caffery Information Technology Consultant Louisiana Optical Network Initiative - LONI O 225.578.7263 C 225.252.3046 www.loni.org From joquendo at e-fensive.net Thu May 2 19:40:58 2013 From: joquendo at e-fensive.net (J. Oquendo) Date: Thu, 2 May 2013 14:40:58 -0500 Subject: Google Security Contact Message-ID: <20130502194058.GA47043@e-fensive.net> Can someone put me in touch with someone "up there" in the security realm at Google? (sorry for the noise) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF From betty at newnog.org Thu May 2 20:14:39 2013 From: betty at newnog.org (Betty Burke ) Date: Thu, 2 May 2013 16:14:39 -0400 Subject: [NANOG-announce] NANOG 58 Updates Message-ID: Colleagues: NANOG 58 is fast approaching! NANOGers will be meeting June 3 ? 5, 2013 in New Orleans, LA. Do not delay, be sure to register for NANOG 58and take advantage of early Bird Registration which ends on May 10, 2013 (non-member $450, member $425, student $100). As you register for NANOG 58, be sure to reserve your hotel room at theRoosevelt New Orleans Hotel, the room block is almost full and the NANOG room rate will expire at 5 PM CT on May 10, 2013. For meeting information be sure to visit the NANOG 58 Highlightspage, and check-out the NANOG Topic List and Preliminary Agenda . The NANOG Program Committee received a number of great submissions and are very close to posting the tentative agenda. NANOG 58 will once again showcase a program packed with great content. If you are interested in a NANOG Sponsorship, contact our Development Committee by emailing Marketing at nanog.org. We look forward to a great meeting and seeing you in New Orleans. Should you have any questions, please direct them to nanog-support at nanog.org . Sincerely, Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From damian at google.com Thu May 2 22:02:37 2013 From: damian at google.com (Damian Menscher) Date: Thu, 2 May 2013 15:02:37 -0700 Subject: Google Security Contact In-Reply-To: <20130502194058.GA47043@e-fensive.net> References: <20130502194058.GA47043@e-fensive.net> Message-ID: In general security vulnerabilities in applications should be reported following the links at http://www.google.com/about/appsecurity/ For abuse issues, there are usually links within the products. If your question isn't covered by any of that, I can probably help. Feel free to ping me off-list. Damian -- Damian Menscher :: Security Reliability Engineer :: Google On Thu, May 2, 2013 at 12:40 PM, J. Oquendo wrote: > > Can someone put me in touch with someone "up there" in the > security realm at Google? (sorry for the noise) > > -- > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM > > "Where ignorance is our master, there is no possibility of > real peace" - Dalai Lama > > 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF > > From tcannon at beatsmusic.com Thu May 2 21:55:09 2013 From: tcannon at beatsmusic.com (Thomas Cannon) Date: Thu, 2 May 2013 14:55:09 -0700 Subject: Louisiana Optical Network Initiative In-Reply-To: <759366B15C91B844B1122B305C967A2A6505E374@BY2PRD0612MB671.namprd06.prod.outlook.com> References: <759366B15C91B844B1122B305C967A2A6505D5EC@BY2PRD0612MB671.namprd06.prod.outlook.com> <759366B15C91B844B1122B305C967A2A6505E374@BY2PRD0612MB671.namprd06.prod.outlook.com> Message-ID: <2FFAD874-F004-457E-B63E-107A5DFE13EB@beatsmusic.com> Hijacked DNS to steal login credentials perhaps? -tc On May 2, 2013, at 10:35 AM, John D Caffery wrote: > I am sending this query on behalf of the University of New Orleans. For the past couple of weeks users on their campus are unable to get logged on to the Capital One Online Banking Secure Portal to do their online banking. The UNO AS number is 23666 and LONI, which I am part of, is their internet provider, AS number 32440. None of our other Louisiana Participants seem to have an issue getting there and every test I do from other locations in our network are successful. Users can get to the https://onlinebanking.capitalone.com site but after putting in their login credentials the site simply times out. > > Capital One peers with both Verizon and AT&T but when I go to the above site it is via Verizon. > > Does anyone know of or have this issue also? I have a ticket open with Verizon but have yet to get a response. I was speaking with a representative from Capital One but after leaving several voice mails I have yet to get a call back. > > Thank you in advance for anyone's assistance, > > John Caffery > Information Technology Consultant > Louisiana Optical Network Initiative - LONI > O 225.578.7263 > C 225.252.3046 > www.loni.org > > From fergdawgster at gmail.com Thu May 2 22:22:10 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 2 May 2013 15:22:10 -0700 Subject: Louisiana Optical Network Initiative In-Reply-To: <2FFAD874-F004-457E-B63E-107A5DFE13EB@beatsmusic.com> References: <759366B15C91B844B1122B305C967A2A6505D5EC@BY2PRD0612MB671.namprd06.prod.outlook.com> <759366B15C91B844B1122B305C967A2A6505E374@BY2PRD0612MB671.namprd06.prod.outlook.com> <2FFAD874-F004-457E-B63E-107A5DFE13EB@beatsmusic.com> Message-ID: John, Can you provide the prefixes in question off-list? Thanks, - ferg (not at Capital One, but can perhaps assist here) > On May 2, 2013, at 10:35 AM, John D Caffery wrote: > >> I am sending this query on behalf of the University of New Orleans. For the past couple of weeks users on their campus are unable to get logged on to the Capital One Online Banking Secure Portal to do their online banking. The UNO AS number is 23666 and LONI, which I am part of, is their internet provider, AS number 32440. None of our other Louisiana Participants seem to have an issue getting there and every test I do from other locations in our network are successful. Users can get to the https://onlinebanking.capitalone.com site but after putting in their login credentials the site simply times out. >> >> Capital One peers with both Verizon and AT&T but when I go to the above site it is via Verizon. >> >> Does anyone know of or have this issue also? I have a ticket open with Verizon but have yet to get a response. I was speaking with a representative from Capital One but after leaving several voice mails I have yet to get a call back. >> >> Thank you in advance for anyone's assistance, >> >> John Caffery >> Information Technology Consultant >> Louisiana Optical Network Initiative - LONI >> O 225.578.7263 >> C 225.252.3046 >> www.loni.org >> >> > > -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From EWieling at nyigc.com Thu May 2 22:25:50 2013 From: EWieling at nyigc.com (Eric Wieling) Date: Thu, 2 May 2013 18:25:50 -0400 Subject: Louisiana Optical Network Initiative In-Reply-To: <2FFAD874-F004-457E-B63E-107A5DFE13EB@beatsmusic.com> References: <759366B15C91B844B1122B305C967A2A6505D5EC@BY2PRD0612MB671.namprd06.prod.outlook.com> <759366B15C91B844B1122B305C967A2A6505E374@BY2PRD0612MB671.namprd06.prod.outlook.com> <2FFAD874-F004-457E-B63E-107A5DFE13EB@beatsmusic.com> Message-ID: <616B4ECE1290D441AD56124FEBB03D081713F8F46B@mailserver2007.nyigc.globe> Blocking ICMP packet-too-big packets (or other ICMP which might break PMTU) on your firewall, perhaps? -----Original Message----- From: Thomas Cannon [mailto:tcannon at beatsmusic.com] Sent: Thursday, May 02, 2013 5:55 PM To: John D Caffery Cc: nanog at nanog.org Subject: Re: Louisiana Optical Network Initiative Hijacked DNS to steal login credentials perhaps? -tc On May 2, 2013, at 10:35 AM, John D Caffery wrote: > I am sending this query on behalf of the University of New Orleans. For the past couple of weeks users on their campus are unable to get logged on to the Capital One Online Banking Secure Portal to do their online banking. The UNO AS number is 23666 and LONI, which I am part of, is their internet provider, AS number 32440. None of our other Louisiana Participants seem to have an issue getting there and every test I do from other locations in our network are successful. Users can get to the https://onlinebanking.capitalone.com site but after putting in their login credentials the site simply times out. > > Capital One peers with both Verizon and AT&T but when I go to the above site it is via Verizon. > > Does anyone know of or have this issue also? I have a ticket open with Verizon but have yet to get a response. I was speaking with a representative from Capital One but after leaving several voice mails I have yet to get a call back. > > Thank you in advance for anyone's assistance, > > John Caffery > Information Technology Consultant > Louisiana Optical Network Initiative - LONI O 225.578.7263 > C 225.252.3046 > www.loni.org > > From cdaniel at nurve.com.au Thu May 2 22:41:41 2013 From: cdaniel at nurve.com.au (Cameron Daniel) Date: Fri, 03 May 2013 08:41:41 +1000 Subject: whoami.akamai.net [was: Google Public DNS =?UTF-8?Q?Problems=3F=5D?= In-Reply-To: References: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> <8E4F462A-B098-4958-B190-EE76AFED452A@hopcount.ca> <734DD68C-4AF2-47E0-9966-C31DAC6E4BCD@hopcount.ca> <31BE8CEA-379B-4F8A-A3AB-586970EEF248@hopcount.ca> Message-ID: On 2013-05-03 4:57 am, Christopher Morrow wrote: > anyway... nit-picking-aside, cool that there's a way to figure this > sort of > thing out :) > google has a similar method, which I can't find today :( webcrawler!!!> dig -t txt o-o.myaddr.l.google.com From mureninc at gmail.com Thu May 2 22:48:08 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 2 May 2013 15:48:08 -0700 Subject: whoami.akamai.net [was: Google Public DNS Problems?] In-Reply-To: References: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> <8E4F462A-B098-4958-B190-EE76AFED452A@hopcount.ca> <734DD68C-4AF2-47E0-9966-C31DAC6E4BCD@hopcount.ca> <31BE8CEA-379B-4F8A-A3AB-586970EEF248@hopcount.ca> Message-ID: On 2 May 2013 15:41, Cameron Daniel wrote: > On 2013-05-03 4:57 am, Christopher Morrow wrote: >> >> anyway... nit-picking-aside, cool that there's a way to figure this sort >> of >> thing out :) >> google has a similar method, which I can't find today :( > webcrawler!!!> > > > dig -t txt o-o.myaddr.l.google.com That's cool, but still no IPv6. Cns# dig -t txt o-o.myaddr.l.google.com ; <<>> DiG 9.4.2-P2 <<>> -t txt o-o.myaddr.l.google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53188 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;o-o.myaddr.l.google.com. IN TXT ;; ANSWER SECTION: o-o.myaddr.l.google.com. 60 IN TXT "216.66.80.30" ;; Query time: 9 msec ;; SERVER: 2001:470:20::2#53(2001:470:20::2) ;; WHEN: Thu May 2 15:46:22 2013 ;; MSG SIZE rcvd: 66 Cns# From fergdawgster at gmail.com Thu May 2 22:54:21 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 2 May 2013 15:54:21 -0700 Subject: Louisiana Optical Network Initiative In-Reply-To: References: <759366B15C91B844B1122B305C967A2A6505D5EC@BY2PRD0612MB671.namprd06.prod.outlook.com> <759366B15C91B844B1122B305C967A2A6505E374@BY2PRD0612MB671.namprd06.prod.outlook.com> <2FFAD874-F004-457E-B63E-107A5DFE13EB@beatsmusic.com> Message-ID: Hang on -- University of New Orleans's AS is 23666? Looks like "SISTELINDO-AS-ID PT Sistelindo Mitralintas": http://www.cidr-report.org/cgi-bin/as-report?as=as23666 ? - ferg On Thu, May 2, 2013 at 3:22 PM, Paul Ferguson wrote: > John, > > Can you provide the prefixes in question off-list? > > Thanks, > > - ferg (not at Capital One, but can perhaps assist here) > > >> On May 2, 2013, at 10:35 AM, John D Caffery wrote: >> >>> I am sending this query on behalf of the University of New Orleans. For the past couple of weeks users on their campus are unable to get logged on to the Capital One Online Banking Secure Portal to do their online banking. The UNO AS number is 23666 and LONI, which I am part of, is their internet provider, AS number 32440. None of our other Louisiana Participants seem to have an issue getting there and every test I do from other locations in our network are successful. Users can get to the https://onlinebanking.capitalone.com site but after putting in their login credentials the site simply times out. >>> >>> Capital One peers with both Verizon and AT&T but when I go to the above site it is via Verizon. >>> >>> Does anyone know of or have this issue also? I have a ticket open with Verizon but have yet to get a response. I was speaking with a representative from Capital One but after leaving several voice mails I have yet to get a call back. >>> >>> Thank you in advance for anyone's assistance, >>> >>> John Caffery >>> Information Technology Consultant >>> Louisiana Optical Network Initiative - LONI >>> O 225.578.7263 >>> C 225.252.3046 >>> www.loni.org >>> >>> >> >> > > -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From Valdis.Kletnieks at vt.edu Thu May 2 23:07:15 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 02 May 2013 19:07:15 -0400 Subject: whoami.akamai.net [was: Google Public DNS Problems?] In-Reply-To: Your message of "Thu, 02 May 2013 15:48:08 -0700." References: <13658729.4872.1367509872682.JavaMail.root@benjamin.baylink.com> <8E4F462A-B098-4958-B190-EE76AFED452A@hopcount.ca> <734DD68C-4AF2-47E0-9966-C31DAC6E4BCD@hopcount.ca> <31BE8CEA-379B4F8A-A3AB-586970EEF248@hopcount.ca> Message-ID: <33098.1367536035@turing-police.cc.vt.edu> On Thu, 02 May 2013 15:48:08 -0700, "Constantine A. Murenin" said: > On 2 May 2013 15:41, Cameron Daniel wrote: > > dig -t txt o-o.myaddr.l.google.com > > That's cool, but still no IPv6. > o-o.myaddr.l.google.com. 60 IN TXT "216.66.80.30" You're complaining that there's no IPv6 data in a *descriptive TXT* record? Man, if that's the biggest IPv6 issue we have, we're on easy street. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From joelja at bogus.com Thu May 2 23:14:30 2013 From: joelja at bogus.com (joel jaeggli) Date: Thu, 02 May 2013 16:14:30 -0700 Subject: Louisiana Optical Network Initiative In-Reply-To: References: <759366B15C91B844B1122B305C967A2A6505D5EC@BY2PRD0612MB671.namprd06.prod.outlook.com> <759366B15C91B844B1122B305C967A2A6505E374@BY2PRD0612MB671.namprd06.prod.outlook.com> <2FFAD874-F004-457E-B63E-107A5DFE13EB@beatsmusic.com> Message-ID: <5182F356.5090008@bogus.com> On 5/2/13 3:54 PM, Paul Ferguson wrote: > Hang on -- University of New Orleans's AS is 23666? http://bgp.he.net/AS26333 > Looks like "SISTELINDO-AS-ID PT Sistelindo Mitralintas": > > http://www.cidr-report.org/cgi-bin/as-report?as=as23666 > > ? > > - ferg > > On Thu, May 2, 2013 at 3:22 PM, Paul Ferguson wrote: > >> John, >> >> Can you provide the prefixes in question off-list? >> >> Thanks, >> >> - ferg (not at Capital One, but can perhaps assist here) >> >> >>> On May 2, 2013, at 10:35 AM, John D Caffery wrote: >>> >>>> I am sending this query on behalf of the University of New Orleans. For the past couple of weeks users on their campus are unable to get logged on to the Capital One Online Banking Secure Portal to do their online banking. The UNO AS number is 23666 and LONI, which I am part of, is their internet provider, AS number 32440. None of our other Louisiana Participants seem to have an issue getting there and every test I do from other locations in our network are successful. Users can get to the https://onlinebanking.capitalone.com site but after putting in their login credentials the site simply times out. >>>> >>>> Capital One peers with both Verizon and AT&T but when I go to the above site it is via Verizon. >>>> >>>> Does anyone know of or have this issue also? I have a ticket open with Verizon but have yet to get a response. I was speaking with a representative from Capital One but after leaving several voice mails I have yet to get a call back. >>>> >>>> Thank you in advance for anyone's assistance, >>>> >>>> John Caffery >>>> Information Technology Consultant >>>> Louisiana Optical Network Initiative - LONI >>>> O 225.578.7263 >>>> C 225.252.3046 >>>> www.loni.org >>>> >>>> >>> >> > > -- > "Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > > From wbailey at satelliteintelligencegroup.com Thu May 2 23:27:01 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 2 May 2013 23:27:01 +0000 Subject: Louisiana Optical Network Initiative In-Reply-To: Message-ID: AS26333 Country: US Registration Date: 2002-08-22 Registrar: arin Owner: UNONET - University of New Orleans On 5/2/13 3:54 PM, "Paul Ferguson" wrote: >Hang on -- University of New Orleans's AS is 23666? > >Looks like "SISTELINDO-AS-ID PT Sistelindo Mitralintas": > >http://www.cidr-report.org/cgi-bin/as-report?as=as23666 > >? > >- ferg > >On Thu, May 2, 2013 at 3:22 PM, Paul Ferguson >wrote: > >> John, >> >> Can you provide the prefixes in question off-list? >> >> Thanks, >> >> - ferg (not at Capital One, but can perhaps assist here) >> >> >>> On May 2, 2013, at 10:35 AM, John D Caffery wrote: >>> >>>> I am sending this query on behalf of the University of New Orleans. >>>>For the past couple of weeks users on their campus are unable to get >>>>logged on to the Capital One Online Banking Secure Portal to do their >>>>online banking. The UNO AS number is 23666 and LONI, which I am part >>>>of, is their internet provider, AS number 32440. None of our other >>>>Louisiana Participants seem to have an issue getting there and every >>>>test I do from other locations in our network are successful. Users >>>>can get to the https://onlinebanking.capitalone.com site but after >>>>putting in their login credentials the site simply times out. >>>> >>>> Capital One peers with both Verizon and AT&T but when I go to the >>>>above site it is via Verizon. >>>> >>>> Does anyone know of or have this issue also? I have a ticket open >>>>with Verizon but have yet to get a response. I was speaking with a >>>>representative from Capital One but after leaving several voice mails >>>>I have yet to get a call back. >>>> >>>> Thank you in advance for anyone's assistance, >>>> >>>> John Caffery >>>> Information Technology Consultant >>>> Louisiana Optical Network Initiative - LONI >>>> O 225.578.7263 >>>> C 225.252.3046 >>>> www.loni.org >>>> >>>> >>> >>> >> >> > > >-- >"Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > > From davidianwalker at gmail.com Thu May 2 23:59:53 2013 From: davidianwalker at gmail.com (David Walker) Date: Fri, 3 May 2013 09:29:53 +0930 Subject: Louisiana Optical Network Initiative In-Reply-To: <759366B15C91B844B1122B305C967A2A6505E374@BY2PRD0612MB671.namprd06.prod.outlook.com> References: <759366B15C91B844B1122B305C967A2A6505D5EC@BY2PRD0612MB671.namprd06.prod.outlook.com> <759366B15C91B844B1122B305C967A2A6505E374@BY2PRD0612MB671.namprd06.prod.outlook.com> Message-ID: On 03/05/2013, John D Caffery wrote: > The UNO AS number is 23666 ... 26333 right? From fergdawgster at gmail.com Fri May 3 00:05:36 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 2 May 2013 17:05:36 -0700 Subject: Louisiana Optical Network Initiative In-Reply-To: References: <759366B15C91B844B1122B305C967A2A6505D5EC@BY2PRD0612MB671.namprd06.prod.outlook.com> <759366B15C91B844B1122B305C967A2A6505E374@BY2PRD0612MB671.namprd06.prod.outlook.com> Message-ID: In the original message, he said 23666.... - ferg On Thu, May 2, 2013 at 4:59 PM, David Walker wrote: > On 03/05/2013, John D Caffery wrote: >> The UNO AS number is 23666 ... > > 26333 right? > -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From wbailey at satelliteintelligencegroup.com Fri May 3 00:26:33 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 3 May 2013 00:26:33 +0000 Subject: Louisiana Optical Network Initiative In-Reply-To: References: <759366B15C91B844B1122B305C967A2A6505D5EC@BY2PRD0612MB671.namprd06.prod.outlook.com> <759366B15C91B844B1122B305C967A2A6505E374@BY2PRD0612MB671.namprd06.prod.outlook.com> , Message-ID: I'm not even cool enough to have an As number, so I'll be in my hole if anyone needs me.. ;) Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Paul Ferguson Date: 05/02/2013 5:08 PM (GMT-08:00) To: David Walker Cc: nanog at nanog.org Subject: Re: Louisiana Optical Network Initiative In the original message, he said 23666.... - ferg On Thu, May 2, 2013 at 4:59 PM, David Walker wrote: > On 03/05/2013, John D Caffery wrote: >> The UNO AS number is 23666 ... > > 26333 right? > -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From Valdis.Kletnieks at vt.edu Fri May 3 02:45:10 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 02 May 2013 22:45:10 -0400 Subject: Louisiana Optical Network Initiative In-Reply-To: Your message of "Thu, 02 May 2013 17:05:36 -0700." References: <759366B15C91B844B1122B305C967A2A6505D5EC@BY2PRD0612MB671.namprd06.prod.outlook.com> <759366B15C91B844B1122B305C967A2A6505E374@BY2PRD0612MB671.namprd06.prod.outlook.com> Message-ID: <64386.1367549110@turing-police.cc.vt.edu> On Thu, 02 May 2013 17:05:36 -0700, Paul Ferguson said: > In the original message, he said 23666.... But 'whois as23666' points at Indonesia, not Louisiana, so I suspect some transcription errors have crept into the process... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From fergdawgster at gmail.com Fri May 3 02:46:26 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 2 May 2013 19:46:26 -0700 Subject: Louisiana Optical Network Initiative In-Reply-To: <64386.1367549110@turing-police.cc.vt.edu> References: <759366B15C91B844B1122B305C967A2A6505D5EC@BY2PRD0612MB671.namprd06.prod.outlook.com> <759366B15C91B844B1122B305C967A2A6505E374@BY2PRD0612MB671.namprd06.prod.outlook.com> <64386.1367549110@turing-police.cc.vt.edu> Message-ID: Ya think? :-) - ferg On Thu, May 2, 2013 at 7:45 PM, wrote: > On Thu, 02 May 2013 17:05:36 -0700, Paul Ferguson said: >> In the original message, he said 23666.... > > But 'whois as23666' points at Indonesia, not Louisiana, so I suspect > some transcription errors have crept into the process... > -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From israel.lugo at lugosys.com Fri May 3 09:30:32 2013 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Fri, 03 May 2013 10:30:32 +0100 Subject: Problem reaching Wikipedia (AS43821) via Tele2 In-Reply-To: <791AB073-4ACB-47C2-A864-1B63338CBF03@gmail.com> References: <518271CE.7010002@lugosys.com> <791AB073-4ACB-47C2-A864-1B63338CBF03@gmail.com> Message-ID: <518383B8.6060302@lugosys.com> Indeed, although I wouldn't know why. The problem lasted the whole day yesterday, but it seems to be gone now. I was given the tech contact for Wikimedia off-list; if anything rises up again I'll get in touch with them. Thank you for the reply, and also to everyone who replied off-list. Regards, Israel G. Lugo On 05/02/2013 07:08 PM, Grant Ridder wrote: > Looks like ge-2-5.br1-knams.wikimedia.org (130.244.6.250) is filtering you somehow. > > Grant > > Sent from my iPhone > > On May 2, 2013, at 9:01 AM, "Israel G. Lugo" wrote: > >> Hello, >> >> Anyone else having problems reaching Wikipedia? >> >> I can't reach AS43821 (Wikimedia RIPE) from within the Portuguese NREN >> (AS1930), via Cogent (AS174) -> Tele2 (AS1257): >> >> traceroute to en.wikipedia.org (91.198.174.225), 30 hops max, 60 byte >> packets >> 1 Router3.10GE.Lisboa.fccn.pt (193.136.1.89) [AS1930] 0.953 ms >> 2 ROUTER10.10GE.Lisboa.fccn.pt (193.137.0.8) [AS1930] 0.939 ms >> 3 ROUTER4.10GE.Lisboa.fccn.pt (193.137.0.20) [AS1930] 1.000 ms >> 4 fccn.mx2.lis.pt.geant.net (62.40.124.97) [AS20965] 1.000 ms >> 5 xe-2-3-0.rt1.mad.es.geant.net (62.40.98.107) [AS20965] 13.926 ms >> 6 as2.rt1.gen.ch.geant2.net (62.40.112.25) [AS20965] 37.882 ms >> 7 ae3.mx1.gen.ch.geant.net (62.40.112.14) [AS20965] 37.874 ms >> 8 ae1.mx1.fra.de.geant.net (62.40.98.109) [AS20965] 44.154 ms >> 9 ae4.rt1.fra.de.geant.net (62.40.98.135) [AS20965] 43.935 ms >> 10 te0-4-0-2.mag21.fra03.atlas.cogentco.com (149.6.42.73) [AS174] >> 44.842 ms >> 11 fra36-peer-1.xe-1-2-0-unit0.tele2.net (130.244.200.41) [AS1257] >> 44.368 ms >> 12 fra36-core-1.bundle-ether2.tele2.net (130.244.64.186) [AS1257] >> 44.977 ms >> 13 * >> 14 ams13-peer-1.ae0-unit0.tele2.net (130.244.53.123) [AS1257] 50.299 ms >> 15 * >> 16 * >> 17 * >> 18 * >> 19 * >> 20 * >> >> Tele2's traceroute server (http://services.tele2net.at/traceroute.html) >> reaches the same IP without problems: >> >> 1 213.90.34.4 (213.90.34.4) 0.268 ms 0.124 ms 0.151 ms >> 2 213.90.1.20 (213.90.1.20) 0.430 ms 0.382 ms 0.303 ms >> 3 wat1-15-93.net.uta.at (62.218.15.93) 0.497 ms 0.368 ms 0.387 ms >> 4 c76wmode1-tengigE4-1.net.uta.at (212.152.192.206) 0.644 ms 0.572 ms >> 0.599 ms >> 5 wen1-core-2.tengige0-0-1-1.tele2.net (130.244.205.57) 0.836 ms 0.874 >> ms 0.737 ms >> 6 fra36-core-1.bundle-ether7.tele2.net (130.244.206.28) 13.683 ms 13.472 >> ms 13.817 ms >> 7 ams-core-2.bundle-ether4.tele2.net (130.244.64.201) 20.421 ms 20.482 >> ms 20.762 ms >> 8 ams13-peer-1.ae0-unit0.tele2.net (130.244.53.123) 19.972 ms 19.936 ms >> 19.962 ms >> 9 ge-2-5.br1-knams.wikimedia.org (130.244.6.250) 20.727 ms 20.641 ms >> 20.660 ms >> 10 wikipedia-lb.esams.wikimedia.org (91.198.174.225) 20.610 ms 20.539 ms >> 20.615 ms >> >> Trying from $HOME_ISP, via AS6453 (Globe) -> AS1299 (Telia) works fine. >> >> Regards, >> Israel G. Lugo >> >> From jcaffery at lsu.edu Fri May 3 11:49:49 2013 From: jcaffery at lsu.edu (John D Caffery) Date: Fri, 3 May 2013 11:49:49 +0000 Subject: Louisiana Optical Network Initiative In-Reply-To: References: <759366B15C91B844B1122B305C967A2A6505D5EC@BY2PRD0612MB671.namprd06.prod.outlook.com> <759366B15C91B844B1122B305C967A2A6505E374@BY2PRD0612MB671.namprd06.prod.outlook.com> <64386.1367549110@turing-police.cc.vt.edu>, Message-ID: Sorry guys, the as is 26333. So sorry for the incorrect information. John Caffery 255.252.3046 Jcaffery at lsu.edu Sent with my IPhone On May 2, 2013, at 9:49 PM, "Paul Ferguson" wrote: > Ya think? :-) > > - ferg > > On Thu, May 2, 2013 at 7:45 PM, wrote: > >> On Thu, 02 May 2013 17:05:36 -0700, Paul Ferguson said: >>> In the original message, he said 23666.... >> >> But 'whois as23666' points at Indonesia, not Louisiana, so I suspect >> some transcription errors have crept into the process... > > > > -- > "Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > > From kiwi at oav.net Fri May 3 17:49:20 2013 From: kiwi at oav.net (Xavier Beaudouin) Date: Fri, 3 May 2013 19:49:20 +0200 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) Message-ID: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> Hello there, Seems there is some people in Ukraine that love to use IP and AS that doesn't belong to them. See : #sh ip bgp 91.220.85.0/24 BGP routing table entry for 91.220.85.0/24, version 6661169 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 174 8359 8359 13249 57954 42989 51888, (received & used) 149.11.xx.xx from 149.11.xxx.xxx (38.28.xx.xx) Origin IGP, metric 14050, localpref 100, valid, external, best Community: 11424365 11425269 24990 21371 8359 13249 57954 42989 51888, (received & used) 185.3.25.1 (metric 10) from 185.17.xxx.xxx (185.17.xxx.xxx) Origin IGP, metric 0, localpref 100, valid, internal, not synchronized According to RIPE database : aut-num: AS51888 as-name: PILOTSYSTEMS-AS descr: Pilot Systems consulting SARL org: ORG-PS74-RIPE import: from AS16128 accept ANY import: from AS29075 accept ANY import: from AS35189 accept ANY export: to AS16128 announce AS51888 export: to AS29075 announce AS51888 export: to AS35189 announce AS51888 admin-c: DS7922-RIPE tech-c: GLM89-RIPE tech-c: XB80-RIPE mnt-by: RIPE-NCC-END-MNT mnt-by: MNT-KAZAR mnt-by: MNT-PILOTSYSTEMS mnt-routes: MNT-KAZAR mnt-routes: MNT-PILOTSYSTEMS source: RIPE #Filtered Seems that there is no AS42989 as upstream.... So we can consider that AS42989 is handle illicit activities, and does not filter prefixes (same also for AS57954). That's cool but those people in UA, use that prefix to send spam, as LIR member I got thousands of mails from people that get thoses IP as spam source. Needs really that rpki and other stuff to be deployed massively. If some people from those UA AS can do their job instead of getting the honeypot of spammers, this should be better for everyone. I have already tried to contact abuse / email from ripe data base : no MX, mailbox doesn't exist, even the domain doesn't exist... Maybe AS-MTU doesn't lookaround the quality of their customers ? So bad... People there that have some PI and unused AS, have a look if your ressources are not used by someone that should not use them. Xavier From nick at foobar.org Fri May 3 18:01:24 2013 From: nick at foobar.org (Nick Hilliard) Date: Fri, 03 May 2013 19:01:24 +0100 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> Message-ID: <5183FB74.4090501@foobar.org> On 03/05/2013 18:49, Xavier Beaudouin wrote: > People there that have some PI and unused AS, have a look if your > ressources are not used by someone that should not use them. ripe policy 2007-01 will help with this problem by ensuring that anyone who has got PI address space will be traceable and will be paying for it (i.e. it will appear on the holder's payment radar). RPKI could potentially help with this problem, but only if unknown and invalid prefixes are dropped by policy (to deal with the cases where the there are no ROAs or else there are ROAs but they are e.g. revoked). If they are simply depreffed, rpki will not help. It will be a brave person who drops both unknown and invalid prefixes. Nick From morrowc.lists at gmail.com Fri May 3 18:07:33 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 3 May 2013 14:07:33 -0400 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> Message-ID: On Fri, May 3, 2013 at 1:49 PM, Xavier Beaudouin wrote: > Hello there, > > I'm not sure I'd have lead with 'illegal', certainly 'not friendly' fits though :( also, I'm so glad we're doing well with: 1) provider filters 2) verification of address/number-holder validity 3) route origin authorization > Needs really that rpki and other stuff to be deployed massively. > > I agree, thanks for the up vote! (or do we call them 'likes' these days?) good luck in your quest to have this squelched. -chris From morrowc.lists at gmail.com Fri May 3 18:08:30 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 3 May 2013 14:08:30 -0400 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: <5183FB74.4090501@foobar.org> References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> Message-ID: On Fri, May 3, 2013 at 2:01 PM, Nick Hilliard wrote: > It will be a brave person who drops both unknown and invalid prefixes. > hopefully it won't involve people being brave :) hopefully good measurement and metrics lead us to a position where things 'just work' and we can do it with confidence! :) From nick at foobar.org Fri May 3 18:21:04 2013 From: nick at foobar.org (Nick Hilliard) Date: Fri, 03 May 2013 19:21:04 +0100 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> Message-ID: <51840010.4050006@foobar.org> On 03/05/2013 19:08, Christopher Morrow wrote: > hopefully it won't involve people being brave :) hopefully good measurement > and metrics lead us to a position where things 'just work' and we can do it > with confidence! :) dropping prefixes means that you're ok about not having reachability to a prefix if its roa pops up as "unknown". This could be because the prefix holder hasn't bothered to register their prefix in the rpki (i.e. sloppiness), or it could be because the ROA has been revoked for some reason (e.g. because of hijacking). For sure, a router can't tell the difference. >From a deployment point of view, there's a pretty big gap between poking around with rpki and actually dropping prefixes on your routers. I don't see that the rpki data will be good enough for the latter any time soon, but maybe one day. Nick From cscora at apnic.net Fri May 3 18:33:43 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 May 2013 04:33:43 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201305031833.r43IXhwq022111@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 04 May, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 453510 Prefixes after maximum aggregation: 185040 Deaggregation factor: 2.45 Unique aggregates announced to Internet: 223585 Total ASes present in the Internet Routing Table: 44001 Prefixes per ASN: 10.31 Origin-only ASes present in the Internet Routing Table: 34568 Origin ASes announcing only one prefix: 16101 Transit ASes present in the Internet Routing Table: 5821 Transit-only ASes present in the Internet Routing Table: 148 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 30 Max AS path prepend of ASN ( 19037) 22 Prefixes from unregistered ASNs in the Routing Table: 317 Unregistered ASNs in the Routing Table: 133 Number of 32-bit ASNs allocated by the RIRs: 4753 Number of 32-bit ASNs visible in the Routing Table: 3612 Prefixes from 32-bit ASNs in the Routing Table: 10306 Special use prefixes present in the Routing Table: 22 Prefixes being announced from unallocated address space: 192 Number of addresses announced to Internet: 2616629196 Equivalent to 155 /8s, 246 /16s and 151 /24s Percentage of available address space announced: 70.7 Percentage of allocated address space announced: 70.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.4 Total number of prefixes smaller than registry allocations: 160134 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 108607 Total APNIC prefixes after maximum aggregation: 33426 APNIC Deaggregation factor: 3.25 Prefixes being announced from the APNIC address blocks: 109908 Unique aggregates announced from the APNIC address blocks: 44627 APNIC Region origin ASes present in the Internet Routing Table: 4840 APNIC Prefixes per ASN: 22.71 APNIC Region origin ASes announcing only one prefix: 1228 APNIC Region transit ASes present in the Internet Routing Table: 818 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 516 Number of APNIC addresses announced to Internet: 720862688 Equivalent to 42 /8s, 247 /16s and 125 /24s Percentage of available APNIC address space announced: 84.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, 131072-133119 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: 159060 Total ARIN prefixes after maximum aggregation: 80079 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 159679 Unique aggregates announced from the ARIN address blocks: 73184 ARIN Region origin ASes present in the Internet Routing Table: 15672 ARIN Prefixes per ASN: 10.19 ARIN Region origin ASes announcing only one prefix: 5962 ARIN Region transit ASes present in the Internet Routing Table: 1622 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 18 Number of ARIN addresses announced to Internet: 1063469184 Equivalent to 63 /8s, 99 /16s and 64 /24s Percentage of available ARIN address space announced: 56.3 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, 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: 116889 Total RIPE prefixes after maximum aggregation: 59658 RIPE Deaggregation factor: 1.96 Prefixes being announced from the RIPE address blocks: 120453 Unique aggregates announced from the RIPE address blocks: 77565 RIPE Region origin ASes present in the Internet Routing Table: 17160 RIPE Prefixes per ASN: 7.02 RIPE Region origin ASes announcing only one prefix: 8154 RIPE Region transit ASes present in the Internet Routing Table: 2801 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2313 Number of RIPE addresses announced to Internet: 657143652 Equivalent to 39 /8s, 43 /16s and 55 /24s Percentage of available RIPE address space announced: 95.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, 196608-199679 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: 47736 Total LACNIC prefixes after maximum aggregation: 9316 LACNIC Deaggregation factor: 5.12 Prefixes being announced from the LACNIC address blocks: 51868 Unique aggregates announced from the LACNIC address blocks: 24181 LACNIC Region origin ASes present in the Internet Routing Table: 1915 LACNIC Prefixes per ASN: 27.09 LACNIC Region origin ASes announcing only one prefix: 566 LACNIC Region transit ASes present in the Internet Routing Table: 354 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 759 Number of LACNIC addresses announced to Internet: 128404232 Equivalent to 7 /8s, 167 /16s and 75 /24s Percentage of available LACNIC address space announced: 76.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-62463, 262144-263167 plus 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: 10828 Total AfriNIC prefixes after maximum aggregation: 2521 AfriNIC Deaggregation factor: 4.30 Prefixes being announced from the AfriNIC address blocks: 11410 Unique aggregates announced from the AfriNIC address blocks: 3851 AfriNIC Region origin ASes present in the Internet Routing Table: 627 AfriNIC Prefixes per ASN: 18.20 AfriNIC Region origin ASes announcing only one prefix: 191 AfriNIC Region transit ASes present in the Internet Routing Table: 135 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46413568 Equivalent to 2 /8s, 196 /16s and 55 /24s Percentage of available AfriNIC address space announced: 46.1 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 2943 11557 920 Korea Telecom (KIX) 17974 2512 839 90 PT TELEKOMUNIKASI INDONESIA 7545 1897 320 109 TPG Internet Pty Ltd 4755 1726 390 190 TATA Communications formerly 9829 1508 1205 40 BSNL National Internet Backbo 9583 1285 98 533 Sify Limited 7552 1175 1064 12 Vietel Corporation 4808 1118 2113 328 CNCGROUP IP network: China169 9498 1098 310 73 BHARTI Airtel Ltd. 24560 1072 393 167 Bharti Airtel Ltd., Telemedia 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 3022 3693 84 bellsouth.net, inc. 7029 2144 1265 211 Windstream Communications Inc 18566 2067 382 184 Covad Communications 1785 1992 677 125 PaeTec Communications, Inc. 22773 1971 2929 125 Cox Communications, Inc. 20115 1670 1610 613 Charter Communications 4323 1608 1139 399 Time Warner Telecom 30036 1335 297 653 Mediacom Communications Corp 7018 1313 10821 849 AT&T WorldNet Services 11492 1240 228 330 Cable One 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 8402 1753 544 16 Corbina telecom 2118 1390 97 13 EUnet/RELCOM Autonomous Syste 34984 1173 237 215 BILISIM TELEKOM 12479 840 785 66 Uni2 Autonomous System 13188 834 99 64 Educational Network 20940 832 291 657 Akamai Technologies European 31148 794 41 21 FreeNet ISP 6830 770 2376 443 UPC Distribution Services 8551 753 369 50 Bezeq International 34744 672 180 53 SC GVM SISTEM 2003 SRL 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 28573 2688 1470 108 NET Servicos de Comunicao S.A 10620 2617 410 222 TVCABLE BOGOTA 7303 1689 1157 219 Telecom Argentina Stet-France 8151 1239 2700 391 UniNet S.A. de C.V. 6503 1014 435 68 AVANTEL, S.A. 18881 914 780 19 Global Village Telecom 27947 817 88 95 Telconet S.A 11830 716 364 14 Instituto Costarricense de El 7738 698 1370 35 Telecomunicacoes da Bahia S.A 3816 697 306 85 Empresa Nacional de Telecomun 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 36998 1237 80 4 MOBITEL 24863 887 274 34 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 458 956 9 TEDATA 24835 344 80 8 RAYA Telecom - Egypt 3741 262 906 220 The Internet Solution 15706 222 32 6 Sudatel Internet Exchange Aut 12258 193 28 67 Vodacom Internet Company 29975 191 667 21 Vodacom 36992 189 527 21 Etisalat MISR 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 6389 3022 3693 84 bellsouth.net, inc. 4766 2943 11557 920 Korea Telecom (KIX) 28573 2688 1470 108 NET Servicos de Comunicao S.A 10620 2617 410 222 TVCABLE BOGOTA 17974 2512 839 90 PT TELEKOMUNIKASI INDONESIA 7029 2144 1265 211 Windstream Communications Inc 18566 2067 382 184 Covad Communications 1785 1992 677 125 PaeTec Communications, Inc. 22773 1971 2929 125 Cox Communications, Inc. 7545 1897 320 109 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 28573 2688 2580 NET Servicos de Comunicao S.A 17974 2512 2422 PT TELEKOMUNIKASI INDONESIA 10620 2617 2395 TVCABLE BOGOTA 4766 2943 2023 Korea Telecom (KIX) 7029 2144 1933 Windstream Communications Inc 18566 2067 1883 Covad Communications 1785 1992 1867 PaeTec Communications, Inc. 22773 1971 1846 Cox Communications, Inc. 7545 1897 1788 TPG Internet Pty Ltd 8402 1753 1737 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.52.0/24 60906 NETOPIA SRL 128.0.58.0/23 9050 RTD-ROMTELECOM Autonomous Sys 128.0.60.0/24 9050 RTD-ROMTELECOM Autonomous Sys 128.0.61.0/24 9050 RTD-ROMTELECOM Autonomous Sys 128.0.62.0/24 9050 RTD-ROMTELECOM Autonomous Sys 128.0.63.0/24 9050 RTD-ROMTELECOM Autonomous Sys 128.0.72.0/21 23456 32-bit ASN transition Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.222.80.0/21 37110 Moztel LDA 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. 64.185.230.0/24 27431 JTL Networks Inc. 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:13 /10:29 /11:87 /12:250 /13:491 /14:887 /15:1567 /16:12692 /17:6631 /18:11109 /19:22112 /20:31995 /21:34054 /22:47248 /23:42085 /24:238107 /25:1366 /26:1757 /27:868 /28:43 /29:67 /30:18 /31:0 /32:18 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2018 2067 Covad Communications 6389 1729 3022 bellsouth.net, inc. 7029 1606 2144 Windstream Communications Inc 8402 1457 1753 Corbina telecom 22773 1281 1971 Cox Communications, Inc. 36998 1231 1237 MOBITEL 30036 1208 1335 Mediacom Communications Corp 11492 1199 1240 Cable One 1785 1061 1992 PaeTec Communications, Inc. 6983 1007 1133 ITC^Deltacom Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:782 2:747 3:3 4:15 5:880 6:7 8:552 12:1919 13:3 14:777 15:11 16:3 17:9 20:18 23:274 24:1762 27:1503 31:1272 32:43 33:2 34:5 36:44 37:1818 38:869 39:2 40:172 41:2794 42:187 44:6 46:1888 47:2 49:630 50:684 52:12 54:32 55:8 57:26 58:1139 59:568 60:306 61:1391 62:1061 63:2040 64:4324 65:2173 66:4319 67:2051 68:1129 69:3250 70:873 71:536 72:1943 74:2548 75:410 76:292 77:1108 78:1052 79:581 80:1264 81:979 82:623 83:557 84:526 85:1167 86:462 87:979 88:539 89:1791 90:280 91:5497 92:633 93:1724 94:1855 95:1522 96:526 97:342 98:1051 99:41 100:30 101:320 103:2533 105:535 106:144 107:209 108:519 109:1842 110:871 111:1050 112:509 113:784 114:705 115:934 116:897 117:790 118:1056 119:1261 120:402 121:721 122:1771 123:1234 124:1351 125:1338 128:632 129:223 130:323 131:649 132:339 133:149 134:253 135:66 136:222 137:250 138:346 139:196 140:207 141:323 142:549 143:382 144:493 145:92 146:508 147:390 148:691 149:371 150:158 151:569 152:414 153:195 154:43 155:401 156:265 157:402 158:276 159:726 160:339 161:421 162:414 163:212 164:591 165:448 166:304 167:582 168:1027 169:133 170:1029 171:178 172:4 173:1604 174:586 175:464 176:1281 177:1949 178:1839 179:5 180:1411 181:420 182:1147 183:384 184:674 185:408 186:2322 187:1304 188:2045 189:1358 190:6319 192:6569 193:5842 194:4667 195:3456 196:1339 197:906 198:4409 199:5292 200:5928 201:2408 202:8844 203:8819 204:4515 205:2565 206:2835 207:2883 208:4055 209:3611 210:2942 211:1552 212:2063 213:1914 214:911 215:98 216:5250 217:1568 218:618 219:331 220:1276 221:555 222:319 223:443 End of report From pnowak at batblue.com Fri May 3 18:48:29 2013 From: pnowak at batblue.com (Peter Nowak) Date: Fri, 3 May 2013 14:48:29 -0400 Subject: Bermuda connectivity Message-ID: <692B615A-74A7-45FC-A411-5F01AC91AC1A@batblue.com> Hello, I'm looking for a carrier to provide connectivity between New York (111 8th or 60 Hudson) and Bermuda. Can someone point me in the right direction? Thanks Peter From jra at baylink.com Fri May 3 19:06:31 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 3 May 2013 15:06:31 -0400 (EDT) Subject: HTTPS-everywhere vs. proxy caching In-Reply-To: <20397199.4926.1367607836997.JavaMail.root@benjamin.baylink.com> Message-ID: <26650528.4928.1367607990956.JavaMail.root@benjamin.baylink.com> It occurs to me that I don't believe I've seen any discussion of the Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated sessions, like non-logged-in users browsing sites like Wikipedia. That traffic's not cacheable, is it? Proxy caches on services like mobile 3/4G, or smaller ISPs, or larger corporations can't cache it, I wouldn't think, which means both that they will see traffic increases, and that the end sites will as well. Has this been discussed and I missed it? Do I improperly understand transparent caching? Or is this just a bomb waiting to go off? I assume that Wikipedia themselves are on top of the idea that their in-house reverse-proxies won't be carrying that traffic (though I don't actually know what their architecture looks like anymore), but.. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From lathama at gmail.com Fri May 3 19:13:33 2013 From: lathama at gmail.com (Andrew Latham) Date: Fri, 3 May 2013 15:13:33 -0400 Subject: HTTPS-everywhere vs. proxy caching In-Reply-To: <26650528.4928.1367607990956.JavaMail.root@benjamin.baylink.com> References: <20397199.4926.1367607836997.JavaMail.root@benjamin.baylink.com> <26650528.4928.1367607990956.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, May 3, 2013 at 3:06 PM, Jay Ashworth wrote: > It occurs to me that I don't believe I've seen any discussion of the > Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated > sessions, like non-logged-in users browsing sites like Wikipedia. > > That traffic's not cacheable, is it? Proxy caches on services like > mobile 3/4G, or smaller ISPs, or larger corporations can't cache it, I > wouldn't think, which means both that they will see traffic increases, > and that the end sites will as well. > > Has this been discussed and I missed it? Do I improperly understand > transparent caching? Or is this just a bomb waiting to go off? > > I assume that Wikipedia themselves are on top of the idea that their > in-house reverse-proxies won't be carrying that traffic (though I don't > actually know what their architecture looks like anymore), but.. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 TLS/SSL can be applied at the loadbalancer/caching proxy for service providers like Wikipedia. As you may already know products like Apple's IPhone include CA that can allow groups like the DOD to do chain-loading to allow their proxies to be MITM systems(super scary, in more systems than the one mentioned.). Yes it is a bomb but only from the ISP caching point of view, not the provider caching point of view. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From wmf at felter.org Fri May 3 19:33:02 2013 From: wmf at felter.org (Wes Felter) Date: Fri, 03 May 2013 14:33:02 -0500 Subject: HTTPS-everywhere vs. proxy caching In-Reply-To: <26650528.4928.1367607990956.JavaMail.root@benjamin.baylink.com> References: <20397199.4926.1367607836997.JavaMail.root@benjamin.baylink.com> <26650528.4928.1367607990956.JavaMail.root@benjamin.baylink.com> Message-ID: On 5/3/13 2:06 PM, Jay Ashworth wrote: > It occurs to me that I don't believe I've seen any discussion of the > Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated > sessions, like non-logged-in users browsing sites like Wikipedia. > > That traffic's not cacheable, is it? This has been discussed over the last year in the IETF HTTP WG in the context of SPDY and HTTP 2.0. Today this traffic is not cacheable. Some people are proposing to have a mode that is end-to-end secure and shows the lock icon in the browser and a different mode that uses SSL to the cache and SSL from the cache to the origin and doesn't show a lock. For networks that have traffic inspection "requirements" (e.g. education/enterprise) there has also been discussion about a signaling protocol for the network to indicate to browsers that all non-proxied traffic will be dropped. Transparent proxies are evil and one of the goals of HTTP 2.0 is to make proxies visible to the browser/user so they can choose whether to consent to having their traffic proxied. -- Wes Felter From rlb at ipv.sx Fri May 3 19:58:00 2013 From: rlb at ipv.sx (Richard Barnes) Date: Fri, 3 May 2013 15:58:00 -0400 Subject: HTTPS-everywhere vs. proxy caching In-Reply-To: References: <20397199.4926.1367607836997.JavaMail.root@benjamin.baylink.com> <26650528.4928.1367607990956.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, May 3, 2013 at 3:33 PM, Wes Felter wrote: > On 5/3/13 2:06 PM, Jay Ashworth wrote: > >> It occurs to me that I don't believe I've seen any discussion of the >> Unexpected Consequence of pervasive HTTPS replacing HTTP for >> unauthenticated >> sessions, like non-logged-in users browsing sites like Wikipedia. >> >> That traffic's not cacheable, is it? >> > > This has been discussed over the last year in the IETF HTTP WG in the > context of SPDY and HTTP 2.0. Today this traffic is not cacheable. Some > people are proposing to have a mode that is end-to-end secure and shows the > lock icon in the browser and a different mode that uses SSL to the cache > and SSL from the cache to the origin and doesn't show a lock. > For networks that have traffic inspection "requirements" (e.g. > education/enterprise) there has also been discussion about a signaling > protocol for the network to indicate to browsers that all non-proxied > traffic will be dropped. Transparent proxies are evil and one of the goals > of HTTP 2.0 is to make proxies visible to the browser/user so they can > choose whether to consent to having their traffic proxied. > > -- > Wes Felter > Thanks for the summary, Wes. If operators have thoughts on this issue, there is still discussion going on about HTTP/2.0. As Wes notes, HTTP/2.0 is going to have a strong emphasis on TLS, as with SPDY. Please send comments to the WG mailing list: Cheers, --Richard From morrowc.lists at gmail.com Fri May 3 21:42:08 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 3 May 2013 17:42:08 -0400 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: <51840010.4050006@foobar.org> References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> <51840010.4050006@foobar.org> Message-ID: On Fri, May 3, 2013 at 2:21 PM, Nick Hilliard wrote: > On 03/05/2013 19:08, Christopher Morrow wrote: > > hopefully it won't involve people being brave :) hopefully good > measurement > > and metrics lead us to a position where things 'just work' and we can do > it > > with confidence! :) > > dropping prefixes means that you're ok about not having reachability to a > prefix if its roa pops up as "unknown". This could be because the prefix > holder hasn't bothered to register their prefix in the rpki (i.e. > sloppiness), or it could be because the ROA has been revoked for some > reason (e.g. because of hijacking). For sure, a router can't tell the > difference. > > right, in the ideal tomorrow-tomorrow-land ... this all is part of turnup and the timelines associated with propogation/etc are all known and accounted for. Additionally, the systems involved are all well understood and redundant/resilient/etc. in short, in the tomorrow-tomorrow-land... this all just works as we expect/want, and the only 'unknown' are actually 'invalid'. > From a deployment point of view, there's a pretty big gap between poking > around with rpki and actually dropping prefixes on your routers. I don't > see that the rpki dat a will be good enough for the latter any time soon, > but maybe one day. > > right, no problem with this. > Nick > > From cidr-report at potaroo.net Fri May 3 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 May 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201305032200.r43M00bF076327@wattle.apnic.net> This report has been generated at Fri May 3 21:13:19 2013 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 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 26-04-13 453190 259754 27-04-13 454713 259757 28-04-13 454581 259704 29-04-13 454614 260166 30-04-13 455153 260246 01-05-13 455330 259820 02-05-13 455481 259731 03-05-13 455147 259785 AS Summary 44103 Number of ASes in routing system 18264 Number of ASes announcing only one prefix 3022 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 117115616 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 03May13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 455694 259723 195971 43.0% All ASes AS6389 3022 88 2934 97.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4766 2943 936 2007 68.2% KIXS-AS-KR Korea Telecom AS28573 2684 727 1957 72.9% NET Servi?os de Comunica??o S.A. AS17974 2512 571 1941 77.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS10620 2618 705 1913 73.1% Telmex Colombia S.A. AS22773 1971 130 1841 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2067 473 1594 77.1% COVAD - Covad Communications Co. AS2118 1390 65 1325 95.3% RELCOM-AS OOO "NPO Relcom" AS7303 1689 457 1232 72.9% Telecom Argentina S.A. AS4323 1611 402 1209 75.0% TWTC - tw telecom holdings, inc. AS4755 1726 628 1098 63.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1175 167 1008 85.8% VIETEL-AS-AP Vietel Corporation AS36998 1237 301 936 75.7% SDN-MOBITEL AS7029 2144 1234 910 42.4% WINDSTREAM - Windstream Communications Inc AS18881 914 23 891 97.5% Global Village Telecom AS18101 1003 179 824 82.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS1785 1992 1240 752 37.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1118 370 748 66.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 846 130 716 84.6% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 736 54 682 92.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS8151 1247 584 663 53.2% Uninet S.A. de C.V. AS6983 1133 479 654 57.7% ITCDELTA - ITC^Deltacom AS22561 1146 496 650 56.7% DIGITAL-TELEPORT - Digital Teleport Inc. AS24560 1072 433 639 59.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 734 111 623 84.9% GIGAINFRA Softbank BB Corp. AS3549 1056 442 614 58.1% GBLX Global Crossing Ltd. AS34744 672 69 603 89.7% GVM S.C. GVM SISTEM 2003 S.R.L. AS3356 1083 495 588 54.3% LEVEL3 Level 3 Communications AS9808 807 220 587 72.7% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS19262 995 410 585 58.8% VZGNI-TRANSIT - Verizon Online LLC Total 45343 12619 32724 72.2% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.197.36.0/22 AS43359 100.64.1.0/24 AS17338 NIS - Network Integration Services, Inc. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 164.138.97.0/24 AS58101 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.52.192.0/24 AS27919 190.52.193.0/24 AS27919 190.52.194.0/24 AS27919 190.52.195.0/24 AS27919 190.52.196.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.197.0/24 AS27919 190.52.198.0/24 AS27919 190.52.199.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.200.0/24 AS27947 Telconet S.A 190.52.201.0/24 AS27947 Telconet S.A 190.52.202.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.203.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.205.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.206.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.207.0/24 AS3549 GBLX Global Crossing Ltd. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS22011 Metro Net, S.A.P.I. de C.V. 200.58.248.0/21 AS27849 200.107.248.0/24 AS27919 200.107.249.0/24 AS27919 200.107.250.0/24 AS27919 200.107.251.0/24 AS27919 200.107.252.0/24 AS28006 CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 201.71.16.0/20 AS28638 201.77.96.0/20 AS28639 201.222.32.0/20 AS27821 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 May 3 22:00:02 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 May 2013 22:00:02 GMT Subject: BGP Update Report Message-ID: <201305032200.r43M029D076350@wattle.apnic.net> BGP Update Report Interval: 25-Apr-13 -to- 02-May-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS58113 64482 2.7% 96.8 -- LIR-AS LIR DATACENTER TELECOM SRL 2 - AS9829 45721 1.9% 32.1 -- BSNL-NIB National Internet Backbone 3 - AS8402 43693 1.9% 26.1 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS36998 41515 1.8% 32.3 -- SDN-MOBITEL 5 - AS3909 22266 0.9% 674.7 -- QWEST-AS-3908 - Qwest Communications Company, LLC 6 - AS28573 20827 0.9% 7.6 -- NET Servi?os de Comunica??o S.A. 7 - AS4538 19817 0.8% 38.0 -- ERX-CERNET-BKB China Education and Research Network Center 8 - AS7552 19114 0.8% 16.4 -- VIETEL-AS-AP Vietel Corporation 9 - AS18403 15960 0.7% 32.7 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 10 - AS14287 15909 0.7% 252.5 -- TRIAD-TELECOM - Triad Telecom, Inc. 11 - AS9416 15620 0.7% 2231.4 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 12 - AS5400 14893 0.6% 141.8 -- BT British Telecommunications plc 13 - AS29049 14634 0.6% 43.3 -- DELTA-TELECOM-AS Delta Telecom LTD. 14 - AS10620 14136 0.6% 5.7 -- Telmex Colombia S.A. 15 - AS38868 13835 0.6% 3458.8 -- UPM-AS-AP Universiti Putra Malaysia AS 16 - AS22216 13247 0.6% 254.8 -- SIEMENS-PLM - Siemens Corporation 17 - AS33776 13216 0.6% 71.8 -- STARCOMMS-ASN 18 - AS22561 12904 0.6% 11.5 -- DIGITAL-TELEPORT - Digital Teleport Inc. 19 - AS2 12648 0.5% 973.0 -- SERVU-AS-AP ServU Networks 20 - AS6713 12317 0.5% 31.4 -- IAM-AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35905 5097 0.2% 5097.0 -- TELX-NYC - Telx 2 - AS15957 7668 0.3% 3834.0 -- WTG-AS Web Technology Group 3 - AS38868 13835 0.6% 3458.8 -- UPM-AS-AP Universiti Putra Malaysia AS 4 - AS42334 2945 0.1% 2945.0 -- BBP-AS Broadband Plus s.a.l. 5 - AS6174 5864 0.2% 2932.0 -- SPRINTLINK8 - Sprint 6 - AS14680 6777 0.3% 2259.0 -- REALE-6 - Auction.com 7 - AS9416 15620 0.7% 2231.4 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 8 - AS33920 3281 0.1% 1640.5 -- AQL (aq) Networks Limited 9 - AS39983 1633 0.1% 1633.0 -- PBGC-HQ-AS - Pension Benefit Guaranty Corp. 10 - AS6629 7479 0.3% 1495.8 -- NOAA-AS - NOAA 11 - AS50453 855 0.0% 855.0 -- EMBRIA FotoStrana Ltd 12 - AS48612 9278 0.4% 843.5 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 13 - AS33629 2295 0.1% 765.0 -- NKU-AS1 - Northern Kentucky University 14 - AS3909 22266 0.9% 674.7 -- QWEST-AS-3908 - Qwest Communications Company, LLC 15 - AS51024 669 0.0% 669.0 -- OLISAT-AS International Olisat S.R.L. 16 - AS33866 660 0.0% 660.0 -- ELAN Elan Ltd. 17 - AS48010 1242 0.1% 621.0 -- OLIMP1-AS OLIMP-KONSALT Ltd. 18 - AS5956 584 0.0% 584.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - AS56678 538 0.0% 538.0 -- GYDROZO-AS LLC "Gydrozo" 20 - AS48359 2116 0.1% 529.0 -- HESABGAR-AS Hesabgar Pardaz Gharb Co. Private J.S. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 209.142.140.0/24 10633 0.4% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 2 - 193.19.90.0/23 9219 0.4% AS29684 -- NOURNET-ASN Nour Communication Co.Ltd - Nournet 3 - 92.246.207.0/24 9195 0.4% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 4 - 203.118.224.0/21 7878 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 5 - 203.118.232.0/21 7737 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 6 - 192.58.232.0/24 7475 0.3% AS6629 -- NOAA-AS - NOAA 7 - 151.118.254.0/24 7416 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 8 - 151.118.255.0/24 7416 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 9 - 151.118.18.0/24 7372 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 10 - 12.139.133.0/24 5467 0.2% AS14680 -- REALE-6 - Auction.com 11 - 208.64.180.0/24 5097 0.2% AS35905 -- TELX-NYC - Telx 12 - 69.38.178.0/24 4029 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 13 - 194.63.9.0/24 3960 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 14 - 173.232.234.0/24 3926 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 15 - 173.232.235.0/24 3923 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 16 - 212.28.16.0/20 3840 0.1% AS15957 -- WTG-AS Web Technology Group 17 - 212.28.0.0/20 3828 0.1% AS15957 -- WTG-AS Web Technology Group 18 - 58.184.229.0/24 3730 0.1% AS9950 -- PUBNETPLUS2-AS-KR DACOM 19 - 119.40.124.0/22 3459 0.1% AS38868 -- UPM-AS-AP Universiti Putra Malaysia AS 20 - 119.40.112.0/22 3459 0.1% AS38868 -- UPM-AS-AP Universiti Putra Malaysia AS 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 morrowc.lists at gmail.com Fri May 3 22:03:32 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 3 May 2013 18:03:32 -0400 Subject: [apops] BGP Update Report In-Reply-To: <201305032200.r43M029D076350@wattle.apnic.net> References: <201305032200.r43M029D076350@wattle.apnic.net> Message-ID: On Fri, May 3, 2013 at 6:00 PM, wrote: > BGP Update Report > Interval: 25-Apr-13 -to- 02-May-13 (7 days) > Observation Point: BGP Peering with AS131072 > > TOP 20 Unstable Origin AS > Rank ASN Upds % Upds/Pfx AS-Name > 1 - AS58113 64482 2.7% 96.8 -- LIR-AS LIR DATACENTER > TELECOM SRL > 2 - AS9829 45721 1.9% 32.1 -- BSNL-NIB National Internet > Backbone > 3 - AS8402 43693 1.9% 26.1 -- CORBINA-AS OJSC "Vimpelcom" > 4 - AS36998 41515 1.8% 32.3 -- SDN-MOBITEL > 5 - AS3909 22266 0.9% 674.7 -- QWEST-AS-3908 - Qwest > Communications Company, LLC > 6 - AS28573 20827 0.9% 7.6 -- NET Servi?os de > Comunica??o S.A. > 7 - AS4538 19817 0.8% 38.0 -- ERX-CERNET-BKB China > Education and Research Network Center > 8 - AS7552 19114 0.8% 16.4 -- VIETEL-AS-AP Vietel > Corporation > 9 - AS18403 15960 0.7% 32.7 -- FPT-AS-AP The Corporation > for Financing & Promoting Technology > 10 - AS14287 15909 0.7% 252.5 -- TRIAD-TELECOM - Triad > Telecom, Inc. > 11 - AS9416 15620 0.7% 2231.4 -- MULTIMEDIA-AS-AP Hoshin > Multimedia Center Inc. > 12 - AS5400 14893 0.6% 141.8 -- BT British > Telecommunications plc > 13 - AS29049 14634 0.6% 43.3 -- DELTA-TELECOM-AS Delta > Telecom LTD. > 14 - AS10620 14136 0.6% 5.7 -- Telmex Colombia S.A. > 15 - AS38868 13835 0.6% 3458.8 -- UPM-AS-AP Universiti Putra > Malaysia AS > 16 - AS22216 13247 0.6% 254.8 -- SIEMENS-PLM - Siemens > Corporation > 17 - AS33776 13216 0.6% 71.8 -- STARCOMMS-ASN > 18 - AS22561 12904 0.6% 11.5 -- DIGITAL-TELEPORT - Digital > Teleport Inc. > 19 - AS2 12648 0.5% 973.0 -- SERVU-AS-AP ServU Networks > AS2 is UDel ? not 'serve-u' ? is the rest of this data proper? (briefly randomly checking most of the rest seem correct ,but...) > 20 - AS6713 12317 0.5% 31.4 -- IAM-AS > > > TOP 20 Unstable Origin AS (Updates per announced prefix) > Rank ASN Upds % Upds/Pfx AS-Name > 1 - AS35905 5097 0.2% 5097.0 -- TELX-NYC - Telx > 2 - AS15957 7668 0.3% 3834.0 -- WTG-AS Web Technology Group > 3 - AS38868 13835 0.6% 3458.8 -- UPM-AS-AP Universiti Putra > Malaysia AS > 4 - AS42334 2945 0.1% 2945.0 -- BBP-AS Broadband Plus > s.a.l. > 5 - AS6174 5864 0.2% 2932.0 -- SPRINTLINK8 - Sprint > 6 - AS14680 6777 0.3% 2259.0 -- REALE-6 - Auction.com > 7 - AS9416 15620 0.7% 2231.4 -- MULTIMEDIA-AS-AP Hoshin > Multimedia Center Inc. > 8 - AS33920 3281 0.1% 1640.5 -- AQL (aq) Networks Limited > 9 - AS39983 1633 0.1% 1633.0 -- PBGC-HQ-AS - Pension > Benefit Guaranty Corp. > 10 - AS6629 7479 0.3% 1495.8 -- NOAA-AS - NOAA > 11 - AS50453 855 0.0% 855.0 -- EMBRIA FotoStrana Ltd > 12 - AS48612 9278 0.4% 843.5 -- RTC-ORENBURG-AS CJSC > "Comstar-Regions" > 13 - AS33629 2295 0.1% 765.0 -- NKU-AS1 - Northern > Kentucky University > 14 - AS3909 22266 0.9% 674.7 -- QWEST-AS-3908 - Qwest > Communications Company, LLC > 15 - AS51024 669 0.0% 669.0 -- OLISAT-AS International > Olisat S.R.L. > 16 - AS33866 660 0.0% 660.0 -- ELAN Elan Ltd. > 17 - AS48010 1242 0.1% 621.0 -- OLIMP1-AS OLIMP-KONSALT > Ltd. > 18 - AS5956 584 0.0% 584.0 -- DNIC-ASBLK-05800-06055 - > DoD Network Information Center > 19 - AS56678 538 0.0% 538.0 -- GYDROZO-AS LLC "Gydrozo" > 20 - AS48359 2116 0.1% 529.0 -- HESABGAR-AS Hesabgar > Pardaz Gharb Co. Private J.S. > > > TOP 20 Unstable Prefixes > Rank Prefix Upds % Origin AS -- AS Name > 1 - 209.142.140.0/24 10633 0.4% AS22561 -- DIGITAL-TELEPORT - > Digital Teleport Inc. > 2 - 193.19.90.0/23 9219 0.4% AS29684 -- NOURNET-ASN Nour > Communication Co.Ltd - Nournet > 3 - 92.246.207.0/24 9195 0.4% AS48612 -- RTC-ORENBURG-AS CJSC > "Comstar-Regions" > 4 - 203.118.224.0/21 7878 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin > Multimedia Center Inc. > 5 - 203.118.232.0/21 7737 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin > Multimedia Center Inc. > 6 - 192.58.232.0/24 7475 0.3% AS6629 -- NOAA-AS - NOAA > 7 - 151.118.254.0/24 7416 0.3% AS3909 -- QWEST-AS-3908 - Qwest > Communications Company, LLC > 8 - 151.118.255.0/24 7416 0.3% AS3909 -- QWEST-AS-3908 - Qwest > Communications Company, LLC > 9 - 151.118.18.0/24 7372 0.3% AS3909 -- QWEST-AS-3908 - Qwest > Communications Company, LLC > 10 - 12.139.133.0/24 5467 0.2% AS14680 -- REALE-6 - Auction.com > 11 - 208.64.180.0/24 5097 0.2% AS35905 -- TELX-NYC - Telx > 12 - 69.38.178.0/24 4029 0.2% AS19406 -- TWRS-MA - Towerstream I, > Inc. > 13 - 194.63.9.0/24 3960 0.2% AS1273 -- CW Cable and Wireless > Worldwide plc > 14 - 173.232.234.0/24 3926 0.2% AS30693 -- > EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation > 15 - 173.232.235.0/24 3923 0.2% AS30693 -- > EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation > 16 - 212.28.16.0/20 3840 0.1% AS15957 -- WTG-AS Web Technology > Group > 17 - 212.28.0.0/20 3828 0.1% AS15957 -- WTG-AS Web Technology > Group > 18 - 58.184.229.0/24 3730 0.1% AS9950 -- PUBNETPLUS2-AS-KR DACOM > 19 - 119.40.124.0/22 3459 0.1% AS38868 -- UPM-AS-AP Universiti > Putra Malaysia AS > 20 - 119.40.112.0/22 3459 0.1% AS38868 -- UPM-AS-AP Universiti > Putra Malaysia AS > > 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 > > _______________________________________________ > apops mailing list > apops at apops.net > http://mailman.apnic.net/mailman/listinfo/apops > Website: www.apops.net > From sam at spacething.org Sat May 4 12:27:17 2013 From: sam at spacething.org (Sam Stickland) Date: Sat, 4 May 2013 13:27:17 +0100 Subject: A spoof film about networking Message-ID: Apologies for the off-topic post, but I thought some of you might get enjoyment out of this... After four and a half years and around 5,000 man hours we finally finished our feature film comedy about networking. If nothing else I think this must be the only film in existence that has eight CCIEs in the cast! I'll keep this brief. There's a two minute trailer here: http://www.youtube.com/watch?v=9t3B3hBXKCc And the full film (one hour long) is here: http://www.youtube.com/watch?v=07H0ci7-OMw We now return to your regular scheduled programming... Sam From geekgirl at gmail.com Sun May 5 14:15:53 2013 From: geekgirl at gmail.com (Leslie) Date: Sun, 5 May 2013 07:15:53 -0700 Subject: Problem reaching Wikipedia (AS43821) via Tele2 In-Reply-To: <518383B8.6060302@lugosys.com> References: <518271CE.7010002@lugosys.com> <791AB073-4ACB-47C2-A864-1B63338CBF03@gmail.com> <518383B8.6060302@lugosys.com> Message-ID: I should really look at NANOG more ;) All of our whois information is up to date, our peeringdb information is up to date, and the usual generic email of noc at wikimedia.org also works. We also have a few irc channels, bugzilla, and a technical problem wiki page! If anyone has issues reaching AS43821 or AS14907 , please contact us directly if you want it fixed sooner than once a week :) Leslie (Wikimedia Foundation - you can also contact me at lcarr at wikimedia.org for any official business). P.S. If anyone's curious, Tele2 was fine - there was an issue between two other as's on a different return path. Hence the * * * after hopping into our network post-border router. On Fri, May 3, 2013 at 2:30 AM, Israel G. Lugo wrote: > Indeed, although I wouldn't know why. > > The problem lasted the whole day yesterday, but it seems to be gone now. > I was given the tech contact for Wikimedia off-list; if anything rises > up again I'll get in touch with them. > > Thank you for the reply, and also to everyone who replied off-list. > > Regards, > Israel G. Lugo > > On 05/02/2013 07:08 PM, Grant Ridder wrote: >> Looks like ge-2-5.br1-knams.wikimedia.org (130.244.6.250) is filtering you somehow. >> >> Grant >> >> Sent from my iPhone >> >> On May 2, 2013, at 9:01 AM, "Israel G. Lugo" wrote: >> >>> Hello, >>> >>> Anyone else having problems reaching Wikipedia? >>> >>> I can't reach AS43821 (Wikimedia RIPE) from within the Portuguese NREN >>> (AS1930), via Cogent (AS174) -> Tele2 (AS1257): >>> >>> traceroute to en.wikipedia.org (91.198.174.225), 30 hops max, 60 byte >>> packets >>> 1 Router3.10GE.Lisboa.fccn.pt (193.136.1.89) [AS1930] 0.953 ms >>> 2 ROUTER10.10GE.Lisboa.fccn.pt (193.137.0.8) [AS1930] 0.939 ms >>> 3 ROUTER4.10GE.Lisboa.fccn.pt (193.137.0.20) [AS1930] 1.000 ms >>> 4 fccn.mx2.lis.pt.geant.net (62.40.124.97) [AS20965] 1.000 ms >>> 5 xe-2-3-0.rt1.mad.es.geant.net (62.40.98.107) [AS20965] 13.926 ms >>> 6 as2.rt1.gen.ch.geant2.net (62.40.112.25) [AS20965] 37.882 ms >>> 7 ae3.mx1.gen.ch.geant.net (62.40.112.14) [AS20965] 37.874 ms >>> 8 ae1.mx1.fra.de.geant.net (62.40.98.109) [AS20965] 44.154 ms >>> 9 ae4.rt1.fra.de.geant.net (62.40.98.135) [AS20965] 43.935 ms >>> 10 te0-4-0-2.mag21.fra03.atlas.cogentco.com (149.6.42.73) [AS174] >>> 44.842 ms >>> 11 fra36-peer-1.xe-1-2-0-unit0.tele2.net (130.244.200.41) [AS1257] >>> 44.368 ms >>> 12 fra36-core-1.bundle-ether2.tele2.net (130.244.64.186) [AS1257] >>> 44.977 ms >>> 13 * >>> 14 ams13-peer-1.ae0-unit0.tele2.net (130.244.53.123) [AS1257] 50.299 ms >>> 15 * >>> 16 * >>> 17 * >>> 18 * >>> 19 * >>> 20 * >>> >>> Tele2's traceroute server (http://services.tele2net.at/traceroute.html) >>> reaches the same IP without problems: >>> >>> 1 213.90.34.4 (213.90.34.4) 0.268 ms 0.124 ms 0.151 ms >>> 2 213.90.1.20 (213.90.1.20) 0.430 ms 0.382 ms 0.303 ms >>> 3 wat1-15-93.net.uta.at (62.218.15.93) 0.497 ms 0.368 ms 0.387 ms >>> 4 c76wmode1-tengigE4-1.net.uta.at (212.152.192.206) 0.644 ms 0.572 ms >>> 0.599 ms >>> 5 wen1-core-2.tengige0-0-1-1.tele2.net (130.244.205.57) 0.836 ms 0.874 >>> ms 0.737 ms >>> 6 fra36-core-1.bundle-ether7.tele2.net (130.244.206.28) 13.683 ms 13.472 >>> ms 13.817 ms >>> 7 ams-core-2.bundle-ether4.tele2.net (130.244.64.201) 20.421 ms 20.482 >>> ms 20.762 ms >>> 8 ams13-peer-1.ae0-unit0.tele2.net (130.244.53.123) 19.972 ms 19.936 ms >>> 19.962 ms >>> 9 ge-2-5.br1-knams.wikimedia.org (130.244.6.250) 20.727 ms 20.641 ms >>> 20.660 ms >>> 10 wikipedia-lb.esams.wikimedia.org (91.198.174.225) 20.610 ms 20.539 ms >>> 20.615 ms >>> >>> Trying from $HOME_ISP, via AS6453 (Globe) -> AS1299 (Telia) works fine. >>> >>> Regards, >>> Israel G. Lugo >>> >>> > > From geekgirl at gmail.com Sun May 5 14:26:14 2013 From: geekgirl at gmail.com (Leslie) Date: Sun, 5 May 2013 07:26:14 -0700 Subject: HTTPS-everywhere vs. proxy caching In-Reply-To: <26650528.4928.1367607990956.JavaMail.root@benjamin.baylink.com> References: <20397199.4926.1367607836997.JavaMail.root@benjamin.baylink.com> <26650528.4928.1367607990956.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, May 3, 2013 at 12:06 PM, Jay Ashworth wrote: > It occurs to me that I don't believe I've seen any discussion of the > Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated > sessions, like non-logged-in users browsing sites like Wikipedia. > > That traffic's not cacheable, is it? Proxy caches on services like > mobile 3/4G, or smaller ISPs, or larger corporations can't cache it, I > wouldn't think, which means both that they will see traffic increases, > and that the end sites will as well. > > Has this been discussed and I missed it? Do I improperly understand > transparent caching? Or is this just a bomb waiting to go off? > > I assume that Wikipedia themselves are on top of the idea that their > in-house reverse-proxies won't be carrying that traffic (though I don't > actually know what their architecture looks like anymore), but.. > If anyone's curious about Wikipedia (we're open with our architecture) - we aren't really effected by using https instead of http for non logged in sessions. I'm assuming all of the other major sites use similar methods. The path goes user <--> LVS load balancer <--> nginx ssl termination <--> varnish (caching layer) <--> (if cache miss) application layer The only extra "hop" for https is the ssl termination, and while if all of a sudden 100% of our traffic switched from http to https, we'd be underprovisioned and have to scramble, the incremental effect of a single user (or all the https everywhere users!) using https is incredibly tiny. It's not as cpu-intensive as many people think. Unless a corporation is breaking ssl ( like in this case - http://superuser.com/questions/115349/firefox-this-connection-is-untrusted-behind-corporate-firewall ) their proxies would be unable to cache SSL content. If you're curious about wikimedia's architecture, you can check it out on our wiki -- https://wikitech.wikimedia.org/wiki/Main_Page Leslie > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > From jsw at inconcepts.biz Sun May 5 18:12:36 2013 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 5 May 2013 14:12:36 -0400 Subject: NANOG58 parking Message-ID: I noticed that some folks were unhappy with the parking fee in Orlando. The Roosevelt New Orleans, for NANOG 58, tells me that the only on-site parking is valet for $42/day. Anyone planning to drive or stay at a different hotel may want to consider that in advance. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From r.engehausen at gmail.com Sun May 5 19:06:58 2013 From: r.engehausen at gmail.com (Roy) Date: Sun, 05 May 2013 12:06:58 -0700 Subject: NANOG58 parking In-Reply-To: References: Message-ID: <5186ADD2.1070504@gmail.com> On 5/5/2013 11:12 AM, Jeff Wheeler wrote: > I noticed that some folks were unhappy with the parking fee in Orlando. > > The Roosevelt New Orleans, for NANOG 58, tells me that the only > on-site parking is valet for $42/day. Anyone planning to drive or > stay at a different hotel may want to consider that in advance. > Its the airline pricing scheme. Show cheap prices and then make it up in fees :-) From wbailey at satelliteintelligencegroup.com Sun May 5 20:02:32 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 5 May 2013 20:02:32 +0000 Subject: NANOG58 parking In-Reply-To: <5186ADD2.1070504@gmail.com> References: , <5186ADD2.1070504@gmail.com> Message-ID: 42 a day is perfect.. Now your town car expense will go through with zero problems.. ;) Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Roy Date: 05/05/2013 12:09 PM (GMT-08:00) To: Cc: NANOG Subject: Re: NANOG58 parking On 5/5/2013 11:12 AM, Jeff Wheeler wrote: > I noticed that some folks were unhappy with the parking fee in Orlando. > > The Roosevelt New Orleans, for NANOG 58, tells me that the only > on-site parking is valet for $42/day. Anyone planning to drive or > stay at a different hotel may want to consider that in advance. > Its the airline pricing scheme. Show cheap prices and then make it up in fees :-) From adam.vitkovsky at swan.sk Mon May 6 07:31:41 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Mon, 6 May 2013 09:31:41 +0200 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: <51840010.4050006@foobar.org> References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> <51840010.4050006@foobar.org> Message-ID: <040901ce4a2b$c0692b10$413b8130$@swan.sk> -----Original Message----- From: Nick Hilliard [mailto:nick at foobar.org] Sent: Friday, May 03, 2013 8:21 PM > From a deployment point of view, there's a pretty big gap between poking around with rpki and actually dropping prefixes on your routers. I don't see that the rpki data will be good enough for the latter any time soon, but maybe one day. Well you can always jus lower the preference for a particular prefix based on the roa state or roa missing. Than it is solely up to your customers whether they bother to register their prefixes to avoid hijacks or not, as you'll be ready on your part. adam From JFaraone at paulo.com Mon May 6 13:21:05 2013 From: JFaraone at paulo.com (Jason Faraone) Date: Mon, 6 May 2013 13:21:05 +0000 Subject: A spoof film about networking In-Reply-To: References: Message-ID: I watched the whole thing and regret nothing. Be the packet. -----Original Message----- From: Sam Stickland [mailto:sam at spacething.org] Sent: Saturday, May 04, 2013 7:27 AM To: nanog at nanog.org Subject: A spoof film about networking Apologies for the off-topic post, but I thought some of you might get enjoyment out of this... After four and a half years and around 5,000 man hours we finally finished our feature film comedy about networking. If nothing else I think this must be the only film in existence that has eight CCIEs in the cast! I'll keep this brief. There's a two minute trailer here: http://www.youtube.com/watch?v=9t3B3hBXKCc And the full film (one hour long) is here: http://www.youtube.com/watch?v=07H0ci7-OMw We now return to your regular scheduled programming... Sam From mikeal.clark at gmail.com Mon May 6 14:27:03 2013 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Mon, 6 May 2013 09:27:03 -0500 Subject: A spoof film about networking In-Reply-To: References: Message-ID: Good Monday material. "I don't like BGP, because I'm not an ISP, and I don't work externally, so all I need is EIGRP." ha. On Mon, May 6, 2013 at 8:21 AM, Jason Faraone wrote: > I watched the whole thing and regret nothing. > > Be the packet. > > -----Original Message----- > From: Sam Stickland [mailto:sam at spacething.org] > Sent: Saturday, May 04, 2013 7:27 AM > To: nanog at nanog.org > Subject: A spoof film about networking > > Apologies for the off-topic post, but I thought some of you might get > enjoyment out of this... > > After four and a half years and around 5,000 man hours we finally finished > our feature film comedy about networking. If nothing else I think this must > be the only film in existence that has eight CCIEs in the cast! > > I'll keep this brief. There's a two minute trailer here: > http://www.youtube.com/watch?v=9t3B3hBXKCc > > And the full film (one hour long) is here: > http://www.youtube.com/watch?v=07H0ci7-OMw > > We now return to your regular scheduled programming... > > Sam > > > From olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa Mon May 6 14:29:12 2013 From: olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa (Oliver) Date: Mon, 06 May 2013 16:29:12 +0200 Subject: A spoof film about networking In-Reply-To: References: Message-ID: <1995095.b1I21ulMVN@gentoovm> On Saturday 04 May 2013 13:27:17 Sam Stickland wrote: > Apologies for the off-topic post, but I thought some of you might get > enjoyment out of this... > > After four and a half years and around 5,000 man hours we finally > finished our feature film comedy about networking. If nothing else I > think this must be the only film in existence that has eight CCIEs in > the cast! > > I'll keep this brief. There's a two minute trailer here: > http://www.youtube.com/watch?v=9t3B3hBXKCc > > And the full film (one hour long) is here: > http://www.youtube.com/watch?v=07H0ci7-OMw > > We now return to your regular scheduled programming... > > Sam I cringed so hard at the EIGRP song, in fact, just thinking about it makes me hurt inside. Aside from that, I was thoroughly amused, top work. I especially loved the hilarious visuals of packets "flowing" into a bucket for the face-off challenge. Regards, Oliver From wbailey at satelliteintelligencegroup.com Mon May 6 15:27:35 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 6 May 2013 15:27:35 +0000 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: <040901ce4a2b$c0692b10$413b8130$@swan.sk> References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> <51840010.4050006@foobar.org>,<040901ce4a2b$c0692b10$413b8130$@swan.sk> Message-ID: Illegal or undesired? Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Adam Vitkovsky Date: 05/06/2013 12:33 AM (GMT-08:00) To: 'Nick Hilliard' ,'Christopher Morrow' Cc: 'NANOG' Subject: RE: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) -----Original Message----- From: Nick Hilliard [mailto:nick at foobar.org] Sent: Friday, May 03, 2013 8:21 PM > From a deployment point of view, there's a pretty big gap between poking around with rpki and actually dropping prefixes on your routers. I don't see that the rpki data will be good enough for the latter any time soon, but maybe one day. Well you can always jus lower the preference for a particular prefix based on the roa state or roa missing. Than it is solely up to your customers whether they bother to register their prefixes to avoid hijacks or not, as you'll be ready on your part. adam From dwhite at olp.net Mon May 6 15:50:42 2013 From: dwhite at olp.net (Dan White) Date: Mon, 6 May 2013 10:50:42 -0500 Subject: McAfee Update failing for newly allocated IP block Message-ID: <20130506155042.GB11283@dan.olp.net> http://update.nai.com/Products/CommonUpdater is returning an html generated error (Unable to forward this request at this time), when connecting via a recently allocated IP block. If someone from McAfee is monitoring this list, please contact me off-list. Thank You, -- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at olp.net http://www.btcbroadband.com From Valdis.Kletnieks at vt.edu Mon May 6 16:23:16 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 06 May 2013 12:23:16 -0400 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: Your message of "Mon, 06 May 2013 15:27:35 -0000." References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> <51840010.4050006@foobar.org>, <040901ce4a2b$c0692b10$413b8130$@swan.sk> Message-ID: <121668.1367857396@turing-police.cc.vt.edu> On Mon, 06 May 2013 15:27:35 -0000, Warren Bailey said: > Illegal or undesired? This sort of stuff comes in two flavors: "typo" and "intentionally done in furtherance of criminal activities". The fact that an AS number and matching IP range are involved tends to say it's not a typo. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From morrowc.lists at gmail.com Mon May 6 16:28:26 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 6 May 2013 12:28:26 -0400 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: <121668.1367857396@turing-police.cc.vt.edu> References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> <51840010.4050006@foobar.org> <040901ce4a2b$c0692b10$413b8130$@swan.sk> <121668.1367857396@turing-police.cc.vt.edu> Message-ID: On Mon, May 6, 2013 at 12:23 PM, wrote: > On Mon, 06 May 2013 15:27:35 -0000, Warren Bailey said: > > Illegal or undesired? > > This sort of stuff comes in two flavors: "typo" and "intentionally done > in furtherance of criminal activities". > > The fact that an AS number and matching IP range are involved tends to say > it's > not a typo. > > maybe warren's question is better stated: "Please point to relevant legal code in the jurisdiction(s) which are relevant." (if you feel this is 'illegal', showing where in the relevant code(s) where this would be classified as such would help) -chris From wbailey at satelliteintelligencegroup.com Mon May 6 16:29:34 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 6 May 2013 16:29:34 +0000 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> <51840010.4050006@foobar.org> <040901ce4a2b$c0692b10$413b8130$@swan.sk> <121668.1367857396@turing-police.cc.vt.edu>, Message-ID: +1 Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Christopher Morrow Date: 05/06/2013 9:29 AM (GMT-08:00) To: Valdis Kletnieks Cc: Warren Bailey ,Adam Vitkovsky ,Nick Hilliard ,NANOG Subject: Re: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) On Mon, May 6, 2013 at 12:23 PM, > wrote: On Mon, 06 May 2013 15:27:35 -0000, Warren Bailey said: > Illegal or undesired? This sort of stuff comes in two flavors: "typo" and "intentionally done in furtherance of criminal activities". The fact that an AS number and matching IP range are involved tends to say it's not a typo. maybe warren's question is better stated: "Please point to relevant legal code in the jurisdiction(s) which are relevant." (if you feel this is 'illegal', showing where in the relevant code(s) where this would be classified as such would help) -chris From goemon at anime.net Mon May 6 18:28:43 2013 From: goemon at anime.net (goemon at anime.net) Date: Mon, 6 May 2013 11:28:43 -0700 (PDT) Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> <51840010.4050006@foobar.org> <040901ce4a2b$c0692b10$413b8130$@swan.sk> <121668.1367857396@turing-police.cc.vt.edu>, Message-ID: if anyone wondered why abuse goes unchecked, wonder no longer. -Dan On Mon, 6 May 2013, Warren Bailey wrote: > +1 > > > Sent from my T-Mobile 4G LTE Device > > > > -------- Original message -------- > From: Christopher Morrow > Date: 05/06/2013 9:29 AM (GMT-08:00) > To: Valdis Kletnieks > Cc: Warren Bailey ,Adam Vitkovsky ,Nick Hilliard ,NANOG > Subject: Re: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) > > > > > > On Mon, May 6, 2013 at 12:23 PM, > wrote: > On Mon, 06 May 2013 15:27:35 -0000, Warren Bailey said: >> Illegal or undesired? > > This sort of stuff comes in two flavors: "typo" and "intentionally done > in furtherance of criminal activities". > > The fact that an AS number and matching IP range are involved tends to say it's > not a typo. > > > maybe warren's question is better stated: "Please point to relevant legal code in the jurisdiction(s) which are relevant." (if you feel this is 'illegal', showing where in the relevant code(s) where this would be classified as such would help) > > -chris > > > From wbailey at satelliteintelligencegroup.com Mon May 6 18:39:25 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 6 May 2013 18:39:25 +0000 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> <51840010.4050006@foobar.org> <040901ce4a2b$c0692b10$413b8130$@swan.sk> <121668.1367857396@turing-police.cc.vt.edu>, , Message-ID: Abuse is abuse.. People are going to do bad things, even when you call them illegal (in some cases, as a result of calling them illegal). It's not illegal to be a tool, but it is illegal to break a law. In my opinikn Laws need to be written and passed, not thought about and argued over. If we are going to arbitrarily make our own laws, why don't we start at something cooler than preventing a guy announcing someone's Internet addresses? I understand the magnitude of these actions, but at some point we need to pay attention to things outside of /dev/internet. Again.. I'm not saying these hijackers aren't pricks, I'm saying that stealing an AS number shouldn't be illegal - committing a crime with information gained should be (and is). It's not that I don't care, I just don't care that MUCH. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: goemon at anime.net Date: 05/06/2013 11:31 AM (GMT-08:00) To: Warren Bailey Cc: Christopher Morrow ,Valdis Kletnieks ,NANOG Subject: Re: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) if anyone wondered why abuse goes unchecked, wonder no longer. -Dan On Mon, 6 May 2013, Warren Bailey wrote: > +1 > > > Sent from my T-Mobile 4G LTE Device > > > > -------- Original message -------- > From: Christopher Morrow > Date: 05/06/2013 9:29 AM (GMT-08:00) > To: Valdis Kletnieks > Cc: Warren Bailey ,Adam Vitkovsky ,Nick Hilliard ,NANOG > Subject: Re: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) > > > > > > On Mon, May 6, 2013 at 12:23 PM, > wrote: > On Mon, 06 May 2013 15:27:35 -0000, Warren Bailey said: >> Illegal or undesired? > > This sort of stuff comes in two flavors: "typo" and "intentionally done > in furtherance of criminal activities". > > The fact that an AS number and matching IP range are involved tends to say it's > not a typo. > > > maybe warren's question is better stated: "Please point to relevant legal code in the jurisdiction(s) which are relevant." (if you feel this is 'illegal', showing where in the relevant code(s) where this would be classified as such would help) > > -chris > > > From morrowc.lists at gmail.com Mon May 6 18:51:30 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 6 May 2013 14:51:30 -0400 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> <51840010.4050006@foobar.org> <040901ce4a2b$c0692b10$413b8130$@swan.sk> <121668.1367857396@turing-police.cc.vt.edu> Message-ID: On Mon, May 6, 2013 at 2:39 PM, Warren Bailey wrote: > > Abuse is abuse.. People are going to do bad things, even when you call them illegal (in some cases, as a result of calling them illegal). It's not illegal to be a tool, but it is illegal to break a law. In my opinikn Laws need to be written and passed, not thought about and argued over. If we are going to arbitrarily make our own laws, why don't we start at something cooler than preventing a guy announcing someone's Internet addresses? I understand the magnitude of these actions, but at some point we need to pay attention to things outside of /dev/internet. Again.. I'm not saying these hijackers aren't pricks, I'm saying that stealing an AS number shouldn't be illegal - committing a crime with information gained should be (and is). It's not that I don't care, I just don't care that MUCH. > agreed, I wasn't of the opinion that the action was 'right', just that calling it 'illegal' was quite a leap. I do think that putting effort into making it significantly harder to 'hijack prefixes' is a good thing, which is the reason I put effort into: tools.ietf.org/wg/sidr pitching a fit from the sidelines isn't helpful, finding a way to keep it from happening again/again/again at least tries to move the ball forward. -chris > > Sent from my T-Mobile 4G LTE Device > > > > -------- Original message -------- > From: goemon at anime.net > Date: 05/06/2013 11:31 AM (GMT-08:00) > To: Warren Bailey > Cc: Christopher Morrow ,Valdis Kletnieks ,NANOG > Subject: Re: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) > > > if anyone wondered why abuse goes unchecked, wonder no longer. > > -Dan > > On Mon, 6 May 2013, Warren Bailey wrote: > > > +1 > > > > > > Sent from my T-Mobile 4G LTE Device > > > > > > > > -------- Original message -------- > > From: Christopher Morrow > > Date: 05/06/2013 9:29 AM (GMT-08:00) > > To: Valdis Kletnieks > > Cc: Warren Bailey ,Adam Vitkovsky ,Nick Hilliard ,NANOG > > Subject: Re: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) > > > > > > > > > > > > On Mon, May 6, 2013 at 12:23 PM, > wrote: > > On Mon, 06 May 2013 15:27:35 -0000, Warren Bailey said: > >> Illegal or undesired? > > > > This sort of stuff comes in two flavors: "typo" and "intentionally done > > in furtherance of criminal activities". > > > > The fact that an AS number and matching IP range are involved tends to say it's > > not a typo. > > > > > > maybe warren's question is better stated: "Please point to relevant legal code in the jurisdiction(s) which are relevant." (if you feel this is 'illegal', showing where in the relevant code(s) where this would be classified as such would help) > > > > -chris > > > > > > > From mike.hyde1 at gmail.com Mon May 6 20:14:19 2013 From: mike.hyde1 at gmail.com (Mike Hyde) Date: Mon, 6 May 2013 15:14:19 -0500 Subject: Historical Info Message-ID: <4BE72B02-42E6-4732-8A8B-524D69CB60E6@gmail.com> Is there a way to get the past owners on IP blocks and AS numbers? From jared at puck.nether.net Mon May 6 20:15:22 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 6 May 2013 16:15:22 -0400 Subject: Historical Info In-Reply-To: <4BE72B02-42E6-4732-8A8B-524D69CB60E6@gmail.com> References: <4BE72B02-42E6-4732-8A8B-524D69CB60E6@gmail.com> Message-ID: On May 6, 2013, at 4:14 PM, Mike Hyde wrote: > Is there a way to get the past owners on IP blocks and AS numbers? > > https://www.arin.net/resources/whowas/ From ahmed at simula.no Mon May 6 20:24:32 2013 From: ahmed at simula.no (Ahmed Elmokashfi) Date: Mon, 6 May 2013 22:24:32 +0200 Subject: Historical Info In-Reply-To: <4BE72B02-42E6-4732-8A8B-524D69CB60E6@gmail.com> References: <4BE72B02-42E6-4732-8A8B-524D69CB60E6@gmail.com> Message-ID: <45E7B829-6A6C-470C-B269-58D7BA0EC27E@simula.no> ARIN has a WHOWAS service which requires access permission. For other RIRs, you need to get historical Whois dumps. Ahmed On 6. mai 2013, at 22:14, Mike Hyde wrote: > Is there a way to get the past owners on IP blocks and AS numbers? > > > From waehlisch at ieee.org Mon May 6 20:28:49 2013 From: waehlisch at ieee.org (Matthias Waehlisch) Date: Mon, 6 May 2013 22:28:49 +0200 Subject: Historical Info In-Reply-To: <45E7B829-6A6C-470C-B269-58D7BA0EC27E@simula.no> References: <4BE72B02-42E6-4732-8A8B-524D69CB60E6@gmail.com> <45E7B829-6A6C-470C-B269-58D7BA0EC27E@simula.no> Message-ID: For RIPE there is a new beta service to display history of objects in the RIPE DB https://labs.ripe.net/Members/kranjbar/proposal-to-display-history-of-objects-in-ripe-database Cheers 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 On Mon, 6 May 2013, Ahmed Elmokashfi wrote: > ARIN has a WHOWAS service which requires access permission. For other RIRs, you need to get historical Whois dumps. > > Ahmed > > On 6. mai 2013, at 22:14, Mike Hyde wrote: > > > Is there a way to get the past owners on IP blocks and AS numbers? > > > > > > > > From nick at foobar.org Mon May 6 20:41:58 2013 From: nick at foobar.org (Nick Hilliard) Date: Mon, 06 May 2013 21:41:58 +0100 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: <040901ce4a2b$c0692b10$413b8130$@swan.sk> References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> <51840010.4050006@foobar.org> <040901ce4a2b$c0692b10$413b8130$@swan.sk> Message-ID: <51881596.7020604@foobar.org> On 06/05/2013 08:31, Adam Vitkovsky wrote: > Well you can always jus lower the preference for a particular prefix based > on the roa state or roa missing. > Than it is solely up to your customers whether they bother to register their > prefixes to avoid hijacks or not, as you'll be ready on your part. yep, you can depref stuff but it won't necessarily do what you want. E.g. if someone in Iran decides to announce a more-specific for some prefix in germany: https://twitter.com/bgpmon/status/330777020395040768 then the roa validation process would return "invalid". If you depref this, the more-specific will still provide the best path, so it's pretty useless. The only way to handle this is to drop roa-invalid paths completely, but it's not going to be possible to implement that as a general routing policy until the rpki data is pretty good quality overall. Nick From goemon at anime.net Mon May 6 20:51:08 2013 From: goemon at anime.net (goemon at anime.net) Date: Mon, 6 May 2013 13:51:08 -0700 (PDT) Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> <51840010.4050006@foobar.org> <040901ce4a2b$c0692b10$413b8130$@swan.sk> <121668.1367857396@turing-police.cc.vt.edu>, , Message-ID: And then you end up on RBLs. That seems to help the caring aspect PDQ. -Dan On Mon, 6 May 2013, Warren Bailey wrote: > Abuse is abuse.. People are going to do bad things, even when you call them illegal (in some cases, as a result of calling them illegal). It's not illegal to be a tool, but it is illegal to break a law. In my opinikn Laws need to be written and passed, not thought about and argued over. If we are going to arbitrarily make our own laws, why don't we start at something cooler than preventing a guy announcing someone's Internet addresses? I understand the magnitude of these actions, but at some point we need to pay attention to things outside of /dev/internet. Again.. I'm not saying these hijackers aren't pricks, I'm saying that stealing an AS number shouldn't be illegal - committing a crime with information gained should be (and is). It's not that I don't care, I just don't care that MUCH. > > Sent from my T-Mobile 4G LTE Device > > > > -------- Original message -------- > From: goemon at anime.net > Date: 05/06/2013 11:31 AM (GMT-08:00) > To: Warren Bailey > Cc: Christopher Morrow ,Valdis Kletnieks ,NANOG > Subject: Re: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) > > > if anyone wondered why abuse goes unchecked, wonder no longer. > > -Dan > > On Mon, 6 May 2013, Warren Bailey wrote: > >> +1 >> >> >> Sent from my T-Mobile 4G LTE Device >> >> >> >> -------- Original message -------- >> From: Christopher Morrow >> Date: 05/06/2013 9:29 AM (GMT-08:00) >> To: Valdis Kletnieks >> Cc: Warren Bailey ,Adam Vitkovsky ,Nick Hilliard ,NANOG >> Subject: Re: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) >> >> >> >> >> >> On Mon, May 6, 2013 at 12:23 PM, > wrote: >> On Mon, 06 May 2013 15:27:35 -0000, Warren Bailey said: >>> Illegal or undesired? >> >> This sort of stuff comes in two flavors: "typo" and "intentionally done >> in furtherance of criminal activities". >> >> The fact that an AS number and matching IP range are involved tends to say it's >> not a typo. >> >> >> maybe warren's question is better stated: "Please point to relevant legal code in the jurisdiction(s) which are relevant." (if you feel this is 'illegal', showing where in the relevant code(s) where this would be classified as such would help) >> >> -chris >> >> >> > > From randy at psg.com Tue May 7 08:59:49 2013 From: randy at psg.com (Randy Bush) Date: Tue, 07 May 2013 10:59:49 +0200 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: <51881596.7020604@foobar.org> References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> <51840010.4050006@foobar.org> <040901ce4a2b$c0692b10$413b8130$@swan.sk> <51881596.7020604@foobar.org> Message-ID: > The only way to handle this is to drop roa-invalid paths completely, > but it's not going to be possible to implement that as a general > routing policy until the rpki data is pretty good quality overall. ssshhhh. my routers might hear you and think there was something wrong about themselves. randy From jlester at wcs.k12.va.us Tue May 7 16:54:21 2013 From: jlester at wcs.k12.va.us (Jason Lester) Date: Tue, 7 May 2013 12:54:21 -0400 Subject: CenturyLink Outage? Message-ID: Does anyone know what is going on with the nationwide CenturyLink outage? Their NOC recording says it is a BGP routing issue with their upstream peers affecting Internet traffic and traffic between regions. Our outside connectivity with them has basically been down since about 4:00AM (EDT) this morning. The prefixes we were receiving from them were fluctuating between a few hundred and a few thousand all morning. We are getting the full BGP table from them now (for about the last hour), but still not seeing any incoming traffic. Seems like a major issue since it has been almost 9 hours now. Thanks, Jason -- Jason Lester Administrator for Instructional Technology Washington County Public Schools Tel: 276-739-3060 Fax: 276-628-1893 http://www.wcs.k12.va.us From j at 2600hz.com Tue May 7 17:17:36 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Tue, 7 May 2013 17:17:36 +0000 Subject: CenturyLink Outage? In-Reply-To: References: Message-ID: <4427CD29-C19D-4A5A-829A-58275FC373B9@2600hz.com> Outages list is going bananas right now: Same thing happened in Monroe LA that took down all of north Louisiana. It was an update that went bad and the switch had to be manually checked line by line. No backup was done before the maintenance. 16 hours of downtime about 45 days ago. On Tuesday, May 7, 2013, Frank Bulk wrote: Sounds like it was scheduled maintenance gone bad: "Perrine said he spoke with CenturyLink at 6 a.m. where they advised him the company was doing scheduled maintenance. At 7:35 a.m. they told him something had gone wrong during the maintenance and it was affecting customers in 13 states." http://www.tallahassee.com/article/20130507/NEWS/130507010/Centurylink-outag e-affecting-local-internet-provider?nclick_check=1 I bite my tongue in regards to Network Tallahasee's singlehomedness and Perrine's comment on his questioning of the timing of the update. I encourage all my competitors to stay single homed and to do their maintenance Sunday morning, while their vendors are at their lowest staffing levels. Frank -----Original Message----- From: Outages [mailto:outages-bounces at outages.org] On Behalf Of Frank Bulk Sent: Tuesday, May 07, 2013 8:29 AM To: 'Marco Prechel'; outages at outages.org Subject: Re: [outages] Centurylink nationwide outage I first saw timeouts with www.qwest.com over IPv6 at 3:08 am Central -- I was wondering why, now I know. =) Frank -----Original Message----- From: Outages [mailto:outages-bounces at outages.org] On Behalf Of Marco Prechel Sent: Tuesday, May 07, 2013 7:33 AM To: outages at outages.org Subject: [outages] Centurylink nationwide outage Saw our Centurylink Ethernet circuit lose L3 connectivity in SWFL around 0400 EDT. ANS/ABS states it's a nationwide routing issue. No ETR. _______________________________________________ Outages mailing list Outages at outages.org https://puck.nether.net/mailman/listinfo/outages _______________________________________________ Outages mailing list Outages at outages.org https://puck.nether.net/mailman/listinfo/outages _______________________________________________ Outages mailing list Outages at outages.org https://puck.nether.net/mailman/listinfo/outages -- Jeremie Chism Triton Communications _______________________________________________ Outages mailing list Outages at outages.org https://puck.nether.net/mailman/listinfo/outages Sent from my iPad On May 7, 2013, at 10:16 AM, "Jason Lester" > wrote: Does anyone know what is going on with the nationwide CenturyLink outage? Their NOC recording says it is a BGP routing issue with their upstream peers affecting Internet traffic and traffic between regions. Our outside connectivity with them has basically been down since about 4:00AM (EDT) this morning. The prefixes we were receiving from them were fluctuating between a few hundred and a few thousand all morning. We are getting the full BGP table from them now (for about the last hour), but still not seeing any incoming traffic. Seems like a major issue since it has been almost 9 hours now. Thanks, Jason -- Jason Lester Administrator for Instructional Technology Washington County Public Schools Tel: 276-739-3060 Fax: 276-628-1893 http://www.wcs.k12.va.us From jneiberger at gmail.com Tue May 7 17:18:43 2013 From: jneiberger at gmail.com (John Neiberger) Date: Tue, 7 May 2013 11:18:43 -0600 Subject: CenturyLink Outage? In-Reply-To: References: Message-ID: There is an ongoing discussion about this on the outages list. https://puck.nether.net/mailman/listinfo/outages John On Tue, May 7, 2013 at 10:54 AM, Jason Lester wrote: > Does anyone know what is going on with the nationwide CenturyLink outage? > Their NOC recording says it is a BGP routing issue with their upstream > peers affecting Internet traffic and traffic between regions. Our outside > connectivity with them has basically been down since about 4:00AM (EDT) > this morning. The prefixes we were receiving from them were fluctuating > between a few hundred and a few thousand all morning. We are getting the > full BGP table from them now (for about the last hour), but still not > seeing any incoming traffic. Seems like a major issue since it has been > almost 9 hours now. > > Thanks, > Jason > -- > > Jason Lester > Administrator for Instructional Technology > Washington County Public Schools > Tel: 276-739-3060 > Fax: 276-628-1893 > http://www.wcs.k12.va.us > From me at staticsafe.ca Tue May 7 17:19:59 2013 From: me at staticsafe.ca (staticsafe) Date: Tue, 07 May 2013 13:19:59 -0400 Subject: CenturyLink Outage? In-Reply-To: References: Message-ID: <518937BF.6030503@staticsafe.ca> On 5/7/2013 12:54, Jason Lester wrote: > Does anyone know what is going on with the nationwide CenturyLink outage? > Their NOC recording says it is a BGP routing issue with their upstream > peers affecting Internet traffic and traffic between regions. Our outside > connectivity with them has basically been down since about 4:00AM (EDT) > this morning. The prefixes we were receiving from them were fluctuating > between a few hundred and a few thousand all morning. We are getting the > full BGP table from them now (for about the last hour), but still not > seeing any incoming traffic. Seems like a major issue since it has been > almost 9 hours now. > > Thanks, > Jason > See the [outages] thread - https://puck.nether.net/pipermail/outages/2013-May/005513.html -- staticsafe O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post - http://goo.gl/YrmAb Don't CC me! I'm subscribed to whatever list I just posted on. From jlester at wcs.k12.va.us Tue May 7 17:20:28 2013 From: jlester at wcs.k12.va.us (Jason Lester) Date: Tue, 7 May 2013 13:20:28 -0400 Subject: CenturyLink Outage? In-Reply-To: References: Message-ID: Thanks, I did not know about that list. Jason On Tue, May 7, 2013 at 1:18 PM, John Neiberger wrote: > There is an ongoing discussion about this on the outages list. > > https://puck.nether.net/mailman/listinfo/outages > > John > > > On Tue, May 7, 2013 at 10:54 AM, Jason Lester wrote: > >> Does anyone know what is going on with the nationwide CenturyLink outage? >> Their NOC recording says it is a BGP routing issue with their upstream >> peers affecting Internet traffic and traffic between regions. Our outside >> connectivity with them has basically been down since about 4:00AM (EDT) >> this morning. The prefixes we were receiving from them were fluctuating >> between a few hundred and a few thousand all morning. We are getting the >> full BGP table from them now (for about the last hour), but still not >> seeing any incoming traffic. Seems like a major issue since it has been >> almost 9 hours now. >> >> Thanks, >> Jason >> -- >> >> Jason Lester >> Administrator for Instructional Technology >> Washington County Public Schools >> Tel: 276-739-3060 >> Fax: 276-628-1893 >> http://www.wcs.k12.va.us >> > > -- Jason Lester Administrator for Instructional Technology Washington County Public Schools Tel: 276-739-3060 Fax: 276-628-1893 http://www.wcs.k12.va.us From george.herbert at gmail.com Tue May 7 17:26:10 2013 From: george.herbert at gmail.com (George Herbert) Date: Tue, 7 May 2013 10:26:10 -0700 Subject: CenturyLink Outage? In-Reply-To: References: Message-ID: <7D1641FF-85B5-432D-8DDD-0BDCCC3A6F94@gmail.com> Widely discussed on outages at outages.org list (hint!) but for those not yet list members over there, 13 or more states in southeast US affected, reportedly routing / layer 3 issue, possibly BGP to outside but not clear. Some service restorations discussed. George William Herbert Sent from my iPhone On May 7, 2013, at 9:54 AM, Jason Lester wrote: > Does anyone know what is going on with the nationwide CenturyLink outage? > Their NOC recording says it is a BGP routing issue with their upstream > peers affecting Internet traffic and traffic between regions. Our outside > connectivity with them has basically been down since about 4:00AM (EDT) > this morning. The prefixes we were receiving from them were fluctuating > between a few hundred and a few thousand all morning. We are getting the > full BGP table from them now (for about the last hour), but still not > seeing any incoming traffic. Seems like a major issue since it has been > almost 9 hours now. > > Thanks, > Jason > -- > > Jason Lester > Administrator for Instructional Technology > Washington County Public Schools > Tel: 276-739-3060 > Fax: 276-628-1893 > http://www.wcs.k12.va.us From cfriacas at fccn.pt Tue May 7 18:07:32 2013 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 7 May 2013 19:07:32 +0100 (WEST) Subject: Problem reaching AS32 In-Reply-To: References: Message-ID: Hi, AS1930 is again feeling reachability issues, now with AS32. (there was a thread last week about wikipedia reachability also reported from our side -- there was nothing wrong within our network) We are now having problems reaching AS32 in California. Traceroute stops well away from our (direct) transit providers. I've already tried to push packets towards the two AS32's transit providers i see (AS46749 and AS2153) and i can't get through to AS32. Is it possible this has something to do with the previous thread (Century Link outage)? (i'm in Europe, i know very little about US networks) I've also tried to send e-mail to noc at cenic.org, but both their MXs are not reachable either... :-( Other local commercial providers seem to be able to reach AS32, so there should be something in the way against AS1930's prefixes. Thanks. Regards, Carlos Fria?as From ted at io-tx.com Tue May 7 18:46:29 2013 From: ted at io-tx.com (Ted Hatfield) Date: Tue, 7 May 2013 13:46:29 -0500 (CDT) Subject: ProofPoint admin In-Reply-To: References: Message-ID: If there is a proofpoint email admin available please contact me off list. Thanks, Ted Hatfield PrismNet Ltd. From jarenangerbauer at gmail.com Tue May 7 19:02:31 2013 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Tue, 7 May 2013 13:02:31 -0600 Subject: ProofPoint admin In-Reply-To: References: Message-ID: Responded off list. --Jaren On Tue, May 7, 2013 at 12:46 PM, Ted Hatfield wrote: > > If there is a proofpoint email admin available please contact me off list. > > > > Thanks, > > Ted Hatfield > PrismNet Ltd. > > > > From quantumfoam at gmail.com Tue May 7 19:26:25 2013 From: quantumfoam at gmail.com (Jonathan Rogers) Date: Tue, 7 May 2013 15:26:25 -0400 Subject: CenturyLink Outage? In-Reply-To: <7D1641FF-85B5-432D-8DDD-0BDCCC3A6F94@gmail.com> References: <7D1641FF-85B5-432D-8DDD-0BDCCC3A6F94@gmail.com> Message-ID: CenturyLink having an OUTAGE?!? Well, I never!! --JR @ Google-Atlanta On Tue, May 7, 2013 at 1:26 PM, George Herbert wrote: > Widely discussed on outages at outages.org list (hint!) but for those not > yet list members over there, 13 or more states in southeast US affected, > reportedly routing / layer 3 issue, possibly BGP to outside but not clear. > Some service restorations discussed. > > > George William Herbert > Sent from my iPhone > > On May 7, 2013, at 9:54 AM, Jason Lester wrote: > > > Does anyone know what is going on with the nationwide CenturyLink outage? > > Their NOC recording says it is a BGP routing issue with their upstream > > peers affecting Internet traffic and traffic between regions. Our > outside > > connectivity with them has basically been down since about 4:00AM (EDT) > > this morning. The prefixes we were receiving from them were fluctuating > > between a few hundred and a few thousand all morning. We are getting the > > full BGP table from them now (for about the last hour), but still not > > seeing any incoming traffic. Seems like a major issue since it has been > > almost 9 hours now. > > > > Thanks, > > Jason > > -- > > > > Jason Lester > > Administrator for Instructional Technology > > Washington County Public Schools > > Tel: 276-739-3060 > > Fax: 276-628-1893 > > http://www.wcs.k12.va.us > > From wbailey at satelliteintelligencegroup.com Tue May 7 19:28:56 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 7 May 2013 19:28:56 +0000 Subject: CenturyLink Outage? In-Reply-To: References: <7D1641FF-85B5-432D-8DDD-0BDCCC3A6F94@gmail.com>, Message-ID: <1pmsfnmrqqugl4v48xudcgef.1367954933192@email.android.com> Need to pay their bills on time? ;) Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Jonathan Rogers Date: 05/07/2013 12:28 PM (GMT-08:00) To: George Herbert Cc: nanog at nanog.org Subject: Re: CenturyLink Outage? CenturyLink having an OUTAGE?!? Well, I never!! --JR @ Google-Atlanta On Tue, May 7, 2013 at 1:26 PM, George Herbert wrote: > Widely discussed on outages at outages.org list (hint!) but for those not > yet list members over there, 13 or more states in southeast US affected, > reportedly routing / layer 3 issue, possibly BGP to outside but not clear. > Some service restorations discussed. > > > George William Herbert > Sent from my iPhone > > On May 7, 2013, at 9:54 AM, Jason Lester wrote: > > > Does anyone know what is going on with the nationwide CenturyLink outage? > > Their NOC recording says it is a BGP routing issue with their upstream > > peers affecting Internet traffic and traffic between regions. Our > outside > > connectivity with them has basically been down since about 4:00AM (EDT) > > this morning. The prefixes we were receiving from them were fluctuating > > between a few hundred and a few thousand all morning. We are getting the > > full BGP table from them now (for about the last hour), but still not > > seeing any incoming traffic. Seems like a major issue since it has been > > almost 9 hours now. > > > > Thanks, > > Jason > > -- > > > > Jason Lester > > Administrator for Instructional Technology > > Washington County Public Schools > > Tel: 276-739-3060 > > Fax: 276-628-1893 > > http://www.wcs.k12.va.us > > From cfriacas at fccn.pt Tue May 7 20:30:13 2013 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 7 May 2013 21:30:13 +0100 (WEST) Subject: Problem reaching AS32 In-Reply-To: References: Message-ID: It's solved now! :-)) Thanks to CENIC's NOC. Regards, Carlos On Tue, 7 May 2013, Carlos Friacas wrote: > > Hi, > > AS1930 is again feeling reachability issues, now with AS32. > (there was a thread last week about wikipedia reachability also reported from > our side -- there was nothing wrong within our network) > > We are now having problems reaching AS32 in California. > > Traceroute stops well away from our (direct) transit providers. I've already > tried to push packets towards the two AS32's transit providers i see (AS46749 > and AS2153) and i can't get through to AS32. > > Is it possible this has something to do with the previous thread (Century > Link outage)? (i'm in Europe, i know very little about US networks) > > I've also tried to send e-mail to noc at cenic.org, but both their MXs are not > reachable either... :-( > Other local commercial providers seem to be able to reach AS32, so there > should be something in the way against AS1930's prefixes. > > Thanks. > > Regards, > Carlos Fria?as > From yang.yu.list at gmail.com Tue May 7 20:44:33 2013 From: yang.yu.list at gmail.com (Yang Yu) Date: Tue, 7 May 2013 16:44:33 -0400 Subject: "Network Engineering" Stack Exchange site in Area51 (fwd) In-Reply-To: References: Message-ID: Network Engineering Q&A site - Area 51 - Stack Exchange just started private beta. http://networkengineering.stackexchange.com/ If anyone needs a private beta invitation, feel free to email me offlist. Thanks. On Tue, Apr 30, 2013 at 7:40 PM, Simon Lyall wrote: > > The proposal currently needs just 13 more committers with 200+ SE points on > any site... > > http://area51.stackexchange.com/proposals/52519/network-engineering > > The SE site proposal for 'network engineering' is so close to going into > Beta. It's up to > 441 committers, and is currently 7th overall, (of 800+ proposals,) on the > "hottest proposal list. > > -- > Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ > "To stay awake all night adds a day to your life" - Stilgar | eMT. > > From rdrake at direcpath.com Tue May 7 23:56:16 2013 From: rdrake at direcpath.com (Robert Drake) Date: Tue, 7 May 2013 19:56:16 -0400 Subject: NANOG58 bad helo for hotel reservation emails Message-ID: <518994A0.9040400@direcpath.com> Sorry for the noise, but I thought this might be of interest to anyone waiting for their hotel confirmation: NOQUEUE: reject: RCPT from feport01.hiltonhhonors.net[63.122.201.171]: 450 4.7.1 : Helo command rejected: Host not found; from= to= proto=ESMTP helo= So if you run your own server and/or are capable of compensating for a misconfigured MTA, you should add an exception for feport01.hiltonhhonors.net. From ops.lists at gmail.com Wed May 8 00:19:36 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 8 May 2013 05:49:36 +0530 Subject: NANOG58 bad helo for hotel reservation emails In-Reply-To: <518994A0.9040400@direcpath.com> References: <518994A0.9040400@direcpath.com> Message-ID: Checking for a non resolvable HELO will get you significant fps. There are plenty of HELO patterns that can and must be filtered but not this one. On Wednesday, May 8, 2013, Robert Drake wrote: > Sorry for the noise, but I thought this might be of interest to anyone > waiting for their hotel confirmation: > > NOQUEUE: reject: RCPT from feport01.hiltonhhonors.net[63.**122.201.171]: > 450 4.7.1 : Helo command rejected: Host not > found; from= to= > proto=ESMTP helo= > > So if you run your own server and/or are capable of compensating for a > misconfigured MTA, you should add an exception for > feport01.hiltonhhonors.net. > > > > > -- --srs (iPad) From tyler.haske at gmail.com Wed May 8 14:02:07 2013 From: tyler.haske at gmail.com (Tyler Haske) Date: Wed, 8 May 2013 10:02:07 -0400 Subject: Per Site QOS policy with Cisco IOS-XE In-Reply-To: References: Message-ID: If you want to prevent a PE router from deciding which ingress packets to drop, the only plan is to send packets to spoke sites at or below the spoke line-rate. The only good way to do that is shaping on the hub router. policy-map parent_shaper class class-default shape average 100000000 < --- 100Mbps parent shaper. service-policy site_shaper policy-map site_shaper class t1_site shape average 1536000 service-policy qos_global class multilink_site shape average 3072000 service-policy qos_global class class-default service-policy qos_global policy-map qos_global ... whatever you typically use here.... Tyler Haske On Wed, May 1, 2013 at 5:03 PM, Wes Tribble wrote: > I have a question for the QOS gurus out there. > > We are having some problems with packet loss for our > smaller MPLS locations. This packet loss is due to the large speed > differential on our Hub site(150mb/s) in comparison the the branch office > locations(single T-1 to 4.5mb/s multilinks). This packet loss only seems > to impact really bursty applications like our Web Proxy. I have been > around and around with WindStream to give me some extra buffer or enable > random early detection on the smaller interfaces in my MPLS network. So > far they are unwilling to do a custom policy and none of their standard > policies have enough buffer to handle the bursts. They do FIFO tail drop > in every queue, so I can?t even choose a policy that has WRED implemented. > From westribble at gmail.com Wed May 8 14:54:48 2013 From: westribble at gmail.com (Wes Tribble) Date: Wed, 8 May 2013 09:54:48 -0500 Subject: Per Site QOS policy with Cisco IOS-XE In-Reply-To: References: Message-ID: Tyler, I would love to implement a policy similar to that one. Unfortunately, I don't believe you can have two tiers of shaping like that in a policy. Most of the two-tiered shaping solutions I have seen involve using a VRF to shape to the aggregate rate and then use a second VRF to shape to the site rate. This is to get around the three-tier policy limitations. With that said, if you have something like that configured and working, I would love to see the config and the "show policy-map interface" output. That is exactly the kind of policy I was originally looking to implement, but then I ran into those limitations. Thanks for the reply. Great idea in concept. If only we could implement. On Wed, May 8, 2013 at 9:02 AM, Tyler Haske wrote: > If you want to prevent a PE router from deciding which ingress packets to > drop, the only plan is to send packets to spoke sites at or below the spoke > line-rate. The only good way to do that is shaping on the hub router. > > policy-map parent_shaper > class class-default > shape average 100000000 < --- 100Mbps parent shaper. > service-policy site_shaper > > policy-map site_shaper > class t1_site > shape average 1536000 > service-policy qos_global > class multilink_site > shape average 3072000 > service-policy qos_global > class class-default > service-policy qos_global > > policy-map qos_global > ... whatever you typically use here.... > > Tyler Haske > > > > On Wed, May 1, 2013 at 5:03 PM, Wes Tribble wrote: > >> I have a question for the QOS gurus out there. >> >> We are having some problems with packet loss for our >> smaller MPLS locations. This packet loss is due to the large speed >> differential on our Hub site(150mb/s) in comparison the the branch office >> locations(single T-1 to 4.5mb/s multilinks). This packet loss only seems >> to impact really bursty applications like our Web Proxy. I have been >> around and around with WindStream to give me some extra buffer or enable >> random early detection on the smaller interfaces in my MPLS network. So >> far they are unwilling to do a custom policy and none of their standard >> policies have enough buffer to handle the bursts. They do FIFO tail drop >> in every queue, so I can?t even choose a policy that has WRED implemented. >> > From rayw at rayw.net Wed May 8 14:54:53 2013 From: rayw at rayw.net (Ray Wong) Date: Wed, 8 May 2013 07:54:53 -0700 Subject: Traffic shaping going on? Message-ID: Doesn't seem directly correlated with outages, and everything seems to be working ok, but I'm seeing about a 20-30% shift in flows from AS7792 to AS3356. Seems unlikely that many ISPs have suddenly turned up a level3 link on the same day/hour, and performance metrics all seem normal. I confess I've had to turn my attention away from network issues to systems/DB/security ones lately, so I may have missed something. Anyone else seeing fairly significant next hop shifts over the previous 24 hours? All of yesterdays major outages I was sort of suspecting seem to have been resolved without correlating shifts back. -R> From BECHA at ripe.net Wed May 8 17:03:32 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 08 May 2013 19:03:32 +0200 Subject: Historical Info In-Reply-To: <4BE72B02-42E6-4732-8A8B-524D69CB60E6@gmail.com> References: <4BE72B02-42E6-4732-8A8B-524D69CB60E6@gmail.com> Message-ID: <518A8564.3070503@ripe.net> Hi Mike, you can use RIPEstat: http://stat.ripe.net On 5/6/13 10:14 PM, Mike Hyde wrote: > Is there a way to get the past owners on IP blocks and AS numbers? for the routing history: https://stat.ripe.net/m/widget/routing-history#w.resource=193.0.21.44 (link to mobile version -> "/m") for the allocation history: https://stat.ripe.net/m/widget/allocation-history#w.resource=192.0.21.44 (without "/m") And, today released BGPlay2 can be useful too: https://labs.ripe.net/Members/vastur/bgplay-v2-integrated-in-ripestat For RIPE NCC members, it is possible see the history of _registration in whois_, of IP ranges and AS numbers, and related objects: https://labs.ripe.net/Members/dfk/registration-history-for-members-a-demo I hope this helps. Regards, Vesna From jared at puck.nether.net Wed May 8 17:09:02 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 8 May 2013 13:09:02 -0400 Subject: Traffic shaping going on? In-Reply-To: References: Message-ID: On May 8, 2013, at 10:54 AM, Ray Wong wrote: > Doesn't seem directly correlated with outages, and everything seems to be > working ok, but I'm seeing about a 20-30% shift in flows from AS7792 to > AS3356. Seems unlikely that many ISPs have suddenly turned up a level3 link > on the same day/hour, and performance metrics all seem normal. I confess > I've had to turn my attention away from network issues to > systems/DB/security ones lately, so I may have missed something. Anyone > else seeing fairly significant next hop shifts over the previous 24 hours? > All of yesterdays major outages I was sort of suspecting seem to have been > resolved without correlating shifts back. Just a random guess: Level3 could be migrating/integrating further networks which has triggered this shift. They do represent over 50% of the networks out there http://as-rank.caida.org/?mode0=as-ranking&n=50&ranksort=1 You can see here they have 51% of AS'es and 55% of IPv4 prefixes behind them. If you look at the combined, it's even more @69%/72% here: http://as-rank.caida.org/?mode0=org-info&mode1=member-ases&org=LVLT-ARIN - Jared From hank at efes.iucc.ac.il Wed May 8 17:16:05 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 08 May 2013 20:16:05 +0300 Subject: Feedly and Facebook having issues? Message-ID: <5.1.1.6.2.20130508200436.01ee4a08@efes.iucc.ac.il> http://www.isitdownrightnow.com/facebook.com.html http://www.isitdownrightnow.com/feedly.com.html -Hank From shortdudey123 at gmail.com Wed May 8 17:31:04 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 8 May 2013 12:31:04 -0500 Subject: Feedly and Facebook having issues? In-Reply-To: <5.1.1.6.2.20130508200436.01ee4a08@efes.iucc.ac.il> References: <5.1.1.6.2.20130508200436.01ee4a08@efes.iucc.ac.il> Message-ID: I am not seeing any slowness from a TWTC circuit in Milwaukee, WI. (The spike an noon is due to a script that also runs that slows the server a bit) -Grant On Wed, May 8, 2013 at 12:16 PM, Hank Nussbacher wrote: > http://www.isitdownrightnow.**com/facebook.com.html > http://www.isitdownrightnow.**com/feedly.com.html > > -Hank > > > From joesox at gmail.com Wed May 8 23:34:54 2013 From: joesox at gmail.com (JoeSox) Date: Wed, 8 May 2013 16:34:54 -0700 Subject: Could not send email to office 365 In-Reply-To: References: <20130501182123.2455.AEA43824@ugec.net> <51820ABE.4070000@isc.org> <2AEB6E00-1ECA-460F-A656-98085B5F053D@hopcount.ca> Message-ID: Just an update if list members are still experiencing this issue. I spoke on the phone with Escalation Manager for Microsoft North America and they had meetings today and their Engineering team is putting a game plan together to roll out a fix for the Outlook connectivity issues. They were debating to roll-out to the group of effected customers or one-by-one. From the data I provided to them it looks like something to do with their NSPI RPC endpoint environment. They told me I should receive a call tomorrow but call them Friday if I do not receive a call. Hopefully, everyone else experiencing this issue is being taken care of as this is the main concern with Cloud services is the lack of response times on major issues. -- Thanks, Joe On Thu, May 2, 2013 at 10:16 AM, JoeSox wrote: > Our Technical Support is reporting a big jump in Outlook connectivity > issues about 5-10 minutes ago. > Our resolvers are testing fine. > -- > Thanks, Joe > > > On Thu, May 2, 2013 at 4:53 AM, Joe Abley wrote: > >> >> On 2013-05-02, at 02:42, Cathy Almond wrote: >> >> > This may be a red herring, but I've heard of some dropping of DNS >> > queries for the names within outlook.com domains where the queries are >> > all coming from source port 53 (i.e. your recursive server doesn't use >> > query source port randomization >> >> ... or there's a NAT or some other box in front of the recursive server >> which re-writes the source port... >> >> > ). Might be worth checking what the >> > recursive server you're using is doing? >> > >> > See https://www.dns-oarc.net/oarc/services/porttest >> >> >> Joe >> > > From jeroen at mompl.net Thu May 9 00:29:29 2013 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 08 May 2013 17:29:29 -0700 Subject: Data Center Installations In-Reply-To: References: <97cd9e3bdef74966b69501d5ac127aa5@BY2PR05MB079.namprd05.prod.outlook.com> Message-ID: <518AEDE9.3070802@mompl.net> On 05/01/2013 10:05 PM, shawn wilson wrote: > I'm more impressed with MicroCenter than Frys (at least the Frys south if > SF). Too bad the Micro Center in Santa Clara along hwy 101 closed shop a year or so ago. According to them the owner of the building raised the lease price too much. The closest one for the bay Area now is LA... But I too liked them better than frys. It looks like in frys most time I spend dodging pushy sales people. You can't look at a thing for more than 10 seconds before some creepster walks over asking if you need help. A good alternative for the Bay Area is Central Computers. They even have a healthy selection of server hardware, including cases and motherboards: http://www.centralcomputers.com/commerce/catalog/spcategory.jsp?category_id=1573 Greetings, Jeroen -- Earthquake Magnitude: 4.4 Date: Wednesday, May 8, 2013 14:10:48 UTC Location: Kuril Islands Latitude: 44.1198; Longitude: 147.1659 Depth: 76.00 km From george.herbert at gmail.com Thu May 9 00:45:38 2013 From: george.herbert at gmail.com (George Herbert) Date: Wed, 8 May 2013 17:45:38 -0700 Subject: Data Center Installations In-Reply-To: <518AEDE9.3070802@mompl.net> References: <97cd9e3bdef74966b69501d5ac127aa5@BY2PR05MB079.namprd05.prod.outlook.com> <518AEDE9.3070802@mompl.net> Message-ID: Central Computers is ok on no-name server components, but not at all for rack / cabling / power / management / etc. Micro Center was right next to places I go to eat over there, but all gone. I can almost see Frys off Lawrence/Scott from here, and there's a Graybar 3 miles the other direction. They no longer welcome me at that Graybar with my first name, I spent too much time ordering online for delivery and / or doing datacenters up in SF / the Peninsula, but there were a few years in the 90s... BTW, if you're sweating the cost on your cable wrap velcro, you're missing something. Your time is more valuable than all the above. On Wed, May 8, 2013 at 5:29 PM, Jeroen van Aart wrote: > On 05/01/2013 10:05 PM, shawn wilson wrote: > >> I'm more impressed with MicroCenter than Frys (at least the Frys south if >> SF). >> > > Too bad the Micro Center in Santa Clara along hwy 101 closed shop a year > or so ago. According to them the owner of the building raised the lease > price too much. The closest one for the bay Area now is LA... But I too > liked them better than frys. It looks like in frys most time I spend > dodging pushy sales people. You can't look at a thing for more than 10 > seconds before some creepster walks over asking if you need help. > > A good alternative for the Bay Area is Central Computers. They even have a > healthy selection of server hardware, including cases and motherboards: > http://www.centralcomputers.**com/commerce/catalog/** > spcategory.jsp?category_id=**1573 > > Greetings, > Jeroen > > -- > Earthquake Magnitude: 4.4 > Date: Wednesday, May 8, 2013 14:10:48 UTC > Location: Kuril Islands > Latitude: 44.1198; Longitude: 147.1659 > Depth: 76.00 km > > -- -george william herbert george.herbert at gmail.com From jeff-kell at utc.edu Thu May 9 03:21:27 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 8 May 2013 23:21:27 -0400 Subject: Entry level WDM gear? Message-ID: <518B1637.20002@utc.edu> Apologies if this is a "dumb newbie" question, but this is one area of networking where I remain a virgin :) We have a local loop fiber to a regional fiber hut that has served us well for several years. It's carrying a 1550nm ER 10G circuit at the moment, but we're looking at another one, possibly two (or more) in the near future. Getting another dark pair is "complicated" so we're exploring options to [C|D]WDM multiple lambdas over the existing fiber. Ciena/Cyan/etc are way over our non-existant budget... what is the going recommendation to throw say 4-8 lambdas over a dark pair without breaking the bank? :) Jeff From swmike at swm.pp.se Thu May 9 03:40:40 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 9 May 2013 05:40:40 +0200 (CEST) Subject: Entry level WDM gear? In-Reply-To: <518B1637.20002@utc.edu> References: <518B1637.20002@utc.edu> Message-ID: On Wed, 8 May 2013, Jeff Kell wrote: > Ciena/Cyan/etc are way over our non-existant budget... what is the > going recommendation to throw say 4-8 lambdas over a dark pair without > breaking the bank? :) You purchase a CWDM filter for each end, purchase CWDM optical modules for each end for the lambads you want use. Something like this: Prices for optics depends on attenuation for the link, but for instance: -- Mikael Abrahamsson email: swmike at swm.pp.se From tyler.haske at gmail.com Thu May 9 12:14:46 2013 From: tyler.haske at gmail.com (Tyler Haske) Date: Thu, 9 May 2013 08:14:46 -0400 Subject: Per Site QOS policy with Cisco IOS-XE In-Reply-To: References: Message-ID: Wes, If the router is running HQF code for QoS [really anything later then 12.4(20)T], it should support this kind of hierarchy. It's a common policy I have customers implement all the time. http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/qos_frhqf_support.html On Wed, May 8, 2013 at 10:54 AM, Wes Tribble wrote: > Tyler, > > I would love to implement a policy similar to that one. Unfortunately, I > don't believe you can have two tiers of shaping like that in a policy. > Most of the two-tiered shaping solutions I have seen involve using a VRF to > shape to the aggregate rate and then use a second VRF to shape to the site > rate. This is to get around the three-tier policy limitations. > > With that said, if you have something like that configured and working, I > would love to see the config and the "show policy-map interface" output. > That is exactly the kind of policy I was originally looking to implement, > but then I ran into those limitations. > > Thanks for the reply. Great idea in concept. If only we could implement. > From welisson at conectcor.com.br Thu May 9 12:37:50 2013 From: welisson at conectcor.com.br (Welisson) Date: Thu, 09 May 2013 09:37:50 -0300 Subject: Problem watch video Youtube in Brazil In-Reply-To: References: Message-ID: <518B989E.6020901@conectcor.com.br> Hello, Dears, I'd like know if someone is having any kind problem with watch movies on Youtube, because the access of in Brazil is a lot bad, between 4h and 10(p.m utc -3)? Best Regards Welisson Tom? From westribble at gmail.com Thu May 9 12:58:11 2013 From: westribble at gmail.com (Wes Tribble) Date: Thu, 9 May 2013 07:58:11 -0500 Subject: Per Site QOS policy with Cisco IOS-XE In-Reply-To: References: Message-ID: Thanks for the information Tyler, I will have to play around with that kind of policy in my lab. What would you suggest if you are oversubscribing the interface? With the child policy inheriting the bandwith of the parent shaper, wouldn't I run out of bandwidth allocation before I built all the shapers for all of my 29 sites? On Thu, May 9, 2013 at 7:14 AM, Tyler Haske wrote: > Wes, > > If the router is running HQF code for QoS [really anything later then > 12.4(20)T], it should support this kind of hierarchy. It's a common policy > I have customers implement all the time. > > > http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/qos_frhqf_support.html > > > > On Wed, May 8, 2013 at 10:54 AM, Wes Tribble wrote: > >> Tyler, >> >> I would love to implement a policy similar to that one. Unfortunately, I >> don't believe you can have two tiers of shaping like that in a policy. >> Most of the two-tiered shaping solutions I have seen involve using a VRF to >> shape to the aggregate rate and then use a second VRF to shape to the site >> rate. This is to get around the three-tier policy limitations. >> >> With that said, if you have something like that configured and working, I >> would love to see the config and the "show policy-map interface" output. >> That is exactly the kind of policy I was originally looking to implement, >> but then I ran into those limitations. >> >> Thanks for the reply. Great idea in concept. If only we could implement. >> > From tyler.haske at gmail.com Thu May 9 13:33:45 2013 From: tyler.haske at gmail.com (Tyler Haske) Date: Thu, 9 May 2013 09:33:45 -0400 Subject: Per Site QOS policy with Cisco IOS-XE In-Reply-To: References: Message-ID: Wes, The earlier policy doesn't use bandwidth commands, hence, it doesn't *subscribe* anything. The only thing it does is ensures that individual sites do not exceed their shaped rate. You could add bandwidth statements if you wanted to ensure a certain site always is guaranteed a certain amount of bandwidth from the parent shaper. You can't oversubscribe with the bandwidth command. policy-map parent_shaper class class-default shape average 100000000 service-policy site_shaper policy-map site_shaper class t1_site shape average 1536000 bandwidth percent 1 service-policy qos_global class multilink_site shape average 3072000 bandwidth percent 2 service-policy qos_global class class-default bandwidth percent 97 service-policy qos_global policy-map qos_global ! ... whatever you want here. This would make sure that large sites don't stare out small spoke sites for bandwidth. On Thu, May 9, 2013 at 8:58 AM, Wes Tribble wrote: > Thanks for the information Tyler, I will have to play around with that > kind of policy in my lab. What would you suggest if you are > oversubscribing the interface? With the child policy inheriting the > bandwith of the parent shaper, wouldn't I run out of bandwidth allocation > before I built all the shapers for all of my 29 sites? > From westribble at gmail.com Thu May 9 14:40:15 2013 From: westribble at gmail.com (Wes Tribble) Date: Thu, 9 May 2013 09:40:15 -0500 Subject: Per Site QOS policy with Cisco IOS-XE In-Reply-To: References: Message-ID: Tyler, Tyler, I already had a case open with TAC on this issue. This is what the CCIE assigned to the case is saying about that type of policy: Hi Wesley, Yes, I?m afraid that configuration is not possible. We can only mark or police traffic on this child policy. You will see the following message when trying to attach the service-policy to the interface: --- ASR10004(config-if)#service-policy output parent_shaper Cannot attach queuing-based child policy to a non-queuing based class *This is what I sent to her:* So this configuration is not possible? policy-map parent_shaper class class-default shape average 100000000 < --- 100Mbps parent shaper. service-policy site_shaper policy-map site_shaper class t1_site shape average 1536000 service-policy qos_global class multilink_site shape average 3072000 service-policy qos_global class class-default service-policy qos_global policy-map qos_global class VOICE priority percent 25 set dscp ef class AF41 bandwidth percent 40 set dscp af41 queue-limit 1024 packets class class-default fair-queue set dscp af21 queue-limit 1024 packets On Thu, May 9, 2013 at 8:33 AM, Tyler Haske wrote: > Wes, > > The earlier policy doesn't use bandwidth commands, hence, it doesn't > *subscribe* anything. The only thing it does is ensures that individual > sites do not exceed their shaped rate. You could add bandwidth statements > if you wanted to ensure a certain site always is guaranteed a certain > amount of bandwidth from the parent shaper. You can't oversubscribe with > the bandwidth command. > > > policy-map parent_shaper > class class-default > shape average 100000000 > service-policy site_shaper > > policy-map site_shaper > class t1_site > shape average 1536000 > bandwidth percent 1 > > service-policy qos_global > class multilink_site > shape average 3072000 > bandwidth percent 2 > service-policy qos_global > class class-default > bandwidth percent 97 > service-policy qos_global > > policy-map qos_global > ! ... whatever you want here. > > This would make sure that large sites don't stare out small spoke sites > for bandwidth. > > On Thu, May 9, 2013 at 8:58 AM, Wes Tribble wrote: > >> Thanks for the information Tyler, I will have to play around with that >> kind of policy in my lab. What would you suggest if you are >> oversubscribing the interface? With the child policy inheriting the >> bandwith of the parent shaper, wouldn't I run out of bandwidth allocation >> before I built all the shapers for all of my 29 sites? >> > From jlester at wcs.k12.va.us Thu May 9 14:55:19 2013 From: jlester at wcs.k12.va.us (Jason Lester) Date: Thu, 9 May 2013 10:55:19 -0400 Subject: Per Site QOS policy with Cisco IOS-XE In-Reply-To: References: Message-ID: We had a similar problem years ago with a frame-relay <---> IMA setup. The hub end was a multiplexed ATM circuit with PVC's to each site's frame-relay circuit. The IMA speed was equal to the aggregate speed of each site's CIR. It worked great until all the sites were bursting above CIR. VoIP call quality would go really bad when that happened (early mornings mainly.) QoS policies could not be maintained between the frame and ATM sides. Sprint (support contract on the CPE) and MCI (circuits) engineers finally decided to run PPP over the native protocols on each end and then apply QoS to the PPP sessions. That fixed the problem. I am not sure if something like that is possible in your case or not though as I am not familiar with MPLS. I tried to find the config, but I no longer have it. I remember it used virtual templates, but don't remember the specifics. Jason On Thu, May 9, 2013 at 10:40 AM, Wes Tribble wrote: > Tyler, > > Tyler, > > I already had a case open with TAC on this issue. This is what the CCIE > assigned to the case is saying about that type of policy: > > > Hi Wesley, > > > Yes, I?m afraid that configuration is not possible. We can only mark or > police traffic on this child policy. > > > > You will see the following message when trying to attach the service-policy > to the interface: > > > > --- > > ASR10004(config-if)#service-policy output parent_shaper > Cannot attach queuing-based child policy to a non-queuing based class > > *This is what I sent to her:* > > So this configuration is not possible? > > policy-map parent_shaper > class class-default > shape average 100000000 < --- 100Mbps parent shaper. > service-policy site_shaper > > policy-map site_shaper > class t1_site > shape average 1536000 > service-policy qos_global > class multilink_site > shape average 3072000 > service-policy qos_global > class class-default > service-policy qos_global > > policy-map qos_global > class VOICE > priority percent 25 > set dscp ef > class AF41 > bandwidth percent 40 > set dscp af41 > queue-limit 1024 packets > class class-default > fair-queue > set dscp af21 > queue-limit 1024 packets > > On Thu, May 9, 2013 at 8:33 AM, Tyler Haske wrote: > > > Wes, > > > > The earlier policy doesn't use bandwidth commands, hence, it doesn't > > *subscribe* anything. The only thing it does is ensures that individual > > sites do not exceed their shaped rate. You could add bandwidth statements > > if you wanted to ensure a certain site always is guaranteed a certain > > amount of bandwidth from the parent shaper. You can't oversubscribe with > > the bandwidth command. > > > > > > policy-map parent_shaper > > class class-default > > shape average 100000000 > > service-policy site_shaper > > > > policy-map site_shaper > > class t1_site > > shape average 1536000 > > bandwidth percent 1 > > > > service-policy qos_global > > class multilink_site > > shape average 3072000 > > bandwidth percent 2 > > service-policy qos_global > > class class-default > > bandwidth percent 97 > > service-policy qos_global > > > > policy-map qos_global > > ! ... whatever you want here. > > > > This would make sure that large sites don't stare out small spoke sites > > for bandwidth. > > > > On Thu, May 9, 2013 at 8:58 AM, Wes Tribble > wrote: > > > >> Thanks for the information Tyler, I will have to play around with that > >> kind of policy in my lab. What would you suggest if you are > >> oversubscribing the interface? With the child policy inheriting the > >> bandwith of the parent shaper, wouldn't I run out of bandwidth > allocation > >> before I built all the shapers for all of my 29 sites? > >> > > > -- Jason Lester Administrator for Instructional Technology Washington County Public Schools Tel: 276-739-3060 Fax: 276-628-1893 http://www.wcs.k12.va.us From jared at puck.nether.net Thu May 9 15:35:41 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 May 2013 11:35:41 -0400 Subject: Open Resolver List, New Orleans, etc.. Message-ID: I am putting the finishing touches on a presentation I will be making later this week at the DNS-OARC meeting, but I also wanted to ask anyone here if they had data/ideas of items they are interested in seeing from the Open Resolver Project. We perform a weekly scan of the IPv4 space looking for DNS servers that can be used in an amplification attack. Some interesting data: about 46% of the IPs that respond to a DNS query do not respond from port 53, meaning they are "broken" in some interesting way. I encourage folks to check your IP space here: http://openresolverproject.org/ You can also e-mail the project to get direct access to per-ASN reports. That email needs to come from a contact in the RIR object, or from a corporate address that can be easily identified as related to your org. If you are an ISAC or similar, we can also assist you. Thanks, - jared From westribble at gmail.com Thu May 9 16:10:19 2013 From: westribble at gmail.com (Wes Tribble) Date: Thu, 9 May 2013 11:10:19 -0500 Subject: Per Site QOS policy with Cisco IOS-XE In-Reply-To: References: Message-ID: Tyler, Thank you very much. I took off the bandwidth reservations on the child shapers and I was able to apply to an 1841 series router in my lab. Either my TAC engineer is off base or there is some limitatin with the ASR that does not exist for vanilla IOS. QUOTE: The earlier policy doesn't use bandwidth commands, hence, it doesn't *subscribe* anything. The only thing it does is ensures that individual sites do not exceed their shaped rate. You could add bandwidth statements if you wanted to ensure a certain site always is guaranteed a certain amount of bandwidth from the parent shaper. You can't oversubscribe with the bandwidth command. Here is a short snippet of the show policy-map int, i cut it off after two sites for brevity. Service-policy output: BigShaper Class-map: class-default (match-any) 31694 packets, 4932119 bytes 30 second offered rate 129000 bps, drop rate 0 bps Match: any Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 31723/4962574 shape (average) cir 50000000, bc 1250000, be 1250000 target shape rate 50000000 Service-policy : PerSiteShaper Class-map: LittleRock (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: access-group name LittleRockSubnets 0 packets, 0 bytes 30 second rate 0 bps Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 shape (average) cir 4608000, bc 115200, be 115200 target shape rate 4608000 Service-policy : Scheduler queue stats for all priority classes: queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 Class-map: VOICE (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: ip dscp ef (46) 0 packets, 0 bytes 30 second rate 0 bps Match: ip dscp cs3 (24) 0 packets, 0 bytes 30 second rate 0 bps Match: ip dscp af31 (26) 0 packets, 0 bytes 30 second rate 0 bps Priority: 50% (28 kbps), burst bytes 1500, b/w exceed drops: 0 QoS Set dscp ef Packets marked 0 Class-map: AF41 (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: ip dscp af41 (34) 0 packets, 0 bytes 30 second rate 0 bps Match: access-group name eCustodyClass 0 packets, 0 bytes 30 second rate 0 bps Match: access-group name BloombergClass 0 packets, 0 bytes 30 second rate 0 bps Match: access-group name LiquidPointClass 0 packets, 0 bytes 30 second rate 0 bps Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 bandwidth 25% (14 kbps) QoS Set dscp af41 Packets marked 0 Class-map: class-default (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: any Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0 (pkts output/bytes output) 0/0 Fair-queue: per-flow queue limit 16 QoS Set dscp af21 Packets marked 0 Exp-weight-constant: 9 (1/512) Mean queue depth: 0 packets dscp Transmitted ECN Random drop Tail/Flow drop Minimum Maximum Mark pkts/bytes marked pkts/bytes pkts/bytes thresh thresh prob Class-map: Chicago (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: access-group name ChicagoSubnets 0 packets, 0 bytes 30 second rate 0 bps Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 shape (average) cir 10000000, bc 250000, be 250000 target shape rate 10000000 Service-policy : Scheduler queue stats for all priority classes: queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 Class-map: VOICE (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: ip dscp ef (46) 0 packets, 0 bytes 30 second rate 0 bps Match: ip dscp cs3 (24) 0 packets, 0 bytes 30 second rate 0 bps Match: ip dscp af31 (26) 0 packets, 0 bytes 30 second rate 0 bps Priority: 50% (28 kbps), burst bytes 1500, b/w exceed drops: 0 QoS Set dscp ef Packets marked 0 Class-map: AF41 (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: ip dscp af41 (34) 0 packets, 0 bytes 30 second rate 0 bps Match: access-group name eCustodyClass 0 packets, 0 bytes 30 second rate 0 bps Match: access-group name BloombergClass 0 packets, 0 bytes 30 second rate 0 bps Match: access-group name LiquidPointClass 0 packets, 0 bytes 30 second rate 0 bps Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 bandwidth 25% (14 kbps) QoS Set dscp af41 Packets marked 0 Class-map: class-default (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: any Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0 (pkts output/bytes output) 0/0 Fair-queue: per-flow queue limit 16 QoS Set dscp af21 Packets marked 0 Exp-weight-constant: 9 (1/512) Mean queue depth: 0 packets dscp Transmitted ECN Random drop Tail/Flow drop Minimum Maximum Mark pkts/bytes marked pkts/bytes pkts/bytes thresh thresh prob From ahebert at pubnix.net Thu May 9 17:14:42 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 09 May 2013 13:14:42 -0400 Subject: Open Resolvers pseudo Honey Pot (Was: Open Resolver Problems) In-Reply-To: References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> Message-ID: <518BD982.60709@pubnix.net> ( Ok, ok, another bad customer =D ) Starting today at 5h15m EST... There is a bigger than usual DDoS amplification against the IP's listed below. Granted root servers query is barely 1k while the usual isc.org is 3.5k and this is a "possible" 15Mbps from this one source but still :( PS: If you're a Tier and wish to track down the *^%$*#@ source ISP's to explain to them the joy of BCP38... Contact me off list, from your corporate email address, and I'll provide you with the IP of that server. ----- IP are targeted for DDoS amplification. Format: [query] 94.23.42.215 2128 . IN ANY +E 208.98.25.130 3079 . IN ANY +E 188.134.46.102 2639 . IN ANY +E 108.61.239.105 2270 . IN ANY +E 95.129.166.186 2416 . IN ANY +E 176.9.210.53 2839 . IN ANY +E 145.53.65.130 2326 . IN ANY +E 99.198.100.86 1223 . IN ANY +E 37.59.72.74 2508 . IN ANY +E 199.83.133.42 2392 . IN ANY +E 74.63.248.210 1481 . IN ANY +E 173.199.68.62 1178 . IN ANY +E 82.80.17.4 2666 . IN ANY +E 188.162.228.50 1075 . IN ANY +E 79.225.4.183 1014 . IN ANY +E 78.108.79.171 1291 . IN ANY +E 31.53.123.192 1093 . IN ANY +E 90.3.194.151 1245 . IN ANY +E 27.50.70.191 1304 . IN ANY +E 198.7.63.39 1579 . IN ANY +E 81.220.28.129 1103 . IN ANY +E 198.105.218.12 1110 . IN ANY +E 86.160.85.37 1128 . IN ANY +E 184.95.35.194 1237 . IN ANY +E 134.255.237.244 1245 . IN ANY +E 178.32.36.67 1588 . IN ANY +E 204.45.55.8 1419 . IN ANY +E 95.211.209.182 1520 . IN ANY +E 80.192.224.22 1430 . IN ANY +E 24.244.248.8 1414 . IN ANY +E 79.71.69.165 1090 . IN ANY +E 24.244.248.57 1364 . IN ANY +E 82.132.226.216 1079 . IN ANY +E 69.162.97.99 1601 . IN ANY +E ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From wbailey at satelliteintelligencegroup.com Thu May 9 17:18:04 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 9 May 2013 17:18:04 +0000 Subject: Open Resolvers pseudo Honey Pot (Was: Open Resolver Problems) In-Reply-To: <518BD982.60709@pubnix.net> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> , <518BD982.60709@pubnix.net> Message-ID: <37584iqhlg7jjy4b73cqs8g1.1368119882794@email.android.com> Is anyone in particular being pocketed, or are these random addresses? Sent from my Mobile Device. -------- Original message -------- From: Alain Hebert Date: 05/09/2013 10:16 AM (GMT-08:00) To: nanog at nanog.org Subject: Open Resolvers pseudo Honey Pot (Was: Open Resolver Problems) ( Ok, ok, another bad customer =D ) Starting today at 5h15m EST... There is a bigger than usual DDoS amplification against the IP's listed below. Granted root servers query is barely 1k while the usual isc.org is 3.5k and this is a "possible" 15Mbps from this one source but still :( PS: If you're a Tier and wish to track down the *^%$*#@ source ISP's to explain to them the joy of BCP38... Contact me off list, from your corporate email address, and I'll provide you with the IP of that server. ----- IP are targeted for DDoS amplification. Format: [query] 94.23.42.215 2128 . IN ANY +E 208.98.25.130 3079 . IN ANY +E 188.134.46.102 2639 . IN ANY +E 108.61.239.105 2270 . IN ANY +E 95.129.166.186 2416 . IN ANY +E 176.9.210.53 2839 . IN ANY +E 145.53.65.130 2326 . IN ANY +E 99.198.100.86 1223 . IN ANY +E 37.59.72.74 2508 . IN ANY +E 199.83.133.42 2392 . IN ANY +E 74.63.248.210 1481 . IN ANY +E 173.199.68.62 1178 . IN ANY +E 82.80.17.4 2666 . IN ANY +E 188.162.228.50 1075 . IN ANY +E 79.225.4.183 1014 . IN ANY +E 78.108.79.171 1291 . IN ANY +E 31.53.123.192 1093 . IN ANY +E 90.3.194.151 1245 . IN ANY +E 27.50.70.191 1304 . IN ANY +E 198.7.63.39 1579 . IN ANY +E 81.220.28.129 1103 . IN ANY +E 198.105.218.12 1110 . IN ANY +E 86.160.85.37 1128 . IN ANY +E 184.95.35.194 1237 . IN ANY +E 134.255.237.244 1245 . IN ANY +E 178.32.36.67 1588 . IN ANY +E 204.45.55.8 1419 . IN ANY +E 95.211.209.182 1520 . IN ANY +E 80.192.224.22 1430 . IN ANY +E 24.244.248.8 1414 . IN ANY +E 79.71.69.165 1090 . IN ANY +E 24.244.248.57 1364 . IN ANY +E 82.132.226.216 1079 . IN ANY +E 69.162.97.99 1601 . IN ANY +E ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From ahebert at pubnix.net Thu May 9 17:31:31 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 09 May 2013 13:31:31 -0400 Subject: Open Resolvers pseudo Honey Pot (Was: Open Resolver Problems) In-Reply-To: <37584iqhlg7jjy4b73cqs8g1.1368119882794@email.android.com> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> , <518BD982.60709@pubnix.net> <37584iqhlg7jjy4b73cqs8g1.1368119882794@email.android.com> Message-ID: <518BDD73.5050904@pubnix.net> It looks like to be a service and some of their customers. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 05/09/13 13:18, Warren Bailey wrote: > 94.23.42.215 > 2128 . IN ANY +E > 208.98.25.130 > 3079 . IN ANY +E > 188.134.46.102 > 2639 . IN ANY +E > 108.61.239.105 > 2270 . IN ANY +E > 95.129.166.186 > 2416 . IN ANY +E > 176.9.210.53 > 2839 . IN ANY +E > 145.53.65.130 > 2326 . IN ANY +E > 99.198.100.86 > 1223 . IN ANY +E > 37.59.72.74 > 2508 . IN ANY +E > 199.83.133.42 > 2392 . IN ANY +E > 74.63.248.210 > 1481 . IN ANY +E > 173.199.68.62 > 1178 . IN ANY +E > 82.80.17.4 > 2666 . IN ANY +E > 188.162.228.50 > 1075 . IN ANY +E > 79.225.4.183 > 1014 . IN ANY +E > 78.108.79.171 > 1291 . IN ANY +E > 31.53.123.192 > 1093 . IN ANY +E > 90.3.194.151 > 1245 . IN ANY +E > 27.50.70.191 > 1304 . IN ANY +E > 198.7.63.39 > 1579 . IN ANY +E > 81.220.28.129 > 1103 . IN ANY +E > 198.105.218.12 > 1110 . IN ANY +E > 86.160.85.37 > 1128 . IN ANY +E > 184.95.35.194 > 1237 . IN ANY +E > 134.255.237.244 > 1245 . IN ANY +E > 178.32.36.67 > 1588 . IN ANY +E > 204.45.55.8 > 1419 . IN ANY +E > 95.211.209.182 > 1520 . IN ANY +E > 80.192.224.22 > 1430 . IN ANY +E > 24.244.248.8 > 1414 . IN ANY +E > 79.71.69.165 > 1090 . IN ANY +E > 24.244.248.57 > 1364 . IN ANY +E > 82.132.226.216 > 1079 . IN ANY +E > 69.162.97.99 > 1601 . IN ANY +E From nick at foobar.org Thu May 9 17:40:40 2013 From: nick at foobar.org (Nick Hilliard) Date: Thu, 09 May 2013 18:40:40 +0100 Subject: Per Site QOS policy with Cisco IOS-XE In-Reply-To: References: Message-ID: <518BDF98.1050508@foobar.org> On 09/05/2013 17:10, Wes Tribble wrote: > Thank you very much. I took off the bandwidth reservations on the child > shapers and I was able to apply to an 1841 series router in my lab. Either > my TAC engineer is off base or there is some limitatin with the ASR that > does not exist for vanilla IOS. you shouldn't be surprised by this. the asr1k platform implements qos using dedicated silicon, which means that it's less flexible but much faster. The 1800 series routers handle everything using a single route processor and shared dram, which means that they are more flexible but much slower. Nick From mrodriguez at cladirect.com Thu May 9 19:38:29 2013 From: mrodriguez at cladirect.com (Mauricio Rodriguez) Date: Thu, 9 May 2013 15:38:29 -0400 Subject: Entry level WDM gear? Message-ID: Jeff, Take a look at ECI -- http://www.ecitele.com, or BTI -- http://www.btisystems.com/home.aspx. They have both passive and active systems, depending on your needs. Regards, *Mauricio R Rodriguez* *Senior Systems Engineer *CLAdirect (http://www.cladirect.com) From marka at isc.org Thu May 9 23:03:56 2013 From: marka at isc.org (Mark Andrews) Date: Fri, 10 May 2013 09:03:56 +1000 Subject: Open Resolvers pseudo Honey Pot (Was: Open Resolver Problems) In-Reply-To: Your message of "Thu, 09 May 2013 13:14:42 -0400." <518BD982.60709@pubnix.net> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> Message-ID: <20130509230356.BA789341BF16@drugs.dv.isc.org> In message <518BD982.60709 at pubnix.net>, Alain Hebert writes: > ( Ok, ok, another bad customer =D ) > > Starting today at 5h15m EST... > > There is a bigger than usual DDoS amplification against the IP's > listed below. > > Granted root servers query is barely 1k while the usual isc.org is > 3.5k and this is a "possible" 15Mbps from this one source but still :( With a validating resolver "dig any . +edns" return a 1872 byte payload. "dig any . +dnssec" return a 2030 byte payload. (difference is NS RRSIG records) Getting the DNSKEY records included isn't hard. Throw a single DNSKEY query into the stream once a day/hour and it will be cached for 48 hours. If you have the SOA cached as well it gets to "dig any . +edns" return a 2087 byte payload. "dig any . +dnssec" return a 2245 byte payload. Mark > PS: > > If you're a Tier and wish to track down the *^%$*#@ source ISP's to > explain to them the joy of BCP38... > > Contact me off list, from your corporate email address, and I'll > provide you with the IP of that server. > > ----- IP are targeted for DDoS amplification. > > Format: > > > [query] > > 94.23.42.215 > 2128 . IN ANY +E > 208.98.25.130 > 3079 . IN ANY +E > 188.134.46.102 > 2639 . IN ANY +E > 108.61.239.105 > 2270 . IN ANY +E > 95.129.166.186 > 2416 . IN ANY +E > 176.9.210.53 > 2839 . IN ANY +E > 145.53.65.130 > 2326 . IN ANY +E > 99.198.100.86 > 1223 . IN ANY +E > 37.59.72.74 > 2508 . IN ANY +E > 199.83.133.42 > 2392 . IN ANY +E > 74.63.248.210 > 1481 . IN ANY +E > 173.199.68.62 > 1178 . IN ANY +E > 82.80.17.4 > 2666 . IN ANY +E > 188.162.228.50 > 1075 . IN ANY +E > 79.225.4.183 > 1014 . IN ANY +E > 78.108.79.171 > 1291 . IN ANY +E > 31.53.123.192 > 1093 . IN ANY +E > 90.3.194.151 > 1245 . IN ANY +E > 27.50.70.191 > 1304 . IN ANY +E > 198.7.63.39 > 1579 . IN ANY +E > 81.220.28.129 > 1103 . IN ANY +E > 198.105.218.12 > 1110 . IN ANY +E > 86.160.85.37 > 1128 . IN ANY +E > 184.95.35.194 > 1237 . IN ANY +E > 134.255.237.244 > 1245 . IN ANY +E > 178.32.36.67 > 1588 . IN ANY +E > 204.45.55.8 > 1419 . IN ANY +E > 95.211.209.182 > 1520 . IN ANY +E > 80.192.224.22 > 1430 . IN ANY +E > 24.244.248.8 > 1414 . IN ANY +E > 79.71.69.165 > 1090 . IN ANY +E > 24.244.248.57 > 1364 . IN ANY +E > 82.132.226.216 > 1079 . IN ANY +E > 69.162.97.99 > 1601 . IN ANY +E > > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jlewis at lewis.org Thu May 9 23:32:11 2013 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 9 May 2013 19:32:11 -0400 (EDT) Subject: Open Resolver List, New Orleans, etc.. In-Reply-To: References: Message-ID: On Thu, 9 May 2013, Jared Mauch wrote: > Some interesting data: about 46% of the IPs that respond to a DNS query > do not respond from port 53, meaning they are "broken" in some > interesting way. Maybe I'm not being very imaginative, but how can something from !53 be considered a DNS response to a query sent to port 53? Can you give some examples of the sorts of packets that fall into this rather large % of ill-behaved hosts? Are you sure you're not treating things like icmp port unreachable as a "!udp/53 src response"? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From David.Wilde at aarnet.edu.au Fri May 10 00:10:31 2013 From: David.Wilde at aarnet.edu.au (David Wilde) Date: Fri, 10 May 2013 00:10:31 +0000 Subject: Entry level WDM gear? In-Reply-To: <518B1637.20002@utc.edu> References: <518B1637.20002@utc.edu> Message-ID: <3AFB87B02BA2FE42B4EDEC3CDAFE58823B6C0A6A@SYD-VM-MBX1.ms.aarnet.edu.au> Hi Jeff, Cisco make a passive CWDM/EWDM solution for this. http://www.cisco.com/en/US/prod/collateral/modules/ps5455/ps6575/product_data_sheet0900aecd8029d01b_ps708_Products_Data_Sheet.html You need to order a CWDM-MUX8A= for each end, plus the CWDM-CHASSIS-2= to rack-mount them. Then, plug your dark fibre into the trunk port of each mux, and use pairs of coloured optics instead of your ER. The muxes carry 8xlambdas: 1470, 1490, 1510, 1530, 1550, 1570, 1590, and 1610. I don't believe Cisco make CWDM 10G optics however, so you may have to get compatible optics. For 8 additional wavelengths, you could also insert an EWDM mux into the path at each end: http://www.cisco.com/en/US/prod/collateral/modules/ps5455/product_data_sheet0900aecd806a1c36.html ie. a EWDM-MUX8= for each end - it fits into the same rack-mount chassis. This allows you to carry 8 more channels, at DWDM spacings: 1538.98, 1539.77 etc. Cisco do make 10G optics at these wavelengths; X2, Xenpak etc. Having both types of mux in the path can add a fair bit of loss though, and there's an optional amplifier unit which can be plugged into the EWDM muxes: EWDM-OA=. Regards, David > -----Original Message----- > From: Jeff Kell [mailto:jeff-kell at utc.edu] > Sent: Thursday, 9 May 2013 1:21 PM > To: nanog at nanog.org > Subject: Entry level WDM gear? > > Apologies if this is a "dumb newbie" question, but this is one area of > networking where I remain a virgin :) > > We have a local loop fiber to a regional fiber hut that has served us well for > several years. It's carrying a 1550nm ER 10G circuit at the moment, but we're > looking at another one, possibly two (or more) in the near future. Getting > another dark pair is "complicated" so we're exploring options to [C|D]WDM > multiple lambdas over the existing fiber. > > Ciena/Cyan/etc are way over our non-existant budget... what is the going > recommendation to throw say 4-8 lambdas over a dark pair without breaking > the bank? :) > > Jeff > From mysidia at gmail.com Fri May 10 00:26:35 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 9 May 2013 19:26:35 -0500 Subject: Open Resolver List, New Orleans, etc.. In-Reply-To: References: Message-ID: On 5/9/13, Jared Mauch wrote: On a totally unrelated note... the document at that URL looks visually almost exactly like the CentOS stock apache 2 test page. It's, so similar in appearance, that when opening it, at first, I thought it a broken link instead of an actual website.... > I encourage folks to check your IP space here: > > http://openresolverproject.org/ -- -JH From jared at puck.nether.net Fri May 10 00:32:03 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 May 2013 20:32:03 -0400 Subject: Open Resolver List, New Orleans, etc.. In-Reply-To: References: Message-ID: <38370DA9-EADA-4B1A-96D4-C732831E5DB5@puck.nether.net> On May 9, 2013, at 7:32 PM, Jon Lewis wrote: > On Thu, 9 May 2013, Jared Mauch wrote: > >> Some interesting data: about 46% of the IPs that respond to a DNS query do not respond from port 53, meaning they are "broken" in some interesting way. > > Maybe I'm not being very imaginative, but how can something from !53 be considered a DNS response to a query sent to port 53? Can you give some examples of the sorts of packets that fall into this rather large % of ill-behaved hosts? Are you sure you're not treating things like icmp port unreachable as a "!udp/53 src response"? IP1:Port:IP-Probed:Responding-IP:time_t:RCODE:RA:CorrectAnswerInPacket Here's a sample excerpt: IP1:14474:122.177.40.2:NULL:1367712184.690540:0:1:1 IP1:10316:123.26.39.2:NULL:1367712184.690683:0:1:1 IP1:15218:5.11.41.2:NULL:1367712184.691114:0:1:1 IP1:21388:186.31.41.2:NULL:1367712184.691402:0:1:1 IP1:11161:87.21.41.2:NULL:1367712184.691693:0:1:1 IP1:23884:88.249.40.2:NULL:1367712184.692264:0:1:1 IP1:12707:77.51.41.2:NULL:1367712184.692833:0:1:1 IP1:16290:190.86.41.2:NULL:1367712184.693118:0:1:1 IP1:10169:151.48.41.2:NULL:1367712184.694703:0:1:1 IP1:20885:112.209.40.2:NULL:1367712184.694992:0:1:1 I have the raw packet data for these. They were on a UDP socket, not some tcpdump output parsing snafu? :) I have many more of these in the dataset. I'm thinking about flagging those that aren't from udp/53 and giving a pointer to things like CPE device firmware that causes problem. I've got a lot of private data on that which I can't share, either because the vendor is delivering fixed firmware or something else. - Jared From jared at puck.nether.net Fri May 10 00:37:18 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 May 2013 20:37:18 -0400 Subject: Open Resolver List, New Orleans, etc.. In-Reply-To: References: Message-ID: <7A1C8E44-4E70-421B-8D3E-0384AC733598@puck.nether.net> On May 9, 2013, at 8:26 PM, Jimmy Hess wrote: > On 5/9/13, Jared Mauch wrote: > > On a totally unrelated note... the document at that URL looks > visually almost exactly like the CentOS stock apache 2 test page. > > It's, so similar in appearance, that when opening it, at first, I > thought it a broken link instead of an actual website.... I think it looks very minimal for a webpage :) If you want to sign-up with your HTML skills, let me know off list. I want to make getting the data simple. I'm also thinking of making an alert pop up if the exact IP you visit from is in the database? A few weeks ago I fingerprinted all the DNS servers. All DNS servers in the database: http://openresolverproject.org/version.bind.20130421.final.txt All Open Resolvers in the database: http://openresolverproject.org/version.bind.report.txt - Jared From ag4ve.us at gmail.com Fri May 10 02:52:06 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 9 May 2013 22:52:06 -0400 Subject: bind verbose logging Message-ID: In this log line, what is -EDC? I've also noticed +, -, -E, and -ED but I have no Idea what they are (called/represent). 08-May-2013 08:04:49.751 client 1.2.3.4#48747 (ns2.example.com): query: ns2.example.com IN AAAA -EDC (1.2.3.4) Also, I'm writing a parser and we're only loging 'queries' but if someone has examples / schemas for the other categories, I'd like to integrate that. http://www.zytrax.com/books/dns/ch7/logging.html From me at staticsafe.ca Fri May 10 02:56:23 2013 From: me at staticsafe.ca (staticsafe) Date: Thu, 09 May 2013 22:56:23 -0400 Subject: bind verbose logging In-Reply-To: References: Message-ID: <518C61D7.3050105@staticsafe.ca> On 5/9/2013 22:52, shawn wilson wrote: > In this log line, what is -EDC? I've also noticed +, -, -E, and -ED > but I have no Idea what they are (called/represent). > > 08-May-2013 08:04:49.751 client 1.2.3.4#48747 (ns2.example.com): > query: ns2.example.com IN AAAA -EDC (1.2.3.4) > > Also, I'm writing a parser and we're only loging 'queries' but if > someone has examples / schemas for the other categories, I'd like to > integrate that. > http://www.zytrax.com/books/dns/ch7/logging.html > "+EDC on a query indicates that it is: - Recursive (+) - it has come from a client or a server that is forwarding queries to your server - The sender is using EDNS0 (using larger UDP packet sizes and signalling the size that can be accepted) - The sender understands DNSSEC (D) - this is a request to your server to include any DNSSEC material associated with answer in the query reply. - DNSSEC validation checking is disabled (C) - the sender wants the answer anyway, even if the validation checks fail." Source - https://kb.isc.org/article/AA-00434/0/What-do-EDC-and-other-letters-I-see-in-my-query-log-mean.html Also see https://www.isc.org/software/bind/documentation for further documentation. -- staticsafe O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post - http://goo.gl/YrmAb Don't CC me! I'm subscribed to whatever list I just posted on. From eyeronic.design at gmail.com Fri May 10 02:58:18 2013 From: eyeronic.design at gmail.com (Mike Hale) Date: Thu, 9 May 2013 19:58:18 -0700 Subject: bind verbose logging In-Reply-To: References: Message-ID: See this: https://kb.isc.org/article/AA-00434/0/What-do-EDC-and-other-letters-I-see-in-my-query-log-mean.html I've written a quick and dirty logging mechanism which stores the bind logs in a mysql database in various fields. It works well for the great majority of queries...happy to share the bash script if you're interested. On Thu, May 9, 2013 at 7:52 PM, shawn wilson wrote: > In this log line, what is -EDC? I've also noticed +, -, -E, and -ED > but I have no Idea what they are (called/represent). > > 08-May-2013 08:04:49.751 client 1.2.3.4#48747 (ns2.example.com): > query: ns2.example.com IN AAAA -EDC (1.2.3.4) > > Also, I'm writing a parser and we're only loging 'queries' but if > someone has examples / schemas for the other categories, I'd like to > integrate that. > http://www.zytrax.com/books/dns/ch7/logging.html > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From ag4ve.us at gmail.com Fri May 10 03:14:38 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 9 May 2013 23:14:38 -0400 Subject: bind verbose logging In-Reply-To: <518C61D7.3050105@staticsafe.ca> References: <518C61D7.3050105@staticsafe.ca> Message-ID: Thanks, that's what I'm looking for. Mike, sure I wouldn't mind schema ideas. On Thu, May 9, 2013 at 10:56 PM, staticsafe wrote: > On 5/9/2013 22:52, shawn wilson wrote: >> In this log line, what is -EDC? I've also noticed +, -, -E, and -ED >> but I have no Idea what they are (called/represent). >> >> 08-May-2013 08:04:49.751 client 1.2.3.4#48747 (ns2.example.com): >> query: ns2.example.com IN AAAA -EDC (1.2.3.4) >> >> Also, I'm writing a parser and we're only loging 'queries' but if >> someone has examples / schemas for the other categories, I'd like to >> integrate that. >> http://www.zytrax.com/books/dns/ch7/logging.html >> > > "+EDC on a query indicates that it is: > > - Recursive (+) - it has come from a client or a server that is > forwarding queries to your server > - The sender is using EDNS0 (using larger UDP packet sizes and > signalling the size that can be accepted) > - The sender understands DNSSEC (D) - this is a request to your server > to include any DNSSEC material associated with answer in the query reply. > - DNSSEC validation checking is disabled (C) - the sender wants the > answer anyway, even if the validation checks fail." > > Source - > https://kb.isc.org/article/AA-00434/0/What-do-EDC-and-other-letters-I-see-in-my-query-log-mean.html > > Also see https://www.isc.org/software/bind/documentation for further > documentation. > -- > staticsafe > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > Please don't top post - http://goo.gl/YrmAb > Don't CC me! I'm subscribed to whatever list I just posted on. > From eyeronic.design at gmail.com Fri May 10 03:27:33 2013 From: eyeronic.design at gmail.com (Mike Hale) Date: Thu, 9 May 2013 20:27:33 -0700 Subject: bind verbose logging In-Reply-To: References: <518C61D7.3050105@staticsafe.ca> Message-ID: I'll send over some info tomorrow. Shoot me a reminder if you don't get it by the later afternoon. I wouldn't really call it a schema...it's just a simple field extraction bash script that then generates the sql inserts. Like I said...quick and dirty. Afte coding it from scratch, I'm starting to like the idea of using Splunk as a front-end to analyze the logs. You may want to look at using that rather than coding one by hand. The free version can index 500 megs a day...which is a *lot* of queries. On Thu, May 9, 2013 at 8:14 PM, shawn wilson wrote: > Thanks, that's what I'm looking for. > > Mike, sure I wouldn't mind schema ideas. > > On Thu, May 9, 2013 at 10:56 PM, staticsafe wrote: >> On 5/9/2013 22:52, shawn wilson wrote: >>> In this log line, what is -EDC? I've also noticed +, -, -E, and -ED >>> but I have no Idea what they are (called/represent). >>> >>> 08-May-2013 08:04:49.751 client 1.2.3.4#48747 (ns2.example.com): >>> query: ns2.example.com IN AAAA -EDC (1.2.3.4) >>> >>> Also, I'm writing a parser and we're only loging 'queries' but if >>> someone has examples / schemas for the other categories, I'd like to >>> integrate that. >>> http://www.zytrax.com/books/dns/ch7/logging.html >>> >> >> "+EDC on a query indicates that it is: >> >> - Recursive (+) - it has come from a client or a server that is >> forwarding queries to your server >> - The sender is using EDNS0 (using larger UDP packet sizes and >> signalling the size that can be accepted) >> - The sender understands DNSSEC (D) - this is a request to your server >> to include any DNSSEC material associated with answer in the query reply. >> - DNSSEC validation checking is disabled (C) - the sender wants the >> answer anyway, even if the validation checks fail." >> >> Source - >> https://kb.isc.org/article/AA-00434/0/What-do-EDC-and-other-letters-I-see-in-my-query-log-mean.html >> >> Also see https://www.isc.org/software/bind/documentation for further >> documentation. >> -- >> staticsafe >> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org >> Please don't top post - http://goo.gl/YrmAb >> Don't CC me! I'm subscribed to whatever list I just posted on. >> > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From ag4ve.us at gmail.com Fri May 10 03:45:35 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 9 May 2013 23:45:35 -0400 Subject: bind verbose logging In-Reply-To: References: <518C61D7.3050105@staticsafe.ca> Message-ID: On May 9, 2013 11:27 PM, "Mike Hale" wrote: > > I'll send over some info tomorrow. Shoot me a reminder if you don't > get it by the later afternoon. > > I wouldn't really call it a schema...it's just a simple field > extraction bash script that then generates the sql inserts. Like I > said...quick and dirty. > Cool. > Afte coding it from scratch, I'm starting to like the idea of using > Splunk as a front-end to analyze the logs. You may want to look at > using that rather than coding one by hand. The free version can index > 500 megs a day...which is a *lot* of queries. > Thought about Splunk, then Graylog2, then LogStash. Now I'm just thinking of continuing by hand and getting ElasticSearch going (got a perl Storable going right now). But alternative thinking is always useful so... > On Thu, May 9, 2013 at 8:14 PM, shawn wilson wrote: > > Thanks, that's what I'm looking for. > > > > Mike, sure I wouldn't mind schema ideas. > > > > On Thu, May 9, 2013 at 10:56 PM, staticsafe wrote: > >> On 5/9/2013 22:52, shawn wilson wrote: > >>> In this log line, what is -EDC? I've also noticed +, -, -E, and -ED > >>> but I have no Idea what they are (called/represent). > >>> > >>> 08-May-2013 08:04:49.751 client 1.2.3.4#48747 (ns2.example.com): > >>> query: ns2.example.com IN AAAA -EDC (1.2.3.4) > >>> > >>> Also, I'm writing a parser and we're only loging 'queries' but if > >>> someone has examples / schemas for the other categories, I'd like to > >>> integrate that. > >>> http://www.zytrax.com/books/dns/ch7/logging.html > >>> > >> > >> "+EDC on a query indicates that it is: > >> > >> - Recursive (+) - it has come from a client or a server that is > >> forwarding queries to your server > >> - The sender is using EDNS0 (using larger UDP packet sizes and > >> signalling the size that can be accepted) > >> - The sender understands DNSSEC (D) - this is a request to your server > >> to include any DNSSEC material associated with answer in the query reply. > >> - DNSSEC validation checking is disabled (C) - the sender wants the > >> answer anyway, even if the validation checks fail." > >> > >> Source - > >> https://kb.isc.org/article/AA-00434/0/What-do-EDC-and-other-letters-I-see-in-my-query-log-mean.html > >> > >> Also see https://www.isc.org/software/bind/documentation for further > >> documentation. > >> -- > >> staticsafe > >> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > >> Please don't top post - http://goo.gl/YrmAb > >> Don't CC me! I'm subscribed to whatever list I just posted on. > >> > > > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From jcole at tularosa.net Fri May 10 13:56:02 2013 From: jcole at tularosa.net (Jerimiah Cole) Date: Fri, 10 May 2013 07:56:02 -0600 Subject: Entry level WDM gear? In-Reply-To: <518B1637.20002@utc.edu> References: <518B1637.20002@utc.edu> Message-ID: <518CFC72.6020109@tularosa.net> On 05/08/2013 09:21 PM, Jeff Kell wrote: > Ciena/Cyan/etc are way over our non-existant budget... what is the > going recommendation to throw say 4-8 lambdas over a dark pair without > breaking the bank? :) I've used http://www.omnitron-systems.com/ media converters and found them reliable. They've got the filters to do an 8 channel system. From ahebert at pubnix.net Fri May 10 14:14:37 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 10 May 2013 10:14:37 -0400 Subject: Open Resolvers pseudo Honey Pot (Was: Open Resolver Problems) In-Reply-To: <20130509230356.BA789341BF16@drugs.dv.isc.org> References: <33324208.752.1365007937812.JavaMail.root@benjamin.baylink.com> <45AF4685-36BC-4C97-BCDA-A547A54A797E@hopcount.ca> <518BD982.60709@pubnix.net> <20130509230356.BA789341BF16@drugs.dv.isc.org> Message-ID: <518D00CD.5070906@pubnix.net> On 05/09/13 19:03, Mark Andrews wrote: > In message <518BD982.60709 at pubnix.net>, Alain Hebert writes: >> ( Ok, ok, another bad customer =D ) >> >> Starting today at 5h15m EST... >> >> There is a bigger than usual DDoS amplification against the IP's >> listed below. >> >> Granted root servers query is barely 1k while the usual isc.org is >> 3.5k and this is a "possible" 15Mbps from this one source but still :( > With a validating resolver > > "dig any . +edns" return a 1872 byte payload. > "dig any . +dnssec" return a 2030 byte payload. > (difference is NS RRSIG records) > > Getting the DNSKEY records included isn't hard. Throw a > single DNSKEY query into the stream once a day/hour > and it will be cached for 48 hours. > > If you have the SOA cached as well it gets to > > "dig any . +edns" return a 2087 byte payload. > "dig any . +dnssec" return a 2245 byte payload. > > Mark Well during the spamhaus incident I saw some at around 8k. On another note... After 18 hours, that "pot" is still receiving ~200pps (down from 800 and 400pps) and its up to 614 IP now... I still do not see the motive behind this one: Either someone messed up his botnet and he's stuck on it =D Could be a rootkit using this server as a DNS server (lots of targets are hosted Linux in outfit like OVH). ( But again why spamming . IN ANY queries and not cache the results ) And a new query popped up -> doc.gov IN ANY +E, granted I only saw a few of them. And a few of the source IP's are gaming forums mostly Minecraft oriented. PS: Reminder, that this server do not actually amplify anything and the service at that location is not affected. > >> PS: >> >> If you're a Tier and wish to track down the *^%$*#@ source ISP's to >> explain to them the joy of BCP38... >> >> Contact me off list, from your corporate email address, and I'll >> provide you with the IP of that server. >> >> ----- IP are targeted for DDoS amplification. >> >> Format: >> >> >> [query] >> >> 94.23.42.215 >> 2128 . IN ANY +E >> 208.98.25.130 >> 3079 . IN ANY +E >> 188.134.46.102 >> 2639 . IN ANY +E >> 108.61.239.105 >> 2270 . IN ANY +E >> 95.129.166.186 >> 2416 . IN ANY +E >> 176.9.210.53 >> 2839 . IN ANY +E >> 145.53.65.130 >> 2326 . IN ANY +E >> 99.198.100.86 >> 1223 . IN ANY +E >> 37.59.72.74 >> 2508 . IN ANY +E >> 199.83.133.42 >> 2392 . IN ANY +E >> 74.63.248.210 >> 1481 . IN ANY +E >> 173.199.68.62 >> 1178 . IN ANY +E >> 82.80.17.4 >> 2666 . IN ANY +E >> 188.162.228.50 >> 1075 . IN ANY +E >> 79.225.4.183 >> 1014 . IN ANY +E >> 78.108.79.171 >> 1291 . IN ANY +E >> 31.53.123.192 >> 1093 . IN ANY +E >> 90.3.194.151 >> 1245 . IN ANY +E >> 27.50.70.191 >> 1304 . IN ANY +E >> 198.7.63.39 >> 1579 . IN ANY +E >> 81.220.28.129 >> 1103 . IN ANY +E >> 198.105.218.12 >> 1110 . IN ANY +E >> 86.160.85.37 >> 1128 . IN ANY +E >> 184.95.35.194 >> 1237 . IN ANY +E >> 134.255.237.244 >> 1245 . IN ANY +E >> 178.32.36.67 >> 1588 . IN ANY +E >> 204.45.55.8 >> 1419 . IN ANY +E >> 95.211.209.182 >> 1520 . IN ANY +E >> 80.192.224.22 >> 1430 . IN ANY +E >> 24.244.248.8 >> 1414 . IN ANY +E >> 79.71.69.165 >> 1090 . IN ANY +E >> 24.244.248.57 >> 1364 . IN ANY +E >> 82.132.226.216 >> 1079 . IN ANY +E >> 69.162.97.99 >> 1601 . IN ANY +E >> >> ----- >> Alain Hebert ahebert at pubnix.net >> PubNIX Inc. >> 50 boul. St-Charles >> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 >> Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 >> >> From jared at puck.nether.net Fri May 10 18:01:15 2013 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 10 May 2013 14:01:15 -0400 Subject: A spoof film about networking In-Reply-To: <1995095.b1I21ulMVN@gentoovm> References: <1995095.b1I21ulMVN@gentoovm> Message-ID: On May 6, 2013, at 10:29 AM, Oliver wrote: > I cringed so hard at the EIGRP song, in fact, just thinking about it makes me > hurt inside. They posted it here: https://soundcloud.com/stickwell-productions/love_me_eigrp If you didn't watch it, at least listen to the song. You will either cringe or laugh. It's something nice to unwind after a long friday week. Plus it will play for 2 minutes while you do something else and you can enjoy. - Jared From cscora at apnic.net Fri May 10 18:33:05 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 May 2013 04:33:05 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201305101833.r4AIX5E3029853@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 11 May, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 454386 Prefixes after maximum aggregation: 185202 Deaggregation factor: 2.45 Unique aggregates announced to Internet: 224421 Total ASes present in the Internet Routing Table: 44038 Prefixes per ASN: 10.32 Origin-only ASes present in the Internet Routing Table: 34566 Origin ASes announcing only one prefix: 16097 Transit ASes present in the Internet Routing Table: 5845 Transit-only ASes present in the Internet Routing Table: 151 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 57 Max AS path prepend of ASN ( 61154) 54 Prefixes from unregistered ASNs in the Routing Table: 315 Unregistered ASNs in the Routing Table: 131 Number of 32-bit ASNs allocated by the RIRs: 4760 Number of 32-bit ASNs visible in the Routing Table: 3627 Prefixes from 32-bit ASNs in the Routing Table: 10293 Special use prefixes present in the Routing Table: 22 Prefixes being announced from unallocated address space: 235 Number of addresses announced to Internet: 2614671852 Equivalent to 155 /8s, 216 /16s and 185 /24s Percentage of available address space announced: 70.6 Percentage of allocated address space announced: 70.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.5 Total number of prefixes smaller than registry allocations: 160423 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 108833 Total APNIC prefixes after maximum aggregation: 33440 APNIC Deaggregation factor: 3.25 Prefixes being announced from the APNIC address blocks: 110179 Unique aggregates announced from the APNIC address blocks: 44862 APNIC Region origin ASes present in the Internet Routing Table: 4837 APNIC Prefixes per ASN: 22.78 APNIC Region origin ASes announcing only one prefix: 1221 APNIC Region transit ASes present in the Internet Routing Table: 827 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 523 Number of APNIC addresses announced to Internet: 721082080 Equivalent to 42 /8s, 250 /16s and 214 /24s Percentage of available APNIC address space announced: 84.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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: 159410 Total ARIN prefixes after maximum aggregation: 80155 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 160009 Unique aggregates announced from the ARIN address blocks: 73348 ARIN Region origin ASes present in the Internet Routing Table: 15677 ARIN Prefixes per ASN: 10.21 ARIN Region origin ASes announcing only one prefix: 5965 ARIN Region transit ASes present in the Internet Routing Table: 1632 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 39 Number of ARIN region 32-bit ASNs visible in the Routing Table: 19 Number of ARIN addresses announced to Internet: 1061791104 Equivalent to 63 /8s, 73 /16s and 165 /24s Percentage of available ARIN address space announced: 56.2 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, 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: 117197 Total RIPE prefixes after maximum aggregation: 59752 RIPE Deaggregation factor: 1.96 Prefixes being announced from the RIPE address blocks: 120753 Unique aggregates announced from the RIPE address blocks: 77929 RIPE Region origin ASes present in the Internet Routing Table: 17166 RIPE Prefixes per ASN: 7.03 RIPE Region origin ASes announcing only one prefix: 8147 RIPE Region transit ASes present in the Internet Routing Table: 2805 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 57 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2318 Number of RIPE addresses announced to Internet: 656487012 Equivalent to 39 /8s, 33 /16s and 50 /24s Percentage of available RIPE address space announced: 95.4 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, 196608-199679 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: 47766 Total LACNIC prefixes after maximum aggregation: 9328 LACNIC Deaggregation factor: 5.12 Prefixes being announced from the LACNIC address blocks: 51844 Unique aggregates announced from the LACNIC address blocks: 24191 LACNIC Region origin ASes present in the Internet Routing Table: 1928 LACNIC Prefixes per ASN: 26.89 LACNIC Region origin ASes announcing only one prefix: 578 LACNIC Region transit ASes present in the Internet Routing Table: 357 Average LACNIC Region AS path length visible: 4.6 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 761 Number of LACNIC addresses announced to Internet: 128546088 Equivalent to 7 /8s, 169 /16s and 117 /24s Percentage of available LACNIC address space announced: 76.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-62463, 262144-263167 plus 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: 10802 Total AfriNIC prefixes after maximum aggregation: 2487 AfriNIC Deaggregation factor: 4.34 Prefixes being announced from the AfriNIC address blocks: 11366 Unique aggregates announced from the AfriNIC address blocks: 3873 AfriNIC Region origin ASes present in the Internet Routing Table: 625 AfriNIC Prefixes per ASN: 18.19 AfriNIC Region origin ASes announcing only one prefix: 186 AfriNIC Region transit ASes present in the Internet Routing Table: 133 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46413824 Equivalent to 2 /8s, 196 /16s and 56 /24s Percentage of available AfriNIC address space announced: 46.1 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 2958 11558 927 Korea Telecom (KIX) 17974 2512 839 90 PT TELEKOMUNIKASI INDONESIA 7545 1903 320 109 TPG Internet Pty Ltd 4755 1725 390 191 TATA Communications formerly 9829 1509 1205 40 BSNL National Internet Backbo 9583 1221 91 502 Sify Limited 7552 1172 1064 12 Vietel Corporation 4808 1120 2113 328 CNCGROUP IP network: China169 9498 1099 309 71 BHARTI Airtel Ltd. 24560 1069 393 166 Bharti Airtel Ltd., Telemedia 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 3016 3693 82 bellsouth.net, inc. 7029 2144 1265 211 Windstream Communications Inc 18566 2067 382 184 Covad Communications 1785 1993 677 125 PaeTec Communications, Inc. 22773 1971 2929 125 Cox Communications, Inc. 20115 1668 1609 617 Charter Communications 4323 1613 1139 399 Time Warner Telecom 30036 1338 297 649 Mediacom Communications Corp 7018 1313 10819 849 AT&T WorldNet Services 11492 1245 228 320 Cable One 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 8402 1747 544 16 Corbina telecom 2118 1390 97 13 EUnet/RELCOM Autonomous Syste 34984 1185 238 221 BILISIM TELEKOM 13188 834 99 64 Educational Network 20940 825 285 654 Akamai Technologies European 31148 790 39 20 FreeNet ISP 8551 772 370 43 Bezeq International 6830 771 2376 444 UPC Distribution Services 12479 681 782 67 Uni2 Autonomous System 34744 671 172 55 SC GVM SISTEM 2003 SRL 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 28573 2684 1482 109 NET Servicos de Comunicao S.A 10620 2625 411 225 TVCABLE BOGOTA 7303 1689 1157 219 Telecom Argentina Stet-France 8151 1242 2701 393 UniNet S.A. de C.V. 6503 971 435 68 AVANTEL, S.A. 18881 921 780 19 Global Village Telecom 27947 822 88 95 Telconet S.A 11830 710 364 14 Instituto Costarricense de El 3816 706 306 85 Empresa Nacional de Telecomun 7738 698 1370 35 Telecomunicacoes da Bahia 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 36998 1237 80 4 MOBITEL 24863 888 274 32 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 461 956 9 TEDATA 24835 344 80 8 RAYA Telecom - Egypt 3741 261 906 220 The Internet Solution 15706 222 32 6 Sudatel Internet Exchange Aut 12258 193 28 67 Vodacom Internet Company 29975 191 667 21 Vodacom 36992 189 527 21 Etisalat MISR 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 6389 3016 3693 82 bellsouth.net, inc. 4766 2958 11558 927 Korea Telecom (KIX) 28573 2684 1482 109 NET Servicos de Comunicao S.A 10620 2625 411 225 TVCABLE BOGOTA 17974 2512 839 90 PT TELEKOMUNIKASI INDONESIA 7029 2144 1265 211 Windstream Communications Inc 18566 2067 382 184 Covad Communications 1785 1993 677 125 PaeTec Communications, Inc. 22773 1971 2929 125 Cox Communications, Inc. 7545 1903 320 109 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 28573 2684 2575 NET Servicos de Comunicao S.A 17974 2512 2422 PT TELEKOMUNIKASI INDONESIA 10620 2625 2400 TVCABLE BOGOTA 4766 2958 2031 Korea Telecom (KIX) 7029 2144 1933 Windstream Communications Inc 18566 2067 1883 Covad Communications 1785 1993 1868 PaeTec Communications, Inc. 22773 1971 1846 Cox Communications, Inc. 7545 1903 1794 TPG Internet Pty Ltd 8402 1747 1731 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.52.0/24 60906 NETOPIA SRL 128.0.58.0/23 9050 RTD-ROMTELECOM Autonomous Sys 128.0.60.0/24 9050 RTD-ROMTELECOM Autonomous Sys 128.0.61.0/24 9050 RTD-ROMTELECOM Autonomous Sys 128.0.62.0/24 9050 RTD-ROMTELECOM Autonomous Sys 128.0.63.0/24 9050 RTD-ROMTELECOM Autonomous Sys 128.0.72.0/21 23456 32-bit ASN transition Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. 64.185.230.0/24 27431 JTL Networks Inc. 64.185.231.0/24 27431 JTL Networks Inc. 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:13 /10:29 /11:87 /12:250 /13:490 /14:883 /15:1566 /16:12683 /17:6624 /18:11168 /19:22067 /20:32025 /21:34139 /22:47347 /23:42141 /24:238728 /25:1362 /26:1756 /27:867 /28:43 /29:65 /30:18 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2018 2067 Covad Communications 6389 1728 3016 bellsouth.net, inc. 7029 1612 2144 Windstream Communications Inc 8402 1451 1747 Corbina telecom 22773 1281 1971 Cox Communications, Inc. 36998 1231 1237 MOBITEL 30036 1211 1338 Mediacom Communications Corp 11492 1204 1245 Cable One 1785 1062 1993 PaeTec Communications, Inc. 6983 1008 1134 ITC^Deltacom Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:805 2:744 3:3 4:15 5:876 6:7 8:555 12:1917 13:3 14:776 15:11 16:3 17:9 20:17 23:276 24:1760 27:1500 31:1275 32:43 33:1 34:5 36:44 37:1852 38:872 39:2 40:172 41:2772 42:190 44:6 46:1889 47:2 49:632 50:691 52:12 54:34 55:9 57:26 58:1141 59:568 60:306 61:1391 62:1081 63:2035 64:4309 65:2175 66:4363 67:2046 68:1128 69:3280 70:872 71:537 72:1944 74:2558 75:412 76:307 77:1105 78:1054 79:584 80:1265 81:993 82:622 83:556 84:529 85:1150 86:462 87:979 88:537 89:1781 90:161 91:5453 92:614 93:1723 94:1856 95:1528 96:526 97:344 98:1052 99:41 100:30 101:328 103:2559 105:535 106:144 107:210 108:520 109:1850 110:869 111:1054 112:509 113:790 114:709 115:941 116:895 117:791 118:1068 119:1287 120:401 121:719 122:1777 123:1246 124:1351 125:1343 128:630 129:216 130:323 131:648 132:339 133:149 134:261 135:66 136:221 137:255 138:346 139:196 140:207 141:327 142:546 143:405 144:484 145:92 146:513 147:405 148:693 149:371 150:158 151:567 152:415 153:196 154:44 155:397 156:263 157:400 158:276 159:729 160:358 161:428 162:419 163:212 164:591 165:452 166:301 167:582 168:1032 169:134 170:1029 171:178 172:6 173:1665 174:592 175:469 176:1282 177:1960 178:1841 179:6 180:1419 181:423 182:1185 183:389 184:675 185:430 186:2300 187:1306 188:2148 189:1331 190:6344 192:6599 193:5866 194:4667 195:3455 196:1331 197:907 198:4427 199:5291 200:5924 201:2416 202:8846 203:8831 204:4514 205:2563 206:2843 207:2889 208:4054 209:3627 210:2942 211:1559 212:2106 213:1941 214:918 215:98 216:5251 217:1596 218:617 219:330 220:1279 221:555 222:319 223:442 End of report From cidr-report at potaroo.net Fri May 10 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 May 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201305102200.r4AM00kD031613@wattle.apnic.net> This report has been generated at Fri May 10 21:13:29 2013 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 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 03-05-13 455147 259665 04-05-13 455649 260035 05-05-13 455820 259904 06-05-13 455574 259944 07-05-13 455611 260337 08-05-13 455729 260398 09-05-13 455897 260480 10-05-13 456517 260613 AS Summary 44137 Number of ASes in routing system 18272 Number of ASes announcing only one prefix 3016 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116963808 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 10May13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 456572 260614 195958 42.9% All ASes AS6389 3016 86 2930 97.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4766 2958 943 2015 68.1% KIXS-AS-KR Korea Telecom AS17974 2512 570 1942 77.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS10620 2630 707 1923 73.1% Telmex Colombia S.A. AS28573 2671 755 1916 71.7% NET Servi?os de Comunica??o S.A. AS22773 1971 186 1785 90.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2067 473 1594 77.1% COVAD - Covad Communications Co. AS2118 1390 65 1325 95.3% RELCOM-AS OOO "NPO Relcom" AS7303 1689 457 1232 72.9% Telecom Argentina S.A. AS4323 1616 403 1213 75.1% TWTC - tw telecom holdings, inc. AS4755 1725 610 1115 64.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1172 169 1003 85.6% VIETEL-AS-AP Vietel Corporation AS36998 1237 301 936 75.7% SDN-MOBITEL AS7029 2144 1240 904 42.2% WINDSTREAM - Windstream Communications Inc AS18881 921 25 896 97.3% Global Village Telecom AS18101 1001 179 822 82.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS1785 1993 1241 752 37.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1120 385 735 65.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 844 135 709 84.0% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 741 55 686 92.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS8151 1250 580 670 53.6% Uninet S.A. de C.V. AS22561 1169 500 669 57.2% DIGITAL-TELEPORT - Digital Teleport Inc. AS24560 1069 408 661 61.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS6983 1134 479 655 57.8% ITCDELTA - ITC^Deltacom AS17676 730 107 623 85.3% GIGAINFRA Softbank BB Corp. AS27947 826 207 619 74.9% Telconet S.A AS3549 1058 442 616 58.2% GBLX Global Crossing Ltd. AS34744 671 68 603 89.9% GVM S.C. GVM SISTEM 2003 S.R.L. AS3356 1082 495 587 54.3% LEVEL3 Level 3 Communications AS11830 710 129 581 81.8% Instituto Costarricense de Electricidad y Telecom. Total 45117 12400 32717 72.5% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.197.36.0/22 AS43359 100.64.1.0/24 AS17338 NIS - Network Integration Services, Inc. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.248.20.0/24 AS55720 GIGABIT-MY THEGIGABIT.com - Dedicated Server & Server Co-Location 103.248.21.0/24 AS55720 GIGABIT-MY THEGIGABIT.com - Dedicated Server & Server Co-Location 103.248.22.0/24 AS55720 GIGABIT-MY THEGIGABIT.com - Dedicated Server & Server Co-Location 103.248.23.0/24 AS55720 GIGABIT-MY THEGIGABIT.com - Dedicated Server & Server Co-Location 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.138.128.0/20 AS32738 185.25.240.0/22 AS39451 MELBOURNE-AS Melbourne Server Hosting Ltd. 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.52.192.0/24 AS27919 190.52.193.0/24 AS27919 190.52.194.0/24 AS27919 190.52.195.0/24 AS27919 190.52.196.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.197.0/24 AS27919 190.52.198.0/24 AS27919 190.52.199.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.200.0/24 AS27947 Telconet S.A 190.52.201.0/24 AS27947 Telconet S.A 190.52.202.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.203.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.205.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.206.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.207.0/24 AS3549 GBLX Global Crossing Ltd. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS22011 Metro Net, S.A.P.I. de C.V. 200.58.248.0/21 AS27849 200.107.248.0/24 AS27919 200.107.249.0/24 AS27919 200.107.250.0/24 AS27919 200.107.251.0/24 AS27919 200.107.252.0/24 AS28006 CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 201.71.16.0/20 AS28638 201.77.96.0/20 AS28639 201.222.32.0/20 AS27821 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 204.8.218.0/24 AS39323 AS-DZONE - Dedicated Zone Inc 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.70.56.0/21 AS32738 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.94.48.0/21 AS46324 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 209.250.230.0/24 AS39323 AS-DZONE - Dedicated Zone Inc 209.250.252.0/22 AS39323 AS-DZONE - Dedicated Zone Inc 209.250.255.0/24 AS46496 AS-6GTECH - 6G Technologies Inc 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.127.192.0/24 AS22166 216.127.193.0/24 AS22166 216.127.194.0/24 AS22166 216.127.195.0/24 AS22166 216.127.196.0/24 AS22166 216.127.196.64/26 AS22166 216.127.197.0/24 AS22166 216.127.198.0/24 AS22166 216.127.199.0/24 AS22166 216.127.200.0/24 AS22166 216.127.201.0/24 AS22166 216.127.202.0/24 AS22166 216.127.203.0/24 AS22166 216.127.204.0/24 AS22166 216.127.205.0/24 AS22166 216.127.206.0/24 AS22166 216.127.207.0/24 AS22166 216.127.208.0/24 AS22166 216.127.209.0/24 AS22166 216.127.210.0/24 AS22166 216.127.211.0/24 AS22166 216.127.212.0/24 AS22166 216.127.213.0/24 AS22166 216.127.214.0/24 AS22166 216.127.215.0/24 AS22166 216.127.216.0/24 AS22166 216.127.217.0/24 AS22166 216.127.218.0/24 AS22166 216.127.219.0/24 AS22166 216.127.220.0/24 AS22166 216.127.221.0/24 AS22166 216.127.222.0/24 AS22166 216.127.223.0/24 AS22166 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 May 10 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 May 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201305102200.r4AM01EG031628@wattle.apnic.net> BGP Update Report Interval: 02-May-13 -to- 09-May-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS36998 174311 7.8% 204.6 -- SDN-MOBITEL 2 - AS22561 107210 4.8% 189.4 -- DIGITAL-TELEPORT - Digital Teleport Inc. 3 - AS9829 43679 2.0% 38.6 -- BSNL-NIB National Internet Backbone 4 - AS10620 36545 1.6% 14.4 -- Telmex Colombia S.A. 5 - AS5800 34733 1.6% 142.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - AS8402 27906 1.2% 21.8 -- CORBINA-AS OJSC "Vimpelcom" 7 - AS5668 27078 1.2% 168.2 -- AS-5668 - CenturyTel Internet Holdings, Inc. 8 - AS15003 21807 1.0% 43.0 -- NOBIS-TECH - Nobis Technology Group, LLC 9 - AS3909 20581 0.9% 3430.2 -- QWEST-AS-3908 - Qwest Communications Company, LLC 10 - AS7552 18904 0.8% 16.2 -- VIETEL-AS-AP Vietel Corporation 11 - AS38547 16090 0.7% 143.7 -- WITRIBE-AS-AP WITRIBE PAKISTAN LIMITED 12 - AS9416 16010 0.7% 313.9 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 13 - AS9260 15321 0.7% 136.8 -- MULTINET-AS-AP Multinet Pakistan Pvt. Ltd. 14 - AS4837 14095 0.6% 22.6 -- CHINA169-BACKBONE CNCGROUP China169 Backbone 15 - AS23966 13799 0.6% 39.9 -- LDN-AS-PK LINKdotNET Telecom Limited 16 - AS27738 13377 0.6% 23.6 -- Ecuadortelecom S.A. 17 - AS2914 13127 0.6% 285.4 -- NTT-COMMUNICATIONS-2914 - NTT America, Inc. 18 - AS37054 12876 0.6% 98.3 -- DTS 19 - AS17563 12828 0.6% 104.3 -- NEXLINX-AS-AP Autonomous System Number for Nexlinx 20 - AS11664 12005 0.5% 37.9 -- Techtel LMDS Comunicaciones Interactivas S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6629 7373 0.3% 7373.0 -- NOAA-AS - NOAA 2 - AS15957 9388 0.4% 4694.0 -- WTG-AS Web Technology Group 3 - AS19406 4196 0.2% 4196.0 -- TWRS-MA - Towerstream I, Inc. 4 - AS3909 20581 0.9% 3430.2 -- QWEST-AS-3908 - Qwest Communications Company, LLC 5 - AS42334 3032 0.1% 3032.0 -- BBP-AS Broadband Plus s.a.l. 6 - AS6174 5904 0.3% 2952.0 -- SPRINTLINK8 - Sprint 7 - AS45808 2431 0.1% 2431.0 -- UTP-MY Bandar Seri Iskandar 8 - AS14680 7077 0.3% 2359.0 -- REALE-6 - Auction.com 9 - AS37318 1443 0.1% 1443.0 -- BESA 10 - AS3789 1172 0.1% 1172.0 -- VRMC-AS - Virginia Regional Medical Center 11 - AS48612 8864 0.4% 1108.0 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 12 - AS46035 1036 0.1% 1036.0 -- TRIKOMSEL-AS-ID PT Trikomsel Oke Tbk 13 - AS33920 2772 0.1% 924.0 -- AQL (aq) Networks Limited 14 - AS38523 2894 0.1% 723.5 -- INTIKOMP-AS-ID INTI INFORMATIKA, PT 15 - AS19796 721 0.0% 721.0 -- SHUBERT - Shubert Organization, Inc. 16 - AS8657 637 0.0% 637.0 -- CPRM PT Comunicacoes S A 17 - AS45708 1910 0.1% 636.7 -- SURABAYA-AS-ID Pemerintah Kota Surabaya 18 - AS8382 633 0.0% 633.0 -- IRTEL-AS OJSC Rostelecom 19 - AS38502 3611 0.2% 601.8 -- MDPNET-AS-ID PT. MULTI DATA PALEMBANG 20 - AS38868 2386 0.1% 596.5 -- UPM-AS-AP Universiti Putra Malaysia AS TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 209.142.140.0/24 10378 0.4% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 2 - 193.19.90.0/23 9255 0.4% AS29684 -- NOURNET-ASN Nour Communication Co.Ltd - Nournet 3 - 92.246.207.0/24 8819 0.4% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 4 - 203.118.224.0/21 7958 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 5 - 203.118.232.0/21 7904 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 6 - 192.58.232.0/24 7373 0.3% AS6629 -- NOAA-AS - NOAA 7 - 151.118.255.0/24 6871 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 8 - 151.118.254.0/24 6871 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 9 - 151.118.18.0/24 6827 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 10 - 12.139.133.0/24 5755 0.2% AS14680 -- REALE-6 - Auction.com 11 - 173.232.234.0/24 5167 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 12 - 173.232.235.0/24 5167 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 13 - 212.28.16.0/20 4696 0.2% AS15957 -- WTG-AS Web Technology Group 14 - 212.28.0.0/20 4692 0.2% AS15957 -- WTG-AS Web Technology Group 15 - 69.38.178.0/24 4196 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 16 - 62.84.76.0/24 3032 0.1% AS42334 -- BBP-AS Broadband Plus s.a.l. 17 - 206.105.75.0/24 2952 0.1% AS6174 -- SPRINTLINK8 - Sprint 18 - 208.16.110.0/24 2952 0.1% AS6174 -- SPRINTLINK8 - Sprint 19 - 78.40.240.0/24 2767 0.1% AS33920 -- AQL (aq) Networks Limited 20 - 84.205.66.0/24 2564 0.1% AS12654 -- RIPE-NCC-RIS-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC) 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 olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa Sat May 11 07:00:11 2013 From: olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa (Oliver) Date: Sat, 11 May 2013 09:00:11 +0200 Subject: "Network Engineering" Stack Exchange site in Area51 (fwd) In-Reply-To: References: Message-ID: <1679274.XdSqHNRXol@gentoovm> On Tuesday 07 May 2013 16:44:33 Yang Yu wrote: > Network Engineering Q&A site - Area 51 - Stack Exchange just started > private beta. > http://networkengineering.stackexchange.com/ > > If anyone needs a private beta invitation, feel free to email me > offlist. Thanks. I'm throwing myself into what I imagine is a flurry of requests for beta access, I look forward to participating. Thanks, Oliver From olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa Sat May 11 07:01:21 2013 From: olipro at 8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa (Oliver) Date: Sat, 11 May 2013 09:01:21 +0200 Subject: "Network Engineering" Stack Exchange site in Area51 (fwd) In-Reply-To: <1679274.XdSqHNRXol@gentoovm> References: <1679274.XdSqHNRXol@gentoovm> Message-ID: <8406909.QmoEjJfIag@gentoovm> On Saturday 11 May 2013 09:00:11 you wrote: > On Tuesday 07 May 2013 16:44:33 Yang Yu wrote: > > Network Engineering Q&A site - Area 51 - Stack Exchange just started > > private beta. > > http://networkengineering.stackexchange.com/ > > > > If anyone needs a private beta invitation, feel free to email me > > offlist. Thanks. > > I'm throwing myself into what I imagine is a flurry of requests for beta > access, I look forward to participating. > > Thanks, > Oliver hurr durr, slow morning. sorry folks. From fw at deneb.enyo.de Sat May 11 09:10:22 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 11 May 2013 11:10:22 +0200 Subject: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine) In-Reply-To: <5183FB74.4090501@foobar.org> (Nick Hilliard's message of "Fri, 03 May 2013 19:01:24 +0100") References: <7EABCF7A-EEF3-45D3-BC7E-999EFB901F1E@oav.net> <5183FB74.4090501@foobar.org> Message-ID: <87li7l3mrl.fsf@mid.deneb.enyo.de> * Nick Hilliard: > ripe policy 2007-01 will help with this problem by ensuring that anyone who > has got PI address space will be traceable and will be paying for it (i.e. > it will appear on the holder's payment radar). I don't think there are plans to publish this information in the WHOIS database, though. From glen.kent at gmail.com Sun May 12 08:41:37 2013 From: glen.kent at gmail.com (Glen Kent) Date: Sun, 12 May 2013 14:11:37 +0530 Subject: ISIS and OSPF together Message-ID: Hi, I would like to understand the scenarios wherein the service provider/network admin might run both ISIS and OSPF together inside their network. Is this something that really happens out there? One scenario that i can think of when somebody might run the 2 protocols ISIS and OSPF together for a brief period is when the admin is migrating from one IGP to the other. This, i understand never happens in steady state. The only time this can happen is if an AS gets merged into another AS (due to mergers and acquisitions) and the two ASes happen to run ISIS and OSPF respectively. In such instances, there is a brief period when two protocols might run together before one gets turned off and there is only one left. The other instance would be when say OSPF is used to manage the OOB network and the ISIS is used for network reachability. Is there any other scenario? Glen From peterehiwe at gmail.com Sun May 12 08:51:07 2013 From: peterehiwe at gmail.com (Peter Ehiwe) Date: Sun, 12 May 2013 09:51:07 +0100 Subject: ISIS and OSPF together In-Reply-To: References: Message-ID: Ospf offered as Pe-ce protocol to L3 mpls vpn customers and Isis as IGP for MPLS Core. Sent from my iPhone On May 12, 2013, at 9:41 AM, Glen Kent wrote: > Hi, > > I would like to understand the scenarios wherein the service > provider/network admin might run both ISIS and OSPF together inside their > network. Is this something that really happens out there? > > One scenario that i can think of when somebody might run the 2 protocols > ISIS and OSPF together for a brief period is when the admin is migrating > from one IGP to the other. This, i understand never happens in steady > state. The only time this can happen is if an AS gets merged into another > AS (due to mergers and acquisitions) and the two ASes happen to run ISIS > and OSPF respectively. In such instances, there is a brief period when two > protocols might run together before one gets turned off and there is only > one left. > > The other instance would be when say OSPF is used to manage the OOB network > and the ISIS is used for network reachability. > > Is there any other scenario? > > Glen From swmike at swm.pp.se Sun May 12 08:51:31 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 12 May 2013 10:51:31 +0200 (CEST) Subject: ISIS and OSPF together In-Reply-To: References: Message-ID: On Sun, 12 May 2013, Glen Kent wrote: > Is there any other scenario? When you might run OSPFv3 (for IPv6) and ISIS (IPv4) together because you have equipment that is buggy for ISIS multi topology. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Sun May 12 08:57:08 2013 From: randy at psg.com (Randy Bush) Date: Sun, 12 May 2013 09:57:08 +0100 Subject: ISIS and OSPF together In-Reply-To: References: Message-ID: > One scenario that i can think of when somebody might run the 2 protocols > ISIS and OSPF together for a brief period is when the admin is migrating > from one IGP to the other. This, i understand never happens in steady > state. The only time this can happen is if an AS gets merged into another > AS (due to mergers and acquisitions) and the two ASes happen to run ISIS > and OSPF respectively. In such instances, there is a brief period when two > protocols might run together before one gets turned off and there is only > one left. no. some ops come to see the light and move their network from ospf to is-is. see vijay gill's nanog preso http://nanog.org/meetings/nanog29/presentations/aol-backbone.ram From victor at jvknet.com Sun May 12 12:47:56 2013 From: victor at jvknet.com (Victor Kuarsingh) Date: Sun, 12 May 2013 08:47:56 -0400 Subject: ISIS and OSPF together In-Reply-To: Message-ID: Glen, One transition scenario you noted below is often a use case. I have seen networks move from OSPF to IS-IS (more cases then the reverse). In those cases, the overlap period may not be very short (years vs. weeks/months). I have also seen some use one protocol (which I think was mentioned in another response) used for IPv4 and another used for IPv6. The cases I am familiar, tended to be IPv6 with IS-IS and IPv4 with OSPFv2. I guess the reasoning here was that if you are running dual stack, with OSPF you will need to run two protocols anyway, so running OSPFv2(IPv3) and OSPFv3(IPv6) may not be that different then running OSPFv2(IPv4) with IS-IS(IPv6). This dual stack option has run longer or is semi-permanent at times. A sub-case to the above may also be that one (operator) may want to leverage some of capabilities of IS-IS and may not be willing to get off OSPF for some reason. The Multi-topology option in IS-IS may be quite useful if you have some functions which are non-congruent in your network and you want to maintain topology variations (multicast being one, or in-band management which I believe was alluded to in your OOB use case) Regards, Victor K On 2013-05-12 4:41 AM, "Glen Kent" wrote: >Hi, > >I would like to understand the scenarios wherein the service >provider/network admin might run both ISIS and OSPF together inside their >network. Is this something that really happens out there? > >One scenario that i can think of when somebody might run the 2 protocols >ISIS and OSPF together for a brief period is when the admin is migrating >from one IGP to the other. This, i understand never happens in steady >state. The only time this can happen is if an AS gets merged into another >AS (due to mergers and acquisitions) and the two ASes happen to run ISIS >and OSPF respectively. In such instances, there is a brief period when two >protocols might run together before one gets turned off and there is only >one left. > >The other instance would be when say OSPF is used to manage the OOB >network >and the ISIS is used for network reachability. > >Is there any other scenario? > >Glen From mansaxel at besserwisser.org Sun May 12 17:49:46 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 12 May 2013 19:49:46 +0200 Subject: ISIS and OSPF together In-Reply-To: References: Message-ID: <20130512174946.GA32099@besserwisser.org> Subject: ISIS and OSPF together Date: Sun, May 12, 2013 at 02:11:37PM +0530 Quoting Glen Kent (glen.kent at gmail.com): > Hi, > > I would like to understand the scenarios wherein the service > provider/network admin might run both ISIS and OSPF together inside their > network. Is this something that really happens out there? Indeed; one of the more sane situations might be to have say anycast name servers or full-service resolvers in the network and having them talk OSPF to the first hop router. ISIS daemons on PC operating systems are scarce, working ones hardly exist. It is clear, though, that the path forward is ISIS; most people I've spoken to roll it out (in greenfield/forklift situations) or migrate to it. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I always have fun because I'm out of my mind!!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From glen.kent at gmail.com Sun May 12 18:43:38 2013 From: glen.kent at gmail.com (Glen Kent) Date: Mon, 13 May 2013 00:13:38 +0530 Subject: ISIS and OSPF together In-Reply-To: References: Message-ID: Victor, Folks could, at least theoretically, use ISIS or OSPF multi instance/multi topology extensions to support IPv4 and IPv6 topologies. This way they would only need to run a single protocol and thereby requiring expertise in handling only one protocol. With whatever i remember, OSPFv3 can be used to support IPv4 as well - so folks could also use OSPFv3 when they want to support both IPv4 and IPv6. Glen On Sun, May 12, 2013 at 6:17 PM, Victor Kuarsingh wrote: > Glen, > > One transition scenario you noted below is often a use case. I have seen > networks move from OSPF to IS-IS (more cases then the reverse). > > In those cases, the overlap period may not be very short (years vs. > weeks/months). > > I have also seen some use one protocol (which I think was mentioned in > another response) used for IPv4 and another used for IPv6. The cases I am > familiar, tended to be IPv6 with IS-IS and IPv4 with OSPFv2. > I guess the reasoning here was that if you are running dual stack, with > OSPF you will need to run two protocols anyway, so running OSPFv2(IPv3) > and OSPFv3(IPv6) may not be that different then running OSPFv2(IPv4) with > IS-IS(IPv6). This dual stack option has run longer or is semi-permanent > at times. > > A sub-case to the above may also be that one (operator) may want to > leverage some of capabilities of IS-IS and may not be willing to get off > OSPF for some reason. The Multi-topology option in IS-IS may be quite > useful if you have some functions which are non-congruent in your network > and you want to maintain topology variations (multicast being one, or > in-band management which I believe was alluded to in your OOB use case) > > Regards, > > Victor K > > > > On 2013-05-12 4:41 AM, "Glen Kent" wrote: > > >Hi, > > > >I would like to understand the scenarios wherein the service > >provider/network admin might run both ISIS and OSPF together inside their > >network. Is this something that really happens out there? > > > >One scenario that i can think of when somebody might run the 2 protocols > >ISIS and OSPF together for a brief period is when the admin is migrating > >from one IGP to the other. This, i understand never happens in steady > >state. The only time this can happen is if an AS gets merged into another > >AS (due to mergers and acquisitions) and the two ASes happen to run ISIS > >and OSPF respectively. In such instances, there is a brief period when two > >protocols might run together before one gets turned off and there is only > >one left. > > > >The other instance would be when say OSPF is used to manage the OOB > >network > >and the ISIS is used for network reachability. > > > >Is there any other scenario? > > > >Glen > > > From swm at emanon.com Sun May 12 19:24:47 2013 From: swm at emanon.com (Scott Morris) Date: Sun, 12 May 2013 15:24:47 -0400 Subject: ISIS and OSPF together In-Reply-To: References: Message-ID: <518FEC7F.30302@emanon.com> From victor at jvknet.com Sun May 12 19:57:34 2013 From: victor at jvknet.com (Victor Kuarsingh) Date: Sun, 12 May 2013 15:57:34 -0400 Subject: ISIS and OSPF together In-Reply-To: Message-ID: Glen, Yes, if you are referring to RFC5838 like functionality in OSPFv3 (AF support) that is correct. I personally don't have experience with that mode of operation (as the networks I had experience with went dual stack a while back). I guess someone looking to dual stack now may want to consider that option. I am personally biased towards IS-IS when looking to do both, but to each their own. To further my early points (not saying it's a good option, but adding some context). The rationale for keeping OSPFv2 was due to legacy tools and operational procedures. Adding a second IGP (years ago) for IPv6 was considered (to some) a way of not specifically impacting the "bread and butter" IPv4 service while turning up IPv6. I guess all of that reasoning has likely changed for new IPv6 turn-ups as there is much more operational experience with running multiple AFs now. I should have highlighted the context before ? sorry. Regards, Victor K From: Glen Kent Date: Mon, 13 May 2013 00:13:38 +0530 To: Victor Kuarsingh Cc: "nanog at nanog.org" Subject: Re: ISIS and OSPF together Victor, Folks could, at least theoretically, use ISIS or OSPF multi instance/multi topology extensions to support IPv4 and IPv6 topologies. This way they would only need to run a single protocol and thereby requiring expertise in handling only one protocol. With whatever i remember, OSPFv3 can be used to support IPv4 as well - so folks could also use OSPFv3 when they want to support both IPv4 and IPv6. Glen On Sun, May 12, 2013 at 6:17 PM, Victor Kuarsingh wrote: > Glen, > > One transition scenario you noted below is often a use case. I have seen > networks move from OSPF to IS-IS (more cases then the reverse). > > In those cases, the overlap period may not be very short (years vs. > weeks/months). > > I have also seen some use one protocol (which I think was mentioned in > another response) used for IPv4 and another used for IPv6. The cases I am > familiar, tended to be IPv6 with IS-IS and IPv4 with OSPFv2. > I guess the reasoning here was that if you are running dual stack, with > OSPF you will need to run two protocols anyway, so running OSPFv2(IPv3) > and OSPFv3(IPv6) may not be that different then running OSPFv2(IPv4) with > IS-IS(IPv6). This dual stack option has run longer or is semi-permanent > at times. > > A sub-case to the above may also be that one (operator) may want to > leverage some of capabilities of IS-IS and may not be willing to get off > OSPF for some reason. The Multi-topology option in IS-IS may be quite > useful if you have some functions which are non-congruent in your network > and you want to maintain topology variations (multicast being one, or > in-band management which I believe was alluded to in your OOB use case) > > Regards, > > Victor K > > > > On 2013-05-12 4:41 AM, "Glen Kent" wrote: > >> >Hi, >> > >> >I would like to understand the scenarios wherein the service >> >provider/network admin might run both ISIS and OSPF together inside their >> >network. Is this something that really happens out there? >> > >> >One scenario that i can think of when somebody might run the 2 protocols >> >ISIS and OSPF together for a brief period is when the admin is migrating >> >from one IGP to the other. This, i understand never happens in steady >> >state. The only time this can happen is if an AS gets merged into another >> >AS (due to mergers and acquisitions) and the two ASes happen to run ISIS >> >and OSPF respectively. In such instances, there is a brief period when two >> >protocols might run together before one gets turned off and there is only >> >one left. >> > >> >The other instance would be when say OSPF is used to manage the OOB >> >network >> >and the ISIS is used for network reachability. >> > >> >Is there any other scenario? >> > >> >Glen > > From randy at psg.com Mon May 13 09:31:18 2013 From: randy at psg.com (Randy Bush) Date: Mon, 13 May 2013 10:31:18 +0100 Subject: ISIS and OSPF together In-Reply-To: References: Message-ID: > Folks could, at least theoretically, use ISIS or OSPF multi instance/multi > topology extensions to support IPv4 and IPv6 topologies. This way they > would only need to run a single protocol and thereby requiring expertise in > handling only one protocol. and, as is-is supports 4 and 6, why do you use ospf in this scenario? randy From bmeshier at amherst.com Mon May 13 05:59:33 2013 From: bmeshier at amherst.com (Meshier, Brent) Date: Mon, 13 May 2013 05:59:33 +0000 Subject: Dallas Peering Issues Message-ID: <68C2CBC977F3E04799DF9C76E938E7090F3848@DFEXCH1.asglp.com> Was alerted by our MSSP of connectivity issues, looks like something big is happening right now that's affecting Level3, Savvis, Cogent, Verizon and Century Link. Take a look at Internet Health Report, never seen it this bad. Anyone have more information? --Brent **************************************************************************************************************************************************************************************** The material contained herein is for informational purposes only and is not intended as an offer or solicitation with respect to the purchase or sale of securities. The decision of whether to adopt any strategy or to engage in any transaction and the decision of whether any strategy or transaction fits into an appropriate portfolio structure remains the responsibility of the customer and/or its advisors. Past performance on the underlying securities is no guarantee of future results. This material is intended for use by institutional clients only and not for use by the general public. Portions of this material may incorporate information provided by third party market data sources. Although this information has been obtained from and based upon sources believed to be reliable, neither Amherst Holdings, LLC nor any of its affiliates guarantee the accuracy or completeness of the information contained herein, and cannot be held responsible for inaccuracies in such third party data or the data supplied to the third party by issuers or guarantors. This report constitutes Amherst's views as of the date of the report and is subject to change without notice. This information does not purport to be a complete analysis of any security, company or industry, including but not limited to any claim as to the prepayment consistency and/or the future performance of any securities or structures. To the extent applicable, change in prepayment rates and/or payments may significantly affect yield, price, total return and average life. Our affiliate, Amherst Securities Group, L.P., may have a position in securities discussed in this material. From dwhite at olp.net Mon May 13 13:46:07 2013 From: dwhite at olp.net (Dan White) Date: Mon, 13 May 2013 08:46:07 -0500 Subject: Dallas Peering Issues In-Reply-To: <68C2CBC977F3E04799DF9C76E938E7090F3848@DFEXCH1.asglp.com> References: <68C2CBC977F3E04799DF9C76E938E7090F3848@DFEXCH1.asglp.com> Message-ID: <20130513134607.GB6847@dan.olp.net> On 05/13/13?05:59?+0000, Meshier, Brent wrote: >Was alerted by our MSSP of connectivity issues, looks like something big >is happening right now that's affecting Level3, Savvis, Cogent, Verizon >and Century Link. Take a look at Internet Health Report, never seen it >this bad. Anyone have more information? Does anyone have more information about this? We received a customer complaint yesterday, around this time period, with packet loss to 8.8.8.8 (our traceroutes to 8.8.8.8 typically route through Level 3 in Dallas). -- Dan White From jfmezei_nanog at vaxination.ca Tue May 14 05:50:54 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 14 May 2013 01:50:54 -0400 Subject: Lucent Stinger DSLAM End of Life questions Message-ID: <5191D0BE.5010406@vaxination.ca> Does anyone know when Alcatel declared the Lucent Stinger product line "end of sales" ? The Alcatel web page confirms it is discontinued but no date shown. > https://support.alcatel-lucent.com/portal/productContent.do?productId=stinger&entryId=1-0000000001080 All of the PDFs I have seen (thank to my buddy Mr Google) point to Lucent documents in early 2000s. (and few discuss Stingers deployed in remotes). None have the Alcatel-Lucent name, all have Lucent only. In a regulatory Filing, Bell Canada says that it deployed 80% of them between 2006 and 2009, with the rest between 2009 and 2012. I was under the impression that Alcatel end-of-lifed the Stinger product line not long after it purchased Lucent at end of 2006. So knowing when this actually happened would greatly help understanding this. The Stinger DSLAMs deployed by Bell Canada are causing problems because they are not fully VDSL2 compatible and Bell Canada has identified only 1 modem (Sagemcom 2864) that is compatible ( a previous one Cellpipe has been end of lifed). >From the time the end of sales has been reached, how many years could a carrier expect to see firmware/software fixes for their fleet of DSLAMs installed throughout cities ? I assume that while the end of life .PDF on the web site is restrictive, that Alcatel would still value carriers and provide them with "mature product" support ? Are there precedents of other carriers who deployed Stingers and have since replaced them due to their being end of life and not so compatible with VDSL2 ? Bell Canada stated that it has no plans to replace them, but this could be just regulatory talk. Any background information would be appreciated. From betty at newnog.org Tue May 14 14:21:41 2013 From: betty at newnog.org (Betty Burke ) Date: Tue, 14 May 2013 15:21:41 +0100 Subject: [NANOG-announce] 2013 Postel Scholarship Announcement Message-ID: On behalf of the North American Network Operators' Group (NANOG) and the American Registry for Internet Numbers (ARIN), we would like to take this opportunity to draw your attention to the 2013 Postel Network Operator's Scholarship . The Postel Network Operator's Scholarship targets personnel from developing countries who are actively involved in Internet development, in any of the following roles: - Engineers (Network Builders) - Operational and Infrastructure Support Personnel - Educators and Trainers This is not a postgraduate fellowship or academic scholarship. Individuals may nominate themselves for the Scholarship via email. The Scholarship will be awarded annually to a recipient selected by a committee comprising representatives from the NANOG Board of Directors and the ARIN Board of Trustees. The selection committee will "whimsically" select the annual recipient exclusively in response to the question: "What Would JonDo?" if he were asked to select a recipient. The successful applicant will be provided with transportation to and from the NANOG and ARIN joint meeting October 7-11, 2013 in Phoenix, Arizona, USA, and a reasonable (local host standard) allowance for food and accommodation. In addition, all fees for participation in both meetings' events will be waived. The final grant size is determined according to final costs and available funding. The chosen recipient will be advised at least 2 months prior to the fall meeting date. Applications from qualified individuals are now being accepted. The deadline for application is June 7, 2013 and the awardees will be informed by July 19, 2013. Please read full information about the scholarship at: http://nanog.org/resources/scholarships/postel To apply, please submit your application in PLAIN ASCII in the BODY of the message, not as an attachment nor as a Word document, PDF, or any other form, to PostelNOS at nanog.org. Please be sure to include the following: - Full name and contact info - Your brief biography, including current and recent jobs held - A description of why you need and deserve this Scholarship to attend the NANOG and ARIN meetings - A description of how you plan to leverage your attendance at the meetings in your work - A brief abstract of a presentation you would give at the NANOG and/or ARIN meetings, if selected as a Scholarship winner Kind regards, Steve Gibbard and John Curran, on behalf of the Postel Scholarship Selection Committee -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jason.sherron at microsoft.com Tue May 14 18:02:49 2013 From: jason.sherron at microsoft.com (Jason Sherron) Date: Tue, 14 May 2013 18:02:49 +0000 Subject: Could not send email to office 365 In-Reply-To: References: <20130501182123.2455.AEA43824@ugec.net> <51820ABE.4070000@isc.org> <2AEB6E00-1ECA-460F-A656-98085B5F053D@hopcount.ca> Message-ID: <9826f8732f844d44a3b5c4ff3b50ac73@DFM-DB3MBX15-07.exchange.corp.microsoft.com> I'm an engineer on the Microsoft Office365 Exchange Online ("outlook.office365.com") network team. I'm gathering forensics specific to IPv6 reports -- are people still experiencing IPv6-related issues? I am interested solely in failures that are IPv6 connection issues to "outlook.office365.com". If you have a clear repro of an IPv6 connection failure, please message me off-list with at least a traceroute. (Please don't deluge me with non-IPv6-related issues -- I'm a network guy working on this one report.) Jason (dot) Sherron [at] Microsoft (dot) com -----Original Message----- From: JoeSox [mailto:joesox at gmail.com] Sent: Wednesday, May 8, 2013 4:35 PM To: nanog at nanog.org Subject: Re: Could not send email to office 365 Just an update if list members are still experiencing this issue. I spoke on the phone with Escalation Manager for Microsoft North America and they had meetings today and their Engineering team is putting a game plan together to roll out a fix for the Outlook connectivity issues. They were debating to roll-out to the group of effected customers or one-by-one. From the data I provided to them it looks like something to do with their NSPI RPC endpoint environment. They told me I should receive a call tomorrow but call them Friday if I do not receive a call. Hopefully, everyone else experiencing this issue is being taken care of as this is the main concern with Cloud services is the lack of response times on major issues. -- Thanks, Joe On Thu, May 2, 2013 at 10:16 AM, JoeSox wrote: > Our Technical Support is reporting a big jump in Outlook connectivity > issues about 5-10 minutes ago. > Our resolvers are testing fine. > -- > Thanks, Joe > > > On Thu, May 2, 2013 at 4:53 AM, Joe Abley wrote: > >> >> On 2013-05-02, at 02:42, Cathy Almond wrote: >> >> > This may be a red herring, but I've heard of some dropping of DNS >> > queries for the names within outlook.com domains where the queries >> > are all coming from source port 53 (i.e. your recursive server >> > doesn't use query source port randomization >> >> ... or there's a NAT or some other box in front of the recursive >> server which re-writes the source port... >> >> > ). Might be worth checking what the recursive server you're using >> > is doing? >> > >> > See https://www.dns-oarc.net/oarc/services/porttest >> >> >> Joe >> > > From jra at baylink.com Tue May 14 17:06:52 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 14 May 2013 13:06:52 -0400 (EDT) Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <18149689.5528.1368551129630.JavaMail.root@benjamin.baylink.com> Message-ID: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> Or I don't. Which is not completely impossible. In this piece: http://variety.com/2013/digital/news/netflix-puts-even-more-strain-on-the-internet-1200480561/ they suggest that Akamai and other ISP-side caching is either not affecting these numbers and their pertinence to the "backbone" at all, or not much. Did they miss something? or did I? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jfmezei_nanog at vaxination.ca Tue May 14 19:53:10 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 14 May 2013 15:53:10 -0400 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> Message-ID: <51929626.9030504@vaxination.ca> On 13-05-14 13:06, Jay Ashworth wrote: > http://variety.com/2013/digital/news/netflix-puts-even-more-strain-on-the-internet-1200480561/ > > they suggest that Akamai and other ISP-side caching is either not > affecting these numbers and their pertinence to the "backbone" at all, > or not much. This is from a Sandvine press release. Sandvine measures traffic at the last mile, so it doesn't really know whether a Netflix stream is coming from a local caching server within the carrier's LAN, from a caching server that is peering with the carrier, or via the real internet. In the case of a large ISP with a Netflix cache server accessible locally, (either in-house, or via peering at a local carrier hotel), the traffic doesn't really travel on the internet. But for smaller ISPs, the traffic will travel on the internet between the nearest cache server and their facilities. Because of caching, the load on the actual internet won't increase as much as the amoount streamed onto last mile infrastructure. From morrowc.lists at gmail.com Tue May 14 20:17:42 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 14 May 2013 16:17:42 -0400 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <51929626.9030504@vaxination.ca> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> Message-ID: On Tue, May 14, 2013 at 3:53 PM, Jean-Francois Mezei wrote: > On 13-05-14 13:06, Jay Ashworth wrote: > >> http://variety.com/2013/digital/news/netflix-puts-even-more-strain-on-the-internet-1200480561/ >> >> they suggest that Akamai and other ISP-side caching is either not >> affecting these numbers and their pertinence to the "backbone" at all, >> or not much. > > > This is from a Sandvine press release. Sandvine measures traffic at the > last mile, so it doesn't really know whether a Netflix stream is coming > from a local caching server within the carrier's LAN, from a caching > server that is peering with the carrier, or via the real internet. can't the routing data on the network tell them some of this? or even routing data collected from like 'routeviews'? they don't even really need 'live' data as much as daily snapshots to say: "Yea, that network is 3 as-hops away -- it's across the "backbone"". sounds like lazy research... > In the case of a large ISP with a Netflix cache server accessible > locally, (either in-house, or via peering at a local carrier hotel), the > traffic doesn't really travel on the internet. and that fact ought to be visible in the local routing system and/or global system. > But for smaller ISPs, the traffic will travel on the internet between > the nearest cache server and their facilities. > > Because of caching, the load on the actual internet won't increase as > much as the amoount streamed onto last mile infrastructure. one hopes. (providing cache-hit is above a few percent) -chris From berni at birkenwald.de Tue May 14 20:18:12 2013 From: berni at birkenwald.de (Bernhard Schmidt) Date: Tue, 14 May 2013 20:18:12 +0000 (UTC) Subject: Could not send email to office 365 References: <20130501182123.2455.AEA43824@ugec.net> <51820ABE.4070000@isc.org> <2AEB6E00-1ECA-460F-A656-98085B5F053D@hopcount.ca> <9826f8732f844d44a3b5c4ff3b50ac73@DFM-DB3MBX15-07.exchange.corp.microsoft.com> Message-ID: Jason Sherron wrote: Hello Jason, > I'm an engineer on the Microsoft Office365 Exchange Online > ("outlook.office365.com") network team. I'm gathering forensics > specific to IPv6 reports -- are people still experiencing IPv6-related > issues? I am interested solely in failures that are IPv6 connection > issues to "outlook.office365.com". Looks okay from my POV now. Thanks for fixing it, can you share the root cause? This issue had rather interesting symptoms. Bernhard From ESundberg at nitelusa.com Tue May 14 22:59:32 2013 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Tue, 14 May 2013 22:59:32 +0000 Subject: Looking for Netflow analysis package Message-ID: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> Does anyone know of a netflow collector that will do the following. *Graph/List Destination Networks By Top AS *Graph/List Destination Networks By Top IP Address *AS Path Analysis *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) We will be using this to help us decide who to Peer with and what transit Providers to look at. I am familiar with Arbor Network's Peak Flow utility but it's a little too pricy. I also found AS-Stats https://neon1.net/as-stats/ look promising from the power point on their page. Thanks Erik ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From dhubbard at dino.hostasaurus.com Tue May 14 23:10:05 2013 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 14 May 2013 19:10:05 -0400 Subject: Looking for Netflow analysis package References: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> Message-ID: The Netflow analyzer from Solarwinds works pretty well for all of that provided you're receiving the data from a Cisco source that does netflow v9. It is not very useful at all for sflow though because they haven't updated it to recognize the ASN data. Their sales staff will also hound you relentlessly about 'special pricing' for their other products while not actually being willing to give anything all that special, so use a throwaway email address and phone number if you do choose to purchase and don't want to be bothered. David > -----Original Message----- > From: Erik Sundberg [mailto:ESundberg at nitelusa.com] > Sent: Tuesday, May 14, 2013 7:00 PM > To: nanog at nanog.org > Subject: Looking for Netflow analysis package > > Does anyone know of a netflow collector that will do the following. > *Graph/List Destination Networks By Top AS > *Graph/List Destination Networks By Top IP Address > *AS Path Analysis > *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) > > We will be using this to help us decide who to Peer with and > what transit Providers to look at. > > I am familiar with Arbor Network's Peak Flow utility but it's > a little too pricy. > I also found AS-Stats https://neon1.net/as-stats/ look > promising from the power point on their page. > > Thanks > Erik > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any > documents, files or previous e-mail messages attached to it > may contain confidential information that is legally > privileged. If you are not the intended recipient, or a > person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, > copying, distribution or use of any of the information > contained in or attached to this transmission is STRICTLY > PROHIBITED. If you have received this transmission in error > please notify the sender immediately by replying to this > e-mail. You must destroy the original transmission and its > attachments without reading or saving in any manner. Thank you. > > From eyeronic.design at gmail.com Tue May 14 23:17:40 2013 From: eyeronic.design at gmail.com (Mike Hale) Date: Tue, 14 May 2013 16:17:40 -0700 Subject: Looking for Netflow analysis package In-Reply-To: References: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> Message-ID: Solarwinds netflow is also way, way overpriced for what you get...and their license model for Netflow is utterly ridiculous. I like Splunk plus Netflow integrator. With some custom lookup tables, you might be able to code up a view that'll show you the per-ASN stats. You can definitely do it by Subnet pretty easily. On Tue, May 14, 2013 at 4:10 PM, David Hubbard wrote: > The Netflow analyzer from Solarwinds works pretty well for > all of that provided you're receiving the data from a > Cisco source that does netflow v9. It is not very useful > at all for sflow though because they haven't updated it to > recognize the ASN data. Their sales staff will also hound > you relentlessly about 'special pricing' for their other > products while not actually being willing to give anything > all that special, so use a throwaway email address and phone > number if you do choose to purchase and don't want to be > bothered. > > David > >> -----Original Message----- >> From: Erik Sundberg [mailto:ESundberg at nitelusa.com] >> Sent: Tuesday, May 14, 2013 7:00 PM >> To: nanog at nanog.org >> Subject: Looking for Netflow analysis package >> >> Does anyone know of a netflow collector that will do the following. >> *Graph/List Destination Networks By Top AS >> *Graph/List Destination Networks By Top IP Address >> *AS Path Analysis >> *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) >> >> We will be using this to help us decide who to Peer with and >> what transit Providers to look at. >> >> I am familiar with Arbor Network's Peak Flow utility but it's >> a little too pricy. >> I also found AS-Stats https://neon1.net/as-stats/ look >> promising from the power point on their page. >> >> Thanks >> Erik >> >> >> ________________________________ >> >> CONFIDENTIALITY NOTICE: This e-mail transmission, and any >> documents, files or previous e-mail messages attached to it >> may contain confidential information that is legally >> privileged. If you are not the intended recipient, or a >> person responsible for delivering it to the intended >> recipient, you are hereby notified that any disclosure, >> copying, distribution or use of any of the information >> contained in or attached to this transmission is STRICTLY >> PROHIBITED. If you have received this transmission in error >> please notify the sender immediately by replying to this >> e-mail. You must destroy the original transmission and its >> attachments without reading or saving in any manner. Thank you. >> >> > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From ravi at cow.org Tue May 14 23:25:15 2013 From: ravi at cow.org (Ravi Pina) Date: Tue, 14 May 2013 19:25:15 -0400 Subject: Looking for Netflow analysis package In-Reply-To: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> Message-ID: <20130514232515.GH31279@neu.cow.org> While it doesn't do everything you're looking for nfsen[1] is pretty extensible. [1] http://nfsen.sourceforge.net/ On Tue, May 14, 2013 at 10:59:32PM +0000, Erik Sundberg wrote: > Does anyone know of a netflow collector that will do the following. > *Graph/List Destination Networks By Top AS > *Graph/List Destination Networks By Top IP Address > *AS Path Analysis > *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) > > We will be using this to help us decide who to Peer with and what transit Providers to look at. > > I am familiar with Arbor Network's Peak Flow utility but it's a little too pricy. > I also found AS-Stats https://neon1.net/as-stats/ look promising from the power point on their page. > > Thanks > Erik > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From wbailey at satelliteintelligencegroup.com Tue May 14 23:45:28 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 14 May 2013 23:45:28 +0000 Subject: Looking for Netflow analysis package In-Reply-To: References: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads>, Message-ID: Where are all my ntop brethren? Sent from my Mobile Device. -------- Original message -------- From: David Hubbard Date: 05/14/2013 4:12 PM (GMT-08:00) To: nanog at nanog.org Subject: RE: Looking for Netflow analysis package The Netflow analyzer from Solarwinds works pretty well for all of that provided you're receiving the data from a Cisco source that does netflow v9. It is not very useful at all for sflow though because they haven't updated it to recognize the ASN data. Their sales staff will also hound you relentlessly about 'special pricing' for their other products while not actually being willing to give anything all that special, so use a throwaway email address and phone number if you do choose to purchase and don't want to be bothered. David > -----Original Message----- > From: Erik Sundberg [mailto:ESundberg at nitelusa.com] > Sent: Tuesday, May 14, 2013 7:00 PM > To: nanog at nanog.org > Subject: Looking for Netflow analysis package > > Does anyone know of a netflow collector that will do the following. > *Graph/List Destination Networks By Top AS > *Graph/List Destination Networks By Top IP Address > *AS Path Analysis > *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) > > We will be using this to help us decide who to Peer with and > what transit Providers to look at. > > I am familiar with Arbor Network's Peak Flow utility but it's > a little too pricy. > I also found AS-Stats https://neon1.net/as-stats/ look > promising from the power point on their page. > > Thanks > Erik > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any > documents, files or previous e-mail messages attached to it > may contain confidential information that is legally > privileged. If you are not the intended recipient, or a > person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, > copying, distribution or use of any of the information > contained in or attached to this transmission is STRICTLY > PROHIBITED. If you have received this transmission in error > please notify the sender immediately by replying to this > e-mail. You must destroy the original transmission and its > attachments without reading or saving in any manner. Thank you. > > From dedelman at iname.com Tue May 14 23:51:11 2013 From: dedelman at iname.com (David Edelman) Date: Tue, 14 May 2013 19:51:11 -0400 Subject: Looking for Netflow analysis package In-Reply-To: References: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> Message-ID: <82872EAB-2FC9-44C5-AAA5-84CF87B80AE1@iname.com> Take a look at argus www.qosient.com Dave Edelman On May 14, 2013, at 19:17, Mike Hale wrote: > Solarwinds netflow is also way, way overpriced for what you get...and > their license model for Netflow is utterly ridiculous. > > I like Splunk plus Netflow integrator. With some custom lookup > tables, you might be able to code up a view that'll show you the > per-ASN stats. You can definitely do it by Subnet pretty easily. > > On Tue, May 14, 2013 at 4:10 PM, David Hubbard > wrote: >> The Netflow analyzer from Solarwinds works pretty well for >> all of that provided you're receiving the data from a >> Cisco source that does netflow v9. It is not very useful >> at all for sflow though because they haven't updated it to >> recognize the ASN data. Their sales staff will also hound >> you relentlessly about 'special pricing' for their other >> products while not actually being willing to give anything >> all that special, so use a throwaway email address and phone >> number if you do choose to purchase and don't want to be >> bothered. >> >> David >> >>> -----Original Message----- >>> From: Erik Sundberg [mailto:ESundberg at nitelusa.com] >>> Sent: Tuesday, May 14, 2013 7:00 PM >>> To: nanog at nanog.org >>> Subject: Looking for Netflow analysis package >>> >>> Does anyone know of a netflow collector that will do the following. >>> *Graph/List Destination Networks By Top AS >>> *Graph/List Destination Networks By Top IP Address >>> *AS Path Analysis >>> *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) >>> >>> We will be using this to help us decide who to Peer with and >>> what transit Providers to look at. >>> >>> I am familiar with Arbor Network's Peak Flow utility but it's >>> a little too pricy. >>> I also found AS-Stats https://neon1.net/as-stats/ look >>> promising from the power point on their page. >>> >>> Thanks >>> Erik >>> >>> >>> ________________________________ >>> >>> CONFIDENTIALITY NOTICE: This e-mail transmission, and any >>> documents, files or previous e-mail messages attached to it >>> may contain confidential information that is legally >>> privileged. If you are not the intended recipient, or a >>> person responsible for delivering it to the intended >>> recipient, you are hereby notified that any disclosure, >>> copying, distribution or use of any of the information >>> contained in or attached to this transmission is STRICTLY >>> PROHIBITED. If you have received this transmission in error >>> please notify the sender immediately by replying to this >>> e-mail. You must destroy the original transmission and its >>> attachments without reading or saving in any manner. Thank you. > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > From patrick at ianai.net Wed May 15 00:51:20 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 14 May 2013 20:51:20 -0400 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> Message-ID: <7E4E0410-879B-48EA-8F88-30AC8E5B51BB@ianai.net> On May 14, 2013, at 13:06 , Jay Ashworth wrote: > Or I don't. Which is not completely impossible. > > In this piece: > > http://variety.com/2013/digital/news/netflix-puts-even-more-strain-on-the-internet-1200480561/ > > they suggest that Akamai and other ISP-side caching is either not > affecting these numbers and their pertinence to the "backbone" at all, > or not much. > > Did they miss something? or did I? I don't see the word "backbone" in there, other than in the comments. Your DSL line is part of the Internet, and doing more traffic puts more "strain" (FSVO "strain") on that link, even if the server is colocated with the cable head end. So I don't see the problem here. But then, maybe I'm the one who is confused? :) -- TTFN, patrick From patrick at ianai.net Wed May 15 00:55:50 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 14 May 2013 20:55:50 -0400 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <51929626.9030504@vaxination.ca> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> Message-ID: On May 14, 2013, at 15:53 , Jean-Francois Mezei wrote: > On 13-05-14 13:06, Jay Ashworth wrote: > >> http://variety.com/2013/digital/news/netflix-puts-even-more-strain-on-the-internet-1200480561/ >> >> they suggest that Akamai and other ISP-side caching is either not >> affecting these numbers and their pertinence to the "backbone" at all, >> or not much. > > > This is from a Sandvine press release. Sandvine measures traffic at the > last mile, so it doesn't really know whether a Netflix stream is coming > from a local caching server within the carrier's LAN, from a caching > server that is peering with the carrier, or via the real internet. > > In the case of a large ISP with a Netflix cache server accessible > locally, (either in-house, or via peering at a local carrier hotel), the > traffic doesn't really travel on the internet. Since when is peering not part of the Internet? Since when is even on-net caches not part of the Internet? I always thought if I am on the Internet, anything I ping is "on the Internet". (I am intentionally ignoring things like split tunnel VPN nodes.) Perhaps you think of the "Internet" as the "tier ones" or something? > But for smaller ISPs, the traffic will travel on the internet between > the nearest cache server and their facilities. I guess you assume smaller ISPs don't peer? Unfortunately, reality disagrees with you, 100s if not 1000s of times. Still confused about this whole notion, though. Perhaps you can clarify? > Because of caching, the load on the actual internet won't increase as > much as the amoount streamed onto last mile infrastructure. Uh.... I give up. -- TTFN, patrick From jfmezei_nanog at vaxination.ca Wed May 15 01:14:56 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 14 May 2013 21:14:56 -0400 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> Message-ID: <5192E190.2000007@vaxination.ca> On 13-05-14 20:55, Patrick W. Gilmore wrote: > Since when is peering not part of the Internet? Yes, one car argue that an device with an IP address routable from the internet is part of the internet. But when traffic from a cahe server flows directly into an ISP's intranet to end users, it doesn't really make use of the "Internet" nor does it cost the ISP transit capacity. Compare this to a small ISP in a city where there are no cache servers. Reaching netfix involves using paid transit to reach the nearest point where Netflix has a cache server. So traffic truly travels on the internet. From jloiacon at csc.com Wed May 15 01:15:00 2013 From: jloiacon at csc.com (Joe Loiacono) Date: Tue, 14 May 2013 21:15:00 -0400 Subject: Looking for Netflow analysis package In-Reply-To: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> Message-ID: Check out the FlowViewer/flow-tools/SiLK combo also. https://sourceforge.net/projects/flowviewer/ Erik Sundberg wrote on 05/14/2013 06:59:32 PM: > From: Erik Sundberg > To: "nanog at nanog.org" > Date: 05/14/2013 07:00 PM > Subject: Looking for Netflow analysis package > > Does anyone know of a netflow collector that will do the following. > *Graph/List Destination Networks By Top AS > *Graph/List Destination Networks By Top IP Address > *AS Path Analysis > *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) > > We will be using this to help us decide who to Peer with and what > transit Providers to look at. > > I am familiar with Arbor Network's Peak Flow utility but it's a > little too pricy. > I also found AS-Stats https://neon1.net/as-stats/ look promising > from the power point on their page. > > Thanks > Erik > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, > files or previous e-mail messages attached to it may contain > confidential information that is legally privileged. If you are not > the intended recipient, or a person responsible for delivering it to > the intended recipient, you are hereby notified that any disclosure, > copying, distribution or use of any of the information contained in > or attached to this transmission is STRICTLY PROHIBITED. If you have > received this transmission in error please notify the sender > immediately by replying to this e-mail. You must destroy the > original transmission and its attachments without reading or saving > in any manner. Thank you. From joesox at gmail.com Wed May 15 01:19:31 2013 From: joesox at gmail.com (JoeSox) Date: Tue, 14 May 2013 18:19:31 -0700 Subject: Could not send email to office 365 In-Reply-To: <9826f8732f844d44a3b5c4ff3b50ac73@DFM-DB3MBX15-07.exchange.corp.microsoft.com> References: <20130501182123.2455.AEA43824@ugec.net> <51820ABE.4070000@isc.org> <2AEB6E00-1ECA-460F-A656-98085B5F053D@hopcount.ca> <9826f8732f844d44a3b5c4ff3b50ac73@DFM-DB3MBX15-07.exchange.corp.microsoft.com> Message-ID: Hi Jason, My business mysteriously stabilized after speaking with the Escalation Manager of North America, last week. Next, health status statement said it was a false-positive on May 9th. Yesterday, speaking with the tech to close my case, he had a hunch engineering fixed something but he made it clear that he was only guessing. I never was able to get a real cause of this issue for the company I work for or the reported other companies in North America reporting the issue. Troubleshooting never led me down an IPv6 path but others might have, or maybe that was the root cause on the Microsoft side. -- Thanks, Joe On Tue, May 14, 2013 at 11:02 AM, Jason Sherron wrote: > I'm an engineer on the Microsoft Office365 Exchange Online (" > outlook.office365.com") network team. I'm gathering forensics specific to > IPv6 reports -- are people still experiencing IPv6-related issues? I am > interested solely in failures that are IPv6 connection issues to " > outlook.office365.com". > > If you have a clear repro of an IPv6 connection failure, please message me > off-list with at least a traceroute. (Please don't deluge me with > non-IPv6-related issues -- I'm a network guy working on this one report.) > > Jason (dot) Sherron [at] Microsoft (dot) com > > > > -----Original Message----- > From: JoeSox [mailto:joesox at gmail.com] > Sent: Wednesday, May 8, 2013 4:35 PM > To: nanog at nanog.org > Subject: Re: Could not send email to office 365 > > Just an update if list members are still experiencing this issue. I spoke > on the phone with Escalation Manager for Microsoft North America and they > had meetings today and their Engineering team is putting a game plan > together to roll out a fix for the Outlook connectivity issues. They were > debating to roll-out to the group of effected customers or one-by-one. From > the data I provided to them it looks like something to do with their NSPI > RPC endpoint environment. They told me I should receive a call tomorrow but > call them Friday if I do not receive a call. Hopefully, everyone else > experiencing this issue is being taken care of as this is the main concern > with Cloud services is the lack of response times on major issues. > -- > Thanks, Joe > > > On Thu, May 2, 2013 at 10:16 AM, JoeSox wrote: > > > Our Technical Support is reporting a big jump in Outlook connectivity > > issues about 5-10 minutes ago. > > Our resolvers are testing fine. > > -- > > Thanks, Joe > > > > > > On Thu, May 2, 2013 at 4:53 AM, Joe Abley wrote: > > > >> > >> On 2013-05-02, at 02:42, Cathy Almond wrote: > >> > >> > This may be a red herring, but I've heard of some dropping of DNS > >> > queries for the names within outlook.com domains where the queries > >> > are all coming from source port 53 (i.e. your recursive server > >> > doesn't use query source port randomization > >> > >> ... or there's a NAT or some other box in front of the recursive > >> server which re-writes the source port... > >> > >> > ). Might be worth checking what the recursive server you're using > >> > is doing? > >> > > >> > See https://www.dns-oarc.net/oarc/services/porttest > >> > >> > >> Joe > >> > > > > > From patrick at ianai.net Wed May 15 01:24:28 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 14 May 2013 21:24:28 -0400 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <5192E190.2000007@vaxination.ca> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> <5192E190.2000007@vaxination.ca> Message-ID: On May 14, 2013, at 21:14 , Jean-Francois Mezei wrote: > On 13-05-14 20:55, Patrick W. Gilmore wrote: >> Since when is peering not part of the Internet? > > Yes, one car argue that an device with an IP address routable from the > internet is part of the internet. Can argue? How would you define the Internet? > But when traffic from a cahe server flows directly into an ISP's > intranet to end users, it doesn't really make use of the "Internet" nor > does it cost the ISP transit capacity. Transit capacity != "Internet". Plus you said even peering wasn't the Internet. > Compare this to a small ISP in a city where there are no cache servers. > Reaching netfix involves using paid transit to reach the nearest point > where Netflix has a cache server. So traffic truly travels on the internet. "Truly"? You have interesting definitions. I think you are trying to say "small ISPs have to pay to access $CONTENT, big ones do not". This is objectively false-to-fact. If you are trying to say scale makes some things easier, then I'm sure most people would agree. But trying to define the Internet as transit capacity, or saying small ISPs can't peer, or anything of the sort is silly. -- TTFN, patrick From hhoffman at ip-solutions.net Wed May 15 01:25:55 2013 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 14 May 2013 21:25:55 -0400 Subject: Looking for Netflow analysis package Message-ID: From ag4ve.us at gmail.com Wed May 15 02:02:15 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Tue, 14 May 2013 22:02:15 -0400 Subject: Looking for Netflow analysis package In-Reply-To: References: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> Message-ID: Not exactly netflow until you set it up as such buy, Graylog2 and LogStash are OSS. Also, I'll probably be releasing modules and a simple evented (POE) program in perl soon (don't wait up if you can't deal with code - it ain't and ain't going to be a web app but a simple framework mainly for the simplest and fastest parsing regexes). But all of the modern log aggregation software uses ElasticSearch as a data store which makes correlation / netflow pretty easy. On May 14, 2013 9:20 PM, "Joe Loiacono" wrote: > Check out the FlowViewer/flow-tools/SiLK combo also. > > https://sourceforge.net/projects/flowviewer/ > > > > Erik Sundberg wrote on 05/14/2013 06:59:32 PM: > > > From: Erik Sundberg > > To: "nanog at nanog.org" > > Date: 05/14/2013 07:00 PM > > Subject: Looking for Netflow analysis package > > > > Does anyone know of a netflow collector that will do the following. > > *Graph/List Destination Networks By Top AS > > *Graph/List Destination Networks By Top IP Address > > *AS Path Analysis > > *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) > > > > We will be using this to help us decide who to Peer with and what > > transit Providers to look at. > > > > I am familiar with Arbor Network's Peak Flow utility but it's a > > little too pricy. > > I also found AS-Stats https://neon1.net/as-stats/ look promising > > from the power point on their page. > > > > Thanks > > Erik > > > > > > ________________________________ > > > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, > > files or previous e-mail messages attached to it may contain > > confidential information that is legally privileged. If you are not > > the intended recipient, or a person responsible for delivering it to > > the intended recipient, you are hereby notified that any disclosure, > > copying, distribution or use of any of the information contained in > > or attached to this transmission is STRICTLY PROHIBITED. If you have > > received this transmission in error please notify the sender > > immediately by replying to this e-mail. You must destroy the > > original transmission and its attachments without reading or saving > > in any manner. Thank you. > > > From jlester at wcs.k12.va.us Wed May 15 02:18:07 2013 From: jlester at wcs.k12.va.us (Jason Lester) Date: Tue, 14 May 2013 22:18:07 -0400 Subject: Looking for Netflow analysis package In-Reply-To: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> Message-ID: ManageEngine's NetFlow Analyzer will do most of that (not sure about AS Path Analysis.) It is priced per monitored interface, but is pretty reasonable for what it does. They have a 30-day demo available. We use their full OpManager+NetFlow suite to monitor several hundred devices with thousands of interfaces. We only license NetFlow for the interfaces that connect to external providers. E-mail me privately if you want to see the reports. Jason On Tue, May 14, 2013 at 6:59 PM, Erik Sundberg wrote: > Does anyone know of a netflow collector that will do the following. > *Graph/List Destination Networks By Top AS > *Graph/List Destination Networks By Top IP Address > *AS Path Analysis > *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) > > We will be using this to help us decide who to Peer with and what transit > Providers to look at. > > I am familiar with Arbor Network's Peak Flow utility but it's a little too > pricy. > I also found AS-Stats https://neon1.net/as-stats/ look promising from the > power point on their page. > > Thanks > Erik > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > From nanog at data102.com Wed May 15 02:32:25 2013 From: nanog at data102.com (randal k) Date: Tue, 14 May 2013 20:32:25 -0600 Subject: Looking for Netflow analysis package In-Reply-To: References: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> Message-ID: We use/d nfsen extensively for this this past November & December and have been very successful in planning our bandwidth purchases since then. We like it so much that reliable, full-speed Netflow telemetry is now a requirement on all edge/core routers. Randal On Tue, May 14, 2013 at 8:18 PM, Jason Lester wrote: > ManageEngine's NetFlow Analyzer will do most of that (not sure about AS > Path Analysis.) It is priced per monitored interface, but is pretty > reasonable for what it does. They have a 30-day demo available. We use > their full OpManager+NetFlow suite to monitor several hundred devices with > thousands of interfaces. We only license NetFlow for the interfaces that > connect to external providers. > > E-mail me privately if you want to see the reports. > > Jason > > > On Tue, May 14, 2013 at 6:59 PM, Erik Sundberg >wrote: > > > Does anyone know of a netflow collector that will do the following. > > *Graph/List Destination Networks By Top AS > > *Graph/List Destination Networks By Top IP Address > > *AS Path Analysis > > *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) > > > > We will be using this to help us decide who to Peer with and what transit > > Providers to look at. > > > > I am familiar with Arbor Network's Peak Flow utility but it's a little > too > > pricy. > > I also found AS-Stats https://neon1.net/as-stats/ look promising from > the > > power point on their page. > > > > Thanks > > Erik > > > > > > ________________________________ > > > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, > files > > or previous e-mail messages attached to it may contain confidential > > information that is legally privileged. If you are not the intended > > recipient, or a person responsible for delivering it to the intended > > recipient, you are hereby notified that any disclosure, copying, > > distribution or use of any of the information contained in or attached to > > this transmission is STRICTLY PROHIBITED. If you have received this > > transmission in error please notify the sender immediately by replying to > > this e-mail. You must destroy the original transmission and its > attachments > > without reading or saving in any manner. Thank you. > > > From rubensk at gmail.com Wed May 15 02:40:38 2013 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 14 May 2013 23:40:38 -0300 Subject: Looking for Netflow analysis package In-Reply-To: References: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> Message-ID: On Tue, May 14, 2013 at 11:18 PM, Jason Lester wrote: > ManageEngine's NetFlow Analyzer will do most of that (not sure about AS > Path Analysis.) It is priced per monitored interface, but is pretty > reasonable for what it does. They have a 30-day demo available. We use > their full OpManager+NetFlow suite to monitor several hundred devices with > thousands of interfaces. We only license NetFlow for the interfaces that > connect to external providers. This product cannot stand any service provider production network I can think of. It is toooooo slow to handle high-speed routers. I suggest staying away from all ManageEngine's products in general, but NFA is the worst of them. Rubens From peter.phaal at gmail.com Wed May 15 03:55:28 2013 From: peter.phaal at gmail.com (Peter Phaal) Date: Tue, 14 May 2013 20:55:28 -0700 Subject: Looking for Netflow analysis package In-Reply-To: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> Message-ID: You might want to take a look at pmacct, http://www.pmacct.net/. It includes an embedded version of Quagga, allowing BGP AS Path data to be efficiently joined with flow records. Peter On Tue, May 14, 2013 at 3:59 PM, Erik Sundberg wrote: > Does anyone know of a netflow collector that will do the following. > *Graph/List Destination Networks By Top AS > *Graph/List Destination Networks By Top IP Address > *AS Path Analysis > *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) > > We will be using this to help us decide who to Peer with and what transit > Providers to look at. > > I am familiar with Arbor Network's Peak Flow utility but it's a little too > pricy. > I also found AS-Stats https://neon1.net/as-stats/ look promising from the > power point on their page. > > Thanks > Erik > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > From andra.lutu at imdea.org Wed May 15 10:22:10 2013 From: andra.lutu at imdea.org (Andra Lutu) Date: Wed, 15 May 2013 12:22:10 +0200 Subject: The BGP Visibility Scanner Message-ID: <519361D2.8040508@imdea.org> Dear all, We have built a tool that checks the visibility of IPv4 prefixes at the interdomain level. The tool is available at *http://visibility.it.uc3m.es/* and you can use it to retrieve the Limited Visibility Prefixes (LVPs) (i.e., prefixes that are not present in all the global routing tables we analyse) injected by a certain originating AS. The query is very simple, it just requires to input the AS number for which you want to retrieve the originated LVPs, if any. After checking the limited-visibility prefixes, we would appreciate any feedback that you can provide on the cause of the limited visibility (we provide a form with a few very short questions which you could fill in and submit). Using a dataset from May 2nd 2013, we generated a list with the ASes which are originating LVPs: *http://visibility.it.uc3m.es/fullASlist.html* We would like to hear from any operator who might find this project interesting, and, in particular, from these large contributors to the LVPs set. Please note that advertising prefixes with limited visibility does not mean that the originating AS is necessarily doing something wrong. The ASes might be generating the LVPs knowingly (e.g., scoped advertisements). However, there might be cases where the origin AS might be unaware that some prefixes are not globally visible (when they should) or that others are leaking as a consequence of mis-configurations/slips. Our purpose is to spread awareness about these latter phenomena, help eliminate the cause of unintended/accidental LVPs and upgrade this tool to an anomaly detection mechanism. For more information on the definition and characteristics of a Limited Visibility prefix, please check the Frequently Asked Questions section of the webpage, available here: *http://visibility.it.uc3m.es/Q_and_A_latest.html* The tool works with publicly available BGP routing data, retrieved from the RIPE NCC RIS and RouteViews Projects. The results are updated on a daily basis. For more information on the methodology we refer you to the slides of the NANOG57 presentation about the BGP Visibility Scanner: http://www.nanog.org/meetings/nanog57/presentations/Wednesday/wed.general.Lutu.BGP_visibility_scanner.19.pdf Also, you can check the RIPE labs article about the BGP Visibility Scanner, available here: https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner We are looking forward to your feedback! Thank you, best regards, Andra From james at towardex.com Wed May 15 10:24:03 2013 From: james at towardex.com (james at towardex.com) Date: Wed, 15 May 2013 06:24:03 -0400 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <5192E190.2000007@vaxination.ca> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> <5192E190.2000007@vaxination.ca> Message-ID: <084401ce5156$53088e30$f919aa90$@towardex.com> On May 14, 2013, Jean-Francois Mezei wrote: > But when traffic from a cahe server flows directly into an ISP's intranet to end users, it doesn't really make use of the "Internet" nor does it cost the ISP transit capacity. > Compare this to a small ISP in a city where there are no cache servers. > Reaching netfix involves using paid transit to reach the nearest point where Netflix has a cache server. So traffic truly travels on the internet. We're a small ISP and we reach lot of content via peering just fine. Lot of these contents that you speak of (Netflix, Akamai, et al) have open peering policies and are present in more exchange points than anybody else. james From jhellenthal at dataix.net Wed May 15 13:00:53 2013 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Wed, 15 May 2013 09:00:53 -0400 Subject: The BGP Visibility Scanner In-Reply-To: <519361D2.8040508@imdea.org> References: <519361D2.8040508@imdea.org> Message-ID: <33E73ACC-9AE0-4BD9-9E57-470CCF95979D@DataIX.net> Pretty nice. Thanks! I don't suppose there is any straight text version of all this info is there ? -- Jason Hellenthal IS&T Services Professional Inbox: jhellenthal at DataIX.net JJH48-ARIN On May 15, 2013, at 6:22, Andra Lutu wrote: > Dear all, > > We have built a tool that checks the visibility of IPv4 prefixes at the interdomain level. > The tool is available at *http://visibility.it.uc3m.es/* and you can use it to retrieve the Limited Visibility Prefixes (LVPs) (i.e., prefixes that are not present in all the global routing tables we analyse) injected by a certain originating AS. > The query is very simple, it just requires to input the AS number for which you want to retrieve the originated LVPs, if any. > After checking the limited-visibility prefixes, we would appreciate any feedback that you can provide on the cause of the limited visibility (we provide a form with a few very short questions which you could fill in and submit). > > Using a dataset from May 2nd 2013, we generated a list with the ASes which are originating LVPs: *http://visibility.it.uc3m.es/fullASlist.html* > We would like to hear from any operator who might find this project interesting, and, in particular, from these large contributors to the LVPs set. > Please note that advertising prefixes with limited visibility does not mean that the originating AS is necessarily doing something wrong. > The ASes might be generating the LVPs knowingly (e.g., scoped advertisements). However, there might be cases where the origin AS might be unaware that some prefixes are not globally visible (when they should) or that others are leaking as a consequence of mis-configurations/slips. > > Our purpose is to spread awareness about these latter phenomena, help eliminate the cause of unintended/accidental LVPs and upgrade this tool to an anomaly detection mechanism. > For more information on the definition and characteristics of a Limited Visibility prefix, please check the Frequently Asked Questions section of the webpage, available here: *http://visibility.it.uc3m.es/Q_and_A_latest.html* > > The tool works with publicly available BGP routing data, retrieved from the RIPE NCC RIS and RouteViews Projects. The results are updated on a daily basis. > For more information on the methodology we refer you to the slides of the NANOG57 presentation about the BGP Visibility Scanner: > http://www.nanog.org/meetings/nanog57/presentations/Wednesday/wed.general.Lutu.BGP_visibility_scanner.19.pdf > Also, you can check the RIPE labs article about the BGP Visibility Scanner, available here: https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner > > We are looking forward to your feedback! > > Thank you, best regards, > Andra From rbf+nanog at panix.com Wed May 15 13:02:56 2013 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Wed, 15 May 2013 08:02:56 -0500 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <5192E190.2000007@vaxination.ca> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> <5192E190.2000007@vaxination.ca> Message-ID: <20130515130256.GA23735@panix.com> On Tue, May 14, 2013 at 09:14:56PM -0400, Jean-Francois Mezei wrote: > On 13-05-14 20:55, Patrick W. Gilmore wrote: > > > Since when is peering not part of the Internet? > > Yes, one car argue that an device with an IP address routable from the > internet is part of the internet. > > But when traffic from a cahe server flows directly into an ISP's > intranet to end users, it doesn't really make use of the "Internet" nor > does it cost the ISP transit capacity. So it's only on the Internet if it uses a provider's transit capacity? So if ISP1 and ISP2 are customers of ISP3 (and ISP3 is the only provider-to-provider connection for ISP1 and ISP2), then traffic between a customer of ISP1 and a customer of ISP2 is on the "Internet"? What if ISP1 and ISP2 then setup a private peering connection? Is traffic between ISP1 and ISP2 still on "the Internet", or is that reserved for traffic over paid transit? And if that's still "on the Internet", what happens if ISP1 then buys IPS2? Does the traffic between them cease to be "on the Internet" now that it's the same company? And, if you define "on the Internet" to mean "goes over paid transit", then the only traffic that is on the Internet is traffic to ISPs who have paid transit. Traffic between end customers of two Tier 1 providers (defined as "providers who don't pay for any transit" for the purposes of this message) would never be "on the Internet"? (I assume "transit", if that's your threshold, is "transit paid for by a provider". End user connections are essentially paid transit, even though it's not typically called that, especially at the lower end.) The point is: I don't think you definition works. Could post exactly what your definition of "on the Internet" is (as opposed to just enumerating examples of things you think are on the internet and things you think are not on the Internet)? -- Brett From jamel at cin.ufpe.br Wed May 15 14:29:29 2013 From: jamel at cin.ufpe.br (Djamel Sadok) Date: Wed, 15 May 2013 11:29:29 -0300 Subject: CDN server log Message-ID: Hi, Anyone knows of any public CDN server log trace. I am looking for object popularity, hit rate information, ... Thanks, Djamel From andra.lutu at imdea.org Wed May 15 14:51:13 2013 From: andra.lutu at imdea.org (Andra Lutu) Date: Wed, 15 May 2013 16:51:13 +0200 Subject: The BGP Visibility Scanner In-Reply-To: <33E73ACC-9AE0-4BD9-9E57-470CCF95979D@DataIX.net> References: <519361D2.8040508@imdea.org> <33E73ACC-9AE0-4BD9-9E57-470CCF95979D@DataIX.net> Message-ID: <5193A0E1.5080209@imdea.org> Hi Jason, Thank you for your email! We are glad to hear that you like the work! At the moment, you can only query the webpage and retrieve the LVPs per origin AS. We haven't yet considered giving the option of downloading the complete report. We are now working on a new version of the tool, and we will try to integrate your suggestion, thank you! If you have any other suggestions or requests, don't hesitate to let us know! Best regards, Andra On 05/15/2013 03:00 PM, Jason Hellenthal wrote: > Pretty nice. Thanks! > > I don't suppose there is any straight text version of all this info is > there ? > > /-- / > > /*Jason Hellenthal*/ > > IS&T Services Professional > > Inbox: /jhellenthal at DataIX.net / > > JJH48-ARIN > > > > On May 15, 2013, at 6:22, Andra Lutu > wrote: > >> Dear all, >> >> We have built a tool that checks the visibility of IPv4 prefixes at >> the interdomain level. >> The tool is available at *http://visibility.it.uc3m.es/* and you can >> use it to retrieve the Limited Visibility Prefixes (LVPs) (i.e., >> prefixes that are not present in all the global routing tables we >> analyse) injected by a certain originating AS. >> The query is very simple, it just requires to input the AS number for >> which you want to retrieve the originated LVPs, if any. >> After checking the limited-visibility prefixes, we would appreciate >> any feedback that you can provide on the cause of the limited >> visibility (we provide a form with a few very short questions which >> you could fill in and submit). >> >> Using a dataset from May 2nd 2013, we generated a list with the ASes >> which are originating LVPs: >> *http://visibility.it.uc3m.es/fullASlist.html* >> We would like to hear from any operator who might find this project >> interesting, and, in particular, from these large contributors to the >> LVPs set. >> Please note that advertising prefixes with limited visibility does >> not mean that the originating AS is necessarily doing something wrong. >> The ASes might be generating the LVPs knowingly (e.g., scoped >> advertisements). However, there might be cases where the origin AS >> might be unaware that some prefixes are not globally visible (when >> they should) or that others are leaking as a consequence of >> mis-configurations/slips. >> >> Our purpose is to spread awareness about these latter phenomena, help >> eliminate the cause of unintended/accidental LVPs and upgrade this >> tool to an anomaly detection mechanism. >> For more information on the definition and characteristics of a >> Limited Visibility prefix, please check the Frequently Asked >> Questions section of the webpage, available here: >> *http://visibility.it.uc3m.es/Q_and_A_latest.html* >> >> The tool works with publicly available BGP routing data, retrieved >> from the RIPE NCC RIS and RouteViews Projects. The results are >> updated on a daily basis. >> For more information on the methodology we refer you to the slides of >> the NANOG57 presentation about the BGP Visibility Scanner: >> http://www.nanog.org/meetings/nanog57/presentations/Wednesday/wed.general.Lutu.BGP_visibility_scanner.19.pdf >> Also, you can check the RIPE labs article about the BGP Visibility >> Scanner, available here: >> https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner >> >> We are looking forward to your feedback! >> >> Thank you, best regards, >> Andra From wilhelm at ripe.net Wed May 15 15:01:49 2013 From: wilhelm at ripe.net (Rene Wilhelm) Date: Wed, 15 May 2013 17:01:49 +0200 Subject: The BGP Visibility Scanner In-Reply-To: <33E73ACC-9AE0-4BD9-9E57-470CCF95979D@DataIX.net> References: <519361D2.8040508@imdea.org> <33E73ACC-9AE0-4BD9-9E57-470CCF95979D@DataIX.net> Message-ID: <5193A35D.8030405@ripe.net> On 5/15/13 3:00 PM, Jason Hellenthal wrote: > Pretty nice. Thanks! > > I don't suppose there is any straight text version of all this info is there ? At the RIPE NCC we are publishing aggregated dumps from our collective of 12 RIS route collectors every 8 hours. For each prefix we list the origin AS and the number of peers (on all collectors) which observe the prefix. If you are happy to do your own post-processing, set your own boundaries on what to consider limited visibility prefixes, have a look at the IPv4 and IPv6 table dumps at http://www.ris.ripe.net/dumps/ Note that the fact that not all RIS peers give us a full BGP table blurs the counts somewhat. Prefixes which are globally visible may (today) have anywhere between 96 and 110 peers announcing the prefix to the RIS route collectors. -- Rene > -- Jason Hellenthal IS&T Services Professional Inbox: > jhellenthal at DataIX.net JJH48-ARIN On May 15, 2013, at 6:22, Andra Lutu > wrote: >> >Dear all, >> > >> >We have built a tool that checks the visibility of IPv4 prefixes at the interdomain level. >> >The tool is available at *http://visibility.it.uc3m.es/* and you can use it to retrieve the Limited Visibility Prefixes (LVPs) (i.e., prefixes that are not present in all the global routing tables we analyse) injected by a certain originating AS. >> >The query is very simple, it just requires to input the AS number for which you want to retrieve the originated LVPs, if any. >> >After checking the limited-visibility prefixes, we would appreciate any feedback that you can provide on the cause of the limited visibility (we provide a form with a few very short questions which you could fill in and submit). >> > >> >Using a dataset from May 2nd 2013, we generated a list with the ASes which are originating LVPs:*http://visibility.it.uc3m.es/fullASlist.html* >> >We would like to hear from any operator who might find this project interesting, and, in particular, from these large contributors to the LVPs set. >> >Please note that advertising prefixes with limited visibility does not mean that the originating AS is necessarily doing something wrong. >> >The ASes might be generating the LVPs knowingly (e.g., scoped advertisements). However, there might be cases where the origin AS might be unaware that some prefixes are not globally visible (when they should) or that others are leaking as a consequence of mis-configurations/slips. >> > >> >Our purpose is to spread awareness about these latter phenomena, help eliminate the cause of unintended/accidental LVPs and upgrade this tool to an anomaly detection mechanism. >> >For more information on the definition and characteristics of a Limited Visibility prefix, please check the Frequently Asked Questions section of the webpage, available here:*http://visibility.it.uc3m.es/Q_and_A_latest.html* >> > >> >The tool works with publicly available BGP routing data, retrieved from the RIPE NCC RIS and RouteViews Projects. The results are updated on a daily basis. >> >For more information on the methodology we refer you to the slides of the NANOG57 presentation about the BGP Visibility Scanner: >> >http://www.nanog.org/meetings/nanog57/presentations/Wednesday/wed.general.Lutu.BGP_visibility_scanner.19.pdf >> >Also, you can check the RIPE labs article about the BGP Visibility Scanner, available here:https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner >> > >> >We are looking forward to your feedback! >> > >> >Thank you, best regards, >> >Andra From jhellenthal at dataix.net Wed May 15 15:07:39 2013 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Wed, 15 May 2013 11:07:39 -0400 Subject: The BGP Visibility Scanner In-Reply-To: <5193A35D.8030405@ripe.net> References: <519361D2.8040508@imdea.org> <33E73ACC-9AE0-4BD9-9E57-470CCF95979D@DataIX.net> <5193A35D.8030405@ripe.net> Message-ID: <95F6A519-7F00-4ACB-9C3B-34B3F318A40F@DataIX.net> Awesome! Thank you to you as well! -- Jason Hellenthal IS&T Services Professional Inbox: jhellenthal at DataIX.net JJH48-ARIN On May 15, 2013, at 11:01, Rene Wilhelm wrote: > > On 5/15/13 3:00 PM, Jason Hellenthal wrote: >> Pretty nice. Thanks! >> >> I don't suppose there is any straight text version of all this info is there ? > At the RIPE NCC we are publishing aggregated dumps from our collective of 12 RIS route collectors every 8 hours. For each prefix we list the origin AS and the number of peers (on all collectors) which observe the prefix. If you are happy to do your own post-processing, set your own boundaries on what to consider limited visibility prefixes, have a look at the IPv4 and IPv6 table dumps at http://www.ris.ripe.net/dumps/ > > Note that the fact that not all RIS peers give us a full BGP table blurs the counts somewhat. Prefixes which are globally visible may (today) have anywhere between 96 and 110 peers announcing the prefix to the RIS route collectors. > > -- Rene >> -- Jason Hellenthal IS&T Services Professional Inbox: jhellenthal at DataIX.net JJH48-ARIN On May 15, 2013, at 6:22, Andra Lutu wrote: >>> >Dear all, >>> > >>> >We have built a tool that checks the visibility of IPv4 prefixes at the interdomain level. >>> >The tool is available at *http://visibility.it.uc3m.es/* and you can use it to retrieve the Limited Visibility Prefixes (LVPs) (i.e., prefixes that are not present in all the global routing tables we analyse) injected by a certain originating AS. >>> >The query is very simple, it just requires to input the AS number for which you want to retrieve the originated LVPs, if any. >>> >After checking the limited-visibility prefixes, we would appreciate any feedback that you can provide on the cause of the limited visibility (we provide a form with a few very short questions which you could fill in and submit). >>> > >>> >Using a dataset from May 2nd 2013, we generated a list with the ASes which are originating LVPs:*http://visibility.it.uc3m.es/fullASlist.html* >>> >We would like to hear from any operator who might find this project interesting, and, in particular, from these large contributors to the LVPs set. >>> >Please note that advertising prefixes with limited visibility does not mean that the originating AS is necessarily doing something wrong. >>> >The ASes might be generating the LVPs knowingly (e.g., scoped advertisements). However, there might be cases where the origin AS might be unaware that some prefixes are not globally visible (when they should) or that others are leaking as a consequence of mis-configurations/slips. >>> > >>> >Our purpose is to spread awareness about these latter phenomena, help eliminate the cause of unintended/accidental LVPs and upgrade this tool to an anomaly detection mechanism. >>> >For more information on the definition and characteristics of a Limited Visibility prefix, please check the Frequently Asked Questions section of the webpage, available here:*http://visibility.it.uc3m.es/Q_and_A_latest.html* >>> > >>> >The tool works with publicly available BGP routing data, retrieved from the RIPE NCC RIS and RouteViews Projects. The results are updated on a daily basis. >>> >For more information on the methodology we refer you to the slides of the NANOG57 presentation about the BGP Visibility Scanner: >>> >http://www.nanog.org/meetings/nanog57/presentations/Wednesday/wed.general.Lutu.BGP_visibility_scanner.19.pdf >>> >Also, you can check the RIPE labs article about the BGP Visibility Scanner, available here:https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner >>> > >>> >We are looking forward to your feedback! >>> > >>> >Thank you, best regards, >>> >Andra > From ryan at u13.net Wed May 15 15:12:06 2013 From: ryan at u13.net (ryan at u13.net) Date: Wed, 15 May 2013 11:12:06 -0400 Subject: Borrow request (Chicago): Cat 4900M copper interface(s) Message-ID: <91ae3c4e72387b1500301aceeaa943c0@u13.net> Hello all, I'll spare you the details, but we are in need of some means to temporarily get a copper interface on at least one of our 4900M switches to narrow down a network performance issue. Does anyone have a 4900M half card with copper ports, or a Cisco TwinGig X2 adapter in the Chicago area? We would love to borrow one or two for a few days until we can locate and resolve this issue. Ryan From furry13 at gmail.com Wed May 15 15:31:30 2013 From: furry13 at gmail.com (Jen Linkova) Date: Thu, 16 May 2013 01:31:30 +1000 Subject: ISIS and OSPF together In-Reply-To: References: Message-ID: On Sun, May 12, 2013 at 6:41 PM, Glen Kent wrote: > I would like to understand the scenarios wherein the service > provider/network admin might run both ISIS and OSPF together inside their > network. Is this something that really happens out there? > > One scenario that i can think of when somebody might run the 2 protocols > ISIS and OSPF together for a brief period is when the admin is migrating > from one IGP to the other. > > The other instance would be when say OSPF is used to manage the OOB network > and the ISIS is used for network reachability. > Is there any other scenario? There is still equipment around which doesn't support ISIS but support OSPF. Getting such boxes into a network which is using ISIS might lead to running both protocols together. -- SY, Jen Linkova aka Furry From jfmezei_nanog at vaxination.ca Wed May 15 15:46:36 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 15 May 2013 11:46:36 -0400 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <084401ce5156$53088e30$f919aa90$@towardex.com> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> <5192E190.2000007@vaxination.ca> <084401ce5156$53088e30$f919aa90$@towardex.com> Message-ID: <5193ADDC.2030401@vaxination.ca> On 13-05-15 06:24, james at towardex.com wrote: > We're a small ISP and we reach lot of content via peering just fine. Lot of > these contents that you speak of (Netflix, Akamai, et al) have open peering > policies and are present in more exchange points than anybody else. Not all ISPs are fortunate enough to be in a town where there is an active exchange with Netflix/Akamai/Google presence. For instance, Montr?al just recently oopened a peering exchange. While this will eventually allow local ISPs to peer with the big content providers, until this happens, small ISPs have to get that content via paid transit links. Toronto has "local" content available via peering so smaller ISPs can benefit from that. But not every city has that chance. Netflix's policy does require a minimum amount of traffic before an ISP can deploy an Open Connect appliance. So smaller ISPs are at a disadvantage if they are located in a city without CDN presence. From morrowc.lists at gmail.com Wed May 15 16:50:07 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 15 May 2013 12:50:07 -0400 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <5193ADDC.2030401@vaxination.ca> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> <5192E190.2000007@vaxination.ca> <084401ce5156$53088e30$f919aa90$@towardex.com> <5193ADDC.2030401@vaxination.ca> Message-ID: On Wed, May 15, 2013 at 11:46 AM, Jean-Francois Mezei wrote: > On 13-05-15 06:24, james at towardex.com wrote: > >> We're a small ISP and we reach lot of content via peering just fine. Lot of >> these contents that you speak of (Netflix, Akamai, et al) have open peering >> policies and are present in more exchange points than anybody else. > > Not all ISPs are fortunate enough to be in a town where there is an > active exchange with Netflix/Akamai/Google presence. > > For instance, Montr?al just recently oopened a peering exchange. While > this will eventually allow local ISPs to peer with the big content > providers, until this happens, small ISPs have to get that content via > paid transit links. or via some cooperative arrangement with another IX participant, no? > Toronto has "local" content available via peering so smaller ISPs can > benefit from that. But not every city has that chance. > > > Netflix's policy does require a minimum amount of traffic before an ISP > can deploy an Open Connect appliance. So smaller ISPs are at a > disadvantage if they are located in a city without CDN presence. > From jfmezei_nanog at vaxination.ca Wed May 15 16:59:50 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 15 May 2013 12:59:50 -0400 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <20130515130256.GA23735@panix.com> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> <5192E190.2000007@vaxination.ca> <20130515130256.GA23735@panix.com> Message-ID: <5193BF06.2090509@vaxination.ca> On 13-05-15 09:02, Brett Frankenberger wrote: > So it's only on the Internet if it uses a provider's transit capacity? I made the statement in a context of "the internet is crumbling under the Netflix load". There have been many media reports over the years of the internet unable to cope with the explosion of traffic. When a content provider delivers content at an ISP's doorstep, it basically bypasses "the internet" (the big cloud). I am fully aware that it is still technically the internet. But the load is not on "the internet" but rathers localised to particular individual networks within the internet. The point here is that the internet (as a whole) has adapted to the likes of Netflix and Youtube who are able to deliver huge amounts of data without "the internet" crumbling. From morrowc.lists at gmail.com Wed May 15 17:12:57 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 15 May 2013 13:12:57 -0400 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <5193BF06.2090509@vaxination.ca> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> <5192E190.2000007@vaxination.ca> <20130515130256.GA23735@panix.com> <5193BF06.2090509@vaxination.ca> Message-ID: On Wed, May 15, 2013 at 12:59 PM, Jean-Francois Mezei wrote: > On 13-05-15 09:02, Brett Frankenberger wrote: > >> So it's only on the Internet if it uses a provider's transit capacity? > > I made the statement in a context of "the internet is crumbling under > the Netflix load". There have been many media reports over the years of is it? it seems ok so far... > the internet unable to cope with the explosion of traffic. 'internet doom, news at 11' ? i don't think there's as much of a problem as news folk want us all to believe. I also bet that as problems arise, folk route around them with better/closer/cheaper peering, no? From Valdis.Kletnieks at vt.edu Wed May 15 17:29:46 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 15 May 2013 13:29:46 -0400 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: Your message of "Wed, 15 May 2013 11:46:36 -0400." <5193ADDC.2030401@vaxination.ca> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> <5192E190.2000007@vaxination.ca> <084401ce5156$53088e30$f919aa90$@towardex.com> <5193ADDC.2030401@vaxination.ca> Message-ID: <12692.1368638986@turing-police.cc.vt.edu> On Wed, 15 May 2013 11:46:36 -0400, Jean-Francois Mezei said: > Not all ISPs are fortunate enough to be in a town where there is an > active exchange with Netflix/Akamai/Google presence. > > For instance, Montr?al just recently oopened a peering exchange. While > this will eventually allow local ISPs to peer with the big content > providers, until this happens, small ISPs have to get that content via > paid transit links. AS1312 isn't particularly large (2 /16s, 30K students, 8K fac/staff), and Akamai was more than willing to drop a cache unit in our machine room. And Google was happy to meet us at the upstream end of our link to the outside world - but I half-suspect that was just because we make their IPv6 stats look good :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From james at towardex.com Wed May 15 17:36:47 2013 From: james at towardex.com (James Jun) Date: Wed, 15 May 2013 13:36:47 -0400 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <5193ADDC.2030401@vaxination.ca> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> <5192E190.2000007@vaxination.ca> <084401ce5156$53088e30$f919aa90$@towardex.com> <5193ADDC.2030401@vaxination.ca> Message-ID: <006f01ce5192$c64c0930$52e41b90$@com> > Not all ISPs are fortunate enough to be in a town where there is an active exchange with Netflix/Akamai/Google presence. > For instance, Montr?al just recently oopened a peering exchange. While this will eventually allow local ISPs to peer with > the big content providers, until this happens, small ISPs have to get that content via paid transit links. lolwut? Montreal isn't a small town, just not developed on peering side. What's the cost of upgrading your IP transit in Montreal or getting a 10G wave to Toronto for peering w/ content nowadays? Not very much. james From scott at sberkman.net Wed May 15 17:50:53 2013 From: scott at sberkman.net (Scott Berkman) Date: Wed, 15 May 2013 13:50:53 -0400 Subject: Looking for Netflow analysis package In-Reply-To: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> Message-ID: <04d801ce5194$c097da30$41c78e90$@sberkman.net> I'd also suggest looking at NetFlow Auditor: http://www.netflowauditor.com/ I think it will do all of those except AS path analysis. Another good option might also be the InterNAP FCP, which does all of that PLUS optimizes routing based on the data (can also be deployed in a preview mode): http://www.internap.com/business-internet-connectivity-services/route-optimi zation-flow-control/ Good luck, -Scott -----Original Message----- From: Erik Sundberg [mailto:ESundberg at nitelusa.com] Sent: Tuesday, May 14, 2013 7:00 PM To: nanog at nanog.org Subject: Looking for Netflow analysis package Does anyone know of a netflow collector that will do the following. *Graph/List Destination Networks By Top AS *Graph/List Destination Networks By Top IP Address *AS Path Analysis *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) We will be using this to help us decide who to Peer with and what transit Providers to look at. I am familiar with Arbor Network's Peak Flow utility but it's a little too pricy. I also found AS-Stats https://neon1.net/as-stats/ look promising from the power point on their page. Thanks Erik ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From owen at delong.com Wed May 15 18:07:25 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 15 May 2013 11:07:25 -0700 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <5193BF06.2090509@vaxination.ca> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> <5192E190.2000007@vaxination.ca> <20130515130256.GA23735@panix.com> <5193BF06.2090509@vaxination.ca> Message-ID: <27214B84-C335-465A-BBE5-4A6A3A5D2A2A@delong.com> On May 15, 2013, at 09:59 , Jean-Francois Mezei wrote: > On 13-05-15 09:02, Brett Frankenberger wrote: > >> So it's only on the Internet if it uses a provider's transit capacity? All of this is leading me to the following conclusion: If we, as network engineers can't agree on the nature and definition of the internet, how can we possibly expect the media to understand it? Owen From jonwolberg at gmail.com Wed May 15 18:39:12 2013 From: jonwolberg at gmail.com (Jon Wolberg) Date: Wed, 15 May 2013 11:39:12 -0700 Subject: Looking for Netflow analysis package In-Reply-To: <04d801ce5194$c097da30$41c78e90$@sberkman.net> References: <495D0934DA46854A9CA758393724D59009DE82@NI-MAIL02.nii.ads> <04d801ce5194$c097da30$41c78e90$@sberkman.net> Message-ID: I can vouch for the FCP. I haven't used their newer platforms but the device worked very well. On Wed, May 15, 2013 at 10:50 AM, Scott Berkman wrote: > I'd also suggest looking at NetFlow Auditor: > > http://www.netflowauditor.com/ > > I think it will do all of those except AS path analysis. > > Another good option might also be the InterNAP FCP, which does all of that > PLUS optimizes routing based on the data (can also be deployed in a preview > mode): > > http://www.internap.com/business-internet-connectivity-services/route-optimi > zation-flow-control/ > > Good luck, > > -Scott > > > -----Original Message----- > From: Erik Sundberg [mailto:ESundberg at nitelusa.com] > Sent: Tuesday, May 14, 2013 7:00 PM > To: nanog at nanog.org > Subject: Looking for Netflow analysis package > > Does anyone know of a netflow collector that will do the following. > *Graph/List Destination Networks By Top AS *Graph/List Destination Networks > By Top IP Address *AS Path Analysis *Traffic Type (ICMP, TCP, UDP, IPSEC, > HTTP, SSH, SMTP, etc..) > > We will be using this to help us decide who to Peer with and what transit > Providers to look at. > > I am familiar with Arbor Network's Peak Flow utility but it's a little too > pricy. > I also found AS-Stats https://neon1.net/as-stats/ look promising from the > power point on their page. > > Thanks > Erik > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > > From jfmezei_nanog at vaxination.ca Wed May 15 18:49:25 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 15 May 2013 14:49:25 -0400 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <27214B84-C335-465A-BBE5-4A6A3A5D2A2A@delong.com> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> <5192E190.2000007@vaxination.ca> <20130515130256.GA23735@panix.com> <5193BF06.2090509@vaxination.ca> <27214B84-C335-465A-BBE5-4A6A3A5D2A2A@delong.com> Message-ID: <5193D8B5.1060306@vaxination.ca> On 13-05-15 14:07, Owen DeLong wrote: > If we, as network engineers can't agree on the nature and definition of the internet, > how can we possibly expect the media to understand it? When someone cuts a cable in the meditarenean, the media doesn't say "the internet has crawled to a snail's pace", it says "internet connections in the middle east are very slow". If DNS servers at Comcast fail, one doesn't say "the internet has suffered a failure". Generally , if one uses the expression "the internet", it would generally mean the generic term which encompasses the whole internet. So you can state "Syria is disconnected from the internet". If root servers went down around the world, then one could state that "the internet has suffered a failure". From Clinton_Popovich at McAfee.com Wed May 15 22:01:32 2013 From: Clinton_Popovich at McAfee.com (Clinton_Popovich at McAfee.com) Date: Wed, 15 May 2013 22:01:32 +0000 Subject: Spamcop Blacklist Message-ID: <5C16FDE8D6362B46A0F7DCE68508B532ADA632@MIVEXAMER1N2.corp.nai.org> Anyone- We are having a bit of trouble with spamcop blocking 2 of our MTAs with IPs of 208.65.145.71 and 208.65.145.66. We have yet to receive any samples of the spam and do not seem to be able to submit for removal as it appears someone has attempted to do this for us and basically used up all our our requests for a period of time. Does anyone have a contact over at spamcop that might be able to assist us in removing these MTAs before this becomes a large issue or us and our customers? Below is the Bounce message we are receiving. Bounce message 554 Service unavailable; Client host [pXXcXXoXXX.mxlogic.net] blocked by bl.spamcop.net Just to let everyone know, we do vigorously monitor outbound spam traffic and take seriously any reports of spam from our network. If someone can get us a sample of what spamcop is see this would also help! Any help is greatly appreciated. Thanks, -- Clinton Popovich Linux Systems Administrator McAfee 9781 S. Meridian Blvd., Suite 400, Englewood, CO 80112 USA From rsk at gsp.org Wed May 15 22:40:57 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 15 May 2013 18:40:57 -0400 Subject: Spamcop Blacklist In-Reply-To: <5C16FDE8D6362B46A0F7DCE68508B532ADA632@MIVEXAMER1N2.corp.nai.org> References: <5C16FDE8D6362B46A0F7DCE68508B532ADA632@MIVEXAMER1N2.corp.nai.org> Message-ID: <20130515224057.GA12144@gsp.org> This is probably much more appropriate over on mailop; please see: http://chilli.nosignal.org/mailman/listinfo/mailop I don't recall offhand is any Spamcop personnel hang out there, but it's plausible to think they might. ---rsk From jaydesh9 at gmail.com Wed May 15 23:06:54 2013 From: jaydesh9 at gmail.com (Jayram Deshpande) Date: Wed, 15 May 2013 16:06:54 -0700 Subject: ISIS and OSPF together In-Reply-To: References: Message-ID: <02121345-330C-48FB-BE28-56A3FB83C4EC@gmail.com> Sent from my iPhone On May 12, 2013, at 1:41 AM, Glen Kent wrote: > > The other instance would be when say OSPF is used to manage the OOB network > and the ISIS is used for network reachability. > > Is there any other scenario? Yes, in virtualization world , where people no more want to waste their links that form loops, there are scenarios where you may have a TRILL deployment that runs over IS-IS while you have OSPF running side by side. -Jay From yang.yu.list at gmail.com Wed May 15 23:43:11 2013 From: yang.yu.list at gmail.com (Yang Yu) Date: Wed, 15 May 2013 19:43:11 -0400 Subject: "Network Engineering" Stack Exchange site in Area51 (fwd) In-Reply-To: References: Message-ID: Now it's public :) > The new Network Engineering Stack Exchange site is now open to the public! > > After just 8 days in private beta, we've already got 451 users who have > asked 99 questions and written 258 answers. We're off to a good start, and > it's time to unleash this baby on the public and see if it flies. (Sorry; > mixed metaphor.) > > Tell all your friends, blog about it, tweet about it, and write the URL > (http://networkengineering.stackexchange.com) in chalk on the sidewalk in > front of your neighbor's house. Or paint. No, never mind, better use chalk. > > Most importantly, go to the site now and start earning reputation and > badges! We'll see you there! Right now! > > http://networkengineering.stackexchange.com <-- that is the URL again > http://networkengineering.stackexchange.com <-- it has not changed in the > last 10 microseconds > > All the best, > > The Stack Exchange Team On Tue, May 7, 2013 at 4:44 PM, Yang Yu wrote: > Network Engineering Q&A site - Area 51 - Stack Exchange just started > private beta. > http://networkengineering.stackexchange.com/ > > If anyone needs a private beta invitation, feel free to email me > offlist. Thanks. > > On Tue, Apr 30, 2013 at 7:40 PM, Simon Lyall wrote: >> >> The proposal currently needs just 13 more committers with 200+ SE points on >> any site... >> >> http://area51.stackexchange.com/proposals/52519/network-engineering >> >> The SE site proposal for 'network engineering' is so close to going into >> Beta. It's up to >> 441 committers, and is currently 7th overall, (of 800+ proposals,) on the >> "hottest proposal list. >> >> -- >> Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ >> "To stay awake all night adds a day to your life" - Stilgar | eMT. >> >> From adam.vitkovsky at swan.sk Thu May 16 07:58:42 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Thu, 16 May 2013 09:58:42 +0200 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <27214B84-C335-465A-BBE5-4A6A3A5D2A2A@delong.com> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> <5192E190.2000007@vaxination.ca> <20130515130256.GA23735@panix.com> <5193BF06.2090509@vaxination.ca> <27214B84-C335-465A-BBE5-4A6A3A5D2A2A@delong.com> Message-ID: <009e01ce520b$2efa5a40$8cef0ec0$@swan.sk> Maybe we should try poetry, Human, you tied the soul, You will not behold joy if you break down that wall, So why the leaving beam is calling you, Brick by brick, slowly one by one, ... hoping to at least catch a glimpse of ray. Translated from: Kingmaker (Life ... in a nest of copper) By: Rikin adam -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, May 15, 2013 8:07 PM To: Jean-Francois Mezei Cc: nanog at nanog.org Subject: Re: Variety, On The Media, don't understand the Internet On May 15, 2013, at 09:59 , Jean-Francois Mezei wrote: > On 13-05-15 09:02, Brett Frankenberger wrote: > >> So it's only on the Internet if it uses a provider's transit capacity? All of this is leading me to the following conclusion: If we, as network engineers can't agree on the nature and definition of the internet, how can we possibly expect the media to understand it? Owen From jamel at cin.ufpe.br Thu May 16 13:16:25 2013 From: jamel at cin.ufpe.br (Djamel Sadok) Date: Thu, 16 May 2013 10:16:25 -0300 Subject: CDN server log In-Reply-To: <2CF5AE4B-C05D-4CA7-8A70-C37ED8E496C4@internap.com> References: <2CF5AE4B-C05D-4CA7-8A70-C37ED8E496C4@internap.com> Message-ID: Hi Pete, I do not use a CDN I am only interested in analyzing content popularity in logs. These could be anonymized. Djamel On Wed, May 15, 2013 at 3:55 PM, Pete Mastin wrote: > Hi djamel. If I understand your question - you should take a look at what > sawmill offers. Many of our clients use this product to analyze our cdn > produced logs. > > http://www.sawmill.net/ > > > > Sent from my iPhone > > On May 15, 2013, at 10:30 AM, "Djamel Sadok" wrote: > > > Hi, > > > > Anyone knows of any public CDN server log trace. I am looking for object > > popularity, hit rate information, ... > > > > Thanks, Djamel > > > > From dave at temk.in Thu May 16 14:37:12 2013 From: dave at temk.in (David Temkin) Date: Thu, 16 May 2013 15:37:12 +0100 Subject: Variety, On The Media, don't understand the Internet In-Reply-To: <5193ADDC.2030401@vaxination.ca> References: <7168021.5530.1368551211969.JavaMail.root@benjamin.baylink.com> <51929626.9030504@vaxination.ca> <5192E190.2000007@vaxination.ca> <084401ce5156$53088e30$f919aa90$@towardex.com> <5193ADDC.2030401@vaxination.ca> Message-ID: On Wed, May 15, 2013 at 4:46 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > > > Netflix's policy does require a minimum amount of traffic before an ISP > can deploy an Open Connect appliance. So smaller ISPs are at a > disadvantage if they are located in a city without CDN presence. > > To be clear - the purpose of this policy is to ensure that people who deploy appliances use them in the best way possible for their network. Anything less than the minimum amount of traffic and the appliance uses more bandwidth to fill than serve and you end up in a race of diminishing returns. We're always happy to try to find the best solution for any network, even those too small for an OCA. For more info see http://openconnect.netflix.com Regards, -Dave From michal at krsek.cz Thu May 16 15:33:47 2013 From: michal at krsek.cz (Michal Krsek) Date: Thu, 16 May 2013 17:33:47 +0200 Subject: CDN server log In-Reply-To: References: <2CF5AE4B-C05D-4CA7-8A70-C37ED8E496C4@internap.com> Message-ID: <5194FC5B.70405@krsek.cz> Hi Djamel, I'm not sure what you are looking for. There is variety of CDN content and popularity is being driven by users and designers. If you have CDN that serves pictures, you get most hits on "design pictures", for paid VoD, you get most hits on free trailers. For CatchTV tup you get most hits on new arrivals of popular content. It also depends on geo distribution. Global CDNs get different coverage than regional ones. For live transmissions, you get a lot of content when covering big sports events. For adult based content CDN ... you can imagine ... Just talking in general, having no permission to provide any log. With kind regards Michal Dne 16.5.2013 15:16, Djamel Sadok napsal(a): > Hi Pete, > > I do not use a CDN I am only interested in analyzing content popularity in > logs. These could be anonymized. > > Djamel > > > > On Wed, May 15, 2013 at 3:55 PM, Pete Mastin wrote: > >> Hi djamel. If I understand your question - you should take a look at what >> sawmill offers. Many of our clients use this product to analyze our cdn >> produced logs. >> >> http://www.sawmill.net/ >> >> >> >> Sent from my iPhone >> >> On May 15, 2013, at 10:30 AM, "Djamel Sadok" wrote: >> >>> Hi, >>> >>> Anyone knows of any public CDN server log trace. I am looking for object >>> popularity, hit rate information, ... >>> >>> Thanks, Djamel >>> >> From florian.hibler at kaiaglobal.com Thu May 16 10:33:07 2013 From: florian.hibler at kaiaglobal.com (Hibler, Florian) Date: Thu, 16 May 2013 12:33:07 +0200 Subject: Call for papers / DENOG5 Message-ID: <5194B5E3.50705@kaiaglobal.com> Dear NANOG list, I just checked with grizz, before posting this request here. ****** DENOG 5 - Call for Participation and Papers The fifth meeting of the German Network Operators Group (DENOG) will be held in Darmstadt, Germany on the 14th of November 2013. We are pleased to hereby invite applications for presentations or lightning talks to be held at this event. General Information =================== DENOG is a community for professionals within Germany who are operating, designing or researching the Internet. It provides a technical forum where those working on, with and for the Internet can come together to solve problems with every aspect of their (net)work. The meeting is designed to provide an opportunity for the exchange of information among network operators, engineers, researchers and other professionals close to the network community. More information about DENOG (in German) can be found at http://www.denog.de/ Information about the meeting will be published at http://www.denog.de/meetings/ Meeting Countdown ================= What When ------------------------------------------------------ Publication of Call for Papers April 18th, 2013 Deadline for all submissions June 19th, 2013 Publication of final program August 16th, 2013 Deadline for receipt of final present. November 8th, 2013 Meeting Day November 14th, 2013 Topics for Presentations/Talks ============================== The day will be divided into several sessions. The number and length of presentations per session is not fixed, although due to time constraints we would prefer the length of the presentations to be between 15 to 30 minutes. However proposals whose subject fall outside of the topics below are also welcome; please do not hesitate to submit them. Topic #1: Virtual network infrastructure --------------------------------------------------- "Clouds" are everywhere. Virtualization is the way to consolidate servers and lower the cost as well as the administrative overhead. But what about virtualizing network infrastructure like routers, firewalls, etc.? We see certain approaches of these technologies on the market now. Which company would be the right target? How does it scale? Topic #2: Issues affecting the global internet infrastructure ------------------------------------------------------------- Cyber attacks, software bugs, route-hijacking incidents and denial of service attacks are common in todays internet, not only affecting single companies, carriers or enterprises but sometimes even entire countries. One of the examples was Cloudflare in March 2013. What was really affected? Was it "a global issue"? In this light securing the global internet infrastructure is a major topic amongst entities relying on the internet. Topic #3: Peering ------------------ Everything about your peering experience. Why are you doing it? How are you doing it? Have you written any useful tools which others might find interesting? What are the issues you are facing? Topic #4: Network & resource planning --------------------------- Around the world we see large companies consuming lots of bandwidth for new media services like YouTube, Netflix, Akamai etc. Forecasting and planning of capactiy is an essential part of quality assurance to keep your users/subscribers happy. What are the best techniques to evaluate traffic levels to certain providers? How to manage the flow of traffic in the best way under the aspect of commerical and engineering views? Topic #5: ISP BOF ----------------- "All things ISP". From Network/SLA Management (for or against it), abuse handling and log systems to data centre layout and planning (including power and cooling), everything that is interesting to you as an ISP can be presented or discussed within this topic. Lightning Talks --------------- In addition to the topics mentioned below we will reserve slots for lightning talks, which consist of a few slides and will not last longer than 5 minutes. Lightning talks can be submitted until November 8th, with the deadline for submission of the corresponding slides being November 13th. Language of Slides and Talks ============================ To appeal to an international audience we ask you to produce your slides in English, but the spoken language of the presentation itself can be either German or English. Submission Guidelines ===================== All submissions must have a strong technical bias and must not be solely promotional for your employer. Please remember that your presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes may vary considerably. To submit a proposal for a presentation, we request you to register at http://pc.denog.de/denog5/cfp If you have further questions, you can reach the program committee at denog-pc at denog.de. We also welcome suggestions for specific presentations which you feel would be valuable to the DENOG community. Please be aware that your presentation and a video of it will be published on the DENOG website after the event. For the DENOG programme committee, Florian Hibler From leavingin13 at yahoo.com Thu May 16 14:51:10 2013 From: leavingin13 at yahoo.com (Laura Smith) Date: Thu, 16 May 2013 07:51:10 -0700 (PDT) Subject: Looking for Netflow analysis package Message-ID: <1368715870.5058.YahooMailNeo@web164506.mail.gq1.yahoo.com> Hello Erik, Scrutinizer from?http://www.plixer.com/?supports all of those features you listed and scales to over 100K flows/second. http://www.plixer.com/Scrutinizer-Netflow-Sflow/scrutinizer.html Good luck with your search. ------------------------------------------------------------------------------------------------------ Does anyone know of a netflow collector that will do the following.? *Graph/List Destination Networks By Top AS? *Graph/List Destination Networks By Top IP Address? *AS Path Analysis? *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..)? We will be using this to help us decide who to Peer with and what transit Providers to look at.? I am familiar with Arbor Network's Peak Flow utility but it's a little too pricy.? I also found AS-Stats?https://neon1.net/as-stats/?look promising from the power point on their page.? Thanks? Erik? From bmeshier at amherst.com Thu May 16 18:29:15 2013 From: bmeshier at amherst.com (Meshier, Brent) Date: Thu, 16 May 2013 18:29:15 +0000 Subject: Looking for Netflow analysis package In-Reply-To: <1368715870.5058.YahooMailNeo@web164506.mail.gq1.yahoo.com> References: <1368715870.5058.YahooMailNeo@web164506.mail.gq1.yahoo.com> Message-ID: <68C2CBC977F3E04799DF9C76E938E709101D3D@DFEXCH1.asglp.com> Laura, Do not appreciate the cold call from Plixer. Please do not use the NANOG mailing list as your personal directory for sales leads. It's a sure fire way to get your company blacklisted among IT professionals. --Brent -----Original Message----- From: Laura Smith [mailto:leavingin13 at yahoo.com] Sent: Thursday, May 16, 2013 9:51 AM To: nanog at nanog.org Subject: Looking for Netflow analysis package Hello Erik, Scrutinizer from http://www.plixer.com/ supports all of those features you listed and scales to over 100K flows/second. http://www.plixer.com/Scrutinizer-Netflow-Sflow/scrutinizer.html Good luck with your search. ------------------------------------------------------------------------------------------------------ Does anyone know of a netflow collector that will do the following. *Graph/List Destination Networks By Top AS *Graph/List Destination Networks By Top IP Address *AS Path Analysis *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) We will be using this to help us decide who to Peer with and what transit Providers to look at. I am familiar with Arbor Network's Peak Flow utility but it's a little too pricy. I also found AS-Stats https://neon1.net/as-stats/ look promising from the power point on their page. Thanks Erik **************************************************************************************************************************************************************************************** The material contained herein is for informational purposes only and is not intended as an offer or solicitation with respect to the purchase or sale of securities. The decision of whether to adopt any strategy or to engage in any transaction and the decision of whether any strategy or transaction fits into an appropriate portfolio structure remains the responsibility of the customer and/or its advisors. Past performance on the underlying securities is no guarantee of future results. This material is intended for use by institutional clients only and not for use by the general public. Portions of this material may incorporate information provided by third party market data sources. Although this information has been obtained from and based upon sources believed to be reliable, neither Amherst Holdings, LLC nor any of its affiliates guarantee the accuracy or completeness of the information contained herein, and cannot be held responsible for inaccuracies in such third party data or the data supplied to the third party by issuers or guarantors. This report constitutes Amherst?s views as of the date of the report and is subject to change without notice. This information does not purport to be a complete analysis of any security, company or industry, including but not limited to any claim as to the prepayment consistency and/or the future performance of any securities or structures. To the extent applicable, change in prepayment rates and/or payments may significantly affect yield, price, total return and average life. Our affiliate, Amherst Securities Group, L.P., may have a position in securities discussed in this material. From tcannon at beatsmusic.com Thu May 16 18:47:14 2013 From: tcannon at beatsmusic.com (Thomas Cannon) Date: Thu, 16 May 2013 11:47:14 -0700 Subject: Looking for Netflow analysis package In-Reply-To: <68C2CBC977F3E04799DF9C76E938E709101D3D@DFEXCH1.asglp.com> References: <1368715870.5058.YahooMailNeo@web164506.mail.gq1.yahoo.com> <68C2CBC977F3E04799DF9C76E938E709101D3D@DFEXCH1.asglp.com> Message-ID: <370EFCAC-3D75-4C26-935F-89A2FD6E3DEE@beatsmusic.com> That wasn't in your signature's disclaimer. Perhaps now would be a good time to add it? Geez. --tc On May 16, 2013, at 11:29 AM, "Meshier, Brent" wrote: > Laura, > > Do not appreciate the cold call from Plixer. Please do not use the NANOG mailing list as your personal directory for sales leads. It's a sure fire way to get your company blacklisted among IT professionals. > > --Brent > > -----Original Message----- > From: Laura Smith [mailto:leavingin13 at yahoo.com] > Sent: Thursday, May 16, 2013 9:51 AM > To: nanog at nanog.org > Subject: Looking for Netflow analysis package > > Hello Erik, > > > Scrutinizer from http://www.plixer.com/ supports all of those features you listed and scales to over 100K flows/second. > http://www.plixer.com/Scrutinizer-Netflow-Sflow/scrutinizer.html > > > Good luck with your search. > > > ------------------------------------------------------------------------------------------------------ > > Does anyone know of a netflow collector that will do the following. *Graph/List Destination Networks By Top AS *Graph/List Destination Networks By Top IP Address *AS Path Analysis *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) > > We will be using this to help us decide who to Peer with and what transit Providers to look at. > > I am familiar with Arbor Network's Peak Flow utility but it's a little too pricy. I also found AS-Stats https://neon1.net/as-stats/ look promising from the power point on their page. > > Thanks > Erik > > > **************************************************************************************************************************************************************************************** The material contained herein is for informational purposes only and is not intended as an offer or solicitation with respect to the purchase or sale of securities. The decision of whether to adopt any strategy or to engage in any transaction and the decision of whether any strategy or transaction fits into an appropriate portfolio structure remains the responsibility of the customer and/or its advisors. Past performance on the underlying securities is no guarantee of future results. This material is intended for use by institutional clients only and not for use by the general public. Portions of this material may incorporate information provided by third party market data sources. Although this information has been obtained from and based upon sources believed to be reliable, neither Amherst Holdings, LLC nor any of its affiliates guarantee the accuracy or completeness of the information contained herein, and cannot be held responsible for inaccuracies in such third party data or the data supplied to the third party by issuers or guarantors. This report constitutes Amherst?s views as of the date of the report and is subject to change without notice. This information does not purport to be a complete analysis of any security, company or industry, including but not limited to any claim as to the prepayment consistency and/or the future performance of any securities or structures. To the extent applicable, change in prepayment rates and/or payments may significantly affect yield, price, total return and average life. Our affiliate, Amherst Securities Group, L.P., may have a position in securities discussed in this material. From surfer at mauigateway.com Thu May 16 22:16:22 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 16 May 2013 15:16:22 -0700 Subject: Looking for Netflow analysis package Message-ID: <20130516151622.A0F49051@resin04.mta.everyone.net> > Does anyone know of a netflow collector that will do the following. -------------------------------------------- -------------Original Message------------- > From: Laura Smith [mailto:leavingin13 at yahoo.com] ------------------------------------------ -------------"Meshier, Brent" wrote: ------------ > Do not appreciate the cold call from Plixer. Please do not use the > NANOG mailing list as your personal directory for sales leads. It's a > sure fire way to get your company blacklisted among IT professionals. ------------------------------------------------- -------- tcannon at beatsmusic.com wrote: ---------- From: Thomas Cannon That wasn't in your signature's disclaimer. Perhaps now would be a good time to add it? ------------------------------------------------ You haven't been here long have you... He DOES NOT need a 260 word signature (see below!) to make sure he does not get UCE from posting to NANOG. For any other sales folks out there considering doing this, Brent's warning is a good one: "It's a sure fire way to get your company blacklisted among IT professionals." scott ps. WTF is this?!? **************************************************************************************************************************************************************************************** The material contained herein is for informational purposes only and is not intended as an offer or solicitation with respect to the purchase or sale of securities. The decision of whether to adopt any strategy or to engage in any transaction and the decision of whether any strategy or transaction fits into an appropriate portfolio structure remains the responsibility of the customer and/or its advisors. Past performance on the underlying securities is no guarantee of future results. This material is intended for use by institutional clients only and not for use by the general public. Portions of this material may incorporate information provided by third party market data sources. Although this information has been obtained from and based upon sources believed to be reliable, neither Amherst Holdings, LLC nor any of its affiliates guarantee the accuracy or completeness of the information contained herein, and cannot be held responsible for inaccuracies in such third party data or the data supplied to the third party by issuers or guarantors. This report constitutes Amherst?s views as of the date of the report and is subject to change without notice. This information does not purport to be a complete analysis of any security, company or industry, including but not limited to any claim as to the prepayment consistency and/or the future performance of any securities or structures. To the extent applicable, change in prepayment rates and/or payments may significantly affect yield, price, total return and average life. Our affiliate, Amherst Securities Group, L.P., may have a position in securities discussed in this material. From patrick at ianai.net Thu May 16 22:21:57 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 16 May 2013 18:21:57 -0400 Subject: whoami.akamai.net Message-ID: <0899470B-3856-4B00-8B5C-E8EA8BBFFF5C@ianai.net> As the whoami.akamai.net hostname came up on the list, I thought I'd mention it here. The hostname 'whoami.akamai.com' is a CNAME for whoami.akamai.net. That CNAME is, frankly, a mistake. It will be removed "soon". If you are using the .com name, please move to the .net name. -- TTFN, patrick -------------- 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 tstpierre at iweb.com Fri May 17 03:56:58 2013 From: tstpierre at iweb.com (Thomas St-Pierre) Date: Fri, 17 May 2013 03:56:58 +0000 Subject: BGP instability? Message-ID: Hi, Did anyone else see a large amount of instability between around 12:20am and 3:10am? (UTC, May 17th) We saw around 9 million announces per hour during that period come in through all our upstreams (vs an average normal of around 128k per hour). Just curious as to what happened, if anything. Thanks, Thomas From tim at interworx.nl Fri May 17 10:11:57 2013 From: tim at interworx.nl (Tim Vollebregt) Date: Fri, 17 May 2013 12:11:57 +0200 Subject: Looking for Netflow analysis package In-Reply-To: <20130516151622.A0F49051@resin04.mta.everyone.net> References: <20130516151622.A0F49051@resin04.mta.everyone.net> Message-ID: <076E4598-1ADD-4E2D-9A17-47E48D2F720C@interworx.nl> Is anyone using an open source solution to process netflow v9 captures? I'm waiting for SiLK v3 for some time now, which is currently only available for TLA's and Universities. Currently looking into nfdump. Tim On May 17, 2013, at 12:16 AM, Scott Weeks wrote: > >> Does anyone know of a netflow collector that will do the following. > > -------------------------------------------- > > -------------Original Message------------- >> From: Laura Smith [mailto:leavingin13 at yahoo.com] > > ------------------------------------------ > > -------------"Meshier, Brent" wrote: ------------ >> Do not appreciate the cold call from Plixer. Please do not use the >> NANOG mailing list as your personal directory for sales leads. It's a >> sure fire way to get your company blacklisted among IT professionals. > ------------------------------------------------- > > > -------- tcannon at beatsmusic.com wrote: ---------- > From: Thomas Cannon > > That wasn't in your signature's disclaimer. Perhaps now would be a good > time to add it? > ------------------------------------------------ > > You haven't been here long have you... > > He DOES NOT need a 260 word signature (see below!) to make sure he does > not get UCE from posting to NANOG. For any other sales folks out there > considering doing this, Brent's warning is a good one: "It's a sure fire > way to get your company blacklisted among IT professionals." > > scott > > > ps. WTF is this?!? > **************************************************************************************************************************************************************************************** The material contained herein is for informational purposes only and is not intended as an offer or solicitation with respect to the purchase or sale of securities. The decision of whether to adopt any strategy or to engage in any transaction and the decision of whether any strategy or transaction fits into an appropriate portfolio structure remains the responsibility of the customer and/or its advisors. Past performance on the underlying securities is no guarantee of future results. This material is intended for use by institutional clients only and not for use by the general public. Portions of this material may incorporate information provided by third party market data sources. Although this information has been obtained from and based upon sources believed to be reliable, neither Amherst Holdings, LLC nor any of its affiliates guarantee the accuracy or completeness of the information contained herein, and cannot be held responsible for inaccuracies in such third party data or the data supplied to the third party by issuers or guarantors. This report constitutes Amherst?s views as of the date of the report and is subject to change without notice. This information does not purport to be a complete analysis of any security, company or industry, including but not limited to any claim as to the prepayment consistency and/or the future performance of any securities or structures. To the extent applicable, change in prepayment rates and/or payments may significantly affect yield, price, total return and average life. Our affiliate, Amherst Securities Group, L.P., may have a position in securities discussed in this material. > > > > From eugen at leitl.org Fri May 17 10:15:38 2013 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 17 May 2013 12:15:38 +0200 Subject: 40 GBit @ 240 GHz across 1 km LoS Message-ID: <20130517101537.GU26408@leitl.org> Fraunhofer: http://www.iaf.fraunhofer.de/de/news-medien/pressemitteilungen/presse-2013-05-16.html Google Translate: New world record in data transmission by radio Press Release 16/05/2013 With a Langstreckendemonstrator between two skyscrapers in Karlsruhe, a distance of over a kilometer could already be bridged. ? KIT The RF chip is only 4 x 1.5 mm2 large, since electronic components with the frequency or wavelength scale. ? Fraunhofer IAF Researchers at the Fraunhofer Institute for Applied Solid State Physics IAF and the Karlsruhe Institute of Technology KIT, it is able to transmit 40 Gb / s at 240 GHz and over a distance of one kilometer by radio. With its recent demonstration they have achieved a new world record and establish for the first time seamlessly with the capacity of fiber to. Such future radio links could close gaps in the provision of broadband Internet by the wireless links complement the network of hard to reach areas or in rural areas. Digital, mobile and networked - the changing media usage behavior and require progressively increasing faster data transfer rates. The expansion of the fiber network in Germany is lagging behind European standards, such as the statistics of the industry organization FTTH Council Europe show. To lay fiber optic lines is expensive and in the case of natural or urban obstacles such as rivers and transport hubs difficult. Broadband radio links can help to overcome such critical points and so promote the expansion of network infrastructures. In rural areas, they provide a cost effective and flexible alternative to "Fibre To The Home 'in the expansion of broadband network dar. In the data transmission by radio researchers have set a new world record for the first time fully integrated electronic transmitter and receiver are designed for a frequency of 240 GHz, with which the data transfer rates up to 40 Gbit s is / possible. This corresponds to the transfer of a full DVD in less than a second or 2400 DSL16000 Internet connections. With a Langstreckendemonstrator a distance of over a kilometer could already be covered, which was built by the Karlsruhe Institute of Technology between two skyscrapers in the "Milli Link" project. "We have managed to develop a wireless link based on active electronic circuits similar to high data rates, such as fiber optic systems, and thus a seamless integration of the radio link allows" said Professor Ingmar Kallfass, the project initially at Fraunhofer IAF in looking a shared professorship - supported by IAF and KIT - coordinated. Kallfass since 2013 has been working at the University of Stuttgart, where he continued to lead the project. High frequencies allow fast data transfer The use of the high frequency range between 200 and 280 GHz not only enables the fast transfer of large amounts of data, but also a very compact technical structure. Since the dimensions of electronic circuits and antennas scalable with frequency or wavelength of the transmitter and receiver chip is 4 x 1.5 mm 2 in size. Developed at Fraunhofer IAF semiconductor technology based on transistors with high electron mobility transistor (HEMT) makes it possible to use the frequency range between 200 and 280 GHz with active transmitters and receivers in the form of compact, integrated circuits. In this frequency range, the atmosphere has low attenuation values, so that broadband radio links are possible. "This is our spark gap compared to optical data transmission systems easier to align and work in bad weather conditions such as fog or rain," explains Jochen antes from the KIT. So far, radio systems were not yet able to provide the bandwidth of an optical fiber directly. That could change in the future, as the test shows construction of the project. Such a powerful system possess the advantage of the so-called bit transparency, ie, the signal could be fed directly to a fiber without energy-intensive recoding in a radio link, transmit and re-routed at the other end with a glass fiber. The record data from the test set are just the beginning. "With an improvement in spectral efficiency through the use of complex modulation formats or combination of channels, ie multiplexing, we can achieve even higher data rates, 'said Antes is safe. This could be the expansion of broadband network a boost. Maybe Germany will in future no longer lies in Europe compared to the rear seats. About the project The project "Milli Link" is supported by the German Federal Ministry of Education and Research within the funding program "broadband access next generation networks" with a total of two million euros. Besides the two research institutes Fraunhofer IAF and KIT industry partner Siemens AG, Kathrein KG and Radiometer Physics GmbH are involved in the project. The aim of the project is the integration of wireless links or radio links in broadband optical communication networks in order to provide particular to rural areas with fast Internet access. Other possible applications include indoor wireless local area networks (WLAN), wireless personal area networks (WPAN), and intra-machine and board-to-board communication. Milli link Langstreckendemonstrator (print quality) [1.6095294952392578 MB JPG] Milli link radio frequency chip (print quality) [1.7061738967895508 MB JPG] From philfagan at gmail.com Fri May 17 11:32:11 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 17 May 2013 05:32:11 -0600 Subject: 40 GBit @ 240 GHz across 1 km LoS In-Reply-To: <20130517101537.GU26408@leitl.org> References: <20130517101537.GU26408@leitl.org> Message-ID: Congrats! How does 240Ghz react to atmospheric conditions other than "clear skys?" On May 17, 2013 4:17 AM, "Eugen Leitl" wrote: > > Fraunhofer: > > http://www.iaf.fraunhofer.de/de/news-medien/pressemitteilungen/presse-2013-05-16.html > > Google Translate: > > New world record in data transmission by radio > > Press Release 16/05/2013 > > With a Langstreckendemonstrator between two skyscrapers in Karlsruhe, a > distance of over a kilometer could already be bridged. ? KIT > > The RF chip is only 4 x 1.5 mm2 large, since electronic components with the > frequency or wavelength scale. > > ? Fraunhofer IAF > > Researchers at the Fraunhofer Institute for Applied Solid State Physics IAF > and the Karlsruhe Institute of Technology KIT, it is able to transmit 40 > Gb / > s at 240 GHz and over a distance of one kilometer by radio. With its recent > demonstration they have achieved a new world record and establish for the > first time seamlessly with the capacity of fiber to. Such future radio > links > could close gaps in the provision of broadband Internet by the wireless > links > complement the network of hard to reach areas or in rural areas. > > Digital, mobile and networked - the changing media usage behavior and > require > progressively increasing faster data transfer rates. The expansion of the > fiber network in Germany is lagging behind European standards, such as the > statistics of the industry organization FTTH Council Europe show. To lay > fiber optic lines is expensive and in the case of natural or urban > obstacles > such as rivers and transport hubs difficult. Broadband radio links can help > to overcome such critical points and so promote the expansion of network > infrastructures. In rural areas, they provide a cost effective and flexible > alternative to "Fibre To The Home 'in the expansion of broadband network > dar. > > In the data transmission by radio researchers have set a new world record > for > the first time fully integrated electronic transmitter and receiver are > designed for a frequency of 240 GHz, with which the data transfer rates up > to > 40 Gbit s is / possible. This corresponds to the transfer of a full DVD in > less than a second or 2400 DSL16000 Internet connections. With a > Langstreckendemonstrator a distance of over a kilometer could already be > covered, which was built by the Karlsruhe Institute of Technology between > two > skyscrapers in the "Milli Link" project. "We have managed to develop a > wireless link based on active electronic circuits similar to high data > rates, > such as fiber optic systems, and thus a seamless integration of the radio > link allows" said Professor Ingmar Kallfass, the project initially at > Fraunhofer IAF in looking a shared professorship - supported by IAF and > KIT - > coordinated. Kallfass since 2013 has been working at the University of > Stuttgart, where he continued to lead the project. > > High frequencies allow fast data transfer > > The use of the high frequency range between 200 and 280 GHz not only > enables > the fast transfer of large amounts of data, but also a very compact > technical > structure. Since the dimensions of electronic circuits and antennas > scalable > with frequency or wavelength of the transmitter and receiver chip is 4 x > 1.5 > mm 2 in size. Developed at Fraunhofer IAF semiconductor technology based on > transistors with high electron mobility transistor (HEMT) makes it possible > to use the frequency range between 200 and 280 GHz with active transmitters > and receivers in the form of compact, integrated circuits. In this > frequency > range, the atmosphere has low attenuation values, so that broadband radio > links are possible. "This is our spark gap compared to optical data > transmission systems easier to align and work in bad weather conditions > such > as fog or rain," explains Jochen antes from the KIT. > > So far, radio systems were not yet able to provide the bandwidth of an > optical fiber directly. That could change in the future, as the test shows > construction of the project. Such a powerful system possess the advantage > of > the so-called bit transparency, ie, the signal could be fed directly to a > fiber without energy-intensive recoding in a radio link, transmit and > re-routed at the other end with a glass fiber. The record data from the > test > set are just the beginning. "With an improvement in spectral efficiency > through the use of complex modulation formats or combination of channels, > ie > multiplexing, we can achieve even higher data rates, 'said Antes is safe. > This could be the expansion of broadband network a boost. Maybe Germany > will > in future no longer lies in Europe compared to the rear seats. > > About the project > > The project "Milli Link" is supported by the German Federal Ministry of > Education and Research within the funding program "broadband access next > generation networks" with a total of two million euros. Besides the two > research institutes Fraunhofer IAF and KIT industry partner Siemens AG, > Kathrein KG and Radiometer Physics GmbH are involved in the project. The > aim > of the project is the integration of wireless links or radio links in > broadband optical communication networks in order to provide particular to > rural areas with fast Internet access. Other possible applications include > indoor wireless local area networks (WLAN), wireless personal area networks > (WPAN), and intra-machine and board-to-board communication. > > Milli link Langstreckendemonstrator (print quality) [1.6095294952392578 MB > JPG] Milli link radio frequency chip (print quality) [1.7061738967895508 MB > JPG] > > From david at mailplus.nl Fri May 17 11:51:18 2013 From: david at mailplus.nl (MailPlus| David Hofstee) Date: Fri, 17 May 2013 13:51:18 +0200 Subject: 40 GBit @ 240 GHz across 1 km LoS In-Reply-To: References: <20130517101537.GU26408@leitl.org> Message-ID: <78C35D6C1A82D243B830523B4193CF5F5EAA6E7FF2@SBS1.blinker.local> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=1139451&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1139451 -----Oorspronkelijk bericht----- Van: Phil Fagan [mailto:philfagan at gmail.com] Verzonden: vrijdag 17 mei 2013 13:32 Aan: Eugen Leitl CC: NANOG Onderwerp: Re: 40 GBit @ 240 GHz across 1 km LoS Congrats! How does 240Ghz react to atmospheric conditions other than "clear skys?" On May 17, 2013 4:17 AM, "Eugen Leitl" wrote: > > Fraunhofer: > > http://www.iaf.fraunhofer.de/de/news-medien/pressemitteilungen/presse- > 2013-05-16.html > > Google Translate: > > New world record in data transmission by radio > > Press Release 16/05/2013 > > With a Langstreckendemonstrator between two skyscrapers in Karlsruhe, > a distance of over a kilometer could already be bridged. ? KIT > > The RF chip is only 4 x 1.5 mm2 large, since electronic components > with the frequency or wavelength scale. > > ? Fraunhofer IAF > > Researchers at the Fraunhofer Institute for Applied Solid State > Physics IAF and the Karlsruhe Institute of Technology KIT, it is able > to transmit 40 Gb / s at 240 GHz and over a distance of one kilometer > by radio. With its recent demonstration they have achieved a new world > record and establish for the first time seamlessly with the capacity > of fiber to. Such future radio links could close gaps in the provision > of broadband Internet by the wireless links complement the network of > hard to reach areas or in rural areas. > > Digital, mobile and networked - the changing media usage behavior and > require progressively increasing faster data transfer rates. The > expansion of the fiber network in Germany is lagging behind European > standards, such as the statistics of the industry organization FTTH > Council Europe show. To lay fiber optic lines is expensive and in the > case of natural or urban obstacles such as rivers and transport hubs > difficult. Broadband radio links can help to overcome such critical > points and so promote the expansion of network infrastructures. In > rural areas, they provide a cost effective and flexible alternative to > "Fibre To The Home 'in the expansion of broadband network dar. > > In the data transmission by radio researchers have set a new world > record for the first time fully integrated electronic transmitter and > receiver are designed for a frequency of 240 GHz, with which the data > transfer rates up to > 40 Gbit s is / possible. This corresponds to the transfer of a full > DVD in less than a second or 2400 DSL16000 Internet connections. With > a Langstreckendemonstrator a distance of over a kilometer could > already be covered, which was built by the Karlsruhe Institute of > Technology between two skyscrapers in the "Milli Link" project. "We > have managed to develop a wireless link based on active electronic > circuits similar to high data rates, such as fiber optic systems, and > thus a seamless integration of the radio link allows" said Professor > Ingmar Kallfass, the project initially at Fraunhofer IAF in looking a > shared professorship - supported by IAF and KIT - coordinated. > Kallfass since 2013 has been working at the University of Stuttgart, > where he continued to lead the project. > > High frequencies allow fast data transfer > > The use of the high frequency range between 200 and 280 GHz not only > enables the fast transfer of large amounts of data, but also a very > compact technical structure. Since the dimensions of electronic > circuits and antennas scalable with frequency or wavelength of the > transmitter and receiver chip is 4 x > 1.5 > mm 2 in size. Developed at Fraunhofer IAF semiconductor technology > based on transistors with high electron mobility transistor (HEMT) > makes it possible to use the frequency range between 200 and 280 GHz > with active transmitters and receivers in the form of compact, > integrated circuits. In this frequency range, the atmosphere has low > attenuation values, so that broadband radio links are possible. "This > is our spark gap compared to optical data transmission systems easier > to align and work in bad weather conditions such as fog or rain," > explains Jochen antes from the KIT. > > So far, radio systems were not yet able to provide the bandwidth of an > optical fiber directly. That could change in the future, as the test > shows construction of the project. Such a powerful system possess the > advantage of the so-called bit transparency, ie, the signal could be > fed directly to a fiber without energy-intensive recoding in a radio > link, transmit and re-routed at the other end with a glass fiber. The > record data from the test set are just the beginning. "With an > improvement in spectral efficiency through the use of complex > modulation formats or combination of channels, ie multiplexing, we can > achieve even higher data rates, 'said Antes is safe. > This could be the expansion of broadband network a boost. Maybe > Germany will in future no longer lies in Europe compared to the rear > seats. > > About the project > > The project "Milli Link" is supported by the German Federal Ministry > of Education and Research within the funding program "broadband access > next generation networks" with a total of two million euros. Besides > the two research institutes Fraunhofer IAF and KIT industry partner > Siemens AG, Kathrein KG and Radiometer Physics GmbH are involved in > the project. The aim of the project is the integration of wireless > links or radio links in broadband optical communication networks in > order to provide particular to rural areas with fast Internet access. > Other possible applications include indoor wireless local area > networks (WLAN), wireless personal area networks (WPAN), and > intra-machine and board-to-board communication. > > Milli link Langstreckendemonstrator (print quality) > [1.6095294952392578 MB JPG] Milli link radio frequency chip (print > quality) [1.7061738967895508 MB JPG] > > From froztbyte at froztbyte.net Fri May 17 13:08:50 2013 From: froztbyte at froztbyte.net (JP) Date: Fri, 17 May 2013 15:08:50 +0200 Subject: Looking for Netflow analysis package In-Reply-To: <076E4598-1ADD-4E2D-9A17-47E48D2F720C@interworx.nl> References: <20130516151622.A0F49051@resin04.mta.everyone.net> <076E4598-1ADD-4E2D-9A17-47E48D2F720C@interworx.nl> Message-ID: <20130517130850.GD25880@elegua.za.net> On Fri, May 17, 2013 at 12:11:57PM +0200, Tim Vollebregt wrote: > Is anyone using an open source solution to process netflow v9 captures? > I'm waiting for SiLK v3 for some time now, which is currently only available for TLA's and Universities. pmacct does this pretty nicely (along with a couple other things) -J From hhoffman at ip-solutions.net Fri May 17 13:25:57 2013 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Fri, 17 May 2013 09:25:57 -0400 Subject: Looking for Netflow analysis package In-Reply-To: <076E4598-1ADD-4E2D-9A17-47E48D2F720C@interworx.nl> References: <20130516151622.A0F49051@resin04.mta.everyone.net> <076E4598-1ADD-4E2D-9A17-47E48D2F720C@interworx.nl> Message-ID: <51962FE5.1020108@ip-solutions.net> Check out argus http://www.qosient.com/argus/ Netflow v9 support was added within the last few months. Cheers, Harry On 05/17/2013 06:11 AM, Tim Vollebregt wrote: > Is anyone using an open source solution to process netflow v9 captures? > I'm waiting for SiLK v3 for some time now, which is currently only available for TLA's and Universities. > > Currently looking into nfdump. > > Tim > On May 17, 2013, at 12:16 AM, Scott Weeks wrote: > >> >>> Does anyone know of a netflow collector that will do the following. >> >> -------------------------------------------- >> >> -------------Original Message------------- >>> From: Laura Smith [mailto:leavingin13 at yahoo.com] >> >> ------------------------------------------ >> >> -------------"Meshier, Brent" wrote: ------------ >>> Do not appreciate the cold call from Plixer. Please do not use the >>> NANOG mailing list as your personal directory for sales leads. It's a >>> sure fire way to get your company blacklisted among IT professionals. >> ------------------------------------------------- >> >> >> -------- tcannon at beatsmusic.com wrote: ---------- >> From: Thomas Cannon >> >> That wasn't in your signature's disclaimer. Perhaps now would be a good >> time to add it? >> ------------------------------------------------ >> >> You haven't been here long have you... >> >> He DOES NOT need a 260 word signature (see below!) to make sure he does >> not get UCE from posting to NANOG. For any other sales folks out there >> considering doing this, Brent's warning is a good one: "It's a sure fire >> way to get your company blacklisted among IT professionals." >> >> scott >> >> >> ps. WTF is this?!? >> **************************************************************************************************************************************************************************************** The material contained herein is for informational purposes only and is not intended as an offer or solicitation with respect to the purchase or sale of securities. The decision of whether to adopt any strategy or to engage in any transaction and the decision of whether any strategy or transaction fits into an appropriate portfolio structure remains the responsibility of the customer and/or its advisors. Past performance on the underlying securities is no guarantee of future results. This material is intended for use by institutional clients only and not for use by the general public. Portions of this material may incorporate information provided by third party market data sources. Although this information has been obtained from and based upon sources believed to be reliable, neither Amherst Holding s, LLC nor any of its affiliates guarantee the accuracy or completeness of the information contained herein, and cannot be held responsible for inaccuracies in such third party data or the data supplied to the third party by issuers or guarantors. This report constitutes Amherst?s views as of the date of the report and is subject to change without notice. This information does not purport to be a complete analysis of any security, company or industry, including but not limited to any claim as to the prepayment consistency and/or the future performance of any securities or structures. To the extent applicable, change in prepayment rates and/or payments may significantly affect yield, price, total return and average life. Our affiliate, Amherst Securities Group, L.P., may have a position in securities discussed in this material. >> >> >> >> > > From wbailey at satelliteintelligencegroup.com Fri May 17 14:30:22 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 17 May 2013 14:30:22 +0000 Subject: 40 GBit @ 240 GHz across 1 km LoS In-Reply-To: References: <20130517101537.GU26408@leitl.org>, Message-ID: By not working. At those frequencies you're talking a light moisture pocket taking the entire link down. Sent from my Mobile Device. -------- Original message -------- From: Phil Fagan Date: 05/17/2013 4:36 AM (GMT-08:00) To: Eugen Leitl Cc: NANOG Subject: Re: 40 GBit @ 240 GHz across 1 km LoS Congrats! How does 240Ghz react to atmospheric conditions other than "clear skys?" On May 17, 2013 4:17 AM, "Eugen Leitl" wrote: > > Fraunhofer: > > http://www.iaf.fraunhofer.de/de/news-medien/pressemitteilungen/presse-2013-05-16.html > > Google Translate: > > New world record in data transmission by radio > > Press Release 16/05/2013 > > With a Langstreckendemonstrator between two skyscrapers in Karlsruhe, a > distance of over a kilometer could already be bridged. ? KIT > > The RF chip is only 4 x 1.5 mm2 large, since electronic components with the > frequency or wavelength scale. > > ? Fraunhofer IAF > > Researchers at the Fraunhofer Institute for Applied Solid State Physics IAF > and the Karlsruhe Institute of Technology KIT, it is able to transmit 40 > Gb / > s at 240 GHz and over a distance of one kilometer by radio. With its recent > demonstration they have achieved a new world record and establish for the > first time seamlessly with the capacity of fiber to. Such future radio > links > could close gaps in the provision of broadband Internet by the wireless > links > complement the network of hard to reach areas or in rural areas. > > Digital, mobile and networked - the changing media usage behavior and > require > progressively increasing faster data transfer rates. The expansion of the > fiber network in Germany is lagging behind European standards, such as the > statistics of the industry organization FTTH Council Europe show. To lay > fiber optic lines is expensive and in the case of natural or urban > obstacles > such as rivers and transport hubs difficult. Broadband radio links can help > to overcome such critical points and so promote the expansion of network > infrastructures. In rural areas, they provide a cost effective and flexible > alternative to "Fibre To The Home 'in the expansion of broadband network > dar. > > In the data transmission by radio researchers have set a new world record > for > the first time fully integrated electronic transmitter and receiver are > designed for a frequency of 240 GHz, with which the data transfer rates up > to > 40 Gbit s is / possible. This corresponds to the transfer of a full DVD in > less than a second or 2400 DSL16000 Internet connections. With a > Langstreckendemonstrator a distance of over a kilometer could already be > covered, which was built by the Karlsruhe Institute of Technology between > two > skyscrapers in the "Milli Link" project. "We have managed to develop a > wireless link based on active electronic circuits similar to high data > rates, > such as fiber optic systems, and thus a seamless integration of the radio > link allows" said Professor Ingmar Kallfass, the project initially at > Fraunhofer IAF in looking a shared professorship - supported by IAF and > KIT - > coordinated. Kallfass since 2013 has been working at the University of > Stuttgart, where he continued to lead the project. > > High frequencies allow fast data transfer > > The use of the high frequency range between 200 and 280 GHz not only > enables > the fast transfer of large amounts of data, but also a very compact > technical > structure. Since the dimensions of electronic circuits and antennas > scalable > with frequency or wavelength of the transmitter and receiver chip is 4 x > 1.5 > mm 2 in size. Developed at Fraunhofer IAF semiconductor technology based on > transistors with high electron mobility transistor (HEMT) makes it possible > to use the frequency range between 200 and 280 GHz with active transmitters > and receivers in the form of compact, integrated circuits. In this > frequency > range, the atmosphere has low attenuation values, so that broadband radio > links are possible. "This is our spark gap compared to optical data > transmission systems easier to align and work in bad weather conditions > such > as fog or rain," explains Jochen antes from the KIT. > > So far, radio systems were not yet able to provide the bandwidth of an > optical fiber directly. That could change in the future, as the test shows > construction of the project. Such a powerful system possess the advantage > of > the so-called bit transparency, ie, the signal could be fed directly to a > fiber without energy-intensive recoding in a radio link, transmit and > re-routed at the other end with a glass fiber. The record data from the > test > set are just the beginning. "With an improvement in spectral efficiency > through the use of complex modulation formats or combination of channels, > ie > multiplexing, we can achieve even higher data rates, 'said Antes is safe. > This could be the expansion of broadband network a boost. Maybe Germany > will > in future no longer lies in Europe compared to the rear seats. > > About the project > > The project "Milli Link" is supported by the German Federal Ministry of > Education and Research within the funding program "broadband access next > generation networks" with a total of two million euros. Besides the two > research institutes Fraunhofer IAF and KIT industry partner Siemens AG, > Kathrein KG and Radiometer Physics GmbH are involved in the project. The > aim > of the project is the integration of wireless links or radio links in > broadband optical communication networks in order to provide particular to > rural areas with fast Internet access. Other possible applications include > indoor wireless local area networks (WLAN), wireless personal area networks > (WPAN), and intra-machine and board-to-board communication. > > Milli link Langstreckendemonstrator (print quality) [1.6095294952392578 MB > JPG] Milli link radio frequency chip (print quality) [1.7061738967895508 MB > JPG] > > From wbailey at satelliteintelligencegroup.com Fri May 17 14:30:59 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 17 May 2013 14:30:59 +0000 Subject: 40 GBit @ 240 GHz across 1 km LoS In-Reply-To: References: <20130517101537.GU26408@leitl.org>, Message-ID: These links are impressive, but I think this kind of stuff was designed for outer space. Sent from my Mobile Device. -------- Original message -------- From: Phil Fagan Date: 05/17/2013 4:36 AM (GMT-08:00) To: Eugen Leitl Cc: NANOG Subject: Re: 40 GBit @ 240 GHz across 1 km LoS Congrats! How does 240Ghz react to atmospheric conditions other than "clear skys?" On May 17, 2013 4:17 AM, "Eugen Leitl" wrote: > > Fraunhofer: > > http://www.iaf.fraunhofer.de/de/news-medien/pressemitteilungen/presse-2013-05-16.html > > Google Translate: > > New world record in data transmission by radio > > Press Release 16/05/2013 > > With a Langstreckendemonstrator between two skyscrapers in Karlsruhe, a > distance of over a kilometer could already be bridged. ? KIT > > The RF chip is only 4 x 1.5 mm2 large, since electronic components with the > frequency or wavelength scale. > > ? Fraunhofer IAF > > Researchers at the Fraunhofer Institute for Applied Solid State Physics IAF > and the Karlsruhe Institute of Technology KIT, it is able to transmit 40 > Gb / > s at 240 GHz and over a distance of one kilometer by radio. With its recent > demonstration they have achieved a new world record and establish for the > first time seamlessly with the capacity of fiber to. Such future radio > links > could close gaps in the provision of broadband Internet by the wireless > links > complement the network of hard to reach areas or in rural areas. > > Digital, mobile and networked - the changing media usage behavior and > require > progressively increasing faster data transfer rates. The expansion of the > fiber network in Germany is lagging behind European standards, such as the > statistics of the industry organization FTTH Council Europe show. To lay > fiber optic lines is expensive and in the case of natural or urban > obstacles > such as rivers and transport hubs difficult. Broadband radio links can help > to overcome such critical points and so promote the expansion of network > infrastructures. In rural areas, they provide a cost effective and flexible > alternative to "Fibre To The Home 'in the expansion of broadband network > dar. > > In the data transmission by radio researchers have set a new world record > for > the first time fully integrated electronic transmitter and receiver are > designed for a frequency of 240 GHz, with which the data transfer rates up > to > 40 Gbit s is / possible. This corresponds to the transfer of a full DVD in > less than a second or 2400 DSL16000 Internet connections. With a > Langstreckendemonstrator a distance of over a kilometer could already be > covered, which was built by the Karlsruhe Institute of Technology between > two > skyscrapers in the "Milli Link" project. "We have managed to develop a > wireless link based on active electronic circuits similar to high data > rates, > such as fiber optic systems, and thus a seamless integration of the radio > link allows" said Professor Ingmar Kallfass, the project initially at > Fraunhofer IAF in looking a shared professorship - supported by IAF and > KIT - > coordinated. Kallfass since 2013 has been working at the University of > Stuttgart, where he continued to lead the project. > > High frequencies allow fast data transfer > > The use of the high frequency range between 200 and 280 GHz not only > enables > the fast transfer of large amounts of data, but also a very compact > technical > structure. Since the dimensions of electronic circuits and antennas > scalable > with frequency or wavelength of the transmitter and receiver chip is 4 x > 1.5 > mm 2 in size. Developed at Fraunhofer IAF semiconductor technology based on > transistors with high electron mobility transistor (HEMT) makes it possible > to use the frequency range between 200 and 280 GHz with active transmitters > and receivers in the form of compact, integrated circuits. In this > frequency > range, the atmosphere has low attenuation values, so that broadband radio > links are possible. "This is our spark gap compared to optical data > transmission systems easier to align and work in bad weather conditions > such > as fog or rain," explains Jochen antes from the KIT. > > So far, radio systems were not yet able to provide the bandwidth of an > optical fiber directly. That could change in the future, as the test shows > construction of the project. Such a powerful system possess the advantage > of > the so-called bit transparency, ie, the signal could be fed directly to a > fiber without energy-intensive recoding in a radio link, transmit and > re-routed at the other end with a glass fiber. The record data from the > test > set are just the beginning. "With an improvement in spectral efficiency > through the use of complex modulation formats or combination of channels, > ie > multiplexing, we can achieve even higher data rates, 'said Antes is safe. > This could be the expansion of broadband network a boost. Maybe Germany > will > in future no longer lies in Europe compared to the rear seats. > > About the project > > The project "Milli Link" is supported by the German Federal Ministry of > Education and Research within the funding program "broadband access next > generation networks" with a total of two million euros. Besides the two > research institutes Fraunhofer IAF and KIT industry partner Siemens AG, > Kathrein KG and Radiometer Physics GmbH are involved in the project. The > aim > of the project is the integration of wireless links or radio links in > broadband optical communication networks in order to provide particular to > rural areas with fast Internet access. Other possible applications include > indoor wireless local area networks (WLAN), wireless personal area networks > (WPAN), and intra-machine and board-to-board communication. > > Milli link Langstreckendemonstrator (print quality) [1.6095294952392578 MB > JPG] Milli link radio frequency chip (print quality) [1.7061738967895508 MB > JPG] > > From cabo at tzi.org Fri May 17 15:22:30 2013 From: cabo at tzi.org (Carsten Bormann) Date: Fri, 17 May 2013 17:22:30 +0200 Subject: 40 GBit @ 240 GHz across 1 km LoS In-Reply-To: References: <20130517101537.GU26408@leitl.org>, Message-ID: <81EF97A8-0B6E-44EE-B166-E6F66F1E214A@tzi.org> On May 17, 2013, at 16:30, Warren Bailey wrote: > By not working. At those frequencies you're talking a light moisture pocket taking the entire link down. Not quite as bad: http://www.uni-stuttgart.de/int/institut/MA_Publikationen/reichart/COMCAS_25G_link.pdf The ~ 50 mm/h rain they seem to budget for is not yet quite an "end of the world" torrent, but it's not like you sneeze and the link goes down. (And if you have more than 50 mm/h sustained, you've got a much, much bigger problem :-) Gr??e, Carsten From Valdis.Kletnieks at vt.edu Fri May 17 15:24:00 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 17 May 2013 11:24:00 -0400 Subject: Looking for Netflow analysis package In-Reply-To: Your message of "Thu, 16 May 2013 15:16:22 -0700." <20130516151622.A0F49051@resin04.mta.everyone.net> References: <20130516151622.A0F49051@resin04.mta.everyone.net> Message-ID: <35076.1368804240@turing-police.cc.vt.edu> On Thu, 16 May 2013 15:16:22 -0700, "Scott Weeks" said: > You haven't been here long have you... > > He DOES NOT need a 260 word signature (see below!) to make sure he does > not get UCE from posting to NANOG. Actually, I think Thomas Cannon was making the opposite point - that if he's going to spam us all with a 260 word disclaimer, it could have been expanded to 263 words and add 'No cold calls'. Or just have that and lose the other 260 words that make absolutely no sense on a NANOG posting. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From brandon at bitradius.com Fri May 17 15:33:06 2013 From: brandon at bitradius.com (Brandon Lehmann) Date: Fri, 17 May 2013 15:33:06 +0000 Subject: BGP instability? In-Reply-To: References: Message-ID: <15AE4040AA24964AAE3DA9F2DE04C4F5C8F4750F@W2K8-EX.corp.bitradius.com> Thomas, We saw some instability this morning around 2:53am (EST) that resulted in practically complete communication failure in our Detroit colo. It lasted approximately 45 minutes and service was restored rather gradually. --- Brandon Lehmann CCNA, CCAI, CFOT, Net+, A+, Security+ BitRadius, LLC PO Box 493 Fremont, Ohio 43420 Email: brandon at bitradius.com Web: http://www.bitradius.com Phone: 567-255-3610 x9500 Toll-Free: 888-608-7253 x9500 Fax: 567-255-3611 ________________________________________ From: Thomas St-Pierre [tstpierre at iweb.com] Sent: Thursday, May 16, 2013 11:56 PM To: NANOG list Subject: BGP instability? Hi, Did anyone else see a large amount of instability between around 12:20am and 3:10am? (UTC, May 17th) We saw around 9 million announces per hour during that period come in through all our upstreams (vs an average normal of around 128k per hour). Just curious as to what happened, if anything. Thanks, Thomas From wbailey at satelliteintelligencegroup.com Fri May 17 16:44:20 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 17 May 2013 16:44:20 +0000 Subject: 40 GBit @ 240 GHz across 1 km LoS In-Reply-To: <81EF97A8-0B6E-44EE-B166-E6F66F1E214A@tzi.org> Message-ID: I disagree. It's not the near field stuff that is an issue.. It's the far field stuff further down the road that is going to murder the link.. Look at his Fig 1 and Fig 2. Fig 1 is saying that he is getting killed at 50mm/h of rain at 60 gig and at 175 gig. Fig 2 is saying that everything works well until you exceed .1km - where real life kicks back in. His clear sky is normal for anything wireless, but look at what happens at distances exceeding his comfort zone. From .1km to 1km he's taking 30-50dB of loss on his link. I don't know what kind of transmitter he has, but *IF* he were to encounter rain I sure as hell hope he has a form of transmit power control. I also noticed that they're using OOK, which is much better than FSK but runs the risk of being clobbered by a relatively small amount of noise. So yes, this is awesome for running huge data rates across the street. Down the road, you may have a few bad days. On 5/17/13 8:22 AM, "Carsten Bormann" wrote: >On May 17, 2013, at 16:30, Warren Bailey > wrote: > >> By not working. At those frequencies you're talking a light moisture >>pocket taking the entire link down. > >Not quite as bad: > >http://www.uni-stuttgart.de/int/institut/MA_Publikationen/reichart/COMCAS_ >25G_link.pdf > >The ~ 50 mm/h rain they seem to budget for is not yet quite an "end of >the world" torrent, but it's not like you sneeze and the link goes down. >(And if you have more than 50 mm/h sustained, you've got a much, much >bigger problem :-) > >Gr??e, Carsten > From philfagan at gmail.com Fri May 17 17:29:19 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 17 May 2013 11:29:19 -0600 Subject: 40 GBit @ 240 GHz across 1 km LoS In-Reply-To: References: <81EF97A8-0B6E-44EE-B166-E6F66F1E214A@tzi.org> Message-ID: Well put; 1kM is a giant leap from .1Km, but its a far cry from rural transport. I wonder what the fixed mobile/metro use cases might look like; Alternate path, aggregate short distance media backhaul... I think I like the idea most for non-earth atmosphere use cases, space vehicle or exploration vehicle use. Can you blast your way through rain, snow, or hell...a sandstorm by increasing your power? On Fri, May 17, 2013 at 10:44 AM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > I disagree. > > It's not the near field stuff that is an issue.. It's the far field stuff > further down the road that is going to murder the link.. Look at his Fig 1 > and Fig 2. > > Fig 1 is saying that he is getting killed at 50mm/h of rain at 60 gig and > at 175 gig. Fig 2 is saying that everything works well until you exceed > .1km - where real life kicks back in. His clear sky is normal for anything > wireless, but look at what happens at distances exceeding his comfort > zone. From .1km to 1km he's taking 30-50dB of loss on his link. I don't > know what kind of transmitter he has, but *IF* he were to encounter rain I > sure as hell hope he has a form of transmit power control. I also noticed > that they're using OOK, which is much better than FSK but runs the risk of > being clobbered by a relatively small amount of noise. > > So yes, this is awesome for running huge data rates across the street. > Down the road, you may have a few bad days. > > On 5/17/13 8:22 AM, "Carsten Bormann" wrote: > > >On May 17, 2013, at 16:30, Warren Bailey > > wrote: > > > >> By not working. At those frequencies you're talking a light moisture > >>pocket taking the entire link down. > > > >Not quite as bad: > > > > > http://www.uni-stuttgart.de/int/institut/MA_Publikationen/reichart/COMCAS_ > >25G_link.pdf > > > >The ~ 50 mm/h rain they seem to budget for is not yet quite an "end of > >the world" torrent, but it's not like you sneeze and the link goes down. > >(And if you have more than 50 mm/h sustained, you've got a much, much > >bigger problem :-) > > > >Gr??e, Carsten > > > > > -- Phil Fagan Denver, CO 970-480-7618 From wbailey at satelliteintelligencegroup.com Fri May 17 17:33:14 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 17 May 2013 17:33:14 +0000 Subject: 40 GBit @ 240 GHz across 1 km LoS In-Reply-To: References: <81EF97A8-0B6E-44EE-B166-E6F66F1E214A@tzi.org> , Message-ID: Super high frequency stuff is already in space. Iridium uses ka for their space craft to space craft routing network. Not much attenuation in a vacuum.. ;) Look up vortex beams. These guys should hook up with the vortex guys. They were getting like 40bits to hertz using oam. Sent from my Mobile Device. -------- Original message -------- From: Phil Fagan Date: 05/17/2013 10:29 AM (GMT-08:00) To: Warren Bailey Cc: Carsten Bormann ,NANOG list Subject: Re: 40 GBit @ 240 GHz across 1 km LoS Well put; 1kM is a giant leap from .1Km, but its a far cry from rural transport. I wonder what the fixed mobile/metro use cases might look like; Alternate path, aggregate short distance media backhaul... I think I like the idea most for non-earth atmosphere use cases, space vehicle or exploration vehicle use. Can you blast your way through rain, snow, or hell...a sandstorm by increasing your power? On Fri, May 17, 2013 at 10:44 AM, Warren Bailey > wrote: I disagree. It's not the near field stuff that is an issue.. It's the far field stuff further down the road that is going to murder the link.. Look at his Fig 1 and Fig 2. Fig 1 is saying that he is getting killed at 50mm/h of rain at 60 gig and at 175 gig. Fig 2 is saying that everything works well until you exceed .1km - where real life kicks back in. His clear sky is normal for anything wireless, but look at what happens at distances exceeding his comfort zone. From .1km to 1km he's taking 30-50dB of loss on his link. I don't know what kind of transmitter he has, but *IF* he were to encounter rain I sure as hell hope he has a form of transmit power control. I also noticed that they're using OOK, which is much better than FSK but runs the risk of being clobbered by a relatively small amount of noise. So yes, this is awesome for running huge data rates across the street. Down the road, you may have a few bad days. On 5/17/13 8:22 AM, "Carsten Bormann" > wrote: >On May 17, 2013, at 16:30, Warren Bailey >> wrote: > >> By not working. At those frequencies you're talking a light moisture >>pocket taking the entire link down. > >Not quite as bad: > >http://www.uni-stuttgart.de/int/institut/MA_Publikationen/reichart/COMCAS_ >25G_link.pdf > >The ~ 50 mm/h rain they seem to budget for is not yet quite an "end of >the world" torrent, but it's not like you sneeze and the link goes down. >(And if you have more than 50 mm/h sustained, you've got a much, much >bigger problem :-) > >Gr??e, Carsten > -- Phil Fagan Denver, CO 970-480-7618 From philfagan at gmail.com Fri May 17 17:37:07 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 17 May 2013 11:37:07 -0600 Subject: 40 GBit @ 240 GHz across 1 km LoS In-Reply-To: References: <81EF97A8-0B6E-44EE-B166-E6F66F1E214A@tzi.org> Message-ID: Nice...8x300Gbit optical beams; that's awesome. On Fri, May 17, 2013 at 11:33 AM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Super high frequency stuff is already in space. Iridium uses ka for > their space craft to space craft routing network. Not much attenuation in a > vacuum.. ;) > > Look up vortex beams. These guys should hook up with the vortex guys. > They were getting like 40bits to hertz using oam. > > > Sent from my Mobile Device. > > > -------- Original message -------- > From: Phil Fagan > Date: 05/17/2013 10:29 AM (GMT-08:00) > To: Warren Bailey > Cc: Carsten Bormann ,NANOG list > Subject: Re: 40 GBit @ 240 GHz across 1 km LoS > > > Well put; 1kM is a giant leap from .1Km, but its a far cry from rural > transport. > > I wonder what the fixed mobile/metro use cases might look like; > Alternate path, aggregate short distance media backhaul... > > I think I like the idea most for non-earth atmosphere use cases, space > vehicle or exploration vehicle use. > > Can you blast your way through rain, snow, or hell...a sandstorm by > increasing your power? > > > On Fri, May 17, 2013 at 10:44 AM, Warren Bailey < > wbailey at satelliteintelligencegroup.com> wrote: > >> I disagree. >> >> It's not the near field stuff that is an issue.. It's the far field stuff >> further down the road that is going to murder the link.. Look at his Fig 1 >> and Fig 2. >> >> Fig 1 is saying that he is getting killed at 50mm/h of rain at 60 gig and >> at 175 gig. Fig 2 is saying that everything works well until you exceed >> .1km - where real life kicks back in. His clear sky is normal for anything >> wireless, but look at what happens at distances exceeding his comfort >> zone. From .1km to 1km he's taking 30-50dB of loss on his link. I don't >> know what kind of transmitter he has, but *IF* he were to encounter rain I >> sure as hell hope he has a form of transmit power control. I also noticed >> that they're using OOK, which is much better than FSK but runs the risk of >> being clobbered by a relatively small amount of noise. >> >> So yes, this is awesome for running huge data rates across the street. >> Down the road, you may have a few bad days. >> >> On 5/17/13 8:22 AM, "Carsten Bormann" wrote: >> >> >On May 17, 2013, at 16:30, Warren Bailey >> > wrote: >> > >> >> By not working. At those frequencies you're talking a light moisture >> >>pocket taking the entire link down. >> > >> >Not quite as bad: >> > >> > >> http://www.uni-stuttgart.de/int/institut/MA_Publikationen/reichart/COMCAS_ >> >25G_link.pdf >> > >> >The ~ 50 mm/h rain they seem to budget for is not yet quite an "end of >> >the world" torrent, but it's not like you sneeze and the link goes down. >> >(And if you have more than 50 mm/h sustained, you've got a much, much >> >bigger problem :-) >> > >> >Gr??e, Carsten >> > >> >> >> > > > -- > Phil Fagan > Denver, CO > 970-480-7618 > -- Phil Fagan Denver, CO 970-480-7618 From wbailey at satelliteintelligencegroup.com Fri May 17 17:53:50 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 17 May 2013 17:53:50 +0000 Subject: 40 GBit @ 240 GHz across 1 km LoS In-Reply-To: References: <81EF97A8-0B6E-44EE-B166-E6F66F1E214A@tzi.org> , Message-ID: Yeah, the orbital in addition to spin is pretty ground breaking. The pictures of the actual light are jaw dropping. And I'm not sure they actually found the limit, they just tested to whatever they had gear for. Sent from my Mobile Device. -------- Original message -------- From: Phil Fagan Date: 05/17/2013 10:37 AM (GMT-08:00) To: Warren Bailey Cc: Carsten Bormann ,NANOG list Subject: Re: 40 GBit @ 240 GHz across 1 km LoS Nice...8x300Gbit optical beams; that's awesome. On Fri, May 17, 2013 at 11:33 AM, Warren Bailey > wrote: Super high frequency stuff is already in space. Iridium uses ka for their space craft to space craft routing network. Not much attenuation in a vacuum.. ;) Look up vortex beams. These guys should hook up with the vortex guys. They were getting like 40bits to hertz using oam. Sent from my Mobile Device. -------- Original message -------- From: Phil Fagan > Date: 05/17/2013 10:29 AM (GMT-08:00) To: Warren Bailey > Cc: Carsten Bormann >,NANOG list > Subject: Re: 40 GBit @ 240 GHz across 1 km LoS Well put; 1kM is a giant leap from .1Km, but its a far cry from rural transport. I wonder what the fixed mobile/metro use cases might look like; Alternate path, aggregate short distance media backhaul... I think I like the idea most for non-earth atmosphere use cases, space vehicle or exploration vehicle use. Can you blast your way through rain, snow, or hell...a sandstorm by increasing your power? On Fri, May 17, 2013 at 10:44 AM, Warren Bailey > wrote: I disagree. It's not the near field stuff that is an issue.. It's the far field stuff further down the road that is going to murder the link.. Look at his Fig 1 and Fig 2. Fig 1 is saying that he is getting killed at 50mm/h of rain at 60 gig and at 175 gig. Fig 2 is saying that everything works well until you exceed .1km - where real life kicks back in. His clear sky is normal for anything wireless, but look at what happens at distances exceeding his comfort zone. From .1km to 1km he's taking 30-50dB of loss on his link. I don't know what kind of transmitter he has, but *IF* he were to encounter rain I sure as hell hope he has a form of transmit power control. I also noticed that they're using OOK, which is much better than FSK but runs the risk of being clobbered by a relatively small amount of noise. So yes, this is awesome for running huge data rates across the street. Down the road, you may have a few bad days. On 5/17/13 8:22 AM, "Carsten Bormann" > wrote: >On May 17, 2013, at 16:30, Warren Bailey >> wrote: > >> By not working. At those frequencies you're talking a light moisture >>pocket taking the entire link down. > >Not quite as bad: > >http://www.uni-stuttgart.de/int/institut/MA_Publikationen/reichart/COMCAS_ >25G_link.pdf > >The ~ 50 mm/h rain they seem to budget for is not yet quite an "end of >the world" torrent, but it's not like you sneeze and the link goes down. >(And if you have more than 50 mm/h sustained, you've got a much, much >bigger problem :-) > >Gr??e, Carsten > -- Phil Fagan Denver, CO 970-480-7618 -- Phil Fagan Denver, CO 970-480-7618 From cscora at apnic.net Fri May 17 18:34:26 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 May 2013 04:34:26 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201305171834.r4HIYQ4Q009654@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 18 May, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 454719 Prefixes after maximum aggregation: 185412 Deaggregation factor: 2.45 Unique aggregates announced to Internet: 224945 Total ASes present in the Internet Routing Table: 44101 Prefixes per ASN: 10.31 Origin-only ASes present in the Internet Routing Table: 34624 Origin ASes announcing only one prefix: 16102 Transit ASes present in the Internet Routing Table: 5833 Transit-only ASes present in the Internet Routing Table: 152 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 30 Max AS path prepend of ASN ( 19037) 22 Prefixes from unregistered ASNs in the Routing Table: 320 Unregistered ASNs in the Routing Table: 136 Number of 32-bit ASNs allocated by the RIRs: 4770 Number of 32-bit ASNs visible in the Routing Table: 3644 Prefixes from 32-bit ASNs in the Routing Table: 10428 Special use prefixes present in the Routing Table: 23 Prefixes being announced from unallocated address space: 260 Number of addresses announced to Internet: 2616500460 Equivalent to 155 /8s, 244 /16s and 160 /24s Percentage of available address space announced: 70.7 Percentage of allocated address space announced: 70.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.5 Total number of prefixes smaller than registry allocations: 160213 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 109185 Total APNIC prefixes after maximum aggregation: 33486 APNIC Deaggregation factor: 3.26 Prefixes being announced from the APNIC address blocks: 110553 Unique aggregates announced from the APNIC address blocks: 44986 APNIC Region origin ASes present in the Internet Routing Table: 4845 APNIC Prefixes per ASN: 22.82 APNIC Region origin ASes announcing only one prefix: 1226 APNIC Region transit ASes present in the Internet Routing Table: 823 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 527 Number of APNIC addresses announced to Internet: 722376416 Equivalent to 43 /8s, 14 /16s and 150 /24s Percentage of available APNIC address space announced: 84.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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: 159587 Total ARIN prefixes after maximum aggregation: 80307 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 160174 Unique aggregates announced from the ARIN address blocks: 73630 ARIN Region origin ASes present in the Internet Routing Table: 15701 ARIN Prefixes per ASN: 10.20 ARIN Region origin ASes announcing only one prefix: 5977 ARIN Region transit ASes present in the Internet Routing Table: 1634 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 19 Number of ARIN addresses announced to Internet: 1062085504 Equivalent to 63 /8s, 78 /16s and 35 /24s Percentage of available ARIN address space announced: 56.2 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, 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: 117001 Total RIPE prefixes after maximum aggregation: 59797 RIPE Deaggregation factor: 1.96 Prefixes being announced from the RIPE address blocks: 120559 Unique aggregates announced from the RIPE address blocks: 77886 RIPE Region origin ASes present in the Internet Routing Table: 17174 RIPE Prefixes per ASN: 7.02 RIPE Region origin ASes announcing only one prefix: 8142 RIPE Region transit ASes present in the Internet Routing Table: 2800 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2332 Number of RIPE addresses announced to Internet: 656203364 Equivalent to 39 /8s, 28 /16s and 222 /24s Percentage of available RIPE address space announced: 95.4 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, 196608-199679 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: 47606 Total LACNIC prefixes after maximum aggregation: 9289 LACNIC Deaggregation factor: 5.12 Prefixes being announced from the LACNIC address blocks: 51794 Unique aggregates announced from the LACNIC address blocks: 24339 LACNIC Region origin ASes present in the Internet Routing Table: 1932 LACNIC Prefixes per ASN: 26.81 LACNIC Region origin ASes announcing only one prefix: 573 LACNIC Region transit ASes present in the Internet Routing Table: 353 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 760 Number of LACNIC addresses announced to Internet: 129090344 Equivalent to 7 /8s, 177 /16s and 195 /24s Percentage of available LACNIC address space announced: 76.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-62463, 262144-263167 plus 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: 10824 Total AfriNIC prefixes after maximum aggregation: 2492 AfriNIC Deaggregation factor: 4.34 Prefixes being announced from the AfriNIC address blocks: 11379 Unique aggregates announced from the AfriNIC address blocks: 3870 AfriNIC Region origin ASes present in the Internet Routing Table: 625 AfriNIC Prefixes per ASN: 18.21 AfriNIC Region origin ASes announcing only one prefix: 184 AfriNIC Region transit ASes present in the Internet Routing Table: 134 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46428416 Equivalent to 2 /8s, 196 /16s and 113 /24s Percentage of available AfriNIC address space announced: 46.1 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 2958 11559 924 Korea Telecom (KIX) 17974 2513 839 90 PT TELEKOMUNIKASI INDONESIA 7545 1980 320 108 TPG Internet Pty Ltd 4755 1729 391 192 TATA Communications formerly 9829 1510 1205 40 BSNL National Internet Backbo 9583 1219 91 502 Sify Limited 7552 1171 1064 12 Vietel Corporation 4808 1121 2112 328 CNCGROUP IP network: China169 9498 1109 309 71 BHARTI Airtel Ltd. 24560 1069 393 166 Bharti Airtel Ltd., Telemedia 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 3020 3693 81 bellsouth.net, inc. 7029 2143 1265 211 Windstream Communications Inc 18566 2067 382 184 Covad Communications 1785 1989 677 123 PaeTec Communications, Inc. 22773 1974 2929 125 Cox Communications, Inc. 20115 1668 1608 617 Charter Communications 4323 1620 1139 401 Time Warner Telecom 30036 1327 295 643 Mediacom Communications Corp 7018 1311 10819 848 AT&T WorldNet Services 11492 1231 220 345 Cable One 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 8402 1773 544 16 Corbina telecom 2118 1309 97 13 EUnet/RELCOM Autonomous Syste 34984 1204 240 228 BILISIM TELEKOM 20940 832 286 659 Akamai Technologies European 13188 820 97 84 Educational Network 31148 792 39 22 FreeNet ISP 8551 772 370 43 Bezeq International 6830 770 2376 443 UPC Distribution Services 12479 686 782 67 Uni2 Autonomous System 34744 676 173 56 SC GVM SISTEM 2003 SRL 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 28573 2732 1528 113 NET Servicos de Comunicao S.A 10620 2631 412 224 TVCABLE BOGOTA 7303 1723 1153 221 Telecom Argentina Stet-France 8151 1247 2705 394 UniNet S.A. de C.V. 6503 979 435 68 AVANTEL, S.A. 18881 940 780 19 Global Village Telecom 27947 840 89 99 Telconet S.A 3816 706 306 85 Empresa Nacional de Telecomun 7738 698 1370 35 Telecomunicacoes da Bahia S.A 11172 608 87 64 Servicios Alestra S.A de C.V 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 36998 1237 80 4 MOBITEL 24863 885 274 32 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 445 956 9 TEDATA 24835 344 80 8 RAYA Telecom - Egypt 3741 261 906 220 The Internet Solution 15706 222 32 6 Sudatel Internet Exchange Aut 12258 193 28 67 Vodacom Internet Company 29975 191 667 21 Vodacom 36992 189 527 22 Etisalat MISR 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 6389 3020 3693 81 bellsouth.net, inc. 4766 2958 11559 924 Korea Telecom (KIX) 28573 2732 1528 113 NET Servicos de Comunicao S.A 10620 2631 412 224 TVCABLE BOGOTA 17974 2513 839 90 PT TELEKOMUNIKASI INDONESIA 7029 2143 1265 211 Windstream Communications Inc 18566 2067 382 184 Covad Communications 1785 1989 677 123 PaeTec Communications, Inc. 7545 1980 320 108 TPG Internet Pty Ltd 22773 1974 2929 125 Cox 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 28573 2732 2619 NET Servicos de Comunicao S.A 17974 2513 2423 PT TELEKOMUNIKASI INDONESIA 10620 2631 2407 TVCABLE BOGOTA 4766 2958 2034 Korea Telecom (KIX) 7029 2143 1932 Windstream Communications Inc 18566 2067 1883 Covad Communications 7545 1980 1872 TPG Internet Pty Ltd 1785 1989 1866 PaeTec Communications, Inc. 22773 1974 1849 Cox Communications, Inc. 8402 1773 1757 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.46.0/23 39743 Mobimax Telecom SRL 128.0.52.0/24 60906 NETOPIA SRL 128.0.58.0/23 9050 RTD-ROMTELECOM Autonomous Sys 128.0.60.0/24 9050 RTD-ROMTELECOM Autonomous Sys 128.0.61.0/24 9050 RTD-ROMTELECOM Autonomous Sys 128.0.62.0/24 9050 RTD-ROMTELECOM Autonomous Sys 128.0.63.0/24 9050 RTD-ROMTELECOM Autonomous Sys Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. 64.185.230.0/24 27431 JTL Networks Inc. 64.185.231.0/24 27431 JTL Networks Inc. 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:13 /10:30 /11:87 /12:248 /13:490 /14:882 /15:1567 /16:12689 /17:6625 /18:11182 /19:22118 /20:32017 /21:34142 /22:47283 /23:42242 /24:239077 /25:1308 /26:1689 /27:868 /28:44 /29:66 /30:18 /31:0 /32:18 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2018 2067 Covad Communications 6389 1733 3020 bellsouth.net, inc. 7029 1611 2143 Windstream Communications Inc 8402 1469 1773 Corbina telecom 22773 1283 1974 Cox Communications, Inc. 36998 1231 1237 MOBITEL 30036 1197 1327 Mediacom Communications Corp 11492 1192 1231 Cable One 1785 1062 1989 PaeTec Communications, Inc. 6983 1008 1134 ITC^Deltacom Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:803 2:756 3:3 4:15 5:879 6:7 8:557 12:1933 13:3 14:820 15:11 16:3 17:9 20:17 23:281 24:1767 27:1511 31:1286 32:43 33:2 34:5 36:28 37:1849 38:875 39:2 40:172 41:2785 42:192 44:6 46:1897 47:2 49:637 50:708 52:12 54:35 55:7 57:26 58:1141 59:571 60:313 61:1391 62:1090 63:2026 64:4327 65:2195 66:4359 67:2063 68:1128 69:3279 70:880 71:537 72:1924 74:2559 75:416 76:308 77:1111 78:1046 79:591 80:1255 81:994 82:624 83:557 84:530 85:1161 86:462 87:980 88:536 89:1792 90:162 91:5478 92:587 93:1706 94:1833 95:1490 96:529 97:344 98:1053 99:41 100:31 101:329 103:2593 105:519 106:153 107:209 108:520 109:1851 110:882 111:1053 112:516 113:799 114:710 115:946 116:912 117:789 118:1073 119:1287 120:408 121:724 122:1795 123:1215 124:1348 125:1354 128:637 129:224 130:325 131:653 132:341 133:149 134:262 135:66 136:221 137:265 138:345 139:197 140:207 141:327 142:549 143:382 144:485 145:92 146:514 147:405 148:696 149:373 150:160 151:569 152:418 153:199 154:43 155:394 156:264 157:399 158:277 159:729 160:357 161:427 162:434 163:218 164:594 165:450 166:300 167:585 168:1037 169:133 170:1026 171:178 172:22 173:1668 174:592 175:489 176:1291 177:2035 178:1875 179:6 180:1431 181:388 182:1210 183:379 184:677 185:438 186:2272 187:1322 188:2145 189:1358 190:6310 192:6653 193:5865 194:4630 195:3420 196:1332 197:906 198:4462 199:5290 200:5924 201:2252 202:8874 203:8844 204:4507 205:2569 206:2841 207:2897 208:4072 209:3623 210:2957 211:1559 212:2107 213:1952 214:914 215:98 216:5241 217:1605 218:615 219:330 220:1279 221:555 222:319 223:442 End of report From john at starta.org Fri May 17 17:02:53 2013 From: john at starta.org (John Starta) Date: Fri, 17 May 2013 10:02:53 -0700 Subject: Looking for Netflow analysis package In-Reply-To: <35076.1368804240@turing-police.cc.vt.edu> References: <20130516151622.A0F49051@resin04.mta.everyone.net> <35076.1368804240@turing-police.cc.vt.edu> Message-ID: <0118C59B-99A1-4A16-A08A-90561479BA66@starta.org> On May 17, 2013, at 8:24 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 16 May 2013 15:16:22 -0700, "Scott Weeks" said: > >> You haven't been here long have you... >> >> He DOES NOT need a 260 word signature (see below!) to make sure he does >> not get UCE from posting to NANOG. > > Actually, I think Thomas Cannon was making the opposite point - that if > he's going to spam us all with a 260 word disclaimer, it could have been > expanded to 263 words and add 'No cold calls'. Or just have that and lose > the other 260 words that make absolutely no sense on a NANOG posting. Do you believe that Brent wrote the disclaimer attached to his message? Despite y/our opinions of such disclaimers, legal counsel in some companies still mandate their automatic attachment on all outbound messages. The only means of avoiding them is to subscribe to mailing lists from a personal e-mail account. Unfortunately these companies usually also have policies prohibiting your accessing personal e-mail accounts from company owned resources which can minimize the usefulness of some lists. In other words, just because we might work for "enlightened" companies doesn't mean all our colleagues can or do. From philfagan at gmail.com Fri May 17 20:12:28 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 17 May 2013 14:12:28 -0600 Subject: Looking for Netflow analysis package In-Reply-To: <0118C59B-99A1-4A16-A08A-90561479BA66@starta.org> References: <20130516151622.A0F49051@resin04.mta.everyone.net> <35076.1368804240@turing-police.cc.vt.edu> <0118C59B-99A1-4A16-A08A-90561479BA66@starta.org> Message-ID: Well put. On May 17, 2013 1:54 PM, "John Starta" wrote: > On May 17, 2013, at 8:24 AM, Valdis.Kletnieks at vt.edu wrote: > > > On Thu, 16 May 2013 15:16:22 -0700, "Scott Weeks" said: > > > >> You haven't been here long have you... > >> > >> He DOES NOT need a 260 word signature (see below!) to make sure he does > >> not get UCE from posting to NANOG. > > > > Actually, I think Thomas Cannon was making the opposite point - that if > > he's going to spam us all with a 260 word disclaimer, it could have been > > expanded to 263 words and add 'No cold calls'. Or just have that and lose > > the other 260 words that make absolutely no sense on a NANOG posting. > > Do you believe that Brent wrote the disclaimer attached to his message? > Despite y/our opinions of such disclaimers, legal counsel in some companies > still mandate their automatic attachment on all outbound messages. The only > means of avoiding them is to subscribe to mailing lists from a personal > e-mail account. Unfortunately these companies usually also have policies > prohibiting your accessing personal e-mail accounts from company owned > resources which can minimize the usefulness of some lists. In other words, > just because we might work for "enlightened" companies doesn't mean all our > colleagues can or do. > From surfer at mauigateway.com Fri May 17 20:49:28 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 17 May 2013 13:49:28 -0700 Subject: Looking for Netflow analysis package Message-ID: <20130517134928.A0F439B8@resin04.mta.everyone.net> On May 17, 2013 1:54 PM, "John Starta" wrote: > On May 17, 2013, at 8:24 AM, Valdis.Kletnieks at vt.edu wrote: > > On Thu, 16 May 2013 15:16:22 -0700, "Scott Weeks" said: > >> He DOES NOT need a 260 word signature (see below!) to make sure he does > >> not get UCE from posting to NANOG. > > Actually, I think Thomas Cannon was making the opposite point - that if > > he's going to spam us all with a 260 word disclaimer, it could have been > > expanded to 263 words and add 'No cold calls'. Or just have that and lose > > the other 260 words that make absolutely no sense on a NANOG posting. > Do you believe that Brent wrote the disclaimer attached to his message? > Despite y/our opinions of such disclaimers, legal counsel in some companies > still mandate their automatic attachment on all outbound messages. The only > means of avoiding them is to subscribe to mailing lists from a personal > e-mail account. Unfortunately these companies usually also have policies > prohibiting your accessing personal e-mail accounts from company owned > resources which can minimize the usefulness of some lists. In other words, > just because we might work for "enlightened" companies doesn't mean all our > colleagues can or do. ----------------------------------------------------- ------ philfagan at gmail.com wrote: ------------ From: Phil Fagan Well put. ---------------------------------------- One, you're both missing the point. Do you think a sales droid that'll scrape a technical mailing list like NANOG for cold calls will respect whatever crap is put into a .sig? Don't answer. It's rhetorical... Two, "Unfortunately these companies usually also have policies prohibiting your accessing personal e-mail accounts from company owned resources". So don't. Set up an SSH tunnel over port 80 to your home server and access your non-paragraph-sized-signature email account from home. There's a million ways to do things and still follow corporate rules... scot From cidr-report at potaroo.net Fri May 17 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 May 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201305172200.r4HM00hU028573@wattle.apnic.net> This report has been generated at Fri May 17 21:13:20 2013 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 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 10-05-13 456517 260545 11-05-13 456429 260800 12-05-13 456427 260578 13-05-13 456657 260920 14-05-13 456257 260595 15-05-13 456644 260634 16-05-13 456641 260546 17-05-13 456674 260667 AS Summary 44203 Number of ASes in routing system 18296 Number of ASes announcing only one prefix 3020 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116963808 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 17May13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 456741 260292 196449 43.0% All ASes AS6389 3020 85 2935 97.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4766 2958 940 2018 68.2% KIXS-AS-KR Korea Telecom AS28573 2732 718 2014 73.7% NET Servi?os de Comunica??o S.A. AS17974 2513 566 1947 77.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 1974 125 1849 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2067 473 1594 77.1% COVAD - Covad Communications Co. AS10620 2631 1335 1296 49.3% Telmex Colombia S.A. AS7303 1723 452 1271 73.8% Telecom Argentina S.A. AS2118 1309 63 1246 95.2% RELCOM-AS OOO "NPO Relcom" AS4323 1623 405 1218 75.0% TWTC - tw telecom holdings, inc. AS4755 1728 582 1146 66.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1171 180 991 84.6% VIETEL-AS-AP Vietel Corporation AS36998 1237 301 936 75.7% SDN-MOBITEL AS18881 932 24 908 97.4% Global Village Telecom AS7029 2143 1242 901 42.0% WINDSTREAM - Windstream Communications Inc AS18101 999 180 819 82.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8402 1749 1000 749 42.8% CORBINA-AS OJSC "Vimpelcom" AS1785 1989 1241 748 37.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1121 385 736 65.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 843 135 708 84.0% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS9808 813 121 692 85.1% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS855 742 55 687 92.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS8151 1256 588 668 53.2% Uninet S.A. de C.V. AS22561 1169 501 668 57.1% DIGITAL-TELEPORT - Digital Teleport Inc. AS24560 1069 408 661 61.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS6983 1134 478 656 57.8% ITCDELTA - ITC^Deltacom AS7545 1984 1330 654 33.0% TPG-INTERNET-AP TPG Telecom Limited AS15003 793 155 638 80.5% NOBIS-TECH - Nobis Technology Group, LLC AS17676 731 108 623 85.2% GIGAINFRA Softbank BB Corp. AS3549 1068 447 621 58.1% GBLX Global Crossing Ltd. Total 47221 14623 32598 69.0% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.197.36.0/22 AS43359 91.203.76.0/22 AS44932 91.203.76.0/24 AS44932 91.203.77.0/24 AS44932 91.203.78.0/24 AS44932 91.203.79.0/24 AS44932 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 91.214.32.0/22 AS49326 91.214.32.0/24 AS49326 91.214.33.0/24 AS49326 91.214.34.0/24 AS49326 91.214.35.0/24 AS49326 100.64.1.0/24 AS17338 NIS - Network Integration Services, Inc. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.138.128.0/20 AS32738 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.52.192.0/24 AS27919 190.52.193.0/24 AS27919 190.52.194.0/24 AS27919 190.52.195.0/24 AS27919 190.52.196.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.197.0/24 AS27919 190.52.198.0/24 AS27919 190.52.199.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.200.0/24 AS27947 Telconet S.A 190.52.201.0/24 AS27947 Telconet S.A 190.52.202.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.203.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.205.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.206.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.207.0/24 AS3549 GBLX Global Crossing Ltd. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 195.60.172.0/23 AS39208 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 200.107.248.0/24 AS27919 200.107.249.0/24 AS27919 200.107.250.0/24 AS27919 200.107.251.0/24 AS27919 200.107.252.0/24 AS28006 CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 200.107.254.0/24 AS27919 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 201.222.32.0/20 AS27821 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 204.8.218.0/24 AS39323 AS-DZONE - Dedicated Zone Inc 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.70.56.0/21 AS32738 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.22.0/24 AS6939 HURRICANE - Hurricane Electric, Inc. 209.209.38.0/24 AS6939 HURRICANE - Hurricane Electric, Inc. 209.209.50.0/24 AS6939 HURRICANE - Hurricane Electric, Inc. 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.209.67.0/24 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 209.250.230.0/24 AS39323 AS-DZONE - Dedicated Zone Inc 209.250.252.0/22 AS39323 AS-DZONE - Dedicated Zone Inc 209.250.255.0/24 AS46496 AS-6GTECH - 6G Technologies Inc 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.127.192.0/24 AS22166 216.127.193.0/24 AS22166 216.127.194.0/24 AS22166 216.127.195.0/24 AS22166 216.127.196.0/24 AS22166 216.127.196.64/26 AS22166 216.127.197.0/24 AS22166 216.127.198.0/24 AS22166 216.127.199.0/24 AS22166 216.127.200.0/24 AS22166 216.127.201.0/24 AS22166 216.127.202.0/24 AS22166 216.127.203.0/24 AS22166 216.127.204.0/24 AS22166 216.127.205.0/24 AS22166 216.127.206.0/24 AS22166 216.127.207.0/24 AS22166 216.127.208.0/24 AS22166 216.127.209.0/24 AS22166 216.127.210.0/24 AS22166 216.127.211.0/24 AS22166 216.127.212.0/24 AS22166 216.127.213.0/24 AS22166 216.127.214.0/24 AS22166 216.127.215.0/24 AS22166 216.127.216.0/24 AS22166 216.127.217.0/24 AS22166 216.127.218.0/24 AS22166 216.127.219.0/24 AS22166 216.127.220.0/24 AS22166 216.127.221.0/24 AS22166 216.127.222.0/24 AS22166 216.127.223.0/24 AS22166 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 May 17 22:00:02 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 May 2013 22:00:02 GMT Subject: BGP Update Report Message-ID: <201305172200.r4HM02Mp028597@wattle.apnic.net> BGP Update Report Interval: 09-May-13 -to- 16-May-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS36998 211390 9.9% 277.4 -- SDN-MOBITEL 2 - AS9829 46479 2.2% 45.9 -- BSNL-NIB National Internet Backbone 3 - AS8402 35090 1.6% 20.2 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS34875 30967 1.5% 260.2 -- YANFES OJSC "Rostelecom" 5 - AS31148 28573 1.3% 35.9 -- FREENET-AS Freenet Ltd. 6 - AS7552 27491 1.3% 23.5 -- VIETEL-AS-AP Vietel Corporation 7 - AS5800 27044 1.3% 112.2 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 8 - AS28573 26943 1.3% 7.9 -- NET Servi?os de Comunica??o S.A. 9 - AS15003 26262 1.2% 42.7 -- NOBIS-TECH - Nobis Technology Group, LLC 10 - AS10620 18972 0.9% 8.9 -- Telmex Colombia S.A. 11 - AS34744 18709 0.9% 28.0 -- GVM S.C. GVM SISTEM 2003 S.R.L. 12 - AS27738 18327 0.9% 32.3 -- Ecuadortelecom S.A. 13 - AS9416 16368 0.8% 314.8 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 14 - AS3909 16180 0.8% 2311.4 -- QWEST-AS-3908 - Qwest Communications Company, LLC 15 - AS2708 15117 0.7% 196.3 -- Universidad de Guanajuato 16 - AS24532 14742 0.7% 313.7 -- INET-AS-ID PT. Inet Global Indo 17 - AS4538 13651 0.6% 26.3 -- ERX-CERNET-BKB China Education and Research Network Center 18 - AS2914 12826 0.6% 158.3 -- NTT-COMMUNICATIONS-2914 - NTT America, Inc. 19 - AS2118 12823 0.6% 9.2 -- RELCOM-AS OOO "NPO Relcom" 20 - AS33776 12043 0.6% 65.5 -- STARCOMMS-ASN TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6629 7469 0.3% 7469.0 -- NOAA-AS - NOAA 2 - AS19406 4193 0.2% 4193.0 -- TWRS-MA - Towerstream I, Inc. 3 - AS6174 6042 0.3% 3021.0 -- SPRINTLINK8 - Sprint 4 - AS3909 16180 0.8% 2311.4 -- QWEST-AS-3908 - Qwest Communications Company, LLC 5 - AS14680 6723 0.3% 2241.0 -- REALE-6 - Auction.com 6 - AS37318 2112 0.1% 2112.0 -- BESA 7 - AS16536 1931 0.1% 1931.0 -- HPES - Hewlett-Packard Company 8 - AS60811 1730 0.1% 1730.0 -- SAIPAYADAH-AS Saipa Yadak Co. PLC 9 - AS37367 2952 0.1% 1476.0 -- CALLKEY 10 - AS33920 2933 0.1% 1466.5 -- AQL (aq) Networks Limited 11 - AS19796 2076 0.1% 1038.0 -- SHUBERT - Shubert Organization, Inc. 12 - AS42334 2276 0.1% 758.7 -- BBP-AS Broadband Plus s.a.l. 13 - AS1273 3784 0.2% 756.8 -- CW Cable and Wireless Worldwide plc 14 - AS48612 8190 0.4% 585.0 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 15 - AS8382 568 0.0% 568.0 -- IRTEL-AS OJSC Rostelecom 16 - AS37343 3348 0.2% 558.0 -- AirtelSeychelles 17 - AS37307 526 0.0% 526.0 -- AGRA 18 - AS58385 951 0.0% 475.5 -- BSM-AS-ID PT. Bank Syariah Mandiri 19 - AS57798 1301 0.1% 433.7 -- IT-NET-LTD-AS IT-Net ltd. 20 - AS15741 423 0.0% 423.0 -- NETEXPILINE Expiline Ltd. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 209.142.140.0/24 10525 0.5% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 2 - 193.19.90.0/23 9090 0.4% AS29684 -- NOURNET-ASN Nour Communication Co.Ltd - Nournet 3 - 203.118.224.0/21 8098 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 4 - 92.246.207.0/24 8093 0.4% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 5 - 203.118.232.0/21 7942 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 6 - 192.58.232.0/24 7469 0.3% AS6629 -- NOAA-AS - NOAA 7 - 202.41.70.0/24 6579 0.3% AS2697 -- ERX-ERNET-AS Education and Research Network 8 - 12.139.133.0/24 5441 0.2% AS14680 -- REALE-6 - Auction.com 9 - 151.118.255.0/24 5391 0.2% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 10 - 151.118.254.0/24 5391 0.2% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 11 - 151.118.18.0/24 5381 0.2% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 12 - 173.232.234.0/24 5096 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 13 - 173.232.235.0/24 5096 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 14 - 209.240.40.0/21 4964 0.2% AS32020 -- TRANSACT-BM-ASN - Transact Ltd. 15 - 69.38.178.0/24 4193 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 16 - 194.63.9.0/24 3773 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 17 - 64.187.64.0/23 3524 0.1% AS16608 -- KENTEC - Kentec Communications, Inc. 18 - 206.105.75.0/24 3021 0.1% AS6174 -- SPRINTLINK8 - Sprint 19 - 208.16.110.0/24 3021 0.1% AS6174 -- SPRINTLINK8 - Sprint 20 - 41.75.40.0/21 2949 0.1% AS37367 -- CALLKEY 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 aaron at heyaaron.com Sat May 18 00:00:32 2013 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 17 May 2013 17:00:32 -0700 Subject: Remote Hands Nation-Wide? Message-ID: I recall a message a while back about a company that offered remote hands nation-wide, but my Google-Fu is failing me. Any pointers? We basically need to find coverage for eastern Washington State and all of Oregon. -A From ml at kenweb.org Sat May 18 00:06:59 2013 From: ml at kenweb.org (ML) Date: Fri, 17 May 2013 20:06:59 -0400 Subject: Remote Hands Nation-Wide? In-Reply-To: References: Message-ID: <5196C623.9080208@kenweb.org> On 5/17/2013 8:00 PM, Aaron C. de Bruyn wrote: > I recall a message a while back about a company that offered remote hands > nation-wide, but my Google-Fu is failing me. > > Any pointers? > > We basically need to find coverage for eastern Washington State and all of > Oregon. > > -A Perhaps Ledcor? http://www.ledcor.com/what-we-do/communications/front-line-maintenance From kyle.creyts at gmail.com Sat May 18 02:16:51 2013 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Fri, 17 May 2013 19:16:51 -0700 Subject: looking for documents describing frequent causes for line cuts Message-ID: has anyone come by documents containing some statistics regarding leading causes for cuts in fiber, power, cable lines? I seem to remember one which included % cuts due to equipment failure, maintenance, weather, rodents, boring, car accidents, etc. but alas, I cannot find it in my archives. From jeff-kell at utc.edu Sat May 18 02:18:34 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 17 May 2013 22:18:34 -0400 Subject: Entry level WDM gear? follow-up In-Reply-To: <518CFC72.6020109@tularosa.net> References: <518B1637.20002@utc.edu> <518CFC72.6020109@tularosa.net> Message-ID: <5196E4FA.1050502@utc.edu> On 5/10/2013 9:56 AM, Jerimiah Cole wrote: > On 05/08/2013 09:21 PM, Jeff Kell wrote: >> Ciena/Cyan/etc are way over our non-existant budget... what is the >> going recommendation to throw say 4-8 lambdas over a dark pair without >> breaking the bank? :) > I've used http://www.omnitron-systems.com/ media converters and found > them reliable. They've got the filters to do an 8 channel system. Thanks for this and other responses. Cumulatively I have some more information, but also more questions :) We have an existing fiber pair to location "A" where it is cross-connected to location "B" and terminated. It's currently a ~35km link running 10G-ER optics (1550nm). We're getting a little less than -7dBm receive over the link now with standard 10G-ER optics. We need to connect to another provider at location "A" (also 10G), so thinking of xWDM from campus to location "A". Would like to handoff one lambda on to location "B" to maintain that circuit, and the new/additional ones would terminate at location "A". CWDM is obviously cheaper and supports the 1550nm current band (but do we need to replace existing optics with "tuned" ones to keep things honest?). Cisco lists no CWDM 10G optics at all in any form factor, only DWDM, and they're "really proud" of them based on the list price. The "tuned" optics have no SR/LR/ER/ZR attributes... so what are their real distance characteristics? In particular, can we cross-connect one of the outputs to the existing location "B" and have the dBm budget to get there? This is becoming quite the adventure :) Jeff From me at staticsafe.ca Sat May 18 03:00:08 2013 From: me at staticsafe.ca (staticsafe) Date: Fri, 17 May 2013 23:00:08 -0400 Subject: looking for documents describing frequent causes for line cuts In-Reply-To: References: Message-ID: <5196EEB8.3090803@staticsafe.ca> On 5/17/2013 22:16, Kyle Creyts wrote: > has anyone come by documents containing some statistics regarding leading > causes for cuts in fiber, power, cable lines? > > I seem to remember one which included % cuts due to equipment failure, > maintenance, weather, rodents, boring, car accidents, etc. > > but alas, I cannot find it in my archives. > On an amusing note: http://blog.level3.com/level-3-network/the-10-most-bizarre-and-annoying-causes-of-fiber-cuts/ -- staticsafe O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post - http://goo.gl/YrmAb Don't CC me! I'm subscribed to whatever list I just posted on. From cra at WPI.EDU Sat May 18 03:29:53 2013 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 17 May 2013 23:29:53 -0400 Subject: Entry level WDM gear? follow-up In-Reply-To: <5196E4FA.1050502@utc.edu> References: <518B1637.20002@utc.edu> <518CFC72.6020109@tularosa.net> <5196E4FA.1050502@utc.edu> Message-ID: <20130518032952.GH26546@angus.ind.WPI.EDU> On Fri, May 17, 2013 at 10:18:34PM -0400, Jeff Kell wrote: > On 5/10/2013 9:56 AM, Jerimiah Cole wrote: > > On 05/08/2013 09:21 PM, Jeff Kell wrote: > >> Ciena/Cyan/etc are way over our non-existant budget... what is the > >> going recommendation to throw say 4-8 lambdas over a dark pair without > >> breaking the bank? :) > > I've used http://www.omnitron-systems.com/ media converters and found > > them reliable. They've got the filters to do an 8 channel system. > > Thanks for this and other responses. Cumulatively I have some more > information, but also more questions :) > > We have an existing fiber pair to location "A" where it is > cross-connected to location "B" and terminated. It's currently a ~35km > link running 10G-ER optics (1550nm). We're getting a little less than > -7dBm receive over the link now with standard 10G-ER optics. > > We need to connect to another provider at location "A" (also 10G), so > thinking of xWDM from campus to location "A". Would like to handoff one > lambda on to location "B" to maintain that circuit, and the > new/additional ones would terminate at location "A". Typically you would use an Optical Add/Drop Multiplexer at each intermediate site and a regular Optical Mux at the endpoint sites, but you should be able to simplify this to just two OMUXes, one at "A" and the other at campus, sending the lambda for "B" through the cross-connect as long as you don't need more than one lambda at "B". > CWDM is obviously cheaper and supports the 1550nm current band (but do > we need to replace existing optics with "tuned" ones to keep things > honest?). Should work fine with your existing 1550 ER optics, as long as you have enough optical budget to account for the additional loss of the CWDM passives. You should even be able to use one of the wavelengths of DWDM C-band optics within the 1550nm 20nm-wide channel of a CWDM system. I know somemone who did this to "future-proof" their optics for an eventual upgrade to a DWDM system. > Cisco lists no CWDM 10G optics at all in any form factor, only DWDM, and > they're "really proud" of them based on the list price. Transition Networks and Integra Networks should both have 10G SFP+ and XFP optics in CWDM wavelengths. Integra can also do the CWDM passives including custom arrangements in various form factors. > The "tuned" optics have no SR/LR/ER/ZR attributes... so what are their > real distance characteristics? In particular, can we cross-connect one > of the outputs to the existing location "B" and have the dBm budget to > get there? Distance specs are always "approximate" or "nominal" with no guarantee that you will reach that far since it depends on lots of different factors and in some cases you can even go farther. You should be able to tell definitively by the optical specs, specifically output power in dBm & receiver sensitivity in dBm (subtract the two to get the link budget in dB) or the optical budget may be given directly in dB or you may be able to infer by the distance spec (different vendors' 40km, 80km, 120km optics I've seen all have similar optical power specs/budgets--but these may be different 1gig vs. 10gig so only compare distances of the same speed optics to infer optical budgets and keep this in mind when upgrading a link from 1g to 10g). Once you know the budget for each pair of optics, you need to add up the loss of all components between the two endpoints of each pair, using the losses given in the CWDM passives spec sheet for add/drop loss, pass-thru loss, etc. as well as connector, splice, and distance losses. In my experience, so-called 80km 10gig optics were necessary to go even 2km (two km) in a CWDM system with several add/drops in between the endpoints (including some leftover budget for expansion to more add/drops), while so-called 40km 1gig optics were fine under the same conditions. From kyle.creyts at gmail.com Sat May 18 09:03:30 2013 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Sat, 18 May 2013 02:03:30 -0700 Subject: looking for documents describing frequent causes for line cuts In-Reply-To: <5196EEB8.3090803@staticsafe.ca> References: <5196EEB8.3090803@staticsafe.ca> Message-ID: thanks! also amusing: http://blog.lafayetteprofiber.com/2008/06/nutria-ratsand-fiber.html http://news.techeye.net/internet/internet-attacked-by-bears#.TnZXk5rhOv8.reddit but I'm looking for something slightly more efficacious than anecdotal. off-list replies (and, why not, some of them are really funny) anecdotes are welcome. On Fri, May 17, 2013 at 8:00 PM, staticsafe wrote: > On 5/17/2013 22:16, Kyle Creyts wrote: > > has anyone come by documents containing some statistics regarding leading > > causes for cuts in fiber, power, cable lines? > > > > I seem to remember one which included % cuts due to equipment failure, > > maintenance, weather, rodents, boring, car accidents, etc. > > > > but alas, I cannot find it in my archives. > > > > On an amusing note: > > http://blog.level3.com/level-3-network/the-10-most-bizarre-and-annoying-causes-of-fiber-cuts/ > -- > staticsafe > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > Please don't top post - http://goo.gl/YrmAb > Don't CC me! I'm subscribed to whatever list I just posted on. > > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From ryangard at gmail.com Sat May 18 09:40:10 2013 From: ryangard at gmail.com (Ryan Gard) Date: Sat, 18 May 2013 05:40:10 -0400 Subject: looking for documents describing frequent causes for line cuts In-Reply-To: References: <5196EEB8.3090803@staticsafe.ca> Message-ID: Here's one I came across from Southern Telecom that seems to give some hard numbers on incidents they've experienced with their fibre lines being severed. Hope this is useful for your needs. Link: http://www.southern-telecom.com/AFL%20Reliability.pdf On Sat, May 18, 2013 at 5:03 AM, Kyle Creyts wrote: > thanks! > > also amusing: > http://blog.lafayetteprofiber.com/2008/06/nutria-ratsand-fiber.html > > http://news.techeye.net/internet/internet-attacked-by-bears#.TnZXk5rhOv8.reddit > > but I'm looking for something slightly more efficacious than anecdotal. > > off-list replies (and, why not, some of them are really funny) anecdotes > are welcome. > > > On Fri, May 17, 2013 at 8:00 PM, staticsafe wrote: > > > On 5/17/2013 22:16, Kyle Creyts wrote: > > > has anyone come by documents containing some statistics regarding > leading > > > causes for cuts in fiber, power, cable lines? > > > > > > I seem to remember one which included % cuts due to equipment failure, > > > maintenance, weather, rodents, boring, car accidents, etc. > > > > > > but alas, I cannot find it in my archives. > > > > > > > On an amusing note: > > > > > http://blog.level3.com/level-3-network/the-10-most-bizarre-and-annoying-causes-of-fiber-cuts/ > > -- > > staticsafe > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > > Please don't top post - http://goo.gl/YrmAb > > Don't CC me! I'm subscribed to whatever list I just posted on. > > > > > > > -- > Kyle Creyts > > Information Assurance Professional > BSidesDetroit Organizer > -- Ryan Gard From akurenath at hotmail.com Sat May 18 15:13:20 2013 From: akurenath at hotmail.com (akurenath) Date: Sat, 18 May 2013 11:13:20 -0400 Subject: Vpn tunnel Asa 5505 to fortigate 60c Message-ID: Hi nanog, I have a fortigate 60c connecting a vpn tunnel to an asa 5505. I have the connection setup, ?but it will not connect because unfortunately the isp at the fortigate end decided to give us a 192.168.13/24 address. Now what I'd like to know is if there is any way to get this vpn connection to work through a pat connection until the isp resolves this issue?? Thank you for any help. Zane Sent from Samsung mobile From malayter at gmail.com Sat May 18 16:21:49 2013 From: malayter at gmail.com (Ryan Malayter) Date: Sat, 18 May 2013 11:21:49 -0500 Subject: CDN server log In-Reply-To: <5194FC5B.70405@krsek.cz> References: <2CF5AE4B-C05D-4CA7-8A70-C37ED8E496C4@internap.com> <5194FC5B.70405@krsek.cz> Message-ID: <5F5D3302-4F33-4AF6-B077-41F32F527B55@gmail.com> Djamel, If you are looking for a CDN log trace to do academic research work on say, caching algorithms, please be straightforward about your needs and someone (including myself) might be able to help. If your purposes are commercial, asking for free data won't likely get you far. If you're trying to turn the data into money expect to pay someone for it. On May 16, 2013, at 10:33 AM, Michal Krsek wrote: > Hi Djamel, > I'm not sure what you are looking for. > > There is variety of CDN content and popularity is being driven by users and designers. > > If you have CDN that serves pictures, you get most hits on "design pictures", for paid VoD, you get most hits on free trailers. For CatchTV tup you get most hits on new arrivals of popular content. It also depends on geo distribution. Global CDNs get different coverage than regional ones. For live transmissions, you get a lot of content when covering big sports events. > > For adult based content CDN ... you can imagine ... > > Just talking in general, having no permission to provide any log. > > With kind regards > Michal > > > Dne 16.5.2013 15:16, Djamel Sadok napsal(a): >> Hi Pete, >> >> I do not use a CDN I am only interested in analyzing content popularity in >> logs. These could be anonymized. >> >> Djamel >> >> >> >> On Wed, May 15, 2013 at 3:55 PM, Pete Mastin wrote: >> >>> Hi djamel. If I understand your question - you should take a look at what >>> sawmill offers. Many of our clients use this product to analyze our cdn >>> produced logs. >>> >>> http://www.sawmill.net/ >>> >>> >>> >>> Sent from my iPhone >>> >>> On May 15, 2013, at 10:30 AM, "Djamel Sadok" wrote: >>> >>>> Hi, >>>> >>>> Anyone knows of any public CDN server log trace. I am looking for object >>>> popularity, hit rate information, ... >>>> >>>> Thanks, Djamel > > From kenneth.mcrae at dreamhost.com Sat May 18 16:50:14 2013 From: kenneth.mcrae at dreamhost.com (Kenneth McRae) Date: Sat, 18 May 2013 09:50:14 -0700 Subject: Vpn tunnel Asa 5505 to fortigate 60c In-Reply-To: References: Message-ID: What is the public peer address on the ISP end? On May 18, 2013 8:15 AM, "akurenath" wrote: > Hi nanog, > > I have a fortigate 60c connecting a vpn tunnel to an asa 5505. I have the > connection setup, but it will not connect because unfortunately the isp at > the fortigate end decided to give us a 192.168.13/24 address. Now what I'd > like to know is if there is any way to get this vpn connection to work > through a pat connection until the isp resolves this issue? > > Thank you for any help. > > Zane > > > Sent from Samsung mobile From bross at pobox.com Sat May 18 17:03:56 2013 From: bross at pobox.com (Brandon Ross) Date: Sat, 18 May 2013 13:03:56 -0400 (EDT) Subject: Remote Hands Nation-Wide? In-Reply-To: References: Message-ID: We do. Worldwide, in fact. On Fri, 17 May 2013, Aaron C. de Bruyn wrote: > I recall a message a while back about a company that offered remote hands > nation-wide, but my Google-Fu is failing me. > > Any pointers? > > We basically need to find coverage for eastern Washington State and all of > Oregon. > > -A > -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From rodrick.brown at gmail.com Sat May 18 17:31:46 2013 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Sat, 18 May 2013 13:31:46 -0400 Subject: Remote Hands Nation-Wide? In-Reply-To: References: Message-ID: <-7725822910982065392@unknownmsgid> Looking for someone who can do remote hands in the LN3 Savvis data center email me off list with rate and availability. Would essentially need someone to rack/stack do basic cable runs and initial switch/router/server setup. No real technical skills required. Sent from my iPhone On May 18, 2013, at 1:06 PM, Brandon Ross wrote: > We do. > > Worldwide, in fact. > > On Fri, 17 May 2013, Aaron C. de Bruyn wrote: > >> I recall a message a while back about a company that offered remote hands >> nation-wide, but my Google-Fu is failing me. >> >> Any pointers? >> >> We basically need to find coverage for eastern Washington State and all of >> Oregon. >> >> -A > > -- > Brandon Ross Yahoo & AIM: BrandonNRoss > +1-404-635-6667 ICQ: 2269442 > Schedule a meeting: https://doodle.com/bross Skype: brandonross > From streiner at cluebyfour.org Sat May 18 18:00:46 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 18 May 2013 14:00:46 -0400 (EDT) Subject: Remote Hands Nation-Wide? In-Reply-To: References: Message-ID: On Fri, 17 May 2013, Aaron C. de Bruyn wrote: > I recall a message a while back about a company that offered remote hands > nation-wide, but my Google-Fu is failing me. I seem to recall discussion of someone running something like a "remote hands have/need" blog/message board, but my Google-fu is failing me at the moment. It was a good idea, but I don't know if it ever took off. I remember there being sites for coordinating remote hands/volunteer efforts after 9/11, Katrina, and Sandy, but I haven't been able to find one that is more general in nature. jms From mysidia at gmail.com Sat May 18 20:58:53 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 18 May 2013 15:58:53 -0500 Subject: Looking for Netflow analysis package In-Reply-To: <20130517134928.A0F439B8@resin04.mta.everyone.net> References: <20130517134928.A0F439B8@resin04.mta.everyone.net> Message-ID: On 5/17/13, Scott Weeks wrote: > owned resources". So don't. Set up an SSH tunnel over port 80 to > your home server and access your non-paragraph-sized-signature email > account from home. There's a million ways to do things and still > follow corporate rules... The disclaimer requirements seem dumb, but not entirely unreasonable -- we should just tolerate them. As for spam... no good there. I would caution against taking the advise of setting up a SSH tunnel to "follow corporate rules". In some cases, that might be subverting the intended affects of corporate rules. The outgoing SSH session (or any encrypted session or tunnel) to an unapproved non-company resource could still be a policy violation in some organizations; where they don't already have a firewall that identifies SSH protocol traffic regardless of TCP port, it is essentially firewall circumvention. The same goes for other encrypted or obscured remote access protocols such as VPNs, IP traffic tunnels, VNC over port 80. The defeat of e-mail/other network activity usage monitoring, may impact archiving of mail or compliance with banking, (or other) regulations. Since the SSH session is encrypted, the company's super-expensive Data Leak Protection software suite may be unable to analyze the outgoing traffic flow over the network. It _might_ be a harmless SSH session to post to a mailing list; OR it might instead be a covert channel for exfiltrating corporate data. The channel is encrypted... how can you prove the difference? How can the organization prove that its employees aren't siphoning customer data out of the database, to satisfy compliance with privacy laws? In orgs with different priorities, or that haven't addressed certain risks, it might be OK. But there will be organizations where it definitely is not OK, so we should just tolerate the spurious disclaimers. > scot -- -JH From Valdis.Kletnieks at vt.edu Sat May 18 23:56:38 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 18 May 2013 19:56:38 -0400 Subject: Looking for Netflow analysis package In-Reply-To: Your message of "Fri, 17 May 2013 10:02:53 -0700." <0118C59B-99A1-4A16-A08A-90561479BA66@starta.org> References: <20130516151622.A0F49051@resin04.mta.everyone.net> <35076.1368804240@turing-police.cc.vt.edu> <0118C59B-99A1-4A16-A08A-90561479BA66@starta.org> Message-ID: <106470.1368921398@turing-police.cc.vt.edu> On Fri, 17 May 2013 10:02:53 -0700, John Starta said: > Do you believe that Brent wrote the disclaimer attached to his message? > Despite y/our opinions of such disclaimers, legal counsel in some companies > still mandate their automatic attachment on all outbound messages. The only > means of avoiding them is to subscribe to mailing lists from a personal e-mail > account. There's another way. Educate the technology-challenged people who mandated the disclaimer. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From symack at gmail.com Sat May 18 15:39:55 2013 From: symack at gmail.com (Nick Khamis) Date: Sat, 18 May 2013 11:39:55 -0400 Subject: High throughput bgp links using gentoo + stipped kernel Message-ID: Hello Everyone, We are running: Gentoo Server on Dual Core Intel Xeon 3060, 2 Gb Ram Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (rev 03) 2 bgp links from different providers using quagga, iptables etc.... We are transmitting an average of 700Mbps with packet sizes upwards of 900-1000 bytes when the traffic graph begins to flatten. We also start experiencing some crashes at that point, and not have been able to pinpoint that either. I was hoping to get some feedback on what else we can strip from the kernel. If you have a similar setup for a stable platform the .config would be great! Also, what are your thoughts on migrating to OpenBSD and bgpd, not sure if there would be a performance increase, but the security would be even more stronger? Kind Regards, Nick From freimer at freimer.org Sat May 18 17:05:22 2013 From: freimer at freimer.org (Fred Reimer) Date: Sat, 18 May 2013 17:05:22 +0000 Subject: Vpn tunnel Asa 5505 to fortigate 60c In-Reply-To: Message-ID: Almost all firewalls support NAT-T, which allows for using a private IP address on the "outside" of the firewall (which is translated to a routable public IP address before it gets on the Internet). You will need UDP 500 (for IKE) and UDP 4500 (for IPsec NAT-T) open, so no devices between the firewalls can block those ports. I know the ASA supports this, because I have setup customers with "private" IP addresses on their ASAs in certain circumstances. I'm not familiar enough with the Fortinet equipment, but you may need to turn on a NAT-T feature. HTH, Fred Reimer On 5/18/13 11:13 AM, "akurenath" wrote: >Hi nanog, > >I have a fortigate 60c connecting a vpn tunnel to an asa 5505. I have the >connection setup, but it will not connect because unfortunately the isp >at the fortigate end decided to give us a 192.168.13/24 address. Now what >I'd like to know is if there is any way to get this vpn connection to >work through a pat connection until the isp resolves this issue? > >Thank you for any help. > >Zane > > >Sent from Samsung mobile From nikky at mnet.bg Sun May 19 07:21:16 2013 From: nikky at mnet.bg (Nikola Kolev) Date: Sun, 19 May 2013 10:21:16 +0300 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: Message-ID: <8EC20B64-77CF-4BE5-82CF-8BC2131573C6@mnet.bg> Hello Nick, On 18.05.2013, at 18:39, Nick Khamis wrote: > Hello Everyone, > > We are running: > > Gentoo Server on Dual Core Intel Xeon 3060, 2 Gb Ram > Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet > Controller (rev 06) > Ethernet controller: Intel Corporation 82573E Gigabit Ethernet > Controller (rev 03) > > 2 bgp links from different providers using quagga, iptables etc.... > > We are transmitting an average of 700Mbps with packet sizes upwards of > 900-1000 bytes when the traffic graph begins to flatten. We also start > experiencing some crashes at that point, and not have been able to > pinpoint that either. > > I was hoping to get some feedback on what else we can strip from the > kernel. If you have a similar setup for a stable platform the .config > would be great! > > Also, what are your thoughts on migrating to OpenBSD and bgpd, not > sure if there would be a performance increase, but the security would > be even more stronger? > > Kind Regards, > > Nick You might be maxing out your server's PCI bus throughput, so it might be a better idea if you can get Ethernet NICs that are sitting at least on PCIe x8 slots. Leaving that aside, I take it you've configured some sort of CPU/PCI affinity? As for migration to another OS, I find FreeBSD better as a matter of network performance. The last time I checked OpenBSD was either lacking or was in the early stages of multiple cores support. From bill at herrin.us Sun May 19 13:21:21 2013 From: bill at herrin.us (William Herrin) Date: Sun, 19 May 2013 09:21:21 -0400 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: Message-ID: On Sat, May 18, 2013 at 11:39 AM, Nick Khamis wrote: > We are transmitting an average of 700Mbps with packet sizes upwards of > 900-1000 bytes when the traffic graph begins to flatten. We also start > experiencing some crashes at that point, and not have been able to > pinpoint that either. Hi Nick, You're done. You can buy more recent server hardware and get another small bump. You may be able to tweak interrupt rates from the NICs as well, trading latency for throughput. But basically you're done: you've hit the upper bound of what slow-path (not hardware assisted) networking can currently do. Options: 1. Buy equipment with a hardware fast path, such as the higher end Juniper and Cisco routers. 2. Split the load. Run multiple BGP routers and filter some portion of the /8's on each of them. On your IGP, advertise /8's instead of a default. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jlewis at lewis.org Sun May 19 13:36:12 2013 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 19 May 2013 09:36:12 -0400 (EDT) Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: Message-ID: On Sun, 19 May 2013, William Herrin wrote: > On Sat, May 18, 2013 at 11:39 AM, Nick Khamis wrote: >> We are transmitting an average of 700Mbps with packet sizes upwards of >> 900-1000 bytes when the traffic graph begins to flatten. We also start >> experiencing some crashes at that point, and not have been able to >> pinpoint that either. > > Hi Nick, > > You're done. You can buy more recent server hardware and get another > small bump. You may be able to tweak interrupt rates from the NICs as > well, trading latency for throughput. But basically you're done: > you've hit the upper bound of what slow-path (not hardware assisted) > networking can currently do. > > Options: > > 1. Buy equipment with a hardware fast path, such as the higher end > Juniper and Cisco routers. I think you've misinterpreted his numbers. He's using 1gb ethernet interfaces, so that's 700 mbit/s. He didn't mention if he'd done any IP stack tuning, or what sort of crashes he's having...but people have been doing higher bandwith than this on Linux for years. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From andre-nanog at tomt.net Sun May 19 14:01:27 2013 From: andre-nanog at tomt.net (Andre Tomt) Date: Sun, 19 May 2013 16:01:27 +0200 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: Message-ID: <5198DB37.10109@tomt.net> On 18. mai 2013 17:39, Nick Khamis wrote: > Hello Everyone, > > We are running: > > Gentoo Server on Dual Core Intel Xeon 3060, 2 Gb Ram > Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet > Controller (rev 06) > Ethernet controller: Intel Corporation 82573E Gigabit Ethernet > Controller (rev 03) > > 2 bgp links from different providers using quagga, iptables etc.... > > We are transmitting an average of 700Mbps with packet sizes upwards of > 900-1000 bytes when the traffic graph begins to flatten. We also start > experiencing some crashes at that point, and not have been able to > pinpoint that either. > > I was hoping to get some feedback on what else we can strip from the > kernel. If you have a similar setup for a stable platform the .config > would be great! > > Also, what are your thoughts on migrating to OpenBSD and bgpd, not > sure if there would be a performance increase, but the security would > be even more stronger? This is some fairly ancient hardware, so what you can get out if it will be limited. Though gige should not be impossible. The usual tricks are to make sure netfilter is not loaded, especially the conntrack/nat based parts as that will inspect every flow for state information. Either make sure those parts are compiled out or the modules/code never loads. If you have any iptables/netfilter rules, make sure they are 1) stateless 2) properly organized (cant just throw everything into FORWARD and expect it to be performant). You could try setting IRQ affinity so both ports run on the same core, however I'm not sure if that will help much as its still the same cache and distance to memory. On modern NICS you can do tricks like tie rx of port 1 with tx of port 2. Probably not on that generation though. The 82571EB and 82573E is, while old, PCIe hardware, there should not be any PCI bottlenecks, even with you having to bounce off that stone age FSB that old CPU has. Not sure well that generation intel NIC silicon does linerate easily though. But really you should get some newerish hardware with on-cpu PCIe and memory controllers (and preferably QPI). That architectural jump really upped the networking throughput of commodity hardware, probably by orders of magnitude (people were doing 40Gbps routing using standard Linux 5 years ago). Curious about vmstat output during saturation, and kernel version too. IPv4 routing changed significantly recently and IPv6 routing performance also improved somewhat. From symack at gmail.com Sun May 19 14:58:54 2013 From: symack at gmail.com (Nick Khamis) Date: Sun, 19 May 2013 10:58:54 -0400 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: Message-ID: On 5/18/13, Michael McConnell wrote: > Hello Nick, > > Your email is pretty generic, the likelihood of anyone being able to provide > any actual help or advice is pretty low. I suggest you check out Vyatta.org, > its an Open Source router solution that uses Quagga for its underlying BGP > management, and if you desire you can purpose a support package a few grand > a year. > > Cheers, > Mike > > -- > > Michael McConnell > WINK Streaming; > email: michael at winkstreaming.com > phone: +1 312 281-5433 x 7400 > cell: +506 8706-2389 > skype: wink-michael > web: http://winkstreaming.com > > On May 18, 2013, at 9:39 AM, Nick Khamis wrote: > >> Hello Everyone, >> >> We are running: >> >> Gentoo Server on Dual Core Intel Xeon 3060, 2 Gb Ram >> Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet >> Controller (rev 06) >> Ethernet controller: Intel Corporation 82573E Gigabit Ethernet >> Controller (rev 03) >> >> 2 bgp links from different providers using quagga, iptables etc.... >> >> We are transmitting an average of 700Mbps with packet sizes upwards of >> 900-1000 bytes when the traffic graph begins to flatten. We also start >> experiencing some crashes at that point, and not have been able to >> pinpoint that either. >> >> I was hoping to get some feedback on what else we can strip from the >> kernel. If you have a similar setup for a stable platform the .config >> would be great! >> >> Also, what are your thoughts on migrating to OpenBSD and bgpd, not >> sure if there would be a performance increase, but the security would >> be even more stronger? >> >> Kind Regards, >> >> Nick >> > > Hello Michael, I totally understand how my question is generic in nature. I will defiantly take a look at Vyatta, and weigh the effort vs. benefit topic. The purpose of my email is to see how people with similar setups managed to get more out of their system using kernel tweaks or further stripping on their OS. In our case, we are using Gentoo. Nick. From symack at gmail.com Sun May 19 15:25:53 2013 From: symack at gmail.com (Nick Khamis) Date: Sun, 19 May 2013 11:25:53 -0400 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: <8EC20B64-77CF-4BE5-82CF-8BC2131573C6@mnet.bg> References: <8EC20B64-77CF-4BE5-82CF-8BC2131573C6@mnet.bg> Message-ID: On 5/19/13, Nikola Kolev wrote: > You might be maxing out your server's PCI bus throughput, so it might be a > better idea if you can get Ethernet NICs that are sitting at least on PCIe > x8 slots. > > Nikola, thank you so much for your response! It kind of looks that way, and we do have another candidate machine that has a PCIe 3 x8. First thing, I never liked riser card and the candidate IBM x3250 M$ does use them. Not sure how much of a hit I will take for that. Secondly are there any proven intel 4 port cards in PCIe 3 preferably pro 1000. > Leaving that aside, I take it you've configured some sort of CPU/PCI > affinity? For interrupts we disabled CONFIG_HOTPLUG_CPU in the kernel, and assigned interrupts to the less used core using APIC. I am not sure if there is anything more we can do? > As for migration to another OS, I find FreeBSD better as a matter of network > performance. The last time I checked OpenBSD was either lacking or was in > the early stages of multiple cores support. I know I mentioned migration, but gentoo has been really good to us, and we grew really fond of her :). Hope I can tune it further before retiring it as our OS of choice. Nick. From zgiles at gmail.com Sun May 19 15:28:30 2013 From: zgiles at gmail.com (Zachary Giles) Date: Sun, 19 May 2013 11:28:30 -0400 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: Message-ID: I had two Dell R3xx 1U servers with Quad Gige Cards in them and a few small BGP connections for a few year. They were running CentOS 5 + Quagga with a bunch of stuff turned off. Worked extremely well. We also had really small traffic back then. Server hardware has become amazingly fast under-the-covers these days. It certainly still can't match an ASIC designed solution from Cisco etc, but it should be able to push several GB of traffic. In HPC storage applications, for example, we have multiple servers with Quad 40Gig and IB pushing ~40GB of traffic of fairly large blocks. It's not network, but it does demonstrate pushing data into daemon applications and back down to the kernel at high rates. Certainly a kernel routing table with no iptables and a small Quagga daemon in the background can push similar. In other words, get new hardware and design it flow. On Sun, May 19, 2013 at 10:58 AM, Nick Khamis wrote: > On 5/18/13, Michael McConnell wrote: > > Hello Nick, > > > > Your email is pretty generic, the likelihood of anyone being able to > provide > > any actual help or advice is pretty low. I suggest you check out > Vyatta.org, > > its an Open Source router solution that uses Quagga for its underlying > BGP > > management, and if you desire you can purpose a support package a few > grand > > a year. > > > > Cheers, > > Mike > > > > -- > > > > Michael McConnell > > WINK Streaming; > > email: michael at winkstreaming.com > > phone: +1 312 281-5433 x 7400 > > cell: +506 8706-2389 > > skype: wink-michael > > web: http://winkstreaming.com > > > > On May 18, 2013, at 9:39 AM, Nick Khamis wrote: > > > >> Hello Everyone, > >> > >> We are running: > >> > >> Gentoo Server on Dual Core Intel Xeon 3060, 2 Gb Ram > >> Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet > >> Controller (rev 06) > >> Ethernet controller: Intel Corporation 82573E Gigabit Ethernet > >> Controller (rev 03) > >> > >> 2 bgp links from different providers using quagga, iptables etc.... > >> > >> We are transmitting an average of 700Mbps with packet sizes upwards of > >> 900-1000 bytes when the traffic graph begins to flatten. We also start > >> experiencing some crashes at that point, and not have been able to > >> pinpoint that either. > >> > >> I was hoping to get some feedback on what else we can strip from the > >> kernel. If you have a similar setup for a stable platform the .config > >> would be great! > >> > >> Also, what are your thoughts on migrating to OpenBSD and bgpd, not > >> sure if there would be a performance increase, but the security would > >> be even more stronger? > >> > >> Kind Regards, > >> > >> Nick > >> > > > > > > > Hello Michael, > > I totally understand how my question is generic in nature. I will > defiantly take a look at Vyatta, and weigh the effort vs. benefit > topic. The purpose of my email is to see how people with similar > setups managed to get more out of their system using kernel tweaks or > further stripping on their OS. In our case, we are using Gentoo. > > Nick. > > -- Zach Giles zgiles at gmail.com From symack at gmail.com Sun May 19 15:34:14 2013 From: symack at gmail.com (Nick Khamis) Date: Sun, 19 May 2013 11:34:14 -0400 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: Message-ID: > Hi Nick, > > You're done. You can buy more recent server hardware and get another > small bump. You may be able to tweak interrupt rates from the NICs as > well, trading latency for throughput. But basically you're done: > you've hit the upper bound of what slow-path (not hardware assisted) > networking can currently do. > > Options: > > 1. Buy equipment with a hardware fast path, such as the higher end > Juniper and Cisco routers. > > 2. Split the load. Run multiple BGP routers and filter some portion of > the /8's on each of them. On your IGP, advertise /8's instead of a > default. > > Regards, > Bill Herrin > Hey Bill, thanks for your reply!!!! Yeah option 1...... I think we will do whatever it takes to avoid that route. I don't have a good reason for it, it's just preference. Great manufactures/produts.... etc..., we just like the flexibility we get with how things are setup right now. Not to mention extra rack space! Option 2 is exactly what we are looking at. But before that, we are looking at upgrading to a PCIe 3 x8 or x16 as mentioned earlier for that "small bump". If we hit 25% increase in throughout then that would keep the barracudas in suits at bay. But for now, they are really breathing down my back... :) N. From symack at gmail.com Sun May 19 15:48:17 2013 From: symack at gmail.com (Nick Khamis) Date: Sun, 19 May 2013 11:48:17 -0400 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: <5198DA9E.8090700@tomt.net> References: <5198DA9E.8090700@tomt.net> Message-ID: > This is some fairly ancient hardware, so what you can get out if it will > be limited. Though gige should not be impossible. > Agreed!!! > The usual tricks are to make sure netfilter is not loaded, especially > the conntrack/nat based parts as that will inspect every flow for state > information. Either make sure those parts are compiled out or the > modules/code never loads. > > If you have any iptables/netfilter rules, make sure they are 1) > stateless 2) properly organized (cant just throw everything into FORWARD > and expect it to be performant). > We do use a statefull iptables on our router, some forward rules... This is known to be on of our issues, not sure if having a separate iptables box would be the best and only solution for this? > You could try setting IRQ affinity so both ports run on the same core, > however I'm not sure if that will help much as its still the same cache > and distance to memory. On modern NICS you can do tricks like tie rx of > port 1 with tx of port 2. Probably not on that generation though. Those figures include IRQ affinity tweaks at the kernel and APIC level. > > The 82571EB and 82573E is, while old, PCIe hardware, there should not be > any PCI bottlenecks, even with you having to bounce off that stone age > FSB that old CPU has. Not sure well that generation intel NIC silicon > does linerate easily though. > > But really you should get some newerish hardware with on-cpu PCIe and > memory controllers (and preferably QPI). That architectural jump really > upped the networking throughput of commodity hardware, probably by > orders of magnitude (people were doing 40Gbps routing using standard > Linux 5 years ago). Any ideas of the setup??? Maybe as far as naming some chipset, interface? And xserver that is the best candidate. Will google.. :) > Curious about vmstat output during saturation, and kernel version too. > IPv4 routing changed significantly recently and IPv6 routing performance > also improved somewhat. > > Will get that output during peak on monday for you guys. Newest kernel 3.6 or 7... Thank you so much for your insight, Nick. From michael at winkstreaming.com Sun May 19 03:20:47 2013 From: michael at winkstreaming.com (Michael McConnell) Date: Sat, 18 May 2013 21:20:47 -0600 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: Message-ID: Hello Nick, Your email is pretty generic, the likelihood of anyone being able to provide any actual help or advice is pretty low. I suggest you check out Vyatta.org, its an Open Source router solution that uses Quagga for its underlying BGP management, and if you desire you can purpose a support package a few grand a year. Cheers, Mike -- Michael McConnell WINK Streaming; email: michael at winkstreaming.com phone: +1 312 281-5433 x 7400 cell: +506 8706-2389 skype: wink-michael web: http://winkstreaming.com On May 18, 2013, at 9:39 AM, Nick Khamis wrote: > Hello Everyone, > > We are running: > > Gentoo Server on Dual Core Intel Xeon 3060, 2 Gb Ram > Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet > Controller (rev 06) > Ethernet controller: Intel Corporation 82573E Gigabit Ethernet > Controller (rev 03) > > 2 bgp links from different providers using quagga, iptables etc.... > > We are transmitting an average of 700Mbps with packet sizes upwards of > 900-1000 bytes when the traffic graph begins to flatten. We also start > experiencing some crashes at that point, and not have been able to > pinpoint that either. > > I was hoping to get some feedback on what else we can strip from the > kernel. If you have a similar setup for a stable platform the .config > would be great! > > Also, what are your thoughts on migrating to OpenBSD and bgpd, not > sure if there would be a performance increase, but the security would > be even more stronger? > > Kind Regards, > > Nick > From symack at gmail.com Sun May 19 16:19:00 2013 From: symack at gmail.com (Nick Khamis) Date: Sun, 19 May 2013 12:19:00 -0400 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: Message-ID: On 5/19/13, Zachary Giles wrote: > I had two Dell R3xx 1U servers with Quad Gige Cards in them and a few small > BGP connections for a few year. They were running CentOS 5 + Quagga with a > bunch of stuff turned off. Worked extremely well. We also had really small > traffic back then. > > Server hardware has become amazingly fast under-the-covers these days. It > certainly still can't match an ASIC designed solution from Cisco etc, but > it should be able to push several GB of traffic. > In HPC storage applications, for example, we have multiple servers with > Quad 40Gig and IB pushing ~40GB of traffic of fairly large blocks. It's not > network, but it does demonstrate pushing data into daemon applications and > back down to the kernel at high rates. > Certainly a kernel routing table with no iptables and a small Quagga daemon > in the background can push similar. > > In other words, get new hardware and design it flow. What we are having a hard time with right now is finding that "perfect" setup without going the whitebox route. For example the x3250 M4 has one pci-e gen 3 x8 full length (great!), and one gen 2 x4 (Not so good...). The ideal in our case would be a newish xserver with two full length gen 3 x8 or even x16 in a nice 1u for factor humming along and being able to handle up to 64 GT/s of traffic, firewall and NAT rules included. Hope this is not considered noise to an old problem however, any help is greatly appreciated, and will keep everyone posted on the final numbers post upgrade. N. From vgill at vijaygill.com Sun May 19 17:21:37 2013 From: vgill at vijaygill.com (vijay gill) Date: Sun, 19 May 2013 10:21:37 -0700 Subject: Inventory and workflow management systems In-Reply-To: <21ef2c1c0804041416w28aac3d1la30c3ad5e1b91129@mail.gmail.com> References: <21ef2c1c0804041416w28aac3d1la30c3ad5e1b91129@mail.gmail.com> Message-ID: Resurrecting this thread. Anyone? What software solution do people use for inventory management for things like riser/conduit drawdown, fiber inventory, physical topology store, CLR/DLR, x-connect, contracts, port inventory, etc. Any experiences in integrating workflow into those packages for work orders, modeling, drawdown levels, etc. On Fri, Apr 4, 2008 at 2:16 PM, vijay gill wrote: > What software solution do people use for inventory management for things > like riser/conduit drawdown, fiber inventory, physical topology store, > CLR/DLR, x-connect, contracts, port inventory, etc. > Any experiences in integrating workflow into those packages for work > orders, modeling, drawdown levels, etc. > > /vijay > > > > From philfagan at gmail.com Sun May 19 17:34:59 2013 From: philfagan at gmail.com (Phil Fagan) Date: Sun, 19 May 2013 11:34:59 -0600 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: Message-ID: Not noise! On May 19, 2013 10:20 AM, "Nick Khamis" wrote: > On 5/19/13, Zachary Giles wrote: > > I had two Dell R3xx 1U servers with Quad Gige Cards in them and a few > small > > BGP connections for a few year. They were running CentOS 5 + Quagga with > a > > bunch of stuff turned off. Worked extremely well. We also had really > small > > traffic back then. > > > > Server hardware has become amazingly fast under-the-covers these days. It > > certainly still can't match an ASIC designed solution from Cisco etc, but > > it should be able to push several GB of traffic. > > In HPC storage applications, for example, we have multiple servers with > > Quad 40Gig and IB pushing ~40GB of traffic of fairly large blocks. It's > not > > network, but it does demonstrate pushing data into daemon applications > and > > back down to the kernel at high rates. > > Certainly a kernel routing table with no iptables and a small Quagga > daemon > > in the background can push similar. > > > > In other words, get new hardware and design it flow. > > What we are having a hard time with right now is finding that > "perfect" setup without going the whitebox route. For example the > x3250 M4 has one pci-e gen 3 x8 full length (great!), and one gen 2 > x4 (Not so good...). The ideal in our case would be a newish xserver > with two full length gen 3 x8 or even x16 in a nice 1u for factor > humming along and being able to handle up to 64 GT/s of traffic, > firewall and NAT rules included. > > Hope this is not considered noise to an old problem however, any help > is greatly appreciated, and will keep everyone posted on the final > numbers post upgrade. > > N. > > From vgill at vijaygill.com Sun May 19 17:35:12 2013 From: vgill at vijaygill.com (vijay gill) Date: Sun, 19 May 2013 10:35:12 -0700 Subject: ISIS and OSPF together In-Reply-To: References: Message-ID: Randy is correct. In most cases, the two protocols are running co-incident for a while so you can do your table validation and topology mapping and then you turn off OSPF. For vendors that aren't capable of supporting ISIS, this is a feature and not a bug. On Sun, May 12, 2013 at 1:57 AM, Randy Bush wrote: > > One scenario that i can think of when somebody might run the 2 protocols > > ISIS and OSPF together for a brief period is when the admin is migrating > > from one IGP to the other. This, i understand never happens in steady > > state. The only time this can happen is if an AS gets merged into another > > AS (due to mergers and acquisitions) and the two ASes happen to run ISIS > > and OSPF respectively. In such instances, there is a brief period when > two > > protocols might run together before one gets turned off and there is only > > one left. > > no. some ops come to see the light and move their network from ospf to > is-is. see vijay gill's nanog preso > http://nanog.org/meetings/nanog29/presentations/aol-backbone.ram > > From brandon at rd.bbc.co.uk Sun May 19 17:55:48 2013 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 19 May 2013 18:55:48 +0100 (BST) Subject: ISIS and OSPF together Message-ID: <201305191755.SAA02385@sunf10.rd.bbc.co.uk> > Randy is correct But who'd follow his advice, he regularly encourages his competitors to do stupid things. brandon From andre-nanog at tomt.net Sun May 19 20:37:06 2013 From: andre-nanog at tomt.net (Andre Tomt) Date: Sun, 19 May 2013 22:37:06 +0200 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: <5198DA9E.8090700@tomt.net> Message-ID: <519937F2.5050102@tomt.net> (oops, I keep forgetting to send with my nanog identity..) On 19. mai 2013 17:48, Nick Khamis wrote: > We do use a statefull iptables on our router, some forward rules... > This is known to be on of our issues, not sure if having a separate > iptables box would be the best and only solution for this? Ah, statefullness/conntrack .. once you load it you kinda lost already.. Sorry. Any gains from other tunables will likely be dwarfed by the cpu cycles spent by the kernel to track all connections. The more diverse the traffic the more it will hurt. Connection tracking is just inherently non-scalable (and fragile - by the way.) However, the cheapest and simplest is probably just to throw more modern hardware at it. A Xeon E3 (or two for redudancy ;)) is quite cheap.. The long term, scalable solution is a deeper network like you hinted at, with statefullness - if really needed at all - pushed as close to your edge and as far away from your border as possible. But.. More boxes, more to manage, more power, more stuff that can fail, more redudancies needed.. adds up. Then again if you are close to gig actual traffic already, you might want to at least think about future scalability.. > Any ideas of the setup??? Maybe as far as naming some chipset, interface? > And xserver that is the best candidate. Will google.. :) The big shift to integrated (and fast) I/O happened around 2008 IIRC, anything introduced after that is usually quite efficient at moving packets around, at least if Intel based. Even desktop i3/i5/i7 platforms can do 10gig as long as you make sure you put the network chips/cards on the cpu pcie controllers lanes. With anything new its hard to go wrong. xserver?? xserve? That is quite old.. >> Curious about vmstat output during saturation, and kernel version too. >> IPv4 routing changed significantly recently and IPv6 routing performance >> also improved somewhat. > > Will get that output during peak on monday for you guys. Newest kernel > 3.6 or 7... Good. That is at least fairly recent and has most of the more modern networking stuff (and better defaults) From mpalmer at hezmatt.org Sun May 19 21:31:59 2013 From: mpalmer at hezmatt.org (Matt Palmer) Date: Mon, 20 May 2013 07:31:59 +1000 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: <5198DA9E.8090700@tomt.net> Message-ID: <20130519213159.GY26847@hezmatt.org> On Sun, May 19, 2013 at 11:48:17AM -0400, Nick Khamis wrote: > We do use a statefull iptables on our router, some forward rules... > This is known to be on of our issues, not sure if having a separate > iptables box would be the best and only solution for this? I don't know about "only", but it'd have to come close to "best". iptables (and stateful firewalling in general) is a pretty significant CPU and memory sink. Definitely get rid of any stateful rules, preferably *all* the rules, and apply them at a separate location. We've always had BGP routing separated from firewalling, but we're currently migrating from one-giant-core-firewall to lots-of-little-firewalls because our firewalls are starting to cry a little. Nice thing is that horizontally scaling firewalls is easy -- just whack 'em on each subnet instead of running everything together. Core routing is a little harder to scale out (although as has been described already, by no means impossible). The important thing is to remove *anything* from your core routing boxes that doesn't *absolutely* have to be there -- and stateful firewall rules are *extremely* high on that list. - Matt -- When the revolution comes, they won't be able to FIND the wall. -- Brian Kantor, in the Monastery From cdaniel at nurve.com.au Sun May 19 22:40:16 2013 From: cdaniel at nurve.com.au (Cameron Daniel) Date: Mon, 20 May 2013 08:40:16 +1000 Subject: Looking for Netflow analysis package In-Reply-To: <076E4598-1ADD-4E2D-9A17-47E48D2F720C@interworx.nl> References: <20130516151622.A0F49051@resin04.mta.everyone.net> <076E4598-1ADD-4E2D-9A17-47E48D2F720C@interworx.nl> Message-ID: <9279ebd77173fce5359bbcab3df8d0d9@nurve.com.au> On 2013-05-17 8:11 pm, Tim Vollebregt wrote: > Is anyone using an open source solution to process netflow v9 captures? > I'm waiting for SiLK v3 for some time now, which is currently only > available for TLA's and Universities. > > Currently looking into nfdump. To drag this back on topic, yes I'm currently using nfcap/nfdump to capture and parse Netflow v9. It's not as tidy as I'd like but it does the job. If you want something you can just point and shoot, nfsen ties those two tools together into one config file. > Tim From ben at meh.net.nz Sun May 19 23:23:14 2013 From: ben at meh.net.nz (Ben) Date: Mon, 20 May 2013 11:23:14 +1200 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: Message-ID: <20130519232314.GA2519@pearl.meh.net.nz> On Sat, May 18, 2013 at 11:39:55AM -0400, Nick Khamis wrote: > Hello Everyone, > > We are running: > > Gentoo Server on Dual Core Intel Xeon 3060, 2 Gb Ram > Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet > Controller (rev 06) > Ethernet controller: Intel Corporation 82573E Gigabit Ethernet > Controller (rev 03) > > 2 bgp links from different providers using quagga, iptables etc.... > > We are transmitting an average of 700Mbps with packet sizes upwards of > 900-1000 bytes when the traffic graph begins to flatten. We also start > experiencing some crashes at that point, and not have been able to > pinpoint that either. > > I was hoping to get some feedback on what else we can strip from the > kernel. If you have a similar setup for a stable platform the .config > would be great! > > Also, what are your thoughts on migrating to OpenBSD and bgpd, not > sure if there would be a performance increase, but the security would > be even more stronger? That hardware should be fine to do two gig ports upstream, with another two to go to your network? I'd check with "vmstat 1" to see what your interrupt rate is like, if it's above 40k/sec I'd check coalescing settings. I also prefer OpenBSD/OpenBGP myself. It's a simpler configuration, with less things to "fix". With Linux you have to disable reverse path filtering, screw around with iptables to do bypass on stateful filtering. Then Quagga itself can be buggy. (my original reason for shifting away from Linux was that Quagga didn't fix enough of Zebra's bugs.. although that was many years ago, things may have improved a little by then, but ime significantly buggy software tends to stay buggy even with fixing) With regards to security of OpenBSD versus Linux, you shouldn't be exposing any services to the world with either. And it's more stability/configuration that would push me to OpenBSD rather than performance. And with regards to crashing I'd try and figure out what was happening there quickly before making radical changes. Is it running out of memory, is Quagga dying? Is there a default route that works when Quagga crashes? One issue I had was I found Quagga crashing leaving a whole lot of routes lingering in the table, and I had a script that'd go through and purge them. I'm also a bit confused about your dual upstreams with two ethernet interfaces total, are they both sharing one pipe, or are there some Broadcom or such ethernet interfaces too. I've found Broadcom chipsets can be a bit problematic, and the only stability issue I've ever had with OpenBSD is a Broadcom interface wedging for minutes under DDOS attack, which was gigabit'ish speed DDOS with older hardware than you. oh, to check coalescing settings under linux use: "ethtool -c eth0; ethtool -c eth1" Ben. From ben at meh.net.nz Sun May 19 23:27:57 2013 From: ben at meh.net.nz (Ben) Date: Mon, 20 May 2013 11:27:57 +1200 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: <5198DA9E.8090700@tomt.net> Message-ID: <20130519232757.GB2519@pearl.meh.net.nz> On Sun, May 19, 2013 at 11:48:17AM -0400, Nick Khamis wrote: > We do use a statefull iptables on our router, some forward rules... > This is known to be on of our issues, not sure if having a separate > iptables box would be the best and only solution for this? Do you actually need stateful filtering? A lot of people seem to think that it's important, when really they're accomplishing little from it, you can block ports etc without it. And the idea of protecting hosts from strange traffic is only really significant if the hosts have very outdated TCP/IP stacks etc. And it breaks things like having multiple routers. There's an obscure NOTRACK rule you can use to cut down the number of state entries, or remote state tracking for hosts that don't need it. http://serverfault.com/questions/234560/how-to-turn-iptables-stateless although googling for NOTRACK should find other things too. Ben. From ben at meh.net.nz Sun May 19 23:32:31 2013 From: ben at meh.net.nz (Ben) Date: Mon, 20 May 2013 11:32:31 +1200 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: <5198DA9E.8090700@tomt.net> Message-ID: <20130519233231.GC2519@pearl.meh.net.nz> On Sun, May 19, 2013 at 11:48:17AM -0400, Nick Khamis wrote: > > But really you should get some newerish hardware with on-cpu PCIe and > > memory controllers (and preferably QPI). That architectural jump really > > upped the networking throughput of commodity hardware, probably by > > orders of magnitude (people were doing 40Gbps routing using standard > > Linux 5 years ago). > Any ideas of the setup??? Maybe as far as naming some chipset, interface? > And xserver that is the best candidate. Will google.. :) Base model e5 CPU is generally considered adequate, and has direct link between cache and PCI bypassing memory. http://www.intel.com/content/www/us/en/io/data-direct-i-o-faq.html Motherboard is likely to have i350 chipset for ethernet. http://www.intel.com/content/www/us/en/ethernet-controllers/ethernet-i350-server-adapter-brief.html Ben. From sethm at rollernet.us Sun May 19 23:42:23 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 19 May 2013 16:42:23 -0700 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: <20130519232757.GB2519@pearl.meh.net.nz> References: <5198DA9E.8090700@tomt.net> <20130519232757.GB2519@pearl.meh.net.nz> Message-ID: <5199635F.1050606@rollernet.us> On 5/19/13 4:27 PM, Ben wrote: > Do you actually need stateful filtering? A lot of people seem to think > that it's important, when really they're accomplishing little from it, > you can block ports etc without it. I believe PCI compliance requires it, other things like it probably do too. ~Seth From tvhawaii at shaka.com Sun May 19 23:58:22 2013 From: tvhawaii at shaka.com (Michael Painter) Date: Sun, 19 May 2013 13:58:22 -1000 Subject: What hath god wrought? Message-ID: http://arstechnica.com/security/2013/05/ddos-for-hire-service-works-with-blessing-of-fbi-operator-says/ From j at 2600hz.com Mon May 20 00:14:07 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Mon, 20 May 2013 00:14:07 +0000 Subject: What hath god wrought? In-Reply-To: References: Message-ID: Like the comment below the article says, that line about turning off recursive DNS is pretty lame. Tantamount to saying "if you don't want me coming in your house you shouldn't have used wooden doors n00b!". It's still breaking and entering. Call me crazy but I tend to think every service has a Backdoor these days. It's not surprising to see one for a Ddos service. In other news, the sky is still blue. Thanks for sharing the article though! Was a fun read. Cheers, Joshua Sent from my iPhone On May 19, 2013, at 4:59 PM, "Michael Painter" wrote: > http://arstechnica.com/security/2013/05/ddos-for-hire-service-works-with-blessing-of-fbi-operator-says/ > From Valdis.Kletnieks at vt.edu Mon May 20 00:32:55 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 19 May 2013 20:32:55 -0400 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: Your message of "Sun, 19 May 2013 16:42:23 -0700." <5199635F.1050606@rollernet.us> References: <5198DA9E.8090700@tomt.net> <20130519232757.GB2519@pearl.meh.net.nz> <5199635F.1050606@rollernet.us> Message-ID: <159509.1369009975@turing-police.cc.vt.edu> On Sun, 19 May 2013 16:42:23 -0700, Seth Mattinen said: > On 5/19/13 4:27 PM, Ben wrote: > > Do you actually need stateful filtering? A lot of people seem to think > > that it's important, when really they're accomplishing little from it, > > you can block ports etc without it. > > > I believe PCI compliance requires it, other things like it probably do too. It's the rare ISP who's border routers are in-scope for PCI compliance. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bill at herrin.us Mon May 20 00:50:13 2013 From: bill at herrin.us (William Herrin) Date: Sun, 19 May 2013 20:50:13 -0400 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: Message-ID: On Sun, May 19, 2013 at 11:34 AM, Nick Khamis wrote: > Hey Bill, thanks for your reply!!!! Yeah option 1...... I think we > will do whatever it takes to avoid that route. I don't have a good > reason for it, it's just preference. Option 2 is exactly what > we are looking at. Hi Nick, You might get enough of a bump from something like an HP DL380p gen8 to saturate your gig-e. I wouldn't bank on stably going any higher than that. And as someone else mentioned, definitely lose conntrack and stateful firewalling. If you need 'em, move 'em to interior boxes that aren't dealing with your main Internet pipe. If you're up for a challenge there are specialty NIC cards like the Endace DAG. They're usually used for packet capture but in principle they have the right kind of hardware fast path (e.g. TCAMs) built in to accomplish what you want to do. Heck of a challenge though. I haven't heard of anybody putting together a white-box fast path router before. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From andre-nanog at tomt.net Mon May 20 01:01:25 2013 From: andre-nanog at tomt.net (Andre Tomt) Date: Mon, 20 May 2013 03:01:25 +0200 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: <20130519232314.GA2519@pearl.meh.net.nz> References: <20130519232314.GA2519@pearl.meh.net.nz> Message-ID: <519975E5.3080108@tomt.net> Minor nitpicking I know.. On 20. mai 2013 01:23, Ben wrote: > With Linux you have to disable reverse path filtering, screw around with iptables > to do bypass on stateful filtering. You dont have to "screw around" with iptables. The kernel wont load the conntrack modules/code unless you actually try to load stateful rulesets*. rp filtering on by default I'd also argue is the better default setting, for the 99% of other usecases :-P With quagga I would tend to agree - but as you I have not used it ages and things do change for the better over time -- occasionally. * you CAN configure your kernel to always load it, but that is silly. From aj at jonesy.com.au Mon May 20 01:02:17 2013 From: aj at jonesy.com.au (Andrew Jones) Date: Mon, 20 May 2013 11:02:17 +1000 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: <8EC20B64-77CF-4BE5-82CF-8BC2131573C6@mnet.bg> References: <8EC20B64-77CF-4BE5-82CF-8BC2131573C6@mnet.bg> Message-ID: <2d2fe94d32c4536cc2033699c740119e@jonesy.com.au> > As for migration to another OS, I find FreeBSD better as a matter of > network performance. The last time I checked OpenBSD was either > lacking or was in the early stages of multiple cores support. If you do decide to go the FreeBSD route (you can run openbgpd on FreeBSD if you like), check out the POLLING option on ethernet NICs, it cuts down on the number of interrupts and can increase performance, particularly when dealing with smaller packets. From morrowc.lists at gmail.com Mon May 20 02:04:44 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 19 May 2013 22:04:44 -0400 Subject: Inventory and workflow management systems In-Reply-To: References: <21ef2c1c0804041416w28aac3d1la30c3ad5e1b91129@mail.gmail.com> Message-ID: On Sun, May 19, 2013 at 1:21 PM, vijay gill wrote: > Resurrecting this thread. Anyone? > What software solution do people use for inventory management for things > like riser/conduit drawdown, fiber inventory, physical topology store, > CLR/DLR, x-connect, contracts, port inventory, etc. > Any experiences in integrating workflow into those packages for work > orders, modeling, drawdown levels, etc. isn't it odd/lame that in many cases the answer to this is 'build your own' ? From laurent at guerby.net Mon May 20 08:35:20 2013 From: laurent at guerby.net (Laurent GUERBY) Date: Mon, 20 May 2013 10:35:20 +0200 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: <20130519232314.GA2519@pearl.meh.net.nz> References: <20130519232314.GA2519@pearl.meh.net.nz> Message-ID: <1369038920.31084.466.camel@pc2> On Mon, 2013-05-20 at 11:23 +1200, Ben wrote: > With regards to security of OpenBSD versus Linux, you shouldn't be exposing any > services to the world with either. And it's more stability/configuration that would > push me to OpenBSD rather than performance. > > And with regards to crashing I'd try and figure out what was happening there quickly > before making radical changes. Is it running out of memory, is Quagga dying? Is > there a default route that works when Quagga crashes? One issue I had was I found > Quagga crashing leaving a whole lot of routes lingering in the table, and I had a > script that'd go through and purge them. Hi, We've been running a small AS with BIRD on Linux(debian) without any issue in two years of production on two software routers so far: http://bird.network.cz/ It uses less than 100MB of RAM per IPv4 DFZ, we run around 100 BGP sessions in 350M of RAM (process virtual). Looking glass developper by our members: http://lg.tetaneutral.net/prefix_bgpmap/gw+h3/ipv4?q=meh.net.nz http://lg.tetaneutral.net/summary/gw+h3/ipv4 Sincerely, Laurent http://tetaneutral.net http://as197422.peeringdb.com From laurent at guerby.net Mon May 20 08:46:53 2013 From: laurent at guerby.net (Laurent GUERBY) Date: Mon, 20 May 2013 10:46:53 +0200 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: <1369038920.31084.466.camel@pc2> References: <20130519232314.GA2519@pearl.meh.net.nz> <1369038920.31084.466.camel@pc2> Message-ID: <1369039613.31084.467.camel@pc2> On Mon, 2013-05-20 at 10:35 +0200, Laurent GUERBY wrote: > On Mon, 2013-05-20 at 11:23 +1200, Ben wrote: > > With regards to security of OpenBSD versus Linux, you shouldn't be exposing any > > services to the world with either. And it's more stability/configuration that would > > push me to OpenBSD rather than performance. > > > > And with regards to crashing I'd try and figure out what was happening there quickly > > before making radical changes. Is it running out of memory, is Quagga dying? Is > > there a default route that works when Quagga crashes? One issue I had was I found > > Quagga crashing leaving a whole lot of routes lingering in the table, and I had a > > script that'd go through and purge them. > > Hi, > > We've been running a small AS with BIRD on Linux(debian) without any > issue in two years of production on two software routers so far: > > http://bird.network.cz/ I forgot to mention that there is now a paying support programme in case you need it: http://bird.network.cz/?support Laurent From oscar.vives at gmail.com Mon May 20 09:14:55 2013 From: oscar.vives at gmail.com (<"tei''>>) Date: Mon, 20 May 2013 11:14:55 +0200 Subject: What hath god wrought? In-Reply-To: References: Message-ID: On 20 May 2013 01:58, Michael Painter wrote: > http://arstechnica.com/security/2013/05/ddos-for-hire-service-works-with-blessing-of-fbi-operator-says/ > More on the same topic. http://krebsonsecurity.com/2013/05/ragebooter-legit-ddos-service-or-fed-backdoor/#more-19475 Maybe the FBI use this to commit crimes in USA using a foreign company as proxy so nothing dirty show on the books. That way the FBI can avoid respecting USA laws. -- -- ?in del ?ensaje. From rinse.kloek at isp.solcon.nl Mon May 20 09:21:22 2013 From: rinse.kloek at isp.solcon.nl (Rinse Kloek) Date: Mon, 20 May 2013 11:21:22 +0200 Subject: Looking for Netflow analysis package In-Reply-To: <9279ebd77173fce5359bbcab3df8d0d9@nurve.com.au> References: <20130516151622.A0F49051@resin04.mta.everyone.net> <076E4598-1ADD-4E2D-9A17-47E48D2F720C@interworx.nl> <9279ebd77173fce5359bbcab3df8d0d9@nurve.com.au> Message-ID: <5199EB12.6060303@isp.solcon.nl> Op 20-5-2013 0:40, Cameron Daniel schreef: > On 2013-05-17 8:11 pm, Tim Vollebregt wrote: >> Is anyone using an open source solution to process netflow v9 captures? >> I'm waiting for SiLK v3 for some time now, which is currently only >> available for TLA's and Universities. >> >> Currently looking into nfdump. > > To drag this back on topic, yes I'm currently using nfcap/nfdump to > capture and parse Netflow v9. It's not as tidy as I'd like but it does > the job. > > If you want something you can just point and shoot, nfsen ties those > two tools together into one config file. > >> Tim > > Not only for netflow analysis, but also a DDOS detection tool: I am testing Andrisoft Wanguard this month. Very nice webinterface and has even possibility to do BGP blackholing. RInse From streiner at cluebyfour.org Mon May 20 13:53:56 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 20 May 2013 09:53:56 -0400 (EDT) Subject: Inventory and workflow management systems In-Reply-To: References: <21ef2c1c0804041416w28aac3d1la30c3ad5e1b91129@mail.gmail.com> Message-ID: On Sun, 19 May 2013, Christopher Morrow wrote: > On Sun, May 19, 2013 at 1:21 PM, vijay gill wrote: >> Resurrecting this thread. Anyone? >> What software solution do people use for inventory management for things >> like riser/conduit drawdown, fiber inventory, physical topology store, >> CLR/DLR, x-connect, contracts, port inventory, etc. >> Any experiences in integrating workflow into those packages for work >> orders, modeling, drawdown levels, etc. > > isn't it odd/lame that in many cases the answer to this is 'build your own' ? I remember looking several years ago at a commercial fiber plant management application called Mapcom. It looked pretty good, but it was pricey, and no one wanted to spend the money on it. So... fast-forward to 2013.... and we're still using spreadsheets :( I haven't looked lately to see what's out there, but I'd imagine there *has* to be something. I can understand why many telcos ended up building their own systems, because many of them use(d) different or home-grown provisioning/billing/plant management/trouble ticketing systems, and different back-end systems in general, making a one-size-fits-all solution tough to do. jms From morrowc.lists at gmail.com Mon May 20 14:05:09 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 20 May 2013 10:05:09 -0400 Subject: Inventory and workflow management systems In-Reply-To: References: <21ef2c1c0804041416w28aac3d1la30c3ad5e1b91129@mail.gmail.com> Message-ID: On Mon, May 20, 2013 at 9:53 AM, Justin M. Streiner wrote: > > I haven't looked lately to see what's out there, but I'd imagine there *has* > to be something. I bet this is a market/cost thing... there are ~100 people who want this? it's going to take a few million in SWE resources to build, and probably recovery of that expense is going to be difficult :( > I can understand why many telcos ended up building their own systems, > because many of them use(d) different or home-grown > provisioning/billing/plant management/trouble ticketing systems, and > different back-end systems in general, making a one-size-fits-all solution > tough to do. this MOSTLY gets to the ins/outs formats, right? 'billing system at $TELCO requires CSV output' (or something) and telco folk don't always like to think about 'standards'. From streiner at cluebyfour.org Mon May 20 15:37:51 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 20 May 2013 11:37:51 -0400 (EDT) Subject: Inventory and workflow management systems In-Reply-To: References: <21ef2c1c0804041416w28aac3d1la30c3ad5e1b91129@mail.gmail.com> Message-ID: On Mon, 20 May 2013, Christopher Morrow wrote: >> I haven't looked lately to see what's out there, but I'd imagine there *has* >> to be something. > > I bet this is a market/cost thing... there are ~100 people who want > this? it's going to take a few million in SWE resources to build, and > probably recovery of that expense is going to be difficult :( True, and would explain why the systems I've seen tend to be very expensive. I have taken a look at netdot from UOregon, and it looks like it has lots of nice features and an active development community. The main thing there is I need to really sit down and see how painful modifying the default DB schema will be to capture some of the fiber plant data I need, and preventing that all from getting blown away by the next cycle of software upgrades. Tying it into some other back-end systems we already have is another challenge that I really haven't had time to dig into yet. >> I can understand why many telcos ended up building their own systems, >> because many of them use(d) different or home-grown >> provisioning/billing/plant management/trouble ticketing systems, and >> different back-end systems in general, making a one-size-fits-all solution >> tough to do. > > this MOSTLY gets to the ins/outs formats, right? 'billing system at > $TELCO requires CSV output' (or something) and telco folk don't always > like to think about 'standards'. That, and there can belots of general compatibility issues. Something like: The provisioning system is running on an old VAX mainframe, and $PROGRAM expects CSV with CR-LF, rather than just CR, but the billing system is built on a DB2 database on an IBM mainframe and doesn't know how to output the data in an acceptable format. A lot of it is probably centered around software engineering/DBA tasks, often requiring people with lots of institutional/legacy knowledge to get the appropriate pieces talking together correctly. In some cases, those people are no longer around, and consultants with the right skills (and often a pretty hefty hourly rate) need to be brought in. I would imagine that's why some of the telcos that went on acquision binges during the dot-com boom (coughcoughworldcom ;) ) never fully integrated the back-end systems of those acquired telcos into their own, even though it does/did make like more painful for their customers and their own ops people. Example: "Oh wait... that's an MFS circuit. I need to get into a different system to look at that..." jms From brandon.galbraith at gmail.com Mon May 20 18:37:01 2013 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 20 May 2013 13:37:01 -0500 Subject: Remote Hands Nation-Wide? In-Reply-To: References: Message-ID: http://nanog.cluepon.net/index.php/Hands ? From morrowc.lists at gmail.com Mon May 20 18:47:01 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 20 May 2013 14:47:01 -0400 Subject: Remote Hands Nation-Wide? In-Reply-To: References: Message-ID: there's also a mailing-list Warren Kumari setup ... there are folk in the DC area (myself and warren) who have on occasion helped out with these sorts of things. http://www.ne-where.com/cgi-bin/mailman/listinfo/ne-where I think is the thing in question... On Mon, May 20, 2013 at 2:37 PM, Brandon Galbraith wrote: > http://nanog.cluepon.net/index.php/Hands > > From listas at esds.com.br Mon May 20 18:51:22 2013 From: listas at esds.com.br (Eduardo Schoedler) Date: Mon, 20 May 2013 15:51:22 -0300 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: <2d2fe94d32c4536cc2033699c740119e@jonesy.com.au> References: <8EC20B64-77CF-4BE5-82CF-8BC2131573C6@mnet.bg> <2d2fe94d32c4536cc2033699c740119e@jonesy.com.au> Message-ID: 2013/5/19 Andrew Jones > As for migration to another OS, I find FreeBSD better as a matter of >> network performance. The last time I checked OpenBSD was either >> lacking or was in the early stages of multiple cores support. >> > > If you do decide to go the FreeBSD route (you can run openbgpd on FreeBSD > if you like), check out the POLLING option on ethernet NICs, it cuts down > on the number of interrupts and can increase performance, particularly when > dealing with smaller packets. > Polling on FreeBSD in modern NICs is discouraged. -- Eduardo Schoedler From charles-lists at knownelement.com Mon May 20 18:58:49 2013 From: charles-lists at knownelement.com (Charles Wyble) Date: Mon, 20 May 2013 13:58:49 -0500 Subject: What hath god wrought? In-Reply-To: References: Message-ID: No proxy needed. No need to hide. While working for a very large hosting company, I once observed DHS hammering an occupy related website. No attempt to hide the source ip or anything. What are you going to do? Sue them? If they wish to take a site offline, they will ddos it or simply seize the domain under the national security banner. "<<"tei''>>>" wrote: >On 20 May 2013 01:58, Michael Painter wrote: >> >http://arstechnica.com/security/2013/05/ddos-for-hire-service-works-with-blessing-of-fbi-operator-says/ >> > >More on the same topic. >http://krebsonsecurity.com/2013/05/ragebooter-legit-ddos-service-or-fed-backdoor/#more-19475 > >Maybe the FBI use this to commit crimes in USA using a foreign company >as proxy so nothing dirty show on the books. That way the FBI can >avoid respecting USA laws. > > > > >-- >-- >?in del ?ensaje. -- Charles Wyble charles at knownelement.com / 818 280 7059 CTO Free Network Foundation (www.thefnf.org) From eyeronic.design at gmail.com Mon May 20 19:03:17 2013 From: eyeronic.design at gmail.com (Mike Hale) Date: Mon, 20 May 2013 12:03:17 -0700 Subject: What hath god wrought? In-Reply-To: References: Message-ID: "Sue them?" Uhm...yes? That's why we have courts that we can sue federal agencies in. On Mon, May 20, 2013 at 11:58 AM, Charles Wyble wrote: > No proxy needed. No need to hide. > > While working for a very large hosting company, I once observed DHS hammering an occupy related website. No attempt to hide the source ip or anything. > > What are you going to do? Sue them? If they wish to take a site offline, they will ddos it or simply seize the domain under the national security banner. > > > > "<<"tei''>>>" wrote: > >>On 20 May 2013 01:58, Michael Painter wrote: >>> >>http://arstechnica.com/security/2013/05/ddos-for-hire-service-works-with-blessing-of-fbi-operator-says/ >>> >> >>More on the same topic. >>http://krebsonsecurity.com/2013/05/ragebooter-legit-ddos-service-or-fed-backdoor/#more-19475 >> >>Maybe the FBI use this to commit crimes in USA using a foreign company >>as proxy so nothing dirty show on the books. That way the FBI can >>avoid respecting USA laws. >> >> >> >> >>-- >>-- >>?in del ?ensaje. > > -- > Charles Wyble > charles at knownelement.com / 818 280 7059 > CTO Free Network Foundation (www.thefnf.org) -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From charles-lists at knownelement.com Mon May 20 19:13:59 2013 From: charles-lists at knownelement.com (Charles Wyble) Date: Mon, 20 May 2013 14:13:59 -0500 Subject: What hath god wrought? In-Reply-To: References: Message-ID: <851d0ba9-16ef-499d-a7e9-6ad2b4570d22@email.android.com> Yes. I'm aware of that. It would be futile in most cases, which is a huge problem in and of itself, as that's really the only recourse. I mean they were using a shared hosting plan. Not exactly deep pocketed. My point is that the abuse of power is blatant and they are unafraid of any kind of retaliation. They don't need to hide. Mike Hale wrote: >"Sue them?" >Uhm...yes? That's why we have courts that we can sue federal agencies >in. > >On Mon, May 20, 2013 at 11:58 AM, Charles Wyble > wrote: >> No proxy needed. No need to hide. >> >> While working for a very large hosting company, I once observed DHS >hammering an occupy related website. No attempt to hide the source ip >or anything. >> >> What are you going to do? Sue them? If they wish to take a site >offline, they will ddos it or simply seize the domain under the >national security banner. >> >> >> >> "<<"tei''>>>" wrote: >> >>>On 20 May 2013 01:58, Michael Painter wrote: >>>> >>>http://arstechnica.com/security/2013/05/ddos-for-hire-service-works-with-blessing-of-fbi-operator-says/ >>>> >>> >>>More on the same topic. >>>http://krebsonsecurity.com/2013/05/ragebooter-legit-ddos-service-or-fed-backdoor/#more-19475 >>> >>>Maybe the FBI use this to commit crimes in USA using a foreign >company >>>as proxy so nothing dirty show on the books. That way the FBI can >>>avoid respecting USA laws. >>> >>> >>> >>> >>>-- >>>-- >>>?in del ?ensaje. >> >> -- >> Charles Wyble >> charles at knownelement.com / 818 280 7059 >> CTO Free Network Foundation (www.thefnf.org) > > > >-- >09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 -- Charles Wyble charles at knownelement.com / 818 280 7059 CTO Free Network Foundation (www.thefnf.org) From eyeronic.design at gmail.com Mon May 20 19:29:55 2013 From: eyeronic.design at gmail.com (Mike Hale) Date: Mon, 20 May 2013 12:29:55 -0700 Subject: What hath god wrought? In-Reply-To: <851d0ba9-16ef-499d-a7e9-6ad2b4570d22@email.android.com> References: <851d0ba9-16ef-499d-a7e9-6ad2b4570d22@email.android.com> Message-ID: Would it be futile though? I mean...DHS running a DOS against an American organization is the kind of stuff that makes Constitutional lawyers salivate. I'm not trying to call you out, btw. I'm genuinely curious why the hosting company itself didn't file suit. You've got a US Government agency abusing your resources and acting in a blatantly illegal manner. That's the kind of stuff that results in letters of resignation when publicized. On Mon, May 20, 2013 at 12:13 PM, Charles Wyble wrote: > Yes. I'm aware of that. It would be futile in most cases, which is a huge problem in and of itself, as that's really the only recourse. > > I mean they were using a shared hosting plan. Not exactly deep pocketed. > > My point is that the abuse of power is blatant and they are unafraid of any kind of retaliation. They don't need to hide. > > Mike Hale wrote: > >>"Sue them?" >>Uhm...yes? That's why we have courts that we can sue federal agencies >>in. >> >>On Mon, May 20, 2013 at 11:58 AM, Charles Wyble >> wrote: >>> No proxy needed. No need to hide. >>> >>> While working for a very large hosting company, I once observed DHS >>hammering an occupy related website. No attempt to hide the source ip >>or anything. >>> >>> What are you going to do? Sue them? If they wish to take a site >>offline, they will ddos it or simply seize the domain under the >>national security banner. >>> >>> >>> >>> "<<"tei''>>>" wrote: >>> >>>>On 20 May 2013 01:58, Michael Painter wrote: >>>>> >>>>http://arstechnica.com/security/2013/05/ddos-for-hire-service-works-with-blessing-of-fbi-operator-says/ >>>>> >>>> >>>>More on the same topic. >>>>http://krebsonsecurity.com/2013/05/ragebooter-legit-ddos-service-or-fed-backdoor/#more-19475 >>>> >>>>Maybe the FBI use this to commit crimes in USA using a foreign >>company >>>>as proxy so nothing dirty show on the books. That way the FBI can >>>>avoid respecting USA laws. >>>> >>>> >>>> >>>> >>>>-- >>>>-- >>>>?in del ?ensaje. >>> >>> -- >>> Charles Wyble >>> charles at knownelement.com / 818 280 7059 >>> CTO Free Network Foundation (www.thefnf.org) >> >> >> >>-- >>09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > > -- > Charles Wyble > charles at knownelement.com / 818 280 7059 > CTO Free Network Foundation (www.thefnf.org) -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From jlsparks at gmail.com Mon May 20 21:59:40 2013 From: jlsparks at gmail.com (Jason L. Sparks) Date: Mon, 20 May 2013 17:59:40 -0400 Subject: What hath god wrought? In-Reply-To: References: <851d0ba9-16ef-499d-a7e9-6ad2b4570d22@email.android.com> Message-ID: "No attempt to hide the source IP" "I mean, they were using a shared hosting plan" What makes you certain it was DHS? Genuinely curious, because this is a hell of a claim. -- Jason On Mon, May 20, 2013 at 3:29 PM, Mike Hale wrote: > Would it be futile though? I mean...DHS running a DOS against an > American organization is the kind of stuff that makes Constitutional > lawyers salivate. > > I'm not trying to call you out, btw. I'm genuinely curious why the > hosting company itself didn't file suit. You've got a US Government > agency abusing your resources and acting in a blatantly illegal > manner. That's the kind of stuff that results in letters of > resignation when publicized. > > On Mon, May 20, 2013 at 12:13 PM, Charles Wyble > wrote: > > Yes. I'm aware of that. It would be futile in most cases, which is a > huge problem in and of itself, as that's really the only recourse. > > > > I mean they were using a shared hosting plan. Not exactly deep pocketed. > > > > My point is that the abuse of power is blatant and they are unafraid of > any kind of retaliation. They don't need to hide. > > > > Mike Hale wrote: > > > >>"Sue them?" > >>Uhm...yes? That's why we have courts that we can sue federal agencies > >>in. > >> > >>On Mon, May 20, 2013 at 11:58 AM, Charles Wyble > >> wrote: > >>> No proxy needed. No need to hide. > >>> > >>> While working for a very large hosting company, I once observed DHS > >>hammering an occupy related website. No attempt to hide the source ip > >>or anything. > >>> > >>> What are you going to do? Sue them? If they wish to take a site > >>offline, they will ddos it or simply seize the domain under the > >>national security banner. > >>> > >>> > >>> > >>> "<<"tei''>>>" wrote: > >>> > >>>>On 20 May 2013 01:58, Michael Painter wrote: > >>>>> > >>>> > http://arstechnica.com/security/2013/05/ddos-for-hire-service-works-with-blessing-of-fbi-operator-says/ > >>>>> > >>>> > >>>>More on the same topic. > >>>> > http://krebsonsecurity.com/2013/05/ragebooter-legit-ddos-service-or-fed-backdoor/#more-19475 > >>>> > >>>>Maybe the FBI use this to commit crimes in USA using a foreign > >>company > >>>>as proxy so nothing dirty show on the books. That way the FBI can > >>>>avoid respecting USA laws. > >>>> > >>>> > >>>> > >>>> > >>>>-- > >>>>-- > >>>>?in del ?ensaje. > >>> > >>> -- > >>> Charles Wyble > >>> charles at knownelement.com / 818 280 7059 > >>> CTO Free Network Foundation (www.thefnf.org) > >> > >> > >> > >>-- > >>09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > > > > -- > > Charles Wyble > > charles at knownelement.com / 818 280 7059 > > CTO Free Network Foundation (www.thefnf.org) > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > > From mpalmer at hezmatt.org Mon May 20 21:45:58 2013 From: mpalmer at hezmatt.org (Matt Palmer) Date: Tue, 21 May 2013 07:45:58 +1000 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: <5199635F.1050606@rollernet.us> References: <5198DA9E.8090700@tomt.net> <20130519232757.GB2519@pearl.meh.net.nz> <5199635F.1050606@rollernet.us> Message-ID: <20130520214558.GE26847@hezmatt.org> On Sun, May 19, 2013 at 04:42:23PM -0700, Seth Mattinen wrote: > On 5/19/13 4:27 PM, Ben wrote: > > Do you actually need stateful filtering? A lot of people seem to think > > that it's important, when really they're accomplishing little from it, > > you can block ports etc without it. > > I believe PCI compliance requires it, other things like it probably do too. There'd be very few PCI compliant sites if PCI required stateful firewalling in core routers. - Matt From mysidia at gmail.com Mon May 20 22:44:39 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 20 May 2013 17:44:39 -0500 Subject: Inventory and workflow management systems In-Reply-To: References: <21ef2c1c0804041416w28aac3d1la30c3ad5e1b91129@mail.gmail.com> Message-ID: On 5/20/13, Justin M. Streiner wrote: > I remember looking several years ago at a commercial fiber plant > management application called Mapcom. It looked pretty good, but it was > pricey, and no one wanted to spend the money on it. So... fast-forward to > 2013.... and we're still using spreadsheets :( [snip] See, this is a problem.... standard spreadsheet programs are such a great competitor. How can you possibly justify the time and expense of developing software, if spreadsheet programs always wins against your product, because of its low price, so that there is no net income that is feasible to be made in that venture? Maybe the answer is, someone did make the program... it's just Excel, and developing more detailed custom software could be a good idea if it provides greater utility than the applicable cost of development -- once you have it though, maybe you don't want to sell it because it provides a competitive edge, and noone would be willing to pay enough for product and support anyways.... :) -- -JH From philfagan at gmail.com Mon May 20 23:08:18 2013 From: philfagan at gmail.com (Phil Fagan) Date: Mon, 20 May 2013 17:08:18 -0600 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: <20130520214558.GE26847@hezmatt.org> References: <5198DA9E.8090700@tomt.net> <20130519232757.GB2519@pearl.meh.net.nz> <5199635F.1050606@rollernet.us> <20130520214558.GE26847@hezmatt.org> Message-ID: Just curious and perhaps off topic a tad but; is the stateful filtering of sessions on a router to replace a firewall? Or is there another reason to do it? I could see a benefit of creating blacklists, however, I'm struggling with what other benefits it would provide...service aware load-balancing? I'm very interested to learn what other strategies and or design considerations would be made with thinking of using filtering on a router. I'm perfectly willing to accept consolidation of services :-) On Mon, May 20, 2013 at 3:45 PM, Matt Palmer wrote: > On Sun, May 19, 2013 at 04:42:23PM -0700, Seth Mattinen wrote: > > On 5/19/13 4:27 PM, Ben wrote: > > > Do you actually need stateful filtering? A lot of people seem to think > > > that it's important, when really they're accomplishing little from it, > > > you can block ports etc without it. > > > > I believe PCI compliance requires it, other things like it probably do > too. > > There'd be very few PCI compliant sites if PCI required stateful > firewalling > in core routers. > > - Matt > > > -- Phil Fagan Denver, CO 970-480-7618 From joelja at bogus.com Mon May 20 23:47:12 2013 From: joelja at bogus.com (joel jaeggli) Date: Mon, 20 May 2013 16:47:12 -0700 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: <20130520214558.GE26847@hezmatt.org> References: <5198DA9E.8090700@tomt.net> <20130519232757.GB2519@pearl.meh.net.nz> <5199635F.1050606@rollernet.us> <20130520214558.GE26847@hezmatt.org> Message-ID: <519AB600.5010109@bogus.com> On 5/20/13 2:45 PM, Matt Palmer wrote: > On Sun, May 19, 2013 at 04:42:23PM -0700, Seth Mattinen wrote: >> On 5/19/13 4:27 PM, Ben wrote: >>> Do you actually need stateful filtering? A lot of people seem to think >>> that it's important, when really they're accomplishing little from it, >>> you can block ports etc without it. >> I believe PCI compliance requires it, other things like it probably do too. > There'd be very few PCI compliant sites if PCI required stateful firewalling > in core routers. Putting your border router in scope for your pci environment is imho an engineering/documentation mistake. > - Matt > > From charles-lists at knownelement.com Tue May 21 04:07:55 2013 From: charles-lists at knownelement.com (Charles Wyble) Date: Mon, 20 May 2013 23:07:55 -0500 Subject: What hath god wrought? In-Reply-To: References: <851d0ba9-16ef-499d-a7e9-6ad2b4570d22@email.android.com> Message-ID: <73b6702f-2233-49f7-ad9b-8c5ddeee5adf@email.android.com> Sorry. The occupy site was on a shared hosting plan at the company I worked for. Source determined via Whois output for the attacking ip found via our analysis. It was a rather crude dos attack (repeated get requests). At first we figured they were just mirroring the site for offline analysis or something, but it soon became evident they were just hammering the site. Yes we could of sued. However the inevitable stonewalling, endless resources of the feds etc would of made for a long and exhaustive legal battle. This was at the height of the occupy activities. Far worse offenses were being committed by federal, state and local govts during that period than a dos attack by DHS. "Jason L. Sparks" wrote: >"No attempt to hide the source IP" >"I mean, they were using a shared hosting plan" > >What makes you certain it was DHS? > >Genuinely curious, because this is a hell of a claim. >-- >Jason > > >On Mon, May 20, 2013 at 3:29 PM, Mike Hale >wrote: > >> Would it be futile though? I mean...DHS running a DOS against an >> American organization is the kind of stuff that makes Constitutional >> lawyers salivate. >> >> I'm not trying to call you out, btw. I'm genuinely curious why the >> hosting company itself didn't file suit. You've got a US Government >> agency abusing your resources and acting in a blatantly illegal >> manner. That's the kind of stuff that results in letters of >> resignation when publicized. >> >> On Mon, May 20, 2013 at 12:13 PM, Charles Wyble >> wrote: >> > Yes. I'm aware of that. It would be futile in most cases, which is >a >> huge problem in and of itself, as that's really the only recourse. >> > >> > I mean they were using a shared hosting plan. Not exactly deep >pocketed. >> > >> > My point is that the abuse of power is blatant and they are >unafraid of >> any kind of retaliation. They don't need to hide. >> > >> > Mike Hale wrote: >> > >> >>"Sue them?" >> >>Uhm...yes? That's why we have courts that we can sue federal >agencies >> >>in. >> >> >> >>On Mon, May 20, 2013 at 11:58 AM, Charles Wyble >> >> wrote: >> >>> No proxy needed. No need to hide. >> >>> >> >>> While working for a very large hosting company, I once observed >DHS >> >>hammering an occupy related website. No attempt to hide the source >ip >> >>or anything. >> >>> >> >>> What are you going to do? Sue them? If they wish to take a site >> >>offline, they will ddos it or simply seize the domain under the >> >>national security banner. >> >>> >> >>> >> >>> >> >>> "<<"tei''>>>" wrote: >> >>> >> >>>>On 20 May 2013 01:58, Michael Painter wrote: >> >>>>> >> >>>> >> >http://arstechnica.com/security/2013/05/ddos-for-hire-service-works-with-blessing-of-fbi-operator-says/ >> >>>>> >> >>>> >> >>>>More on the same topic. >> >>>> >> >http://krebsonsecurity.com/2013/05/ragebooter-legit-ddos-service-or-fed-backdoor/#more-19475 >> >>>> >> >>>>Maybe the FBI use this to commit crimes in USA using a foreign >> >>company >> >>>>as proxy so nothing dirty show on the books. That way the FBI can >> >>>>avoid respecting USA laws. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>>-- >> >>>>-- >> >>>>?in del ?ensaje. >> >>> >> >>> -- >> >>> Charles Wyble >> >>> charles at knownelement.com / 818 280 7059 >> >>> CTO Free Network Foundation (www.thefnf.org) >> >> >> >> >> >> >> >>-- >> >>09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 >> > >> > -- >> > Charles Wyble >> > charles at knownelement.com / 818 280 7059 >> > CTO Free Network Foundation (www.thefnf.org) >> >> >> >> -- >> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 >> >> -- Charles Wyble charles at knownelement.com / 818 280 7059 CTO Free Network Foundation (www.thefnf.org) From jayfar at jayfar.com Tue May 21 04:56:14 2013 From: jayfar at jayfar.com (Jay Farrell) Date: Tue, 21 May 2013 00:56:14 -0400 Subject: What hath god wrought? In-Reply-To: <73b6702f-2233-49f7-ad9b-8c5ddeee5adf@email.android.com> References: <851d0ba9-16ef-499d-a7e9-6ad2b4570d22@email.android.com> <73b6702f-2233-49f7-ad9b-8c5ddeee5adf@email.android.com> Message-ID: Are you certain it was a DoS attempt? They may have just been running a surveillance software package such as URLy warning, which GETs the pages of a site repeatedly and diffs them to watch for updates. In the case of an (non-)organization like Occupy I can't imagine law enforcement would neglect to do this. I've been on the receiving end of this sort of thing myself (long story). -- Jayfar On Tue, May 21, 2013 at 12:07 AM, Charles Wyble wrote: > Sorry. The occupy site was on a shared hosting plan at the company I worked for. > > Source determined via Whois output for the attacking ip found via our analysis. It was a rather crude dos attack (repeated get requests). At first we figured they were just mirroring the site for offline analysis or something, but it soon became evident they were just hammering the site. > > Yes we could of sued. However the inevitable stonewalling, endless resources of the feds etc would of made for a long and exhaustive legal battle. > > This was at the height of the occupy activities. Far worse offenses were being committed by federal, state and local govts during that period than a dos attack by DHS. > > > "Jason L. Sparks" wrote: > >>"No attempt to hide the source IP" >>"I mean, they were using a shared hosting plan" >> >>What makes you certain it was DHS? >> >>Genuinely curious, because this is a hell of a claim. >>-- >>Jason >> >> >>On Mon, May 20, 2013 at 3:29 PM, Mike Hale >>wrote: >> >>> Would it be futile though? I mean...DHS running a DOS against an >>> American organization is the kind of stuff that makes Constitutional >>> lawyers salivate. >>> >>> I'm not trying to call you out, btw. I'm genuinely curious why the >>> hosting company itself didn't file suit. You've got a US Government >>> agency abusing your resources and acting in a blatantly illegal >>> manner. That's the kind of stuff that results in letters of >>> resignation when publicized. >>> >>> On Mon, May 20, 2013 at 12:13 PM, Charles Wyble >>> wrote: >>> > Yes. I'm aware of that. It would be futile in most cases, which is >>a >>> huge problem in and of itself, as that's really the only recourse. >>> > >>> > I mean they were using a shared hosting plan. Not exactly deep >>pocketed. >>> > >>> > My point is that the abuse of power is blatant and they are >>unafraid of >>> any kind of retaliation. They don't need to hide. >>> > >>> > Mike Hale wrote: >>> > >>> >>"Sue them?" >>> >>Uhm...yes? That's why we have courts that we can sue federal >>agencies >>> >>in. >>> >> >>> >>On Mon, May 20, 2013 at 11:58 AM, Charles Wyble >>> >> wrote: >>> >>> No proxy needed. No need to hide. >>> >>> >>> >>> While working for a very large hosting company, I once observed >>DHS >>> >>hammering an occupy related website. No attempt to hide the source >>ip >>> >>or anything. >>> >>> >>> >>> What are you going to do? Sue them? If they wish to take a site >>> >>offline, they will ddos it or simply seize the domain under the >>> >>national security banner. >>> >>> >>> >>> >>> >>> >>> >>> "<<"tei''>>>" wrote: >>> >>> >>> >>>>On 20 May 2013 01:58, Michael Painter wrote: >>> >>>>> >>> >>>> >>> >>http://arstechnica.com/security/2013/05/ddos-for-hire-service-works-with-blessing-of-fbi-operator-says/ >>> >>>>> >>> >>>> >>> >>>>More on the same topic. >>> >>>> >>> >>http://krebsonsecurity.com/2013/05/ragebooter-legit-ddos-service-or-fed-backdoor/#more-19475 >>> >>>> >>> >>>>Maybe the FBI use this to commit crimes in USA using a foreign >>> >>company >>> >>>>as proxy so nothing dirty show on the books. That way the FBI can >>> >>>>avoid respecting USA laws. >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>>-- >>> >>>>-- >>> >>>>?in del ?ensaje. >>> >>> >>> >>> -- >>> >>> Charles Wyble >>> >>> charles at knownelement.com / 818 280 7059 >>> >>> CTO Free Network Foundation (www.thefnf.org) >>> >> >>> >> >>> >> >>> >>-- >>> >>09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 >>> > >>> > -- >>> > Charles Wyble >>> > charles at knownelement.com / 818 280 7059 >>> > CTO Free Network Foundation (www.thefnf.org) >>> >>> >>> >>> -- >>> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 >>> >>> > > -- > Charles Wyble > charles at knownelement.com / 818 280 7059 > CTO Free Network Foundation (www.thefnf.org) From david at mailplus.nl Tue May 21 08:24:30 2013 From: david at mailplus.nl (MailPlus| David Hofstee) Date: Tue, 21 May 2013 10:24:30 +0200 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: <20130519213159.GY26847@hezmatt.org> References: <5198DA9E.8090700@tomt.net> <20130519213159.GY26847@hezmatt.org> Message-ID: <78C35D6C1A82D243B830523B4193CF5F5EAA6E80B6@SBS1.blinker.local> This is what we do too: Separate firewalling and routing. We use Vyatta for both and it works. Bye, David -----Oorspronkelijk bericht----- Van: Matt Palmer [mailto:mpalmer at hezmatt.org] Verzonden: zondag 19 mei 2013 23:32 Aan: nanog at nanog.org Onderwerp: Re: High throughput bgp links using gentoo + stipped kernel On Sun, May 19, 2013 at 11:48:17AM -0400, Nick Khamis wrote: > We do use a statefull iptables on our router, some forward rules... > This is known to be on of our issues, not sure if having a separate > iptables box would be the best and only solution for this? I don't know about "only", but it'd have to come close to "best". iptables (and stateful firewalling in general) is a pretty significant CPU and memory sink. Definitely get rid of any stateful rules, preferably *all* the rules, and apply them at a separate location. We've always had BGP routing separated from firewalling, but we're currently migrating from one-giant-core-firewall to lots-of-little-firewalls because our firewalls are starting to cry a little. Nice thing is that horizontally scaling firewalls is easy -- just whack 'em on each subnet instead of running everything together. Core routing is a little harder to scale out (although as has been described already, by no means impossible). The important thing is to remove *anything* from your core routing boxes that doesn't *absolutely* have to be there -- and stateful firewall rules are *extremely* high on that list. - Matt -- When the revolution comes, they won't be able to FIND the wall. -- Brian Kantor, in the Monastery From streiner at cluebyfour.org Tue May 21 13:25:36 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 21 May 2013 09:25:36 -0400 (EDT) Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: <5198DA9E.8090700@tomt.net> <20130519232757.GB2519@pearl.meh.net.nz> <5199635F.1050606@rollernet.us> <20130520214558.GE26847@hezmatt.org> Message-ID: On Mon, 20 May 2013, Phil Fagan wrote: > Just curious and perhaps off topic a tad but; is the stateful filtering of > sessions on a router to replace a firewall? Or is there another reason to > do it? I could see a benefit of creating blacklists, however, > I'm struggling with what other benefits it would provide...service > aware load-balancing? I'm very interested to learn what other strategies > and or design considerations would be made with thinking of using filtering > on a router. > > I'm perfectly willing to accept consolidation of services :-) Stateful firewalling is also painful in environments where path asymmetry could exist, since either the routing policy would need to be designed to enforce symmetry (more complex, less reliable), or the stateful firewalling devices would need to have a way to share state information with each other to accommodate asymmetry. jms From dave at temk.in Tue May 21 13:33:59 2013 From: dave at temk.in (David Temkin) Date: Tue, 21 May 2013 09:33:59 -0400 Subject: [NANOG 58] Final agenda posted and late registration - See you in New Orleans! Message-ID: All- The final agenda for NANOG 58 has been posted at: http://www.nanog.org/meetings/nanog58/agenda Also of note, Standard Registration ends on May 30 - the price will then go up $75. We encourage you to register now and lock in the few remaining hotel rooms at http://www.nanog.org/meetings/nanog58/registration This meeting will follow the new Monday-Wednesday format of tutorials beginning Monday morning, a Newcomers Lunch, and then General Sessions beginning in the early afternoon. The program will conclude with the Peering Track and then a social on Wednesday night. Looking forward to seeing everyone in The Big Easy! Regards, -Dave Temkin Chair, NANOG Program Committee From morgan.miskell at caro.net Tue May 21 13:49:14 2013 From: morgan.miskell at caro.net (Morgan Miskell) Date: Tue, 21 May 2013 09:49:14 -0400 Subject: APC In-row Units Message-ID: <1369144154.3478.10.camel@cromagnon> I realize this topic is semi off point so feel free to reply to the list or to me personally. I am wondering if anyone has any experience using the APC In-row cooling units in their data centers. I am specifically looking at the ACRD501. Do they work well? How long have you run them? Any maintenance issues? Any input would be greatly appreciated. -- Morgan A. Miskell CaroNet Data Centers 704-643-8330 x206 ---------------------------------------------------------------------------- The information contained in this e-mail is confidential and is intended only for the named recipient(s). If you are not the intended recipient you must not copy, distribute, or take any action or reliance on it. If you have received this e-mail in error, please notify the sender. Any unauthorized disclosure of the information contained in this e-mail is strictly prohibited. ---------------------------------------------------------------------------- From streiner at cluebyfour.org Tue May 21 14:01:44 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 21 May 2013 10:01:44 -0400 (EDT) Subject: APC In-row Units In-Reply-To: <1369144154.3478.10.camel@cromagnon> References: <1369144154.3478.10.camel@cromagnon> Message-ID: On Tue, 21 May 2013, Morgan Miskell wrote: > I realize this topic is semi off point so feel free to reply to the list > or to me personally. I am wondering if anyone has any experience using > the APC In-row cooling units in their data centers. I am specifically > looking at the ACRD501. > > Do they work well? How long have you run them? Any maintenance issues? > > Any input would be greatly appreciated. We have some APC in-row coolers in our DR site. They've been in place for about 3 years, and no major maintenance issues that are outside of the norm. I believe we feed them off of our building chilled water loop, with a backup domestic water feed for times when the chilled water plant has to be taken offline for maintenance. I don't directly run our DR site, but I've never heard of any serious performance issues. I don't know the exact model of the coolers we're using, but I can find out. jms From dwcarder at wisc.edu Tue May 21 14:40:32 2013 From: dwcarder at wisc.edu (Dale W. Carder) Date: Tue, 21 May 2013 09:40:32 -0500 Subject: APC In-row Units In-Reply-To: <1369144154.3478.10.camel@cromagnon> References: <1369144154.3478.10.camel@cromagnon> Message-ID: <20130521144031.GB344@ricotta.doit.wisc.edu> Thus spake Morgan Miskell (morgan.miskell at caro.net) on Tue, May 21, 2013 at 09:49:14AM -0400: > I realize this topic is semi off point so feel free to reply to the list > or to me personally. I am wondering if anyone has any experience using > the APC In-row cooling units in their data centers. I am specifically > looking at the ACRD501. > > Do they work well? How long have you run them? Any maintenance issues? We have lots of the apc units, including the 500 or 501 IIRC. In general they are great except for finding skilled enough labor to install & maintain them. They are capable of getting your equipment mighty wet. Also pay attention to your water quality during the design process. Dale From bmanning at vacation.karoshi.com Tue May 21 15:03:29 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 21 May 2013 15:03:29 +0000 Subject: ISOC item of interest Message-ID: <20130521150329.GA8204@vacation.karoshi.com.> ISOC - the folks who bring you IETF standards, is seeking public input. This from Emma: ---- Hi all, In case it is of interest there is currently a public consultation on the Internet Society's mission now and in the future, you can voice your opinions by filling in the form at: https://www.internetsociety.org/form/strategic-and-business-planning-2014 If you have any questions you can mail me at and i'll forward them on for you. Cheers, Emma ----- From drc at virtualized.org Tue May 21 15:18:27 2013 From: drc at virtualized.org (David Conrad) Date: Tue, 21 May 2013 08:18:27 -0700 Subject: What hath god wrought? In-Reply-To: References: <851d0ba9-16ef-499d-a7e9-6ad2b4570d22@email.android.com> <73b6702f-2233-49f7-ad9b-8c5ddeee5adf@email.android.com> Message-ID: On May 20, 2013, at 9:56 PM, Jay Farrell wrote: > Are you certain it was a DoS attempt? And if you were certain, are you certain the folks at DHS were aware their machine(s) were engaged in a DoS attack? You can find zombies in the oddest places... Regards, -drc From deleskie at gmail.com Tue May 21 16:13:19 2013 From: deleskie at gmail.com (jim deleskie) Date: Tue, 21 May 2013 13:13:19 -0300 Subject: What hath god wrought? In-Reply-To: References: <851d0ba9-16ef-499d-a7e9-6ad2b4570d22@email.android.com> <73b6702f-2233-49f7-ad9b-8c5ddeee5adf@email.android.com> Message-ID: Maybe my tinfoil isn't on tight enough, or maybe I give to much credit to a gov't, or perhaps I'm just feeding the trolls, but I have a very hard time believing that DHS, launched a DoS from their own machines. -jim On Tue, May 21, 2013 at 12:18 PM, David Conrad wrote: > On May 20, 2013, at 9:56 PM, Jay Farrell wrote: > > Are you certain it was a DoS attempt? > > And if you were certain, are you certain the folks at DHS were aware their > machine(s) were engaged in a DoS attack? > > You can find zombies in the oddest places... > > Regards, > -drc > > > From David.Siegel at Level3.com Tue May 21 17:28:15 2013 From: David.Siegel at Level3.com (Siegel, David) Date: Tue, 21 May 2013 17:28:15 +0000 Subject: Inventory and workflow management systems In-Reply-To: References: <21ef2c1c0804041416w28aac3d1la30c3ad5e1b91129@mail.gmail.com> Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC048610C7F@USIDCWVEMBX10.corp.global.level3.com> Off the shelf stuff? There are lots of options, but it seems like the general opinion of the IT groups I've worked with is that it's just as much work to customize and integrate them as it is to write from scratch so we tend to get further way from COTS all the time. You should take a look at Metasolv (now part of Oracle, I believe). We used it in one of our P&L regions for some regional products for over a decade and I was always impressed by how quickly they could roll out new workflows and products in it since much of the customization work could be done by a business process architect rather than having to be coded by a developer. We've also used Granite, which is from Telcordia, but I don't have enough direct or indirect experience to have an opinion on whether or not it's any good. Dave -----Original Message----- From: vijay gill [mailto:vgill at vijaygill.com] Sent: Sunday, May 19, 2013 11:22 AM To: NANOG list Subject: Re: Inventory and workflow management systems Resurrecting this thread. Anyone? What software solution do people use for inventory management for things like riser/conduit drawdown, fiber inventory, physical topology store, CLR/DLR, x-connect, contracts, port inventory, etc. Any experiences in integrating workflow into those packages for work orders, modeling, drawdown levels, etc. On Fri, Apr 4, 2008 at 2:16 PM, vijay gill wrote: > What software solution do people use for inventory management for > things like riser/conduit drawdown, fiber inventory, physical topology > store, CLR/DLR, x-connect, contracts, port inventory, etc. > Any experiences in integrating workflow into those packages for work > orders, modeling, drawdown levels, etc. > > /vijay > > > > From wbailey at satelliteintelligencegroup.com Tue May 21 17:39:11 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 21 May 2013 17:39:11 +0000 Subject: Inventory and workflow management systems In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC048610C7F@USIDCWVEMBX10.corp.global.level3.com> Message-ID: Beware of Metasolv license costs.. Beware of Metasolv in general. On 5/21/13 10:28 AM, "Siegel, David" wrote: >Off the shelf stuff? There are lots of options, but it seems like the >general opinion of the IT groups I've worked with is that it's just as >much work to customize and integrate them as it is to write from scratch >so we tend to get further way from COTS all the time. > >You should take a look at Metasolv (now part of Oracle, I believe). We >used it in one of our P&L regions for some regional products for over a >decade and I was always impressed by how quickly they could roll out new >workflows and products in it since much of the customization work could >be done by a business process architect rather than having to be coded by >a developer. > >We've also used Granite, which is from Telcordia, but I don't have enough >direct or indirect experience to have an opinion on whether or not it's >any good. > >Dave > > >-----Original Message----- >From: vijay gill [mailto:vgill at vijaygill.com] >Sent: Sunday, May 19, 2013 11:22 AM >To: NANOG list >Subject: Re: Inventory and workflow management systems > >Resurrecting this thread. Anyone? >What software solution do people use for inventory management for things >like riser/conduit drawdown, fiber inventory, physical topology store, >CLR/DLR, x-connect, contracts, port inventory, etc. >Any experiences in integrating workflow into those packages for work >orders, modeling, drawdown levels, etc. > > > >On Fri, Apr 4, 2008 at 2:16 PM, vijay gill wrote: > >> What software solution do people use for inventory management for >> things like riser/conduit drawdown, fiber inventory, physical topology >> store, CLR/DLR, x-connect, contracts, port inventory, etc. >> Any experiences in integrating workflow into those packages for work >> orders, modeling, drawdown levels, etc. >> >> /vijay >> >> >> >> > From philfagan at gmail.com Tue May 21 17:54:39 2013 From: philfagan at gmail.com (Phil Fagan) Date: Tue, 21 May 2013 11:54:39 -0600 Subject: What hath god wrought? In-Reply-To: References: <851d0ba9-16ef-499d-a7e9-6ad2b4570d22@email.android.com> <73b6702f-2233-49f7-ad9b-8c5ddeee5adf@email.android.com> Message-ID: HAH! Thats pretty funny....the tinfoil piece. On Tue, May 21, 2013 at 10:13 AM, jim deleskie wrote: > Maybe my tinfoil isn't on tight enough, or maybe I give to much credit to a > gov't, or perhaps I'm just feeding the trolls, but I have a very hard time > believing that DHS, launched a DoS from their own machines. > > > -jim > > > On Tue, May 21, 2013 at 12:18 PM, David Conrad > wrote: > > > On May 20, 2013, at 9:56 PM, Jay Farrell wrote: > > > Are you certain it was a DoS attempt? > > > > And if you were certain, are you certain the folks at DHS were aware > their > > machine(s) were engaged in a DoS attack? > > > > You can find zombies in the oddest places... > > > > Regards, > > -drc > > > > > > > -- Phil Fagan Denver, CO 970-480-7618 From wbailey at satelliteintelligencegroup.com Tue May 21 18:48:54 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 21 May 2013 18:48:54 +0000 Subject: Dear NANOG Gods Message-ID: NANOG Gods, I need to ship some Dell servers, and my google skills have gotten me nowhere. Is there a decent place to find standard server size shipping boxes? Located in Socal if anyone has an extra or two.. ;) //warren From lathama at gmail.com Tue May 21 18:54:21 2013 From: lathama at gmail.com (Andrew Latham) Date: Tue, 21 May 2013 14:54:21 -0400 Subject: Dear NANOG Gods In-Reply-To: References: Message-ID: http://www.uline.com/ or any good shipping company. On Tue, May 21, 2013 at 2:48 PM, Warren Bailey wrote: > NANOG Gods, > > I need to ship some Dell servers, and my google skills have gotten me nowhere. Is there a decent place to find standard server size shipping boxes? Located in Socal if anyone has an extra or two.. ;) > > //warren -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From jabley at hopcount.ca Tue May 21 18:56:22 2013 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 21 May 2013 14:56:22 -0400 Subject: Dear NANOG Gods In-Reply-To: References: Message-ID: <585071D9-C7B9-4D68-A466-0E44A228C42F@hopcount.ca> Hi Warren, On 2013-05-21, at 14:48, Warren Bailey wrote: > I need to ship some Dell servers, and my google skills have gotten me nowhere. Is there a decent place to find standard server size shipping boxes? Located in Socal if anyone has an extra or two.. ;) The last time I had to ship a box myself I went to the local UPS Canada office, since they evidently will pack and ship rather than just ship. The last time we had to ship a number of (Dell, actually) boxes from ICANN in LA we bought some flight cases that we could rack the servers into. Our thought was to go for reusable, rather than one-off (and we had doubts about the state of the boxes upon arrival if they weren't securely packed; a flight case with 19" rails inside seemed like a good bet). We found the flight cases with only minimal googling, but if you're having trouble Mehmet could no doubt hook you up. And if you're close to El Segundo and we can get the flight case back when you're done, you could probably just borrow ours :-) Joe From gourmetcisco at hotmail.com Tue May 21 19:02:45 2013 From: gourmetcisco at hotmail.com (Hank Disuko) Date: Tue, 21 May 2013 15:02:45 -0400 Subject: Bermuda connectivity In-Reply-To: <692B615A-74A7-45FC-A411-5F01AC91AC1A@batblue.com> References: <692B615A-74A7-45FC-A411-5F01AC91AC1A@batblue.com> Message-ID: Hello, Link Bermuda and Logic Communications are 2 broadband carriers on the island. I believe they both have facilities terminating in NY/NJ and I believe they both either own or partially lease the submarine cables that connect the island to the US. www.linkbermuda.com www.logic.bm -Hank > From: pnowak at batblue.com > Subject: Bermuda connectivity > Date: Fri, 3 May 2013 14:48:29 -0400 > To: nanog at nanog.org > > Hello, > > I'm looking for a carrier to provide connectivity between New York (111 8th or 60 Hudson) and Bermuda. > Can someone point me in the right direction? > > Thanks > Peter > > > > From JFaraone at paulo.com Tue May 21 19:10:32 2013 From: JFaraone at paulo.com (Jason Faraone) Date: Tue, 21 May 2013 19:10:32 +0000 Subject: Dear NANOG Gods In-Reply-To: <585071D9-C7B9-4D68-A466-0E44A228C42F@hopcount.ca> References: <585071D9-C7B9-4D68-A466-0E44A228C42F@hopcount.ca> Message-ID: Would you happen to have a link for a flight case that would fit a 1-2u server? I was in the same situation a few days ago and ran the risky proposition of building my own box. -----Original Message----- From: Joe Abley [mailto:jabley at hopcount.ca] Sent: Tuesday, May 21, 2013 1:56 PM To: Warren Bailey Cc: NANOG list Subject: Re: Dear NANOG Gods Hi Warren, On 2013-05-21, at 14:48, Warren Bailey wrote: > I need to ship some Dell servers, and my google skills have gotten me nowhere. Is there a decent place to find standard server size shipping boxes? Located in Socal if anyone has an extra or two.. ;) The last time I had to ship a box myself I went to the local UPS Canada office, since they evidently will pack and ship rather than just ship. The last time we had to ship a number of (Dell, actually) boxes from ICANN in LA we bought some flight cases that we could rack the servers into. Our thought was to go for reusable, rather than one-off (and we had doubts about the state of the boxes upon arrival if they weren't securely packed; a flight case with 19" rails inside seemed like a good bet). We found the flight cases with only minimal googling, but if you're having trouble Mehmet could no doubt hook you up. And if you're close to El Segundo and we can get the flight case back when you're done, you could probably just borrow ours :-) Joe From cabenth at gmail.com Tue May 21 19:20:29 2013 From: cabenth at gmail.com (eric clark) Date: Tue, 21 May 2013 12:20:29 -0700 Subject: APC In-row Units In-Reply-To: <1369144154.3478.10.camel@cromagnon> References: <1369144154.3478.10.camel@cromagnon> Message-ID: I'm turning up a facility With APC gear now. I'll let you Know. On Tuesday, May 21, 2013, Morgan Miskell wrote: > I realize this topic is semi off point so feel free to reply to the list > or to me personally. I am wondering if anyone has any experience using > the APC In-row cooling units in their data centers. I am specifically > looking at the ACRD501. > > Do they work well? How long have you run them? Any maintenance issues? > > Any input would be greatly appreciated. > -- > Morgan A. Miskell > CaroNet Data Centers > 704-643-8330 x206 > > ---------------------------------------------------------------------------- > The information contained in this e-mail is confidential and is intended > only for the named recipient(s). If you are not the intended recipient > you must not copy, distribute, or take any action or reliance on it. If > you have received this e-mail in error, please notify the sender. Any > unauthorized disclosure of the information contained in this e-mail is > strictly prohibited. > > ---------------------------------------------------------------------------- > > > From streiner at cluebyfour.org Tue May 21 19:25:37 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 21 May 2013 15:25:37 -0400 (EDT) Subject: Dear NANOG Gods In-Reply-To: <585071D9-C7B9-4D68-A466-0E44A228C42F@hopcount.ca> References: <585071D9-C7B9-4D68-A466-0E44A228C42F@hopcount.ca> Message-ID: On Tue, 21 May 2013, Joe Abley wrote: > The last time we had to ship a number of (Dell, actually) boxes from > ICANN in LA we bought some flight cases that we could rack the servers > into. Our thought was to go for reusable, rather than one-off (and we > had doubts about the state of the boxes upon arrival if they weren't > securely packed; a flight case with 19" rails inside seemed like a good > bet). > > We found the flight cases with only minimal googling, but if you're > having trouble Mehmet could no doubt hook you up. > > And if you're close to El Segundo and we can get the flight case back > when you're done, you could probably just borrow ours :-) There a number of vendors that can either custom-build cases, or might have something off-the-shelf that will work, and meet ATA300/Milspec standards. Calzone Cases - http://www.calzonecases.com/ Jan-Al Cases - http://www.janalcase.com/ Pelican-Hardigg - http://www.pelican.com/ NOTE: I use several different types of road/flight cases for transporting audio gear for $sidejob. Fair warning: A case that provides the level of cushioning and impact protection you're looking for is likely to be heavy - possibly as heavy as the server itself. jms From christer at christers.net Tue May 21 19:37:22 2013 From: christer at christers.net (Christer Swartz) Date: Tue, 21 May 2013 12:37:22 -0700 Subject: Bermuda connectivity In-Reply-To: References: <692B615A-74A7-45FC-A411-5F01AC91AC1A@batblue.com> Message-ID: <184E6ACD-7B94-4163-BF52-AB111E29B546@christers.net> Contact either Logic Communications or TeleBermuda. I used to work for the former. --- Christer On May 21, 2013, at 12:02 PM, Hank Disuko wrote: > Hello, > > Link Bermuda and Logic Communications are 2 broadband carriers on the island. I believe they both have facilities terminating in NY/NJ and I believe they both either own or partially lease the submarine cables that connect the island to the US. > > www.linkbermuda.com > www.logic.bm > > -Hank > >> From: pnowak at batblue.com >> Subject: Bermuda connectivity >> Date: Fri, 3 May 2013 14:48:29 -0400 >> To: nanog at nanog.org >> >> Hello, >> >> I'm looking for a carrier to provide connectivity between New York (111 8th or 60 Hudson) and Bermuda. >> Can someone point me in the right direction? >> >> Thanks >> Peter >> >> >> >> > From jabley at hopcount.ca Tue May 21 19:39:40 2013 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 21 May 2013 15:39:40 -0400 Subject: Dear NANOG Gods In-Reply-To: <80497153-EEFF-4662-A730-49F0978346D4@icann.org> References: <80497153-EEFF-4662-A730-49F0978346D4@icann.org> Message-ID: Since some people were interested (on- and off-list), see below. On 2013-05-21, at 15:32, Mehmet Akcin wrote: > hey there > > we have a case from http://www.skbcases.com 20U 20" > > they are really reliable (been using them since 6 years, shipped meeting equipment for ICANN before and also servers as joe mentioned below > > let me know how we can help > > mehmet > > On May 21, 2013, at 12:27 PM, Joe Abley wrote: > >> Hey, >> >> Do you remember where you bought those flight cases we used to ship Dell 1Us around the place? >> >> People on NANOG want to know :-) >> >> >> Joe >> >> Begin forwarded message: >> >>> From: Jason Faraone >>> Subject: RE: Dear NANOG Gods >>> Date: 21 May 2013 15:10:32 EDT >>> To: 'Joe Abley' , Warren Bailey >>> Cc: NANOG list >>> >>> Would you happen to have a link for a flight case that would fit a 1-2u server? I was in the same situation a few days ago and ran the risky proposition of building my own box. >>> >>> -----Original Message----- >>> From: Joe Abley [mailto:jabley at hopcount.ca] >>> Sent: Tuesday, May 21, 2013 1:56 PM >>> To: Warren Bailey >>> Cc: NANOG list >>> Subject: Re: Dear NANOG Gods >>> >>> Hi Warren, >>> >>> On 2013-05-21, at 14:48, Warren Bailey wrote: >>> >>>> I need to ship some Dell servers, and my google skills have gotten me nowhere. Is there a decent place to find standard server size shipping boxes? Located in Socal if anyone has an extra or two.. ;) >>> >>> The last time I had to ship a box myself I went to the local UPS Canada office, since they evidently will pack and ship rather than just ship. >>> >>> The last time we had to ship a number of (Dell, actually) boxes from ICANN in LA we bought some flight cases that we could rack the servers into. Our thought was to go for reusable, rather than one-off (and we had doubts about the state of the boxes upon arrival if they weren't securely packed; a flight case with 19" rails inside seemed like a good bet). >>> >>> We found the flight cases with only minimal googling, but if you're having trouble Mehmet could no doubt hook you up. >>> >>> And if you're close to El Segundo and we can get the flight case back when you're done, you could probably just borrow ours :-) >>> >>> >>> Joe >> > From morrowc.lists at gmail.com Tue May 21 20:18:10 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 21 May 2013 16:18:10 -0400 Subject: Bermuda connectivity In-Reply-To: <184E6ACD-7B94-4163-BF52-AB111E29B546@christers.net> References: <692B615A-74A7-45FC-A411-5F01AC91AC1A@batblue.com> <184E6ACD-7B94-4163-BF52-AB111E29B546@christers.net> Message-ID: On Tue, May 21, 2013 at 3:37 PM, Christer Swartz wrote: > > Contact either Logic Communications or TeleBermuda. I used to work for the former. > > --- Christer > > > > On May 21, 2013, at 12:02 PM, Hank Disuko wrote: > >> Hello, >> >> Link Bermuda and Logic Communications are 2 broadband carriers on the island. I believe they both have facilities terminating in NY/NJ and I believe they both either own or partially lease the submarine cables that connect the island to the US. >> >> www.linkbermuda.com >> www.logic.bm >> >> -Hank >> >>> From: pnowak at batblue.com >>> Subject: Bermuda connectivity >>> Date: Fri, 3 May 2013 14:48:29 -0400 >>> To: nanog at nanog.org >>> >>> Hello, >>> >>> I'm looking for a carrier to provide connectivity between New York (111 8th or 60 Hudson) and Bermuda. >>> Can someone point me in the right direction? >>> >>> Thanks >>> Peter >>> >>> >>> >>> >> > From hannigan at gmail.com Wed May 22 02:21:12 2013 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 21 May 2013 22:21:12 -0400 Subject: Bermuda connectivity In-Reply-To: References: <692B615A-74A7-45FC-A411-5F01AC91AC1A@batblue.com> <184E6ACD-7B94-4163-BF52-AB111E29B546@christers.net> Message-ID: Hola, I don't have any direct knowledge about Bermuda telecom (I do highly recommend it as a destination though), but the ask sounds like IPL or waves to me so cable systems are the logical place to start. NY. Banking. BDA. < > etc. http://www.cablemap.info/ Looks like GlobeNet since Wikipedia is labeling the C&W Gemini cable decommissioned. YMMV, and Best, -M< On Tue, May 21, 2013 at 4:18 PM, Christopher Morrow wrote: > > > On Tue, May 21, 2013 at 3:37 PM, Christer Swartz > wrote: > > > > Contact either Logic Communications or TeleBermuda. I used to work for > the former. > > > > --- Christer > > > > > > > > On May 21, 2013, at 12:02 PM, Hank Disuko > wrote: > > > >> Hello, > >> > >> Link Bermuda and Logic Communications are 2 broadband carriers on the > island. I believe they both have facilities terminating in NY/NJ and I > believe they both either own or partially lease the submarine cables that > connect the island to the US. > >> > >> www.linkbermuda.com > >> www.logic.bm > >> > >> -Hank > >> > >>> From: pnowak at batblue.com > >>> Subject: Bermuda connectivity > >>> Date: Fri, 3 May 2013 14:48:29 -0400 > >>> To: nanog at nanog.org > >>> > >>> Hello, > >>> > >>> I'm looking for a carrier to provide connectivity between New York > (111 8th or 60 Hudson) and Bermuda. > >>> Can someone point me in the right direction? > >>> > >>> Thanks > >>> Peter > >>> > >>> > >>> > >>> > >> > > > > From mehmet at akcin.net Wed May 22 06:07:47 2013 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 21 May 2013 23:07:47 -0700 Subject: DNS Track at NANOG 58 In-Reply-To: <645BD201-33BB-46D8-80B6-9EDB16A658A1@akcin.net> References: <645BD201-33BB-46D8-80B6-9EDB16A658A1@akcin.net> Message-ID: Hello everyone, DNS Track will be on June 5, 2013 Wednesday 4:45pm-6:15pm in Crescent City Ball Room. I still have some slots available if you would like to talk about an interesting DNS related subject. , We've got a very good coverage with rate-limiting, reflection attacks, dns software updates, and some other interesting topics already. (i will be sending an agenda before the track ) look forward to see you all there. please contact me directly if you have any questions mehmet On Apr 18, 2013, at 12:15 PM, Mehmet Akcin wrote: > Greetings folks > > Once again we will have DNS Track in NANOG. > > There has been lots of recent DNS related discussions going on in many e-mail lists and I am quite sure there will be many great DNS talks in NANOG 58 just like in previous NANOGs. > > DNS Track's goal is to bring together the audience who doesn't necessarily want to know all the details of a topic but would like to spend 90 mins listening quick updates from various DNS related subjects and get some crucial information and updates. > > If you are interested in talking/presenting in the DNS Track and/or want to help me organize this Track in any way, please contact me off-list. Hopefully we can inform those who do NOT spend much time dealing with DNS about some topics they were not aware. > > Once I know the details of the agenda such as time and date of the track, topics that will be covered, i will share this with you. > > Mehmet > > From mansaxel at besserwisser.org Wed May 22 08:43:50 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 22 May 2013 10:43:50 +0200 Subject: Dear NANOG Gods In-Reply-To: <585071D9-C7B9-4D68-A466-0E44A228C42F@hopcount.ca> References: <585071D9-C7B9-4D68-A466-0E44A228C42F@hopcount.ca> Message-ID: <20130522084350.GH31267@besserwisser.org> Subject: Re: Dear NANOG Gods Date: Tue, May 21, 2013 at 02:56:22PM -0400 Quoting Joe Abley (jabley at hopcount.ca): > The last time we had to ship a number of (Dell, actually) boxes from ICANN in LA we bought some flight cases that we could rack the servers into. Our thought was to go for reusable, rather than one-off (and we had doubts about the state of the boxes upon arrival if they weren't securely packed; a flight case with 19" rails inside seemed like a good bet). If survivability is important, I like CP Cases: http://www.cpcases.com/prodrange.asp?prodrangeid=15&typeid=3 More expensive than SKB, but they bounce when dropped. And preserve the stuff inside. One probably should opt for removing PSU and drives if shipping is expected to be very rough. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 What a COINCIDENCE! I'm an authorized "SNOOTS OF THE STARS" dealer!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From daniel.white at globenet.net Wed May 22 13:58:23 2013 From: daniel.white at globenet.net (Daniel White) Date: Wed, 22 May 2013 13:58:23 +0000 Subject: Bermuda connectivity Message-ID: <2CC27F78E3C8E042A5C0721993F450B733E0CFD0@GNETMAIL01.globenet.local> Peter, I will contact you offline to discuss GlobeNet's offerings from either 111 8th or 60 Hudson to Bermuda. Thanks Dan -----Original Message----- Message: 1 Date: Tue, 21 May 2013 16:18:10 -0400 From: Christopher Morrow To: NANOG Subject: Re: Bermuda connectivity Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 21, 2013 at 3:37 PM, Christer Swartz wrote: > > Contact either Logic Communications or TeleBermuda. I used to work for the former. > > --- Christer > > > > On May 21, 2013, at 12:02 PM, Hank Disuko wrote: > >> Hello, >> >> Link Bermuda and Logic Communications are 2 broadband carriers on the island. I believe they both have facilities terminating in NY/NJ and I believe they both either own or partially lease the submarine cables that connect the island to the US. >> >> www.linkbermuda.com >> www.logic.bm >> >> -Hank >> >>> From: pnowak at batblue.com >>> Subject: Bermuda connectivity >>> Date: Fri, 3 May 2013 14:48:29 -0400 >>> To: nanog at nanog.org >>> >>> Hello, >>> >>> I'm looking for a carrier to provide connectivity between New York (111 8th or 60 Hudson) and Bermuda. >>> Can someone point me in the right direction? >>> >>> Thanks >>> Peter >>> >>> >>> >>> >> > ------------------------------ Message: 2 Date: Tue, 21 May 2013 22:21:12 -0400 From: Martin Hannigan To: Christopher Morrow Cc: NANOG Subject: Re: Bermuda connectivity Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Hola, I don't have any direct knowledge about Bermuda telecom (I do highly recommend it as a destination though), but the ask sounds like IPL or waves to me so cable systems are the logical place to start. NY. Banking. BDA. < > etc. http://www.cablemap.info/ Looks like GlobeNet since Wikipedia is labeling the C&W Gemini cable decommissioned. YMMV, and Best, -M< On Tue, May 21, 2013 at 4:18 PM, Christopher Morrow wrote: > > > On Tue, May 21, 2013 at 3:37 PM, Christer Swartz > > wrote: > > > > Contact either Logic Communications or TeleBermuda. I used to work > > for > the former. > > > > --- Christer > > > > > > > > On May 21, 2013, at 12:02 PM, Hank Disuko > wrote: > > > >> Hello, > >> > >> Link Bermuda and Logic Communications are 2 broadband carriers on > >> the > island. I believe they both have facilities terminating in NY/NJ and > I believe they both either own or partially lease the submarine cables > that connect the island to the US. > >> > >> www.linkbermuda.com > >> www.logic.bm > >> > >> -Hank > >> > >>> From: pnowak at batblue.com > >>> Subject: Bermuda connectivity > >>> Date: Fri, 3 May 2013 14:48:29 -0400 > >>> To: nanog at nanog.org > >>> > >>> Hello, > >>> > >>> I'm looking for a carrier to provide connectivity between New York > (111 8th or 60 Hudson) and Bermuda. > >>> Can someone point me in the right direction? > >>> > >>> Thanks > >>> Peter > >>> > >>> > >>> > >>> > >> > > > > ________________________________ CONFIDENTIAL: This e-mail (including any attachments) is intended only for the use of the Recipient and is CONFIDENTIAL. By downloading any attachments, the Recipient thereby acknowledges, agrees, and consents not to divulge or otherwise disclose this email and any attachments, except Recipient may only disclose the contents therein to its employees on a need-to-know basis, or as required by law. Please advise immediately if you or your employer do not consent to these conditions. CONFIDENCIAL: Este e-mail (incluyendo los archivos adjuntos) es s?lo para el uso de el Destinatario y es CONFIDENCIAL. Al bajar los archivos adjuntos, el Destinatario reconoce, est? de acuerdo, y acepta no divulgar este e-mail y los archivos adjuntos, excepto el Destinatario ?nicamente puede divulgar el contenido a sus empleados en la medida en que necesite conocerlo, o come exige la ley. Por favor ind?quenos inmediatamente si usted o su empleador no acepta estas condiciones. From mir at ripe.net Wed May 22 14:22:08 2013 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 22 May 2013 16:22:08 +0200 Subject: Please take the RIPE NCC Survey 2013 Message-ID: <519CD490.3020806@ripe.net> Hello, The RIPE NCC asks all members and other interested parties to take a survey for the RIPE NCC and the RIPE community. This survey will help us to assess our services and activities, identify areas for improvement, and help shape our strategy for the coming years. The survey is open to anyone and is carried out by the Oxford Internet Institute, which guarantees anonymity for participants and independent assessment of the results. It will remain open until 17 June 2013. The results will be presented at the RIPE 67 Meeting in Athens, 14 ? 18 October 2013. You can find the survey here: https://www.ripe.net/lir-services/member-support/info/surveys/ripe-ncc-survey-2013 Kind regards, Mirjam Kuehne RIPE NCC From joe at via.net Thu May 23 01:37:05 2013 From: joe at via.net (joe mcguckin) Date: Wed, 22 May 2013 18:37:05 -0700 Subject: Dear NANOG Gods In-Reply-To: References: Message-ID: <690183AB-D5AB-478E-B8F1-75CA1EE6F50B@via.net> Find a used computer/network equipment vendor near you. They'll have the right sized boxes & can foam encapsulate your gear. Most companies have been willing to box up equipment for me at no (or little) charge. Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax On May 21, 2013, at 11:48 AM, Warren Bailey wrote: > NANOG Gods, > > I need to ship some Dell servers, and my google skills have gotten me nowhere. Is there a decent place to find standard server size shipping boxes? Located in Socal if anyone has an extra or two.. ;) > > //warren From job.snijders at atrato.com Thu May 23 10:28:58 2013 From: job.snijders at atrato.com (Job Snijders) Date: Thu, 23 May 2013 12:28:58 +0200 Subject: peeringdb accuracy research Message-ID: Dear fellow networkers, I need your help! For the good of PeeringDB I am researching the accuracy of the current PeeringDB data set. We plan to compare three sources of information: peeringdb itself, publicly available listings from IXP operators ... and the ultimate source of truth: user submitted information, e.g. your "show bgp sum". Why? I'd rather trust 10 sightings in the wild than one entry in PeeringDB! :-) What can you do? ---------------- We've created a webapp where you can copy + paste the output from your routers' show ip bgp sum / show bgp sum / show ipv6 bgp sum. The webapp extracts the ASN and remote IP for the sessions and store those after your confirmation. Go to the following URL and submit your BGP data now! https://research.peeringdb.com/ If you prefer, you can also submit the data in CSV format [2]. What data are we using, exactly? -------------------------------- Only the following tuples of information are used: (remote_ASN, remote_IP) All other data is purged from the data set: I don't care if you are even exchanging prefixes or how many, nor does it matter what your own ASN is. The _only_ thing that matters is that you confirm that you have a BGP session up and running with a certain remote IP and ASN. You can submit such confirmations by copying + pasting your routers' bgp summaries. Please submit your BGP summaries from all your IXP facing routers! So when will I hear back about this? ------------------------------------ I will present the findings at the upcoming NANOG meeting in New Orleans [1]. Given that the NANOG meeting is approaching rapidly, I urge you to submit your data sooner rather than later. :-) Kind regards, Job Snijders [1] - CSV format should be formatted like column 1: ASN, column 2: remote IP, separated by a comma. example: "5580,195.69.144.229" [2] - http://www.nanog.org/meetings/abstract?id=2140 From jmkeller at houseofzen.org Thu May 23 13:25:01 2013 From: jmkeller at houseofzen.org (James M Keller) Date: Thu, 23 May 2013 09:25:01 -0400 Subject: Reclaiming legacy allocation transferred to APNIC? Message-ID: <519E18AD.30408@houseofzen.org> All, $DAYJOB has a legacy block assignment that was transferred to APNIC from ARIN under the Early Registration transfer project back in 2003... ARIN whois queried directly still shows the /16 block has ARIN contact information, but walking it down from the /8 APNIC has no data other then the /8 block information and the ERX comment. However on the ERX page listing the transferes, the specific /16 block isn't listed under the /8 as it appears to be for others that had been transferred. The So my question is who do we work with now? ARIN or APNIC for this block? Do we need to join either RIR just to update records, or is it just painful manual process without having membership and website logins? Off-list if specifics for the block in question are needed. Thanks in advance. -- --- James M Keller From jcurran at arin.net Thu May 23 14:00:00 2013 From: jcurran at arin.net (John Curran) Date: Thu, 23 May 2013 14:00:00 +0000 Subject: Reclaiming legacy allocation transferred to APNIC? In-Reply-To: <519E18AD.30408@houseofzen.org> References: <519E18AD.30408@houseofzen.org> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FDD02EA@CHAXCH01.corp.arin.net> On May 23, 2013, at 9:25 AM, James M Keller wrote: > All, > > $DAYJOB has a legacy block assignment that was transferred to APNIC from > ARIN under the Early Registration transfer project back in 2003... > > ARIN whois queried directly still shows the /16 block has ARIN contact > information, but walking it down from the /8 APNIC has no data other > then the /8 block information and the ERX comment. However on the ERX > page listing the transferes, the specific /16 block isn't listed under > the /8 as it appears to be for others that had been transferred. The > So my question is who do we work with now? ARIN or APNIC for this > block? Do we need to join either RIR just to update records, or is it > just painful manual process without having membership and website logins? > > Off-list if specifics for the block in question are needed. > > Thanks in advance. James - Can you send me specifics when you have a moment? Thanks! /John John Curran President and CEO ARIN From saamato at frontiernet.net Thu May 23 14:30:13 2013 From: saamato at frontiernet.net (Stephen Amato) Date: Thu, 23 May 2013 10:30:13 -0400 Subject: Verizon Business Support Message-ID: <003401ce57c2$098a17c0$1c9e4740$@frontiernet.net> Can an Admin from Verizon Business please contact me off-list to resolve a routing/bogon issue? Thank you, Steve From jmkeller at houseofzen.org Thu May 23 14:31:26 2013 From: jmkeller at houseofzen.org (James M Keller) Date: Thu, 23 May 2013 10:31:26 -0400 Subject: Reclaiming legacy allocation transferred to APNIC? In-Reply-To: <519E18AD.30408@houseofzen.org> References: <519E18AD.30408@houseofzen.org> Message-ID: <519E283E.8020700@houseofzen.org> On 5/23/2013 9:25 AM, James M Keller wrote: > All, > > $DAYJOB has a legacy block assignment that was transferred to APNIC from > ARIN under the Early Registration transfer project back in 2003... > > ARIN whois queried directly still shows the /16 block has ARIN contact > information, but walking it down from the /8 APNIC has no data other > then the /8 block information and the ERX comment. However on the ERX > page listing the transferes, the specific /16 block isn't listed under > the /8 as it appears to be for others that had been transferred. The > So my question is who do we work with now? ARIN or APNIC for this > block? Do we need to join either RIR just to update records, or is it > just painful manual process without having membership and website logins? > > Off-list if specifics for the block in question are needed. > > Thanks in advance. > Thanks for the off-list responses. I'll follow up if I run into a dead end on this. -- --- James M Keller From james.smits at gmail.com Thu May 23 17:13:47 2013 From: james.smits at gmail.com (James Smits) Date: Thu, 23 May 2013 13:13:47 -0400 Subject: Widespread Outages Message-ID: Is something major going on? This looks like a X-mas tree http://www.internetpulse.net/ And FedEx rate servers are returning a 503 "for up to an hour" according to their rep. From shortdudey123 at gmail.com Thu May 23 17:56:44 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Thu, 23 May 2013 12:56:44 -0500 Subject: Mailman reverting settings Message-ID: Hi Everyone, Has anyone ever seen Mailman revert to an old user list? This morning we had out lists VM pounded on from India and hung the box. After blocking the ip on our firewall and rebooting the hung vm, everything came back up except 1 list. The list appears to have reverted to old settings. I found the config.pck file and it does not have the current settings in it. This has happened once before. The box is running Ubuntu 10.04 and Mailman 2.1.13. Anyone know what would cause this and how to fix it? We are working to try a file level restore from a backup. Thanks, Grant ~~~~~~~~~~ Grant Ridder Assistant Systems Administrator Milwaukee School of Engineering From ag4ve.us at gmail.com Thu May 23 19:47:08 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 23 May 2013 15:47:08 -0400 Subject: Geoip lookup In-Reply-To: References: Message-ID: What's the best way to find the networks in a country? I was thinking of writing some perl with Net::Whois::ARIN or some such module and loop through the block. But I think I'll have to be smarter than just a simple loop not to get blocked and I figure I'm not the first to want to do this. I've noticed some paid databases out there. They don't cost much but are they even worth what they charge? Ie, countryipblocks.net doesn't list quite a few addresses from a country I've looked at blocking. Isn't this information free from the different *NICs anyway? This is probably two questions: a program that smartly looks for country's blocks in a block and are GeoIP services worth anything? From jabley at hopcount.ca Thu May 23 20:32:03 2013 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 23 May 2013 16:32:03 -0400 Subject: Geoip lookup In-Reply-To: References: Message-ID: On 2013-05-23, at 15:47, shawn wilson wrote: > What's the best way to find the networks in a country? I was thinking of > writing some perl with Net::Whois::ARIN or some such module and loop > through the block. But I think I'll have to be smarter than just a simple > loop not to get blocked and I figure I'm not the first to want to do this. If you are looking for registration data, try looking in one or more of ftp://ftp.apnic.net/public/apnic/stats/apnic/ ftp://ftp.ripe.net/ripe/dbase/ ftp://ftp.lacnic.net/pub/stats/lacnic/ ftp://ftp.afrinic.net/stats/afrinic/ ftp://ftp.arin.net/pub/stats/arin/ (poke around and see what you can find; I didn't spend much time trying, but several/all of the RIRs seem to mirror data from all the others) Note that "networks in a country" is a funny phrase. The sets - address space assigned to all organisations located in country X - routes visible in country X (from some viewpoint) - all addresses assigned to devices physically located within country X - routes that are considered "in-country" in places where billing is aligned with the necessity to traverse a long bit of wet glass are frequently incongruent. If this matters, you might want to consider a more detailed specification of "networks in a country". Joe From ag4ve.us at gmail.com Thu May 23 20:40:27 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 23 May 2013 16:40:27 -0400 Subject: Geoip lookup In-Reply-To: References: Message-ID: On Thu, May 23, 2013 at 4:32 PM, Joe Abley wrote: > > On 2013-05-23, at 15:47, shawn wilson wrote: > >> What's the best way to find the networks in a country? I was thinking of >> writing some perl with Net::Whois::ARIN or some such module and loop >> through the block. But I think I'll have to be smarter than just a simple >> loop not to get blocked and I figure I'm not the first to want to do this. > > If you are looking for registration data, try looking in one or more of > > ftp://ftp.apnic.net/public/apnic/stats/apnic/ > ftp://ftp.ripe.net/ripe/dbase/ > ftp://ftp.lacnic.net/pub/stats/lacnic/ > ftp://ftp.afrinic.net/stats/afrinic/ > ftp://ftp.arin.net/pub/stats/arin/ > > (poke around and see what you can find; I didn't spend much time trying, but several/all of the RIRs seem to mirror data from all the others) Thanks > > Note that "networks in a country" is a funny phrase. The sets > > - address space assigned to all organisations located in country X > - routes visible in country X (from some viewpoint) > - all addresses assigned to devices physically located within country X > - routes that are considered "in-country" in places where billing is aligned with the necessity to traverse a long bit of wet glass > > are frequently incongruent. If this matters, you might want to consider a more detailed specification of "networks in a country". > I had somewhat considered the second and the fourth point. I assumed by using whois data, I am getting the second of those options and that was good enough. If there's a way to (somewhat easily) implement the third option, I'm all ears. From ag4ve.us at gmail.com Thu May 23 20:56:21 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 23 May 2013 16:56:21 -0400 Subject: Geoip lookup In-Reply-To: References: Message-ID: On Thu, May 23, 2013 at 4:40 PM, shawn wilson wrote: > On Thu, May 23, 2013 at 4:32 PM, Joe Abley wrote: >> >> On 2013-05-23, at 15:47, shawn wilson wrote: >> >> >> ftp://ftp.apnic.net/public/apnic/stats/apnic/ >> ftp://ftp.ripe.net/ripe/dbase/ >> ftp://ftp.lacnic.net/pub/stats/lacnic/ >> ftp://ftp.afrinic.net/stats/afrinic/ >> ftp://ftp.arin.net/pub/stats/arin/ >> It looks you're right and everyone does have the same data in historical format. Looks like RIPE has everything compiled into what is current. So if a block hasn't changed for 10 years, it'll be in the RIPE dataset vs with the others, I'd have to write something to overlay the data through out time to get current? From chip.gwyn at gmail.com Thu May 23 21:06:24 2013 From: chip.gwyn at gmail.com (chip) Date: Thu, 23 May 2013 17:06:24 -0400 Subject: Geoip lookup In-Reply-To: References: Message-ID: I've used the MaxMind Lite geo-ip database plus some perl modules and a BGP table to get something fairly close. Anything in the BGP table that was larger than a /20 I split into /20's. For my use case, this was close enough. I then grabbed 30 or so IP's within the range and geo-ip mapped them. You can then apply some algebra and get a general idea of where things are or are not. Things I used: http://search.cpan.org/~plonka/Net-Patricia-1.014/Patricia.pm - For ip/prefix/lat-lon mapping http://search.cpan.org/~borisz/Geo-IP-1.41/lib/Geo/IP.pm - For Geo-IP lat/lon data http://dev.maxmind.com/geoip/legacy/geolite - Maxmind's city database http://data.caida.org/datasets/routing/routeviews-prefix2as/ - for BGP prefix/mask + src ASN info Good luck! --chip On Thu, May 23, 2013 at 3:47 PM, shawn wilson wrote: > What's the best way to find the networks in a country? I was thinking of > writing some perl with Net::Whois::ARIN or some such module and loop > through the block. But I think I'll have to be smarter than just a simple > loop not to get blocked and I figure I'm not the first to want to do this. > > I've noticed some paid databases out there. They don't cost much but are > they even worth what they charge? Ie, countryipblocks.net doesn't list > quite a few addresses from a country I've looked at blocking. Isn't this > information free from the different *NICs anyway? > > This is probably two questions: a program that smartly looks for country's > blocks in a block and are GeoIP services worth anything? > -- Just my $.02, your mileage may vary, batteries not included, etc.... From jabley at hopcount.ca Thu May 23 21:36:56 2013 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 23 May 2013 17:36:56 -0400 Subject: Geoip lookup In-Reply-To: References: Message-ID: On 2013-05-23, at 16:56, shawn wilson wrote: > It looks you're right and everyone does have the same data in > historical format. Looks like RIPE has everything compiled into what > is current. So if a block hasn't changed for 10 years, it'll be in the > RIPE dataset vs with the others, I'd have to write something to > overlay the data through out time to get current? Could be. You've looked at this more than I have, now -- I was mainly trying to point out that bulk data retrieval is a possible option so you could avoid whois-hammering :-) Joe From ag4ve.us at gmail.com Thu May 23 22:34:56 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 23 May 2013 18:34:56 -0400 Subject: Geoip lookup In-Reply-To: References: Message-ID: On Thu, May 23, 2013 at 5:36 PM, Joe Abley wrote: > > On 2013-05-23, at 16:56, shawn wilson wrote: > >> It looks you're right and everyone does have the same data in >> historical format. Looks like RIPE has everything compiled into what >> is current. So if a block hasn't changed for 10 years, it'll be in the >> RIPE dataset vs with the others, I'd have to write something to >> overlay the data through out time to get current? > > Could be. You've looked at this more than I have, now -- I was mainly trying to point out that bulk data retrieval is a possible option so you could avoid whois-hammering Actually, I can't find anything better, so I think i'm going to query the bottom of ranges like so: % dig +short 0.0.66.77.origin.asn.cymru.com TXT "16245 | 77.66.0.0/17 | DK | ripencc | 2007-01-24" % dig +short 0.0.65.77.origin.asn.cymru.com TXT "13110 | 77.65.0.0/17 | PL | ripencc | 2007-01-17" According to their web site, they won't block me if I don't do anything stupid "If you are planning on implementing the use of this service in any software, application, or device PLEASE let us know in advance. We would like to adequately plan for capacity and make sure that we can adequately handle the load. If at all possible, PLEASE use the DNS based service since it is faster and more efficient, particularly for larger deployments of individual IP based queries." http://www.team-cymru.org/Services/ip-to-asn.html#dns and use this https://metacpan.org/module/MRSAM/Net-CIDR-0.17/CIDR.pm to find my upper ranges. So, I'm pretty much thinking about whois-hammering still :( Also, I just picked those IPs at random (ie, start at one end of the number, hit twice, dot, next number) nothing particularly interresting about whoever that is AFAIK. From rs at seastrom.com Fri May 24 00:54:39 2013 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 23 May 2013 20:54:39 -0400 Subject: Geoip lookup In-Reply-To: (chip's message of "Thu, 23 May 2013 17:06:24 -0400") References: Message-ID: <86ip298aeo.fsf@valhalla.seastrom.com> This may be just a case of getting what you pay for, but Maxmind marks entire netblocks as proxies, puts 'em in the wrong country, and ignores repeated efforts by the registrant of the address space to set the record straight. The problem comes when people actually do stuff with the information, like block access to legitimate web sites because the're in "proxy space" and therefore assumed to be bad guys (believe it or not this practice is widespread by well-intentioned but clueless folk). Caveat utilitor. -r chip writes: > I've used the MaxMind Lite geo-ip database plus some perl modules and a BGP > table to get something fairly close. Anything in the BGP table that was > larger than a /20 I split into /20's. For my use case, this was close > enough. I then grabbed 30 or so IP's within the range and geo-ip mapped > them. You can then apply some algebra and get a general idea of where > things are or are not. > > Things I used: > http://search.cpan.org/~plonka/Net-Patricia-1.014/Patricia.pm - For > ip/prefix/lat-lon mapping > http://search.cpan.org/~borisz/Geo-IP-1.41/lib/Geo/IP.pm - For Geo-IP > lat/lon data > http://dev.maxmind.com/geoip/legacy/geolite - Maxmind's city database > http://data.caida.org/datasets/routing/routeviews-prefix2as/ - for BGP > prefix/mask + src ASN info > > Good luck! > > --chip > > > > > > > On Thu, May 23, 2013 at 3:47 PM, shawn wilson wrote: > >> What's the best way to find the networks in a country? I was thinking of >> writing some perl with Net::Whois::ARIN or some such module and loop >> through the block. But I think I'll have to be smarter than just a simple >> loop not to get blocked and I figure I'm not the first to want to do this. >> >> I've noticed some paid databases out there. They don't cost much but are >> they even worth what they charge? Ie, countryipblocks.net doesn't list >> quite a few addresses from a country I've looked at blocking. Isn't this >> information free from the different *NICs anyway? >> >> This is probably two questions: a program that smartly looks for country's >> blocks in a block and are GeoIP services worth anything? >> > > > > -- > Just my $.02, your mileage may vary, batteries not included, etc.... From andreas.larsen at ip-only.se Fri May 24 05:53:10 2013 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Fri, 24 May 2013 07:53:10 +0200 Subject: Geoip lookup In-Reply-To: <86ip298aeo.fsf@valhalla.seastrom.com> Message-ID: The whole idea of Geoip is flawed. IP dosen't reside in countries, they are routable adresses that can reside everywhere, I guess soon on mars even. 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 Den 2013-05-24 02:54 skrev Rob Seastrom : > >This may be just a case of getting what you pay for, but Maxmind marks >entire netblocks as proxies, puts 'em in the wrong country, and >ignores repeated efforts by the registrant of the address space to set >the record straight. The problem comes when people actually do stuff >with the information, like block access to legitimate web sites >because the're in "proxy space" and therefore assumed to be bad guys >(believe it or not this practice is widespread by well-intentioned but >clueless folk). Caveat utilitor. > >-r > >chip writes: > >> I've used the MaxMind Lite geo-ip database plus some perl modules and a >>BGP >> table to get something fairly close. Anything in the BGP table that was >> larger than a /20 I split into /20's. For my use case, this was close >> enough. I then grabbed 30 or so IP's within the range and geo-ip mapped >> them. You can then apply some algebra and get a general idea of where >> things are or are not. >> >> Things I used: >> http://search.cpan.org/~plonka/Net-Patricia-1.014/Patricia.pm - For >> ip/prefix/lat-lon mapping >> http://search.cpan.org/~borisz/Geo-IP-1.41/lib/Geo/IP.pm - For Geo-IP >> lat/lon data >> http://dev.maxmind.com/geoip/legacy/geolite - Maxmind's city database >> http://data.caida.org/datasets/routing/routeviews-prefix2as/ - for BGP >> prefix/mask + src ASN info >> >> Good luck! >> >> --chip >> >> >> >> >> >> >> On Thu, May 23, 2013 at 3:47 PM, shawn wilson >>wrote: >> >>> What's the best way to find the networks in a country? I was thinking >>>of >>> writing some perl with Net::Whois::ARIN or some such module and loop >>> through the block. But I think I'll have to be smarter than just a >>>simple >>> loop not to get blocked and I figure I'm not the first to want to do >>>this. >>> >>> I've noticed some paid databases out there. They don't cost much but >>>are >>> they even worth what they charge? Ie, countryipblocks.net doesn't list >>> quite a few addresses from a country I've looked at blocking. Isn't >>>this >>> information free from the different *NICs anyway? >>> >>> This is probably two questions: a program that smartly looks for >>>country's >>> blocks in a block and are GeoIP services worth anything? >>> >> >> >> >> -- >> Just my $.02, your mileage may vary, batteries not included, etc.... > From jhellenthal at dataix.net Fri May 24 06:03:09 2013 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Fri, 24 May 2013 02:03:09 -0400 Subject: Widespread Outages In-Reply-To: References: Message-ID: <659DFEA4-CACA-4271-8C45-9D4D28FB50AA@DataIX.net> That's a no. Not quite sure what you would see in these statistics given the weather conditions around the US. Might be more useful looking at a direct route from a specific point to destination where it might seem like things are awry. Looking glasses would be of more help to determine that. Though I can say mobile YouTube traffic has been quirky lately. On May 23, 2013, at 13:13, James Smits wrote: > Is something major going on? > > This looks like a X-mas tree http://www.internetpulse.net/ > > And FedEx rate servers are returning a 503 "for up to an hour" according to > their rep. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6118 bytes Desc: not available URL: From drc at virtualized.org Fri May 24 06:17:15 2013 From: drc at virtualized.org (David Conrad) Date: Thu, 23 May 2013 23:17:15 -0700 Subject: Geoip lookup In-Reply-To: References: Message-ID: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> On May 23, 2013, at 10:53 PM, Andreas Larsen wrote: > The whole idea of Geoip is flawed. Sure, but pragmatically, it's an 80% solution. > IP dosen't reside in countries, True, according to (at least some of) the RIRs they reside in regions... Regards, -drc From andreas.larsen at ip-only.se Fri May 24 06:34:08 2013 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Fri, 24 May 2013 08:34:08 +0200 Subject: Geoip lookup In-Reply-To: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> Message-ID: If we continue to support and build tools around this geolocation based ip-dravel, we give people a false notion that this is something we should do. Identify users with some other means that Geoip Couple of things comes to mind. * normal postage mail that they have to collect at their home and send back confirming that they are indeed in the country from where their IP is * Passports scanned. * Fingerprinting Or just get rid of the whole idea and realize that the internet is global and reaches everywhere no matter what your IP currently is. 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 Den 2013-05-24 08:17 skrev David Conrad : >On May 23, 2013, at 10:53 PM, Andreas Larsen >wrote: >> The whole idea of Geoip is flawed. > >Sure, but pragmatically, it's an 80% solution. > >> IP dosen't reside in countries, > >True, according to (at least some of) the RIRs they reside in regions... > >Regards, >-drc > From owen at delong.com Fri May 24 06:39:12 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 23 May 2013 23:39:12 -0700 Subject: Geoip lookup In-Reply-To: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> References: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> Message-ID: <78F7BBF3-C10D-44CD-ABF1-96EB506E4D40@delong.com> On May 23, 2013, at 23:17 , David Conrad wrote: > On May 23, 2013, at 10:53 PM, Andreas Larsen wrote: >> The whole idea of Geoip is flawed. > > Sure, but pragmatically, it's an 80% solution. > >> IP dosen't reside in countries, > > True, according to (at least some of) the RIRs they reside in regions... > Really? Which ones? I thought they were only issued to organizations that had operations in regions. Owen From bmanning at vacation.karoshi.com Fri May 24 06:49:41 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 24 May 2013 06:49:41 +0000 Subject: Geoip lookup In-Reply-To: <78F7BBF3-C10D-44CD-ABF1-96EB506E4D40@delong.com> References: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> <78F7BBF3-C10D-44CD-ABF1-96EB506E4D40@delong.com> Message-ID: <20130524064941.GF23438@vacation.karoshi.com.> On Thu, May 23, 2013 at 11:39:12PM -0700, Owen DeLong wrote: > > On May 23, 2013, at 23:17 , David Conrad wrote: > > > On May 23, 2013, at 10:53 PM, Andreas Larsen wrote: > >> The whole idea of Geoip is flawed. > > > > Sure, but pragmatically, it's an 80% solution. > > > >> IP dosen't reside in countries, > > > > True, according to (at least some of) the RIRs they reside in regions... > > > > Really? Which ones? I thought they were only issued to organizations that had operations in regions. > > Owen Just because I have operations in one region does not preclude me from having operations in other regions. YMMV of course. /bill From owen at delong.com Fri May 24 06:57:06 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 23 May 2013 23:57:06 -0700 Subject: Geoip lookup In-Reply-To: <20130524064941.GF23438@vacation.karoshi.com.> References: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> <78F7BBF3-C10D-44CD-ABF1-96EB506E4D40@delong.com> <20130524064941.GF23438@vacation.karoshi.com.> Message-ID: <87F5A01F-7283-4EEE-B076-E18C710B5C9D@delong.com> On May 23, 2013, at 23:49 , bmanning at vacation.karoshi.com wrote: > On Thu, May 23, 2013 at 11:39:12PM -0700, Owen DeLong wrote: >> >> On May 23, 2013, at 23:17 , David Conrad wrote: >> >>> On May 23, 2013, at 10:53 PM, Andreas Larsen wrote: >>>> The whole idea of Geoip is flawed. >>> >>> Sure, but pragmatically, it's an 80% solution. >>> >>>> IP dosen't reside in countries, >>> >>> True, according to (at least some of) the RIRs they reside in regions... >>> >> >> Really? Which ones? I thought they were only issued to organizations that had operations in regions. >> >> Owen > > Just because I have operations in one region does not preclude me from having operations > in other regions. YMMV of course. > > /bill That was exactly my point, Bill... If you have operations in RIPE and ARIN regions, it is entirely possible for you to obtain addresses from RIPE or ARIN and use them in both locations, or, obtain addresses from both RIPE and ARIN and use them in their respective regions, or mix and match in just about any imaginable way. Thus, IP addresses don't reside in regions, either. They are merely issued somewhat regionally. Owen From paul at blacknight.com Fri May 24 07:27:47 2013 From: paul at blacknight.com (Paul Kelly :: Blacknight) Date: Fri, 24 May 2013 07:27:47 +0000 Subject: Geoip lookup In-Reply-To: <20130524065755.9BCF25A4010@merlin.blacknight.ie> References: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> <78F7BBF3-C10D-44CD-ABF1-96EB506E4D40@delong.com> <20130524064941.GF23438@vacation.karoshi.com.> <20130524065755.9BCF25A4010@merlin.blacknight.ie> Message-ID: <2DAB8DD43DA13045A341D800A4E91C9F4A1D66D4@bkexchmbx01.blacknight.local> > > > > Just because I have operations in one region does not preclude me > from having operations > > in other regions. YMMV of course. > > > > /bill > > That was exactly my point, Bill... If you have operations in RIPE and ARIN > regions, it is entirely possible for you to obtain addresses from RIPE or ARIN > and use them in both locations, or, obtain addresses from both RIPE and > ARIN and use them in their respective regions, or mix and match in just about > any imaginable way. Thus, IP addresses don't reside in regions, either. They > are merely issued somewhat regionally. > In theory Maxmind is quite accurate. From 1 x /20 that we own we tag different space with the country: flag in the RIPE db. Maxmind picks this up after approx 30 days and says it's in Country X vrs country Y. e.g. $ geoiplookup 81.17.247.64 GeoIP Country Edition: US, United States $ geoiplookup 81.17.247.1 GeoIP Country Edition: IE, Ireland Obviously the RIPE db structure makes this simple. As for other RIRs it's not as easy. Like someone else said, it's going to be an 80% solution and its really down to good administration from a network operator point of view. i.e. if you route some of your RIPE space in ARIN territory you should specify the country. There's numerous reasons for this but it's just good practice IMO. Pk From jfmezei_nanog at vaxination.ca Fri May 24 07:28:04 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 24 May 2013 03:28:04 -0400 Subject: Geoip lookup In-Reply-To: <87F5A01F-7283-4EEE-B076-E18C710B5C9D@delong.com> References: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> <78F7BBF3-C10D-44CD-ABF1-96EB506E4D40@delong.com> <20130524064941.GF23438@vacation.karoshi.com.> <87F5A01F-7283-4EEE-B076-E18C710B5C9D@delong.com> Message-ID: <519F1684.3080502@vaxination.ca> On 13-05-24 02:57, Owen DeLong wrote: > That was exactly my point, Bill... If you have operations in RIPE and ARIN regions, it is entirely possible for you to obtain addresses from RIPE or ARIN and use them in both locations, or, obtain addresses from both RIPE and ARIN and use them in their respective regions, or mix and match in just about any imaginable way. Thus, IP addresses don't reside in regions, either. They are merely issued somewhat regionally. Correct. But the fact remains that a lot of services assume geolocation works and do so in terms of restricting access to their content (oftent due to legacy content rights that require geolocation). One extreme example. A sports equipment retailer operates under a different banner in the province of Qu?bec than in the rest of Canada. They geolocate the user's province and prevent qu?beckers from accessing the "rest of canada" web site. So residents of ontario who subscribe to an ISP based in Qu?bec are blocked from the web site because that web site thinks they are based in Qu?bec. The problem is with many web designers and managers who do not understand geolocation and the ISP business and how they are structured. In the case of the sports equipment chain. there is no real need to geoblock. (perhaps to prevent Qu?beckers from seeing the prices in the rest of canada ?) But in the case of entertainment, rights to programs are purchased with strict geolocation requirements. One example are pay TV channels TMN (Astral) and Movie Central (Shaw). The first has eastern canada, the later has western Canada. an IPTV BDU (regulated "cable" carrier (aka: cable competitor) must therefore ensure that a customer to whom it delivers the IPTV feed for "TMN" is located in the region for which TMN has rights. Same for all channels. And there is also pesky channel substitution requirements rhat are based on your location. In Canada, we are not allowed to watch a program on a US channel if a local TV channel carries the same program at same time. The better solution is to do like satellite BDUs do: billing address. But some web based systems ignore the unreliable geolocation services and use them to geolocate their customers. It is probably the fault of geolocation services which misrepresent the accuracy of their data. But if you can't beat them, you might as well join them, and that may mean separate IP blocks for different provinces/states and separate registrations so geoocation companies can at least get province/state right. It will get much worse if governments start to tax purchases/services based on gelocation. From ag4ve.us at gmail.com Fri May 24 08:13:32 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 24 May 2013 04:13:32 -0400 Subject: Geoip lookup In-Reply-To: <87F5A01F-7283-4EEE-B076-E18C710B5C9D@delong.com> References: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> <78F7BBF3-C10D-44CD-ABF1-96EB506E4D40@delong.com> <20130524064941.GF23438@vacation.karoshi.com.> <87F5A01F-7283-4EEE-B076-E18C710B5C9D@delong.com> Message-ID: I knew this would come up. Actually I'm surprised and glad it waited until I got a solution first. I'll address a few points: - this is mainly to stop stupid things from sending packets from countries we will probably never want to do business with (I'm looking mainly at that big country under APNIC). - I'd prefer a solution that blocks all traffic that is routed through those countries so that they could never see data from us (and when Jin-rong has a configuration mess up and rerouts ~10% of traffic through them for a half hour, I don't see any of that traffic). Since I have no idea how one would go about doing this, just blocking traffic from IP addresses registered in certain countries is good enough. - it is well known (I think everyone on this list at least) that you can evade geographic placement of your origin by tunneling. Given this, I fail to see the point in bringing up that "GeoIP" doesn't work. Also, if it doesn't work, why do content providers, CDNs, google, and streaming services rely on it as part of their business model? The sad truth of the mater is it does work and surprisingly well. We just don't like it because it's brittle and a user can fool us (I know Akami and the like look at trip time and the like because they know there are issues). Given all of this, how often is looking at the country an IP address originates from via what is listed for the particular ASN actually fiction? Again, the input was invaluable for getting me where I wanted to be so thanks again. On May 24, 2013 2:59 AM, "Owen DeLong" wrote: > > On May 23, 2013, at 23:49 , bmanning at vacation.karoshi.com wrote: > > > On Thu, May 23, 2013 at 11:39:12PM -0700, Owen DeLong wrote: > >> > >> On May 23, 2013, at 23:17 , David Conrad wrote: > >> > >>> On May 23, 2013, at 10:53 PM, Andreas Larsen < > andreas.larsen at ip-only.se> wrote: > >>>> The whole idea of Geoip is flawed. > >>> > >>> Sure, but pragmatically, it's an 80% solution. > >>> > >>>> IP dosen't reside in countries, > >>> > >>> True, according to (at least some of) the RIRs they reside in > regions... > >>> > >> > >> Really? Which ones? I thought they were only issued to organizations > that had operations in regions. > >> > >> Owen > > > > Just because I have operations in one region does not preclude me > from having operations > > in other regions. YMMV of course. > > > > /bill > > That was exactly my point, Bill... If you have operations in RIPE and ARIN > regions, it is entirely possible for you to obtain addresses from RIPE or > ARIN and use them in both locations, or, obtain addresses from both RIPE > and ARIN and use them in their respective regions, or mix and match in just > about any imaginable way. Thus, IP addresses don't reside in regions, > either. They are merely issued somewhat regionally. > > Owen > > > From rsk at gsp.org Fri May 24 09:30:27 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 24 May 2013 05:30:27 -0400 Subject: Mailman reverting settings In-Reply-To: References: Message-ID: <20130524093027.GA8619@gsp.org> 1. The mailman-users list is here: http://mail.python.org/mailman/listinfo/mailman-users 2. Blocking one IP address is not usually sufficient. If you don't need email from India (or any other country for that matter) to reach that list, then you should block the entire country from that VM. See http://ipdeny.com/ for lists. ---rsk From jcurran at istaff.org Fri May 24 13:15:08 2013 From: jcurran at istaff.org (John Curran) Date: Fri, 24 May 2013 09:15:08 -0400 Subject: Geoip lookup In-Reply-To: References: Message-ID: <4678C8BF-CC3C-4385-B0C6-F43E1D01EA20@istaff.org> On May 24, 2013, at 2:34 AM, Andreas Larsen wrote: > If we continue to support and build tools around this geolocation based > ip-dravel, we give people a false notion that this is something we should > do. > ... > > Or just get rid of the whole idea and realize that the internet is global > and reaches everywhere no matter what your IP currently is. While the Internet is global and reaches everywhere, the same is not true about most businesses and governments... As a result, there are many use cases that we may not like, but are seen as basic requirements by those organizations. Examples include laws and business contracts that require different behavior depending on the location of the user, and from the view of these organizations, the Internet almost gives the impression of shoddy workmanship to omit such an obvious capability. Luckily, many organizations did come up with workarounds, and the lack of a 100% reliable solution did not prevent them from distributing content (software, music, movies, articles, etc.) that they only had rights to do so in a particular region. If the approximate geolocation approaches had not been used, we'd would not have had the region-restricted experimentation in content distribution that underlies quite a bit of the industry even today. One can argue that regionally-based business models should be changed, but the fact is that the not-quite-reliable geolocation services are actually has been pretty important in enabling traditional content in making it onto the Internet. (It is left as a exercise for the reader as to whether more highly reliable geolocation would meaningfully help the situation, or simply enable its use in non-commercial contexts to the detriment of the global user community.) /John Disclaimer: My views alone (& for folks who wish to filter this email based on my geolocation, it is presently Northern Virginia USA ;-) From philfagan at gmail.com Fri May 24 14:23:45 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 24 May 2013 08:23:45 -0600 Subject: Mailman reverting settings In-Reply-To: References: Message-ID: What hung the box? Core dump? Filled up var? On May 23, 2013 11:57 AM, "Grant Ridder" wrote: > Hi Everyone, > > Has anyone ever seen Mailman revert to an old user list? This morning we > had out lists VM pounded on from India and hung the box. After blocking > the ip on our firewall and rebooting the hung vm, everything came back up > except 1 list. The list appears to have reverted to old settings. I found > the config.pck file and it does not have the current settings in it. This > has happened once before. The box is running Ubuntu 10.04 and Mailman > 2.1.13. Anyone know what would cause this and how to fix it? We are > working to try a file level restore from a backup. > > Thanks, > Grant > > ~~~~~~~~~~ > > Grant Ridder > > Assistant Systems Administrator > > Milwaukee School of Engineering > From drc at virtualized.org Fri May 24 14:47:56 2013 From: drc at virtualized.org (David Conrad) Date: Fri, 24 May 2013 07:47:56 -0700 Subject: Geoip lookup In-Reply-To: <87F5A01F-7283-4EEE-B076-E18C710B5C9D@delong.com> References: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> <78F7BBF3-C10D-44CD-ABF1-96EB506E4D40@delong.com> <20130524064941.GF23438@vacation.karoshi.com.> <87F5A01F-7283-4EEE-B076-E18C710B5C9D@delong.com> Message-ID: <3479A4BC-33D4-433C-A37B-99A2F83EBDB6@virtualized.org> I replied privately to Owen, but might as well share: On May 23, 2013, at 11:57 PM, Owen DeLong wrote: >>>> True, according to (at least some of) the RIRs they reside in regions... >>> Really? Which ones? I thought they were only issued to organizations that had operations in regions. > That was exactly my point, Bill... If you have operations in RIPE and ARIN regions, it is entirely possible for you to obtain addresses from RIPE or ARIN and use them in both locations, or, obtain addresses from both RIPE and ARIN and use them in their respective regions, or mix and match in just about any imaginable way. Thus, IP addresses don't reside in regions, either. They are merely issued somewhat regionally. A direct quote from a recent interaction with ARIN (this was requested by ARIN staff as part of the back and forth for requesting address space): "Please reply and verify that you will be using the requested number resources within the ARIN region and announcing all routing prefixes of the requested space from within the ARIN region. In accordance with section 2.2 of the NRPM, ARIN issues number resources only for use within its region. ARIN is therefore only able to provide for your in-region numbering needs." I believe AfriNIC and LACNIC have similar limitations on use but am too lazy to look it up (and I don't really care all that much: just thought it was amusing). Regards, -drc From owen at delong.com Fri May 24 16:08:13 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 24 May 2013 09:08:13 -0700 Subject: Geoip lookup In-Reply-To: <519F1684.3080502@vaxination.ca> References: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> <78F7BBF3-C10D-44CD-ABF1-96EB506E4D40@delong.com> <20130524064941.GF23438@vacation.karoshi.com.> <87F5A01F-7283-4EEE-B076-E18C710B5C9D@delong.com> <519F1684.3080502@vaxination.ca> Message-ID: On May 24, 2013, at 00:28 , Jean-Francois Mezei wrote: > On 13-05-24 02:57, Owen DeLong wrote: > >> That was exactly my point, Bill... If you have operations in RIPE and ARIN regions, it is entirely possible for you to obtain addresses from RIPE or ARIN and use them in both locations, or, obtain addresses from both RIPE and ARIN and use them in their respective regions, or mix and match in just about any imaginable way. Thus, IP addresses don't reside in regions, either. They are merely issued somewhat regionally. > > Correct. > But the fact remains that a lot of services assume geolocation works and > do so in terms of restricting access to their content (oftent due to > legacy content rights that require geolocation). > The fact remains that a certain percentage of the population robs banks. Neither is a particularly good thing, IMHO. > One extreme example. A sports equipment retailer operates under a > different banner in the province of Qu?bec than in the rest of Canada. > They geolocate the user's province and prevent qu?beckers from accessing > the "rest of canada" web site. > And the quebeckers that care use a tunnel to get an address that doesn't geolocate to quebec. > So residents of ontario who subscribe to an ISP based in Qu?bec are > blocked from the web site because that web site thinks they are based in > Qu?bec. > Which goes to prove my point wrt. bank robbery. > The problem is with many web designers and managers who do not > understand geolocation and the ISP business and how they are structured. > So called experts who remain rather ignorant in their field of "expertise" are a problem across a wide variety of fields. The internet is not unique in this regard and geolocation is just one aspect of this problem on the internet. > In the case of the sports equipment chain. there is no real need to > geoblock. (perhaps to prevent Qu?beckers from seeing the prices in the > rest of canada ?) > Yep... And even if there were a reason, geoblocking is a joke anyway because it is trivially subverted by anyone who cares and more of a problem for people who should have access but their IP doesn't match their actual geography. > But in the case of entertainment, rights to programs are purchased with > strict geolocation requirements. One example are pay TV channels TMN > (Astral) and Movie Central (Shaw). The first has eastern canada, the > later has western Canada. But IP geolocation doesn't help in either of these cases. Those wanting to subvert the programming restrictions simply use a tunnel to do so. On the other hand, a customer who lives near the boundary and gets his internet service from the "wrong side" of the boundary has access to the service from the wrong geography and not the correct geography. > an IPTV BDU (regulated "cable" carrier (aka: cable competitor) must > therefore ensure that a customer to whom it delivers the IPTV feed for > "TMN" is located in the region for which TMN has rights. Same for all > channels. And there is also pesky channel substitution requirements > rhat are based on your location. In Canada, we are not allowed to watch > a program on a US channel if a local TV channel carries the same program > at same time. And geolocation by IP doesn't actually work to enforce any of these restrictions because tunnels easily circumvent it for those that want to circumvent it. OTOH, it also breaks the process for those who happen to be victims of unfortunate mismatches between topology and geography. Where the IPTV provider is also the ISP, this isn't really much of a problem, but in that case, geo IP is kind of redundant. Where the IPTV provider is not the ISP, it gets very strange very quickly. > The better solution is to do like satellite BDUs do: billing address. > But some web based systems ignore the unreliable geolocation services > and use them to geolocate their customers. Yep... Again, see above comments about ignorance and bank robbery. > It is probably the fault of geolocation services which misrepresent the > accuracy of their data. But if you can't beat them, you might as well > join them, and that may mean separate IP blocks for different > provinces/states and separate registrations so geoocation companies can > at least get province/state right. Why would I want to help them? I'd much rather give my customers the option of where they want to pretend to be. If I were running a provider that crossed such regional boundaries, I'd likely offer a service (for a fee) where a customer could tunnel through whichever region got them access to the content they wanted at any given time. > It will get much worse if governments start to tax purchases/services > based on gelocation. ROFLMAO... Indeed... That will likely lead to some very interesting lawsuits and consumer complaints about invalid taxation due to inaccuracies in the geolocation database. Owen From owen at delong.com Fri May 24 16:15:53 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 24 May 2013 09:15:53 -0700 Subject: Geoip lookup In-Reply-To: References: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> <78F7BBF3-C10D-44CD-ABF1-96EB506E4D40@delong.com> <20130524064941.GF23438@vacation.karoshi.com.> <87F5A01F-7283-4EEE-B076-E18C710B5C9D@delong.com> Message-ID: On May 24, 2013, at 01:13 , shawn wilson wrote: > I knew this would come up. Actually I'm surprised and glad it waited until I got a solution first. > > I'll address a few points: > - this is mainly to stop stupid things from sending packets from countries we will probably never want to do business with (I'm looking mainly at that big country under APNIC). > I can't tell you how much I enjoyed all the hoops I had to jump through in order to access my online banking while traveling in that country. Assuming that your local customers aren't in that location isn't a valid assumption to begin with. Making life difficult for those that do travel will not earn you brownie points with them. (I am no longer with the financial institution that made this most difficult). > - I'd prefer a solution that blocks all traffic that is routed through those countries so that they could never see data from us (and when Jin-rong has a configuration mess up and rerouts ~10% of traffic through them for a half hour, I don't see any of that traffic). Since I have no idea how one would go about doing this, just blocking traffic from IP addresses registered in certain countries is good enough. > That's hard to do. Unless you require "record-route" on all packets and have some way to validate the contents of the route recording header (and enough space in the header to record all hops every time), it's not going to be possible. Further, even if it were, there's no way to ensure that all of your client's packets will get retransmitted on a path that works, so you would have the potential to severely degrade customer service in non-intuitive and hard-to-diagnose ways. If you are my competitor, then I encourage you to try this. > - it is well known (I think everyone on this list at least) that you can evade geographic placement of your origin by tunneling. Given this, I fail to see the point in bringing up that "GeoIP" doesn't work. Also, if it doesn't work, why do content providers, CDNs, google, and streaming services rely on it as part of their business model? The sad truth of the mater is it does work and surprisingly well. We just don't like it because it's brittle and a user can fool us (I know Akami and the like look at trip time and the like because they know there are issues). Given all of this, how often is looking at the country an IP address originates from via what is listed for the particular ASN actually fiction? > Asking why providers rely on GeoIP in the face of it's flaws is like asking why people continue to buy Windows. It's a cross between inertia and a lack of better solutions at comparable cost. The sad truth of the matter is that it doesn't work. It works well enough to give the illusion of working. Deeper analysis, however, reveals that it works just well enough to keep honest people honest some of the time. Further, victims of it not working have little or no recourse available to them even if they understand what is happening. For the average user, it just looks like some portion of the internet is {permanently|temporarily} broken again for reasons passing understanding and they go somewhere else. Owen > Again, the input was invaluable for getting me where I wanted to be so thanks again. > > On May 24, 2013 2:59 AM, "Owen DeLong" wrote: > > On May 23, 2013, at 23:49 , bmanning at vacation.karoshi.com wrote: > > > On Thu, May 23, 2013 at 11:39:12PM -0700, Owen DeLong wrote: > >> > >> On May 23, 2013, at 23:17 , David Conrad wrote: > >> > >>> On May 23, 2013, at 10:53 PM, Andreas Larsen wrote: > >>>> The whole idea of Geoip is flawed. > >>> > >>> Sure, but pragmatically, it's an 80% solution. > >>> > >>>> IP dosen't reside in countries, > >>> > >>> True, according to (at least some of) the RIRs they reside in regions... > >>> > >> > >> Really? Which ones? I thought they were only issued to organizations that had operations in regions. > >> > >> Owen > > > > Just because I have operations in one region does not preclude me from having operations > > in other regions. YMMV of course. > > > > /bill > > That was exactly my point, Bill... If you have operations in RIPE and ARIN regions, it is entirely possible for you to obtain addresses from RIPE or ARIN and use them in both locations, or, obtain addresses from both RIPE and ARIN and use them in their respective regions, or mix and match in just about any imaginable way. Thus, IP addresses don't reside in regions, either. They are merely issued somewhat regionally. > > Owen > > From bzs at world.std.com Fri May 24 17:47:52 2013 From: bzs at world.std.com (Barry Shein) Date: Fri, 24 May 2013 13:47:52 -0400 Subject: Geoip lookup In-Reply-To: References: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> Message-ID: <20895.42952.224238.708020@world.std.com> You're thinking like an engineer. Think like a marketer. They expect less than 1% response on paper mail advertising. Now, compare and contrast your idea of a reasonable confidence level and theirs. -- -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 ryangard at gmail.com Fri May 24 18:41:44 2013 From: ryangard at gmail.com (Ryan Gard) Date: Fri, 24 May 2013 14:41:44 -0400 Subject: What hath god wrought? In-Reply-To: References: <851d0ba9-16ef-499d-a7e9-6ad2b4570d22@email.android.com> <73b6702f-2233-49f7-ad9b-8c5ddeee5adf@email.android.com> Message-ID: Smells more like a honeypot than anything. Now that this guy's clearly decided to open his mouth and claim he's got the green light from the Fed, I wouldn't be surprised if they change their mind. On Tue, May 21, 2013 at 1:54 PM, Phil Fagan wrote: > HAH! Thats pretty funny....the tinfoil piece. > > > On Tue, May 21, 2013 at 10:13 AM, jim deleskie wrote: > > > Maybe my tinfoil isn't on tight enough, or maybe I give to much credit > to a > > gov't, or perhaps I'm just feeding the trolls, but I have a very hard > time > > believing that DHS, launched a DoS from their own machines. > > > > > > -jim > > > > > > On Tue, May 21, 2013 at 12:18 PM, David Conrad > > wrote: > > > > > On May 20, 2013, at 9:56 PM, Jay Farrell wrote: > > > > Are you certain it was a DoS attempt? > > > > > > And if you were certain, are you certain the folks at DHS were aware > > their > > > machine(s) were engaged in a DoS attack? > > > > > > You can find zombies in the oddest places... > > > > > > Regards, > > > -drc > > > > > > > > > > > > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 > -- Ryan Gard From ryangard at gmail.com Fri May 24 19:17:39 2013 From: ryangard at gmail.com (Ryan Gard) Date: Fri, 24 May 2013 15:17:39 -0400 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: <8EC20B64-77CF-4BE5-82CF-8BC2131573C6@mnet.bg> <2d2fe94d32c4536cc2033699c740119e@jonesy.com.au> Message-ID: Do you have a source on this? Reason I ask is because any recent documentation I've come across indicates that polling is recommended to reduce chances of livelock on a running system. On Mon, May 20, 2013 at 2:51 PM, Eduardo Schoedler wrote: > 2013/5/19 Andrew Jones > > > As for migration to another OS, I find FreeBSD better as a matter of > >> network performance. The last time I checked OpenBSD was either > >> lacking or was in the early stages of multiple cores support. > >> > > > > If you do decide to go the FreeBSD route (you can run openbgpd on FreeBSD > > if you like), check out the POLLING option on ethernet NICs, it cuts down > > on the number of interrupts and can increase performance, particularly > when > > dealing with smaller packets. > > > > Polling on FreeBSD in modern NICs is discouraged. > > -- > Eduardo Schoedler > -- Ryan Gard From tvest at eyeconomics.com Fri May 24 19:20:56 2013 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 24 May 2013 15:20:56 -0400 Subject: Geoip lookup In-Reply-To: <2DAB8DD43DA13045A341D800A4E91C9F4A1D66D4@bkexchmbx01.blacknight.local> References: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> <78F7BBF3-C10D-44CD-ABF1-96EB506E4D40@delong.com> <20130524064941.GF23438@vacation.karoshi.com.> <20130524065755.9BCF25A4010@merlin.blacknight.ie> <2DAB8DD43DA13045A341D800A4E91C9F4A1D66D4@bkexchmbx01.blacknight.local> Message-ID: On May 24, 2013, at 3:27 AM, Paul Kelly :: Blacknight wrote: >>> >>> Just because I have operations in one region does not preclude me >> from having operations >>> in other regions. YMMV of course. >>> >>> /bill >> >> That was exactly my point, Bill... If you have operations in RIPE and ARIN >> regions, it is entirely possible for you to obtain addresses from RIPE or ARIN >> and use them in both locations, or, obtain addresses from both RIPE and >> ARIN and use them in their respective regions, or mix and match in just about >> any imaginable way. Thus, IP addresses don't reside in regions, either. They >> are merely issued somewhat regionally. >> > > In theory Maxmind is quite accurate. From 1 x /20 that we own we tag different space with the country: flag in the RIPE db. Maxmind picks this up after approx 30 days and says it's in Country X vrs country Y. Interesting. I wonder how many days it takes the RIPE db to report the correct country for those more specifics that you've tagged... TV > e.g. > > $ geoiplookup 81.17.247.64 > GeoIP Country Edition: US, United States > $ geoiplookup 81.17.247.1 > GeoIP Country Edition: IE, Ireland > > Obviously the RIPE db structure makes this simple. As for other RIRs it's not as easy. Like someone else said, it's going to be an 80% solution and its really down to good administration from a network operator point of view. i.e. if you route some of your RIPE space in ARIN territory you should specify the country. There's numerous reasons for this but it's just good practice IMO. > > Pk > From jgreco at ns.sol.net Fri May 24 19:21:07 2013 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 24 May 2013 14:21:07 -0500 (CDT) Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: Message-ID: <201305241921.r4OJL75f031941@aurora.sol.net> > Do you have a source on this? Reason I ask is because any recent > documentation I've come across indicates that polling is recommended to > reduce chances of livelock on a running system. What recent documentation have you come across? Luigi did the polling stuff more than a decade ago. Polling fixes some issues and seems to cause others. ... 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 cscora at apnic.net Fri May 24 19:32:18 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 25 May 2013 05:32:18 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201305241932.r4OJWIIp002554@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 25 May, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 455658 Prefixes after maximum aggregation: 185562 Deaggregation factor: 2.46 Unique aggregates announced to Internet: 224685 Total ASes present in the Internet Routing Table: 44157 Prefixes per ASN: 10.32 Origin-only ASes present in the Internet Routing Table: 34642 Origin ASes announcing only one prefix: 16112 Transit ASes present in the Internet Routing Table: 5852 Transit-only ASes present in the Internet Routing Table: 152 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 54 Max AS path prepend of ASN ( 56484) 51 Prefixes from unregistered ASNs in the Routing Table: 315 Unregistered ASNs in the Routing Table: 128 Number of 32-bit ASNs allocated by the RIRs: 4775 Number of 32-bit ASNs visible in the Routing Table: 3663 Prefixes from 32-bit ASNs in the Routing Table: 10451 Special use prefixes present in the Routing Table: 26 Prefixes being announced from unallocated address space: 244 Number of addresses announced to Internet: 2619297836 Equivalent to 156 /8s, 31 /16s and 80 /24s Percentage of available address space announced: 70.7 Percentage of allocated address space announced: 70.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.5 Total number of prefixes smaller than registry allocations: 160151 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 110112 Total APNIC prefixes after maximum aggregation: 33502 APNIC Deaggregation factor: 3.29 Prefixes being announced from the APNIC address blocks: 111514 Unique aggregates announced from the APNIC address blocks: 44846 APNIC Region origin ASes present in the Internet Routing Table: 4843 APNIC Prefixes per ASN: 23.03 APNIC Region origin ASes announcing only one prefix: 1218 APNIC Region transit ASes present in the Internet Routing Table: 829 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 537 Number of APNIC addresses announced to Internet: 722621440 Equivalent to 43 /8s, 18 /16s and 84 /24s Percentage of available APNIC address space announced: 84.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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: 159423 Total ARIN prefixes after maximum aggregation: 80337 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 160003 Unique aggregates announced from the ARIN address blocks: 73260 ARIN Region origin ASes present in the Internet Routing Table: 15710 ARIN Prefixes per ASN: 10.18 ARIN Region origin ASes announcing only one prefix: 5979 ARIN Region transit ASes present in the Internet Routing Table: 1631 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 19 Number of ARIN addresses announced to Internet: 1063351616 Equivalent to 63 /8s, 97 /16s and 117 /24s Percentage of available ARIN address space announced: 56.3 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, 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: 117067 Total RIPE prefixes after maximum aggregation: 59894 RIPE Deaggregation factor: 1.95 Prefixes being announced from the RIPE address blocks: 120631 Unique aggregates announced from the RIPE address blocks: 78083 RIPE Region origin ASes present in the Internet Routing Table: 17198 RIPE Prefixes per ASN: 7.01 RIPE Region origin ASes announcing only one prefix: 8158 RIPE Region transit ASes present in the Internet Routing Table: 2816 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 54 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2342 Number of RIPE addresses announced to Internet: 656531684 Equivalent to 39 /8s, 33 /16s and 224 /24s Percentage of available RIPE address space announced: 95.4 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, 196608-199679 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: 47649 Total LACNIC prefixes after maximum aggregation: 9284 LACNIC Deaggregation factor: 5.13 Prefixes being announced from the LACNIC address blocks: 51815 Unique aggregates announced from the LACNIC address blocks: 24372 LACNIC Region origin ASes present in the Internet Routing Table: 1933 LACNIC Prefixes per ASN: 26.81 LACNIC Region origin ASes announcing only one prefix: 571 LACNIC Region transit ASes present in the Internet Routing Table: 354 Average LACNIC Region AS path length visible: 4.6 Max LACNIC Region AS path length visible: 20 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 759 Number of LACNIC addresses announced to Internet: 129734152 Equivalent to 7 /8s, 187 /16s and 150 /24s Percentage of available LACNIC address space announced: 77.3 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-62463, 262144-263167 plus 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: 10870 Total AfriNIC prefixes after maximum aggregation: 2505 AfriNIC Deaggregation factor: 4.34 Prefixes being announced from the AfriNIC address blocks: 11451 Unique aggregates announced from the AfriNIC address blocks: 3899 AfriNIC Region origin ASes present in the Internet Routing Table: 631 AfriNIC Prefixes per ASN: 18.15 AfriNIC Region origin ASes announcing only one prefix: 186 AfriNIC Region transit ASes present in the Internet Routing Table: 135 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46505984 Equivalent to 2 /8s, 197 /16s and 160 /24s Percentage of available AfriNIC address space announced: 46.2 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 2962 11559 926 Korea Telecom (KIX) 17974 2512 838 90 PT TELEKOMUNIKASI INDONESIA 7545 1984 320 108 TPG Internet Pty Ltd 4755 1734 391 192 TATA Communications formerly 9829 1512 1205 40 BSNL National Internet Backbo 9583 1219 91 502 Sify Limited 7552 1167 1064 12 Vietel Corporation 4808 1133 2112 329 CNCGROUP IP network: China169 9498 1113 309 72 BHARTI Airtel Ltd. 24560 1069 393 166 Bharti Airtel Ltd., Telemedia 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 3018 3693 79 bellsouth.net, inc. 18566 2066 382 184 Covad Communications 1785 1992 677 124 PaeTec Communications, Inc. 22773 1979 2929 125 Cox Communications, Inc. 7029 1973 1265 211 Windstream Communications Inc 20115 1671 1610 612 Charter Communications 4323 1608 1138 399 Time Warner Telecom 30036 1327 296 645 Mediacom Communications Corp 7018 1302 11074 834 AT&T WorldNet Services 11492 1234 221 342 Cable One 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 8402 1787 544 16 Corbina telecom 2118 1260 97 13 EUnet/RELCOM Autonomous Syste 34984 1205 240 228 BILISIM TELEKOM 20940 856 298 674 Akamai Technologies European 13188 827 98 73 Educational Network 31148 795 40 24 FreeNet ISP 6830 771 2377 444 UPC Distribution Services 8551 771 370 43 Bezeq International 34744 688 173 56 SC GVM SISTEM 2003 SRL 58113 666 74 386 LIR DATACENTER TELECOM SRL 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 28573 2766 1535 115 NET Servicos de Comunicao S.A 10620 2625 412 228 TVCABLE BOGOTA 7303 1726 1154 224 Telecom Argentina Stet-France 8151 1257 2707 396 UniNet S.A. de C.V. 18881 951 780 19 Global Village Telecom 6503 933 435 68 AVANTEL, S.A. 27947 835 89 104 Telconet S.A 3816 706 306 85 Empresa Nacional de Telecomun 7738 698 1370 35 Telecomunicacoes da Bahia S.A 11172 608 87 64 Servicios Alestra S.A de C.V 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 36998 1237 80 4 MOBITEL 24863 886 274 33 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 444 956 9 TEDATA 24835 344 80 8 RAYA Telecom - Egypt 3741 261 906 220 The Internet Solution 15706 222 32 6 Sudatel Internet Exchange Aut 12258 193 28 67 Vodacom Internet Company 29975 191 667 21 Vodacom 36992 189 527 22 Etisalat MISR 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 6389 3018 3693 79 bellsouth.net, inc. 4766 2962 11559 926 Korea Telecom (KIX) 28573 2766 1535 115 NET Servicos de Comunicao S.A 10620 2625 412 228 TVCABLE BOGOTA 17974 2512 838 90 PT TELEKOMUNIKASI INDONESIA 18566 2066 382 184 Covad Communications 1785 1992 677 124 PaeTec Communications, Inc. 7545 1984 320 108 TPG Internet Pty Ltd 22773 1979 2929 125 Cox Communications, Inc. 7029 1973 1265 211 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 28573 2766 2651 NET Servicos de Comunicao S.A 17974 2512 2422 PT TELEKOMUNIKASI INDONESIA 10620 2625 2397 TVCABLE BOGOTA 4766 2962 2036 Korea Telecom (KIX) 18566 2066 1882 Covad Communications 7545 1984 1876 TPG Internet Pty Ltd 1785 1992 1868 PaeTec Communications, Inc. 22773 1979 1854 Cox Communications, Inc. 8402 1787 1771 Corbina telecom 7029 1973 1762 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 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.46.0/23 39743 Mobimax Telecom SRL 128.0.52.0/24 60906 NETOPIA SRL 128.0.53.0/24 60993 Totalsoft SA 128.0.54.0/24 60972 Carpatair SA 128.0.57.0/24 60993 Totalsoft SA 128.0.58.0/23 9050 RTD-ROMTELECOM Autonomous Sys 128.0.60.0/24 9050 RTD-ROMTELECOM Autonomous Sys Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. 64.185.230.0/24 27431 JTL Networks Inc. 64.185.231.0/24 27431 JTL Networks Inc. 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:13 /10:30 /11:88 /12:249 /13:483 /14:895 /15:1581 /16:12669 /17:6643 /18:11170 /19:22240 /20:32135 /21:34322 /22:47650 /23:42441 /24:239067 /25:1304 /26:1665 /27:850 /28:47 /29:63 /30:18 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2017 2066 Covad Communications 6389 1733 3018 bellsouth.net, inc. 7029 1526 1973 Windstream Communications Inc 8402 1479 1787 Corbina telecom 22773 1287 1979 Cox Communications, Inc. 36998 1231 1237 MOBITEL 30036 1197 1327 Mediacom Communications Corp 11492 1194 1234 Cable One 1785 1063 1992 PaeTec Communications, Inc. 6983 1008 1134 ITC^Deltacom Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:801 2:797 3:3 4:15 5:888 6:8 8:554 12:1906 13:3 14:828 15:11 16:3 17:9 20:17 23:274 24:1764 27:1479 31:1291 32:57 33:2 34:5 36:28 37:1864 38:876 39:2 40:172 41:2782 42:192 44:6 46:1917 47:2 49:588 50:704 52:12 54:33 55:7 57:26 58:1193 59:570 60:313 61:1404 62:1110 63:2037 64:4351 65:2180 66:4371 67:2060 68:1131 69:3310 70:879 71:527 72:1921 74:2568 75:406 76:305 77:1109 78:1047 79:591 80:1262 81:989 82:624 83:570 84:534 85:1165 86:461 87:982 88:539 89:1765 90:144 91:5483 92:593 93:1700 94:1839 95:1504 96:514 97:344 98:1028 99:41 100:30 101:332 103:2634 105:519 106:92 107:209 108:518 109:1824 110:888 111:1035 112:510 113:800 114:719 115:1022 116:931 117:796 118:1075 119:1300 120:435 121:730 122:1805 123:1229 124:1354 125:1375 128:643 129:221 130:324 131:648 132:334 133:149 134:267 135:66 136:221 137:261 138:344 139:186 140:208 141:326 142:548 143:371 144:481 145:93 146:510 147:392 148:682 149:374 150:158 151:568 152:416 153:199 154:43 155:395 156:264 157:398 158:278 159:730 160:338 161:430 162:427 163:218 164:594 165:497 166:279 167:590 168:1031 169:129 170:1028 171:180 172:21 173:1663 174:582 175:483 176:1091 177:1982 178:1855 179:6 180:1461 181:401 182:1198 183:386 184:675 185:463 186:2272 187:1284 188:2140 189:1321 190:6363 192:6634 193:5860 194:4591 195:3425 196:1362 197:910 198:4434 199:5304 200:5910 201:2252 202:8914 203:8902 204:4504 205:2567 206:2840 207:2903 208:4052 209:3627 210:2984 211:1518 212:2198 213:1923 214:902 215:98 216:5238 217:1609 218:618 219:330 220:1261 221:558 222:318 223:483 End of report From gabe at teksavvy.ca Fri May 24 19:32:56 2013 From: gabe at teksavvy.ca (Gabriel Blanchard) Date: Fri, 24 May 2013 15:32:56 -0400 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: <8EC20B64-77CF-4BE5-82CF-8BC2131573C6@mnet.bg> <2d2fe94d32c4536cc2033699c740119e@jonesy.com.au> Message-ID: <519FC068.2090509@teksavvy.ca> On 13-05-24 03:17 PM, Ryan Gard wrote: > Do you have a source on this? Reason I ask is because any recent > documentation I've come across indicates that polling is recommended to > reduce chances of livelock on a running system. This depends a *ton* of what NIC you are using. Polling IMO should not be enabled on modern NICs. They use MSI-X to distribute interrupts to each core through the PCI bus to the APIC. As well as various methods to reduce the number of interrupts generated per second. This polling thing only worked well 10years ago. (Or if you still have 10 year old gear) -Gabe From nick at foobar.org Fri May 24 19:35:54 2013 From: nick at foobar.org (Nick Hilliard) Date: Fri, 24 May 2013 20:35:54 +0100 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: <201305241921.r4OJL75f031941@aurora.sol.net> References: <201305241921.r4OJL75f031941@aurora.sol.net> Message-ID: <519FC11A.70300@foobar.org> On 24/05/2013 20:21, Joe Greco wrote: > Luigi did the polling stuff more than a decade ago. Polling fixes some > issues and seems to cause others. interrupt mitigation helps more than polling these days. Make sure you're using modern hardware. Nick From symack at gmail.com Fri May 24 20:35:46 2013 From: symack at gmail.com (Nick Khamis) Date: Fri, 24 May 2013 16:35:46 -0400 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: <519FC11A.70300@foobar.org> References: <201305241921.r4OJL75f031941@aurora.sol.net> <519FC11A.70300@foobar.org> Message-ID: +1 on the interrupt cpu assignment.... N. On 5/24/13, Nick Hilliard wrote: > On 24/05/2013 20:21, Joe Greco wrote: >> Luigi did the polling stuff more than a decade ago. Polling fixes some >> issues and seems to cause others. > > interrupt mitigation helps more than polling these days. Make sure you're > using modern hardware. > > Nick > > > From symack at gmail.com Fri May 24 20:36:06 2013 From: symack at gmail.com (Nick Khamis) Date: Fri, 24 May 2013 16:36:06 -0400 Subject: High throughput bgp links using gentoo + stipped kernel In-Reply-To: References: <201305241921.r4OJL75f031941@aurora.sol.net> <519FC11A.70300@foobar.org> Message-ID: Sorry for the top post!!! N. From jra at baylink.com Fri May 24 21:14:06 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 24 May 2013 17:14:06 -0400 (EDT) Subject: ADVANCE WARNING: Google moving to 2048-bit SSL and root keys In-Reply-To: <20130524205240.GB533@vortex.com> Message-ID: <27222114.6344.1369430046519.JavaMail.root@benjamin.baylink.com> Via PRIVACY Forum: ----- Forwarded Message ----- > From: "PRIVACY Forum mailing list" > Google moving to longer SSL keys > > http://j.mp/10YAWaC (Google Online Security Blog) > > "This encryption needs to be updated at times to make it even > stronger, so this year our SSL services will undergo a series of > certificate upgrades-specifically, all of our SSL certificates > will be upgraded to 2048-bit keys by the end of 2013. We will > begin switching to the new 2048-bit certificates on August 1st, to > ensure adequate time for a careful rollout before the end of the > year. We're also going to change the root certificate that signs > all of our SSL certificates because it has a 1024-bit key." > > - - - > > I will note, however, that given the fundamental weaknesses in the > PKI -- especially relating to certificate authorities in general -- > even longer keys will not solve intrinsic problems that must be faced. > > --Lauren-- > Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren > _______________________________________________ > privacy mailing list > http://lists.vortex.com/mailman/listinfo/privacy Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From cidr-report at potaroo.net Fri May 24 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 May 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201305242200.r4OM00pJ021544@wattle.apnic.net> This report has been generated at Fri May 24 21:13:21 2013 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 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 17-05-13 456674 260287 18-05-13 456618 259718 19-05-13 456593 259863 20-05-13 456601 260071 21-05-13 456490 260473 22-05-13 456760 260482 23-05-13 457215 261060 24-05-13 457343 260436 AS Summary 44264 Number of ASes in routing system 18329 Number of ASes announcing only one prefix 3018 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116962272 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 24May13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 457303 260379 196924 43.1% All ASes AS6389 3018 83 2935 97.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2768 557 2211 79.9% NET Servi?os de Comunica??o S.A. AS4766 2962 942 2020 68.2% KIXS-AS-KR Korea Telecom AS17974 2513 563 1950 77.6% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 1979 131 1848 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 2631 788 1843 70.0% Telmex Colombia S.A. AS18566 2066 474 1592 77.1% COVAD - Covad Communications Co. AS4755 1733 208 1525 88.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7303 1727 453 1274 73.8% Telecom Argentina S.A. AS4323 1611 406 1205 74.8% TWTC - tw telecom holdings, inc. AS2118 1260 86 1174 93.2% RELCOM-AS OOO "NPO Relcom" AS7552 1167 180 987 84.6% VIETEL-AS-AP Vietel Corporation AS36998 1237 301 936 75.7% SDN-MOBITEL AS18881 951 26 925 97.3% Global Village Telecom AS18101 1000 180 820 82.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS9808 814 60 754 92.6% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS1785 1992 1242 750 37.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1133 386 747 65.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS8402 1753 1007 746 42.6% CORBINA-AS OJSC "Vimpelcom" AS13977 845 138 707 83.7% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 742 56 686 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS22561 1178 504 674 57.2% DIGITAL-TELEPORT - Digital Teleport Inc. AS8151 1266 597 669 52.8% Uninet S.A. de C.V. AS7029 2071 1409 662 32.0% WINDSTREAM - Windstream Communications Inc AS6983 1134 478 656 57.8% ITCDELTA - ITC^Deltacom AS24560 1069 413 656 61.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS15003 798 158 640 80.2% NOBIS-TECH - Nobis Technology Group, LLC AS7545 1987 1357 630 31.7% TPG-INTERNET-AP TPG Telecom Limited AS17676 733 110 623 85.0% GIGAINFRA Softbank BB Corp. AS3549 1064 444 620 58.3% GBLX Global Crossing Ltd. Total 47202 13737 33465 70.9% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.197.36.0/22 AS43359 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.111.111.0/24 AS8039 CCC-ASN-1 - Cinergy Communications 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.138.128.0/20 AS32738 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.52.192.0/24 AS27919 190.52.193.0/24 AS27919 190.52.194.0/24 AS27919 190.52.195.0/24 AS27919 190.52.196.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.197.0/24 AS27919 190.52.198.0/24 AS27919 190.52.199.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.200.0/24 AS27947 Telconet S.A 190.52.201.0/24 AS27947 Telconet S.A 190.52.202.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.203.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.205.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.206.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.207.0/24 AS3549 GBLX Global Crossing Ltd. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 200.107.248.0/24 AS27919 200.107.249.0/24 AS27919 200.107.250.0/24 AS27919 200.107.251.0/24 AS27919 200.107.252.0/24 AS28006 CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 200.107.253.0/24 AS27919 200.107.254.0/24 AS27919 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 201.222.32.0/20 AS27821 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.70.56.0/21 AS32738 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.209.67.0/24 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.127.192.0/24 AS22166 216.127.193.0/24 AS22166 216.127.194.0/24 AS22166 216.127.195.0/24 AS22166 216.127.196.0/24 AS22166 216.127.196.64/26 AS22166 216.127.197.0/24 AS22166 216.127.198.0/24 AS22166 216.127.199.0/24 AS22166 216.127.200.0/24 AS22166 216.127.201.0/24 AS22166 216.127.202.0/24 AS22166 216.127.203.0/24 AS22166 216.127.204.0/24 AS22166 216.127.205.0/24 AS22166 216.127.206.0/24 AS22166 216.127.207.0/24 AS22166 216.127.208.0/24 AS22166 216.127.209.0/24 AS22166 216.127.210.0/24 AS22166 216.127.211.0/24 AS22166 216.127.212.0/24 AS22166 216.127.213.0/24 AS22166 216.127.214.0/24 AS22166 216.127.215.0/24 AS22166 216.127.216.0/24 AS22166 216.127.217.0/24 AS22166 216.127.218.0/24 AS22166 216.127.219.0/24 AS22166 216.127.220.0/24 AS22166 216.127.221.0/24 AS22166 216.127.222.0/24 AS22166 216.127.223.0/24 AS22166 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 May 24 22:00:02 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 May 2013 22:00:02 GMT Subject: BGP Update Report Message-ID: <201305242200.r4OM02GW021559@wattle.apnic.net> BGP Update Report Interval: 16-May-13 -to- 23-May-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS36998 176470 7.2% 208.6 -- SDN-MOBITEL 2 - AS9829 54002 2.2% 50.4 -- BSNL-NIB National Internet Backbone 3 - AS8402 36213 1.5% 38.3 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS5800 30402 1.2% 124.6 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 5 - AS2708 27616 1.1% 358.6 -- Universidad de Guanajuato 6 - AS4538 24503 1.0% 47.0 -- ERX-CERNET-BKB China Education and Research Network Center 7 - AS28573 22778 0.9% 6.1 -- NET Servi?os de Comunica??o S.A. 8 - AS15003 21085 0.8% 46.5 -- NOBIS-TECH - Nobis Technology Group, LLC 9 - AS17974 19423 0.8% 8.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 10 - AS45899 19103 0.8% 53.8 -- VNPT-AS-VN VNPT Corp 11 - AS31148 18670 0.8% 23.4 -- FREENET-AS Freenet Ltd. 12 - AS29049 17051 0.7% 50.1 -- DELTA-TELECOM-AS Delta Telecom LTD. 13 - AS3909 16639 0.7% 2773.2 -- QWEST-AS-3908 - Qwest Communications Company, LLC 14 - AS27738 16172 0.7% 28.2 -- Ecuadortelecom S.A. 15 - AS9416 16116 0.7% 322.3 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 16 - AS34744 14185 0.6% 20.5 -- GVM S.C. GVM SISTEM 2003 S.R.L. 17 - AS10620 13434 0.5% 5.6 -- Telmex Colombia S.A. 18 - AS33776 13205 0.5% 71.8 -- STARCOMMS-ASN 19 - AS2118 12887 0.5% 9.6 -- RELCOM-AS OOO "NPO Relcom" 20 - AS7552 11716 0.5% 20.6 -- VIETEL-AS-AP Vietel Corporation TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6629 7314 0.3% 7314.0 -- NOAA-AS - NOAA 2 - AS8137 4782 0.2% 4782.0 -- DISNEYONLINE-AS - Disney Online 3 - AS42334 3956 0.2% 3956.0 -- BBP-AS Broadband Plus s.a.l. 4 - AS16608 7197 0.3% 3598.5 -- KENTEC - Kentec Communications, Inc. 5 - AS6174 5973 0.2% 2986.5 -- SPRINTLINK8 - Sprint 6 - AS3909 16639 0.7% 2773.2 -- QWEST-AS-3908 - Qwest Communications Company, LLC 7 - AS44971 5538 0.2% 2769.0 -- GOETEC-AS GOETEC Limited 8 - AS22356 9156 0.4% 2289.0 -- Durand do Brasil Ltda 9 - AS19406 4506 0.2% 2253.0 -- TWRS-MA - Towerstream I, Inc. 10 - AS36948 4319 0.2% 2159.5 -- KENIC 11 - AS14680 6434 0.3% 2144.7 -- REALE-6 - Auction.com 12 - AS27735 8332 0.3% 2083.0 -- Synapsis Soluciones y Servicios IT LTDA 13 - AS60924 1897 0.1% 1897.0 -- ORIXCOM Orixcom JLT 14 - AS37318 1390 0.1% 1390.0 -- BESA 15 - AS33920 2605 0.1% 1302.5 -- AQL (aq) Networks Limited 16 - AS60811 1283 0.1% 1283.0 -- SAIPAYADAH-AS Saipa Yadak Co. PLC 17 - AS22688 1173 0.1% 1173.0 -- DOLGENCORP - Dollar General Corporation 18 - AS37367 1984 0.1% 992.0 -- CALLKEY 19 - AS33922 9575 0.4% 957.5 -- NTT-LT-AS UAB Nacionalinis Telekomunikaciju Tinklas 20 - AS15947 1450 0.1% 725.0 -- CCBISP-AS Cork Community Broadband Limited TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 88.216.171.0/24 9539 0.4% AS33922 -- NTT-LT-AS UAB Nacionalinis Telekomunikaciju Tinklas 2 - 193.19.90.0/23 9089 0.3% AS29684 -- NOURNET-ASN Nour Communication Co.Ltd - Nournet 3 - 206.48.139.0/24 8326 0.3% AS27735 -- Synapsis Soluciones y Servicios IT LTDA 4 - 92.246.207.0/24 8291 0.3% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 5 - 203.118.232.0/21 7976 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 6 - 203.118.224.0/21 7954 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 7 - 192.58.232.0/24 7314 0.3% AS6629 -- NOAA-AS - NOAA 8 - 194.219.56.0/24 5658 0.2% AS1241 -- FORTHNET-GR Forthnet 9 - 151.118.255.0/24 5537 0.2% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 10 - 151.118.254.0/24 5537 0.2% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 11 - 151.118.18.0/24 5520 0.2% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 12 - 12.139.133.0/24 5330 0.2% AS14680 -- REALE-6 - Auction.com 13 - 5.56.48.0/21 5093 0.2% AS44971 -- GOETEC-AS GOETEC Limited 14 - 209.240.40.0/21 4916 0.2% AS32020 -- TRANSACT-BM-ASN - Transact Ltd. 15 - 198.187.189.0/24 4782 0.2% AS8137 -- DISNEYONLINE-AS - Disney Online 16 - 173.232.234.0/24 4673 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 17 - 173.232.235.0/24 4670 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 18 - 189.124.96.0/20 4593 0.2% AS22356 -- Durand do Brasil Ltda 19 - 200.160.200.0/21 4525 0.2% AS22356 -- Durand do Brasil Ltda 20 - 69.38.178.0/24 4503 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 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 shortdudey123 at gmail.com Sat May 25 01:04:16 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Fri, 24 May 2013 20:04:16 -0500 Subject: Mailman reverting settings In-Reply-To: References: Message-ID: Hi, I received a couple offlist replies. To answer Phil's questions, iptables appeared to have spiked the cpu to 100% and caused it to overload and become unresponsive. Var was lot filled up to my knowledge. An offlist reply suggested that if the config.pck file gets corrupted, then mailman will revert to using an old config.db file. After doing a file level restore of the appropriate config.pck file, the list returned to normal. Thanks, Grant On Fri, May 24, 2013 at 9:23 AM, Phil Fagan wrote: > What hung the box? Core dump? Filled up var? > On May 23, 2013 11:57 AM, "Grant Ridder" wrote: > >> Hi Everyone, >> >> Has anyone ever seen Mailman revert to an old user list? This morning we >> had out lists VM pounded on from India and hung the box. After blocking >> the ip on our firewall and rebooting the hung vm, everything came back up >> except 1 list. The list appears to have reverted to old settings. I >> found >> the config.pck file and it does not have the current settings in it. This >> has happened once before. The box is running Ubuntu 10.04 and Mailman >> 2.1.13. Anyone know what would cause this and how to fix it? We are >> working to try a file level restore from a backup. >> >> Thanks, >> Grant >> >> ~~~~~~~~~~ >> >> Grant Ridder >> >> Assistant Systems Administrator >> >> Milwaukee School of Engineering >> > From mysidia at gmail.com Sat May 25 01:34:26 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 24 May 2013 20:34:26 -0500 Subject: ADVANCE WARNING: Google moving to 2048-bit SSL and root keys In-Reply-To: <27222114.6344.1369430046519.JavaMail.root@benjamin.baylink.com> References: <20130524205240.GB533@vortex.com> <27222114.6344.1369430046519.JavaMail.root@benjamin.baylink.com> Message-ID: On 5/24/13, Jay Ashworth wrote: Hm.. this might be no big deal if not for public key pinning and CA pinning in modern browsers of certain sites, they could just get themselves 2048 bit certificates from any CA... So what could otherwise be a routine certificate change, may have some unusual extra baggage attached to it -- requiring end users performing software code update in their only slightly outdated browsers, instead of just switching certificates, so they stop getting big red SSL errors when trying to perform searches via Google... > Via PRIVACY Forum: > > ----- Forwarded Message ----- >> From: "PRIVACY Forum mailing list" > >> Google moving to longer SSL keys >> >> http://j.mp/10YAWaC (Google Online Security Blog) -- -JH From ryangard at gmail.com Sat May 25 06:37:00 2013 From: ryangard at gmail.com (Ryan Gard) Date: Sat, 25 May 2013 02:37:00 -0400 Subject: ADVANCE WARNING: Google moving to 2048-bit SSL and root keys In-Reply-To: References: <20130524205240.GB533@vortex.com> <27222114.6344.1369430046519.JavaMail.root@benjamin.baylink.com> Message-ID: >From what it looks like, I'd assume they'll be sticking with a CA that has a 2048 bit certificate as well. Seems they also put a sandbox for testing together. That being said, they won't confirm or deny whether or not they'll be using the same CA as they have in the sandbox... https://cert-test.sandbox.google.com/ On Fri, May 24, 2013 at 9:34 PM, Jimmy Hess wrote: > On 5/24/13, Jay Ashworth wrote: > > > Hm.. this might be no big deal if not for public key pinning and CA > pinning in modern browsers of certain sites, they could just get > themselves 2048 bit certificates from any CA... > > So what could otherwise be a routine certificate change, may have some > unusual extra baggage attached to it -- requiring end users performing > software code update in their only slightly outdated browsers, > instead of just switching certificates, so they stop getting big red > SSL errors when trying to perform searches via Google... > > > > Via PRIVACY Forum: > > > > ----- Forwarded Message ----- > >> From: "PRIVACY Forum mailing list" > > > >> Google moving to longer SSL keys > >> > >> http://j.mp/10YAWaC (Google Online Security Blog) > > -- > -JH > > -- Ryan Gard From jcurran at arin.net Sat May 25 10:44:01 2013 From: jcurran at arin.net (John Curran) Date: Sat, 25 May 2013 10:44:01 +0000 Subject: Geoip lookup In-Reply-To: <3479A4BC-33D4-433C-A37B-99A2F83EBDB6@virtualized.org> References: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> <78F7BBF3-C10D-44CD-ABF1-96EB506E4D40@delong.com> <20130524064941.GF23438@vacation.karoshi.com> <87F5A01F-7283-4EEE-B076-E18C710B5C9D@delong.com> <3479A4BC-33D4-433C-A37B-99A2F83EBDB6@virtualized.org> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FDFE258@CHAXCH01.corp.arin.net> On May 24, 2013, at 10:47 AM, David Conrad wrote: > I replied privately to Owen, but might as well share: > > On May 23, 2013, at 11:57 PM, Owen DeLong wrote: >>>>> True, according to (at least some of) the RIRs they reside in regions... >>>> Really? Which ones? I thought they were only issued to organizations that had operations in regions. >> That was exactly my point, Bill... If you have operations in RIPE and ARIN regions, it is entirely possible for you to obtain addresses from RIPE or ARIN and use them in both locations, or, obtain addresses from both RIPE and ARIN and use them in their respective regions, or mix and match in just about any imaginable way. Thus, IP addresses don't reside in regions, either. They are merely issued somewhat regionally. > > A direct quote from a recent interaction with ARIN (this was requested by ARIN staff as part of the back and forth for requesting address space): > > "Please reply and verify that you will be using the requested number resources within the ARIN region and announcing all routing prefixes of the requested space from within the ARIN region. In accordance with section 2.2 of the NRPM, ARIN issues number resources only for use within its region. ARIN is therefore only able to provide for your in-region numbering needs." > > I believe AfriNIC and LACNIC have similar limitations on use but am too lazy to look it up (and I don't really care all that much: just thought it was amusing). Indeed. This was covered in more detail in the Policy Experience Report given at the ARIN 31, in which it was noted that we are seeing an increase in requests for IPv4 address space from parties who have infrastructure in the region, but for customers entirely from outside the region. This has resulted in a significant change in the issuance rate and therefore any estimates for regional free pool depletion. ARIN has sought guidance from the community regarding what constitutes appropriate in-region use, should this be based on infrastructure or served customers, and whether incidental use outside the region is appropriate. (This topic was also on this list on 26 April 2012 - see attached email from that thread) Policy proposals in this area to bring further clarity in address management are encouraged. FYI, /John John Curran President and CEO ARIN === Begin forwarded message: > From: John Curran > Subject: Re: "It's the end of the world as we know it" -- REM > Date: April 26, 2013 10:43:51 AM EDT > To: "nanog at nanog.org Group" > > On Apr 26, 2013, at 10:23 AM, Chris Grundemann wrote: >> >> One interesting twist in all of this is that several of these new >> "slow-start" players in the ARIN region seem to be servicing customers >> outside of the region with equipment and services hosted here inside >> the ARIN region (see slide 12 on the ARIN 31 "Policy Implementation >> and Experience Report" >> https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf). > > NANOG Folks - > > Please read this slide deck, section noted by Chris. It explains the > "situation"... (I would not call the sudden acceleration in IP address > issuance a problem, per se, as that is an judgement for the community > either way.) > > FYI, > /John > > John Curran > President and CEO > ARIN From jwbensley at gmail.com Sat May 25 12:09:10 2013 From: jwbensley at gmail.com (James Bensley) Date: Sat, 25 May 2013 13:09:10 +0100 Subject: Network Research Message-ID: Hello everyone, I am performing some research on networking at present and want the input of the community and industry at large. I have created a small on-line survey and would be very grateful to anyone that could give 3 minutes to fill it out. You will be benefiting networking research so I'm sure you are all wanting to participate; The survey is here: https://docs.google.com/forms/d/1lqigAHYHEgLLHr2kifiyBwgJ9Nw5AFS6d_XVXfhKkTw/viewform All results will be anonymised when published. If you want a copy of the anonymised results, or have any queries about the research or the survey, please email me off-list to save on-list noise. Kind regards, James P.S. Apologies if you are on multiple mailing lists and receive this email multiple times! From jeroen at massar.ch Sat May 25 12:55:10 2013 From: jeroen at massar.ch (Jeroen Massar) Date: Sat, 25 May 2013 14:55:10 +0200 Subject: Network Research In-Reply-To: References: Message-ID: <51A0B4AE.7080302@massar.ch> On 2013-05-25 14:09, James Bensley wrote: > Hello everyone, > > I am performing some research on networking at present and want the > input of the community and industry at large. I have created a small > on-line survey and would be very grateful to anyone that could give 3 > minutes to fill it out. You will be benefiting networking research so Networking "research" for which organization? > I'm sure you are all wanting to participate; > > The survey is here: > https://docs.google.com/forms/d/1lqigAHYHEgLLHr2kifiyBwgJ9Nw5AFS6d_XVXfhKkTw/viewform > > All results will be anonymised when published. Published how and where and for what purpose? Greets, Jeroen From jwbensley at gmail.com Sat May 25 13:56:54 2013 From: jwbensley at gmail.com (James Bensley) Date: Sat, 25 May 2013 14:56:54 +0100 Subject: Network Research In-Reply-To: <51A0B4AE.7080302@massar.ch> References: <51A0B4AE.7080302@massar.ch> Message-ID: On 25 May 2013 13:55, Jeroen Massar wrote: > Networking "research" for which organization? I am currently undertaking a research project for a masters degree in advanced networking, with The Open University, in the UK. I am researching for no company. I intend to conduct the research as part of my dissertation, then upload my dissertation containing the research results, for all and sundry to freely read and distribute (if it interests them!). Hopefully it will, and more importantly, I hope it will be beneficial to someone, and an educational read. >> All results will be anonymised when published. > > Published how and where and for what purpose? In its simplest form, I will upload the the dissertation to the Internet and send the link round, so that anyone who wants to, can, read it. "Published" Is the wrong word there I suppose, as in research terms "published" often means published in a journal article, for example. I simply meant "published" as in "realising the information", "disseminating it to the general populous". Although, I will be trying to find someone to publish it it in the true sense, although I'm not counting my chickens (if anyone is interested, drop me an email off-list). Cheers, James. From andrius at andrius.org Sat May 25 14:34:34 2013 From: andrius at andrius.org (Andrius Kazimieras =?utf-8?Q?Kasparavi=C4=8Dius?=) Date: Sat, 25 May 2013 17:34:34 +0300 Subject: leasing/managed offices in London, UK with 10gbe carriers POPs? Message-ID: <20130525143434.GA23737@diedas.soften.ktu.lt> Hi, I was going through this database[1] looking for office facilities/buildings with 10gbe carriers POPs already present, but only datacentres are listed. My requirement is low cost 10gbe connectivity to any London datacentre where I could either get either low-cost few racks hosting+partial transit.. Well multiple 1gig links might be ok too. I am sure there are already large office blocks with multiple 10gbe carrier POPs or am I? Maybe it is possible to save costs and time by choosing office with built-in good connectivity rather than wait months and multiple permits to dig the road etc..? [1] https://www.peeringdb.com/private/facility_list.php Thanks, From jra at baylink.com Sat May 25 16:01:10 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 25 May 2013 12:01:10 -0400 (EDT) Subject: Mail contact needed at CenturyLink.com Message-ID: <1571331.6400.1369497670171.JavaMail.root@benjamin.baylink.com> The Outages list is receiving hard bounces from *some* email address hosted at Qwest/Centurylink. Alas, the bounce message comes from "qwestrsp at centurylink.com", and neither the headers nor the message body *identifies the invalid address*. This does not seem to conform with best practices. :-) If you're in responsible charge of that mail service, could you please contact me off-list, that we might track down who it is, and maybe modify your bouncer to properly include the bounced address? (Side note: what error messages are generate by *code you've written*, folks, that don't include parameters because "they should be obvious to the sender"?) All replies off list, please, this is cross-posted[1]. Cheers, -- jra [1] Why? Because I'm not trying to fix only my own problem. -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From simon at slimey.org Sat May 25 16:58:46 2013 From: simon at slimey.org (Simon Lockhart) Date: Sat, 25 May 2013 17:58:46 +0100 Subject: leasing/managed offices in London, UK with 10gbe carriers POPs? In-Reply-To: <20130525143434.GA23737@diedas.soften.ktu.lt> References: <20130525143434.GA23737@diedas.soften.ktu.lt> Message-ID: <20130525165845.GH27700@virtual.bogons.net> On Sat May 25, 2013 at 05:34:34PM +0300, Andrius Kazimieras Kasparavi??ius wrote: > I am sure there are already large office blocks with multiple > 10gbe carrier POPs or am I? Maybe it is possible to save costs > and time by choosing office with built-in good connectivity > rather than wait months and multiple permits to dig the road > etc..? Unlikely to find managed offices with multiple 10GE connections. In my experience, if they have 1GE shared between all tenants, then you're doing well :) That said, if you talk to the people with lots of fibre around London (Geo, Zayo/Abovenet, Level3, etc), then you will probably find that you can pick up a metro dark fibre hop back to one of the major datacentres for not too much money. If you shop around carefully, you may find that they have buildings that they're either in, or immediately outside of, and digs won't be a major issue. Simon -- Simon Lockhart | * Server Co-location * ADSL * Domain Registration * Director | * Domain & Web Hosting * Connectivity * Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From jra at baylink.com Sat May 25 16:42:47 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 25 May 2013 12:42:47 -0400 (EDT) Subject: Inventory and workflow management systems In-Reply-To: Message-ID: <5195490.6408.1369500167296.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Christopher Morrow" > On Sun, May 19, 2013 at 1:21 PM, vijay gill > wrote: > > Resurrecting this thread. Anyone? > > What software solution do people use for inventory management for > > things > > like riser/conduit drawdown, fiber inventory, physical topology > > store, > > CLR/DLR, x-connect, contracts, port inventory, etc. > > Any experiences in integrating workflow into those packages for work > > orders, modeling, drawdown levels, etc. > > isn't it odd/lame that in many cases the answer to this is 'build your > own' ? In fact, I don't think it's all that odd. Ontology recapitulates phylology, as they say, and *all* carriers are sui generis these days, excepting possibly what's left of the RBOCs. So it's probably not all that surprising that there's no "template" to fit them into; the software has to be bolted on around the systems, rather than otherwise. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mysidia at gmail.com Sun May 26 04:23:45 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 25 May 2013 23:23:45 -0500 Subject: Inventory and workflow management systems In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC048610C7F@USIDCWVEMBX10.corp.global.level3.com> References: <21ef2c1c0804041416w28aac3d1la30c3ad5e1b91129@mail.gmail.com> <970945E55BFD8C4EA4CAD74B647A9DC048610C7F@USIDCWVEMBX10.corp.global.level3.com> Message-ID: On 5/21/13, Siegel, David wrote: > Off the shelf stuff? There are lots of options, but it seems like the > general opinion of the IT groups I've worked with is that it's just as much > work to customize and integrate them as it is to write from scratch so we > tend to get further way from COTS all the time. Unless the requirement is quite trivial, or the usage quite small.. I would question 'write everything from scratch' -- now custom code for integrations makes sense; it doesn't make sense for every company to become a software company though and custom code all the bits of their systems, instead of customizing and reusing proven code. A solution implemented with mature OTS components doing all the heavy lifting may be more robust, if good choices were made. Customizing and integrating OTS components may be hard; once you do, you worry only about maintaining customizations and integrations. Chances are you get vendor support and well-tested software. :) That is, if the integrations/customizations made are supported ones, available through configuration of the software. With totally custom coded software, the org bears an ongoing burden of software reliability testing, for all the custom components. When one finds custom software cheaper than an OTS solution... one should probably ask... was ongoing testing, support, updates/security patches, and maintenance included? In other words... did the IT group just count the Initial cost to implement, or did they actually figure out a TCO, including changes to the custom software later required to solve scalability issues? The answer in some cases may be to figure out what products might fit the need/requirement in the most general sense, and find a consulting group adept with whichever products, rather than a local IT group. :) I am sure there are plenty of inventory management and accounting type products out in the world, able to be adapted for the unique requirements of inventorying different kinds of things. Chop up the problem sufficiently into bite-sized pieces, and I believe there are bound to be existing OTS options more useful than a spreadsheet. -- -JH From ag4ve.us at gmail.com Sun May 26 04:26:48 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 26 May 2013 00:26:48 -0400 Subject: Geoip lookup In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FDFE258@CHAXCH01.corp.arin.net> References: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> <78F7BBF3-C10D-44CD-ABF1-96EB506E4D40@delong.com> <20130524064941.GF23438@vacation.karoshi.com> <87F5A01F-7283-4EEE-B076-E18C710B5C9D@delong.com> <3479A4BC-33D4-433C-A37B-99A2F83EBDB6@virtualized.org> <8DA1853CE466B041B104C1CAEE00B3748FDFE258@CHAXCH01.corp.arin.net> Message-ID: If anyone is interrested, here's a little Perl CLI util to lookup what countries registered networks within a block. There's no documentation yet, it's a .pl where it should probably be a command with a makefile installer, and Net::CIDR overlaps Net::IP. At any rate, hopefully it is useful to someone. https://github.com/ag4ve/geocidr PS - do note the -mask option (where you can define say, a 20 or 21 or 22) so that you're not sitting there banging on their DNS looking up tons of /32s for blocks CYMRU doesn't have any information on. On Sat, May 25, 2013 at 6:44 AM, John Curran wrote: > On May 24, 2013, at 10:47 AM, David Conrad wrote: > >> I replied privately to Owen, but might as well share: >> >> On May 23, 2013, at 11:57 PM, Owen DeLong wrote: >>>>>> True, according to (at least some of) the RIRs they reside in regions... >>>>> Really? Which ones? I thought they were only issued to organizations that had operations in regions. >>> That was exactly my point, Bill... If you have operations in RIPE and ARIN regions, it is entirely possible for you to obtain addresses from RIPE or ARIN and use them in both locations, or, obtain addresses from both RIPE and ARIN and use them in their respective regions, or mix and match in just about any imaginable way. Thus, IP addresses don't reside in regions, either. They are merely issued somewhat regionally. >> >> A direct quote from a recent interaction with ARIN (this was requested by ARIN staff as part of the back and forth for requesting address space): >> >> "Please reply and verify that you will be using the requested number resources within the ARIN region and announcing all routing prefixes of the requested space from within the ARIN region. In accordance with section 2.2 of the NRPM, ARIN issues number resources only for use within its region. ARIN is therefore only able to provide for your in-region numbering needs." >> >> I believe AfriNIC and LACNIC have similar limitations on use but am too lazy to look it up (and I don't really care all that much: just thought it was amusing). > > Indeed. This was covered in more detail in the Policy Experience Report > given at the ARIN 31, in which it was noted that we are seeing an increase > in requests for IPv4 address space from parties who have infrastructure in > the region, but for customers entirely from outside the region. This has > resulted in a significant change in the issuance rate and therefore any > estimates for regional free pool depletion. ARIN has sought guidance from > the community regarding what constitutes appropriate in-region use, should > this be based on infrastructure or served customers, and whether incidental > use outside the region is appropriate. (This topic was also on this list on > 26 April 2012 - see attached email from that thread) Policy proposals in > this area to bring further clarity in address management are encouraged. > > FYI, > /John > > John Curran > President and CEO > ARIN > > === > Begin forwarded message: > >> From: John Curran >> Subject: Re: "It's the end of the world as we know it" -- REM >> Date: April 26, 2013 10:43:51 AM EDT >> To: "nanog at nanog.org Group" >> >> On Apr 26, 2013, at 10:23 AM, Chris Grundemann wrote: >>> >>> One interesting twist in all of this is that several of these new >>> "slow-start" players in the ARIN region seem to be servicing customers >>> outside of the region with equipment and services hosted here inside >>> the ARIN region (see slide 12 on the ARIN 31 "Policy Implementation >>> and Experience Report" >>> https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf). >> >> NANOG Folks - >> >> Please read this slide deck, section noted by Chris. It explains the >> "situation"... (I would not call the sudden acceleration in IP address >> issuance a problem, per se, as that is an judgement for the community >> either way.) >> >> FYI, >> /John >> >> John Curran >> President and CEO >> ARIN > > > > From jason.sherron at microsoft.com Sun May 26 20:21:27 2013 From: jason.sherron at microsoft.com (Jason Sherron) Date: Sun, 26 May 2013 20:21:27 +0000 Subject: Inventory and workflow management systems In-Reply-To: References: <21ef2c1c0804041416w28aac3d1la30c3ad5e1b91129@mail.gmail.com> Message-ID: <5a586c3a10a84c51b83bcea42c4c0e0e@DFM-TK5MBX15-08.exchange.corp.microsoft.com> Not a personal experience or recommend but I've seen Pinnacle used for this purpose. TFA http://www.pinnsoft.com/services/operations-management.html Infrastructure Manager allows you to track every element of your communications infrastructure, from the outside and inside cable plant to the port assignment and availability of every network provisioning device. Just as important, Infrastructure Manager ensures that all records are immediately updated whether they are modified from inside or outside the service order and incident management process. By maintaining a single, central repository of all documentation, you'll be able to: Establish a centralized framework for documenting your entire infrastructure Eliminate data corruption and reduce the resources required to synchronize disparate records Provide a unified real-time perspective on the status of all communication records Facilitate proactive availability management for all ports and cable plant components Enable cost-effective capacity management Rationalize audits of your communications infrastructure Automate updates and prevent corruption -----Original Message----- From: vijay gill [mailto:vgill at vijaygill.com] Sent: Sunday, May 19, 2013 10:22 AM To: NANOG list Subject: Re: Inventory and workflow management systems Resurrecting this thread. Anyone? What software solution do people use for inventory management for things like riser/conduit drawdown, fiber inventory, physical topology store, CLR/DLR, x-connect, contracts, port inventory, etc. Any experiences in integrating workflow into those packages for work orders, modeling, drawdown levels, etc. On Fri, Apr 4, 2008 at 2:16 PM, vijay gill wrote: > What software solution do people use for inventory management for > things like riser/conduit drawdown, fiber inventory, physical topology > store, CLR/DLR, x-connect, contracts, port inventory, etc. > Any experiences in integrating workflow into those packages for work > orders, modeling, drawdown levels, etc. > > /vijay > > > > From frnkblk at iname.com Mon May 27 02:05:04 2013 From: frnkblk at iname.com (Frank Bulk (iname.com)) Date: Sun, 26 May 2013 21:05:04 -0500 Subject: Geoip lookup In-Reply-To: References: <367EA6A4-927C-4391-8F9A-2F979C0C789B@virtualized.org> <78F7BBF3-C10D-44CD-ABF1-96EB506E4D40@delong.com> <20130524064941.GF23438@vacation.karoshi.com> <87F5A01F-7283-4EEE-B076-E18C710B5C9D@delong.com> <3479A4BC-33D4-433C-A37B-99A2F83EBDB6@virtualized.org> <8DA1853CE466B041B104C1CAEE00B3748FDFE258@CHAXCH01.corp.arin.net> Message-ID: <000001ce5a7e$9ab0a4d0$d011ee70$@iname.com> Here's a few more resources: http://www.ipdeny.com/ipblocks/ http://www.nirsoft.net/countryip/ Frank -----Original Message----- From: shawn wilson [mailto:ag4ve.us at gmail.com] Sent: Saturday, May 25, 2013 11:27 PM To: info at cymru.com Cc: North American Network Operators Group Subject: Re: Geoip lookup If anyone is interrested, here's a little Perl CLI util to lookup what countries registered networks within a block. There's no documentation yet, it's a .pl where it should probably be a command with a makefile installer, and Net::CIDR overlaps Net::IP. At any rate, hopefully it is useful to someone. https://github.com/ag4ve/geocidr PS - do note the -mask option (where you can define say, a 20 or 21 or 22) so that you're not sitting there banging on their DNS looking up tons of /32s for blocks CYMRU doesn't have any information on. On Sat, May 25, 2013 at 6:44 AM, John Curran wrote: > On May 24, 2013, at 10:47 AM, David Conrad wrote: > >> I replied privately to Owen, but might as well share: >> >> On May 23, 2013, at 11:57 PM, Owen DeLong wrote: >>>>>> True, according to (at least some of) the RIRs they reside in regions... >>>>> Really? Which ones? I thought they were only issued to organizations that had operations in regions. >>> That was exactly my point, Bill... If you have operations in RIPE and ARIN regions, it is entirely possible for you to obtain addresses from RIPE or ARIN and use them in both locations, or, obtain addresses from both RIPE and ARIN and use them in their respective regions, or mix and match in just about any imaginable way. Thus, IP addresses don't reside in regions, either. They are merely issued somewhat regionally. >> >> A direct quote from a recent interaction with ARIN (this was requested by ARIN staff as part of the back and forth for requesting address space): >> >> "Please reply and verify that you will be using the requested number resources within the ARIN region and announcing all routing prefixes of the requested space from within the ARIN region. In accordance with section 2.2 of the NRPM, ARIN issues number resources only for use within its region. ARIN is therefore only able to provide for your in-region numbering needs." >> >> I believe AfriNIC and LACNIC have similar limitations on use but am too lazy to look it up (and I don't really care all that much: just thought it was amusing). > > Indeed. This was covered in more detail in the Policy Experience Report > given at the ARIN 31, in which it was noted that we are seeing an increase > in requests for IPv4 address space from parties who have infrastructure in > the region, but for customers entirely from outside the region. This has > resulted in a significant change in the issuance rate and therefore any > estimates for regional free pool depletion. ARIN has sought guidance from > the community regarding what constitutes appropriate in-region use, should > this be based on infrastructure or served customers, and whether incidental > use outside the region is appropriate. (This topic was also on this list on > 26 April 2012 - see attached email from that thread) Policy proposals in > this area to bring further clarity in address management are encouraged. > > FYI, > /John > > John Curran > President and CEO > ARIN > > === > Begin forwarded message: > >> From: John Curran >> Subject: Re: "It's the end of the world as we know it" -- REM >> Date: April 26, 2013 10:43:51 AM EDT >> To: "nanog at nanog.org Group" >> >> On Apr 26, 2013, at 10:23 AM, Chris Grundemann wrote: >>> >>> One interesting twist in all of this is that several of these new >>> "slow-start" players in the ARIN region seem to be servicing customers >>> outside of the region with equipment and services hosted here inside >>> the ARIN region (see slide 12 on the ARIN 31 "Policy Implementation >>> and Experience Report" >>> https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf). >> >> NANOG Folks - >> >> Please read this slide deck, section noted by Chris. It explains the >> "situation"... (I would not call the sudden acceleration in IP address >> issuance a problem, per se, as that is an judgement for the community >> either way.) >> >> FYI, >> /John >> >> John Curran >> President and CEO >> ARIN > > > > From guu at google.com Tue May 28 03:46:33 2013 From: guu at google.com (Yunhong Gu) Date: Mon, 27 May 2013 23:46:33 -0400 Subject: GoDaddy contact? Message-ID: Hello, I wonder if there is anyone from GoDaddy on this list. I am trying to debug a problem between Google Public DNS and some GoDaddy name servers. Please contact me directly at guu at google.com. Thanks, Yunhong From dpcarlton at gmail.com Tue May 28 14:10:59 2013 From: dpcarlton at gmail.com (Dan Carlton) Date: Tue, 28 May 2013 08:10:59 -0600 Subject: Paraguay International Connectivity Questions Message-ID: Looking for some information regarding international connectivity from Paraguay. We are looking to start up a new business down there and we were told that the international connections from Paraguay are not reliable and all of the only external connections from there have go through Argentina. I would assume this would apply to Public Internet as well as private networks (MPLS, etc.). - Is this true? - Does anyone have a map of the external connections from there, similar to the submarine map ? - Or other data (BGP routing tables that would show traffic transiting via Brazil or Bolivia)? - Is the international connectivity really that bad down there? From wbailey at satelliteintelligencegroup.com Tue May 28 15:53:33 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 28 May 2013 15:53:33 +0000 Subject: GoDaddy contact? In-Reply-To: Message-ID: Is there another email?? I know they haves sales at godaddy.com, but I thought that was about it. On 5/27/13 8:46 PM, "Yunhong Gu" wrote: >Hello, I wonder if there is anyone from GoDaddy on this list. I am trying >to debug a problem between Google Public DNS and some GoDaddy name >servers. >Please contact me directly at guu at google.com. > >Thanks, >Yunhong From guu at google.com Tue May 28 16:36:26 2013 From: guu at google.com (Yunhong Gu) Date: Tue, 28 May 2013 12:36:26 -0400 Subject: GoDaddy contact? In-Reply-To: References: Message-ID: Thanks very much for those contacted me off list. I have found the right person already. Yunhong On May 27, 2013 11:46 PM, "Yunhong Gu" wrote: > Hello, I wonder if there is anyone from GoDaddy on this list. I am trying > to debug a problem between Google Public DNS and some GoDaddy name servers. > Please contact me directly at guu at google.com. > > Thanks, > Yunhong > From joly at punkcast.com Wed May 29 02:16:28 2013 From: joly at punkcast.com (Joly MacFie) Date: Tue, 28 May 2013 22:16:28 -0400 Subject: Fwd: ICANN News Alert -- Security Studies on the Use of Non-Delegated TLDs, and Dotless Names Message-ID: FYI, since this has been a topic here. ---------- Forwarded message ---------- http://www.icann.org/en/news/announcements/announcement-28may13-en.htm ________________________________ Security Studies on the Use of Non-Delegated TLDs, and Dotless Names 28 May 2013 ICANN's mission and core values call to preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet. In pursuing these goals and following the direction of its Board of Directors as well as the advice of the Security and Stability Advisory Committee, ICANN is announcing two studies regarding: 1) the use of non-delegated TLDs and 2) potential risks related to dotless domain names. On 31 January 2013, ICANN security team received the SAC 057: SSAC Advisory on Internal Name Certificates. On 18 May, the ICANN Board directed staff to commission a study on the use of TLDs that are not currently delegated at the root level of the public DNS in enterprises. Today, ICANN is announcing that a study has been commissioned on the potential security impacts of the applied-for new-gTLD strings in relation to namespace collisions with non-delegated TLDs that may be in use in private namespaces including their use in X.509 digital certificates. As part of this study, the expert study team will develop a framework for assessing the risk level and classify the risk level for the strings as identified in the study. The report will also provide options for ICANN as to how to mitigate the various risks and will describe the pros and cons of the options. On 23 February 2012, the SSAC published the SAC 053: SSAC Report on Dotless Domains. A domain name that consists of a single label is referred to as a "dotless domain name". Use of dotless names could provide potential innovations to the domain name industry and new gTLD applicants, but their use also raises usability, functionality, security and stability concerns as described in the SSAC report. On 23 June 2012, the ICANN Board directed staff to consult with the relevant communities regarding implementation of the recommendations in SAC 053 and to provide a briefing paper for the Board, detailing the issues and options available to mitigate such issues. During the period of August to September 2012, a public comment period was held regarding the SAC 053 report. The public comment period made clear that dotless domain names are a subject of active discussion in the ICANN community, that no clear conclusion could be drawn, and that a greater effort to identify and explore solutions to the concerns raised before implementing SAC 053 recommendations could be useful. Today, ICANN is announcing that it has commissioned a study on the potential risks related to dotless domain names based on SAC 053 report. The study report will identify and describe the potential risks that dotless names raise with particular focus on those related to security and stability. The report will also provide options for ICANN as to how to mitigate the various risks and will describe the pros and cons of the options. In both cases ICANN intends to deliver the study teams findings before the ICANN 47th meeting in Durban, South Africa. -- --------------------------------------------------------------- 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 sj_hznm at hotmail.com Thu May 30 09:10:21 2013 From: sj_hznm at hotmail.com (Joe) Date: Thu, 30 May 2013 09:10:21 +0000 Subject: why does dail-up or pppoe access always has session-timeout ? Message-ID: hi. a question obsessed me for a long time. "why my pppoe connection to internet has a max session time, even if every thing goes ok? " In our DSL access network , max session timeout is set to 4 days, this parameter is sent to BAS by radius server after finishing authenticating procedure. As I know, beside us some other service providers also applied this parameter to pppoe session, the parameter varies from 48 hours to 96 hours. Reading documents of BAS, we found this is default value for session-time on BAS, that means even if radius server does not response BAS with session-timeout attribute BAS will cut pppoe session after sometime. so , why does those BAS designer or protocol designer set such a parameter for pppoe access ? should anyone do me a favor on explaining this ? regards Joe From freimer at freimer.org Thu May 30 12:32:51 2013 From: freimer at freimer.org (Fred Reimer) Date: Thu, 30 May 2013 12:32:51 +0000 Subject: why does dail-up or pppoe access always has session-timeout ? In-Reply-To: References: Message-ID: Because PPPOE comes from PPP, which was designed for dialup. You typically don't want to leave a dialup connection up forever. Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: Joe Date: 05/30/2013 5:11 AM (GMT-05:00) To: NANOG Subject: why does dail-up or pppoe access always has session-timeout ? hi. a question obsessed me for a long time. "why my pppoe connection to internet has a max session time, even if every thing goes ok? " In our DSL access network , max session timeout is set to 4 days, this parameter is sent to BAS by radius server after finishing authenticating procedure. As I know, beside us some other service providers also applied this parameter to pppoe session, the parameter varies from 48 hours to 96 hours. Reading documents of BAS, we found this is default value for session-time on BAS, that means even if radius server does not response BAS with session-timeout attribute BAS will cut pppoe session after sometime. so , why does those BAS designer or protocol designer set such a parameter for pppoe access ? should anyone do me a favor on explaining this ? regards Joe From josh at zevlag.com Thu May 30 15:04:44 2013 From: josh at zevlag.com (Josh Galvez) Date: Thu, 30 May 2013 09:04:44 -0600 Subject: ipp.gov and Google DNS (8.8.8.8) Message-ID: Google Public DNS (8.8.8.8, 8.8.4.4) is failing to resolve ipp.gov, returning a SERVFAIL. Other DNS servers seem to resolve this just fine (ie. OpenDNS) If I use dig +trace, I get appropriate results all the way down. DNSSEC seems to be validating properly. http://dnssec-debugger.verisignlabs.com/ipp.gov http://dnsviz.net/d/ipp.gov/dnssec/ Is there any one here from Google that can help with this? See dig results and traceroutes below. -Josh $ dig @8.8.8.8 ipp.gov soa +trace ; <<>> DiG 9.8.3-P4 <<>> @8.8.8.8 ipp.gov soa +trace ; (1 server found) ;; global options: +cmd . 2209 IN NS e.root-servers.net. . 2209 IN NS h.root-servers.net. . 2209 IN NS d.root-servers.net. . 2209 IN NS i.root-servers.net. . 2209 IN NS k.root-servers.net. . 2209 IN NS j.root-servers.net. . 2209 IN NS l.root-servers.net. . 2209 IN NS a.root-servers.net. . 2209 IN NS b.root-servers.net. . 2209 IN NS c.root-servers.net. . 2209 IN NS f.root-servers.net. . 2209 IN NS g.root-servers.net. . 2209 IN NS m.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 1218 ms gov. 172800 IN NS a.gov-servers.net. gov. 172800 IN NS b.gov-servers.net. ;; Received 132 bytes from 128.63.2.53#53(128.63.2.53) in 113 ms ipp.gov. 86400 IN NS ns1.federalreserve.org. ipp.gov. 86400 IN NS ns2.federalreserve.org. ipp.gov. 86400 IN NS ns3.federalreserve.org. ;; Received 97 bytes from 69.36.157.30#53(69.36.157.30) in 375 ms ipp.gov. 30 IN SOA ns1.federalreserve.org. dns.ids.frb.org. 5 1200 1800 1209600 21600 ipp.gov. 30 IN NS ns1.federalreserve.org. ipp.gov. 30 IN NS ns3.federalreserve.org. ipp.gov. 30 IN NS ns2.federalreserve.org. ;; Received 193 bytes from 199.169.208.138#53(199.169.208.138) in 40 ms $ dig @8.8.8.8 ipp.gov soa ; <<>> DiG 9.8.3-P4 <<>> @8.8.8.8 ipp.gov soa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17671 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ipp.gov. IN SOA ;; Query time: 3353 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu May 30 14:55:08 2013 ;; MSG SIZE rcvd: 25 $ traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets 1 ve1003.mpls1.core.prco.etv.net (66.111.113.1) 5.989 ms 0.534 ms 0.222 ms 2 interface-74-214-233-10 (74.214.233.10) 5.205 ms 2.618 ms 2.615 ms 3 te-8-3.car2.SaltLakeCity1.Level3.net (4.53.42.153) 146.414 ms 178.280 ms 3.753 ms 4 ae-11-11.car1.SaltLakeCity1.Level3.net (4.69.133.121) 30.170 ms 33.988 ms 40.203 ms 5 * * * 6 ae-91-91.csw4.LosAngeles1.Level3.net (4.69.137.14) 30.178 ms 30.058 ms ae-81-81.csw3.LosAngeles1.Level3.net (4.69.137.10) 30.047 ms 7 * * * 8 GOOGLE-INC.edge1.LosAngeles9.Level3.net (4.53.228.6) 30.293 ms 29.913 ms 29.950 ms 9 216.239.46.40 (216.239.46.40) 30.129 ms 64.233.174.238 (64.233.174.238) 86.755 ms 216.239.46.40 (216.239.46.40) 30.164 ms 10 64.233.174.192 (64.233.174.192) 67.074 ms 64.233.174.188 (64.233.174.188) 30.725 ms 64.233.174.186 (64.233.174.186) 46.088 ms 11 72.14.239.153 (72.14.239.153) 42.234 ms 72.14.239.159 (72.14.239.159) 42.772 ms 72.14.239.160 (72.14.239.160) 43.318 ms 12 64.233.174.129 (64.233.174.129) 41.513 ms 41.510 ms 64.233.174.131 (64.233.174.131) 42.157 ms 13 * * * 14 google-public-dns-a.google.com (8.8.8.8) 42.258 ms 42.423 ms 42.408 ms $ traceroute 8.8.4.4 traceroute to 8.8.4.4 (8.8.4.4), 64 hops max, 40 byte packets 1 ve1003.mpls1.core.prco.etv.net (66.111.113.1) 0.287 ms 0.290 ms 0.175 ms 2 interface-74-214-233-10 (74.214.233.10) 7.919 ms 2.576 ms 2.687 ms 3 te-8-3.car2.SaltLakeCity1.Level3.net (4.53.42.153) 2.848 ms 2.767 ms 2.758 ms 4 ae-11-11.car1.SaltLakeCity1.Level3.net (4.69.133.121) 30.160 ms 30.289 ms 30.147 ms 5 * * * 6 ae-81-81.csw3.LosAngeles1.Level3.net (4.69.137.10) 30.222 ms ae-61-61.csw1.LosAngeles1.Level3.net (4.69.137.2) 30.070 ms 30.220 ms 7 * * * 8 GOOGLE-INC.edge1.LosAngeles9.Level3.net (4.53.228.6) 30.086 ms 30.301 ms 30.325 ms 9 64.233.174.238 (64.233.174.238) 30.178 ms 30.228 ms 216.239.46.40 (216.239.46.40) 30.440 ms 10 64.233.174.192 (64.233.174.192) 30.392 ms 64.233.174.190 (64.233.174.190) 30.564 ms 72.14.238.0 (72.14.238.0) 42.441 ms 11 72.14.239.155 (72.14.239.155) 41.626 ms 42.002 ms 72.14.239.157 (72.14.239.157) 42.397 ms 12 216.239.48.167 (216.239.48.167) 41.958 ms 64.233.174.131 (64.233.174.131) 42.470 ms 216.239.48.167 (216.239.48.167) 42.106 ms 13 * * * 14 google-public-dns-b.google.com (8.8.4.4) 41.619 ms 41.725 ms 41.527 ms From bortzmeyer at nic.fr Thu May 30 15:17:29 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 30 May 2013 17:17:29 +0200 Subject: ipp.gov and Google DNS (8.8.8.8) In-Reply-To: References: Message-ID: <20130530151729.GA29702@nic.fr> On Thu, May 30, 2013 at 09:04:44AM -0600, Josh Galvez wrote a message of 135 lines which said: > DNSSEC seems to be validating properly. Since Google Public DNS returns SERVFAIL even with the +cd option (Checking Disabled), I suspect that it is not a DNSSEC issue at all. From clayton at MNSi.Net Thu May 30 12:16:09 2013 From: clayton at MNSi.Net (Clayton Zekelman) Date: Thu, 30 May 2013 08:16:09 -0400 Subject: why does dail-up or pppoe access always has session-timeout ? In-Reply-To: References: Message-ID: <1369916172_5792@duplo.mnsi.net> The simple answer is that it does not. If you don't specify a session timeout, the session will not timeout. This is how we run our PPPoE services. The protocol and BAS designer does not set the parameter - the network operator does. At 05:10 AM 30/05/2013, Joe wrote: >hi. > a question obsessed me for a long time. "why my pppoe > connection to internet has a max session time, even if every thing goes ok? " > In our DSL access network , max session timeout is set to 4 days, > this parameter is sent to BAS by radius server after finishing > authenticating procedure. As I know, beside us some other > service providers also applied this parameter to pppoe session, the > parameter varies from 48 hours to 96 hours. Reading documents > of BAS, we found this is default value for session-time on BAS, > that means even if radius server does not response BAS > with session-timeout attribute BAS will cut pppoe session after > sometime. so , why does those BAS designer or protocol > designer set such a parameter for pppoe access ? >should anyone do me a favor on explaining this ? >regards >Joe --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From casey at deccio.net Thu May 30 16:03:37 2013 From: casey at deccio.net (Casey Deccio) Date: Thu, 30 May 2013 09:03:37 -0700 Subject: ipp.gov and Google DNS (8.8.8.8) In-Reply-To: <20130530151729.GA29702@nic.fr> References: <20130530151729.GA29702@nic.fr> Message-ID: On Thu, May 30, 2013 at 8:17 AM, Stephane Bortzmeyer wrote: > On Thu, May 30, 2013 at 09:04:44AM -0600, > Josh Galvez wrote > a message of 135 lines which said: > >> DNSSEC seems to be validating properly. > > Since Google Public DNS returns SERVFAIL even with the +cd option > (Checking Disabled), I suspect that it is not a DNSSEC issue at all. > That's not my experience: $ dig +cd @8.8.8.8 ipp.gov | grep status: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16884 $ dig @8.8.8.8 ipp.gov | grep status: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57555 The resolvers seem to be choking on the DNSKEY (with or without CD): $ dig +cd @8.8.8.8 ipp.gov dnskey | grep status: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19590 Casey From guu at google.com Thu May 30 16:22:36 2013 From: guu at google.com (Yunhong Gu) Date: Thu, 30 May 2013 12:22:36 -0400 Subject: ipp.gov and Google DNS (8.8.8.8) In-Reply-To: References: <20130530151729.GA29702@nic.fr> Message-ID: Google resolvers got no response (i.e. timeout) for ipp.gov/dnskey from its authoritative name servers. If there is anyone on this list who manages ipp.gov DNS servers, please take a look. Our resolver IPs can be found at https://developers.google.com/speed/public-dns/faq#locations. Thanks Yunhong (Google Public DNS) On Thu, May 30, 2013 at 12:03 PM, Casey Deccio wrote: > On Thu, May 30, 2013 at 8:17 AM, Stephane Bortzmeyer > wrote: > > On Thu, May 30, 2013 at 09:04:44AM -0600, > > Josh Galvez wrote > > a message of 135 lines which said: > > > >> DNSSEC seems to be validating properly. > > > > Since Google Public DNS returns SERVFAIL even with the +cd option > > (Checking Disabled), I suspect that it is not a DNSSEC issue at all. > > > > That's not my experience: > > $ dig +cd @8.8.8.8 ipp.gov | grep status: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16884 > $ dig @8.8.8.8 ipp.gov | grep status: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57555 > > The resolvers seem to be choking on the DNSKEY (with or without CD): > > $ dig +cd @8.8.8.8 ipp.gov dnskey | grep status: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19590 > > Casey > > From Valdis.Kletnieks at vt.edu Thu May 30 17:37:32 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 30 May 2013 13:37:32 -0400 Subject: why does dail-up or pppoe access always has session-timeout ? In-Reply-To: Your message of "Thu, 30 May 2013 09:10:21 -0000." References: Message-ID: <16280.1369935452@turing-police.cc.vt.edu> On Thu, 30 May 2013 09:10:21 -0000, Joe said: > a question obsessed me for a long time. "why my pppoe connection to > internet has a max session time, even if every thing goes ok? " >From a provider's point of view, forcing a connection to re-establish itself every few days means that if you ever have to roll out a change, you don't end up with *That* *One* *User* who stays connected for weeks or even months with the old parameters. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From wbailey at satelliteintelligencegroup.com Thu May 30 17:49:29 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 30 May 2013 17:49:29 +0000 Subject: why does dail-up or pppoe access always has session-timeout ? In-Reply-To: <16280.1369935452@turing-police.cc.vt.edu> Message-ID: It also probably has something to do with oversubscription. Providers generally allocated trunks (most dial up providers I knew used Livingston Port Masters), however their subscriber base was much larger than the number of phone lines available to take incoming calls. If you time out idle users, you have more phone lines available to take calls. Even in the BBS days, we still had to wait our turn.. Usually it was a redial until we got a carrier. I'll agree with the configuration aspect, but I really think it has much more to do with resource allocation in a telco environment (n:1 oversub). //warren On 5/30/13 10:37 AM, "Valdis.Kletnieks at vt.edu" wrote: >On Thu, 30 May 2013 09:10:21 -0000, Joe said: >> a question obsessed me for a long time. "why my pppoe connection to >> internet has a max session time, even if every thing goes ok? " > >From a provider's point of view, forcing a connection to re-establish >itself >every few days means that if you ever have to roll out a change, you >don't end >up with *That* *One* *User* who stays connected for weeks or even months >with >the old parameters. > From casey at deccio.net Thu May 30 18:17:03 2013 From: casey at deccio.net (Casey Deccio) Date: Thu, 30 May 2013 11:17:03 -0700 Subject: ipp.gov and Google DNS (8.8.8.8) In-Reply-To: References: <20130530151729.GA29702@nic.fr> Message-ID: On Thu, May 30, 2013 at 9:22 AM, Yunhong Gu wrote: > Google resolvers got no response (i.e. timeout) for ipp.gov/dnskey from its > authoritative name servers. If there is anyone on this list who manages > ipp.gov DNS servers, please take a look. Our resolver IPs can be found at > https://developers.google.com/speed/public-dns/faq#locations. > > I get a response for DNSKEY just fine*. However, the payload of the response is 1279 bytes, and Google's resolvers set the maximum UDP receive payload to 1232, which results in the truncated response. Unfortunately, the ipp.gov servers don't respond over TCP, so the resolvers aren't able to retrieve ipp.gov/DNSKEY. The problem here is that the ipp.gov servers aren't responding on TCP/53. But of curiosity, why a max payload size of 1232 for the Google resolvers? It seems like that would result in a lot more TCP transactions (and overhead) for queries to signed zones. Casey * Although, that's only if the DO bit is set; interestingly, if I don't set the DO bit, the response times out. From jfmezei_nanog at vaxination.ca Thu May 30 18:23:31 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 30 May 2013 14:23:31 -0400 Subject: why does dail-up or pppoe access always has session-timeout ? In-Reply-To: References: Message-ID: <51A79923.1000503@vaxination.ca> On 13-05-30 05:10, Joe wrote: > a question obsessed me for a long time. "why my pppoe connection to internet has a max session time, even if every thing goes ok? " > In our DSL access network , max session timeout is set to 4 days, this parameter is sent to BAS by radius server after finishing authenticating procedure. As I know, beside us some other service providers also applied this parameter to pppoe session, the parameter varies from 48 hours to 96 hours. Reading documents of BAS, we found this is default value for session-time on BAS, that means even if radius server does not response BAS with session-timeout attribute BAS will cut pppoe session after sometime. so , why does those BAS designer or protocol designer set such a parameter for pppoe access ? > should anyone do me a favor on explaining this ? Under normal circumstances, usage accounting data is only sent when the PPPoE connection ends. So an ISP might want to force PPPoE sessions to end every couple of days to capture usage data for accounting/billing purposes. Note that there are techniques to get the BAS (or router) to send these accounting updates to the radius server at regular intervals, allowing uninterruoted PPPoE sessions. Not all ISPs may have implemented this. In Canada, when threathened with UBB and now morphed into CBB billing regime for wholesale, many ISPs read their router's manuals and found the way to get the forced sending of accounting data at regular intervals. This has allowed them for instance to provide for unlimited usage during the wee hours of morning. They get the routers to send out accounting info at 02:00 in morning and at 12:00 (noon) and the ISP can then count only the usage between noon and 02:00. From guu at google.com Thu May 30 18:35:54 2013 From: guu at google.com (Yunhong Gu) Date: Thu, 30 May 2013 14:35:54 -0400 Subject: ipp.gov and Google DNS (8.8.8.8) In-Reply-To: References: <20130530151729.GA29702@nic.fr> Message-ID: On Thu, May 30, 2013 at 2:17 PM, Casey Deccio wrote: > On Thu, May 30, 2013 at 9:22 AM, Yunhong Gu wrote: > > Google resolvers got no response (i.e. timeout) for ipp.gov/dnskey from > its > > authoritative name servers. If there is anyone on this list who manages > > ipp.gov DNS servers, please take a look. Our resolver IPs can be found > at > > https://developers.google.com/speed/public-dns/faq#locations. > > > > > > I get a response for DNSKEY just fine*. However, the payload of the > response is 1279 bytes, and Google's resolvers set the maximum UDP > receive payload to 1232, which results in the truncated response. > Unfortunately, the ipp.gov servers don't respond over TCP, so the > resolvers aren't able to retrieve ipp.gov/DNSKEY. Thanks, I suspected this problem but tried to verify using a wrong buffer size by mistake. > > The problem here is that the ipp.gov servers aren't responding on > TCP/53. But of curiosity, why a max payload size of 1232 for the > Google resolvers? It seems like that would result in a lot more TCP > transactions (and overhead) for queries to signed zones. > There is still chance for fragmented UDP responses to get dropped nowadays, so we want response in single UDP packets or otherwise from TCP. Overhead should be insignificant due to the cache in resolvers. That being said, we are testing 4k max UDP buffer and may turn it on in the near future. > > Casey > > * Although, that's only if the DO bit is set; interestingly, if I > don't set the DO bit, the response times out. > From jra at baylink.com Thu May 30 19:29:39 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 30 May 2013 15:29:39 -0400 (EDT) Subject: FIXED: Mail contact needed at CenturyLink.com In-Reply-To: <1571331.6400.1369497670171.JavaMail.root@benjamin.baylink.com> Message-ID: <15625102.6748.1369942179309.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jay Ashworth" > The Outages list is receiving hard bounces from *some* email address > hosted at Qwest/Centurylink. Thanks to Don and Theresa at Qwest/CenturyLink for identifying the relevant address so we could unsubscribe it; I gather the bouncer which does not identify the address it's bouncing is scheduled to be replaced with a bouncer which does, relatively soon. Thanks also to everyone else for not replying on-list[s]. :-) A couple other qwest.com addresses were collateral damage in the interim; we'll have those back on the list shortly. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From cjp at 0x1.net Thu May 30 20:37:27 2013 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Thu, 30 May 2013 16:37:27 -0400 Subject: Verizon NY (LEC) prior notification Message-ID: Is anyone aware of a method to "mark" or "flag" certain services with Verizon NY (the LEC) as critical, such that changes aren't made to the services without prior notification? I know it's a lot to ask of Verizon. We experienced an outage on a number of PRI that were rehomed to another switch without our knowledge. The PRIs worked great outbound, but our customer noticed when all the DIDs stopped working. (They forgot to move the DIDs from old switch.) Thanks, -cjp From nanog at haller.ws Fri May 31 01:04:17 2013 From: nanog at haller.ws (Patrick) Date: Fri, 31 May 2013 09:04:17 +0800 Subject: Verizon NY (LEC) prior notification In-Reply-To: References: Message-ID: <20130531010416.GR13767@haller.ws> On 2013-05-30 16:37, Christopher J. Pilkington wrote: > Is anyone aware of a method to "mark" or "flag" certain services with > Verizon NY (the LEC) as critical, such that changes aren't made to the > services without prior notification? I know it's a lot to ask of Verizon. Probably better to watch stats for each NPA-NXX calling each DID. You can fit a distribution to the data for the length of time before another call arrives, and automatically throw a ticket at your carrier support group when the time between calls exceeds 99% of previous data. Patrick From Valdis.Kletnieks at vt.edu Fri May 31 01:43:05 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 30 May 2013 21:43:05 -0400 Subject: Verizon NY (LEC) prior notification In-Reply-To: Your message of "Fri, 31 May 2013 09:04:17 +0800." <20130531010416.GR13767@haller.ws> References: <20130531010416.GR13767@haller.ws> Message-ID: <40715.1369964585@turing-police.cc.vt.edu> On Fri, 31 May 2013 09:04:17 +0800, Patrick said: > Probably better to watch stats for each NPA-NXX calling each DID. You > can fit a distribution to the data for the length of time before another > call arrives, and automatically throw a ticket at your carrier support > group when the time between calls exceeds 99% of previous data. May not be workable without a sufficiently high call rate 24/7. If you're a small call center that usually has 3-4 calls per hour at 2AM, now long is "too long without a call, time to get suspicious"? Does your answer change if you're a 911 or suicide hotline? (Yes, if you usually handle 50-60 calls per hour even at 2AM, a 5 minute gap is probably suspicious. As I said, it depends highly on normal call rates) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From nanog at haller.ws Fri May 31 02:50:03 2013 From: nanog at haller.ws (Patrick) Date: Fri, 31 May 2013 10:50:03 +0800 Subject: Verizon NY (LEC) prior notification In-Reply-To: <40715.1369964585@turing-police.cc.vt.edu> References: <20130531010416.GR13767@haller.ws> <40715.1369964585@turing-police.cc.vt.edu> Message-ID: <20130531025003.GT13767@haller.ws> On 2013-05-30 21:43, Valdis.Kletnieks at vt.edu wrote: > May not be workable without a sufficiently high call rate 24/7. If you're a > small call center that usually has 3-4 calls per hour at 2AM, now long is "too > long without a call, time to get suspicious"? Correct. Alternatively, perhaps VZ has an outages list one could get on for any planned upgrades, so that one could test post-operation. While this would have helped the OP, it covers much (?) less of the error space. Or maybe get to know the local switch techs. Does VZ ex-nynex still have local switch techs, or did they centralize like Sprint/Kansas City? Other solutions? Patrick From streiner at cluebyfour.org Fri May 31 03:09:13 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 30 May 2013 23:09:13 -0400 (EDT) Subject: Verizon NY (LEC) prior notification In-Reply-To: <20130531025003.GT13767@haller.ws> References: <20130531010416.GR13767@haller.ws> <40715.1369964585@turing-police.cc.vt.edu> <20130531025003.GT13767@haller.ws> Message-ID: On Fri, 31 May 2013, Patrick wrote: > On 2013-05-30 21:43, Valdis.Kletnieks at vt.edu wrote: >> May not be workable without a sufficiently high call rate 24/7. If you're a >> small call center that usually has 3-4 calls per hour at 2AM, now long is "too >> long without a call, time to get suspicious"? > > Correct. > > Alternatively, perhaps VZ has an outages list one could get on for any > planned upgrades, so that one could test post-operation. While this > would have helped the OP, it covers much (?) less of the error space. > > Or maybe get to know the local switch techs. Does VZ ex-nynex still have > local switch techs, or did they centralize like Sprint/Kansas City? The vast majority of Verizon's COs are not staffed with on-site techs on a regular basis. I suspect the same is true of most telcos. jms From christopher.morrow at gmail.com Fri May 31 03:38:18 2013 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Thu, 30 May 2013 23:38:18 -0400 Subject: A bit of historical news Message-ID: http://www.cidr-report.org/cgi-bin/as-report?as=AS19262view=2.0 note the list of 'withdrawn' ... err, 19262 is no more? now it's borged into the 701 confed? From wbailey at satelliteintelligencegroup.com Fri May 31 04:07:30 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 31 May 2013 04:07:30 +0000 Subject: Verizon NY (LEC) prior notification In-Reply-To: References: <20130531010416.GR13767@haller.ws> <40715.1369964585@turing-police.cc.vt.edu> <20130531025003.GT13767@haller.ws>, Message-ID: <6fggl6dg5qjoiseo53hh6263.1369973247418@email.android.com> Sadly, I agree. If anyone is there late, it's a noc administrator looking at pictures of cats. Sent from my Mobile Device. -------- Original message -------- From: "Justin M. Streiner" Date: 05/30/2013 8:11 PM (GMT-08:00) To: Patrick Cc: nanog at nanog.org Subject: Re: Verizon NY (LEC) prior notification On Fri, 31 May 2013, Patrick wrote: > On 2013-05-30 21:43, Valdis.Kletnieks at vt.edu wrote: >> May not be workable without a sufficiently high call rate 24/7. If you're a >> small call center that usually has 3-4 calls per hour at 2AM, now long is "too >> long without a call, time to get suspicious"? > > Correct. > > Alternatively, perhaps VZ has an outages list one could get on for any > planned upgrades, so that one could test post-operation. While this > would have helped the OP, it covers much (?) less of the error space. > > Or maybe get to know the local switch techs. Does VZ ex-nynex still have > local switch techs, or did they centralize like Sprint/Kansas City? The vast majority of Verizon's COs are not staffed with on-site techs on a regular basis. I suspect the same is true of most telcos. jms From hschiller at google.com Fri May 31 04:14:42 2013 From: hschiller at google.com (Heather Schiller) Date: Fri, 31 May 2013 00:14:42 -0400 Subject: A bit of historical news In-Reply-To: References: Message-ID: Congrats.. now get on with Global AS and merge all those 70x's together! :) --h On Thu, May 30, 2013 at 11:38 PM, Christopher Morrow < christopher.morrow at gmail.com> wrote: > http://www.cidr-report.org/cgi-bin/as-report?as=AS19262view=2.0 > > note the list of 'withdrawn' ... err, 19262 is no more? now it's > borged into the 701 confed? > > From nanog at haller.ws Fri May 31 04:37:01 2013 From: nanog at haller.ws (Patrick) Date: Fri, 31 May 2013 12:37:01 +0800 Subject: Verizon NY (LEC) prior notification In-Reply-To: <6fggl6dg5qjoiseo53hh6263.1369973247418@email.android.com> References: <20130531010416.GR13767@haller.ws> <40715.1369964585@turing-police.cc.vt.edu> <20130531025003.GT13767@haller.ws> <6fggl6dg5qjoiseo53hh6263.1369973247418@email.android.com> Message-ID: <20130531043700.GU13767@haller.ws> On 2013-05-31 04:07, Warren Bailey wrote: > Sadly, I agree. If anyone is there late, it's a noc administrator looking at pictures of cats. Sure. However, when you know the switch (or special circuits) techs and occasionally eat where they do, you'll probably catch an FYI or two that switch X that carries your traffic is being forklift-upgraded next week. From selina.harrington at icann.org Thu May 30 21:54:10 2013 From: selina.harrington at icann.org (Selina Harrington) Date: Thu, 30 May 2013 14:54:10 -0700 Subject: IANA AS Numbers registry update Message-ID: The IANA AS Numbers registry has been updated to reflect the allocation of 1 block to ARIN in 2013-05-30: 62464-63487 You can find the IANA AS Numbers registry at: http://www.iana.org/assignments/as-numbers/as-numbers.xml Regards, Selina Harrington ******************************************* Internet Assigned Numbers Authority (IANA) Internet Corporation for Assigned Names & Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Phone: +1 310 301 5800 Fax: +1-310-823-8649 ******************************************* From streiner at cluebyfour.org Fri May 31 11:15:19 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 31 May 2013 07:15:19 -0400 (EDT) Subject: A bit of historical news In-Reply-To: References: Message-ID: On Thu, 30 May 2013, Christopher Morrow wrote: > http://www.cidr-report.org/cgi-bin/as-report?as=AS19262view=2.0 > > note the list of 'withdrawn' ... err, 19262 is no more? now it's > borged into the 701 confed? Yay! Now if I can just get VZ to light up native v6 on my fios connection... ;) jms From ryanshea at google.com Fri May 31 12:55:13 2013 From: ryanshea at google.com (Ryan Shea) Date: Fri, 31 May 2013 08:55:13 -0400 Subject: A bit of historical news In-Reply-To: References: Message-ID: +1 to v6 on FiOS, I'd also add "make the YouTube work" to my wish list for the artist formerly known as 19262. On Fri, May 31, 2013 at 7:15 AM, Justin M. Streiner wrote: > On Thu, 30 May 2013, Christopher Morrow wrote: > > http://www.cidr-report.org/**cgi-bin/as-report?as=**AS19262view=2.0 >> >> note the list of 'withdrawn' ... err, 19262 is no more? now it's >> borged into the 701 confed? >> > > Yay! Now if I can just get VZ to light up native v6 on my fios > connection... ;) > > jms > > From dhubbard at dino.hostasaurus.com Fri May 31 13:01:07 2013 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Fri, 31 May 2013 09:01:07 -0400 Subject: A bit of historical news References: Message-ID: Not holding my breath on that; been complaining to my VZ rep for v6 on fios for two years now since we have it in several remote locations and the most he could find for me as of last month was: "Verizon's First Office Application (FOA) is planned for deployment in Tampa, FL in May of 2012. During this time, Verizon will establish Dual Stack support on two E320 Gateway routers and 200 FiOS customers will be installed with IPv6 enabled BHRs. As far as I can tell, this never occurred so we seem to be a year late." David > -----Original Message----- > From: Ryan Shea [mailto:ryanshea at google.com] > Sent: Friday, May 31, 2013 8:55 AM > To: Justin M. Streiner > Cc: nanog list > Subject: Re: A bit of historical news > > +1 to v6 on FiOS, I'd also add "make the YouTube work" to my > wish list for > the artist formerly known as 19262. > > > On Fri, May 31, 2013 at 7:15 AM, Justin M. Streiner > > wrote: > > > On Thu, 30 May 2013, Christopher Morrow wrote: > > > > > http://www.cidr-report.org/**cgi-bin/as-report?as=**AS19262vie > w=2.0 > >> > >> note the list of 'withdrawn' ... err, 19262 is no more? now it's > >> borged into the 701 confed? > >> > > > > Yay! Now if I can just get VZ to light up native v6 on my fios > > connection... ;) > > > > jms > > > > > > From ryanshea at google.com Fri May 31 13:16:57 2013 From: ryanshea at google.com (Ryan Shea) Date: Fri, 31 May 2013 09:16:57 -0400 Subject: A bit of historical news In-Reply-To: References: Message-ID: I believe they plan on spelling IPv6 slightly differently than we do, C-G-N http://www22.verizon.com/Support/Residential/internet/highspeed/networking/troubleshooting/portforwarding/123897.htm On Fri, May 31, 2013 at 9:01 AM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Not holding my breath on that; been complaining to my VZ > rep for v6 on fios for two years now since we have it in > several remote locations and the most he could find for > me as of last month was: > > "Verizon's First Office Application (FOA) is planned for > deployment in Tampa, FL in May of 2012. During this time, > Verizon will establish Dual Stack support on two E320 > Gateway routers and 200 FiOS customers will be installed > with IPv6 enabled BHRs. > > As far as I can tell, this never occurred so we seem to > be a year late." > > David > > > -----Original Message----- > > From: Ryan Shea [mailto:ryanshea at google.com] > > Sent: Friday, May 31, 2013 8:55 AM > > To: Justin M. Streiner > > Cc: nanog list > > Subject: Re: A bit of historical news > > > > +1 to v6 on FiOS, I'd also add "make the YouTube work" to my > > wish list for > > the artist formerly known as 19262. > > > > > > On Fri, May 31, 2013 at 7:15 AM, Justin M. Streiner > > > > wrote: > > > > > On Thu, 30 May 2013, Christopher Morrow wrote: > > > > > > > > http://www.cidr-report.org/**cgi-bin/as-report?as=**AS19262vie > > w=2.0 > > >> > > >> note the list of 'withdrawn' ... err, 19262 is no more? now it's > > >> borged into the 701 confed? > > >> > > > > > > Yay! Now if I can just get VZ to light up native v6 on my fios > > > connection... ;) > > > > > > jms > > > > > > > > > > > > From ml at kenweb.org Fri May 31 13:54:09 2013 From: ml at kenweb.org (ML) Date: Fri, 31 May 2013 09:54:09 -0400 Subject: A bit of historical news In-Reply-To: References: Message-ID: <51A8AB81.2080807@kenweb.org> On 5/31/2013 9:01 AM, David Hubbard wrote: > Not holding my breath on that; been complaining to my VZ > rep for v6 on fios for two years now since we have it in > several remote locations and the most he could find for > me as of last month was: > > "Verizon's First Office Application (FOA) is planned for > deployment in Tampa, FL in May of 2012. During this time, > Verizon will establish Dual Stack support on two E320 > Gateway routers and 200 FiOS customers will be installed > with IPv6 enabled BHRs. > > As far as I can tell, this never occurred so we seem to > be a year late." > > David > Would it be difficult to at least enable v6 for the people that don't use their gateways? Many people use the ethernet ports on their ONT. From morrowc.lists at gmail.com Fri May 31 14:55:22 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 31 May 2013 10:55:22 -0400 Subject: A bit of historical news In-Reply-To: <51A8AB81.2080807@kenweb.org> References: <51A8AB81.2080807@kenweb.org> Message-ID: On Fri, May 31, 2013 at 9:54 AM, ML wrote: > On 5/31/2013 9:01 AM, David Hubbard wrote: >> Not holding my breath on that; been complaining to my VZ >> rep for v6 on fios for two years now since we have it in >> several remote locations and the most he could find for >> me as of last month was: >> >> "Verizon's First Office Application (FOA) is planned for >> deployment in Tampa, FL in May of 2012. During this time, >> Verizon will establish Dual Stack support on two E320 >> Gateway routers and 200 FiOS customers will be installed >> with IPv6 enabled BHRs. >> >> As far as I can tell, this never occurred so we seem to >> be a year late." >> >> David >> > > Would it be difficult to at least enable v6 for the people that don't > use their gateways? > > Many people use the ethernet ports on their ONT. Oh! you want them to: 1) assign a v6 address to the thing facing your ONT on their side 2) dhcpv6/PD a prefix to a requestor on your side of the ONT 3) profit right? that seems much simpler than: router bgp 19262 confederation reload maybe they'll get to it? From dwcarder at wisc.edu Fri May 31 15:56:04 2013 From: dwcarder at wisc.edu (Dale W. Carder) Date: Fri, 31 May 2013 10:56:04 -0500 Subject: ipp.gov and Google DNS (8.8.8.8) In-Reply-To: References: <20130530151729.GA29702@nic.fr> Message-ID: <20130531155604.GC73218@ricotta.doit.wisc.edu> Thus spake Casey Deccio (casey at deccio.net) on Thu, May 30, 2013 at 11:17:03AM -0700: > On Thu, May 30, 2013 at 9:22 AM, Yunhong Gu wrote: > > Google resolvers got no response (i.e. timeout) for ipp.gov/dnskey from its > > authoritative name servers. If there is anyone on this list who manages > > ipp.gov DNS servers, please take a look. Our resolver IPs can be found at > > https://developers.google.com/speed/public-dns/faq#locations. > > > > > > I get a response for DNSKEY just fine*. However, the payload of the > response is 1279 bytes, and Google's resolvers set the maximum UDP > receive payload to 1232, which results in the truncated response. > Unfortunately, the ipp.gov servers don't respond over TCP, so the > resolvers aren't able to retrieve ipp.gov/DNSKEY. > > The problem here is that the ipp.gov servers aren't responding on > TCP/53. But of curiosity, why a max payload size of 1232 for the > Google resolvers? I would guess that it is to fit inside tunnels? You will also see smaller than usual MSS (ex: 1416) from some (all?) google tcp services. Dale From tuc at admarketplace.com Fri May 31 11:15:58 2013 From: tuc at admarketplace.com (Tuc) Date: Fri, 31 May 2013 07:15:58 -0400 Subject: Cat-5 cables near 200 Paul, SF Message-ID: Hi, Hate to be "that guy" but really need help. Anyone know a place near 200 Paul in SF with a major quantity of cat-5 cables? Like 30 8ft blue, 20 8ft grey, 30 5ft blue. Need them today due to ex-employee's poor inventory keeping. Thanks, Tuc From alby.williams at verizon.com Fri May 31 12:42:24 2013 From: alby.williams at verizon.com (Anthony Williams) Date: Fri, 31 May 2013 08:42:24 -0400 Subject: A bit of historical news In-Reply-To: References: Message-ID: <51A89AB0.5000307@one.verizon.com> Yup. Changes are underway and AS19262 will become a footnote. :) -Alby On 5/30/2013 11:38 PM, Christopher Morrow wrote: > http://www.cidr-report.org/cgi-bin/as-report?as=AS19262view=2.0 > > note the list of 'withdrawn' ... err, 19262 is no more? now it's > borged into the 701 confed? > > From wbailey at satelliteintelligencegroup.com Fri May 31 18:16:57 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 31 May 2013 18:16:57 +0000 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: Message-ID: We talked about this the other day. I think the consensus was.. In San Fran, you're best off to head over to Fry's. I'm foggy, but I believe the word was Fry's in lieu of Microcenter etc. I think we also heard some people reply back with Graybar. On 5/31/13 4:15 AM, "Tuc" wrote: >Hi, > >Hate to be "that guy" but really need help. Anyone know a place near 200 >Paul in SF with a major quantity of cat-5 cables? Like 30 8ft blue, 20 8ft >grey, 30 5ft blue. Need them today due to ex-employee's poor inventory >keeping. > >Thanks, Tuc From carlos at race.com Fri May 31 18:20:48 2013 From: carlos at race.com (Carlos Alcantar) Date: Fri, 31 May 2013 18:20:48 +0000 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: Message-ID: gray bar on cesar chavez about 5-10 min from 200 paul. Not sure if you need to have an account or if you can just walk into the counter. 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 -----Original Message----- From: Tuc Date: Friday, May 31, 2013 4:15 AM To: "nanog at nanog.org" Subject: Cat-5 cables near 200 Paul, SF Hi, Hate to be "that guy" but really need help. Anyone know a place near 200 Paul in SF with a major quantity of cat-5 cables? Like 30 8ft blue, 20 8ft grey, 30 5ft blue. Need them today due to ex-employee's poor inventory keeping. Thanks, Tuc From jof at thejof.com Fri May 31 18:21:07 2013 From: jof at thejof.com (Jonathan Lassoff) Date: Fri, 31 May 2013 11:21:07 -0700 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: References: Message-ID: I could suggest a few places. Might want to call ahead to make sure they'll have what you need: - Central Computer. Has locations in San Francisco and San Mateo. SF maybe closer, but will take longer with traffic and parking. -- http://www.centralcomputers.com/commerce/misc/sanfrancisco.jsp -- http://www.centralcomputers.com/commerce/misc/sanmateo.jsp - Frys. Much further. Closest shop would be Palo Alto -- http://www.frys.com/template/isp/index/Frys/isp/Middle_Topics/H1%20Store%20Maps/palo%20alto/ - Jameco. Has some limited Ethernet cable selection. Has a will-call pick up at their warehouse in Belmont. -- http://www.jameco.com/ Cheers, jof From jna at retina.net Fri May 31 18:23:29 2013 From: jna at retina.net (John Adams) Date: Fri, 31 May 2013 11:23:29 -0700 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: References: Message-ID: Central computer. It's next to Moscone west. It's great. No need to go to the south bay. -j On Fri, May 31, 2013 at 11:16 AM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > We talked about this the other day. I think the consensus was.. In San > Fran, you're best off to head over to Fry's. I'm foggy, but I believe the > word was Fry's in lieu of Microcenter etc. I think we also heard some > people reply back with Graybar. > > On 5/31/13 4:15 AM, "Tuc" wrote: > > >Hi, > > > >Hate to be "that guy" but really need help. Anyone know a place near 200 > >Paul in SF with a major quantity of cat-5 cables? Like 30 8ft blue, 20 8ft > >grey, 30 5ft blue. Need them today due to ex-employee's poor inventory > >keeping. > > > >Thanks, Tuc > > > From wbailey at satelliteintelligencegroup.com Fri May 31 18:25:54 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 31 May 2013 18:25:54 +0000 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: Message-ID: We walked up the counter all the time, however that was in Alaska so the rules may be different down here. On 5/31/13 11:20 AM, "Carlos Alcantar" wrote: >gray bar on cesar chavez about 5-10 min from 200 paul. Not sure if you >need to have an account or if you can just walk into the counter. > >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 > > > > > >-----Original Message----- >From: Tuc >Date: Friday, May 31, 2013 4:15 AM >To: "nanog at nanog.org" >Subject: Cat-5 cables near 200 Paul, SF > >Hi, > >Hate to be "that guy" but really need help. Anyone know a place near 200 >Paul in SF with a major quantity of cat-5 cables? Like 30 8ft blue, 20 8ft >grey, 30 5ft blue. Need them today due to ex-employee's poor inventory >keeping. > >Thanks, Tuc > > > From scott at doc.net.au Fri May 31 18:30:28 2013 From: scott at doc.net.au (Scott Howard) Date: Fri, 31 May 2013 11:30:28 -0700 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: References: Message-ID: On Fri, May 31, 2013 at 11:16 AM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > We talked about this the other day. I think the consensus was.. In San > Fran, you're best off to head over to Fry's. The nearest Frys to SF is about 30 miles away in Palo Alto. Scott From mureninc at gmail.com Fri May 31 18:31:37 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Fri, 31 May 2013 11:31:37 -0700 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: References: Message-ID: MicroCenter Santa Clara / Silicon Valley is no more, due to the rent extortion in the Bay Area. If you care for my rant on the subject: http://tu.cnst.su/post/39584711234/why-microcenter-silicon-valley-is-no-more C. On 31 May 2013 11:16, Warren Bailey wrote: > We talked about this the other day. I think the consensus was.. In San > Fran, you're best off to head over to Fry's. I'm foggy, but I believe the > word was Fry's in lieu of Microcenter etc. I think we also heard some > people reply back with Graybar. > > On 5/31/13 4:15 AM, "Tuc" wrote: > >>Hi, >> >>Hate to be "that guy" but really need help. Anyone know a place near 200 >>Paul in SF with a major quantity of cat-5 cables? Like 30 8ft blue, 20 8ft >>grey, 30 5ft blue. Need them today due to ex-employee's poor inventory >>keeping. >> >>Thanks, Tuc From streiner at cluebyfour.org Fri May 31 18:31:50 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 31 May 2013 14:31:50 -0400 (EDT) Subject: A bit of historical news In-Reply-To: References: Message-ID: On Fri, 31 May 2013, David Hubbard wrote: > Not holding my breath on that; been complaining to my VZ > rep for v6 on fios for two years now since we have it in > several remote locations and the most he could find for > me as of last month was: > > "Verizon's First Office Application (FOA) is planned for > deployment in Tampa, FL in May of 2012. During this time, > Verizon will establish Dual Stack support on two E320 > Gateway routers and 200 FiOS customers will be installed > with IPv6 enabled BHRs. > > As far as I can tell, this never occurred so we seem to > be a year late." I keep pressing people at VZ on this, in hopes of getting some grease for this squeaky wheel, but so far... no go. I just got fios this past summer, and the router they provided does support v6. I've messed around with a tunnel to Hurricane Electric, but haven't had much time to figure out why it doesn't work. jms From ivanov_andrei at yahoo.com Fri May 31 18:33:52 2013 From: ivanov_andrei at yahoo.com (Andrei Ivanov) Date: Fri, 31 May 2013 11:33:52 -0700 (PDT) Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: References: Message-ID: <1370025232.82561.YahooMailNeo@web163806.mail.gq1.yahoo.com> Tuc wrote: >Hate to be "that guy" but really need help. Anyone know a place near 200 >Paul in SF with a major quantity of cat-5 cables? Like 30 8ft blue, 20 8ft >grey, 30 5ft blue. Need them today due to ex-employee's poor inventory >keeping. Central Computer (http://www.centralcomputers.com/) is much closer than Fry's. -- andrei From streiner at cluebyfour.org Fri May 31 18:34:19 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 31 May 2013 14:34:19 -0400 (EDT) Subject: A bit of historical news In-Reply-To: References: Message-ID: On Fri, 31 May 2013, Ryan Shea wrote: > I believe they plan on spelling IPv6 slightly differently than we do, C-G-N > > http://www22.verizon.com/Support/Residential/internet/highspeed/networking/troubleshooting/portforwarding/123897.htm I have fios business service at the house. So far, there's even less information available for any v6 rollout on that. jms > On Fri, May 31, 2013 at 9:01 AM, David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > >> Not holding my breath on that; been complaining to my VZ >> rep for v6 on fios for two years now since we have it in >> several remote locations and the most he could find for >> me as of last month was: >> >> "Verizon's First Office Application (FOA) is planned for >> deployment in Tampa, FL in May of 2012. During this time, >> Verizon will establish Dual Stack support on two E320 >> Gateway routers and 200 FiOS customers will be installed >> with IPv6 enabled BHRs. >> >> As far as I can tell, this never occurred so we seem to >> be a year late." >> >> David >> >>> -----Original Message----- >>> From: Ryan Shea [mailto:ryanshea at google.com] >>> Sent: Friday, May 31, 2013 8:55 AM >>> To: Justin M. Streiner >>> Cc: nanog list >>> Subject: Re: A bit of historical news >>> >>> +1 to v6 on FiOS, I'd also add "make the YouTube work" to my >>> wish list for >>> the artist formerly known as 19262. >>> >>> >>> On Fri, May 31, 2013 at 7:15 AM, Justin M. Streiner >>> >>> wrote: >>> >>>> On Thu, 30 May 2013, Christopher Morrow wrote: >>>> >>>> >>> http://www.cidr-report.org/**cgi-bin/as-report?as=**AS19262vie >>> w=2.0 >>>>> >>>>> note the list of 'withdrawn' ... err, 19262 is no more? now it's >>>>> borged into the 701 confed? >>>>> >>>> >>>> Yay! Now if I can just get VZ to light up native v6 on my fios >>>> connection... ;) >>>> >>>> jms >>>> >>>> >>> >>> >> >> > From cscora at apnic.net Fri May 31 18:39:31 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 1 Jun 2013 04:39:31 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201305311839.r4VIdVdi030132@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 01 Jun, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 455214 Prefixes after maximum aggregation: 185422 Deaggregation factor: 2.46 Unique aggregates announced to Internet: 224816 Total ASes present in the Internet Routing Table: 44200 Prefixes per ASN: 10.30 Origin-only ASes present in the Internet Routing Table: 34661 Origin ASes announcing only one prefix: 16138 Transit ASes present in the Internet Routing Table: 5862 Transit-only ASes present in the Internet Routing Table: 150 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 54 Max AS path prepend of ASN ( 56484) 51 Prefixes from unregistered ASNs in the Routing Table: 315 Unregistered ASNs in the Routing Table: 130 Number of 32-bit ASNs allocated by the RIRs: 4781 Number of 32-bit ASNs visible in the Routing Table: 3677 Prefixes from 32-bit ASNs in the Routing Table: 10524 Special use prefixes present in the Routing Table: 26 Prefixes being announced from unallocated address space: 235 Number of addresses announced to Internet: 2620299948 Equivalent to 156 /8s, 46 /16s and 154 /24s Percentage of available address space announced: 70.8 Percentage of allocated address space announced: 70.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.6 Total number of prefixes smaller than registry allocations: 160166 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 109303 Total APNIC prefixes after maximum aggregation: 33546 APNIC Deaggregation factor: 3.26 Prefixes being announced from the APNIC address blocks: 110744 Unique aggregates announced from the APNIC address blocks: 45098 APNIC Region origin ASes present in the Internet Routing Table: 4852 APNIC Prefixes per ASN: 22.82 APNIC Region origin ASes announcing only one prefix: 1221 APNIC Region transit ASes present in the Internet Routing Table: 822 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 547 Number of APNIC addresses announced to Internet: 722414304 Equivalent to 43 /8s, 15 /16s and 42 /24s Percentage of available APNIC address space announced: 84.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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: 159792 Total ARIN prefixes after maximum aggregation: 80132 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 160347 Unique aggregates announced from the ARIN address blocks: 73391 ARIN Region origin ASes present in the Internet Routing Table: 15711 ARIN Prefixes per ASN: 10.21 ARIN Region origin ASes announcing only one prefix: 5978 ARIN Region transit ASes present in the Internet Routing Table: 1639 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 19 Number of ARIN addresses announced to Internet: 1064198208 Equivalent to 63 /8s, 110 /16s and 96 /24s Percentage of available ARIN address space announced: 56.3 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, 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: 116865 Total RIPE prefixes after maximum aggregation: 59837 RIPE Deaggregation factor: 1.95 Prefixes being announced from the RIPE address blocks: 120385 Unique aggregates announced from the RIPE address blocks: 77846 RIPE Region origin ASes present in the Internet Routing Table: 17210 RIPE Prefixes per ASN: 7.00 RIPE Region origin ASes announcing only one prefix: 8176 RIPE Region transit ASes present in the Internet Routing Table: 2821 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 54 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2345 Number of RIPE addresses announced to Internet: 656498020 Equivalent to 39 /8s, 33 /16s and 93 /24s Percentage of available RIPE address space announced: 95.4 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, 196608-199679 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: 47792 Total LACNIC prefixes after maximum aggregation: 9344 LACNIC Deaggregation factor: 5.11 Prefixes being announced from the LACNIC address blocks: 52052 Unique aggregates announced from the LACNIC address blocks: 24378 LACNIC Region origin ASes present in the Internet Routing Table: 1948 LACNIC Prefixes per ASN: 26.72 LACNIC Region origin ASes announcing only one prefix: 580 LACNIC Region transit ASes present in the Internet Routing Table: 358 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 760 Number of LACNIC addresses announced to Internet: 130286632 Equivalent to 7 /8s, 196 /16s and 4 /24s Percentage of available LACNIC address space announced: 77.7 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-62463, 262144-263167 plus 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: 10851 Total AfriNIC prefixes after maximum aggregation: 2523 AfriNIC Deaggregation factor: 4.30 Prefixes being announced from the AfriNIC address blocks: 11451 Unique aggregates announced from the AfriNIC address blocks: 3885 AfriNIC Region origin ASes present in the Internet Routing Table: 625 AfriNIC Prefixes per ASN: 18.32 AfriNIC Region origin ASes announcing only one prefix: 183 AfriNIC Region transit ASes present in the Internet Routing Table: 131 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46610176 Equivalent to 2 /8s, 199 /16s and 55 /24s Percentage of available AfriNIC address space announced: 46.3 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 11559 926 Korea Telecom (KIX) 17974 2519 839 86 PT TELEKOMUNIKASI INDONESIA 7545 1983 320 108 TPG Internet Pty Ltd 4755 1734 391 192 TATA Communications formerly 9829 1514 1205 40 BSNL National Internet Backbo 9583 1220 91 503 Sify Limited 7552 1152 1080 13 Vietel Corporation 4808 1141 2121 331 CNCGROUP IP network: China169 9498 1120 309 70 BHARTI Airtel Ltd. 24560 1076 394 164 Bharti Airtel Ltd., Telemedia 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 3017 3692 77 bellsouth.net, inc. 7029 2070 1265 211 Windstream Communications Inc 18566 2065 382 184 Covad Communications 1785 1991 677 123 PaeTec Communications, Inc. 22773 1983 2929 125 Cox Communications, Inc. 20115 1671 1611 611 Charter Communications 4323 1612 1139 401 Time Warner Telecom 701 1587 11075 841 UUNET Technologies, Inc. 30036 1334 298 642 Mediacom Communications Corp 7018 1306 11059 838 AT&T WorldNet Services 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 8402 1586 544 16 Corbina telecom 2118 1260 97 13 EUnet/RELCOM Autonomous Syste 34984 1215 240 222 BILISIM TELEKOM 20940 876 307 684 Akamai Technologies European 13188 828 98 73 Educational Network 31148 794 39 23 FreeNet ISP 8551 773 370 43 Bezeq International 6830 771 2377 444 UPC Distribution Services 34744 684 173 59 SC GVM SISTEM 2003 SRL 58113 666 74 386 LIR DATACENTER TELECOM SRL 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 28573 2791 1533 112 NET Servicos de Comunicao S.A 10620 2633 414 231 TVCABLE BOGOTA 7303 1723 1154 219 Telecom Argentina Stet-France 8151 1272 2710 406 UniNet S.A. de C.V. 18881 958 780 19 Global Village Telecom 6503 926 434 65 AVANTEL, S.A. 27947 838 89 102 Telconet S.A 3816 710 306 85 Empresa Nacional de Telecomun 7738 698 1370 35 Telecomunicacoes da Bahia S.A 11172 608 87 64 Servicios Alestra S.A de C.V 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 36998 1237 80 4 MOBITEL 24863 892 274 33 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 437 956 9 TEDATA 24835 345 80 8 RAYA Telecom - Egypt 3741 261 906 220 The Internet Solution 15706 222 32 6 Sudatel Internet Exchange Aut 12258 193 28 67 Vodacom Internet Company 29975 191 667 21 Vodacom 36992 189 527 22 Etisalat MISR 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 6389 3017 3692 77 bellsouth.net, inc. 4766 2959 11559 926 Korea Telecom (KIX) 28573 2791 1533 112 NET Servicos de Comunicao S.A 10620 2633 414 231 TVCABLE BOGOTA 17974 2519 839 86 PT TELEKOMUNIKASI INDONESIA 7029 2070 1265 211 Windstream Communications Inc 18566 2065 382 184 Covad Communications 1785 1991 677 123 PaeTec Communications, Inc. 7545 1983 320 108 TPG Internet Pty Ltd 22773 1983 2929 125 Cox 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 28573 2791 2679 NET Servicos de Comunicao S.A 17974 2519 2433 PT TELEKOMUNIKASI INDONESIA 10620 2633 2402 TVCABLE BOGOTA 4766 2959 2033 Korea Telecom (KIX) 18566 2065 1881 Covad Communications 7545 1983 1875 TPG Internet Pty Ltd 1785 1991 1868 PaeTec Communications, Inc. 7029 2070 1859 Windstream Communications Inc 22773 1983 1858 Cox Communications, Inc. 8402 1586 1570 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.46.0/23 39743 Mobimax Telecom SRL 128.0.53.0/24 60993 Totalsoft SA 128.0.54.0/24 60972 Carpatair SA 128.0.55.0/24 48571 SC efectRO SRL 128.0.57.0/24 60993 Totalsoft SA 128.0.58.0/23 9050 RTD-ROMTELECOM Autonomous Sys 128.0.60.0/24 9050 RTD-ROMTELECOM Autonomous Sys Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. 64.185.230.0/24 27431 JTL Networks Inc. 64.185.231.0/24 27431 JTL Networks Inc. 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:11 /10:30 /11:88 /12:249 /13:483 /14:899 /15:1595 /16:12688 /17:6658 /18:11175 /19:22184 /20:32051 /21:34277 /22:47494 /23:42375 /24:238957 /25:1316 /26:1665 /27:855 /28:46 /29:64 /30:18 /31:0 /32:20 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2016 2065 Covad Communications 6389 1732 3017 bellsouth.net, inc. 7029 1580 2070 Windstream Communications Inc 22773 1290 1983 Cox Communications, Inc. 8402 1280 1586 Corbina telecom 36998 1231 1237 MOBITEL 30036 1203 1334 Mediacom Communications Corp 11492 1180 1219 Cable One 1785 1062 1991 PaeTec Communications, Inc. 6983 1009 1136 ITC^Deltacom Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:812 2:676 3:3 4:15 5:756 6:9 8:557 12:1924 13:3 14:826 15:11 16:3 17:9 20:17 23:274 24:1771 27:1478 31:1306 32:57 33:2 34:5 36:28 37:1869 38:876 39:2 40:172 41:2800 42:192 44:6 46:1910 47:2 49:650 50:717 52:12 54:33 55:9 57:26 58:1173 59:570 60:313 61:1408 62:1111 63:2035 64:4355 65:2174 66:4379 67:2063 68:1124 69:3312 70:882 71:566 72:1924 74:2559 75:413 76:304 77:1115 78:1019 79:616 80:1264 81:1000 82:623 83:571 84:534 85:1161 86:455 87:989 88:534 89:1738 90:147 91:5495 92:592 93:1666 94:1841 95:1487 96:516 97:344 98:1040 99:41 100:31 101:325 103:2646 105:519 106:150 107:208 108:519 109:1824 110:895 111:1037 112:539 113:799 114:693 115:951 116:920 117:796 118:1082 119:1298 120:405 121:726 122:1798 123:1212 124:1356 125:1355 128:643 129:221 130:326 131:655 132:342 133:148 134:265 135:67 136:222 137:263 138:347 139:196 140:210 141:327 142:541 143:372 144:496 145:93 146:503 147:395 148:683 149:368 150:158 151:567 152:416 153:193 154:41 155:398 156:267 157:398 158:278 159:729 160:337 161:431 162:438 163:219 164:599 165:446 166:289 167:592 168:1029 169:129 170:1025 171:181 172:21 173:1660 174:606 175:477 176:1110 177:2006 178:1860 179:14 180:1452 181:434 182:1211 183:389 184:670 185:490 186:2270 187:1307 188:2145 189:1322 190:6376 192:6648 193:5870 194:4594 195:3424 196:1359 197:908 198:4467 199:5319 200:5922 201:2276 202:8836 203:8877 204:4503 205:2560 206:2811 207:2886 208:4043 209:3648 210:2974 211:1509 212:2199 213:1919 214:917 215:98 216:5234 217:1599 218:618 219:331 220:1260 221:558 222:321 223:451 End of report From msa at latt.net Fri May 31 18:49:35 2013 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 31 May 2013 14:49:35 -0400 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: References: Message-ID: <20130531184934.GA27305@puck.nether.net> On Fri, May 31, 2013 at 06:25:54PM +0000, Warren Bailey wrote: > We walked up the counter all the time, however that was in Alaska so the > rules may be different down here. You can walk up with a credit card, terms just make it easier to place orders in advance for pickup. Anyway, as noted, from 200P, Graybar is your closest and best bet, Central Computer doesn't always have the quantities that people on this list sometimes require. --msa From knife at toaster.net Fri May 31 19:03:09 2013 From: knife at toaster.net (Sean Lazar) Date: Fri, 31 May 2013 12:03:09 -0700 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: References: Message-ID: <51A8F3ED.3020907@toaster.net> +1 Central computer on Howard. On 5/31/13 11:23 AM, John Adams wrote: > Central computer. It's next to Moscone west. It's great. No need to go to > the south bay. > > -j > > > On Fri, May 31, 2013 at 11:16 AM, Warren Bailey < > wbailey at satelliteintelligencegroup.com> wrote: > >> We talked about this the other day. I think the consensus was.. In San >> Fran, you're best off to head over to Fry's. I'm foggy, but I believe the >> word was Fry's in lieu of Microcenter etc. I think we also heard some >> people reply back with Graybar. >> >> On 5/31/13 4:15 AM, "Tuc" wrote: >> >>> Hi, >>> >>> Hate to be "that guy" but really need help. Anyone know a place near 200 >>> Paul in SF with a major quantity of cat-5 cables? Like 30 8ft blue, 20 8ft >>> grey, 30 5ft blue. Need them today due to ex-employee's poor inventory >>> keeping. >>> >>> Thanks, Tuc >> >> > From george.herbert at gmail.com Fri May 31 19:06:07 2013 From: george.herbert at gmail.com (George Herbert) Date: Fri, 31 May 2013 12:06:07 -0700 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: <20130531184934.GA27305@puck.nether.net> References: <20130531184934.GA27305@puck.nether.net> Message-ID: +1 ; go Graybar. On Fri, May 31, 2013 at 11:49 AM, Majdi S. Abbas wrote: > On Fri, May 31, 2013 at 06:25:54PM +0000, Warren Bailey wrote: > > We walked up the counter all the time, however that was in Alaska so the > > rules may be different down here. > > You can walk up with a credit card, terms just make it easier > to place orders in advance for pickup. > > Anyway, as noted, from 200P, Graybar is your closest and best > bet, Central Computer doesn't always have the quantities that people > on this list sometimes require. > > --msa > > -- -george william herbert george.herbert at gmail.com From tim at lifelike.com Fri May 31 19:06:50 2013 From: tim at lifelike.com (Tim M Edwards) Date: Fri, 31 May 2013 12:06:50 -0700 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: References: <20130531184934.GA27305@puck.nether.net> Message-ID: Needs to be a Corporate CC though. On Fri, May 31, 2013 at 12:01 PM, Tim M Edwards wrote: > Needs to be a Corporate CC though. > > > > > On Fri, May 31, 2013 at 11:49 AM, Majdi S. Abbas wrote: > >> On Fri, May 31, 2013 at 06:25:54PM +0000, Warren Bailey wrote: >> > We walked up the counter all the time, however that was in Alaska so the >> > rules may be different down here. >> >> You can walk up with a credit card, terms just make it easier >> to place orders in advance for pickup. >> >> Anyway, as noted, from 200P, Graybar is your closest and best >> bet, Central Computer doesn't always have the quantities that people >> on this list sometimes require. >> >> --msa >> >> > From sethm at rollernet.us Fri May 31 19:27:11 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 31 May 2013 12:27:11 -0700 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: References: <20130531184934.GA27305@puck.nether.net> Message-ID: <51A8F98F.9070103@rollernet.us> On 5/31/13 12:06 PM, Tim M Edwards wrote: > Needs to be a Corporate CC though. > Graybar? My local counter here has taken my personal card, but you still have to have an account with them. ~Seth From ryan at lookout.com Fri May 31 19:37:47 2013 From: ryan at lookout.com (Ryan Dooley) Date: Fri, 31 May 2013 12:37:47 -0700 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: References: Message-ID: <51A8FC0B.5090002@lookout.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/31/2013 04:15 AM, Tuc wrote: > Hi, > > Hate to be "that guy" but really need help. Anyone know a place > near 200 Paul in SF with a major quantity of cat-5 cables? Like 30 > 8ft blue, 20 8ft grey, 30 5ft blue. Need them today due to > ex-employee's poor inventory keeping. > > Thanks, Tuc > Depending on how soon your need is, check out http://www.sfcable.com/ They pretty much deliver overnight in the Bay Area. Cheers, Ryan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRqPwLAAoJEMth0VwPagXs6FYP/REN7Q7Gw4ThyXX2ZHqvWfnN v8NQa1KZvvCsvGRoSp1D1ICR5xqo+ArYFd4KlGcXtjJ81JAb8679Xr7oNYogO/bw Zr5rg4ngEinEmNr5uxCYg/ya+Ad1ae9XsOtIQiyhMcxsc79tIN+FEoVrcObGYMRM mprbTJFxt9mXJ7JA1JRbbycT0otILyF+se2DeSKrO4YvwF4VJSiJRZZcG+aavgdP RGttenvJpZfApbd6m9eLpa+6b8w5nfupZkkjYwm5ir3MEADMxy5+Cn+NfOHCEUa3 XN56vSk6mNVQv6G6vZGv17/kSn1WXuRGHeLS6Y+pAyraP8rqeV5Ks/bVGFXROypw ClsUhfNdzaOQTVIlvcv0AU7vK0fBjRdkDcRbgGmHf42bdbbokGJiogVZsvaMCUDP Q2lU3b0Tc4vO0rd4a/U2/+2qaRqvDayPOyqwwT3WPm6wXvZxd3QLo8gQLV5jraAU 3bJjyANkJ+VeDII8Yntc9FW4KcEv6dYjAe6PT1mah4FzdLX67/cXLChPc/HzqepY w2VhScP1D/72ov6Pq2RuUBtFArH5CFIMlidOqF6wBL0NSwI1D6MejqCU6V1cjHa4 2YsMNqUHMKH3sFNnR9+cTnu0rhA5jUl6aThy9+PFsN0bwL6KrbexzCcfpyxgrRdI Ei8xeRRdc84ziEInHCKc =a/fa -----END PGP SIGNATURE----- From cidr-report at potaroo.net Fri May 31 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 31 May 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201305312200.r4VM00ld095740@wattle.apnic.net> This report has been generated at Fri May 31 21:13:21 2013 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 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 24-05-13 457343 260522 25-05-13 457261 261050 26-05-13 457360 261034 27-05-13 457347 261303 28-05-13 457273 261905 29-05-13 457301 261868 30-05-13 457371 260916 31-05-13 456466 261087 AS Summary 44286 Number of ASes in routing system 18335 Number of ASes announcing only one prefix 3017 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116960224 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 31May13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 456592 260924 195668 42.9% All ASes AS6389 3017 81 2936 97.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2794 547 2247 80.4% NET Servi?os de Comunica??o S.A. AS4766 2959 942 2017 68.2% KIXS-AS-KR Korea Telecom AS17974 2518 544 1974 78.4% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 1983 135 1848 93.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 2633 831 1802 68.4% Telmex Colombia S.A. AS18566 2065 474 1591 77.0% COVAD - Covad Communications Co. AS7303 1723 452 1271 73.8% Telecom Argentina S.A. AS4323 1622 411 1211 74.7% TWTC - tw telecom holdings, inc. AS2118 1260 86 1174 93.2% RELCOM-AS OOO "NPO Relcom" AS4755 1733 584 1149 66.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1152 198 954 82.8% VIETEL-AS-AP Vietel Corporation AS36998 1237 301 936 75.7% SDN-MOBITEL AS18881 958 83 875 91.3% Global Village Telecom AS18101 999 180 819 82.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS1785 1991 1242 749 37.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1138 389 749 65.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1585 848 737 46.5% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS13977 844 140 704 83.4% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 733 55 678 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS22561 1185 509 676 57.0% DIGITAL-TELEPORT - Digital Teleport Inc. AS8151 1278 608 670 52.4% Uninet S.A. de C.V. AS7029 2070 1405 665 32.1% WINDSTREAM - Windstream Communications Inc AS6983 1136 476 660 58.1% ITCDELTA - ITC^Deltacom AS24560 1076 418 658 61.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 733 110 623 85.0% GIGAINFRA Softbank BB Corp. AS34744 684 72 612 89.5% GVM S.C. GVM SISTEM 2003 S.R.L. AS3549 1055 444 611 57.9% GBLX Global Crossing Ltd. AS7545 1987 1381 606 30.5% TPG-INTERNET-AP TPG Telecom Limited AS3356 1100 509 591 53.7% LEVEL3 Level 3 Communications Total 47248 14455 32793 69.4% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.197.36.0/22 AS43359 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.249.84.0/24 AS55720 GIGABIT-MY Gigabit Hosting Sdn Bhd 103.249.85.0/24 AS55720 GIGABIT-MY Gigabit Hosting Sdn Bhd 103.249.86.0/24 AS55720 GIGABIT-MY Gigabit Hosting Sdn Bhd 103.249.87.0/24 AS55720 GIGABIT-MY Gigabit Hosting Sdn Bhd 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.138.128.0/20 AS32738 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.52.192.0/24 AS27919 190.52.193.0/24 AS27919 190.52.194.0/24 AS27919 190.52.195.0/24 AS27919 190.52.196.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.197.0/24 AS27919 190.52.198.0/24 AS27919 190.52.199.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.202.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.203.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.205.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.206.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.207.0/24 AS3549 GBLX Global Crossing Ltd. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 195.248.240.0/23 AS34169 MEDIA-COM-TYCHY Media-Com Sp. z o.o. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 200.107.248.0/24 AS27919 200.107.249.0/24 AS27919 200.107.250.0/24 AS27919 200.107.251.0/24 AS27919 200.107.252.0/24 AS28006 CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 200.107.253.0/24 AS27919 200.107.254.0/24 AS27919 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 201.222.32.0/20 AS27821 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.70.56.0/21 AS32738 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.209.64.0/20 AS46851 IPARADIGMS - iParadigms, LLC 209.209.67.0/24 AS46851 IPARADIGMS - iParadigms, LLC 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.127.192.0/24 AS22166 216.127.193.0/24 AS22166 216.127.194.0/24 AS22166 216.127.195.0/24 AS22166 216.127.196.0/24 AS22166 216.127.196.64/26 AS22166 216.127.197.0/24 AS22166 216.127.198.0/24 AS22166 216.127.199.0/24 AS22166 216.127.200.0/24 AS22166 216.127.201.0/24 AS22166 216.127.202.0/24 AS22166 216.127.203.0/24 AS22166 216.127.204.0/24 AS22166 216.127.205.0/24 AS22166 216.127.206.0/24 AS22166 216.127.207.0/24 AS22166 216.127.208.0/24 AS22166 216.127.209.0/24 AS22166 216.127.210.0/24 AS22166 216.127.211.0/24 AS22166 216.127.212.0/24 AS22166 216.127.213.0/24 AS22166 216.127.214.0/24 AS22166 216.127.215.0/24 AS22166 216.127.216.0/24 AS22166 216.127.217.0/24 AS22166 216.127.218.0/24 AS22166 216.127.219.0/24 AS22166 216.127.220.0/24 AS22166 216.127.221.0/24 AS22166 216.127.222.0/24 AS22166 216.127.223.0/24 AS22166 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 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 May 31 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 31 May 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201305312200.r4VM01Wq095765@wattle.apnic.net> BGP Update Report Interval: 23-May-13 -to- 30-May-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS36998 213281 8.8% 301.7 -- SDN-MOBITEL 2 - AS5800 52809 2.2% 219.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 3 - AS8402 48260 2.0% 36.5 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS9829 39099 1.6% 41.3 -- BSNL-NIB National Internet Backbone 5 - AS4538 35774 1.5% 68.9 -- ERX-CERNET-BKB China Education and Research Network Center 6 - AS7552 23880 1.0% 20.8 -- VIETEL-AS-AP Vietel Corporation 7 - AS21299 17430 0.7% 77.5 -- ORBITA-PLUS-AS ORBITA-PLUS Autonomous System 8 - AS17974 17048 0.7% 8.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 9 - AS9416 16296 0.7% 354.3 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 10 - AS3909 16063 0.7% 2677.2 -- QWEST-AS-3908 - Qwest Communications Company, LLC 11 - AS28573 14733 0.6% 6.7 -- NET Servi?os de Comunica??o S.A. 12 - AS29049 14613 0.6% 43.0 -- DELTA-TELECOM-AS Delta Telecom LTD. 13 - AS33776 13834 0.6% 75.6 -- STARCOMMS-ASN 14 - AS45899 13619 0.6% 36.5 -- VNPT-AS-VN VNPT Corp 15 - AS30693 12382 0.5% 33.6 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 16 - AS27738 12108 0.5% 21.2 -- Ecuadortelecom S.A. 17 - AS31148 11434 0.5% 14.0 -- FREENET-AS Freenet Ltd. 18 - AS7545 11310 0.5% 7.8 -- TPG-INTERNET-AP TPG Telecom Limited 19 - AS2708 11185 0.5% 145.3 -- Universidad de Guanajuato 20 - AS18207 10917 0.5% 38.6 -- YOU-INDIA-AP YOU Broadband & Cable India Ltd. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6629 7406 0.3% 7406.0 -- NOAA-AS - NOAA 2 - AS19406 5390 0.2% 5390.0 -- TWRS-MA - Towerstream I, Inc. 3 - AS42334 5270 0.2% 5270.0 -- BBP-AS Broadband Plus s.a.l. 4 - AS44971 9912 0.4% 4956.0 -- GOETEC-AS GOETEC Limited 5 - AS9854 6818 0.3% 3409.0 -- KTO-AS-KR KTO 6 - AS6174 6386 0.3% 3193.0 -- SPRINTLINK8 - Sprint 7 - AS37367 2843 0.1% 2843.0 -- CALLKEY 8 - AS3909 16063 0.7% 2677.2 -- QWEST-AS-3908 - Qwest Communications Company, LLC 9 - AS14680 8022 0.3% 2674.0 -- REALE-6 - Auction.com 10 - AS27735 5660 0.2% 1886.7 -- Synapsis Soluciones y Servicios IT LTDA 11 - AS33920 3361 0.1% 1680.5 -- AQL (aq) Networks Limited 12 - AS8137 5028 0.2% 1676.0 -- DISNEYONLINE-AS - Disney Online 13 - AS57201 1236 0.1% 1236.0 -- EDF-AS Estonian Defence Forces 14 - AS22356 5590 0.2% 1118.0 -- Durand do Brasil Ltda 15 - AS22688 979 0.0% 979.0 -- DOLGENCORP - Dollar General Corporation 16 - AS23295 793 0.0% 793.0 -- EA-01 - Extend America 17 - AS12396 745 0.0% 745.0 -- INAR-ARKHNAGELSK-AS OJSC MegaFon 18 - AS27164 2190 0.1% 730.0 -- US-INTERNET - Global Reach Communications LLC 19 - AS48612 9633 0.4% 688.1 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 20 - AS47887 3831 0.2% 638.5 -- NEU-AS NEU Telecom & Technologies TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 92.246.207.0/24 9560 0.4% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 2 - 5.56.48.0/21 8945 0.3% AS44971 -- GOETEC-AS GOETEC Limited 3 - 202.41.70.0/24 8227 0.3% AS2697 -- ERX-ERNET-AS Education and Research Network 4 - 203.118.224.0/21 8081 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 5 - 203.118.232.0/21 8027 0.3% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 6 - 192.58.232.0/24 7406 0.3% AS6629 -- NOAA-AS - NOAA 7 - 211.214.206.0/24 6816 0.3% AS9854 -- KTO-AS-KR KTO 8 - 12.139.133.0/24 6672 0.3% AS14680 -- REALE-6 - Auction.com 9 - 206.48.139.0/24 5655 0.2% AS27735 -- Synapsis Soluciones y Servicios IT LTDA 10 - 69.38.178.0/24 5390 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 11 - 151.118.255.0/24 5348 0.2% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 12 - 151.118.254.0/24 5348 0.2% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 13 - 151.118.18.0/24 5340 0.2% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 14 - 62.84.76.0/24 5270 0.2% AS42334 -- BBP-AS Broadband Plus s.a.l. 15 - 173.232.235.0/24 5215 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 16 - 173.232.234.0/24 5214 0.2% AS30693 -- EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation 17 - 198.187.189.0/24 5026 0.2% AS8137 -- DISNEYONLINE-AS - Disney Online 18 - 193.19.90.0/23 4868 0.2% AS29684 -- NOURNET-ASN Nour Communication Co.Ltd - Nournet 19 - 203.215.32.0/24 4228 0.2% AS55330 -- GCN-DCN-AS AFGHANTELECOM GOVERNMENT COMMUNICATION NETWORK 20 - 64.187.64.0/23 4100 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. 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 mike-nanog at tiedyenetworks.com Fri May 31 22:25:22 2013 From: mike-nanog at tiedyenetworks.com (Mike) Date: Fri, 31 May 2013 15:25:22 -0700 Subject: Headscratcher of the week Message-ID: <51A92352.3000906@tiedyenetworks.com> Gang, In the interest of sharing 'the weird stuff' which makes the job of being an operator ... uh, fun? is that the right word?..., I would like to present the following two smokeping latency/packetloss plots, which are by far the weirdest I have ever seen. These plots are from our smokeping host out to a customer location. The customer is connected via DSL and they run PPPoE over it to connect with our access concentrator. There is about 5 physical insfastructure hops between the host and customer; The switch, the BRAS, the Switch again, and then directly to the DSLAM and then customer on the end. The 10 day plot: http://picpaste.com/10_Day_graph-YV3IdvRV.png The 30 hour plot: http://picpaste.com/30_hour_graph-DrwzfhYJ.png How can you possibly have consistent increase in latency like that? I'd love to hear theories (or offers of beer, your choice!). Happy friday all! Mike- From msa at latt.net Fri May 31 22:26:45 2013 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 31 May 2013 18:26:45 -0400 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: References: <20130531184934.GA27305@puck.nether.net> Message-ID: <20130531222645.GC27305@puck.nether.net> On Fri, May 31, 2013 at 12:06:50PM -0700, Tim M Edwards wrote: > Needs to be a Corporate CC though. Nahh, they take my personal card in Phoenix and SF all the time. --msa From carlos at race.com Fri May 31 22:37:14 2013 From: carlos at race.com (Carlos Alcantar) Date: Fri, 31 May 2013 22:37:14 +0000 Subject: Cat-5 cables near 200 Paul, SF In-Reply-To: <20130531222645.GC27305@puck.nether.net> Message-ID: I don't think they will care how you pay. It's just the question if you do or don't need an account. 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 -----Original Message----- From: "Majdi S. Abbas" Date: Friday, May 31, 2013 3:26 PM To: Tim M Edwards Cc: "nanog at nanog.org" Subject: Re: Cat-5 cables near 200 Paul, SF On Fri, May 31, 2013 at 12:06:50PM -0700, Tim M Edwards wrote: > Needs to be a Corporate CC though. Nahh, they take my personal card in Phoenix and SF all the time. --msa From jof at thejof.com Fri May 31 22:39:39 2013 From: jof at thejof.com (Jonathan Lassoff) Date: Fri, 31 May 2013 15:39:39 -0700 Subject: Headscratcher of the week In-Reply-To: <51A92352.3000906@tiedyenetworks.com> References: <51A92352.3000906@tiedyenetworks.com> Message-ID: Those are some truly perplexing graphs. Quite strange that it appears linear, as if something is slightly changing over time or growing/shrinking at a constant-ish rate. Do you have throughput or PPS graphs for the intermediate links as well? Any similar correlations in the derivative slope? My only hunch would be some intermediate buffer being increasingly full over time, as some other application riding the path linearly grows in packets/second or bits/second. Cheers, jof On Fri, May 31, 2013 at 3:25 PM, Mike wrote: > Gang, > > In the interest of sharing 'the weird stuff' which makes the job of > being an operator ... uh, fun? is that the right word?..., I would like to > present the following two smokeping latency/packetloss plots, which are by > far the weirdest I have ever seen. > > These plots are from our smokeping host out to a customer location. > The customer is connected via DSL and they run PPPoE over it to connect with > our access concentrator. There is about 5 physical insfastructure hops > between the host and customer; The switch, the BRAS, the Switch again, and > then directly to the DSLAM and then customer on the end. > > > The 10 day plot: > http://picpaste.com/10_Day_graph-YV3IdvRV.png > > The 30 hour plot: > http://picpaste.com/30_hour_graph-DrwzfhYJ.png > > > How can you possibly have consistent increase in latency like that? > I'd love to hear theories (or offers of beer, your choice!). > > Happy friday all! > > > Mike- > From jeff-kell at utc.edu Fri May 31 22:39:52 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 31 May 2013 18:39:52 -0400 Subject: Headscratcher of the week In-Reply-To: <51A92352.3000906@tiedyenetworks.com> References: <51A92352.3000906@tiedyenetworks.com> Message-ID: <51A926B8.1080504@utc.edu> OK, here's a wild guess from left-field. Well, at least from left-field where I made at least one game-saving catch :) We had a similar case some years back, but it was a ramp-up in overall traffic we were looking at. If you're looking at latency, it could be related to traffic (do you have traffic graphs?). One particular user that was accustomed to Windows and trying to get started with Linux was "playing games" with our NAT firewall. Rather than file a request with us for a static NAT and firewall openings for their "new" Linux server, they discovered that as long as they generated some internet traffic periodically, they could defeat the NAT translation timeout, and essentially keep a static outside IP. Problem was, they "crontab"ed a "ping" of an outside server to run once a minute. Just a "ping x.x.x.x". Windows as we know defaults to only ping 4 times then quit. Linux does not :) So you might look for some "recurring scheduled event" on the customer's end that might be cumulative rather than simply recurring. Jeff On 5/31/2013 6:25 PM, Mike wrote: > Gang, > > In the interest of sharing 'the weird stuff' which makes the job > of being an operator ... uh, fun? is that the right word?..., I would > like to present the following two smokeping latency/packetloss plots, > which are by far the weirdest I have ever seen. > > These plots are from our smokeping host out to a customer > location. The customer is connected via DSL and they run PPPoE over it > to connect with our access concentrator. There is about 5 physical > insfastructure hops between the host and customer; The switch, the > BRAS, the Switch again, and then directly to the DSLAM and then > customer on the end. > > > The 10 day plot: > http://picpaste.com/10_Day_graph-YV3IdvRV.png > > The 30 hour plot: > http://picpaste.com/30_hour_graph-DrwzfhYJ.png > > > How can you possibly have consistent increase in latency like > that? I'd love to hear theories (or offers of beer, your choice!). > > Happy friday all! > > > Mike- > >