From marktees at gmail.com Thu Aug 1 00:00:49 2013 From: marktees at gmail.com (Mark Tees) Date: Thu, 1 Aug 2013 10:00:49 +1000 Subject: nLayer IP transit Message-ID: Howdy listers, I remember reading a while back that customers of nLayer IP transit services could send in Flowspec rules to nLayer. Anyone know if that is true/current? Thanks, -- Regards, Mark From patrick at ianai.net Thu Aug 1 00:03:19 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 31 Jul 2013 20:03:19 -0400 Subject: nLayer IP transit In-Reply-To: References: Message-ID: <736DD1D9-189E-43F5-9810-A1014B1EEE83@ianai.net> On Jul 31, 2013, at 20:00 , Mark Tees wrote: > I remember reading a while back that customers of nLayer IP transit > services could send in Flowspec rules to nLayer. Anyone know if that is > true/current? Not any more. -- 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 bottiger10 at gmail.com Thu Aug 1 00:07:57 2013 From: bottiger10 at gmail.com (bottiger) Date: Wed, 31 Jul 2013 17:07:57 -0700 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> Message-ID: I realize the root cause is security-oblivious designers and one level below that, lack of BCP38. But realistically those 2 problems are not going to be solved any time in the next decade. I have tested 7 large hosting networks only one of them had BCP38. To my knowledge it is practically impossible for someone outside a multi-homed network to know if they allow spoofing which means it will be difficult to punish. It also cost time and money to maintain these ACLs, much more than blocking the occasional wide-spread protocol with 8000x amplification every couple of years. I am here to talk about solutions today. BCP38 has been repeated to death and people aren't going to start doing it because I said so. The fact that the amplification factor is so high means that you need to ensure near 100% conformity even if everyone started to become BCP38 compliant today. On Wed, Jul 31, 2013 at 4:42 PM, Jimmy Hess wrote: > On 7/31/13, Blake Dunlap wrote: >> I bet blocking all SYN packets and non related flow UDP packets to >> customers would be even more effective. Why don't we do that and be done >> with it instead of playing whack a mole every 3 months when someone finds >> some new service that was poorly designed so that it can be used to send a >> flood? > > Because it breaks applications that people are paying to be able to use. > > The way I see it; more and more samples keep getting found about > protocols abused because networks have not implemented BCP38. > > The latest SNMP trend is just another uptick to the sample size, and > proof that Closing off perfectly OK recursive DNS services is > totally inadequate and not a useful long-term fix to the problem of > DDoS or IP/UDP reflection attacks. > > Asking folks to improve the security of access to their SNMP instances > is just chasing the latest exploit implementation, with no attention > to the vulnerability or the root cause.... > > -- > -JH > From jcurran at arin.net Thu Aug 1 02:14:52 2013 From: jcurran at arin.net (John Curran) Date: Thu, 1 Aug 2013 02:14:52 +0000 Subject: ARIN WHOIS for leads In-Reply-To: <20985.18076.970267.597692@world.std.com> References: <51F2968A.3090701@opus1.com> <51F92683.3080200@west.net> <20985.18076.970267.597692@world.std.com> Message-ID: <5E6D223F-E8A8-447D-954D-9547245FF181@corp.arin.net> On Jul 31, 2013, at 1:17 PM, Barry Shein wrote: > The usual method is to insert "ringers" which would be info which > points back at non-existant people with valid-looking contact > information. > > If for example they called a phone number, or several, owned by ARIN > (or a service they employed) asking for James T Kirk or Diana Prince > then that would be a problem and should be logged. There are some interesting non-obvious elements in the database for such purposes and we do take action when they are triggered. FYI, /John John Curran President and CEO ARIN From marka at isc.org Thu Aug 1 02:58:02 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 01 Aug 2013 12:58:02 +1000 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: Your message of "Wed, 31 Jul 2013 17:07:57 -0700." References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> Message-ID: <20130801025803.1226337E762E@drugs.dv.isc.org> In message , bottiger writes: > I realize the root cause is security-oblivious designers and one level > below that, lack of BCP38. > > But realistically those 2 problems are not going to be solved any time > in the next decade. I have tested 7 large hosting networks only one of > them had BCP38. Then name and shame. > To my knowledge it is practically impossible for someone outside a > multi-homed network to know if they allow spoofing which means it will > be difficult to punish. It also cost time and money to maintain these > ACLs, much more than blocking the occasional wide-spread protocol with > 8000x amplification every couple of years. Just define a EDNS option which contains the real ip address and update who-am-i services to look for that when replying, use a modified DNS cookies or similar to prevent this being used as amplifier. You can do this with a experimental EDNS option code points today. Send a non-spoofed request then send a spoofed request using the cookie learnt from the first request. Standardise it and every nameserver on the planet and be used to detect if spoofing is possible. Using DNS puts up to costs for ISP's that want to block people checking. The blackhats already check whether spoofing is possible so there is little point in blocking whitehats checking. As for time and money to maintain these acls it really shouldn't now that SIDR is becoming a reality. Present a properly signed CERT to the other providers and automatically generate the acls based on those. There is a little setup cost to get the system running and almost no additional recurrent costs to keep it up to date. The CERTs need to be generated for sBGP anyway. > I am here to talk about solutions today. BCP38 has been repeated to > death and people aren't going to start doing it because I said so. The > fact that the amplification factor is so high means that you need to > ensure near 100% conformity even if everyone started to become BCP38 > compliant today. > > On Wed, Jul 31, 2013 at 4:42 PM, Jimmy Hess wrote: > > On 7/31/13, Blake Dunlap wrote: > >> I bet blocking all SYN packets and non related flow UDP packets to > >> customers would be even more effective. Why don't we do that and be done > >> with it instead of playing whack a mole every 3 months when someone finds > >> some new service that was poorly designed so that it can be used to send a > >> flood? > > > > Because it breaks applications that people are paying to be able to use. > > > > The way I see it; more and more samples keep getting found about > > protocols abused because networks have not implemented BCP38. > > > > The latest SNMP trend is just another uptick to the sample size, and > > proof that Closing off perfectly OK recursive DNS services is > > totally inadequate and not a useful long-term fix to the problem of > > DDoS or IP/UDP reflection attacks. > > > > Asking folks to improve the security of access to their SNMP instances > > is just chasing the latest exploit implementation, with no attention > > to the vulnerability or the root cause.... > > > > -- > > -JH > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From saku at ytti.fi Thu Aug 1 06:13:59 2013 From: saku at ytti.fi (Saku Ytti) Date: Thu, 1 Aug 2013 09:13:59 +0300 Subject: nLayer IP transit In-Reply-To: References: Message-ID: <20130801061359.GA14921@pob.ytti.fi> On (2013-08-01 10:00 +1000), Mark Tees wrote: > I remember reading a while back that customers of nLayer IP transit > services could send in Flowspec rules to nLayer. Anyone know if that is > true/current? Anyone planning to do this might want to be aware that the validation process of flowspec does not limit actions. In practice this means, if you do run flowspec to your customers, your customers likely can inject traffic to arbitrary VRFs. I feel RFC should have explicitly stated valid actions for validation process, which operator MAY change, and any other action MUST cause validation process to fail. -- ++ytti From saku at ytti.fi Thu Aug 1 06:31:51 2013 From: saku at ytti.fi (Saku Ytti) Date: Thu, 1 Aug 2013 09:31:51 +0300 Subject: SNMP DDoS: the vulnerability you might not know you have In-Reply-To: References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> Message-ID: <20130801063151.GA16879@pob.ytti.fi> On (2013-07-31 17:07 -0700), bottiger wrote: > But realistically those 2 problems are not going to be solved any time > in the next decade. I have tested 7 large hosting networks only one of > them had BCP38. I wonder if it's truly that unrealistic. If we target access networks, it seems impractical target. We have about 40k origin only ASNs and about 7k ASNs which offer transit, who could arguably trivially ACL those 40k peers. If we truly tried, as a community to make deploying these ACLs easy and actively reach out those 7k ASNs and offer help, would it be unrealistic to have ACL deployed to sufficiently large portion of networks to make spoofing impractical/expensive? Do we have other approaches? Can we make this ACL dynamic to a degree? Can we extract ACL information from BGP table? If origin only ASN advertises prefix to global table anywhere, allow it at matching 'remote-as' port. Does not look like difficult feature to build, does not require magic HW support, essentially dynamically built ACL. After this spoof would require injected trash BGP route, which would also steal return traffic, making it useless for DoS. -- ++ytti From snar at snar.spb.ru Thu Aug 1 07:35:38 2013 From: snar at snar.spb.ru (Alexandre Snarskii) Date: Thu, 1 Aug 2013 11:35:38 +0400 Subject: nLayer IP transit In-Reply-To: <20130801061359.GA14921@pob.ytti.fi> References: <20130801061359.GA14921@pob.ytti.fi> Message-ID: <20130801073538.GA11283@snar.spb.ru> On Thu, Aug 01, 2013 at 09:13:59AM +0300, Saku Ytti wrote: > On (2013-08-01 10:00 +1000), Mark Tees wrote: > > > I remember reading a while back that customers of nLayer IP transit > > services could send in Flowspec rules to nLayer. Anyone know if that is > > true/current? > > Anyone planning to do this might want to be aware that the validation > process of flowspec does not limit actions. > > In practice this means, if you do run flowspec to your customers, your > customers likely can inject traffic to arbitrary VRFs. You can match flow actions by extended communities and not accept actions you do not like. For example, to permit only "discard" action you can match community flow_discard members traffic-rate:*:0; Or am I missing something ? > I feel RFC should have explicitly stated valid actions for validation > process, which operator MAY change, and any other action MUST cause > validation process to fail. > > > -- > ++ytti -- In theory, there is no difference between theory and practice. But, in practice, there is. From saku at ytti.fi Thu Aug 1 07:55:04 2013 From: saku at ytti.fi (Saku Ytti) Date: Thu, 1 Aug 2013 10:55:04 +0300 Subject: nLayer IP transit In-Reply-To: <20130801073538.GA11283@snar.spb.ru> References: <20130801061359.GA14921@pob.ytti.fi> <20130801073538.GA11283@snar.spb.ru> Message-ID: <20130801075504.GA13639@pob.ytti.fi> On (2013-08-01 11:35 +0400), Alexandre Snarskii wrote: > You can match flow actions by extended communities and not accept > actions you do not like. For example, to permit only "discard" action > you can match > > community flow_discard members traffic-rate:*:0; > > Or am I missing something ? No you're not missing anything. This is what I implied with 'likely', I feel validation check should guarantee eBGP safety as most operators won't deploy additional security via manual config, because issue isn't mentioned in RFC or vendor docs. -- ++ytti From Parthiv.Shah at theclearinghouse.org Thu Aug 1 14:00:02 2013 From: Parthiv.Shah at theclearinghouse.org (Shah, Parthiv) Date: Thu, 1 Aug 2013 10:00:02 -0400 Subject: BGP related question Message-ID: <9B39CC09BCBB9D4FBF6BE4774E4F0A321117ED366D@NYEXCHANGE.NYCH.ORG> My apology if I am asking for a repeat question on the list. On 7/29/13 I read an incident about accidental BGP broadcast see article here https://isc.sans.edu/diary/BGP+multiple+banking+addresses+hijacked/16249 or older 2008 incident http://www.renesys.com/2008/02/pakistan-hijacks-youtube-1/ My questions: 1) I would like to understand how can we detect and potentially prevent activities like this? I understand native BGP was not design to authenticate IP owners to the BGP broadcaster. Therefore, issues like this due to a human error would happen. How can activities like this be detected as this is clearly a threat if someone decides to broadcast IP networks of an organization and knock the real org. off the Net. 2) In reference to prevention, I recall there were discussions about secure BGP (S-BGP), Pretty Good BGP, or Secure Original BGP but I don't remember if any one of them was finalized (from practicality viewpoint) and if any one of them is implementable/enforceable by ISPs (do anyone have any insight)? 3) If I was to ask for an opinion, from your viewpoint which one is better and why and which one is not doable and why not? Thank you in advance, Parthiv This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and notify us immediately. From chip.gwyn at gmail.com Thu Aug 1 16:00:28 2013 From: chip.gwyn at gmail.com (chip) Date: Thu, 1 Aug 2013 12:00:28 -0400 Subject: BGP related question In-Reply-To: <9B39CC09BCBB9D4FBF6BE4774E4F0A321117ED366D@NYEXCHANGE.NYCH.ORG> References: <9B39CC09BCBB9D4FBF6BE4774E4F0A321117ED366D@NYEXCHANGE.NYCH.ORG> Message-ID: For detection, there are a few solutions, but mostly it's just monitoring the route table for your specific routes and being alerted when things change. For prevention there are things like RPKI ( https://www.arin.net/resources/rpki/index.html) that can help. There are a few other possibilities as well, each with their own pros and cons and various cases of weakness. RPKI seems to be the current favorite and most widely supported. Well, by vendors at least... --chip On Thu, Aug 1, 2013 at 10:00 AM, Shah, Parthiv < Parthiv.Shah at theclearinghouse.org> wrote: > My apology if I am asking for a repeat question on the list. On 7/29/13 I > read an incident about accidental BGP broadcast see article here > https://isc.sans.edu/diary/BGP+multiple+banking+addresses+hijacked/16249or older 2008 incident > http://www.renesys.com/2008/02/pakistan-hijacks-youtube-1/ > > My questions: > > > 1) I would like to understand how can we detect and potentially > prevent activities like this? I understand native BGP was not design to > authenticate IP owners to the BGP broadcaster. Therefore, issues like this > due to a human error would happen. How can activities like this be detected > as this is clearly a threat if someone decides to broadcast IP networks of > an organization and knock the real org. off the Net. 2) In reference to > prevention, I recall there were discussions about secure BGP (S-BGP), > Pretty Good BGP, or Secure Original BGP but I don't remember if any one of > them was finalized (from practicality viewpoint) and if any one of them is > implementable/enforceable by ISPs (do anyone have any insight)? 3) If I was > to ask for an opinion, from your viewpoint which one is better and why and > which one is not doable and why not? > > Thank you in advance, > Parthiv > > > This e-mail may contain information that is privileged or confidential. If > you are not the intended recipient, please delete the e-mail and notify us > immediately. > -- Just my $.02, your mileage may vary, batteries not included, etc.... From sam at wwcandt.com Thu Aug 1 17:00:28 2013 From: sam at wwcandt.com (sam at wwcandt.com) Date: Thu, 1 Aug 2013 13:00:28 -0400 (EDT) Subject: Feds snooping and FCC 477 and FCC 499 forms and 214 licenses Message-ID: <53478.71.62.150.38.1375376428.squirrel@www.systemetrixs.com> Good Morning Nanog List, I'm not normally the tinfoil hat type howerver I do want to know other operators opinions on the FCC 477, 499 and the 214 license requirements in light of the recent revealations. Do you think the info is actually for the stated purposes? I'm trying hard not to become a member of the tin foil club but it's getting hard each day. Thanks. Sam * Moderators please delete the copy of this I sent from sam at circlenet.us. From otis at ocosa.com Thu Aug 1 16:31:06 2013 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Thu, 1 Aug 2013 11:31:06 -0500 Subject: BGP related question In-Reply-To: <9B39CC09BCBB9D4FBF6BE4774E4F0A321117ED366D@NYEXCHANGE.NYCH.ORG> References: <9B39CC09BCBB9D4FBF6BE4774E4F0A321117ED366D@NYEXCHANGE.NYCH.ORG> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B0187B5@ocsbs.ocosa.com> -----Original Message----- From: Shah, Parthiv [mailto:Parthiv.Shah at theclearinghouse.org] Sent: Thursday, August 01, 2013 9:00 AM To: nanog at nanog.org Subject: BGP related question >1) I would like to understand how can we detect and potentially prevent activities like this? I understand native BGP was not design to authenticate IP owners to the BGP broadcaster. Therefore, issues like this due to a human error would happen. How >can activities like this be detected as this is clearly a threat if someone decides to broadcast IP networks of an organization and knock the real org. off the Net. The most basic short answer would be use of proper filtering and LOAs. Transit providers should be checking whether or not customers have permission to act as a transit provider for prefixes or originate the prefixes not registered to them by the RIRs. If every operator would have controls in place to ensure folks are originating the routes they are supposed to then you wouldn't have a problem. However, it seems the best course of action is to implement "checks and balances" internally to each organization which usually prevents all together or mitigate things as much as possible. Human error is inevitable. We have outside monitoring (bgpmon) for our prefixes. >2) In reference to prevention, I recall there were discussions about secure BGP (S-BGP), Pretty Good BGP, or Secure Original BGP but I don't remember if any one of them was finalized (from practicality viewpoint) and if any one of them is >implementable/enforceable by ISPs (do anyone have any insight)? If I had to pick one based on practicality it would be secure original BGP. You can create a fairly secure BGP session by using multiple mechanisms (prefix lists/filters/routemaps, password, iACL, TTL-security, AS limits etc.) However, there are caveats to anything. From sam at circlenet.us Thu Aug 1 15:29:12 2013 From: sam at circlenet.us (Sam Moats) Date: Thu, 01 Aug 2013 11:29:12 -0400 Subject: Feds snooping and FCC 477 and FCC 499 forms and 214 licenses In-Reply-To: References: Message-ID: On 2013-08-01 10:57, Sam Moats wrote: Good Morning Nanog List, I'm not normally the tinfoil hat type howerver I do want to know other operators opinions on the FCC 477, 499 and the 214 license requirements in light of the recent revealations. Do you think the info is actually for the stated purposes? I'm trying hard not to become a member of the tin foil club but it's getting hard each day. Thanks. Sam From sam at circlenet.us Thu Aug 1 14:57:19 2013 From: sam at circlenet.us (Sam Moats) Date: Thu, 01 Aug 2013 10:57:19 -0400 Subject: FCC 477 and FCC499 forms Message-ID: Good Morning Nanog List, I'm not normally the tinfoil hat type howerver I do want to know other operators opinions on the FCC 477, 499 and the 214 license requirements in light of the recent revealations. Do you think the info is actually for the stated purposes? I'm trying hard not to become a member of the tin foil club but it's getting hard each day. Thanks. Sam From ras at e-gerbil.net Thu Aug 1 17:30:53 2013 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 1 Aug 2013 12:30:53 -0500 Subject: nLayer IP transit In-Reply-To: References: Message-ID: <20130801173053.GV67768@gerbil.cluepon.net> On Thu, Aug 01, 2013 at 10:00:49AM +1000, Mark Tees wrote: > Howdy listers, > > I remember reading a while back that customers of nLayer IP transit > services could send in Flowspec rules to nLayer. Anyone know if that > is true/current? We were forced to stop offering flowspec connections to customers, after we started experiencing a rash of issues with it. Among other things, we found ways for flowspec generated rules to easily cause non line-rate performance on Juniper MX boxes, and we had a couple of incidents where customer generated routes were able to cause cascading failure behaviors like crashing the firewall compiler processes across the entire network. I previously mentioned some of this here: http://mailman.nanog.org/pipermail/nanog/2011-January/030051.html There have also been a few other high profile outages caused by bugs in the Juniper implementation, for example: https://support.cloudflare.com/entries/23294588-CloudFlare-Post-Mortem-from-Outage-on-March-3-2013 As a concept I still very much like Flowspec, and wish we could continue to offer it to customers, but as with any "new" routing protocol there are significant risks of network-wide impact if the implementation is not stable. IMHO Juniper has done a horrible job of maintaining support for Flowspec in recent years, and has effectively abandoned doing the proper testing and support necessary to run it in production. Until that changes, or until some other major router vendors pick it up and do better with it, I don't expect to see any major changes in this position any time soon. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From betty at newnog.org Thu Aug 1 20:57:53 2013 From: betty at newnog.org (Betty Burke ) Date: Thu, 1 Aug 2013 16:57:53 -0400 Subject: [NANOG-announce] NANOG on The Road In-Reply-To: References: Message-ID: NANOGers, You are invited to attend NANOG's first one-day meeting, "NANOG on the Road"joint with ARIN on September 10, 2013 in Portland, OR. ARIN + NANOG on the Road Portland will provide an opportunity to network with colleagues, access to a day's worth of professional education and current Internet operations. Content will be provided by speakers from both ARIN and NANOG. ** ** Complete Event details are available on the NANOG website: ARIN + NANOG on the Road in Portland, Oregon **** will be held at the Courtyard by Marriott Portland Downtown/Convention Center. **** * * Registration is free but required, so make sure to register now ! Spend the morning getting up to speed on the history of the Regional Registry System, Internet Governance, and ARIN technical services. Find out the latest about Internet number resource management ? including IPv4 transfers and IPv6 adoption, and current ARIN policy developments. Then spend some time networking with fellow attendees over lunch. **** ** ** Kick off the afternoon with tutorials from ARIN on RPKI, NANOG on DNSSEC, and additional NANOG educational content. NANOG will host a session on its role in the network operator community and ways to engage with and take part in its lively professional community of Internet engineers and architects. The day will conclude with an Open Microphone / Q&A session, followed by a networking Happy Hour where conversation can continue in a more relaxed setting. **** ** ** Attendees who complete a short survey about the event will be eligible to win one of two $100 Amazon gift cards. *Register today* !**** ** ** Please feel free to forward this invitation to friends and colleagues who may be interested in attending this ARIN + NANOG on the Road event. Contact us at nanog-support at nanog.org if you have any questions. **** ** ** Regards, **** ** ** ARIN + NANOG on the Road Team**** American Registry for Internet Numbers (ARIN) **** North American Network Operators Group (NANOG) -- 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 marktees at gmail.com Thu Aug 1 21:11:34 2013 From: marktees at gmail.com (Mark Tees) Date: Fri, 2 Aug 2013 07:11:34 +1000 Subject: nLayer IP transit In-Reply-To: <20130801173053.GV67768@gerbil.cluepon.net> References: <20130801173053.GV67768@gerbil.cluepon.net> Message-ID: <50D67364-EAB7-40E8-A3F1-E34B24007741@gmail.com> Thanks for the replies. I think I saw somewhere around the Cloudflare outage post someone mentioning that since the person at Juniper that was responsible for Flowspec left it all went down hill. I take it then Flowspec is still used internally then? I am still wondering if its best to avoid Flowspec and roll your own firewall rules applied via Netconf for transit interfaces to achieve the same sort of functionality. On 02/08/2013, at 3:30 AM, Richard A Steenbergen wrote: > On Thu, Aug 01, 2013 at 10:00:49AM +1000, Mark Tees wrote: >> Howdy listers, >> >> I remember reading a while back that customers of nLayer IP transit >> services could send in Flowspec rules to nLayer. Anyone know if that >> is true/current? > > We were forced to stop offering flowspec connections to customers, after > we started experiencing a rash of issues with it. Among other things, we > found ways for flowspec generated rules to easily cause non line-rate > performance on Juniper MX boxes, and we had a couple of incidents where > customer generated routes were able to cause cascading failure behaviors > like crashing the firewall compiler processes across the entire network. > > I previously mentioned some of this here: > > http://mailman.nanog.org/pipermail/nanog/2011-January/030051.html > > There have also been a few other high profile outages caused by bugs in > the Juniper implementation, for example: > > https://support.cloudflare.com/entries/23294588-CloudFlare-Post-Mortem-from-Outage-on-March-3-2013 > > As a concept I still very much like Flowspec, and wish we could continue > to offer it to customers, but as with any "new" routing protocol there > are significant risks of network-wide impact if the implementation is > not stable. > > IMHO Juniper has done a horrible job of maintaining support for Flowspec > in recent years, and has effectively abandoned doing the proper testing > and support necessary to run it in production. Until that changes, or > until some other major router vendors pick it up and do better with it, > I don't expect to see any major changes in this position any time soon. > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From andree+nanog at toonk.nl Thu Aug 1 22:42:37 2013 From: andree+nanog at toonk.nl (Andree Toonk) Date: Thu, 01 Aug 2013 15:42:37 -0700 Subject: BGP related question In-Reply-To: <9B39CC09BCBB9D4FBF6BE4774E4F0A321117ED366D@NYEXCHANGE.NYCH.ORG> References: <9B39CC09BCBB9D4FBF6BE4774E4F0A321117ED366D@NYEXCHANGE.NYCH.ORG> Message-ID: <51FAE45D.5010507@toonk.nl> Hi Parthiv, .-- My secret spy satellite informs me that at 2013-08-01 7:00 AM Shah, Parthiv wrote: > My apology if I am asking for a repeat question on the list. On 7/29/13 I read an incident about accidental BGP broadcast see article here https://isc.sans.edu/diary/BGP+multiple+banking+addresses+hijacked/16249 or older 2008 incident http://www.renesys.com/2008/02/pakistan-hijacks-youtube-1/ This was the same issue as was discussed last week on Nanog: http://mailman.nanog.org/pipermail/nanog/2013-July/059992.html In summary there were 72 prefixes hijacked, they also leaked a few hundred more specifics of their own prefixes. You can examples of similar events here: http://www.bgpmon.net/blog/ > 1) I would like to understand how can we detect and potentially prevent activities like this? I understand native BGP was not design to authenticate IP owners to the BGP broadcaster. Therefore, issues like this due to a human error would happen. How can activities like this be detected as this is clearly a threat if someone decides to broadcast IP networks of an organization and knock the real org. off the Net. There are a few BGP monitoring tools available, BGPMon.net is one such service. 2) In reference to prevention, I recall there were discussions about secure BGP (S-BGP), Pretty Good BGP, or Secure Original BGP but I don't remember if any one of them was finalized (from practicality viewpoint) and if any one of them is implementable/enforceable by ISPs (do anyone have any insight)? The thing we can improve today is providers doing a better job of filtering. But that's still not full proof. Since many folks use max-prefix filters only on for example Internet Exchange points, it's easy to pick up a hijacked route from peers. In the long term RPKI should solve this, but that's not full proof either. The next step is full path validation, that's going to take a while. For more info see for example: http://www.bgpmon.net/securing-bgp-routing-with-rpki-and-roas/ or http://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure Cheers, Andree From symack at gmail.com Fri Aug 2 00:53:48 2013 From: symack at gmail.com (Nick Khamis) Date: Thu, 1 Aug 2013 20:53:48 -0400 Subject: Revealed: NSA program collects 'nearly everything a user does on the internet' In-Reply-To: References: Message-ID: I'll make this short. Is our OpenVPN server prone? From akennykant at gmail.com Fri Aug 2 00:55:19 2013 From: akennykant at gmail.com (Kenny Kant) Date: Thu, 1 Aug 2013 19:55:19 -0500 Subject: L3 Contact Message-ID: <98C27701-12FF-482E-8E27-CCD2713F54EE@gmail.com> Will an IP engineer from Level3 contact me off list. We having trouble routing traffic through.. Possible bogon update issue ? Thanks Sent from my iPhone From akennykant at gmail.com Fri Aug 2 05:07:27 2013 From: akennykant at gmail.com (Kenny Kant) Date: Fri, 2 Aug 2013 00:07:27 -0500 Subject: IP allocations / bogon - verification Message-ID: Gang, I apologize for a double post on this same topic tonight however I thought that broadening my request may help our cause. This month we had one of our IP allocations revoked and just recently got everything squared away with ARIN and things are "turned back" on so to speak. However I still have some customers having issues hitting a number of financial related websites ..etc and I assume its because of bogons ..etc I saw some earlier posts on here where folks have posted their allocation to ensure that others are routing it properly so I wanted to do the same. My allocation which has recently been revived: 66.185.0.0/20 Test point traceroute .etc 66.185.0.198 We do seem to be having some issues with some level 3 routing our range to some desitnations and can provide specifics off list. Thanks all for the help / verification. Kenny From morrowc.lists at gmail.com Fri Aug 2 07:17:22 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 2 Aug 2013 03:17:22 -0400 Subject: Revealed: NSA program collects 'nearly everything a user does on the internet' In-Reply-To: References: Message-ID: On Thu, Aug 1, 2013 at 8:53 PM, Nick Khamis wrote: > I'll make this short. Is our OpenVPN server prone? > if you sent pictures it's surelybe easier to tell if it were prone, or standing... From ristic.sasa at gmail.com Fri Aug 2 07:18:09 2013 From: ristic.sasa at gmail.com (Sasa Ristic) Date: Fri, 2 Aug 2013 09:18:09 +0200 Subject: IP allocations / bogon - verification In-Reply-To: References: Message-ID: from europe, serbia seems to be working via level3... # traceroute 66.185.0.198 traceroute to 66.185.0.198 (66.185.0.198), 30 hops max, 40 byte packets 1 XX.verat.net (213.244.xx.xxx) 0.780 ms 1.692 ms 1.697 ms 2 XX.verat.net (217.26.xx.xxx) 3.062 ms 3.054 ms 3.018 ms 3 clint.noc.verat.net (62.108.96.77) 2.973 ms 2.938 ms 2.901 ms 4 195.178.34.125 (195.178.34.125) 2.839 ms 3.000 ms 2.968 ms 5 212.200.5.105 (212.200.5.105) 15.477 ms 15.383 ms 15.333 ms 6 212.73.203.245 (212.73.203.245) 15.400 ms 14.308 ms 14.914 ms 7 ae-0-11.bar1.vienna1.level3.net (4.69.153.149) 14.730 ms 14.615 ms 14.648 ms 8 ae-12-12.ebr2.frankfurt1.level3.net (4.69.153.146) 158.533 ms 158.503 ms 158.468 ms 9 ae-93-93.csw4.frankfurt1.level3.net (4.69.163.14) 159.090 ms ae-83-83.csw3.frankfurt1.level3.net (4.69.163.10) 158.330 ms 158.264 ms 10 ae-81-81.ebr1.frankfurt1.level3.net (4.69.140.9) 158.135 ms ae-71-71.ebr1.frankfurt1.level3.net (4.69.140.5) 158.150 ms ae-91-91.ebr1.frankfurt1.level3.net (4.69.140.13) 155.613 ms 11 ae-47-47.ebr2.paris1.level3.net (4.69.143.142) 158.885 ms * 158.402 ms 12 ae-41-41.ebr2.washington1.level3.net (4.69.137.50) 156.600 ms ae-44-44.ebr2.washington1.level3.net (4.69.137.62) 154.621 ms 157.051 ms 13 ae-72-72.csw2.washington1.level3.net (4.69.134.150) 156.779 ms ae-92-92.csw4.washington1.level3.net (4.69.134.158) 158.681 ms ae-72-72.csw2.washington1.level3.net (4.69.134.150) 164.913 ms 14 ae-81-81.ebr1.washington1.level3.net (4.69.134.137) 154.991 ms ae-91-91.ebr1.washington1.level3.net (4.69.134.141) 155.272 ms 156.546 ms 15 ae-2-2.ebr3.atlanta2.level3.net (4.69.132.85) 158.204 ms 158.965 ms 158.492 ms 16 ae-7-7.ebr3.dallas1.level3.net (4.69.134.21) 157.186 ms 157.565 ms 157.564 ms 17 ae-93-93.csw4.dallas1.level3.net (4.69.151.169) 159.837 ms ae-83-83.csw3.dallas1.level3.net (4.69.151.157) 158.034 ms ae-73-73.csw2.dallas1.level3.net (4.69.151.145) 156.320 ms 18 ae-82-82.ebr2.dallas1.level3.net (4.69.151.154) 161.284 ms ae-72-72.ebr2.dallas1.level3.net (4.69.151.142) 158.624 ms 159.402 ms 19 ae-5-5.car1.kansascity1.level3.net (4.69.135.229) 156.168 ms 156.481 ms 158.202 ms 20 ae-11-11.car2.kansascity1.level3.net (4.69.135.234) 160.914 ms 158.152 ms 160.836 ms 21 iowa-networ.car2.kansascity1.level3.net (4.53.34.114) 180.620 ms 180.514 ms 180.249 ms 22 ins-db1-et-12-1.desm.netins.net (167.142.67.6) 180.053 ms 179.767 ms 179.712 ms 23 prairieinet.desm.netins.net (167.142.53.18) 179.123 ms 178.434 ms 178.410 ms 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * host is btw. pingable: # ping 66.185.0.198 -A -q -c 5 PING 66.185.0.198 (66.185.0.198) 56(84) bytes of data. --- 66.185.0.198 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 657ms rtt min/avg/max/mdev = 162.617/163.933/165.772/1.296 ms, ipg/ewma 164.282/163.237 ms generally, it's visible from routers in Germany, and West Coast... On Fri, Aug 2, 2013 at 7:07 AM, Kenny Kant wrote: > Gang, > > I apologize for a double post on this same topic tonight however I thought > that broadening my request may help our cause. This month we had one of > our IP allocations revoked and just recently got everything squared away > with ARIN and things are "turned back" on so to speak. > > However I still have some customers having issues hitting a number of > financial related websites ..etc and I assume its because of bogons ..etc > > I saw some earlier posts on here where folks have posted their allocation > to ensure that others are routing it properly so I wanted to do the same. > > My allocation which has recently been revived: 66.185.0.0/20 > > Test point traceroute .etc 66.185.0.198 > > We do seem to be having some issues with some level 3 routing our range to > some desitnations and can provide specifics off list. > > Thanks all for the help / verification. > > Kenny > -- ricky From larry.brower at aramcoservices.com Fri Aug 2 01:49:21 2013 From: larry.brower at aramcoservices.com (BROWER, LARRY) Date: Fri, 2 Aug 2013 01:49:21 +0000 Subject: Revealed: NSA program collects 'nearly everything a user does on the internet' In-Reply-To: References: Message-ID: <6C89EEB4-C198-4463-924D-106BB405216F@aramcoservices.com> On Aug 1, 2013, at 7:55 PM, "Nick Khamis" wrote: > I'll make this short. Is our OpenVPN server prone? prone to what exactly? If you mean your connection to the server then I would say no but the server to other servers is a different story. From sgraun at airstreamcomm.net Fri Aug 2 13:37:21 2013 From: sgraun at airstreamcomm.net (sgraun at airstreamcomm.net) Date: Fri, 02 Aug 2013 08:37:21 -0500 Subject: ddos attacks Message-ID: I?m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What?s the best way people are dealing with them? Scott From Valdis.Kletnieks at vt.edu Fri Aug 2 14:36:10 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 02 Aug 2013 10:36:10 -0400 Subject: ddos attacks In-Reply-To: Your message of "Fri, 02 Aug 2013 08:37:21 -0500." References: Message-ID: <26118.1375454170@turing-police.cc.vt.edu> On Fri, 02 Aug 2013 08:37:21 -0500, sgraun at airstreamcomm.net said: > I???m curious to know what other service providers are doing to > alleviate/prevent ddos attacks from happening in your network. The answers will vary from "nothing" to "extensive network planning and contracts with mitigation services", depending on the respondent's budget and how many DDoS attacks they attract per fiscal year... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From patrick at ianai.net Fri Aug 2 14:38:15 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 2 Aug 2013 10:38:15 -0400 Subject: ddos attacks In-Reply-To: References: Message-ID: On Aug 02, 2013, at 09:37 , sgraun at airstreamcomm.net wrote: > I?m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What?s the best way people are dealing with them? #1: Ensure your network is BCP38 compliant. Hard to complain about others attacking you when you are not clear. And if you do not block source-address spoofing, you are not clean. As for the rest, I'll let others with more recent experience explain what they do. -- 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 jared at puck.nether.net Fri Aug 2 14:55:17 2013 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 2 Aug 2013 10:55:17 -0400 Subject: ddos attacks In-Reply-To: References: Message-ID: <1C2F65D3-1E71-4C08-9A05-BA6536FDBF40@puck.nether.net> On Aug 2, 2013, at 10:38 AM, "Patrick W. Gilmore" wrote: > On Aug 02, 2013, at 09:37 , sgraun at airstreamcomm.net wrote: > >> I?m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What?s the best way people are dealing with them? > > #1: Ensure your network is BCP38 compliant. > > Hard to complain about others attacking you when you are not clear. And if you do not block source-address spoofing, you are not clean. > > As for the rest, I'll let others with more recent experience explain what they do. We have had challenges with deploying BCP38, even on simple connections. We have outstanding defects in IOS-XR that prevent us from deploying it. Wherever possible we have enabled source address validation (bcp38). I do have a map of some networks that don't do this as a result of the OpenResolverProject.org data. Here's some top ASNs that can send spoofed packets: Count ASN --------------- 1006 18747 1004 262824 877 196753 522 29119 516 5617 514 34977 513 47570 513 12615 512 262336 512 12301 372 6739 These ASNs spoof my machine I use to send queries out to 8.8.8.8 and goole responds back to me. Likely some firewall/CPE/NAT that does this, but the provider lets those spoofed packets reach outside their network to google. I have many more of these if folks want to see a broader list. If you look at the ASN relationships involved here, it means either 3491 or 3257 allows these spoofed packets from 18747. - Jared From glen.kent at gmail.com Fri Aug 2 16:40:12 2013 From: glen.kent at gmail.com (Glen Kent) Date: Fri, 2 Aug 2013 22:10:12 +0530 Subject: OSPF Vulnerability - Owning the Routing Table Message-ID: Hi, Does anybody have details on what this vulnerability is? https://www.blackhat.com/us-13/briefings.html#Nakibly Glen From ghira at mistral.co.uk Fri Aug 2 16:51:21 2013 From: ghira at mistral.co.uk (Adam Atkinson) Date: Fri, 02 Aug 2013 17:51:21 +0100 Subject: OSPF Vulnerability - Owning the Routing Table In-Reply-To: References: Message-ID: <51FBE389.4050801@mistral.co.uk> Glen Kent wrote: > Hi, > > Does anybody have details on what this vulnerability is? > > https://www.blackhat.com/us-13/briefings.html#Nakibly > > Glen > Could it be related to: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130801-lsaospf announced very recently? There is a little more information here than in your link, but not enough to go out and reproduce the problem. From aledm at qix.co.uk Fri Aug 2 16:55:15 2013 From: aledm at qix.co.uk (Aled Morris) Date: Fri, 2 Aug 2013 17:55:15 +0100 Subject: OSPF Vulnerability - Owning the Routing Table In-Reply-To: References: Message-ID: Cisco published an advisory on OSPF vulnerability yesterday I think. I assume it's related. OSPFv3 is not vulnerable, and connections protected by MD5 are safe too, apparently. Aled On 2 August 2013 17:40, Glen Kent wrote: > Hi, > > Does anybody have details on what this vulnerability is? > > https://www.blackhat.com/us-13/briefings.html#Nakibly > > Glen > From achatz at forthnetgroup.gr Fri Aug 2 16:58:50 2013 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Fri, 02 Aug 2013 19:58:50 +0300 Subject: OSPF Vulnerability - Owning the Routing Table In-Reply-To: References: Message-ID: <51FBE54A.9010607@forthnetgroup.gr> These were published recently: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130801-lsaospf http://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2013-08-987&actionBtn=Search -- Tassos Glen Kent wrote on 02/08/2013 19:40: > Hi, > > Does anybody have details on what this vulnerability is? > > https://www.blackhat.com/us-13/briefings.html#Nakibly > > Glen > From leo.vegoda at icann.org Fri Aug 2 18:28:55 2013 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 2 Aug 2013 11:28:55 -0700 Subject: IP allocations / bogon - verification In-Reply-To: References: Message-ID: <5648A8908CCB564EBF46E2BC904A75B184E131A9BA@EXVPMBX100-1.exc.icann.org> Hi, Kenny Kant wrote: [...] > However I still have some customers having issues hitting a number of > financial related websites ..etc and I assume its because of bogons ..etc 66/8 was allocated to ARIN some 13 years ago and 66.185.0.0/20 seem to have been allocated to JAB Wireless a little over a year after that. I'd be surprised if your problems are due to people not updating old bogon filters. A dozen years is long enough that that kind of basic error sounds unlikely. But I'd be fascinated - if somewhat disturbed - to be proved wrong... Regards, Leo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From cscora at apnic.net Fri Aug 2 18:33:39 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Aug 2013 04:33:39 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201308021833.r72IXd2U023170@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 03 Aug, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 462161 Prefixes after maximum aggregation: 186936 Deaggregation factor: 2.47 Unique aggregates announced to Internet: 228387 Total ASes present in the Internet Routing Table: 44607 Prefixes per ASN: 10.36 Origin-only ASes present in the Internet Routing Table: 34905 Origin ASes announcing only one prefix: 16176 Transit ASes present in the Internet Routing Table: 5877 Transit-only ASes present in the Internet Routing Table: 159 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 29 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 3785 Unregistered ASNs in the Routing Table: 1451 Number of 32-bit ASNs allocated by the RIRs: 4919 Number of 32-bit ASNs visible in the Routing Table: 3825 Prefixes from 32-bit ASNs in the Routing Table: 11480 Special use prefixes present in the Routing Table: 29 Prefixes being announced from unallocated address space: 280 Number of addresses announced to Internet: 2631038412 Equivalent to 156 /8s, 210 /16s and 117 /24s Percentage of available address space announced: 71.1 Percentage of allocated address space announced: 71.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.8 Total number of prefixes smaller than registry allocations: 162245 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 111245 Total APNIC prefixes after maximum aggregation: 33944 APNIC Deaggregation factor: 3.28 Prefixes being announced from the APNIC address blocks: 113001 Unique aggregates announced from the APNIC address blocks: 46108 APNIC Region origin ASes present in the Internet Routing Table: 4859 APNIC Prefixes per ASN: 23.26 APNIC Region origin ASes announcing only one prefix: 1220 APNIC Region transit ASes present in the Internet Routing Table: 822 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table: 624 Number of APNIC addresses announced to Internet: 725607392 Equivalent to 43 /8s, 63 /16s and 227 /24s Percentage of available APNIC address space announced: 84.8 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: 159988 Total ARIN prefixes after maximum aggregation: 80604 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 160571 Unique aggregates announced from the ARIN address blocks: 74210 ARIN Region origin ASes present in the Internet Routing Table: 15784 ARIN Prefixes per ASN: 10.17 ARIN Region origin ASes announcing only one prefix: 5989 ARIN Region transit ASes present in the Internet Routing Table: 1648 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: 1067855936 Equivalent to 63 /8s, 166 /16s and 48 /24s Percentage of available ARIN address space announced: 56.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 118234 Total RIPE prefixes after maximum aggregation: 60308 RIPE Deaggregation factor: 1.96 Prefixes being announced from the RIPE address blocks: 122020 Unique aggregates announced from the RIPE address blocks: 78392 RIPE Region origin ASes present in the Internet Routing Table: 17320 RIPE Prefixes per ASN: 7.05 RIPE Region origin ASes announcing only one prefix: 8206 RIPE Region transit ASes present in the Internet Routing Table: 2823 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: 2383 Number of RIPE addresses announced to Internet: 656244132 Equivalent to 39 /8s, 29 /16s and 125 /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: 49579 Total LACNIC prefixes after maximum aggregation: 9506 LACNIC Deaggregation factor: 5.22 Prefixes being announced from the LACNIC address blocks: 54151 Unique aggregates announced from the LACNIC address blocks: 25483 LACNIC Region origin ASes present in the Internet Routing Table: 1990 LACNIC Prefixes per ASN: 27.21 LACNIC Region origin ASes announcing only one prefix: 574 LACNIC Region transit ASes present in the Internet Routing Table: 363 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: 793 Number of LACNIC addresses announced to Internet: 134428168 Equivalent to 8 /8s, 3 /16s and 54 /24s Percentage of available LACNIC address space announced: 80.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 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: 11548 Total AfriNIC prefixes after maximum aggregation: 2534 AfriNIC Deaggregation factor: 4.56 Prefixes being announced from the AfriNIC address blocks: 12138 Unique aggregates announced from the AfriNIC address blocks: 3934 AfriNIC Region origin ASes present in the Internet Routing Table: 643 AfriNIC Prefixes per ASN: 18.88 AfriNIC Region origin ASes announcing only one prefix: 187 AfriNIC Region transit ASes present in the Internet Routing Table: 129 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46568960 Equivalent to 2 /8s, 198 /16s and 150 /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 2918 11561 917 Korea Telecom (KIX) 17974 2651 871 92 PT TELEKOMUNIKASI INDONESIA 7545 2037 320 111 TPG Internet Pty Ltd 4755 1782 393 201 TATA Communications formerly 9829 1537 1221 45 BSNL National Internet Backbo 9583 1223 92 504 Sify Limited 9498 1176 309 71 BHARTI Airtel Ltd. 4808 1159 2133 336 CNCGROUP IP network: China169 7552 1131 1080 13 Vietel Corporation 24560 1087 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 2981 3689 63 bellsouth.net, inc. 18566 2065 382 184 Covad Communications 1785 2004 679 124 PaeTec Communications, Inc. 22773 2001 2927 123 Cox Communications, Inc. 20115 1671 1623 622 Charter Communications 4323 1618 1105 406 Time Warner Telecom 701 1517 11093 804 UUNET Technologies, Inc. 30036 1356 307 653 Mediacom Communications Corp 7018 1318 11037 830 AT&T WorldNet Services 11492 1221 218 363 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 1605 544 16 Corbina telecom 34984 1299 244 221 BILISIM TELEKOM 2118 1155 97 13 EUnet/RELCOM Autonomous Syste 31148 977 43 19 FreeNet ISP 20940 958 336 743 Akamai Technologies European 6830 848 2371 431 UPC Distribution Services 13188 840 98 78 Educational Network 8551 780 370 45 Bezeq International 12479 678 796 52 Uni2 Autonomous System 9198 595 343 21 Kazakhtelecom Data Network Ad 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 2973 1591 110 NET Servicos de Comunicao S.A 10620 2652 421 228 TVCABLE BOGOTA 7303 1728 1156 220 Telecom Argentina Stet-France 8151 1276 2756 386 UniNet S.A. de C.V. 18881 1271 844 20 Global Village Telecom 27947 836 94 90 Telconet S.A 6503 819 434 63 AVANTEL, S.A. 11830 749 364 15 Instituto Costarricense de El 3816 722 302 83 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 1860 112 5 MOBITEL 24863 875 274 30 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 435 956 9 TEDATA 24835 279 80 8 RAYA Telecom - Egypt 3741 258 921 217 The Internet Solution 15706 221 32 6 Sudatel Internet Exchange Aut 29571 220 17 12 Ci Telecom Autonomous system 36992 209 527 22 Etisalat MISR 12258 193 28 71 Vodacom Internet Company 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 2981 3689 63 bellsouth.net, inc. 28573 2973 1591 110 NET Servicos de Comunicao S.A 4766 2918 11561 917 Korea Telecom (KIX) 10620 2652 421 228 TVCABLE BOGOTA 17974 2651 871 92 PT TELEKOMUNIKASI INDONESIA 18566 2065 382 184 Covad Communications 7545 2037 320 111 TPG Internet Pty Ltd 1785 2004 679 124 PaeTec Communications, Inc. 22773 2001 2927 123 Cox Communications, Inc. 36998 1860 112 5 MOBITEL 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 2973 2863 NET Servicos de Comunicao S.A 17974 2651 2559 PT TELEKOMUNIKASI INDONESIA 10620 2652 2424 TVCABLE BOGOTA 4766 2918 2001 Korea Telecom (KIX) 7545 2037 1926 TPG Internet Pty Ltd 18566 2065 1881 Covad Communications 1785 2004 1880 PaeTec Communications, Inc. 22773 2001 1878 Cox Communications, Inc. 36998 1860 1855 MOBITEL 8402 1605 1589 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 30621 UNALLOCATED 12.151.74.0/23 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 2541 >>UNKNOWN<< 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.40.0/24 60449 >>UNKNOWN<< 128.0.42.0/24 60619 >>UNKNOWN<< 128.0.43.0/24 60619 >>UNKNOWN<< 128.0.45.0/24 60657 >>UNKNOWN<< 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 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 62.182.96.0/23 15830 TELECITY London 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:11 /10:30 /11:92 /12:249 /13:479 /14:905 /15:1601 /16:12738 /17:6640 /18:11090 /19:22524 /20:32191 /21:34694 /22:48720 /23:42665 /24:243597 /25:1285 /26:1642 /27:839 /28:44 /29:74 /30:17 /31:0 /32:18 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2016 2065 Covad Communications 36998 1825 1860 MOBITEL 6389 1715 2981 bellsouth.net, inc. 8402 1304 1605 Corbina telecom 22773 1303 2001 Cox Communications, Inc. 30036 1218 1356 Mediacom Communications Corp 11492 1182 1221 Cable One 1785 1078 2004 PaeTec Communications, Inc. 6983 1020 1147 ITC^Deltacom 10620 987 2652 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:829 2:695 3:3 4:19 5:909 6:17 8:580 12:1923 13:2 14:870 15:11 16:3 17:10 20:17 23:297 24:1770 27:1527 31:1354 32:45 33:2 34:5 36:71 37:1845 38:892 39:2 40:175 41:3280 42:249 44:8 46:1957 47:2 49:650 50:830 52:12 54:37 55:7 57:26 58:1164 59:614 60:332 61:1500 62:1177 63:2008 64:4348 65:2148 66:4190 67:2023 68:1093 69:3290 70:799 71:490 72:1914 74:2505 75:324 76:305 77:1123 78:1034 79:610 80:1288 81:1013 82:630 83:584 84:578 85:1235 86:466 87:1021 88:533 89:1804 90:154 91:5522 92:633 93:1685 94:1923 95:1629 96:592 97:344 98:1028 99:44 100:29 101:592 103:3079 105:523 106:139 107:208 108:520 109:1824 110:946 111:1073 112:564 113:816 114:701 115:1100 116:957 117:804 118:1144 119:1284 120:362 121:852 122:1803 123:1239 124:1370 125:1395 128:635 129:218 130:310 131:669 132:361 133:160 134:270 135:72 136:257 137:245 138:344 139:189 140:201 141:320 142:532 143:392 144:512 145:92 146:527 147:422 148:663 149:351 150:154 151:585 152:414 153:190 154:29 155:420 156:275 157:402 158:276 159:742 160:349 161:455 162:514 163:223 164:582 165:514 166:254 167:598 168:1026 169:126 170:1062 171:186 172:23 173:1576 174:556 175:501 176:1168 177:2121 178:1888 179:72 180:1507 181:595 182:1293 183:420 184:674 185:703 186:2317 187:1380 188:1888 189:1329 190:6827 192:6812 193:5625 194:4708 195:3587 196:1322 197:990 198:4565 199:5372 200:6002 201:2443 202:8787 203:8876 204:4512 205:2595 206:2826 207:2895 208:4002 209:3596 210:2937 211:1530 212:2240 213:2014 214:912 215:99 216:5252 217:1636 218:617 219:332 220:1274 221:551 222:318 223:462 End of report From marcelplug at gmail.com Fri Aug 2 19:09:57 2013 From: marcelplug at gmail.com (Marcel Plug) Date: Fri, 2 Aug 2013 15:09:57 -0400 Subject: IP allocations / bogon - verification In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B184E131A9BA@EXVPMBX100-1.exc.icann.org> References: <5648A8908CCB564EBF46E2BC904A75B184E131A9BA@EXVPMBX100-1.exc.icann.org> Message-ID: On Fri, Aug 2, 2013 at 2:28 PM, Leo Vegoda wrote: > > > But I'd be fascinated - if somewhat disturbed - to be proved wrong... > Team Cymru seems to think it was a Bogon, as recently as yesterday. http://www.cymru.com/BGP/bogons.html (search for 66.185.0.0/20, last seen Aug 1st) Probably the networks of the "financial related websites" were blocking due to the Cymru Bogons list. > > Regards, > > Leo > > -Marcel From leo.vegoda at icann.org Fri Aug 2 19:22:07 2013 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 2 Aug 2013 12:22:07 -0700 Subject: IP allocations / bogon - verification In-Reply-To: References: <5648A8908CCB564EBF46E2BC904A75B184E131A9BA@EXVPMBX100-1.exc.icann.org> Message-ID: On 2 Aug 2013, at 12:09, Marcel Plug wrote: > > On Fri, Aug 2, 2013 at 2:28 PM, Leo Vegoda wrote: > > But I'd be fascinated - if somewhat disturbed - to be proved wrong... > > Team Cymru seems to think it was a Bogon, as recently as yesterday. > http://www.cymru.com/BGP/bogons.html (search for 66.185.0.0/20, last seen Aug 1st) > > Probably the networks of the "financial related websites" were blocking due to the Cymru Bogons list. It is possible that it ended up on TC's Bogons list because the prefix was listed as reserved by ARIN in: ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20130730 ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20130731 ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20130801 ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20130802 I have not checked back further than 30 July. It definitely shows as allocated here in whois, so I'm confused by the mismatch. Regards, Leo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4359 bytes Desc: not available URL: From jstuppi at cisco.com Fri Aug 2 19:34:52 2013 From: jstuppi at cisco.com (John Stuppi (jstuppi)) Date: Fri, 2 Aug 2013 19:34:52 +0000 Subject: OSPF Vulnerability - Owning the Routing Table In-Reply-To: <51FBE54A.9010607@forthnetgroup.gr> References: <51FBE54A.9010607@forthnetgroup.gr> Message-ID: <3FA32E339980EB4BBB4935C00A6A8F291E35F1CD@xmb-aln-x09.cisco.com> Yes, these advisories (from both Cisco and Juniper), covering CVE-2013-0149, are both related to the announcement yesterday (1-Aug) at BlackHat regarding the OSPF LSA Manipulation vulnerability. Thanks, John ?Optimism is the faith that leads to achievement. Nothing can be done without hope and confidence?. John Stuppi, CISSP Technical Leader Strategic Security Research jstuppi at cisco.com Phone: +1 732 516 5994 Mobile: 732 319 3886 CCIE, Security - 11154 Cisco Systems Mail Stop INJ01/2/ 111 Wood Avenue South Iselin, New Jersey 08830 United States Cisco.com Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -----Original Message----- From: Tassos Chatzithomaoglou [mailto:achatz at forthnetgroup.gr] Sent: Friday, August 02, 2013 12:59 PM To: Glen Kent; nanog at nanog.org Subject: Re: OSPF Vulnerability - Owning the Routing Table These were published recently: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130801-lsaospf http://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2013-08-987&actionBtn=Search -- Tassos Glen Kent wrote on 02/08/2013 19:40: > Hi, > > Does anybody have details on what this vulnerability is? > > https://www.blackhat.com/us-13/briefings.html#Nakibly > > Glen > From rmckrill at fidelityvoice.com Fri Aug 2 19:48:37 2013 From: rmckrill at fidelityvoice.com (Rob McKrill) Date: Fri, 2 Aug 2013 15:48:37 -0400 Subject: Technical contact at Verizon Wireles Message-ID: <4507632539221486544@unknownmsgid> Was hoping to find someone out there that might have a contact within Verizon Wireless that could assist in a resolving a voice quality (static) issue on calls outbound from VZW, inbound to L3/GBLX in the Cleveland, Ohio market. Anyone able to contact me off-list with some info or recommendations on resolution? The trouble has been isolated to be outside of L3/GLBX's network and obviously AT&T is unwilling to research the problem further. Thanks in advance! Best Regards, --- Rob McKrill Voice Engineering Fidelity Voice and Data From ras at e-gerbil.net Fri Aug 2 19:56:22 2013 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 2 Aug 2013 14:56:22 -0500 Subject: nLayer IP transit In-Reply-To: <50D67364-EAB7-40E8-A3F1-E34B24007741@gmail.com> References: <20130801173053.GV67768@gerbil.cluepon.net> <50D67364-EAB7-40E8-A3F1-E34B24007741@gmail.com> Message-ID: <20130802195622.GJ67768@gerbil.cluepon.net> On Fri, Aug 02, 2013 at 07:11:34AM +1000, Mark Tees wrote: > Thanks for the replies. > > I think I saw somewhere around the Cloudflare outage post someone > mentioning that since the person at Juniper that was responsible for > Flowspec left it all went down hill. > > I take it then Flowspec is still used internally then? I am still > wondering if its best to avoid Flowspec and roll your own firewall > rules applied via Netconf for transit interfaces to achieve the same > sort of functionality. It's a lot less likely to go south if you control the routes that go into the system. That said, it still breaks some things just by having it enabled (like NSR, though I suppose one could argue that NSR breaks itself :P), so you might be better served with a netconf distribution of rules if you want to avoid those potential issues. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From wilhelm at ripe.net Fri Aug 2 20:04:01 2013 From: wilhelm at ripe.net (Rene Wilhelm) Date: Fri, 02 Aug 2013 22:04:01 +0200 Subject: IP allocations / bogon - verification In-Reply-To: References: <5648A8908CCB564EBF46E2BC904A75B184E131A9BA@EXVPMBX100-1.exc.icann.org> Message-ID: <51FC10B1.4090701@ripe.net> On 8/2/13 9:22 PM, Leo Vegoda wrote: > On 2 Aug 2013, at 12:09, Marcel Plug wrote: > >> On Fri, Aug 2, 2013 at 2:28 PM, Leo Vegoda wrote: >> >> But I'd be fascinated - if somewhat disturbed - to be proved wrong... >> >> Team Cymru seems to think it was a Bogon, as recently as yesterday. >> http://www.cymru.com/BGP/bogons.html (search for 66.185.0.0/20, last seen Aug 1st) >> >> Probably the networks of the "financial related websites" were blocking due to the Cymru Bogons list. > It is possible that it ended up on TC's Bogons list because the prefix was listed as reserved by ARIN in: > > ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20130730 > ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20130731 > ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20130801 > ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20130802 > > I have not checked back further than 30 July. RIPEstat shows the prefix was "withdrawn" from ARIN delegated stats on the 8 of July https://stat.ripe.net/widget/allocation-history#w.resource=66.185.0.0%2F20 It came reappeared as 'allocated' yesterday, 2013-08-01 > > It definitely shows as allocated here in whois, so I'm confused by the mismatch. there is a mismatch between the normal and extended ARIN stats: $ cd ftp/pub/stats/arin $ grep 66.185.0.0 delegated-arin-*20130802 delegated-arin-20130802:arin|US|ipv4|66.185.0.0|4096|20011026|allocated delegated-arin-extended-20130802:arin||ipv4|66.185.0.0|4096||reserved| -- Rene > > Regards, > > Leo From cidr-report at potaroo.net Fri Aug 2 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Aug 2013 22:00:01 GMT Subject: The Cidr Report Message-ID: <201308022200.r72M01A8003365@wattle.apnic.net> This report has been generated at Fri Aug 2 21:13:42 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-07-13 471541 267325 27-07-13 471990 267277 28-07-13 471547 267401 29-07-13 471316 267436 30-07-13 471834 267867 31-07-13 472195 268182 01-08-13 472870 268231 02-08-13 473248 268443 AS Summary 44760 Number of ASes in routing system 18454 Number of ASes announcing only one prefix 4230 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 117330144 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'). --- 02Aug13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 473519 268341 205178 43.3% All ASes AS6389 2981 66 2915 97.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2982 455 2527 84.7% NET Servi?os de Comunica??o S.A. AS17974 2650 422 2228 84.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 4230 2103 2127 50.3% WINDSTREAM - Windstream Communications Inc AS4766 2918 932 1986 68.1% KIXS-AS-KR Korea Telecom AS22773 2001 239 1762 88.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2065 468 1597 77.3% COVAD - Covad Communications Co. AS10620 2652 1063 1589 59.9% Telmex Colombia S.A. AS36998 1860 391 1469 79.0% SDN-MOBITEL AS4323 2983 1533 1450 48.6% TWTC - tw telecom holdings, inc. AS7545 2050 772 1278 62.3% TPG-INTERNET-AP TPG Telecom Limited AS7303 1728 453 1275 73.8% Telecom Argentina S.A. AS18881 1272 43 1229 96.6% Global Village Telecom AS4755 1777 589 1188 66.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1155 51 1104 95.6% RELCOM-AS OOO "NPO Relcom" AS7552 1153 156 997 86.5% VIETEL-AS-AP Vietel Corporation AS22561 1208 227 981 81.2% DIGITAL-TELEPORT - Digital Teleport Inc. AS1785 2004 1156 848 42.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS18101 987 177 810 82.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1159 393 766 66.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1520 810 710 46.7% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS13977 846 139 707 83.6% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS8151 1278 577 701 54.9% Uninet S.A. de C.V. AS855 735 55 680 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS33363 1729 1053 676 39.1% BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC AS6983 1147 480 667 58.2% ITCDELTA - ITC^Deltacom AS24560 1087 428 659 60.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS11830 750 101 649 86.5% Instituto Costarricense de Electricidad y Telecom. AS31148 977 340 637 65.2% FREENET-AS Freenet Ltd. AS17676 753 127 626 83.1% GIGAINFRA Softbank BB Corp. Total 52637 15799 36838 70.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- 10.255.255.12/30 AS65530 -Private Use AS- 10.255.255.252/30 AS64512 -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 62.182.96.0/23 AS15830 TELECITY-LON TELECITYGROUP INTERNATIONAL LIMITED 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. 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 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.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 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 80.68.144.0/20 AS33982 82.103.0.0/18 AS30901 91.197.36.0/22 AS43359 91.205.188.0/22 AS47983 91.207.200.0/23 AS48523 91.209.93.0/24 AS48523 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 96.45.48.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.49.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.50.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.51.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.52.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.53.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.54.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.55.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.56.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.57.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.58.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.59.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.60.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.61.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.62.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.63.0/24 AS33475 RSN-1 - RockSolid Network, 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.224.163.0/24 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 103.224.188.0/23 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) 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.111.111.0/24 AS8039 CCC-ASN-1 - Cinergy Communications 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 173.45.192.0/19 AS6461 MFNX MFN - Metromedia Fiber Network 174.138.144.0/20 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 185.32.80.0/22 AS42442 ADACOR-AS Adacor Hosting GmbH 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 193.33.112.0/23 AS8586 OBSL-AS TalkTalk Communications Limited 193.111.125.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.111.155.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 194.79.48.0/22 AS39117 194.117.250.0/23 AS41412 MIVITEC-AS MIVITEC GmbH 194.169.237.0/24 AS12968 CDP Netia SA 195.238.120.0/22 AS33837 PRQ-AS PeRiQuito AB 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 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.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 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 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 204.16.25.0/24 AS18434 METAVANTE - Metavante Corporation 204.16.28.0/24 AS1239 AS1239 SprintLink Global Network 204.124.87.0/24 AS11339 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.54.144.0/21 AS19613 206.54.154.0/24 AS18434 METAVANTE - Metavante Corporation 206.54.155.0/24 AS46672 COLO5 - Colo5, LLC 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.68.244.0/22 AS17140 208.68.244.0/23 AS17140 208.68.246.0/23 AS17140 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 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.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 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.90.64.0/22 AS16415 PRCNET-DOM - Precision Response Corporation 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.160.81.0/24 AS36184 209.160.83.0/24 AS36184 209.160.84.0/24 AS36184 209.160.86.0/24 AS36184 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.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.151.192.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.151.200.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 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 Aug 2 22:00:02 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Aug 2013 22:00:02 GMT Subject: BGP Update Report Message-ID: <201308022200.r72M02ur003379@wattle.apnic.net> BGP Update Report Interval: 25-Jul-13 -to- 01-Aug-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS50710 52971 2.8% 221.6 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services 2 - AS9829 41660 2.2% 30.6 -- BSNL-NIB National Internet Backbone 3 - AS18403 35215 1.8% 55.4 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 4 - AS8402 32299 1.7% 27.0 -- CORBINA-AS OJSC "Vimpelcom" 5 - AS7552 27697 1.4% 23.1 -- VIETEL-AS-AP Vietel Corporation 6 - AS35819 20990 1.1% 48.7 -- MOBILY-AS Etihad Etisalat Company (Mobily) 7 - AS27738 18304 0.9% 31.8 -- Ecuadortelecom S.A. 8 - AS36998 17772 0.9% 10.1 -- SDN-MOBITEL 9 - AS9416 17527 0.9% 1752.7 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 10 - AS4775 17024 0.9% 207.6 -- GLOBE-TELECOM-AS Globe Telecoms 11 - AS10428 16298 0.8% 2328.3 -- CWV-NETWORKS - The College of West Virginia 12 - AS14287 12987 0.7% 2164.5 -- TRIAD-TELECOM - Triad Telecom, Inc. 13 - AS17974 12888 0.7% 4.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 14 - AS18025 12563 0.7% 228.4 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 15 - AS28573 12522 0.7% 12.3 -- NET Servi?os de Comunica??o S.A. 16 - AS34969 11944 0.6% 1493.0 -- PASJONET-AS Pasjo.Net Sp, z o.o. 17 - AS52280 11560 0.6% 2890.0 -- INTERNEXA Chile S.A. 18 - AS5800 11249 0.6% 48.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - AS2118 10085 0.5% 8.2 -- RELCOM-AS OOO "NPO Relcom" 20 - AS48612 9649 0.5% 1608.2 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS19406 4553 0.2% 4553.0 -- TWRS-MA - Towerstream I, Inc. 2 - AS6174 7017 0.4% 3508.5 -- SPRINTLINK8 - Sprint 3 - AS52280 11560 0.6% 2890.0 -- INTERNEXA Chile S.A. 4 - AS10428 16298 0.8% 2328.3 -- CWV-NETWORKS - The College of West Virginia 5 - AS14287 12987 0.7% 2164.5 -- TRIAD-TELECOM - Triad Telecom, Inc. 6 - AS6629 9370 0.5% 1874.0 -- NOAA-AS - NOAA 7 - AS19111 1811 0.1% 1811.0 -- NATURES-BOUN - NBTY, Inc. 8 - AS9416 17527 0.9% 1752.7 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 9 - AS37367 1680 0.1% 1680.0 -- CALLKEY 10 - AS36976 1613 0.1% 1613.0 -- SONANGOL 11 - AS48612 9649 0.5% 1608.2 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 12 - AS34969 11944 0.6% 1493.0 -- PASJONET-AS Pasjo.Net Sp, z o.o. 13 - AS1880 4901 0.3% 1225.2 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 14 - AS3 1191 0.1% 1508.0 -- CMED-AS Cmed Technology Ltd 15 - AS56552 958 0.1% 958.0 -- TEHRANAIR Tehran Airlines 16 - AS38654 4230 0.2% 846.0 -- INES-NETWORK INES Corporation. 17 - AS8382 845 0.0% 845.0 -- IRTEL-AS OJSC Rostelecom 18 - AS6187 1683 0.1% 841.5 -- SPRINT-ZA 19 - AS48068 784 0.0% 784.0 -- VISONIC Visonic Ltd 20 - AS22688 765 0.0% 765.0 -- DOLGENCORP - Dollar General Corporation TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 190.211.175.0/24 11539 0.6% AS52280 -- INTERNEXA Chile S.A. 2 - 92.246.207.0/24 9493 0.5% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 3 - 192.58.232.0/24 9334 0.5% AS6629 -- NOAA-AS - NOAA 4 - 203.118.232.0/21 8841 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 5 - 203.118.224.0/21 8659 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 6 - 120.28.62.0/24 8000 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 7 - 222.127.0.0/24 7974 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 8 - 65.90.49.0/24 6798 0.3% AS3356 -- LEVEL3 Level 3 Communications 9 - 115.170.128.0/17 6471 0.3% AS4847 -- CNIX-AP China Networks Inter-Exchange 10 - 12.43.218.0/24 5402 0.3% AS10428 -- CWV-NETWORKS - The College of West Virginia 11 - 199.248.240.0/24 5400 0.3% AS10428 -- CWV-NETWORKS - The College of West Virginia 12 - 205.166.165.0/24 5400 0.3% AS10428 -- CWV-NETWORKS - The College of West Virginia 13 - 204.29.132.0/23 4887 0.2% AS1880 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 14 - 69.38.178.0/24 4553 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 15 - 150.39.0.0/16 4212 0.2% AS38654 -- INES-NETWORK INES Corporation. 16 - 64.187.64.0/23 3601 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. 17 - 208.16.110.0/24 3509 0.2% AS6174 -- SPRINTLINK8 - Sprint 18 - 206.105.75.0/24 3508 0.2% AS6174 -- SPRINTLINK8 - Sprint 19 - 62.84.76.0/24 3366 0.2% AS42334 -- BBP-AS Broadband Plus s.a.l. 20 - 112.203.192.0/19 3345 0.2% AS9299 -- IPG-AS-AP Philippine Long Distance Telephone Company 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 marka at isc.org Sat Aug 3 00:39:24 2013 From: marka at isc.org (Mark Andrews) Date: Sat, 03 Aug 2013 10:39:24 +1000 Subject: ddos attacks In-Reply-To: Your message of "Fri, 02 Aug 2013 10:55:17 -0400." <1C2F65D3-1E71-4C08-9A05-BA6536FDBF40@puck.nether.net> References: <1C2F65D3-1E71-4C08-9A05-BA6536FDBF40@puck.nether.net> Message-ID: <20130803003924.3E4BC37FB9F7@drugs.dv.isc.org> In message <1C2F65D3-1E71-4C08-9A05-BA6536FDBF40 at puck.nether.net>, Jared Mauch writes: > > On Aug 2, 2013, at 10:38 AM, "Patrick W. Gilmore" > wrote: > > > On Aug 02, 2013, at 09:37 , sgraun at airstreamcomm.net wrote: > > > >> I'm curious to know what other service providers are doing to > >> alleviate/prevent ddos attacks from happening in your network. Are you > >> completely reactive and block as many addresses as possible or null0 > >> traffic to the effected host until it stops or do you block certain ports > >> to prevent them. What's the best way people are dealing with them? > > > > #1: Ensure your network is BCP38 compliant. > > > > Hard to complain about others attacking you when you are not clear. And > > if you do not block source-address spoofing, you are not clean. > > > > As for the rest, I'll let others with more recent experience explain > > what they do. > > We have had challenges with deploying BCP38, even on simple connections. > We have outstanding defects in IOS-XR that prevent us from deploying it. > > Wherever possible we have enabled source address validation (bcp38). I > do have a map of some networks that don't do this as a result of the > OpenResolverProject.org data. > > Here's some top ASNs that can send spoofed packets: > > Count ASN > --------------- > 1006 18747 > 1004 262824 > 877 196753 > 522 29119 > 516 5617 > 514 34977 > 513 47570 > 513 12615 > 512 262336 > 512 12301 > 372 6739 > > > These ASNs spoof my machine I use to send queries out to 8.8.8.8 and > goole responds back to me. > > Likely some firewall/CPE/NAT that does this, but the provider lets those > spoofed packets reach outside their network to google. > > I have many more of these if folks want to see a broader list. > > If you look at the ASN relationships involved here, it means either 3491 > or 3257 allows these spoofed packets from 18747. > > - Jared Please publish the full list. It is long past the time when operators should be filtering out spoofed source address traffic. This sort of data should be refreshed and published quarterly. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From excelsio at gmx.com Sat Aug 3 08:20:56 2013 From: excelsio at gmx.com (excelsio at gmx.com) Date: Sat, 03 Aug 2013 10:20:56 +0200 Subject: OSPF Vulnerability - Owning the Routing Table In-Reply-To: <3FA32E339980EB4BBB4935C00A6A8F291E35F1CD@xmb-aln-x09.cisco.com> References: <51FBE54A.9010607@forthnetgroup.gr> <3FA32E339980EB4BBB4935C00A6A8F291E35F1CD@xmb-aln-x09.cisco.com> Message-ID: <51FCBD68.1090601@gmx.com> So, only Cisco and Juniper are hit by this one? What about "the rest"? Michael Am 02.08.2013 21:34, schrieb John Stuppi (jstuppi): > Yes, these advisories (from both Cisco and Juniper), covering CVE-2013-0149, are both related to the announcement yesterday (1-Aug) at BlackHat regarding the OSPF LSA Manipulation vulnerability. > > Thanks, > John > > ?Optimism is the faith that leads to achievement. Nothing can be done without hope and confidence?. > > > > > > John Stuppi, CISSP > Technical Leader > Strategic Security Research > jstuppi at cisco.com > Phone: +1 732 516 5994 > Mobile: 732 319 3886 > > CCIE, Security - 11154 > Cisco Systems > Mail Stop INJ01/2/ > 111 Wood Avenue South > Iselin, New Jersey 08830 > United States > Cisco.com > From jeff.tantsura at ericsson.com Sat Aug 3 21:09:13 2013 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Sat, 3 Aug 2013 21:09:13 +0000 Subject: OSPF Vulnerability - Owning the Routing Table In-Reply-To: <51FCBD68.1090601@gmx.com> References: <51FBE54A.9010607@forthnetgroup.gr> <3FA32E339980EB4BBB4935C00A6A8F291E35F1CD@xmb-aln-x09.cisco.com>, <51FCBD68.1090601@gmx.com> Message-ID: Hi, As for Ericsson (Redback) products. We found the issue quite some time ago and fixed it immediately. Smart Edge code base (SEOS) has been fixed back to the release 6.3 SSR code base (IPOS) - not affected. Please let me know if you have got any questions. Regards, Jeff On Aug 3, 2013, at 10:25, "excelsio at gmx.com" wrote: > So, only Cisco and Juniper are hit by this one? What about "the rest"? > Michael > > > Am 02.08.2013 21:34, schrieb John Stuppi (jstuppi): >> Yes, these advisories (from both Cisco and Juniper), covering CVE-2013-0149, are both related to the announcement yesterday (1-Aug) at BlackHat regarding the OSPF LSA Manipulation vulnerability. >> >> Thanks, >> John >> >> ?Optimism is the faith that leads to achievement. Nothing can be done without hope and confidence?. >> >> >> >> >> >> John Stuppi, CISSP >> Technical Leader >> Strategic Security Research >> jstuppi at cisco.com >> Phone: +1 732 516 5994 >> Mobile: 732 319 3886 >> >> CCIE, Security - 11154 >> Cisco Systems >> Mail Stop INJ01/2/ >> 111 Wood Avenue South >> Iselin, New Jersey 08830 >> United States >> Cisco.com > > From mysidia at gmail.com Sat Aug 3 23:38:39 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 3 Aug 2013 18:38:39 -0500 Subject: OSPF Vulnerability - Owning the Routing Table In-Reply-To: References: Message-ID: On 8/2/13, Aled Morris wrote: > Cisco published an advisory on OSPF vulnerability yesterday I think. I > assume it's related. OSPF is a dynamic routing protocol. It automatically discovers neighbors on a multi-access segment claiming to be routers. In what way could it possibly be unexpected that an attacker can pose as a router and inject false routes; if an attacker able to emit multicast to OSPF multicast address onto a LAN speaking OSPF? That's not news to me, but fully expected. Do the vendors /really/ have a code fix to what would seem to be an inherent problem; if you failed to properly secure your OSPF implementation (via MD5 authentication)? > OSPFv3 is not vulnerable, and connections protected by MD5 are safe too, > apparently. > > Aled -- -JH From frnkblk at iname.com Sun Aug 4 03:14:37 2013 From: frnkblk at iname.com (Frank Bulk (iname.com)) Date: Sat, 3 Aug 2013 22:14:37 -0500 Subject: IP allocations / bogon - verification In-Reply-To: References: Message-ID: <004f01ce90c0$c0f75bc0$42e61340$@iname.com> It's listed as being on a BOGON at HE, too: http://bgp.he.net/net/66.185.0.0/20 Not sure who HE uses to make that designation. Frank -----Original Message----- From: Kenny Kant [mailto:akennykant at gmail.com] Sent: Friday, August 02, 2013 12:07 AM To: nanog at nanog.org Subject: IP allocations / bogon - verification Gang, I apologize for a double post on this same topic tonight however I thought that broadening my request may help our cause. This month we had one of our IP allocations revoked and just recently got everything squared away with ARIN and things are "turned back" on so to speak. However I still have some customers having issues hitting a number of financial related websites ..etc and I assume its because of bogons ..etc I saw some earlier posts on here where folks have posted their allocation to ensure that others are routing it properly so I wanted to do the same. My allocation which has recently been revived: 66.185.0.0/20 Test point traceroute .etc 66.185.0.198 We do seem to be having some issues with some level 3 routing our range to some desitnations and can provide specifics off list. Thanks all for the help / verification. Kenny From rmosher at he.net Sun Aug 4 04:06:13 2013 From: rmosher at he.net (Rob Mosher) Date: Sun, 04 Aug 2013 00:06:13 -0400 Subject: IP allocations / bogon - ARIN Inconsistency In-Reply-To: <004f01ce90c0$c0f75bc0$42e61340$@iname.com> References: <004f01ce90c0$c0f75bc0$42e61340$@iname.com> Message-ID: <51FDD335.5000101@he.net> Frank, HE uses the extended files for these stats since the standard ones will soon be deprecated. As Rene pointed out, the extended and standard delegation files from ARIN do not match for this prefix. I do not know why there is inconsistent data between the two, but this is something that ARIN should look into. It appears the extended file is not being updated properly, though whois output clearly shows this was updated recently. NetRange: 66.185.0.0 - 66.185.15.255 CIDR: 66.185.0.0/20 OriginAS: AS36219 NetName: PAIRIEINET-SPARKPLUG NetHandle: NET-66-185-0-0-1 Parent: NET-66-0-0-0-0 NetType: Direct Allocation RegDate: 2001-10-26 Updated: 2013-07-31 -- Rob Mosher Senior Network and Software Engineer Hurricane Electric / AS6939 On 8/3/2013 11:14 PM, Frank Bulk (iname.com) wrote: > It's listed as being on a BOGON at HE, too: > http://bgp.he.net/net/66.185.0.0/20 > Not sure who HE uses to make that designation. On 8/2/2013 4:04 PM, Rene Wilhelm wrote: > there is a mismatch between the normal and extended ARIN stats: > > $ cd ftp/pub/stats/arin > $ grep 66.185.0.0 delegated-arin-*20130802 > delegated-arin-20130802:arin|US|ipv4|66.185.0.0|4096|20011026|allocated > delegated-arin-extended-20130802:arin||ipv4|66.185.0.0|4096||reserved| From gih at apnic.net Sun Aug 4 04:50:13 2013 From: gih at apnic.net (Geoff Huston) Date: Sun, 4 Aug 2013 14:50:13 +1000 Subject: IP allocations / bogon - ARIN Inconsistency In-Reply-To: <51FDD335.5000101@he.net> References: <004f01ce90c0$c0f75bc0$42e61340$@iname.com> <51FDD335.5000101@he.net> Message-ID: On 04/08/2013, at 2:06 PM, Rob Mosher wrote: > Frank, > > HE uses the extended files for these stats since the standard ones will soon be deprecated. As Rene pointed out, the extended and standard delegation files from ARIN do not match for this prefix. I do not know why there is inconsistent data between the two, but this is something that ARIN should look into. I have been lead to understand that, for ARIN, the extended stats file reflects the registry state at a slightly different time (earlier by ~1 day) than the "standard" stats file. This is a likely explanation of the observed inconsistency. Geoff From me at anuragbhatia.com Sun Aug 4 05:15:57 2013 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sun, 4 Aug 2013 10:45:57 +0530 Subject: Strange entries from AS1 in global table Message-ID: Hello everyone I was looking at global IPv4 table and saw some strange entries from AS1. As per ARIN whois AS1 seems to be with Level3 but I noticed few prefixes of Brazil based ISP - Netvip http://bgp.he.net/AS1#_prefixes Looking at any prefix in detail, it seems like there are multiple ASNs announcing same prefix. E.g 177.185.96.0/24 - is being announced by AS1 as well as AS52931 (Netvip's allocated ASN). Same is true with 177.185.98.0/24, 177.185.98.0/24and so on. http://bgp.he.net/net/177.185.96.0/24 So seems like AS1 acting like a mirror for all announcements of AS52931. To see who exactly gave "transit" to AS1 by Netvip in Brazil, I checked Oregon and noticed these routes: 3356 3549 16735 52931 1 i Seems like AS52931 itself is acting as transit for AS1 (and AS16735 which seems like a backbone ISP in Brazil) is not filtering these routes further passing to Level3 (AS3549+AS3356). I am curious to know what could be possible reason for an ASN like AS1 acting in exact mirror of AS52931? Could it be a case of internal use of AS1 (assuming it to be private ASN)? May be it's a case of leaked internal routes? Appreciate your time & answer. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com From saku at ytti.fi Sun Aug 4 08:17:03 2013 From: saku at ytti.fi (Saku Ytti) Date: Sun, 4 Aug 2013 11:17:03 +0300 Subject: OSPF Vulnerability - Owning the Routing Table In-Reply-To: References: Message-ID: <20130804081703.GA4037@pob.ytti.fi> On (2013-08-03 18:38 -0500), Jimmy Hess wrote: > That's not news to me, but fully expected. > Do the vendors /really/ have a code fix to what would seem to be an > inherent problem; if you failed to properly secure your OSPF > implementation (via MD5 authentication)? It is news to me. It's design flaw in the protocol itself which has gone unnoticed for two decades and I would have naively fully expected that this flaw does not exist in standard. As I've understood issue lies in the fact that 'link state id' and 'advertising router' should always be the same (so it's redundant information in the LSA, single field should suffice?). But standard does not enforce this at all. Victim will omit doing corrective reflood for received bogus LSA if 'advertising router' is something else than 'router-id', even while 'link state id' == 'router-id' I suppose vendors implement fix where either a) corrective reflood occur if 'link state id' == 'router-id' or b) LSA is rejected unless 'link state id' == 'advertising router' How serious or new this is, may be debatable, as only thing it seems remove, is the need for attacker to inject 0.2pps worth of packets which will suppress the corrective reflooding. -- ++ytti From mysidia at gmail.com Sun Aug 4 10:01:00 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 4 Aug 2013 05:01:00 -0500 Subject: OSPF Vulnerability - Owning the Routing Table In-Reply-To: <20130804081703.GA4037@pob.ytti.fi> References: <20130804081703.GA4037@pob.ytti.fi> Message-ID: On 8/4/13, Saku Ytti wrote: > On (2013-08-03 18:38 -0500), Jimmy Hess wrote: > >> That's not news to me, but fully expected. >> Do the vendors /really/ have a code fix to what would seem to be an >> inherent problem; if you failed to properly secure your OSPF >> implementation (via MD5 authentication)? > It is news to me. It's design flaw in the protocol itself which has gone > unnoticed for two decades and I would have naively fully expected that this > flaw does not exist in standard. I would say the risk score of the advisory is overstated. And if you think "ospf is secure" against LAN activity after any patch, that would be wishful thinking. Someone just rediscovered one of the countless innumerable holes in the back of the cardboard box and tried covering it with duck tape... What is the rationale for overlooking or ignoring the possibility that an attacker can introduce a device with /faithful/ correct implementation of the protocol with bad/malicious data intentionally advertised by the "Rogue speaker" ? This could be as simple as inserting a real router (which can be just a piece of software) on a broadcast LAN with a proper OSPF implementation but malicious configuration -- in that routes configured for advertisement are bogus ones, or a router ID is intentionally chosen to conflict with the router ID of another device. In addition, the rogue router, can be configured such that it forces an election and becomes the DR. Just a few examples -- -JH From saku at ytti.fi Sun Aug 4 10:12:00 2013 From: saku at ytti.fi (Saku Ytti) Date: Sun, 4 Aug 2013 13:12:00 +0300 Subject: OSPF Vulnerability - Owning the Routing Table In-Reply-To: References: <20130804081703.GA4037@pob.ytti.fi> Message-ID: <20130804101200.GA6780@pob.ytti.fi> On (2013-08-04 05:01 -0500), Jimmy Hess wrote: > I would say the risk score of the advisory is overstated. And if you > think "ospf is secure" against LAN activity after any patch, that > would be wishful thinking. Someone just rediscovered one of the > countless innumerable holes in the back of the cardboard box and tried > covering it with duck tape... I tend to agree. OTOH I'm not 100% sure if it's unexploitable outside LAN via unicast OSPF packets. But like you say MD5 offers some level of protection. I wish there would be some KDF for IGP KARP so that each LSA would actually have unique not-to-be-repeated password, so even if someone gets copy of one LSA and calculates out the MD5 it won't be relevant anymore. L2 is very dangerous in any platform I've tried, access to L2 and you can usually DoS the neighbouring router, even when optimally configured CoPP/Lo0 filter. -- ++ytti From wilhelm at ripe.net Sun Aug 4 11:31:34 2013 From: wilhelm at ripe.net (Rene Wilhelm) Date: Sun, 04 Aug 2013 13:31:34 +0200 Subject: IP allocations / bogon - ARIN Inconsistency In-Reply-To: References: <004f01ce90c0$c0f75bc0$42e61340$@iname.com> <51FDD335.5000101@he.net> Message-ID: <51FE3B96.8010508@ripe.net> On 8/4/13 6:50 AM, Geoff Huston wrote: > > > On 04/08/2013, at 2:06 PM, Rob Mosher wrote: > >> Frank, >> >> HE uses the extended files for these stats since the standard ones will soon be deprecated. As Rene pointed out, the extended and standard delegation files from ARIN do not match for this prefix. I do not know why there is inconsistent data between the two, but this is something that ARIN should look into. > I have been lead to understand that, for ARIN, the extended stats file reflects the registry state at a slightly different time (earlier by ~1 day) than the "standard" stats file. This is a likely explanation of the observed inconsistency. > > Geoff It looks like the update process for the extended stats got stuck. The files which have been published in recent days all are identical to the version of 2013-07-30, ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20130730 Thus allocations and changes made to the registry on 30 July or later are not accounted for in delegated-arin-extended-latest -- Rene From jeff.tantsura at ericsson.com Mon Aug 5 01:10:47 2013 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Mon, 5 Aug 2013 01:10:47 +0000 Subject: OSPF Vulnerability - Owning the Routing Table In-Reply-To: <20130804101200.GA6780@pob.ytti.fi> References: <20130804081703.GA4037@pob.ytti.fi> , <20130804101200.GA6780@pob.ytti.fi> Message-ID: Agree, that't why using p2p has been mentioned as BCP in networking "howto's" for at least last 10 years. Regards, Jeff On Aug 4, 2013, at 3:14 AM, "Saku Ytti" wrote: > On (2013-08-04 05:01 -0500), Jimmy Hess wrote: > >> I would say the risk score of the advisory is overstated. And if you >> think "ospf is secure" against LAN activity after any patch, that >> would be wishful thinking. Someone just rediscovered one of the >> countless innumerable holes in the back of the cardboard box and tried >> covering it with duck tape... > > I tend to agree. OTOH I'm not 100% sure if it's unexploitable outside LAN > via unicast OSPF packets. > But like you say MD5 offers some level of protection. I wish there would be > some KDF for IGP KARP so that each LSA would actually have unique > not-to-be-repeated password, so even if someone gets copy of one LSA and > calculates out the MD5 it won't be relevant anymore. > > L2 is very dangerous in any platform I've tried, access to L2 and you can > usually DoS the neighbouring router, even when optimally configured > CoPP/Lo0 filter. > > -- > ++ytti > From mysidia at gmail.com Mon Aug 5 04:07:59 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 4 Aug 2013 23:07:59 -0500 Subject: Returned mail: see transcript for details In-Reply-To: <201308050137.r751bCeX018121@mx1.kdc.fujixerox.co.jp> References: <201308050137.r751bCeX018121@mx1.kdc.fujixerox.co.jp> Message-ID: This was just received a flood of bounces reporting delivery failuers on messages I sent to nanog@ a few days ago... Actually, I have just received a flood of about 15 messages just like this one around 9:00pm; from various nanog posts I had sent 2 to 5 days in the past...... Is that strange or what? I thought the mailing list software rewrote the return path to suppress bounces? On 8/4/13, MAILER-DAEMON at mx1.kdc.fujixerox.co.jp wrote: > The original message was received at Mon, 5 Aug 2013 10:37:12 +0900 (JST) > from ms2.dc.fxis.co.jp [143.94.15.17] > > ----- The following addresses had permanent fatal errors ----- > > (reason: 550 5.1.1 : Recipient > address rejected: User unknown in local recipient table) > > ----- Transcript of session follows ----- > ... while talking to de-anza.rdh.fujixerox.co.jp.: >>>> DATA > <<< 550 5.1.1 : Recipient address > rejected: User unknown in local recipient table > 550 5.1.1 ... User unknown > <<< 554 5.5.1 Error: no valid recipients > -- -JH From wbailey at satelliteintelligencegroup.com Mon Aug 5 04:13:12 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 5 Aug 2013 04:13:12 +0000 Subject: Returned mail: see transcript for details In-Reply-To: References: <201308050137.r751bCeX018121@mx1.kdc.fujixerox.co.jp>, Message-ID: I got hit the same. Sent from my Mobile Device. -------- Original message -------- From: Jimmy Hess Date: 08/04/2013 9:09 PM (GMT-08:00) To: nanog at nanog.org Subject: Re: Returned mail: see transcript for details This was just received a flood of bounces reporting delivery failuers on messages I sent to nanog@ a few days ago... Actually, I have just received a flood of about 15 messages just like this one around 9:00pm; from various nanog posts I had sent 2 to 5 days in the past...... Is that strange or what? I thought the mailing list software rewrote the return path to suppress bounces? On 8/4/13, MAILER-DAEMON at mx1.kdc.fujixerox.co.jp wrote: > The original message was received at Mon, 5 Aug 2013 10:37:12 +0900 (JST) > from ms2.dc.fxis.co.jp [143.94.15.17] > > ----- The following addresses had permanent fatal errors ----- > > (reason: 550 5.1.1 : Recipient > address rejected: User unknown in local recipient table) > > ----- Transcript of session follows ----- > ... while talking to de-anza.rdh.fujixerox.co.jp.: >>>> DATA > <<< 550 5.1.1 : Recipient address > rejected: User unknown in local recipient table > 550 5.1.1 ... User unknown > <<< 554 5.5.1 Error: no valid recipients > -- -JH From LarrySheldon at cox.net Mon Aug 5 04:22:56 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 04 Aug 2013 23:22:56 -0500 Subject: Returned mail: see transcript for details In-Reply-To: <8sDy1m01f1Una3W01sE2NB> References: <201308050137.r751bCeX018121@mx1.kdc.fujixerox.co.jp>, <8sDy1m01f1Una3W01sE2NB> Message-ID: <51FF28A0.9010709@cox.net> On 8/4/2013 11:13 PM, Warren Bailey wrote: > I got hit the same. me too. errrr, me two. No clues as to what the messages were that I could see. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From Valdis.Kletnieks at vt.edu Mon Aug 5 04:52:16 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 05 Aug 2013 00:52:16 -0400 Subject: Returned mail: see transcript for details In-Reply-To: Your message of "Sun, 04 Aug 2013 23:07:59 -0500." References: <201308050137.r751bCeX018121@mx1.kdc.fujixerox.co.jp> Message-ID: <146509.1375678336@turing-police.cc.vt.edu> On Sun, 04 Aug 2013 23:07:59 -0500, Jimmy Hess said: > I thought the mailing list software rewrote the return path to > suppress bounces? Yeah, but every once in a while you'll come across a mail server hosted at Billy Bob's Bait, Tackle, and E-mail, or Klooful Joe's Bargain Hosting, that doesn't understand that bounces go to the RFC821 MAIL FROM and instead insist on sending to the RFC822 From:. In this case, it appears to be an end user with a badly misconfigured Fetchmail 6.3.21 that isn't handling bounces sanely. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From akennykant at gmail.com Mon Aug 5 09:45:51 2013 From: akennykant at gmail.com (Kenny Kant) Date: Mon, 5 Aug 2013 04:45:51 -0500 Subject: which firewall product? In-Reply-To: References: Message-ID: If the tunnel is to be terminated on this firewall device I would say look into a Mikrotik box. Alternatively you could make Cisco's IOS firewall / zone based firewall do this. So look into an ISR? Sent from my iPad On Jul 30, 2013, at 3:00 PM, William Herrin wrote: > Hi folks, > > I'm trying to identify a firewall appliance for one of my customers. > The wrinkle is: it has to be able to inspect packets inside an IPIP > tunnel and accept/reject based on IP address, TCP port number and > standard things like that. On the packet carried *inside* the IPIP > tunnel packet. > > > From what I can tell, the Cisco ASA can't do this. > > Linux iptables can (with the u32 match module) but the customer wants > an appliance, not a server. > > What appliances do you know of that can do this? Is there a different > Cisco box? A Juniper firewall? Anything else? > > Thanks in advance, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From becha at ripe.net Mon Aug 5 13:09:07 2013 From: becha at ripe.net (becha) Date: Mon, 05 Aug 2013 15:09:07 +0200 Subject: IP allocations / bogon - verification In-Reply-To: References: <5648A8908CCB564EBF46E2BC904A75B184E131A9BA@EXVPMBX100-1.exc.icann.org> Message-ID: <9a77f8125cfcd5b87ed8237b9347ec36@ripe.net> Hi, For additional information, including BGP history and BGplay, take a look at RIPEstat: https://stat.ripe.net/66.185.0.0/20#tabId=routing Regards, Vesna On 2013-08-02 21:09, Marcel Plug wrote: > On Fri, Aug 2, 2013 at 2:28 PM, Leo Vegoda > wrote: >> >> >> But I'd be fascinated - if somewhat disturbed - to be proved wrong... >> > > Team Cymru seems to think it was a Bogon, as recently as yesterday. > http://www.cymru.com/BGP/bogons.html (search for 66.185.0.0/20, last > seen > Aug 1st) From Chad.Reid at apollogrp.edu Sun Aug 4 14:41:18 2013 From: Chad.Reid at apollogrp.edu (Chad Reid) Date: Sun, 4 Aug 2013 07:41:18 -0700 Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts Message-ID: <4496469827D6CB48A4CE49A3C6602BD4A01A5CA1EB@EXCH07-02.apollogrp.edu> Hello NANOG, A few hundred of our users that use Comcast in the South East United States (other regions aren't affected) are unable to access our websites in the IP block 204.17.16.0/20. Based upon testing with the users, they're getting a destination unreachable from a Comcast backbone router in ASN 7922: be-16-pe03.56marietta.ga.ibone.comcast.net [68.86.83.134] reports: Destination net unreachable. We're not a customer of Comcast, nor are any of our ISPs. Because of this, we can't find anyone at Comcast to look at this issue nor do we have good contact info to even reach someone. Our users in the South East can open tickets with Comcast technical support, but you can imagine how successful they are trying to explain this to frontline support and getting frontline support to understand. Is anyone from Comcast on the list that can assist or know of a contact? Chad M. Reid, Network Administrator II Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) Apollo Group | IT Services ? IT Operations Center (ITOC) 4025 S. Riverpoint Parkway ? MS: AA-M002 ? Phoenix, AZ 85040 phone: 602.557.6746 ? fax: 602.557.6606 ? email: chad.reid at apollogrp.edu This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. From ahad at telcoinabox.com Mon Aug 5 11:09:05 2013 From: ahad at telcoinabox.com (Ahad Aboss) Date: Mon, 5 Aug 2013 21:09:05 +1000 Subject: ddos attacks In-Reply-To: References: Message-ID: <6613b77386ec3b13ce249100d02290c2@mail.gmail.com> Scott, Use a DDOS detection and mitigation system with DPI capabilities to deal with traditional DDOS attack and anomalous behaviour such as worm propagation, botnet attacks and malicious subscriber activity such as flooding and probing. There are only a few vendors who successfully play in this space who provide a self healing/self defending system. Cheers Ahad -----Original Message----- From: sgraun at airstreamcomm.net [mailto:sgraun at airstreamcomm.net] Sent: Friday, 2 August 2013 11:37 PM To: nanog at nanog.org Subject: ddos attacks I?m curious to know what other service providers are doing to alleviate/prevent ddos attacks from happening in your network. Are you completely reactive and block as many addresses as possible or null0 traffic to the effected host until it stops or do you block certain ports to prevent them. What?s the best way people are dealing with them? Scott From jpack at sevone.com Mon Aug 5 12:48:34 2013 From: jpack at sevone.com (Jason Pack) Date: Mon, 5 Aug 2013 08:48:34 -0400 Subject: which firewall product? In-Reply-To: References: Message-ID: I'm pretty sure you can do this with any modern firewall... An ASA5505 is always a good bet. You'd just have to route the IPIP packets to a hairpin interface on the firewall, then create a policy that handles packets coming inbound from the hairpin. Policies for handling traffic with that as the source interface would be able to filter based on layer-3 info as normal. The trick is, as mentioned, to route the de-encapsulated traffic back into the firewall. A quick googling shows a related example of this for the ASA here: http://nat0.net/cisco-asa-hairpinning/ *Jason Pack* Network Security Engineer - SevOne 4550 New Linden Hill Rd, Wilmington, DE, 19808 | p: 302-319-5400 | m: 302-464-0253 | e: jpack at sevone.com | w: www.SevOne.com On Mon, Aug 5, 2013 at 5:45 AM, Kenny Kant wrote: > If the tunnel is to be terminated on this firewall device I would say look > into a Mikrotik box. Alternatively you could make Cisco's IOS firewall / > zone based firewall do this. So look into an ISR? > > > Sent from my iPad > > On Jul 30, 2013, at 3:00 PM, William Herrin wrote: > > > Hi folks, > > > > I'm trying to identify a firewall appliance for one of my customers. > > The wrinkle is: it has to be able to inspect packets inside an IPIP > > tunnel and accept/reject based on IP address, TCP port number and > > standard things like that. On the packet carried *inside* the IPIP > > tunnel packet. > > > > > > From what I can tell, the Cisco ASA can't do this. > > > > Linux iptables can (with the u32 match module) but the customer wants > > an appliance, not a server. > > > > What appliances do you know of that can do this? Is there a different > > Cisco box? A Juniper firewall? Anything else? > > > > Thanks in advance, > > Bill Herrin > > > > > > -- > > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > > 3005 Crane Dr. ...................... Web: > > Falls Church, VA 22042-3004 > > > > From ak47 at gawul.net Mon Aug 5 14:10:38 2013 From: ak47 at gawul.net (Andrew Koch) Date: Mon, 5 Aug 2013 09:10:38 -0500 Subject: Returned mail: see transcript for details In-Reply-To: References: <201308050137.r751bCeX018121@mx1.kdc.fujixerox.co.jp> Message-ID: <860284E7-6E64-4CA2-A4B4-CF4FD6C084EA@gawul.net> On Aug 4, 2013, at 23:07, Jimmy Hess wrote: > This was just received a flood of bounces reporting delivery failuers > on messages I sent to nanog@ a few days ago... Actually, I have just > received a flood of about 15 messages just > > like this one around 9:00pm; from various nanog posts I had sent 2 to > 5 days in the past...... > Is that strange or what? > > I thought the mailing list software rewrote the return path to > suppress bounces? > > On 8/4/13, MAILER-DAEMON at mx1.kdc.fujixerox.co.jp > wrote: >> The original message was received at Mon, 5 Aug 2013 10:37:12 +0900 (JST) >> from ms2.dc.fxis.co.jp [143.94.15.17] >> >> ----- The following addresses had permanent fatal errors ----- >> >> (reason: 550 5.1.1 : Recipient >> address rejected: User unknown in local recipient table) >> The mailing list does try to receive and process bounce messages. I cannot find this address in the NANOG mailing list as a subscriber. It appears that a subscriber is forwarding messages to this mailbox. Best Regards, Andrew Koch on behalf of the NANOG Communications Committee From Valdis.Kletnieks at vt.edu Mon Aug 5 14:22:45 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 05 Aug 2013 10:22:45 -0400 Subject: Returned mail: see transcript for details In-Reply-To: Your message of "Mon, 05 Aug 2013 09:10:38 -0500." <860284E7-6E64-4CA2-A4B4-CF4FD6C084EA@gawul.net> References: <201308050137.r751bCeX018121@mx1.kdc.fujixerox.co.jp> <860284E7-6E64-4CA2-A4B4-CF4FD6C084EA@gawul.net> Message-ID: <194539.1375712565@turing-police.cc.vt.edu> On Mon, 05 Aug 2013 09:10:38 -0500, Andrew Koch said: > The mailing list does try to receive and process bounce messages. If it had caught these, I'd have been amazed - the offending site sent the bounces directly to the address in the From: so the NANOG mail server never saw the bounce. > I cannot find this address in the NANOG mailing list as a subscriber. It appears that a subscriber is forwarding messages to this mailbox. The bounces that you didn't see contained a Received: header that ID'ed the subscriber. I've sent you an off-list note.. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jra at baylink.com Mon Aug 5 16:10:17 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 5 Aug 2013 12:10:17 -0400 (EDT) Subject: Returned mail: see transcript for details In-Reply-To: <194539.1375712565@turing-police.cc.vt.edu> Message-ID: <6761435.2938.1375719016960.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > > The mailing list does try to receive and process bounce messages. > > If it had caught these, I'd have been amazed - the offending site sent > the > bounces directly to the address in the From: so the NANOG mail server > never > saw the bounce. The problem with that theory, Valdis, is that *I* saw half a dozen or so of them as well. So I'm guessing the list server did see at least some of them. 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 dsparro at gmail.com Mon Aug 5 17:16:54 2013 From: dsparro at gmail.com (Dave Sparro) Date: Mon, 05 Aug 2013 13:16:54 -0400 Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts In-Reply-To: <4496469827D6CB48A4CE49A3C6602BD4A01A5CA1EB@EXCH07-02.apollogrp.edu> References: <4496469827D6CB48A4CE49A3C6602BD4A01A5CA1EB@EXCH07-02.apollogrp.edu> Message-ID: <51FFDE06.8050201@gmail.com> On 8/4/2013 10:41 AM, Chad Reid wrote: > Is anyone from Comcast on the list that can assist or know of a contact? > > > This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. > I may, but it appears that you don't want me to share this message with him. -- Dave From Chad.Reid at apollogrp.edu Mon Aug 5 17:32:43 2013 From: Chad.Reid at apollogrp.edu (Chad Reid) Date: Mon, 5 Aug 2013 10:32:43 -0700 Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts Message-ID: <4496469827D6CB48A4CE49A3C6602BD4A01A5CA683@EXCH07-02.apollogrp.edu> Thanks for the assistance everyone. This issue was resolved by shutting down a BGP peering session between Time Warner and Comcast. --Chad Chad M. Reid, Network Administrator II Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) Apollo Group | IT Services ? IT Operations Center (ITOC) 4025 S. Riverpoint Parkway ? MS: AA-M002 ? Phoenix, AZ 85040 phone: 602.557.6746 ? fax: 602.557.6606 ? email: chad.reid at apollogrp.edu -----Original Message----- From: Chad Reid Sent: Sunday, August 04, 2013 7:41 AM To: 'nanog at nanog.org' Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts Hello NANOG, A few hundred of our users that use Comcast in the South East United States (other regions aren't affected) are unable to access our websites in the IP block 204.17.16.0/20. Based upon testing with the users, they're getting a destination unreachable from a Comcast backbone router in ASN 7922: be-16-pe03.56marietta.ga.ibone.comcast.net [68.86.83.134] reports: Destination net unreachable. We're not a customer of Comcast, nor are any of our ISPs. Because of this, we can't find anyone at Comcast to look at this issue nor do we have good contact info to even reach someone. Our users in the South East can open tickets with Comcast technical support, but you can imagine how successful they are trying to explain this to frontline support and getting frontline support to understand. Is anyone from Comcast on the list that can assist or know of a contact? Chad M. Reid, Network Administrator II Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) Apollo Group | IT Services ? IT Operations Center (ITOC) 4025 S. Riverpoint Parkway ? MS: AA-M002 ? Phoenix, AZ 85040 phone: 602.557.6746 ? fax: 602.557.6606 ? email: chad.reid at apollogrp.edu This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. From marcelplug at gmail.com Mon Aug 5 18:26:05 2013 From: marcelplug at gmail.com (Marcel Plug) Date: Mon, 5 Aug 2013 14:26:05 -0400 Subject: RPKI and Trust Anchor question Message-ID: Hi Nanog, Does anyone have any inside information what may be happening in the effort to have a single trust anchor for RPKI? Is ICANN still working on this? If so is there any timeline or published info of any kind? Most of the information i can find is about 2 years old. Any links or info of any kind would be much appreciated. Thanks, Marcel Plug From rubensk at gmail.com Mon Aug 5 18:59:22 2013 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 5 Aug 2013 15:59:22 -0300 Subject: RPKI and Trust Anchor question In-Reply-To: References: Message-ID: NRO, the RIRs collective, is still working on this. It's listed as an open action item since Q2 this CY at NRO Executive Council meetings: http://www.nro.net It's very unlikely that ICANN, which sees the NRO as it's address support organization, will move on this before NRO does. Rubens On Mon, Aug 5, 2013 at 3:26 PM, Marcel Plug wrote: > Hi Nanog, > > Does anyone have any inside information what may be happening in the effort > to have a single trust anchor for RPKI? Is ICANN still working on this? > If so is there any timeline or published info of any kind? > > Most of the information i can find is about 2 years old. > > Any links or info of any kind would be much appreciated. > > Thanks, > > Marcel Plug > From drc at virtualized.org Mon Aug 5 19:08:33 2013 From: drc at virtualized.org (David Conrad) Date: Mon, 5 Aug 2013 12:08:33 -0700 Subject: RPKI and Trust Anchor question In-Reply-To: References: Message-ID: Actually, ICANN had an RPKI pilot in operation back in 1996 or so. For political reasons (as far as I can tell), the RIRs refused to let ICANN/IANA play. Unless the RIRs are willing to accept ICANN/IANA as the root TA as recommended by the IAB, ICANN can't move forward. Regards, -drc ---- Mobile device, sorry about tpyos On Aug 5, 2013, at 11:59 AM, Rubens Kuhl wrote: > NRO, the RIRs collective, is still working on this. It's listed as an open > action item since Q2 this CY at NRO Executive Council meetings: > http://www.nro.net > > It's very unlikely that ICANN, which sees the NRO as it's address support > organization, will move on this before NRO does. > > > Rubens > > > > > > > On Mon, Aug 5, 2013 at 3:26 PM, Marcel Plug wrote: > >> Hi Nanog, >> >> Does anyone have any inside information what may be happening in the effort >> to have a single trust anchor for RPKI? Is ICANN still working on this? >> If so is there any timeline or published info of any kind? >> >> Most of the information i can find is about 2 years old. >> >> Any links or info of any kind would be much appreciated. >> >> Thanks, >> >> Marcel Plug >> From bill at herrin.us Mon Aug 5 19:19:25 2013 From: bill at herrin.us (William Herrin) Date: Mon, 5 Aug 2013 15:19:25 -0400 Subject: which firewall product? In-Reply-To: References: Message-ID: On Mon, Aug 5, 2013 at 8:48 AM, Jason Pack wrote: > I'm pretty sure you can do this with any modern firewall... An ASA5505 is > always a good bet. > > You'd just have to route the IPIP packets to a hairpin interface on the > firewall, then create a policy that handles packets coming inbound from the > hairpin. Policies for handling traffic with that as the source interface > would be able to filter based on layer-3 info as normal. Hi Jason, Hairpinning. So, set a router in there with a policy set on the inbound ipip tunnel to forward all traffic out an ethernet to the ASA. Then once I get it back on another ethernet from the ASA, use another policy route to push it all to an outbound tunnel interface. I hadn't considered that. Yikes, I'm not sure I want to. :) Thanks, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From barbara.roseman at icann.org Mon Aug 5 22:22:44 2013 From: barbara.roseman at icann.org (Barbara Roseman) Date: Mon, 5 Aug 2013 15:22:44 -0700 Subject: RPKI and Trust Anchor question In-Reply-To: Message-ID: I think David meant 2006, not 1996. -Barb Roseman On 8/5/13 12:08 PM, "David Conrad" wrote: >Actually, ICANN had an RPKI pilot in operation back in 1996 or so. For >political reasons (as far as I can tell), the RIRs refused to let >ICANN/IANA play. Unless the RIRs are willing to accept ICANN/IANA as the >root TA as recommended by the IAB, ICANN can't move forward. > >Regards, >-drc >---- >Mobile device, sorry about tpyos > >On Aug 5, 2013, at 11:59 AM, Rubens Kuhl wrote: > >> NRO, the RIRs collective, is still working on this. It's listed as an >>open >> action item since Q2 this CY at NRO Executive Council meetings: >> http://www.nro.net >> >> It's very unlikely that ICANN, which sees the NRO as it's address >>support >> organization, will move on this before NRO does. >> >> >> Rubens >> >> >> >> >> >> >> On Mon, Aug 5, 2013 at 3:26 PM, Marcel Plug >>wrote: >> >>> Hi Nanog, >>> >>> Does anyone have any inside information what may be happening in the >>>effort >>> to have a single trust anchor for RPKI? Is ICANN still working on >>>this? >>> If so is there any timeline or published info of any kind? >>> >>> Most of the information i can find is about 2 years old. >>> >>> Any links or info of any kind would be much appreciated. >>> >>> Thanks, >>> >>> Marcel Plug >>> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5046 bytes Desc: not available URL: From jcurran at arin.net Tue Aug 6 01:58:40 2013 From: jcurran at arin.net (John Curran) Date: Tue, 6 Aug 2013 01:58:40 +0000 Subject: RPKI and Trust Anchor question In-Reply-To: References: Message-ID: <2AA52AF5-F613-4EA4-AA0A-33875AC4F94F@corp.arin.net> On Aug 5, 2013, at 2:26 PM, Marcel Plug wrote: > Hi Nanog, > > Does anyone have any inside information what may be happening in the effort > to have a single trust anchor for RPKI? Is ICANN still working on this? > If so is there any timeline or published info of any kind? > > Most of the information i can find is about 2 years old. > > Any links or info of any kind would be much appreciated. Hello Marcel - The IAB and the five RIRs have both indicated that it is desirable to have a single trust anchor for RPKI. The IAB made a statement in 2010 here and in August 2011, the RIRs asked to meet with ICANN to work towards "an ICANN-hosted global trust anchor for the RPKI system." ICANN has indicated that it is willing to host such a service, and has included support for it within ICANN budget each year. Since that time, there has been quite a bit of technical work going on between the RIR's and ICANN's technical teams, including work to document some of the technical issues that might result from having a global trust anchor (if you are interested in those, you might want to follow the IETF sidr working group.) I would say that slow and steady progress is being made towards the technical ability to have a single global trust anchor (including understanding some of the more interesting things that happen with key roll-overs, blocks transfers between RIRs, etc.); my present estimate is that we'll have a solid understanding of technical steps and consequences for deploying a RPKI global trust anchor by the end of 2013. There is discussion of preparing a ICANN/RIR testbed at that time to demonstrate technical compatibility and functionality of the RPKI system while making use of a Global Trust Anchor. In parallel, there is another set of issues being worked, and that is engaging with the operator community in each region to understand their desire for having a global trust anchor. It has been noted that relying on such a construct will effectively create a single point of "control" for Internet operational routing (to the extent that folks everywhere begin actively validating routes using RPKI.) There is a single point of failure argument against a global trust anchor, as well as creation of a point of potential compromise, whether due to malfeasance or actual governmental interference. Note that these types of concerns are very similar to those faced by DNSSEC, and in that case they were able to be managed in an acceptable manner. The discussion of the merit of a single trust anchor is still ongoing among operators globally, and will need to reach convergence in order to proceed (in addition to the technical issues outlined above.) So, Marcel, please allow me to turn the question around... Do you do you believe that there should be an RPKI Global Trust Anchor? Are you concerned about the potential aggregation of control and risk that may result? (Feel free to answer me privately if you would prefer.) At the point in time when we understand the technical architecture being proposed and its implications, we will formally poll the ARIN and NANOG community on the question of whether there is support for having an RPKI Global Trust Anchor. My best estimate is that this will occur near the end of this year, but there's nothing wrong with having some discussion in the meantime if the mailing list is otherwise quiet. :-) I hope this provides some insight - thank you for asking about it, as it has been too long since any status update on this project (I will work on that as well for the very near future.) Thanks! /John John Curran President and CEO ARIN From dougb at dougbarton.us Tue Aug 6 04:25:18 2013 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 05 Aug 2013 21:25:18 -0700 Subject: RPKI and Trust Anchor question In-Reply-To: <2AA52AF5-F613-4EA4-AA0A-33875AC4F94F@corp.arin.net> References: <2AA52AF5-F613-4EA4-AA0A-33875AC4F94F@corp.arin.net> Message-ID: <52007AAE.3090202@dougbarton.us> On 08/05/2013 06:58 PM, John Curran wrote: > > On Aug 5, 2013, at 2:26 PM, Marcel Plug wrote: > >> Hi Nanog, >> >> Does anyone have any inside information what may be happening in the effort >> to have a single trust anchor for RPKI? Is ICANN still working on this? >> If so is there any timeline or published info of any kind? >> >> Most of the information i can find is about 2 years old. >> >> Any links or info of any kind would be much appreciated. > > Hello Marcel - > > The IAB and the five RIRs have both indicated that it is desirable > to have a single trust anchor for RPKI. The IAB made a statement > in 2010 here > and in August 2011, the RIRs asked to meet with ICANN to work towards > "an ICANN-hosted global trust anchor for the RPKI system." > > ICANN has indicated that it is willing to host such a service, and has > included support for it within ICANN budget each year. > > Since that time, there has been quite a bit of technical work going on > between the RIR's and ICANN's technical teams, including work to document > some of the technical issues that might result from having a global trust > anchor (if you are interested in those, you might want to follow the IETF > sidr working group.) I would say that slow and steady progress is being > made towards the technical ability to have a single global trust anchor > (including understanding some of the more interesting things that happen > with key roll-overs, blocks transfers between RIRs, etc.); my present > estimate is that we'll have a solid understanding of technical steps and > consequences for deploying a RPKI global trust anchor by the end of 2013. > There is discussion of preparing a ICANN/RIR testbed at that time to > demonstrate technical compatibility and functionality of the RPKI system > while making use of a Global Trust Anchor. > > In parallel, there is another set of issues being worked, and that is > engaging with the operator community in each region to understand their > desire for having a global trust anchor. It has been noted that relying > on such a construct will effectively create a single point of "control" > for Internet operational routing (to the extent that folks everywhere > begin actively validating routes using RPKI.) There is a single point > of failure argument against a global trust anchor, as well as creation > of a point of potential compromise, whether due to malfeasance or actual > governmental interference. Note that these types of concerns are very > similar to those faced by DNSSEC, and in that case they were able to be > managed in an acceptable manner. The discussion of the merit of a single > trust anchor is still ongoing among operators globally, and will need to > reach convergence in order to proceed (in addition to the technical issues > outlined above.) > > So, Marcel, please allow me to turn the question around... Do you > do you believe that there should be an RPKI Global Trust Anchor? > Are you concerned about the potential aggregation of control and > risk that may result? (Feel free to answer me privately if you > would prefer.) > > At the point in time when we understand the technical architecture > being proposed and its implications, we will formally poll the ARIN > and NANOG community on the question of whether there is support for > having an RPKI Global Trust Anchor. My best estimate is that this > will occur near the end of this year, but there's nothing wrong with > having some discussion in the meantime if the mailing list is otherwise > quiet. :-) > > I hope this provides some insight - thank you for asking about it, > as it has been too long since any status update on this project > (I will work on that as well for the very near future.) > > Thanks! > /John > > John Curran > President and CEO > ARIN John, Thanks for the update! It's good to hear that progress is being made. Is there a place where the challenges and solutions are being discussed publicly? It's interesting that you raise DNSSEC in comparison since the two technologies have many similarities. One of the things that made DNSSEC successful was the wide-ranging public discussion that not only led to concerns that would likely not have been uncovered otherwise, but also solutions to those and other problems. Doug From randy at psg.com Tue Aug 6 06:58:07 2013 From: randy at psg.com (Randy Bush) Date: Tue, 06 Aug 2013 08:58:07 +0200 Subject: RPKI and Trust Anchor question In-Reply-To: References: Message-ID: > Actually, ICANN had an RPKI pilot in operation back in 1996 or so. For > political reasons (as far as I can tell), the RIRs refused to let > ICANN/IANA play. Unless the RIRs are willing to accept ICANN/IANA as > the root TA as recommended by the IAB, ICANN can't move forward. the rirs should get their next (ipv6) address allocations from the nro pool, eh? From jcurran at arin.net Tue Aug 6 13:32:13 2013 From: jcurran at arin.net (John Curran) Date: Tue, 6 Aug 2013 13:32:13 +0000 Subject: RPKI and Trust Anchor question In-Reply-To: <52007AAE.3090202@dougbarton.us> References: <2AA52AF5-F613-4EA4-AA0A-33875AC4F94F@corp.arin.net> <52007AAE.3090202@dougbarton.us> Message-ID: <1E12E256-657A-4B6C-B680-BB99F1D95F20@corp.arin.net> On Aug 6, 2013, at 12:25 AM, Doug Barton wrote: > John, > > Thanks for the update! It's good to hear that progress is being made. > > Is there a place where the challenges and solutions are being discussed publicly? It's interesting that you raise DNSSEC in comparison since the two technologies have many similarities. One of the things that made DNSSEC successful was the wide-ranging public discussion that not only led to concerns that would likely not have been uncovered otherwise, but also solutions to those and other problems. Agreed. I believe that it is necessary to do the same with respect to any global trust anchor architecture for RPKI, and believe that much of this needs to take place initially in the IETF sidr working group. The first step of that process is to have an initial draft doc for discussion (which is presently being written by the ICANN/RIR technical folks.) FYI, /John John Curran President and CEO ARIN From drc at virtualized.org Tue Aug 6 14:35:32 2013 From: drc at virtualized.org (David Conrad) Date: Tue, 6 Aug 2013 07:35:32 -0700 Subject: RPKI and Trust Anchor question In-Reply-To: References: Message-ID: <4990D871-3111-4336-90E6-87D04441B72F@virtualized.org> Barb, You've apparently forgotten ICANN's time distortion field (which they'll be inventing very shortly with the zillions of dollars they'll get from the new gTLD program). Err, yeah. 2006. Apologies -- typing on a cellphone can be distracting. Regards, -drc On Aug 5, 2013, at 3:22 PM, Barbara Roseman wrote: > I think David meant 2006, not 1996. > > -Barb Roseman > > On 8/5/13 12:08 PM, "David Conrad" wrote: > >> Actually, ICANN had an RPKI pilot in operation back in 1996 or so. For >> political reasons (as far as I can tell), the RIRs refused to let >> ICANN/IANA play. Unless the RIRs are willing to accept ICANN/IANA as the >> root TA as recommended by the IAB, ICANN can't move forward. >> >> Regards, >> -drc >> ---- >> Mobile device, sorry about tpyos >> >> On Aug 5, 2013, at 11:59 AM, Rubens Kuhl wrote: >> >>> NRO, the RIRs collective, is still working on this. It's listed as an >>> open >>> action item since Q2 this CY at NRO Executive Council meetings: >>> http://www.nro.net >>> >>> It's very unlikely that ICANN, which sees the NRO as it's address >>> support >>> organization, will move on this before NRO does. >>> >>> >>> Rubens >>> >>> >>> >>> >>> >>> >>> On Mon, Aug 5, 2013 at 3:26 PM, Marcel Plug >>> wrote: >>> >>>> Hi Nanog, >>>> >>>> Does anyone have any inside information what may be happening in the >>>> effort >>>> to have a single trust anchor for RPKI? Is ICANN still working on >>>> this? >>>> If so is there any timeline or published info of any kind? >>>> >>>> Most of the information i can find is about 2 years old. >>>> >>>> Any links or info of any kind would be much appreciated. >>>> >>>> Thanks, >>>> >>>> Marcel Plug >>>> >> From andy at newslink.com Tue Aug 6 15:56:23 2013 From: andy at newslink.com (Andy Ringsmuth) Date: Tue, 6 Aug 2013 10:56:23 -0500 Subject: Comcast contact Message-ID: <7602EBBC-4007-4E59-B6CE-E9B8D4B36250@newslink.com> Any chance someone on this list is affiliated with Comcast who could contact me off-list? I have an employee in Virginia who works from home using, in part, a VOIP desk telephone tied into our office phone system back in Nebraska. She's had nothing but problems maintaining a stable connection and I'm at my wit's end to diagnose and fix whatever is causing her problems. I've got this exact setup with several employees around the country, but this one person is the only one who, 1 - has problems and 2 - has Comcast. Much appreciated! ---- Andy Ringsmuth andy at newslink.com News Link ? Manager Technology & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From brandon.galbraith at gmail.com Tue Aug 6 16:10:30 2013 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Tue, 6 Aug 2013 11:10:30 -0500 Subject: Comcast contact In-Reply-To: <7602EBBC-4007-4E59-B6CE-E9B8D4B36250@newslink.com> References: <7602EBBC-4007-4E59-B6CE-E9B8D4B36250@newslink.com> Message-ID: Have you monitored your user's home Comcast connection with regards to packet loss or latency, preferably from network-near the SIP termination point? On Tue, Aug 6, 2013 at 10:56 AM, Andy Ringsmuth wrote: > Any chance someone on this list is affiliated with Comcast who could contact me off-list? I have an employee in Virginia who works from home using, in part, a VOIP desk telephone tied into our office phone system back in Nebraska. She's had nothing but problems maintaining a stable connection and I'm at my wit's end to diagnose and fix whatever is causing her problems. > > I've got this exact setup with several employees around the country, but this one person is the only one who, 1 - has problems and 2 - has Comcast. > > Much appreciated! > > ---- > Andy Ringsmuth > andy at newslink.com > News Link ? Manager Technology & Facilities > 2201 Winthrop Rd., Lincoln, NE 68502-4158 > (402) 475-6397 (402) 304-0083 cellular > > From mshaw at fairpoint.com Tue Aug 6 17:42:06 2013 From: mshaw at fairpoint.com (Shaw, Matthew) Date: Tue, 6 Aug 2013 17:42:06 +0000 Subject: Comcast contact In-Reply-To: References: <7602EBBC-4007-4E59-B6CE-E9B8D4B36250@newslink.com> Message-ID: <457F9455036417428963A59E3B38874120252662@0NH1C2P10.fairpoint.com> Make sure the remote phone is using a low bandwidth codec too. In a previous life changing a remote (home) user's phone from G.711 to G.729 made all the difference in the world to their call quality. Matthew Shaw ? Sr. Network Administrator FairPoint Communications | mshaw at fairpoint.com www.FairPoint.com -----Original Message----- From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] Sent: Tuesday, August 06, 2013 12:11 PM To: Andy Ringsmuth Cc: NANOG list Subject: Re: Comcast contact Have you monitored your user's home Comcast connection with regards to packet loss or latency, preferably from network-near the SIP termination point? On Tue, Aug 6, 2013 at 10:56 AM, Andy Ringsmuth wrote: > Any chance someone on this list is affiliated with Comcast who could contact me off-list? I have an employee in Virginia who works from home using, in part, a VOIP desk telephone tied into our office phone system back in Nebraska. She's had nothing but problems maintaining a stable connection and I'm at my wit's end to diagnose and fix whatever is causing her problems. > > I've got this exact setup with several employees around the country, but this one person is the only one who, 1 - has problems and 2 - has Comcast. > > Much appreciated! > > ---- > Andy Ringsmuth > andy at newslink.com > News Link ? Manager Technology & Facilities > 2201 Winthrop Rd., Lincoln, NE 68502-4158 > (402) 475-6397 (402) 304-0083 cellular > > _______________________________________________________________________ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media. From Valdis.Kletnieks at vt.edu Tue Aug 6 19:16:43 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 06 Aug 2013 15:16:43 -0400 Subject: RPKI and Trust Anchor question In-Reply-To: Your message of "Tue, 06 Aug 2013 07:35:32 -0700." <4990D871-3111-4336-90E6-87D04441B72F@virtualized.org> References: <4990D871-3111-4336-90E6-87D04441B72F@virtualized.org> Message-ID: <10330.1375816603@turing-police.cc.vt.edu> On Tue, 06 Aug 2013 07:35:32 -0700, David Conrad said: > You've apparently forgotten ICANN's time distortion field Apple will almost certainly sue for infringing their reality distortion field patents. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From faisal at snappytelecom.net Tue Aug 6 21:57:05 2013 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 6 Aug 2013 21:57:05 +0000 (GMT) Subject: Comcast contact In-Reply-To: <7602EBBC-4007-4E59-B6CE-E9B8D4B36250@newslink.com> References: <7602EBBC-4007-4E59-B6CE-E9B8D4B36250@newslink.com> Message-ID: <1777054932.293297.1375826225739.JavaMail.root@snappytelecom.net> If you run something like a pingplotter or MTR from pbx side towards the Remote, and do similar from remote towards the pbx side... Let it run for a bit, and compare / analyse the results.. you will spot your problem very quickly. ------- We find that the IP Transit is often overloaded between Comcast networks and certain IP Transit providers. or Some common IP Transit provider have their routers overloaded thus having packet loss. We have had to some route engineering to get around these issues. In our case we are fortunate to have multiple IP Transit Carriers, so that was possible. ------- Regards Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- From: "Andy Ringsmuth" To: "NANOG list" Sent: Tuesday, August 6, 2013 11:56:23 AM Subject: Comcast contact Any chance someone on this list is affiliated with Comcast who could contact me off-list? I have an employee in Virginia who works from home using, in part, a VOIP desk telephone tied into our office phone system back in Nebraska. She's had nothing but problems maintaining a stable connection and I'm at my wit's end to diagnose and fix whatever is causing her problems. I've got this exact setup with several employees around the country, but this one person is the only one who, 1 - has problems and 2 - has Comcast. Much appreciated! ---- Andy Ringsmuth andy at newslink.com News Link ? Manager Technology & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From ryan.landry at gmail.com Tue Aug 6 23:25:19 2013 From: ryan.landry at gmail.com (ryanL) Date: Tue, 6 Aug 2013 16:25:19 -0700 Subject: Returned mail: see transcript for details In-Reply-To: <6761435.2938.1375719016960.JavaMail.root@benjamin.baylink.com> References: <194539.1375712565@turing-police.cc.vt.edu> <6761435.2938.1375719016960.JavaMail.root@benjamin.baylink.com> Message-ID: as it so happens, i could still use a decent contact over at AS3209. noc channels are unresponsive. even tried this one listed in radb: noc at adm.arcor.net. they are doing something really funky with their cg-nat setup for mobile subs. like, frag mapping gone wrong, therefore crazy retries or acks never received, etc. for us, it is breaking SSL. From jmkeller at houseofzen.org Wed Aug 7 01:42:24 2013 From: jmkeller at houseofzen.org (James M Keller) Date: Tue, 06 Aug 2013 21:42:24 -0400 Subject: Comcast contact In-Reply-To: <7602EBBC-4007-4E59-B6CE-E9B8D4B36250@newslink.com> References: <7602EBBC-4007-4E59-B6CE-E9B8D4B36250@newslink.com> Message-ID: <5201A600.7080408@houseofzen.org> On 8/6/2013 11:56 AM, Andy Ringsmuth wrote: > Any chance someone on this list is affiliated with Comcast who could contact me off-list? I have an employee in Virginia who works from home using, in part, a VOIP desk telephone tied into our office phone system back in Nebraska. She's had nothing but problems maintaining a stable connection and I'm at my wit's end to diagnose and fix whatever is causing her problems. > > I've got this exact setup with several employees around the country, but this one person is the only one who, 1 - has problems and 2 - has Comcast. > > Much appreciated! > > ---- > Andy Ringsmuth > andy at newslink.com > News Link ? Manager Technology & Facilities > 2201 Winthrop Rd., Lincoln, NE 68502-4158 > (402) 475-6397 (402) 304-0083 cellular > > > I have found Comcast rate shapes or resets long running encrypted sessions such as https. At $DAYJOB I had to set our SSL VPN system to re-key via new-tunnels every 5 minutes to keep it under their threshold of what looks like seven minutes for a tcp session. After that the sessions appeared to rate shape down to 128kbps. It may also only kick in during local POP congestion. I am assuming this is DPI trying to do peer-2-peer mitigation. --- James M Keller From marcelplug at gmail.com Wed Aug 7 02:53:48 2013 From: marcelplug at gmail.com (Marcel Plug) Date: Tue, 6 Aug 2013 22:53:48 -0400 Subject: RPKI and Trust Anchor question In-Reply-To: <2AA52AF5-F613-4EA4-AA0A-33875AC4F94F@corp.arin.net> References: <2AA52AF5-F613-4EA4-AA0A-33875AC4F94F@corp.arin.net> Message-ID: Thanks for your detailed response John. Further comments inline. On Mon, Aug 5, 2013 at 9:58 PM, John Curran wrote: > > > So, Marcel, please allow me to turn the question around... Do you > do you believe that there should be an RPKI Global Trust Anchor? > Are you concerned about the potential aggregation of control and > risk that may result? (Feel free to answer me privately if you > would prefer.) > Having a single root seems like the right way to go. There will always be the threat (real or imagined) of outside interference. For that reason I'm sure there will be a small droid army of independent systems monitoring and studying every change the Global Trust Anchor makes - ready to sound the alarm. It's probably easier to keep an eye on one trust anchor than it is to monitor 5 of them. All the other arguments I've heard are in favour of a one-TA system so I won't repeat them. > > At the point in time when we understand the technical architecture > being proposed and its implications, we will formally poll the ARIN > and NANOG community on the question of whether there is support for > having an RPKI Global Trust Anchor. My best estimate is that this > will occur near the end of this year, but there's nothing wrong with > having some discussion in the meantime if the mailing list is otherwise > quiet. :-) > > I hope this provides some insight - thank you for asking about it, > as it has been too long since any status update on this project > (I will work on that as well for the very near future.) > As I said, thanks for the update. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > > > Marcel From rs at seastrom.com Wed Aug 7 03:55:38 2013 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 06 Aug 2013 23:55:38 -0400 Subject: Comcast contact In-Reply-To: <457F9455036417428963A59E3B38874120252662@0NH1C2P10.fairpoint.com> (Matthew Shaw's message of "Tue, 6 Aug 2013 17:42:06 +0000") References: <7602EBBC-4007-4E59-B6CE-E9B8D4B36250@newslink.com> <457F9455036417428963A59E3B38874120252662@0NH1C2P10.fairpoint.com> Message-ID: <864nb2yx1h.fsf@valhalla.seastrom.com> "Shaw, Matthew" writes: > Make sure the remote phone is using a low bandwidth codec too. In a > previous life changing a remote (home) user's phone from G.711 to > G.729 made all the difference in the world to their call quality. i think you've got that backwards. 80 kbit/sec on the wire is not a lot these days, and in a world where we're conditioned to accept gsm or worse, un-transcoded g.711u sounds startlingly good. if you're so short on bandwidth that moving to a 24 kbit/sec on the wire codec makes a difference, you're on the ragged edge of being hosed. -r From m4rtntns at gmail.com Wed Aug 7 08:20:52 2013 From: m4rtntns at gmail.com (Martin T) Date: Wed, 7 Aug 2013 11:20:52 +0300 Subject: questions regarding prefix hijacking Message-ID: Hi, as probably many of you know, it's possible to create a "route" object to RIPE database for an address space which is allocated outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example an address space is from APNIC or ARIN region and AS is from RIPE region. For example a LIR in RIPE region creates a "route" object to RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) prefix without having written permission from Turner Broadcasting System and as this LIR uses up-link providers who create prefix filters automatically according to RADb database entries, this ISP is soon able to announce this 157.166.266.0/24 prefix to Internet. This should disturb the availability of the real 157.166.266.0/24 network on Internet? Has there been such situations in history? Isn't there a method against such hijacking? Or have I misunderstood something and this isn't possible? regards, Martin From fergdawgster at gmail.com Wed Aug 7 08:40:34 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 7 Aug 2013 01:40:34 -0700 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: Unfortunately, it is way too easy for people to inject routes into the global routing system. I think most of the folks on the list can attest to that. :-) - ferg On Wed, Aug 7, 2013 at 1:20 AM, Martin T wrote: > Hi, > > as probably many of you know, it's possible to create a "route" object > to RIPE database for an address space which is allocated outside the > RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example > an address space is from APNIC or ARIN region and AS is from RIPE > region. For example a LIR in RIPE region creates a "route" object to > RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) > prefix without having written permission from Turner Broadcasting > System and as this LIR uses up-link providers who create prefix > filters automatically according to RADb database entries, this ISP is > soon able to announce this 157.166.266.0/24 prefix to Internet. This > should disturb the availability of the real 157.166.266.0/24 network > on Internet? Has there been such situations in history? Isn't there a > method against such hijacking? Or have I misunderstood something and > this isn't possible? > > > regards, > Martin > -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From saku at ytti.fi Wed Aug 7 08:58:57 2013 From: saku at ytti.fi (Saku Ytti) Date: Wed, 7 Aug 2013 11:58:57 +0300 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: <20130807085857.GA7561@pob.ytti.fi> On (2013-08-07 11:20 +0300), Martin T wrote: > on Internet? Has there been such situations in history? Isn't there a > method against such hijacking? Or have I misunderstood something and > this isn't possible? Certainly practical scenario, but in many cases not needed at all. In most cases upstream does not do any automatic prefix filter generation, it's maybe somewhat popular in mid-sized european shops but generally not too common. There is active on-going work to secure BGP and you may want to read up on 'RPKI' which is further along that track. -- ++ytti From fergdawgster at gmail.com Wed Aug 7 09:03:45 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 7 Aug 2013 02:03:45 -0700 Subject: questions regarding prefix hijacking In-Reply-To: <20130807085857.GA7561@pob.ytti.fi> References: <20130807085857.GA7561@pob.ytti.fi> Message-ID: On Wed, Aug 7, 2013 at 1:58 AM, Saku Ytti wrote: > On (2013-08-07 11:20 +0300), Martin T wrote: > >> on Internet? Has there been such situations in history? Isn't there a >> method against such hijacking? Or have I misunderstood something and >> this isn't possible? > > Certainly practical scenario, but in many cases not needed at all. In most > cases upstream does not do any automatic prefix filter generation, it's > maybe somewhat popular in mid-sized european shops but generally not too > common. > > There is active on-going work to secure BGP and you may want to read up on > 'RPKI' which is further along that track. > I hope it has better adoption than BCP38/BCP84. :-) - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From m4rtntns at gmail.com Wed Aug 7 09:13:17 2013 From: m4rtntns at gmail.com (Martin T) Date: Wed, 7 Aug 2013 12:13:17 +0300 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: Ok. And such attacks have happened in the past? For example one could do a pretty widespread damage for at least short period of time if it announces for example some of the root DNS server prefixes(as long prefixes as possible) to it's upstream provider and as upstream provider probably prefers client traffic over it's peerings or upstreams, it will prefer those routes by malicious ISP for all the traffic to root DNS servers? regards, Martin 2013/8/7, Paul Ferguson : > Unfortunately, it is way too easy for people to inject routes into the > global routing system. > > I think most of the folks on the list can attest to that. :-) > > - ferg > > > On Wed, Aug 7, 2013 at 1:20 AM, Martin T wrote: > >> Hi, >> >> as probably many of you know, it's possible to create a "route" object >> to RIPE database for an address space which is allocated outside the >> RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example >> an address space is from APNIC or ARIN region and AS is from RIPE >> region. For example a LIR in RIPE region creates a "route" object to >> RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) >> prefix without having written permission from Turner Broadcasting >> System and as this LIR uses up-link providers who create prefix >> filters automatically according to RADb database entries, this ISP is >> soon able to announce this 157.166.266.0/24 prefix to Internet. This >> should disturb the availability of the real 157.166.266.0/24 network >> on Internet? Has there been such situations in history? Isn't there a >> method against such hijacking? Or have I misunderstood something and >> this isn't possible? >> >> >> regards, >> Martin >> > > > > -- > "Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > From stucchi-lists at glevia.com Wed Aug 7 09:31:04 2013 From: stucchi-lists at glevia.com (Massimiliano Stucchi) Date: Wed, 07 Aug 2013 11:31:04 +0200 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: <520213D8.60100@glevia.com> On 8/7/13 11:13 AM, Martin T wrote: > Ok. And such attacks have happened in the past? For example one could > do a pretty widespread damage for at least short period of time if it > announces for example some of the root DNS server prefixes(as long > prefixes as possible) to it's upstream provider and as upstream > provider probably prefers client traffic over it's peerings or > upstreams, it will prefer those routes by malicious ISP for all the > traffic to root DNS servers? Of course similar problems have occurred in the past. Just take a look at this video: http://www.youtube.com/watch?v=IzLPKuAOe50 Some minor occurrences have happened recently as well. Ciao! -- Massimiliano Stucchi From fergdawgster at gmail.com Wed Aug 7 10:07:04 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 7 Aug 2013 03:07:04 -0700 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: On Wed, Aug 7, 2013 at 2:13 AM, Martin T wrote: > Ok. And such attacks have happened in the past? For example one could > do a pretty widespread damage for at least short period of time if it > announces for example some of the root DNS server prefixes(as long > prefixes as possible) to it's upstream provider and as upstream > provider probably prefers client traffic over it's peerings or > upstreams, it will prefer those routes by malicious ISP for all the > traffic to root DNS servers? > > Historically, most prefix hijacks have been accidental, generally due to configuration error -- for instance: http://www.renesys.com/2008/02/pakistan-hijacks-youtube-1/ Having said that, there are quite a few documented cases of it being done intentionally, and for nefarious purposes. - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From ahad at telcoinabox.com Wed Aug 7 11:23:49 2013 From: ahad at telcoinabox.com (Ahad Aboss) Date: Wed, 7 Aug 2013 21:23:49 +1000 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: It has happened in the past and there is no silver bullet solution to prevent this 100%. -----Original Message----- From: Martin T [mailto:m4rtntns at gmail.com] Sent: Wednesday, 7 August 2013 7:13 PM To: Paul Ferguson Cc: nanog at nanog.org Subject: Re: questions regarding prefix hijacking Ok. And such attacks have happened in the past? For example one could do a pretty widespread damage for at least short period of time if it announces for example some of the root DNS server prefixes(as long prefixes as possible) to it's upstream provider and as upstream provider probably prefers client traffic over it's peerings or upstreams, it will prefer those routes by malicious ISP for all the traffic to root DNS servers? regards, Martin 2013/8/7, Paul Ferguson : > Unfortunately, it is way too easy for people to inject routes into the > global routing system. > > I think most of the folks on the list can attest to that. :-) > > - ferg > > > On Wed, Aug 7, 2013 at 1:20 AM, Martin T wrote: > >> Hi, >> >> as probably many of you know, it's possible to create a "route" >> object to RIPE database for an address space which is allocated >> outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer >> object. For example an address space is from APNIC or ARIN region and >> AS is from RIPE region. For example a LIR in RIPE region creates a >> "route" object to RIPE database for 157.166.266.0/24(used by Turner >> Broadcasting System) prefix without having written permission from >> Turner Broadcasting System and as this LIR uses up-link providers who >> create prefix filters automatically according to RADb database >> entries, this ISP is soon able to announce this 157.166.266.0/24 >> prefix to Internet. This should disturb the availability of the real >> 157.166.266.0/24 network on Internet? Has there been such situations >> in history? Isn't there a method against such hijacking? Or have I >> misunderstood something and this isn't possible? >> >> >> regards, >> Martin >> > > > > -- > "Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > From Jason_Livingood at cable.comcast.com Wed Aug 7 12:38:09 2013 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Wed, 7 Aug 2013 12:38:09 +0000 Subject: Comcast contact In-Reply-To: <5201A600.7080408@houseofzen.org> Message-ID: <10229F86C86EB444898E629583FD4171BDEBFE41@PACDCEXMB06.cable.comcast.com> >I have found Comcast rate shapes or resets long running encrypted >sessions such as https. At $DAYJOB I had to set our SSL VPN system to >re-key via new-tunnels every 5 minutes to keep it under their threshold >of what looks like seven minutes for a tcp session. After that the >sessions appeared to rate shape down to 128kbps. It may also only kick >in during local POP congestion. I am assuming this is DPI trying to do >peer-2-peer mitigation. We don't have such network practices and are required not to under Open Internet rules. I have no idea what was causing your VPN issue - I can use my corporate VPN for hours or days at a time with no issues. Happy to assist off list if you like. Jason From Chad.Reid at apollogrp.edu Wed Aug 7 13:04:14 2013 From: Chad.Reid at apollogrp.edu (Chad Reid) Date: Wed, 7 Aug 2013 06:04:14 -0700 Subject: Comcast contact Message-ID: <4496469827D6CB48A4CE49A3C6602BD4A01A656FA3@EXCH07-02.apollogrp.edu> Andy, I posted in this list earlier in the week regarding Comcast and an issue my company was experiencing. I also posted at www.reddit.com/r/networking. I had numerous support staff from Comcast contact me over on Reddit. I would recommend posting there too. Message: 4 Date: Tue, 6 Aug 2013 11:10:30 -0500 From: Brandon Galbraith To: Andy Ringsmuth Cc: NANOG list Subject: Re: Comcast contact Message-ID: Content-Type: text/plain; charset=UTF-8 Have you monitored your user's home Comcast connection with regards to packet loss or latency, preferably from network-near the SIP termination point? On Tue, Aug 6, 2013 at 10:56 AM, Andy Ringsmuth wrote: > Any chance someone on this list is affiliated with Comcast who could contact me off-list? I have an employee in Virginia who works from home using, in part, a VOIP desk telephone tied into our office phone system back in Nebraska. She's had nothing but problems maintaining a stable connection and I'm at my wit's end to diagnose and fix whatever is causing her problems. > > I've got this exact setup with several employees around the country, but this one person is the only one who, 1 - has problems and 2 - has Comcast. > > Much appreciated! > > ---- > Andy Ringsmuth > andy at newslink.com > News Link ? Manager Technology & Facilities > 2201 Winthrop Rd., Lincoln, NE 68502-4158 > (402) 475-6397 (402) 304-0083 cellular This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. From rayw at rayw.net Wed Aug 7 13:17:34 2013 From: rayw at rayw.net (Ray Wong) Date: Wed, 7 Aug 2013 06:17:34 -0700 Subject: Comcast contact In-Reply-To: <10229F86C86EB444898E629583FD4171BDEBFE41@PACDCEXMB06.cable.comcast.com> References: <5201A600.7080408@houseofzen.org> <10229F86C86EB444898E629583FD4171BDEBFE41@PACDCEXMB06.cable.comcast.com> Message-ID: agreed this isn't the case based on what I've seen based on my latest former employer(s). Comcast is playing by the (generally agreed upon) rules. what I have been seeing is a lot of other route optimizations changing as other providers consolidate routing among latest acquisitions. And of course, there's always the defensive changes also based said changes. constant maintenance and optimizations in recognition of the contracts. it'll sort out, the questions are what's needed to force the issue and, of course, where the standouts end up. -R> On Wed, Aug 7, 2013 at 5:38 AM, Livingood, Jason < Jason_Livingood at cable.comcast.com> wrote: > >I have found Comcast rate shapes or resets long running encrypted > >sessions such as https. At $DAYJOB I had to set our SSL VPN system to > >re-key via new-tunnels every 5 minutes to keep it under their threshold > >of what looks like seven minutes for a tcp session. After that the > >sessions appeared to rate shape down to 128kbps. It may also only kick > >in during local POP congestion. I am assuming this is DPI trying to do > >peer-2-peer mitigation. > > We don't have such network practices and are required not to under Open > Internet rules. I have no idea what was causing your VPN issue - I can use > my corporate VPN for hours or days at a time with no issues. Happy to > assist off list if you like. > > Jason > > > From mshaw at fairpoint.com Wed Aug 7 13:54:32 2013 From: mshaw at fairpoint.com (Shaw, Matthew) Date: Wed, 7 Aug 2013 13:54:32 +0000 Subject: Comcast contact In-Reply-To: <864nb2yx1h.fsf@valhalla.seastrom.com> References: <7602EBBC-4007-4E59-B6CE-E9B8D4B36250@newslink.com> <457F9455036417428963A59E3B38874120252662@0NH1C2P10.fairpoint.com> <864nb2yx1h.fsf@valhalla.seastrom.com> Message-ID: <457F9455036417428963A59E3B388741202531DB@0NH1C2P10.fairpoint.com> I agree it's not a lot of bandwidth, but I was grasping at straws at that point finding out about the cross country VoIP arrangement after the fact. For whatever reason, the 711 calls were full of voice clipping and call drops, 729, (with to your point, the lower MOS) worked better as despite not sounding as good, the calls stopped dropping and people's voices were no longer dropping out. Matt -----Original Message----- From: Rob Seastrom [mailto:rs at seastrom.com] Sent: Tuesday, August 06, 2013 11:56 PM To: Shaw, Matthew Cc: Brandon Galbraith; Andy Ringsmuth; NANOG list Subject: Re: Comcast contact "Shaw, Matthew" writes: > Make sure the remote phone is using a low bandwidth codec too. In a > previous life changing a remote (home) user's phone from G.711 to > G.729 made all the difference in the world to their call quality. i think you've got that backwards. 80 kbit/sec on the wire is not a lot these days, and in a world where we're conditioned to accept gsm or worse, un-transcoded g.711u sounds startlingly good. if you're so short on bandwidth that moving to a 24 kbit/sec on the wire codec makes a difference, you're on the ragged edge of being hosed. -r _______________________________________________________________________ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media. From indra at sg.or.id Wed Aug 7 16:29:45 2013 From: indra at sg.or.id (Indra Pramana) Date: Thu, 8 Aug 2013 00:29:45 +0800 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: One big happening I can recall was the AS7007 incident way back in 1997. http://en.wikipedia.org/wiki/AS_7007_incident Cheers. On Wed, Aug 7, 2013 at 7:23 PM, Ahad Aboss wrote: > It has happened in the past and there is no silver bullet solution to > prevent this 100%. > > > -----Original Message----- > From: Martin T [mailto:m4rtntns at gmail.com] > Sent: Wednesday, 7 August 2013 7:13 PM > To: Paul Ferguson > Cc: nanog at nanog.org > Subject: Re: questions regarding prefix hijacking > > Ok. And such attacks have happened in the past? For example one could do a > pretty widespread damage for at least short period of time if it announces > for example some of the root DNS server prefixes(as long prefixes as > possible) to it's upstream provider and as upstream provider probably > prefers client traffic over it's peerings or upstreams, it will prefer > those routes by malicious ISP for all the traffic to root DNS servers? > > > regards, > Martin > > 2013/8/7, Paul Ferguson : > > Unfortunately, it is way too easy for people to inject routes into the > > global routing system. > > > > I think most of the folks on the list can attest to that. :-) > > > > - ferg > > > > > > On Wed, Aug 7, 2013 at 1:20 AM, Martin T wrote: > > > >> Hi, > >> > >> as probably many of you know, it's possible to create a "route" > >> object to RIPE database for an address space which is allocated > >> outside the RIPE region using the RIPE-NCC-RPSL-MNT maintainer > >> object. For example an address space is from APNIC or ARIN region and > >> AS is from RIPE region. For example a LIR in RIPE region creates a > >> "route" object to RIPE database for 157.166.266.0/24(used by Turner > >> Broadcasting System) prefix without having written permission from > >> Turner Broadcasting System and as this LIR uses up-link providers who > >> create prefix filters automatically according to RADb database > >> entries, this ISP is soon able to announce this 157.166.266.0/24 > >> prefix to Internet. This should disturb the availability of the real > >> 157.166.266.0/24 network on Internet? Has there been such situations > >> in history? Isn't there a method against such hijacking? Or have I > >> misunderstood something and this isn't possible? > >> > >> > >> regards, > >> Martin > >> > > > > > > > > -- > > "Fergie", a.k.a. Paul Ferguson > > fergdawgster(at)gmail.com > > > > From nobleton at fasttrackcomm.net Wed Aug 7 16:41:08 2013 From: nobleton at fasttrackcomm.net (Natambu Obleton) Date: Wed, 7 Aug 2013 10:41:08 -0600 Subject: IPAM Message-ID: <9FFA8B2148100D40969011DAEEB56FD00266C9DF0B30@server.fasttrackcomm.local> I have customer that we deployed Northstar for their internal ip management over 8 yrs ago. They are still using it, but it is slowly breaking on them. Can someone recommend an IPAM solution that has a Northstar import option? They have hundreds of entries detailing customer who was assigned the ip address and I would like to avoid any data massaging. TIA -- Natambu Obleton, CISSP CCIE Senior Network Engineer FastTrack Communications, Inc. 970.828.1009 From Valdis.Kletnieks at vt.edu Wed Aug 7 19:58:26 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 07 Aug 2013 15:58:26 -0400 Subject: questions regarding prefix hijacking In-Reply-To: Your message of "Wed, 07 Aug 2013 03:07:04 -0700." References: Message-ID: <48113.1375905506@turing-police.cc.vt.edu> On Wed, 07 Aug 2013 03:07:04 -0700, Paul Ferguson said: > Having said that, there are quite a few documented cases of it being > done intentionally, and for nefarious purposes. Do I need ECC on my brain to stop the bitrot, or was there a kerfluffle a long ways back when somebody announced 127/8, and a surprising number of systems actually bit? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From maray at microsoft.com Wed Aug 7 20:59:40 2013 From: maray at microsoft.com (Marsh Ray) Date: Wed, 7 Aug 2013 20:59:40 +0000 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: > From: Paul Ferguson > Sent: Wednesday, August 7, 2013 3:07 AM > Subject: Re: questions regarding prefix hijacking > > Historically, most prefix hijacks have been accidental, generally due to > configuration error -- for instance... > > Having said that, there are quite a few documented cases of it being done > intentionally, and for nefarious purposes. It would be incredibly useful for someone to start a page or a category on Wikipedia "List of Internet Routing and DNS Incidents" that would include both "accidental" and malicious events. - Marsh From morrowc.lists at gmail.com Wed Aug 7 21:06:07 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 7 Aug 2013 17:06:07 -0400 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray wrote: > > It would be incredibly useful for someone to start a page or a category on Wikipedia "List of Internet Routing and DNS Incidents" that would include both "accidental" and malicious events. > do we really need that? they seem to occur often enough that that isn't really required :( From philfagan at gmail.com Wed Aug 7 21:31:52 2013 From: philfagan at gmail.com (Phil Fagan) Date: Wed, 7 Aug 2013 15:31:52 -0600 Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts In-Reply-To: <4496469827D6CB48A4CE49A3C6602BD4A01A5CA683@EXCH07-02.apollogrp.edu> References: <4496469827D6CB48A4CE49A3C6602BD4A01A5CA683@EXCH07-02.apollogrp.edu> Message-ID: BGP Noob question here; but wouldn't Time Warner not recieve a prefix if it wasn't reachable? Is this an artifact? On Mon, Aug 5, 2013 at 11:32 AM, Chad Reid wrote: > Thanks for the assistance everyone. This issue was resolved by shutting > down a BGP peering session between Time Warner and Comcast. --Chad > > Chad M. Reid, Network Administrator II > Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) > Apollo Group | IT Services ? IT Operations Center (ITOC) > 4025 S. Riverpoint Parkway ? MS: AA-M002 ? Phoenix, AZ 85040 > phone: 602.557.6746 ? fax: 602.557.6606 ? email: chad.reid at apollogrp.edu > > > -----Original Message----- > From: Chad Reid > Sent: Sunday, August 04, 2013 7:41 AM > To: 'nanog at nanog.org' > Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for > Help or Contacts > > Hello NANOG, > > A few hundred of our users that use Comcast in the South East United > States (other regions aren't affected) are unable to access our websites in > the IP block 204.17.16.0/20. Based upon testing with the users, they're > getting a destination unreachable from a Comcast backbone router in ASN > 7922: > be-16-pe03.56marietta.ga.ibone.comcast.net [68.86.83.134] reports: > Destination net unreachable. > > We're not a customer of Comcast, nor are any of our ISPs. Because of this, > we can't find anyone at Comcast to look at this issue nor do we have good > contact info to even reach someone. Our users in the South East can open > tickets with Comcast technical support, but you can imagine how successful > they are trying to explain this to frontline support and getting frontline > support to understand. > > Is anyone from Comcast on the list that can assist or know of a contact? > > > Chad M. Reid, Network Administrator II > Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) Apollo Group | > IT Services ? IT Operations Center (ITOC) > 4025 S. Riverpoint Parkway ? MS: AA-M002 ? Phoenix, AZ 85040 > phone: 602.557.6746 ? fax: 602.557.6606 ? email: chad.reid at apollogrp.edu > > > > This message is private and confidential. If you have received it in > error, please notify the sender and remove it from your system. > > > > -- Phil Fagan Denver, CO 970-480-7618 From maray at microsoft.com Wed Aug 7 21:47:26 2013 From: maray at microsoft.com (Marsh Ray) Date: Wed, 7 Aug 2013 21:47:26 +0000 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: > From: Christopher Morrow > Sent: Wednesday, August 7, 2013 2:06 PM > > On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray wrote: > > > > It would be incredibly useful for someone to start a page or a category on > Wikipedia "List of Internet Routing and DNS Incidents" that would include > both "accidental" and malicious events. > > do we really need that? Have you ever heard of someone using IP addresses as an access control mechanism? (AKA, "IP whitelist") When I hear about this, I would really *love* to be able to link them to a credible source. > they seem to occur often enough that that isn't really required :( *I* believe you, but in practice that's not sufficient to convince many other folks. Currently, a section of a page on Wikipedia lists 7 incidents going back to 1997. http://en.wikipedia.org/wiki/IP_hijacking#Public_incidents Serious question: Do folks here feel that is an accurate representation of this phenomenon in practice? - Marsh From alexander at neilson.net.nz Wed Aug 7 21:55:11 2013 From: alexander at neilson.net.nz (Alexander Neilson) Date: Thu, 8 Aug 2013 09:55:11 +1200 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: <01F86570-17E7-4037-A351-E0771C0D1B9E@neilson.net.nz> Regards Alexander Alexander Neilson Neilson Productions Limited alexander at neilson.net.nz 021 329 681 022 456 2326 On 8/08/2013, at 9:47 AM, Marsh Ray wrote: >> From: Christopher Morrow >> Sent: Wednesday, August 7, 2013 2:06 PM >> >> On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray wrote: >>> >>> It would be incredibly useful for someone to start a page or a category on >> Wikipedia "List of Internet Routing and DNS Incidents" that would include >> both "accidental" and malicious events. I would see there being a problem with Wikipedia trying to categorise some of them as accidental / malicious. I think if it was done it would have to be list where ones that were publicly announced as accidental would be listed as accidents and the rest left un noted to comply with neutral point of view and verification. >> >> do we really need that? > > Have you ever heard of someone using IP addresses as an access control mechanism? (AKA, "IP whitelist") > > When I hear about this, I would really *love* to be able to link them to a credible source. > >> they seem to occur often enough that that isn't really required :( > > *I* believe you, but in practice that's not sufficient to convince many other folks. > Currently, a section of a page on Wikipedia lists 7 incidents going back to 1997. > http://en.wikipedia.org/wiki/IP_hijacking#Public_incidents > > Serious question: Do folks here feel that is an accurate representation of this phenomenon in practice? I would tend to say as it lists BGPmon.net as an external link thats a good resource for finding out about other ones that have happened. Also maybe that section should be renamed notable incidents and just have it as a sample of some of these incidents. > > - Marsh > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4154 bytes Desc: not available URL: From pdonner at cisco.com Wed Aug 7 22:22:08 2013 From: pdonner at cisco.com (Paul Donner) Date: Wed, 07 Aug 2013 16:22:08 -0600 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: <5202C890.2050008@cisco.com> > It appears AS3549 is announcing 10.0.0.0/8. I noticed it from an > AS3549 customer. > >>From GBLX looking glass, ATL1 > > traceroute > Protocol [ip]: ip > Target IP address: 10.0.0.1 > Source address: > Numeric display [n]: n > Timeout in seconds [3]: 1 > Probe count [3]: 2 > Minimum Time to Live [1]: 1 > Maximum Time to Live [30]: 30 > Port Number [33434]: > Loose, Strict, Record, Timestamp, Verbose[none]: > Type escape sequence to abort. > Tracing the route to 10.0.0.1 > VRF info: (vrf in name/id, vrf out name/id) > 1 te3-1-10G.par9.CTA1.GRU.gblx.net (67.16.142.26) 120 msec 124 msec > 2 122.5.125.189.static.impsat.net.br (189.125.5.122) 120 msec 120 msec > 3 10.0.0.1 [AS 262487] 124 msec 120 msec > > Apparently the customer didn't have proper inbound filter...... > Reply from 10.0.0.1: bytes=32 time=132ms TTL=61 > > On 08/07/2013 02:20 AM, Martin T wrote: > Hi, > > as probably many of you know, it's possible to create a "route" object > to RIPE database for an address space which is allocated outside the > RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example > an address space is from APNIC or ARIN region and AS is from RIPE > region. For example a LIR in RIPE region creates a "route" object to > RIPE database for 157.166.266.0/24(used by Turner Broadcasting System) > prefix without having written permission from Turner Broadcasting > System and as this LIR uses up-link providers who create prefix > filters automatically according to RADb database entries, this ISP is > soon able to announce this 157.166.266.0/24 prefix to Internet. This > should disturb the availability of the real 157.166.266.0/24 network > on Internet? Has there been such situations in history? Isn't there a > method against such hijacking? Or have I misunderstood something and > this isn't possible? > > > regards, > Martin > > From bross at pobox.com Wed Aug 7 22:47:58 2013 From: bross at pobox.com (Brandon Ross) Date: Wed, 7 Aug 2013 18:47:58 -0400 (EDT) Subject: IPAM In-Reply-To: <9FFA8B2148100D40969011DAEEB56FD00266C9DF0B30@server.fasttrackcomm.local> References: <9FFA8B2148100D40969011DAEEB56FD00266C9DF0B30@server.fasttrackcomm.local> Message-ID: On Wed, 7 Aug 2013, Natambu Obleton wrote: > I have customer that we deployed Northstar for their internal ip > management over 8 yrs ago. They are still using it, but it is slowly > breaking on them. Can someone recommend an IPAM solution that has a > Northstar import option? They have hundreds of entries detailing > customer who was assigned the ip address and I would like to avoid any > data massaging. TIA I'm pretty sure that if 6connect doesn't have an existing tool to import Northstar that they'd work with your client to get it done. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From marka at isc.org Thu Aug 8 00:19:01 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 08 Aug 2013 10:19:01 +1000 Subject: questions regarding prefix hijacking In-Reply-To: Your message of "Wed, 07 Aug 2013 21:47:26 +0000." References: Message-ID: <20130808001901.4832B38226EA@drugs.dv.isc.org> In message , Marsh Ray writes: > > From: Christopher Morrow > > Sent: Wednesday, August 7, 2013 2:06 PM > > > > On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray wrote: > > > > > > It would be incredibly useful for someone to start a page or a > > > category on > > > Wikipedia "List of Internet Routing and DNS Incidents" that would > > > include > > > both "accidental" and malicious events. > > > > do we really need that? > > Have you ever heard of someone using IP addresses as an access control > mechanism? (AKA, "IP whitelist") Yes. I've even had to configure my DHCP client to auto generate requests to get the whitelist updated when my ISP gives my cable modem a new address. They are used all the time to allow access to DNS servers. If fact we ship nameservers where the default setting whitelist particular sets of clients (directly connected) by default. > When I hear about this, I would really *love* to be able to link them to > a credible source. > > > they seem to occur often enough that that isn't really required :( > > *I* believe you, but in practice that's not sufficient to convince many > other folks. > Currently, a section of a page on Wikipedia lists 7 incidents going back > to 1997. > http://en.wikipedia.org/wiki/IP_hijacking#Public_incidents > > Serious question: Do folks here feel that is an accurate representation > of this phenomenon in practice? > > - Marsh -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Thu Aug 8 00:20:21 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 08 Aug 2013 10:20:21 +1000 Subject: questions regarding prefix hijacking In-Reply-To: Your message of "Wed, 07 Aug 2013 02:03:45 -0700." References: <20130807085857.GA7561@pob.ytti.fi> Message-ID: <20130808002021.ACCC33822743@drugs.dv.isc.org> In message , Paul Ferguson writes: > On Wed, Aug 7, 2013 at 1:58 AM, Saku Ytti wrote: > > > On (2013-08-07 11:20 +0300), Martin T wrote: > > > >> on Internet? Has there been such situations in history? Isn't there a > >> method against such hijacking? Or have I misunderstood something and > >> this isn't possible? > > > > Certainly practical scenario, but in many cases not needed at all. In most > > cases upstream does not do any automatic prefix filter generation, it's > > maybe somewhat popular in mid-sized european shops but generally not too > > common. > > > > There is active on-going work to secure BGP and you may want to read up on > > 'RPKI' which is further along that track. > > > > I hope it has better adoption than BCP38/BCP84. :-) SIDR should help with BCP38/BCP84 as it allows correct filters to be securely built. Mark > - ferg > > -- > "Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From LarrySheldon at cox.net Thu Aug 8 01:12:14 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 07 Aug 2013 20:12:14 -0500 Subject: questions regarding prefix hijacking In-Reply-To: <9w1F1m0031Una3W01w1LTl> References: <9w1F1m0031Una3W01w1LTl> Message-ID: <5202F06E.5010906@cox.net> On 8/7/2013 2:58 PM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 07 Aug 2013 03:07:04 -0700, Paul Ferguson said: > >> Having said that, there are quite a few documented cases of it being >> done intentionally, and for nefarious purposes. > > Do I need ECC on my brain to stop the bitrot, or was there a kerfluffle a > long ways back when somebody announced 127/8, and a surprising number of > systems actually bit? Seems like that might have been the first time I was annoying the Big Net Operators about why they route unroutable traffic. And a new annoying question: does it seem odd that the Big Net Operator's Private Mailing List is answering such gut basic and old news questions about how do I best destroy the Internet, should I wan t to do that? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From mpetach at netflight.com Thu Aug 8 06:21:38 2013 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 7 Aug 2013 23:21:38 -0700 Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts In-Reply-To: References: <4496469827D6CB48A4CE49A3C6602BD4A01A5CA683@EXCH07-02.apollogrp.edu> Message-ID: On Wed, Aug 7, 2013 at 2:31 PM, Phil Fagan wrote: > BGP Noob question here; but wouldn't Time Warner not recieve a prefix if it > wasn't reachable? Is this an artifact? > In a perfect world, people wouldn't advertise prefixes unless they knew they had reachability for those prefixes. Unfortunately, this a far, far from perfect world. Matt > > > On Mon, Aug 5, 2013 at 11:32 AM, Chad Reid > wrote: > > > Thanks for the assistance everyone. This issue was resolved by shutting > > down a BGP peering session between Time Warner and Comcast. --Chad > > > > Chad M. Reid, Network Administrator II > > Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) > > Apollo Group | IT Services ? IT Operations Center (ITOC) > > 4025 S. Riverpoint Parkway ? MS: AA-M002 ? Phoenix, AZ 85040 > > phone: 602.557.6746 ? fax: 602.557.6606 ? email: chad.reid at apollogrp.edu > > > > > > -----Original Message----- > > From: Chad Reid > > Sent: Sunday, August 04, 2013 7:41 AM > > To: 'nanog at nanog.org' > > Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for > > Help or Contacts > > > > Hello NANOG, > > > > A few hundred of our users that use Comcast in the South East United > > States (other regions aren't affected) are unable to access our websites > in > > the IP block 204.17.16.0/20. Based upon testing with the users, they're > > getting a destination unreachable from a Comcast backbone router in ASN > > 7922: > > be-16-pe03.56marietta.ga.ibone.comcast.net [68.86.83.134] reports: > > Destination net unreachable. > > > > We're not a customer of Comcast, nor are any of our ISPs. Because of > this, > > we can't find anyone at Comcast to look at this issue nor do we have good > > contact info to even reach someone. Our users in the South East can open > > tickets with Comcast technical support, but you can imagine how > successful > > they are trying to explain this to frontline support and getting > frontline > > support to understand. > > > > Is anyone from Comcast on the list that can assist or know of a contact? > > > > > > Chad M. Reid, Network Administrator II > > Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) Apollo Group | > > IT Services ? IT Operations Center (ITOC) > > 4025 S. Riverpoint Parkway ? MS: AA-M002 ? Phoenix, AZ 85040 > > phone: 602.557.6746 ? fax: 602.557.6606 ? email: chad.reid at apollogrp.edu > > > > > > > > This message is private and confidential. If you have received it in > > error, please notify the sender and remove it from your system. > > > > > > > > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 > > From humbertogaliza at gmail.com Thu Aug 8 10:25:20 2013 From: humbertogaliza at gmail.com (Humberto Galiza) Date: Thu, 8 Aug 2013 07:25:20 -0300 Subject: Strange entries from AS1 in global table In-Reply-To: References: Message-ID: Looking at our routers I can see this: 3549 3356 26114 1 i 12956 1239 23520 23383 1 ? but neither 26114 or 23383 are Brazilian ISP?s. Anyway, I guess it?s probably leaked routes or even use of AS 1 as private one (I don?t think level3 guys are using this AS anymore...). Cheers, Humberto Galiza 2013/8/4 Anurag Bhatia : > Hello everyone > > > I was looking at global IPv4 table and saw some strange entries from AS1. > As per ARIN whois AS1 seems to be with Level3 but I noticed few prefixes of > Brazil based ISP - Netvip > > > http://bgp.he.net/AS1#_prefixes > > > > Looking at any prefix in detail, it seems like there are multiple ASNs > announcing same prefix. > > E.g 177.185.96.0/24 - is being announced by AS1 as well as AS52931 > (Netvip's allocated ASN). Same is true with 177.185.98.0/24, > 177.185.98.0/24and so on. > http://bgp.he.net/net/177.185.96.0/24 > > So seems like AS1 acting like a mirror for all announcements of AS52931. To > see who exactly gave "transit" to AS1 by Netvip in Brazil, I checked Oregon > and noticed these routes: > > 3356 3549 16735 52931 1 i > > > > Seems like AS52931 itself is acting as transit for AS1 (and AS16735 which > seems like a backbone ISP in Brazil) is not filtering these routes further > passing to Level3 (AS3549+AS3356). > > > > I am curious to know what could be possible reason for an ASN like AS1 > acting in exact mirror of AS52931? Could it be a case of internal use of > AS1 (assuming it to be private ASN)? May be it's a case of leaked internal > routes? > > > > Appreciate your time & answer. > > > > Thanks. > > -- > > Anurag Bhatia > anuragbhatia.com > > Linkedin | > Twitter > Skype: anuragbhatia.com From carlosm3011 at gmail.com Thu Aug 8 14:06:54 2013 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Thu, 8 Aug 2013 11:06:54 -0300 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: They do happen, but they get little publicity. People that I've talked to about this say, for reasons mostly unspecified, they'd rather not talk about it. On Wed, Aug 7, 2013 at 6:06 PM, Christopher Morrow wrote: > On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray wrote: > > > > It would be incredibly useful for someone to start a page or a category > on Wikipedia "List of Internet Routing and DNS Incidents" that would > include both "accidental" and malicious events. > > > > do we really need that? they seem to occur often enough that that > isn't really required :( > > -- -- ========================= Carlos M. Martinez-Cagnazzo h ttp://cagnazzo.me ========================= From Vinny_Abello at Dell.com Thu Aug 8 14:46:18 2013 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Thu, 8 Aug 2013 14:46:18 +0000 Subject: Strange entries from AS1 in global table In-Reply-To: References: Message-ID: Level 3 currently uses AS 1 in their MPLS network. I'm unsure if it's used elsewhere, but AS 1 could get into the AS paths of prefixes in the global routing table this way. I wouldn't expect to see it originating routes outside of the WAN interface for customers though and those are typically way too small to make it into the global routing table. -Vinny -----Original Message----- From: Humberto Galiza [mailto:humbertogaliza at gmail.com] Sent: Thursday, August 08, 2013 6:25 AM To: Anurag Bhatia Cc: NANOG Mailing List Subject: Re: Strange entries from AS1 in global table Looking at our routers I can see this: 3549 3356 26114 1 i 12956 1239 23520 23383 1 ? but neither 26114 or 23383 are Brazilian ISP?s. Anyway, I guess it?s probably leaked routes or even use of AS 1 as private one (I don?t think level3 guys are using this AS anymore...). Cheers, Humberto Galiza 2013/8/4 Anurag Bhatia : > Hello everyone > > > I was looking at global IPv4 table and saw some strange entries from AS1. > As per ARIN whois AS1 seems to be with Level3 but I noticed few prefixes of > Brazil based ISP - Netvip > > > http://bgp.he.net/AS1#_prefixes > > > > Looking at any prefix in detail, it seems like there are multiple ASNs > announcing same prefix. > > E.g 177.185.96.0/24 - is being announced by AS1 as well as AS52931 > (Netvip's allocated ASN). Same is true with 177.185.98.0/24, > 177.185.98.0/24and so on. > http://bgp.he.net/net/177.185.96.0/24 > > So seems like AS1 acting like a mirror for all announcements of AS52931. To > see who exactly gave "transit" to AS1 by Netvip in Brazil, I checked Oregon > and noticed these routes: > > 3356 3549 16735 52931 1 i > > > > Seems like AS52931 itself is acting as transit for AS1 (and AS16735 which > seems like a backbone ISP in Brazil) is not filtering these routes further > passing to Level3 (AS3549+AS3356). > > > > I am curious to know what could be possible reason for an ASN like AS1 > acting in exact mirror of AS52931? Could it be a case of internal use of > AS1 (assuming it to be private ASN)? May be it's a case of leaked internal > routes? > > > > Appreciate your time & answer. > > > > Thanks. > > -- > > Anurag Bhatia > anuragbhatia.com > > Linkedin | > Twitter > Skype: anuragbhatia.com From m4rtntns at gmail.com Thu Aug 8 14:48:31 2013 From: m4rtntns at gmail.com (Martin T) Date: Thu, 8 Aug 2013 17:48:31 +0300 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: Saku, > In most cases upstream does not do any automatic prefix filter generation, it's maybe somewhat popular in mid-sized european shops but generally not too common. What do you mean? In most cases upstreams do not filter prefixes at all? > There is active on-going work to secure BGP and you may want to read up on 'RPKI' which is further along that track. Thanks for mentioning this! Very interesting effort. I validated some routes in LIR portal, verified that those are validated using RIPE rpki-validator tool and a Juniper router connected to validator: rpki at lr1.ham1.de> show validation session detail Session 195.13.63.18, State: up, Session index: 2 Group: eurotransit-testbed, Preference: 100 Local IPv4 address: 193.34.50.25, Port: 8282 Refresh time: 120s Hold time: 180s Record Life time: 3600s Serial (Full Update): 559 Serial (Incremental Update): 559 Session flaps: 0 Session uptime: 00:11:35 Last PDU received: 00:00:27 IPv4 prefix count: 4921 IPv6 prefix count: 833 rpki at lr1.ham1.de> show route protocol bgp 5.11.81.0 inet.0: 456407 destinations, 456408 routes (456407 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 5.11.81.0/24 *[BGP/170] 00:11:59, localpref 110, from 79.141.168.1 AS path: 33926 25577 43532 I, validation-state: valid > to 193.34.50.1 via em0.0 RPKI-valid.inet.0: 11440 destinations, 11440 routes (11440 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 5.11.81.0/24 *[BGP/170] 00:11:11, localpref 110, from 79.141.168.1 AS path: 33926 25577 43532 I, validation-state: valid > to 193.34.50.1 via em0.0 rpki at lr1.ham1.de> Massimiliano, Paul, Indra: thanks for pointing out those interesting cases! regards, Martin 2013/8/8, Carlos Martinez-Cagnazzo : > They do happen, but they get little publicity. People that I've talked to > about this say, for reasons mostly unspecified, they'd rather not talk > about it. > > > On Wed, Aug 7, 2013 at 6:06 PM, Christopher Morrow > wrote: > >> On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray wrote: >> > >> > It would be incredibly useful for someone to start a page or a category >> on Wikipedia "List of Internet Routing and DNS Incidents" that would >> include both "accidental" and malicious events. >> > >> >> do we really need that? they seem to occur often enough that that >> isn't really required :( >> >> > > > -- > -- > ========================= > Carlos M. Martinez-Cagnazzo > h ttp://cagnazzo.me > ========================= > From bdflemin at gmail.com Thu Aug 8 14:48:46 2013 From: bdflemin at gmail.com (Brad Fleming) Date: Thu, 8 Aug 2013 09:48:46 -0500 Subject: Strange entries from AS1 in global table In-Reply-To: References: Message-ID: <15AC4C89-E85E-40B4-B72B-77691E822102@gmail.com> I think Level(3) uses it for at least some L3 MPLS VPN stuff. We peer with that AS for dedicated SIP service transport for example. On Aug 8, 2013, at 5:25 AM, Humberto Galiza wrote: > Looking at our routers I can see this: > 3549 3356 26114 1 i > 12956 1239 23520 23383 1 ? > > but neither 26114 or 23383 are Brazilian ISP?s. Anyway, I guess it?s > probably leaked routes or even use of AS 1 as private one (I don?t > think level3 guys are using this AS anymore...). > > Cheers, > Humberto Galiza > > > 2013/8/4 Anurag Bhatia : >> Hello everyone >> >> >> I was looking at global IPv4 table and saw some strange entries from AS1. >> As per ARIN whois AS1 seems to be with Level3 but I noticed few prefixes of >> Brazil based ISP - Netvip >> >> >> http://bgp.he.net/AS1#_prefixes >> >> >> >> Looking at any prefix in detail, it seems like there are multiple ASNs >> announcing same prefix. >> >> E.g 177.185.96.0/24 - is being announced by AS1 as well as AS52931 >> (Netvip's allocated ASN). Same is true with 177.185.98.0/24, >> 177.185.98.0/24and so on. >> http://bgp.he.net/net/177.185.96.0/24 >> >> So seems like AS1 acting like a mirror for all announcements of AS52931. To >> see who exactly gave "transit" to AS1 by Netvip in Brazil, I checked Oregon >> and noticed these routes: >> >> 3356 3549 16735 52931 1 i >> >> >> >> Seems like AS52931 itself is acting as transit for AS1 (and AS16735 which >> seems like a backbone ISP in Brazil) is not filtering these routes further >> passing to Level3 (AS3549+AS3356). >> >> >> >> I am curious to know what could be possible reason for an ASN like AS1 >> acting in exact mirror of AS52931? Could it be a case of internal use of >> AS1 (assuming it to be private ASN)? May be it's a case of leaked internal >> routes? >> >> >> >> Appreciate your time & answer. >> >> >> >> Thanks. >> >> -- >> >> Anurag Bhatia >> anuragbhatia.com >> >> Linkedin | >> Twitter >> Skype: anuragbhatia.com > From saku at ytti.fi Thu Aug 8 14:59:47 2013 From: saku at ytti.fi (Saku Ytti) Date: Thu, 8 Aug 2013 17:59:47 +0300 Subject: questions regarding prefix hijacking In-Reply-To: References: Message-ID: <20130808145947.GA31278@pob.ytti.fi> On (2013-08-08 17:48 +0300), Martin T wrote: > > In most cases upstream does not do any automatic prefix filter generation, it's maybe somewhat popular in mid-sized european shops but generally not too common. > > What do you mean? In most cases upstreams do not filter prefixes at all? Exactly. Source data has usually low quality and even even data is high quality for many organization it's very complex task. Internet does not have very good MTBF what we are pretty good at is MTTR. -- ++ytti From ttauber at 1-4-5.net Thu Aug 8 16:39:44 2013 From: ttauber at 1-4-5.net (Tony Tauber) Date: Thu, 8 Aug 2013 12:39:44 -0400 Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts In-Reply-To: References: <4496469827D6CB48A4CE49A3C6602BD4A01A5CA683@EXCH07-02.apollogrp.edu> Message-ID: It's a fair question and had nothing to do with the other network (TW Telecom, in this case, not TIme Warner Cable). Sorry for not filling in details sooner. We recently needed to adjust the scale profile on some of our Cisco ASR9k trident chip (80gig) Line Cards as we reached . The default profile only supports up to 512k routes and will notify that CEF has run out of DATA_TYPE_TABLE_SET space as a result. The profile change required (profile 13) requires a reload of the chassis. please be advised. You might want to review with your local support team. The symptom involved BGP neighbor instability and unreachability of some destinations. Shutting down that particular BGP session was a temporary work-around until the adjustment could be made during a demand maintenance window to minimize disruption. Thanks, Tony On Wed, Aug 7, 2013 at 5:31 PM, Phil Fagan wrote: > BGP Noob question here; but wouldn't Time Warner not recieve a prefix if it > wasn't reachable? Is this an artifact? > > > On Mon, Aug 5, 2013 at 11:32 AM, Chad Reid > wrote: > > > Thanks for the assistance everyone. This issue was resolved by shutting > > down a BGP peering session between Time Warner and Comcast. --Chad > > > > Chad M. Reid, Network Administrator II > > Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) > > Apollo Group | IT Services ? IT Operations Center (ITOC) > > 4025 S. Riverpoint Parkway ? MS: AA-M002 ? Phoenix, AZ 85040 > > phone: 602.557.6746 ? fax: 602.557.6606 ? email: chad.reid at apollogrp.edu > > > > > > -----Original Message----- > > From: Chad Reid > > Sent: Sunday, August 04, 2013 7:41 AM > > To: 'nanog at nanog.org' > > Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for > > Help or Contacts > > > > Hello NANOG, > > > > A few hundred of our users that use Comcast in the South East United > > States (other regions aren't affected) are unable to access our websites > in > > the IP block 204.17.16.0/20. Based upon testing with the users, they're > > getting a destination unreachable from a Comcast backbone router in ASN > > 7922: > > be-16-pe03.56marietta.ga.ibone.comcast.net [68.86.83.134] reports: > > Destination net unreachable. > > > > We're not a customer of Comcast, nor are any of our ISPs. Because of > this, > > we can't find anyone at Comcast to look at this issue nor do we have good > > contact info to even reach someone. Our users in the South East can open > > tickets with Comcast technical support, but you can imagine how > successful > > they are trying to explain this to frontline support and getting > frontline > > support to understand. > > > > Is anyone from Comcast on the list that can assist or know of a contact? > > > > > > Chad M. Reid, Network Administrator II > > Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) Apollo Group | > > IT Services ? IT Operations Center (ITOC) > > 4025 S. Riverpoint Parkway ? MS: AA-M002 ? Phoenix, AZ 85040 > > phone: 602.557.6746 ? fax: 602.557.6606 ? email: chad.reid at apollogrp.edu > > > > > > > > This message is private and confidential. If you have received it in > > error, please notify the sender and remove it from your system. > > > > > > > > > > > -- > Phil Fagan > Denver, CO > 970-480-7618 > From jared at puck.nether.net Thu Aug 8 17:29:30 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 8 Aug 2013 13:29:30 -0400 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: <20130801063151.GA16879@pob.ytti.fi> References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> Message-ID: <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> On Aug 1, 2013, at 2:31 AM, Saku Ytti wrote: > On (2013-07-31 17:07 -0700), bottiger wrote: > >> But realistically those 2 problems are not going to be solved any time >> in the next decade. I have tested 7 large hosting networks only one of >> them had BCP38. > > I wonder if it's truly that unrealistic. If we target access networks, it > seems impractical target. > > We have about 40k origin only ASNs and about 7k ASNs which offer transit, > who could arguably trivially ACL those 40k peers. > > If we truly tried, as a community to make deploying these ACLs easy and > actively reach out those 7k ASNs and offer help, would it be unrealistic to > have ACL deployed to sufficiently large portion of networks to make > spoofing impractical/expensive? The following is a sorted list from worst to best of networks that allow spoofing: (cutoff here is 25k) (full list - http://openresolverproject.org/full-spoofer-asn-list-201307.txt ) Count ASN# ------------ 1323950 3462 1300938 4134 1270046 8151 1213972 9737 851124 22927 706434 45899 532546 3816 497303 1267 487965 17974 486882 4837 433170 9829 425991 18403 422356 19429 406870 24560 378440 4766 357974 6697 341044 6147 332602 18881 251074 7303 238461 9318 221201 4812 217794 7418 213049 17552 181995 7552 159078 13489 153877 9299 142740 7738 138730 209 120860 8452 118506 46606 117700 14420 107600 17813 101967 36947 98708 6400 93526 36351 92471 4788 89976 9198 88570 11556 81665 9050 81624 27695 80837 13354 80415 701 79032 6332 78164 4808 77937 55430 75800 2554 65618 9394 63992 4713 60380 9808 59274 6057 55177 8400 53862 9269 53266 13285 51620 9329 50822 22833 50320 16276 49847 23752 48998 4780 48278 31549 47195 8167 46484 10299 46270 21844 43439 26599 43211 32475 43048 36444 41688 27668 35448 24863 34160 27866 33068 26496 32166 14754 31656 2379 31450 32613 30641 27699 29225 45951 28804 6389 27836 56040 27406 5617 26758 39501 26454 24940 26175 13999 25736 7018 25482 131090 25478 1221 From mpetach at netflight.com Thu Aug 8 17:40:19 2013 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 8 Aug 2013 10:40:19 -0700 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> Message-ID: On Thu, Aug 8, 2013 at 10:29 AM, Jared Mauch wrote: > > On Aug 1, 2013, at 2:31 AM, Saku Ytti wrote: > > > On (2013-07-31 17:07 -0700), bottiger wrote: > > > >> But realistically those 2 problems are not going to be solved any time > >> in the next decade. I have tested 7 large hosting networks only one of > >> them had BCP38. > > > > I wonder if it's truly that unrealistic. If we target access networks, it > > seems impractical target. > > > > We have about 40k origin only ASNs and about 7k ASNs which offer transit, > > who could arguably trivially ACL those 40k peers. > > > > If we truly tried, as a community to make deploying these ACLs easy and > > actively reach out those 7k ASNs and offer help, would it be unrealistic > to > > have ACL deployed to sufficiently large portion of networks to make > > spoofing impractical/expensive? > > The following is a sorted list from worst to best of networks that allow > spoofing: (cutoff here is 25k) > > (full list - > http://openresolverproject.org/full-spoofer-asn-list-201307.txt ) > > > Count ASN# > ------------ > 1323950 3462 > 1300938 4134 > 1270046 8151 > 1213972 9737 ... For the technically clueless among us... what does "count" refer to in this output? How many times you were able to spoof an address through them? How many different addresses you could spoof through them? How many spoofed packets made it through before being blocked? It's kinda hard to know what the list represents without a bit of explanation around it. ^_^; Thanks! :) Matt From jared at puck.nether.net Thu Aug 8 17:45:03 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 8 Aug 2013 13:45:03 -0400 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> Message-ID: On Aug 8, 2013, at 1:40 PM, Matthew Petach wrote: > > > On Thu, Aug 8, 2013 at 10:29 AM, Jared Mauch wrote: > > On Aug 1, 2013, at 2:31 AM, Saku Ytti wrote: > > > On (2013-07-31 17:07 -0700), bottiger wrote: > > > >> But realistically those 2 problems are not going to be solved any time > >> in the next decade. I have tested 7 large hosting networks only one of > >> them had BCP38. > > > > I wonder if it's truly that unrealistic. If we target access networks, it > > seems impractical target. > > > > We have about 40k origin only ASNs and about 7k ASNs which offer transit, > > who could arguably trivially ACL those 40k peers. > > > > If we truly tried, as a community to make deploying these ACLs easy and > > actively reach out those 7k ASNs and offer help, would it be unrealistic to > > have ACL deployed to sufficiently large portion of networks to make > > spoofing impractical/expensive? > > The following is a sorted list from worst to best of networks that allow spoofing: (cutoff here is 25k) > > (full list - http://openresolverproject.org/full-spoofer-asn-list-201307.txt ) > > > Count ASN# > ------------ > 1323950 3462 > 1300938 4134 > 1270046 8151 > 1213972 9737 > ... > > For the technically clueless among us... > > what does "count" refer to in this output? > How many times you were able to spoof > an address through them? How many > different addresses you could spoof through > them? How many spoofed packets made it > through before being blocked? > > It's kinda hard to know what the list > represents without a bit of explanation > around it. ^_^; Number of unique IPs that spoofed a packet to me. (eg: I sent a packet to 1.2.3.4 and 5.6.7.8 responded). If those ASNs are downstream to you, or you are part of that ASN, you can ask for a list of the IPs involved. Either way, if you have 1.2 million hosts, it may be a lot of BCP38 you need to apply. - Jared From ikiris at gmail.com Thu Aug 8 17:46:10 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 8 Aug 2013 12:46:10 -0500 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> Message-ID: I noticed that two of my ASNs are on that list for example with low numbers. I can't fathom how as at least one of them has uRPF implemented on any actual interfaces and no downstreams/peers. -Blake On Thu, Aug 8, 2013 at 12:40 PM, Matthew Petach wrote: > On Thu, Aug 8, 2013 at 10:29 AM, Jared Mauch > wrote: > > > > > On Aug 1, 2013, at 2:31 AM, Saku Ytti wrote: > > > > > On (2013-07-31 17:07 -0700), bottiger wrote: > > > > > >> But realistically those 2 problems are not going to be solved any time > > >> in the next decade. I have tested 7 large hosting networks only one of > > >> them had BCP38. > > > > > > I wonder if it's truly that unrealistic. If we target access networks, > it > > > seems impractical target. > > > > > > We have about 40k origin only ASNs and about 7k ASNs which offer > transit, > > > who could arguably trivially ACL those 40k peers. > > > > > > If we truly tried, as a community to make deploying these ACLs easy and > > > actively reach out those 7k ASNs and offer help, would it be > unrealistic > > to > > > have ACL deployed to sufficiently large portion of networks to make > > > spoofing impractical/expensive? > > > > The following is a sorted list from worst to best of networks that allow > > spoofing: (cutoff here is 25k) > > > > (full list - > > http://openresolverproject.org/full-spoofer-asn-list-201307.txt ) > > > > > > > Count ASN# > > ------------ > > 1323950 3462 > > 1300938 4134 > > 1270046 8151 > > 1213972 9737 > > ... > > For the technically clueless among us... > > what does "count" refer to in this output? > How many times you were able to spoof > an address through them? How many > different addresses you could spoof through > them? How many spoofed packets made it > through before being blocked? > > It's kinda hard to know what the list > represents without a bit of explanation > around it. ^_^; > > Thanks! :) > > Matt > From jared at puck.nether.net Thu Aug 8 17:51:05 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 8 Aug 2013 13:51:05 -0400 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> Message-ID: Oops, I pulled the wrong data (off by one column) out before a trip and didn't realize it until now. This is not the spoofer list, but the list of ASNs with open resolvers. Let me reprocess it. Apologies, corrected data being generated. - Jared On Aug 8, 2013, at 1:29 PM, Jared Mauch wrote: > The following is a sorted list from worst to best of networks that allow spoofing: (cutoff here is 25k) > > (full list - http://openresolverproject.org/full-spoofer-asn-list-201307.txt ) From Valdis.Kletnieks at vt.edu Thu Aug 8 17:52:42 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 08 Aug 2013 13:52:42 -0400 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: Your message of "Thu, 08 Aug 2013 12:46:10 -0500." References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> Message-ID: <60902.1375984362@turing-police.cc.vt.edu> On Thu, 08 Aug 2013 12:46:10 -0500, Blake Dunlap said: > I noticed that two of my ASNs are on that list for example with low > numbers. I can't fathom how as at least one of them has uRPF implemented on > any actual interfaces and no downstreams/peers. Most likely, you have places where one host in a /24 or /28 can spoof a packet claiming to be another host in the same subnet, and have the spoofed packet escape into the outside world. There's really no way to stop that unless you get *really* fascist with your edge-host facing routers/switches. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From ikiris at gmail.com Thu Aug 8 18:07:56 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 8 Aug 2013 13:07:56 -0500 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> Message-ID: On a related note, how are you actually getting this data? What you have said previously ( Number of unique IPs that spoofed a packet to me. (eg: I sent a packet to 1.2.3.4 and 5.6.7.8 responded). ) doesn't even make sense. -Blake On Thu, Aug 8, 2013 at 12:51 PM, Jared Mauch wrote: > Oops, I pulled the wrong data (off by one column) out before a trip and > didn't realize it until now. > > This is not the spoofer list, but the list of ASNs with open resolvers. > > Let me reprocess it. > > Apologies, corrected data being generated. > > - Jared > > On Aug 8, 2013, at 1:29 PM, Jared Mauch wrote: > > > The following is a sorted list from worst to best of networks that allow > spoofing: (cutoff here is 25k) > > > > (full list - > http://openresolverproject.org/full-spoofer-asn-list-201307.txt ) > > > From jared at puck.nether.net Thu Aug 8 18:36:02 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 8 Aug 2013 14:36:02 -0400 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> Message-ID: <09BF635C-4C69-41AE-A5AE-E047CA55DA3B@puck.nether.net> All, Here's the correct list, apologies for the confusion. http://openresolverproject.org/spoofers-20130804-byasn-count.txt Top ASN excerpt: Count ASN ---------------- 46024 5617 43729 9394 28358 17964 27923 3269 24323 12874 22726 4847 22690 286 1136 21541 6079 20380 20825 11538 17430 10657 7497 17430 10544 4766 9883 7497 9061 3462 8875 38208 8553 7385 8295 4812 7297 11830 7204 7029 7137 3215 6655 6854 6618 4788 6424 17621 5794 53173 5069 8452 4944 9808 4930 6830 4877 38511 4648 4134 4135 2856 3982 9340 3678 6805 3605 38235 3398 17816 3364 9299 3297 9812 3238 15003 3221 9116 3025 4565 On Aug 8, 2013, at 1:51 PM, Jared Mauch wrote: > Oops, I pulled the wrong data (off by one column) out before a trip and didn't realize it until now. > > This is not the spoofer list, but the list of ASNs with open resolvers. > > Let me reprocess it. > > Apologies, corrected data being generated. > > - Jared > > On Aug 8, 2013, at 1:29 PM, Jared Mauch wrote: > >> The following is a sorted list from worst to best of networks that allow spoofing: (cutoff here is 25k) >> >> (full list - http://openresolverproject.org/full-spoofer-asn-list-201307.txt ) > From mksmith at mac.com Thu Aug 8 18:48:12 2013 From: mksmith at mac.com (Michael Smith) Date: Thu, 08 Aug 2013 11:48:12 -0700 Subject: 2013 NANOG Board - Call for Nominations Message-ID: <8EDB7742-75D7-4991-B422-BCACF7E054BC@mac.com> Dear NANOGers, Hope you are enjoying this great Summer. Following our July 15, 2013 posting ??Announcing the October 2013 NANOG Elections? which provided a preview into our election process, on behalf of the Board and 2013 Elections Committee, we are pleased to open the Call for Board Member Nominations for the three vacant positions on the Board of Directors. The nomination period starts August 9 and closes September 20, 2013 at 23:59 Pacific Standard Time. If you are nominating another person, please send that person's name and email address to elections at nanog.org and we will contact them to acknowledge their willingness to stand and will ask them to submit their Declaration of Candidacy Form, found under the2013 Elections Main Menu. If you are nominating yourself, please submit your Declaration of Candidacy Form and email it to elections at nanog.org. Below is the summary of the Board Member role and a detailed description is viewable on our NANOG website. ************************************ Position: Board Member Time commitment: Five hours per week (meetings, preparation, consultation) for Members or Eight hours per week (meetings, preparation, consultation) for Officers (Chair, Vice Chair, Secretary, Treasurer). Term: Two years. Maximum of two consecutive terms. Accountability The Board of Directors are collectively accountable to the community, sponsors and other stakeholders. They are accountable for NANOG?s performance in relation to its mission and strategic objectives and for the effective stewardship of financial and human resources. Authority Individual board members have no authority to approve actions by NANOG, to direct staff, or to speak on behalf for NANOG, unless given such authority by the board. Responsibility Board members are responsible for acting in the best long-term interests of the organization and its community and will bring to the task of informed decision-making, a broad knowledge and an inclusive perspective. General Duties Every member of the Board of Directors is expected to do the following: ? Be a NANOG member in good standing ? Prepare for and attend board meetings every fortnight ? Work as a team member and support board decisions ? Participate in the review of NANOG?s mission and objectives and the development of a strategic plan ? Monitor the performance of the organization in relation to objectives and core values ? Approve the budget and monitor financial performance in relation to it ? Abide by the by-laws, code of conduct and other policies that apply to the board ? Establish, review and monitor policies that guide core operational practices (eg. financial management, human resource management) ? Participate in hiring and releasing the Executive Director ? Participate in the evaluation of the Executive Director ? Participate in the recruitment of new board members ? Participate in the evaluation of the board itself ? Participate in committee work (liaison) ? Appoint Standing committees members ? Appoint Ad-Hoc committees members. ? Attend two out of every three NANOG conferences ? Keep informed about community issues relevant to the mission and objectives of NANOG Qualifications The following are considered key job qualifications: ? Knowledge of the community ? Experience in or willingness to participate in the governance of a non-profit organization ? Demonstrated aptitudes for financial management ? Leadership, outreach and communication skills ? Commitment to organization?s mission and strategic directions ? A commitment of time ? Consensus organizing and openness to learning Removal of a Board Member A Board of Directors member who misses three or more meetings in a row and who does not attend any Board of Directors meetings for three months may be removed. ************************************ The Board of Directors is an active and engaged component of NANOG. As NANOG continues to evolve, our Board and our Committees will continue to play an increasingly important role in our success. We thank you in advance for becoming NANOG members and taking an active part in our governance. Should you have any questions, please feel free to send the elections at nanog.org. Best regards Michael K. Smith Vice Chair, NANOG Board of Directors From sander at steffann.nl Thu Aug 8 19:56:44 2013 From: sander at steffann.nl (Sander Steffann) Date: Thu, 8 Aug 2013 21:56:44 +0200 Subject: IPAM In-Reply-To: References: <9FFA8B2148100D40969011DAEEB56FD00266C9DF0B30@server.fasttrackcomm.local> Message-ID: Hi, > I'm pretty sure that if 6connect doesn't have an existing tool to import Northstar that they'd work with your client to get it done. +1 on 6connect. Very helpful people there :-) Sander From jared at puck.nether.net Thu Aug 8 20:37:11 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 8 Aug 2013 16:37:11 -0400 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> Message-ID: On Aug 8, 2013, at 2:07 PM, Blake Dunlap wrote: > On a related note, how are you actually getting this data? Sure: https://www.nanog.org/sites/default/files/tue.lightning3.open_resolver.mauch_.pdf I would point you at the streaming archive, but I'm not sure where they went. Perhaps they can post them to Youtube? Anyways, the alternate set of IPs responding is actually increasing over time: http://openresolverproject.org/breakdown-graph2.cgi > What you have said previously ( Number of unique IPs that spoofed a packet to me. (eg: I sent a packet to 1.2.3.4 and 5.6.7.8 responded). ) doesn't even make sense. Many CPE devices will perform NAT on udp/53 packets received on their WAN interface and forward them to their configured DNS server. Some will just take the source IP and copy it into the packet. Because it comes in on their WAN interface, it will instead of copying the inside NAT address just copy my source IP from the weekly scan and use that. Since it's on the outside, it doesn't copy it's outside IP and put that in, it copies mine. - Jared > On Thu, Aug 8, 2013 at 12:51 PM, Jared Mauch wrote: > Oops, I pulled the wrong data (off by one column) out before a trip and didn't realize it until now. > > This is not the spoofer list, but the list of ASNs with open resolvers. > > Let me reprocess it. > > Apologies, corrected data being generated. > > - Jared > > On Aug 8, 2013, at 1:29 PM, Jared Mauch wrote: > > > The following is a sorted list from worst to best of networks that allow spoofing: (cutoff here is 25k) > > > > (full list - http://openresolverproject.org/full-spoofer-asn-list-201307.txt ) > > > From james.sink at freedomvoice.com Thu Aug 8 20:40:28 2013 From: james.sink at freedomvoice.com (James Sink) Date: Thu, 8 Aug 2013 20:40:28 +0000 Subject: Strange entries from AS1 in global table In-Reply-To: <15AC4C89-E85E-40B4-B72B-77691E822102@gmail.com> References: <15AC4C89-E85E-40B4-B72B-77691E822102@gmail.com> Message-ID: That's correct, I have seen L3 use that for MPLS as recently as a few months ago. -James -----Original Message----- From: Brad Fleming [mailto:bdflemin at gmail.com] Sent: Thursday, August 08, 2013 7:49 AM To: Humberto Galiza Cc: NANOG Mailing List Subject: Re: Strange entries from AS1 in global table I think Level(3) uses it for at least some L3 MPLS VPN stuff. We peer with that AS for dedicated SIP service transport for example. On Aug 8, 2013, at 5:25 AM, Humberto Galiza wrote: > Looking at our routers I can see this: > 3549 3356 26114 1 i > 12956 1239 23520 23383 1 ? > > but neither 26114 or 23383 are Brazilian ISP?s. Anyway, I guess it?s > probably leaked routes or even use of AS 1 as private one (I don?t > think level3 guys are using this AS anymore...). > > Cheers, > Humberto Galiza > > > 2013/8/4 Anurag Bhatia : >> Hello everyone >> >> >> I was looking at global IPv4 table and saw some strange entries from AS1. >> As per ARIN whois AS1 seems to be with Level3 but I noticed few >> prefixes of Brazil based ISP - Netvip >> >> >> http://bgp.he.net/AS1#_prefixes >> >> >> >> Looking at any prefix in detail, it seems like there are multiple >> ASNs announcing same prefix. >> >> E.g 177.185.96.0/24 - is being announced by AS1 as well as AS52931 >> (Netvip's allocated ASN). Same is true with 177.185.98.0/24, >> 177.185.98.0/24and so on. >> http://bgp.he.net/net/177.185.96.0/24 >> >> So seems like AS1 acting like a mirror for all announcements of >> AS52931. To see who exactly gave "transit" to AS1 by Netvip in >> Brazil, I checked Oregon and noticed these routes: >> >> 3356 3549 16735 52931 1 i >> >> >> >> Seems like AS52931 itself is acting as transit for AS1 (and AS16735 >> which seems like a backbone ISP in Brazil) is not filtering these >> routes further passing to Level3 (AS3549+AS3356). >> >> >> >> I am curious to know what could be possible reason for an ASN like >> AS1 acting in exact mirror of AS52931? Could it be a case of internal >> use of >> AS1 (assuming it to be private ASN)? May be it's a case of leaked >> internal routes? >> >> >> >> Appreciate your time & answer. >> >> >> >> Thanks. >> >> -- >> >> Anurag Bhatia >> anuragbhatia.com >> >> Linkedin | >> Twitter >> Skype: anuragbhatia.com > From ikiris at gmail.com Fri Aug 9 01:13:56 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 8 Aug 2013 20:13:56 -0500 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> Message-ID: Thanks, this is quite interesting. I never would have expected that kind of behavior. -Blake On Thu, Aug 8, 2013 at 3:37 PM, Jared Mauch wrote: > > On Aug 8, 2013, at 2:07 PM, Blake Dunlap wrote: > > > On a related note, how are you actually getting this data? > > Sure: > > > https://www.nanog.org/sites/default/files/tue.lightning3.open_resolver.mauch_.pdf > > I would point you at the streaming archive, but I'm not sure where they > went. Perhaps they can post them to Youtube? > > Anyways, the alternate set of IPs responding is actually increasing over > time: > > http://openresolverproject.org/breakdown-graph2.cgi > > > What you have said previously ( Number of unique IPs that spoofed a > packet to me. (eg: I sent a packet to 1.2.3.4 and 5.6.7.8 responded). ) > doesn't even make sense. > > Many CPE devices will perform NAT on udp/53 packets received on their WAN > interface and forward them to their configured DNS server. Some will just > take the source IP and copy it into the packet. Because it comes in on > their WAN interface, it will instead of copying the inside NAT address just > copy my source IP from the weekly scan and use that. Since it's on the > outside, it doesn't copy it's outside IP and put that in, it copies mine. > > - Jared > > > On Thu, Aug 8, 2013 at 12:51 PM, Jared Mauch > wrote: > > Oops, I pulled the wrong data (off by one column) out before a trip and > didn't realize it until now. > > > > This is not the spoofer list, but the list of ASNs with open resolvers. > > > > Let me reprocess it. > > > > Apologies, corrected data being generated. > > > > - Jared > > > > On Aug 8, 2013, at 1:29 PM, Jared Mauch wrote: > > > > > The following is a sorted list from worst to best of networks that > allow spoofing: (cutoff here is 25k) > > > > > > (full list - > http://openresolverproject.org/full-spoofer-asn-list-201307.txt ) > > > > > > > > From jared at puck.nether.net Fri Aug 9 01:54:18 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 8 Aug 2013 21:54:18 -0400 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> Message-ID: <26E852E9-9D3C-4651-B003-AE81F3200865@puck.nether.net> On Aug 8, 2013, at 9:13 PM, Blake Dunlap wrote: > Thanks, this is quite interesting. I never would have expected that kind of behavior. I've been having trouble getting in touch with the Netgear security group about this, if someone knows how to contact them, I'd appreciate a referral on this topic :) - Jared From andra.lutu at imdea.org Fri Aug 9 14:24:12 2013 From: andra.lutu at imdea.org (Andra Lutu) Date: Fri, 09 Aug 2013 16:24:12 +0200 Subject: The BGP Visibility Scanner now for IPv6 prefixes Message-ID: <5204FB8C.20302@imdea.org> Dear all, In November 2012 we have released the *BGP Visibility Scanner*, a tool that checks the visibility of IPv4 prefixes at the interdomain level. We are now happy to further make available the *visibility query for IPv6 prefixes*. Back in February 2013 we have presented the BGP Visibility Scanner at NANOG57. Please find the abstract and slides at the following link: http://www.nanog.org/meetings/abstract?id=2072 The tool is publicly available at *http://visibility.it.uc3m.es/* You can use it to retrieve prefixes injected by a certain origin AS that are not distributed everywhere (i.e., the Limited Visibility Prefixes). The tool has already been proven to be of real help to network operators. In particular, it helped identify and eliminate a large number of unintended IPv4 LVPs (e.g., prefixes leaked because of misconfigurations). We believe the tool is of interest for the ASes already deploying IPv6, enabling the operators to check the visibility status of their IPv6 prefixes and validate their routing policies. We would greatly appreciate your feedback on the limited visibility prefixes that you discover with the tool! For more information about the BGP Visibility Scanner project, we further refer you to the RIPE Labs article: https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner For any further questions, do not hesitate to contact us! Thank you, best regards, Andra From james at freedomnet.co.nz Fri Aug 9 16:37:05 2013 From: james at freedomnet.co.nz (james jones) Date: Fri, 9 Aug 2013 12:37:05 -0400 Subject: Exchange Point Message-ID: Greetings, Does anyone see value in putting a open exchange point in one federal in Springfield, MA? -James From florian.hibler at kaiaglobal.com Fri Aug 9 18:15:41 2013 From: florian.hibler at kaiaglobal.com (Hibler, Florian) Date: Fri, 9 Aug 2013 20:15:41 +0200 Subject: IPAM In-Reply-To: References: <9FFA8B2148100D40969011DAEEB56FD00266C9DF0B30@server.fasttrackcomm.local> Message-ID: +1 on 6connect here as well. Best regards, Florian On Thu, Aug 8, 2013 at 9:56 PM, Sander Steffann wrote: > Hi, > >> I'm pretty sure that if 6connect doesn't have an existing tool to import Northstar that they'd work with your client to get it done. > > +1 on 6connect. Very helpful people there :-) > Sander > > -- Florian Hibler Chief Technical Officer eMail: florian.hibler at kaiaglobal.com Kaia Global Networks Limited Internet: http://www.kaiaglobal.com Company No. 08257877 Registered Office: High Wycombe, UK Notice: This transmittal and/or attachments may be privileged or confidential. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you. From cscora at apnic.net Fri Aug 9 18:33:43 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Aug 2013 04:33:43 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201308091833.r79IXhHg010432@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 10 Aug, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 463025 Prefixes after maximum aggregation: 187283 Deaggregation factor: 2.47 Unique aggregates announced to Internet: 229238 Total ASes present in the Internet Routing Table: 44667 Prefixes per ASN: 10.37 Origin-only ASes present in the Internet Routing Table: 34951 Origin ASes announcing only one prefix: 16188 Transit ASes present in the Internet Routing Table: 5881 Transit-only ASes present in the Internet Routing Table: 159 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 29 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 4144 Unregistered ASNs in the Routing Table: 1422 Number of 32-bit ASNs allocated by the RIRs: 4934 Number of 32-bit ASNs visible in the Routing Table: 3835 Prefixes from 32-bit ASNs in the Routing Table: 11571 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 273 Number of addresses announced to Internet: 2632015212 Equivalent to 156 /8s, 225 /16s and 93 /24s Percentage of available address space announced: 71.1 Percentage of allocated address space announced: 71.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.8 Total number of prefixes smaller than registry allocations: 162512 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 111367 Total APNIC prefixes after maximum aggregation: 33976 APNIC Deaggregation factor: 3.28 Prefixes being announced from the APNIC address blocks: 113162 Unique aggregates announced from the APNIC address blocks: 46312 APNIC Region origin ASes present in the Internet Routing Table: 4862 APNIC Prefixes per ASN: 23.27 APNIC Region origin ASes announcing only one prefix: 1218 APNIC Region transit ASes present in the Internet Routing Table: 826 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table: 632 Number of APNIC addresses announced to Internet: 725744352 Equivalent to 43 /8s, 65 /16s and 250 /24s Percentage of available APNIC address space announced: 84.8 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: 160175 Total ARIN prefixes after maximum aggregation: 80768 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 160775 Unique aggregates announced from the ARIN address blocks: 74685 ARIN Region origin ASes present in the Internet Routing Table: 15817 ARIN Prefixes per ASN: 10.16 ARIN Region origin ASes announcing only one prefix: 6003 ARIN Region transit ASes present in the Internet Routing Table: 1651 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: 1067981120 Equivalent to 63 /8s, 168 /16s and 25 /24s Percentage of available ARIN address space announced: 56.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 118384 Total RIPE prefixes after maximum aggregation: 60395 RIPE Deaggregation factor: 1.96 Prefixes being announced from the RIPE address blocks: 122184 Unique aggregates announced from the RIPE address blocks: 78455 RIPE Region origin ASes present in the Internet Routing Table: 17330 RIPE Prefixes per ASN: 7.05 RIPE Region origin ASes announcing only one prefix: 8208 RIPE Region transit ASes present in the Internet Routing Table: 2812 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: 2381 Number of RIPE addresses announced to Internet: 656776996 Equivalent to 39 /8s, 37 /16s and 159 /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: 49809 Total LACNIC prefixes after maximum aggregation: 9570 LACNIC Deaggregation factor: 5.20 Prefixes being announced from the LACNIC address blocks: 54393 Unique aggregates announced from the LACNIC address blocks: 25582 LACNIC Region origin ASes present in the Internet Routing Table: 1992 LACNIC Prefixes per ASN: 27.31 LACNIC Region origin ASes announcing only one prefix: 575 LACNIC Region transit ASes present in the Internet Routing Table: 368 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: 797 Number of LACNIC addresses announced to Internet: 134582824 Equivalent to 8 /8s, 5 /16s and 146 /24s Percentage of available LACNIC address space announced: 80.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 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: 11633 Total AfriNIC prefixes after maximum aggregation: 2534 AfriNIC Deaggregation factor: 4.59 Prefixes being announced from the AfriNIC address blocks: 12238 Unique aggregates announced from the AfriNIC address blocks: 3950 AfriNIC Region origin ASes present in the Internet Routing Table: 645 AfriNIC Prefixes per ASN: 18.97 AfriNIC Region origin ASes announcing only one prefix: 184 AfriNIC Region transit ASes present in the Internet Routing Table: 129 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46602752 Equivalent to 2 /8s, 199 /16s and 26 /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 2922 11561 917 Korea Telecom (KIX) 17974 2649 871 92 PT TELEKOMUNIKASI INDONESIA 7545 2053 320 111 TPG Internet Pty Ltd 4755 1779 393 197 TATA Communications formerly 9829 1537 1221 45 BSNL National Internet Backbo 9583 1224 92 504 Sify Limited 9498 1175 309 70 BHARTI Airtel Ltd. 4808 1155 2127 333 CNCGROUP IP network: China169 7552 1139 1080 13 Vietel Corporation 24560 1088 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 2980 3689 63 bellsouth.net, inc. 18566 2065 382 184 Covad Communications 1785 2006 679 125 PaeTec Communications, Inc. 22773 2004 2927 123 Cox Communications, Inc. 20115 1673 1624 620 Charter Communications 4323 1622 1106 408 Time Warner Telecom 701 1522 11104 799 UUNET Technologies, Inc. 30036 1377 310 652 Mediacom Communications Corp 7018 1320 11037 834 AT&T WorldNet Services 11492 1221 218 363 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 1659 544 16 Corbina telecom 34984 1299 244 221 BILISIM TELEKOM 2118 1159 97 13 EUnet/RELCOM Autonomous Syste 31148 978 43 17 FreeNet ISP 20940 975 348 751 Akamai Technologies European 6830 871 2371 429 UPC Distribution Services 13188 843 99 70 Educational Network 8551 772 370 45 Bezeq International 12479 681 797 53 Uni2 Autonomous System 9198 570 343 21 Kazakhtelecom Data Network Ad 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 3039 1595 110 NET Servicos de Comunicao S.A 10620 2654 422 231 TVCABLE BOGOTA 7303 1730 1157 220 Telecom Argentina Stet-France 18881 1286 844 20 Global Village Telecom 8151 1278 2760 394 UniNet S.A. de C.V. 27947 837 94 91 Telconet S.A 6503 817 434 63 AVANTEL, S.A. 11830 749 364 15 Instituto Costarricense de El 3816 722 302 83 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 1861 112 5 MOBITEL 24863 872 274 30 LINKdotNET AS number 6713 542 617 25 Itissalat Al-MAGHRIB 8452 435 956 9 TEDATA 24835 291 80 8 RAYA Telecom - Egypt 3741 258 921 217 The Internet Solution 15706 221 32 6 Sudatel Internet Exchange Aut 29571 220 17 12 Ci Telecom Autonomous system 36992 215 527 23 Etisalat MISR 12258 193 28 71 Vodacom Internet Company 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 28573 3039 1595 110 NET Servicos de Comunicao S.A 6389 2980 3689 63 bellsouth.net, inc. 4766 2922 11561 917 Korea Telecom (KIX) 10620 2654 422 231 TVCABLE BOGOTA 17974 2649 871 92 PT TELEKOMUNIKASI INDONESIA 18566 2065 382 184 Covad Communications 7545 2053 320 111 TPG Internet Pty Ltd 1785 2006 679 125 PaeTec Communications, Inc. 22773 2004 2927 123 Cox Communications, Inc. 36998 1861 112 5 MOBITEL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2980 2917 bellsouth.net, inc. 17974 2649 2557 PT TELEKOMUNIKASI INDONESIA 10620 2654 2423 TVCABLE BOGOTA 4766 2922 2005 Korea Telecom (KIX) 7545 2053 1942 TPG Internet Pty Ltd 18566 2065 1881 Covad Communications 1785 2006 1881 PaeTec Communications, Inc. 22773 2004 1881 Cox Communications, Inc. 36998 1861 1856 MOBITEL 8402 1659 1643 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 30621 UNALLOCATED 12.151.74.0/23 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 100.100.0.0/24 4847 China Networks Inter-Exchange 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 62.182.96.0/23 15830 TELECITY London 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:11 /10:30 /11:92 /12:249 /13:480 /14:907 /15:1605 /16:12732 /17:6646 /18:11033 /19:22531 /20:32233 /21:34772 /22:48835 /23:42725 /24:244185 /25:1299 /26:1649 /27:839 /28:44 /29:75 /30:18 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2016 2065 Covad Communications 36998 1826 1861 MOBITEL 6389 1714 2980 bellsouth.net, inc. 8402 1360 1659 Corbina telecom 22773 1304 2004 Cox Communications, Inc. 30036 1239 1377 Mediacom Communications Corp 11492 1182 1221 Cable One 1785 1079 2006 PaeTec Communications, Inc. 6983 1021 1149 ITC^Deltacom 10620 986 2654 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:801 2:752 3:3 4:19 5:913 6:17 8:597 12:1904 13:2 14:870 15:11 16:3 17:10 18:19 20:17 23:302 24:1772 27:1538 31:1347 32:45 33:2 34:5 36:67 37:1803 38:892 39:2 40:176 41:3281 42:258 44:7 46:1964 47:2 49:658 50:844 52:12 54:37 55:7 57:26 58:1171 59:638 60:332 61:1495 62:1178 63:2007 64:4339 65:2157 66:4201 67:2042 68:1091 69:3301 70:798 71:488 72:1919 74:2513 75:324 76:303 77:1133 78:1047 79:613 80:1290 81:1018 82:650 83:585 84:568 85:1220 86:465 87:1031 88:535 89:1807 90:152 91:5530 92:618 93:1655 94:1975 95:1610 96:591 97:346 98:1027 99:43 100:29 101:595 103:3118 105:524 106:139 107:208 108:520 109:1857 110:943 111:1070 112:568 113:814 114:700 115:1097 116:956 117:795 118:1140 119:1298 120:361 121:848 122:1808 123:1243 124:1369 125:1399 128:638 129:221 130:310 131:667 132:348 133:160 134:274 135:72 136:259 137:241 138:344 139:189 140:201 141:320 142:532 143:386 144:532 145:93 146:534 147:414 148:675 149:351 150:155 151:582 152:413 153:191 154:29 155:416 156:274 157:402 158:276 159:743 160:349 161:456 162:552 163:223 164:582 165:529 166:255 167:601 168:1026 169:126 170:1071 171:188 172:23 173:1588 174:554 175:492 176:1165 177:2129 178:1908 179:83 180:1512 181:607 182:1228 183:420 184:653 185:733 186:2364 187:1389 188:1852 189:1273 190:6870 192:6873 193:5621 194:4718 195:3597 196:1330 197:998 198:4583 199:5382 200:5994 201:2430 202:8843 203:8894 204:4524 205:2595 206:2831 207:2899 208:4002 209:3597 210:2939 211:1531 212:2247 213:2042 214:913 215:100 216:5263 217:1644 218:619 219:331 220:1278 221:551 222:321 223:462 End of report From philfagan at gmail.com Fri Aug 9 18:42:46 2013 From: philfagan at gmail.com (Phil Fagan) Date: Fri, 9 Aug 2013 12:42:46 -0600 Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts In-Reply-To: References: <4496469827D6CB48A4CE49A3C6602BD4A01A5CA683@EXCH07-02.apollogrp.edu> Message-ID: Interesting; instability due to reaching this table limit? Good info! On Thu, Aug 8, 2013 at 10:39 AM, Tony Tauber wrote: > It's a fair question and had nothing to do with the other network (TW > Telecom, in this case, not TIme Warner Cable). > Sorry for not filling in details sooner. > > We recently needed to adjust the scale profile on some of our Cisco ASR9k > trident chip (80gig) Line Cards as we reached . The default profile only > supports up to 512k routes and will notify that CEF has run out of > DATA_TYPE_TABLE_SET space as a result. The profile change required (profile > 13) requires a reload of the chassis. please be advised. You might want to > review with your local support team. > > The symptom involved BGP neighbor instability and unreachability of some > destinations. > Shutting down that particular BGP session was a temporary work-around > until the adjustment could be made during a demand maintenance window to > minimize disruption. > > Thanks, > Tony > > > On Wed, Aug 7, 2013 at 5:31 PM, Phil Fagan wrote: > >> BGP Noob question here; but wouldn't Time Warner not recieve a prefix if >> it >> wasn't reachable? Is this an artifact? >> >> >> On Mon, Aug 5, 2013 at 11:32 AM, Chad Reid >> wrote: >> >> > Thanks for the assistance everyone. This issue was resolved by shutting >> > down a BGP peering session between Time Warner and Comcast. --Chad >> > >> > Chad M. Reid, Network Administrator II >> > Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) >> > Apollo Group | IT Services ? IT Operations Center (ITOC) >> > 4025 S. Riverpoint Parkway ? MS: AA-M002 ? Phoenix, AZ 85040 >> > phone: 602.557.6746 ? fax: 602.557.6606 ? email: >> chad.reid at apollogrp.edu >> > >> > >> > -----Original Message----- >> > From: Chad Reid >> > Sent: Sunday, August 04, 2013 7:41 AM >> > To: 'nanog at nanog.org' >> > Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for >> > Help or Contacts >> > >> > Hello NANOG, >> > >> > A few hundred of our users that use Comcast in the South East United >> > States (other regions aren't affected) are unable to access our >> websites in >> > the IP block 204.17.16.0/20. Based upon testing with the users, they're >> > getting a destination unreachable from a Comcast backbone router in ASN >> > 7922: >> > be-16-pe03.56marietta.ga.ibone.comcast.net [68.86.83.134] reports: >> > Destination net unreachable. >> > >> > We're not a customer of Comcast, nor are any of our ISPs. Because of >> this, >> > we can't find anyone at Comcast to look at this issue nor do we have >> good >> > contact info to even reach someone. Our users in the South East can open >> > tickets with Comcast technical support, but you can imagine how >> successful >> > they are trying to explain this to frontline support and getting >> frontline >> > support to understand. >> > >> > Is anyone from Comcast on the list that can assist or know of a contact? >> > >> > >> > Chad M. Reid, Network Administrator II >> > Work Hours: Sun. - Tue. 6AM-6PM and Wed. 6AM-3PM (MST -7) Apollo Group >> | >> > IT Services ? IT Operations Center (ITOC) >> > 4025 S. Riverpoint Parkway ? MS: AA-M002 ? Phoenix, AZ 85040 >> > phone: 602.557.6746 ? fax: 602.557.6606 ? email: >> chad.reid at apollogrp.edu >> > >> > >> > >> > This message is private and confidential. If you have received it in >> > error, please notify the sender and remove it from your system. >> > >> > >> > >> > >> >> >> -- >> Phil Fagan >> Denver, CO >> 970-480-7618 >> > > -- Phil Fagan Denver, CO 970-480-7618 From cidr-report at potaroo.net Fri Aug 9 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Aug 2013 22:00:01 GMT Subject: The Cidr Report Message-ID: <201308092200.r79M014H006374@wattle.apnic.net> This report has been generated at Fri Aug 9 21:13:27 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 02-08-13 473248 268333 03-08-13 473467 268519 04-08-13 473615 268943 05-08-13 473751 269065 06-08-13 473796 269041 07-08-13 474116 269494 08-08-13 474746 269391 09-08-13 474589 270024 AS Summary 44811 Number of ASes in routing system 18465 Number of ASes announcing only one prefix 4237 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 117330144 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'). --- 09Aug13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 475025 269929 205096 43.2% All ASes AS6389 2980 66 2914 97.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 3039 484 2555 84.1% NET Servi?os de Comunica??o S.A. AS17974 2648 443 2205 83.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 4237 2069 2168 51.2% WINDSTREAM - Windstream Communications Inc AS4766 2922 932 1990 68.1% KIXS-AS-KR Korea Telecom AS22773 2004 241 1763 88.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2065 468 1597 77.3% COVAD - Covad Communications Co. AS4323 2989 1535 1454 48.6% TWTC - tw telecom holdings, inc. AS36998 1861 421 1440 77.4% SDN-MOBITEL AS10620 2654 1338 1316 49.6% Telmex Colombia S.A. AS7545 2058 769 1289 62.6% TPG-INTERNET-AP TPG Telecom Limited AS7303 1730 453 1277 73.8% Telecom Argentina S.A. AS18881 1285 43 1242 96.7% Global Village Telecom AS4755 1777 592 1185 66.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1159 52 1107 95.5% RELCOM-AS OOO "NPO Relcom" AS7552 1160 127 1033 89.1% VIETEL-AS-AP Vietel Corporation AS22561 1208 226 982 81.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS1785 2006 1157 849 42.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS11830 947 101 846 89.3% Instituto Costarricense de Electricidad y Telecom. AS18101 981 173 808 82.4% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1155 390 765 66.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1523 803 720 47.3% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS13977 846 139 707 83.6% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS8151 1281 586 695 54.3% Uninet S.A. de C.V. AS33363 1739 1052 687 39.5% BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC AS855 735 55 680 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6983 1149 482 667 58.1% ITCDELTA - ITC^Deltacom AS24560 1088 425 663 60.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS31148 978 338 640 65.4% FREENET-AS Freenet Ltd. AS4788 779 141 638 81.9% TMNET-AS-AP TM Net, Internet Service Provider Total 52983 16101 36882 69.6% 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- 10.255.255.12/30 AS65530 -Private Use AS- 10.255.255.248/30 AS64608 -Private Use AS- 10.255.255.252/30 AS64512 -Private Use AS- 23.112.0.0/12 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.182.96.0/23 AS15830 TELECITY-LON TELECITYGROUP INTERNATIONAL LIMITED 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. 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 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.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 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 80.68.144.0/20 AS33982 82.103.0.0/18 AS30901 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.205.188.0/22 AS47983 91.207.200.0/23 AS48523 91.209.93.0/24 AS48523 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 96.45.48.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.49.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.50.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.51.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.52.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.53.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.54.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.55.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.56.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.57.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.58.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.59.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.60.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.61.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.62.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.63.0/24 AS33475 RSN-1 - RockSolid Network, 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.224.163.0/24 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 103.224.188.0/23 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 103.240.48.0/22 AS17589 GABIA-AS-KR GABIA Inc. 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.40.184.0/24 AS19821 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. 173.45.192.0/19 AS6461 MFNX MFN - Metromedia Fiber Network 174.138.144.0/20 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 193.33.112.0/23 AS8586 OBSL-AS TalkTalk Communications Limited 193.111.125.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.111.155.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 194.50.82.0/24 AS16276 OVH OVH Systems 194.79.48.0/22 AS39117 194.117.250.0/23 AS41412 MIVITEC-AS MIVITEC GmbH 194.169.237.0/24 AS12968 CDP Netia SA 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 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.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 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 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 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 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.68.244.0/22 AS17140 208.68.244.0/23 AS17140 208.68.246.0/23 AS17140 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 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.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 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.90.64.0/22 AS16415 PRCNET-DOM - Precision Response Corporation 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.160.81.0/24 AS36184 209.160.83.0/24 AS36184 209.160.84.0/24 AS36184 209.160.86.0/24 AS36184 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.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.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.151.192.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.151.200.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 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 Aug 9 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Aug 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201308092200.r79M01dF006393@wattle.apnic.net> BGP Update Report Interval: 01-Aug-13 -to- 08-Aug-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 30338 1.6% 25.5 -- CORBINA-AS OJSC "Vimpelcom" 2 - AS35819 29993 1.6% 66.1 -- MOBILY-AS Etihad Etisalat Company (Mobily) 3 - AS9829 29106 1.6% 39.2 -- BSNL-NIB National Internet Backbone 4 - AS27738 25299 1.4% 72.5 -- Ecuadortelecom S.A. 5 - AS7552 23197 1.3% 19.8 -- VIETEL-AS-AP Vietel Corporation 6 - AS32748 20812 1.1% 507.6 -- STEADFAST - Steadfast Networks 7 - AS17974 18894 1.0% 15.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 8 - AS9416 18269 1.0% 9134.5 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 9 - AS28573 17402 0.9% 6.0 -- NET Servi?os de Comunica??o S.A. 10 - AS18403 16572 0.9% 29.4 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 11 - AS36998 16232 0.9% 9.0 -- SDN-MOBITEL 12 - AS34969 15688 0.8% 1961.0 -- PASJONET-AS Pasjo.Net Sp, z o.o. 13 - AS4775 14028 0.8% 738.3 -- GLOBE-TELECOM-AS Globe Telecoms 14 - AS5800 12543 0.7% 56.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 15 - AS38654 10494 0.6% 10494.0 -- INES-NETWORK INES Corporation. 16 - AS6325 9835 0.5% 138.5 -- ILLINOIS-CENTURY - Illinois Century Network 17 - AS48612 9816 0.5% 1636.0 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 18 - AS45400 9658 0.5% 38.0 -- NICNET Korea Telecom-PUBNET 19 - AS17841 9320 0.5% 33.2 -- NCIA-AS-KR MIC E-GOVERNMENT 20 - AS6629 9215 0.5% 2303.8 -- NOAA-AS - NOAA TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS38654 10494 0.6% 10494.0 -- INES-NETWORK INES Corporation. 2 - AS9416 18269 1.0% 9134.5 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 3 - AS19406 4741 0.3% 4741.0 -- TWRS-MA - Towerstream I, Inc. 4 - AS16608 8145 0.4% 4072.5 -- KENTEC - Kentec Communications, Inc. 5 - AS6174 7234 0.4% 3617.0 -- SPRINTLINK8 - Sprint 6 - AS10428 8778 0.5% 2926.0 -- CWV-NETWORKS - The College of West Virginia 7 - AS42334 2885 0.2% 2885.0 -- BBP-AS Broadband Plus s.a.l. 8 - AS6629 9215 0.5% 2303.8 -- NOAA-AS - NOAA 9 - AS19111 2144 0.1% 2144.0 -- NATURES-BOUN - NBTY, Inc. 10 - AS34969 15688 0.8% 1961.0 -- PASJONET-AS Pasjo.Net Sp, z o.o. 11 - AS36976 1925 0.1% 1925.0 -- SONANGOL 12 - AS52280 1674 0.1% 1674.0 -- INTERNEXA Chile S.A. 13 - AS48612 9816 0.5% 1636.0 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 14 - AS14287 9084 0.5% 1514.0 -- TRIAD-TELECOM - Triad Telecom, Inc. 15 - AS14906 2380 0.1% 1190.0 -- EMUSIC - eMusic.com Inc. 16 - AS49076 1184 0.1% 1184.0 -- COMPASS-EOS COMPASS ELECTRO-OPTICAL SYSTEMS LTD 17 - AS56678 1120 0.1% 1120.0 -- GYDROZO-AS LLC "Gydrozo" 18 - AS58694 929 0.1% 929.0 -- REGOCOMMUNICATIONS-BD House 8 (2rd Floor) 19 - AS22688 806 0.0% 806.0 -- DOLGENCORP - Dollar General Corporation 20 - AS10905 768 0.0% 768.0 -- CITIC-SECURITIES-INTERNATIONAL-USA - CITIC SECURITIES INTERNATIONAL USA, LLC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 150.39.0.0/16 10494 0.5% AS38654 -- INES-NETWORK INES Corporation. 2 - 92.246.207.0/24 9805 0.5% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 3 - 192.58.232.0/24 9203 0.5% AS6629 -- NOAA-AS - NOAA 4 - 207.63.128.0/18 9199 0.5% AS6325 -- ILLINOIS-CENTURY - Illinois Century Network 5 - 203.118.224.0/21 9196 0.5% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 6 - 203.118.232.0/21 9073 0.5% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 7 - 112.203.192.0/19 7926 0.4% AS9299 -- IPG-AS-AP Philippine Long Distance Telephone Company 8 - 120.28.62.0/24 7083 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 10 - 115.170.128.0/17 5329 0.3% AS4847 -- CNIX-AP China Networks Inter-Exchange 11 - 65.90.49.0/24 4965 0.2% AS3356 -- LEVEL3 Level 3 Communications 12 - 69.38.178.0/24 4741 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 13 - 64.187.64.0/23 4344 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. 14 - 2.93.235.0/24 4262 0.2% AS8402 -- CORBINA-AS OJSC "Vimpelcom" 15 - 64.187.64.0/24 3801 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. 16 - 206.105.75.0/24 3617 0.2% AS6174 -- SPRINTLINK8 - Sprint 17 - 208.16.110.0/24 3617 0.2% AS6174 -- SPRINTLINK8 - Sprint 18 - 23.29.128.0/19 3616 0.2% AS32748 -- STEADFAST - Steadfast Networks 19 - 74.120.122.0/24 3091 0.2% AS32748 -- STEADFAST - Steadfast Networks 20 - 12.43.218.0/24 2926 0.1% AS10428 -- CWV-NETWORKS - The College of West Virginia 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 james at towardex.com Fri Aug 9 23:16:57 2013 From: james at towardex.com (james at towardex.com) Date: Fri, 9 Aug 2013 19:16:57 -0400 Subject: Exchange Point In-Reply-To: References: Message-ID: <08b801ce9556$8b2de550$a189aff0$@towardex.com> > Does anyone see value in putting a open exchange point in one federal in Springfield, MA? Springfield, Mass.? Can't hurt, especially with MBI development as of late. There's also Boston Internet Exchange which has been slowly picking up steam, over at 1 Summer; you may want to look into remote interconnection. james From Amrodriguez at tricom.com.do Sat Aug 10 00:08:43 2013 From: Amrodriguez at tricom.com.do (Amaury Rodriguez, TRI) Date: Fri, 9 Aug 2013 20:08:43 -0400 Subject: Google Play Store - Is not working Message-ID: <22716198AAB328468DE93087C990A64F1A7AC5A1@SVREX0.TRICOMRD.COM> Hello everyone Someone knows goggle contacts. We have localization issues with our newly assigned IP block from LACNIC. We are using new IP Block recently assigned by LACNIC in our network and Google Play Store don't work. Thanks in Advance! Fuera de Aqui nada se Vive Mejor! Amaury Rodriguez | Senior IP Engineer | TRICOM S.A. Phone: 809.476.6000 | Office: 809.334.7001 | Cell: 809.628.2047 | Mail: amrodriguez at tricom.com.do | Site: www.tricom.net P Please consider the environment before you print this e-mail. Importante: Este mensaje o correo electrnico y todos sus archivos adjuntos pueden contener informacin confidencial y es exclusivamente para el uso del individuo o entidad al cual es enviado. Si usted no es el destinatario del mismo favor desecharlo inmediatamente, borrndolo de su computadora, y proceda a informar al remitente respondiendo este correo electrnico. Queda formalmente notificado que cualquier divulgacin, distribucin, reproduccin, copiado o uso de esta informacin, por otras personas que no sean las destinatarias, queda estrictamente prohibido. Las opiniones expresadas en este mensaje son propias del autor y no necesariamente coinciden con las de TRICOM, S.A. www.tricom.net Important: This message or electronic mail and all attached files therein could contain confidential information and it is of the exclusive use of the individual or entity to which it is sent. If you are not the intended user of the message, please discard it immediately by erasing the e-mail from your computer, and proceed to inform the recipient by replying this electronic mail. It is formally notified that any and all dissemination, distribution, reproduction, copying or use of this information, by any other persons who are not the recipients, is strictly prohibited. Any opinions expressed in this message are of the property of the author and do not necessarily express or coincide with those of TRICOM, S.A. www.tricom.net From morrowc.lists at gmail.com Sat Aug 10 02:44:55 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 9 Aug 2013 22:44:55 -0400 Subject: Google Play Store - Is not working In-Reply-To: <22716198AAB328468DE93087C990A64F1A7AC5A1@SVREX0.TRICOMRD.COM> References: <22716198AAB328468DE93087C990A64F1A7AC5A1@SVREX0.TRICOMRD.COM> Message-ID: On Fri, Aug 9, 2013 at 8:08 PM, Amaury Rodriguez, TRI wrote: > We have localization issues with our newly assigned IP block from > LACNIC. always super helpful to include what ip block you mean... else it's a bit harder to tell what's going on, eh? From excelsio at gmx.com Sat Aug 10 07:44:47 2013 From: excelsio at gmx.com (excelsio at gmx.com) Date: Sat, 10 Aug 2013 09:44:47 +0200 Subject: IPAM In-Reply-To: <9FFA8B2148100D40969011DAEEB56FD00266C9DF0B30@server.fasttrackcomm.local> References: <9FFA8B2148100D40969011DAEEB56FD00266C9DF0B30@server.fasttrackcomm.local> Message-ID: <5205EF6F.7030703@gmx.com> I don?t know Northstar, but if you can export their tables into a *.csv, you can easily import it into http://www.gestioip.net/ Michael Am 07.08.2013 18:41, schrieb Natambu Obleton: > I have customer that we deployed Northstar for their internal ip management over 8 yrs ago. They are still using it, but it is slowly breaking on them. Can someone recommend an IPAM solution that has a Northstar import option? They have hundreds of entries detailing customer who was assigned the ip address and I would like to avoid any data massaging. TIA From woody at pch.net Sat Aug 10 23:21:36 2013 From: woody at pch.net (Bill Woodcock) Date: Sat, 10 Aug 2013 16:21:36 -0700 Subject: Exchange Point In-Reply-To: <08b801ce9556$8b2de550$a189aff0$@towardex.com> References: <08b801ce9556$8b2de550$a189aff0$@towardex.com> Message-ID: >> Does anyone see value in putting a open exchange point in one federal in >> Springfield, MA? > > Springfield, Mass.? Can't hurt? Agreed. There's essentially no reason not to put in an exchange, anywhere three or more ISPs are present. > There's also Boston Internet Exchange which has been slowly picking up > steam, over at 1 Summer; you may want to look into remote interconnection. That's 90 miles away, so I'd recommend not trying to extend their switch fabric that far. If you were considering a second exchange in Boston, I'd definitely recommend using the same switch fabric for both locations, but not at 90 miles of remove. That would put a pretty big burden on the smaller ISPs that are likely to be participating in Springfield. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sh.vahabzadeh at gmail.com Sun Aug 11 06:33:55 2013 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sun, 11 Aug 2013 11:03:55 +0430 Subject: Native VLAN for Huawei MA5616 DSLAM Message-ID: Dear Friends, Anybody have idea about changing native vlan on Huawei MA5616 DSLAM? I can not find the correct syntax, there is no option under "interface eth 0/0" Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From linuxloader at gmail.com Sun Aug 11 11:47:59 2013 From: linuxloader at gmail.com (Georgi Genov) Date: Sun, 11 Aug 2013 14:47:59 +0300 Subject: Native VLAN for Huawei MA5616 DSLAM In-Reply-To: References: Message-ID: <520779EF.2090608@gmail.com> It`s configurable under scu/scuh/giu board interface scu 0/9 native-vlan 1 vlan XXXX native-vlan 2 vlan YYYY or interface giu 0/19 native-vlan 1 vlan XXXX native-vlan 2 vlan YYYY On 11.8.2013 ?. 09:33 ?., Shahab Vahabzadeh wrote: > Dear Friends, > Anybody have idea about changing native vlan on Huawei MA5616 DSLAM? > I can not find the correct syntax, there is no option under "interface eth > 0/0" > Thanks > From sh.vahabzadeh at gmail.com Sun Aug 11 12:25:20 2013 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sun, 11 Aug 2013 16:55:20 +0430 Subject: Native VLAN for Huawei MA5616 DSLAM In-Reply-To: <520779EF.2090608@gmail.com> References: <520779EF.2090608@gmail.com> Message-ID: Dear Georgi, MA5616 does not have any SCU interface... What can we do? On Sun, Aug 11, 2013 at 4:17 PM, Georgi Genov wrote: > It`s configurable under scu/scuh/giu board > > interface scu 0/9 > native-vlan 1 vlan XXXX > native-vlan 2 vlan YYYY > or > interface giu 0/19 > native-vlan 1 vlan XXXX > native-vlan 2 vlan YYYY > > On 11.8.2013 ?. 09:33 ?., Shahab Vahabzadeh wrote: > >> Dear Friends, >> Anybody have idea about changing native vlan on Huawei MA5616 DSLAM? >> I can not find the correct syntax, there is no option under "interface eth >> 0/0" >> Thanks >> >> > -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From fw at deneb.enyo.de Sun Aug 11 12:45:30 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 11 Aug 2013 14:45:30 +0200 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: (Jared Mauch's message of "Thu, 8 Aug 2013 13:45:03 -0400") References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> Message-ID: <87pptk5rbp.fsf@mid.deneb.enyo.de> * Jared Mauch: > Number of unique IPs that spoofed a packet to me. (eg: I sent a > packet to 1.2.3.4 and 5.6.7.8 responded). That's not necessarily proof of spoofing, isn't it? The system in question might legitimately own IP addresses from very different networks. If the system is a router and the service you're pinging is not correctly implemented and it picks up the IP address of the outgoing interface instead of the source address of the request, that's totally expected. I'm not saying that BCP 38 is widely implement (it's not, unless operators have configured exceptions for ICMP traffic from private address, which I very much doubt). I just think you aren't actually measuring spoofing capabilities. From mysidia at gmail.com Sun Aug 11 13:23:22 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 11 Aug 2013 08:23:22 -0500 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: <87pptk5rbp.fsf@mid.deneb.enyo.de> References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> <87pptk5rbp.fsf@mid.deneb.enyo.de> Message-ID: A strange thought occurs.... Regarding, devices that unintentionally have SNMP open to the public. They might also have write access open, which could enable reconfiguring the device to facilitate full TCP spoofing, or opening up a tunnel; enabling 3 way handshake and everything, permitting the possible DDoS conditions to go well beyond simple UDP reflection. Those devices that just have SNMP read access; might reveal enough information in the exposed MIBs about the device, timestamps, connection table status..... for an attacker to successfully inject false data into a TCP stream. For example... spoofing a TCP message containing a false BGP route advertisement; if enough about the state of the router's TCP connection table and synchronization numbers, timestamp, and other hints about the state of the random number generator, can be discovered directly or indirectly through some piece of data in the SNMP MIB.... -- -Jimmy On Sun, Aug 11, 2013 at 7:45 AM, Florian Weimer wrote: > * Jared Mauch: > > > Number of unique IPs that spoofed a packet to me. (eg: I sent a > > packet to 1.2.3.4 and 5.6.7.8 responded). > > That's not necessarily proof of spoofing, isn't it? The system in > question might legitimately own IP addresses from very different > networks. If the system is a router and the service you're pinging is > not correctly implemented and it picks up the IP address of the > outgoing interface instead of the source address of the request, > that's totally expected. > > I'm not saying that BCP 38 is widely implement (it's not, unless > operators have configured exceptions for ICMP traffic from private > address, which I very much doubt). I just think you aren't actually > measuring spoofing capabilities. > > -- -Mysid From sh.vahabzadeh at gmail.com Sun Aug 11 13:42:12 2013 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sun, 11 Aug 2013 18:12:12 +0430 Subject: Native VLAN for Huawei MA5616 DSLAM In-Reply-To: References: <520779EF.2090608@gmail.com> Message-ID: Only these interface's are available under: MA5616(config)# interface ? > adsl > emu > eponnni > eth > gponnni > h248 > loopback > meth > null > shl > vdsl > vlanif Thanks On Sun, Aug 11, 2013 at 4:55 PM, Shahab Vahabzadeh wrote: > Dear Georgi, > MA5616 does not have any SCU interface... > What can we do? > > > On Sun, Aug 11, 2013 at 4:17 PM, Georgi Genov wrote: > >> It`s configurable under scu/scuh/giu board >> >> interface scu 0/9 >> native-vlan 1 vlan XXXX >> native-vlan 2 vlan YYYY >> or >> interface giu 0/19 >> native-vlan 1 vlan XXXX >> native-vlan 2 vlan YYYY >> >> On 11.8.2013 ?. 09:33 ?., Shahab Vahabzadeh wrote: >> >>> Dear Friends, >>> Anybody have idea about changing native vlan on Huawei MA5616 DSLAM? >>> I can not find the correct syntax, there is no option under "interface >>> eth >>> 0/0" >>> Thanks >>> >>> >> > > > -- > Regards, > Shahab Vahabzadeh, Network Engineer and System Administrator > > Cell Phone: +1 (415) 871 0742 > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 > -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From jared at puck.nether.net Sun Aug 11 15:08:46 2013 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 11 Aug 2013 11:08:46 -0400 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: <87pptk5rbp.fsf@mid.deneb.enyo.de> References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> <87pptk5rbp.fsf@mid.deneb.enyo.de> Message-ID: <0E761BB8-1625-4F7F-A147-32BA3B9ADE92@puck.nether.net> The incidence rate is too high for it to be multihomed hosts. Let me know if you want to look at the raw data. Very interesting stuff. Or just look for 8.8.8.8 in the openresolverproject page. - Jared On Aug 11, 2013, at 8:45 AM, Florian Weimer wrote: > * Jared Mauch: > >> Number of unique IPs that spoofed a packet to me. (eg: I sent a >> packet to 1.2.3.4 and 5.6.7.8 responded). > > That's not necessarily proof of spoofing, isn't it? The system in > question might legitimately own IP addresses from very different > networks. If the system is a router and the service you're pinging is > not correctly implemented and it picks up the IP address of the > outgoing interface instead of the source address of the request, > that's totally expected. > > I'm not saying that BCP 38 is widely implement (it's not, unless > operators have configured exceptions for ICMP traffic from private > address, which I very much doubt). I just think you aren't actually > measuring spoofing capabilities. From fw at deneb.enyo.de Sun Aug 11 15:40:28 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 11 Aug 2013 17:40:28 +0200 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: <0E761BB8-1625-4F7F-A147-32BA3B9ADE92@puck.nether.net> (Jared Mauch's message of "Sun, 11 Aug 2013 11:08:46 -0400") References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> <87pptk5rbp.fsf@mid.deneb.enyo.de> <0E761BB8-1625-4F7F-A147-32BA3B9ADE92@puck.nether.net> Message-ID: <8738qg2q37.fsf@mid.deneb.enyo.de> * Jared Mauch: > The incidence rate is too high for it to be multihomed hosts. > > Let me know if you want to look at the raw data. Very interesting stuff. > > Or just look for 8.8.8.8 in the openresolverproject page. Indeed, I could verify that 5.61.0.0 can indeed spoof one of my IP addresses to the 8.8.8.8 DNS resolver. For a cache miss, I get a query from a Google IP address and the 8.8.8.8 reply has a plausible TTL, so I don't think it's spoofing the response. Apparently, they're implementing DNS proxy by destination-NATting, and because they listen also on the WAN interface, they get the source address wrong. This is quite scary. From morrowc.lists at gmail.com Sun Aug 11 16:02:52 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 11 Aug 2013 12:02:52 -0400 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: <8738qg2q37.fsf@mid.deneb.enyo.de> References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> <87pptk5rbp.fsf@mid.deneb.enyo.de> <0E761BB8-1625-4F7F-A147-32BA3B9ADE92@puck.nether.net> <8738qg2q37.fsf@mid.deneb.enyo.de> Message-ID: On Sun, Aug 11, 2013 at 11:40 AM, Florian Weimer wrote: > Apparently, they're implementing DNS proxy by destination-NATting, and > because they listen also on the WAN interface, they get the source > address wrong. > > This is quite scary. which part? the fact that most NAT implementations on CPE are crap? or the spoofing bit? From fw at deneb.enyo.de Sun Aug 11 16:14:28 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 11 Aug 2013 18:14:28 +0200 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: (Christopher Morrow's message of "Sun, 11 Aug 2013 12:02:52 -0400") References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> <87pptk5rbp.fsf@mid.deneb.enyo.de> <0E761BB8-1625-4F7F-A147-32BA3B9ADE92@puck.nether.net> <8738qg2q37.fsf@mid.deneb.enyo.de> Message-ID: <87y588yzkr.fsf@mid.deneb.enyo.de> * Christopher Morrow: > On Sun, Aug 11, 2013 at 11:40 AM, Florian Weimer wrote: > >> Apparently, they're implementing DNS proxy by destination-NATting, and >> because they listen also on the WAN interface, they get the source >> address wrong. >> >> This is quite scary. > > which part? the fact that most NAT implementations on CPE are crap? or > the spoofing bit? The spoofing bit. Among other things, it makes the impact of CPE crappiness non-localized. From Amrodriguez at tricom.com.do Sun Aug 11 22:59:42 2013 From: Amrodriguez at tricom.com.do (Amaury Rodriguez, TRI) Date: Sun, 11 Aug 2013 18:59:42 -0400 Subject: Google Play Store - Is not working In-Reply-To: References: <22716198AAB328468DE93087C990A64F1A7AC5A1@SVREX0.TRICOMRD.COM> Message-ID: <22716198AAB328468DE93087C990A64F1A80236E@SVREX0.TRICOMRD.COM> Hello Christ, The IP Block is 186.50/16. We receive a mail from On Call Google Engineer. Best Regards, Fuera de Aqui nada se Vive Mejor! Amaury Rodriguez | Senior IP Engineer?|?TRICOM S.A.? Phone: 809.476.6000 | Office: 809.334.7001 |?Cell: 809.628.2047 | Mail: amrodriguez at tricom.com.do | Site: www.tricom.net? ? Please consider the environment before you print this e-mail. ? -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Friday, August 09, 2013 10:45 PM To: Amaury Rodriguez, TRI Cc: nanog list; Jose Osoria, TRI; Jose Ventura, TRI; Gamalier Sanchez, TRI Subject: Re: Google Play Store - Is not working On Fri, Aug 9, 2013 at 8:08 PM, Amaury Rodriguez, TRI wrote: > We have localization issues with our newly assigned IP block from > LACNIC. always super helpful to include what ip block you mean... else it's a bit harder to tell what's going on, eh? Importante: Este mensaje o correo electrnico y todos sus archivos adjuntos pueden contener informacin confidencial y es exclusivamente para el uso del individuo o entidad al cual es enviado. Si usted no es el destinatario del mismo favor desecharlo inmediatamente, borrndolo de su computadora, y proceda a informar al remitente respondiendo este correo electrnico. Queda formalmente notificado que cualquier divulgacin, distribucin, reproduccin, copiado o uso de esta informacin, por otras personas que no sean las destinatarias, queda estrictamente prohibido. Las opiniones expresadas en este mensaje son propias del autor y no necesariamente coinciden con las de TRICOM, S.A. www.tricom.net Important: This message or electronic mail and all attached files therein could contain confidential information and it is of the exclusive use of the individual or entity to which it is sent. If you are not the intended user of the message, please discard it immediately by erasing the e-mail from your computer, and proceed to inform the recipient by replying this electronic mail. It is formally notified that any and all dissemination, distribution, reproduction, copying or use of this information, by any other persons who are not the recipients, is strictly prohibited. Any opinions expressed in this message are of the property of the author and do not necessarily express or coincide with those of TRICOM, S.A. www.tricom.net From morrowc.lists at gmail.com Mon Aug 12 00:30:48 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 11 Aug 2013 20:30:48 -0400 Subject: Google Play Store - Is not working In-Reply-To: <22716198AAB328468DE93087C990A64F1A80236E@SVREX0.TRICOMRD.COM> References: <22716198AAB328468DE93087C990A64F1A7AC5A1@SVREX0.TRICOMRD.COM> <22716198AAB328468DE93087C990A64F1A80236E@SVREX0.TRICOMRD.COM> Message-ID: On Sun, Aug 11, 2013 at 6:59 PM, Amaury Rodriguez, TRI wrote: > Hello Christ, > > The IP Block is 186.50/16. do you not announce all of that block on purpose? (only smaller portions of the /16 are announced globally) > > We receive a mail from On Call Google Engineer. > yup, I think they are also waiting on the reply to: "what part of the /16 and is that part announced globally?" or that's a question I asked to be asked :) > > > Best Regards, > > Fuera de Aqui nada se Vive Mejor! > Amaury Rodriguez | Senior IP Engineer | TRICOM S.A. > Phone: 809.476.6000 | Office: 809.334.7001 | Cell: 809.628.2047 | Mail: amrodriguez at tricom.com.do | Site: www.tricom.net > ? Please consider the environment before you print this e-mail. > > > -----Original Message----- > From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow > Sent: Friday, August 09, 2013 10:45 PM > To: Amaury Rodriguez, TRI > Cc: nanog list; Jose Osoria, TRI; Jose Ventura, TRI; Gamalier Sanchez, TRI > Subject: Re: Google Play Store - Is not working > > On Fri, Aug 9, 2013 at 8:08 PM, Amaury Rodriguez, TRI > wrote: >> We have localization issues with our newly assigned IP block from >> LACNIC. > > always super helpful to include what ip block you mean... else it's a > bit harder to tell what's going on, eh? > > > Importante: Este mensaje o correo electrnico y todos sus archivos adjuntos pueden contener informacin confidencial y es exclusivamente para el uso del individuo o entidad al cual es enviado. Si usted no es el destinatario del mismo favor desecharlo inmediatamente, borrndolo de su computadora, y proceda a informar al remitente respondiendo este correo electrnico. Queda formalmente notificado que cualquier divulgacin, distribucin, reproduccin, copiado o uso de esta informacin, por otras personas que no sean las destinatarias, queda estrictamente prohibido. Las opiniones expresadas en este mensaje son propias del autor y no necesariamente coinciden con las de TRICOM, S.A. www.tricom.net > > Important: This message or electronic mail and all attached files therein could contain confidential information and it is of the exclusive use of the individual or entity to which it is sent. If you are not the intended user of the message, please discard it immediately by erasing the e-mail from your computer, and proceed to inform the recipient by replying this electronic mail. It is formally notified that any and all dissemination, distribution, reproduction, copying or use of this information, by any other persons who are not the recipients, is strictly prohibited. Any opinions expressed in this message are of the property of the author and do not necessarily express or coincide with those of TRICOM, S.A. www.tricom.net > From Amrodriguez at tricom.com.do Mon Aug 12 00:51:44 2013 From: Amrodriguez at tricom.com.do (Amaury Rodriguez, TRI) Date: Sun, 11 Aug 2013 20:51:44 -0400 Subject: Google Play Store - Is not working In-Reply-To: References: <22716198AAB328468DE93087C990A64F1A7AC5A1@SVREX0.TRICOMRD.COM><22716198AAB328468DE93087C990A64F1A80236E@SVREX0.TRICOMRD.COM> Message-ID: <22716198AAB328468DE93087C990A64F1A802376@SVREX0.TRICOMRD.COM> Christ, Is correct. Only a portion is actually in use for customers. We will used as required. We have been testing for different segment within /16 and the issue is the same. The block is announced to our internet providers. We can see at route servers. Regards, Fuera de Aqui nada se Vive Mejor! Amaury Rodriguez | Senior IP Engineer?|?TRICOM S.A.? Phone: 809.476.6000 | Office: 809.334.7001 |?Cell: 809.628.2047 | Mail: amrodriguez at tricom.com.do | Site: www.tricom.net? ? Please consider the environment before you print this e-mail. ? -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Sunday, August 11, 2013 8:31 PM To: Amaury Rodriguez, TRI Cc: nanog list; Jose Osoria, TRI; Jose Ventura, TRI; Gamalier Sanchez, TRI Subject: Re: Google Play Store - Is not working On Sun, Aug 11, 2013 at 6:59 PM, Amaury Rodriguez, TRI wrote: > Hello Christ, > > The IP Block is 186.50/16. do you not announce all of that block on purpose? (only smaller portions of the /16 are announced globally) > > We receive a mail from On Call Google Engineer. > yup, I think they are also waiting on the reply to: "what part of the /16 and is that part announced globally?" or that's a question I asked to be asked :) > > > Best Regards, > > Fuera de Aqui nada se Vive Mejor! > Amaury Rodriguez | Senior IP Engineer | TRICOM S.A. > Phone: 809.476.6000 | Office: 809.334.7001 | Cell: 809.628.2047 | Mail: amrodriguez at tricom.com.do | Site: www.tricom.net > ? Please consider the environment before you print this e-mail. > > > -----Original Message----- > From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow > Sent: Friday, August 09, 2013 10:45 PM > To: Amaury Rodriguez, TRI > Cc: nanog list; Jose Osoria, TRI; Jose Ventura, TRI; Gamalier Sanchez, TRI > Subject: Re: Google Play Store - Is not working > > On Fri, Aug 9, 2013 at 8:08 PM, Amaury Rodriguez, TRI > wrote: >> We have localization issues with our newly assigned IP block from >> LACNIC. > > always super helpful to include what ip block you mean... else it's a > bit harder to tell what's going on, eh? > > > Importante: Este mensaje o correo electrnico y todos sus archivos adjuntos pueden contener informacin confidencial y es exclusivamente para el uso del individuo o entidad al cual es enviado. Si usted no es el destinatario del mismo favor desecharlo inmediatamente, borrndolo de su computadora, y proceda a informar al remitente respondiendo este correo electrnico. Queda formalmente notificado que cualquier divulgacin, distribucin, reproduccin, copiado o uso de esta informacin, por otras personas que no sean las destinatarias, queda estrictamente prohibido. Las opiniones expresadas en este mensaje son propias del autor y no necesariamente coinciden con las de TRICOM, S.A. www.tricom.net > > Important: This message or electronic mail and all attached files therein could contain confidential information and it is of the exclusive use of the individual or entity to which it is sent. If you are not the intended user of the message, please discard it immediately by erasing the e-mail from your computer, and proceed to inform the recipient by replying this electronic mail. It is formally notified that any and all dissemination, distribution, reproduction, copying or use of this information, by any other persons who are not the recipients, is strictly prohibited. Any opinions expressed in this message are of the property of the author and do not necessarily express or coincide with those of TRICOM, S.A. www.tricom.net > Importante: Este mensaje o correo electrnico y todos sus archivos adjuntos pueden contener informacin confidencial y es exclusivamente para el uso del individuo o entidad al cual es enviado. Si usted no es el destinatario del mismo favor desecharlo inmediatamente, borrndolo de su computadora, y proceda a informar al remitente respondiendo este correo electrnico. Queda formalmente notificado que cualquier divulgacin, distribucin, reproduccin, copiado o uso de esta informacin, por otras personas que no sean las destinatarias, queda estrictamente prohibido. Las opiniones expresadas en este mensaje son propias del autor y no necesariamente coinciden con las de TRICOM, S.A. www.tricom.net Important: This message or electronic mail and all attached files therein could contain confidential information and it is of the exclusive use of the individual or entity to which it is sent. If you are not the intended user of the message, please discard it immediately by erasing the e-mail from your computer, and proceed to inform the recipient by replying this electronic mail. It is formally notified that any and all dissemination, distribution, reproduction, copying or use of this information, by any other persons who are not the recipients, is strictly prohibited. Any opinions expressed in this message are of the property of the author and do not necessarily express or coincide with those of TRICOM, S.A. www.tricom.net From randy at psg.com Mon Aug 12 01:08:16 2013 From: randy at psg.com (Randy Bush) Date: Mon, 12 Aug 2013 10:08:16 +0900 Subject: Google Play Store - Is not working In-Reply-To: <22716198AAB328468DE93087C990A64F1A802376@SVREX0.TRICOMRD.COM> References: <22716198AAB328468DE93087C990A64F1A7AC5A1@SVREX0.TRICOMRD.COM> <22716198AAB328468DE93087C990A64F1A80236E@SVREX0.TRICOMRD.COM> <22716198AAB328468DE93087C990A64F1A802376@SVREX0.TRICOMRD.COM> Message-ID: > The block is announced to our internet providers. We can see at route > servers. then you are using different route servers than i am route-views>sh ip bg 186.50.0.0 BGP routing table entry for 186.50.0.0/20, version 307454 ^^^ randy From morrowc.lists at gmail.com Mon Aug 12 02:32:50 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 11 Aug 2013 22:32:50 -0400 Subject: Google Play Store - Is not working In-Reply-To: References: <22716198AAB328468DE93087C990A64F1A7AC5A1@SVREX0.TRICOMRD.COM> <22716198AAB328468DE93087C990A64F1A80236E@SVREX0.TRICOMRD.COM> <22716198AAB328468DE93087C990A64F1A802376@SVREX0.TRICOMRD.COM> Message-ID: On Sun, Aug 11, 2013 at 9:21 PM, Gamalier Sanchez, TRI wrote: > Just a little correction about the block. > > It's the 186.150/16 > > Maybe the block available to look from a route server is a /19 subnet. > > sure. so... maybe you could send an update to the opened ticket with google with an example source-/32 that's a problem? -chris > > El 11/08/2013, a las 21:08, "Randy Bush" escribi?: > >>> The block is announced to our internet providers. We can see at route >>> servers. >> >> then you are using different route servers than i am >> >> route-views>sh ip bg 186.50.0.0 >> BGP routing table entry for 186.50.0.0/20, version 307454 >> ^^^ >> randy > > > Importante: Este mensaje o correo electrnico y todos sus archivos adjuntos pueden contener informacin confidencial y es exclusivamente para el uso del individuo o entidad al cual es enviado. Si usted no es el destinatario del mismo favor desecharlo inmediatamente, borrndolo de su computadora, y proceda a informar al remitente respondiendo este correo electrnico. Queda formalmente notificado que cualquier divulgacin, distribucin, reproduccin, copiado o uso de esta informacin, por otras personas que no sean las destinatarias, queda estrictamente prohibido. Las opiniones expresadas en este mensaje son propias del autor y no necesariamente coinciden con las de TRICOM, S.A. www.tricom.net > > Important: This message or electronic mail and all attached files therein could contain confidential information and it is of the exclusive use of the individual or entity to which it is sent. If you are not the intended user of the message, please discard it immediately by erasing the e-mail from your computer, and proceed to inform the recipient by replying this electronic mail. It is formally notified that any and all dissemination, distribution, reproduction, copying or use of this information, by any other persons who are not the recipients, is strictly prohibited. Any opinions expressed in this message are of the property of the author and do not necessarily express or coincide with those of TRICOM, S.A. www.tricom.net > From sh.vahabzadeh at gmail.com Mon Aug 12 07:51:00 2013 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Mon, 12 Aug 2013 12:21:00 +0430 Subject: Native VLAN for Huawei MA5616 DSLAM In-Reply-To: <722B9A48-BEB6-4573-A437-CC48B0EFF83F@huawei.com> References: <520779EF.2090608@gmail.com> <722B9A48-BEB6-4573-A437-CC48B0EFF83F@huawei.com> Message-ID: Dear Tina, Thanks for your reply, I have done the same example you told but there is no native-vlan command inside interface eth 0/0. here my configuration and version of device, maybe firmare does not support it. MA5616#display current-configuration > > [vlan-config] > > vlan 2 smart > port vlan 2 0/0 0 > MA5616#display board 0 > ------------------------------------------------------------------------- > SlotID BoardName Status SubType0 SubType1 Online/Offline > ------------------------------------------------------------------------- > 0 H831CCUB Active_normal EP1A ASDA > 1 H835ADLE Auto_find > 2 H835ADLE Auto_find > 3 H835ADLE Auto_find > 4 H835ADLE Auto_find > 5 H831PDIA Normal > ------------------------------------------------------------------------- > MA5616#display version > > Command: > display version > > VERSION : MA5616V800R308C01 > PATCH : SPC200 SPH508 HP2108 > PRODUCT : MA5616 > > Mainboard Running Area Information: > -------------------------------------------- > Current Program Area : Area A > Current Data Area : Area A > > Program Area A Version : MA5616V800R308C01 > Program Area B Version : MA5616V800R308C01 > > Data Area A Version : MA5616V800R308C01 > Data Area B Version : MA5616V800R308C01 > -------------------------------------------- > MA5616(config)#interface eth 0/0 > > MA5616(config-if-eth-0/0)#? > --------------------------------------------- > Command of eth Mode: > --------------------------------------------- > auto-neg Enable/Disable port negotiation > combo-mode Switch working mode of COMBO port > display Display information > duplex Set duplex > flow-control Support flow control > line Line test > mdi Line-adaptive function > mirror Add mirror > network-role Network role > port Set TX optical power threshold > quit Exit from current mode and enter prior mode > reset Clear port statistics > return Enter the privileged mode > shutdown Deactivate port > speed Rate > switch Switch language mode > traffic-suppress Set port traffic suppression > undo Negate a command or set its defaults > Thanks On Mon, Aug 12, 2013 at 5:51 AM, Tina TSOU wrote: > Dear all, > Only for the uplink GE, the native VLAN can be configured, it can not be > configured for NNI EPON/GPON and UNI DSL port. > > //if the uplink port is GE, then configure a new VLAN 2 > huawei(config)#vlan 2 > //add the uplink GE 0/0 0 to VLAN 2 > huawei(config)#port vlan 2 0/0 0 > //change to uplink card interface view > huawei(config)#interface eth 0/0 > //change native vlan of uplink GE to 2 > huawei(config-if-eth-0/0)#native-vlan 0 vlan 2 > > > Thank you, > Tina > > On Aug 11, 2013, at 6:44 AM, "Shahab Vahabzadeh" > wrote: > > > Only these interface's are available under: > > > > MA5616(config)# interface ? > >> adsl > >> emu > >> eponnni > >> eth > >> gponnni > >> h248 > >> loopback > >> meth > >> null > >> shl > >> vdsl > >> vlanif > > > > > > Thanks > > > > > > On Sun, Aug 11, 2013 at 4:55 PM, Shahab Vahabzadeh > > wrote: > > > >> Dear Georgi, > >> MA5616 does not have any SCU interface... > >> What can we do? > >> > >> > >> On Sun, Aug 11, 2013 at 4:17 PM, Georgi Genov >wrote: > >> > >>> It`s configurable under scu/scuh/giu board > >>> > >>> interface scu 0/9 > >>> native-vlan 1 vlan XXXX > >>> native-vlan 2 vlan YYYY > >>> or > >>> interface giu 0/19 > >>> native-vlan 1 vlan XXXX > >>> native-vlan 2 vlan YYYY > >>> > >>> On 11.8.2013 ?. 09:33 ?., Shahab Vahabzadeh wrote: > >>> > >>>> Dear Friends, > >>>> Anybody have idea about changing native vlan on Huawei MA5616 DSLAM? > >>>> I can not find the correct syntax, there is no option under "interface > >>>> eth > >>>> 0/0" > >>>> Thanks > >> > >> > >> -- > >> Regards, > >> Shahab Vahabzadeh, Network Engineer and System Administrator > >> > >> Cell Phone: +1 (415) 871 0742 > >> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 > > > > > > > > -- > > Regards, > > Shahab Vahabzadeh, Network Engineer and System Administrator > > > > Cell Phone: +1 (415) 871 0742 > > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 > -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From raj at rajlog.com Mon Aug 12 17:12:37 2013 From: raj at rajlog.com (Raj Jalan) Date: Mon, 12 Aug 2013 13:12:37 -0400 Subject: IPAM In-Reply-To: <9FFA8B2148100D40969011DAEEB56FD00266C9DF0B30@server.fasttrackcomm.local> References: <9FFA8B2148100D40969011DAEEB56FD00266C9DF0B30@server.fasttrackcomm.local> Message-ID: If you are using Postgresql with Northstar, you should be able to export data to csv with a command like following: COPY table_name TO '/tmp/file_name.csv' DELIMITER ',' CSV HEADER; If you are using mysql as your DB in Northstart, you can do something like this to create a CSV file: SELECT * INTO OUTFILE '/tmp/file_name.csv' FIELDS TERMINATED BY ',' ENCLOSED BY '"' ESCAPED BY '\\' LINES TERMINATED BY '\n' FROM table_name Once you create the csv file, most of tools can import it. One more tool to checkout is device42(http://www.device42.com) which has extensive import and auto-discovery options. On Wed, Aug 7, 2013 at 12:41 PM, Natambu Obleton wrote: > I have customer that we deployed Northstar for their internal ip > management over 8 yrs ago. They are still using it, but it is slowly > breaking on them. Can someone recommend an IPAM solution that has a > Northstar import option? They have hundreds of entries detailing customer > who was assigned the ip address and I would like to avoid any data > massaging. TIA > > > > -- > > Natambu Obleton, CISSP CCIE > Senior Network Engineer > FastTrack Communications, Inc. > 970.828.1009 > > From amitchell at isipp.com Mon Aug 12 18:00:22 2013 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Mon, 12 Aug 2013 12:00:22 -0600 Subject: Looking for a part-time contractor.. Message-ID: All, I hope this is an ok place to post this - the people on this list have a unique skill-set and world view that is exactly in synch with that for which we are looking. :-) We're looking for someone for some very limited (in terms of hours) part-time contract work..but ongoing, regular work? the person needs to have a keen sense of "why did this email fail delivery" and/or "why is this email going to the junk folder" and "why did this email end up blacklisted" (this is for email sent by white hat senders, or at very least senders who are trying to be white hat - *not* for black hat stuff). So, basically, someone who, when shown an email (full headers, etc.) their first thought would be to check whether authentication was set up properly, is rDNS set up properly, what does the content look like, what are the IPs of the various hops and are any of them blacklisted, etc. etc.. If anyone here has that background/skill set and might be interested in, say, 5 to 10 hours a week extra work (remote, time of day not important so long as they are available most days, so ideal for picking up some extra cash after $DAYJOB), please let me know offlist. Please also feel free to send this to anyone you think might be a good fit, so long as you'd be willing to vouch for them. Thanks! Anne Anne P. Mitchell, Attorney at Law Author: Section 6 of the CAN-SPAM Act of 2003 CEO/President: Institute for Social Internet Public Policy Providers: SuretyMail Email Accreditation Member: California Bar Cyberspace Law Committee From chris.paul at rexconsulting.net Mon Aug 12 18:12:35 2013 From: chris.paul at rexconsulting.net (Chris Paul) Date: Mon, 12 Aug 2013 11:12:35 -0700 (PDT) Subject: Looking for a part-time contractor.. In-Reply-To: References: Message-ID: <87609671.2487.1376331155680.JavaMail.root@rexconsulting.net> Hi Anne, I've been troubleshooting email since supporting Worldtalk's X.400 gateway in the 1990s. Since then, I've been a professional SMTP and LDAP consultant. My current clients are AT&T, The Gap, and SKHMS. I have just barely 5-10 hours a week but since I've been looking for a house to buy here in California since March, the prices have increased by 10% and upwards, so I'm kind of motivated to work extra right now. The thing though is you might find someone cheaper than me. I'll quote you $150/hour for this work right now. Many thanks! CP -- Chris Paul Rex Consulting, Inc 231 Market Place #149, San Ramon, CA 94583 email: chris.paul at rexconsulting.net web: http://www.rexconsulting.net phone, toll-free: +1 (888) 403-8996 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. is a California Corporation. ----- Original Message ----- > All, > > I hope this is an ok place to post this - the people on this list have a > unique skill-set and world view that is exactly in synch with that for which > we are looking. :-) > > We're looking for someone for some very limited (in terms of hours) part-time > contract work..but ongoing, regular work? the person needs to have a keen > sense of "why did this email fail delivery" and/or "why is this email going > to the junk folder" and "why did this email end up blacklisted" (this is for > email sent by white hat senders, or at very least senders who are trying to > be white hat - *not* for black hat stuff). > > So, basically, someone who, when shown an email (full headers, etc.) their > first thought would be to check whether authentication was set up properly, > is rDNS set up properly, what does the content look like, what are the IPs > of the various hops and are any of them blacklisted, etc. etc.. > > If anyone here has that background/skill set and might be interested in, say, > 5 to 10 hours a week extra work (remote, time of day not important so long > as they are available most days, so ideal for picking up some extra cash > after $DAYJOB), please let me know offlist. Please also feel free to send > this to anyone you think might be a good fit, so long as you'd be willing to > vouch for them. > > Thanks! > > Anne > > Anne P. Mitchell, Attorney at Law > Author: Section 6 of the CAN-SPAM Act of 2003 > CEO/President: Institute for Social Internet Public Policy > Providers: SuretyMail Email Accreditation > Member: California Bar Cyberspace Law Committee > > > From aaron at heyaaron.com Mon Aug 12 18:21:28 2013 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Mon, 12 Aug 2013 11:21:28 -0700 Subject: Looking for a part-time contractor.. In-Reply-To: <87609671.2487.1376331155680.JavaMail.root@rexconsulting.net> References: <87609671.2487.1376331155680.JavaMail.root@rexconsulting.net> Message-ID: Count me in at $149.95/hr. ;) -A On Mon, Aug 12, 2013 at 11:12 AM, Chris Paul wrote: > Hi Anne, > > I've been troubleshooting email since supporting Worldtalk's X.400 gateway > in the 1990s. Since then, I've been a professional SMTP and LDAP > consultant. My current clients are AT&T, The Gap, and SKHMS. I have just > barely 5-10 hours a week but since I've been looking for a house to buy > here in California since March, the prices have increased by 10% and > upwards, so I'm kind of motivated to work extra right now. > > The thing though is you might find someone cheaper than me. I'll quote you > $150/hour for this work right now. > > Many thanks! > > CP > > -- > Chris Paul > Rex Consulting, Inc > 231 Market Place #149, San Ramon, CA 94583 > email: chris.paul at rexconsulting.net > web: http://www.rexconsulting.net > phone, toll-free: +1 (888) 403-8996 > > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, > or taking of any action in reliance upon, this information by persons > or entities other than the intended recipient is prohibited. > Rex Consulting, Inc. is a California Corporation. > > ----- Original Message ----- > > All, > > > > I hope this is an ok place to post this - the people on this list have a > > unique skill-set and world view that is exactly in synch with that for > which > > we are looking. :-) > > > > We're looking for someone for some very limited (in terms of hours) > part-time > > contract work..but ongoing, regular work? the person needs to have a keen > > sense of "why did this email fail delivery" and/or "why is this email > going > > to the junk folder" and "why did this email end up blacklisted" (this is > for > > email sent by white hat senders, or at very least senders who are trying > to > > be white hat - *not* for black hat stuff). > > > > So, basically, someone who, when shown an email (full headers, etc.) > their > > first thought would be to check whether authentication was set up > properly, > > is rDNS set up properly, what does the content look like, what are the > IPs > > of the various hops and are any of them blacklisted, etc. etc.. > > > > If anyone here has that background/skill set and might be interested in, > say, > > 5 to 10 hours a week extra work (remote, time of day not important so > long > > as they are available most days, so ideal for picking up some extra cash > > after $DAYJOB), please let me know offlist. Please also feel free to > send > > this to anyone you think might be a good fit, so long as you'd be > willing to > > vouch for them. > > > > Thanks! > > > > Anne > > > > Anne P. Mitchell, Attorney at Law > > Author: Section 6 of the CAN-SPAM Act of 2003 > > CEO/President: Institute for Social Internet Public Policy > > Providers: SuretyMail Email Accreditation > > Member: California Bar Cyberspace Law Committee > > > > > > > > From bmeshier at amherst.com Mon Aug 12 18:35:44 2013 From: bmeshier at amherst.com (Meshier, Brent) Date: Mon, 12 Aug 2013 18:35:44 +0000 Subject: COX contact Message-ID: <68C2CBC977F3E04799DF9C76E938E7090813BA6F@DFEXCH1.asglp.com> Can someone at COX contact me off-list to troubleshoot packet loss I'm seeing on langbprj02-ae2.rd.la.cox.net I've tried tech support but they only seem to be concerned about signal strength rather than peering issues. --- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for important disclosures regarding this electronic communication. From ikiris at gmail.com Mon Aug 12 18:50:52 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 12 Aug 2013 13:50:52 -0500 Subject: Looking for a part-time contractor.. In-Reply-To: References: Message-ID: The email address you're sending from is for a service that does what you're asking for, and your signature lists you as the CEO, so I guess all I can say is, in the words of Bob: "What would ya say... ya do here?" -Blake On Mon, Aug 12, 2013 at 1:00 PM, Anne P. Mitchell, Esq. wrote: > All, > > I hope this is an ok place to post this - the people on this list have a > unique skill-set and world view that is exactly in synch with that for > which we are looking. :-) > > We're looking for someone for some very limited (in terms of hours) > part-time contract work..but ongoing, regular work? the person needs to > have a keen sense of "why did this email fail delivery" and/or "why is this > email going to the junk folder" and "why did this email end up blacklisted" > (this is for email sent by white hat senders, or at very least senders who > are trying to be white hat - *not* for black hat stuff). > > So, basically, someone who, when shown an email (full headers, etc.) their > first thought would be to check whether authentication was set up properly, > is rDNS set up properly, what does the content look like, what are the IPs > of the various hops and are any of them blacklisted, etc. etc.. > > If anyone here has that background/skill set and might be interested in, > say, 5 to 10 hours a week extra work (remote, time of day not important so > long as they are available most days, so ideal for picking up some extra > cash after $DAYJOB), please let me know offlist. Please also feel free to > send this to anyone you think might be a good fit, so long as you'd be > willing to vouch for them. > > Thanks! > > Anne > > Anne P. Mitchell, Attorney at Law > Author: Section 6 of the CAN-SPAM Act of 2003 > CEO/President: Institute for Social Internet Public Policy > Providers: SuretyMail Email Accreditation > Member: California Bar Cyberspace Law Committee > > > From amitchell at isipp.com Mon Aug 12 18:57:06 2013 From: amitchell at isipp.com (Anne P. Mitchell, Esq. ) Date: Mon, 12 Aug 2013 12:57:06 -0600 Subject: Looking for a part-time contractor.. In-Reply-To: References: Message-ID: <9D9EDD59-9B9A-4324-B512-A529BA1DD7F2@isipp.com> We need someone to help with some overflow. :-) Dictated on my phone, apologies for any tupos. On Aug 12, 2013, at 12:50 PM, Blake Dunlap wrote: > The email address you're sending from is for a service that does what you're asking for, and your signature lists you as the CEO, so I guess all I can say is, in the words of Bob: "What would ya say... ya do here?" > > -Blake > > > On Mon, Aug 12, 2013 at 1:00 PM, Anne P. Mitchell, Esq. wrote: >> All, >> >> I hope this is an ok place to post this - the people on this list have a unique skill-set and world view that is exactly in synch with that for which we are looking. :-) >> >> We're looking for someone for some very limited (in terms of hours) part-time contract work..but ongoing, regular work? the person needs to have a keen sense of "why did this email fail delivery" and/or "why is this email going to the junk folder" and "why did this email end up blacklisted" (this is for email sent by white hat senders, or at very least senders who are trying to be white hat - *not* for black hat stuff). >> >> So, basically, someone who, when shown an email (full headers, etc.) their first thought would be to check whether authentication was set up properly, is rDNS set up properly, what does the content look like, what are the IPs of the various hops and are any of them blacklisted, etc. etc.. >> >> If anyone here has that background/skill set and might be interested in, say, 5 to 10 hours a week extra work (remote, time of day not important so long as they are available most days, so ideal for picking up some extra cash after $DAYJOB), please let me know offlist. Please also feel free to send this to anyone you think might be a good fit, so long as you'd be willing to vouch for them. >> >> Thanks! >> >> Anne >> >> Anne P. Mitchell, Attorney at Law >> Author: Section 6 of the CAN-SPAM Act of 2003 >> CEO/President: Institute for Social Internet Public Policy >> Providers: SuretyMail Email Accreditation >> Member: California Bar Cyberspace Law Committee > From rdrake at direcpath.com Mon Aug 12 20:20:51 2013 From: rdrake at direcpath.com (rdrake) Date: Mon, 12 Aug 2013 16:20:51 -0400 Subject: COX contact In-Reply-To: <68C2CBC977F3E04799DF9C76E938E7090813BA6F@DFEXCH1.asglp.com> References: <68C2CBC977F3E04799DF9C76E938E7090813BA6F@DFEXCH1.asglp.com> Message-ID: <520943A3.5080805@direcpath.com> On 08/12/2013 02:35 PM, Meshier, Brent wrote: > I've tried tech support but they only seem to be concerned about signal strength rather than peering issues. > > --- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for important disclosures regarding this electronic communication. > I checked your email headers and it doesn't include the signal strength. Can you include that in the subject line in future emails? Also since they didn't indicate what to measure or what units, I would say that my signal strength currently is 5. Oh, and if you have a signal strength meter that only goes to 10 you need to buy the better one that goes to 11. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From tknchris at gmail.com Mon Aug 12 20:31:13 2013 From: tknchris at gmail.com (chris) Date: Mon, 12 Aug 2013 16:31:13 -0400 Subject: COX contact In-Reply-To: <68C2CBC977F3E04799DF9C76E938E7090813BA6F@DFEXCH1.asglp.com> References: <68C2CBC977F3E04799DF9C76E938E7090813BA6F@DFEXCH1.asglp.com> Message-ID: Let me guess MTR is telling you about this packetloss? :) On Mon, Aug 12, 2013 at 2:35 PM, Meshier, Brent wrote: > Can someone at COX contact me off-list to troubleshoot packet loss I'm > seeing on langbprj02-ae2.rd.la.cox.net > > I've tried tech support but they only seem to be concerned about signal > strength rather than peering issues. > > --- Please refer to http://www.amherst.com/amherst-email-disclaimer/ for > important disclosures regarding this electronic communication. > From laicanac at gmail.com Mon Aug 12 17:24:57 2013 From: laicanac at gmail.com (=?ISO-8859-1?Q?COULIBALY_La=EFcana?=) Date: Mon, 12 Aug 2013 17:24:57 +0000 Subject: IPAM In-Reply-To: References: <9FFA8B2148100D40969011DAEEB56FD00266C9DF0B30@server.fasttrackcomm.local> Message-ID: Raj Jalan is right 2013/8/12 Raj Jalan > If you are using Postgresql with Northstar, you should be able to export > data to csv with a command like following: > > COPY table_name TO '/tmp/file_name.csv' DELIMITER ',' CSV HEADER; > > If you are using mysql as your DB in Northstart, you can do something like > this to create a CSV file: > > SELECT * > INTO OUTFILE '/tmp/file_name.csv' > FIELDS TERMINATED BY ',' > ENCLOSED BY '"' > ESCAPED BY '\\' > LINES TERMINATED BY '\n' > FROM table_name > > Once you create the csv file, most of tools can import it. One more tool to > checkout is device42(http://www.device42.com) which has extensive import > and auto-discovery options. > > > > > > On Wed, Aug 7, 2013 at 12:41 PM, Natambu Obleton < > nobleton at fasttrackcomm.net > > wrote: > > > I have customer that we deployed Northstar for their internal ip > > management over 8 yrs ago. They are still using it, but it is slowly > > breaking on them. Can someone recommend an IPAM solution that has a > > Northstar import option? They have hundreds of entries detailing customer > > who was assigned the ip address and I would like to avoid any data > > massaging. TIA > > > > > > > > -- > > > > Natambu Obleton, CISSP CCIE > > Senior Network Engineer > > FastTrack Communications, Inc. > > 970.828.1009 > > > > > -- *=====================================* *Coulibaly La?cana* *IT Security auditor* *Web developer* *Skype:lecgates* *Phone: +22505547261* From Tina.Tsou.Zouting at huawei.com Tue Aug 13 01:59:47 2013 From: Tina.Tsou.Zouting at huawei.com (Tina TSOU) Date: Tue, 13 Aug 2013 01:59:47 +0000 Subject: Native VLAN for Huawei MA5616 DSLAM In-Reply-To: References: <520779EF.2090608@gmail.com> <722B9A48-BEB6-4573-A437-CC48B0EFF83F@huawei.com> Message-ID: Dear Shahab, Thank you for more information. CCUB main board doesn?t support native-VLAN setting, only CCUE main board supports it, the version should be upgraded to R312 above. Thank you, Tina From: Shahab Vahabzadeh [mailto:sh.vahabzadeh at gmail.com] Sent: 2013?8?12? 0:51 To: Tina TSOU; Zharov Oleg; nanog Cc: Georgi Genov Subject: Re: Native VLAN for Huawei MA5616 DSLAM Dear Tina, Thanks for your reply, I have done the same example you told but there is no native-vlan command inside interface eth 0/0. here my configuration and version of device, maybe firmare does not support it. MA5616#display current-configuration [vlan-config] vlan 2 smart port vlan 2 0/0 0 MA5616#display board 0 ------------------------------------------------------------------------- SlotID BoardName Status SubType0 SubType1 Online/Offline ------------------------------------------------------------------------- 0 H831CCUB Active_normal EP1A ASDA 1 H835ADLE Auto_find 2 H835ADLE Auto_find 3 H835ADLE Auto_find 4 H835ADLE Auto_find 5 H831PDIA Normal ------------------------------------------------------------------------- MA5616#display version Command: display version VERSION : MA5616V800R308C01 PATCH : SPC200 SPH508 HP2108 PRODUCT : MA5616 Mainboard Running Area Information: -------------------------------------------- Current Program Area : Area A Current Data Area : Area A Program Area A Version : MA5616V800R308C01 Program Area B Version : MA5616V800R308C01 Data Area A Version : MA5616V800R308C01 Data Area B Version : MA5616V800R308C01 -------------------------------------------- MA5616(config)#interface eth 0/0 MA5616(config-if-eth-0/0)#? --------------------------------------------- Command of eth Mode: --------------------------------------------- auto-neg Enable/Disable port negotiation combo-mode Switch working mode of COMBO port display Display information duplex Set duplex flow-control Support flow control line Line test mdi Line-adaptive function mirror Add mirror network-role Network role port Set TX optical power threshold quit Exit from current mode and enter prior mode reset Clear port statistics return Enter the privileged mode shutdown Deactivate port speed Rate switch Switch language mode traffic-suppress Set port traffic suppression undo Negate a command or set its defaults Thanks On Mon, Aug 12, 2013 at 5:51 AM, Tina TSOU > wrote: Dear all, Only for the uplink GE, the native VLAN can be configured, it can not be configured for NNI EPON/GPON and UNI DSL port. //if the uplink port is GE, then configure a new VLAN 2 huawei(config)#vlan 2 //add the uplink GE 0/0 0 to VLAN 2 huawei(config)#port vlan 2 0/0 0 //change to uplink card interface view huawei(config)#interface eth 0/0 //change native vlan of uplink GE to 2 huawei(config-if-eth-0/0)#native-vlan 0 vlan 2 Thank you, Tina On Aug 11, 2013, at 6:44 AM, "Shahab Vahabzadeh" > wrote: > Only these interface's are available under: > > MA5616(config)# interface ? >> adsl >> emu >> eponnni >> eth >> gponnni >> h248 >> loopback >> meth >> null >> shl >> vdsl >> vlanif > > > Thanks > > > On Sun, Aug 11, 2013 at 4:55 PM, Shahab Vahabzadeh > >wrote: > >> Dear Georgi, >> MA5616 does not have any SCU interface... >> What can we do? >> >> >> On Sun, Aug 11, 2013 at 4:17 PM, Georgi Genov >wrote: >> >>> It`s configurable under scu/scuh/giu board >>> >>> interface scu 0/9 >>> native-vlan 1 vlan XXXX >>> native-vlan 2 vlan YYYY >>> or >>> interface giu 0/19 >>> native-vlan 1 vlan XXXX >>> native-vlan 2 vlan YYYY >>> >>> On 11.8.2013 ?. 09:33 ?., Shahab Vahabzadeh wrote: >>> >>>> Dear Friends, >>>> Anybody have idea about changing native vlan on Huawei MA5616 DSLAM? >>>> I can not find the correct syntax, there is no option under "interface >>>> eth >>>> 0/0" >>>> Thanks >> >> >> -- >> Regards, >> Shahab Vahabzadeh, Network Engineer and System Administrator >> >> Cell Phone: +1 (415) 871 0742 >> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 > > > > -- > Regards, > Shahab Vahabzadeh, Network Engineer and System Administrator > > Cell Phone: +1 (415) 871 0742 > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From sh.vahabzadeh at gmail.com Tue Aug 13 09:48:12 2013 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Tue, 13 Aug 2013 14:18:12 +0430 Subject: Native VLAN for Huawei MA5616 DSLAM In-Reply-To: References: <520779EF.2090608@gmail.com> <722B9A48-BEB6-4573-A437-CC48B0EFF83F@huawei.com> Message-ID: Dear Tina, How can I upgrade the version? main board must change or it can upgrade with changing software/firmware? Thank On Tue, Aug 13, 2013 at 6:29 AM, Tina TSOU wrote: > Dear Shahab,**** > > Thank you for more information.**** > > CCUB main board doesn?t support native-VLAN setting, only CCUE main board > supports it, the version should be upgraded to R312 above.**** > > ** ** > > Thank you,**** > > Tina**** > > ** ** > > *From:* Shahab Vahabzadeh [mailto:sh.vahabzadeh at gmail.com] > *Sent:* 2013?8?12? 0:51 > *To:* Tina TSOU; Zharov Oleg; nanog > *Cc:* Georgi Genov > > *Subject:* Re: Native VLAN for Huawei MA5616 DSLAM**** > > ** ** > > Dear Tina, > Thanks for your reply, **** > > I have done the same example you told but there is no native-vlan command > inside interface eth 0/0. > here my configuration and version of device, maybe firmare does not > support it.**** > > MA5616#display current-configuration > > [vlan-config] > > vlan 2 smart > port vlan 2 0/0 0**** > > ** ** > > MA5616#display board 0 > ------------------------------------------------------------------------- > SlotID BoardName Status SubType0 SubType1 Online/Offline > ------------------------------------------------------------------------- > 0 H831CCUB Active_normal EP1A ASDA > 1 H835ADLE Auto_find > 2 H835ADLE Auto_find > 3 H835ADLE Auto_find > 4 H835ADLE Auto_find > 5 H831PDIA Normal > ------------------------------------------------------------------------- > **** > > ** ** > > MA5616#display version > > Command: > display version > > VERSION : MA5616V800R308C01 > PATCH : SPC200 SPH508 HP2108 > PRODUCT : MA5616 > > Mainboard Running Area Information: > -------------------------------------------- > Current Program Area : Area A > Current Data Area : Area A > > Program Area A Version : MA5616V800R308C01 > Program Area B Version : MA5616V800R308C01 > > Data Area A Version : MA5616V800R308C01 > Data Area B Version : MA5616V800R308C01 > --------------------------------------------**** > > ** ** > > MA5616(config)#interface eth 0/0 > > MA5616(config-if-eth-0/0)#? > --------------------------------------------- > Command of eth Mode: > --------------------------------------------- > auto-neg Enable/Disable port negotiation > combo-mode Switch working mode of COMBO port > display Display information > duplex Set duplex > flow-control Support flow control > line Line test > mdi Line-adaptive function > mirror Add mirror > network-role Network role > port Set TX optical power threshold > quit Exit from current mode and enter prior mode > reset Clear port statistics > return Enter the privileged mode > shutdown Deactivate port > speed Rate > switch Switch language mode > traffic-suppress Set port traffic suppression > undo Negate a command or set its defaults**** > > ** ** > > Thanks**** > > ** ** > > ** ** > > On Mon, Aug 12, 2013 at 5:51 AM, Tina TSOU > wrote:**** > > Dear all, > Only for the uplink GE, the native VLAN can be configured, it can not be > configured for NNI EPON/GPON and UNI DSL port. > > //if the uplink port is GE, then configure a new VLAN 2 > huawei(config)#vlan 2 > //add the uplink GE 0/0 0 to VLAN 2 > huawei(config)#port vlan 2 0/0 0 > //change to uplink card interface view > huawei(config)#interface eth 0/0 > //change native vlan of uplink GE to 2 > huawei(config-if-eth-0/0)#native-vlan 0 vlan 2 > > > Thank you, > Tina**** > > > On Aug 11, 2013, at 6:44 AM, "Shahab Vahabzadeh" > wrote: > > > Only these interface's are available under: > > > > MA5616(config)# interface ? > >> adsl > >> emu > >> eponnni > >> eth > >> gponnni > >> h248 > >> loopback > >> meth > >> null > >> shl > >> vdsl > >> vlanif > > > > > > Thanks > > > > > > On Sun, Aug 11, 2013 at 4:55 PM, Shahab Vahabzadeh > > wrote: > > > >> Dear Georgi, > >> MA5616 does not have any SCU interface... > >> What can we do? > >> > >> > >> On Sun, Aug 11, 2013 at 4:17 PM, Georgi Genov >wrote: > >> > >>> It`s configurable under scu/scuh/giu board > >>> > >>> interface scu 0/9 > >>> native-vlan 1 vlan XXXX > >>> native-vlan 2 vlan YYYY > >>> or > >>> interface giu 0/19 > >>> native-vlan 1 vlan XXXX > >>> native-vlan 2 vlan YYYY > >>> > >>> On 11.8.2013 ?. 09:33 ?., Shahab Vahabzadeh wrote: > >>> > >>>> Dear Friends, > >>>> Anybody have idea about changing native vlan on Huawei MA5616 DSLAM? > >>>> I can not find the correct syntax, there is no option under "interface > >>>> eth > >>>> 0/0" > >>>> Thanks > >> > >> > >> -- > >> Regards, > >> Shahab Vahabzadeh, Network Engineer and System Administrator > >> > >> Cell Phone: +1 (415) 871 0742 > >> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 > > > > > > > > -- > > Regards, > > Shahab Vahabzadeh, Network Engineer and System Administrator > > > > Cell Phone: +1 (415) 871 0742 > > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 > **** > > > > > -- > Regards, > Shahab Vahabzadeh, Network Engineer and System Administrator > > Cell Phone: +1 (415) 871 0742 > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90** > ** > -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From Tina.Tsou.Zouting at huawei.com Wed Aug 14 03:30:50 2013 From: Tina.Tsou.Zouting at huawei.com (Tina TSOU) Date: Wed, 14 Aug 2013 03:30:50 +0000 Subject: Native VLAN for Huawei MA5616 DSLAM In-Reply-To: References: <520779EF.2090608@gmail.com> <722B9A48-BEB6-4573-A437-CC48B0EFF83F@huawei.com> , Message-ID: Dear Shahab, Thank you for your prompt reply. You can change to CCUE main board, then check the version, as far as I know, the software on CCUE shipped are all R312 above, so u don't need to upgrade software. Thank you, Tina On Aug 13, 2013, at 2:48 AM, "Shahab Vahabzadeh" > wrote: Dear Tina, How can I upgrade the version? main board must change or it can upgrade with changing software/firmware? Thank On Tue, Aug 13, 2013 at 6:29 AM, Tina TSOU > wrote: Dear Shahab, Thank you for more information. CCUB main board doesn?t support native-VLAN setting, only CCUE main board supports it, the version should be upgraded to R312 above. Thank you, Tina From: Shahab Vahabzadeh [mailto:sh.vahabzadeh at gmail.com] Sent: 2013?8?12? 0:51 To: Tina TSOU; Zharov Oleg; nanog Cc: Georgi Genov Subject: Re: Native VLAN for Huawei MA5616 DSLAM Dear Tina, Thanks for your reply, I have done the same example you told but there is no native-vlan command inside interface eth 0/0. here my configuration and version of device, maybe firmare does not support it. MA5616#display current-configuration [vlan-config] vlan 2 smart port vlan 2 0/0 0 MA5616#display board 0 ------------------------------------------------------------------------- SlotID BoardName Status SubType0 SubType1 Online/Offline ------------------------------------------------------------------------- 0 H831CCUB Active_normal EP1A ASDA 1 H835ADLE Auto_find 2 H835ADLE Auto_find 3 H835ADLE Auto_find 4 H835ADLE Auto_find 5 H831PDIA Normal ------------------------------------------------------------------------- MA5616#display version Command: display version VERSION : MA5616V800R308C01 PATCH : SPC200 SPH508 HP2108 PRODUCT : MA5616 Mainboard Running Area Information: -------------------------------------------- Current Program Area : Area A Current Data Area : Area A Program Area A Version : MA5616V800R308C01 Program Area B Version : MA5616V800R308C01 Data Area A Version : MA5616V800R308C01 Data Area B Version : MA5616V800R308C01 -------------------------------------------- MA5616(config)#interface eth 0/0 MA5616(config-if-eth-0/0)#? --------------------------------------------- Command of eth Mode: --------------------------------------------- auto-neg Enable/Disable port negotiation combo-mode Switch working mode of COMBO port display Display information duplex Set duplex flow-control Support flow control line Line test mdi Line-adaptive function mirror Add mirror network-role Network role port Set TX optical power threshold quit Exit from current mode and enter prior mode reset Clear port statistics return Enter the privileged mode shutdown Deactivate port speed Rate switch Switch language mode traffic-suppress Set port traffic suppression undo Negate a command or set its defaults Thanks On Mon, Aug 12, 2013 at 5:51 AM, Tina TSOU > wrote: Dear all, Only for the uplink GE, the native VLAN can be configured, it can not be configured for NNI EPON/GPON and UNI DSL port. //if the uplink port is GE, then configure a new VLAN 2 huawei(config)#vlan 2 //add the uplink GE 0/0 0 to VLAN 2 huawei(config)#port vlan 2 0/0 0 //change to uplink card interface view huawei(config)#interface eth 0/0 //change native vlan of uplink GE to 2 huawei(config-if-eth-0/0)#native-vlan 0 vlan 2 Thank you, Tina On Aug 11, 2013, at 6:44 AM, "Shahab Vahabzadeh" > wrote: > Only these interface's are available under: > > MA5616(config)# interface ? >> adsl >> emu >> eponnni >> eth >> gponnni >> h248 >> loopback >> meth >> null >> shl >> vdsl >> vlanif > > > Thanks > > > On Sun, Aug 11, 2013 at 4:55 PM, Shahab Vahabzadeh > >wrote: > >> Dear Georgi, >> MA5616 does not have any SCU interface... >> What can we do? >> >> >> On Sun, Aug 11, 2013 at 4:17 PM, Georgi Genov >wrote: >> >>> It`s configurable under scu/scuh/giu board >>> >>> interface scu 0/9 >>> native-vlan 1 vlan XXXX >>> native-vlan 2 vlan YYYY >>> or >>> interface giu 0/19 >>> native-vlan 1 vlan XXXX >>> native-vlan 2 vlan YYYY >>> >>> On 11.8.2013 ?. 09:33 ?., Shahab Vahabzadeh wrote: >>> >>>> Dear Friends, >>>> Anybody have idea about changing native vlan on Huawei MA5616 DSLAM? >>>> I can not find the correct syntax, there is no option under "interface >>>> eth >>>> 0/0" >>>> Thanks >> >> >> -- >> Regards, >> Shahab Vahabzadeh, Network Engineer and System Administrator >> >> Cell Phone: +1 (415) 871 0742 >> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 > > > > -- > Regards, > Shahab Vahabzadeh, Network Engineer and System Administrator > > Cell Phone: +1 (415) 871 0742 > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From sean at donelan.com Wed Aug 14 14:32:13 2013 From: sean at donelan.com (Sean Donelan) Date: Wed, 14 Aug 2013 10:32:13 -0400 (EDT) Subject: How big is the Internet? Message-ID: Researchers have complained for years about the lack of good statistics about the internet for a couple fo decades, since the end of NSFNET statistics. What are the current estimates about the size of the Internet, all IP networks including managed IP and private IP, and all telecommunications including analog voice, video, sensor data, etc? CAIDA, ITU, Telegeography and some vendors like Cisco have released forecasts and estimates. There are occasional pieces of information stated by companies in their investor documents (SEC 10-K, etc). From dreamwaverfx at yahoo.com Wed Aug 14 15:10:53 2013 From: dreamwaverfx at yahoo.com (Alex) Date: Wed, 14 Aug 2013 18:10:53 +0300 Subject: How big is the Internet? In-Reply-To: References: Message-ID: <520B9DFD.1080405@yahoo.com> Current size is HUGE and growing at a phenomenal speed. Public IP networks...just look at ARIN, RIPE,etc and see how many IPs there are left. Private networks and private IPs...well that is anyone's guess. There are no estimates because everything changes rather fast and noone can keep up with all this stuff. The only thing you could have a really good estimate are the resources used by your company and thats about it. On 8/14/2013 5:32 PM, Sean Donelan wrote: > > Researchers have complained for years about the lack of good > statistics about the internet for a couple fo decades, since the > end of NSFNET statistics. > > What are the current estimates about the size of the Internet, all IP > networks including managed IP and private IP, and all telecommunications > including analog voice, video, sensor data, etc? > > CAIDA, ITU, Telegeography and some vendors like Cisco have released > forecasts and estimates. There are occasional pieces of information > stated by companies in their investor documents (SEC 10-K, etc). > > From gabe at teksavvy.ca Wed Aug 14 15:15:32 2013 From: gabe at teksavvy.ca (Gabriel Blanchard) Date: Wed, 14 Aug 2013 11:15:32 -0400 Subject: How big is the Internet? In-Reply-To: <520B9DFD.1080405@yahoo.com> References: <520B9DFD.1080405@yahoo.com> Message-ID: <520B9F14.1040801@teksavvy.ca> Iz this big *spreads arms wide open* On 13-08-14 11:10 AM, Alex wrote: > Current size is HUGE and growing at a phenomenal speed. > Public IP networks...just look at ARIN, RIPE,etc and see how many IPs > there are left. > Private networks and private IPs...well that is anyone's guess. > > There are no estimates because everything changes rather fast and > noone can keep up with all this stuff. > The only thing you could have a really good estimate are the resources > used by your company and thats about it. > > On 8/14/2013 5:32 PM, Sean Donelan wrote: >> >> Researchers have complained for years about the lack of good >> statistics about the internet for a couple fo decades, since the >> end of NSFNET statistics. >> >> What are the current estimates about the size of the Internet, all IP >> networks including managed IP and private IP, and all telecommunications >> including analog voice, video, sensor data, etc? >> >> CAIDA, ITU, Telegeography and some vendors like Cisco have released >> forecasts and estimates. There are occasional pieces of information >> stated by companies in their investor documents (SEC 10-K, etc). >> >> > > From james.sink at freedomvoice.com Wed Aug 14 15:26:36 2013 From: james.sink at freedomvoice.com (James Sink) Date: Wed, 14 Aug 2013 15:26:36 +0000 Subject: How big is the Internet? In-Reply-To: References: Message-ID: <4496efdd96a04c5d94d8c4ac551ff0de@BL2PR08MB148.namprd08.prod.outlook.com> Pretty big, but they gotta keep it trimmed down to fit on a floppy disk. Details within -> http://www.cidr-report.org -James -----Original Message----- From: Sean Donelan [mailto:sean at donelan.com] Sent: Wednesday, August 14, 2013 7:32 AM To: nanog at nanog.org Subject: How big is the Internet? Researchers have complained for years about the lack of good statistics about the internet for a couple fo decades, since the end of NSFNET statistics. What are the current estimates about the size of the Internet, all IP networks including managed IP and private IP, and all telecommunications including analog voice, video, sensor data, etc? CAIDA, ITU, Telegeography and some vendors like Cisco have released forecasts and estimates. There are occasional pieces of information stated by companies in their investor documents (SEC 10-K, etc). From alby.williams at verizon.com Wed Aug 14 15:31:16 2013 From: alby.williams at verizon.com (Anthony Williams) Date: Wed, 14 Aug 2013 11:31:16 -0400 Subject: How big is the Internet? In-Reply-To: <520B9DFD.1080405@yahoo.com> References: <520B9DFD.1080405@yahoo.com> Message-ID: <520BA2C4.9050705@one.verizon.com> One segment is the number of people on the planet with a mobile device that can connect to the Internet? Throw in laptops, workstations, servers, routers, toasters, etc and the number starts to get pretty big. The NSA will need some more hard drives. lol ** Of the 6 billion cell phones in use, only around 1.1 billion of them are mobile-broadband devices. ** http://www.digitaltrends.com/mobile/mobile-phone-world-population-2014 -Alby On 8/14/2013 11:10 AM, Alex wrote: > Current size is HUGE and growing at a phenomenal speed. > Public IP networks...just look at ARIN, RIPE,etc and see how many IPs > there are left. > Private networks and private IPs...well that is anyone's guess. > > There are no estimates because everything changes rather fast and noone > can keep up with all this stuff. > The only thing you could have a really good estimate are the resources > used by your company and thats about it. > > On 8/14/2013 5:32 PM, Sean Donelan wrote: >> >> Researchers have complained for years about the lack of good >> statistics about the internet for a couple fo decades, since the >> end of NSFNET statistics. >> >> What are the current estimates about the size of the Internet, all IP >> networks including managed IP and private IP, and all telecommunications >> including analog voice, video, sensor data, etc? >> >> CAIDA, ITU, Telegeography and some vendors like Cisco have released >> forecasts and estimates. There are occasional pieces of information >> stated by companies in their investor documents (SEC 10-K, etc). >> >> > > > > From geier at geier.ne.tz Wed Aug 14 15:56:09 2013 From: geier at geier.ne.tz (Frank Habicht) Date: Wed, 14 Aug 2013 18:56:09 +0300 Subject: How big is the Internet? In-Reply-To: References: Message-ID: <520BA899.8050103@geier.ne.tz> On 8/14/2013 5:32 PM, Sean Donelan wrote: > What are the current estimates about the size of the Internet, the whole internet... .. is actually the same size in v4 and v6: 0/0 Frank PS: sorry. my mistake: one of them is ::/0 From saku at ytti.fi Wed Aug 14 16:27:59 2013 From: saku at ytti.fi (Saku Ytti) Date: Wed, 14 Aug 2013 19:27:59 +0300 Subject: How big is the Internet? In-Reply-To: References: Message-ID: <20130814162759.GA29336@pob.ytti.fi> On (2013-08-14 10:32 -0400), Sean Donelan wrote: > What are the current estimates about the size of the Internet, all IP > networks including managed IP and private IP, and all telecommunications > including analog voice, video, sensor data, etc? One interesting datapoint might be how many OUI have been allocated, it's about 18k, 2**24 potential MAC addresses in each, so we have 300billion MAC addresses, which is smaller number than what I would have expected. -- ++ytti From bmanning at vacation.karoshi.com Wed Aug 14 17:06:22 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 14 Aug 2013 17:06:22 +0000 Subject: How big is the Internet? - about the size of a strawberry In-Reply-To: References: Message-ID: <20130814170622.GA1958@vacation.karoshi.com.> On Wed, Aug 14, 2013 at 10:32:13AM -0400, Sean Donelan wrote: > > Researchers have complained for years about the lack of good > statistics about the internet for a couple fo decades, since the > end of NSFNET statistics. > > What are the current estimates about the size of the Internet, all IP > networks including managed IP and private IP, and all telecommunications > including analog voice, video, sensor data, etc? > > CAIDA, ITU, Telegeography and some vendors like Cisco have released > forecasts and estimates. There are occasional pieces of information > stated by companies in their investor documents (SEC 10-K, etc). > thats easy... the number of allocated IPv4 /32s and the number of allocated IPv6 /64s. By definition, private networks (RFC 1918) space is not part of the Internet. Or, is your question actually the absolute number of globally reachable IP addresses at any given instant? (reachable from where?) Or do you mean anything that might have an IP address associated with it at some time in its existance? Clarity would be helpful if you want a repeatable answer. /bill From rijilv at riji.lv Wed Aug 14 17:14:34 2013 From: rijilv at riji.lv (RijilV) Date: Wed, 14 Aug 2013 10:14:34 -0700 Subject: How big is the Internet? - about the size of a tastey strawberry Message-ID: On 14 August 2013 10:06, wrote: > On Wed, Aug 14, 2013 at 10:32:13AM -0400, Sean Donelan wrote: > > > > Researchers have complained for years about the lack of good > > statistics about the internet for a couple fo decades, since the > > end of NSFNET statistics. > > > > What are the current estimates about the size of the Internet, all IP > > networks including managed IP and private IP, and all telecommunications > > including analog voice, video, sensor data, etc? > > > > CAIDA, ITU, Telegeography and some vendors like Cisco have released > > forecasts and estimates. There are occasional pieces of information > > stated by companies in their investor documents (SEC 10-K, etc). > > > > thats easy... the number of allocated IPv4 /32s and the > number of allocated IPv6 /64s. By definition, private > networks (RFC 1918) space is not part of the Internet. > > Or, is your question actually the absolute number of globally > reachable IP addresses at any given instant? (reachable from > where?) > > Or do you mean anything that might have an IP address associated > with > it at some time in its existance? > > Clarity would be helpful if you want a repeatable answer. > > /bill > > > Or is size volume based, ie number of bits, and if so is it provisioned capacity or average usage of that capacity? Or even real devices vs used IPs as there isn't a 1:1 mapping... .r' From jmamodio at gmail.com Wed Aug 14 17:40:30 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 14 Aug 2013 12:40:30 -0500 Subject: How big is the Internet? In-Reply-To: References: Message-ID: <286ED4AC-D901-4F75-994E-BD88B1870097@gmail.com> "This big" has been a pretty accurate answer over the years -Jorge On Aug 14, 2013, at 9:32 AM, Sean Donelan wrote: > > Researchers have complained for years about the lack of good > statistics about the internet for a couple fo decades, since the > end of NSFNET statistics. > > What are the current estimates about the size of the Internet, all IP > networks including managed IP and private IP, and all telecommunications > including analog voice, video, sensor data, etc? > > CAIDA, ITU, Telegeography and some vendors like Cisco have released > forecasts and estimates. There are occasional pieces of information > stated by companies in their investor documents (SEC 10-K, etc). > > From symack at gmail.com Wed Aug 14 17:47:52 2013 From: symack at gmail.com (Nick Khamis) Date: Wed, 14 Aug 2013 13:47:52 -0400 Subject: How big is the Internet? In-Reply-To: <286ED4AC-D901-4F75-994E-BD88B1870097@gmail.com> References: <286ED4AC-D901-4F75-994E-BD88B1870097@gmail.com> Message-ID: On 8/14/13, Jorge Amodio wrote: > > "This big" has been a pretty accurate answer over the years > > -Jorge > Oh hahahhaah. Oh man, I better get back to work. Have a nice day gentlemen :). Nick from Toronto. From kemp at network-services.uoregon.edu Wed Aug 14 17:48:48 2013 From: kemp at network-services.uoregon.edu (John Kemp) Date: Wed, 14 Aug 2013 10:48:48 -0700 Subject: route-views3 resource update Message-ID: <201308141748.r7EHmmQd031446@network-services.uoregon.edu> Subject: route-views3 resource update * route-views3.routeviews.org * route-views3 was, until yesterday, a Cisco 7206VXR (NPE-G2) 1GB. route-views3 is now a Redhat 6 box running Quagga 0.99.22.3. This change was made due to memory exhaustion on the older hardware. Quagga provides a similar but less powerful CLI. The new platform has allowed us to resume data collection on route-views3. The data format is the same as most of our other collectors. route-views3 is a multi-hop ebgp collector located at the University of Oregon. The resources available are: CLI -- telnet://route-views3.routeviews.org PEERS -- http://www.routeviews.org/peers/route-views3.routeviews.org.txt DATA -- {http,ftp,rsync}://archive.routeviews.org/route-views3/bgpdata/ ex. rsync --list-only archive.routeviews.org::routeviews ex. rsync -av archive.routeviews.org::routeviews/route-views3/bgpdata . ex. rsync -av archive2.routeviews.org::routeviews/route-views3/bgpdata . Please be aware that the older route-views3 data still resides at the higher level within that data directory. New data is being stored in the bgpdata directory. The older data was captured using the Cisco hardware and expect session scripts. Questions and comments are welcome. We do intend to retain the Cisco CLI on the original route-views router for the forseeable future. --- John Kemp (kemp at routeviews.org) RouteViews Network Engineer help at routeviews.org From tdurack at gmail.com Wed Aug 14 17:51:53 2013 From: tdurack at gmail.com (Tim Durack) Date: Wed, 14 Aug 2013 13:51:53 -0400 Subject: How big is the Internet? In-Reply-To: References: Message-ID: Not as big as the one that got away... (IPv6) On Wed, Aug 14, 2013 at 10:32 AM, Sean Donelan wrote: > > Researchers have complained for years about the lack of good > statistics about the internet for a couple fo decades, since the > end of NSFNET statistics. > > What are the current estimates about the size of the Internet, all IP > networks including managed IP and private IP, and all telecommunications > including analog voice, video, sensor data, etc? > > CAIDA, ITU, Telegeography and some vendors like Cisco have released > forecasts and estimates. There are occasional pieces of information > stated by companies in their investor documents (SEC 10-K, etc). > > > -- Tim:> From scott at doc.net.au Wed Aug 14 18:29:48 2013 From: scott at doc.net.au (Scott Howard) Date: Wed, 14 Aug 2013 14:29:48 -0400 Subject: How big is the Internet? In-Reply-To: References: Message-ID: To paraphrase Douglas Adams... "The Internet is big. Really big. You just won't believe how vastly, hugely, mind- bogglingly big it is. I mean, you may think it's a long way down the road to the chemist's, but that's just peanuts to space!" Scott On Wed, Aug 14, 2013 at 10:32 AM, Sean Donelan wrote: > > Researchers have complained for years about the lack of good > statistics about the internet for a couple fo decades, since the > end of NSFNET statistics. > > What are the current estimates about the size of the Internet, all IP > networks including managed IP and private IP, and all telecommunications > including analog voice, video, sensor data, etc? > > CAIDA, ITU, Telegeography and some vendors like Cisco have released > forecasts and estimates. There are occasional pieces of information > stated by companies in their investor documents (SEC 10-K, etc). > > > From wayne.wenthin at cascadetech.org Wed Aug 14 18:42:39 2013 From: wayne.wenthin at cascadetech.org (Wayne Wenthin) Date: Wed, 14 Aug 2013 11:42:39 -0700 Subject: How big is the Internet? In-Reply-To: References: Message-ID: According to The IT Crowd... http://vinipsmaker.files.wordpress.com/2012/09/the_internet_it_crowd.gif That big. On Wed, Aug 14, 2013 at 7:32 AM, Sean Donelan wrote: > > Researchers have complained for years about the lack of good > statistics about the internet for a couple fo decades, since the > end of NSFNET statistics. > > What are the current estimates about the size of the Internet, all IP > networks including managed IP and private IP, and all telecommunications > including analog voice, video, sensor data, etc? > > CAIDA, ITU, Telegeography and some vendors like Cisco have released > forecasts and estimates. There are occasional pieces of information > stated by companies in their investor documents (SEC 10-K, etc). > > > -- Wayne Wenthin Technology Services Cascade Technology Alliance (CTA North - Multnomah ESD) Office: 503.257.1562 Cell: 360.818.4283 From acaruso at mre-consulting.com Wed Aug 14 18:47:11 2013 From: acaruso at mre-consulting.com (Caruso, Anthony) Date: Wed, 14 Aug 2013 18:47:11 +0000 Subject: How big is the Internet? In-Reply-To: References: , Message-ID: <4DF39F7C-55FD-4316-BBF3-7F79F904E9B8@mre-consulting.com> You guys are cracking me up and I'm getting odd stares. Now stop it. I've got to get this "internet" thing on a CDROM for my boss by 5p so he can review it tonight... On Aug 14, 2013, at 1:43 PM, "Wayne Wenthin" wrote: > According to The IT Crowd... > > http://vinipsmaker.files.wordpress.com/2012/09/the_internet_it_crowd.gif > > That big. > > > On Wed, Aug 14, 2013 at 7:32 AM, Sean Donelan wrote: > >> >> Researchers have complained for years about the lack of good >> statistics about the internet for a couple fo decades, since the >> end of NSFNET statistics. >> >> What are the current estimates about the size of the Internet, all IP >> networks including managed IP and private IP, and all telecommunications >> including analog voice, video, sensor data, etc? >> >> CAIDA, ITU, Telegeography and some vendors like Cisco have released >> forecasts and estimates. There are occasional pieces of information >> stated by companies in their investor documents (SEC 10-K, etc). >> >> >> > > > -- > Wayne Wenthin > Technology Services > Cascade Technology Alliance (CTA North - Multnomah ESD) > Office: 503.257.1562 > Cell: 360.818.4283 ________________________________ This email message and any attachments are for the sole use of the intended recipient(s) and contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments. From sean at donelan.com Wed Aug 14 19:00:51 2013 From: sean at donelan.com (Sean Donelan) Date: Wed, 14 Aug 2013 15:00:51 -0400 (EDT) Subject: How big is the Internet? In-Reply-To: <520B9F14.1040801@teksavvy.ca> References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> Message-ID: I should have remembered, NANOG prefers to correct things. So here are several estimates about how much IP/Internet traffic is downloaded in a month. Does anyone have better numbers, or better souces of numbers that can be shared? Arbor/Merit/Michigan Internet Observatory: 9,000 PB/month (2009) Minnesota Internet Traffic Studies: 7,500-12,000 PB/month (2009) Cisco Visual Network Index: Total IP: 55,553 PB/month (2013) Fixed IP: 39,295 PB/month (2013) Managed IP: 14,679 PB/month (2013) Mobile Data: 1,578 PB/month (2013) Telegeography via ITU report: 44,000 PB/month (2012) National Security Agency: 55,680 PB/month (2013) Individual providers/countries Australian Bureau of Statistics (AU only) : 184 PB/month (2012) AT&T Big Petabyte report (AT&T only): 990 PB/month (2013) CTIA mobile traffic (US only): 69 PB/month (2011) London School of Economics (Europe only): 3,600 PB/month (2012) TATA Communications: 1,600 PB/month (2013) Historical: NSFNET: 0.015 PB/month (1994) From bmanning at vacation.karoshi.com Wed Aug 14 19:46:49 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 14 Aug 2013 19:46:49 +0000 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> Message-ID: <20130814194649.GA2757@vacation.karoshi.com.> On Wed, Aug 14, 2013 at 03:00:51PM -0400, Sean Donelan wrote: > > I should have remembered, NANOG prefers to correct things. So here are > several estimates about how much IP/Internet traffic is downloaded > in a month. Does anyone have better numbers, or better souces of > numbers that can be shared? > > Arbor/Merit/Michigan Internet Observatory: 9,000 PB/month (2009) > Minnesota Internet Traffic Studies: 7,500-12,000 PB/month (2009) > > Cisco Visual Network Index: > Total IP: 55,553 PB/month (2013) > Fixed IP: 39,295 PB/month (2013) > Managed IP: 14,679 PB/month (2013) > Mobile Data: 1,578 PB/month (2013) > Telegeography via ITU report: 44,000 PB/month (2012) > National Security Agency: 55,680 PB/month (2013) > > > Individual providers/countries > Australian Bureau of Statistics (AU only) : 184 PB/month (2012) > AT&T Big Petabyte report (AT&T only): 990 PB/month (2013) > CTIA mobile traffic (US only): 69 PB/month (2011) > London School of Economics (Europe only): 3,600 PB/month (2012) > TATA Communications: 1,600 PB/month (2013) > > Historical: > NSFNET: 0.015 PB/month (1994) Well, the NSFnet numbers did not reflect CSnet or the DoD/ARPA follow on networks, of any of the other IPbased transmission systems of the era. And each of the sources you cite are undoubtedly correct and the best available. Two bits of missing data prevent you from reaching your goal of traffic loading, across all IPbased transmission systems. a) duplicate suppression in the existing datasets. b) access to datasets for unrepresented IPbased transmission systems. You seem to be asking for "b". Not sure how to correct for "a" without direct access to the raw data (and even then, there are issues). Other than more datasets, are you looking at traffic loading graphs, wiht the idea of projecting future loading trends? If so, I'd be interested in your methods since there is some interest in what might be called "the southern hemisphere" challange. /bill From r.engehausen at gmail.com Wed Aug 14 20:00:12 2013 From: r.engehausen at gmail.com (Roy) Date: Wed, 14 Aug 2013 13:00:12 -0700 Subject: How big is the Internet? In-Reply-To: References: Message-ID: <520BE1CC.4020706@gmail.com> On 8/14/2013 11:29 AM, Scott Howard wrote: > To paraphrase Douglas Adams... > > "The Internet is big. Really big. You just won't believe how vastly, > hugely, mind- bogglingly big it is. I mean, you may think it's a long way > down the road to the chemist's, but that's just peanuts to space!" > > Scott > So the correct answer is 42? > > > On Wed, Aug 14, 2013 at 10:32 AM, Sean Donelan wrote: > >> Researchers have complained for years about the lack of good >> statistics about the internet for a couple fo decades, since the >> end of NSFNET statistics. >> >> What are the current estimates about the size of the Internet, all IP >> networks including managed IP and private IP, and all telecommunications >> including analog voice, video, sensor data, etc? >> >> CAIDA, ITU, Telegeography and some vendors like Cisco have released >> forecasts and estimates. There are occasional pieces of information >> stated by companies in their investor documents (SEC 10-K, etc). >> >> >> > . > From jchambers at ucla.edu Wed Aug 14 20:10:39 2013 From: jchambers at ucla.edu (Jason Chambers) Date: Wed, 14 Aug 2013 13:10:39 -0700 Subject: How big is the Internet? In-Reply-To: References: Message-ID: <520BE43F.8030906@ucla.edu> On 8/14/13 7:32 AM, Sean Donelan wrote: > > Researchers have complained for years about the lack of good > statistics about the internet for a couple fo decades, since the > end of NSFNET statistics. > > What are the current estimates about the size of the Internet, all IP > networks including managed IP and private IP, and all telecommunications > including analog voice, video, sensor data, etc? > > CAIDA, ITU, Telegeography and some vendors like Cisco have released > forecasts and estimates. There are occasional pieces of information > stated by companies in their investor documents (SEC 10-K, etc). > > I stumbled on (an) ANT the other day. Very interesting, esp. the part about tracking the growth of Google. I've only made a cursory review over some of the projects but I think it is somewhat relevant to your research, and I'm sure there are many other similar .edu projects you could cull together for a rough estimate. http://ant.isi.edu/blog/ http://www.isi.edu/ant/index.html OPTE seems to have gone stale, too bad. Mapping the internet in a single day... instant gratification ! http://www.opte.org/status/ http://opte.org/history/ Regards, --Jason From patrick at ianai.net Wed Aug 14 20:27:00 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 14 Aug 2013 16:27:00 -0400 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> Message-ID: <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> On Aug 14, 2013, at 15:00 , Sean Donelan wrote: > I should have remembered, NANOG prefers to correct things. So here are > several estimates about how much IP/Internet traffic is downloaded > in a month. Does anyone have better numbers, or better souces of > numbers that can be shared? I think you are not defining things precisely enough to be corrected. What does "downloaded" mean? For instance: 1) If a Google server pulls traffic from another Google server in another datacenter over the Google backbone, is that "downloaded"? 2) How about if an an Akamai server pulls traffic from another Akamai server in the same building but two different networks? 3) How about if the two servers are on the same switch? 4) What if I am playing X-Box with another user on Comcast on the same head end? 5) Two different head ends in the same city? 6) Different cities? Etc. It is actually even harder than the above illustrates. Most people define "Mbps on the Internet" as inter-AS bits. But then what about Akamai AANP nodes, Google GGC nodes, Netflix Open Connect nodes, etc.? They are all inside the AS. Given that Akamai claims to be 20% of all broadband traffic, Google is on the same order, and NF claims to be 30% of US peak-evening traffic, it seems like it would be foolish to ignore this traffic. I could go on, but you get the point. Definitions are a bitch. Once you define what you mean by "how bit is the Internet", I'll be happy to spout off about how big it is. :) All that said: My back-of-the-envelope math says the Internet is order of 1 exabyte/day, as defined by my own rules on what counts as "the Internet"[*]. I could easily be wrong, but you asked. -- TTFN, patrick [*] I count Company-to-Company traffic. This is _mostly_ inter-AS traffic, but on-net nodes (e.g. Akamai, Google, NF) -> Provider _do_ count. Things like Google -> Google over Google backbone do not count. Things like as701 -> as702 would count, but not as701 -> as701, even if the traffic is between two single-homed customers. It is a weird definition, but that's how I define it. (Although I may be biased, since counting only inter-AS traffic leaves off $SOME_PERCENTAGE of the traffic from my company.) > Arbor/Merit/Michigan Internet Observatory: 9,000 PB/month (2009) > Minnesota Internet Traffic Studies: 7,500-12,000 PB/month (2009) > > Cisco Visual Network Index: > Total IP: 55,553 PB/month (2013) > Fixed IP: 39,295 PB/month (2013) > Managed IP: 14,679 PB/month (2013) > Mobile Data: 1,578 PB/month (2013) > Telegeography via ITU report: 44,000 PB/month (2012) > National Security Agency: 55,680 PB/month (2013) > > > Individual providers/countries > Australian Bureau of Statistics (AU only) : 184 PB/month (2012) > AT&T Big Petabyte report (AT&T only): 990 PB/month (2013) > CTIA mobile traffic (US only): 69 PB/month (2011) > London School of Economics (Europe only): 3,600 PB/month (2012) > TATA Communications: 1,600 PB/month (2013) > > Historical: > NSFNET: 0.015 PB/month (1994) > > -------------- 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 jmamodio at gmail.com Wed Aug 14 21:12:10 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 14 Aug 2013 16:12:10 -0500 Subject: How big is the Internet? In-Reply-To: References: Message-ID: <7F58DB7C-702A-4D2D-AD50-6DDF984399E7@gmail.com> IPV6 makes it wider -Jorge On Aug 14, 2013, at 12:51 PM, Tim Durack wrote: > Not as big as the one that got away... (IPv6) > From marka at isc.org Wed Aug 14 21:18:02 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 15 Aug 2013 07:18:02 +1000 Subject: How big is the Internet? In-Reply-To: Your message of "Wed, 14 Aug 2013 16:12:10 -0500." <7F58DB7C-702A-4D2D-AD50-6DDF984399E7@gmail.com> References: <7F58DB7C-702A-4D2D-AD50-6DDF984399E7@gmail.com> Message-ID: <20130814211802.74268386043B@drugs.dv.isc.org> In message <7F58DB7C-702A-4D2D-AD50-6DDF984399E7 at gmail.com>, Jorge Amodio writes: > > IPV6 makes it wider > > -Jorge > > On Aug 14, 2013, at 12:51 PM, Tim Durack wrote: > > > Not as big as the one that got away... (IPv6) 10^12 km^3 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jaydesh9 at gmail.com Wed Aug 14 22:11:55 2013 From: jaydesh9 at gmail.com (Jayram Deshpande) Date: Wed, 14 Aug 2013 15:11:55 -0700 Subject: How big is the Internet? - about the size of a strawberry In-Reply-To: <520bb9c8.4358e00a.161c.ffffe7f4SMTPIN_ADDED_BROKEN@mx.google.com> References: <520bb9c8.4358e00a.161c.ffffe7f4SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: If we try to comprehend the Internet in terms of number of boxes that can reach from their local networks to globally routable destinations, we have to take into account Multi- NATed , multi-tunneled (ipv6 over ipv4 in a VPLS , and other crazy scenarios such v6 over v4 in a VPLS running over VXLANs : is that even realistic ? ) overlay networking environments. So also the overlays formed to talk to sensors who can understand say TM/TC ( Telemetry/Tele-commands). In terms of the Address space , the problem statement shows more convergence. Regards, -Jay Sent from my iPhone On Aug 14, 2013, at 10:06 AM, bmanning at vacation.karoshi.com wrote: > On Wed, Aug 14, 2013 at 10:32:13AM -0400, Sean Donelan wrote: >> >> Researchers have complained for years about the lack of good >> statistics about the internet for a couple fo decades, since the >> end of NSFNET statistics. >> >> What are the current estimates about the size of the Internet, all IP >> networks including managed IP and private IP, and all telecommunications >> including analog voice, video, sensor data, etc? >> >> CAIDA, ITU, Telegeography and some vendors like Cisco have released >> forecasts and estimates. There are occasional pieces of information >> stated by companies in their investor documents (SEC 10-K, etc). > > thats easy... the number of allocated IPv4 /32s and the > number of allocated IPv6 /64s. By definition, private > networks (RFC 1918) space is not part of the Internet. > > Or, is your question actually the absolute number of globally > reachable IP addresses at any given instant? (reachable from where?) > > Or do you mean anything that might have an IP address associated with > it at some time in its existance? > > Clarity would be helpful if you want a repeatable answer. > > /bill > > From LarrySheldon at cox.net Wed Aug 14 22:50:46 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 14 Aug 2013 17:50:46 -0500 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> Message-ID: <520C09C6.2080309@cox.net> On 8/14/2013 10:31 AM, Anthony Williams wrote: > > > One segment is the number of people on the planet with a mobile device > that can connect to the Internet? Throw in laptops, workstations, > servers, routers, toasters, etc and the number starts to get pretty big. > > The NSA will need some more hard drives. lol > > > ** Of the 6 billion cell phones in use, only around 1.1 billion of them > are mobile-broadband devices. ** > > http://www.digitaltrends.com/mobile/mobile-phone-world-population-2014 Do "we" (meaning y'all) even know the edges look like? My elderly crackberry does internetish stuff like email and browsing and file transfers when there is no wiffy in sight. So it either speaks TCP/IP with the towers (it might, I have no clue), or there is non-TCP/IP fabric in the skirts. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Wed Aug 14 22:59:19 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 14 Aug 2013 17:59:19 -0500 Subject: How big is the Internet? In-Reply-To: References: Message-ID: <520C0BC7.9080605@cox.net> On 8/14/2013 1:29 PM, Scott Howard wrote: > To paraphrase Douglas Adams... > > "The Internet is big. Really big. You just won't believe how vastly, > hugely, mind- bogglingly big it is. I mean, you may think it's a long way > down the road to the chemist's, but that's just peanuts to space!" It occurred to me that discussing the size of the Internet is a lot like discussing cosmology (for somebody like me that is not well schooled in either art-form). -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From I.Smith at F5.com Wed Aug 14 23:05:15 2013 From: I.Smith at F5.com (Ian Smith) Date: Wed, 14 Aug 2013 23:05:15 +0000 Subject: How big is the Internet? In-Reply-To: <520C09C6.2080309@cox.net> References: <520B9DFD.1080405@yahoo.com> ,<520C09C6.2080309@cox.net> Message-ID: <419417C345CA5F48BF45F0A23955A0634A6A8AE1@SEAEMBX02.olympus.F5Net.com> Yes. Smartphones have one or more IPs, which may or may not be IPv4/IPv6 & public or rfc1918 address space. There is some tunnelling between the radio and the packet core, but they typically are first class Internet nodes. You could look at them as analogous to cable modems or wifi clients. Feature phones (eg. Motorola Razr) might be using a proxy gateway to to internetish stuff and that gateway actually owns the IP address they use similar to a campus network with a web proxy gateway. Older crackberries tunnel all their traffic inside udp-like encrypted datagrams back to the RIM data centers where they emerge onto the Internet like AOL dial-up subscribers of yesteryear. LTE is IP end-to-end; 3G is IP to a radio-wire interface. ________________________________________ From: Larry Sheldon [LarrySheldon at cox.net] Sent: Wednesday, August 14, 2013 6:50 PM To: nanog at nanog.org Subject: Re: How big is the Internet? On 8/14/2013 10:31 AM, Anthony Williams wrote: > > > One segment is the number of people on the planet with a mobile device > that can connect to the Internet? Throw in laptops, workstations, > servers, routers, toasters, etc and the number starts to get pretty big. > > The NSA will need some more hard drives. lol > > > ** Of the 6 billion cell phones in use, only around 1.1 billion of them > are mobile-broadband devices. ** > > http://www.digitaltrends.com/mobile/mobile-phone-world-population-2014 Do "we" (meaning y'all) even know the edges look like? My elderly crackberry does internetish stuff like email and browsing and file transfers when there is no wiffy in sight. So it either speaks TCP/IP with the towers (it might, I have no clue), or there is non-TCP/IP fabric in the skirts. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From dwessels at verisign.com Wed Aug 14 23:16:37 2013 From: dwessels at verisign.com (Wessels, Duane) Date: Wed, 14 Aug 2013 23:16:37 +0000 Subject: .gov DNSSEC operational message In-Reply-To: <85ED6D15-1809-4AC2-BFD3-461B7102B5E5@verisign.com> References: <85ED6D15-1809-4AC2-BFD3-461B7102B5E5@verisign.com> Message-ID: <13445CED-D4F2-4C92-9C69-D95932B02487@verisign.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On the morning of August 14, a relatively small number of networks may have experienced an operational disruption related to the signing of the .gov zone. In preparation for a previously announced algorithm rollover, a software defect resulted in publishing the .gov zone signed only with DNSSEC algorithm 8 keys rather than with both algorithm 7 and 8. As a result .gov name resolution may have failed for validating recursive name servers. Upon discovery of the issue, Verisign took prompt action to restore the valid zone. Verisign plans to proceed with the previously announced .gov algorithm rollover at the end of the month with the zone being signed with both algorithms for a period of approximately 10 days. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSDA5cAAoJEGyZpGmowJiNQEIH/j3Q649aTV2tmNBWWdSweub9 pSONxMRzD+xS5DqAP/P6x6zw3WTI9oAKESWRiaJjwSR23PP5e94sGFjZJoDW5hnW MqkMGpI2ARB7NNMwYTkwhxK+DFe5fPldSz2eW11AQpy8pSOpVEmVtMW2/lWF1Ykx Auu4HMqFJ930WvpwlyUL+zM3sbm4Mg1q3nb/QAoK7F541CPlvUCSHeVDgwTGDlqu 3SlGr9ztb0BR3203rA1cqlC//XJ1MXZNkE2cye+mXCIEvXJ4q4cA7QS6m6uq7OzT hMMmr0R1q+laOiVkdjaDXxXTbxHzviRAGbPLB+DPvOHd0Hg3srWmoCSNKDWEx2M= =FCd7 -----END PGP SIGNATURE----- From zachary.mcgibbon+nanog at gmail.com Thu Aug 15 01:24:14 2013 From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon) Date: Wed, 14 Aug 2013 21:24:14 -0400 Subject: CNN broadcasting online free? Hogging my bandwidth... Message-ID: I noticed my bandwidth graphs were a little out of whack tonight and after much digging through pcap files I found that my chrome tab with 'cnn.com' had a live stream of cnn playing on the right side halfway down. It seems this started around 8am this morning and it was a macromedia tcp flash stream on port 1935. Did they decide to give free CNN to everyone today? Or is this a goof? Either way it chewed up a lot of my bandwidth which doesn't come cheap here in Canada, eh? Also, sometimes it says: Watch CNN will resume momentarily on the feed but it's still pushing traffic. What a pain! Turning off the 'free' Piers Morgan feed now... - Zachary From LarrySheldon at cox.net Thu Aug 15 01:42:26 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 14 Aug 2013 20:42:26 -0500 Subject: CNN broadcasting online free? Hogging my bandwidth... In-Reply-To: References: Message-ID: <520C3202.9090400@cox.net> On 8/14/2013 8:24 PM, Zachary McGibbon wrote: > I noticed my bandwidth graphs were a little out of whack tonight and after > much digging through pcap files I found that my chrome tab with 'cnn.com' > had a live stream of cnn playing on the right side halfway down. > > It seems this started around 8am this morning and it was a macromedia tcp > flash stream on port 1935. > > Did they decide to give free CNN to everyone today? Or is this a goof? > Either way it chewed up a lot of my bandwidth which doesn't come cheap > here in Canada, eh? > > Also, sometimes it says: > > Watch CNN will resume momentarily > > on the feed but it's still pushing traffic. What a pain! > > Turning off the 'free' Piers Morgan feed now... Trying to get their "numbers" up off the floor? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From jordan at viviotech.net Thu Aug 15 01:46:15 2013 From: jordan at viviotech.net (Jordan Michaels) Date: Wed, 14 Aug 2013 18:46:15 -0700 Subject: CNN broadcasting online free? Hogging my bandwidth... In-Reply-To: <520C3202.9090400@cox.net> References: <520C3202.9090400@cox.net> Message-ID: <520C32E7.8030709@viviotech.net> On 08/14/2013 06:42 PM, Larry Sheldon wrote: > > Trying to get their "numbers" up off the floor? > lol. That was my first thought as well. =P -Jordan From jeff-kell at utc.edu Thu Aug 15 01:59:36 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 14 Aug 2013 21:59:36 -0400 Subject: CNN broadcasting online free? Hogging my bandwidth... In-Reply-To: References: Message-ID: <520C3608.6070305@utc.edu> On 8/14/2013 9:24 PM, Zachary McGibbon wrote: > It seems this started around 8am this morning and it was a macromedia tcp > flash stream on port 1935. Wait until they throw some OctoShape P2P streaming video at you... Jeff From mysidia at gmail.com Thu Aug 15 02:03:37 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 14 Aug 2013 21:03:37 -0500 Subject: How big is the Internet? In-Reply-To: <520B9DFD.1080405@yahoo.com> References: <520B9DFD.1080405@yahoo.com> Message-ID: On Wed, Aug 14, 2013 at 10:10 AM, Alex wrote: > Current size is HUGE and growing at a phenomenal speed. > Public IP networks...just look at ARIN, RIPE,etc and see how many IPs > there are left. > Private networks and private IPs...well that is anyone's guess. > > There are no estimates because everything changes rather fast and noone > can keep up with all this stuff. > The only thing you could have a really good estimate are the resources > used by your company and thats about it. > Your best bet for estimating the true size of the Internet would probably require access to Google, Bing, et al. search engine client access datasets, and number of files / sites crawled datasets; I wouldn't be surprised if they already had this data -- and use cookies as a sieve to accurately separate higher-volume single users from multiple NAT'ed users. Predict the average client's search volume, and infer a predicted number of NAT'ed users per IP accessing search over time. Then enumerate every domain name registered in every single gTLD and ccTLD, and count the number of uniques -- excluding ones with nameservers listed that are used for /dev/null domains which just display advertising. Is the number of network nodes on the internet more interesting than the number of exabytes of unique public data able to be downloaded..... or the number of SD cards and amount of download time required to backup the internet? :) -- -JH From nathana at fsr.com Thu Aug 15 02:28:02 2013 From: nathana at fsr.com (Nathan Anderson) Date: Wed, 14 Aug 2013 19:28:02 -0700 Subject: CNN broadcasting online free? Hogging my bandwidth... In-Reply-To: References: Message-ID: On Wednesday, August 14, 2013 6:24 PM, Zachary McGibbon wrote: > I noticed my bandwidth graphs were a little out of whack tonight and after > much digging through pcap files I found that my chrome tab with 'cnn.com' > had a live stream of cnn playing on the right side halfway down. I'm seeing the same thing, too, but it appears to be video-only...no accompanying audio. -- Nathan From lyle at lcrcomputer.net Thu Aug 15 02:30:13 2013 From: lyle at lcrcomputer.net (Lyle Giese) Date: Wed, 14 Aug 2013 21:30:13 -0500 Subject: How big is the Internet? In-Reply-To: <520BE1CC.4020706@gmail.com> References: <520BE1CC.4020706@gmail.com> Message-ID: <520C3D35.1050203@lcrcomputer.net> On 08/14/13 15:00, Roy wrote: > On 8/14/2013 11:29 AM, Scott Howard wrote: >> To paraphrase Douglas Adams... >> >> "The Internet is big. Really big. You just won't believe how vastly, >> hugely, mind- bogglingly big it is. I mean, you may think it's a long >> way >> down the road to the chemist's, but that's just peanuts to space!" >> >> Scott >> > > So the correct answer is 42? > > >> >> >> On Wed, Aug 14, 2013 at 10:32 AM, Sean Donelan wrote: >> >>> Researchers have complained for years about the lack of good >>> statistics about the internet for a couple fo decades, since the >>> end of NSFNET statistics. >>> Now finally we have the answer. And we are still working on the correct question(if that's possible)! -- Lyle Giese LCR Computer Services, Inc Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 1775 From jra at baylink.com Thu Aug 15 03:11:48 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 14 Aug 2013 23:11:48 -0400 (EDT) Subject: How big is the Internet? In-Reply-To: Message-ID: <12596311.3588.1376536308445.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Sean Donelan" > What are the current estimates about the size of the Internet, all IP > networks including managed IP and private IP, and all > telecommunications including analog voice, video, sensor data, etc? I can't decide, Sean, whether it's obvious or amusing that when I dug back to the beginning of this thread, it would be you who'd asked. (It says some things I don't want to know about how email clients attribute these days, but that's neither here nor there.) Did you want that in "assigned IP addresses", "active IP addresses", "core routes", "core routes, deaggregated", "route miles of fiber", "aggregate bandwidth", or something else? I'm tempted to go with either "mind-bogglingly big" or "42", but since it's you, I'll assume you want an actual answer. Didn't someone recently redo the IPv4 census? Like last year? 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 jra at baylink.com Thu Aug 15 03:24:09 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 14 Aug 2013 23:24:09 -0400 (EDT) Subject: How big is the Internet? In-Reply-To: <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> Message-ID: <31014936.3590.1376537049244.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Patrick W. Gilmore" > All that said: My back-of-the-envelope math says the Internet is order > of 1 exabyte/day, as defined by my own rules on what counts as "the > Internet"[*]. I could easily be wrong, but you asked. Which means that you could get somewhere between 11 and 17 days (depending on how far off my math was) worth of all of that onto LTO-5 carts and load them on a 747F. Where you'd fly them to, I'm not sure. http://baylink.pitas.com/20110516.html#747F 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 scott at doc.net.au Thu Aug 15 04:10:36 2013 From: scott at doc.net.au (Scott Howard) Date: Wed, 14 Aug 2013 21:10:36 -0700 Subject: How big is the Internet? In-Reply-To: <31014936.3590.1376537049244.JavaMail.root@benjamin.baylink.com> References: <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> <31014936.3590.1376537049244.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Aug 14, 2013 at 8:24 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Patrick W. Gilmore" > > > All that said: My back-of-the-envelope math says the Internet is order > > of 1 exabyte/day, as defined by my own rules on what counts as "the > > Internet"[*]. I could easily be wrong, but you asked. > > Which means that you could get somewhere between 11 and 17 days (depending > on how far off my math was) worth of all of that onto LTO-5 carts and load > them on a 747F. Where you'd fly them to, I'm not sure. Unless you add in de-dup, in which case it probably comes down to about 10 carts per day. After all, we all know that 90% of that 1 exabyte/day is just the same 3 cat videos on Youtube... Scott From sean at donelan.com Thu Aug 15 04:19:38 2013 From: sean at donelan.com (Sean Donelan) Date: Thu, 15 Aug 2013 00:19:38 -0400 (EDT) Subject: How big is the Internet? In-Reply-To: <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> Message-ID: On Wed, 14 Aug 2013, Patrick W. Gilmore wrote: > It is actually even harder than the above illustrates. Most people > define "Mbps on the Internet" as inter-AS bits. But then what about > Akamai AANP nodes, Google GGC nodes, Netflix Open Connect nodes, etc.? > They are all inside the AS. Given that Akamai claims to be 20% of all > broadband traffic, Google is on the same order, and NF claims to be 30% > of US peak-evening traffic, it seems like it would be foolish to ignore > this traffic. > > I could go on, but you get the point. Definitions are a bitch. Some of that may help explain why the Internet traffic estimates seem to be too high or too low since about 2007. The primary data sources for the Internet traffic estimates seem to be mostly Internet backbones and Internet exchange points. I hadn't been paying attention until I looked at a bunch of companies' investor filings this week because the size of the Internet was in the news. If you add up the percentages that companies are telling investors and policy makers, you end up with more than 100%. Most of the companies' investor reports don't explain % of what. But the few that do, end up pointing back to the same traffic forecast reports. That doesn't even get to the "long tail" of small providers that don't report anything. Either there is a lot of traffic missing, or market concentration is much greater than assumed. From pcprognosis at verizon.net Thu Aug 15 04:19:22 2013 From: pcprognosis at verizon.net (Clinton Popovich) Date: Wed, 14 Aug 2013 22:19:22 -0600 Subject: How big is the Internet? In-Reply-To: References: <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> <31014936.3590.1376537049244.JavaMail.root@benjamin.baylink.com> Message-ID: <520C56CA.2040705@verizon.net> so true On 8/14/2013 10:10 PM, Scott Howard wrote: > On Wed, Aug 14, 2013 at 8:24 PM, Jay Ashworth wrote: > >> ----- Original Message ----- >>> From: "Patrick W. Gilmore" >>> All that said: My back-of-the-envelope math says the Internet is order >>> of 1 exabyte/day, as defined by my own rules on what counts as "the >>> Internet"[*]. I could easily be wrong, but you asked. >> Which means that you could get somewhere between 11 and 17 days (depending >> on how far off my math was) worth of all of that onto LTO-5 carts and load >> them on a 747F. Where you'd fly them to, I'm not sure. > > Unless you add in de-dup, in which case it probably comes down to about 10 > carts per day. After all, we all know that 90% of that 1 exabyte/day is > just the same 3 cat videos on Youtube... > > Scott > From patrick at ianai.net Thu Aug 15 04:25:08 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 15 Aug 2013 00:25:08 -0400 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> Message-ID: On Aug 15, 2013, at 00:19 , Sean Donelan wrote: > On Wed, 14 Aug 2013, Patrick W. Gilmore wrote: >> It is actually even harder than the above illustrates. Most people define "Mbps on the Internet" as inter-AS bits. But then what about Akamai AANP nodes, Google GGC nodes, Netflix Open Connect nodes, etc.? They are all inside the AS. Given that Akamai claims to be 20% of all broadband traffic, Google is on the same order, and NF claims to be 30% of US peak-evening traffic, it seems like it would be foolish to ignore this traffic. >> >> I could go on, but you get the point. Definitions are a bitch. > > Some of that may help explain why the Internet traffic estimates seem to be too high or too low since about 2007. The primary data sources for > the Internet traffic estimates seem to be mostly Internet backbones and Internet exchange points. > > I hadn't been paying attention until I looked at a bunch of companies' investor filings this week because the size of the Internet was in the news. If you add up the percentages that companies are telling investors and policy makers, you end up with more than 100%. Most of the companies' investor reports don't explain % of what. But the few that > do, end up pointing back to the same traffic forecast reports. That doesn't even get to the "long tail" of small providers that don't report anything. > > Either there is a lot of traffic missing, or market concentration is much greater than assumed. I am not at all surprised the sum of percentages is > 100. User on Joe's-DSL-and-Bait store sends a packet up through Mary's-backbone-and-coffee shop to Bill's-other-transit-and-sandwich cart which finally lands on Comcast. (Didn't see that coming, did you? :) All four networks are going to claim that packet, but a true accounting of "petabytes downloaded per day" will only count it once. -- 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 bmanning at vacation.karoshi.com Thu Aug 15 04:27:31 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 15 Aug 2013 04:27:31 +0000 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> Message-ID: <20130815042731.GA5332@vacation.karoshi.com.> On Thu, Aug 15, 2013 at 12:19:38AM -0400, Sean Donelan wrote: > > Either there is a lot of traffic missing, or market concentration is much > greater than assumed. > I'd argue that its both. /bill From fergdawgster at gmail.com Thu Aug 15 04:34:41 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 14 Aug 2013 21:34:41 -0700 Subject: How big is the Internet? In-Reply-To: <520c59c6.2463310a.7acf.5215SMTPIN_ADDED_BROKEN@mx.google.com> References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> <520c59c6.2463310a.7acf.5215SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: On Wed, Aug 14, 2013 at 9:27 PM, wrote: > On Thu, Aug 15, 2013 at 12:19:38AM -0400, Sean Donelan wrote: >> >> Either there is a lot of traffic missing, or market concentration is much >> greater than assumed. >> > > I'd argue that its both. > I don't want to argue, but perhaps a Hilbert Graph? :-) - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From randy at psg.com Thu Aug 15 04:43:29 2013 From: randy at psg.com (Randy Bush) Date: Thu, 15 Aug 2013 13:43:29 +0900 Subject: How big is the Internet? In-Reply-To: <20130815042731.GA5332@vacation.karoshi.com.> References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> Message-ID: i think of cdns as simpler. aside from the nyt-core-to-cdn traffic, they're just as if the nyt had connectivity to the provider(s) which embedded the cache. they are not another layer of traffic, but rather just traffic for the provider(s) in which they embedded. randy From gdt at gdt.id.au Thu Aug 15 06:22:53 2013 From: gdt at gdt.id.au (Glen Turner) Date: Thu, 15 Aug 2013 15:52:53 +0930 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> Message-ID: <8D32F6E7-B43A-4AAF-A69C-5EC873E6EC00@gdt.id.au> Perhaps more interesting than bytes on backbones would be the median distance to an Internet-connected device. -glen From mfidelman at meetinghouse.net Thu Aug 15 09:53:28 2013 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 15 Aug 2013 05:53:28 -0400 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> Message-ID: <520CA518.6040600@meetinghouse.net> Don't think I've seen it mentioned yet (but then I've stopped reading a lot of this thread): Akamai publishes a "state of the net" report periodically, with lots of statistics. http://www.akamai.com/stateoftheinternet/ Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From sh.vahabzadeh at gmail.com Thu Aug 15 10:45:15 2013 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Thu, 15 Aug 2013 15:15:15 +0430 Subject: SMTP Authentication for Local Domain in Postfix Message-ID: Dear friends, I have problem with my postfix configuration, I have enable SASL for postfix and now authentication works well for my clients but right now anyboy can send email from my local domain to local domain without authentication and cause of that I have lots of attacks. How can I force that if sender is my localdomain it must authenticate?! Here is my postfix configuration: main.cf: smtpd_sasl_auth_enable = yes > smtpd_sasl_local_domain = $myhostname > smtpd_sasl_security_options = noanonymous > broken_sasl_auth_clients = yes > smtpd_sasl_authenticated_header = yes > smtpd_client_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > reject_unauth_pipelining, > reject_rbl_client zen.spamhaus.org, > smtpd_helo_restrictions = > permit_mynetworks, > #reject_non_fqdn_hostname, > reject_invalid_hostname > smtpd_sender_restriction = > permit_mynetworks, > permit_sasl_authenticated, > check_sender_access hash:/etc/postfix/access_table > reject_unknown_sender_domain, > reject_non_fqdn_sender > smtpd_recipient_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > reject_invalid_hostname, > reject_unauth_pipelining, > reject_non_fqdn_sender, > reject_unknown_sender_domain, > reject_non_fqdn_recipient, > reject_unknown_recipient_domain, > reject_unverified_recipient, > reject_unauth_destination, > check_policy_service unix:private/policy-spf, > permit master.cf: smtp inet n - - - - smtpd > -o content_filter=spamassassin > submission inet n - - - - smtpd > -o smtpd_tls_security_level=may > -o smtpd_sasl_auth_enable=yes > -o smtpd_client_restrictions=permit_sasl_authenticated,reject > -o milter_macro_daemon_name=ORIGINATING > -o content_filter=spamassassin > smtps inet n - - - - smtpd > -o smtpd_tls_wrappermode=yes > -o smtpd_sasl_auth_enable=yes > -o smtpd_client_restrictions=permit_sasl_authenticated,reject > -o milter_macro_daemon_name=ORIGINATING > spamassassin > unix - n n - - pipe > user=nobody argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} > ${recipient} > policy-spf unix - n n - - spawn > user=nobody argv=/usr/bin/perl /usr/sbin/postfix-policyd-spf-perl access_table: mydomain.com REJECT You're not me! Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From daniel.crompton at gmail.com Thu Aug 15 12:46:51 2013 From: daniel.crompton at gmail.com (=?UTF-8?Q?Dani=C3=ABl_W=2E_Crompton?=) Date: Thu, 15 Aug 2013 14:46:51 +0200 Subject: SMTP Authentication for Local Domain in Postfix In-Reply-To: References: Message-ID: Hi Shahab, Your mistake is highlighted below, the order of *smtpd_sender_restriction* is such that you are permitting local delivery to your network before sasl authentication. In my config I removed it and only have it in * smtpd_recipient_restrictions* and then only after sasl authentication has been confirmed. D. On 15 August 2013 12:45, Shahab Vahabzadeh wrote: > smtpd_sender_restriction = > > *permit_mynetworks,* > > permit_sasl_authenticated, > > check_sender_access hash:/etc/postfix/access_table > > reject_unknown_sender_domain, > > reject_non_fqdn_sender > -- blaze your trail -- Dani?l W. Crompton http://specialbrands.net/ From bicknell at ufp.org Thu Aug 15 14:05:26 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 15 Aug 2013 09:05:26 -0500 Subject: How big is the Internet? In-Reply-To: <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> Message-ID: On Aug 14, 2013, at 3:27 PM, Patrick W. Gilmore wrote: > Once you define what you mean by "how bit is the Internet", I'll be happy to spout off about how big it is. :) Arbitrary definition time: A Internet host is one that can send and receive packets directly with at least one far end device addressed out of RIR managed IPv4 or IPv6 space. That means behind a NAT counts, behind a firewall counts, but a true private network (two PC's into an L2 switch with no other connections) does not, even if they use IP protocols. Note that devices behind a pure L3 proxy do not count, but the L3 proxy itself counts. Now, take those Internet hosts and create a graph where each node has a binary state, forwards packets or does not forward packets the result is a set of edge nodes that do not forward packets. The simple case is an end user PC, the complex case may be something like a server in a data center that while connected to multiple networks does not forward any packets, and is an edge node on all of the networks to which it is attached. To me, "all Internet" traffic is the sum of all "in" traffic on all edge nodes. Note if I did my definition carefully out = in - (packet loss + undeliverable), which means on the scale of the global Internet I suspect out == in, when rounded off. So please, carry on and spout off as to how big that is, I think an estimate would be very interesting. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From sethm at rollernet.us Thu Aug 15 15:10:31 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 15 Aug 2013 08:10:31 -0700 Subject: How big is the Internet? In-Reply-To: <12596311.3588.1376536308445.JavaMail.root@benjamin.baylink.com> References: <12596311.3588.1376536308445.JavaMail.root@benjamin.baylink.com> Message-ID: <520CEF67.9000007@rollernet.us> On 8/14/13 8:11 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Sean Donelan" > >> What are the current estimates about the size of the Internet, all IP >> networks including managed IP and private IP, and all >> telecommunications including analog voice, video, sensor data, etc? > > I can't decide, Sean, whether it's obvious or amusing that when I dug back > to the beginning of this thread, it would be you who'd asked. (It says > some things I don't want to know about how email clients attribute these > days, but that's neither here nor there.) > > Did you want that in "assigned IP addresses", "active IP addresses", > "core routes", "core routes, deaggregated", "route miles of fiber", > "aggregate bandwidth", or something else? > > I'm tempted to go with either "mind-bogglingly big" or "42", but since > it's you, I'll assume you want an actual answer. > > Didn't someone recently redo the IPv4 census? Like last year? > We'll also need this data in units of number of Libraries of Congress. ~Seth From scott at doc.net.au Thu Aug 15 16:30:24 2013 From: scott at doc.net.au (Scott Howard) Date: Thu, 15 Aug 2013 12:30:24 -0400 Subject: How big is the Internet? In-Reply-To: <8D32F6E7-B43A-4AAF-A69C-5EC873E6EC00@gdt.id.au> References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> <8D32F6E7-B43A-4AAF-A69C-5EC873E6EC00@gdt.id.au> Message-ID: You'd almost think this was a technology mailing list given some of the answers... (ohh.. wait!) How about this - the size of the Internet is just short of 3 billion. That's the number of people that have access to it. To me, that's a far more telling number than anything around IP address or Exabytes of data. Scott From harbor235 at gmail.com Thu Aug 15 16:35:31 2013 From: harbor235 at gmail.com (harbor235) Date: Thu, 15 Aug 2013 12:35:31 -0400 Subject: Level3 L2VPN service Message-ID: Anybody have any experiences they want to share with Level3's L2VPN service? I am looking for performance, stability, and support issues? thank you, Mike From jason at lixfeld.ca Thu Aug 15 16:46:07 2013 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 15 Aug 2013 12:46:07 -0400 Subject: Recommendations for dynamic imix traffic generators Message-ID: Hi folks, I'm trying to put together a test bench to soak some CPE equipment with an imix of eyeball traffic. I'm wondering if anyone has any recommendations on open-source platforms that might be able to accomplish this. I'd like to simulate traffic conditions that various tiers of Internet users might create from behind these CPEs - Casual user, business user, gamer, heavy users, netflix client, Apple TV client, a combination of any of the aforementioned, etc. In a perfect world, I'd love for these traffic patterns to be dynamic; various pps/bps/fps/nat cps rates, various intervals of each and durations of each instead of just continually puking out the same set of packets in an endless loop. I think it would be important for this traffic generator to be intelligent enough to determine whether or not the tests it's performing are successful or not; that is, be cognizant of errors in the tests that would translate into what a user would perceive to be a broken web page or a slow loading web page or a video freezing or a game to lock up, all of which might be attributed to a timeout on a DNS lookup or packet-loss or a bad NAT stack, etc. If anyone has any ideas or experiences they can share on this type of setup, I'd love some feedback or advice. icir.org has a list of tools which I'm making my way through as well. Not sure what is useful for what it I'm trying to do, but I digress. Thanks in advance. From ikiris at gmail.com Thu Aug 15 16:55:33 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 15 Aug 2013 11:55:33 -0500 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> <8D32F6E7-B43A-4AAF-A69C-5EC873E6EC00@gdt.id.au> Message-ID: I agree, Librarys of Congress / second is the standard notation for bandwidth. -Blake On Thu, Aug 15, 2013 at 11:30 AM, Scott Howard wrote: > You'd almost think this was a technology mailing list given some of the > answers... (ohh.. wait!) > > How about this - the size of the Internet is just short of 3 billion. > > That's the number of people that have access to it. To me, that's a far > more telling number than anything around IP address or Exabytes of data. > > Scott > From dave at temk.in Thu Aug 15 17:05:10 2013 From: dave at temk.in (David Temkin) Date: Thu, 15 Aug 2013 19:05:10 +0200 Subject: NANOG 59 - Important Schedule Notice & Call For Presentations. Please read! In-Reply-To: References: Message-ID: All- One final reminder - abstracts are due by the end of this week. Also, the track coordinators for the Data Center track (Dan Golding - dgolding at gmail.com) and the Peering Track (Nina Bargisen - nihb at netflix.com) would like me to remind you to submit your relevant content for these tracks early so that your track-specific content may be properly considered. Regards, -Dave On Mon, Jun 17, 2013 at 9:33 PM, David Temkin wrote: > NANOG Community, > > I hope everyone enjoyed New Orleans as much as I did! It's truly one of > my favorite cities in the world. Fresh off a great meeting, we're already > starting to get ready for NANOG 59 in Phoenix. If you have a topic you'd > like to speak about, the program committee would love to consider it. > Please watch http://www.nanog.org/meetings/nanog59/callforpresentations for > more information. > > After considering feedback from members, speakers, ARIN, and sponsors we > have decided to make a small tweak to the program timing at NANOG 59. We > will continue with the Monday-Wednesday format, however we will move the > ARIN Track and Tutorials to Tuesday morning, highlighting their importance > to the program. The program will begin on Monday morning at 10:00AM > followed by our popular Newcomers Lunch. The exact schedule layout can be > found at http://www.nanog.org/meetings/nanog59/preagenda and is also > attached in JPG format to this email. > > > If you wish to submit a presentation, please keep these important dates > in mind: > > > Presentation Abstracts and Draft Slides Due: 16-Aug-2013 > Slides Due: > 30-Aug-2013 > Topic List Posted: > 06-Sep-2013 > Final Agenda Published: > 27-Sep-2013 > > Please submit your materials to http://pc.nanog.org > > Looking forward to seeing everyone in Phoenix! > > -Dave Temkin > > (Chair, NANOG Program Committee) > > From jmamodio at gmail.com Thu Aug 15 17:14:02 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 15 Aug 2013 12:14:02 -0500 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> Message-ID: <6F6AF372-2ECB-4D1C-957F-A5C1F0A0B8BD@gmail.com> If devices behind an L3 proxy generate packets that end in the "public" Internet or if they get packets originated there, IMHO those devices are also part of the Internet not just the proxy, and you also may have that proxy for particular protocols but not all. -Jorge On Aug 15, 2013, at 9:05 AM, Leo Bicknell wrote: > > That means behind a NAT counts, behind a firewall counts, but a true private network (two PC's into an L2 switch with no other connections) does not, even if they use IP protocols. Note that devices behind a pure L3 proxy do not count, but the L3 proxy itself counts. > Jorge - CPB49 (Certified Packet Butcher) From jmamodio at gmail.com Thu Aug 15 17:23:14 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 15 Aug 2013 12:23:14 -0500 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> <8D32F6E7-B43A-4AAF-A69C-5EC873E6EC00@gdt.id.au> Message-ID: <658C502C-5CA8-4378-B7AF-9E0FFA1C1BE8@gmail.com> What Congress ? We have to be very careful with this the ITU may complain the we are taking a US centric approach to the subject and the EU will debate for months on the definition of "Library" then ICANN will initiate a PDP to figure how to associate Library with Congress after the SSAC says it is safe to do so, and after 10 years of public consultation and 50 conferences in exotic places we may find that the definition is outdated and the UN will call a panel of experts to devise why the Internet became several orders of magnitude bigger. At that time Vint will be sending 4D tweets via the galactic network from Pluto -Jorge On Aug 15, 2013, at 11:55 AM, Blake Dunlap wrote: > I agree, Librarys of Congress / second is the standard notation for > bandwidth. > > -Blake > > > On Thu, Aug 15, 2013 at 11:30 AM, Scott Howard wrote: > >> You'd almost think this was a technology mailing list given some of the >> answers... (ohh.. wait!) >> >> How about this - the size of the Internet is just short of 3 billion. >> >> That's the number of people that have access to it. To me, that's a far >> more telling number than anything around IP address or Exabytes of data. >> >> Scott >> From eugen at leitl.org Thu Aug 15 18:18:28 2013 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 15 Aug 2013 20:18:28 +0200 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> <8D32F6E7-B43A-4AAF-A69C-5EC873E6EC00@gdt.id.au> Message-ID: <20130815181828.GY29404@leitl.org> On Thu, Aug 15, 2013 at 12:30:24PM -0400, Scott Howard wrote: > How about this - the size of the Internet is just short of 3 billion. > > That's the number of people that have access to it. To me, that's a far > more telling number than anything around IP address or Exabytes of data. Sure enough -- but people might be no longer the prime movers and shakers, with increased automation. From oscar.vives at gmail.com Thu Aug 15 18:30:10 2013 From: oscar.vives at gmail.com (<"tei''>>) Date: Thu, 15 Aug 2013 11:30:10 -0700 Subject: How big is the Internet? In-Reply-To: <20130815181828.GY29404@leitl.org> References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> <8D32F6E7-B43A-4AAF-A69C-5EC873E6EC00@gdt.id.au> <20130815181828.GY29404@leitl.org> Message-ID: I know the exact size: Infinite. When I was in the university I was downloading many things at the night, while the whole internet bandwith was wasted (hehehehe). Many times my wget -r -l 32 got stuck on things like CGI's that point to itself creating a infinite loop. This was in 2002, but probably still exist many CGI's like this one. I imagine spider programmers have many fun similar histories, of websites that seems "infinite" to the spider. -- -- ?in del ?ensaje. From patrick at ianai.net Thu Aug 15 18:27:36 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 15 Aug 2013 14:27:36 -0400 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> Message-ID: On Aug 15, 2013, at 10:05 , Leo Bicknell wrote: > On Aug 14, 2013, at 3:27 PM, Patrick W. Gilmore wrote: >> Once you define what you mean by "how bit is the Internet", I'll be happy to spout off about how big it is. :) > > Arbitrary definition time: A Internet host is one that can send and receive packets directly with at least one far end device addressed out of RIR managed IPv4 or IPv6 space. > > That means behind a NAT counts, behind a firewall counts, but a true private network (two PC's into an L2 switch with no other connections) does not, even if they use IP protocols. Note that devices behind a pure L3 proxy do not count, but the L3 proxy itself counts. > > Now, take those Internet hosts and create a graph where each node has a binary state, forwards packets or does not forward packets the result is a set of edge nodes that do not forward packets. The simple case is an end user PC, the complex case may be something like a server in a data center that while connected to multiple networks does not forward any packets, and is an edge node on all of the networks to which it is attached. > > To me, "all Internet" traffic is the sum of all "in" traffic on all edge nodes. Note if I did my definition carefully out = in - (packet loss + undeliverable), which means on the scale of the global Internet I suspect out == in, when rounded off. I have a feeling you flipped "in" & "out" in that formula. > So please, carry on and spout off as to how big that is, I think an estimate would be very interesting. Spout off time: My laptop at home is an edge node under the definition above, despite being behind a NAT. My home NAS is as well. When I back up my laptop to my NAS over my home network, that traffic would be counted as "Internet" traffic by your definition. I have a feeling that does not come close to matching the mental model most people have in their head of "Internet traffic". But maybe I'm confused. -- 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 eric.sieg at gmail.com Wed Aug 14 21:56:30 2013 From: eric.sieg at gmail.com (Eric Sieg) Date: Wed, 14 Aug 2013 17:56:30 -0400 Subject: Limelight contact Message-ID: Can someone from Limelight contact me offline to assist in isolating some routes leaking into their network? From bicknell at ufp.org Thu Aug 15 20:10:31 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 15 Aug 2013 15:10:31 -0500 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> Message-ID: On Aug 15, 2013, at 1:27 PM, Patrick W. Gilmore wrote: > My laptop at home is an edge node under the definition above, despite being behind a NAT. My home NAS is as well. When I back up my laptop to my NAS over my home network, that traffic would be counted as "Internet" traffic by your definition. > > I have a feeling that does not come close to matching the mental model most people have in their head of "Internet traffic". But maybe I'm confused. It matches my mental model. Your network is connected to the Internet, that's traffic between two hosts, it's Internet traffic. Let's take the same two machines, but I own one and you own one, and let's put them on the same network behind a NAT just like your home, but at a coffee shop. Rather than backups we're both running bit torrent and our two machines exchange data. That's Internet traffic, isn't it? Two unrelated people talking over the network? They just happen to be on the same LAN. My definition was arbitrary, so feel free to argue another arbitrary definition is more useful in some way, but for my arbitrary definition you've applied the rules correct, and I would argue it's the right way to think about things. In a broad english sense "IP packets traversing an Internet connected network are Internet traffic". It's all graph cross sections. "Peering" volume totals a set of particular links in the graph, omitting traffic from your laptop to your file server, or your NAS to your laptop. My model attempts to isolate every edge on the graph, and generate the total sum of IP traffic crossing any Internet connected network, which would always include all forms of local caches (Akamai, Google, Netflix) and even your NAT. I think that's a more interesting number, and a number that's easier to count and defend than say a peering or "backbone" number. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From dsparro at gmail.com Thu Aug 15 20:16:19 2013 From: dsparro at gmail.com (Dave Sparro) Date: Thu, 15 Aug 2013 16:16:19 -0400 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> Message-ID: <520D3713.4040101@gmail.com> On 8/14/2013 3:00 PM, Sean Donelan wrote: > > I should have remembered, NANOG prefers to correct things. So here are > several estimates about how much IP/Internet traffic is downloaded > I had always assumed that Bytes were like photons, and had no mass. -- Dave From wbailey at satelliteintelligencegroup.com Thu Aug 15 20:44:46 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 15 Aug 2013 20:44:46 +0000 Subject: How big is the Internet? In-Reply-To: Message-ID: Is internal DNS considered to be in the same realm? I agree with you, but I'm not totally sure there is a straight forward answer here. Device connected to internet, sends query (same as would be over the internet) to local DNS service. Is that an Internet transaction? On 8/15/13 1:10 PM, "Leo Bicknell" wrote: > >On Aug 15, 2013, at 1:27 PM, Patrick W. Gilmore wrote: > >> My laptop at home is an edge node under the definition above, despite >>being behind a NAT. My home NAS is as well. When I back up my laptop to >>my NAS over my home network, that traffic would be counted as "Internet" >>traffic by your definition. >> >> I have a feeling that does not come close to matching the mental model >>most people have in their head of "Internet traffic". But maybe I'm >>confused. > >It matches my mental model. Your network is connected to the Internet, >that's traffic between two hosts, it's Internet traffic. > >Let's take the same two machines, but I own one and you own one, and >let's put them on the same network behind a NAT just like your home, but >at a coffee shop. Rather than backups we're both running bit torrent and >our two machines exchange data. > >That's Internet traffic, isn't it? Two unrelated people talking over the >network? They just happen to be on the same LAN. > >My definition was arbitrary, so feel free to argue another arbitrary >definition is more useful in some way, but for my arbitrary definition >you've applied the rules correct, and I would argue it's the right way to >think about things. In a broad english sense "IP packets traversing an >Internet connected network are Internet traffic". > >It's all graph cross sections. "Peering" volume totals a set of >particular links in the graph, omitting traffic from your laptop to your >file server, or your NAS to your laptop. My model attempts to isolate >every edge on the graph, and generate the total sum of IP traffic >crossing any Internet connected network, which would always include all >forms of local caches (Akamai, Google, Netflix) and even your NAT. I >think that's a more interesting number, and a number that's easier to >count and defend than say a peering or "backbone" number. > >-- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > > From wbailey at satelliteintelligencegroup.com Thu Aug 15 20:48:53 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 15 Aug 2013 20:48:53 +0000 Subject: How big is the Internet? In-Reply-To: Message-ID: I neglected to say one additional thing which I think may be worth reading before replying. I have always held the opinion that internet traffic isn't internet traffic until it hits the Internet, which I defined as two or more autonomous systems functioning on their own but possessing the ability to relay information between the two. I'm pretty sure that if you have a single network, you couldn't label it "inter" unless "inter" was between yourself - and then you have a network.. Not an internetwork. Maybe?? :) On 8/15/13 1:10 PM, "Leo Bicknell" wrote: > >On Aug 15, 2013, at 1:27 PM, Patrick W. Gilmore wrote: > >> My laptop at home is an edge node under the definition above, despite >>being behind a NAT. My home NAS is as well. When I back up my laptop to >>my NAS over my home network, that traffic would be counted as "Internet" >>traffic by your definition. >> >> I have a feeling that does not come close to matching the mental model >>most people have in their head of "Internet traffic". But maybe I'm >>confused. > >It matches my mental model. Your network is connected to the Internet, >that's traffic between two hosts, it's Internet traffic. > >Let's take the same two machines, but I own one and you own one, and >let's put them on the same network behind a NAT just like your home, but >at a coffee shop. Rather than backups we're both running bit torrent and >our two machines exchange data. > >That's Internet traffic, isn't it? Two unrelated people talking over the >network? They just happen to be on the same LAN. > >My definition was arbitrary, so feel free to argue another arbitrary >definition is more useful in some way, but for my arbitrary definition >you've applied the rules correct, and I would argue it's the right way to >think about things. In a broad english sense "IP packets traversing an >Internet connected network are Internet traffic". > >It's all graph cross sections. "Peering" volume totals a set of >particular links in the graph, omitting traffic from your laptop to your >file server, or your NAS to your laptop. My model attempts to isolate >every edge on the graph, and generate the total sum of IP traffic >crossing any Internet connected network, which would always include all >forms of local caches (Akamai, Google, Netflix) and even your NAT. I >think that's a more interesting number, and a number that's easier to >count and defend than say a peering or "backbone" number. > >-- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > > From LarrySheldon at cox.net Thu Aug 15 21:18:31 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 15 Aug 2013 16:18:31 -0500 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> Message-ID: <520D45A7.2030404@cox.net> On 8/15/2013 9:05 AM, Leo Bicknell wrote: > > On Aug 14, 2013, at 3:27 PM, Patrick W. Gilmore > wrote: > >> Once you define what you mean by "how bit is the Internet", I'll be >> happy to spout off about how big it is. :) > > Arbitrary definition time: A Internet host is one that can send and > receive packets directly with at least one far end device addressed > out of RIR managed IPv4 or IPv6 space. > > That means behind a NAT counts, behind a firewall counts, but a true > private network (two PC's into an L2 switch with no other > connections) does not, even if they use IP protocols. Note that > devices behind a pure L3 proxy do not count, but the L3 proxy itself > counts. Isn't that like excluding city streets from the "How many miles of roads?" question--likely to be the bigger fraction of the whole-as-a-traveler-sees-it? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From Valdis.Kletnieks at vt.edu Thu Aug 15 21:21:35 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 15 Aug 2013 17:21:35 -0400 Subject: How big is the Internet? In-Reply-To: Your message of "Thu, 15 Aug 2013 20:48:53 -0000." References: Message-ID: <20920.1376601695@turing-police.cc.vt.edu> On Thu, 15 Aug 2013 20:48:53 -0000, Warren Bailey said: > I neglected to say one additional thing which I think may be worth reading > before replying. I have always held the opinion that internet traffic > isn't internet traffic until it hits the Internet, which I defined as two > or more autonomous systems functioning on their own but possessing the So bittorrent packets from my computer to some other computer that also happens to belong to a Comcast subscriber aren't Internet traffic? But other packets to another Comcast subscriber that happen to cross an AS boundary are? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From ttauber at 1-4-5.net Thu Aug 15 22:04:19 2013 From: ttauber at 1-4-5.net (Tony Tauber) Date: Thu, 15 Aug 2013 18:04:19 -0400 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> <8D32F6E7-B43A-4AAF-A69C-5EC873E6EC00@gdt.id.au> Message-ID: All this goes to the point that the original question was poorly worded and I daresay ill-conceived. There's no "one number" or "one metric", much less "one definition". It all depends on what the real question is that you're trying to answer and why. There is plenty of room for study; though it's necessary to start with some circumscribed question. Of course the answers you may get won't likely then be readily applicable to answering some other question that may come in the future. Tony On Thu, Aug 15, 2013 at 12:30 PM, Scott Howard wrote: > You'd almost think this was a technology mailing list given some of the > answers... (ohh.. wait!) > > How about this - the size of the Internet is just short of 3 billion. > > That's the number of people that have access to it. To me, that's a far > more telling number than anything around IP address or Exabytes of data. > > Scott > From jabley at hopcount.ca Thu Aug 15 23:07:12 2013 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 15 Aug 2013 18:07:12 -0500 Subject: How big is the Internet? In-Reply-To: <520D45A7.2030404@cox.net> References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> <520D45A7.2030404@cox.net> Message-ID: <-2843105678401179764@unknownmsgid> On 2013-08-15, at 16:18, Larry Sheldon wrote: > Isn't that like excluding city streets from the "How many miles of roads?" question--likely to be the bigger fraction of the whole-as-a-traveler-sees-it? At last! A car analogy. I was beginning to think this was some other NANOG. Joe From mike at conlen.org Thu Aug 15 22:07:04 2013 From: mike at conlen.org (Michael Conlen) Date: Thu, 15 Aug 2013 18:07:04 -0400 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> <8D32F6E7-B43A-4AAF-A69C-5EC873E6EC00@gdt.id.au> Message-ID: <9BDC50BD-A6C8-4546-B10C-B1CC5CB7A8DE@conlen.org> One could say that the size of the internet is, up to isomorphism, 2; very precise but as useful as you predict. -- Mike On Aug 15, 2013, at 6:04 PM, Tony Tauber wrote: > All this goes to the point that the original question was poorly worded and > I daresay ill-conceived. > There's no "one number" or "one metric", much less "one definition". > It all depends on what the real question is that you're trying to answer > and why. > > There is plenty of room for study; though it's necessary to start with some > circumscribed question. > Of course the answers you may get won't likely then be readily applicable > to answering some other question that may come in the future. > > Tony > > > On Thu, Aug 15, 2013 at 12:30 PM, Scott Howard wrote: > >> You'd almost think this was a technology mailing list given some of the >> answers... (ohh.. wait!) >> >> How about this - the size of the Internet is just short of 3 billion. >> >> That's the number of people that have access to it. To me, that's a far >> more telling number than anything around IP address or Exabytes of data. >> >> Scott >> From jra at baylink.com Thu Aug 15 23:57:26 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 15 Aug 2013 19:57:26 -0400 (EDT) Subject: How big is the Internet? In-Reply-To: <658C502C-5CA8-4378-B7AF-9E0FFA1C1BE8@gmail.com> Message-ID: <4351216.3608.1376611046116.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jorge Amodio" > What Congress ? We have to be very careful with this the ITU may > complain the we are taking a US centric approach to the subject and > the EU will debate for months on the definition of "Library" then > ICANN will initiate a PDP to figure how to associate Library with > Congress after the SSAC says it is safe to do so, and after 10 years > of public consultation and 50 conferences in exotic places we may find > that the definition is outdated and the UN will call a panel of > experts to devise why the Internet became several orders of magnitude > bigger. > > At that time Vint will be sending 4D tweets via the galactic network > from Pluto C'mon guys; Whacky Weekend doesn't start til 3pm ET Fridays, except when Friday is a US Federal holiday... 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 jra at baylink.com Fri Aug 16 00:00:38 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 15 Aug 2013 20:00:38 -0400 (EDT) Subject: How big is the Internet? In-Reply-To: Message-ID: <1995511.3610.1376611238343.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Leo Bicknell" > > I have a feeling that does not come close to matching the mental > > model most people have in their head of "Internet traffic". But > > maybe I'm confused. > > It matches my mental model. Your network is connected to the Internet, > that's traffic between two hosts, it's Internet traffic. > > Let's take the same two machines, but I own one and you own one, and > let's put them on the same network behind a NAT just like your home, > but at a coffee shop. Rather than backups we're both running bit > torrent and our two machines exchange data. > > That's Internet traffic, isn't it? Two unrelated people talking over > the network? They just happen to be on the same LAN. "Internet traffic is traffic which leaves and/or arrives at your machine in a session with some other machine which is on a network physically or administratively disjoint from the one your network is on." How's that? I think it solves both your and Patrick's requirements. 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 jra at baylink.com Fri Aug 16 00:02:41 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 15 Aug 2013 20:02:41 -0400 (EDT) Subject: How big is the Internet? In-Reply-To: Message-ID: <15226028.3612.1376611361409.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Warren Bailey" > I neglected to say one additional thing which I think may be worth reading > before replying. I have always held the opinion that internet traffic > isn't internet traffic until it hits the Internet, which I defined as > two or more autonomous systems functioning on their own but possessing the > ability to relay information between the two. I'm pretty sure that if > you have a single network, you couldn't label it "inter" unless "inter" > was between yourself - and then you have a network.. Not an internetwork. I suspect that, to a first approximation, "traffic which passes through the edge of at least one AS" is probably what most people think of as 'Internet' traffic. As for your DNS question: the interior query isn't, per-se, but the repeated one from your resolver/proxy *is*. 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 jra at baylink.com Fri Aug 16 01:00:01 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 15 Aug 2013 21:00:01 -0400 (EDT) Subject: WaPo writes about vulnerabilities in Supermicro IPMIs Message-ID: <21288797.3692.1376614801039.JavaMail.root@benjamin.baylink.com> Presumably, everyone else's are very religious as well. Is anyone here stupid enough not to put the management interfaces behind a firewall/VPN? http://www.washingtonpost.com/blogs/the-switch/wp/2013/08/14/researchers-figure-out-how-to-hack-tens-of-thousands-of-servers/ And should I be nervous that Usenix pointed me *there* for the story, rather than a tech press outlet? 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 nanog at jima.us Fri Aug 16 01:03:57 2013 From: nanog at jima.us (Jima) Date: Thu, 15 Aug 2013 19:03:57 -0600 Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: <21288797.3692.1376614801039.JavaMail.root@benjamin.baylink.com> References: <21288797.3692.1376614801039.JavaMail.root@benjamin.baylink.com> Message-ID: <520D7A7D.1080509@jima.us> On 2013-08-15 19:00, Jay Ashworth wrote: > Presumably, everyone else's are very religious as well. > > Is anyone here stupid enough not to put the management interfaces behind > a firewall/VPN? That was my initial thought, too. Jima From Valdis.Kletnieks at vt.edu Fri Aug 16 01:47:51 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 15 Aug 2013 21:47:51 -0400 Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: Your message of "Thu, 15 Aug 2013 21:00:01 -0400." <21288797.3692.1376614801039.JavaMail.root@benjamin.baylink.com> References: <21288797.3692.1376614801039.JavaMail.root@benjamin.baylink.com> Message-ID: <10139.1376617671@turing-police.cc.vt.edu> On Thu, 15 Aug 2013 21:00:01 -0400, Jay Ashworth said: > Presumably, everyone else's are very religious as well. > > Is anyone here stupid enough not to put the management interfaces behind > a firewall/VPN? In most cases, this requires plugging in two separate ethernet cables without wondering why you asked to be provisioned one IP address.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From surfer at mauigateway.com Fri Aug 16 01:53:36 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 15 Aug 2013 18:53:36 -0700 Subject: WaPo writes about vulnerabilities in Supermicro IPMIs Message-ID: <20130815185336.7B35C4CC@resin11.mta.everyone.net> On 2013-08-15 19:00, Jay Ashworth wrote: > Is anyone here stupid enough not to put the management interfaces behind > a firewall/VPN? --------------------------------------------------- Pain is a great teacher... scott From LarrySheldon at cox.net Fri Aug 16 02:14:03 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 15 Aug 2013 21:14:03 -0500 Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: References: Message-ID: <520D8AEB.5030406@cox.net> On 8/15/2013 8:53 PM, Scott Weeks wrote: > > > On 2013-08-15 19:00, Jay Ashworth wrote: > >> Is anyone here stupid enough not to put the management interfaces >> behind a firewall/VPN? > --------------------------------------------------- > > > Pain is a great teacher... The problem is getting the one that learned to transfer what was learned to the person hired as the replacement for the idiot that did the learning. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From lists.nanog at monmotha.net Fri Aug 16 02:18:02 2013 From: lists.nanog at monmotha.net (Brandon Martin) Date: Thu, 15 Aug 2013 22:18:02 -0400 Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: <21288797.3692.1376614801039.JavaMail.root@benjamin.baylink.com> References: <21288797.3692.1376614801039.JavaMail.root@benjamin.baylink.com> Message-ID: <520D8BDA.1010504@monmotha.net> On 08/15/2013 09:00 PM, Jay Ashworth wrote: > Presumably, everyone else's are very religious as well. > > Is anyone here stupid enough not to put the management interfaces behind > a firewall/VPN? > > http://www.washingtonpost.com/blogs/the-switch/wp/2013/08/14/researchers-figure-out-how-to-hack-tens-of-thousands-of-servers/ > > And should I be nervous that Usenix pointed me *there* for the story, > rather than a tech press outlet? Unfortunately that article is somewhat light on the technical details, but AFAIK, SuperMicro has fixed most of the egregious implementation issues, like the one that let you bounce spam off the SSH server without even authenticating, and the remainder are mostly mitigated by properly configuring the IPMI to ensure Anonymous and whatnot is disabled, passwords are not at the default, etc. Sadly, the default configuration is still grossly insecure, of course, and the thing will do everything it can to hop onto the same network you plug the primary NIC into. In general, the thing seems to be designed by the lowest cost bidder who didn't take security into account at all and probably has no idea as to the security implications of their decisions. I wouldn't be surprised in the slightest if the thing is still riddled with buffer overflows, etc. that could allow an actual targeted attack to bypass a proper configuration. The documentation they (SuperMicro) ship is also atrocious and basically amounts to nothing more than "change the ADMIN password" in terms of its security recommendations, which isn't even all that effective: the Anonymous IPMI user can, by default, launch the SOL. FWIW, the "IP access control" features do (probably) work reasonably. They just drop what you'd expect straight into the INPUT chain of iptables on the embedded Linux system on which all this stuff runs. There's probably a race during startup where some stuff is running before the rules are applied, but that would lower your attack surface a lot and should, barring a Linux kernel bug (and figure the kernel on this thing is probably hacked up), be effective once the rules are in place. As to why people wouldn't put them behind dedicated firewalls, imagine something like a single-server colo scenario. Most such providers don't offer any form of lights-out management aside from maybe remote reboot (power-cycle) nor do they offer any form of protected/secondary network to their customers. So, if you want to save yourself from a trip, you chuck the thing raw on a public IP and hope you configured it right. This is certainly not a great idea, and it's definitely not my preference, and I would never recommend somebody do it, but I'm sure it happens. If you've got enough resources to build a "real" network to which the box is hooked up, which should be the case in pretty much ANY other scenario, then you have no excuse for not putting the thing on a dedicated/restricted management network, of course. It would be really nice if SuperMicro would offer some options to do things like completely disable the IPMI and only allow e.g. SSH/SOL or iKVM (which needs work, itself) access, since I suspect that's all most people are using in scenarios like the above, and the IPMI is one of the most arcane and difficult to secure parts of the BMC software (while also being one of the most powerful in terms of datacenter automation). -- Brandon Martin From jra at baylink.com Fri Aug 16 02:36:28 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 15 Aug 2013 22:36:28 -0400 (EDT) Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: <10139.1376617671@turing-police.cc.vt.edu> Message-ID: <8181012.3694.1376620588000.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > > Is anyone here stupid enough not to put the management interfaces > > behind a firewall/VPN? > > In most cases, this requires plugging in two separate ethernet cables > without wondering why you asked to be provisioned one IP address.... Hey; on my very first colo deploy, I was smart enough to put public, private and ILO on separate VLANs. Well, ok, I put ILO on the private VLAN, and just put it in a disjoint network, but still... :-) 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 jra at baylink.com Fri Aug 16 02:46:13 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 15 Aug 2013 22:46:13 -0400 (EDT) Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: <520D8BDA.1010504@monmotha.net> Message-ID: <10832266.3696.1376621173310.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brandon Martin" > As to why people wouldn't put them behind dedicated firewalls, imagine > something like a single-server colo scenario. Most such providers don't > offer any form of lights-out management aside from maybe remote reboot > (power-cycle) nor do they offer any form of protected/secondary network > to their customers. So, if you want to save yourself from a trip, you > chuck the thing raw on a public IP and hope you configured it right. Well, *I* would firewall eth1 from eth0 and cross-over eth1 to the ILO jack; let the box be the firewall. Sure, it's still as breakable as the box proper, but security-by-obscurity isn't *bad*, it's just *not good enough*. It's another layer of tape. Whether it's teflon or Gorilla is up to you. 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 jof at thejof.com Fri Aug 16 02:56:36 2013 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 15 Aug 2013 19:56:36 -0700 Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: <10832266.3696.1376621173310.JavaMail.root@benjamin.baylink.com> References: <520D8BDA.1010504@monmotha.net> <10832266.3696.1376621173310.JavaMail.root@benjamin.baylink.com> Message-ID: The primary point of IPMI for most users is to be able to administer and control the box when it's not running. Using the host itself as a firewall is the quickest way to get that BMC online, but it kinda defeats the purpose. On Thu, Aug 15, 2013 at 7:46 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Brandon Martin" > > > As to why people wouldn't put them behind dedicated firewalls, imagine > > something like a single-server colo scenario. Most such providers don't > > offer any form of lights-out management aside from maybe remote reboot > > (power-cycle) nor do they offer any form of protected/secondary network > > to their customers. So, if you want to save yourself from a trip, you > > chuck the thing raw on a public IP and hope you configured it right. > > Well, *I* would firewall eth1 from eth0 and cross-over eth1 to the ILO > jack; > let the box be the firewall. Sure, it's still as breakable as the box > proper, but security-by-obscurity isn't *bad*, it's just *not good enough*. > > It's another layer of tape. > > Whether it's teflon or Gorilla is up to you. > > 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 aj at jonesy.com.au Fri Aug 16 02:59:47 2013 From: aj at jonesy.com.au (Andrew Jones) Date: Fri, 16 Aug 2013 12:59:47 +1000 Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: <10832266.3696.1376621173310.JavaMail.root@benjamin.baylink.com> References: <10832266.3696.1376621173310.JavaMail.root@benjamin.baylink.com> Message-ID: <650753103856f99b2ad6b2c03e4eb6d7@jonesy.com.au> On 16.08.2013 12:46, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Brandon Martin" > >> As to why people wouldn't put them behind dedicated firewalls, >> imagine >> something like a single-server colo scenario. Most such providers >> don't >> offer any form of lights-out management aside from maybe remote >> reboot >> (power-cycle) nor do they offer any form of protected/secondary >> network >> to their customers. So, if you want to save yourself from a trip, >> you >> chuck the thing raw on a public IP and hope you configured it right. > > Well, *I* would firewall eth1 from eth0 and cross-over eth1 to the > ILO jack; > let the box be the firewall. Sure, it's still as breakable as the > box > proper, but security-by-obscurity isn't *bad*, it's just *not good > enough*. That's great until you muck up your firewall config or the kernel hangs etc. and you're up for a trip to the data centre. From josmon at rigozsaurus.com Fri Aug 16 03:11:11 2013 From: josmon at rigozsaurus.com (John Osmon) Date: Thu, 15 Aug 2013 21:11:11 -0600 Subject: How big is the Internet? In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> <710B24A9-C5C7-4BB5-AA24-9DD325BF0F4E@ianai.net> <8D32F6E7-B43A-4AAF-A69C-5EC873E6EC00@gdt.id.au> Message-ID: <20130816031111.GA27011@jeeves.rigozsaurus.com> On Thu, Aug 15, 2013 at 06:04:19PM -0400, Tony Tauber wrote: > All this goes to the point that the original question was poorly worded and > I daresay ill-conceived. Are you saying there *are* dumb questions? :-) From mailinglists at expresswebsystems.com Fri Aug 16 03:38:55 2013 From: mailinglists at expresswebsystems.com (Tom Walsh - EWS) Date: Thu, 15 Aug 2013 22:38:55 -0500 Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: <10139.1376617671@turing-police.cc.vt.edu> References: <21288797.3692.1376614801039.JavaMail.root@benjamin.baylink.com> <10139.1376617671@turing-police.cc.vt.edu> Message-ID: <017801ce9a32$22e77700$68b66500$@com> > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Thursday, August 15, 2013 8:48 PM > To: Jay Ashworth > Cc: NANOG > Subject: Re: WaPo writes about vulnerabilities in Supermicro IPMIs > > On Thu, 15 Aug 2013 21:00:01 -0400, Jay Ashworth said: > > Presumably, everyone else's are very religious as well. > > > > Is anyone here stupid enough not to put the management interfaces > > behind a firewall/VPN? > > In most cases, this requires plugging in two separate ethernet cables > without wondering why you asked to be provisioned one IP address.... I would just like to point out that the Supermicro IPMI interface (on the built in IPMI cards in the X8*-F boards and greater) automatically proxy the IPMI interface with the ETH0 interface if a connection isn't present on the physical interface. So in certain circumstances (dhcpd on eth0, IPMI defaults to dhcp as well) you can be exposing the IPMI interface and not even know it. The Supermicro IPMI has an incredibly poor security history (even in its relatively short life span). There were some initial versions of the IPMI SSHd that allowed a complete bypass of the SSHd auth mechanism on the IPMI interface. I believe that there was also a backdoor username and password combination in some of the earlier firmware revisions. Supermicro IPMI interfaces should be isolated at all costs, and many in the dedicated server hosting industry are well aware of this fact. There has been some in depth discussion about the security of these things for several years on a couple of forums (WHT). From jra at baylink.com Fri Aug 16 03:43:05 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 15 Aug 2013 23:43:05 -0400 (EDT) Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: <650753103856f99b2ad6b2c03e4eb6d7@jonesy.com.au> Message-ID: <20969208.3714.1376624585918.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Andrew Jones" > > Well, *I* would firewall eth1 from eth0 and cross-over eth1 to the ILO jack; > > let the box be the firewall. Sure, it's still as breakable as the box > > proper, but security-by-obscurity isn't *bad*, it's just *not good > > enough*. > > That's great until you muck up your firewall config or the kernel > hangs etc. and you're up for a trip to the data centre. Sure. But if you can reduce 1% to 1% of 1%, then you've still done something useful. 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 jra at baylink.com Fri Aug 16 03:48:40 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 15 Aug 2013 23:48:40 -0400 (EDT) Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: Message-ID: <25560093.3718.1376624920355.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jonathan Lassoff" > The primary point of IPMI for most users is to be able to administer > and control the box when it's not running. > Using the host itself as a firewall is the quickest way to get that > BMC online, but it kinda defeats the purpose. Wow. I don't get caught by Flat Earth Syndrome much... but when I do, it's a doozy. Fair point, Jon. 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 patrick at ianai.net Fri Aug 16 04:19:18 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 16 Aug 2013 00:19:18 -0400 Subject: How big is the Internet? In-Reply-To: <15226028.3612.1376611361409.JavaMail.root@benjamin.baylink.com> References: <15226028.3612.1376611361409.JavaMail.root@benjamin.baylink.com> Message-ID: On Aug 15, 2013, at 20:02 , Jay Ashworth wrote: >> From: "Warren Bailey" > >> I neglected to say one additional thing which I think may be worth reading >> before replying. I have always held the opinion that internet traffic >> isn't internet traffic until it hits the Internet, which I defined as >> two or more autonomous systems functioning on their own but possessing the >> ability to relay information between the two. I'm pretty sure that if >> you have a single network, you couldn't label it "inter" unless "inter" >> was between yourself - and then you have a network.. Not an internetwork. > > I suspect that, to a first approximation, "traffic which passes through the > edge of at least one AS" is probably what most people think of as 'Internet' > traffic. As per my original post to this thread, that would remove all traffic from Akamai on-net nodes, Google's GGC nodes, Netflix's on-net Open Connect nodes, and many others. If you are a broadband network in many countries, that is well over half the traffic going down your customer's pipes. I think most people would alter their definition to count that traffic. > As for your DNS question: the interior query isn't, per-se, but the > repeated one from your resolver/proxy *is*. I don't think the type of packet (DNS, HTTP, SMTP, etc. or even TCP, IP, ICMP) should matter. -- 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 kyle.creyts at gmail.com Fri Aug 16 04:22:14 2013 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Thu, 15 Aug 2013 21:22:14 -0700 Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: <21288797.3692.1376614801039.JavaMail.root@benjamin.baylink.com> References: <21288797.3692.1376614801039.JavaMail.root@benjamin.baylink.com> Message-ID: just so we're all clear, SuperMicro wasn't the only one... link: http://pastebin.com/syXHLuC5 1. CVE-2013-4782 CVSS Base Score = 10.0 2. The SuperMicro BMC implementation allows remote attackers to bypass authentication and execute arbitrary IPMI commands by using cipher suite 0 (aka cipher zero) and an arbitrary password. 3. 4. CVE-2013-4783 CVSS Base Score = 10.0 5. The Dell iDRAC 6 BMC implementation allows remote attackers to bypass authentication and execute arbitrary IPMI commands by using cipher suite 0 (aka cipher zero) and an arbitrary password. 6. 7. CVE-2013-4784 CVSS Base Score = 10.0 8. The HP Integrated Lights-Out (iLO) BMC implementation allows remote attackers to bypass authentication and execute arbitrary IPMI commands by using cipher suite 0 (aka cipher zero) and an arbitrary password. 9. 10. CVE-2013-4785 CVSS Base Score = 10.0 11. iDRAC 6 firmware 1.7, and possibly other versions, allows remote attackers to modify the CLP interface for arbitrary users and possibly have other impact via a request to an unspecified form that is accessible from testurls.html. 12. 13. CVE-2013-4786 CVSS Base Score = 7.8 14. The IPMI 2.0 specification supports RMCP+ Authenticated Key-Exchange Protocol (RAKP) authentication, which allows remote attackers to obtain password hashes and conduct offline password guessing attacks by obtaining the HMAC from a RAKP message 2 responses from a BMC. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4782 => http://fish2.com/ipmi/cipherzero.html http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4783 => http://fish2.com/ipmi/cipherzero.html http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4784 => http://fish2.com/ipmi/cipherzero.html http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4785 => http://fish2.com/ipmi/dell/secret.html http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4786 => http://fish2.com/ipmi/remote-pw-cracking.html On Thu, Aug 15, 2013 at 6:00 PM, Jay Ashworth wrote: > Presumably, everyone else's are very religious as well. > > Is anyone here stupid enough not to put the management interfaces behind > a firewall/VPN? > > http://www.washingtonpost.com/blogs/the-switch/wp/2013/08/14/researchers-figure-out-how-to-hack-tens-of-thousands-of-servers/ > > And should I be nervous that Usenix pointed me *there* for the story, > rather than a tech press outlet? > > 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 > -- Kyle Creyts Information Assurance Professional Founder BSidesDetroit From jra at baylink.com Fri Aug 16 04:26:05 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 16 Aug 2013 00:26:05 -0400 (EDT) Subject: How big is the Internet? In-Reply-To: Message-ID: <2576347.3730.1376627165681.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Patrick W. Gilmore" > > I suspect that, to a first approximation, "traffic which passes through the > > edge of at least one AS" is probably what most people think of as > > 'Internet' traffic. > > As per my original post to this thread, that would remove all traffic > from Akamai on-net nodes, Google's GGC nodes, Netflix's on-net Open > Connect nodes, and many others. > > If you are a broadband network in many countries, that is well over > half the traffic going down your customer's pipes. > > I think most people would alter their definition to count that > traffic. Ok, "to a zeroth approximation". That said: it depends on what you're trying to measure, as has been pointed out before: the entire *point* of edge caching is "to get all that duplicated traffic 'off of the Internet'," no? > > As for your DNS question: the interior query isn't, per-se, but the > > repeated one from your resolver/proxy *is*. > > I don't think the type of packet (DNS, HTTP, SMTP, etc. or even TCP, > IP, ICMP) should matter. The rest of those are generally not application-level proxied the way DNS is with most consumer edge NAT routers. 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 sean at donelan.com Fri Aug 16 04:37:20 2013 From: sean at donelan.com (Sean Donelan) Date: Fri, 16 Aug 2013 00:37:20 -0400 (EDT) Subject: How big is the Internet? In-Reply-To: <520CEF67.9000007@rollernet.us> References: <12596311.3588.1376536308445.JavaMail.root@benjamin.baylink.com> <520CEF67.9000007@rollernet.us> Message-ID: On Thu, 15 Aug 2013, Seth Mattinen wrote: > We'll also need this data in units of number of Libraries of Congress. The researchers at the Library of Congress are more than happy to explain why you are wrong to attempt to use the Library of Congress as a unit of measure, and why the estimates being used are wrong. http://blogs.loc.gov/digitalpreservation/2011/07/transferring-libraries-of-congress-of-data/ along with several other blog posts over the years. But it doesn't seem to stop people from wanting to 1) know how big the Library of Congress is and 2) using it as a unit of measure. It seems odd that there are relatively good estimates for other communication networks and utilities; i.e. how big is the PSTN, how many television or radio stations, how much freight is carried by railroads, trucks and ships. But asking how big is the Internet, how much data does it carry, ends up with no answer. Even the researchers at the Library of Congress, if you give them enough beer and beg them enough, will eventually give you an estimate about the Library collection size as of the end of the last year. What so special about the Internet that it can't be measured? From patrick at ianai.net Fri Aug 16 04:46:06 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 16 Aug 2013 00:46:06 -0400 Subject: How big is the Internet? In-Reply-To: References: <12596311.3588.1376536308445.JavaMail.root@benjamin.baylink.com> <520CEF67.9000007@rollernet.us> Message-ID: <7C368B62-BC06-41B9-9CB9-DA885CCD915C@ianai.net> On Aug 16, 2013, at 00:37 , Sean Donelan wrote: > On Thu, 15 Aug 2013, Seth Mattinen wrote: >> We'll also need this data in units of number of Libraries of Congress. > > The researchers at the Library of Congress are more than happy to explain why you are wrong to attempt to use the Library of Congress as a unit of measure, and why the estimates being used are wrong. > > http://blogs.loc.gov/digitalpreservation/2011/07/transferring-libraries-of-congress-of-data/ > > along with several other blog posts over the years. > > But it doesn't seem to stop people from wanting to 1) know how big the Library of Congress is and 2) using it as a unit of measure. > > It seems odd that there are relatively good estimates for other communication networks and utilities; i.e. how big is the PSTN, how many television or radio stations, how much freight is carried by railroads, trucks and ships. But asking how big is the Internet, how much data does it carry, ends up with no answer. > > Even the researchers at the Library of Congress, if you give them enough beer and beg them enough, will eventually give you an estimate > about the Library collection size as of the end of the last year. > > What so special about the Internet that it can't be measured? Complete lack of regulation, and in many cases, even billing. You cannot make a call on the PSTN without someone getting money from someone else and a CDR () being created. Television & radio stations are trivially countable and probably literally a a dozen or more orders of magnitude off the number of packets on the Internet. Railroads are similarly tiny in number and bill for freight. Roads are built by taxpayer dollars, so the gov't keeps a good account. Etc., etc. The Internet is the first world-wide "thing" that doesn't bill based on where you send something, what you are doing, why you do it, and in many cases, even how much you do. Moreover, anyone can set up anything on it without asking the gov't for permission. This has enabled the impossible growth curve seen the last 20 years, but also made it impossible to count, categorize, or control. Which pisses off some people (usually governments), but makes others (e.g. me!) all warm & fuzzy inside. -- TTFN, patrick P.S. I know you already knew the answer to the question, but I figured you wanted it answered when you asked, so I did. -------------- 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 surfer at mauigateway.com Fri Aug 16 04:55:25 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 15 Aug 2013 21:55:25 -0700 Subject: How big is the Internet? Message-ID: <20130815215525.7B353642@resin11.mta.everyone.net> Ok, I'll put on my flame-proof undies, have some fun and bite at this one... --- sean at donelan.com wrote: From: Sean Donelan :: It seems odd that there are relatively good estimates :: for other communication networks and utilities; i.e. :: how big is the PSTN :: how many television or radio stations, :: how much freight is carried by railroads, trucks and ships. centralized control :: But asking how big is the Internet [...] What so special :: about the Internet that it can't be measured? Not controlled by small groups of people in positions of power. Thus innovation flourishes. Yay! :-) scott From jmamodio at gmail.com Fri Aug 16 06:46:56 2013 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 16 Aug 2013 01:46:56 -0500 Subject: How big is the Internet? In-Reply-To: <20130815215525.7B353642@resin11.mta.everyone.net> References: <20130815215525.7B353642@resin11.mta.everyone.net> Message-ID: <10CDB72A-C8FE-4B28-AD65-9522179E4B46@gmail.com> You are absolutely right -Jorge On Aug 15, 2013, at 11:55 PM, "Scott Weeks" wrote: > > Ok, I'll put on my flame-proof undies, have some fun > and bite at this one... > > > --- sean at donelan.com wrote: > From: Sean Donelan > > :: It seems odd that there are relatively good estimates > :: for other communication networks and utilities; i.e. > > :: how big is the PSTN > :: how many television or radio stations, > :: how much freight is carried by railroads, trucks and ships. > > centralized control > > > :: But asking how big is the Internet [...] What so special > :: about the Internet that it can't be measured? > > Not controlled by small groups of people in positions of power. > Thus innovation flourishes. Yay! :-) > > scott > From BECHA at ripe.net Fri Aug 16 09:42:21 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 16 Aug 2013 11:42:21 +0200 Subject: How big is the Internet? usage of electricity = coal for ICT In-Reply-To: References: <520B9DFD.1080405@yahoo.com> <520B9F14.1040801@teksavvy.ca> Message-ID: <520DF3FD.5040600@ripe.net> Hi, On 14/08/13 9:00 , Sean Donelan wrote: > > I should have remembered, NANOG prefers to correct things. So here are > several estimates about how much IP/Internet traffic is downloaded > in a month. Does anyone have better numbers, or better souces of > numbers that can be shared? No source, but a pretty quote: "In the near future, hourly Internet traffic will exceed the Internet?s annual traffic in the year 2000." http://thebreakthrough.org/index.php/programs/economic-growth/bracing-for-the-cloud/ Vesna From dsparro at gmail.com Fri Aug 16 13:15:56 2013 From: dsparro at gmail.com (Dave Sparro) Date: Fri, 16 Aug 2013 09:15:56 -0400 Subject: How big is the Internet? In-Reply-To: <7C368B62-BC06-41B9-9CB9-DA885CCD915C@ianai.net> References: <12596311.3588.1376536308445.JavaMail.root@benjamin.baylink.com> <520CEF67.9000007@rollernet.us> <7C368B62-BC06-41B9-9CB9-DA885CCD915C@ianai.net> Message-ID: <520E260C.2070001@gmail.com> On 8/16/2013 12:46 AM, Patrick W. Gilmore wrote: > On Aug 16, 2013, at 00:37 , Sean Donelan wrote: >> On Thu, 15 Aug 2013, Seth Mattinen wrote: >>> We'll also need this data in units of number of Libraries of Congress. >> The researchers at the Library of Congress are more than happy to explain why you are wrong to attempt to use the Library of Congress as a unit of measure, and why the estimates being used are wrong. >> >> http://blogs.loc.gov/digitalpreservation/2011/07/transferring-libraries-of-congress-of-data/ >> >> along with several other blog posts over the years. >> >> But it doesn't seem to stop people from wanting to 1) know how big the Library of Congress is and 2) using it as a unit of measure. >> >> It seems odd that there are relatively good estimates for other communication networks and utilities; i.e. how big is the PSTN, how many television or radio stations, how much freight is carried by railroads, trucks and ships. But asking how big is the Internet, how much data does it carry, ends up with no answer. >> >> Even the researchers at the Library of Congress, if you give them enough beer and beg them enough, will eventually give you an estimate >> about the Library collection size as of the end of the last year. >> >> What so special about the Internet that it can't be measured? > Complete lack of regulation, and in many cases, even billing. > > You cannot make a call on the PSTN without someone getting money from someone else and a CDR () being created. Television & radio stations are trivially countable and probably literally a a dozen or more orders of magnitude off the number of packets on the Internet. Railroads are similarly tiny in number and bill for freight. Roads are built by taxpayer dollars, so the gov't keeps a good account. Etc., etc. > > The Internet is the first world-wide "thing" that doesn't bill based on where you send something, what you are doing, why you do it, and in many cases, even how much you do. Moreover, anyone can set up anything on it without asking the gov't for permission. > > This has enabled the impossible growth curve seen the last 20 years, but also made it impossible to count, categorize, or control. Which pisses off some people (usually governments), but makes others (e.g. me!) all warm & fuzzy inside. > That's probably the best answer, but I'd add that nobody has gathered sufficient quantities of beer to give to the for-profit companies that are in a position to gather the requested data. If somebody wants to collect that much beer, what would the rest of us drink? -- Dave From bmanning at vacation.karoshi.com Fri Aug 16 14:06:17 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 16 Aug 2013 14:06:17 +0000 Subject: How big is the Internet? In-Reply-To: References: <12596311.3588.1376536308445.JavaMail.root@benjamin.baylink.com> <520CEF67.9000007@rollernet.us> Message-ID: <20130816140617.GA12276@vacation.karoshi.com.> On Fri, Aug 16, 2013 at 12:37:20AM -0400, Sean Donelan wrote: > Even the researchers at the Library of Congress, if you give them > enough beer and beg them enough, will eventually give you an estimate > about the Library collection size as of the end of the last year. > > What so special about the Internet that it can't be measured? The problem is that is can be measured, along a large number variables. The LOC question, How Big? Might be linear shelf space, sqft, number of items, number of warehouses, number of employees, budget, etc. The base question, How Big needs a qualifier or two. Same with the Internet. How big makes no sense. How much traffic begs the question of measured from where. A unique attribute of IP based transport is that -as far as I know- there is no measurement point between -every- pair of nodes that might exchange traffic. And since the instrumentation does not exist, you'll never get the numbers. Select other vectors and the problem remains, the instrumentation is poor or non-existant. Any numbers that are derived are incomplete and/or estimates. Pick your poision. /bill From bicknell at ufp.org Fri Aug 16 14:14:43 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 16 Aug 2013 09:14:43 -0500 Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: <520D8BDA.1010504@monmotha.net> References: <21288797.3692.1376614801039.JavaMail.root@benjamin.baylink.com> <520D8BDA.1010504@monmotha.net> Message-ID: <75FB9B0C-C170-418F-A753-32680B384978@ufp.org> On Aug 15, 2013, at 9:18 PM, Brandon Martin wrote: > As to why people wouldn't put them behind dedicated firewalls, imagine something like a single-server colo scenario. I have asked about this on other lists, but I'll ask here. Does anyone know of a small (think Raspberry Pi sized) device that is: 1) USB powered. 2) Has two ethernet ports. 3) Runs some sort of standard open source OS? You might already see where I'm going with this, a small 2-port firewall device sitting in front of IPMI, and powered off the USB bus of the server. That way another RU isn't required. Making it fit in an expansion card slot and using an internal USB header might be interesting too, so from the outside it wasn't obvious what it was. I would actually like to see the thing only respond on the USB side, power + console, enabling consoling in and changing L2 firewall rules. No IP stack on it what so ever. That would be highly secure and simple. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From ahebert at pubnix.net Fri Aug 16 14:17:35 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 16 Aug 2013 10:17:35 -0400 Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: References: <21288797.3692.1376614801039.JavaMail.root@benjamin.baylink.com> Message-ID: <520E347F.6010000@pubnix.net> Hi, I find it odd that this is suddenly news... There is plenty of security updates for iBMC/iDrac/etc from IBM/HP/Dell/etc over the years. But: You can use ipmitool, rootkit/exploit some Linux box and upload your own firmware in that iBMC/iDrac/etc... for example the BMC firmware for a Dell C1100 leave plenty of space to inject your own shell in it. And Voila! access to the management network =D. BTW I got ipmitool working even on VMWare 5.1 :( Counter: We (PCIDSS hat) always check for those management interfaces and "proposed" to move those interfaces into they own VLANs+Subnets. Meaning: PCI DMZ Zone has its own DMZ iBMC VLAN/Subnet/FW Rules, PCI DB Zone has its own iBMC VLAN/Subnet/FW Rules, etc. It is a few more VLAN/Subnets... but modern Firewall can handle this easy. PS: "proposed" as in not giving them a choice =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 08/16/13 00:22, Kyle Creyts wrote: > just so we're all clear, SuperMicro wasn't the only one... > > link: http://pastebin.com/syXHLuC5 > > 1. CVE-2013-4782 CVSS Base Score = 10.0 > 2. The SuperMicro BMC implementation allows remote attackers to > bypass authentication and execute arbitrary IPMI commands by using > cipher suite 0 (aka cipher zero) and an arbitrary password. > 3. > 4. CVE-2013-4783 CVSS Base Score = 10.0 > 5. The Dell iDRAC 6 BMC implementation allows remote attackers to > bypass authentication and execute arbitrary IPMI commands by using > cipher suite 0 (aka cipher zero) and an arbitrary password. > 6. > 7. CVE-2013-4784 CVSS Base Score = 10.0 > 8. The HP Integrated Lights-Out (iLO) BMC implementation allows > remote attackers to bypass authentication and execute arbitrary IPMI > commands by using cipher suite 0 (aka cipher zero) and an arbitrary > password. > 9. > 10. CVE-2013-4785 CVSS Base Score = 10.0 > 11. iDRAC 6 firmware 1.7, and possibly other versions, allows remote > attackers to modify the CLP interface for arbitrary users and possibly > have other impact via a request to an unspecified form that is > accessible from testurls.html. > 12. > 13. CVE-2013-4786 CVSS Base Score = 7.8 > 14. The IPMI 2.0 specification supports RMCP+ Authenticated > Key-Exchange Protocol (RAKP) authentication, which allows remote > attackers to obtain password hashes and conduct offline password > guessing attacks by obtaining the HMAC from a RAKP message 2 responses > from a BMC. > > > References: > > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4782 > => http://fish2.com/ipmi/cipherzero.html > > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4783 > => http://fish2.com/ipmi/cipherzero.html > > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4784 > => http://fish2.com/ipmi/cipherzero.html > > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4785 > => http://fish2.com/ipmi/dell/secret.html > > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4786 > => http://fish2.com/ipmi/remote-pw-cracking.html > > On Thu, Aug 15, 2013 at 6:00 PM, Jay Ashworth wrote: >> Presumably, everyone else's are very religious as well. >> >> Is anyone here stupid enough not to put the management interfaces behind >> a firewall/VPN? >> >> http://www.washingtonpost.com/blogs/the-switch/wp/2013/08/14/researchers-figure-out-how-to-hack-tens-of-thousands-of-servers/ >> >> And should I be nervous that Usenix pointed me *there* for the story, >> rather than a tech press outlet? >> >> 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 smb at cs.columbia.edu Fri Aug 16 15:34:34 2013 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 16 Aug 2013 11:34:34 -0400 Subject: Practical effects of DNSSEC deployment Message-ID: <41BF2D77-F740-4B52-9F5F-31F1CCC35CB6@cs.columbia.edu> There was an interesting paper at Usenix Security on the effects of deploying DNSSEC; see https://www.usenix.org/conference/usenixsecurity13/measuring-practical-impact-dnssec-deployment . The difference in geographical impact was quite striking. --Steve Bellovin, https://www.cs.columbia.edu/~smb From rps at maine.edu Fri Aug 16 16:05:44 2013 From: rps at maine.edu (Ray Soucy) Date: Fri, 16 Aug 2013 12:05:44 -0400 Subject: Cisco DMVPN Configuration Question Message-ID: Don't usually poke NANOG for a second pair of eyes, but got hit with an urgent need to get connectivity up on a small budget. I've run into a situation where I require multiple DMVPN spokes to be behind a single NAT IP (picture of things to come with CGN?) The DMVPN endpoint works fine behind NAT until a 2nd is added behind the same IP address. At that point the hub gets confused and I start seeing packet loss to the endpoints in a round-robin fashion. As far as I can see Cisco documentation says pretty clearly that each DMVPN spoke requires a unique IP address. Is there any way around this, or do I need to be looking at an alternative VPN solution? Hub config: ----8<---- description DMVPN bandwidth 100000 ip address 10.231.254.1 255.255.255.0 no ip redirects ip mtu 1400 ip nhrp authentication ! removed ip nhrp map multicast dynamic ip nhrp network-id 1 ip nhrp redirect ip tcp adjust-mss 1360 tunnel source ! removed tunnel mode gre multipoint tunnel key 0 tunnel protection ipsec profile DMVPN ----8<---- Spoke: ----8<---- interface Tunnel2 description DMVPN bandwidth 100000 ip vrf forwarding DMVPN ip address 10.231.254.10 255.255.255.0 no ip redirects ip mtu 1400 ip nhrp authentication ! removed ip nhrp map multicast ! removed ip nhrp map 10.231.254.1 ! removed ip nhrp network-id 1 ip nhrp nhs 10.231.254.1 ip nhrp shortcut ip tcp adjust-mss 1360 tunnel source FastEthernet0/0 tunnel mode gre multipoint tunnel key 0 tunnel protection ipsec profile DMVPN end ----8<---- -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From tony at lavanauts.org Fri Aug 16 17:25:11 2013 From: tony at lavanauts.org (Antonio Querubin) Date: Fri, 16 Aug 2013 07:25:11 -1000 (HST) Subject: mail.mil contact? Message-ID: Wondering if anyone else is receiving reports of email to mail.mil addresses being delayed or refused? The mail.mil mx appear to be selectively refusing mail. If anyone has good (non-email) contact info for the mail.mil operators please send it my way. Thanks. Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From garrett at skjelstad.org Fri Aug 16 17:37:22 2013 From: garrett at skjelstad.org (Garrett Skjelstad) Date: Fri, 16 Aug 2013 10:37:22 -0700 Subject: Cisco DMVPN Configuration Question In-Reply-To: References: Message-ID: <20D5F59B-D667-42AE-B204-47D10691CE3C@skjelstad.org> No way around this with DMVPN. Sent from my iPhone On Aug 16, 2013, at 9:05, Ray Soucy wrote: > Don't usually poke NANOG for a second pair of eyes, but got hit with an > urgent need to get connectivity up on a small budget. > > I've run into a situation where I require multiple DMVPN spokes to be > behind a single NAT IP (picture of things to come with CGN?) > > The DMVPN endpoint works fine behind NAT until a 2nd is added behind the > same IP address. At that point the hub gets confused and I start seeing > packet loss to the endpoints in a round-robin fashion. > > As far as I can see Cisco documentation says pretty clearly that each DMVPN > spoke requires a unique IP address. Is there any way around this, or do I > need to be looking at an alternative VPN solution? > > Hub config: > > ----8<---- > description DMVPN > bandwidth 100000 > ip address 10.231.254.1 255.255.255.0 > no ip redirects > ip mtu 1400 > ip nhrp authentication ! removed > ip nhrp map multicast dynamic > ip nhrp network-id 1 > ip nhrp redirect > ip tcp adjust-mss 1360 > tunnel source ! removed > tunnel mode gre multipoint > tunnel key 0 > tunnel protection ipsec profile DMVPN > ----8<---- > > Spoke: > > ----8<---- > interface Tunnel2 > description DMVPN > bandwidth 100000 > ip vrf forwarding DMVPN > ip address 10.231.254.10 255.255.255.0 > no ip redirects > ip mtu 1400 > ip nhrp authentication ! removed > ip nhrp map multicast ! removed > ip nhrp map 10.231.254.1 ! removed > ip nhrp network-id 1 > ip nhrp nhs 10.231.254.1 > ip nhrp shortcut > ip tcp adjust-mss 1360 > tunnel source FastEthernet0/0 > tunnel mode gre multipoint > tunnel key 0 > tunnel protection ipsec profile DMVPN > end > ----8<---- > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net From cscora at apnic.net Fri Aug 16 18:33:48 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 Aug 2013 04:33:48 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201308161833.r7GIXmvD019112@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 17 Aug, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 462841 Prefixes after maximum aggregation: 187161 Deaggregation factor: 2.47 Unique aggregates announced to Internet: 229257 Total ASes present in the Internet Routing Table: 44722 Prefixes per ASN: 10.35 Origin-only ASes present in the Internet Routing Table: 34987 Origin ASes announcing only one prefix: 16208 Transit ASes present in the Internet Routing Table: 5885 Transit-only ASes present in the Internet Routing Table: 156 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 29 Max AS path prepend of ASN ( 19037) 22 Prefixes from unregistered ASNs in the Routing Table: 4596 Unregistered ASNs in the Routing Table: 1584 Number of 32-bit ASNs allocated by the RIRs: 4955 Number of 32-bit ASNs visible in the Routing Table: 3850 Prefixes from 32-bit ASNs in the Routing Table: 11664 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 304 Number of addresses announced to Internet: 2635027852 Equivalent to 157 /8s, 15 /16s and 85 /24s Percentage of available address space announced: 71.2 Percentage of allocated address space announced: 71.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.9 Total number of prefixes smaller than registry allocations: 162142 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 110903 Total APNIC prefixes after maximum aggregation: 33605 APNIC Deaggregation factor: 3.30 Prefixes being announced from the APNIC address blocks: 112709 Unique aggregates announced from the APNIC address blocks: 46196 APNIC Region origin ASes present in the Internet Routing Table: 4867 APNIC Prefixes per ASN: 23.16 APNIC Region origin ASes announcing only one prefix: 1223 APNIC Region transit ASes present in the Internet Routing Table: 824 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table: 638 Number of APNIC addresses announced to Internet: 725990208 Equivalent to 43 /8s, 69 /16s and 187 /24s Percentage of available APNIC address space announced: 84.8 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: 160372 Total ARIN prefixes after maximum aggregation: 80867 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 160922 Unique aggregates announced from the ARIN address blocks: 74720 ARIN Region origin ASes present in the Internet Routing Table: 15828 ARIN Prefixes per ASN: 10.17 ARIN Region origin ASes announcing only one prefix: 5998 ARIN Region transit ASes present in the Internet Routing Table: 1660 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: 1070350848 Equivalent to 63 /8s, 204 /16s and 66 /24s Percentage of available ARIN address space announced: 56.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 117912 Total RIPE prefixes after maximum aggregation: 60555 RIPE Deaggregation factor: 1.95 Prefixes being announced from the RIPE address blocks: 121724 Unique aggregates announced from the RIPE address blocks: 78516 RIPE Region origin ASes present in the Internet Routing Table: 17350 RIPE Prefixes per ASN: 7.02 RIPE Region origin ASes announcing only one prefix: 8219 RIPE Region transit ASes present in the Internet Routing Table: 2810 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 27 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2386 Number of RIPE addresses announced to Internet: 656724772 Equivalent to 39 /8s, 36 /16s and 211 /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: 50343 Total LACNIC prefixes after maximum aggregation: 9566 LACNIC Deaggregation factor: 5.26 Prefixes being announced from the LACNIC address blocks: 55020 Unique aggregates announced from the LACNIC address blocks: 25639 LACNIC Region origin ASes present in the Internet Routing Table: 2001 LACNIC Prefixes per ASN: 27.50 LACNIC Region origin ASes announcing only one prefix: 578 LACNIC Region transit ASes present in the Internet Routing Table: 369 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: 801 Number of LACNIC addresses announced to Internet: 135157288 Equivalent to 8 /8s, 14 /16s and 86 /24s Percentage of available LACNIC address space announced: 80.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 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: 11560 Total AfriNIC prefixes after maximum aggregation: 2528 AfriNIC Deaggregation factor: 4.57 Prefixes being announced from the AfriNIC address blocks: 12162 Unique aggregates announced from the AfriNIC address blocks: 3903 AfriNIC Region origin ASes present in the Internet Routing Table: 643 AfriNIC Prefixes per ASN: 18.91 AfriNIC Region origin ASes announcing only one prefix: 190 AfriNIC Region transit ASes present in the Internet Routing Table: 131 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46473728 Equivalent to 2 /8s, 197 /16s and 34 /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 2922 11561 918 Korea Telecom (KIX) 17974 2655 871 92 PT TELEKOMUNIKASI INDONESIA 7545 2056 321 112 TPG Internet Pty Ltd 4755 1780 393 197 TATA Communications formerly 9829 1537 1221 45 BSNL National Internet Backbo 9583 1224 92 504 Sify Limited 9498 1175 309 70 BHARTI Airtel Ltd. 4808 1153 2127 332 CNCGROUP IP network: China169 7552 1139 1080 13 Vietel Corporation 24560 1088 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 2978 3689 62 bellsouth.net, inc. 18566 2065 382 184 Covad Communications 1785 2006 679 125 PaeTec Communications, Inc. 22773 2006 2927 123 Cox Communications, Inc. 20115 1675 1646 621 Charter Communications 4323 1618 1105 408 Time Warner Telecom 701 1521 11103 797 UUNET Technologies, Inc. 30036 1365 305 639 Mediacom Communications Corp 7018 1317 11293 832 AT&T WorldNet Services 11492 1221 218 363 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 1562 544 16 Corbina telecom 34984 1303 244 221 BILISIM TELEKOM 31148 978 43 17 FreeNet ISP 20940 977 349 748 Akamai Technologies European 2118 962 97 13 EUnet/RELCOM Autonomous Syste 6830 898 2371 429 UPC Distribution Services 13188 843 99 70 Educational Network 8551 768 370 45 Bezeq International 12479 687 797 53 Uni2 Autonomous System 58113 541 55 339 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 3129 1655 108 NET Servicos de Comunicao S.A 10620 2668 424 223 TVCABLE BOGOTA 7303 1730 1157 220 Telecom Argentina Stet-France 18881 1359 844 20 Global Village Telecom 8151 1283 2764 392 UniNet S.A. de C.V. 11830 945 364 15 Instituto Costarricense de El 27947 837 94 91 Telconet S.A 6503 787 434 63 AVANTEL, S.A. 6147 738 374 25 Telefonica Del Peru 3816 721 302 83 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 1861 112 5 MOBITEL 24863 874 274 30 LINKdotNET AS number 6713 543 633 26 Itissalat Al-MAGHRIB 8452 438 956 9 TEDATA 24835 291 80 8 RAYA Telecom - Egypt 3741 258 921 217 The Internet Solution 15706 221 32 6 Sudatel Internet Exchange Aut 29571 220 17 12 Ci Telecom Autonomous system 36992 220 501 29 Etisalat MISR 12258 193 28 71 Vodacom Internet Company 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 28573 3129 1655 108 NET Servicos de Comunicao S.A 6389 2978 3689 62 bellsouth.net, inc. 4766 2922 11561 918 Korea Telecom (KIX) 10620 2668 424 223 TVCABLE BOGOTA 17974 2655 871 92 PT TELEKOMUNIKASI INDONESIA 18566 2065 382 184 Covad Communications 7545 2056 321 112 TPG Internet Pty Ltd 1785 2006 679 125 PaeTec Communications, Inc. 22773 2006 2927 123 Cox Communications, Inc. 36998 1861 112 5 MOBITEL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2978 2916 bellsouth.net, inc. 17974 2655 2563 PT TELEKOMUNIKASI INDONESIA 10620 2668 2445 TVCABLE BOGOTA 4766 2922 2004 Korea Telecom (KIX) 7545 2056 1944 TPG Internet Pty Ltd 22773 2006 1883 Cox Communications, Inc. 18566 2065 1881 Covad Communications 1785 2006 1881 PaeTec Communications, Inc. 36998 1861 1856 MOBITEL 4755 1780 1583 TATA Communications formerly 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 30621 UNALLOCATED 12.151.74.0/23 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 100.100.0.0/24 4847 China Networks Inter-Exchange Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.92.16.0/21 8001 Net Access Corporation 23.92.24.0/22 6939 Hurricane Electric 23.92.64.0/24 54540 Incero LLC 23.92.65.0/24 54540 Incero LLC 23.92.66.0/24 54540 Incero LLC 23.92.67.0/24 54540 Incero LLC 23.92.68.0/24 54540 Incero LLC 23.92.69.0/24 54540 Incero LLC 23.92.70.0/24 54540 Incero LLC 23.92.71.0/24 54540 Incero LLC 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:93 /12:250 /13:479 /14:905 /15:1608 /16:12739 /17:6632 /18:11022 /19:22555 /20:32285 /21:34854 /22:48885 /23:42800 /24:244455 /25:1044 /26:1426 /27:597 /28:43 /29:75 /30:18 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2016 2065 Covad Communications 36998 1826 1861 MOBITEL 6389 1713 2978 bellsouth.net, inc. 22773 1304 2006 Cox Communications, Inc. 8402 1271 1562 Corbina telecom 30036 1229 1365 Mediacom Communications Corp 11492 1182 1221 Cable One 1785 1079 2006 PaeTec Communications, Inc. 6983 1024 1152 ITC^Deltacom 10620 990 2668 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:811 2:706 3:3 4:19 5:908 6:17 8:599 12:1897 13:2 14:868 15:11 16:3 17:10 18:19 20:17 23:334 24:1749 27:1540 31:1274 32:45 33:2 34:5 36:70 37:1818 38:898 39:2 40:180 41:3241 42:259 44:9 46:1854 47:3 49:652 50:842 52:12 54:37 55:7 57:26 58:1174 59:644 60:330 61:1494 62:1181 63:1985 64:4348 65:2155 66:4204 67:2016 68:1090 69:3315 70:863 71:492 72:1917 74:2528 75:327 76:305 77:1138 78:1007 79:615 80:1307 81:1018 82:649 83:587 84:569 85:1214 86:471 87:1042 88:537 89:1811 90:158 91:5568 92:625 93:1656 94:2015 95:1556 96:587 97:346 98:1029 99:42 100:29 101:598 103:3147 105:519 106:139 107:210 108:495 109:1865 110:945 111:1098 112:570 113:802 114:729 115:1102 116:956 117:800 118:1146 119:1288 120:363 121:850 122:1807 123:1243 124:1369 125:1411 128:635 129:223 130:302 131:667 132:348 133:160 134:277 135:72 136:259 137:242 138:344 139:189 140:207 141:321 142:532 143:393 144:498 145:93 146:531 147:478 148:678 149:354 150:154 151:589 152:413 153:193 154:30 155:415 156:275 157:405 158:276 159:745 160:349 161:446 162:580 163:222 164:548 165:555 166:255 167:602 168:1033 169:126 170:1071 171:188 172:25 173:1581 174:567 175:491 176:1173 177:2156 178:1899 179:91 180:1516 181:640 182:1225 183:432 184:655 185:757 186:2476 187:1401 188:1796 189:1279 190:7004 192:6867 193:5546 194:4601 195:3595 196:1327 197:985 198:4590 199:5384 200:5981 201:2602 202:8842 203:8870 204:4519 205:2604 206:2833 207:2893 208:3992 209:3589 210:2938 211:1553 212:2253 213:2019 214:928 215:100 216:5254 217:1651 218:618 219:323 220:1277 221:552 222:322 223:465 End of report From sean at donelan.com Fri Aug 16 19:21:07 2013 From: sean at donelan.com (Sean Donelan) Date: Fri, 16 Aug 2013 15:21:07 -0400 (EDT) Subject: How big is the Internet? In-Reply-To: <20130816140617.GA12276@vacation.karoshi.com.> References: <12596311.3588.1376536308445.JavaMail.root@benjamin.baylink.com> <520CEF67.9000007@rollernet.us> <20130816140617.GA12276@vacation.karoshi.com.> Message-ID: On Fri, 16 Aug 2013, bmanning at vacation.karoshi.com wrote: > On Fri, Aug 16, 2013 at 12:37:20AM -0400, Sean Donelan wrote: >> Even the researchers at the Library of Congress, if you give them >> enough beer and beg them enough, will eventually give you an estimate >> about the Library collection size as of the end of the last year. >> >> What so special about the Internet that it can't be measured? > > The problem is that is can be measured, along a large number variables. > > The LOC question, How Big? Might be linear shelf space, sqft, number of > items, number of warehouses, number of employees, budget, etc. The > base question, How Big needs a qualifier or two. So, in the context of the LOC question about using it as a unit of measurement for comparison with storage size or transmission volume; which of those things are information that can be transmitted or electronically stored? If I asked "how big is an elephant?" some zoologists would look for ways the question can't be answered like "elephants grow from birth to death, have different species, may have illnesses, have not measured every elephant, etc."; others might give an answer like "Adult male elephants usually stand ten to thirteen feet tall and can weigh seven to twenty-six thousand pounds. Females elephants tend to be smaller smaller." > Same with the Internet. How big makes no sense. How much traffic begs > the question of measured from where. A unique attribute of IP based > transport is that -as far as I know- there is no measurement point between > -every- pair of nodes that might exchange traffic. That is true of most transportation networks: roads do not have measurement points between every destination point, oceans do not have a measurement point between every port. Intangiable things like the "economy" don't have measurement points at every economic transaction. Yet there are relatively accepted estimates of the size Gross Domestic Product, annual miles driven on US Highways, shipping between countries. > > And since the instrumentation does not exist, you'll never get the numbers. > > Select other vectors and the problem remains, the instrumentation is poor > or non-existant. > > Any numbers that are derived are incomplete and/or estimates. > > Pick your poision. Ed Felten gave the keynote talk at Usenix Security this week. One of the examples he gave was a out-of-town friend asking a technologist for recommendations for a good resturant. Hilarity ensured. If you wonder why other people don't ask technologists for answers, Dr. Felten's talk is a good starting point. From sean at donelan.com Fri Aug 16 19:44:21 2013 From: sean at donelan.com (Sean Donelan) Date: Fri, 16 Aug 2013 15:44:21 -0400 (EDT) Subject: How big is the Internet? - Results Message-ID: Thanks for all the comments. Through the entire thread on-line and off-line only one person contributed an estimate Patrick Gilmore said: All that said: My back-of-the-envelope math says the Internet is order of 1 exabyte/day, as defined by my own rules on what counts as "the Internet"[*]. I could easily be wrong, but you asked. [*] I count Company-to-Company traffic. This is _mostly_ inter-AS traffic, but on-net nodes (e.g. Akamai, Google, NF) -> Provider _do_ count. Things like Google -> Google over Google backbone do not count. Things like as701 -> as702 would count, but not as701 -> as701, even if the traffic is between two single-homed customers. It is a weird definition, but that's how I define it. (Although I may be biased, since counting only inter-AS traffic leaves off $SOME_PERCENTAGE of the traffic from my company.) Since there weren't any other estimates to choose between, looks like I'll go with Gilmore's number. Gilmore's estimate was signifcantly lower than Cisco's VNI. From jlewis at lewis.org Fri Aug 16 20:18:52 2013 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 16 Aug 2013 16:18:52 -0400 (EDT) Subject: How big is the Internet? - Results In-Reply-To: References: Message-ID: On Fri, 16 Aug 2013, Sean Donelan wrote: > > Thanks for all the comments. Through the entire thread on-line and off-line > only one person contributed an estimate > > Patrick Gilmore said: > All that said: My back-of-the-envelope math says the Internet is order > of 1 exabyte/day, as defined by my own rules on what counts as "the > Internet"[*]. I could easily be wrong, but you asked. Perhaps the answers would have made more sense if everyone knew exactly what the question was. :) You asked for an estimate of the "size of the Internet", but didn't specify if you meant number of networks comprising the Internet, number of devices connected to the Internet, combined total transit for all ASNs connected to the Internet, etc. The nature of the Internet is that nobody knows the answers to any of these questions. How do you know what goes on in my networks? So any "answers" are really only wild guesses. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From maillist at webjogger.net Fri Aug 16 20:35:14 2013 From: maillist at webjogger.net (Adam Greene) Date: Fri, 16 Aug 2013 16:35:14 -0400 Subject: will ISP peer with 2 local WAN routers? Message-ID: <014a01ce9ac0$1cab26a0$560173e0$@webjogger.net> Hi guys, I have a customer who peers via eBGP with Lightpath aka Cablevision (AS 6128) and Level3 (AS 3356) and wants to do some dual-WAN router redundancy. I have heard that carriers will sometimes agree to set up a /29 WAN subnet for a customer and peer with (2) customer routers. The customer is delaying on providing me with the proper circuit ID & contact information to be able to call Lightpath and Level3 directly and find out if they will do this, so I thought of asking this list. Is anyone aware if Lightpath and Level3 will agree to something like this? Thanks, Adam From justin.vocke at gmail.com Fri Aug 16 20:46:43 2013 From: justin.vocke at gmail.com (Justin Vocke) Date: Fri, 16 Aug 2013 15:46:43 -0500 Subject: will ISP peer with 2 local WAN routers? In-Reply-To: <014a01ce9ac0$1cab26a0$560173e0$@webjogger.net> References: <014a01ce9ac0$1cab26a0$560173e0$@webjogger.net> Message-ID: The gotcha with that is then you need a switch in front of the routers. I'd just setup a carrier on each router and run ibgp between. Sent from my iPhone On Aug 16, 2013, at 3:35 PM, "Adam Greene" wrote: > Hi guys, > > > > I have a customer who peers via eBGP with Lightpath aka Cablevision (AS > 6128) and Level3 (AS 3356) and wants to do some dual-WAN router redundancy. > > > > I have heard that carriers will sometimes agree to set up a /29 WAN subnet > for a customer and peer with (2) customer routers. > > > > The customer is delaying on providing me with the proper circuit ID & > contact information to be able to call Lightpath and Level3 directly and > find out if they will do this, so I thought of asking this list. > > > > Is anyone aware if Lightpath and Level3 will agree to something like this? > > > > Thanks, > > Adam > > > > > From rcarpen at network1.net Fri Aug 16 21:17:58 2013 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 16 Aug 2013 17:17:58 -0400 (EDT) Subject: will ISP peer with 2 local WAN routers? In-Reply-To: References: <014a01ce9ac0$1cab26a0$560173e0$@webjogger.net> Message-ID: <61FBBE8A-695B-4A9C-8B75-DB418C42521F@network1.net> Time Warner installed a Juniper EX4200 as the CPE device for us, so we connected 2 routers and had two separate BGP sessions. They have us a /29 to accomplish it. -Randy On Aug 16, 2013, at 16:53, Justin Vocke wrote: > The gotcha with that is then you need a switch in front of the routers. I'd just setup a carrier on each router and run ibgp between. > > Sent from my iPhone > > On Aug 16, 2013, at 3:35 PM, "Adam Greene" wrote: > >> Hi guys, >> >> >> >> I have a customer who peers via eBGP with Lightpath aka Cablevision (AS >> 6128) and Level3 (AS 3356) and wants to do some dual-WAN router redundancy. >> >> >> >> I have heard that carriers will sometimes agree to set up a /29 WAN subnet >> for a customer and peer with (2) customer routers. >> >> >> >> The customer is delaying on providing me with the proper circuit ID & >> contact information to be able to call Lightpath and Level3 directly and >> find out if they will do this, so I thought of asking this list. >> >> >> >> Is anyone aware if Lightpath and Level3 will agree to something like this? >> >> >> >> Thanks, >> >> Adam > > From maillist at webjogger.net Fri Aug 16 21:21:18 2013 From: maillist at webjogger.net (Adam Greene) Date: Fri, 16 Aug 2013 17:21:18 -0400 Subject: will ISP peer with 2 local WAN routers? In-Reply-To: References: <014a01ce9ac0$1cab26a0$560173e0$@webjogger.net> Message-ID: <01a101ce9ac6$8c4d4780$a4e7d680$@webjogger.net> Thanks, Justin. Yes, we considered that option, too. But then if one WAN router goes down, the customer will only have connectivity through a single upstream provider. We'd prefer to maintain connectivity to both even if a router fails. Switches in front of the routers is no problem. -----Original Message----- From: Justin Vocke [mailto:justin.vocke at gmail.com] Sent: Friday, August 16, 2013 4:47 PM To: Adam Greene Cc: Subject: Re: will ISP peer with 2 local WAN routers? The gotcha with that is then you need a switch in front of the routers. I'd just setup a carrier on each router and run ibgp between. Sent from my iPhone On Aug 16, 2013, at 3:35 PM, "Adam Greene" wrote: > Hi guys, > > > > I have a customer who peers via eBGP with Lightpath aka Cablevision > (AS > 6128) and Level3 (AS 3356) and wants to do some dual-WAN router redundancy. > > > > I have heard that carriers will sometimes agree to set up a /29 WAN > subnet for a customer and peer with (2) customer routers. > > > > The customer is delaying on providing me with the proper circuit ID & > contact information to be able to call Lightpath and Level3 directly > and find out if they will do this, so I thought of asking this list. > > > > Is anyone aware if Lightpath and Level3 will agree to something like this? > > > > Thanks, > > Adam > > > > > From alter3d at alter3d.ca Fri Aug 16 21:29:42 2013 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Fri, 16 Aug 2013 17:29:42 -0400 Subject: will ISP peer with 2 local WAN routers? In-Reply-To: <01a101ce9ac6$8c4d4780$a4e7d680$@webjogger.net> References: <014a01ce9ac0$1cab26a0$560173e0$@webjogger.net> <01a101ce9ac6$8c4d4780$a4e7d680$@webjogger.net> Message-ID: <520E99C6.9080803@alter3d.ca> But the switches themselves are a single point of failure, so if a switch dies you still only have a single provider (assuming one switch per provider). ;) All you're doing is moving the your single point of failure from the routers to the switches, with arguably very little increase in actual reliability (if any, depending on whether you think switches are less likely to fail than routers). - Pete On 08/16/2013 05:21 PM, Adam Greene wrote: > Thanks, Justin. Yes, we considered that option, too. But then if one WAN > router goes down, the customer will only have connectivity through a single > upstream provider. We'd prefer to maintain connectivity to both even if a > router fails. Switches in front of the routers is no problem. > > -----Original Message----- > From: Justin Vocke [mailto:justin.vocke at gmail.com] > Sent: Friday, August 16, 2013 4:47 PM > To: Adam Greene > Cc: > Subject: Re: will ISP peer with 2 local WAN routers? > > The gotcha with that is then you need a switch in front of the routers. I'd > just setup a carrier on each router and run ibgp between. > > Sent from my iPhone > > On Aug 16, 2013, at 3:35 PM, "Adam Greene" wrote: > >> Hi guys, >> >> >> >> I have a customer who peers via eBGP with Lightpath aka Cablevision >> (AS >> 6128) and Level3 (AS 3356) and wants to do some dual-WAN router > redundancy. >> >> >> I have heard that carriers will sometimes agree to set up a /29 WAN >> subnet for a customer and peer with (2) customer routers. >> >> >> >> The customer is delaying on providing me with the proper circuit ID & >> contact information to be able to call Lightpath and Level3 directly >> and find out if they will do this, so I thought of asking this list. >> >> >> >> Is anyone aware if Lightpath and Level3 will agree to something like this? >> >> >> Thanks, >> >> Adam >> >> >> >> >> > From maillist at webjogger.net Fri Aug 16 21:47:04 2013 From: maillist at webjogger.net (Adam Greene) Date: Fri, 16 Aug 2013 17:47:04 -0400 Subject: will ISP peer with 2 local WAN routers? In-Reply-To: <520E99C6.9080803@alter3d.ca> References: <014a01ce9ac0$1cab26a0$560173e0$@webjogger.net> <01a101ce9ac6$8c4d4780$a4e7d680$@webjogger.net> <520E99C6.9080803@alter3d.ca> Message-ID: <01b601ce9aca$25715a20$70540e60$@webjogger.net> Pete, Good point, thanks. Yes, in this case, there is some cause to believe that the switches will prove more reliable than the routers. They're older 7200VXR's and have had some lockups in the past, possibly due to PA card / IOS incompatibilities. But you're right, we are also considering accepting full or partial routes from both providers, one provider per router, and then doing iBGP between them to balance the load. We're thinking of deploying default routes and HSRP to stacked 3750's for round-robin load balancing on the LAN side. Thanks for the help! Adam -----Original Message----- From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] Sent: Friday, August 16, 2013 5:30 PM To: nanog at nanog.org Subject: Re: will ISP peer with 2 local WAN routers? But the switches themselves are a single point of failure, so if a switch dies you still only have a single provider (assuming one switch per provider). ;) All you're doing is moving the your single point of failure from the routers to the switches, with arguably very little increase in actual reliability (if any, depending on whether you think switches are less likely to fail than routers). - Pete On 08/16/2013 05:21 PM, Adam Greene wrote: > Thanks, Justin. Yes, we considered that option, too. But then if one > WAN router goes down, the customer will only have connectivity through > a single upstream provider. We'd prefer to maintain connectivity to > both even if a router fails. Switches in front of the routers is no problem. > > -----Original Message----- > From: Justin Vocke [mailto:justin.vocke at gmail.com] > Sent: Friday, August 16, 2013 4:47 PM > To: Adam Greene > Cc: > Subject: Re: will ISP peer with 2 local WAN routers? > > The gotcha with that is then you need a switch in front of the > routers. I'd just setup a carrier on each router and run ibgp between. > > Sent from my iPhone > > On Aug 16, 2013, at 3:35 PM, "Adam Greene" wrote: > >> Hi guys, >> >> >> >> I have a customer who peers via eBGP with Lightpath aka Cablevision >> (AS >> 6128) and Level3 (AS 3356) and wants to do some dual-WAN router > redundancy. >> >> >> I have heard that carriers will sometimes agree to set up a /29 WAN >> subnet for a customer and peer with (2) customer routers. >> >> >> >> The customer is delaying on providing me with the proper circuit ID & >> contact information to be able to call Lightpath and Level3 directly >> and find out if they will do this, so I thought of asking this list. >> >> >> >> Is anyone aware if Lightpath and Level3 will agree to something like this? >> >> >> Thanks, >> >> Adam >> >> >> >> >> > From symack at gmail.com Fri Aug 16 21:47:27 2013 From: symack at gmail.com (Nick Khamis) Date: Fri, 16 Aug 2013 17:47:27 -0400 Subject: APC UPS Advice/Guidance for Canada 120/240 Message-ID: Hello Everyone, We are in the market for a APC UPS, and had a few questions. We are not that familiar with APC, and was hoping for some clarity. Our power demands will be for a unit that will sustain 3 kW/4 kVA scalable to 8 kVA. Input: The first issue is that I see all the units default with 208v input (other inputs 240v). At my location we only have 120 or 240. Also, we do not want to use a transformer (240-120) as it adds another failure point that can be avoided... The unit we are looking is found here: http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=SYA4K8RMP&total_watts=500 Output: Hard Wire 4-wire (2PH + N +G)NEMA L14-30R[image: NEMA L14-30R]NEMA L5-20R[image: NEMA L5-20R] What? How do I plug our 120 PDU into this? STONITH: This will be for a cluster that will require stonith capability. Does anyone know if this unit supports that? Not so important as the previous two questions... Kind Regards, Nick. From joe at nethead.com Fri Aug 16 21:59:20 2013 From: joe at nethead.com (Joe Hamelin) Date: Fri, 16 Aug 2013 14:59:20 -0700 Subject: APC UPS Advice/Guidance for Canada 120/240 In-Reply-To: References: Message-ID: http://www.amazon.com/Conntek-Locking-Adapter-Straight-Connector/dp/B001H9TSEW If you're not sure, then spend for an hour with a licensed electrician. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Fri, Aug 16, 2013 at 2:47 PM, Nick Khamis wrote: > Hello Everyone, > > We are in the market for a APC UPS, and had a few questions. We are not > that familiar with APC, and was hoping for some clarity. Our power demands > will be for a unit that will sustain 3 kW/4 kVA scalable to 8 kVA. > > Input: > > The first issue is that I see all the units default with 208v input (other > inputs 240v). At my location we only have 120 or 240. Also, we do not want > to use a transformer (240-120) as it adds another failure point that can be > avoided... > > The unit we are looking is found here: > > http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=SYA4K8RMP&total_watts=500 > > Output: > > Hard Wire 4-wire (2PH + N +G)NEMA L14-30R[image: NEMA L14-30R]NEMA > L5-20R[image: > NEMA L5-20R] > > What? How do I plug our 120 PDU into this? > > > STONITH: > > This will be for a cluster that will require stonith capability. Does > anyone know if this unit supports that? Not so important as the previous > two questions... > > Kind Regards, > > Nick. > From cidr-report at potaroo.net Fri Aug 16 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Aug 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201308162200.r7GM00OR011241@wattle.apnic.net> This report has been generated at Fri Aug 16 21:13:27 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 09-08-13 474589 270059 10-08-13 475137 269735 11-08-13 474298 269858 12-08-13 474715 269811 13-08-13 474587 269367 14-08-13 474622 269399 15-08-13 475163 269913 16-08-13 475291 269993 AS Summary 44881 Number of ASes in routing system 18477 Number of ASes announcing only one prefix 4235 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 117395680 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'). --- 16Aug13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 474901 269997 204904 43.1% All ASes AS6389 2978 65 2913 97.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 3154 690 2464 78.1% NET Servi?os de Comunica??o S.A. AS17974 2654 434 2220 83.6% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 4235 2069 2166 51.1% WINDSTREAM - Windstream Communications Inc AS4766 2922 933 1989 68.1% KIXS-AS-KR Korea Telecom AS22773 2006 247 1759 87.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2065 468 1597 77.3% COVAD - Covad Communications Co. AS4323 2992 1542 1450 48.5% TWTC - tw telecom holdings, inc. AS36998 1861 434 1427 76.7% SDN-MOBITEL AS10620 2668 1345 1323 49.6% Telmex Colombia S.A. AS7303 1730 453 1277 73.8% Telecom Argentina S.A. AS18881 1359 92 1267 93.2% Global Village Telecom AS4755 1778 592 1186 66.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1139 95 1044 91.7% VIETEL-AS-AP Vietel Corporation AS22561 1208 226 982 81.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS2118 962 88 874 90.9% RELCOM-AS OOO "NPO Relcom" AS1785 2006 1157 849 42.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS11830 946 101 845 89.3% Instituto Costarricense de Electricidad y Telecom. AS7545 2060 1225 835 40.5% TPG-INTERNET-AP TPG Telecom Limited AS18101 985 177 808 82.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1153 389 764 66.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS33363 1761 1038 723 41.1% BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC AS701 1522 801 721 47.4% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS13977 847 140 707 83.5% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS8151 1286 589 697 54.2% Uninet S.A. de C.V. AS15003 842 147 695 82.5% NOBIS-TECH - Nobis Technology Group, LLC AS6147 740 51 689 93.1% Telefonica del Peru S.A.A. AS855 735 55 680 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6983 1152 484 668 58.0% ITCDELTA - ITC^Deltacom AS24560 1088 425 663 60.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services Total 52834 16552 36282 68.7% Top 30 total Possible Bogus Routes 23.92.64.0/24 AS54540 INCERO - Incero LLC 23.92.65.0/24 AS54540 INCERO - Incero LLC 23.92.66.0/24 AS54540 INCERO - Incero LLC 23.92.67.0/24 AS54540 INCERO - Incero LLC 23.92.68.0/24 AS54540 INCERO - Incero LLC 23.92.69.0/24 AS54540 INCERO - Incero LLC 23.92.70.0/24 AS54540 INCERO - Incero LLC 23.92.71.0/24 AS54540 INCERO - Incero LLC 23.92.72.0/24 AS54540 INCERO - Incero LLC 23.92.73.0/24 AS54540 INCERO - Incero LLC 23.92.74.0/24 AS54540 INCERO - Incero LLC 23.92.75.0/24 AS54540 INCERO - Incero LLC 23.92.76.0/24 AS54540 INCERO - Incero LLC 23.92.77.0/24 AS54540 INCERO - Incero LLC 23.92.78.0/24 AS54540 INCERO - Incero LLC 23.92.79.0/24 AS54540 INCERO - Incero LLC 27.54.116.0/22 AS55452 27.54.116.0/24 AS55452 27.54.119.0/24 AS55452 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.182.96.0/23 AS15830 TELECITY-LON TELECITYGROUP INTERNATIONAL LIMITED 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. 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 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.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 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 80.68.144.0/20 AS33982 82.103.0.0/18 AS30901 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.205.188.0/22 AS47983 91.207.200.0/23 AS48523 91.209.93.0/24 AS48523 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 96.45.48.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.49.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.50.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.51.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.52.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.53.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.54.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.55.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.56.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.57.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.58.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.59.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.60.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.61.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.62.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.63.0/24 AS33475 RSN-1 - RockSolid Network, 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.9.107.0/24 AS38442 VODAFONEFIJI-AS-FJ Vodafone Fiji Limited 103.12.0.0/24 AS38442 VODAFONEFIJI-AS-FJ Vodafone Fiji Limited 103.13.0.0/24 AS38442 VODAFONEFIJI-AS-FJ Vodafone Fiji Limited 103.14.0.0/24 AS38442 VODAFONEFIJI-AS-FJ Vodafone Fiji Limited 103.224.163.0/24 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 103.224.188.0/23 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 109.71.156.0/23 AS21246 IPKO-AS Ipko Telecommunications LLC 109.71.158.0/24 AS21246 IPKO-AS Ipko Telecommunications LLC 109.71.159.0/24 AS21246 IPKO-AS Ipko Telecommunications LLC 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.40.184.0/24 AS19821 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.144.0/20 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 193.33.66.0/23 AS39874 193.33.112.0/23 AS8586 OBSL-AS TalkTalk Communications Limited 193.34.108.0/22 AS41984 193.109.15.0/24 AS12690 MKSNET-AS MKS Autonomous System 193.109.224.0/24 AS47427 193.111.125.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.111.155.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 194.50.82.0/24 AS16276 OVH OVH Systems 194.79.48.0/22 AS39117 194.117.250.0/23 AS41412 MIVITEC-AS MIVITEC GmbH 194.126.219.0/24 AS34545 194.169.237.0/24 AS12968 CDP Netia SA 195.28.7.0/24 AS8717 SPECTRUMNET MOBILTEL EAD 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 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.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 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 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 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 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.68.244.0/22 AS17140 208.68.244.0/23 AS17140 208.68.246.0/23 AS17140 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 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.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 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.90.64.0/22 AS16415 PRCNET-DOM - Precision Response Corporation 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.160.81.0/24 AS36184 209.160.83.0/24 AS36184 209.160.84.0/24 AS36184 209.160.86.0/24 AS36184 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.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.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.151.192.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.151.200.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 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 Aug 16 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Aug 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201308162200.r7GM01cA011255@wattle.apnic.net> BGP Update Report Interval: 08-Aug-13 -to- 15-Aug-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS5800 49023 2.8% 215.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 2 - AS8402 32813 1.9% 20.9 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS9829 29704 1.7% 35.4 -- BSNL-NIB National Internet Backbone 4 - AS27738 28447 1.6% 49.4 -- Ecuadortelecom S.A. 5 - AS7552 21849 1.3% 18.6 -- VIETEL-AS-AP Vietel Corporation 6 - AS9416 18573 1.1% 9286.5 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 7 - AS15003 17601 1.0% 33.9 -- NOBIS-TECH - Nobis Technology Group, LLC 8 - AS4775 15874 0.9% 345.1 -- GLOBE-TELECOM-AS Globe Telecoms 9 - AS18403 15147 0.9% 30.4 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 10 - AS28573 14422 0.8% 8.0 -- NET Servi?os de Comunica??o S.A. 11 - AS2118 14252 0.8% 10.4 -- RELCOM-AS OOO "NPO Relcom" 12 - AS34969 11840 0.7% 1480.0 -- PASJONET-AS Pasjo.Net Sp, z o.o. 13 - AS45899 10004 0.6% 29.0 -- VNPT-AS-VN VNPT Corp 14 - AS48612 9975 0.6% 1425.0 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 15 - AS6325 9425 0.6% 428.4 -- ILLINOIS-CENTURY - Illinois Century Network 16 - AS9808 9183 0.5% 11.4 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 17 - AS6629 9081 0.5% 1816.2 -- NOAA-AS - NOAA 18 - AS14287 8886 0.5% 1481.0 -- TRIAD-TELECOM - Triad Telecom, Inc. 19 - AS9299 8514 0.5% 137.3 -- IPG-AS-AP Philippine Long Distance Telephone Company 20 - AS647 8229 0.5% 72.2 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9416 18573 1.1% 9286.5 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 2 - AS38654 6098 0.3% 6098.0 -- INES-NETWORK INES Corporation. 3 - AS1880 4706 0.3% 4706.0 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 4 - AS19406 4669 0.3% 4669.0 -- TWRS-MA - Towerstream I, Inc. 5 - AS42334 3927 0.2% 3927.0 -- BBP-AS Broadband Plus s.a.l. 6 - AS6174 7111 0.4% 3555.5 -- SPRINTLINK8 - Sprint 7 - AS24772 6659 0.4% 3329.5 -- ASIP-AIE-AS Agrupacion de dervicios de internet y prensa AIE 8 - AS6629 9081 0.5% 1816.2 -- NOAA-AS - NOAA 9 - AS3 4902 0.3% 1779.0 -- CMED-AS Cmed Technology Ltd 10 - AS14287 8886 0.5% 1481.0 -- TRIAD-TELECOM - Triad Telecom, Inc. 11 - AS34969 11840 0.7% 1480.0 -- PASJONET-AS Pasjo.Net Sp, z o.o. 12 - AS48612 9975 0.6% 1425.0 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 13 - AS33648 3571 0.2% 1190.3 -- ELEPHANT - ColoFlorida / Elephant Outlook 14 - AS4434 6719 0.4% 1119.8 -- ERX-RADNET1-AS PT Rahajasa Media Internet 15 - AS37367 1056 0.1% 1056.0 -- CALLKEY 16 - AS33158 923 0.1% 923.0 -- DATA-SERVICES-INC - Data Services Incorporated 17 - AS19111 617 0.0% 617.0 -- NATURES-BOUN - NBTY, Inc. 18 - AS10704 5973 0.3% 597.3 -- Microlink Telecom (LNCC) 19 - AS4 5357 0.3% 871.0 -- INFOWAY COMERCIO DE INFORM E TELECOMUNICACOES LTDA 20 - AS20157 582 0.0% 582.0 -- AHL - American Heritage Life Insurance Company TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 92.246.207.0/24 9963 0.5% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 2 - 203.118.232.0/21 9298 0.5% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 3 - 203.118.224.0/21 9275 0.5% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 4 - 207.63.128.0/18 9049 0.5% AS6325 -- ILLINOIS-CENTURY - Illinois Century Network 5 - 192.58.232.0/24 9022 0.5% AS6629 -- NOAA-AS - NOAA 6 - 112.203.192.0/19 8338 0.5% AS9299 -- IPG-AS-AP Philippine Long Distance Telephone Company 7 - 222.127.0.0/24 7785 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 8 - 120.28.62.0/24 7717 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 9 - 202.154.17.0/24 6714 0.4% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 10 - 62.22.10.0/24 6657 0.4% AS24772 -- ASIP-AIE-AS Agrupacion de dervicios de internet y prensa AIE 11 - 150.39.0.0/16 6098 0.3% AS38654 -- INES-NETWORK INES Corporation. 12 - 115.170.128.0/17 5507 0.3% AS4847 -- CNIX-AP China Networks Inter-Exchange 13 - 204.29.132.0/23 4706 0.3% AS1880 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 14 - 69.38.178.0/24 4669 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 15 - 64.187.64.0/23 4444 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. 16 - 148.208.137.0/24 4089 0.2% AS8151 -- Uninet S.A. de C.V. 17 - 62.84.76.0/24 3927 0.2% AS42334 -- BBP-AS Broadband Plus s.a.l. 18 - 208.16.110.0/24 3556 0.2% AS6174 -- SPRINTLINK8 - Sprint 19 - 206.105.75.0/24 3555 0.2% AS6174 -- SPRINTLINK8 - Sprint 20 - 64.187.64.0/24 3550 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 wingar at team-metro.net Fri Aug 16 23:29:30 2013 From: wingar at team-metro.net (wingar at team-metro.net) Date: Fri, 16 Aug 2013 23:29:30 +0000 Subject: =?utf-8?Q?Google_having_issues=3F?= Message-ID: <520eb5f0.6a8a420a.15ad.04dc@mx.google.com> Hey guys, I?m hearing reports of Google services (Search, Youtube, Mail, etc) going down all over the place, providing extremely spotty service. Works fine for me right now, but a lot of people seem to be having problems all over the world. Any ideas what?s going on? Thanks! ~ Em From derek at derekivey.com Fri Aug 16 23:34:09 2013 From: derek at derekivey.com (Derek Ivey) Date: Fri, 16 Aug 2013 19:34:09 -0400 Subject: Google having issues? In-Reply-To: <520eb5f0.6a8a420a.15ad.04dc@mx.google.com> References: <520eb5f0.6a8a420a.15ad.04dc@mx.google.com> Message-ID: <-8184287472816784186@unknownmsgid> I was having a hard time getting to Google Maps from my Verizon FiOS connection and also from my Hurricane Electric IPv6 tunnel. I was able to ping them though. Didn't try any other google services. Derek On Aug 16, 2013, at 7:32 PM, "wingar at team-metro.net" wrote: > > Hey guys, > > > I?m hearing reports of Google services (Search, Youtube, Mail, etc) going down all over the place, providing extremely spotty service. Works fine for me right now, but a lot of people seem to be having problems all over the world. > > Any ideas what?s going on? > > > > Thanks! > > ~ Em -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2547 bytes Desc: not available URL: From scott at doc.net.au Fri Aug 16 23:40:40 2013 From: scott at doc.net.au (Scott Howard) Date: Fri, 16 Aug 2013 16:40:40 -0700 Subject: Google having issues? In-Reply-To: <520eb5f0.6a8a420a.15ad.04dc@mx.google.com> References: <520eb5f0.6a8a420a.15ad.04dc@mx.google.com> Message-ID: I've two 2 short outages to both Google Search and Google Mail/Apps over the last 30 mins. Both cleared after a few minutes. For Search at least it was returning a Google error page. Comcast in the Bay Area. Scott On Fri, Aug 16, 2013 at 4:29 PM, wrote: > > Hey guys, > > > I?m hearing reports of Google services (Search, Youtube, Mail, etc) going > down all over the place, providing extremely spotty service. Works fine for > me right now, but a lot of people seem to be having problems all over the > world. > > Any ideas what?s going on? > > > > Thanks! > > ~ Em From nathana at fsr.com Fri Aug 16 23:42:47 2013 From: nathana at fsr.com (Nathan Anderson) Date: Fri, 16 Aug 2013 16:42:47 -0700 Subject: Google having issues? In-Reply-To: <-8184287472816784186@unknownmsgid> References: <520eb5f0.6a8a420a.15ad.04dc@mx.google.com> <-8184287472816784186@unknownmsgid> Message-ID: At about 5 minutes to 4:00p PDT, downforeveryoneorjustme.com confirmed that "it's not just you!" for google.com; in fact, it's still saying that, although I can reach Google services on our network now. I could also ping Google, but I tried to open a connection to port 80 on google.com via telnet around the time I started having problems, and I was just getting connection refused (immediate RST received upon transmission of SYN) across multiple Google IPs. I then VPN'd over to an off-net DSL connection, and from there I had no trouble accessing Google, but OS X telnet (which apparently will automatically try multiple IPs if DNS resolution comes back with multiple A records) showed that it was still getting "connection refused" on a few IPs before it finally struck gold. -- Nathan -----Original Message----- From: Derek Ivey [mailto:derek at derekivey.com] Sent: Friday, August 16, 2013 4:34 PM To: wingar at team-metro.net Cc: nanog at nanog.org Subject: Re: Google having issues? I was having a hard time getting to Google Maps from my Verizon FiOS connection and also from my Hurricane Electric IPv6 tunnel. I was able to ping them though. Didn't try any other google services. Derek On Aug 16, 2013, at 7:32 PM, "wingar at team-metro.net" wrote: > > Hey guys, > > > I'm hearing reports of Google services (Search, Youtube, Mail, etc) going down all over the place, providing extremely spotty service. Works fine for me right now, but a lot of people seem to be having problems all over the world. > > Any ideas what's going on? > > > > Thanks! > > ~ Em From hannes at stressinduktion.org Sat Aug 17 00:06:35 2013 From: hannes at stressinduktion.org (Hannes Frederic Sowa) Date: Sat, 17 Aug 2013 02:06:35 +0200 Subject: Google having issues? In-Reply-To: <520eb5f0.6a8a420a.15ad.04dc@mx.google.com> References: <520eb5f0.6a8a420a.15ad.04dc@mx.google.com> Message-ID: <20130817000635.GA22330@order.stressinduktion.org> On Fri, Aug 16, 2013 at 11:29:30PM +0000, wingar at team-metro.net wrote: > I?m hearing reports of Google services (Search, Youtube, Mail, etc) going down all over the place, providing extremely spotty service. Works fine for me right now, but a lot of people seem to be having problems all over the world. > > Any ideas what?s going on? Google rolled out an erroneous update for gmail. See and comments. Maybe this has something to do with these problems? Greetings, Hannes From michael at supermathie.net Sat Aug 17 02:33:41 2013 From: michael at supermathie.net (Michael Brown) Date: Fri, 16 Aug 2013 22:33:41 -0400 Subject: APC UPS Advice/Guidance for Canada 120/240 In-Reply-To: References: Message-ID: <520EE105.2060205@supermathie.net> On 13-08-16 05:47 PM, Nick Khamis wrote: > We are in the market for a APC UPS, and had a few questions. We are not > that familiar with APC, and was hoping for some clarity. Our power demands > will be for a unit that will sustain 3 kW/4 kVA scalable to 8 kVA. The model you're looking at looks good for your needs. The electrical spec sheet seems WAY more readable than the webpage by the way: http://www.apcmedia.com/salestools/ASTE-6Z8LSA/ASTE-6Z8LSA_R0_EN.pdf The reason you're looking at the input voltage on the webpage and getting confused is probably: "Input voltage range for main operations: 96 - 138V (Line to Neutral)" What that REALLY means is that it will function as long as the incoming line voltage is in the 122?16V bracket (i.e. the UPS can tolerate under and over-voltages). That's hot-to-neutral voltage. Now, in Canada when you're running on 208V you're USUALLY getting two hot phases at 120? phase offset (each at 120V hot-to-neutral) giving you a RMS voltage (think of it as the time-based mean voltage) of 208V, not the 240V hot-to-neutral you may used to... elsewhere. Sometimes you'll get two hot lines of 120V at 180? phase offset, giving you 240V. In rare cases you'll actually get 240V hot-to-neutral. This UPS will be happy with either (it says on the spec sheet: Input voltage: 200, 208, or 240). As for the output, first a quick primer on reading the NEMA plug types: *$LOCK$VOLTAGE-$AMPERAGE$END* LOCK = L | "" (if L, it means twist lock end) VOLTAGE = 5 | 6 | 14 (5?120V, 6?208 or 240V, 14?120/240V combo i.e. 2 hots, neutral and ground) AMPERAGE = 15 | 20 | 30 (literally 15A / 20A / 30A) END = P | R (Plug or Receptacle) So you'll want to plug your 120V PDU into the L5-20R receptacle and you'll need a cable with a L5-20P at one end an a C13 or C19 (depending on what your PDU takes as input) on the other. Such as: http://ca.startech.com/Cables/Computer-Power/External/8ft-IEC320-C-19-to-NEMA-L5-20P-123C-Power-Cord~PXTL520C198 (btw, do note that those two L5-20R outlets only give you 4800VA ? 0.8 of total power. You'll need to hardwire or use the L14 receptacles as well) As far as STONITH goes, the only control you'll have is all ports off or all ports on. You'll want a PDU with switched outlets if you need more granular control. (plug time: if you want more help speccing this out and a quote, feel free to email me at netdirect.ca as we can sell this). M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian From michael at supermathie.net Sat Aug 17 02:36:23 2013 From: michael at supermathie.net (Michael Brown) Date: Fri, 16 Aug 2013 22:36:23 -0400 Subject: APC UPS Advice/Guidance for Canada 120/240 In-Reply-To: <520EE105.2060205@supermathie.net> References: <520EE105.2060205@supermathie.net> Message-ID: <520EE1A7.3050801@supermathie.net> On 13-08-16 10:33 PM, Michael Brown wrote: > VOLTAGE = 5 | 6 | 14 (5?120V, 6?208 or 240V, 14?120/240V combo i.e. 2 > hots, neutral and ground) That would be: VOLTAGE = 5 | 6 | 14 (5->120V, 6->208 or 240V, 14->120/240V combo i.e. 2 hots, neutral and ground) The mailing list ate my Unicode arrows. Nom nom. M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian From frnkblk at iname.com Sat Aug 17 04:17:25 2013 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 16 Aug 2013 23:17:25 -0500 Subject: Google having issues? In-Reply-To: <520eb5f0.6a8a420a.15ad.04dc@mx.google.com> References: <520eb5f0.6a8a420a.15ad.04dc@mx.google.com> Message-ID: <008701ce9b00$adc1af20$09450d60$@iname.com> Confirmed: http://www.google.com/appsstatus#hl=en&v=issue&ts=1376715599000&sid=1&iid=0a668851fc3f5856b360e2bdb8781fc1 Frank -----Original Message----- From: wingar at team-metro.net [mailto:wingar at team-metro.net] Sent: Friday, August 16, 2013 6:30 PM To: nanog at nanog.org Subject: Google having issues? Hey guys, I?m hearing reports of Google services (Search, Youtube, Mail, etc) going down all over the place, providing extremely spotty service. Works fine for me right now, but a lot of people seem to be having problems all over the world. Any ideas what?s going on? Thanks! ~ Em From gih at apnic.net Sat Aug 17 06:16:15 2013 From: gih at apnic.net (Geoff Huston) Date: Sat, 17 Aug 2013 16:16:15 +1000 Subject: Practical effects of DNSSEC deployment In-Reply-To: <41BF2D77-F740-4B52-9F5F-31F1CCC35CB6@cs.columbia.edu> References: <41BF2D77-F740-4B52-9F5F-31F1CCC35CB6@cs.columbia.edu> Message-ID: <0B94D405-83B4-4B94-A1FB-92CC626BBDDD@apnic.net> Hi Steve, > There was an interesting paper at Usenix Security on the effects of deploying DNSSEC; see https://www.usenix.org/conference/usenixsecurity13/measuring-practical-impact-dnssec-deployment . The difference in geographical impact was quite striking. > George Michaelson and I have been undertaking similar work in DNSSEC, using an advertisement to enrol users' browsers to perform a set of URL loads that tests their ability to perform DNSSEC validation. Our methodology differed from that in the Usenix paper - we worked hard at setting up name structures that eliminated any benefits from DNS caching as well as web caching. We presented on this work at the IEPG meeting at IETF 87 a couple of weeks ago. The bottom line: around 8% of clients across the Internet will perform DNSSEC validation - i.e. they are seen to fetch the DS and DNSKEY RRs for the signed objects, and will fetch the object that is correctly signed, and will not fetch the object that is badly signed. A further 4% of clients appears to use a set of resolvers where there is a mix of validating resolvers and non-validating resolvers. What we see is that the client's resolver will perform a set of fetches of the DS and DNSKEY records for the badly signed onject, then ask for the A record a second time (generally using a different resolver) and then fetch the object anyway - i.e. the original SERV FAIL response causes the client to turn to another resolver in its list, and use that result. 87% of clients only ask for A records - no signs of DNSSEC life for them. We did some basic mapping of client to country (there is a LOT of DNSSEC validation in Sweden!) and network service provider bu origin AS, and also looked at the performance implications, both if you serve a zone thats signed, and if you serve a zone that is signed badly. The presentation is at http://www.iepg.org/2013-07-ietf87/2013-07-28-dnssec.pdf if you are interested. Geoff From ajbonkoski at gmail.com Fri Aug 16 19:19:31 2013 From: ajbonkoski at gmail.com (Anthony Bonkoski) Date: Fri, 16 Aug 2013 15:19:31 -0400 Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: References: <21288797.3692.1376614801039.JavaMail.root@benjamin.baylink.com> <520E347F.6010000@pubnix.net> Message-ID: There's a few misconceptions I'd like to address, plus add some backstory. The Washington Post article is intentionally void of details. It is intended as a non-technical article. You can find the actual technical paper here: https://www.usenix.org/conference/woot13/illuminating-security-issues-surrounding-lights-out-server-management Cipher-0 is an awful, yet well-known issue that comes directly from the Intel spec, and thus affects a large set of implementations. Here's an excellent write-up: http://fish2.com/ipmi/cipherzero.html The iDRAC testurls vuln. was a result of the firmware being shipped with a developer debugging webpage that could be used as a backdoor. Recent work shows that some password hashes can be recovered and cracked. In this latest development, we reverse engineered a SuperMicro/ATEN firmware binary and discovered security gross negligence. We discovered the very worst vuln: client-side only input checking, shell-injection, and trivial buffer-overflows in many CGI programs including the user/pass fields of the login page. Further, the device has almost no modern buffer-overflow defenses (DEP, ASLR, and Stack Carries). We show that it is *easy* to exploit these flaws and gain a root shell. This is especially nasty because the system operator is not give access to a Unix shell on the BMC, thus a remote attacker can gain more capabilities on the BMC than even the administrator. In short, the previous work should certainly be enough to make any sys admin fear exposing IPMI to a public IP. However, the problem is much worse than we previously thought. This particular implementation shows a complete disregard for even the most basic security practices. -Anthony On Aug 16, 2013 10:19 AM, "Alain Hebert" wrote: Hi, I find it odd that this is suddenly news... There is plenty of security updates for iBMC/iDrac/etc from IBM/HP/Dell/etc over the years. But: You can use ipmitool, rootkit/exploit some Linux box and upload your own firmware in that iBMC/iDrac/etc... for example the BMC firmware for a Dell C1100 leave plenty of space to inject your own shell in it. And Voila! access to the management network =D. BTW I got ipmitool working even on VMWare 5.1 :( Counter: We (PCIDSS hat) always check for those management interfaces and "proposed" to move those interfaces into they own VLANs+Subnets. Meaning: PCI DMZ Zone has its own DMZ iBMC VLAN/Subnet/FW Rules, PCI DB Zone has its own iBMC VLAN/Subnet/FW Rules, etc. It is a few more VLAN/Subnets... but modern Firewall can handle this easy. PS: "proposed" as in not giving them a choice =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 08/16/13 00:22, Kyle Creyts wrote: > just so we're all clear, SuperMicro wasn't the only one... > > link: http://pastebin.com/syXHLuC5 > > 1. CVE-2013-4782 CVSS Base Score = 10.0 > 2. The SuperMicro BMC implementation allows remote attackers to > bypass authentication and execute arbitrary IPMI commands by using > cipher suite 0 (aka cipher zero) and an arbitrary password. > 3. > 4. CVE-2013-4783 CVSS Base Score = 10.0 > 5. The Dell iDRAC 6 BMC implementation allows remote attackers to > bypass authentication and execute arbitrary IPMI commands by using > cipher suite 0 (aka cipher zero) and an arbitrary password. > 6. > 7. CVE-2013-4784 CVSS Base Score = 10.0 > 8. The HP Integrated Lights-Out (iLO) BMC implementation allows > remote attackers to bypass authentication and execute arbitrary IPMI > commands by using cipher suite 0 (aka cipher zero) and an arbitrary > password. > 9. > 10. CVE-2013-4785 CVSS Base Score = 10.0 > 11. iDRAC 6 firmware 1.7, and possibly other versions, allows remote > attackers to modify the CLP interface for arbitrary users and possibly > have other impact via a request to an unspecified form that is > accessible from testurls.html. > 12. > 13. CVE-2013-4786 CVSS Base Score = 7.8 > 14. The IPMI 2.0 specification supports RMCP+ Authenticated > Key-Exchange Protocol (RAKP) authentication, which allows remote > attackers to obtain password hashes and conduct offline password > guessing attacks by obtaining the HMAC from a RAKP message 2 responses > from a BMC. > > > References: > > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4782 > => http://fish2.com/ipmi/cipherzero.html > > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4783 > => http://fish2.com/ipmi/cipherzero.html > > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4784 > => http://fish2.com/ipmi/cipherzero.html > > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4785 > => http://fish2.com/ipmi/dell/secret.html > > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4786 > => http://fish2.com/ipmi/remote-pw-cracking.html > > On Thu, Aug 15, 2013 at 6:00 PM, Jay Ashworth wrote: >> Presumably, everyone else's are very religious as well. >> >> Is anyone here stupid enough not to put the management interfaces behind >> a firewall/VPN? >> >> http://www.washingtonpost.com/blogs/the-switch/wp/2013/08/14/researchers-figure-out-how-to-hack-tens-of-thousands-of-servers/ >> >> And should I be nervous that Usenix pointed me *there* for the story, >> rather than a tech press outlet? >> >> 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 me at staticsafe.ca Sat Aug 17 18:41:15 2013 From: me at staticsafe.ca (staticsafe) Date: Sat, 17 Aug 2013 14:41:15 -0400 Subject: [Paper] B4: Experience with a Globally-Deployed Software Defined WAN Message-ID: <20130817184115.GB18473@uriel.asininetech.com> "We present the design, implementation, and evaluation of B4, a pri- vate WAN connecting Google?s data centers across the planet." - http://cseweb.ucsd.edu/~vahdat/papers/b4-sigcomm13.pdf -- staticsafe O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post. Please don't CC! I'm subscribed to whatever list I just posted on. From toddunder at gmail.com Sat Aug 17 19:21:23 2013 From: toddunder at gmail.com (Todd Underwood) Date: Sat, 17 Aug 2013 15:21:23 -0400 Subject: [Paper] B4: Experience with a Globally-Deployed Software Defined WAN In-Reply-To: <20130817184115.GB18473@uriel.asininetech.com> References: <20130817184115.GB18473@uriel.asininetech.com> Message-ID: Unpossible. I heard that no one really uses sdn for anything. :) T On Aug 17, 2013 2:43 PM, "staticsafe" wrote: > "We present the design, implementation, and evaluation of B4, a pri- > vate WAN connecting Google?s data centers across the planet." > > - http://cseweb.ucsd.edu/~vahdat/papers/b4-sigcomm13.pdf > -- > staticsafe > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > Please don't top post. > Please don't CC! I'm subscribed to whatever list I just posted on. > > From freedman at freedman.net Sat Aug 17 19:32:17 2013 From: freedman at freedman.net (Avi Freedman) Date: Sat, 17 Aug 2013 15:32:17 -0400 (EDT) Subject: [Paper] B4: Experience with a Globally-Deployed Software Defined Message-ID: <20130817193218.023845500008D@freedman.net> No, people never use *flow controllers* for anything. People have been doing SDN since before Google was around. OK, so it was horrible expect scripts but it worked. Avi > Unpossible. I heard that no one really uses sdn for anything. > > :) > > T From deleskie at gmail.com Sat Aug 17 22:44:39 2013 From: deleskie at gmail.com (jim deleskie) Date: Sat, 17 Aug 2013 19:44:39 -0300 Subject: [Paper] B4: Experience with a Globally-Deployed Software Defined In-Reply-To: <20130817193218.023845500008D@freedman.net> References: <20130817193218.023845500008D@freedman.net> Message-ID: At iMCI (pre-Worldcom) we had scripts that would build all our ATM VC's for a 400node mesh, would take all night to run :) -jim On Sat, Aug 17, 2013 at 4:32 PM, Avi Freedman wrote: > > No, people never use *flow controllers* for anything. > > People have been doing SDN since before Google was around. > > OK, so it was horrible expect scripts but it worked. > > Avi > > > Unpossible. I heard that no one really uses sdn for anything. > > > > :) > > > > T > > > From mysidia at gmail.com Sat Aug 17 23:02:44 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 17 Aug 2013 18:02:44 -0500 Subject: [Paper] B4: Experience with a Globally-Deployed Software Defined In-Reply-To: <20130817193218.023845500008D@freedman.net> References: <20130817193218.023845500008D@freedman.net> Message-ID: On Sat, Aug 17, 2013 at 2:32 PM, Avi Freedman wrote: > No, people never use *flow controllers* for anything. > People have been doing SDN since before Google was around. > OK, so it was horrible expect scripts but it worked. > Not really. Automatic reconfiguration of routers is not what a software-defined network is. It is one of the things (but not all of the things) that SDN provides. A software defined network is one where the forwarding behavior can be completely defined in software running outside of the devices that perform the forwarding. You can write expect scripts all day; but you cannot turn your basic switch into a Load balancer or stateful firewall with one. or decide in real time exactly which destination Ethernet ports a packet coming in a certain port is going to touch, without having structured VLANs and static MAC tables on the switches ahead of time. Changing device configurations with expect scripts is a limited tiny subset of what SDN is. > Avi > -- -JH From arturo.servin at gmail.com Sat Aug 17 23:14:14 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Sat, 17 Aug 2013 20:14:14 -0300 Subject: [Paper] B4: Experience with a Globally-Deployed Software Defined In-Reply-To: References: <20130817193218.023845500008D@freedman.net> Message-ID: <521003C6.3070308@gmail.com> Hacker will love SDN ... :) Bye, bye dumb and resilient network ... .as On 8/17/13 8:02 PM, Jimmy Hess wrote: > A software defined network is one where the forwarding behavior can be > completely defined > in software running outside of the devices that perform the forwarding. From jeff-kell at utc.edu Sat Aug 17 23:29:33 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Sat, 17 Aug 2013 19:29:33 -0400 Subject: [Paper] B4: Experience with a Globally-Deployed Software Defined In-Reply-To: <521003C6.3070308@gmail.com> References: <20130817193218.023845500008D@freedman.net> <521003C6.3070308@gmail.com> Message-ID: <5210075D.2030101@utc.edu> On 8/17/2013 7:14 PM, Arturo Servin wrote: > Hacker will love SDN ... Yes. Traditional SDN is big, flat layer-2 network with global mac-address resolution, and a big fat Java applet managing the adjacency tables. What could *possibly* go wrong? Jeff From jaydesh9 at gmail.com Sun Aug 18 00:26:07 2013 From: jaydesh9 at gmail.com (=?UTF-8?B?SmF5cmFtIETDqXNocGFuZMOp?=) Date: Sat, 17 Aug 2013 17:26:07 -0700 Subject: [Paper] B4: Experience with a Globally-Deployed Software Defined In-Reply-To: <5210075D.2030101@utc.edu> References: <20130817193218.023845500008D@freedman.net> <521003C6.3070308@gmail.com> <5210075D.2030101@utc.edu> Message-ID: SDN is not a new concept at all. Infact since ARPANET days, the notion of centralized control plane had a lot of traction. But with Cold war around, It made more sense to push the control plane intelligence into individual decision points (routers , switches , et . al. ). Considering the possibility of the commies taking down some part of the early Internet, the remaining partitioned network could still survive as the rest of the decision points could converge and act as independent network snippets. -Jay. On Sat, Aug 17, 2013 at 4:29 PM, Jeff Kell wrote: > On 8/17/2013 7:14 PM, Arturo Servin wrote: > > Hacker will love SDN ... > > Yes. Traditional SDN is big, flat layer-2 network with global > mac-address resolution, and a big fat Java applet managing the adjacency > tables. > > What could *possibly* go wrong? > > Jeff > > > -- "Subvert the paradigm." - C.K. Prahlad From freedman at freedman.net Sun Aug 18 01:08:31 2013 From: freedman at freedman.net (Avi Freedman) Date: Sat, 17 Aug 2013 21:08:31 -0400 (EDT) Subject: [Paper] B4: Experience with a Globally-Deployed Software Defined Message-ID: <20130818010831.B595E55000089@freedman.net> > On Sat, Aug 17, 2013 at 2:32 PM, Avi Freedman wrote: > > > No, people never use *flow controllers* for anything. > > > People have been doing SDN since before Google was around. > > OK, so it was horrible expect scripts but it worked. > > Not really. Note I am talking about flow controllers in my first point. (And I was trying to be funny to match Todd's tone, though I guess it's dangerous to try to copy the master) Re: flow controllers - The idea of centralized decision makers doing something (typically per flow) has been proposed, in my experience, by those with little operational experience or those with extraordinarily constrained topoligies, types of traffic, and usually external filtering to constrain the types of traffic one could face. Because... There have been no proposals that I have seen (or that those who are at the Major Vendors who follow it more closely tell me about when I ask a few times/year) to actually deal with the every-packet-is-a-flow problem we saw first with 7206VXRs and that remain a real possibility for Internet- connected networks. Distributing flow controllers and making them hierarchical doesn't seem to help in the architectures that I've seen proposed. So it seems to be of use only for very tiny networks or for very constrained and filtered or non Internet-connected topologies. I'd be interested to be shown otherwise. > Automatic reconfiguration of routers is not what a software-defined network is. > > It is one of the things (but not all of the things) that SDN provides. > > A software defined network is one where the forwarding behavior can be > completely defined > in software running outside of the devices that perform the forwarding. That said, I wince every time someone starts talking about (not suggesting you are here but many do) making the routing engineer or designer in a box that sits on the bottom or besides the network. Those who have experience and/or run larger infrastructure usually say words like "of course we have to worry about feedback loops" but many don't. I think innovation is great but I don't think there are that many shops that are better off writing their own control pane (centralized, distribtued, whatever) right now. It's worth remembering that Google is a software company. They are far ahead in software defined everything. > You can write expect scripts all day; but you cannot turn your basic switch > into a Load balancer or stateful firewall with one. > or decide in real time exactly which destination Ethernet ports a packet > coming in a certain port is going to touch, without having structured > VLANs and static MAC tables on the switches ahead of time. > > Changing device configurations with expect scripts is a limited tiny subset > of what SDN is. True, but the number of production environments that are going to be more stable or scalable by having people build their own control logic is pretty small in my experience. And being able to debug and reach out to a community of operators with a common set of experience of what to do, not to do, and how to debug is extraordinarily valuable for production networks. When I look at most of the non-Google big guys, SDN means pushing the vendors for better control plane instrumentation and ability to program (but more on the instrumentation side as where the gaps have been), and potentially to get some cross-provider way of doing the above. + having merchant silicon one can get/use for cheap, typically for more constrained topologies, doing pretty dumb switching and/or routing stuff. > -JH Where I see the delta a lot given the customer conversations I have is in the magic provisioning of cloud network infrastructures. New school SDN is that everything is a tunnel, magic software maps things, commercial providers doing this uniformly have to aggressively rate- limit their clients, and performance for content delivery is limited because the hypervisors must be briding and can't do PCI passthrough or SR/IOV. Old school SDN (not really that old school) is API-based provisioning of network devices with vendor support (let's say Juniper) to do filtering, VLANs, and shaping and tunnels where needed. It'll definitely be interesting to see where things go over the next few years. I know tens of companies who have run away from cloud providers with new(er) school SDN-ish infrastructures for the simplicity of just having some high performance dedicated machines/hypervisors with dead simple switching infrastructure. Anyway, innovation is great but I just see few companies with the understanding to go build their own control plane software to connect to the Internet with. And those vendors who do build it will get borged by one of the routing/switching vendors and things will become product features, differentiated by providers, most likely. (Though I hope not) Avi From randy at psg.com Sun Aug 18 01:58:05 2013 From: randy at psg.com (Randy Bush) Date: Sun, 18 Aug 2013 10:58:05 +0900 Subject: morning giggle Message-ID: for your morning, or whatever time of day it is to you, giggle From: "Jeffrey L. Roberts" Subject: DNS Zone File Access Request To: Randy Bush < randy at psg.com> Date: Sat, 17 Aug 2013 21:56:02 -0400 Greetings, My name is Jeff and I hope you're having a great day. I am the CIO of the Trademark Police. We would like to know what forms we need to fill out to receive credentials to access your dns zone files. Please contact me at your earliest convenience at Jeffrey.L.Roberts at gmail.com, or feel free to call me at 1-305-815-1155 Thank you! - Jeffrey L. Roberts From eyeronic.design at gmail.com Sun Aug 18 02:05:55 2013 From: eyeronic.design at gmail.com (Mike Hale) Date: Sat, 17 Aug 2013 16:05:55 -1000 Subject: morning giggle In-Reply-To: References: Message-ID: Maybe he's trying to sell you some eCigars? http://support.shipstation.com/forums/126593-request-a-new-shipstation-feature/suggestions/3357095-print-second-page-of-packing-slip-when-printing-ha http://www.v2cigs.com/ On Sat, Aug 17, 2013 at 3:58 PM, Randy Bush wrote: > for your morning, or whatever time of day it is to you, giggle > > From: "Jeffrey L. Roberts" > Subject: DNS Zone File Access Request > To: Randy Bush < randy at psg.com> > Date: Sat, 17 Aug 2013 21:56:02 -0400 > > Greetings, > > My name is Jeff and I hope you're having a great day. I am the CIO of > the Trademark Police. We would like to know what forms we need to fill > out to receive credentials to access your dns zone files. Please > contact me at your earliest convenience at > Jeffrey.L.Roberts at gmail.com, or feel free to call me at 1-305-815-1155 > > Thank you! > > - Jeffrey L. Roberts > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From chris at westnet.com Sun Aug 18 02:10:12 2013 From: chris at westnet.com (Christopher X. Candreva) Date: Sat, 17 Aug 2013 22:10:12 -0400 (EDT) Subject: morning giggle In-Reply-To: References: Message-ID: On Sun, 18 Aug 2013, Randy Bush wrote: > out to receive credentials to access your dns zone files. Please > contact me at your earliest convenience at > Jeffrey.L.Roberts at gmail.com, or feel free to call me at 1-305-815-1155 Oh my, this is too funny. In fact it reads like a 419 scam -- except the guy gave a phone number ? Uhu, same guy same phone number, claiming to be a developer in Dec 2012 http://support.shipstation.com/forums/126593-request-a-new-shipstation-feature/suggestions/3357095-print-second-page-of-packing-slip-when-printing-ha ========================================================== Chris Candreva -- chris at westnet.com -- (914) 948-3162 WestNet Internet Services of Westchester http://www.westnet.com/ From mysidia at gmail.com Sun Aug 18 02:45:30 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 17 Aug 2013 21:45:30 -0500 Subject: [Paper] B4: Experience with a Globally-Deployed Software Defined In-Reply-To: <20130818010831.B595E55000089@freedman.net> References: <20130818010831.B595E55000089@freedman.net> Message-ID: On Sat, Aug 17, 2013 at 8:08 PM, Avi Freedman wrote: > > On Sat, Aug 17, 2013 at 2:32 PM, Avi Freedman > wrote: > > > OK, so it was horrible expect scripts but it worked. > > Not really. > The idea of centralized decision makers doing something (typically > per flow) has been proposed, in my experience, by those with little > operational experience or those with extraordinarily constrained > topoligies, types of traffic, and usually external filtering to > constrain the types of traffic one could face. > Flow controllers are for constrained topologies. You have some interesting problems, if you decide to try to bring flow controllers into a carrier network, and have them processing flows coming in from an unprotected network. How do you feel about a few billion flows per second, thanks to the attacker's randomized source IPs and port numbers? You might very well have to "constrain the topology" by having a capability to provide a flow entry for the destination IP address, and associating all the traffic with just one "flow". > closely tell me about when I ask a few times/year) to actually > deal with the every-packet-is-a-flow problem we saw first with > 7206VXRs and that remain a real possibility for Internet- > connected networks. Distributing flow controllers and making > The centralized controller doesn't work well in topologies where you cannot take the first packet -- setup the flow tables on the devices, and keep further control traffic limited in number of messages and limited in number of bits. You need a network path for control traffic, you need CPU capacity for your flow processing -- and there will always be RTT latency and various other penalties incurred by extra overhead to reach a remote controller that is geographically farther away from the route processor since the speed of light is finite, and any centralized controller will have finite capacity... Having all the flow processing on central controllers is the opposite of load-balancing --- it is concentration of a distributed load; which is a recipe for creating a capacity bottleneck on the controller and on all the devices that have to have uncongested paths to the controllers... It's a similar idea to storing part of your router's RIB on a hard disk or magnetic tape, because RAM is so expensive ---- you're going to increase the forwarding delays of some traffic, or some connection initializations by doing so. Therefore; the only flow controller that really makes sense in all situations is eventually going to be one that can download its entire state into every router --- that is: A route controller program built into every router and switch (even if defined by software). Such a product for SDN doesn't exist yet? -- other than traditional networking devices which don't allow you to implement an API and download arbitrary code to them in a vendor-independent way. It seems like there is still a lot of work and standardization for vendors to be doing, before a majority of ISP networks could consider using SDN anywhere. > So it seems to be of use only for very tiny networks or for > very constrained and filtered or non Internet-connected topologies. > Yes. That seems to be where the greatest benefits of current SDN products could realistically be experienced at the present time; small filtered and private topologies, where the controller as a bottleneck risk is minimal. > > in software running outside of the devices that perform the forwarding. > > That said, I wince every time someone starts talking about (not suggesting > you are here but many do) making the routing engineer or designer in a box > that sits on the bottom or besides the network. > I don't know -- if you make a box that can help configure your network; you'll still need a routing engineer to setup and maintain that box, make sure it continues to work properly, spend all day on hold waiting for support to help get your network back online, and diagnose things when an inevitable bug crops up and starts costing more damage than money saved by deploying the magic box. I think innovation is great but I don't think there are that many shops > that are better off writing their own control pane (centralized, > distribtued, > whatever) right now. > Yes. Most would have no business trying to write their own control plane. Not too long ago someone wrote about "Tempering your MacGuyver" streak. Which is exactly what should apply here; SDN is something to learn about developments in, and one of those new flow controller schemes could be used in a pinch as a way around certain problems ---- new tech doesn't mean it's somehow better, or somehow magically defeats inherent physical or computational problems. Otherwise Rule #1 of building reliable infrastructure -- is use time-tested technology in well-understood vendor supported configurations in every instance, except in the situations where there exists compelling justification to vary. Flow controllers won't belong on everyone's network just because they're new tech -- until they have more to offer, it would be the exception to the rule that you should want one. > It's worth remembering that Google is a software company. They are far > ahead in software defined everything. > It could be interesting if Google released some of their sw and sw/hw solutions I suppose. Of course there are likely to be people copying them in such case, because of a perception (true or false), that using SDN tech early on is part of their success story. > When I look at most of the non-Google big guys, SDN means pushing the > vendors for better control plane instrumentation and ability to program > (but more on the instrumentation side as where the gaps have been), and > potentially to get some cross-provider way of doing the above. > That bit is the most useful. Network devices have notoriously poor control plane instrumentation and programmability; SNMP and Netflow have their limitations. Improvements in these areas are valuable in their own right. -- -JH From mysidia at gmail.com Sun Aug 18 05:11:37 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 18 Aug 2013 00:11:37 -0500 Subject: morning giggle In-Reply-To: References: Message-ID: On Sat, Aug 17, 2013 at 8:58 PM, Randy Bush wrote: > for your morning, or whatever time of day it is to you, giggle > > lol... Ah... they must want form #298446.3B-II; request for login shell and root password from complete random stranger under dubious circumstances, without justification. It comes right after the form; request to un-send previous e-mail and pretend it didn't exist :-) -- -J From alter3d at alter3d.ca Sun Aug 18 05:22:18 2013 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Sun, 18 Aug 2013 01:22:18 -0400 Subject: morning giggle In-Reply-To: References: Message-ID: <52105A0A.8030904@alter3d.ca> On 8/18/2013 1:11 AM, Jimmy Hess wrote: > On Sat, Aug 17, 2013 at 8:58 PM, Randy Bush wrote: > >> for your morning, or whatever time of day it is to you, giggle >> >> > lol... > > Ah... they must want form #298446.3B-II; request for login shell and > root password from complete random stranger under dubious circumstances, > without justification. > > It comes right after the form; request to un-send previous e-mail and > pretend it didn't exist :-) > > -- > -J Hmm, I thought that they were asking for form numbers # 298446.4 -- legal agreement for licensing of DNS zone data # 298446.4-A -- fee schedule for licensing of DNS zone data (currently $42M per line of data) # 298446.4-B -- affidavit that the text of the legal agreement (form 298446.4) -- all 403 pages of it -- has been indelibly tattooed on the licensee's body. Photographic evidence is required to be attached. # 298446.4-C -- notice of revocation of DNS zone licensing rights Sadly, due to the slow speed of bureaucratic processes, I can never seem to get form -C out to the licensee before they've submitted -B. ;) - Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4246 bytes Desc: S/MIME Cryptographic Signature URL: From excelsio at gmx.com Sun Aug 18 08:07:45 2013 From: excelsio at gmx.com (excelsio at gmx.com) Date: Sun, 18 Aug 2013 10:07:45 +0200 Subject: [Paper] B4: Experience with a Globally-Deployed Software Defined WAN In-Reply-To: <20130817184115.GB18473@uriel.asininetech.com> References: <20130817184115.GB18473@uriel.asininetech.com> Message-ID: <521080D1.5090403@gmx.com> So, where can I buy those "google switches": http://www.networking-forum.com/viewtopic.php?f=46&t=29803 From arturo.servin at gmail.com Sun Aug 18 11:27:42 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Sun, 18 Aug 2013 08:27:42 -0300 Subject: [Paper] B4: Experience with a Globally-Deployed Software Defined In-Reply-To: References: <20130817193218.023845500008D@freedman.net> <521003C6.3070308@gmail.com> <5210075D.2030101@utc.edu> Message-ID: <5210AFAE.1090009@gmail.com> Well, you just made my point. Just change "cold" for "cyber". /as On 8/17/13 9:26 PM, Jayram D?shpand? wrote: > SDN is not a new concept at all. > > Infact since ARPANET days, the notion of centralized control plane had a > lot of traction. But with Cold war around, It made more sense to push the > control plane intelligence into individual decision points (routers , > switches , et . al. ). Considering the possibility of the commies taking > down some part of the early Internet, the remaining partitioned network > could still survive as the rest of the decision points could converge and > act as independent network snippets. > > -Jay. > > > > On Sat, Aug 17, 2013 at 4:29 PM, Jeff Kell wrote: > >> On 8/17/2013 7:14 PM, Arturo Servin wrote: >>> Hacker will love SDN ... >> >> Yes. Traditional SDN is big, flat layer-2 network with global >> mac-address resolution, and a big fat Java applet managing the adjacency >> tables. >> >> What could *possibly* go wrong? >> >> Jeff >> >> >> > > From chris.karel at gmail.com Mon Aug 19 01:33:39 2013 From: chris.karel at gmail.com (Christopher Karel) Date: Sun, 18 Aug 2013 20:33:39 -0500 Subject: BGP Route Issues Message-ID: <521175F3.5010505@gmail.com> Good evening, I'm hoping you guys might be able to offer some advice or insight into a BGP problem I've got. I've noticed some strange routes between our network, AS27270, and AS22943. It looks like both our networks are dual homed. One ISP as the primary, and the other used as a backup, with path prepending to prevent it from actually being used except in an outage. However, our route to 22943 appears to be using their backup link. (27270 4323 7018 22943 22943 22943 22943 22943 22943 22943 22943 22943 22943 22943) Which is strange, because we can reach their primary ISP without any such rigmarole. Playing around with Looking Glass servers indicates that Cogent (AS174) has a similar backup route to our network. (174 22402 27270 27270 27270 27270 27270 27270) Everywhere else I check seems perfectly sane. But since Cogent is essentially in-between the two networks I'm troubleshooting, I would assume that the other network has a similar route. But Cogent won't talk with me about this, since I'm not a customer. So as far as advice goes, is there a common issue that might result in such poor routes in both directions? Any further troubleshooting that I should be doing? Or any ideas on how to help remedy things that appear to be outside our network/ISP? Or are we doing something so wrong that this is all my fault? I'd really appreciate any input on this. From richard.hesse at weebly.com Mon Aug 19 01:43:26 2013 From: richard.hesse at weebly.com (Richard Hesse) Date: Sun, 18 Aug 2013 18:43:26 -0700 Subject: Comcast security NOC/contact Message-ID: Can someone from Comcast please contact me over what appears to be an ill-conceived nullroute or block regarding one of our content IP's. This issue is limited only to Comcast and only to a single IP. Please contact me to get this resolved. I'm guessing that someone wanted us offline but couldn't do it directly. So they attacked you using our spoofed IP, and your automated systems put a block in place. It would also be nice to have an actual, real NOC number listed in your whois. -richard From ikiris at gmail.com Mon Aug 19 02:42:24 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Sun, 18 Aug 2013 21:42:24 -0500 Subject: BGP Route Issues In-Reply-To: <521175F3.5010505@gmail.com> References: <521175F3.5010505@gmail.com> Message-ID: Local Pref (which is common by the way to be set so customers > peers > transit). AS Path doesn't beat it. You can only request people follow the routes you want ingress, there's nothing you can do to force them to take a path to you short of deaggregation, and that only works until they notice it, and it irratates the rest of the world as well by using additional route slots. Poor routing is purely a viewpoint problem, not necessarily in agreement between all parties. -Blake On Sun, Aug 18, 2013 at 8:33 PM, Christopher Karel wrote: > Good evening, > > I'm hoping you guys might be able to offer some advice or insight into > a BGP problem I've got. I've noticed some strange routes between our > network, AS27270, and AS22943. It looks like both our networks are dual > homed. One ISP as the primary, and the other used as a backup, with path > prepending to prevent it from actually being used except in an outage. > However, our route to 22943 appears to be using their backup link. (27270 > 4323 7018 22943 22943 22943 22943 22943 22943 22943 22943 22943 22943 > 22943) Which is strange, because we can reach their primary ISP without > any such rigmarole. > > Playing around with Looking Glass servers indicates that Cogent > (AS174) has a similar backup route to our network. (174 22402 27270 27270 > 27270 27270 27270 27270) Everywhere else I check seems perfectly sane. > But since Cogent is essentially in-between the two networks I'm > troubleshooting, I would assume that the other network has a similar route. > But Cogent won't talk with me about this, since I'm not a customer. > > So as far as advice goes, is there a common issue that might result in > such poor routes in both directions? Any further troubleshooting that I > should be doing? Or any ideas on how to help remedy things that appear to > be outside our network/ISP? Or are we doing something so wrong that this > is all my fault? > > I'd really appreciate any input on this. > > From richard.hesse at weebly.com Mon Aug 19 02:56:25 2013 From: richard.hesse at weebly.com (Richard Hesse) Date: Sun, 18 Aug 2013 19:56:25 -0700 Subject: Comcast security NOC/contact In-Reply-To: References: Message-ID: Several people responded to me off list. Thanks! -richard On Sun, Aug 18, 2013 at 6:43 PM, Richard Hesse wrote: > Can someone from Comcast please contact me over what appears to be an > ill-conceived nullroute or block regarding one of our content IP's. > > This issue is limited only to Comcast and only to a single IP. Please > contact me to get this resolved. I'm guessing that someone wanted us > offline but couldn't do it directly. So they attacked you using our spoofed > IP, and your automated systems put a block in place. > > It would also be nice to have an actual, real NOC number listed in your > whois. > > -richard > From sethm at rollernet.us Mon Aug 19 03:10:26 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 18 Aug 2013 20:10:26 -0700 Subject: BGP Route Issues In-Reply-To: <521175F3.5010505@gmail.com> References: <521175F3.5010505@gmail.com> Message-ID: <52118CA2.7040505@rollernet.us> On 8/18/13 6:33 PM, Christopher Karel wrote: > > I'm hoping you guys might be able to offer some advice or insight > into a BGP problem I've got. I've noticed some strange routes between > our network, AS27270, and AS22943. It looks like both our networks are > dual homed. One ISP as the primary, and the other used as a backup, > with path prepending to prevent it from actually being used except in an > outage. However, our route to 22943 appears to be using their backup > link. (27270 4323 7018 22943 22943 22943 22943 22943 22943 22943 22943 > 22943 22943 22943) Which is strange, because we can reach their primary > ISP without any such rigmarole. It's not strange. AS path prepending like a typewriter monkey on crack doesn't mean anything and certainly does not a "backup" link make. Localpref can and will make it the best path anyway. ~Seth From randy_94108 at yahoo.com Mon Aug 19 03:51:16 2013 From: randy_94108 at yahoo.com (Randy) Date: Sun, 18 Aug 2013 20:51:16 -0700 (PDT) Subject: BGP Route Issues In-Reply-To: References: <521175F3.5010505@gmail.com> Message-ID: <1376884276.80610.YahooMailNeo@web184703.mail.ne1.yahoo.com> 11 prepends is beyond-excessive besides being annoying. filter please _([0-9]+) _/1_/1_/1_ >________________________________ > From: Blake Dunlap >To: Christopher Karel >Cc: "nanog at nanog.org" >Sent: Sunday, August 18, 2013 7:42 PM >Subject: Re: BGP Route Issues > > >Local Pref (which is common by the way to be set so customers > peers > >transit). AS Path doesn't beat it. >You can only request people follow the routes you want ingress, there's >nothing you can do to force them to take a path to you short of >deaggregation, and that only works until they notice it, and it irratates >the rest of the world as well by using additional route slots. > >Poor routing is purely a viewpoint problem, not necessarily in agreement >between all parties. > >-Blake > > >On Sun, Aug 18, 2013 at 8:33 PM, Christopher Karel wrote: > >>? Good evening, >> >>? ? I'm hoping you guys might be able to offer some advice or insight into >> a BGP problem I've got.? I've noticed some strange routes between our >> network, AS27270, and AS22943.? It looks like both our networks are dual >> homed.? One ISP as the primary, and the other used as a backup, with path >> prepending to prevent it from actually being used except in an outage. >>? However, our route to 22943 appears to be using their backup link.? (27270 >> 4323 7018 22943 22943 22943 22943 22943 22943 22943 22943 22943 22943 >> 22943)? Which is strange, because we can reach their primary ISP without >> any such rigmarole. >> >>? ? Playing around with Looking Glass servers indicates that Cogent >> (AS174) has a similar backup route to our network.? (174 22402 27270 27270 >> 27270 27270 27270 27270)? Everywhere else I check seems perfectly sane. >>? But since Cogent is essentially in-between the two networks I'm >> troubleshooting, I would assume that the other network has a similar route. >>? But Cogent won't talk with me about this, since I'm not a customer. >> >>? ? So as far as advice goes, is there a common issue that might result in >> such poor routes in both directions?? Any further troubleshooting that I >> should be doing?? Or any ideas on how to help remedy things that appear to >> be outside our network/ISP?? Or are we doing something so wrong that this >> is all my fault? >> >> I'd really appreciate any input on this. >> >> > > > From LarrySheldon at cox.net Mon Aug 19 07:38:34 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 19 Aug 2013 02:38:34 -0500 Subject: Trivium Message-ID: <5211CB7A.5010004@cox.net> http://news.cnet.com/8301-1023_3-57598978-93/google-outage-reportedly-caused-big-drop-in-global-traffic/ "How big is the Internet"? Depends in whether Google is up or not? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From fakrulalam at gmail.com Mon Aug 19 12:27:08 2013 From: fakrulalam at gmail.com (Fakrul Alam Pappu) Date: Mon, 19 Aug 2013 18:27:08 +0600 Subject: BGP Route Issues In-Reply-To: <1376884276.80610.YahooMailNeo@web184703.mail.ne1.yahoo.com> References: <521175F3.5010505@gmail.com> <1376884276.80610.YahooMailNeo@web184703.mail.ne1.yahoo.com> Message-ID: Won't it be backslash rather than forward slash? _([0-9]+) _\1_\1_\1_ On Mon, Aug 19, 2013 at 9:51 AM, Randy wrote: > 11 prepends is beyond-excessive besides being annoying. > filter please _([0-9]+) _/1_/1_/1_ > > > > > >________________________________ > > From: Blake Dunlap > >To: Christopher Karel > >Cc: "nanog at nanog.org" > >Sent: Sunday, August 18, 2013 7:42 PM > >Subject: Re: BGP Route Issues > > > > > >Local Pref (which is common by the way to be set so customers > peers > > >transit). AS Path doesn't beat it. > >You can only request people follow the routes you want ingress, there's > >nothing you can do to force them to take a path to you short of > >deaggregation, and that only works until they notice it, and it irratates > >the rest of the world as well by using additional route slots. > > > >Poor routing is purely a viewpoint problem, not necessarily in agreement > >between all parties. > > > >-Blake > > > > > >On Sun, Aug 18, 2013 at 8:33 PM, Christopher Karel >wrote: > > > >> Good evening, > >> > >> I'm hoping you guys might be able to offer some advice or insight > into > >> a BGP problem I've got. I've noticed some strange routes between our > >> network, AS27270, and AS22943. It looks like both our networks are dual > >> homed. One ISP as the primary, and the other used as a backup, with > path > >> prepending to prevent it from actually being used except in an outage. > >> However, our route to 22943 appears to be using their backup link. > (27270 > >> 4323 7018 22943 22943 22943 22943 22943 22943 22943 22943 22943 22943 > >> 22943) Which is strange, because we can reach their primary ISP without > >> any such rigmarole. > >> > >> Playing around with Looking Glass servers indicates that Cogent > >> (AS174) has a similar backup route to our network. (174 22402 27270 > 27270 > >> 27270 27270 27270 27270) Everywhere else I check seems perfectly sane. > >> But since Cogent is essentially in-between the two networks I'm > >> troubleshooting, I would assume that the other network has a similar > route. > >> But Cogent won't talk with me about this, since I'm not a customer. > >> > >> So as far as advice goes, is there a common issue that might result > in > >> such poor routes in both directions? Any further troubleshooting that I > >> should be doing? Or any ideas on how to help remedy things that appear > to > >> be outside our network/ISP? Or are we doing something so wrong that > this > >> is all my fault? > >> > >> I'd really appreciate any input on this. > >> > >> > > > > > > > From nick at foobar.org Mon Aug 19 13:19:54 2013 From: nick at foobar.org (Nick Hilliard) Date: Mon, 19 Aug 2013 14:19:54 +0100 Subject: BGP Route Issues In-Reply-To: References: <521175F3.5010505@gmail.com> <1376884276.80610.YahooMailNeo@web184703.mail.ne1.yahoo.com> Message-ID: <52121B7A.4060805@foobar.org> On 19/08/2013 13:27, Fakrul Alam Pappu wrote: > Won't it be backslash rather than forward slash? > > _([0-9]+) _\1_\1_\1_ he probably runs windows. Nick From randy_94108 at yahoo.com Mon Aug 19 14:09:22 2013 From: randy_94108 at yahoo.com (Randy) Date: Mon, 19 Aug 2013 07:09:22 -0700 (PDT) Subject: BGP Route Issues In-Reply-To: References: <521175F3.5010505@gmail.com> <1376884276.80610.YahooMailNeo@web184703.mail.ne1.yahoo.com> Message-ID: <1376921362.23246.YahooMailNeo@web184704.mail.ne1.yahoo.com> yes of course..sorry for the typos >________________________________ > From: Fakrul Alam Pappu >To: Randy >Cc: Blake Dunlap ; Christopher Karel ; "nanog at nanog.org" >Sent: Monday, August 19, 2013 5:27 AM >Subject: Re: BGP Route Issues > > > >Won't it be backslash rather than forward slash? > >_([0-9]+) _\1_\1_\1_ > > > >On Mon, Aug 19, 2013 at 9:51 AM, Randy wrote: > >11 prepends is beyond-excessive besides being annoying. >>filter please _([0-9]+) _/1_/1_/1_ >> >> >> >> >>>________________________________ >>> From: Blake Dunlap >>>To: Christopher Karel >>>Cc: "nanog at nanog.org" >>>Sent: Sunday, August 18, 2013 7:42 PM >>>Subject: Re: BGP Route Issues >> >>> >>> >>>Local Pref (which is common by the way to be set so customers > peers > >>>transit). AS Path doesn't beat it. >>>You can only request people follow the routes you want ingress, there's >>>nothing you can do to force them to take a path to you short of >>>deaggregation, and that only works until they notice it, and it irratates >>>the rest of the world as well by using additional route slots. >>> >>>Poor routing is purely a viewpoint problem, not necessarily in agreement >>>between all parties. >>> >>>-Blake >>> >>> >>>On Sun, Aug 18, 2013 at 8:33 PM, Christopher Karel wrote: >>> >>>>? ?Good evening, >>>> >>>>? ? ?I'm hoping you guys might be able to offer some advice or insight into >>>> a BGP problem I've got.? I've noticed some strange routes between our >>>> network, AS27270, and AS22943.? It looks like both our networks are dual >>>> homed.? One ISP as the primary, and the other used as a backup, with path >>>> prepending to prevent it from actually being used except in an outage. >>>>? However, our route to 22943 appears to be using their backup link.? (27270 >>>> 4323 7018 22943 22943 22943 22943 22943 22943 22943 22943 22943 22943 >>>> 22943)? Which is strange, because we can reach their primary ISP without >>>> any such rigmarole. >>>> >>>>? ? ?Playing around with Looking Glass servers indicates that Cogent >>>> (AS174) has a similar backup route to our network.? (174 22402 27270 27270 >>>> 27270 27270 27270 27270)? Everywhere else I check seems perfectly sane. >>>>? But since Cogent is essentially in-between the two networks I'm >>>> troubleshooting, I would assume that the other network has a similar route. >>>>? But Cogent won't talk with me about this, since I'm not a customer. >>>> >>>>? ? ?So as far as advice goes, is there a common issue that might result in >>>> such poor routes in both directions?? Any further troubleshooting that I >>>> should be doing?? Or any ideas on how to help remedy things that appear to >>>> be outside our network/ISP?? Or are we doing something so wrong that this >>>> is all my fault? >>>> >>>> I'd really appreciate any input on this. >>>> >>>> >>> >>> >>> >> > > > From ikiris at gmail.com Mon Aug 19 14:42:53 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 19 Aug 2013 09:42:53 -0500 Subject: Trivium In-Reply-To: <5211CB7A.5010004@cox.net> References: <5211CB7A.5010004@cox.net> Message-ID: Without Google, how do you know where anything even *is*? -Blake On Mon, Aug 19, 2013 at 2:38 AM, Larry Sheldon wrote: > http://news.cnet.com/8301-**1023_3-57598978-93/google-** > outage-reportedly-caused-big-**drop-in-global-traffic/ > > > "How big is the Internet"? > > Depends in whether Google is up or not? > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > > From james at freedomnet.co.nz Mon Aug 19 14:47:39 2013 From: james at freedomnet.co.nz (james jones) Date: Mon, 19 Aug 2013 10:47:39 -0400 Subject: Trivium In-Reply-To: References: <5211CB7A.5010004@cox.net> Message-ID: I have got my local bookmarks. :D On Mon, Aug 19, 2013 at 10:42 AM, Blake Dunlap wrote: > Without Google, how do you know where anything even *is*? > > -Blake > > > On Mon, Aug 19, 2013 at 2:38 AM, Larry Sheldon > wrote: > > > http://news.cnet.com/8301-**1023_3-57598978-93/google-** > > outage-reportedly-caused-big-**drop-in-global-traffic/< > http://news.cnet.com/8301-1023_3-57598978-93/google-outage-reportedly-caused-big-drop-in-global-traffic/ > > > > > > > > "How big is the Internet"? > > > > Depends in whether Google is up or not? > > > > -- > > Requiescas in pace o email Two identifying characteristics > > of System Administrators: > > Ex turpi causa non oritur actio Infallibility, and the ability to > > learn from their mistakes. > > (Adapted from Stephen Pinker) > > > > > From wbailey at satelliteintelligencegroup.com Mon Aug 19 14:55:16 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 19 Aug 2013 14:55:16 +0000 Subject: Trivium In-Reply-To: References: <5211CB7A.5010004@cox.net> , Message-ID: Or I just type in Slashdot.org and off to the races. If DNS went down on the other hand, I'd be mowing my lawn. Sent from my Mobile Device. -------- Original message -------- From: james jones Date: 08/19/2013 7:50 AM (GMT-08:00) To: Blake Dunlap Cc: nanog at nanog.org Subject: Re: Trivium I have got my local bookmarks. :D On Mon, Aug 19, 2013 at 10:42 AM, Blake Dunlap wrote: > Without Google, how do you know where anything even *is*? > > -Blake > > > On Mon, Aug 19, 2013 at 2:38 AM, Larry Sheldon > wrote: > > > http://news.cnet.com/8301-**1023_3-57598978-93/google-** > > outage-reportedly-caused-big-**drop-in-global-traffic/< > http://news.cnet.com/8301-1023_3-57598978-93/google-outage-reportedly-caused-big-drop-in-global-traffic/ > > > > > > > > "How big is the Internet"? > > > > Depends in whether Google is up or not? > > > > -- > > Requiescas in pace o email Two identifying characteristics > > of System Administrators: > > Ex turpi causa non oritur actio Infallibility, and the ability to > > learn from their mistakes. > > (Adapted from Stephen Pinker) > > > > > From patrick at ianai.net Mon Aug 19 15:11:23 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 19 Aug 2013 11:11:23 -0400 Subject: Trivium In-Reply-To: References: <5211CB7A.5010004@cox.net> Message-ID: On Aug 19, 2013, at 10:42 , Blake Dunlap wrote: > Without Google, how do you know where anything even *is*? Pretending that wasn't a troll, I wonder how much of the traffic these days is things like AppleTV, Roku, OS updates, iThing/Android 'Apps', etc. that do not require a user to type "www.bing.com" into the Google search box[*] so they can find the web page. -- TTFN, patrick [*] I've actually see someone type "www.yahoo.com" into the Google search box, then use Yahoo! to search for something. Don't ask.... > On Mon, Aug 19, 2013 at 2:38 AM, Larry Sheldon wrote: > >> http://news.cnet.com/8301-**1023_3-57598978-93/google-** >> outage-reportedly-caused-big-**drop-in-global-traffic/ >> >> >> "How big is the Internet"? >> >> Depends in whether Google is up or not? >> >> -- >> Requiescas in pace o email Two identifying characteristics >> of System Administrators: >> Ex turpi causa non oritur actio Infallibility, and the ability to >> learn from their mistakes. >> (Adapted from Stephen Pinker) >> >> > -------------- 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 mpetach at netflight.com Mon Aug 19 19:27:39 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 19 Aug 2013 12:27:39 -0700 Subject: Trivium In-Reply-To: References: <5211CB7A.5010004@cox.net> Message-ID: It's pretty well known that the "hottest searches" pages put up by the major search engines filter out the extremely high levels of background noise. Compare http://www.google.com/trends/ with http://www.google.com/trends/explore#cmpt=q while it's more engaging to show the hottest searches as being about your favorite actor or singer, the truth is, those search queries over any appreciable length of time are drowned out by the awe-inspiring number of people typing things like "facebook.com" into the search box so they can click on the link to facebook...instead of just typing it into the URL bar directly. Same with people searching for yahoo on google, or hotmail on yahoo. It isn't the cool, sexy data people want to see, so it gets trimmed out of the "hottest search" results pages. darn it. I had something else I was going to add, but that was 2 hours and two phone calls ago, and now it's completely gone. :/ Matt On Mon, Aug 19, 2013 at 8:11 AM, Patrick W. Gilmore wrote: > On Aug 19, 2013, at 10:42 , Blake Dunlap wrote: > > > Without Google, how do you know where anything even *is*? > > Pretending that wasn't a troll, I wonder how much of the traffic these > days is things like AppleTV, Roku, OS updates, iThing/Android 'Apps', etc. > that do not require a user to type "www.bing.com" into the Google search > box[*] so they can find the web page. > > -- > TTFN, > patrick > > [*] I've actually see someone type "www.yahoo.com" into the Google search > box, then use Yahoo! to search for something. Don't ask.... > > > > On Mon, Aug 19, 2013 at 2:38 AM, Larry Sheldon > wrote: > > > >> http://news.cnet.com/8301-**1023_3-57598978-93/google-** > >> outage-reportedly-caused-big-**drop-in-global-traffic/< > http://news.cnet.com/8301-1023_3-57598978-93/google-outage-reportedly-caused-big-drop-in-global-traffic/ > > > >> > >> > >> "How big is the Internet"? > >> > >> Depends in whether Google is up or not? > >> > >> -- > >> Requiescas in pace o email Two identifying characteristics > >> of System Administrators: > >> Ex turpi causa non oritur actio Infallibility, and the ability to > >> learn from their mistakes. > >> (Adapted from Stephen Pinker) > >> > >> > > > > From mikea at mikea.ath.cx Mon Aug 19 19:49:40 2013 From: mikea at mikea.ath.cx (Mike A) Date: Mon, 19 Aug 2013 14:49:40 -0500 Subject: mail.mil contact? In-Reply-To: References: Message-ID: <20130819194940.GA3797@mikea.ath.cx> On Fri, Aug 16, 2013 at 07:25:11AM -1000, Antonio Querubin wrote: > Wondering if anyone else is receiving reports of email to mail.mil > addresses being delayed or refused? The mail.mil mx appear to be > selectively refusing mail. > > If anyone has good (non-email) contact info for the mail.mil operators > please send it my way. Thanks. I see this frequently in the dayjob; I suspect and conjecture that the operators are doing some sort of configuration stuff, and we see the part where mail receipt gets balky. I have found that calling the IT folks at the receiving installation often gets a "They're doing things upstream, and we're down until they finish" response. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From ikiris at gmail.com Mon Aug 19 20:24:21 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 19 Aug 2013 15:24:21 -0500 Subject: Netscout experiences Message-ID: Greetings, Anyone out there have experiences with Netscout or any of their nGenius products and wish to share impressions? Currently looking at them in comparison to say Netbrain, NetQoS, smarts, etc. -Blake From AOsgood at Streamline-Solutions.net Mon Aug 19 20:36:34 2013 From: AOsgood at Streamline-Solutions.net (Aaron D. Osgood) Date: Mon, 19 Aug 2013 16:36:34 -0400 Subject: Third Party Software Audit Message-ID: I apologize for seeming to waste bandwidth - we have been asked to recommend an firm that does 3rd party software audits. This is a first for me - Suggestions? Aaron D. Osgood Streamline Solutions L.L.C P.O. Box 6115 Falmouth, ME 04105 TEL: 207-781-5561 MOBILE: 207-831-5829 ICQ: 206889374 GVoice: 207.518.8455 GTalk: aaron.osgood AOsgood at Streamline-Solutions.net http://www.streamline-solutions.net Introducing Efficiency to Business since 1986. From dschuemann at gmail.com Mon Aug 19 20:57:35 2013 From: dschuemann at gmail.com (Dustin Schuemann) Date: Mon, 19 Aug 2013 16:57:35 -0400 Subject: Netscout experiences In-Reply-To: References: Message-ID: We were looking at them as well. They came back with a quote for 10 gig capabilities and the pricing was insane. On Mon, Aug 19, 2013 at 4:24 PM, Blake Dunlap wrote: > Greetings, > Anyone out there have experiences with Netscout or any of their > nGenius products and wish to share impressions? Currently looking at them > in comparison to say Netbrain, NetQoS, smarts, etc. > > -Blake > From clowe at vertafore.com Mon Aug 19 21:01:25 2013 From: clowe at vertafore.com (Lowe,Chris) Date: Mon, 19 Aug 2013 21:01:25 +0000 Subject: Netscout experiences In-Reply-To: References: Message-ID: Very useful for troubleshooting and insight to network. Very expensive. -----Original Message----- From: Dustin Schuemann [mailto:dschuemann at gmail.com] Sent: Monday, August 19, 2013 1:58 PM To: Blake Dunlap Cc: nanog at nanog.org Subject: Re: Netscout experiences We were looking at them as well. They came back with a quote for 10 gig capabilities and the pricing was insane. On Mon, Aug 19, 2013 at 4:24 PM, Blake Dunlap wrote: > Greetings, > Anyone out there have experiences with Netscout or any of their > nGenius products and wish to share impressions? Currently looking at > them in comparison to say Netbrain, NetQoS, smarts, etc. > > -Blake > From cconn at b2b2c.ca Mon Aug 19 23:54:39 2013 From: cconn at b2b2c.ca (Chris Conn) Date: Mon, 19 Aug 2013 19:54:39 -0400 Subject: AS174 - cogent - someone without denial syndrome please Message-ID: <5212B03F.2040707@b2b2c.ca> Any BGP admins from AS174 monitoring NANOG? I would appreciate a quick email exchange regarding access to www.cogentco.com from some prefixes. Thanks, Chris From toolb0x.security at gmail.com Tue Aug 20 00:24:48 2013 From: toolb0x.security at gmail.com (tOoLb0x) Date: Mon, 19 Aug 2013 17:24:48 -0700 Subject: Netscout experiences In-Reply-To: References: Message-ID: On Aug 19, 2013, at 13:24, Blake Dunlap wrote: > Greetings, > Anyone out there have experiences with Netscout or any of their > nGenius products and wish to share impressions? Currently looking at them > in comparison to say Netbrain, NetQoS, smarts, etc. > > -Blake We've been using Netscout's nGenius for years. Their Gig probes and Infinistream probes are rather expensive but the resulting application visibility justifies the cost. We have basically built up our network visibility over time starting with a PM server and a single probe, used as a netflow collector, then gradually superseding netflow with dedicated Netscout probes. We used fiber and copper taps instead of SPAN ports since we believe SPAN ports are better used tactically. Take that instrumentation cost into consideration. To be fair, we haven't evaluated the other apps that you have mentioned, as of late. We do have a Concord eHealth implementation which we use for historic SNMP network statistics. It's good for showing us WHEN and WHERE we have a bandwidth spike but it doesn't answer the WHO and WHAT questions like nGenius does. We use the Inifnistream probes strategically as a "network TiVo" which allows us to grab the packets we need for retrospective performance or forensic analysis. All of the Gig probes can do packet capture but they're limited. The Infinistreams are basically deployed at our core and network perimeter. Our Gig probes are more ubiquitous at the datacenter and distribution sites. Our basic philosophy of use is to monitor all the data center switches and any network choke points, especially ingress (ISP, extranet, VPN, dedicated circuits, etc). We also have a couple of portables that we use for our more on-going issues. We do have a few of the 10G probes but we coupled that with a Gigamon deployment since it was too cost prohibitive to purchase multiple 10G tool/interfaces everywhere in our data centers. Gigamon allows us to leverage many of our existing tools but that may not be germane to the conversation. -bb From randy at psg.com Tue Aug 20 02:48:31 2013 From: randy at psg.com (Randy Bush) Date: Tue, 20 Aug 2013 11:48:31 +0900 Subject: Trivium In-Reply-To: References: <5211CB7A.5010004@cox.net> Message-ID: > Without Google, how do you know where anything even *is*? ask that to 20% of the world's population randy From randy at psg.com Tue Aug 20 05:05:08 2013 From: randy at psg.com (Randy Bush) Date: Tue, 20 Aug 2013 14:05:08 +0900 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: Message-ID: > As you may know CIRA has been working with groups across Canada to > establish new IXPs. wow! i thought there were a lot of ixps, torix, vantx, ... are these open, neutral, ixps, a la six etc? or big players trying to save the internet from itself? would some of the *local* providers in the areas who actually use the cira ixen care to report on the experience? > When we started this work, we didn't know that Vancouver already had > an IXP in depth research, eh? >?We and BCNet are planning a town hall style meeting in late September, > tentatively September 26, to talk about the IXP needs of the Vancouver > area. why are all my alarms going off? randy From mysidia at gmail.com Tue Aug 20 05:12:56 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 20 Aug 2013 00:12:56 -0500 Subject: Trivium In-Reply-To: References: <5211CB7A.5010004@cox.net> Message-ID: On Mon, Aug 19, 2013 at 9:48 PM, Randy Bush wrote: > > Without Google, how do you know where anything even *is*? > > ask that to 20% of the world's population Turning off Google is essentially doing a rm -rf http:// www-wide analog to rm -rf / or temporarily loss of the root directory, pending a fsck. The important stuff is still there, somewhere... it's just becomes a real chore to get to your files without a useful directory provided by the indexing system, until you can get your superblock repaired. Webcrawler, Gopher sites, and Archie search engine become viable options. There's also backup on some stacks of tapes somewhere labelled Bing, DMOZ, Yahoo, and a few other misc. unlabelled stacks, various well-known .COM and .EDU domains, which you could probably use to find your materials if you downloaded the old Hosts.txt files; if you look long and hard enough, you can still find the filesystem data you need to relink the directory and get at the files you need; it can just be darn inconvenient sorting out all the spam. randy > -- -JH From mpetach at netflight.com Tue Aug 20 05:29:38 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 19 Aug 2013 22:29:38 -0700 Subject: Trivium In-Reply-To: References: <5211CB7A.5010004@cox.net> Message-ID: I'm curious; do people really think that the difference in material indexed between Google, Yahoo/Bing, and others is really that big? I don't mean the heuristics and algorithms used to return the results in a particularly useful order; I mean the sheer raw set of indexed pages. I don't debate that Google found a particularly useful page ranking system; but I question the notion that the loss of Google was akin to the loss of your root directory. Matt On Mon, Aug 19, 2013 at 10:12 PM, Jimmy Hess wrote: > On Mon, Aug 19, 2013 at 9:48 PM, Randy Bush wrote: > > > > Without Google, how do you know where anything even *is*? > > > > ask that to 20% of the world's population > > > Turning off Google is essentially doing a rm -rf http:// > www-wide analog to rm -rf / or temporarily loss of the root directory, > pending a fsck. > > The important stuff is still there, somewhere... it's just becomes a real > chore to get to your files without a useful directory provided by the > indexing system, until you can get your superblock repaired. > > Webcrawler, Gopher sites, and Archie search engine become viable options. > > > There's also backup on some stacks of tapes somewhere labelled Bing, DMOZ, > Yahoo, and a few other misc. unlabelled stacks, various well-known .COM > and .EDU domains, which you could probably use to find your materials if > you downloaded the old Hosts.txt files; if you look long and hard enough, > you can still find the filesystem data you need to relink the directory > and get at the files you need; it can just be darn inconvenient sorting > out all the spam. > > > randy > > > > -- > -JH > > From LarrySheldon at cox.net Tue Aug 20 05:34:59 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 20 Aug 2013 00:34:59 -0500 Subject: Trivium In-Reply-To: References: <5211CB7A.5010004@cox.net> Message-ID: <52130003.1050300@cox.net> On 8/20/2013 12:12 AM, Jimmy Hess wrote: > On Mon, Aug 19, 2013 at 9:48 PM, Randy Bush wrote: > >>> Without Google, how do you know where anything even *is*? >> >> ask that to 20% of the world's population > > > Turning off Google is essentially doing a rm -rf http:// www-wide > analog to rm -rf / or temporarily loss of the root directory, > pending a fsck. I disagree categorically with that. Turning off Google affects at most my use of electric maps--they still have a better setup than any of the others I have tried. I use Bing, but there are lots of other engines around--some of them a lot more honest. The scary thing to me is that since most of the medicos I see have gone to an Obamacare-compliant records system and all I see is people's backsides at their computer terminal as they use a Google dialog box for most of what they do. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Tue Aug 20 05:35:20 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 20 Aug 2013 00:35:20 -0500 Subject: Trivium In-Reply-To: References: <5211CB7A.5010004@cox.net> Message-ID: <52130018.7070201@cox.net> On 8/20/2013 12:29 AM, Matthew Petach wrote: > I'm curious; do people really think that the difference in material > indexed between Google, Yahoo/Bing, and others is really that > big? I don't mean the heuristics and algorithms used to return > the results in a particularly useful order; I mean the sheer raw > set of indexed pages. I don't debate that Google found a > particularly useful page ranking system; but I question the > notion that the loss of Google was akin to the loss of your > root directory. I don't think the other engines are nearly as badly poisoned by the SEO crap. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From ggm at algebras.org Tue Aug 20 05:35:37 2013 From: ggm at algebras.org (George Michaelson) Date: Tue, 20 Aug 2013 15:35:37 +1000 Subject: Trivium In-Reply-To: References: <5211CB7A.5010004@cox.net> Message-ID: I agree. I think its over stated. But I do think there was a more direct customer-disadvantage outcome, albiet increadibly brief. I think a bunch of people like me have now got a better sense our always-on backend is 'brittle' even if very very strong, most of the time. http://www.google.com/appsstatus#hl=en&v=status&ts=1376701087982 suggests it was a disconnection from considerably more than search. I don't believe index analogies jusify some of the scaling/visualization/comparison-to-root-dns things, but I would have been made distinctly uncomfortable in some circumstances by the loss of google backed email, google drive, and their implicit "no local storage required: you're always on" behaviour. An example is when I posted some stuff to the UK from the Post office across from the hotel at IETF, and spend 2 min online searching google mail for the address. Or, given the new "your airline ticket on your phone" model, I might have been trying to checkin at the last 5 minutes onto a flight. Or get into a ball game... Is this "40% of the net offline" ? no. Was it pretty wide reaching? Yes. On Tue, Aug 20, 2013 at 3:29 PM, Matthew Petach wrote: > I'm curious; do people really think that the difference in material > indexed between Google, Yahoo/Bing, and others is really that > big? I don't mean the heuristics and algorithms used to return > the results in a particularly useful order; I mean the sheer raw > set of indexed pages. I don't debate that Google found a > particularly useful page ranking system; but I question the > notion that the loss of Google was akin to the loss of your > root directory. > > Matt > > > > > On Mon, Aug 19, 2013 at 10:12 PM, Jimmy Hess wrote: > > > On Mon, Aug 19, 2013 at 9:48 PM, Randy Bush wrote: > > > > > > Without Google, how do you know where anything even *is*? > > > > > > ask that to 20% of the world's population > > > > > > Turning off Google is essentially doing a rm -rf http:// > > www-wide analog to rm -rf / or temporarily loss of the root > directory, > > pending a fsck. > > > > The important stuff is still there, somewhere... it's just becomes a > real > > chore to get to your files without a useful directory provided by the > > indexing system, until you can get your superblock repaired. > > > > Webcrawler, Gopher sites, and Archie search engine become viable options. > > > > > > There's also backup on some stacks of tapes somewhere labelled Bing, > DMOZ, > > Yahoo, and a few other misc. unlabelled stacks, various well-known .COM > > and .EDU domains, which you could probably use to find your materials > if > > you downloaded the old Hosts.txt files; if you look long and hard > enough, > > you can still find the filesystem data you need to relink the directory > > and get at the files you need; it can just be darn inconvenient > sorting > > out all the spam. > > > > > > randy > > > > > > > -- > > -JH > > > > > From m.hotze at hotze.com Tue Aug 20 06:43:33 2013 From: m.hotze at hotze.com (Martin Hotze) Date: Tue, 20 Aug 2013 06:43:33 +0000 Subject: Trivium Message-ID: > Date: Mon, 19 Aug 2013 11:11:23 -0400 > From: "Patrick W. Gilmore" > Subject: Re: Trivium > > On Aug 19, 2013, at 10:42 , Blake Dunlap wrote: > > > Without Google, how do you know where anything even *is*? > > Pretending that wasn't a troll, I wonder how much of the traffic these > days is things like AppleTV, Roku, OS updates, iThing/Android 'Apps', etc. > that do not require a user to type "www.bing.com" into the Google search > box[*] so they can find the web page. we're running a wifi hotspot system with about 1,000 users daily. The top 10 domains on the firewall stats (content filter) are apple and f*cebook domains. So when you plan filtering out apple and/or f*cebook you might also shut down the hotspot, because for most users the 'net' then seems to be br0ken. > [*] I've actually see someone type "www.yahoo.com" into the Google search > box, then use Yahoo! to search for something. Don't ask.... "Never type google into google because you can break the Internet!" http://www.youtube.com/watch?v=OqxLmLUT-qc ^^^^^^^^^^^ damn, another google domain ... :-) #m From mmg at transtelco.net Tue Aug 20 06:00:35 2013 From: mmg at transtelco.net (=?ISO-8859-1?Q?Manuel_Mar=EDn?=) Date: Tue, 20 Aug 2013 00:00:35 -0600 Subject: Typical warranty for generic DWDM transceivers Message-ID: Dear nanog group We are currently evaluating the use of generic third party optics (SFP+ and XFP) for 40Kms and 80Kms applications from vendors like NHR and Champion One and I was wondering if someone in the group has experience using optics from these vendors. My concern is about quality/reliability. They are suppose to provide lifetime warranty, however as far as I know the life time for DWDM optics is between 3 to 5 years. Could someone share their experience with using generic optics for DWDM applications? Thank you From eugen at imacandi.net Tue Aug 20 09:43:27 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Tue, 20 Aug 2013 12:43:27 +0300 Subject: will ISP peer with 2 local WAN routers? In-Reply-To: <01b601ce9aca$25715a20$70540e60$@webjogger.net> References: <014a01ce9ac0$1cab26a0$560173e0$@webjogger.net> <01a101ce9ac6$8c4d4780$a4e7d680$@webjogger.net> <520E99C6.9080803@alter3d.ca> <01b601ce9aca$25715a20$70540e60$@webjogger.net> Message-ID: A bit late to the discussion, but we use a stack of EX switches which terminate L2 connections from the providers and two routers which have BGP sessions with them. Each switch has ports provisioned so that in case one switch fails, we just simply move the ethernet cable to the working switch and everything is fine. Eugeniu On Sat, Aug 17, 2013 at 12:47 AM, Adam Greene wrote: > Pete, > > Good point, thanks. Yes, in this case, there is some cause to believe that > the switches will prove more reliable than the routers. They're older > 7200VXR's and have had some lockups in the past, possibly due to PA card / > IOS incompatibilities. > > But you're right, we are also considering accepting full or partial routes > from both providers, one provider per router, and then doing iBGP between > them to balance the load. We're thinking of deploying default routes and > HSRP to stacked 3750's for round-robin load balancing on the LAN side. > > Thanks for the help! > > Adam > > > -----Original Message----- > From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] > Sent: Friday, August 16, 2013 5:30 PM > To: nanog at nanog.org > Subject: Re: will ISP peer with 2 local WAN routers? > > But the switches themselves are a single point of failure, so if a switch > dies you still only have a single provider (assuming one switch per > provider). ;) > > All you're doing is moving the your single point of failure from the > routers > to the switches, with arguably very little increase in actual reliability > (if any, depending on whether you think switches are less likely to fail > than routers). > > - Pete > > > > On 08/16/2013 05:21 PM, Adam Greene wrote: > > Thanks, Justin. Yes, we considered that option, too. But then if one > > WAN router goes down, the customer will only have connectivity through > > a single upstream provider. We'd prefer to maintain connectivity to > > both even if a router fails. Switches in front of the routers is no > problem. > > > > -----Original Message----- > > From: Justin Vocke [mailto:justin.vocke at gmail.com] > > Sent: Friday, August 16, 2013 4:47 PM > > To: Adam Greene > > Cc: > > Subject: Re: will ISP peer with 2 local WAN routers? > > > > The gotcha with that is then you need a switch in front of the > > routers. I'd just setup a carrier on each router and run ibgp between. > > > > Sent from my iPhone > > > > On Aug 16, 2013, at 3:35 PM, "Adam Greene" > wrote: > > > >> Hi guys, > >> > >> > >> > >> I have a customer who peers via eBGP with Lightpath aka Cablevision > >> (AS > >> 6128) and Level3 (AS 3356) and wants to do some dual-WAN router > > redundancy. > >> > >> > >> I have heard that carriers will sometimes agree to set up a /29 WAN > >> subnet for a customer and peer with (2) customer routers. > >> > >> > >> > >> The customer is delaying on providing me with the proper circuit ID & > >> contact information to be able to call Lightpath and Level3 directly > >> and find out if they will do this, so I thought of asking this list. > >> > >> > >> > >> Is anyone aware if Lightpath and Level3 will agree to something like > this? > >> > >> > >> Thanks, > >> > >> Adam > >> > >> > >> > >> > >> > > > > > > > From nick at foobar.org Tue Aug 20 09:56:55 2013 From: nick at foobar.org (Nick Hilliard) Date: Tue, 20 Aug 2013 10:56:55 +0100 Subject: Typical warranty for generic DWDM transceivers In-Reply-To: References: Message-ID: <52133D67.8030107@foobar.org> On 20/08/2013 07:00, Manuel Mar?n wrote: > Could someone share their experience with using generic optics for DWDM > applications? Not sure what you mean by "generic optics"? If you mean manufactured by Joe's Optics and Fishing Bait company and sold on ebay for special low rates, then the question is: are you in a position to test these units in advance to the extent that you're going to be happy with their reliability? Otherwise why are you trusting your entire business to this? Personally, I'm not in that position, so I buy third party transceivers from a respectable vendor with good quality service. This works very well for me. Cheaper transceivers are only cheaper when you take their lifetime cost into account. If they have quality issues, or cause more downtime, or require more amplification, or cause mobo overheating issues due to poor thermal characteristics, or if you need to spend a lot of time testing and characterising the transceivers before deployment, then they are probably not going to be cheaper. I could buy these transceivers on ebay, but I don't want the hassle of having to deal with links flopping offline and transceivers burning out regularly. No doubt plenty of cheap white-label vendors are completely fine, but I'm not going to invest my time/money or anyone else's time/money in trying to find out which, because for my requirements it's cheaper to do this than to use ebay. Nick From saku at ytti.fi Tue Aug 20 09:58:43 2013 From: saku at ytti.fi (Saku Ytti) Date: Tue, 20 Aug 2013 12:58:43 +0300 Subject: Typical warranty for generic DWDM transceivers In-Reply-To: References: Message-ID: <20130820095843.GA12618@pob.ytti.fi> On (2013-08-20 00:00 -0600), Manuel Mar?n wrote: > We are currently evaluating the use of generic third party optics (SFP+ and > XFP) for 40Kms and 80Kms applications from vendors like NHR and Champion > One and I was wondering if someone in the group has experience using optics Neither of these build anything, just resell. When going 3rd party you might want to make sure you know a) who builds the lasers b) who builds the microcontroller c) which software release there is in the microcontroller d) exhaustive spec sheet for each part, not just 'n km' but dispersion tolerance, temperature range, minimum/maximum light levels etc, spread (especially in DWDM) And you might want to ensure in your contract that as long as you are using given SKU to order part, you are always getting the same equipment. If you do run into trouble, then you will know exactly which parts are affected. Many brokers shop around and when you order part it's always something different. Now 99% of them will still work, regardless how badly you handle your procurement. > from these vendors. My concern is about quality/reliability. They are > suppose to provide lifetime warranty, however as far as I know the life > time for DWDM optics is between 3 to 5 years. We've been rocking DWDM core since 2006 and I can't recall losing single XENPAK. We just this year migrated to new core using flexoptix (eoptolink) 10G DWDM XFP. I had no trouble finding buyer to those 7 year old DWDM XENPAKs. > Could someone share their experience with using generic optics for DWDM > applications? Positive. I actually prefer 3rd party, especially flexoptix, because they provide us very simply to use eeprommer so we can save in sparing and can deliver customers optics on very short notice, which their equipment will experience as original part. With 1st party I'd need to have part for each vendor we use, and each part customer might use, essentially everything. And even more importantly, 1st party often does not sell at all optic I might need, like CWDM or BX. -- ++ytti From jabley at hopcount.ca Tue Aug 20 12:52:04 2013 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 20 Aug 2013 08:52:04 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: Message-ID: Hi Randy, On 2013-08-20, at 01:05, Randy Bush wrote: >> As you may know CIRA has been working with groups across Canada to >> establish new IXPs. > > wow! i thought there were a lot of ixps, torix, vantx, ... The TorIX has been the most significant exchange point with growth and traffic for some years. I hear the QIX in Montr?al (pre-CIRA) was active, but I know less about that one since I've never had occasion to connect and use it. Other exchange points have existed (or still exist) in Halifax, London, Edmonton and Ottawa but have struggled to attract interest despite enthusiastic and well-meaning activism on the part of individuals. I always had the impression that the BCIX in Vancouver was mainly a cooperative transit purchasing arrangement between academic institutions, and that all commercial peering on the west coast of Canada really took place in Seattle. Again, I have no direct experience however. What CIRA is doing is providing support in the areas where previous efforts have struggled, providing hardware, accounts payable, legal, help with incorporation and forming sensible bylaws and stimulating local discussion and interest. My perspective is that they have done a great job in Calgary and Montr?al. It sounds like the approach in Vancouver (engage with existing efforts, see where CIRA can help) is following the same path. > are these open, neutral, ixps, a la six etc? or big players trying to > save the internet from itself? I think they are as open and neutral as the local ISP communities want, and that CIRA is not dictating terms but rather enabling locals to do what they think is best for themselves. Open, Neutral, ? la SIX (et ? la TorIX) is what people seem to want. I think the work CIRA is doing here is sensible, pragmatic, sensitive and useful. A good use of my .CA domain registration fees. It'd be nice to hear more about their experiences in Phoenix, if there is a suitable slot available on the programme. Joe From bross at pobox.com Tue Aug 20 13:04:41 2013 From: bross at pobox.com (Brandon Ross) Date: Tue, 20 Aug 2013 09:04:41 -0400 (EDT) Subject: Typical warranty for generic DWDM transceivers In-Reply-To: References: Message-ID: On Tue, 20 Aug 2013, Manuel Mar?n wrote: > We are currently evaluating the use of generic third party optics (SFP+ and > XFP) for 40Kms and 80Kms applications from vendors like NHR and Champion > One and I was wondering if someone in the group has experience using optics > from these vendors. I am biased. My wife sells 3rd party optics at SubSpace Communications, but I think our data is valuable. She has sold many thousands of optics, all with lifetime warrantys. Many of them to very large and clueful organizations, many of whom are represented here on NANOG. Of those thousands sold, I can count less than 20 that have been returned. I've also worked for VARs in the past, and work with several of them today, selling new OEM branded optics. I've found a MUCH higher percentage of OEM optics having to be returned to the manufacturer. Of course, take my report with a grain of salt. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From randy at psg.com Tue Aug 20 13:05:46 2013 From: randy at psg.com (Randy Bush) Date: Tue, 20 Aug 2013 22:05:46 +0900 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <8704746153974412639@unknownmsgid> References: Message-ID: > are these open, neutral, ixps, a la six etc? or big players trying to > save the internet from itself? > > would some of the *local* providers in the areas who actually use the > cira ixen care to report on the experience? ok, i have heard privately from folk who i respect. cira seems to be on the up and up and doing good professional work. randy From jra at baylink.com Tue Aug 20 13:35:06 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 20 Aug 2013 09:35:06 -0400 (EDT) Subject: Typical warranty for generic DWDM transceivers In-Reply-To: Message-ID: <13820259.4304.1377005706491.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brandon Ross" > She has sold many thousands of optics, all with lifetime warrantys. > Many of them to very large and clueful organizations, many of whom are > represented here on NANOG. Of those thousands sold, I can count less > than 20 that have been returned. > > I've also worked for VARs in the past, and work with several of > them today, selling new OEM branded optics. I've found a MUCH higher > percentage of OEM optics having to be returned to the manufacturer. > > Of course, take my report with a grain of salt. Not at all: No one is gonna stop buying Cisco cause a Cisco optic died. Third-party manufacturers don't have that built in cushion, so it's not unreasonable that they might pay the higher degree of attention to reliability that your off-the-cuff statistics imply. You do want to go third-party, though, not fourth-party or below. :-) 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 clayton at MNSi.Net Tue Aug 20 13:49:18 2013 From: clayton at MNSi.Net (Clayton Zekelman) Date: Tue, 20 Aug 2013 09:49:18 -0400 Subject: Typical warranty for generic DWDM transceivers In-Reply-To: <13820259.4304.1377005706491.JavaMail.root@benjamin.baylink .com> References: <13820259.4304.1377005706491.JavaMail.root@benjamin.baylink.com> Message-ID: <1377006561_230822@duplo.mnsi.net> FWIW, I've never had an issue with third party optics. Particularly if they're OEM Finisar, JDSU, etc... At 09:35 AM 20/08/2013, Jay Ashworth wrote: >----- Original Message ----- > > From: "Brandon Ross" > > > > She has sold many thousands of optics, all with lifetime warrantys. > > Many of them to very large and clueful organizations, many of whom are > > represented here on NANOG. Of those thousands sold, I can count less > > than 20 that have been returned. > > > > I've also worked for VARs in the past, and work with several of > > them today, selling new OEM branded optics. I've found a MUCH higher > > percentage of OEM optics having to be returned to the manufacturer. > > > > Of course, take my report with a grain of salt. > >Not at all: No one is gonna stop buying Cisco cause a Cisco optic died. > >Third-party manufacturers don't have that built in cushion, so it's not >unreasonable that they might pay the higher degree of attention to >reliability that your off-the-cuff statistics imply. > >You do want to go third-party, though, not fourth-party or below. :-) > >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 --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From chk at pobox.com Tue Aug 20 13:52:54 2013 From: chk at pobox.com (Harald Koch) Date: Tue, 20 Aug 2013 09:52:54 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <8704746153974412639@unknownmsgid> Message-ID: On 20 August 2013 09:05, Randy Bush wrote: > > ok, i have heard privately from folk who i respect. cira seems to be on > the up and up and doing good professional work. > haha. yes, because Canadians are normally so sinister and nefarious... From tdurack at gmail.com Tue Aug 20 14:01:03 2013 From: tdurack at gmail.com (Tim Durack) Date: Tue, 20 Aug 2013 10:01:03 -0400 Subject: Typical warranty for generic DWDM transceivers In-Reply-To: <1377006561_230822@duplo.mnsi.net> References: <13820259.4304.1377005706491.JavaMail.root@benjamin.baylink.com> <1377006561_230822@duplo.mnsi.net> Message-ID: The vendor-locked optics issue cause more trouble than it is worth. There really needs to be some kind of "aftermarket" ruling on network equipment, something along the lines of: http://en.wikipedia.org/wiki/Aftermarket_(automotive) Tim:> On Tue, Aug 20, 2013 at 9:49 AM, Clayton Zekelman wrote: > > > FWIW, I've never had an issue with third party optics. > > Particularly if they're OEM Finisar, JDSU, etc... > > > At 09:35 AM 20/08/2013, Jay Ashworth wrote: > >> ----- Original Message ----- >> > From: "Brandon Ross" >> >> >> > She has sold many thousands of optics, all with lifetime warrantys. >> > Many of them to very large and clueful organizations, many of whom are >> > represented here on NANOG. Of those thousands sold, I can count less >> > than 20 that have been returned. >> > >> > I've also worked for VARs in the past, and work with several of >> > them today, selling new OEM branded optics. I've found a MUCH higher >> > percentage of OEM optics having to be returned to the manufacturer. >> > >> > Of course, take my report with a grain of salt. >> >> Not at all: No one is gonna stop buying Cisco cause a Cisco optic died. >> >> Third-party manufacturers don't have that built in cushion, so it's not >> unreasonable that they might pay the higher degree of attention to >> reliability that your off-the-cuff statistics imply. >> >> You do want to go third-party, though, not fourth-party or below. :-) >> >> 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 >> > > --- > > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 3363 Tecumseh Rd. E > Windsor, Ontario > N8W 1H4 > > tel. 519-985-8410 > fax. 519-985-8409 > > -- Tim:> From alter3d at alter3d.ca Tue Aug 20 15:12:21 2013 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 20 Aug 2013 11:12:21 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <8704746153974412639@unknownmsgid> Message-ID: <52138755.8070607@alter3d.ca> On 08/20/2013 09:52 AM, Harald Koch wrote: > On 20 August 2013 09:05, Randy Bush wrote: > >> ok, i have heard privately from folk who i respect. cira seems to be on >> the up and up and doing good professional work. >> > haha. yes, because Canadians are normally so sinister and nefarious... Hey, we're nefarious. Our plan to take control the world supply of poutine is well under way! First, delicious and fattening food. Next: the world! *cue evil laugh* - Pete From morrowc.lists at gmail.com Tue Aug 20 15:23:21 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 20 Aug 2013 11:23:21 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <8704746153974412639@unknownmsgid> Message-ID: On Tue, Aug 20, 2013 at 9:52 AM, Harald Koch wrote: > On 20 August 2013 09:05, Randy Bush wrote: > >> >> ok, i have heard privately from folk who i respect. cira seems to be on >> the up and up and doing good professional work. >> > > haha. yes, because Canadians are normally so sinister and nefarious... they do seem to protest a lot... based on what i see on the news: From bzs at world.std.com Tue Aug 20 18:36:07 2013 From: bzs at world.std.com (Barry Shein) Date: Tue, 20 Aug 2013 14:36:07 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <52138755.8070607@alter3d.ca> References: <8704746153974412639@unknownmsgid> <52138755.8070607@alter3d.ca> Message-ID: <21011.46871.244833.881503@world.std.com> On August 20, 2013 at 11:12 alter3d at alter3d.ca (Peter Kristolaitis) wrote: > On 08/20/2013 09:52 AM, Harald Koch wrote: > > On 20 August 2013 09:05, Randy Bush wrote: > > > >> ok, i have heard privately from folk who i respect. cira seems to be on > >> the up and up and doing good professional work. > >> > > haha. yes, because Canadians are normally so sinister and nefarious... > Hey, we're nefarious. Our plan to take control the world supply of > poutine is well under way! > > First, delicious and fattening food. Next: the world! *cue evil laugh* US Senator Ted Cruz just renounced his Canadian (dual w/ US) citizenship. I'm just saying. My take on Canada? Quiet...too quiet... -- -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 clayton at MNSi.Net Tue Aug 20 18:39:38 2013 From: clayton at MNSi.Net (Clayton Zekelman) Date: Tue, 20 Aug 2013 14:39:38 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <21011.46871.244833.881503@world.std.com> References: <8704746153974412639@unknownmsgid> <52138755.8070607@alter3d.ca> <21011.46871.244833.881503@world.std.com> Message-ID: <1377023981_234798@duplo.mnsi.net> At 02:36 PM 20/08/2013, Barry Shein wrote: >US Senator Ted Cruz just renounced his Canadian (dual w/ US) >citizenship. > >I'm just saying. > >My take on Canada? Quiet...too quiet... So we can count him with the likes of Conrad Black? :D >-- > -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* --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From jared at puck.nether.net Tue Aug 20 20:26:20 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 20 Aug 2013 16:26:20 -0400 Subject: Typical warranty for generic DWDM transceivers In-Reply-To: References: <13820259.4304.1377005706491.JavaMail.root@benjamin.baylink.com> <1377006561_230822@duplo.mnsi.net> Message-ID: <8591EA97-ECC0-4DFF-8598-E21A6CDC34D5@puck.nether.net> On Aug 20, 2013, at 10:01 AM, Tim Durack wrote: > The vendor-locked optics issue cause more trouble than it is worth. There > really needs to be some kind of "aftermarket" ruling on network equipment, > something along the lines of: I've had interoperability issues with first party optics with first party equipment that isn't seen with 3rd party. I do wish more people would put pressure on their vendors on this topic. Simple text in your RFP/RFI requiring all SFF-8472 fields to be usable, sticking their "stuff" in their part of the EEPROM, but basing operations on the MSA fields not their own elements. - jared From jonathan.stewart at gmail.com Tue Aug 20 20:42:23 2013 From: jonathan.stewart at gmail.com (Jonathan Stewart) Date: Tue, 20 Aug 2013 15:42:23 -0500 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: Message-ID: On Tue, Aug 20, 2013 at 12:05 AM, Randy Bush wrote: > > As you may know CIRA has been working with groups across Canada to > > establish new IXPs. > > wow! i thought there were a lot of ixps, torix, vantx, ... > Canada is geographically enormous. Long-haul transit is therefore costly, and controlled by few big players. Not good for local ISPs. You named 2 IXPs, and only got one right. A year ago, there were two active: TORIX in Toronto, and OTTIX in Ottawa. Ottawa is too close to Toronto to have an impact, so OTTIX has remained small. Having only 2 open IXPs, 400 km apart in a country 5000 km wide is not good enough. Since then, QIX in Montreal has opened up from a research-only IXP, to a neutral peering facility. MBIX in Winnipeg has started, and YYCIX in Calgary is up and running as well. Vancouver is still lacking. are these open, neutral, ixps, a la six etc? or big players trying to > save the internet from itself? > I can speak for MBIX in Winnipeg, I'm part of the group working to get it fully operational. We are open, neutral. Any AS can become a member, and we are run openly by a board, elected by the members of the exchange. We have route servers, and direct peering is permitted as well. Costs are yearly, per-member, and low: $1200/yr. CIRA's donations have been pivotal in kickstarting this exchange with low cash costs. A couple of local ISPs have also donated to got this project started. Currently, the aforementioned established big players are not at all interested in our exchange, they don't talk to us. Only exception is Hurricane Electric, who recently joined, dropping wholesale bandwidth costs in Winnipeg *dramatically*. would some of the *local* providers in the areas who actually use the > cira ixen care to report on the experience? > I don't count as an operator, but so far, the connected members are learning much more about BGP and traffic flows, and interconnecting in ways never before possible in Winnipeg. BTW, in Winnipeg we still have the problem of cross-continent traffic paths to send data across the street. Worst case is something like this: Winnipeg--Chicago--Toronto--Vancouver--Calgary--Winnipeg. That's a 15,000 km round trip. MBIX can help with that. Our website for the curious:http://www.mbix.ca/ -- Jonathan From bottiger10 at gmail.com Tue Aug 20 20:54:52 2013 From: bottiger10 at gmail.com (bottiger) Date: Tue, 20 Aug 2013 13:54:52 -0700 Subject: Contact for Hetzner AS24940 and Host Europe AS20773? Message-ID: Anyone know of any contacts for Hetzner AS24940 and Host Europe AS20773? Thanks in advance. From arnold at nipper.de Tue Aug 20 21:18:07 2013 From: arnold at nipper.de (Arnold Nipper) Date: Tue, 20 Aug 2013 23:18:07 +0200 Subject: Contact for Hetzner AS24940 and Host Europe AS20773? In-Reply-To: References: Message-ID: <5213DD0F.4050205@nipper.de> On 20.08.2013 22:54, bottiger wrote: > Anyone know of any contacts for Hetzner AS24940 and Host Europe AS20773? > whois -h whois.peeringdb.com AS24940 | grep ^Technical Technical NOC noc at hetzner.de +49 911 234226 0 whois -h whois.peeringdb.com AS20773 | grep ^Technical Technical Malte von dem Hagen mvh at hosteurope.de Technical Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From christopher.morrell.nanog at gmail.com Wed Aug 21 03:02:06 2013 From: christopher.morrell.nanog at gmail.com (Christopher Morrell) Date: Tue, 20 Aug 2013 23:02:06 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: Message-ID: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> The old generation QIX (in Montreal) has been around a long time as an IXP where commercial players have been present. It was managed and operated by RISQ (a research network) but most of the members were commercial. The new generation of QIX is managed much like TorIX and continues to be operated by RISQ. There really isn't much new about the QIX other than how it is managed. It has always welcomed commercial players. In Winnipeg, isn't there also the WPGIX? Do you have two competing IXPs in Winnipeg? On 2013-08-20, at 16:42, Jonathan Stewart wrote: > On Tue, Aug 20, 2013 at 12:05 AM, Randy Bush wrote: > >>> As you may know CIRA has been working with groups across Canada to >>> establish new IXPs. >> >> wow! i thought there were a lot of ixps, torix, vantx, ... > Canada is geographically enormous. Long-haul transit is therefore costly, > and controlled by few big players. Not good for local ISPs. > > You named 2 IXPs, and only got one right. A year ago, there were two > active: TORIX in Toronto, and OTTIX in Ottawa. Ottawa is too close to > Toronto to have an impact, so OTTIX has remained small. Having only 2 open > IXPs, 400 km apart in a country 5000 km wide is not good enough. > > Since then, QIX in Montreal has opened up from a research-only IXP, to a > neutral peering facility. MBIX in Winnipeg has started, and YYCIX in > Calgary is up and running as well. Vancouver is still lacking. > > are these open, neutral, ixps, a la six etc? or big players trying to >> save the internet from itself? > I can speak for MBIX in Winnipeg, I'm part of the group working to get it > fully operational. > > We are open, neutral. Any AS can become a member, and we are run openly by > a board, elected by the members of the exchange. > > We have route servers, and direct peering is permitted as well. Costs are > yearly, per-member, and low: $1200/yr. CIRA's donations have been pivotal > in kickstarting this exchange with low cash costs. A couple of local ISPs > have also donated to got this project started. > > Currently, the aforementioned established big players are not at all > interested in our exchange, they don't talk to us. Only exception is > Hurricane Electric, who recently joined, dropping wholesale bandwidth costs > in Winnipeg *dramatically*. > > would some of the *local* providers in the areas who actually use the >> cira ixen care to report on the experience? > I don't count as an operator, but so far, the connected members are > learning much more about BGP and traffic flows, and interconnecting in ways > never before possible in Winnipeg. > > BTW, in Winnipeg we still have the problem of cross-continent traffic paths > to send data across the street. Worst case is something like this: > Winnipeg--Chicago--Toronto--Vancouver--Calgary--Winnipeg. That's a 15,000 > km round trip. MBIX can help with that. > > Our website for the curious:http://www.mbix.ca/ > > -- > Jonathan From woody at pch.net Wed Aug 21 03:14:10 2013 From: woody at pch.net (Bill Woodcock) Date: Tue, 20 Aug 2013 20:14:10 -0700 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> Message-ID: <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> On Aug 20, 2013, at 8:02 PM, Christopher Morrell wrote: > In Winnipeg, isn't there also the WPGIX? Do you have two competing IXPs in Winnipeg? There are nominally competing efforts in Winnipeg (MBIX and WPGIX), Calgary (YYCIX and AlbertaIX), Montreal (QIX and Peer1), Vancouver (BCIX and Peer1), and even Toronto (TorIX, Peer1, CANIX, and IIX). I would not characterize more than one of those in each city as a going concern, however. https://pch.net/ixpdir -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From christopher.morrell.nanog at gmail.com Wed Aug 21 10:38:47 2013 From: christopher.morrell.nanog at gmail.com (Christopher Morrell) Date: Wed, 21 Aug 2013 06:38:47 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> Message-ID: <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> I think CANIX in Toronto has been dead for years. I used to operate the switch for it in my days at UUNET in the 90s. In Montreal, is anyone at the Peer1 exchange other than Peer1? On 2013-08-20, at 23:14, Bill Woodcock wrote: > > On Aug 20, 2013, at 8:02 PM, Christopher Morrell wrote: >> In Winnipeg, isn't there also the WPGIX? Do you have two competing IXPs in Winnipeg? > > There are nominally competing efforts in Winnipeg (MBIX and WPGIX), Calgary (YYCIX and AlbertaIX), Montreal (QIX and Peer1), Vancouver (BCIX and Peer1), and even Toronto (TorIX, Peer1, CANIX, and IIX). > > I would not characterize more than one of those in each city as a going concern, however. > > https://pch.net/ixpdir > > -Bill > > > > From jabley at hopcount.ca Wed Aug 21 10:52:34 2013 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 21 Aug 2013 06:52:34 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> Message-ID: <-5109713474780003274@unknownmsgid> On 2013-08-21, at 6:40, Christopher Morrell wrote: > I think CANIX in Toronto has been dead for years. I used to operate the switch for it in my days at UUNET in the 90s. Yes, very dead. > In Montreal, is anyone at the Peer1 exchange other than Peer1? Peer1 exchanges are only open to Peer1 customers, I believe. At least, that's how it worked in Toronto the last time I looked. Joe From randy at psg.com Wed Aug 21 10:57:03 2013 From: randy at psg.com (Randy Bush) Date: Wed, 21 Aug 2013 19:57:03 +0900 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <-5109713474780003274@unknownmsgid> References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> Message-ID: >> In Montreal, is anyone at the Peer1 exchange other than Peer1? > Peer1 exchanges are only open to Peer1 customers, I believe. At least, > that's how it worked in Toronto the last time I looked. that is not an exchange. most isps have switches in their transit infrastructure. randy From wmaton at ottix.net Wed Aug 21 11:28:27 2013 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Wed, 21 Aug 2013 07:28:27 -0400 (EDT) Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: Message-ID: On Tue, 20 Aug 2013, Jonathan Stewart wrote: > You named 2 IXPs, and only got one right. A year ago, there were two > active: TORIX in Toronto, and OTTIX in Ottawa. Ottawa is too close to > Toronto to have an impact, so OTTIX has remained small. Having only 2 open That's not entirely accurate. The fact is the Ottawa market - as well as the Eastern Ontario market, had a large number of very small ISPs in the area a decade ago. So OttIX had many ISPs be litle traffic. After a major market conolidation (buyouts,m mergers, etc) the number of peers declined quite a bit - but the traffic increased. In the meantime, within the province of Ontario, LANX costs became effectively the same (to us) to go from one end of the city to the other as the cost to go between cities. Even at the $dayjob, we took advantage of this and simply dragged another LANX over to TorIX. Heck, even OttIX had a POP at 151 Fron in Toronto which saw enormous growth. So in that sense, OttIX achieved one of its primary objectives and that was to drive transit costs down in what is effectively a one-company town. > IXPs, 400 km apart in a country 5000 km wide is not good enough. 5000km in length by 100Km in width as most of the population lives within 100Km of the Canada-US border, but yes, it's a big country. > Since then, QIX in Montreal has opened up from a research-only IXP, to a > neutral peering facility. MBIX in Winnipeg has started, and YYCIX in > Calgary is up and running as well. Vancouver is still lacking. BCNet would beg to differ. :-) There's also VicTX in Victoria run by BCNet. (Granted, some might simply say those are nothing more than BCNet aggregation hubs - but judge for yourselves please.) > Currently, the aforementioned established big players are not at all > interested in our exchange, they don't talk to us. Only exception is > Hurricane Electric, who recently joined, dropping wholesale bandwidth costs > in Winnipeg *dramatically*. IXPs in Canada have been particularly effective in doing this, especially in Ottawa where in 2003 it was something like $550 per megabit/month. One of the OttIX members (IGS) offered $200 and well, a number of OttIX peers went to town with that. The rate grudgingly dropped to $333 by 2006 until $MGMT allowed me to break out in other places to leverage even lower pricing. As of 2011 the best price I could get here was $90 but we already got out of Dodge by then. All to say the effects of an IXP in a certain locale were positive for the end-consumers (ISPs mainly) of transit. > BTW, in Winnipeg we still have the problem of cross-continent traffic paths > to send data across the street. Worst case is something like this: > Winnipeg--Chicago--Toronto--Vancouver--Calgary--Winnipeg. That's a 15,000 > km round trip. MBIX can help with that. For a good view of the Canadian perspective on those and more, see: http://www.ixmaps.ca/index.php We've contributed a lot of traceroutes, ditto via $dayjob given the diverse footprint of the network (national research backbone - not CANARIE's though) just to see how our traffic runs about the country as well as outside. Some surprises there. (I think CIRA funded that one as well.) wfms From jacques.latour at cira.ca Wed Aug 21 03:43:44 2013 From: jacques.latour at cira.ca (Jacques Latour) Date: Tue, 20 Aug 2013 23:43:44 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com>, <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> Message-ID: The main reason we are collecting feedback for Vancouver is that both VANTX and PIX are not member based IXP organizations, VANTX is owned and operated by BCnet, a R&E organization, and PIX is owned and operated by Peer1. We heard from a few people in Vancouver that they would like to have a true open, neutral and member based IXP, the idea for the town hall meeting is to build the community around a Vancouver IXP. BCnet has a good story to tell about VANTX, community support and IXPs across the province. If you care about Vancouver, then let us know. I'll see what I can do about the poutine :-) ________________________________________ From: Bill Woodcock [woody at pch.net] Sent: August 20, 2013 11:14 PM To: North American Network Operators' Group Subject: Re: Vancouver IXP - VanTX - BCNet On Aug 20, 2013, at 8:02 PM, Christopher Morrell wrote: > In Winnipeg, isn't there also the WPGIX? Do you have two competing IXPs in Winnipeg? There are nominally competing efforts in Winnipeg (MBIX and WPGIX), Calgary (YYCIX and AlbertaIX), Montreal (QIX and Peer1), Vancouver (BCIX and Peer1), and even Toronto (TorIX, Peer1, CANIX, and IIX). I would not characterize more than one of those in each city as a going concern, however. https://pch.net/ixpdir -Bill From woody at pch.net Wed Aug 21 13:50:23 2013 From: woody at pch.net (Bill Woodcock) Date: Wed, 21 Aug 2013 06:50:23 -0700 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> Message-ID: <48300247-6033-47C4-B5C4-C344D6CDD6FA@pch.net> On Aug 21, 2013, at 3:57 AM, Randy Bush wrote: >>> In Montreal, is anyone at the Peer1 exchange other than Peer1? >> Peer1 exchanges are only open to Peer1 customers, I believe. At least, >> that's how it worked in Toronto the last time I looked. > > that is not an exchange. most isps have switches in their transit > infrastructure. Correct. The ones in black are exchanges, the ones in gray are things that someone asserted to have been exchanges, or asserted will be exchanges. https://pch.net/ixpdir North America Canada (6) Calgary Calgary Internet Exchange 5 2013 Montreal Quebec Internet Exchange 8 Jan 2013 Ottawa Ottawa Internet Exchange 13 432M 10 Apr 2001 Toronto Toronto Internet Exchange 156 112G 1998 Winnipeg Manitoba Internet Exchange 8 126M 29 Jul 2013 Winnipeg Winnipeg Internet Exchange 5 May 2013 Calgary AlbertaIX Edmonton Edmonton Internet Exchange Montreal Peer1 Internet Exchange - Montreal 2010 Montreal Quebec Internet Exchange/RISQ Toronto CANIX Toronto Greater Toronto International Internet Exchange Jun 2011 Toronto Peer1 Internet Exchange - Toronto 2008 Vancouver British Columbia Internet Exchange Vancouver Peer1 Internet Exchange - Vancouver 2008 Victoria Victoria Transit Exchange -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Wed Aug 21 13:56:07 2013 From: randy at psg.com (Randy Bush) Date: Wed, 21 Aug 2013 22:56:07 +0900 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <48300247-6033-47C4-B5C4-C344D6CDD6FA@pch.net> References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <48300247-6033-47C4-B5C4-C344D6CDD6FA@pch.net> Message-ID: > Correct. The ones in black are exchanges, the ones in gray are things > that someone asserted to have been exchanges, or asserted will be > exchanges. glad it's all so black and white, well grey. :) as i use an old fashioned mail reader, it's all (set-foreground-color "navajo white") to me. but how do you represent seattle colonolizing bc? randy From joelja at bogus.com Wed Aug 21 14:06:20 2013 From: joelja at bogus.com (joel jaeggli) Date: Wed, 21 Aug 2013 07:06:20 -0700 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <48300247-6033-47C4-B5C4-C344D6CDD6FA@pch.net> Message-ID: <5214C95C.50301@bogus.com> On 8/21/13 6:56 AM, Randy Bush wrote: > > but how do you represent seattle colonolizing bc? "keep your potatoes out of my pig." http://en.wikipedia.org/wiki/Pig_War > > randy > From wmaton at ottix.net Wed Aug 21 14:21:13 2013 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Wed, 21 Aug 2013 10:21:13 -0400 (EDT) Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> Message-ID: On Wed, 21 Aug 2013, Randy Bush wrote: >>> In Montreal, is anyone at the Peer1 exchange other than Peer1? >> Peer1 exchanges are only open to Peer1 customers, I believe. At least, >> that's how it worked in Toronto the last time I looked. > > that is not an exchange. most isps have switches in their transit > infrastructure. +1 The Peer1 setups remind me very much of what Group Telecom (defunct Canadian backbone provider) did in the very late 90's and the very early part of the last decade. They had them in nearly every city they had their facilities, but the GT IXPs never caught on ($$$ to get inside the facility and they played hard ball against incumbant access effectively making them closed unless direct GT customers.) wfms From woody at pch.net Wed Aug 21 14:32:41 2013 From: woody at pch.net (Bill Woodcock) Date: Wed, 21 Aug 2013 07:32:41 -0700 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <48300247-6033-47C4-B5C4-C344D6CDD6FA@pch.net> Message-ID: <249E24C3-302B-4963-A3D9-55D46EC921FF@pch.net> On Aug 21, 2013, at 6:56 AM, Randy Bush wrote: >> Correct. The ones in black are exchanges, the ones in gray are things >> that someone asserted to have been exchanges, or asserted will be >> exchanges. > > glad it's all so black and white, well grey. :) When different people are asserting different things (i.e. that something is, and is not, an IXP) the situation is, by definition, contentious. We move things into the "definitely an exchange" and show it in black text when we're able to observe a number of things: - Three or more participants - Shared layer-2 switch fabric across which participants peer with each other, exchanging customer routes - New participation is not too rigorously constrained (at least a domestic ISP new market entrant should be able to participate) - Participants do not receive a metered-rate bill based on utilization In addition, we look for a number of signs of openness and transparency that would indicate that it's intended to be a good-faith effort to provide a point of interconnection between interested parties, rather than a regulatory compliance function, a set of private crossconnects that don't facilitation connection of new participants, a transit buyers' club, or a commercial layer-1/2 WAN carrier trying to re-brand their services. Which are, I would say, the four most common things that attempt to brand themselves as IXPs in disagreement with the general consensus that we observe. New IXP founders typically contact our staff early in the formation process, and we collect the information above through conversations with participants, direct participation in the exchange, and on-site visits. The weak point in this process is that when IXPs go defunct, we're often lacking a clear date of dissolution in our records, because they tend to fade away gradually, with very little public notice. Whenever anyone notices such a discrepancy, we very much appreciate their bringing it to our attention, so we can make the directory more accurate. > but how do you represent seattle colonolizing bc? If, by that, you mean Canadian ISPs peering in Seattle, you'd see that in the participant list... https://prefix.pch.net/applications/ixpdir/detail.php?exchange_point_id=345 https://www.seattleix.net/participants.htm ?and in theory the map here... https://prefix.pch.net/images/applications/ixpdir/origin_country_worldmap/345.png ?should be showing the Canadian participation visually, but the fact that it's not, at the moment, is indicating a data coding error on our ARIN whois import, which I'll have our guys take a look at. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From clayton at MNSi.Net Wed Aug 21 14:38:37 2013 From: clayton at MNSi.Net (Clayton Zekelman) Date: Wed, 21 Aug 2013 10:38:37 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> Message-ID: <1377095998_244645@duplo.mnsi.net> At 10:21 AM 21/08/2013, William F. Maton Sotomayor wrote >The Peer1 setups remind me very much of what Group Telecom (defunct >Canadian backbone provider) did in the very late 90's and the very >early part of the last decade. They had them in nearly every city >they had their facilities, but the GT IXPs never caught on ($$$ to >get inside the facility and they played hard ball against incumbant >access effectively making them closed unless direct GT customers.) > >wfms Just wondering aloud if an ISP that did have commercial interest could run a non-member driven exchange point successfully as long as they had pricing and policies that were similar to member driven exchange points. I have a facility in Windsor, Ontario that is well connected, has all the physical infrastructure necessary, the ability to provide relatively low cost local fibre loops, has an open policy towards other carriers providing transport loops, but alas, it wouldn't be perceived as "neutral". I would suggest that member driven exchanges typically produce the end product that people are interested in. Honestly, if TorIX wasn't member driven, but had the same policies as it does now, I'd still want to connect. Community of interest of course is the other magical ingredient that is necessary. Not sure how many ISPs would want to peer in Windsor... --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From randy at psg.com Wed Aug 21 14:52:12 2013 From: randy at psg.com (Randy Bush) Date: Wed, 21 Aug 2013 23:52:12 +0900 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <249E24C3-302B-4963-A3D9-55D46EC921FF@pch.net> References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <48300247-6033-47C4-B5C4-C344D6CDD6FA@pch.net> <249E24C3-302B-4963-A3D9-55D46EC921FF@pch.net> Message-ID: > New IXP founders typically contact our staff wow! i did not know we had the ixp god here! lemme go back to my camera-ready dreadline. :) > - Three or more participants > - Shared layer-2 switch fabric across which participants peer with > each other, exchanging customer routes > - New participation is not too rigorously constrained (at least a > domestic ISP new market entrant should be able to participate) imiho, it is also nice if non-isp folk can participate, content, etc. > - Participants do not receive a metered-rate bill based on utilization that's a new one. i am not sure i understand why. just seems a finer grained case of 100mb for $1, 1g for $5, and 10g for $20 or whatever. and i would add carrier neutrality, i can haul fiber from anyone into the exchange. this is pretty critical in the exchanges where i have played. randy From wmaton at ottix.net Wed Aug 21 16:10:32 2013 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Wed, 21 Aug 2013 12:10:32 -0400 (EDT) Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <1377095998_244645@duplo.mnsi.net> References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <1377095998_244645@duplo.mnsi.net> Message-ID: On Wed, 21 Aug 2013, Clayton Zekelman wrote: > Just wondering aloud if an ISP that did have commercial interest could run a > non-member driven exchange point successfully as long as they had pricing and > policies that were similar to member driven exchange points. Verrrry interesting that you raise that. IIRC, Albuquerque has NMIX which I think was setup as for-profit. (John Brown are you still here?) Well over a decade ago now, my recollection is fuzzy. I don't recall the reasoning in choosing for-profit over nont-for-profit. As for ISPs doing it, there are clear examples in the wild today, but. Many buts. That ISP would have to be quite benevolent. In the long run. New MGMT/owners and then.....? > I have a facility in Windsor, Ontario that is well connected, has all the > physical infrastructure necessary, the ability to provide relatively low cost > local fibre loops, has an open policy towards other carriers providing > transport loops, but alas, it wouldn't be perceived as "neutral". The only reason why we (OttIX) followed the path of not-for-porfit (and all that it comes with, from beloved loons to passionate supporters to the somewhat silent majority) was to give the community of interest (gawd what a PC-style phrase) assurance that the IXP would not be held hostage to a bottom-line or to the dictates of the single owner. In other words, neutral. (Now going for-profit could have been tempered with issuing one share per peer and having share-holders, etc, but we're starting to delve into philosophical viewpoints which in turn have consequences, advantages and disadvantages too numerous to get into here.) > Community of interest of course is the other magical ingredient that is > necessary. Not sure how many ISPs would want to peer in Windsor... If I were looking strictly at bottomline and had the same cost option between connecting to an IX in Ottawa/Windsor as going to Toronto, I'd go to Toronto. $dayjob was public sector: We believed the more we peer with, the greater the benefit to public citizen (along being able to divide and conquer potential DDOS). Of course there are those who don't subscribe to that notion... so what do I know? But, do what we did, throw it out there and try it just to see if there's any interest Windsor. Get the packets flowing, forget the paperwork and managerial super-structure for now. Talk to CIRA, get them to listen to you, you listen to them. OttIX started with a Paradyne DSLAM as switch core and many peers coming in on $40/month xDSL lines, just to see if there was a point. That's one decade gone, already into another.... wfms From hannigan at gmail.com Wed Aug 21 16:16:44 2013 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 21 Aug 2013 12:16:44 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <48300247-6033-47C4-B5C4-C344D6CDD6FA@pch.net> <249E24C3-302B-4963-A3D9-55D46EC921FF@pch.net> Message-ID: On Wed, Aug 21, 2013 at 10:52 AM, Randy Bush wrote: > > New IXP founders typically contact our staff > > wow! i did not know we had the ixp god here! lemme go back to my > camera-ready dreadline. :) > > > - Three or more participants > > - Shared layer-2 switch fabric across which participants peer with > > each other, exchanging customer routes > > - New participation is not too rigorously constrained (at least a > > domestic ISP new market entrant should be able to participate) > > imiho, it is also nice if non-isp folk can participate, content, etc. > It provides for much more financial benefit for the participants if they can. Pulling that traffic off of the wire at a N:N ratio usually results in enough of a cost savings to be a win-win for both. > > > - Participants do not receive a metered-rate bill based on utilization > > that's a new one. i am not sure i understand why. just seems a finer > grained case of 100mb for $1, 1g for $5, and 10g for $20 or whatever. > I completely agree. > > and i would add carrier neutrality, i can haul fiber from anyone into > the exchange. this is pretty critical in the exchanges where i have > played. > > randy > > Exchanges boxed in by incumbents and monopolies should absolutely be contacting content sources directly (peering@) to determine if there is a way that they can participate in the community directly. In most cases I can definitively tell you that there is likely a way to resolve the business issues that are roadblocks for both parties and to return substantial benefit to the exchange and it's community. That train left the station a few years ago. See Curacao. Best Regards, -M< From josmon at rigozsaurus.com Wed Aug 21 16:47:01 2013 From: josmon at rigozsaurus.com (John Osmon) Date: Wed, 21 Aug 2013 10:47:01 -0600 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <1377095998_244645@duplo.mnsi.net> Message-ID: <20130821164700.GA28701@jeeves.rigozsaurus.com> On Wed, Aug 21, 2013 at 12:10:32PM -0400, William F. Maton Sotomayor wrote: > On Wed, 21 Aug 2013, Clayton Zekelman wrote: > > >Just wondering aloud if an ISP that did have commercial interest > >could run a non-member driven exchange point successfully as long > >as they had pricing and policies that were similar to member > >driven exchange points. > > Verrrry interesting that you raise that. > > IIRC, Albuquerque has NMIX which I think was setup as for-profit. > (John Brown are you still here?) Well over a decade ago now, my > recollection is fuzzy. I don't recall the reasoning in choosing > for-profit over nont-for-profit. NMIX was a group of NM ISPs on a shared router at (last of?) the local feeders into what was once WestNet in the NSF days. It had a local NNTP server and (I believe) a couple of other services. It was useful back in the days when you could plumb some T1s to an AGS+ and make people happy. Mr. Brown's attempt at an exchange (IXNM) lasted about 8 years, and can probably be counted as an example of failure for such a model. The political side overwhelmed any technical advantage in Albuquerque. While it never became an importan IX, from the outside it looked like it was a successful bandwidth co-op with several local ISPs buying from it and benefiting from the local connectivity. Perhaps others can make a go at it? ----------- IXNM Opening e-mail --------------------- Date: Tue, 28 Jan 2003 09:45:27 -0700 From: "John M. Brown" To: 'John Osmon' Subject: IXNM goes live Friday 30-Jan-03 ----------- IXNM Ending e-mail --------------------- Date: Sat, 13 Aug 2011 02:51:33 +0000 From: John Brown To: "1st-Mile-NM" <1st-mile-nm at mailman.dcn.org> Subject: [1st-mile-nm] IXNM End of an Era, death due to stupid politics. From wmaton at ottix.net Wed Aug 21 17:15:38 2013 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Wed, 21 Aug 2013 13:15:38 -0400 (EDT) Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <48300247-6033-47C4-B5C4-C344D6CDD6FA@pch.net> <249E24C3-302B-4963-A3D9-55D46EC921FF@pch.net> Message-ID: On Wed, 21 Aug 2013, Randy Bush wrote: > and i would add carrier neutrality, i can haul fiber from anyone into > the exchange. this is pretty critical in the exchanges where i have > played. Facility neutrality especially. If the IXP is inside a non-neutral DC, it and its peers are always under constant threat of being squeezed out or shutdown by any number of circumstances. If the co-lo business were separate from the facility business, it may be a better environment since the IXP could convince the facility to host it, which the co-lo business could then be attracted to. All depends on the circumstances and environment. wfms From bmanning at vacation.karoshi.com Wed Aug 21 17:15:36 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 21 Aug 2013 17:15:36 +0000 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <1377095998_244645@duplo.mnsi.net> Message-ID: <20130821171536.GA15476@vacation.karoshi.com.> On Wed, Aug 21, 2013 at 12:10:32PM -0400, William F. Maton Sotomayor wrote: > On Wed, 21 Aug 2013, Clayton Zekelman wrote: > > >Just wondering aloud if an ISP that did have commercial interest could run > >a non-member driven exchange point successfully as long as they had > >pricing and policies that were similar to member driven exchange points. > > Verrrry interesting that you raise that. > > IIRC, Albuquerque has NMIX which I think was setup as for-profit. (John > Brown are you still here?) Well over a decade ago now, my recollection is > fuzzy. I don't recall the reasoning in choosing for-profit over > nont-for-profit. [NMIX couldn't pay its bills so it lost a lot of support/clients] /bill > > wfms From jra at baylink.com Wed Aug 21 17:18:25 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 21 Aug 2013 13:18:25 -0400 (EDT) Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <249E24C3-302B-4963-A3D9-55D46EC921FF@pch.net> Message-ID: <6996918.4536.1377105505060.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Bill Woodcock" > On Aug 21, 2013, at 6:56 AM, Randy Bush wrote: > > >> Correct. The ones in black are exchanges, the ones in gray are > >> things > >> that someone asserted to have been exchanges, or asserted will be > >> exchanges. > > > > glad it's all so black and white, well grey. :) > > When different people are asserting different things (i.e. that > something is, and is not, an IXP) the situation is, by definition, > contentious. We move things into the "definitely an exchange" and show > it in black text when we're able to observe a number of things: Randy wasn't shooting at you about your definitions. He was shooting at you for assuming people people were reading a technical mailing list in a non-text format. It's all black to me, too. :-) 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 wmaton at ottix.net Wed Aug 21 17:27:07 2013 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Wed, 21 Aug 2013 13:27:07 -0400 (EDT) Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <20130821171536.GA15476@vacation.karoshi.com.> References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <1377095998_244645@duplo.mnsi.net> <20130821171536.GA15476@vacation.karoshi.com.> Message-ID: On Wed, 21 Aug 2013, bmanning at vacation.karoshi.com wrote: >> IIRC, Albuquerque has NMIX which I think was setup as for-profit. (John >> Brown are you still here?) Well over a decade ago now, my recollection is >> fuzzy. I don't recall the reasoning in choosing for-profit over >> nont-for-profit. > > [NMIX couldn't pay its bills so it lost a lot of support/clients] Ah thanks for that update. You've reminded me of another point: While it is admirable that CIRA (and probably other similar counterparts are watching) looking to establish IXPs, my anxiety lies with the future: Given everything that's already been written, are any of these IXPs capable of becoming self-sustaining in the future? It's a rhetorical question applicable to any starting IXP and requires an understanding of the local environment. wfms From clayton at MNSi.Net Wed Aug 21 17:34:29 2013 From: clayton at MNSi.Net (Clayton Zekelman) Date: Wed, 21 Aug 2013 13:34:29 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <48300247-6033-47C4-B5C4-C344D6CDD6FA@pch.net> <249E24C3-302B-4963-A3D9-55D46EC921FF@pch.net> Message-ID: <1377106472_247136@duplo.mnsi.net> At 01:15 PM 21/08/2013, William F. Maton Sotomayor wrote: >Facility neutrality especially. If the IXP is inside a non-neutral >DC, it and its peers are always under constant threat of being >squeezed out or shutdown by any number of circumstances. If the >co-lo business were separate from the facility business, it may be a >better environment since the IXP could convince the facility to host >it, which the co-lo business could then be attracted to. All >depends on the circumstances and environment. We run our colo facility as a separate business entity than our facilities/ISP business. Our customers actually get two invoices if they buy services and colocate. When we opened the colo, we invited any facilities based carrier in the region to place fibre. My rule was they could have rack space for a patch panel in the MMR for free for cables coming in from outside. If they needed space and power, then they would have to pay for that. They could use the entrance conduits from the first manhole outside the building for free, but they'd have to get there themselves. Colo customers pay a standard fee for fibre pairs to the MMR patch panel, agnostic of which carrier they are connecting to - including our own services. We have some customers that don't buy services from us - just space and power. Just depends on their needs. There are 3 fibre providers in the building now. It seems to work out. Now if there was a legitimate community of interest for establishing an IXP here, we could do it, but alas, as has been pointed out, the case for TorIX is so compelling, and so much needs to flow through Toronto regardless, it seems the natural place to interconnect. --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From christopher.morrell.nanog at gmail.com Wed Aug 21 17:42:55 2013 From: christopher.morrell.nanog at gmail.com (Christopher Morrell) Date: Wed, 21 Aug 2013 13:42:55 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <1377095998_244645@duplo.mnsi.net> <20130821171536.GA15476@vacation.karoshi.com.> Message-ID: <4FE34C3F-94B5-4091-B321-38956C5DD99F@gmail.com> I would hope that at least the 3 largest cities in Canada (Toronto, Montreal, Vancouver) should be able to sustain IXPs. Hopefully Calgary, Edmonton and Winnipeg too considering the size of their populations and their distance from the largest 3 cities. On 2013-08-21, at 13:27, "William F. Maton Sotomayor" wrote: > On Wed, 21 Aug 2013, bmanning at vacation.karoshi.com wrote: > >>> IIRC, Albuquerque has NMIX which I think was setup as for-profit. (John >>> Brown are you still here?) Well over a decade ago now, my recollection is >>> fuzzy. I don't recall the reasoning in choosing for-profit over >>> nont-for-profit. >> >> [NMIX couldn't pay its bills so it lost a lot of support/clients] > > Ah thanks for that update. > > You've reminded me of another point: While it is admirable that CIRA (and probably other similar counterparts are watching) looking to establish IXPs, my anxiety lies with the future: Given everything that's already been written, are any of these IXPs capable of becoming self-sustaining in the future? It's a rhetorical question applicable to any starting IXP and requires an understanding of the local environment. > > wfms > From woody at pch.net Wed Aug 21 19:02:44 2013 From: woody at pch.net (Bill Woodcock) Date: Wed, 21 Aug 2013 12:02:44 -0700 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <48300247-6033-47C4-B5C4-C344D6CDD6FA@pch.net> <249E24C3-302B-4963-A3D9-55D46EC921FF@pch.net> Message-ID: Omnibus reply warning. Skip this one unless you're really into IXP trivia. On Aug 21, 2013, at 7:52 AM, Randy Bush wrote: >> - New participation is not too rigorously constrained (at least a >> domestic ISP new market entrant should be able to participate) > > imiho, it is also nice if non-isp folk can participate, content, etc. Of course, and that is best-practice. I was listing the things that were, to my mind, bare minimums. I think we can agree that if two ISPs interconnect with each other, but prohibit a third or subsequent ISPs from interconnecting, that does not constitute an IXP. There are a small but significant subset of IXPs are the only option within their regions and are universally recognized to be IXPs, yet still place some restrictions upon who can participate, often requiring that participants hold a national ISP license. We generally work to influence them to ease or remove those restrictions over time. For example, we've succeeded in getting that restriction lifted from the Beirut exchange, while we're still working to move the management of the Buenos Aires exchange toward best-practices in this regard. >> - Participants do not receive a metered-rate bill based on utilization > > i am not sure i understand why. just seems a finer > grained case of 100mb for $1, 1g for $5, and 10g for $20 or whatever. Certainly that's one way of looking at it. Can you think of any examples of something you'd consider to unequivocally be an IXP, yet charges a participant 1% more if they use 50.5mbps than if they use 50mbps? Generally this is one of the hallmarks of a layer-1/2 carrier that's trying to pass itself off as an IXP for marketing purposes. The principle drawback of such a charging scheme is that it removes the efficiency-of-scale incentive for ISPs to use the IXP more, and therefore removes their ability to charge their customers less as they use the IXP more, and thus the "exchange" fails to grow. Hypothetically, if the price were low enough, none of this would be a significant factor or disincentive, but in twenty years of IXPs and things-that-tried-to-be-IXPs, I haven't seen a successful example of such, while seeing quite a few that failed, where this was the primary distinguishing feature. It's not a common thing, but it's been a big red flag when it has shown up. > i would add carrier neutrality, i can haul fiber from anyone into > the exchange. this is pretty critical in the exchanges where i have > played. I'd say that carrier neutrality is a hard requirement in markets where that's a decision being made by the IXP (or more often the colo that hosts the IXP). There are a lot of markets that don't have competitive carriers, so this issue isn't yet tested at the time we're trying to figure out what's what. For instance, It was twelve years between the point at which the first IXP was formed in Singapore, and the first time anyone was able to run a competitive piece of fiber into it. >> Peer1 exchanges are only open to Peer1 customers, I believe. At least, >> that's how it worked in Toronto the last time I looked. > > that is not an exchange. most isps have switches in their transit > infrastructure. I agree that ISPs have switches, and will usually happily sell transit (or colo) to customers connected to those switches, and that that doesn't constitute an exchange. Peer1 presents themselves as a colocation provider (that also sells hosting). I think most people other than Peer1 would agree that Peer1's facilities don't constitute exchanges, and they're not marked as exchanges by our staff, in the directory. However, the line between Peer1 and, for instance, Equinix or Global Switch, is fairly fine? I think you'd find general consensus that Equinix switches are IXPs, and Equinix is a colocation provider (that also occasionally sells transit, to some of their customers, on occasion). So while the position you're expressing is certainly the majority position, it's something of a matter of degree and focus, and to some degree a judgment in the eye of the beholder, rather than something easily expressible in a simple objective rule. On Aug 21, 2013, at 7:38 AM, Clayton Zekelman wrote: > Just wondering aloud if an ISP that did have commercial interest could run a non-member driven exchange point successfully as long as they had pricing and policies that were similar to member driven exchange points. ISPs tend to be very pragmatic on the issue of facility neutrality, whereas folks like regulators and those who are selling a product in the area get more religious about it. So ISPs don't tend to care much whether a facility is neutral, or run by one of their competitors, if they can see a clear value proposition in using it. That said, the price-point of the non-neutral for-profit IXP you postulate is not necessarily equal to or greater than zero? First of all, operating a switch is well within the core competency of ISPs, so they all know that the cost of doing it themselves is de minimis. Second, they know that the capex of building out to someone else's facility can be substantial, so while they're willing to do that when the future value of that investment, and their ability to recoup it, is protected, they generally won't do so if they can't see very clear protections (cash and contracts, not assertions and good-will). Third, they know that, while they have to make that infrastructural investment to reach the exchange, the owner of the facility does not. When the owner is not an ISP, that's not an issue, but when the owner is an ISP, and one of their competitors, it constitutes a significant relative competitive disadvantage. Although both parties lose in an absolute sense if they fail to exchange traffic, the other guy didn't have to drop a lot of money, and doesn't have as much to lose, so can afford to play hardball in negotiating over who gets to keep excess rent. In practice, you don't see this arrangement much (non-neutral IXPs) for two reasons: when IXPs are established through an open stakeholder process, all stakeholders make clear that they'd be happy to host the exchange within their facility, and once they've all gotten that off their chests, they move on to deciding upon a jointly-acceptable neutral location; and when a for-profit entity unilaterally establishes a non-neutral exchange, ISPs generally don't choose to use it, and it fails through the action of market forces. The halfway-case, neutral for-profit exchanges, generally a feature of neutral for-profit colocation facilities, are an interesting compromise and are often quite successful in the marketplace. So it's useful to look at them as a point of comparison. ISPs still know that they can do the switch thing themselves just as easily, so the cost still needs to be relatively low, and the points of value need to be things that are more difficult for an ISP to do internally. First and foremost, the neutrality and the large datacenter facility attract other people to talk to. Second, also very compelling, getting to take advantage of the benefits of scale; generators, security, etc., in a location where you only need one or two cabinets. Third, many of these businesses make their money elsewhere, through real-estate speculation or by issuing shares, so the services ISPs are buying are subsidized by those other lines of business, and are, literally, less expensive than if the ISP were to build it themselves. > Community of interest of course is the other magical ingredient that is necessary. Not sure how many ISPs would want to peer in Windsor... > If there was a legitimate community of interest for establishing an IXP here, we could do it, but alas, as has been pointed out, the case for TorIX is so compelling, and so much needs to flow through Toronto regardless, it seems the natural place to interconnect. Folks in London (England, not Ontario) said the same thing about Washington D.C. before they got an IXP of their own up, as well. It's very easy to look at the status-quo and observe that it's functioning, while it's not always so easy to imagine how things will be better, if things pan out, in five or ten years. My experience leads me to believe that Windsor can support an IXP, and that if you don't over-spend and gold-plate it, it'll make money for you, and will grow over time. As will TorIX. It's quite likely that an exchange in Windsor will never be as large as one in Toronto, but that's no reason not to do it. A restaurant or gas station in Toronto might be more successful than one in Windsor, but it doesn't mean that nobody bothers to start a restaurant or gas station in Windsor. Same thing. Speed times distance equals cost, and always will. Exchange traffic more locally to keep speeds high and costs low, and stay competitive. If you just use an IXP in Toronto, ISPs in Toronto will always be more competitive than you will, because their cost-of-goods will always be lower. On Aug 21, 2013, at 10:27 AM, "William F. Maton Sotomayor" wrote: > While it is admirable that CIRA (and probably other similar counterparts are watching) looking to establish IXPs? I think CIRA has been very clear that they're not trying to establish IXPs, they're trying to provide any desired support to locally-based IXP efforts. There's a big difference. In order for an IXP to succeed, it needs a constituency of ISPs who understand that it's critical to their financial success. You can't just drop in and build an IXP for someone, and expect it to still be there a year later. > My anxiety lies with the future: Given everything that's already been written, are any of these IXPs capable of becoming self-sustaining in the future? It's a rhetorical question applicable to any starting IXP. Indeed. I think that ISPs who understand their business model well enough to understand the effect the IXP will have on their average-per-bit-delivery-cost is essential. I think it's also essential that they have some basic familiarity with the different ways IXPs can fail, or fail to thrive, so that they can avoid mistakes others have made in the past. Over-spending, particularly on switches, is a huge killer of IXPs. Under-provisioning of circuits to the IXP is another big mistake. Failure to encourage local content and hosting is another. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From john at west-canaan.net Thu Aug 22 04:41:40 2013 From: john at west-canaan.net (John Zettlemoyer) Date: Thu, 22 Aug 2013 00:41:40 -0400 Subject: hotmail / live.com contact Message-ID: <008801ce9ef1$ea2b8270$be828750$@net> Could someone from the hotmail / live.com mail group contact me off list please. Thank you. John Zettlemoyer From mpetach at netflight.com Thu Aug 22 08:55:02 2013 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 22 Aug 2013 01:55:02 -0700 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <5214C95C.50301@bogus.com> References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <48300247-6033-47C4-B5C4-C344D6CDD6FA@pch.net> <5214C95C.50301@bogus.com> Message-ID: On Wed, Aug 21, 2013 at 7:06 AM, joel jaeggli wrote: > On 8/21/13 6:56 AM, Randy Bush wrote: > > > > but how do you represent seattle colonolizing bc? > "keep your potatoes out of my pig." > Ugh. Suddenly your talk of potatoes in pigs makes "colon-olizing" seem almost meaningful (methinks Randy meant "colonizing", but his colon-os got a bit carried away...:D ) Matt > > http://en.wikipedia.org/wiki/Pig_War > > > > randy > > > > > From nccariaga at stluke.com.ph Thu Aug 22 10:31:46 2013 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Thu, 22 Aug 2013 18:31:46 +0800 Subject: How does Google Global Cache selects which cache to redirect a client? Message-ID: <5215E892.6060907@stluke.com.ph> Hi, Just wondering if anyone here I can discuss offline about Google Global Cache? I am interested in knowing how does the cache selection process takes place (i.e. how does Google know to which cache to redirect a client). I would also like to know what if I have 2 upstreams who both have GGCs installed in their network, how would the selection process takes place. Thank you very much in advance. Regards, -- -nathan From piotr.1234 at interia.pl Thu Aug 22 14:58:01 2013 From: piotr.1234 at interia.pl (Piotr) Date: Thu, 22 Aug 2013 16:58:01 +0200 Subject: 10G standalone switch to access in data center, cheap Message-ID: <521626F9.7090609@interia.pl> Hello, I looking some 10G switches, 24-48 ports, it will be work in DC in access. Something cheaper ( for port) than extreme 670 ? Do You know something ? thanks greets, Peter From brandon.galbraith at gmail.com Thu Aug 22 15:34:56 2013 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 22 Aug 2013 10:34:56 -0500 Subject: How does Google Global Cache selects which cache to redirect a client? In-Reply-To: <5215E892.6060907@stluke.com.ph> References: <5215E892.6060907@stluke.com.ph> Message-ID: Have you tried experimenting programmatically to determine if its based on which DNS servers the client is using to resolve? On Thu, Aug 22, 2013 at 5:31 AM, Nathanael C. Cariaga wrote: > Hi, > > Just wondering if anyone here I can discuss offline about Google Global > Cache? I am interested in knowing how does the cache selection process > takes place (i.e. how does Google know to which cache to redirect a client). > I would also like to know what if I have 2 upstreams who both have GGCs > installed in their network, how would the selection process takes place. > > Thank you very much in advance. > > > Regards, > > -- > -nathan > > From excelsio at gmx.com Thu Aug 22 15:42:51 2013 From: excelsio at gmx.com (excelsio at gmx.com) Date: Thu, 22 Aug 2013 17:42:51 +0200 Subject: 10G standalone switch to access in data center, cheap In-Reply-To: <521626F9.7090609@interia.pl> References: <521626F9.7090609@interia.pl> Message-ID: <5216317B.6040008@gmx.com> Well, "cheap" (and new), i.e. - take 1-2 Netgear XSM7224 with 24x 10GBaseT and 4x SFP+ (shared) each - take 1-2 Netgear XSM7224S with 24x SFP+ and 4x 10GBaseT (shared) each or - take 3-6 Netgear XS708E with 8x 10GBaseT and 1x SFP+ (shared) each - take 2-4 Netgear XS712T with 12x 10GBaseT and 2x SFP+ (shared) each I?m still looking myself for something cheaper, like switches directly bought/imported from original design manufacturers in low quantity. Michael From jeroen.wunnink at atrato.com Thu Aug 22 15:39:31 2013 From: jeroen.wunnink at atrato.com (Jeroen Wunnink | Atrato IP Networks) Date: Thu, 22 Aug 2013 17:39:31 +0200 Subject: 10G standalone switch to access in data center, cheap In-Reply-To: <521626F9.7090609@interia.pl> References: <521626F9.7090609@interia.pl> Message-ID: <521630B3.6080600@atrato.com> Juniper EX4500 or EX4550, they have fairly small send buffers though, so don't expect line-rate forwarding on all your ports. On 8/22/13 4:58 PM, Piotr wrote: > Hello, > > I looking some 10G switches, 24-48 ports, it will be work in DC in > access. Something cheaper ( for port) than extreme 670 ? > > Do You know something ? > > thanks > greets, > Peter > > -- Jeroen Wunnink Senior Network Engineer / NOC Team Lead Atrato IP Networks jeroen.wunnink at atrato.com Phone: +31 20 82 00 623 From piotr.1234 at interia.pl Thu Aug 22 16:58:28 2013 From: piotr.1234 at interia.pl (Piotr) Date: Thu, 22 Aug 2013 18:58:28 +0200 Subject: 10G standalone switch to access in data center, cheap In-Reply-To: <521630B3.6080600@atrato.com> References: <521626F9.7090609@interia.pl> <521630B3.6080600@atrato.com> Message-ID: <52164334.8080900@interia.pl> most of tor, 1u, standalone 10G, switches have only 8-9 MB shared buffers.. Peter W dniu 2013-08-22 17:39, Jeroen Wunnink | Atrato IP Networks pisze: > Juniper EX4500 or EX4550, they have fairly small send buffers though, so > don't expect line-rate forwarding on all your ports. > > On 8/22/13 4:58 PM, Piotr wrote: >> Hello, >> >> I looking some 10G switches, 24-48 ports, it will be work in DC in >> access. Something cheaper ( for port) than extreme 670 ? >> >> Do You know something ? >> >> thanks >> greets, >> Peter >> >> > > From bedard.phil at gmail.com Thu Aug 22 17:03:59 2013 From: bedard.phil at gmail.com (Phil Bedard) Date: Thu, 22 Aug 2013 10:03:59 -0700 Subject: 10G standalone switch to access in data center, cheap Message-ID: <8032375990195925433@unknownmsgid> Quanta is pretty cheap, basically a bare bones reference design. Mellanox as well. Juniper EX4550. Any other features you are looking for? From: Piotr Sent: 8/22/2013 10:59 To: nanog at nanog.org Subject: 10G standalone switch to access in data center, cheap Hello, I looking some 10G switches, 24-48 ports, it will be work in DC in access. Something cheaper ( for port) than extreme 670 ? Do You know something ? thanks greets, Peter From netfortius at gmail.com Thu Aug 22 17:06:25 2013 From: netfortius at gmail.com (Stefan) Date: Thu, 22 Aug 2013 12:06:25 -0500 Subject: [Q] What is your favorite Network Tools Live CD / USB, which you could have running in remote offices? Message-ID: I've been toying with Live distros (CD, then USB) for many years, in support of security toolsets, to which I kept adding my own stuff, or customizing existing components. I am now trying to "build" a network toolset LiveCD/USB, but this time with a completely different purpose: I would like to put it in the hands of all remote offices we have on our network, and use it to have local systems boot out of it, and help us then run troubleshooting tools, from the central office, by SSH/X-ing into the remote live system (e.g. iperf, hping3, httping, tcping, mtr, tcpdump, voip tools, some "thin" clients/apps, synthetic transactions scripted to run at diff time intervals, and report back to us the "health" seen form the remotes, etc.). Has anybody used a "base" network tools Live CD/USB that they would recommend, having used as "basis" for such a "network probe" functionality? NOTE: I assume *nix based (Linux or BSD flavors), not Windows ... TIA, ***Stefan From michael at pbandjelly.org Thu Aug 22 17:29:23 2013 From: michael at pbandjelly.org (Michael Shuler) Date: Thu, 22 Aug 2013 12:29:23 -0500 Subject: [Q] What is your favorite Network Tools Live CD / USB, which you could have running in remote offices? In-Reply-To: References: Message-ID: <52164A73.6080805@pbandjelly.org> On 08/22/2013 12:06 PM, Stefan wrote: > I've been toying with Live distros (CD, then USB) for many years, in > support of security toolsets, to which I kept adding my own stuff, or > customizing existing components. > > I am now trying to "build" a network toolset LiveCD/USB, but this time with > a completely different purpose: I would like to put it in the hands of all > remote offices we have on our network, and use it to have local systems > boot out of it, and help us then run troubleshooting tools, from the > central office, by SSH/X-ing into the remote live system (e.g. iperf, > hping3, httping, tcping, mtr, tcpdump, voip tools, some "thin" > clients/apps, synthetic transactions scripted to run at diff time > intervals, and report back to us the "health" seen form the remotes, etc.). > Has anybody used a "base" network tools Live CD/USB that they would > recommend, having used as "basis" for such a "network probe" functionality? http://www.kali.org/ - it is completely customizable, as well. -- Kind regards, Michael From netfortius at gmail.com Thu Aug 22 17:40:50 2013 From: netfortius at gmail.com (Stefan) Date: Thu, 22 Aug 2013 12:40:50 -0500 Subject: [Q] What is your favorite Network Tools Live CD / USB, which you could have running in remote offices? In-Reply-To: <52164A73.6080805@pbandjelly.org> References: <52164A73.6080805@pbandjelly.org> Message-ID: Should have mentioned what I already use for security toolset base: Kali and Security Onion ... ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius On Thu, Aug 22, 2013 at 12:29 PM, Michael Shuler wrote: > On 08/22/2013 12:06 PM, Stefan wrote: > > I've been toying with Live distros (CD, then USB) for many years, in > > support of security toolsets, to which I kept adding my own stuff, or > > customizing existing components. > > > > I am now trying to "build" a network toolset LiveCD/USB, but this time > with > > a completely different purpose: I would like to put it in the hands of > all > > remote offices we have on our network, and use it to have local systems > > boot out of it, and help us then run troubleshooting tools, from the > > central office, by SSH/X-ing into the remote live system (e.g. iperf, > > hping3, httping, tcping, mtr, tcpdump, voip tools, some "thin" > > clients/apps, synthetic transactions scripted to run at diff time > > intervals, and report back to us the "health" seen form the remotes, > etc.). > > Has anybody used a "base" network tools Live CD/USB that they would > > recommend, having used as "basis" for such a "network probe" > functionality? > > http://www.kali.org/ - it is completely customizable, as well. > > -- > Kind regards, > Michael > > From rtomek at ceti.pl Thu Aug 22 17:58:59 2013 From: rtomek at ceti.pl (Tomasz Rola) Date: Thu, 22 Aug 2013 19:58:59 +0200 (CEST) Subject: [Q] What is your favorite Network Tools Live CD / USB, which you could have running in remote offices? In-Reply-To: <52164A73.6080805@pbandjelly.org> References: <52164A73.6080805@pbandjelly.org> Message-ID: On Thu, 22 Aug 2013, Michael Shuler wrote: > On 08/22/2013 12:06 PM, Stefan wrote: > > I've been toying with Live distros (CD, then USB) for many years, in > > support of security toolsets, to which I kept adding my own stuff, or > > customizing existing components. > > > > I am now trying to "build" a network toolset LiveCD/USB, but this time with > > a completely different purpose: I would like to put it in the hands of all > > remote offices we have on our network, and use it to have local systems > > boot out of it, and help us then run troubleshooting tools, from the > > central office, by SSH/X-ing into the remote live system (e.g. iperf, > > hping3, httping, tcping, mtr, tcpdump, voip tools, some "thin" > > clients/apps, synthetic transactions scripted to run at diff time > > intervals, and report back to us the "health" seen form the remotes, etc.). > > Has anybody used a "base" network tools Live CD/USB that they would > > recommend, having used as "basis" for such a "network probe" functionality? > > http://www.kali.org/ - it is completely customizable, as well. Alternatively, GRML Linux: http://grml.org/features/ http://grml.org/files/ http://grml.org/faq/ I understand it is more about admin than pentesting. Also, last time I downloaded (few months ago), images were somewhere in <=~ 400MB area (vs Kali's 2GB, AFAIK). I am not sure about customizations. It is some kind of Debian's relative, so, in theory, why not. BTW, I am long time lurker and this is my first post here, so hello everybody. You guys know what are your interests - mine are there, too, either full set or a subset. Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From uwcableguy at gmail.com Thu Aug 22 18:13:23 2013 From: uwcableguy at gmail.com (Ben Bartsch) Date: Thu, 22 Aug 2013 13:13:23 -0500 Subject: [Q] What is your favorite Network Tools Live CD / USB, which you could have running in remote offices? In-Reply-To: References: <52164A73.6080805@pbandjelly.org> Message-ID: perfSONAR-PS project - http://www.perfsonar.net/ On Thu, Aug 22, 2013 at 12:58 PM, Tomasz Rola wrote: > On Thu, 22 Aug 2013, Michael Shuler wrote: > > > On 08/22/2013 12:06 PM, Stefan wrote: > > > I've been toying with Live distros (CD, then USB) for many years, in > > > support of security toolsets, to which I kept adding my own stuff, or > > > customizing existing components. > > > > > > I am now trying to "build" a network toolset LiveCD/USB, but this time > with > > > a completely different purpose: I would like to put it in the hands of > all > > > remote offices we have on our network, and use it to have local systems > > > boot out of it, and help us then run troubleshooting tools, from the > > > central office, by SSH/X-ing into the remote live system (e.g. iperf, > > > hping3, httping, tcping, mtr, tcpdump, voip tools, some "thin" > > > clients/apps, synthetic transactions scripted to run at diff time > > > intervals, and report back to us the "health" seen form the remotes, > etc.). > > > Has anybody used a "base" network tools Live CD/USB that they would > > > recommend, having used as "basis" for such a "network probe" > functionality? > > > > http://www.kali.org/ - it is completely customizable, as well. > > Alternatively, GRML Linux: > > http://grml.org/features/ > > http://grml.org/files/ > > http://grml.org/faq/ > > I understand it is more about admin than pentesting. Also, last time I > downloaded (few months ago), images were somewhere in <=~ 400MB area (vs > Kali's 2GB, AFAIK). I am not sure about customizations. It is some kind of > Debian's relative, so, in theory, why not. > > BTW, I am long time lurker and this is my first post here, so hello > everybody. You guys know what are your interests - mine are there, too, > either full set or a subset. > > Regards, > Tomasz Rola > > -- > ** A C programmer asked whether computer had Buddha's nature. ** > ** As the answer, master did "rm -rif" on the programmer's home ** > ** directory. And then the C programmer became enlightened... ** > ** ** > ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** > > From dwhite at olp.net Thu Aug 22 18:14:29 2013 From: dwhite at olp.net (Dan White) Date: Thu, 22 Aug 2013 13:14:29 -0500 Subject: What is your favorite Network Tools Live CD / USB, which you could have running in remote offices? In-Reply-To: References: Message-ID: <20130822181429.GF6793@dan.olp.net> On 08/22/13?12:06?-0500, Stefan wrote: >I've been toying with Live distros (CD, then USB) for many years, in >support of security toolsets, to which I kept adding my own stuff, or >customizing existing components. > >I am now trying to "build" a network toolset LiveCD/USB, but this time with >a completely different purpose: I would like to put it in the hands of all >remote offices we have on our network, and use it to have local systems >boot out of it, and help us then run troubleshooting tools, from the >central office, by SSH/X-ing into the remote live system (e.g. iperf, >hping3, httping, tcping, mtr, tcpdump, voip tools, some "thin" >clients/apps, synthetic transactions scripted to run at diff time >intervals, and report back to us the "health" seen form the remotes, etc.). >Has anybody used a "base" network tools Live CD/USB that they would >recommend, having used as "basis" for such a "network probe" functionality? > >NOTE: I assume *nix based (Linux or BSD flavors), not Windows ... live-build (Debian based) is what I've been using, and has the benefit of allowing you to pick and choose from Debian's vast repository. Here's my latest build script: http://web.olp.net/dwhite/lb.txt -- Dan White From netfortius at gmail.com Thu Aug 22 18:27:45 2013 From: netfortius at gmail.com (Stefan) Date: Thu, 22 Aug 2013 13:27:45 -0500 Subject: What is your favorite Network Tools Live CD / USB, which you could have running in remote offices? In-Reply-To: <20130822181429.GF6793@dan.olp.net> References: <20130822181429.GF6793@dan.olp.net> Message-ID: On Thu, Aug 22, 2013 at 1:14 PM, Dan White wrote: > On 08/22/13 12:06 -0500, Stefan wrote: > >> I've been toying with Live distros (CD, then USB) for many years, in >> support of security toolsets, to which I kept adding my own stuff, or >> customizing existing components. >> >> I am now trying to "build" a network toolset LiveCD/USB, but this time >> with >> a completely different purpose: I would like to put it in the hands of all >> remote offices we have on our network, and use it to have local systems >> boot out of it, and help us then run troubleshooting tools, from the >> central office, by SSH/X-ing into the remote live system (e.g. iperf, >> hping3, httping, tcping, mtr, tcpdump, voip tools, some "thin" >> clients/apps, synthetic transactions scripted to run at diff time >> intervals, and report back to us the "health" seen form the remotes, >> etc.). >> Has anybody used a "base" network tools Live CD/USB that they would >> recommend, having used as "basis" for such a "network probe" >> functionality? >> >> NOTE: I assume *nix based (Linux or BSD flavors), not Windows ... >> > > live-build (Debian based) is what I've been using, and has the benefit of > allowing you to pick and choose from Debian's vast repository. Here's my > latest build script: > > http://web.olp.net/dwhite/lb.**txt > -- > Dan White > I love it, Dan! Thanks for sharing. ***Stefan From meekjt at gmail.com Thu Aug 22 18:58:33 2013 From: meekjt at gmail.com (Jon Meek) Date: Thu, 22 Aug 2013 14:58:33 -0400 Subject: [Q] What is your favorite Network Tools Live CD / USB, which you could have running in remote offices? In-Reply-To: References: Message-ID: On Thu, Aug 22, 2013 at 1:06 PM, Stefan wrote: > I've been toying with Live distros (CD, then USB) for many years, in > support of security toolsets, to which I kept adding my own stuff, or > customizing existing components. > > I am now trying to "build" a network toolset LiveCD/USB, but this time with > a completely different purpose: I would like to put it in the hands of all > remote offices we have on our network, and use it to have local systems > boot out of it, and help us then run troubleshooting tools, from the > central office, by SSH/X-ing into the remote live system (e.g. iperf, > hping3, httping, tcping, mtr, tcpdump, voip tools, some "thin" > clients/apps, synthetic transactions scripted to run at diff time > intervals, and report back to us the "health" seen form the remotes, etc.). > Has anybody used a "base" network tools Live CD/USB that they would > recommend, having used as "basis" for such a "network probe" functionality? > > NOTE: I assume *nix based (Linux or BSD flavors), not Windows ... > > TIA, > ***Stefan > I use Voyage Linux: http://linux.voyage.hk/ In several modes: - Bootable USB flash drive - On PC Engines ALIX boards from Compact Flash - And in a few instances on servers with spinning disks, and desktop with minimal window system The bootable USB stick has been used extensively for iperf + tcpdump + analysis from PCs are remote locations. We either have people copy an image to the USB stick, or mail them a stick. Then they can turn (almost) any PC into a network analysis tool. We have the system report it's IP address at boot time, and then we ssh in. Jon From zgiles at gmail.com Thu Aug 22 19:01:28 2013 From: zgiles at gmail.com (Zachary Giles) Date: Thu, 22 Aug 2013 15:01:28 -0400 Subject: 10G standalone switch to access in data center, cheap In-Reply-To: <8032375990195925433@unknownmsgid> References: <8032375990195925433@unknownmsgid> Message-ID: How about the Force10 S48xx series? They're pretty decent today. On Thu, Aug 22, 2013 at 1:03 PM, Phil Bedard wrote: > Quanta is pretty cheap, basically a bare bones reference design. > Mellanox as well. Juniper EX4550. Any other features you are looking > for? From: Piotr > Sent: 8/22/2013 10:59 > To: nanog at nanog.org > Subject: 10G standalone switch to access in data center, cheap > Hello, > > I looking some 10G switches, 24-48 ports, it will be work in DC in > access. Something cheaper ( for port) than extreme 670 ? > > Do You know something ? > > thanks > greets, > Peter > > -- Zach Giles zgiles at gmail.com From listas at esds.com.br Thu Aug 22 19:29:19 2013 From: listas at esds.com.br (Eduardo Schoedler) Date: Thu, 22 Aug 2013 16:29:19 -0300 Subject: [Q] What is your favorite Network Tools Live CD / USB, which you could have running in remote offices? In-Reply-To: References: Message-ID: BackTrack - http://www.backtrack-linux.org 2013/8/22 Stefan > I've been toying with Live distros (CD, then USB) for many years, in > support of security toolsets, to which I kept adding my own stuff, or > customizing existing components. > > I am now trying to "build" a network toolset LiveCD/USB, but this time with > a completely different purpose: I would like to put it in the hands of all > remote offices we have on our network, and use it to have local systems > boot out of it, and help us then run troubleshooting tools, from the > central office, by SSH/X-ing into the remote live system (e.g. iperf, > hping3, httping, tcping, mtr, tcpdump, voip tools, some "thin" > clients/apps, synthetic transactions scripted to run at diff time > intervals, and report back to us the "health" seen form the remotes, etc.). > Has anybody used a "base" network tools Live CD/USB that they would > recommend, having used as "basis" for such a "network probe" functionality? > > NOTE: I assume *nix based (Linux or BSD flavors), not Windows ... > > TIA, > ***Stefan > -- Eduardo Schoedler From dylan.humphreys at comodo.com Thu Aug 22 17:32:13 2013 From: dylan.humphreys at comodo.com (Dylan Humphreys) Date: Thu, 22 Aug 2013 18:32:13 +0100 Subject: Problems with routing to a couple of IPs In-Reply-To: <52164B00.4030806@comodo.com> References: <52164B00.4030806@comodo.com> Message-ID: <52164B1D.7060903@comodo.com> Hit send too early then! :D -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3940 bytes Desc: S/MIME Cryptographic Signature URL: From kristopher.amundson.contractor at usap.gov Thu Aug 22 20:11:28 2013 From: kristopher.amundson.contractor at usap.gov (Amundson, Kristopher (Contractor)) Date: Fri, 23 Aug 2013 08:11:28 +1200 Subject: 10G standalone switch to access in data center, cheap In-Reply-To: <521626F9.7090609@interia.pl> References: <521626F9.7090609@interia.pl> Message-ID: <52167070.20104@usap.gov> On 2013-08-23 2:58 AM, Piotr wrote: > Hello, > > I looking some 10G switches, 24-48 ports, it will be work in DC in access. > Something cheaper ( for port) than extreme 670 ? Take a look at this list. These folks are putting a commodity Linux environment with binary drivers to merchant silicon switches. Right now they support Accton, Agema, Penguin Computing and Quanta. Arista without the price tag? :) http://cumulusnetworks.com/support/hcl/ Even without the linux distro these switches are probably cheap and usable with their default OS. Hey NANOG, it's good to be back and has been quite a while since I lurked on this list. Greetings from the bottom of the Earth (-70F outside my building). -- Kris Amundson Network Engineer South Pole Station Ext: 61805 LMR: 214 From dwessels at verisign.com Thu Aug 22 20:57:12 2013 From: dwessels at verisign.com (Wessels, Duane) Date: Thu, 22 Aug 2013 20:57:12 +0000 Subject: Reminder about upcoming .gov algorithm roll Message-ID: <6AE3CC6B-2550-4654-9D05-079BBD276EA7@verisign.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This notice is a reminder that an algorithm roll for the .gov zone will take place in the upcoming weeks. The .gov zone is currently signed with algorithm 7 (RSASHA1-NSEC3-SHA1) and will be changed to use algorithm 8 (RSA/SHA-256). The schedule for the algorithm roll is as follows: August 29th: The .gov zone will begin publishing algorithm 8 RRSIGs. September 3rd: The .gov zone will begin publishing algorithm 8 DNSKEYs. September 10th (estimated): The algorithm 8 DS records will replace the algorithm 7 DS records in the root zone. September 17th: The .gov zone will cease publishing algorithm 7 DNSKEYs. September 19th: The .gov zone will cease publishing algorithm 7 RRISGs. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSFno+AAoJEGyZpGmowJiN8ZMIAJ3oewRsTKYpCSSQmdPC6hX3 uQC4Ih3PVyO3SiguVj9Y39/PL/0FPDeq7J5KDoQjcSod4kxZEJngjyg9SpB6kbcn ciqjKM6JAvSIjKz9nH7YIOpoOJoRGae/GwdcLHhpFqEgJ1LO60k8Bmh3VF9J3hk0 chdKs3f4Nbn9TeNv46qURO/ZSRTP2Wwvm+xGmuu6Djtrn+9Rbix4q44J+nZb021j hIrzJAXEbYwzZCw0dtKlhWXwEu2Pe1TKCWF1dg8d1j+EVmaVypB2uKWxjtEPIdtQ RVngz5OirKXUK51naA6cSTjLcGesgPGoxGGi75xdYtYsB/ou0FADiZcO4gYexuk= =Gq2g -----END PGP SIGNATURE----- From hschiller at google.com Thu Aug 22 22:28:04 2013 From: hschiller at google.com (Heather Schiller) Date: Thu, 22 Aug 2013 15:28:04 -0700 Subject: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have) In-Reply-To: <87pptk5rbp.fsf@mid.deneb.enyo.de> References: <2FC10561-FDF8-4CAF-9628-6A9656E8F554@arbor.net> <20130801063151.GA16879@pob.ytti.fi> <05D03AC0-0124-4C60-A0E7-04E1F9D4CAAD@puck.nether.net> <87pptk5rbp.fsf@mid.deneb.enyo.de> Message-ID: This is the RFC that is being violated: http://tools.ietf.org/html/rfc5625#section-6.2 6.2 . Interface Binding Some gateways have been observed to have their DNS proxy listening on both internal (LAN) and external (WAN) interfaces. In this configuration, it is possible for the proxy to be used to mount reflector attacks as described in [RFC5358 ]. The DNS proxy in a gateway SHOULD NOT, by default, be accessible from the WAN interfaces of the device. Implemented correctly, CPE receives DNS request and proxies the request internally. Usually they are only listening on the LAN side. Sometimes they take DNS requests from the WAN side. When a local DNS cache is not defined, these requests can leak out to whatever cache is defined. In some cases, the CPE retains the IP address that originally sourced the packet. So you end up with external caches responding to requests from 3rd parties. Add to that spoofing the original packets to the bad CPE and you have that CPE proxying your DNS amplification attack to other caches. Don't blame the cache. The attacker was intending that the CPE amp directly. Fix: CPE should disable DNS proxying by default and require a restricted list of sources (LAN, vpn, etc) when enabled. Also/alternatively require cache to be local. --Heather On Sun, Aug 11, 2013 at 5:45 AM, Florian Weimer wrote: > * Jared Mauch: > > > Number of unique IPs that spoofed a packet to me. (eg: I sent a > > packet to 1.2.3.4 and 5.6.7.8 responded). > > That's not necessarily proof of spoofing, isn't it? The system in > question might legitimately own IP addresses from very different > networks. If the system is a router and the service you're pinging is > not correctly implemented and it picks up the IP address of the > outgoing interface instead of the source address of the request, > that's totally expected. > > I'm not saying that BCP 38 is widely implement (it's not, unless > operators have configured exceptions for ICMP traffic from private > address, which I very much doubt). I just think you aren't actually > measuring spoofing capabilities. > > From chris at westnet.com Fri Aug 23 01:17:45 2013 From: chris at westnet.com (Christopher X. Candreva) Date: Thu, 22 Aug 2013 21:17:45 -0400 (EDT) Subject: [Q] What is your favorite Network Tools Live CD / USB, which you could have running in remote offices? In-Reply-To: References: Message-ID: On Thu, 22 Aug 2013, Stefan wrote: > a completely different purpose: I would like to put it in the hands of all > remote offices we have on our network, and use it to have local systems > boot out of it, and help us then run troubleshooting tools, from the > central office, by SSH/X-ing into the remote live system (e.g. iperf, > hping3, httping, tcping, mtr, tcpdump, voip tools, some "thin" > clients/apps, synthetic transactions scripted to run at diff time > intervals, and report back to us the "health" seen form the remotes, etc.). I'm toying with a similar idea, though of putting a Raspberry Pi in remote offices to do tests from. I'm just looking for something I can ssh too, however, it also doesn't seem like much of a stretch to put some kind of web-based screen that someone in the office could run an automated scan, and read us off information that might help. ========================================================== Chris Candreva -- chris at westnet.com -- (914) 948-3162 WestNet Internet Services of Westchester http://www.westnet.com/ From meekjt at gmail.com Fri Aug 23 04:30:20 2013 From: meekjt at gmail.com (Jon Meek) Date: Fri, 23 Aug 2013 00:30:20 -0400 Subject: [Q] What is your favorite Network Tools Live CD / USB, which you could have running in remote offices? In-Reply-To: References: Message-ID: On Thu, Aug 22, 2013 at 9:17 PM, Christopher X. Candreva wrote: > On Thu, 22 Aug 2013, Stefan wrote: > > > a completely different purpose: I would like to put it in the hands of > all > > remote offices we have on our network, and use it to have local systems > > boot out of it, and help us then run troubleshooting tools, from the > > central office, by SSH/X-ing into the remote live system (e.g. iperf, > > hping3, httping, tcping, mtr, tcpdump, voip tools, some "thin" > > clients/apps, synthetic transactions scripted to run at diff time > > intervals, and report back to us the "health" seen form the remotes, > etc.). > > I'm toying with a similar idea, though of putting a Raspberry Pi in remote > offices to do tests from. I'm just looking for something I can ssh too, > however, it also doesn't seem like much of a stretch to put some kind of > web-based screen that someone in the office could run an automated scan, > and > read us off information that might help. > > > ========================================================== > Chris Candreva -- chris at westnet.com -- (914) 948-3162 > WestNet Internet Services of Westchester > http://www.westnet.com/ > > There is a lot to be said for the RaspberryPi, but network throughput, and especially processing power are limited. My tests show that the RaspberryPi could push only about 46 Mbps of iperf while most PCs configured the same way get almost to wire speed (100 Mbps or 1Gbps), and processing 30 seconds of 45 Mbps traffic on the RaspberryPi takes many minutes. But, if you want to test slower circuits, it can't be beat for cost, size, flexibility. I am expecting delivery of a Parallella board in October and will be testing it for iperf capability at GigE speed. Jon From niels=nanog at bakker.net Fri Aug 23 10:59:12 2013 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 23 Aug 2013 12:59:12 +0200 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <48300247-6033-47C4-B5C4-C344D6CDD6FA@pch.net> <249E24C3-302B-4963-A3D9-55D46EC921FF@pch.net> Message-ID: <20130823105912.GB3108@burnout.tpb.net> * woody at pch.net (Bill Woodcock) [Wed 21 Aug 2013, 21:04 CEST]: [..] >On Aug 21, 2013, at 10:27 AM, "William F. Maton Sotomayor" > wrote: [..] >>My anxiety lies with the future: Given everything that's already >>been written, are any of these IXPs capable of becoming >>self-sustaining in the future? It's a rhetorical question >>applicable to any starting IXP. > >Indeed. I think that ISPs who understand their business model well >enough to understand the effect the IXP will have on their >average-per-bit-delivery-cost is essential. I think it's also >essential that they have some basic familiarity with the different >ways IXPs can fail, or fail to thrive, so that they can avoid >mistakes others have made in the past. Over-spending, particularly >on switches, is a huge killer of IXPs. Under-provisioning of >circuits to the IXP is another big mistake. Failure to encourage >local content and hosting is another. Can you cite a few examples of an IXP going under because of overspending on switch hardware? You call this a "huge killer" so there must be dozens you can choose from. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From jay.hanke at mankatonetworks.com Fri Aug 23 14:06:50 2013 From: jay.hanke at mankatonetworks.com (Jay Hanke) Date: Fri, 23 Aug 2013 09:06:50 -0500 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <20130823105912.GB3108@burnout.tpb.net> References: <96CFCCF1-EF35-4CF6-8F00-2392BE72D214@gmail.com> <83227146-C0F2-430F-A7B9-970E96480D9C@pch.net> <8601BDBE-445A-46A3-AF35-B80D06C796DE@gmail.com> <-5109713474780003274@unknownmsgid> <48300247-6033-47C4-B5C4-C344D6CDD6FA@pch.net> <249E24C3-302B-4963-A3D9-55D46EC921FF@pch.net> <20130823105912.GB3108@burnout.tpb.net> Message-ID: On Fri, Aug 23, 2013 at 5:59 AM, Niels Bakker wrote: > >> Indeed. I think that ISPs who understand their business model well >> enough to understand the effect the IXP will have on their >> average-per-bit-delivery-cost is essential. I think it's also essential >> that they have some basic familiarity with the different ways IXPs can >> fail, or fail to thrive, so that they can avoid mistakes others have made >> in the past. Over-spending, particularly on switches, is a huge killer of >> IXPs. Under-provisioning of circuits to the IXP is another big mistake. >> Failure to encourage local content and hosting is another. >> > > Can you cite a few examples of an IXP going under because of overspending > on switch hardware? You call this a "huge killer" so there must be dozens > you can choose from.anke > Having recently been through the startup process at an independent non-profit IXP, I can see spending too much on hardware being a problem particularly on supporting the ongoing hardware/software maintenance on the switch. Something else to think about, if an exchange is given an endowment from from outside entity it might be harder to build the commitment levels of participants/volunteers because it's too easy to solve the problems with money as opposed to member contributions. We went through 3 switch upgrades in 2 years and IMHO it built a lot of community. Each IXP will have a set of faithful founders and the key is growing that group beyond the initial group before the founders lose interest and move on to bigger things. Particularly before connecting to the IXP makes business sense to a company that won't connect just because it's cool. When the exchange gets over the hump were companies are saving real money it is much easier to keep the ball rolling and the exchange growing. Many exchange points never make it to that level. Jay From BECHA at ripe.net Fri Aug 23 14:29:18 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 23 Aug 2013 16:29:18 +0200 Subject: Accessing RIS Routing Information Via RIPEstat In-Reply-To: <521770A5.3020003@ripe.net> References: <521770A5.3020003@ripe.net> Message-ID: <521771BE.3000506@ripe.net> Dear colleagues, (apologies for cross-posting) RIPE NCC's Routing Information Service (RIS) has been collecting global BGP routing information for 12 years now. During this period, many different interfaces to analyse and visualise accumulated data have been developed. In line with our long-term goals to provide more consolidated services, we will be integrating the RIS interface's tools and services into RIPEstat. More information about this is detailed in a new RIPE Labs article: https://labs.ripe.net/Members/fatemah_mafi/improved-routing-information-available-via-ripestat We invite NANOG community to comment on these upcoming changes via the MAT Working Group Mailing List: https://www.ripe.net/ripe/groups/wg/mat Please submit any urgent requests for additional features via email to stat at ripe.net by 20 September 2013 so that we can implement these along with the planned migration of tools and features. Any feedback received after this date will be considered feature requests, and added to the RIPEstat Roadmap: http://roadmap.ripe.net/ripe-stat/ We look forward to your feedback. Regards, Vesna -- Vesna Manojlovic BECHA at ripe.net Senior Community Builder @Ms_Measurements for Measurements Tools RIPE NCC http://ripe.net From mark at bernoullinetworks.com Fri Aug 23 14:56:37 2013 From: mark at bernoullinetworks.com (Mark Leonard) Date: Fri, 23 Aug 2013 08:56:37 -0600 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: Message-ID: On Tue, Aug 20, 2013 at 6:52 AM, Joe Abley wrote: > What CIRA is doing is providing support in the areas where previous > efforts have struggled, providing hardware, accounts payable, legal, help > with incorporation and forming sensible bylaws and stimulating local > discussion and interest. My perspective is that they have done a great job > in Calgary and Montr?al. It sounds like the approach in Vancouver (engage > with existing efforts, see where CIRA can help) is following the same path. > What has CIRA done in Calgary? From corbe at corbe.net Fri Aug 23 15:13:15 2013 From: corbe at corbe.net (Daniel Corbe) Date: Fri, 23 Aug 2013 11:13:15 -0400 Subject: Level3 IP contact Message-ID: <2DEBD5C3821F4E48B3444E496C19B224@poopsackHD> If anyone from Level3 here that might be able to help me solve a transit issue out of east Africa, please contact me off-list. From bill at mbix.ca Fri Aug 23 15:54:56 2013 From: bill at mbix.ca (Bill Reid) Date: Fri, 23 Aug 2013 10:54:56 -0500 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: Message-ID: <521785D0.2060307@mbix.ca> On 23/08/13 09:56, Mark Leonard wrote: > On Tue, Aug 20, 2013 at 6:52 AM, Joe Abley wrote: > >> What CIRA is doing is providing support in the areas where previous >> efforts have struggled, providing hardware, accounts payable, legal, help >> with incorporation and forming sensible bylaws and stimulating local >> discussion and interest. My perspective is that they have done a great job >> in Calgary and Montr?al. It sounds like the approach in Vancouver (engage >> with existing efforts, see where CIRA can help) is following the same path. >> > > What has CIRA done in Calgary? > CIRA has done a great job in Winnipeg and Montreal. Nothing in Calgary. From jacques.latour at cira.ca Fri Aug 23 17:30:46 2013 From: jacques.latour at cira.ca (Jacques Latour) Date: Fri, 23 Aug 2013 13:30:46 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: <521785D0.2060307@mbix.ca> References: <521785D0.2060307@mbix.ca> Message-ID: Bill, not true. Following on our vision for Canada to have an IXP in every major city, specifically for Calgary, CIRA worked with CYBERA to organize a town hall meeting in Calgary, on September 14, 2013. At the meeting, we had interested members of the community (Content delivery, ISP, government, R&E, CIRA, others) together to start the development of a new IXP in Calgary. Cybera being local, they took the lead in working with the community members in setting up governance, technical architecture, location, etc... CIRA actively participated in the various committees. CIRA is planning the deployment of equipment for the IXP, a .ca DNS Anycast stack, NTP servers and space for M-Lab nodes. We also work with PCH to have a PCH anycast stack installed in Calgary. We talked to Akamai and Google to be part of the Calgary IXP. HE actually did build to Data Hive (Preferred data center in Calgary). Doing our part in trying to get as much content, ISP, eyeballs, core internet services to be present at IXP. The AlbertaIX is cash poor at that moment in time so CIRA was looking at options to fund equipment or provide start-up grants, nothing was done up to now with respect to providing equipment or funds. Note: CIRA's job is not to go in and put a switch and leave. CIRA works with the community to get the IXP up and running. We have criteria to participate, the IXP must be a member based, vendor neutral non-profit organization with a viable trusted community to operate and sustain an IXP. CIRA is acting as a catalyst, not a doer. The community is the doer. Ask the people in Winnipeg www.mbix.ca and Montreal qix.ca . We are planning the launch of mbix this September as well. This is an example where the IXP build was successful. Back to Calgary, something special occurred, while we were all working on setting up AlbertaIX (we started fast but the pace slowed down significantly), a new IXP came to 'life' YYCIX in Data Hive, yycix.ca. Long story short, CIRA is waiting for things to settle before we continue providing more support and invest in deployment our .CA infrastructure. When the "dust" settles, we will deploy our .ca infrastructure and be a member of the communities (peer). There's a chance we're going to have two IXPs in Calgary, hopefully they would be in the same data center to leverage our investment, if we have two, then it's going to make it confusing for the new potential peers to pick the right one or both. All in all, CIRA's objective was to have 1 IXP in Calgary, we have one now, perhaps 2 in the future, so mission accomplished. It's up to the community to get their act together (no pun intended), and if they need our help, then we're there to help with governance, funding, technical expertise, etc... Also, we're doing our best with our limited resources, Jack (NOTE: English not my first language, if you're not sure what I mean, ask me, don't assume) > -----Original Message----- > From: Bill Reid [mailto:bill at mbix.ca] > Sent: August-23-13 11:55 AM > To: nanog at nanog.org > Subject: Re: Vancouver IXP - VanTX - BCNet > > On 23/08/13 09:56, Mark Leonard wrote: > > On Tue, Aug 20, 2013 at 6:52 AM, Joe Abley wrote: > > > >> What CIRA is doing is providing support in the areas where previous > >> efforts have struggled, providing hardware, accounts payable, legal, > >> help with incorporation and forming sensible bylaws and stimulating > >> local discussion and interest. My perspective is that they have done > >> a great job in Calgary and Montr?al. It sounds like the approach in > >> Vancouver (engage with existing efforts, see where CIRA can help) is > following the same path. > >> > > > > What has CIRA done in Calgary? > > > CIRA has done a great job in Winnipeg and Montreal. Nothing in Calgary. From cscora at apnic.net Fri Aug 23 18:33:55 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 Aug 2013 04:33:55 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201308231833.r7NIXt8f031957@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 24 Aug, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 463793 Prefixes after maximum aggregation: 187304 Deaggregation factor: 2.48 Unique aggregates announced to Internet: 230444 Total ASes present in the Internet Routing Table: 44792 Prefixes per ASN: 10.35 Origin-only ASes present in the Internet Routing Table: 35028 Origin ASes announcing only one prefix: 16228 Transit ASes present in the Internet Routing Table: 5898 Transit-only ASes present in the Internet Routing Table: 174 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 29 Max AS path prepend of ASN ( 19037) 22 Prefixes from unregistered ASNs in the Routing Table: 4740 Unregistered ASNs in the Routing Table: 1572 Number of 32-bit ASNs allocated by the RIRs: 4971 Number of 32-bit ASNs visible in the Routing Table: 3866 Prefixes from 32-bit ASNs in the Routing Table: 11761 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 320 Number of addresses announced to Internet: 2636723020 Equivalent to 157 /8s, 41 /16s and 51 /24s Percentage of available address space announced: 71.2 Percentage of allocated address space announced: 71.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.9 Total number of prefixes smaller than registry allocations: 162609 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 109696 Total APNIC prefixes after maximum aggregation: 33394 APNIC Deaggregation factor: 3.28 Prefixes being announced from the APNIC address blocks: 111547 Unique aggregates announced from the APNIC address blocks: 46487 APNIC Region origin ASes present in the Internet Routing Table: 4868 APNIC Prefixes per ASN: 22.91 APNIC Region origin ASes announcing only one prefix: 1230 APNIC Region transit ASes present in the Internet Routing Table: 824 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 647 Number of APNIC addresses announced to Internet: 726650112 Equivalent to 43 /8s, 79 /16s and 205 /24s Percentage of available APNIC address space announced: 84.9 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: 161354 Total ARIN prefixes after maximum aggregation: 80971 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 161884 Unique aggregates announced from the ARIN address blocks: 75042 ARIN Region origin ASes present in the Internet Routing Table: 15831 ARIN Prefixes per ASN: 10.23 ARIN Region origin ASes announcing only one prefix: 6007 ARIN Region transit ASes present in the Internet Routing Table: 1670 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: 1070483456 Equivalent to 63 /8s, 206 /16s and 72 /24s Percentage of available ARIN address space announced: 56.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 118625 Total RIPE prefixes after maximum aggregation: 60768 RIPE Deaggregation factor: 1.95 Prefixes being announced from the RIPE address blocks: 122478 Unique aggregates announced from the RIPE address blocks: 79045 RIPE Region origin ASes present in the Internet Routing Table: 17370 RIPE Prefixes per ASN: 7.05 RIPE Region origin ASes announcing only one prefix: 8230 RIPE Region transit ASes present in the Internet Routing Table: 2811 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2386 Number of RIPE addresses announced to Internet: 657049124 Equivalent to 39 /8s, 41 /16s and 198 /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: 50637 Total LACNIC prefixes after maximum aggregation: 9581 LACNIC Deaggregation factor: 5.29 Prefixes being announced from the LACNIC address blocks: 55338 Unique aggregates announced from the LACNIC address blocks: 25644 LACNIC Region origin ASes present in the Internet Routing Table: 2003 LACNIC Prefixes per ASN: 27.63 LACNIC Region origin ASes announcing only one prefix: 568 LACNIC Region transit ASes present in the Internet Routing Table: 367 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: 808 Number of LACNIC addresses announced to Internet: 135501864 Equivalent to 8 /8s, 19 /16s and 152 /24s Percentage of available LACNIC address space announced: 80.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 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: 11632 Total AfriNIC prefixes after maximum aggregation: 2548 AfriNIC Deaggregation factor: 4.57 Prefixes being announced from the AfriNIC address blocks: 12226 Unique aggregates announced from the AfriNIC address blocks: 3928 AfriNIC Region origin ASes present in the Internet Routing Table: 651 AfriNIC Prefixes per ASN: 18.78 AfriNIC Region origin ASes announcing only one prefix: 193 AfriNIC Region transit ASes present in the Internet Routing Table: 135 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46605824 Equivalent to 2 /8s, 199 /16s and 38 /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 2922 11561 921 Korea Telecom (KIX) 17974 2656 871 92 PT TELEKOMUNIKASI INDONESIA 7545 2062 321 113 TPG Internet Pty Ltd 4755 1761 391 189 TATA Communications formerly 9829 1530 1221 45 BSNL National Internet Backbo 9583 1226 92 505 Sify Limited 9498 1174 309 70 BHARTI Airtel Ltd. 4808 1152 2126 335 CNCGROUP IP network: China169 7552 1139 1080 13 Vietel Corporation 24560 1089 394 160 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 2976 3689 62 bellsouth.net, inc. 18566 2065 382 184 Covad Communications 22773 2039 2933 123 Cox Communications, Inc. 1785 2006 679 125 PaeTec Communications, Inc. 20115 1674 1645 627 Charter Communications 4323 1621 1105 408 Time Warner Telecom 701 1522 11103 798 UUNET Technologies, Inc. 30036 1346 301 643 Mediacom Communications Corp 7018 1312 11293 829 AT&T WorldNet Services 11492 1223 218 361 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 1585 544 16 Corbina telecom 34984 1306 244 223 BILISIM TELEKOM 31148 979 43 18 FreeNet ISP 20940 971 349 749 Akamai Technologies European 2118 962 97 13 EUnet/RELCOM Autonomous Syste 6830 898 2371 429 UPC Distribution Services 13188 845 99 71 Educational Network 8551 747 370 41 Bezeq International 12479 687 797 53 Uni2 Autonomous System 58113 541 55 339 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 3163 1682 108 NET Servicos de Comunicao S.A 10620 2673 425 219 TVCABLE BOGOTA 7303 1732 1157 222 Telecom Argentina Stet-France 18881 1454 844 20 Global Village Telecom 8151 1280 2767 390 UniNet S.A. de C.V. 11830 945 364 15 Instituto Costarricense de El 27947 837 94 91 Telconet S.A 6503 787 434 63 AVANTEL, S.A. 3816 721 302 83 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 1861 112 5 MOBITEL 24863 871 274 30 LINKdotNET AS number 6713 543 633 26 Itissalat Al-MAGHRIB 8452 437 956 9 TEDATA 24835 291 80 8 RAYA Telecom - Egypt 3741 258 921 217 The Internet Solution 15706 221 32 6 Sudatel Internet Exchange Aut 29571 220 17 12 Ci Telecom Autonomous system 36992 220 501 29 Etisalat MISR 12258 193 28 71 Vodacom Internet Company 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 28573 3163 1682 108 NET Servicos de Comunicao S.A 6389 2976 3689 62 bellsouth.net, inc. 4766 2922 11561 921 Korea Telecom (KIX) 10620 2673 425 219 TVCABLE BOGOTA 17974 2656 871 92 PT TELEKOMUNIKASI INDONESIA 18566 2065 382 184 Covad Communications 7545 2062 321 113 TPG Internet Pty Ltd 22773 2039 2933 123 Cox Communications, Inc. 1785 2006 679 125 PaeTec Communications, Inc. 36998 1861 112 5 MOBITEL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2976 2914 bellsouth.net, inc. 17974 2656 2564 PT TELEKOMUNIKASI INDONESIA 10620 2673 2454 TVCABLE BOGOTA 4766 2922 2001 Korea Telecom (KIX) 7545 2062 1949 TPG Internet Pty Ltd 22773 2039 1916 Cox Communications, Inc. 18566 2065 1881 Covad Communications 1785 2006 1881 PaeTec Communications, Inc. 36998 1861 1856 MOBITEL 4755 1761 1572 TATA Communications formerly 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 30621 UNALLOCATED 12.151.74.0/23 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 100.100.0.0/24 4847 China Networks Inter-Exchange Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.90.128.0/18 27418 OUTOFWALL INC. 23.91.0.0/19 40676 Psychz Networks 23.91.32.0/19 36315 Servpac Inc. 23.92.16.0/21 8001 Net Access Corporation 23.92.24.0/22 6939 Hurricane Electric 23.92.48.0/20 62471 SupremeBytes, LLC 23.92.64.0/24 54540 Incero LLC 23.92.65.0/24 54540 Incero LLC 23.92.66.0/24 54540 Incero LLC 23.92.67.0/24 54540 Incero LLC 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:93 /12:250 /13:480 /14:906 /15:1616 /16:12745 /17:6658 /18:11054 /19:22680 /20:32290 /21:34899 /22:48966 /23:42842 /24:245731 /25:877 /26:1012 /27:481 /28:44 /29:75 /30:18 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2016 2065 Covad Communications 36998 1826 1861 MOBITEL 6389 1711 2976 bellsouth.net, inc. 22773 1328 2039 Cox Communications, Inc. 8402 1321 1585 Corbina telecom 30036 1209 1346 Mediacom Communications Corp 11492 1184 1223 Cable One 1785 1079 2006 PaeTec Communications, Inc. 6983 1023 1151 ITC^Deltacom 10620 991 2673 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:800 2:718 3:3 4:19 5:913 6:17 8:600 12:1894 13:2 14:872 15:11 16:3 17:11 18:19 20:18 23:360 24:1739 27:1551 31:1410 32:45 33:2 34:5 36:70 37:1826 38:901 39:2 40:180 41:3252 42:243 44:9 46:1981 47:3 49:661 50:842 52:12 54:37 55:6 57:26 58:1169 59:616 60:332 61:1400 62:1176 63:1999 64:4550 65:2247 66:4199 67:2078 68:1092 69:3305 70:864 71:495 72:2009 74:2540 75:325 76:306 77:1159 78:1115 79:623 80:1308 81:1021 82:647 83:584 84:571 85:1219 86:482 87:1051 88:539 89:1821 90:158 91:5581 92:641 93:1661 94:2022 95:1550 96:587 97:347 98:1038 99:44 100:29 101:597 103:3181 105:519 106:138 107:210 108:498 109:1883 110:946 111:1104 112:568 113:792 114:729 115:1029 116:964 117:806 118:1120 119:1289 120:367 121:740 122:1864 123:1247 124:1373 125:1348 128:607 129:223 130:310 131:671 132:346 133:160 134:279 135:67 136:267 137:268 138:347 139:189 140:200 141:322 142:548 143:389 144:499 145:95 146:531 147:481 148:673 149:350 150:151 151:560 152:416 153:194 154:30 155:483 156:272 157:406 158:282 159:748 160:352 161:457 162:595 163:221 164:628 165:568 166:255 167:603 168:1030 169:126 170:1074 171:191 172:25 173:1583 174:515 175:496 176:1190 177:2182 178:1903 179:102 180:1525 181:648 182:1226 183:441 184:664 185:769 186:2459 187:1407 188:1893 189:1283 190:6891 192:6946 193:5541 194:4605 195:3603 196:1333 197:1009 198:4612 199:5426 200:5981 201:2571 202:8890 203:8821 204:4530 205:2604 206:2834 207:2914 208:3997 209:3640 210:2913 211:1557 212:2262 213:2034 214:924 215:100 216:5309 217:1653 218:619 219:304 220:1277 221:553 222:324 223:504 End of report From mark at bernoullinetworks.com Fri Aug 23 19:34:38 2013 From: mark at bernoullinetworks.com (Mark Leonard) Date: Fri, 23 Aug 2013 13:34:38 -0600 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <521785D0.2060307@mbix.ca> Message-ID: Is Bill Sandiford a member of the board of both CIRA[1] and AlbertaIX[5]? Since AlbertaIX has no peers [2,3] is CIRA now going to investigate options to help fund YYCIX which does have peers[3,4]? References: [1] http://www.cira.ca/about-cira/about-the-board/meet-the-board/ [2] http://www.albertaix.ca/peers/ [3] https://prefix.pch.net/applications/ixpdir/ [4] http://yycix.ca/peers.html [5] http://www.tcpiputils.com/browse/as/54982 On Fri, Aug 23, 2013 at 11:30 AM, Jacques Latour wrote: > Bill, not true. > > Following on our vision for Canada to have an IXP in every major city, > specifically for Calgary, CIRA worked with CYBERA to organize a town hall > meeting in Calgary, on September 14, 2013. At the meeting, we had > interested members of the community (Content delivery, ISP, government, > R&E, CIRA, others) together to start the development of a new IXP in > Calgary. > > Cybera being local, they took the lead in working with the community > members in setting up governance, technical architecture, location, etc... > CIRA actively participated in the various committees. > > CIRA is planning the deployment of equipment for the IXP, a .ca DNS > Anycast stack, NTP servers and space for M-Lab nodes. We also work with > PCH to have a PCH anycast stack installed in Calgary. We talked to Akamai > and Google to be part of the Calgary IXP. HE actually did build to Data > Hive (Preferred data center in Calgary). Doing our part in trying to get > as much content, ISP, eyeballs, core internet services to be present at > IXP. The AlbertaIX is cash poor at that moment in time so CIRA was looking > at options to fund equipment or provide start-up grants, nothing was done > up to now with respect to providing equipment or funds. > > Note: CIRA's job is not to go in and put a switch and leave. CIRA works > with the community to get the IXP up and running. We have criteria to > participate, the IXP must be a member based, vendor neutral non-profit > organization with a viable trusted community to operate and sustain an IXP. > CIRA is acting as a catalyst, not a doer. The community is the doer. Ask > the people in Winnipeg www.mbix.ca and Montreal qix.ca . We are planning > the launch of mbix this September as well. This is an example where the > IXP build was successful. > > Back to Calgary, something special occurred, while we were all working on > setting up AlbertaIX (we started fast but the pace slowed down > significantly), a new IXP came to 'life' YYCIX in Data Hive, yycix.ca. > Long story short, CIRA is waiting for things to settle before we continue > providing more support and invest in deployment our .CA infrastructure. > When the "dust" settles, we will deploy our .ca infrastructure and be a > member of the communities (peer). > > There's a chance we're going to have two IXPs in Calgary, hopefully they > would be in the same data center to leverage our investment, if we have > two, then it's going to make it confusing for the new potential peers to > pick the right one or both. > > All in all, CIRA's objective was to have 1 IXP in Calgary, we have one > now, perhaps 2 in the future, so mission accomplished. It's up to the > community to get their act together (no pun intended), and if they need our > help, then we're there to help with governance, funding, technical > expertise, etc... > > Also, we're doing our best with our limited resources, > > Jack > > (NOTE: English not my first language, if you're not sure what I mean, ask > me, don't assume) > > > > > -----Original Message----- > > From: Bill Reid [mailto:bill at mbix.ca] > > Sent: August-23-13 11:55 AM > > To: nanog at nanog.org > > Subject: Re: Vancouver IXP - VanTX - BCNet > > > > On 23/08/13 09:56, Mark Leonard wrote: > > > On Tue, Aug 20, 2013 at 6:52 AM, Joe Abley wrote: > > > > > >> What CIRA is doing is providing support in the areas where previous > > >> efforts have struggled, providing hardware, accounts payable, legal, > > >> help with incorporation and forming sensible bylaws and stimulating > > >> local discussion and interest. My perspective is that they have done > > >> a great job in Calgary and Montr?al. It sounds like the approach in > > >> Vancouver (engage with existing efforts, see where CIRA can help) is > > following the same path. > > >> > > > > > > What has CIRA done in Calgary? > > > > > CIRA has done a great job in Winnipeg and Montreal. Nothing in Calgary. > > > From cidr-report at potaroo.net Fri Aug 23 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Aug 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201308232200.r7NM00qI086138@wattle.apnic.net> This report has been generated at Fri Aug 23 21:13:28 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 16-08-13 475291 269969 17-08-13 474905 269949 18-08-13 474745 269992 19-08-13 474719 270214 20-08-13 475043 270108 21-08-13 475543 269812 22-08-13 474747 269663 23-08-13 475628 270260 AS Summary 44954 Number of ASes in routing system 18509 Number of ASes announcing only one prefix 4230 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 117780704 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'). --- 23Aug13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 476252 270281 205971 43.2% All ASes AS6389 2976 65 2911 97.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS17974 2661 104 2557 96.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS28573 3164 722 2442 77.2% NET Servi?os de Comunica??o S.A. AS7029 4230 2070 2160 51.1% WINDSTREAM - Windstream Communications Inc AS4766 2922 936 1986 68.0% KIXS-AS-KR Korea Telecom AS22773 2040 263 1777 87.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2065 468 1597 77.3% COVAD - Covad Communications Co. AS10620 2673 1077 1596 59.7% Telmex Colombia S.A. AS4323 2988 1540 1448 48.5% TWTC - tw telecom holdings, inc. AS36998 1862 433 1429 76.7% SDN-MOBITEL AS18881 1454 70 1384 95.2% Global Village Telecom AS7303 1732 454 1278 73.8% Telecom Argentina S.A. AS4755 1759 583 1176 66.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1161 133 1028 88.5% VIETEL-AS-AP Vietel Corporation AS22561 1217 226 991 81.4% DIGITAL-TELEPORT - Digital Teleport Inc. AS2118 962 88 874 90.9% RELCOM-AS OOO "NPO Relcom" AS1785 2006 1157 849 42.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS11830 946 117 829 87.6% Instituto Costarricense de Electricidad y Telecom. AS18101 983 178 805 81.9% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1152 395 757 65.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7545 2066 1337 729 35.3% TPG-INTERNET-AP TPG Telecom Limited AS701 1523 802 721 47.3% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS13977 850 135 715 84.1% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS15003 847 157 690 81.5% NOBIS-TECH - Nobis Technology Group, LLC AS6147 739 51 688 93.1% Telefonica del Peru S.A.A. AS8151 1285 601 684 53.2% Uninet S.A. de C.V. AS855 736 55 681 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6983 1151 483 668 58.0% ITCDELTA - ITC^Deltacom AS24560 1089 428 661 60.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS31148 979 339 640 65.4% FREENET-AS Freenet Ltd. Total 52218 15467 36751 70.4% Top 30 total Possible Bogus Routes 27.54.116.0/22 AS55452 27.54.116.0/24 AS55452 27.54.119.0/24 AS55452 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.182.96.0/23 AS15830 TELECITY-LON TELECITYGROUP INTERNATIONAL LIMITED 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. 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 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.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 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 80.68.144.0/20 AS33982 82.103.0.0/18 AS30901 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.205.188.0/22 AS47983 91.207.200.0/23 AS48523 91.209.93.0/24 AS48523 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 96.45.48.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.49.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.50.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.51.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.52.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.53.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.54.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.55.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.56.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.57.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.58.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.59.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.60.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.61.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.62.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.63.0/24 AS33475 RSN-1 - RockSolid Network, 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.224.163.0/24 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 103.224.188.0/23 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 109.71.156.0/23 AS21246 IPKO-AS Ipko Telecommunications LLC 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.40.184.0/24 AS19821 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.144.0/20 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 185.33.228.0/22 AS28870 PLUSINFO-AS PlusInfo Ltd 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 193.33.66.0/23 AS39874 193.33.112.0/23 AS8586 OBSL-AS TalkTalk Communications Limited 193.34.108.0/22 AS41984 193.109.15.0/24 AS12690 MKSNET-AS MKS Autonomous System 193.109.224.0/24 AS47427 193.111.125.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.111.155.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 194.50.82.0/24 AS16276 OVH OVH Systems 194.79.48.0/22 AS39117 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.117.250.0/23 AS41412 MIVITEC-AS MIVITEC GmbH 194.126.219.0/24 AS34545 194.169.237.0/24 AS12968 CDP Netia SA 195.28.7.0/24 AS8717 SPECTRUMNET MOBILTEL EAD 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 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.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 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 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.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 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.68.244.0/22 AS17140 208.68.244.0/23 AS17140 208.68.246.0/23 AS17140 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 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.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 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.90.64.0/22 AS16415 PRCNET-DOM - Precision Response Corporation 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.160.81.0/24 AS36184 209.160.83.0/24 AS36184 209.160.84.0/24 AS36184 209.160.86.0/24 AS36184 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.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.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.151.192.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.151.200.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 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 Aug 23 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Aug 2013 22:00:00 GMT Subject: BGP Update Report Message-ID: <201308232200.r7NM005A086152@wattle.apnic.net> BGP Update Report Interval: 15-Aug-13 -to- 22-Aug-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 33779 1.8% 21.9 -- CORBINA-AS OJSC "Vimpelcom" 2 - AS6983 32729 1.8% 132.5 -- ITCDELTA - ITC^Deltacom 3 - AS3593 31766 1.7% 4538.0 -- FRONTIER-EPIX - Frontier Communications of America, Inc. 4 - AS28573 30250 1.6% 17.0 -- NET Servi?os de Comunica??o S.A. 5 - AS9829 29482 1.6% 32.4 -- BSNL-NIB National Internet Backbone 6 - AS18403 22556 1.2% 35.5 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 7 - AS36998 21890 1.2% 12.4 -- SDN-MOBITEL 8 - AS9416 18501 1.0% 451.2 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 9 - AS17974 16285 0.9% 6.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 10 - AS4775 15584 0.8% 362.4 -- GLOBE-TELECOM-AS Globe Telecoms 11 - AS19429 14823 0.8% 166.6 -- ETB - Colombia 12 - AS647 12249 0.7% 113.4 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 13 - AS8151 12142 0.7% 6.4 -- Uninet S.A. de C.V. 14 - AS7552 11931 0.7% 10.3 -- VIETEL-AS-AP Vietel Corporation 15 - AS2118 11851 0.6% 8.6 -- RELCOM-AS OOO "NPO Relcom" 16 - AS15003 11711 0.6% 29.6 -- NOBIS-TECH - Nobis Technology Group, LLC 17 - AS27738 11280 0.6% 19.6 -- Ecuadortelecom S.A. 18 - AS48612 10097 0.6% 721.2 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 19 - AS38654 10036 0.5% 10036.0 -- INES-NETWORK INES Corporation. 20 - AS33363 10016 0.5% 6.2 -- BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS38654 10036 0.5% 10036.0 -- INES-NETWORK INES Corporation. 2 - AS6629 8791 0.5% 8791.0 -- NOAA-AS - NOAA 3 - AS42334 5096 0.3% 5096.0 -- BBP-AS Broadband Plus s.a.l. 4 - AS33158 4657 0.2% 4657.0 -- DATA-SERVICES-INC - Data Services Incorporated 5 - AS3593 31766 1.7% 4538.0 -- FRONTIER-EPIX - Frontier Communications of America, Inc. 6 - AS19406 4507 0.2% 4507.0 -- TWRS-MA - Towerstream I, Inc. 7 - AS6174 7063 0.4% 3531.5 -- SPRINTLINK8 - Sprint 8 - AS24772 1707 0.1% 1707.0 -- ASIP-AIE-AS Agrupacion de dervicios de internet y prensa AIE 9 - AS37425 4683 0.2% 1561.0 -- Somcable 10 - AS37367 1394 0.1% 1394.0 -- CALLKEY 11 - AS33648 4005 0.2% 1335.0 -- ELEPHANT - ColoFlorida / Elephant Outlook 12 - AS19111 1128 0.1% 1128.0 -- NATURES-BOUN - NBTY, Inc. 13 - AS1880 4610 0.2% 922.0 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 14 - AS55635 914 0.1% 914.0 -- LOCAL-PEERING-SERVENET-AP ServeNet Solution Limited Partnership 15 - AS19301 1698 0.1% 849.0 -- CERIDIAN-TAX - CERIDIAN TAX SERVICE, INC 16 - AS3 1558 0.1% 223.0 -- CMED-AS Cmed Technology Ltd 17 - AS48612 10097 0.6% 721.2 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 18 - AS10445 5495 0.3% 686.9 -- HTG - Huntleigh Telcom 19 - AS45413 4657 0.2% 665.3 -- SERVENET-AS-TH-AP ServeNET Solution Limited Partnership 20 - AS53008 2571 0.1% 642.8 -- Pontal Cabo Ltda TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 150.39.0.0/16 10036 0.5% AS38654 -- INES-NETWORK INES Corporation. 2 - 92.246.207.0/24 10000 0.5% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 3 - 203.118.232.0/21 9285 0.5% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 4 - 203.118.224.0/21 9138 0.5% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 5 - 192.58.232.0/24 8791 0.4% AS6629 -- NOAA-AS - NOAA 6 - 112.203.192.0/19 7962 0.4% AS9299 -- IPG-AS-AP Philippine Long Distance Telephone Company 7 - 120.28.62.0/24 7745 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 8 - 202.154.17.0/24 7712 0.4% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 9 - 222.127.0.0/24 7693 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 10 - 61.95.239.0/24 7680 0.4% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 11 - 199.224.95.0/24 6353 0.3% AS3593 -- FRONTIER-EPIX - Frontier Communications of America, Inc. 12 - 199.224.82.0/24 6352 0.3% AS3593 -- FRONTIER-EPIX - Frontier Communications of America, Inc. 13 - 205.238.218.0/24 6351 0.3% AS3593 -- FRONTIER-EPIX - Frontier Communications of America, Inc. 14 - 199.224.78.0/24 6350 0.3% AS3593 -- FRONTIER-EPIX - Frontier Communications of America, Inc. 15 - 209.74.11.0/24 6350 0.3% AS3593 -- FRONTIER-EPIX - Frontier Communications of America, Inc. 16 - 194.71.90.0/24 6174 0.3% AS35041 -- NET-CRYSTONE-STHLM Crystone AB 17 - 115.170.128.0/17 5118 0.3% AS4847 -- CNIX-AP China Networks Inter-Exchange 18 - 62.84.76.0/24 5096 0.3% AS42334 -- BBP-AS Broadband Plus s.a.l. 19 - 12.183.21.0/24 4657 0.2% AS33158 -- DATA-SERVICES-INC - Data Services Incorporated 20 - 41.79.196.0/24 4645 0.2% AS37425 -- Somcable 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 ml at kenweb.org Fri Aug 23 22:33:40 2013 From: ml at kenweb.org (ML) Date: Fri, 23 Aug 2013 18:33:40 -0400 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <521785D0.2060307@mbix.ca> Message-ID: <5217E344.9040205@kenweb.org> On 8/23/2013 1:30 PM, Jacques Latour wrote: > Bill, not true. > > Following on our vision for Canada to have an IXP in every major city, specifically for Calgary, CIRA worked with CYBERA to organize a town hall meeting in Calgary, on September 14, 2013. At the meeting, we had interested members of the community (Content delivery, ISP, government, R&E, CIRA, others) together to start the development of a new IXP in Calgary. > > Cybera being local, they took the lead in working with the community members in setting up governance, technical architecture, location, etc... CIRA actively participated in the various committees. > > CIRA is planning the deployment of equipment for the IXP, a .ca DNS Anycast stack, NTP servers and space for M-Lab nodes. We also work with PCH to have a PCH anycast stack installed in Calgary. We talked to Akamai and Google to be part of the Calgary IXP. HE actually did build to Data Hive (Preferred data center in Calgary). Doing our part in trying to get as much content, ISP, eyeballs, core internet services to be present at IXP. The AlbertaIX is cash poor at that moment in time so CIRA was looking at options to fund equipment or provide start-up grants, nothing was done up to now with respect to providing equipment or funds. > > Note: CIRA's job is not to go in and put a switch and leave. CIRA works with the community to get the IXP up and running. We have criteria to participate, the IXP must be a member based, vendor neutral non-profit organization with a viable trusted community to operate and sustain an IXP. CIRA is acting as a catalyst, not a doer. The community is the doer. Ask the people in Winnipeg www.mbix.ca and Montreal qix.ca . We are planning the launch of mbix this September as well. This is an example where the IXP build was successful. > > Back to Calgary, something special occurred, while we were all working on setting up AlbertaIX (we started fast but the pace slowed down significantly), a new IXP came to 'life' YYCIX in Data Hive, yycix.ca. Long story short, CIRA is waiting for things to settle before we continue providing more support and invest in deployment our .CA infrastructure. When the "dust" settles, we will deploy our .ca infrastructure and be a member of the communities (peer). > > There's a chance we're going to have two IXPs in Calgary, hopefully they would be in the same data center to leverage our investment, if we have two, then it's going to make it confusing for the new potential peers to pick the right one or both. > > All in all, CIRA's objective was to have 1 IXP in Calgary, we have one now, perhaps 2 in the future, so mission accomplished. It's up to the community to get their act together (no pun intended), and if they need our help, then we're there to help with governance, funding, technical expertise, etc... > What is the purpose of creating a second IXP in the same colo space in Calgary? From what I can gather YYCIX is giving away the first gigport for now. Unless CIRA is negotiating cheap transport/colospace/power/cross connects in Datahive, what is the point? From dave at temk.in Sat Aug 24 12:59:49 2013 From: dave at temk.in (David Temkin) Date: Sat, 24 Aug 2013 08:59:49 -0400 Subject: NANOG 59 - Important Schedule Notice & Call For Presentations. Please read! In-Reply-To: References: Message-ID: Reminder to all: Presentation slides are due on Friday, August 30th. Talks without slides may be declined at that point. Regards, -Dave For the NANOG Program Committee On Mon, Jun 17, 2013 at 3:33 PM, David Temkin wrote: > NANOG Community, > > I hope everyone enjoyed New Orleans as much as I did! It's truly one of > my favorite cities in the world. Fresh off a great meeting, we're already > starting to get ready for NANOG 59 in Phoenix. If you have a topic you'd > like to speak about, the program committee would love to consider it. > Please watch http://www.nanog.org/meetings/nanog59/callforpresentations for > more information. > > After considering feedback from members, speakers, ARIN, and sponsors we > have decided to make a small tweak to the program timing at NANOG 59. We > will continue with the Monday-Wednesday format, however we will move the > ARIN Track and Tutorials to Tuesday morning, highlighting their importance > to the program. The program will begin on Monday morning at 10:00AM > followed by our popular Newcomers Lunch. The exact schedule layout can be > found at http://www.nanog.org/meetings/nanog59/preagenda and is also > attached in JPG format to this email. > > > If you wish to submit a presentation, please keep these important dates > in mind: > > > Presentation Abstracts and Draft Slides Due: 16-Aug-2013 > Slides Due: > 30-Aug-2013 > Topic List Posted: > 06-Sep-2013 > Final Agenda Published: > 27-Sep-2013 > > Please submit your materials to http://pc.nanog.org > > Looking forward to seeing everyone in Phoenix! > > -Dave Temkin > > (Chair, NANOG Program Committee) > > From koalafil at gmail.com Sat Aug 24 19:31:08 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Sat, 24 Aug 2013 21:31:08 +0200 Subject: Last Call and Draft program for RIPE 67 References: Message-ID: Dear Colleagues, A list of currently accepted RIPE 67 Plenary talks, BoFs, Tutorials and Workshops is now published at: https://ripe67.ripe.net/programme/meeting-plan/draft-programme/ There are still few slots remaining for a final RIPE 67 programme and RIPE Programme Committee will accept new proposals until 9 September 2013. This is our last call for you to submit your proposals. Kind regards Filiz Yilmaz for RIPE Programme Committee Begin forwarded message: > From: Filiz Yilmaz > Subject: Updated CFP for RIPE 67 > Date: 12 Jul 2013 11:22:52 GMT+02:00 > To: "ripe-list at ripe.net" > > Dear colleagues, > > RIPE PC is now also accepting "Workshop" proposals for RIPE 67. > > Please find the updated CFP with pointers to all possible presentation formats below and at: > https://ripe67.ripe.net/programme/cfp/ > > Note that the deadline for submissions is still 4 August 2013. > > Kind regards > > Filiz Yilmaz > Chair, RIPE Programme Committee > http://www.ripe.net/ripe/meetings/ripe-meetings/pc > > ------------------ > > Call for Presentations > > A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. > > RIPE 67 will take place from 14-18 October 2013 in Athens, Greece. > > The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 67. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: > > ? IPv6 deployment > ? Managing IPv4 scarcity in operations > ? Commercial transactions of IPv4 addresses > ? Data centre technologies > ? Network and DNS operations > ? Internet governance and regulatory practices > ? Network and routing security > ? Content delivery > ? Internet peering and mobile data exchange > > Submissions > > RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. > > The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at > https://ripe67.ripe.net/programme/i-want-to-present/presentation-formats/ > > Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. > > In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for ?lightning talks?, which are selected immediately before or during the conference. > > The following general requirements apply: > > ? Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 4 August 2013, using the meeting submission system (https://ripe67.ripe.net/submit-topic/). Proposals submitted after this date will be considered on a space-available basis. > > ? Lightning talks should also be submitted using the meeting submission system (https://ripe67.ripe.net/submit-topic/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice ? in some cases on the same day but often one day prior to the relevant session. > > ? Presenters should indicate how much time they will require. See more information on time slot allocations per presentation format (https://ripe67.ripe.net/programme/i-want-to-present/presentation-formats/) > > ? Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panelists, presenters and moderators. > > ? Due to potential technical issues, it is expected that most, if not all, presenters/panelists will be physically present at the RIPE Meeting. > > If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. > > ------------------ From charles-lists at knownelement.com Sun Aug 25 18:28:11 2013 From: charles-lists at knownelement.com (Charles N Wyble) Date: Sun, 25 Aug 2013 13:28:11 -0500 Subject: WaPo writes about vulnerabilities in Supermicro IPMIs In-Reply-To: <75FB9B0C-C170-418F-A753-32680B384978@ufp.org> References: <21288797.3692.1376614801039.JavaMail.root@benjamin.baylink.com> <520D8BDA.1010504@monmotha.net> <75FB9B0C-C170-418F-A753-32680B384978@ufp.org> Message-ID: If you are OK with USB ether net for one interface, check out the tplink wr703n. Its powered via USB, has a USB and rj45 jack. Runs OpenWrt. Leo Bicknell wrote: > >On Aug 15, 2013, at 9:18 PM, Brandon Martin >wrote: > >> As to why people wouldn't put them behind dedicated firewalls, >imagine something like a single-server colo scenario. > >I have asked about this on other lists, but I'll ask here. > >Does anyone know of a small (think Raspberry Pi sized) device that is: > > 1) USB powered. > 2) Has two ethernet ports. > 3) Runs some sort of standard open source OS? > >You might already see where I'm going with this, a small 2-port >firewall device sitting in front of IPMI, and powered off the USB bus >of the server. That way another RU isn't required. Making it fit in >an expansion card slot and using an internal USB header might be >interesting too, so from the outside it wasn't obvious what it was. > >I would actually like to see the thing only respond on the USB side, >power + console, enabling consoling in and changing L2 firewall rules. >No IP stack on it what so ever. That would be highly secure and >simple. > >-- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From sharonsaa at gmail.com Sun Aug 25 19:47:18 2013 From: sharonsaa at gmail.com (sharon saadon) Date: Sun, 25 Aug 2013 22:47:18 +0300 Subject: A split window multi ping program Message-ID: Hello, At the passing month, i looked for some small program that can ping to multiply servers in a split window or a program with a split dos windows, i did not found it, So i developed one :) You can download it here.. http://www.sharontools.com/products/9ping.php Regards, Sharon Saadon From jhellenthal at dataix.net Sun Aug 25 19:59:39 2013 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Sun, 25 Aug 2013 15:59:39 -0400 Subject: A split window multi ping program In-Reply-To: References: Message-ID: <50621FA3-E3A2-4820-B977-FD03C11C40B8@dataix.net> Nifty idea but could you give me a scenario where this would come in handy where a single instance of fPing -g would not be adequate ? -- Jason Hellenthal Inbox: jhellenthal at DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN > On Aug 25, 2013, at 15:47, sharon saadon wrote: > > Hello, > At the passing month, i looked for some small program that can ping to > multiply servers in a split window or a program with a split dos windows, > i did not found it, > So i developed one :) > > You can download it here.. > http://www.sharontools.com/products/9ping.php > > Regards, > Sharon Saadon -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6118 bytes Desc: not available URL: From johns at sstar.com Sun Aug 25 20:07:29 2013 From: johns at sstar.com (John Souvestre) Date: Sun, 25 Aug 2013 15:07:29 -0500 Subject: A split window multi ping program Message-ID: <006001cea1ce$bdf77850$39e668f0$@sstar.com> Hello Sharon. >>> At the passing month, i looked for some small program that can ping to multiply servers in a split window or a program with a split dos windows, i did not found it, So i developed one :) Take a look at MultiPing, from Nessoft: http://www.nessoft.com/multiping/ John ??? John Souvestre - New Orleans LA - (504) 454-0899 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6298 bytes Desc: not available URL: From sharonsaa at gmail.com Sun Aug 25 21:30:47 2013 From: sharonsaa at gmail.com (sharon saadon) Date: Mon, 26 Aug 2013 00:30:47 +0300 Subject: A split window multi ping program In-Reply-To: <50621FA3-E3A2-4820-B977-FD03C11C40B8@dataix.net> References: <50621FA3-E3A2-4820-B977-FD03C11C40B8@dataix.net> Message-ID: I need it for ATP tests, I need to know if there was packet lost while disconnecting cables / making changes all the ping results are saved, and you can add bookmarks of the tests you do.. Sharon On Sun, Aug 25, 2013 at 10:59 PM, Jason Hellenthal wrote: > Nifty idea but could you give me a scenario where this would come in handy > where a single instance of fPing -g would not be adequate ? > > -- > Jason Hellenthal > Inbox: jhellenthal at DataIX.net > Voice: +1 (616) 953-0176 > JJH48-ARIN > > > On Aug 25, 2013, at 15:47, sharon saadon wrote: > > Hello, > At the passing month, i looked for some small program that can ping to > multiply servers in a split window or a program with a split dos windows, > i did not found it, > So i developed one :) > > You can download it here.. > http://www.sharontools.com/products/9ping.php > > Regards, > Sharon Saadon > > From drew.linsalata at gmail.com Sun Aug 25 22:18:41 2013 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Sun, 25 Aug 2013 18:18:41 -0400 Subject: CableWiFi SSID in Washington DC? Message-ID: I know, completely non-operational and off topic, but have any of you folks in the DC area seen the CableWiFi SSID around town? Traveling next week and I can't get confirmation nor denial that my Optimum Online account will get me wifi access down there. From tknchris at gmail.com Sun Aug 25 22:25:09 2013 From: tknchris at gmail.com (chris) Date: Sun, 25 Aug 2013 18:25:09 -0400 Subject: CableWiFi SSID in Washington DC? In-Reply-To: References: Message-ID: Why don't you try a rogue ad hoc FreePublicWifi ? :) On Sun, Aug 25, 2013 at 6:18 PM, Drew Linsalata wrote: > I know, completely non-operational and off topic, but have any of you folks > in the DC area seen the CableWiFi SSID around town? Traveling next week > and I can't get confirmation nor denial that my Optimum Online account will > get me wifi access down there. > From drew.linsalata at gmail.com Sun Aug 25 22:50:13 2013 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Sun, 25 Aug 2013 18:50:13 -0400 Subject: CableWiFi SSID in Washington DC? In-Reply-To: References: Message-ID: What? Free? Public? How can I NOT connect to that? ;-) On Sun, Aug 25, 2013 at 6:25 PM, chris wrote: > Why don't you try a rogue ad hoc FreePublicWifi ? :) > > > From jhellenthal at dataix.net Sun Aug 25 22:50:06 2013 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Sun, 25 Aug 2013 18:50:06 -0400 Subject: A split window multi ping program In-Reply-To: References: <50621FA3-E3A2-4820-B977-FD03C11C40B8@dataix.net> Message-ID: Nice features. Good work and thanks for sharing. I'll see if I can put it to use and hopefully be able to provide some intelligible feedback. Thanks. -- Jason Hellenthal Inbox: jhellenthal at DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN > On Aug 25, 2013, at 17:30, sharon saadon wrote: > > I need it for ATP tests, > I need to know if there was packet lost while disconnecting cables / making changes > all the ping results are saved, and you can add bookmarks of the tests you do.. > > Sharon > > >> On Sun, Aug 25, 2013 at 10:59 PM, Jason Hellenthal wrote: >> Nifty idea but could you give me a scenario where this would come in handy where a single instance of fPing -g would not be adequate ? >> >> -- >> Jason Hellenthal >> Inbox: jhellenthal at DataIX.net >> Voice: +1 (616) 953-0176 >> JJH48-ARIN >> >> >>> On Aug 25, 2013, at 15:47, sharon saadon wrote: >>> >>> Hello, >>> At the passing month, i looked for some small program that can ping to >>> multiply servers in a split window or a program with a split dos windows, >>> i did not found it, >>> So i developed one :) >>> >>> You can download it here.. >>> http://www.sharontools.com/products/9ping.php >>> >>> Regards, >>> Sharon Saadon > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6118 bytes Desc: not available URL: From alex.buie at frozenfeline.net Mon Aug 26 00:11:12 2013 From: alex.buie at frozenfeline.net (Alex Buie) Date: Sun, 25 Aug 2013 20:11:12 -0400 Subject: CableWiFi SSID in Washington DC? In-Reply-To: References: Message-ID: I haven't tried it in DC, but I can confirm that my parents' XFINITY and grandparents' OO logins both work on the CableWiFi SSIDs in San Francisco, and friends in DC with XFINITY say theirs work there. I assume it will also for you. (cf http://www.techspot.com/news/48684-five-us-cable-providers-join-forces-to-offer-50000-wireless-hotspots.html ) -alex On Sun, Aug 25, 2013 at 6:50 PM, Drew Linsalata wrote: > What? Free? Public? How can I NOT connect to that? ;-) > > > On Sun, Aug 25, 2013 at 6:25 PM, chris wrote: > > > Why don't you try a rogue ad hoc FreePublicWifi ? :) > > > > > > > From Valdis.Kletnieks at vt.edu Mon Aug 26 00:18:11 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 25 Aug 2013 20:18:11 -0400 Subject: A split window multi ping program In-Reply-To: Your message of "Mon, 26 Aug 2013 00:30:47 +0300." References: <50621FA3-E3A2-4820-B977-FD03C11C40B8@dataix.net> Message-ID: <224273.1377476291@turing-police.cc.vt.edu> On Mon, 26 Aug 2013 00:30:47 +0300, sharon saadon said: > I need it for ATP tests, > I need to know if there was packet lost while disconnecting cables / > making changes Unless you have a very idle server or the fastest hands in the west, you almost certainly *will* drop packets while moving a cable. So the important question is not "if" but "how many" or "how long". And if the answer really matters, ping isn't the right instrumentation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From ag4ve.us at gmail.com Mon Aug 26 11:28:09 2013 From: ag4ve.us at gmail.com (Shawn Wilson) Date: Mon, 26 Aug 2013 07:28:09 -0400 Subject: CableWiFi SSID in Washington DC? In-Reply-To: References: Message-ID: There are indeed "FreePublicWiFi" nodes in some areas like Dupont Circle but it's not very convenient most of the time (signal strength or speed issues). IIRC there's a Commotion mesh around Columbia Heights which should be much faster. Personally, I just use a Mifi and never have any issues. -----Original Message----- From: Alex Buie To: Drew Linsalata Cc: NANOG list Sent: Sun, 25 Aug 2013 20:12 Subject: Re: CableWiFi SSID in Washington DC? I haven't tried it in DC, but I can confirm that my parents' XFINITY and grandparents' OO logins both work on the CableWiFi SSIDs in San Francisco, and friends in DC with XFINITY say theirs work there. I assume it will also for you. (cf http://www.techspot.com/news/48684-five-us-cable-providers-join-forces-to-offer-50000-wireless-hotspots.html ) -alex On Sun, Aug 25, 2013 at 6:50 PM, Drew Linsalata wrote: > What? Free? Public? How can I NOT connect to that? ;-) > > > On Sun, Aug 25, 2013 at 6:25 PM, chris wrote: > > > Why don't you try a rogue ad hoc FreePublicWifi ? :) > > > > > > > From srchlm at its.cz Mon Aug 26 16:26:10 2013 From: srchlm at its.cz (Lumir Srchlm) Date: Mon, 26 Aug 2013 18:26:10 +0200 Subject: Google contact Message-ID: Can someone from Google contact me off-list please. After many submissions to have our IP space fixed for geolocation still looking for Slovak Google and Polish news... Thanks Lumir From drew.weaver at thenap.com Mon Aug 26 18:21:55 2013 From: drew.weaver at thenap.com (Drew Weaver) Date: Mon, 26 Aug 2013 18:21:55 +0000 Subject: ATT.net postmaster contact Message-ID: <1d3d73b350934417b633ef47f989c835@EXCHANGE2K13.thenap.com> Howdy, Does anyone know of a good/working ATT.net postmaster contact? We have been trying for several weeks to get an IP that has never been used before removed from the ATT.net blacklist and we aren't getting replies through the forms on their site. Thanks, -Drew From dave at temk.in Mon Aug 26 19:47:26 2013 From: dave at temk.in (David Temkin) Date: Mon, 26 Aug 2013 15:47:26 -0400 Subject: Seeking members for Open IX standards committees Message-ID: The Open IX Board is seeking members for the standards committees that will draft the Data Center/MMR and IXP standards. Each group will have a chair that will be responsible for their committees output. For the initial bodies, the board will pick the chairs - but it is hoped that the committees can be self organizing in the future and would meet on an infrequent basis once the initial standards are complete. If you are interested in working in either of these groups, please send a few lines to board at open-ix.org stating which committee you'd like to work on, what your qualifications are, and whether or not you'd like to be considered for chairmanship. Membership is non-discriminatory and all are welcome to volunteer regardless of your industry or employer. For more information on Open-IX, see http://open-ix.org/OIX-Framework-Latest.pdf Regards, -Dave Temkin for the Open-IX Board From betty at newnog.org Mon Aug 26 20:48:27 2013 From: betty at newnog.org (Betty Burke ) Date: Mon, 26 Aug 2013 16:48:27 -0400 Subject: [NANOG-announce] NANOG Fellowship Program Message-ID: NANOGers: The NANOG's Fellowship program is announced. The Fellowship program awards two Fellows an opportunity to attend a NANOG Meeting, with the following benefits: ? Hotel accommodations at the meeting hotel ? Round-trip economy class airfare to the meeting ? A small stipend ? A NANOG Committee Member Mentor during the meeting *NANOG 59 FELLOWS APPLY NOW!* The Fellowship application found at Abha Ahuja Fellowship, and Operator of Tomorrow Fellowship, will remain *open from August 26, 2013 until 5:00 PM PST on September 9, 2013*. Applications received after that date will be considered for the next NANOG Meeting. NANOG 59 Fellows will be notified by September 18, 2013. *KNOW SOMEONE THAT WOULD BE INTERESTED?* Help spread the word; NANOG Fellowships are available for NANOG 59 ! Please send your questions to fellowship at nanog.org. Sincerely, Betty Burke On behalf of the NANOG Fellowship 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 Christopher.Palmer at microsoft.com Tue Aug 27 00:01:45 2013 From: Christopher.Palmer at microsoft.com (Christopher Palmer) Date: Tue, 27 Aug 2013 00:01:45 +0000 Subject: IP Fragmentation - Not reliable over the Internet? Message-ID: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> I am trolling for information/community wisdom. What is the probability that a random path between two Internet hosts will traverse a middlebox that drops or otherwise barfs on fragmented IPv4 packets? If anyone has any data or anecdotes, please feel free to send an off-list email or whatever. Thanks! ----------------------------------------------------------- Christopher.Palmer at microsoft.com Program Manager Windows Networking Core - Client Technologies From Valdis.Kletnieks at vt.edu Tue Aug 27 05:02:06 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 Aug 2013 01:02:06 -0400 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: Your message of "Tue, 27 Aug 2013 00:01:45 -0000." <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> Message-ID: <70257.1377579726@turing-police.cc.vt.edu> On Tue, 27 Aug 2013 00:01:45 -0000, Christopher Palmer said: > What is the probability that a random path between two Internet hosts will > traverse a middlebox that drops or otherwise barfs on fragmented IPv4 packets? THe fact you're posting indicates that you already know the practical answer: "Often enough that you need to take defensive measures". But there's really several separate questions here: 1) What is the probability that a given path ends up fragging a packet because it isn't MTU 1500 end-to-end? 2) What is the probability that a frag needed is detected by a router that then botches it? 2a) What is the probability that the router does it right but the source node shoots itself in the foot by requesting PMTUD, but then blocks inbound ICMP for "security reasons"? 3) What is the probability that one router correctly frags a packet, but a subsequent box (most likely a firewall or target host) botches the re-assembly or other handling? 4) When confronted with the fact that there's a very high correlation between the level of technical clue that results in procuring and deploying a broken device, and the level of technical clue clue available to resolve the problem when you try to contact them, what's the appropriate beverage? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From saku at ytti.fi Tue Aug 27 06:55:22 2013 From: saku at ytti.fi (Saku Ytti) Date: Tue, 27 Aug 2013 09:55:22 +0300 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> Message-ID: <20130827065522.GA26981@pob.ytti.fi> On (2013-08-27 00:01 +0000), Christopher Palmer wrote: > If anyone has any data or anecdotes, please feel free to send an off-list email or whatever. [ytti at ytti.fi ~]% ssh ring ring-all -t90 ping -s 1473 -c2 -w3 ip.fi|pastebinit http://p.ip.fi/KA7N [ytti at sci ~]% curl -s http://p.ip.fi/KA7N|grep transmitted|wc -l 224 [ytti at sci ~]% curl -s http://p.ip.fi/KA7N|grep "0 received"|wc -l 10 UUOC wc, but that's how I roll. 224 vantage points, 10 failed. -- ++ytti From owen at delong.com Tue Aug 27 07:34:57 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Aug 2013 00:34:57 -0700 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <70257.1377579726@turing-police.cc.vt.edu> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <70257.1377579726@turing-police.cc.vt.edu> Message-ID: <5DEF4DE9-3680-4D47-9FF0-1FC3CED0A816@delong.com> On Aug 26, 2013, at 22:02 , Valdis.Kletnieks at vt.edu wrote: > On Tue, 27 Aug 2013 00:01:45 -0000, Christopher Palmer said: >> What is the probability that a random path between two Internet hosts will >> traverse a middlebox that drops or otherwise barfs on fragmented IPv4 packets? > > THe fact you're posting indicates that you already know the practical > answer: "Often enough that you need to take defensive measures". > > But there's really several separate questions here: > > 1) What is the probability that a given path ends up fragging a packet > because it isn't MTU 1500 end-to-end? > > 2) What is the probability that a frag needed is detected by a router > that then botches it? > > 2a) What is the probability that the router does it right but the source node > shoots itself in the foot by requesting PMTUD, but then blocks inbound ICMP for > "security reasons"? > > 3) What is the probability that one router correctly frags a packet, but > a subsequent box (most likely a firewall or target host) botches the > re-assembly or other handling? > > 4) When confronted with the fact that there's a very high correlation between > the level of technical clue that results in procuring and deploying a broken > device, and the level of technical clue clue available to resolve the problem > when you try to contact them, what's the appropriate beverage? > > > That's a lot of questions he didn't ask. As I read it, the question he asked is: If I send a packet out as a legitimate series of fragments, what is the chance that they will get dropped somewhere in the middle of the path between the emitting host and the receiving host? To my thinking, the answer to that question is basically "pretty close to 0 and if that changes in the core, very bad things will happen." Owen From emile.aben at ripe.net Tue Aug 27 08:45:25 2013 From: emile.aben at ripe.net (Emile Aben) Date: Tue, 27 Aug 2013 10:45:25 +0200 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <20130827065522.GA26981@pob.ytti.fi> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <20130827065522.GA26981@pob.ytti.fi> Message-ID: <521C6725.8070508@ripe.net> On 27/08/2013 08:55, Saku Ytti wrote: > On (2013-08-27 00:01 +0000), Christopher Palmer wrote: > >> If anyone has any data or anecdotes, please feel free to send an off-list email or whatever. > > [ytti at ytti.fi ~]% ssh ring ring-all -t90 ping -s 1473 -c2 -w3 ip.fi|pastebinit > http://p.ip.fi/KA7N > > [ytti at sci ~]% curl -s http://p.ip.fi/KA7N|grep transmitted|wc -l > 224 > [ytti at sci ~]% curl -s http://p.ip.fi/KA7N|grep "0 received"|wc -l > 10 > > UUOC wc, but that's how I roll. > > 224 vantage points, 10 failed. Same tests from RIPE Atlas pings towards nl-ams-as3333.anchors.atlas.ripe.net today: 48 byte ping: 42 out of 3406 vantage points fail (1.0%) 1473 byte ping: 180 out of 3540 vantage points fail (5.1%) Of the 180 vantage points that failed for the 1473 byte ping, 142 were successful in receiving at least 1 reply for the 48 byte ping. Measurement IDs in RIPE Atlas are 1019675 and 1019676. Emile Aben RIPE NCC From dot at dotat.at Tue Aug 27 09:25:20 2013 From: dot at dotat.at (Tony Finch) Date: Tue, 27 Aug 2013 10:25:20 +0100 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> Message-ID: Christopher Palmer wrote: > > What is the probability that a random path between two Internet hosts > will traverse a middlebox that drops or otherwise barfs on fragmented > IPv4 packets? This question is important for large EDNS packets so you'll find some recent practical investigations from the perspective of people interested in DNSSEC. For instance, a couple of presentations from Roland van Rijswijk: https://ripe64.ripe.net/presentations/91-20120418_-_RIPE64_-_Ljubljana_-_DNSSEC_-_UDP_issues.pdf http://toronto45.icann.org/meetings/toronto2012/presentation-dnssec-fragmentation-17oct12-en.pdf 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 jaap at NLnetLabs.nl Tue Aug 27 10:04:15 2013 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Tue, 27 Aug 2013 12:04:15 +0200 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> Message-ID: <201308271004.r7RA4F17053839@bela.nlnetlabs.nl> Christopher Palmer wrote: > > What is the probability that a random path between two Internet hosts > will traverse a middlebox that drops or otherwise barfs on fragmented > IPv4 packets? This question is important for large EDNS packets so you'll find some recent practical investigations from the perspective of people interested in DNSSEC. For instance, a couple of presentations from Roland van Rijswijk: https://ripe64.ripe.net/presentations/91-20120418_-_RIPE64_-_Ljubljana_-_DNSSEC_-_UDP_issues.pdf http://toronto45.icann.org/meetings/toronto2012/presentation-dnssec-fragmentation-17oct12-en.pdf Related to this and maybe be of interest is the following blog post . jaap From saku at ytti.fi Tue Aug 27 11:24:36 2013 From: saku at ytti.fi (Saku Ytti) Date: Tue, 27 Aug 2013 14:24:36 +0300 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <521C6725.8070508@ripe.net> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <20130827065522.GA26981@pob.ytti.fi> <521C6725.8070508@ripe.net> Message-ID: <20130827112436.GA29165@pob.ytti.fi> On (2013-08-27 10:45 +0200), Emile Aben wrote: > > 224 vantage points, 10 failed. > > 48 byte ping: 42 out of 3406 vantage points fail (1.0%) > 1473 byte ping: 180 out of 3540 vantage points fail (5.1%) Nice, it's starting to almost sound like data rather than anecdote, both tests implicate 4<5% having fragmentation issues. Much larger number than I intuitively had in mind. -- ++ytti From marilyn.hay at ubc.ca Fri Aug 23 20:13:22 2013 From: marilyn.hay at ubc.ca (Hay, Marilyn) Date: Fri, 23 Aug 2013 20:13:22 +0000 Subject: Vancouver IXP - VanTX - BCNet In-Reply-To: References: <521785D0.2060307@mbix.ca> Message-ID: I'll offer some perspective from BCNET on this discussion. BCNET has operated Exchange services in British Columbia for many years however the peering has primarily been a multilateral service and not advertised as what is considered a typical IX. BCNET is a not-for-profit consortium for BC post-secondary and research institutions and a small membership fee with BCNET was required to join. Our exchanges were called Transit Exchanges and participants have certainly benefited from the peering and have significantly lowered their Transit costs. On reviewing this about a year ago, BCNET decided that it was time to look at getting a more typical bi-lateral IXP co-ordinated in Vancouver. In the global Internet scene, Vancouver is not a huge traffic generator but is a very important location in Canada for interconnecting. At about the same time, other efforts were underway such as in Montreal to re-establish the QIX, Winnipeg and Calgary to startup, and CIRA raising the general awareness that there was a shortage of IXPs across Canada. These are all great efforts and require the community ISP support to make them successful. We are working towards this in Vancouver for an open exchange, shared layer 2 switch fabric, bi-lateral peerings, and community driven. Some organization does need to operate a site and the suggestion we have on the table is for BCNET to be the operator of a BC Internet Exchange, BCIX. BCNET has been a network-neutral player in advanced networks since 1988 and we promote fair and accessible access to everyone. We have also discussed opportunities with Peer1 and their local PIX services relative to the BCIX and we will have to see where that leads. A Town Hall to discuss this with the community is scheduled for September 26 and all local ISPs and any other interested parties are welcome to attend. The Town Hall will be the driver for what happens next. The general announcements of the time and location are scheduled to come out the first week of September. CIRA has been very helpful with us in scheduling and co-ordinating this effort - thanks Jacques. Thanks all for this great discussion topic. Take care, Marilyn Hay UBC, Manager Network Planning BCNET, Manager Network Engineering 604.822.4127 -----Original Message----- From: Jacques Latour [mailto:jacques.latour at cira.ca] Sent: Friday, August 23, 2013 10:31 AM To: Bill Reid; nanog at nanog.org Subject: RE: Vancouver IXP - VanTX - BCNet ... Note: CIRA's job is not to go in and put a switch and leave. CIRA works with the community to get the IXP up and running. We have criteria to participate, the IXP must be a member based, vendor neutral non-profit organization with a viable trusted community to operate and sustain an IXP. CIRA is acting as a catalyst, not a doer. The community is the doer. ... From Chae_Chung at Cable.Comcast.com Mon Aug 26 13:46:16 2013 From: Chae_Chung at Cable.Comcast.com (Chung, Chae) Date: Mon, 26 Aug 2013 13:46:16 +0000 Subject: CableWiFi SSID in Washington DC? In-Reply-To: Message-ID: <72B5CE6575B4F24A84ECF43EDED53BCE0DF43A33@PACDCEXMB05.cable.comcast.com> Drew, Optimum's Hotspot locator will show partner hotspots that they have access through. Check out their wifi locator page below to see you will have wifi coverage. http://m.optimumwifi.com/results.php?s=quick&t=washington+dc&local=1&lat=38 .9072309&lon=-77.0364641#pageTop They may also have an iPhone/Android app for locating optimum hotspots similar to Comcast's apps? Android version = https://play.google.com/store/apps/details?id=com.comcast.hsf iPhone version = https://itunes.apple.com/us/app/xfinity-wifi/id549643634?mt=8 Thanks! -chae On 8/25/13 6:18 PM, "Drew Linsalata" wrote: >I know, completely non-operational and off topic, but have any of you >folks >in the DC area seen the CableWiFi SSID around town? Traveling next week >and I can't get confirmation nor denial that my Optimum Online account >will >get me wifi access down there. From nick at flhsi.com Mon Aug 26 19:07:52 2013 From: nick at flhsi.com (Nick Olsen) Date: Mon, 26 Aug 2013 15:07:52 -0400 Subject: TCP Performance Message-ID: <6ef9fed2$45c1a103$45dfc43e$@flhsi.com> Greetings all, I've got an issue I was hoping to put a few more eyes on. Here's the scenario. Downloading a file at our Border is multiple orders of magnitude faster then a few hops out. Using the same 128MB test file, I tested at two different locations. As well as between them. Using multiple connections improves throughput, However it's the single stream issue we're looking at right now. All testing servers in question are Centos Linux. Orlando Datapath: Cogent>Orlando Border Router (Mikrotik)>HP Procurve Switch> Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' saved [127926272/127926272] Cocoa NOC Datapath: Cogent>Orlando Border Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>East Orange Router (Mikrotik)> Licensed Microwave Link (300+Mb/s Capacity)>Cocoa Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>Colo Router (Mikrotik)>NOC Router (Mikrotik)>HP Procurve Switch>Server Results: 2013-08-26 13:42:25 (398 KB/s) - `128mbfile.tgz' saved [127926272/127926272] Orlando-Cocoa NOC Datapath: Orlando Server>HP Procurve Switch>Orlando Border Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>East Orange Router (Mikrotik)> Licensed Microwave Link (300+Mb/s Capacity)>Cocoa Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>Colo Router (Mikrotik)>NOC Router(Mikrotik)>HP Procurve Switch>ServerResults: 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved [134217728/134217728] Now, For the fun of it. I ran Iperf single TCP between our Cocoa and Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). It maxes out the port, Unlike the HTTP test. [root at ded01 ~]# iperf -c 208.90.219.18------------------------------------------------------------Cli ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte (default)------------------------------------------------------------[ 3] local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 Mbits/sec Here's associated packet captures for each transfer. As well as full wget output and traceroutes for each test. As you can see, The tests crossing the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm not sure I'm sold this could show such a huge drop in throughput. Other then that, nothing really stands out to me as to why these transfers are so much slower. Intra-network iperf testing shows full throughput the whole way with single connection. As well as UDP testing. One thing to note is the Iperf testing has far less TCP re-transmit/dup acks then any of the HTTP testing, Crossing the same Microwave Links and routers. http://cdn.141networks.com/files/captures.zip I appreciate any insight anyone might have. Thanks! Nick Olsen Network Operations (855) FLSPEED x106 From tb at tburke.us Tue Aug 27 02:16:29 2013 From: tb at tburke.us (Tim Burke) Date: Mon, 26 Aug 2013 21:16:29 -0500 Subject: ATT.net postmaster contact In-Reply-To: <1d3d73b350934417b633ef47f989c835@EXCHANGE2K13.thenap.com> References: <1d3d73b350934417b633ef47f989c835@EXCHANGE2K13.thenap.com> Message-ID: <521C0BFD.5070802@tburke.us> I've had good luck emailing them at abuse_rbl at abuse-att.net. Takes a couple days to hear back from them, but they do generally reply. On 08/26/2013 01:21 PM, Drew Weaver wrote: > Howdy, > > Does anyone know of a good/working ATT.net postmaster contact? We > have been trying for several weeks to get an IP that has never been > used before removed from the ATT.net blacklist and we aren't > getting replies through the forms on their site. > > Thanks, -Drew > From bicknell at ufp.org Tue Aug 27 14:04:06 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 27 Aug 2013 09:04:06 -0500 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <20130827112436.GA29165@pob.ytti.fi> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <20130827065522.GA26981@pob.ytti.fi> <521C6725.8070508@ripe.net> <20130827112436.GA29165@pob.ytti.fi> Message-ID: On Aug 27, 2013, at 6:24 AM, Saku Ytti wrote: > On (2013-08-27 10:45 +0200), Emile Aben wrote: > >>> 224 vantage points, 10 failed. >> >> 48 byte ping: 42 out of 3406 vantage points fail (1.0%) >> 1473 byte ping: 180 out of 3540 vantage points fail (5.1%) > > Nice, it's starting to almost sound like data rather than anecdote, both > tests implicate 4<5% having fragmentation issues. > > Much larger number than I intuitively had in mind. I'm pretty sure the failure rate is higher, and here's why. The #1 cause of fragments being dropped is firewalls. Too many admins configuring a firewall do not understand fragments or how to properly put them in the rules. Where do firewalls exist? Typically protecting things with public IP space, that is (some) corporate networks and banks of content servers in data centers. This also includes on-box firewalls for Internet servers, ipfw or iptables on the server is just as likely to be part of the problem. Now, where are RIPE probes? Most RIPE probes are probably either with somewhat clueful ISP operators, or at Internet Clueful engineer's personal connectivity (home, or perhaps a box in a colo). RIPE probes have already significantly self-selected for people who like non-broken connectivity. What's more, the ping test was probably to some "known good" host(s), rather than a broad selection of Internet hosts, so effectively it was only testing the probe end, not both ends. Basically, I see RIPE probes as an almost best-case scenario for this sort of broken behavior. I bet the ISC Netalyzer folks have somewhat better data, perhaps skewed a bit towards broken connections as people run Netalyzer when their connection is broken! I suspect reality is somewhere between those two book ends. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ikiris at gmail.com Tue Aug 27 14:32:23 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 27 Aug 2013 09:32:23 -0500 Subject: TCP Performance In-Reply-To: <6ef9fed2$45c1a103$45dfc43e$@flhsi.com> References: <6ef9fed2$45c1a103$45dfc43e$@flhsi.com> Message-ID: You didn't indicate this, but do you understand how TCP windowing works? This conversation can go two very different ways depending on the answer. To me, it looks like this is what you'd expect, and you need to fix your packet loss issues, which possibly might be QoS settings related (but it's hard to tell based on the information given). -Blake On Mon, Aug 26, 2013 at 2:07 PM, Nick Olsen wrote: > Greetings all, I've got an issue I was hoping to put a few more eyes on. > Here's the scenario. Downloading a file at our Border is multiple orders > of magnitude faster then a few hops out. Using the same 128MB test file, I > tested at two different locations. As well as between them. Using multiple > connections improves throughput, However it's the single stream issue we're > looking at right now. All testing servers in question are Centos Linux. > Orlando Datapath: Cogent>Orlando Border Router (Mikrotik)>HP Procurve > Switch> Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' > saved [127926272/127926272] > Cocoa NOC Datapath: Cogent>Orlando Border Router (Mikrotik)>Licensed > Microwave Link (300+Mb/s Capacity)>East Orange Router (Mikrotik)> Licensed > Microwave Link (300+Mb/s Capacity)>Cocoa Router (Mikrotik)>Licensed > Microwave Link (300+Mb/s Capacity)>Colo Router (Mikrotik)>NOC Router > (Mikrotik)>HP Procurve Switch>Server Results: 2013-08-26 13:42:25 (398 > KB/s) - `128mbfile.tgz' saved [127926272/127926272] > Orlando-Cocoa NOC Datapath: Orlando Server>HP Procurve Switch>Orlando > Border Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>East > Orange Router (Mikrotik)> Licensed Microwave Link (300+Mb/s Capacity)>Cocoa > Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>Colo Router > (Mikrotik)>NOC Router(Mikrotik)>HP Procurve Switch>ServerResults: > 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved > [134217728/134217728] > Now, For the fun of it. I ran Iperf single TCP between our Cocoa and > Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). > It maxes out the port, Unlike the HTTP test. > [root at ded01 ~]# iperf -c > 208.90.219.18 > ------------------------------------------------------------Cli > ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte > (default)------------------------------------------------------------[ 3] > local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ > ID] > Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 > Mbits/sec > > Here's associated packet captures for each transfer. As well as full wget > output and traceroutes for each test. As you can see, The tests crossing > the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm > not sure I'm sold this could show such a huge drop in throughput. Other > then that, nothing really stands out to me as to why these transfers are so > much slower. Intra-network iperf testing shows full throughput the whole > way with single connection. As well as UDP testing. One thing to note is > the Iperf testing has far less TCP re-transmit/dup acks then any of the > HTTP testing, Crossing the same Microwave Links and routers. > http://cdn.141networks.com/files/captures.zip > I appreciate any insight anyone might have. Thanks! > Nick Olsen > Network Operations (855) FLSPEED x106 > > > From Valdis.Kletnieks at vt.edu Tue Aug 27 14:33:21 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 Aug 2013 10:33:21 -0400 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: Your message of "Tue, 27 Aug 2013 00:34:57 -0700." <5DEF4DE9-3680-4D47-9FF0-1FC3CED0A816@delong.com> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <70257.1377579726@turing-police.cc.vt.edu> <5DEF4DE9-3680-4D47-9FF0-1FC3CED0A816@delong.com> Message-ID: <105365.1377614001@turing-police.cc.vt.edu> On Tue, 27 Aug 2013 00:34:57 -0700, Owen DeLong said: > That's a lot of questions he didn't ask. This isn't your first rodeo. You should know by now that the question actually asked, the question *meant* to be asked, and the question that actually needed answering are often 3 different things. > If I send a packet out as a legitimate series of fragments, what is the chance > that they will get dropped somewhere in the middle of the path between the > emitting host and the receiving host? > To my thinking, the answer to that question is basically "pretty close to 0 and > if that changes in the core, very bad things will happen." Saku Ytti and Emile Aben have numbers that say otherwise. And there must be a significantly bigger percentage of failures than "pretty close to 0", or Path MTU Discovery wouldn't have a reputation of being next to useless. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From ikiris at gmail.com Tue Aug 27 15:00:36 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 27 Aug 2013 10:00:36 -0500 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <105365.1377614001@turing-police.cc.vt.edu> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <70257.1377579726@turing-police.cc.vt.edu> <5DEF4DE9-3680-4D47-9FF0-1FC3CED0A816@delong.com> <105365.1377614001@turing-police.cc.vt.edu> Message-ID: And then you have other issues like networks that arbitrarily set DF on all packets passing through them. That burnt a good three days of my life back in the day. -Blake On Tue, Aug 27, 2013 at 9:33 AM, wrote: > On Tue, 27 Aug 2013 00:34:57 -0700, Owen DeLong said: > > That's a lot of questions he didn't ask. > > This isn't your first rodeo. You should know by now that the question > actually asked, the question *meant* to be asked, and the question that > actually needed answering are often 3 different things. > > > If I send a packet out as a legitimate series of fragments, what is the > chance > > that they will get dropped somewhere in the middle of the path between > the > > emitting host and the receiving host? > > > To my thinking, the answer to that question is basically "pretty close > to 0 and > > if that changes in the core, very bad things will happen." > > Saku Ytti and Emile Aben have numbers that say otherwise. And there must > be a significantly bigger percentage of failures than "pretty close to 0", > or Path MTU Discovery wouldn't have a reputation of being next to useless. > From nick at flhsi.com Tue Aug 27 14:49:17 2013 From: nick at flhsi.com (Nick Olsen) Date: Tue, 27 Aug 2013 10:49:17 -0400 Subject: TCP Performance Message-ID: <4330773f$65fb0f6f$123272a9$@flhsi.com> Duplex mismatch has been checked across the board. On every device. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Chad Dailey" Sent: Tuesday, August 27, 2013 10:48 AM To: nick at flhsi.com Subject: Re: TCP Performance Check for duplex mismatch at the server. On Mon, Aug 26, 2013 at 2:07 PM, Nick Olsen wrote: Greetings all, I've got an issue I was hoping to put a few more eyes on. Here's the scenario. Downloading a file at our Border is multiple orders of magnitude faster then a few hops out. Using the same 128MB test file, I tested at two different locations. As well as between them. Using multiple connections improves throughput, However it's the single stream issue we're looking at right now. All testing servers in question are Centos Linux. Orlando Datapath: Cogent>Orlando Border Router (Mikrotik)>HP Procurve Switch> Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' saved [127926272/127926272] Cocoa NOC Datapath: Cogent>Orlando Border Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>East Orange Router (Mikrotik)> Licensed Microwave Link (300+Mb/s Capacity)>Cocoa Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>Colo Router (Mikrotik)>NOC Router (Mikrotik)>HP Procurve Switch>Server Results: 2013-08-26 13:42:25 (398 KB/s) - `128mbfile.tgz' saved [127926272/127926272] Orlando-Cocoa NOC Datapath: Orlando Server>HP Procurve Switch>Orlando Border Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>East Orange Router (Mikrotik)> Licensed Microwave Link (300+Mb/s Capacity)>Cocoa Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>Colo Router (Mikrotik)>NOC Router(Mikrotik)>HP Procurve Switch>ServerResults: 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved [134217728/134217728] Now, For the fun of it. I ran Iperf single TCP between our Cocoa and Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). It maxes out the port, Unlike the HTTP test. [root at ded01 ~]# iperf -c 208.90.219.18------------------------------------------------------------Cli ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte (default)------------------------------------------------------------[ 3] local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 Mbits/sec Here's associated packet captures for each transfer. As well as full wget output and traceroutes for each test. As you can see, The tests crossing the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm not sure I'm sold this could show such a huge drop in throughput. Other then that, nothing really stands out to me as to why these transfers are so much slower. Intra-network iperf testing shows full throughput the whole way with single connection. As well as UDP testing. One thing to note is the Iperf testing has far less TCP re-transmit/dup acks then any of the HTTP testing, Crossing the same Microwave Links and routers. http://cdn.141networks.com/files/captures.zip I appreciate any insight anyone might have. Thanks! Nick Olsen Network Operations (855) FLSPEED x106 From nick at flhsi.com Tue Aug 27 15:00:26 2013 From: nick at flhsi.com (Nick Olsen) Date: Tue, 27 Aug 2013 11:00:26 -0400 Subject: TCP Performance Message-ID: <32384144$2f07e367$66b9cbe2$@flhsi.com> I have done a decent amount of reading on both TCP windowing and Flow Control. But I've seen a lot of conflicting data. Some say flow control breaks more then it fixes. Where some say it's completely required. Currently we do not have Flow control enabled. Our routers do not support flow control currently (At least, Not at a configurable level, maybe at the NIC hardware wise). The only way we could currently implement flow control would be installing a manged switch (with flow control) between the router(s) and the Microwave links. Regarding packet loss. We once again have conflicting data. If you take a look at the packet captures. The file download in Orlando (Which rocks ~800Mb/) shows ~5K retransmits/Dup Acks. However the file download in Cocoa (Crossing the wireless) is about 3x that (~16K retransmits/dup acks). The same is shown on an intra-network test from server to server.. But only when HTTP. Iperf testing shows ~18 errors, Vs ~13K errors when HTTP based. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Blake Dunlap" Sent: Tuesday, August 27, 2013 10:32 AM To: nick at flhsi.com Cc: "nanog at nanog.org" Subject: Re: TCP Performance You didn't indicate this, but do you understand how TCP windowing works? This conversation can go two very different ways depending on the answer. To me, it looks like this is what you'd expect, and you need to fix your packet loss issues, which possibly might be QoS settings related (but it's hard to tell based on the information given). -Blake On Mon, Aug 26, 2013 at 2:07 PM, Nick Olsen wrote: Greetings all, I've got an issue I was hoping to put a few more eyes on. Here's the scenario. Downloading a file at our Border is multiple orders of magnitude faster then a few hops out. Using the same 128MB test file, I tested at two different locations. As well as between them. Using multiple connections improves throughput, However it's the single stream issue we're looking at right now. All testing servers in question are Centos Linux. Orlando Datapath: Cogent>Orlando Border Router (Mikrotik)>HP Procurve Switch> Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' saved [127926272/127926272] Cocoa NOC Datapath: Cogent>Orlando Border Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>East Orange Router (Mikrotik)> Licensed Microwave Link (300+Mb/s Capacity)>Cocoa Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>Colo Router (Mikrotik)>NOC Router (Mikrotik)>HP Procurve Switch>Server Results: 2013-08-26 13:42:25 (398 KB/s) - `128mbfile.tgz' saved [127926272/127926272] Orlando-Cocoa NOC Datapath: Orlando Server>HP Procurve Switch>Orlando Border Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>East Orange Router (Mikrotik)> Licensed Microwave Link (300+Mb/s Capacity)>Cocoa Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>Colo Router (Mikrotik)>NOC Router(Mikrotik)>HP Procurve Switch>ServerResults: 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved [134217728/134217728] Now, For the fun of it. I ran Iperf single TCP between our Cocoa and Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). It maxes out the port, Unlike the HTTP test. [root at ded01 ~]# iperf -c 208.90.219.18------------------------------------------------------------Cli ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte (default)------------------------------------------------------------[ 3] local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 Mbits/sec Here's associated packet captures for each transfer. As well as full wget output and traceroutes for each test. As you can see, The tests crossing the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm not sure I'm sold this could show such a huge drop in throughput. Other then that, nothing really stands out to me as to why these transfers are so much slower. Intra-network iperf testing shows full throughput the whole way with single connection. As well as UDP testing. One thing to note is the Iperf testing has far less TCP re-transmit/dup acks then any of the HTTP testing, Crossing the same Microwave Links and routers. http://cdn.141networks.com/files/captures.zip I appreciate any insight anyone might have. Thanks! Nick Olsen Network Operations (855) FLSPEED x106 From ikiris at gmail.com Tue Aug 27 15:42:17 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 27 Aug 2013 10:42:17 -0500 Subject: TCP Performance In-Reply-To: <4330773f$65fb0f6f$123272a9$@flhsi.com> References: <4330773f$65fb0f6f$123272a9$@flhsi.com> Message-ID: This really sounds like you aren't testing the correct flow type in i/jperf, or you have some QoS queues for http traffic but not the perf traffic that are filled. Regardless, your problem looks like either tail drops or packet loss, which you showed originally. The task is to find out where this is occurring, and which of the two it is. If you want to confirm what is going on, there are some great bandwidth calculators on the internet which will show you what bandwidth you can get with a given ms delay and % packet loss. As far as flow control, its really outside the scope. If you ever need flow control, there is usually a specific reason like FCoE, and if not, it's generally better to just fix the backplane congestion issue if you can, than ever worry about using FC. The problem with FC isn't node to node, its when you have node to node to node with additional devices, it isn't smart enough to discriminate, and can crater your network 3 devices over when it would be much better to just lose a few packets. -Blake On Tue, Aug 27, 2013 at 9:49 AM, Nick Olsen wrote: > Duplex mismatch has been checked across the board. On every device. > > Nick Olsen > Network Operations (855) FLSPEED x106 > > ---------------------------------------- > From: "Chad Dailey" > Sent: Tuesday, August 27, 2013 10:48 AM > To: nick at flhsi.com > Subject: Re: TCP Performance > > Check for duplex mismatch at the server. > > On Mon, Aug 26, 2013 at 2:07 PM, Nick Olsen wrote: > Greetings all, I've got an issue I was hoping to put a few more eyes on. > Here's the scenario. Downloading a file at our Border is multiple orders > of magnitude faster then a few hops out. Using the same 128MB test file, I > tested at two different locations. As well as between them. Using multiple > connections improves throughput, However it's the single stream issue > we're > looking at right now. All testing servers in question are Centos Linux. > Orlando Datapath: Cogent>Orlando Border Router (Mikrotik)>HP Procurve > Switch> Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' > saved [127926272/127926272] > Cocoa NOC Datapath: Cogent>Orlando Border Router (Mikrotik)>Licensed > Microwave Link (300+Mb/s Capacity)>East Orange Router (Mikrotik)> Licensed > Microwave Link (300+Mb/s Capacity)>Cocoa Router (Mikrotik)>Licensed > Microwave Link (300+Mb/s Capacity)>Colo Router (Mikrotik)>NOC Router > (Mikrotik)>HP Procurve Switch>Server Results: 2013-08-26 13:42:25 (398 > KB/s) - `128mbfile.tgz' saved [127926272/127926272] > Orlando-Cocoa NOC Datapath: Orlando Server>HP Procurve Switch>Orlando > Border Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>East > Orange Router (Mikrotik)> Licensed Microwave Link (300+Mb/s > Capacity)>Cocoa > Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>Colo Router > (Mikrotik)>NOC Router(Mikrotik)>HP Procurve Switch>ServerResults: > 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved > [134217728/134217728] > Now, For the fun of it. I ran Iperf single TCP between our Cocoa and > Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). > It maxes out the port, Unlike the HTTP test. > [root at ded01 ~]# iperf -c > 208.90.219.18 > ------------------------------------------------------------Cli > > ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte > (default)------------------------------------------------------------[ 3] > local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ > ID] > Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes > 95.7 > Mbits/sec > > Here's associated packet captures for each transfer. As well as full wget > output and traceroutes for each test. As you can see, The tests crossing > the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm > not sure I'm sold this could show such a huge drop in throughput. Other > then that, nothing really stands out to me as to why these transfers are > so > much slower. Intra-network iperf testing shows full throughput the whole > way with single connection. As well as UDP testing. One thing to note is > the Iperf testing has far less TCP re-transmit/dup acks then any of the > HTTP testing, Crossing the same Microwave Links and routers. > http://cdn.141networks.com/files/captures.zip > I appreciate any insight anyone might have. Thanks! > Nick Olsen > Network Operations (855) FLSPEED x106 > > > From robertg at garlic.com Tue Aug 27 16:41:36 2013 From: robertg at garlic.com (Robert Glover) Date: Tue, 27 Aug 2013 09:41:36 -0700 Subject: Anyone from Bluehost? Message-ID: <521CD6C0.3000608@garlic.com> Hello, Can someone from Bluehost please contact me? Email blacklist issue. We have gone through the normal support channels, but have come up with the support staff @ Bluehost not understanding the nature of our request. Thanks, -Bobby From timoid at timoid.org Tue Aug 27 17:07:00 2013 From: timoid at timoid.org (Tim Warnock) Date: Tue, 27 Aug 2013 17:07:00 +0000 Subject: TCP Performance In-Reply-To: References: <4330773f$65fb0f6f$123272a9$@flhsi.com> Message-ID: > Regardless, your problem looks like either tail drops or packet loss, which > you showed originally. The task is to find out where this is occurring, and > which of the two it is. If you want to confirm what is going on, there are > some great bandwidth calculators on the internet which will show you what > bandwidth you can get with a given ms delay and % packet loss. > > As far as flow control, its really outside the scope. If you ever need flow > control, there is usually a specific reason like FCoE, and if not, it's > generally better to just fix the backplane congestion issue if you can, > than ever worry about using FC. The problem with FC isn't node to node, its > when you have node to node to node with additional devices, it isn't smart > enough to discriminate, and can crater your network 3 devices over when it > would be much better to just lose a few packets. > > -Blake In my experience - if you're traversing licenced microwave links as indicated flow control will definitely need to be ON. Check the radio modem stats to confirm but - if you're seeing lots of drops there you're overflowing the buffers on the radio modem. From dave at dvstn.com Tue Aug 27 17:25:18 2013 From: dave at dvstn.com (Dave Brockman) Date: Tue, 27 Aug 2013 13:25:18 -0400 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <20130827065522.GA26981@pob.ytti.fi> <521C6725.8070508@ripe.net> <20130827112436.GA29165@pob.ytti.fi> Message-ID: <521CE0FE.9020906@dvstn.com> On 8/27/2013 10:04 AM, Leo Bicknell wrote: > > On Aug 27, 2013, at 6:24 AM, Saku Ytti wrote: > >> On (2013-08-27 10:45 +0200), Emile Aben wrote: >> >>>> 224 vantage points, 10 failed. >>> >>> 48 byte ping: 42 out of 3406 vantage points fail (1.0%) >>> 1473 byte ping: 180 out of 3540 vantage points fail (5.1%) >> >> Nice, it's starting to almost sound like data rather than >> anecdote, both tests implicate 4<5% having fragmentation issues. >> >> Much larger number than I intuitively had in mind. > > > I'm pretty sure the failure rate is higher, and here's why. > > The #1 cause of fragments being dropped is firewalls. Too many > admins configuring a firewall do not understand fragments or how > to properly put them in the rules. > > Where do firewalls exist? Typically protecting things with public > IP space, that is (some) corporate networks and banks of content > servers in data centers. This also includes on-box firewalls for > Internet servers, ipfw or iptables on the server is just as likely > to be part of the problem. It's not just firewalls.... border-routers are also apt to have ACLs like these[1]: ip access-list extended BORDER-IN 10 deny tcp any any fragments 20 deny udp any any fragments 30 deny icmp any any fragments 40 deny ip any any fragments I see these a *LOT* on customer routers, before the packets even get to the firewall.... Regards, dtb 1. I found it most recently at http://hurricanelabs.com/blog/cisco-security-routers/ but I know there are many other "guides" that include these as part of their ACL. From ikiris at gmail.com Tue Aug 27 17:31:40 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 27 Aug 2013 12:31:40 -0500 Subject: TCP Performance In-Reply-To: <3c3f6faa$247b83c2$1ee532dd$@flhsi.com> References: <3c3f6faa$247b83c2$1ee532dd$@flhsi.com> Message-ID: If you have a router, you can turn on shaping to the bandwidth the link will support. -Blake On Tue, Aug 27, 2013 at 12:11 PM, Nick Olsen wrote: > I do indeed have stats for "TX Pause Frames" And they do increment. > However, Our router is ignoring them since it doesn't support flow control. > > I guess my next question would be. In the scenario where we insert a > switch between the radio and the router that does support flow control. Are > we not only moving where the overflow is going to occur? Will we not see > the router still burst traffic at line rate toward the switch, Which then > buffer overflows sending to the radio on account of it receiving pause > frames? > > > Nick Olsen > Network Operations > (855) FLSPEED x106 > > > > ------------------------------ > *From*: "Tim Warnock" > *Sent*: Tuesday, August 27, 2013 1:08 PM > *To*: "Blake Dunlap" , "nick at flhsi.com" > *Cc*: "nanog at nanog.org" > *Subject*: RE: TCP Performance > > > > Regardless, your problem looks like either tail drops or packet loss, > which > > you showed originally. The task is to find out where this is occurring, > and > > which of the two it is. If you want to confirm what is going on, there > are > > some great bandwidth calculators on the internet which will show you what > > bandwidth you can get with a given ms delay and % packet loss. > > > > As far as flow control, its really outside the scope. If you ever need > flow > > control, there is usually a specific reason like FCoE, and if not, it's > > generally better to just fix the backplane congestion issue if you can, > > than ever worry about using FC. The problem with FC isn't node to node, > its > > when you have node to node to node with additional devices, it isn't > smart > > enough to discriminate, and can crater your network 3 devices over when > it > > would be much better to just lose a few packets. > > > > -Blake > > In my experience - if you're traversing licenced microwave links as > indicated flow control will definitely need to be ON. > > Check the radio modem stats to confirm but - if you're seeing lots of > drops there you're overflowing the buffers on the radio modem. > > From nick at flhsi.com Tue Aug 27 16:56:14 2013 From: nick at flhsi.com (Nick Olsen) Date: Tue, 27 Aug 2013 12:56:14 -0400 Subject: TCP Performance Message-ID: No QoS is in use anywhere.. To the best of my ability I've eliminated Packet loss. However, I've not found a way any better than ICMP/MTR/Ping -f..etc. The reason flow control has been mentioned is to correct buffer overflow at the Microwave links. Where they physically link at GigFDX. But the radio interface is only capable of ~360Mb/s, It's possible for the sending device to overflow the buffer between the fiber/ethernet and the radio interface.I can say we've had an issue like this in the past, Which forcing 100Mb/s FDX on a licensed radio fixed the problem. Being that, The ethernet was now slower then the radio interface. However, The down fall of this is that it limits the link to 100Mb/s which isn't sufficient anymore. In terms of congestion, There is not from my point of view. Every link in questions runs =>30% utilization. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Blake Dunlap" Sent: Tuesday, August 27, 2013 11:42 AM To: nick at flhsi.com Cc: nanog at thedaileyplanet.com, "nanog at nanog.org" Subject: Re: TCP Performance This really sounds like you aren't testing the correct flow type in i/jperf, or you have some QoS queues for http traffic but not the perf traffic that are filled. Regardless, your problem looks like either tail drops or packet loss, which you showed originally. The task is to find out where this is occurring, and which of the two it is. If you want to confirm what is going on, there are some great bandwidth calculators on the internet which will show you what bandwidth you can get with a given ms delay and % packet loss. As far as flow control, its really outside the scope. If you ever need flow control, there is usually a specific reason like FCoE, and if not, it's generally better to just fix the backplane congestion issue if you can, than ever worry about using FC. The problem with FC isn't node to node, its when you have node to node to node with additional devices, it isn't smart enough to discriminate, and can crater your network 3 devices over when it would be much better to just lose a few packets. -Blake On Tue, Aug 27, 2013 at 9:49 AM, Nick Olsen wrote: Duplex mismatch has been checked across the board. On every device. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Chad Dailey" Sent: Tuesday, August 27, 2013 10:48 AM To: nick at flhsi.com Subject: Re: TCP Performance Check for duplex mismatch at the server. On Mon, Aug 26, 2013 at 2:07 PM, Nick Olsen wrote: Greetings all, I've got an issue I was hoping to put a few more eyes on. Here's the scenario. Downloading a file at our Border is multiple orders of magnitude faster then a few hops out. Using the same 128MB test file, I tested at two different locations. As well as between them. Using multiple connections improves throughput, However it's the single stream issue we're looking at right now. All testing servers in question are Centos Linux. Orlando Datapath: Cogent>Orlando Border Router (Mikrotik)>HP Procurve Switch> Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' saved [127926272/127926272] Cocoa NOC Datapath: Cogent>Orlando Border Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>East Orange Router (Mikrotik)> Licensed Microwave Link (300+Mb/s Capacity)>Cocoa Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>Colo Router (Mikrotik)>NOC Router (Mikrotik)>HP Procurve Switch>Server Results: 2013-08-26 13:42:25 (398 KB/s) - `128mbfile.tgz' saved [127926272/127926272] Orlando-Cocoa NOC Datapath: Orlando Server>HP Procurve Switch>Orlando Border Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>East Orange Router (Mikrotik)> Licensed Microwave Link (300+Mb/s Capacity)>Cocoa Router (Mikrotik)>Licensed Microwave Link (300+Mb/s Capacity)>Colo Router (Mikrotik)>NOC Router(Mikrotik)>HP Procurve Switch>ServerResults: 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved [134217728/134217728] Now, For the fun of it. I ran Iperf single TCP between our Cocoa and Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). It maxes out the port, Unlike the HTTP test. [root at ded01 ~]# iperf -c 208.90.219.18------------------------------------------------------------Cli ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte (default)------------------------------------------------------------[ 3] local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 Mbits/sec Here's associated packet captures for each transfer. As well as full wget output and traceroutes for each test. As you can see, The tests crossing the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm not sure I'm sold this could show such a huge drop in throughput. Other then that, nothing really stands out to me as to why these transfers are so much slower. Intra-network iperf testing shows full throughput the whole way with single connection. As well as UDP testing. One thing to note is the Iperf testing has far less TCP re-transmit/dup acks then any of the HTTP testing, Crossing the same Microwave Links and routers. http://cdn.141networks.com/files/captures.zip I appreciate any insight anyone might have. Thanks! Nick Olsen Network Operations (855) FLSPEED x106 From nick at flhsi.com Tue Aug 27 17:11:52 2013 From: nick at flhsi.com (Nick Olsen) Date: Tue, 27 Aug 2013 13:11:52 -0400 Subject: TCP Performance Message-ID: <3c3f6faa$247b83c2$1ee532dd$@flhsi.com> I do indeed have stats for "TX Pause Frames" And they do increment. However, Our router is ignoring them since it doesn't support flow control. I guess my next question would be. In the scenario where we insert a switch between the radio and the router that does support flow control. Are we not only moving where the overflow is going to occur? Will we not see the router still burst traffic at line rate toward the switch, Which then buffer overflows sending to the radio on account of it receiving pause frames? Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Tim Warnock" Sent: Tuesday, August 27, 2013 1:08 PM To: "Blake Dunlap" , "nick at flhsi.com" Cc: "nanog at nanog.org" Subject: RE: TCP Performance > Regardless, your problem looks like either tail drops or packet loss, which > you showed originally. The task is to find out where this is occurring, and > which of the two it is. If you want to confirm what is going on, there are > some great bandwidth calculators on the internet which will show you what > bandwidth you can get with a given ms delay and % packet loss. > > As far as flow control, its really outside the scope. If you ever need flow > control, there is usually a specific reason like FCoE, and if not, it's > generally better to just fix the backplane congestion issue if you can, > than ever worry about using FC. The problem with FC isn't node to node, its > when you have node to node to node with additional devices, it isn't smart > enough to discriminate, and can crater your network 3 devices over when it > would be much better to just lose a few packets. > > -Blake In my experience - if you're traversing licenced microwave links as indicated flow control will definitely need to be ON. Check the radio modem stats to confirm but - if you're seeing lots of drops there you're overflowing the buffers on the radio modem. From bill at herrin.us Tue Aug 27 17:45:02 2013 From: bill at herrin.us (William Herrin) Date: Tue, 27 Aug 2013 13:45:02 -0400 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> Message-ID: On Mon, Aug 26, 2013 at 8:01 PM, Christopher Palmer wrote: > What is the probability that a random path between two Internet > hosts will traverse a middlebox that drops or otherwise barfs on > fragmented IPv4 packets? Hi Christopher, I think there might be three rather different questions here: 1. If I originate IP packet fragments, such as an 8000 byte NFS packet broken into 1500 byte fragments, what's the probability of some host before the other endpoint dropping one or all of those fragments? 2. If I send an IP packet that's too large for the path and *don't* set the don't-fragment bit, what' the chance that the router with the too-small next hop will fail to correctly fragment that packet (or that the correctly fragmented packet will fall into trap #1 above)? 3. If I send an IP packet that's too large for the path and *do* set the don't-fragment bit, what's the chance of failing to receive the "packet too big" message it causes the intermediate router to send? Are you after the answer to one in particular? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nick at flhsi.com Tue Aug 27 18:22:15 2013 From: nick at flhsi.com (Nick Olsen) Date: Tue, 27 Aug 2013 14:22:15 -0400 Subject: TCP Performance Message-ID: <3025777$513803ab$2b2678fd$@flhsi.com> I have indeed tried that. And it didn't make any difference. Functionally limiting each router port to is connected microwave links capacity. And queuing the overflow. However the queue never really fills as the traffic rate never goes higher then the allocated bandwidth. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Blake Dunlap" Sent: Tuesday, August 27, 2013 1:32 PM To: nick at flhsi.com Cc: "Tim Warnock" , "nanog at nanog.org" Subject: Re: TCP Performance If you have a router, you can turn on shaping to the bandwidth the link will support. -Blake On Tue, Aug 27, 2013 at 12:11 PM, Nick Olsen wrote: I do indeed have stats for "TX Pause Frames" And they do increment. However, Our router is ignoring them since it doesn't support flow control. I guess my next question would be. In the scenario where we insert a switch between the radio and the router that does support flow control. Are we not only moving where the overflow is going to occur? Will we not see the router still burst traffic at line rate toward the switch, Which then buffer overflows sending to the radio on account of it receiving pause frames? Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Tim Warnock" Sent: Tuesday, August 27, 2013 1:08 PM To: "Blake Dunlap" , "nick at flhsi.com" Cc: "nanog at nanog.org" Subject: RE: TCP Performance > Regardless, your problem looks like either tail drops or packet loss, which > you showed originally. The task is to find out where this is occurring, and > which of the two it is. If you want to confirm what is going on, there are > some great bandwidth calculators on the internet which will show you what > bandwidth you can get with a given ms delay and % packet loss. > > As far as flow control, its really outside the scope. If you ever need flow > control, there is usually a specific reason like FCoE, and if not, it's > generally better to just fix the backplane congestion issue if you can, > than ever worry about using FC. The problem with FC isn't node to node, its > when you have node to node to node with additional devices, it isn't smart > enough to discriminate, and can crater your network 3 devices over when it > would be much better to just lose a few packets. > > -Blake In my experience - if you're traversing licenced microwave links as indicated flow control will definitely need to be ON. Check the radio modem stats to confirm but - if you're seeing lots of drops there you're overflowing the buffers on the radio modem. From owen at delong.com Tue Aug 27 18:47:15 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Aug 2013 11:47:15 -0700 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <105365.1377614001@turing-police.cc.vt.edu> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <70257.1377579726@turing-police.cc.vt.edu> <5DEF4DE9-3680-4D47-9FF0-1FC3CED0A816@delong.com> <105365.1377614001@turing-police.cc.vt.edu> Message-ID: <02E84CD3-B3E6-4990-8748-8339EA7C27B0@delong.com> On Aug 27, 2013, at 07:33 , Valdis.Kletnieks at vt.edu wrote: > On Tue, 27 Aug 2013 00:34:57 -0700, Owen DeLong said: >> That's a lot of questions he didn't ask. > > This isn't your first rodeo. You should know by now that the question > actually asked, the question *meant* to be asked, and the question that > actually needed answering are often 3 different things. > >> If I send a packet out as a legitimate series of fragments, what is the chance >> that they will get dropped somewhere in the middle of the path between the >> emitting host and the receiving host? > >> To my thinking, the answer to that question is basically "pretty close to 0 and >> if that changes in the core, very bad things will happen." > > Saku Ytti and Emile Aben have numbers that say otherwise. And there must > be a significantly bigger percentage of failures than "pretty close to 0", > or Path MTU Discovery wouldn't have a reputation of being next to useless. No, their numbers describe what happens to single packets of differing sizes. Nothing they did describes results of actually fragmented packets. Owen From elouie at yahoo.com Tue Aug 27 19:02:39 2013 From: elouie at yahoo.com (Eric Louie) Date: Tue, 27 Aug 2013 12:02:39 -0700 Subject: Evaluating Tier 1 Internet providers Message-ID: <017601cea358$00a86ad0$01f94070$@com> Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. I'm open to add other criteria - what would you add to this list? And how would I get a quantitative or qualitative measure of it? routing stability BGP community offerings congestion issues BGP Peering relationships path diversity IPv6 table size Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. I'm shopping for new service and want to do better than choosing on reputation. (or, is reputation also a criteria?) much appreciated, Eric Louie From jabley at hopcount.ca Tue Aug 27 19:14:47 2013 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 27 Aug 2013 15:14:47 -0400 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <017601cea358$00a86ad0$01f94070$@com> References: <017601cea358$00a86ad0$01f94070$@com> Message-ID: <10D5AD8D-7DA5-477F-8FC2-14FDDEB75B84@hopcount.ca> On 2013-08-27, at 15:02, Eric Louie wrote: > Based on various conversation threads on Nanog I've come up with a few > criteria for evaluating Tier 1 providers. I'm open to add other criteria - > what would you add to this list? And how would I get a quantitative or > qualitative measure of it? > > routing stability > > BGP community offerings > > congestion issues > > BGP Peering relationships > > path diversity > > IPv6 table size I would add: - presence of staff in key locations (if 60 Hudson is a critical location for you, find out whether there's someone regularly present in or near the building to clean fibre and help run loopback tests when you need them) - expected time to clue when calling the support number (bonus points for being xkcd-806 compliant) - time taken to turn around BGP import filter changes - response you can expect when you call one day and say "our 10GE is maxed out with inbound traffic from apparently everywhere, it has been going on for an hour, please help" - billing accuracy, and turnaround time for questions raised about invoices received A lot of this comes down to conversations in the NANOG bar with people who have war stories to share. To that extent, I think "reputation" is a good indicator, so long as your sample size is reasonable, and depending on the amount of beer involved. One other thing to think about -- Tier 1 providers are transit free, so your "can be reached by an IP packet from" is naturally limited to specific peering relationships with other Tier 1 providers. Tier 2 providers (those who buy transit from a suitably-diverse set of Tier 1s) can insulate you from route fade due to peering spats. Joe From bhuffake at caida.org Tue Aug 27 19:33:57 2013 From: bhuffake at caida.org (Bradley Huffaker) Date: Tue, 27 Aug 2013 12:33:57 -0700 Subject: looking for hostname geographic hint validation Message-ID: <20130827193357.GP67165@caida.org> We are currently working on an algorithm that automatically detects geographic hints inside of hostnames. At this point we are seeking operators who can validate some of our inferences. Please contact me if you can valid one of the inferences below or can provide us with one we have missed. ########################################### # Inferences ########################################### (International Air Transport Association airport code) http://en.wikipedia.org/wiki/International_Air_Transport_Association_airport_code International Civil Aviation Organization airport code http://en.wikipedia.org/wiki/International_Civil_Aviation_Organization_airport_code COMMON LANGUAGE Location Identifier Code http://en.wikipedia.org/wiki/CLLI largest populated city with the given name for example "sandiego" is "San Diego, CA, US" [^a-z]+[a-z]+\d*.0rbitel.net ([^a-z]+[a-z]+\d*){2}.360.net [^a-z]+[a-z]+\d*.NULL [^a-z]+[a-z]+\d*.aaanet.ru -vis\d*.aapt.net.au .aarnet.net.au [^a-z]+[a-z]+\d*.above.net [^a-z]+[a-z]+\d*.above.net .ac-net.net .accretive-networks.net \d*.acens.net .acesso10.net.br \d*.aco.net .acsalaska.net [^a-z]+[a-z]+\d*.acsalaska.net .wholesale.adamo.es \d*.adaptplc.com .par.adenis.fr -esr\d*.edc\d*.adhost.com -...\d*....\d*.adhost.net ([^a-z]+[a-z]+\d*){2}.adnettelecom.ro -noc.affrc.go.jp ([^a-z]+[a-z]+\d*){5}.africainx.net -........-....africainx.net \d*....afrisp.net \d*.afsnetworks.com .ahrt.hu .rev.hu.ahrt.hu ([^a-z]+[a-z]+\d*){2}.ainaip.net ([^a-z]+[a-z]+\d*){4}.ainaip.net .airband.net ([^a-z]+[a-z]+\d*){2}.airexpress.net.ua ([^a-z]+[a-z]+\d*){3}.airexpress.net.ua ([^a-z]+[a-z]+\d*){2}.airtelbroadband.in \d*.netarch.akamai.com [^a-z]+[a-z]+\d*.akquinet.de \d*.alestra.net.mx \d*-...alkar.net .se.alltele.net ([^a-z]+[a-z]+\d*){3}.alog.com.br .altecom.net ([^a-z]+[a-z]+\d*){2}.alter.net \d*.alter.net \d*.amcbb.net .ameritech.net [^a-z]+[a-z]+\d*.amis.net \d*.amis.net ([^a-z]+[a-z]+\d*){2}.amobia.com .amplivia.fr -..\d*-....\d*.anittel.net 1.antel.net.uy \d*bras\d*-bb\d*.antel.net.uy 01a-ra1.aorta.net 01b-rd1-ae12.aorta.net [^a-z]+[a-z]+\d*.apexn.com.au ([^a-z]+[a-z]+\d*){2}.arbinet.net \d*.arbinet.net [^a-z]+[a-z]+\d*.arianrp.ir .as12703.net \d*....as13237.net .as13285.net ([^a-z]+[a-z]+\d*){2}.as2116.net ([^a-z]+[a-z]+\d*){3}.as2116.net 1.as24557.net.au .ip.as29154.net \d*.as39506.net .at.as39912.net [^a-z]+[a-z]+\d*.as42689.net 1.as4851.net ([^a-z]+[a-z]+\d*){3}.as5580.net [^a-z]+[a-z]+\d*.as5580.net .as5587.net \d*.as6453.net .as8218.eu ([^a-z]+[a-z]+\d*){4}.as9143.net \d*.ascotlc.net \d*.asianetcom.net -xmr.ask4.net 0.bran.asnet.am .astral.ro \d*.-..\d*-.....astral.ro ([^a-z]+[a-z]+\d*){2}.atcsp.co.za -sw0.atdn.net .atman.pl \d*....\d*....atrato.net \d*....atrato.net \d*.attens.net .at.atusmedia.net .avantel.ru [^a-z]+[a-z]+\d*.avonet.cz 49-02.bcb.axione.fr ([^a-z]+[a-z]+\d*){2}.axtel.net .bahnhof.net [^a-z]+[a-z]+\d*.bahnhof.net .basefarm.net ([^a-z]+[a-z]+\d*){3}.bboi.net -agg.bboi.net .bboi.net \d*-h\d*.dslam.bbox.fr .nl.bcc-ip.net ([^a-z]+[a-z]+\d*){2}.bell.ca ([^a-z]+[a-z]+\d*){3}.bell.ca ([^a-z]+[a-z]+\d*){4}.bell.ca [^a-z]+[a-z]+\d*.bell.ca .bellsouth.net [^a-z]+[a-z]+\d*.bellsouth.net \d*.belwue.de ([^a-z]+[a-z]+\d*){2}.belwue.net [^a-z]+[a-z]+\d*.belwue.net [^a-z]+[a-z]+\d*.binc.net \d*.binc.net ([^a-z]+[a-z]+\d*){2}.bit.nl 4.network.bit.nl \d*.blatzheim.com .blix.com .se.borderlight.net .borealisbroadband.net ([^a-z]+[a-z]+\d*){2}.borwood.net [^a-z]+[a-z]+\d*.borwood.net [^a-z]+[a-z]+\d*.brasiltelecom.net.br ([^a-z]+[a-z]+\d*){3}.brcentral.net.br ([^a-z]+[a-z]+\d*){2}.bredband2.net -wy.client.bresnan.net ([^a-z]+[a-z]+\d*){2}.broadviewnet.net .broadviewnet.net [^a-z]+[a-z]+\d*.broadviewnet.net .bt.net [^a-z]+[a-z]+\d*.bt.net -gw01-tu1.bu.edu .businessit.ro .bytemark.co.uk [^a-z]+[a-z]+\d*.c2internet.net ([^a-z]+[a-z]+\d*){2}.cablelynx.com ([^a-z]+[a-z]+\d*){3}.cablenet-as.net -vpls\d*.caribsurf.com \d*.caribsurf.com [^a-z]+[a-z]+\d*.carnet.hr ([^a-z]+[a-z]+\d*){3}.carnet.hr .id.cebridge.net ([^a-z]+[a-z]+\d*){2}.cenic.net ([^a-z]+[a-z]+\d*){3}.cenic.net [^a-z]+[a-z]+\d*.cenic.net ([^a-z]+[a-z]+\d*){4}.century.net.br .centurytel.net ([^a-z]+[a-z]+\d*){3}.centurytel.net \d*.cernet.net \d*.cesnet.cz .la.charter.com ([^a-z]+[a-z]+\d*){3}.charter.com ([^a-z]+[a-z]+\d*){2}.cica.es \d*.red.cica.es 2.cifnet.net ([^a-z]+[a-z]+\d*){3}.cisco.com .clix.net.nz ([^a-z]+[a-z]+\d*){2}.cloud-ix.net \d*-\d*.dslam.club-internet.fr \d*.club-internet.fr ([^a-z]+[a-z]+\d*){3}.cmcnetworks.net -.......cnc.net .he.cns-internet.com \d*.cns-internet.com [^a-z]+[a-z]+\d*.cogentco.com [^a-z]+[a-z]+\d*.cogentco.com .colocrossing.com [^a-z]+[a-z]+\d*.colt.net [^a-z]+[a-z]+\d*.columbus-networks.com ([^a-z]+[a-z]+\d*){2}.comcast.net [^a-z]+[a-z]+\d*.comcastbusiness.net ([^a-z]+[a-z]+\d*){2}.comhem.se .comindico.com.au .commcorp.net.br .comstar-r.ru .comstar.ru [^a-z]+[a-z]+\d*.comstar.ru ([^a-z]+[a-z]+\d*){2}.convergenze.it \d*.convergenze.it .copel.net ([^a-z]+[a-z]+\d*){2}.corbina.net ([^a-z]+[a-z]+\d*){3}.corbina.net [^a-z]+[a-z]+\d*.corbina.net ([^a-z]+[a-z]+\d*){4}.corbina.net \d*.core-backbone.com ([^a-z]+[a-z]+\d*){2}.coreix.net ([^a-z]+[a-z]+\d*){2}.corenap.com ([^a-z]+[a-z]+\d*){3}.corenap.com -\d*-\d*.meq.corenap.com \d*.corexchange.com .covad.com .ok.cox.net \d*-cr\d*-be\d*.cprm.net ([^a-z]+[a-z]+\d*){6}.csc.com .csolutions.net ([^a-z]+[a-z]+\d*){2}.ct.gov ([^a-z]+[a-z]+\d*){2}.cutcom.net -.......cw.net .cw.net [^a-z]+[a-z]+\d*.cw.net \d*.cwpanama.net .cyber.net.pk ([^a-z]+[a-z]+\d*){2}.cypresscom.net \d*....cyta-ip.net \d*.cytanet.com.cy \d*-loc-cr\d*.damamax.net \d*-loc.damamax.net .danaher.net \d*.datafoundry.net [^a-z]+[a-z]+\d*.dataline.net.ua ([^a-z]+[a-z]+\d*){2}.dataphone.net [^a-z]+[a-z]+\d*.dbd-breitband.de \d*.dbnet.dk .dellservices.net ([^a-z]+[a-z]+\d*){3}.demon.net [^a-z]+[a-z]+\d*.demos.net ([^a-z]+[a-z]+\d*){2}.dfn.de ([^a-z]+[a-z]+\d*){3}.dfn.de .dft.com.au .dialog.net.pl .digi.pl .za.digi.pl ([^a-z]+[a-z]+\d*){3}.digica.com ([^a-z]+[a-z]+\d*){2}.digitalcable.ro 1.digitalwest.net .....digitelitalia.com [^a-z]+[a-z]+\d*.digsys.bg \d*.digsys.bg [^a-z]+[a-z]+\d*.direct.net.in ([^a-z]+[a-z]+\d*){3}.diveo.net.br .dls.net ([^a-z]+[a-z]+\d*){2}.dnaip.fi [^a-z]+[a-z]+\d*.dnaip.fi ([^a-z]+[a-z]+\d*){2}.doruk.net.tr ([^a-z]+[a-z]+\d*){3}.doruk.net.tr .doruk.net.tr [^a-z]+[a-z]+\d*.doruk.net.tr .dren.net [^a-z]+[a-z]+\d*.dren.net [^a-z]+[a-z]+\d*.dsl.net ........dtag.de .dts.mg ([^a-z]+[a-z]+\d*){3}.duke.edu .e-xpedient.com [^a-z]+[a-z]+\d*.eastman.net.uk \d*.ixmad.es.easynet.net .edgetelecom.net.uk .eircom.net .electro-com.ru .elisa.ee .elte.hu ([^a-z]+[a-z]+\d*){3}.embratel.net.br .embratel.net.br ([^a-z]+[a-z]+\d*){2}.emman.net .ensite.com.br ([^a-z]+[a-z]+\d*){2}.enta.net [^a-z]+[a-z]+\d*.enta.net -\d*.bb.entelchile.net .entelchile.net [^a-z]+[a-z]+\d*.entelnet.bo .enventis.net .epikip.net -e100.cust.gw.epoch.net ([^a-z]+[a-z]+\d*){2}.ercbroadband.org ([^a-z]+[a-z]+\d*){3}.ercbroadband.org ([^a-z]+[a-z]+\d*){2}.ernet.in -backbone.ernet.in .ertelecom.ru .esc.net.au .estpak.ee -bg-\d*-ae\d*.eunet.rs [^a-z]+[a-z]+\d*.eunet.rs [^a-z]+[a-z]+\d*.eunetip.net [^a-z]+[a-z]+\d*.eunx.net ([^a-z]+[a-z]+\d*){3}.eut.ru \d*.evolink.net .ew.ro [^a-z]+[a-z]+\d*.ewe-ip-backbone.de ([^a-z]+[a-z]+\d*){2}.fasttelco.net \d*.fasttelco.net .fcc.ad.jp 1gai.fcc.ad.jp .fcibroadband.com -cmts\d*.fibernet.hu .fiberpipe.net .fidnet.com [^a-z]+[a-z]+\d*.fidnet.com ([^a-z]+[a-z]+\d*){4}.fiord.ru 01.us.firehost.com -dc3.firenet.net.au \d*.flagtel.com ([^a-z]+[a-z]+\d*){4}.flrnet.org -..-.\d*.....flrnet.org .forthnet.gr [^a-z]+[a-z]+\d*.fplfn.net .fraunhofer.de ([^a-z]+[a-z]+\d*){2}.free.net ([^a-z]+[a-z]+\d*){3}.fregat.net ([^a-z]+[a-z]+\d*){2}.frogfoot.net .in.frontiernet.net ([^a-z]+[a-z]+\d*){2}.frontiernet.net -gw.fsknet.dk .dk.ip.fullrate.dk \d*.funet.fi ([^a-z]+[a-z]+\d*){2}.fuse.net .g8.net.br ([^a-z]+[a-z]+\d*){2}.garr.net ([^a-z]+[a-z]+\d*){3}.gblnet.ru \d*.gblx.net \d*-...-..gbonline.com.br \d*.uk.gbxs.net [^a-z]+[a-z]+\d*.geant.net ....geant2.net .gibtelecom.net .gldn.net .globalcom.lv .glowpoint.net .golden.ru ([^a-z]+[a-z]+\d*){2}.golden.ru .grandecom.net \d*-\d*-\d*.ip.granderiver.com ([^a-z]+[a-z]+\d*){2}.grnet.gr \d*.ptp.gru.net .........gts.sk .gvt.net.br .de.hansenet.net .hbone.hu [^a-z]+[a-z]+\d*.hbone.hu ([^a-z]+[a-z]+\d*){2}.hbone.hu \d*.he.net \d*.hopone.net \d*.host-h.net .host.net .hostedsolutions.com \d*.hosting.com ([^a-z]+[a-z]+\d*){3}.hotnet.net.il .hotze.com .hp.com .hypnet.pl \d*.colo\d*.dus.iacd.net .core\d*.ibtelecom.net.br .ibtelecom.net.br ([^a-z]+[a-z]+\d*){3}.ic.ac.uk .ielo.net 0.ifb.net .th2.ifl.net ([^a-z]+[a-z]+\d*){3}.ii.net \d*.on.ii.net \d*.iinet.com ([^a-z]+[a-z]+\d*){2}.iinet.net.au ([^a-z]+[a-z]+\d*){3}.imp.ch [^a-z]+[a-z]+\d*.in.ua ([^a-z]+[a-z]+\d*){4}.indosat.com ([^a-z]+[a-z]+\d*){5}.indosat.com .inet.de \d*.de.inetbone.net [^a-z]+[a-z]+\d*.inetia.pl .infolink.ru -\d*.net.infomaniak.ch 1.inforelay.net [^a-z]+[a-z]+\d*.init7.net .inoc.net -pol43.cr.inotel.net 01.integra.net 01.intelepeer.net ([^a-z]+[a-z]+\d*){2}.intelsatone.net .interhost.com ([^a-z]+[a-z]+\d*){3}.interop.net .enet.interop.net ([^a-z]+[a-z]+\d*){2}.interoute.net -...-.....-\d*-..\d*.interoute.net -...\d*.....intrinsec.net -pe\d*.invitel.net -....-..iovation.com [^a-z]+[a-z]+\d*.iowatelecom.net \d*.ip-max.net -.-\d*-...\d*-\d*....ip-plus.net ([^a-z]+[a-z]+\d*){3}.ipartners.pl [^a-z]+[a-z]+\d*.ipartners.pl ([^a-z]+[a-z]+\d*){2}.ipb.na .iprimus.net.au .iptransit.com .iquest.net ([^a-z]+[a-z]+\d*){2}.irtel.ru -3-l0.irtel.ru 1.isc.org ([^a-z]+[a-z]+\d*){3}.iseek.com.au [^a-z]+[a-z]+\d*.iseek.com.au ([^a-z]+[a-z]+\d*){2}.isnet.net ([^a-z]+[a-z]+\d*){3}.isnet.net [^a-z]+[a-z]+\d*.isomedia.com .itgate.net ([^a-z]+[a-z]+\d*){2}.ja.net ([^a-z]+[a-z]+\d*){3}.ja.net ([^a-z]+[a-z]+\d*){5}.ja.net \d*.jaring.my \d*.jmfnetworks.net .jussieu.fr -co.k12.ca.us \d*.......\d*.kaiaglobal.com .net.kanren.net \d*ml\d*.bb.kddi.ne.jp \d*.kems.net .kent.edu ([^a-z]+[a-z]+\d*){2}.kis.ru .kpnqwest.it .....ktk.de ([^a-z]+[a-z]+\d*){2}.la.net ([^a-z]+[a-z]+\d*){3}.la.net [^a-z]+[a-z]+\d*.la.net .net.lagis.at [^a-z]+[a-z]+\d*.lambdanet.net ([^a-z]+[a-z]+\d*){4}.latisys.net -..latisys.net \d*.level3.net ......liazo.net [^a-z]+[a-z]+\d*.lightpath.net .lincon.net ([^a-z]+[a-z]+\d*){2}.link.net.pk ([^a-z]+[a-z]+\d*){3}.link.net.pk .link.net.pk \d*.linnea.net ([^a-z]+[a-z]+\d*){2}.linxtelecom.net [^a-z]+[a-z]+\d*.liquidtelecom.net \d*.liquidtelecom.net \d*.llnw.net ([^a-z]+[a-z]+\d*){3}.logic.bm \d*.logic.bm [^a-z]+[a-z]+\d*.m247.com ([^a-z]+[a-z]+\d*){4}.malagasy.com -e1.malagasy.com 01-core01.agg01.mango.com.bd .maxnet.ir .maxnet.ru .infra.mcs.de ([^a-z]+[a-z]+\d*){3}.mediaways.net \d*-...\d*....megapath.net .bb.megapath.net .megapath.net .megared.net.mx [^a-z]+[a-z]+\d*.megared.net.mx \d*.mesh.eu .metrolink.it ([^a-z]+[a-z]+\d*){2}.metronet-uk.com [^a-z]+[a-z]+\d*.mich.net \d*.mich.net .midco.net .mm.pl .mnsbone.net ([^a-z]+[a-z]+\d*){3}.more.net ..........movistar.cl \d*.mozyops.net .mpg.de ([^a-z]+[a-z]+\d*){4}.mpg.de ([^a-z]+[a-z]+\d*){5}.mpg.de \d*.mrse.com.ar ([^a-z]+[a-z]+\d*){3}.msn.net -\d*e-\d*.ntwk.msn.net ([^a-z]+[a-z]+\d*){6}.mtn.net [^a-z]+[a-z]+\d*.mtnbusiness.co.ke \d*....mtnbusiness.net \d*.mtnns.net \d*.na.mtnns.net [^a-z]+[a-z]+\d*.mts-nn.ru ([^a-z]+[a-z]+\d*){2}.multicom-ip.se ([^a-z]+[a-z]+\d*){3}.multicom-ip.se \d*.multimedia-bg.net ([^a-z]+[a-z]+\d*){3}.mweb.co.za .mweb.co.za [^a-z]+[a-z]+\d*.mweb.co.za ([^a-z]+[a-z]+\d*){2}.myren.net.my \d*.mzima.net ......nasa.gov ([^a-z]+[a-z]+\d*){3}.nask.pl [^a-z]+[a-z]+\d*.natm.ru .fi.nblnet.com .ncable.net.au [^a-z]+[a-z]+\d*.ncnetwork.net ([^a-z]+[a-z]+\d*){3}.ncren.net [^a-z]+[a-z]+\d*.ncren.net [^a-z]+[a-z]+\d*.nejtv.cz .net.bw [^a-z]+[a-z]+\d*.net2ez.com ([^a-z]+[a-z]+\d*){3}.netatonce.net ([^a-z]+[a-z]+\d*){4}.netbox.cz -r\d*-e\d*.mng.netbox.cz -...........netins.net [^a-z]+[a-z]+\d*.netins.net .netkom-line.net .netline.net.uk \d*.core.netline.net.uk ([^a-z]+[a-z]+\d*){2}.netnw.net.uk [^a-z]+[a-z]+\d*.netnw.net.uk ([^a-z]+[a-z]+\d*){2}.netsville.com [^a-z]+[a-z]+\d*.netvision.net.il [^a-z]+[a-z]+\d*.networkgci.net \d*.networklayer.com .networkvirginia.net [^a-z]+[a-z]+\d*.netwurx.net .at.nextlayer.net .ngdc.net [^a-z]+[a-z]+\d*.nisag.li 1.nitelusa.net \d*.us.nlayer.net ([^a-z]+[a-z]+\d*){5}.nmmn.net .no-wires.net [^a-z]+[a-z]+\d*.no-wires.net -bdr\d*.noanet.net .tc.nodefour.net .noelcomm.com ([^a-z]+[a-z]+\d*){3}.nokia.com -\d*-lo\d*.northwestern.edu \d*.tch.dtn.ntl.com .dial.ntli.net -....-..nts-online.net ([^a-z]+[a-z]+\d*){3}.ntt.net ([^a-z]+[a-z]+\d*){3}.ntt.net \d*.fw\d*.nucleus.be 1.nursat.net ([^a-z]+[a-z]+\d*){2}.nuvox.net ([^a-z]+[a-z]+\d*){2}.nv.net.il .nxg.net.au \d*.nysernet.net ([^a-z]+[a-z]+\d*){3}.odn.ad.jp \d*-cre\d*.omegabyte.com ([^a-z]+[a-z]+\d*){2}.on.net .lxa.us.oneandone.net [^a-z]+[a-z]+\d*.oneandone.net .oneringnetworks.net ([^a-z]+[a-z]+\d*){6}.onet.pl ([^a-z]+[a-z]+\d*){2}.online.kz [^a-z]+[a-z]+\d*.online.kz .onqnetworks.net ([^a-z]+[a-z]+\d*){3}.onshore.net [^a-z]+[a-z]+\d*.onshore.net \d*.onshore.net .opaltelecom.net .openaccess.org .opentransit.net [^a-z]+[a-z]+\d*.opentransit.net -dvcs.opticon.hu .opticon.hu .oracle.com .oregon-gigapop.net \d*.ovea.com .core.overthewire.net.au \d*.overthewire.net.au ....p80.net \d*.pacenet-india.com \d*.pacific.net.au \d*.pacific.net.in .pacificwave.net 1.us.packetexchange.net \d*.\d*..\d*.paetec.net \d*.paetec.net .panservice.it ([^a-z]+[a-z]+\d*){4}.pccwbtn.net \d*.pccwbtn.net ([^a-z]+[a-z]+\d*){2}.peak.org [^a-z]+[a-z]+\d*.peak.org \d*.peak10.net ([^a-z]+[a-z]+\d*){2}.peer1.net ([^a-z]+[a-z]+\d*){2}.pie.net.pk 77.pie.net.pk [^a-z]+[a-z]+\d*.pie.net.pk ([^a-z]+[a-z]+\d*){2}.pionier.gov.pl .pipenetworks.com ([^a-z]+[a-z]+\d*){2}.pipenetworks.com \d*.planethoster.net \d*.....plat.net.au .platinum.ca \d*.pnap.net \d*-\d*.infra.pnw-gigapop.net ([^a-z]+[a-z]+\d*){2}.pocketinet.com [^a-z]+[a-z]+\d*.poda.cz [^a-z]+[a-z]+\d*.popsite.net ([^a-z]+[a-z]+\d*){2}.port80.se .port80.se \d*....portlane.net \d*.primus.ca ([^a-z]+[a-z]+\d*){2}.profibernet.dk ([^a-z]+[a-z]+\d*){4}.proxad.net ([^a-z]+[a-z]+\d*){5}.proxad.net [^a-z]+[a-z]+\d*.proxad.net ([^a-z]+[a-z]+\d*){2}.ptd.net ([^a-z]+[a-z]+\d*){3}.ptd.net ([^a-z]+[a-z]+\d*){4}.ptd.net ([^a-z]+[a-z]+\d*){5}.ptd.net \d*.q9.net [^a-z]+[a-z]+\d*.qatar.net.qa .qsc.de 1.qualitytech.com .qwest.net ([^a-z]+[a-z]+\d*){2}.qwest.net .se.rackfish.net \d*.rackspace.net ([^a-z]+[a-z]+\d*){4}.ragingwire.net .rap.prd.fr .rdsnet.ro ([^a-z]+[a-z]+\d*){2}.redclara.net 2.redhat.com .red.rediris.es .renater.fr ....retn.net ([^a-z]+[a-z]+\d*){2}.rhnet.is -gw\d*.rhnet.is ([^a-z]+[a-z]+\d*){4}.rionet.cz ([^a-z]+[a-z]+\d*){5}.rionet.cz ([^a-z]+[a-z]+\d*){8}.rionet.cz .riu.edu.ar -...rnp.br .roedu.net .rogers.com 1.rogerstelecom.net \d*-\d*b.rogerstelecom.net ([^a-z]+[a-z]+\d*){2}.rosprint.net .ip.rostelecom.ru .rr.com ([^a-z]+[a-z]+\d*){2}.rsaweb.co.za [^a-z]+[a-z]+\d*.rsaweb.co.za .runnet.ru -gw.ruscomnet.ru -....-...-\d*.....rwth-aachen.de -out-\d*.noc.rwth-aachen.de [^a-z]+[a-z]+\d*.rwth-aachen.de -core.rz-online.net .rz-online.net ([^a-z]+[a-z]+\d*){3}.sadv.co.za .sagonet.net \d*rr\d*-a.sancharnet.in .sanet2.sk .satnet.net ([^a-z]+[a-z]+\d*){2}.savvis.net .savvis.net ([^a-z]+[a-z]+\d*){6}.savvis.net 1.va.saxonshoes.com .sbcglobal.net \d*...sbcglobal.net ([^a-z]+[a-z]+\d*){3}.scarlet.an \d*.us.scnet.net \d*.....seabone.net -\d*-access-\d*.mpls.seacomnet.com .seas-nve.net .seeweb.it ([^a-z]+[a-z]+\d*){2}.selection.co.uk \d*.sentex.ca ([^a-z]+[a-z]+\d*){2}.sentex.ca 3.server-noc.com \d*.servernap.net ([^a-z]+[a-z]+\d*){2}.sibirtelecom.ru .sibirtelecom.ru .sify.net [^a-z]+[a-z]+\d*.sil.at .uk.core.simwood.com .uk.simwood.com ([^a-z]+[a-z]+\d*){2}.sinet.ad.jp ([^a-z]+[a-z]+\d*){3}.sinet.ad.jp -\d*.gw.sinet.ad.jp \d*.singlehop.net .ppp.sint.pl .sint.pl .us.siteprotect.com [^a-z]+[a-z]+\d*.skh.net.ru .sky-vision.net [^a-z]+[a-z]+\d*.skyband.mw ([^a-z]+[a-z]+\d*){2}.skybeam.net .skybeam.net [^a-z]+[a-z]+\d*.skybeam.net .skylink.ru .gw.smitcoms.net ....sn.net -dakar\d*.sonatel.sn [^a-z]+[a-z]+\d*.spark-ryazan.ru .sparkplugbb.net \d*.dsl.speakeasy.net \d*.speakeasy.net ([^a-z]+[a-z]+\d*){2}.spectrumnet.us [^a-z]+[a-z]+\d*.spectrumnet.us [^a-z]+[a-z]+\d*.spnet.net .spotify.com .sprintlink.net [^a-z]+[a-z]+\d*.sprintlink.net ([^a-z]+[a-z]+\d*){2}.starman.ee ([^a-z]+[a-z]+\d*){3}.start.ca .stech.net.br .stisp.net [^a-z]+[a-z]+\d*.stmarys-ca.edu .strencom.net \d*.stupi.net ([^a-z]+[a-z]+\d*){2}.su.se .....suddenlink.net \d*.suddenlink.net [^a-z]+[a-z]+\d*.sunet.se \d*.suomicom.fi ([^a-z]+[a-z]+\d*){2}.surf.net .synterra-sib.ru ([^a-z]+[a-z]+\d*){4}.synterra.ru 1-atm.syringanetworks.net \d*.syringanetworks.net \d*-ppp\d*.t-net.net.ve ([^a-z]+[a-z]+\d*){3}.talkinternet.co.uk ([^a-z]+[a-z]+\d*){3}.tche.br .tche.br .tcisl.net.in .tcl.net.in .......tdc.net \d*.cable.teksavvy.com .telconet.net ([^a-z]+[a-z]+\d*){2}.tele2.net ([^a-z]+[a-z]+\d*){3}.tele2.net [^a-z]+[a-z]+\d*.tele2.net [^a-z]+[a-z]+\d*.telecity.net \d*.telecity.net [^a-z]+[a-z]+\d*.telecom.by ([^a-z]+[a-z]+\d*){2}.telefonica-wholesale.net -...\d*-......telefonica.de ([^a-z]+[a-z]+\d*){2}.teleguam.net ([^a-z]+[a-z]+\d*){2}.telekom.hu ([^a-z]+[a-z]+\d*){2}.telemar.net.br .telemaxx.net .teletrans.ro ([^a-z]+[a-z]+\d*){2}.telia.net ([^a-z]+[a-z]+\d*){3}.telia.net -bb1.telia.net \d*.telkom-ipnet.co.za ([^a-z]+[a-z]+\d*){2}.telkom.net.id ([^a-z]+[a-z]+\d*){3}.teloip.net .teloip.net ([^a-z]+[a-z]+\d*){3}.telstra.net .telstra.net 1-dia.telxgroup.net ([^a-z]+[a-z]+\d*){3}.tenet.ac.za ([^a-z]+[a-z]+\d*){4}.tenet.ac.za [^a-z]+[a-z]+\d*.terra.com.br .terremark.net \d*.tfbnw.net .ti.ru ([^a-z]+[a-z]+\d*){3}.ti.ru ([^a-z]+[a-z]+\d*){2}.tiare.net.pg .time.net.my \d*.uk.timico.net ([^a-z]+[a-z]+\d*){3}.tinet.net [^a-z]+[a-z]+\d*.tinet.net ([^a-z]+[a-z]+\d*){2}.tip.net \d*.tiscali.cz ([^a-z]+[a-z]+\d*){2}.tktelekom.pl ([^a-z]+[a-z]+\d*){4}.tm.net.my -dr\d*-v\d*.tm.net.my \d*.tng.de .at.tnib.net \d*.tnp.pl .top.net.ua .topnet.it ([^a-z]+[a-z]+\d*){2}.totisp.net .towerstream.com 1.twrs.ri.towerstream.com ([^a-z]+[a-z]+\d*){2}.towerstream.net [^a-z]+[a-z]+\d*.towerstream.net -...\d*.tpgi.com.au \d*.transedge.com -ttk-gw.transtelecom.net \d*.transtelecom.net [^a-z]+[a-z]+\d*.true.nl ([^a-z]+[a-z]+\d*){2}.ttc-net.ru .ttcldata.net [^a-z]+[a-z]+\d*.ttnet.cz .tu-dresden.de ([^a-z]+[a-z]+\d*){3}.turk.net ([^a-z]+[a-z]+\d*){4}.turk.net \d*.turktelekom.com.tr \d*cw.tx.twcbiz.com \d*.twdx.net ([^a-z]+[a-z]+\d*){3}.twtelecom.net \d*-er\d*.twttr.com ([^a-z]+[a-z]+\d*){2}.tx-bb.net .tx-learn.net ([^a-z]+[a-z]+\d*){4}.ucdavis.edu .ucomline.net ([^a-z]+[a-z]+\d*){3}.ufamts.ru -nat\d*-v\d*.ufamts.ru \d*.ufanet.ru ([^a-z]+[a-z]+\d*){4}.ufl.edu ([^a-z]+[a-z]+\d*){3}.ufmg.br [^a-z]+[a-z]+\d*.uib.no -a.ujf-grenoble.fr [^a-z]+[a-z]+\d*.uky.edu \d*-............umanitoba.ca .umich.edu 7200.core.ri3.unam.mx ([^a-z]+[a-z]+\d*){2}.uni-giessen.de .uni-jena.de ([^a-z]+[a-z]+\d*){5}.uni-stuttgart.net ([^a-z]+[a-z]+\d*){2}.unimi.it ([^a-z]+[a-z]+\d*){2}.uninet.net.mx ([^a-z]+[a-z]+\d*){3}.uninet.net.mx [^a-z]+[a-z]+\d*.uninett.no ([^a-z]+[a-z]+\d*){3}.unity-media.net .unity-media.net .akl.unleash.net.nz .unleash.net.nz 1.upc.at .ussignalcom.net ([^a-z]+[a-z]+\d*){2}.uta.at [^a-z]+[a-z]+\d*.uta.at ([^a-z]+[a-z]+\d*){2}.utk.edu .ops.us.uu.net 1.verisign.com [^a-z]+[a-z]+\d*.verizon-gni.net ([^a-z]+[a-z]+\d*){2}.verizon-gni.net ......verizon.net .dsl-w.verizon.net [^a-z]+[a-z]+\d*.versatel.de ([^a-z]+[a-z]+\d*){2}.vianet.ca .viatel.ee \d*.viawest.net ([^a-z]+[a-z]+\d*){2}.vipowernet.net .virtua.com.br ([^a-z]+[a-z]+\d*){2}.vivodi.gr ([^a-z]+[a-z]+\d*){3}.vocus.net.au -gw.diamond.volia.net .volia.net \d*...vonagenetworks.net [^a-z]+[a-z]+\d*.voxel.net \d*....\d*....voxel.net ([^a-z]+[a-z]+\d*){2}.voxility.net \d*.vrsn.net .vsnl.net.in [^a-z]+[a-z]+\d*.vsnl.net.in ([^a-z]+[a-z]+\d*){2}.vsnl.net.in .vt.ru [^a-z]+[a-z]+\d*.vt.ru ([^a-z]+[a-z]+\d*){2}.wa-k20.net \d*.....waycom.net ([^a-z]+[a-z]+\d*){2}.wayport.net ([^a-z]+[a-z]+\d*){3}.wayport.net .wbs.co.za ([^a-z]+[a-z]+\d*){2}.wcg.net ([^a-z]+[a-z]+\d*){3}.wcg.net [^a-z]+[a-z]+\d*.wcom.net ([^a-z]+[a-z]+\d*){2}.wctc.net -\d*..wctc.net .wildcard.net.uk -hub-eth0.wiscnet.net [^a-z]+[a-z]+\d*.wispnet.net ([^a-z]+[a-z]+\d*){4}.wm.edu ([^a-z]+[a-z]+\d*){5}.wm.edu -..\d*.wolcomm.net [^a-z]+[a-z]+\d*.worldspice.net ([^a-z]+[a-z]+\d*){2}.xo.net \d*.xs4all.net \d*.xtraordinary.net.uk .yahoo.com .ygnition.net [^a-z]+[a-z]+\d*.yipes.com \d*.youbroadband.in ([^a-z]+[a-z]+\d*){4}.zenon.net .zitomedia.net ([^a-z]+[a-z]+\d*){2}.zonedata.net ([^a-z]+[a-z]+\d*){4}.zsttk.ru .zsttk.ru .zumpatelecom.com.br -- the value of a world model is not how accurately it captures reality but how often it leads us to take appropriate action From streiner at cluebyfour.org Tue Aug 27 16:17:19 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 27 Aug 2013 12:17:19 -0400 (EDT) Subject: Evaluating Tier 1 Internet providers In-Reply-To: <017601cea358$00a86ad0$01f94070$@com> References: <017601cea358$00a86ad0$01f94070$@com> Message-ID: On Tue, 27 Aug 2013, Eric Louie wrote: > Based on various conversation threads on Nanog I've come up with a few > criteria for evaluating Tier 1 providers. I'm open to add other criteria - > what would you add to this list? And how would I get a quantitative or > qualitative measure of it? Define "Tier 1 provider". I ask this because it's something that many people don't know what it means, but assume that Tier 1 > Tier !=1. > routing stability Routeviews.org can shed some light here. > BGP community offerings If $provider has a page on www.peeringdb.com, they might publish a list of their BGP communities there. Other places to look would be the provider's whois/IRR entries, and on their respective websites, or the sales/marketing folks might be able to get this information for you. > congestion issues There are various internet traffic report / weather report sites that can give you indirect insight into things like. By indirect, I mean that you might be able to infer things like congestion at a specific point based on what you see on those sites. > BGP Peering relationships You can look at pages like www.peeringdb.com, and you will typically see if $provider is at an exchange, however the peering relationships that many providers have other providers (locations, speeds, etc) are confidential. > path diversity You can ask $provider's sales and marketing folks, but there is no guarantee that you will get an answer (actual routes are considered confidential and proprietary information, despite the fact that a lot of providers' fiber ends up converging in a small handful of routes in some areas - i.e. many of them follow the same set of railroad tracks or cross a river at the same bridge, possibly even in the same conduit) or a correct answer (wave X might be re-groomed onto path Y without a whole lot of customer notification). > IPv6 table size Sites like routeviews.org can give you some visibility here. > Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 > customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. > I'm shopping for new service and want to do better than choosing on > reputation. (or, is reputation also a criteria?) Absolutely reputation should be a factor. I would argue that Internet access is largely commoditized anymore (and has been for several years), so the real differentiators are cost and level of service. jms From woody at pch.net Tue Aug 27 20:16:43 2013 From: woody at pch.net (Bill Woodcock) Date: Tue, 27 Aug 2013 13:16:43 -0700 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <017601cea358$00a86ad0$01f94070$@com> References: <017601cea358$00a86ad0$01f94070$@com> Message-ID: <1E7B369F-30BC-4218-B1D9-80ECE3E63661@pch.net> On Aug 27, 2013, at 12:02 PM, Eric Louie wrote: > Based on various conversation threads on Nanog I've come up with a few > criteria for evaluating Tier 1 providers. It's easy. Tier 1 is yourself. Tier 2 is your customers and your competitors. Tier 3 is your customers' customers, your competitors' customers, and your customers' competitors. But yes, I'm sure there are as many criteria as there are NANOG subscribers. But Joe Abley's are the correct ones. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From elouie at yahoo.com Tue Aug 27 20:41:19 2013 From: elouie at yahoo.com (Eric Louie) Date: Tue, 27 Aug 2013 13:41:19 -0700 Subject: Evaluating Tier 1 Internet providers In-Reply-To: References: <017601cea358$00a86ad0$01f94070$@com> Message-ID: <019e01cea365$c91760e0$5b4622a0$@com> Good stuff Justin - Any other criteria that you would use? much appreciated, Eric Louie -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Tuesday, August 27, 2013 9:17 AM To: nanog at nanog.org Subject: Re: Evaluating Tier 1 Internet providers On Tue, 27 Aug 2013, Eric Louie wrote: > Based on various conversation threads on Nanog I've come up with a few > criteria for evaluating Tier 1 providers. I'm open to add other > criteria - what would you add to this list? And how would I get a > quantitative or qualitative measure of it? Define "Tier 1 provider". I ask this because it's something that many people don't know what it means, but assume that Tier 1 > Tier !=1. > routing stability Routeviews.org can shed some light here. > BGP community offerings If $provider has a page on www.peeringdb.com, they might publish a list of their BGP communities there. Other places to look would be the provider's whois/IRR entries, and on their respective websites, or the sales/marketing folks might be able to get this information for you. > congestion issues There are various internet traffic report / weather report sites that can give you indirect insight into things like. By indirect, I mean that you might be able to infer things like congestion at a specific point based on what you see on those sites. > BGP Peering relationships You can look at pages like www.peeringdb.com, and you will typically see if $provider is at an exchange, however the peering relationships that many providers have other providers (locations, speeds, etc) are confidential. > path diversity You can ask $provider's sales and marketing folks, but there is no guarantee that you will get an answer (actual routes are considered confidential and proprietary information, despite the fact that a lot of providers' fiber ends up converging in a small handful of routes in some areas - i.e. many of them follow the same set of railroad tracks or cross a river at the same bridge, possibly even in the same conduit) or a correct answer (wave X might be re-groomed onto path Y without a whole lot of customer notification). > IPv6 table size Sites like routeviews.org can give you some visibility here. > Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 > customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. > I'm shopping for new service and want to do better than choosing on > reputation. (or, is reputation also a criteria?) Absolutely reputation should be a factor. I would argue that Internet access is largely commoditized anymore (and has been for several years), so the real differentiators are cost and level of service. jms From elouie at yahoo.com Tue Aug 27 20:45:34 2013 From: elouie at yahoo.com (Eric Louie) Date: Tue, 27 Aug 2013 13:45:34 -0700 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <10D5AD8D-7DA5-477F-8FC2-14FDDEB75B84@hopcount.ca> References: <017601cea358$00a86ad0$01f94070$@com> <10D5AD8D-7DA5-477F-8FC2-14FDDEB75B84@hopcount.ca> Message-ID: <01a101cea366$61326f50$23974df0$@com> Clued-in support is a good criteria. (I've been using a broker for some of my connections and there was virtually no value-add there, especially in the prefix-list modifications, and a liability in other MACs) That's a good point with the Tier 2 providers. So that begs the question, why wouldn't I just get my upstream from a Tier 2? (Because my management is under the perception that we're better off with Tier 1 providers, but that doesn't mean their perception is accurate) much appreciated, Eric Louie -----Original Message----- From: Joe Abley [mailto:jabley at hopcount.ca] Sent: Tuesday, August 27, 2013 12:15 PM To: Eric Louie Cc: nanog at nanog.org Subject: Re: Evaluating Tier 1 Internet providers On 2013-08-27, at 15:02, Eric Louie wrote: > Based on various conversation threads on Nanog I've come up with a few > criteria for evaluating Tier 1 providers. I'm open to add other > criteria - what would you add to this list? And how would I get a > quantitative or qualitative measure of it? > > routing stability > > BGP community offerings > > congestion issues > > BGP Peering relationships > > path diversity > > IPv6 table size I would add: - presence of staff in key locations (if 60 Hudson is a critical location for you, find out whether there's someone regularly present in or near the building to clean fibre and help run loopback tests when you need them) - expected time to clue when calling the support number (bonus points for being xkcd-806 compliant) - time taken to turn around BGP import filter changes - response you can expect when you call one day and say "our 10GE is maxed out with inbound traffic from apparently everywhere, it has been going on for an hour, please help" - billing accuracy, and turnaround time for questions raised about invoices received A lot of this comes down to conversations in the NANOG bar with people who have war stories to share. To that extent, I think "reputation" is a good indicator, so long as your sample size is reasonable, and depending on the amount of beer involved. One other thing to think about -- Tier 1 providers are transit free, so your "can be reached by an IP packet from" is naturally limited to specific peering relationships with other Tier 1 providers. Tier 2 providers (those who buy transit from a suitably-diverse set of Tier 1s) can insulate you from route fade due to peering spats. Joe From streiner at cluebyfour.org Tue Aug 27 17:05:57 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 27 Aug 2013 13:05:57 -0400 (EDT) Subject: Evaluating Tier 1 Internet providers In-Reply-To: <019e01cea365$c91760e0$5b4622a0$@com> References: <017601cea358$00a86ad0$01f94070$@com> <019e01cea365$c91760e0$5b4622a0$@com> Message-ID: On Tue, 27 Aug 2013, Eric Louie wrote: > Good stuff Justin - Any other criteria that you would use? Joe covered a lot of good stuff in his response. A few providers call themselves Tier 1, though the accuracy of those assertions is often suspect. The truth can be somewhat more complicated... and exactly how much more complicated isn't always clear until Provider X gets de-peered by Provider Y and finds themselves having to negotiate a quick fix, often by cutting a check. I would also ask people here who they have had very good experiences with, regardless of what "tier" the provider fits into. jms > -----Original Message----- > From: Justin M. Streiner [mailto:streiner at cluebyfour.org] > Sent: Tuesday, August 27, 2013 9:17 AM > To: nanog at nanog.org > Subject: Re: Evaluating Tier 1 Internet providers > > On Tue, 27 Aug 2013, Eric Louie wrote: > >> Based on various conversation threads on Nanog I've come up with a few >> criteria for evaluating Tier 1 providers. I'm open to add other >> criteria - what would you add to this list? And how would I get a >> quantitative or qualitative measure of it? > > Define "Tier 1 provider". I ask this because it's something that many > people don't know what it means, but assume that Tier 1 > Tier !=1. > >> routing stability > > Routeviews.org can shed some light here. > >> BGP community offerings > > If $provider has a page on www.peeringdb.com, they might publish a list of > their BGP communities there. Other places to look would be the provider's > whois/IRR entries, and on their respective websites, or the sales/marketing > folks might be able to get this information for you. > >> congestion issues > > There are various internet traffic report / weather report sites that can > give you indirect insight into things like. By indirect, I mean that you > might be able to infer things like congestion at a specific point based on > what you see on those sites. > >> BGP Peering relationships > > You can look at pages like www.peeringdb.com, and you will typically see if > $provider is at an exchange, however the peering relationships that many > providers have other providers (locations, speeds, etc) are confidential. > >> path diversity > > You can ask $provider's sales and marketing folks, but there is no guarantee > that you will get an answer (actual routes are considered confidential and > proprietary information, despite the fact that a lot of providers' fiber > ends up converging in a small handful of routes in some areas - i.e. many of > them follow the same set of railroad tracks or cross a river at the same > bridge, possibly even in the same conduit) or a correct answer (wave X might > be re-groomed onto path Y without a whole lot of customer notification). > >> IPv6 table size > > Sites like routeviews.org can give you some visibility here. > >> Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 >> customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. >> I'm shopping for new service and want to do better than choosing on >> reputation. (or, is reputation also a criteria?) > > Absolutely reputation should be a factor. I would argue that Internet > access is largely commoditized anymore (and has been for several years), so > the real differentiators are cost and level of service. > > jms > > > From Valdis.Kletnieks at vt.edu Tue Aug 27 21:02:30 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 Aug 2013 17:02:30 -0400 Subject: Evaluating Tier 1 Internet providers In-Reply-To: Your message of "Tue, 27 Aug 2013 13:45:34 -0700." <01a101cea366$61326f50$23974df0$@com> References: <017601cea358$00a86ad0$01f94070$@com> <10D5AD8D-7DA5-477F-8FC2-14FDDEB75B84@hopcount.ca> <01a101cea366$61326f50$23974df0$@com> Message-ID: <27361.1377637350@turing-police.cc.vt.edu> On Tue, 27 Aug 2013 13:45:34 -0700, "Eric Louie" said: > That's a good point with the Tier 2 providers. So that begs the question, > why wouldn't I just get my upstream from a Tier 2? (Because my management > is under the perception that we're better off with Tier 1 providers, but > that doesn't mean their perception is accurate) The good thing about your upstream being a Tier 2 is that it usually means that if somebody's baking a peering cake, you're not one of the AS's that's suffering. Hmmm... if you're going for a connection to a Tier 1, maybe "peering cakes per decade" is a valid criterion? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From achatz at forthnetgroup.gr Tue Aug 27 21:08:40 2013 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Wed, 28 Aug 2013 00:08:40 +0300 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <017601cea358$00a86ad0$01f94070$@com> References: <017601cea358$00a86ad0$01f94070$@com> Message-ID: <521D1558.3020304@forthnetgroup.gr> http://www.renesys.com/products/ provide some guidance, but probably not the kind of detailed tech you want. Judging from my own experience, we have mostly been hit by limited path diversity & "everything seems fine" support in the past. -- Tassos Eric Louie wrote on 27/8/2013 22:02: > Based on various conversation threads on Nanog I've come up with a few > criteria for evaluating Tier 1 providers. I'm open to add other criteria - > what would you add to this list? And how would I get a quantitative or > qualitative measure of it? > > > > routing stability > > BGP community offerings > > congestion issues > > BGP Peering relationships > > path diversity > > IPv6 table size > > > > Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 > customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. > I'm shopping for new service and want to do better than choosing on > reputation. (or, is reputation also a criteria?) > > > > much appreciated, > > Eric Louie > > > > From elouie at yahoo.com Tue Aug 27 21:11:54 2013 From: elouie at yahoo.com (Eric Louie) Date: Tue, 27 Aug 2013 14:11:54 -0700 Subject: Evaluating Tier 1 Internet providers In-Reply-To: References: <017601cea358$00a86ad0$01f94070$@com> Message-ID: <01bc01cea36a$0f55dfb0$2e019f10$@com> Tier 1 = Internet backbone providers (United States - AT&T, UUNET, Sprint, AboveNet/Zayo, Cogent, Qwest/CenturyLink, L3/GBLX). However, I might be better served with a Tier 2 for reachability as pointed out in another response. When you say "level of service", what are you referring to? Customer service? Service level agreement (which is pretty much the same across all the Tier 1's)? much appreciated, Eric Louie -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Tuesday, August 27, 2013 9:17 AM To: nanog at nanog.org Subject: Re: Evaluating Tier 1 Internet providers On Tue, 27 Aug 2013, Eric Louie wrote: > Based on various conversation threads on Nanog I've come up with a few > criteria for evaluating Tier 1 providers. I'm open to add other > criteria - what would you add to this list? And how would I get a > quantitative or qualitative measure of it? Define "Tier 1 provider". I ask this because it's something that many people don't know what it means, but assume that Tier 1 > Tier !=1. > routing stability Routeviews.org can shed some light here. > BGP community offerings If $provider has a page on www.peeringdb.com, they might publish a list of their BGP communities there. Other places to look would be the provider's whois/IRR entries, and on their respective websites, or the sales/marketing folks might be able to get this information for you. > congestion issues There are various internet traffic report / weather report sites that can give you indirect insight into things like. By indirect, I mean that you might be able to infer things like congestion at a specific point based on what you see on those sites. > BGP Peering relationships You can look at pages like www.peeringdb.com, and you will typically see if $provider is at an exchange, however the peering relationships that many providers have other providers (locations, speeds, etc) are confidential. > path diversity You can ask $provider's sales and marketing folks, but there is no guarantee that you will get an answer (actual routes are considered confidential and proprietary information, despite the fact that a lot of providers' fiber ends up converging in a small handful of routes in some areas - i.e. many of them follow the same set of railroad tracks or cross a river at the same bridge, possibly even in the same conduit) or a correct answer (wave X might be re-groomed onto path Y without a whole lot of customer notification). > IPv6 table size Sites like routeviews.org can give you some visibility here. > Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 > customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. > I'm shopping for new service and want to do better than choosing on > reputation. (or, is reputation also a criteria?) Absolutely reputation should be a factor. I would argue that Internet access is largely commoditized anymore (and has been for several years), so the real differentiators are cost and level of service. jms From elouie at yahoo.com Tue Aug 27 21:14:12 2013 From: elouie at yahoo.com (Eric Louie) Date: Tue, 27 Aug 2013 14:14:12 -0700 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <27361.1377637350@turing-police.cc.vt.edu> References: <017601cea358$00a86ad0$01f94070$@com> <10D5AD8D-7DA5-477F-8FC2-14FDDEB75B84@hopcount.ca> <01a101cea366$61326f50$23974df0$@com> <27361.1377637350@turing-police.cc.vt.edu> Message-ID: <01f301cea36a$6164a610$242df230$@com> I'm thinking that same thing, although after researching, the "de-peering King" is probably not a contender as one of our primary upstream connection. (And I don't have secondary or tertiary connections) much appreciated, Eric Louie -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Tuesday, August 27, 2013 2:03 PM To: Eric Louie Cc: nanog at nanog.org Subject: Re: Evaluating Tier 1 Internet providers On Tue, 27 Aug 2013 13:45:34 -0700, "Eric Louie" said: > That's a good point with the Tier 2 providers. So that begs the > question, why wouldn't I just get my upstream from a Tier 2? (Because > my management is under the perception that we're better off with Tier > 1 providers, but that doesn't mean their perception is accurate) The good thing about your upstream being a Tier 2 is that it usually means that if somebody's baking a peering cake, you're not one of the AS's that's suffering. Hmmm... if you're going for a connection to a Tier 1, maybe "peering cakes per decade" is a valid criterion? From ikiris at gmail.com Tue Aug 27 21:22:31 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 27 Aug 2013 16:22:31 -0500 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <01f301cea36a$6164a610$242df230$@com> References: <017601cea358$00a86ad0$01f94070$@com> <10D5AD8D-7DA5-477F-8FC2-14FDDEB75B84@hopcount.ca> <01a101cea366$61326f50$23974df0$@com> <27361.1377637350@turing-police.cc.vt.edu> <01f301cea36a$6164a610$242df230$@com> Message-ID: If you don't have secondary connectivity, then I don't suggest going with a Teir 1. Using a peer-only as a transit link is not something I would recommend in general unless you know what you are doing in that regard, and have designed around the inevitable peering issues related to that decision. -Blake On Tue, Aug 27, 2013 at 4:14 PM, Eric Louie wrote: > I'm thinking that same thing, although after researching, the "de-peering > King" is probably not a contender as one of our primary upstream > connection. > (And I don't have secondary or tertiary connections) > > much appreciated, > Eric Louie > > > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Tuesday, August 27, 2013 2:03 PM > To: Eric Louie > Cc: nanog at nanog.org > Subject: Re: Evaluating Tier 1 Internet providers > > On Tue, 27 Aug 2013 13:45:34 -0700, "Eric Louie" said: > > > That's a good point with the Tier 2 providers. So that begs the > > question, why wouldn't I just get my upstream from a Tier 2? (Because > > my management is under the perception that we're better off with Tier > > 1 providers, but that doesn't mean their perception is accurate) > > The good thing about your upstream being a Tier 2 is that it usually means > that if somebody's baking a peering cake, you're not one of the AS's that's > suffering. > > Hmmm... if you're going for a connection to a Tier 1, maybe "peering cakes > per decade" is a valid criterion? > > > > From streiner at cluebyfour.org Tue Aug 27 17:35:52 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 27 Aug 2013 13:35:52 -0400 (EDT) Subject: Evaluating Tier 1 Internet providers In-Reply-To: <01bc01cea36a$0f55dfb0$2e019f10$@com> References: <017601cea358$00a86ad0$01f94070$@com> <01bc01cea36a$0f55dfb0$2e019f10$@com> Message-ID: On Tue, 27 Aug 2013, Eric Louie wrote: > Tier 1 = Internet backbone providers (United States - AT&T, UUNET, Sprint, > AboveNet/Zayo, Cogent, Qwest/CenturyLink, L3/GBLX). However, I might be > better served with a Tier 2 for reachability as pointed out in another > response. Some of those providers are probably not in the DFZ. I know Cogent has been involved in some peering spats in the past. I don't know off-hand if Zayo/Above lives in the DFZ. > When you say "level of service", what are you referring to? Customer > service? Service level agreement (which is pretty much the same across all > the Tier 1's)? Mainly customer service. Things like how easy it is to get a clued individual on the phone when there's an issue, turnaround time for things like BGP filter update requests. Like you mentioned, most providers' SLA terms are likely to look pretty similar if you were to compare them side-by-side. I would also look at which providers are on-net in your location, or would be willing to build into your location for a reasonable cost. One thing you want to avoid is all of your providers using the same local loop provider to get into the building, or local dark fiber providers using the same right-of-way / conduit / manhole to get into your building. Many providers might subcontract the physical last-mile construction to a local dark fiber provider. Entrance diversity and last-mile diversity is something you can probably have more influence over than how provider X gets between Chicago and New York. Many providers will build into your location if they're in your city if you either pay the build costs, or are purchasing enough service that the construction costs can amortized over the term of the contract. If they amortize, make sure you keep that in mind when the contract is up for re-negotiation, so they're no longer trying to ding you for construction costs that you've already paid :) jms From elouie at yahoo.com Tue Aug 27 21:31:22 2013 From: elouie at yahoo.com (Eric Louie) Date: Tue, 27 Aug 2013 14:31:22 -0700 Subject: Evaluating Tier 1 Internet providers In-Reply-To: References: <017601cea358$00a86ad0$01f94070$@com> <10D5AD8D-7DA5-477F-8FC2-14FDDEB75B84@hopcount.ca> <01a101cea366$61326f50$23974df0$@com> <27361.1377637350@turing-police.cc.vt.edu> <01f301cea36a$6164a610$242df230$@com> Message-ID: <01f601cea36c$c71dd6a0$555983e0$@com> I appreciate that warning. The bigger truth is, "No secondary/tertiary on that router/in that location." I do have iBGP with alternate providers through my core. much appreciated, Eric Louie -----Original Message----- From: Blake Dunlap [mailto:ikiris at gmail.com] Sent: Tuesday, August 27, 2013 2:23 PM To: nanog at nanog.org Subject: Re: Evaluating Tier 1 Internet providers If you don't have secondary connectivity, then I don't suggest going with a Teir 1. Using a peer-only as a transit link is not something I would recommend in general unless you know what you are doing in that regard, and have designed around the inevitable peering issues related to that decision. -Blake On Tue, Aug 27, 2013 at 4:14 PM, Eric Louie wrote: > I'm thinking that same thing, although after researching, the > "de-peering King" is probably not a contender as one of our primary > upstream connection. > (And I don't have secondary or tertiary connections) > > much appreciated, > Eric Louie > > > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Tuesday, August 27, 2013 2:03 PM > To: Eric Louie > Cc: nanog at nanog.org > Subject: Re: Evaluating Tier 1 Internet providers > > On Tue, 27 Aug 2013 13:45:34 -0700, "Eric Louie" said: > > > That's a good point with the Tier 2 providers. So that begs the > > question, why wouldn't I just get my upstream from a Tier 2? > > (Because my management is under the perception that we're better off > > with Tier > > 1 providers, but that doesn't mean their perception is accurate) > > The good thing about your upstream being a Tier 2 is that it usually > means that if somebody's baking a peering cake, you're not one of the > AS's that's suffering. > > Hmmm... if you're going for a connection to a Tier 1, maybe "peering > cakes per decade" is a valid criterion? > > > > From bryan at serverstack.com Tue Aug 27 21:45:08 2013 From: bryan at serverstack.com (Bryan Socha) Date: Tue, 27 Aug 2013 17:45:08 -0400 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <017601cea358$00a86ad0$01f94070$@com> References: <017601cea358$00a86ad0$01f94070$@com> Message-ID: To add some more from recent experiences.. Most of these are in colocation datacenters. - speed to handle your emergency support call. (recent experience, some tier1 can take a couple hours) - if support requires a portal opened ticket, is the staff to reset a password also 24/7. - Latency in your region. (recent experience: I removed 4 circuits because the backbones weren't the same in different areas). - Is you location a pop, metro ring or dedicated fiber elsewhere. - To get more specific, where is their peering in relationship to you. Strong peering not near you could mean a lot of extra latency just to get off their network. thanks, Bryan Socha From elouie at yahoo.com Tue Aug 27 21:50:50 2013 From: elouie at yahoo.com (Eric Louie) Date: Tue, 27 Aug 2013 14:50:50 -0700 Subject: Evaluating Tier 1 Internet providers In-Reply-To: References: <017601cea358$00a86ad0$01f94070$@com> <01bc01cea36a$0f55dfb0$2e019f10$@com> Message-ID: <01f901cea36f$7f7b2fc0$7e718f40$@com> > -----Original Message----- > From: Justin M. Streiner [mailto:streiner at cluebyfour.org] > Sent: Tuesday, August 27, 2013 10:36 AM > To: nanog at nanog.org > Subject: RE: Evaluating Tier 1 Internet providers > > On Tue, 27 Aug 2013, Eric Louie wrote: > > I would also look at which providers are on-net in your location, or > would be willing to build into your location for a reasonable cost. > One thing you want to avoid is all of your providers using the same > local loop provider to get into the building, or local dark fiber > providers using the same right-of-way / conduit / manhole to get into > your building. > Many providers might subcontract the physical last-mile construction to > a local dark fiber provider. Entrance diversity and last-mile > diversity is something you can probably have more influence over than > how provider X gets between Chicago and New York. > The only thing I'm looking at are on-net solutions - luckily or unluckily we are at data center locations (carrier neutral) so my choices are limited to the on-nets that they already have (I'm not going through the pain of bringing in a new one) and most of them are offering "free install" > Many providers will build into your location if they're in your city if > you either pay the build costs, or are purchasing enough service that > the construction costs can amortized over the term of the contract. If > they amortize, make sure you keep that in mind when the contract is up > for re-negotiation, so they're no longer trying to ding you for > construction costs that you've already paid :) > > jms From elouie at yahoo.com Tue Aug 27 21:57:47 2013 From: elouie at yahoo.com (Eric Louie) Date: Tue, 27 Aug 2013 14:57:47 -0700 Subject: Evaluating Tier 1 Internet providers In-Reply-To: References: <017601cea358$00a86ad0$01f94070$@com> Message-ID: <01ff01cea370$781a7eb0$684f7c10$@com> From: Bryan Socha [mailto:bryan at serverstack.com] Sent: Tuesday, August 27, 2013 2:45 PM To: Eric Louie; nanog at nanog.org Subject: Re: Evaluating Tier 1 Internet providers To add some more from recent experiences.. Most of these are in colocation datacenters. [EL>] I'm colocated too. - speed to handle your emergency support call. (recent experience, some tier1 can take a couple hours) [EL>] time to respond / time to resolve are good ones (hard to get them to provide the true values, though) - if support requires a portal opened ticket, is the staff to reset a password also 24/7. - Latency in your region. (recent experience: I removed 4 circuits because the backbones weren't the same in different areas). - Is you location a pop, metro ring or dedicated fiber elsewhere. - To get more specific, where is their peering in relationship to you. Strong peering not near you could mean a lot of extra latency just to get off their network. [EL>] "How many hops to their edge"? Will they admit that? can I get a traceroute? (however, this is in downtown LA so I'm guessing it's close to the edge thanks, Bryan Socha From bblackford at gmail.com Tue Aug 27 22:20:11 2013 From: bblackford at gmail.com (Bill Blackford) Date: Tue, 27 Aug 2013 15:20:11 -0700 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <017601cea358$00a86ad0$01f94070$@com> References: <017601cea358$00a86ad0$01f94070$@com> Message-ID: If this was previously mentioned, my apologies. The time they can respond to a PNI upgrade. If you have an existing 10G and wish to add another. Can this be provisioned off the same device to form a LAG or can they only provide ECMP. May not be something you can evaluate at contract signing, but it can quickly become an issue when you need it. On Tue, Aug 27, 2013 at 12:02 PM, Eric Louie wrote: > Based on various conversation threads on Nanog I've come up with a few > criteria for evaluating Tier 1 providers. I'm open to add other criteria - > what would you add to this list? And how would I get a quantitative or > qualitative measure of it? > > > > routing stability > > BGP community offerings > > congestion issues > > BGP Peering relationships > > path diversity > > IPv6 table size > > > > Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 > customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. > I'm shopping for new service and want to do better than choosing on > reputation. (or, is reputation also a criteria?) > > > > much appreciated, > > Eric Louie > > > > -- Bill Blackford Logged into reality and abusing my sudo privileges..... From bryan at serverstack.com Tue Aug 27 22:47:59 2013 From: bryan at serverstack.com (Bryan Socha) Date: Tue, 27 Aug 2013 18:47:59 -0400 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <01ff01cea370$781a7eb0$684f7c10$@com> References: <017601cea358$00a86ad0$01f94070$@com> <01ff01cea370$781a7eb0$684f7c10$@com> Message-ID: > - speed to handle your emergency support call. (recent experience, > some tier1 can take a couple hours) > *[EL>] * time to respond / time to resolve are good ones (hard to get > them to provide the true values, though)**** > > > Call and pretend your a customer with an emergency. You might be surprised how long it takes the first person to be on the call with you. > - To get more specific, where is their peering in relationship to you. > Strong peering not near you could mean a lot of extra latency just to get > off their network.**** > > *[EL>] *?How many hops to their edge?? Will they admit that? can I get > a traceroute? (however, this is in downtown LA so I?m guessing it?s close > to the edge**** > > * * > This one can be harder to get any answers on depending on who you are. You can ask what locations they have most of their peering with. Also ask for a POP list they are located in. Usually they are marked with the type of service each building is (pop vs metro ring vs extension). unless it's a private peer, I woudlnt' expect any peering at locations that are not pops and you can see what is nearby your location that is a pop. Somethign else I just thought of that I do ask providers. Ask how they get into your building. If they are using some sort of metro ring between their routers make sure your not about to screw yourself with no diversity when that ring needs to be worked on. Thanks, Bryan From bill at herrin.us Tue Aug 27 23:22:32 2013 From: bill at herrin.us (William Herrin) Date: Tue, 27 Aug 2013 19:22:32 -0400 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <017601cea358$00a86ad0$01f94070$@com> References: <017601cea358$00a86ad0$01f94070$@com> Message-ID: On Tue, Aug 27, 2013 at 3:02 PM, Eric Louie wrote: > Based on various conversation threads on Nanog I've come up with a few > criteria for evaluating Tier 1 providers. I'm open to add other criteria - > what would you add to this list? Billing issues such as: attitude during a billing dispute traceability and accountability (Which service is this 35 cent blah fee attached to?) zombie service rate (Bills showing up for long-ago cancelled products) flexibility (I want you to send me two bills, each for half of that. You can't? Why not?) nickle and dime (There's a $100 monthly rental fee for that 50 foot cat-5 cable!? Really!?) Also, abuse desk knee-jerkiness. If someone reports a problem originating from my system, how much leeway do I have to fix it before you decide to fix it for me? If some knucklehead with a port-scanning worm earns me a no-notice cut off, you and I will have words. At the same time, I don't want to fund someone who would turn a blind eye. > Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 > customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. > I'm shopping for new service and want to do better than choosing on > reputation. (or, is reputation also a criteria?) Reputations are well earned and are certainly a factor. They're heavily qualitative, though. I don't know that's it's practical or useful to measure them. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mksmith at mac.com Wed Aug 28 01:48:20 2013 From: mksmith at mac.com (Michael Smith) Date: Tue, 27 Aug 2013 18:48:20 -0700 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <017601cea358$00a86ad0$01f94070$@com> References: <017601cea358$00a86ad0$01f94070$@com> Message-ID: <091253D8-0E83-49EC-9EA8-B9556A6CDE24@mac.com> You should also consider who exactly your customers (or you alone) want to reach. Are you mostly looking to connect to eyeball networks? Enterprise networks? Government networks? If you have some target networks you should do some due diligence to find out how well connected your various options are to the networks that mean the most to you. If possible, I would also recommend talking to other people that are in your data centers, if that's possible. You might find out about hidden vendor-specific gremlins in that location. Regards, Mike On Aug 27, 2013, at 12:02 PM, Eric Louie wrote: > Based on various conversation threads on Nanog I've come up with a few > criteria for evaluating Tier 1 providers. I'm open to add other criteria - > what would you add to this list? And how would I get a quantitative or > qualitative measure of it? > > > > routing stability > > BGP community offerings > > congestion issues > > BGP Peering relationships > > path diversity > > IPv6 table size > > > > Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 > customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. > I'm shopping for new service and want to do better than choosing on > reputation. (or, is reputation also a criteria?) > > > > much appreciated, > > Eric Louie > > > From bill at herrin.us Wed Aug 28 02:33:52 2013 From: bill at herrin.us (William Herrin) Date: Tue, 27 Aug 2013 22:33:52 -0400 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <017601cea358$00a86ad0$01f94070$@com> References: <017601cea358$00a86ad0$01f94070$@com> Message-ID: On Tue, Aug 27, 2013 at 3:02 PM, Eric Louie wrote: > Based on various conversation threads on Nanog I've come up with a few > criteria for evaluating Tier 1 providers. I'm open to add other criteria - > what would you add to this list? > > BGP Peering relationships Peering policy. A tier 1 with an open peering policy would get all my money. Even a semi-open policy (bring your network to any of these neutral locations at your cost and we'll peer settlement-free for our regional routes) would be worth encouraging through the purchase of transit services. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bhatton at htva.net Tue Aug 27 21:04:29 2013 From: bhatton at htva.net (Ben Hatton) Date: Tue, 27 Aug 2013 17:04:29 -0400 Subject: Evaluating Tier 1 Internet providers In-Reply-To: References: <017601cea358$00a86ad0$01f94070$@com> <019e01cea365$c91760e0$5b4622a0$@com> Message-ID: > - time taken to turn around BGP import filter changes So much This... You don't realize how important this is until your nationwide provider takes 8 WEEKS to add one network to your (already set up and working for 20 other networks) peering. Then decides to charge you a fee for the change. Ben Hatton Network Systems Engineer On Tue, Aug 27, 2013 at 1:05 PM, Justin M. Streiner wrote: > On Tue, 27 Aug 2013, Eric Louie wrote: > > Good stuff Justin - Any other criteria that you would use? >> > > Joe covered a lot of good stuff in his response. > > A few providers call themselves Tier 1, though the accuracy of those > assertions is often suspect. The truth can be somewhat more complicated... > and exactly how much more complicated isn't always clear > until Provider X gets de-peered by Provider Y and finds themselves having > to negotiate a quick fix, often by cutting a check. > > I would also ask people here who they have had very good experiences with, > regardless of what "tier" the provider fits into. > > jms > > > -----Original Message----- >> From: Justin M. Streiner [mailto:streiner at cluebyfour.**org >> ] >> Sent: Tuesday, August 27, 2013 9:17 AM >> To: nanog at nanog.org >> Subject: Re: Evaluating Tier 1 Internet providers >> >> On Tue, 27 Aug 2013, Eric Louie wrote: >> >> Based on various conversation threads on Nanog I've come up with a few >>> criteria for evaluating Tier 1 providers. I'm open to add other >>> criteria - what would you add to this list? And how would I get a >>> quantitative or qualitative measure of it? >>> >> >> Define "Tier 1 provider". I ask this because it's something that many >> people don't know what it means, but assume that Tier 1 > Tier !=1. >> >> routing stability >>> >> >> Routeviews.org can shed some light here. >> >> BGP community offerings >>> >> >> If $provider has a page on www.peeringdb.com, they might publish a list >> of >> their BGP communities there. Other places to look would be the provider's >> whois/IRR entries, and on their respective websites, or the >> sales/marketing >> folks might be able to get this information for you. >> >> congestion issues >>> >> >> There are various internet traffic report / weather report sites that can >> give you indirect insight into things like. By indirect, I mean that you >> might be able to infer things like congestion at a specific point based on >> what you see on those sites. >> >> BGP Peering relationships >>> >> >> You can look at pages like www.peeringdb.com, and you will typically see >> if >> $provider is at an exchange, however the peering relationships that many >> providers have other providers (locations, speeds, etc) are confidential. >> >> path diversity >>> >> >> You can ask $provider's sales and marketing folks, but there is no >> guarantee >> that you will get an answer (actual routes are considered confidential and >> proprietary information, despite the fact that a lot of providers' fiber >> ends up converging in a small handful of routes in some areas - i.e. many >> of >> them follow the same set of railroad tracks or cross a river at the same >> bridge, possibly even in the same conduit) or a correct answer (wave X >> might >> be re-groomed onto path Y without a whole lot of customer notification). >> >> IPv6 table size >>> >> >> Sites like routeviews.org can give you some visibility here. >> >> Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 >>> customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. >>> I'm shopping for new service and want to do better than choosing on >>> reputation. (or, is reputation also a criteria?) >>> >> >> Absolutely reputation should be a factor. I would argue that Internet >> access is largely commoditized anymore (and has been for several years), >> so >> the real differentiators are cost and level of service. >> >> jms >> >> >> >> > From streiner at cluebyfour.org Tue Aug 27 23:16:23 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 27 Aug 2013 19:16:23 -0400 (EDT) Subject: Evaluating Tier 1 Internet providers In-Reply-To: References: <017601cea358$00a86ad0$01f94070$@com> <019e01cea365$c91760e0$5b4622a0$@com> Message-ID: On Tue, 27 Aug 2013, Ben Hatton wrote: >> - time taken to turn around BGP import filter changes > > So much This... You don't realize how important this is until your > nationwide provider takes 8 WEEKS to add one network to your (already set > up and working for 20 other networks) peering. Then decides to charge you > a fee for the change. I think after a week I would be tearing my account rep a new one, and then threatening to dump them as soon as the contract was up... 8 weeks? There is absolutely no excuse I would buy for that, though I might give style points if someone told me the dog ate the ticket or something... jms From joly at punkcast.com Wed Aug 28 03:10:03 2013 From: joly at punkcast.com (Joly MacFie) Date: Tue, 27 Aug 2013 23:10:03 -0400 Subject: Fwd: [newtech-1] Barclays wifi In-Reply-To: <910090754.1377640737467.JavaMail.nobody@james1.pvt.meetup.com> References: <910090754.1377640737467.JavaMail.nobody@james1.pvt.meetup.com> Message-ID: >From the NY tech meetup list. Any one here care to comment, off or on list? j ---------- Forwarded message ---------- From: Dean Collins Anyone know more about Barclay Wifi - http://www.fastcompany.com/3007452/innovation-agents/brooklyn-nets-barclays-center-slam-cam-puts-every-dunk-your-face **** ** ** Can they really stream hidef video to 19,000 devices simultaneously in hd via wifi? Surely they are hitting some spatial limits?..? (eg I know when my old company sold a DECT platform to the ASX we ran into bandwidth limits for the number of base stations in a single room)**** ** ** ** ** ** ** Cheers,**** Dean**** ** ** -- --------------------------------------------------------------- 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 wbailey at satelliteintelligencegroup.com Wed Aug 28 05:54:59 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 28 Aug 2013 05:54:59 +0000 Subject: [newtech-1] Barclays wifi In-Reply-To: References: <910090754.1377640737467.JavaMail.nobody@james1.pvt.meetup.com>, Message-ID: Any idea of the data rate required per stream? Sent from my Mobile Device. -------- Original message -------- From: Joly MacFie Date: 08/27/2013 8:14 PM (GMT-08:00) To: North American Network Operators Group Subject: Fwd: [newtech-1] Barclays wifi >From the NY tech meetup list. Any one here care to comment, off or on list? j ---------- Forwarded message ---------- From: Dean Collins Anyone know more about Barclay Wifi - http://www.fastcompany.com/3007452/innovation-agents/brooklyn-nets-barclays-center-slam-cam-puts-every-dunk-your-face **** ** ** Can they really stream hidef video to 19,000 devices simultaneously in hd via wifi? Surely they are hitting some spatial limits?..? (eg I know when my old company sold a DECT platform to the ASX we ran into bandwidth limits for the number of base stations in a single room)**** ** ** ** ** ** ** Cheers,**** Dean**** ** ** -- --------------------------------------------------------------- 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 tore at fud.no Wed Aug 28 06:05:14 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 28 Aug 2013 08:05:14 +0200 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <02E84CD3-B3E6-4990-8748-8339EA7C27B0@delong.com> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <70257.1377579726@turing-police.cc.vt.edu> <5DEF4DE9-3680-4D47-9FF0-1FC3CED0A816@delong.com> <105365.1377614001@turing-police.cc.vt.edu> <02E84CD3-B3E6-4990-8748-8339EA7C27B0@delong.com> Message-ID: <521D931A.6010606@fud.no> * Owen DeLong > On Aug 27, 2013, at 07:33 , Valdis.Kletnieks at vt.edu wrote: > >> Saku Ytti and Emile Aben have numbers that say otherwise. And there must >> be a significantly bigger percentage of failures than "pretty close to 0", >> or Path MTU Discovery wouldn't have a reputation of being next to useless. > > No, their numbers describe what happens to single packets of differing sizes. > > Nothing they did describes results of actually fragmented packets. Yes, it did. Hint: 1473 + 8 + 20 Tore From joly at punkcast.com Wed Aug 28 06:24:33 2013 From: joly at punkcast.com (Joly MacFie) Date: Wed, 28 Aug 2013 02:24:33 -0400 Subject: [newtech-1] Barclays wifi In-Reply-To: References: <910090754.1377640737467.JavaMail.nobody@james1.pvt.meetup.com> Message-ID: One can only speculate on bandwidth, but a further source reveals that they are using "multicast wi-fi" http://www.theverge.com/2013/2/20/4006836/barclays-center-app-replays-smartphone It's all powered by Cisco's new StadiumVision Mobile, which reps compared > to how cable is delivered to your TV: instead of everyone having to crowd > onto a single connection, the "multicast" connection splits the feed and > delivers the same thing individually to everyone. That means my stream is > the same whether I'm alone in the stadium or surrounded by 19,000 other > Nets fans. In practice, it works remarkably well ? I didn't get a chance to > test it with 19,000 people, but even in a quickly-filling arena my stream > never slowed or broke. I switched between a game feed and a stationary > camera above the rim, and jumping back into a replay worked seamlessly. The stream is delayed about two seconds from the game itself, which for > replays is actually perfect ? by the time you look down the play's > happening again. It does make it impossible to listen to the TV feed's > announcers, though, since they're always slightly behind the game as it > unfolds. On Wed, Aug 28, 2013 at 1:54 AM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Any idea of the data rate required per stream? > > > Sent from my Mobile Device. > > > > -------- Original message -------- > From: Joly MacFie > Date: 08/27/2013 8:14 PM (GMT-08:00) > To: North American Network Operators Group > Subject: Fwd: [newtech-1] Barclays wifi > > > From the NY tech meetup list. Any one here care to comment, off or on > list? > > j > > ---------- Forwarded message ---------- > From: Dean Collins > > Anyone know more about Barclay Wifi - > > http://www.fastcompany.com/3007452/innovation-agents/brooklyn-nets-barclays-center-slam-cam-puts-every-dunk-your-face > **** > > ** ** > > > Can they really stream hidef video to 19,000 devices simultaneously in hd > via wifi? > > Surely they are hitting some spatial limits?..? (eg I know when my old > company sold a DECT platform to the ASX we ran into bandwidth limits for > the number of base stations in a single room)**** > > ** ** > > ** ** > > ** ** > > Cheers,**** > > Dean**** > > ** ** > > > > > > > > -- > --------------------------------------------------------------- > 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 > -------------------------------------------------------------- > - > -- --------------------------------------------------------------- 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 richard.hesse at weebly.com Wed Aug 28 07:14:05 2013 From: richard.hesse at weebly.com (Richard Hesse) Date: Wed, 28 Aug 2013 00:14:05 -0700 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <10D5AD8D-7DA5-477F-8FC2-14FDDEB75B84@hopcount.ca> References: <017601cea358$00a86ad0$01f94070$@com> <10D5AD8D-7DA5-477F-8FC2-14FDDEB75B84@hopcount.ca> Message-ID: On Tue, Aug 27, 2013 at 12:14 PM, Joe Abley wrote: > > I would add: > > - response you can expect when you call one day and say "our 10GE is > maxed out with inbound traffic from apparently everywhere, it has been > going on for an hour, please help" > That was good for a laugh. If it's a DoS, you know what the answer already is. "We no longer offer filtering for any of our customers. You must upgrade to the DDoS prevention service." We've actually made a list of other companies that share our providers' downstream links in each facility and reached out to them. We get them to call up and complain to said tier1 provider that "something is affecting our traffic." That usually gets filters installed....otherwise no dice. If it's a legit capacity issue, you'll get a response whenever your sales guy comes back into the office. -richard From tore at fud.no Wed Aug 28 07:37:14 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 28 Aug 2013 09:37:14 +0200 Subject: Evaluating Tier 1 Internet providers In-Reply-To: References: <017601cea358$00a86ad0$01f94070$@com> <10D5AD8D-7DA5-477F-8FC2-14FDDEB75B84@hopcount.ca> Message-ID: <521DA8AA.3030202@fud.no> * Richard Hesse > On Tue, Aug 27, 2013 at 12:14 PM, Joe Abley wrote: > >> - response you can expect when you call one day and say "our 10GE is >> maxed out with inbound traffic from apparently everywhere, it has been >> going on for an hour, please help" >> > > That was good for a laugh. > > If it's a DoS, you know what the answer already is. "We no longer offer > filtering for any of our customers. You must upgrade to the DDoS prevention > service." We've actually made a list of other companies that share our > providers' downstream links in each facility and reached out to them. We > get them to call up and complain to said tier1 provider that "something is > affecting our traffic." That usually gets filters installed....otherwise no > dice. Several providers have a self-service blackholing functionality which may alleviate DDoS attacks. Typically you announce the attacked /32 or a /128 to your upstreams, tagged with some special blackhole community, and/or to a special multihop BGP session dedicated for blackholing purposes. Doing so will cause your upstreams to automatically drop the attack traffic within their network, *before* it gets to saturate your uplinks. Clearly, this is a blunt and last-resort type of tool which will cement the efficiency of the attack from a global perspective, but that may be an acceptable trade-off depending on the circumstances; you may prevent collateral damage from impacting your other customers, and by cutting out global attack traffic might enable the attacked customer to serve his primary markets just fine through local peering sessions, regional transits, and so forth. I'm not buying transit from a network that don't give me such blackholing functionality, FWIW. Tore From elouie at yahoo.com Wed Aug 28 08:18:03 2013 From: elouie at yahoo.com (Eric A Louie) Date: Wed, 28 Aug 2013 01:18:03 -0700 (PDT) Subject: Evaluating Tier 1 Internet providers In-Reply-To: <091253D8-0E83-49EC-9EA8-B9556A6CDE24@mac.com> References: <017601cea358$00a86ad0$01f94070$@com> <091253D8-0E83-49EC-9EA8-B9556A6CDE24@mac.com> Message-ID: <1377677883.64231.YahooMailNeo@web181605.mail.ne1.yahoo.com> how is that really much different than "reachability"?? If I look at my present Netflow results, it's actually a pretty amusing mix - lots of Netflix traffic (bear in mind we're a business ISP, not residential), Google (probably YouTube in there, I haven't dissected it thoroughly), Amazon, Yahoo, Microsoft/MSN, and that's all covered in the peering fabric connection.? Outside of that, some private VPN-type traffic, I don't see a lot of government networks, just "normal" Internet browsing and email. Since I'm not at the Data Center much, I don't interact with the other customers there.? (It's 150 miles away)? Due to non-disclosure, the Data Center gang aren't much going to share their customer contact info with me.? But it's a nice thought, for sure. -e- >________________________________ > From: Michael Smith >To: Eric Louie >Cc: nanog at nanog.org >Sent: Tuesday, August 27, 2013 6:48 PM >Subject: Re: Evaluating Tier 1 Internet providers > > >You should also consider who exactly your customers (or you alone) want to reach.? Are you mostly looking to connect to eyeball networks?? Enterprise networks?? Government networks?? If you have some target networks you should do some due diligence to find out how well connected your various options are to the networks that mean the most to you. > >If possible, I would also recommend talking to other people that are in your data centers, if that's possible.? You might find out about hidden vendor-specific gremlins in that location. > >Regards, > >Mike > > >On Aug 27, 2013, at 12:02 PM, Eric Louie wrote: > >> Based on various conversation threads on Nanog I've come up with a few >> criteria for evaluating Tier 1 providers.? I'm open to add other criteria - >> what would you add to this list?? And how would I get a quantitative or >> qualitative measure of it? >> >> >> >> routing stability >> >> BGP community offerings >> >> congestion issues >> >> BGP Peering relationships >> >> path diversity >> >> IPv6 table size >> >> >> >> Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 >> customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. >> I'm shopping for new service and want to do better than choosing on >> reputation.? (or, is reputation also a criteria?) >> >> >> >> much appreciated, >> >> Eric Louie >> >> >> > > > > From emile.aben at ripe.net Wed Aug 28 09:26:10 2013 From: emile.aben at ripe.net (Emile Aben) Date: Wed, 28 Aug 2013 11:26:10 +0200 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <521D931A.6010606@fud.no> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <70257.1377579726@turing-police.cc.vt.edu> <5DEF4DE9-3680-4D47-9FF0-1FC3CED0A816@delong.com> <105365.1377614001@turing-police.cc.vt.edu> <02E84CD3-B3E6-4990-8748-8339EA7C27B0@delong.com> <521D931A.6010606@fud.no> Message-ID: <521DC232.20209@ripe.net> On 28/08/2013 08:05, Tore Anderson wrote: > * Owen DeLong > >> On Aug 27, 2013, at 07:33 , Valdis.Kletnieks at vt.edu wrote: >> >>> Saku Ytti and Emile Aben have numbers that say otherwise. And there must >>> be a significantly bigger percentage of failures than "pretty close to 0", >>> or Path MTU Discovery wouldn't have a reputation of being next to useless. >> >> No, their numbers describe what happens to single packets of differing sizes. >> >> Nothing they did describes results of actually fragmented packets. > > Yes, it did. > > Hint: 1473 + 8 + 20 For Saku: yes. For me: that was my intention, but later I discovered the Atlas ping does include the ICMP header in it's 'size' parameter so what I did in effect was 1473 + 20 = 1493 (and not the 1501 I intended). Redid the tests to a "known good" destination where I knew interface MTU (1500) and could tcpdump which confirmed that I was looking at fragmentation. I also took an offline recommendation to do different packet sizes to try to distinguish fragmentation issues from general corruption-based packet loss. Results: size = ICMP packet size, add 20 for IPv4 packet size fail% = % of vantage points where 5 packets where sent, 0 where received. #size fail% vantage points 100 0.88 2963 300 0.77 3614 500 0.88 1133 700 1.07 3258 900 1.13 3614 1000 1.04 770 1100 2.04 3525 1200 1.91 3303 1300 1.76 681 1400 2.06 3014 1450 2.53 3597 1470 3.01 2192 1470 3.12 3592 1473 4.96 3566 1475 4.96 3387 1480 6.04 679 1480 4.93 3492 [*] 1481 9.86 3489 1482 9.81 3567 1483 9.94 3118 There is a ~5% difference going up from 1480 to 1481. As to interpreting this: Leo Bicknell's observations (this is to a "known good" host, and the RIPE Atlas vantage points may very well have a clueful-operator bias) stand, so interpret with care. Also: roughly 2/3 of these vantage points are behind NATs that may also have some firewall(ish) behaviour. Hope this data point helps interpreting the magnitude of IPv4 fragmentation problems. Emile Aben RIPE NCC [*] redid the 'size 1480' experiment because the first time around it had significantly less vantage points. From drew.linsalata at gmail.com Wed Aug 28 12:23:05 2013 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Wed, 28 Aug 2013 08:23:05 -0400 Subject: Hello, Atlantic.net? Message-ID: Sorry to use the list for this, but if anyone from Atlantic.net is listening that has any idea of what the status of your cloud situation is, it would be most appreciated. Usual support channels are resulting in dead air. Thanks. From jared at puck.nether.net Wed Aug 28 12:54:42 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 28 Aug 2013 08:54:42 -0400 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <01bc01cea36a$0f55dfb0$2e019f10$@com> References: <017601cea358$00a86ad0$01f94070$@com> <01bc01cea36a$0f55dfb0$2e019f10$@com> Message-ID: On Aug 27, 2013, at 5:11 PM, "Eric Louie" wrote: > Tier 1 = Internet backbone providers (United States - AT&T, UUNET, Sprint, > AboveNet/Zayo, Cogent, Qwest/CenturyLink, L3/GBLX). However, I might be > better served with a Tier 2 for reachability as pointed out in another You may want to revise your list, and look at the 3rd parties that measure and rank this data. http://as-rank.caida.org/ http://www.renesys.com/2013/01/a-bakers-dozen-2012-edition/ You are missing a few networks that are important. Much of what someone considers a "major network" IMHO depends on how you scope them. Maybe you don't care about things not on your continent. Maybe you don't mind having a different ASN in Asia/Europe. Maybe you don't need to connect in Australia with the same routing policy. The real answer is "it depends", and your criteria may not be the same as someone else. - Jared From ben+nanog at list-subs.com Wed Aug 28 13:57:56 2013 From: ben+nanog at list-subs.com (Ben) Date: Wed, 28 Aug 2013 14:57:56 +0100 Subject: Fwd: [newtech-1] Barclays wifi In-Reply-To: References: <910090754.1377640737467.JavaMail.nobody@james1.pvt.meetup.com> Message-ID: <521E01E4.7000101@list-subs.com> On 28/08/2013 04:10, Joly MacFie wrote: > From the NY tech meetup list. Any one here care to comment, off or on list? > > j > > ---------- Forwarded message ---------- > From: Dean Collins > > Anyone know more about Barclay Wifi - > http://www.fastcompany.com/3007452/innovation-agents/brooklyn-nets-barclays-center-slam-cam-puts-every-dunk-your-face > **** > > ** ** > > Can they really stream hidef video to 19,000 devices simultaneously in hd > via wifi? > > Surely they are hitting some spatial limits?..? (eg I know when my old > company sold a DECT platform to the ASX we ran into bandwidth limits for > the number of base stations in a single room)**** > Also hinted at here http://arstechnica.com/information-technology/2013/02/super-bowl-plans-to-handle-30000-wi-fi-users-at-once-and-sniff-out-rogue-devices/ (and also at Arstechnica where I think the guy said he had a multi-million dollar budget to get it working ) Basically, looks like a lot of expensive kit from the green giant PLUS a great deal of attention during installation PLUS lots and lots of sysadmin time to make it work ! I also seem to recall some interesting eeewwToob demos from xirrus who also specialise in high density kit. From tdurack at gmail.com Wed Aug 28 14:20:03 2013 From: tdurack at gmail.com (Tim Durack) Date: Wed, 28 Aug 2013 10:20:03 -0400 Subject: Cogent multi-hop BGP Message-ID: I was under the impression Cogent no longer did the multi-hop BGP thing, but then I got a copy of their NA user guide, and saw the peer-a/peer-b configuration. Not a fan. Anyone know if this is still required for Cogent IP transit service? (on/off list is fine.) -- Tim:> From dmburgess at linktechs.net Wed Aug 28 14:24:47 2013 From: dmburgess at linktechs.net (Dennis Burgess) Date: Wed, 28 Aug 2013 09:24:47 -0500 Subject: Cogent multi-hop BGP References: Message-ID: <50710E9A7E64454C974049FC998EB6550136021B@03-exchange.lti.local> depends on the site. in st. louis, we connect to their only router, direct peering, no a/b/ stuff, if you are in a colo that they have several access routers as well, then you will typically do the a/b. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition"???????????????????????????????? ?Link Technologies, Inc -- Mikrotik & WISP Support Services??????????????????????????????????????????????????????????????????????????????????? ?Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs???????????????????????????????????????????????????? ?-- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace? -----Original Message----- From: Tim Durack [mailto:tdurack at gmail.com] Sent: Wednesday, August 28, 2013 9:20 AM To: nanog at nanog.org Subject: Cogent multi-hop BGP I was under the impression Cogent no longer did the multi-hop BGP thing, but then I got a copy of their NA user guide, and saw the peer-a/peer-b configuration. Not a fan. Anyone know if this is still required for Cogent IP transit service? (on/off list is fine.) -- Tim:> From jlewis at lewis.org Wed Aug 28 14:25:16 2013 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 28 Aug 2013 10:25:16 -0400 (EDT) Subject: Cogent multi-hop BGP In-Reply-To: References: Message-ID: On Wed, 28 Aug 2013, Tim Durack wrote: > I was under the impression Cogent no longer did the multi-hop BGP thing, > but then I got a copy of their NA user guide, and saw the peer-a/peer-b > configuration. Not a fan. > > Anyone know if this is still required for Cogent IP transit service? > (on/off list is fine.) If you mean required in order to load share over multiple circuits, no. They support LAG in most places now and LAG is their preferred method for load sharing over multiple links. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ml at kenweb.org Wed Aug 28 14:54:05 2013 From: ml at kenweb.org (ML) Date: Wed, 28 Aug 2013 10:54:05 -0400 Subject: Evaluating Tier 1 Internet providers In-Reply-To: References: <017601cea358$00a86ad0$01f94070$@com> <019e01cea365$c91760e0$5b4622a0$@com> Message-ID: <521E0F0D.6020902@kenweb.org> On 8/27/2013 5:04 PM, Ben Hatton wrote: >> - time taken to turn around BGP import filter changes > So much This... You don't realize how important this is until your > nationwide provider takes 8 WEEKS to add one network to your (already set > up and working for 20 other networks) peering. Then decides to charge you > a fee for the change. > > Ben Hatton > Network Systems Engineer Internet Rule 492b - Name and shame that provider. From ryan at deadfrog.net Wed Aug 28 15:23:01 2013 From: ryan at deadfrog.net (Ryan Wilkins) Date: Wed, 28 Aug 2013 11:23:01 -0400 Subject: Cogent multi-hop BGP In-Reply-To: References: Message-ID: <92EFD553-1714-4A41-9842-5CF5E42BD0C1@deadfrog.net> On Aug 28, 2013, at 10:20 AM, Tim Durack wrote: > I was under the impression Cogent no longer did the multi-hop BGP thing, > but then I got a copy of their NA user guide, and saw the peer-a/peer-b > configuration. Not a fan. > > Anyone know if this is still required for Cogent IP transit service? > (on/off list is fine.) > > -- > Tim:> For what it's worth, we started with Cogent doing the A/B peer thing when we were running IPv4 only with them. Once we added IPv6 BGP they migrated us to a direct peering. Much simpler and preferred. This is in Chicago at 710 Lakeshore. Ryan Wilkins From jamesl at mythostech.com Wed Aug 28 15:25:01 2013 From: jamesl at mythostech.com (James Laszko) Date: Wed, 28 Aug 2013 15:25:01 +0000 Subject: Verizon So Cal issues? Message-ID: <8078ED370ADA824281219A7B5BADC39B3CA60E09@MBX023-W1-CA-6.exch023.domain.local> We are seeing huge latency and packet loss issues with Verizon (DSL/FIOS) in Southern California. Does anyone have any insight? Issues started around 8:10AM Pacific. Regards, James Laszko Mythos Technology Inc jamesl at mythostech.com From dhubbard at dino.hostasaurus.com Wed Aug 28 16:05:17 2013 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 28 Aug 2013 12:05:17 -0400 Subject: Verizon So Cal issues? References: <8078ED370ADA824281219A7B5BADC39B3CA60E09@MBX023-W1-CA-6.exch023.domain.local> Message-ID: Seeing it too but appears to be specific to Level 3 peering points? At least in our case that's what we're seeing. Can barely even get to Level3's own website: 2 3 ms 4 ms 4 ms L100.TAMPFL-VFTTP-77.verizon-gni.net [71.180.234.1] 3 6 ms 7 ms 6 ms G0-5-5-1.TAMPFL-LCR-22.verizon-gni.net [130.81.110.230] 4 7 ms 6 ms 7 ms so-2-0-0-0.TPA01-BB-RTR2.verizon-gni.net [130.81.28.214] 5 21 ms 21 ms 22 ms 0.xe-7-3-0.BR3.ATL4.ALTER.NET [152.63.5.129] 6 351 ms 356 ms 356 ms ae17.edge5.Atlanta2.level3.net [4.68.62.37] 7 338 ms 354 ms 361 ms 4.69.159.54 8 152 ms 151 ms * ae-73-73.ebr3.Atlanta2.Level3.net [4.69.148.253] 9 * 339 ms 341 ms ae-7-7.ebr3.Dallas1.Level3.net [4.69.134.21] 10 151 ms 151 ms 151 ms ae-83-83.csw3.Dallas1.Level3.net [4.69.151.157] 11 * * 350 ms ae-82-82.ebr2.Dallas1.Level3.net [4.69.151.154] 12 381 ms 376 ms * ae-2-2.ebr1.Denver1.Level3.net [4.69.132.105] 13 343 ms 336 ms 329 ms ae-1-51.edge6.Denver1.Level3.net [4.69.147.74] 14 * * * Request timed out. David > -----Original Message----- > From: James Laszko [mailto:jamesl at mythostech.com] > Sent: Wednesday, August 28, 2013 11:25 AM > To: nanog (nanog at nanog.org) > Subject: Verizon So Cal issues? > > We are seeing huge latency and packet loss issues with > Verizon (DSL/FIOS) in Southern California. Does anyone have > any insight? Issues started around 8:10AM Pacific. > > > Regards, > > > James Laszko > Mythos Technology Inc > jamesl at mythostech.com > > > From tlyons at ivenue.com Wed Aug 28 16:15:04 2013 From: tlyons at ivenue.com (Todd Lyons) Date: Wed, 28 Aug 2013 09:15:04 -0700 Subject: Verizon So Cal issues? In-Reply-To: <8078ED370ADA824281219A7B5BADC39B3CA60E09@MBX023-W1-CA-6.exch023.domain.local> References: <8078ED370ADA824281219A7B5BADC39B3CA60E09@MBX023-W1-CA-6.exch023.domain.local> Message-ID: On Wed, Aug 28, 2013 at 8:25 AM, James Laszko wrote: > We are seeing huge latency and packet loss issues with Verizon (DSL/FIOS) in Southern California. Does anyone have any insight? Issues started around 8:10AM Pacific. Been using FIOS served from the Pomona plant all morning with no issues, so I'd suspect it's a locational issue, not regional. Or per David's post, maybe it's dependent upon what you're accessing; I've been mostly VPN'd to the office (VZ -> Alter -> Savvis), which doesn't touch David's paths. ...Todd -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine From shortdudey123 at gmail.com Wed Aug 28 16:27:52 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 28 Aug 2013 09:27:52 -0700 Subject: Verizon So Cal issues? In-Reply-To: References: <8078ED370ADA824281219A7B5BADC39B3CA60E09@MBX023-W1-CA-6.exch023.domain.local> Message-ID: There is definitely a VZ / LVL3 issue http://www.internetpulse.net/ It is affecting VZ's Atlanta node but not Boston node: http://www.internetpulse.net/Main.aspx?OriginValue=Level3&OriginLevel=1&DestinationValue=Verizon&DestinationLevel=1&Metric=TCP -Grant On Wed, Aug 28, 2013 at 9:15 AM, Todd Lyons wrote: > On Wed, Aug 28, 2013 at 8:25 AM, James Laszko > wrote: > > We are seeing huge latency and packet loss issues with Verizon > (DSL/FIOS) in Southern California. Does anyone have any insight? Issues > started around 8:10AM Pacific. > > Been using FIOS served from the Pomona plant all morning with no > issues, so I'd suspect it's a locational issue, not regional. Or per > David's post, maybe it's dependent upon what you're accessing; I've > been mostly VPN'd to the office (VZ -> Alter -> Savvis), which doesn't > touch David's paths. > > ...Todd > -- > The total budget at all receivers for solving senders' problems is $0. > If you want them to accept your mail and manage it the way you want, > send it the way the spec says to. --John Levine > > From mksmith at mac.com Wed Aug 28 16:54:28 2013 From: mksmith at mac.com (Michael Smith) Date: Wed, 28 Aug 2013 09:54:28 -0700 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <1377677883.64231.YahooMailNeo@web181605.mail.ne1.yahoo.com> References: <017601cea358$00a86ad0$01f94070$@com> <091253D8-0E83-49EC-9EA8-B9556A6CDE24@mac.com> <1377677883.64231.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: <9A9F813B-30FA-4397-B216-6AF1A3A87116@mac.com> On Aug 28, 2013, at 1:18 AM, Eric A Louie wrote: > how is that really much different than "reachability"? If I look at my present Netflow results, it's actually a pretty amusing mix - lots of Netflix traffic (bear in mind we're a business ISP, not residential), Google (probably YouTube in there, I haven't dissected it thoroughly), Amazon, Yahoo, Microsoft/MSN, and that's all covered in the peering fabric connection. Outside of that, some private VPN-type traffic, I don't see a lot of government networks, just "normal" Internet browsing and email. It's really "can reach" versus "how well can they reach." I can't any provider that would have less than a full view of the DFZ but, if your primary traffic is to Provider X, and one of your Tier 1's peers locally and the other peers in France, then you would look more closely at the closer one. Unless, of course, that local peer was saturated 99% of the time. Then France might be attractive. In short, it's good to do a lot of due diligence in finding out exactly how your providers of choice are connected to your destinations of choice. Mike > > Since I'm not at the Data Center much, I don't interact with the other customers there. (It's 150 miles away) Due to non-disclosure, the Data Center gang aren't much going to share their customer contact info with me. But it's a nice thought, for sure. > > -e- > > > From: Michael Smith > To: Eric Louie > Cc: nanog at nanog.org > Sent: Tuesday, August 27, 2013 6:48 PM > Subject: Re: Evaluating Tier 1 Internet providers > > You should also consider who exactly your customers (or you alone) want to reach. Are you mostly looking to connect to eyeball networks? Enterprise networks? Government networks? If you have some target networks you should do some due diligence to find out how well connected your various options are to the networks that mean the most to you. > > If possible, I would also recommend talking to other people that are in your data centers, if that's possible. You might find out about hidden vendor-specific gremlins in that location. > > Regards, > > Mike > > > On Aug 27, 2013, at 12:02 PM, Eric Louie wrote: > > > Based on various conversation threads on Nanog I've come up with a few > > criteria for evaluating Tier 1 providers. I'm open to add other criteria - > > what would you add to this list? And how would I get a quantitative or > > qualitative measure of it? > > > > > > > > routing stability > > > > BGP community offerings > > > > congestion issues > > > > BGP Peering relationships > > > > path diversity > > > > IPv6 table size > > > > > > > > Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 > > customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. > > I'm shopping for new service and want to do better than choosing on > > reputation. (or, is reputation also a criteria?) > > > > > > > > much appreciated, > > > > Eric Louie > > > > > > > > > From tdurack at gmail.com Wed Aug 28 17:14:06 2013 From: tdurack at gmail.com (Tim Durack) Date: Wed, 28 Aug 2013 13:14:06 -0400 Subject: Cogent multi-hop BGP In-Reply-To: References: Message-ID: As an update to interested parties: I have been informed that Cogent no longer do the A/B peer config. This is a documentation bug apparently. On Wed, Aug 28, 2013 at 10:20 AM, Tim Durack wrote: > I was under the impression Cogent no longer did the multi-hop BGP thing, > but then I got a copy of their NA user guide, and saw the peer-a/peer-b > configuration. Not a fan. > > Anyone know if this is still required for Cogent IP transit service? > (on/off list is fine.) > > -- > Tim:> > -- Tim:> From bhuffake at caida.org Wed Aug 28 19:16:14 2013 From: bhuffake at caida.org (Bradley Huffaker) Date: Wed, 28 Aug 2013 12:16:14 -0700 Subject: looking for hostname geographic hint validation In-Reply-To: <521E1219.3050409@list-subs.com> References: <20130827193357.GP67165@caida.org> <521E1219.3050409@list-subs.com> Message-ID: <20130828191614.GB40592@caida.org> On Wed, Aug 28, 2013 at 04:07:05PM +0100, Ben wrote: > Dear Bradley, > > So basically you're asking others to do your homework for you ? ;-) Actually no, I'm asking people to do something which I can not. While it is true I could test against a manual inference, I would simply be checking one inference against another. Agreement would only prove that the algorithm does what I expect. Only the operators, who actually know what they are doing, can give me the ground truth I need to test my inferences against reality. > For example, picking one example from your list .... > > ([^a-z]+[a-z]+\d*){3}.ic.ac.uk > > Far from being IATA codes, the intermediate subdomains actually refer to > departments (DepartmentOfComputing and CHemistry in the two I quoted). > > Sorry to rain on your parade, but someone had to say it. ;-) You are most likely right, but I am not looking for perfection. I am hoping for an inference that will get me with in 10 km of the actual city most of the time. Given the validation I have so far, out of the 19,611 hostnames for which a location is inferred, and I have validation data, we infer the city correctly 93% of the time. While there is work left to do, it is far from the lost cause you present. -- the value of a world model is not how accurately it captures reality but how often it leads us to take appropriate action From eric at roxanne.org Wed Aug 28 23:49:43 2013 From: eric at roxanne.org (Eric) Date: Wed, 28 Aug 2013 19:49:43 -0400 Subject: Exchange Point In-Reply-To: References: <08b801ce9556$8b2de550$a189aff0$@towardex.com> Message-ID: There's also the bug R&E data center being built in Holyoke and I'm guessing most fiber runs back to people who put stuff there will go via Springfield... Might be of interest to people who don't have/want dark fiber all the way... I also think (but might be off) that OSEAN and some other regional state & R&E networks have a presence there. On Aug 10, 2013, at 7:21 PM, Bill Woodcock wrote: > >>> Does anyone see value in putting a open exchange point in one federal in >>> Springfield, MA? >> >> Springfield, Mass.? Can't hurt? > > Agreed. There's essentially no reason not to put in an exchange, anywhere three or more ISPs are present. > >> There's also Boston Internet Exchange which has been slowly picking up >> steam, over at 1 Summer; you may want to look into remote interconnection. > > That's 90 miles away, so I'd recommend not trying to extend their switch fabric that far. If you were considering a second exchange in Boston, I'd definitely recommend using the same switch fabric for both locations, but not at 90 miles of remove. That would put a pretty big burden on the smaller ISPs that are likely to be participating in Springfield. > > -Bill > > > > From LarrySheldon at cox.net Thu Aug 29 00:55:24 2013 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 28 Aug 2013 19:55:24 -0500 Subject: Exchange Point In-Reply-To: References: <08b801ce9556$8b2de550$a189aff0$@towardex.com> Message-ID: <521E9BFC.40300@cox.net> I have to ask-- On 8/28/2013 6:49 PM, Eric wrote: > There's also the bug R&E data center Really. Now a feature? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From owen at delong.com Thu Aug 29 02:22:28 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 28 Aug 2013 19:22:28 -0700 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <521DC232.20209@ripe.net> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <70257.1377579726@turing-police.cc.vt.edu> <5DEF4DE9-3680-4D47-9FF0-1FC3CED0A816@delong.com> <105365.1377614001@turing-police.cc.vt.edu> <02E84CD3-B3E6-4990-8748-8339EA7C27B0@delong.com> <521D931A.6010606@fud.no> <521DC232.20209@ripe.net> Message-ID: <42D605DF-0018-45A4-95E1-88EA60DEEE2C@delong.com> Has the path MTU been measured for all vantage point pairs? Is it known to be 1500 or just the end-point MTUs? That could affect your results very differently. Owen On Aug 28, 2013, at 02:26 , Emile Aben wrote: > On 28/08/2013 08:05, Tore Anderson wrote: >> * Owen DeLong >> >>> On Aug 27, 2013, at 07:33 , Valdis.Kletnieks at vt.edu wrote: >>> >>>> Saku Ytti and Emile Aben have numbers that say otherwise. And there must >>>> be a significantly bigger percentage of failures than "pretty close to 0", >>>> or Path MTU Discovery wouldn't have a reputation of being next to useless. >>> >>> No, their numbers describe what happens to single packets of differing sizes. >>> >>> Nothing they did describes results of actually fragmented packets. >> >> Yes, it did. >> >> Hint: 1473 + 8 + 20 > > For Saku: yes. For me: that was my intention, but later I discovered the > Atlas ping does include the ICMP header in it's 'size' parameter so what > I did in effect was 1473 + 20 = 1493 (and not the 1501 I intended). > > Redid the tests to a "known good" destination where I knew interface MTU > (1500) and could tcpdump which confirmed that I was looking at > fragmentation. I also took an offline recommendation to do different > packet sizes to try to distinguish fragmentation issues from general > corruption-based packet loss. > > Results: > size = ICMP packet size, add 20 for IPv4 packet size > fail% = % of vantage points where 5 packets where sent, 0 where received. > #size fail% vantage points > 100 0.88 2963 > 300 0.77 3614 > 500 0.88 1133 > 700 1.07 3258 > 900 1.13 3614 > 1000 1.04 770 > 1100 2.04 3525 > 1200 1.91 3303 > 1300 1.76 681 > 1400 2.06 3014 > 1450 2.53 3597 > 1470 3.01 2192 > 1470 3.12 3592 > 1473 4.96 3566 > 1475 4.96 3387 > 1480 6.04 679 > 1480 4.93 3492 [*] > 1481 9.86 3489 > 1482 9.81 3567 > 1483 9.94 3118 > > There is a ~5% difference going up from 1480 to 1481. > > As to interpreting this: Leo Bicknell's observations (this is to a > "known good" host, and the RIPE Atlas vantage points may very well have > a clueful-operator bias) stand, so interpret with care. Also: roughly > 2/3 of these vantage points are behind NATs that may also have some > firewall(ish) behaviour. > > Hope this data point helps interpreting the magnitude of IPv4 > fragmentation problems. > > Emile Aben > RIPE NCC > > [*] redid the 'size 1480' experiment because the first time around it > had significantly less vantage points. From benno at NLnetLabs.nl Thu Aug 29 08:24:16 2013 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Thu, 29 Aug 2013 10:24:16 +0200 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <20130827065522.GA26981@pob.ytti.fi> <521C6725.8070508@ripe.net> <20130827112436.GA29165@pob.ytti.fi> Message-ID: <521F0530.2000105@NLnetLabs.nl> On 8/27/13 4:04 PM, Leo Bicknell wrote: > I'm pretty sure the failure rate is higher, and here's why. > > The #1 cause of fragments being dropped is firewalls. Too many > admins configuring a firewall do not understand fragments or how to > properly put them in the rules. > > Where do firewalls exist? Typically protecting things with public > IP space, that is (some) corporate networks and banks of content > servers in data centers. This also includes on-box firewalls for > Internet servers, ipfw or iptables on the server is just as likely > to be part of the problem. In a study using the RIPE Atlas probes, we have used a heuristic to figure out where the fragments where dropped. And from the Atlas probes where IP fragments did not arrive, there is a high likelihood the problem is with the last hop to the Atlas probe. All other situations are with the router just before the last hop. We did not find any problems in the core. Of course this was rather limited study using the RIPE Atlas probes in a certain setting. See for the full report "Discovering Path MTU Black Holes on the Internet Using the RIPE Atlas", http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf. > Now, where are RIPE probes? Most RIPE probes are probably either > with somewhat clueful ISP operators, or at Internet Clueful > engineer's personal connectivity (home, or perhaps a box in a > colo). RIPE probes have already significantly self-selected for > people who like non-broken connectivity. What's more, the ping > test was probably to some "known good" host(s), rather than a broad > selection of Internet hosts, so effectively it was only testing the > probe end, not both ends. With help from RIPE NCC (many thanks), we did measurements both ways. Cheers, -- Benno -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From emile.aben at ripe.net Thu Aug 29 10:22:00 2013 From: emile.aben at ripe.net (Emile Aben) Date: Thu, 29 Aug 2013 12:22:00 +0200 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <42D605DF-0018-45A4-95E1-88EA60DEEE2C@delong.com> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <70257.1377579726@turing-police.cc.vt.edu> <5DEF4DE9-3680-4D47-9FF0-1FC3CED0A816@delong.com> <105365.1377614001@turing-police.cc.vt.edu> <02E84CD3-B3E6-4990-8748-8339EA7C27B0@delong.com> <521D931A.6010606@fud.no> <521DC232.20209@ripe.net> <42D605DF-0018-45A4-95E1-88EA60DEEE2C@delong.com> Message-ID: <521F20C8.5000403@ripe.net> On 29/08/2013 04:22, Owen DeLong wrote: > Has the path MTU been measured for all vantage point pairs? I didn't, but see http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf Fig 23 (page 24) for path MTU data from roughly a year ago (thanks Benno for posting that link). Emile From karim.adel at gmail.com Thu Aug 29 13:03:14 2013 From: karim.adel at gmail.com (Kasper Adel) Date: Thu, 29 Aug 2013 15:03:14 +0200 Subject: Parsing Syslog and Acting on it, using other input too Message-ID: Hello. I am looking for a way to do proactive monitoring of my network, what I am specifically thinking about is receiving syslog msgs from the routers and the backend engine would correlate certain msgs with output/data that i am receiving through SSH/telnet sessions. What i am after is not exposed to SNMP so i need to do it on my own. I am sure there are many tools that can do parsing of syslog and acting upon it but i wonder if there is something more flexible out there that I can just re-use to do the above ? Please point me to known public or home-grown scripts in use to achieve this. Regards, Sam From saku at ytti.fi Thu Aug 29 13:08:30 2013 From: saku at ytti.fi (Saku Ytti) Date: Thu, 29 Aug 2013 16:08:30 +0300 Subject: subrate SFP? Message-ID: <20130829130830.GA3850@pob.ytti.fi> How do people deal with situation where you need <=48 SFP/SFP+ ports, but you occasionally need one or two cu 10/100 ports? For some reason it's becoming quite rare for SFP port to natively support 10M and 100M rates. Technically obviously solution to me would be subrate SFP, which presents itself as 1GE to host, offering 100M or 10M to client. This would obviously break QoS at the host as host would still think it's 1GE and SFP itself would need to drop+buffer. But for my applications it would be fine, the 10M or 100M ports are typical some MGMT access interfaces. I can't imagine such SFP being complex or expensive, considering we have E1 over IP in a SFP, which includes control-plane and forwarding-plane inside SFP form-factor Is this demand peculiar? Could I source such SFP somewhere by showing there is demand? Putting 2 port switches or fibre converters with external PSU just to support few ports seem dirty. -- ++ytti From jason at biel-tech.com Thu Aug 29 13:10:46 2013 From: jason at biel-tech.com (Jason Biel) Date: Thu, 29 Aug 2013 08:10:46 -0500 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: References: Message-ID: You should look into SPLUNK (http://www.splunk.com/), it will collect/store your syslog data and you can run customized reports and then act on them. On Thu, Aug 29, 2013 at 8:03 AM, Kasper Adel wrote: > Hello. > > I am looking for a way to do proactive monitoring of my network, what I am > specifically thinking about is receiving syslog msgs from the routers and > the backend engine would correlate certain msgs with output/data that i am > receiving through SSH/telnet sessions. What i am after is not exposed to > SNMP so i need to do it on my own. > > > I am sure there are many tools that can do parsing of syslog and acting > upon it but i wonder if there is something more flexible out there that I > can just re-use to do the above ? Please point me to known public or > home-grown scripts in use to achieve this. > > Regards, > > Sam > -- Jason From rdobbins at arbor.net Thu Aug 29 13:14:48 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 29 Aug 2013 13:14:48 +0000 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: References: Message-ID: On Aug 29, 2013, at 8:03 PM, Kasper Adel wrote: > I am sure there are many tools that can do parsing of syslog and acting upon it but i wonder if there is something more flexible out there that I can just re-use to do the above ? If network traffic is of interest, don't forget about flow telemetry like NetFlow and/or IPFIX. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From kstone at inetlabs.net Thu Aug 29 13:17:48 2013 From: kstone at inetlabs.net (Kevin Stone) Date: Thu, 29 Aug 2013 09:17:48 -0400 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: References: Message-ID: Look at Logstash, http://logstash.net. Rsyslog can do a bit, on Windows you could look at the Solarwinds Kiwi syslog server. On Thu, Aug 29, 2013 at 9:10 AM, Jason Biel wrote: > You should look into SPLUNK (http://www.splunk.com/), it will > collect/store > your syslog data and you can run customized reports and then act on them. > > > On Thu, Aug 29, 2013 at 8:03 AM, Kasper Adel wrote: > > > Hello. > > > > I am looking for a way to do proactive monitoring of my network, what I > am > > specifically thinking about is receiving syslog msgs from the routers and > > the backend engine would correlate certain msgs with output/data that i > am > > receiving through SSH/telnet sessions. What i am after is not exposed to > > SNMP so i need to do it on my own. > > > > > > I am sure there are many tools that can do parsing of syslog and acting > > upon it but i wonder if there is something more flexible out there that I > > can just re-use to do the above ? Please point me to known public or > > home-grown scripts in use to achieve this. > > > > Regards, > > > > Sam > > > > > > -- > Jason > From thijs.stuurman at nxs.nl Thu Aug 29 13:19:57 2013 From: thijs.stuurman at nxs.nl (Thijs Stuurman) Date: Thu, 29 Aug 2013 13:19:57 +0000 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: References: Message-ID: For some straightforward things I have used Logdog (http://caspian.dotconf.net/menu/Software/LogDog/). With kind regards, Thijs Stuurman > -----Original Message----- > From: Kasper Adel [mailto:karim.adel at gmail.com] > Sent: donderdag 29 augustus 2013 15:03 > To: NANOG list > Subject: Parsing Syslog and Acting on it, using other input too > > Hello. > > I am looking for a way to do proactive monitoring of my network, what I am > specifically thinking about is receiving syslog msgs from the routers and the > backend engine would correlate certain msgs with output/data that i am > receiving through SSH/telnet sessions. What i am after is not exposed to > SNMP so i need to do it on my own. > > > I am sure there are many tools that can do parsing of syslog and acting upon > it but i wonder if there is something more flexible out there that I can just re- > use to do the above ? Please point me to known public or home-grown > scripts in use to achieve this. > > Regards, > > Sam From sam at circlenet.us Thu Aug 29 13:25:46 2013 From: sam at circlenet.us (Sam Moats) Date: Thu, 29 Aug 2013 09:25:46 -0400 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: References: Message-ID: <9ef22f40b5b70ac6bea664e473cb62f0@www.circlenet.us> My view on splunk, +1 if you intend to have a human act on the reports, it does an excellent job of reducing huge amounts of audit data into the valuable bits. -1 Seemed to be a pita to integrate with my scripting enviroment. I ended up kludging wget,awk and telnet together in a totally undignified way to make it reach out and act on something. +2 Customizable ingestion/parsing, I'm feeding everything from linux audit data to weird proprietary serial output from a multiplexer into it. -1 Proprietary database I would have liked to see an sql plugin for data storage, I would like the data in Mysql/Oracle but no-joy from splunk so that I can use other tools on it easily. +1 Free demo. You can download an eval version that is rate limited and cripples itself after a fixed time. -1 because The license costs are a bit high if your moving lots of data through it Sam Moats On 2013-08-29 09:10, Jason Biel wrote: > You should look into SPLUNK (http://www.splunk.com/), it will > collect/store > your syslog data and you can run customized reports and then act on > them. > > > On Thu, Aug 29, 2013 at 8:03 AM, Kasper Adel > wrote: > >> Hello. >> >> I am looking for a way to do proactive monitoring of my network, >> what I am >> specifically thinking about is receiving syslog msgs from the >> routers and >> the backend engine would correlate certain msgs with output/data >> that i am >> receiving through SSH/telnet sessions. What i am after is not >> exposed to >> SNMP so i need to do it on my own. >> >> >> I am sure there are many tools that can do parsing of syslog and >> acting >> upon it but i wonder if there is something more flexible out there >> that I >> can just re-use to do the above ? Please point me to known public or >> home-grown scripts in use to achieve this. >> >> Regards, >> >> Sam >> From ikiris at gmail.com Thu Aug 29 14:29:24 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 29 Aug 2013 09:29:24 -0500 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: <9ef22f40b5b70ac6bea664e473cb62f0@www.circlenet.us> References: <9ef22f40b5b70ac6bea664e473cb62f0@www.circlenet.us> Message-ID: Since you said you are willing to entertain home grown as well. I would recommend looking at simple event correlator which is a perl script designed to do the kind of thing you are talking about. I've used it in the past to trigger bgp black holing and mail blacklists for example. On Thu, Aug 29, 2013 at 8:25 AM, Sam Moats wrote: > My view on splunk, > +1 if you intend to have a human act on the reports, it does an excellent > job of reducing huge amounts of audit data into the valuable bits. > -1 Seemed to be a pita to integrate with my scripting enviroment. I ended > up kludging wget,awk and telnet together in a totally undignified way to > make it reach out and act on something. > > +2 Customizable ingestion/parsing, I'm feeding everything from linux audit > data to weird proprietary serial output from a multiplexer into it. > -1 Proprietary database I would have liked to see an sql plugin for data > storage, I would like the data in Mysql/Oracle but no-joy from splunk so > that I can use other tools on it easily. > > +1 Free demo. You can download an eval version that is rate limited and > cripples itself after a fixed time. > -1 because The license costs are a bit high if your moving lots of data > through it > > > Sam Moats > > On 2013-08-29 09:10, Jason Biel wrote: > >> You should look into SPLUNK (http://www.splunk.com/), it will >> collect/store >> your syslog data and you can run customized reports and then act on them. >> >> >> On Thu, Aug 29, 2013 at 8:03 AM, Kasper Adel >> wrote: >> >> Hello. >>> >>> I am looking for a way to do proactive monitoring of my network, what I >>> am >>> specifically thinking about is receiving syslog msgs from the routers and >>> the backend engine would correlate certain msgs with output/data that i >>> am >>> receiving through SSH/telnet sessions. What i am after is not exposed to >>> SNMP so i need to do it on my own. >>> >>> >>> I am sure there are many tools that can do parsing of syslog and acting >>> upon it but i wonder if there is something more flexible out there that I >>> can just re-use to do the above ? Please point me to known public or >>> home-grown scripts in use to achieve this. >>> >>> Regards, >>> >>> Sam >>> >>> > > From mike at sentex.net Thu Aug 29 14:44:51 2013 From: mike at sentex.net (Mike Tancsa) Date: Thu, 29 Aug 2013 10:44:51 -0400 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: References: Message-ID: <521F5E63.9090702@sentex.net> On 8/29/2013 9:03 AM, Kasper Adel wrote: > Hello. > > I am looking for a way to do proactive monitoring of my network, what I am > specifically thinking about is receiving syslog msgs from the routers and You might want to look at http://www.ossec.net/ ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From don.wilder at gmail.com Thu Aug 29 14:50:53 2013 From: don.wilder at gmail.com (Don Wilder) Date: Thu, 29 Aug 2013 10:50:53 -0400 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: <521F5E63.9090702@sentex.net> References: <521F5E63.9090702@sentex.net> Message-ID: I wrote a script in Linux that watches for unauthorized login attempts and adds the ip address to the blocked list in my firewall. You might want to search sourceforge for a DYN Firewall and modify it from there. On Thu, Aug 29, 2013 at 10:44 AM, Mike Tancsa wrote: > On 8/29/2013 9:03 AM, Kasper Adel wrote: > > Hello. > > > > I am looking for a way to do proactive monitoring of my network, what I > am > > specifically thinking about is receiving syslog msgs from the routers and > > You might want to look at > > http://www.ossec.net/ > > ---Mike > > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike at sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > > -- --------------------------------------------- Don Wilder --------------------------------------------- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. From richih.mailinglist at gmail.com Thu Aug 29 14:57:43 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 29 Aug 2013 16:57:43 +0200 Subject: Carrier-neutral data center in NYC with good connectivity to long-haul and local loop Message-ID: Dear all, we want to establish a presence in NYC and will need to collect a few local loops (10M-100M) from around NYC. From there, we will connect back to Germany. So, in summary, we will need: * 2-5 rack units to allow for initial deployment and growth * good connectivity to local loops * good connectivity to long-haul back over the Atlantic and within the Continental US While I already compiled a preliminary list of possible choices, I would like input on what DCs would be well-suited for this. As an aside, who are the most painless and efficient Local Loop carriers within NYC and the US? AT&T and Verizon come to mind, but I don't know the local market at all. Thanks, Richard From g at 1337.io Thu Aug 29 15:18:28 2013 From: g at 1337.io (Gino O'Donnell) Date: Thu, 29 Aug 2013 08:18:28 -0700 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: References: Message-ID: <521F6644.5060101@1337.io> Check out Sagan: http://sagan.quadrantsec.com/ On 8/29/13 6:03 AM, Kasper Adel wrote: > Hello. > > I am looking for a way to do proactive monitoring of my network, what I am > specifically thinking about is receiving syslog msgs from the routers and > the backend engine would correlate certain msgs with output/data that i am > receiving through SSH/telnet sessions. What i am after is not exposed to > SNMP so i need to do it on my own. > > > I am sure there are many tools that can do parsing of syslog and acting > upon it but i wonder if there is something more flexible out there that I > can just re-use to do the above ? Please point me to known public or > home-grown scripts in use to achieve this. > > Regards, > > Sam > From charles-lists at knownelement.com Thu Aug 29 17:14:40 2013 From: charles-lists at knownelement.com (Charles N Wyble) Date: Thu, 29 Aug 2013 12:14:40 -0500 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: References: Message-ID: Yes. Logstash shipper on your syslog proxy, forward to elasticsearch. Graylog2 is very cool. Tried kibana and didn't care for it. Actually setting up graylog2 right now to do AD authentication. So workflow is End device -> syslog-ng vm -> graylog2/elasticsearch vm and other destinations (it corp security cloud for stuff they want to track, observium for anything matching my network gear hostname pattern, etc). I have the middle syslog-ng box so I can have great control over where certain hosts ultimately send data. However that system can be used in any template, if I don't filter it just gets dumped to graylog. Kevin Stone wrote: >Look at Logstash, http://logstash.net. > >Rsyslog can do a bit, on Windows you could look at the Solarwinds Kiwi >syslog server. > > >On Thu, Aug 29, 2013 at 9:10 AM, Jason Biel >wrote: > >> You should look into SPLUNK (http://www.splunk.com/), it will >> collect/store >> your syslog data and you can run customized reports and then act on >them. >> >> >> On Thu, Aug 29, 2013 at 8:03 AM, Kasper Adel >wrote: >> >> > Hello. >> > >> > I am looking for a way to do proactive monitoring of my network, >what I >> am >> > specifically thinking about is receiving syslog msgs from the >routers and >> > the backend engine would correlate certain msgs with output/data >that i >> am >> > receiving through SSH/telnet sessions. What i am after is not >exposed to >> > SNMP so i need to do it on my own. >> > >> > >> > I am sure there are many tools that can do parsing of syslog and >acting >> > upon it but i wonder if there is something more flexible out there >that I >> > can just re-use to do the above ? Please point me to known public >or >> > home-grown scripts in use to achieve this. >> > >> > Regards, >> > >> > Sam >> > >> >> >> >> -- >> Jason >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From carlos at race.com Thu Aug 29 18:03:03 2013 From: carlos at race.com (Carlos Alcantar) Date: Thu, 29 Aug 2013 18:03:03 +0000 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: Message-ID: +1 on Splunk or if you don't mind using a SAS service check out https://papertrailapp.com/ 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: Kasper Adel Date: Thursday, August 29, 2013 6:03 AM To: "nanog at nanog.org" Subject: Parsing Syslog and Acting on it, using other input too Hello. I am looking for a way to do proactive monitoring of my network, what I am specifically thinking about is receiving syslog msgs from the routers and the backend engine would correlate certain msgs with output/data that i am receiving through SSH/telnet sessions. What i am after is not exposed to SNMP so i need to do it on my own. I am sure there are many tools that can do parsing of syslog and acting upon it but i wonder if there is something more flexible out there that I can just re-use to do the above ? Please point me to known public or home-grown scripts in use to achieve this. Regards, Sam From chip.gwyn at gmail.com Thu Aug 29 18:11:17 2013 From: chip.gwyn at gmail.com (chip) Date: Thu, 29 Aug 2013 14:11:17 -0400 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: References: Message-ID: http://www.elasticsearch.com/blog/welcome-jordan-logstash/ So now Logstash and Elasticsearch will be even more integrated than before. With Kibana on top of that, this seems like the ultimate log data "do stuff" stack. --chip On Thu, Aug 29, 2013 at 2:03 PM, Carlos Alcantar wrote: > +1 on Splunk or if you don't mind using a SAS service check out > https://papertrailapp.com/ > > 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: Kasper Adel > Date: Thursday, August 29, 2013 6:03 AM > To: "nanog at nanog.org" > Subject: Parsing Syslog and Acting on it, using other input too > > Hello. > > I am looking for a way to do proactive monitoring of my network, what I am > specifically thinking about is receiving syslog msgs from the routers and > the backend engine would correlate certain msgs with output/data that i am > receiving through SSH/telnet sessions. What i am after is not exposed to > SNMP so i need to do it on my own. > > > I am sure there are many tools that can do parsing of syslog and acting > upon it but i wonder if there is something more flexible out there that I > can just re-use to do the above ? Please point me to known public or > home-grown scripts in use to achieve this. > > Regards, > > Sam > > > > -- Just my $.02, your mileage may vary, batteries not included, etc.... From joelja at bogus.com Thu Aug 29 20:38:27 2013 From: joelja at bogus.com (joel jaeggli) Date: Thu, 29 Aug 2013 13:38:27 -0700 Subject: subrate SFP? In-Reply-To: <20130829130830.GA3850@pob.ytti.fi> References: <20130829130830.GA3850@pob.ytti.fi> Message-ID: <521FB143.5000206@bogus.com> On 8/29/13 6:08 AM, Saku Ytti wrote: > How do people deal with situation where you need <=48 SFP/SFP+ ports, but > you occasionally need one or two cu 10/100 ports? arista 7050s support 100 Mb/s on their copper sfp I have leveraged that, if you can break out the 40Gb/s ports you have as many as 64 ports of 10Gb/s. there are other switches that I've seen do this but they're not common. My problem is mostly around PDU/CDU management, in racks that otherwise would be 10Gb/s only and in general I've addressed it with dedicated switches that support many of these devices rather than just two. > For some reason it's becoming quite rare for SFP port to natively support > 10M and 100M rates. > > Technically obviously solution to me would be subrate SFP, which presents > itself as 1GE to host, offering 100M or 10M to client. This would obviously > break QoS at the host as host would still think it's 1GE and SFP itself > would need to drop+buffer. But for my applications it would be fine, the > 10M or 100M ports are typical some MGMT access interfaces. > I can't imagine such SFP being complex or expensive, considering we have E1 > over IP in a SFP, which includes control-plane and forwarding-plane inside > SFP form-factor > > Is this demand peculiar? Could I source such SFP somewhere by showing there > is demand? > > Putting 2 port switches or fibre converters with external PSU just to > support few ports seem dirty. From jmaimon at ttec.com Thu Aug 29 23:08:33 2013 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 29 Aug 2013 19:08:33 -0400 Subject: Cogent multi-hop BGP In-Reply-To: References: Message-ID: <521FD471.6090005@ttec.com> Tim Durack wrote: > I was under the impression Cogent no longer did the multi-hop BGP thing, > but then I got a copy of their NA user guide, and saw the peer-a/peer-b > configuration. Not a fan. > > Anyone know if this is still required for Cogent IP transit service? > (on/off list is fine.) > A/B multihop has plenty of good points. I would not mind it being a more widely available deployment option. B does not have to be your edge device. Joe From tritran at cox.net Fri Aug 30 00:15:40 2013 From: tritran at cox.net (Tri Tran) Date: Fri, 30 Aug 2013 00:15:40 +0000 Subject: ATT contact Message-ID: <1487387187-1377821742-cardhu_decombobulator_blackberry.rim.net-215006264-@b12.c19.bise6.blackberry> Anyone have an ATT contact so that I can get them to update their routing table? I have an issue where ATT landline customers is unable to call a specific destination number. Tri Tran From jmaimon at ttec.com Fri Aug 30 00:38:03 2013 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 29 Aug 2013 20:38:03 -0400 Subject: will ISP peer with 2 local WAN routers? In-Reply-To: <014a01ce9ac0$1cab26a0$560173e0$@webjogger.net> References: <014a01ce9ac0$1cab26a0$560173e0$@webjogger.net> Message-ID: <521FE96B.9050108@ttec.com> Adam Greene wrote: > Hi guys, > > > > I have a customer who peers via eBGP with Lightpath aka Cablevision (AS > 6128) and Level3 (AS 3356) and wants to do some dual-WAN router redundancy. > > I am not optimistic for your odds in having 6128 do anything other than /30 for you. (Though even then you still have options, up to and including eem IP takeover) > > I have heard that carriers will sometimes agree to set up a /29 WAN subnet > for a customer and peer with (2) customer routers. Carriers who do that and more are my favorites. From MGauvin at dryden.ca Fri Aug 30 00:39:57 2013 From: MGauvin at dryden.ca (Mark Gauvin) Date: Thu, 29 Aug 2013 19:39:57 -0500 Subject: will ISP peer with 2 local WAN routers? In-Reply-To: <521FE96B.9050108@ttec.com> References: <014a01ce9ac0$1cab26a0$560173e0$@webjogger.net> <521FE96B.9050108@ttec.com> Message-ID: Offer to provide a /29 out of your own arin assigned block works wonders Sent from my iPhone On 2013-08-29, at 7:40 PM, "Joe Maimon" wrote: > > > Adam Greene wrote: >> Hi guys, >> >> >> >> I have a customer who peers via eBGP with Lightpath aka Cablevision (AS >> 6128) and Level3 (AS 3356) and wants to do some dual-WAN router redundancy. > > I am not optimistic for your odds in having 6128 do anything other than > /30 for you. > > (Though even then you still have options, up to and including eem IP > takeover) > > >> >> I have heard that carriers will sometimes agree to set up a /29 WAN subnet >> for a customer and peer with (2) customer routers. > > Carriers who do that and more are my favorites. > > From Christopher.Palmer at microsoft.com Fri Aug 30 00:51:20 2013 From: Christopher.Palmer at microsoft.com (Christopher Palmer) Date: Fri, 30 Aug 2013 00:51:20 +0000 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> Message-ID: This is what I'm concerned about: """ 1. If I originate IP packet fragments, such as an 8000 byte NFS packet broken into 1500 byte fragments, what's the probability of some host before the other endpoint dropping one or all of those fragments? """ Big thanks to everyone who has sent thoughts already, really quite helpful. -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Tuesday, August 27, 2013 10:45 AM To: Christopher Palmer Cc: North American Network Operators' Group Subject: Re: IP Fragmentation - Not reliable over the Internet? On Mon, Aug 26, 2013 at 8:01 PM, Christopher Palmer wrote: > What is the probability that a random path between two Internet hosts > will traverse a middlebox that drops or otherwise barfs on fragmented > IPv4 packets? Hi Christopher, I think there might be three rather different questions here: 1. If I originate IP packet fragments, such as an 8000 byte NFS packet broken into 1500 byte fragments, what's the probability of some host before the other endpoint dropping one or all of those fragments? 2. If I send an IP packet that's too large for the path and *don't* set the don't-fragment bit, what' the chance that the router with the too-small next hop will fail to correctly fragment that packet (or that the correctly fragmented packet will fall into trap #1 above)? 3. If I send an IP packet that's too large for the path and *do* set the don't-fragment bit, what's the chance of failing to receive the "packet too big" message it causes the intermediate router to send? Are you after the answer to one in particular? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From marka at isc.org Fri Aug 30 01:15:59 2013 From: marka at isc.org (Mark Andrews) Date: Fri, 30 Aug 2013 11:15:59 +1000 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: Your message of "Fri, 30 Aug 2013 00:51:20 +0000." References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> Message-ID: <20130830011600.1091838FEF4F@drugs.dv.isc.org> In message , Christopher Palmer writes: > This is what I'm concerned about: > > """ > 1. If I originate IP packet fragments, such as an 8000 byte NFS packet > broken into 1500 byte fragments, what's the probability of some host > before the other endpoint dropping one or all of those fragments? > """ For wide area NFS I would be using TCP not UDP. If you can't use TCP you should ensure that the firewalls at both ends pass fragmented UDP packet. NFS is generally not open to the world so fragmentation and NFS is essentially a local issue. Fragments don't get routinely dropped in the core. Ensure that the firealls at both ends pass ICMP/ICMPv6 PTB. Only idiots block all ICMP/ICMPv6. Yes there are a lot of idiots in the world. > Big thanks to everyone who has sent thoughts already, really quite > helpful. > > -----Original Message----- > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William > Herrin > Sent: Tuesday, August 27, 2013 10:45 AM > To: Christopher Palmer > Cc: North American Network Operators' Group > Subject: Re: IP Fragmentation - Not reliable over the Internet? > > On Mon, Aug 26, 2013 at 8:01 PM, Christopher Palmer > wrote: > > What is the probability that a random path between two Internet hosts > > will traverse a middlebox that drops or otherwise barfs on fragmented > > IPv4 packets? > > Hi Christopher, > > I think there might be three rather different questions here: > > 1. If I originate IP packet fragments, such as an 8000 byte NFS packet > broken into 1500 byte fragments, what's the probability of some host > before the other endpoint dropping one or all of those fragments? > > 2. If I send an IP packet that's too large for the path and *don't* set > the don't-fragment bit, what' the chance that the router with the > too-small next hop will fail to correctly fragment that packet (or that > the correctly fragmented packet will fall into trap #1 above)? > > 3. If I send an IP packet that's too large for the path and *do* set the > don't-fragment bit, what's the chance of failing to receive the "packet > too big" message it causes the intermediate router to send? > > Are you after the answer to one in particular? > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: Falls > Church, VA 22042-3004 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Fri Aug 30 01:47:02 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 29 Aug 2013 21:47:02 -0400 Subject: ATT contact In-Reply-To: <1487387187-1377821742-cardhu_decombobulator_blackberry.rim.net-215006264-@b12.c19.bise6.blackberry> References: <1487387187-1377821742-cardhu_decombobulator_blackberry.rim.net-215006264-@b12.c19.bise6.blackberry> Message-ID: On Thu, Aug 29, 2013 at 8:15 PM, Tri Tran wrote: > Anyone have an ATT contact so that I can get them to update their routing table? > I have an issue where ATT landline customers is unable to call a specific destination number. maybe you want to talk to their PSTN support people? :) you can probably call them... From ras at e-gerbil.net Fri Aug 30 02:37:18 2013 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 29 Aug 2013 21:37:18 -0500 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <9A9F813B-30FA-4397-B216-6AF1A3A87116@mac.com> References: <017601cea358$00a86ad0$01f94070$@com> <091253D8-0E83-49EC-9EA8-B9556A6CDE24@mac.com> <1377677883.64231.YahooMailNeo@web181605.mail.ne1.yahoo.com> <9A9F813B-30FA-4397-B216-6AF1A3A87116@mac.com> Message-ID: <20130830023718.GL67768@gerbil.cluepon.net> On Wed, Aug 28, 2013 at 09:54:28AM -0700, Michael Smith wrote: > > It's really "can reach" versus "how well can they reach." I can't any > provider that would have less than a full view of the DFZ but, if your > primary traffic is to Provider X, and one of your Tier 1's peers > locally and the other peers in France, then you would look more > closely at the closer one. Unless, of course, that local peer was > saturated 99% of the time. Then France might be attractive. One thing to keep in mind is that for major Tier 1s, it's not at all uncommon to see some very large percentages of traffic (like say well north of 50%) stay completely on-net, going from customer to customer. In this type of model, capacity to other third party peers (typically the other Tier 1's) becomes secondary to other considerations like backbone capacity, which is why those "huge Tier 1 networks" often have much less peering capacity than you might otherwise expect. Tier 2's on the other hand, typically spend the vast majority of their time/money/effort figuring out how they can deliver traffic to "other networks" via peering and transit relationships. This usually means they have much smaller amounts of backbone capacity, but relative to their total sizes they often have a lot more capacity to the other major peering/transit networks. The economics of each model are vastly different too. Tier 2's are typically always looking to take advantage of tricks like hot potato routing and 95th percentile billing to get "free" inbound to minimize their backhaul costs. All too often people tend to get caught in the mentral trap of thinking "peering == free", but in reality the Tier 1's are just shifting the majority of their operational costs into backbone instead, and peering becomes the way to handle the "leftovers". Each model has its advantages and weaknesses, but most people who haven't lived in both worlds tend to vastly underestimate the realities of the "other side"'s cost models. There is a lot to be said for the value of a Tier 2 network. Sometimes throwing a token amount of money at a problem solves it much more effectively than waiting for two squabbling Tier 1's to fight over the "principal" of not paying anything or risking being perceived as weak. And a Tier 2 with multiple transit paths and extensive peering options may be able to easily reroute traffic around a particular problem spot in a way that a Tier 1 just doesn't have the ability to do. Then again, sometimes there is value in just buying transit from someone who operates a massive entwork, with the economy of scale necessary to implement terabits of backbone capacity for cheap, and a huge customer base. As for the "which one should I buy" question, a smart person would realize the different strengths and weaknesses of each model, and probably end up buying from (at least) one of each to take advantage of this. Of course in reality 99% of people fail to understand any of this, and turn off their brains after thinking things like "1 > 2 so it must be better". :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From tritran at cox.net Fri Aug 30 02:43:22 2013 From: tritran at cox.net (Tri Tran) Date: Thu, 29 Aug 2013 19:43:22 -0700 Subject: ATT contact In-Reply-To: References: <1487387187-1377821742-cardhu_decombobulator_blackberry.rim.net-215006264-@b12.c19.bise6.blackberry> Message-ID: <522006CA.3080300@cox.net> Their cs line was not helpful. Their CISC group helped me in the past but now it's forwarded to a cruise line... http://wholesale.att.com/contact/centers/cisc.html --Tri Tran On 8/29/2013 6:47 PM, Christopher Morrow wrote: > On Thu, Aug 29, 2013 at 8:15 PM, Tri Tran wrote: >> Anyone have an ATT contact so that I can get them to update their routing table? >> I have an issue where ATT landline customers is unable to call a specific destination number. > maybe you want to talk to their PSTN support people? :) > you can probably call them... > From ikiris at gmail.com Fri Aug 30 02:43:18 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Thu, 29 Aug 2013 21:43:18 -0500 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <20130830023718.GL67768@gerbil.cluepon.net> References: <017601cea358$00a86ad0$01f94070$@com> <091253D8-0E83-49EC-9EA8-B9556A6CDE24@mac.com> <1377677883.64231.YahooMailNeo@web181605.mail.ne1.yahoo.com> <9A9F813B-30FA-4397-B216-6AF1A3A87116@mac.com> <20130830023718.GL67768@gerbil.cluepon.net> Message-ID: +10 Good explanation. This is a lot of why I have someone like Cogent/L3/etc and some random transit provider in most of my pops I spec, plus a backhaul to another node. On Thu, Aug 29, 2013 at 9:37 PM, Richard A Steenbergen wrote: > On Wed, Aug 28, 2013 at 09:54:28AM -0700, Michael Smith wrote: > > > > It's really "can reach" versus "how well can they reach." I can't any > > provider that would have less than a full view of the DFZ but, if your > > primary traffic is to Provider X, and one of your Tier 1's peers > > locally and the other peers in France, then you would look more > > closely at the closer one. Unless, of course, that local peer was > > saturated 99% of the time. Then France might be attractive. > > One thing to keep in mind is that for major Tier 1s, it's not at all > uncommon to see some very large percentages of traffic (like say well > north of 50%) stay completely on-net, going from customer to customer. > In this type of model, capacity to other third party peers (typically > the other Tier 1's) becomes secondary to other considerations like > backbone capacity, which is why those "huge Tier 1 networks" often have > much less peering capacity than you might otherwise expect. > > Tier 2's on the other hand, typically spend the vast majority of their > time/money/effort figuring out how they can deliver traffic to "other > networks" via peering and transit relationships. This usually means they > have much smaller amounts of backbone capacity, but relative to their > total sizes they often have a lot more capacity to the other major > peering/transit networks. > > The economics of each model are vastly different too. Tier 2's are > typically always looking to take advantage of tricks like hot potato > routing and 95th percentile billing to get "free" inbound to minimize > their backhaul costs. All too often people tend to get caught in the > mentral trap of thinking "peering == free", but in reality the Tier 1's > are just shifting the majority of their operational costs into backbone > instead, and peering becomes the way to handle the "leftovers". Each > model has its advantages and weaknesses, but most people who haven't > lived in both worlds tend to vastly underestimate the realities of the > "other side"'s cost models. > > There is a lot to be said for the value of a Tier 2 network. Sometimes > throwing a token amount of money at a problem solves it much more > effectively than waiting for two squabbling Tier 1's to fight over the > "principal" of not paying anything or risking being perceived as weak. > And a Tier 2 with multiple transit paths and extensive peering options > may be able to easily reroute traffic around a particular problem spot > in a way that a Tier 1 just doesn't have the ability to do. Then again, > sometimes there is value in just buying transit from someone who > operates a massive entwork, with the economy of scale necessary to > implement terabits of backbone capacity for cheap, and a huge customer > base. > > As for the "which one should I buy" question, a smart person would > realize the different strengths and weaknesses of each model, and > probably end up buying from (at least) one of each to take advantage of > this. Of course in reality 99% of people fail to understand any of this, > and turn off their brains after thinking things like "1 > 2 so it must > be better". :) > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > > From morrowc.lists at gmail.com Fri Aug 30 03:19:21 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 29 Aug 2013 23:19:21 -0400 Subject: ATT contact In-Reply-To: <522006CA.3080300@cox.net> References: <1487387187-1377821742-cardhu_decombobulator_blackberry.rim.net-215006264-@b12.c19.bise6.blackberry> <522006CA.3080300@cox.net> Message-ID: On Thu, Aug 29, 2013 at 10:43 PM, Tri Tran wrote: > Their cs line was not helpful. > > Their CISC group helped me in the past but now it's forwarded to a cruise > line... > http://wholesale.att.com/contact/centers/cisc.html > so... my point was that asking an IP network focused mailing list for PSTN help is not likely to get you success. > --Tri Tran > > On 8/29/2013 6:47 PM, Christopher Morrow wrote: > > On Thu, Aug 29, 2013 at 8:15 PM, Tri Tran wrote: > > Anyone have an ATT contact so that I can get them to update their routing > table? > I have an issue where ATT landline customers is unable to call a specific > destination number. > > maybe you want to talk to their PSTN support people? :) > you can probably call them... > > From lsc at prgmr.com Fri Aug 30 03:25:41 2013 From: lsc at prgmr.com (Luke S. Crawford) Date: Thu, 29 Aug 2013 20:25:41 -0700 Subject: Evaluating Tier 1 Internet providers In-Reply-To: References: <017601cea358$00a86ad0$01f94070$@com> <091253D8-0E83-49EC-9EA8-B9556A6CDE24@mac.com> <1377677883.64231.YahooMailNeo@web181605.mail.ne1.yahoo.com> <9A9F813B-30FA-4397-B216-6AF1A3A87116@mac.com> <20130830023718.GL67768@gerbil.cluepon.net> Message-ID: <522010B5.1030005@prgmr.com> On 08/29/2013 07:43 PM, Blake Dunlap wrote: > +10 Good explanation. > > This is a lot of why I have someone like Cogent/L3/etc and some random > transit provider in most of my pops I spec, plus a backhaul to another node. ... >> One thing to keep in mind is that for major Tier 1s, it's not at all >> uncommon to see some very large percentages of traffic (like say well >> north of 50%) stay completely on-net, going from customer to customer. >> In this type of model, capacity to other third party peers (typically >> the other Tier 1's) becomes secondary to other considerations like >> backbone capacity, which is why those "huge Tier 1 networks" often have >> much less peering capacity than you might otherwise expect. a major problem here is that some providers try too hard to be tier 1... - my pager has gone off many times because $lowcost_tier1 decided to route a packet from them in san jose destined for them in Sacramento through texas. Problem is, often that is still fewer hops, (even if it's many more ms) than going through my tier2 provider, so having the backup did not help me. Nor would taking customer-only routes from $lowcost_tier1... the shortest path, in terms of hops, was through them, through texas. There was nothing to be done short of switching to my tier2. I have no idea how to solve this sort of problem automatically. Ideally, if someone has a congested or down link, I'd prefer that they not announce routes to that part of the internet, as I do have a backup, but that isn't how it works. From ras at e-gerbil.net Fri Aug 30 03:46:48 2013 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 29 Aug 2013 22:46:48 -0500 Subject: Evaluating Tier 1 Internet providers In-Reply-To: <522010B5.1030005@prgmr.com> References: <017601cea358$00a86ad0$01f94070$@com> <091253D8-0E83-49EC-9EA8-B9556A6CDE24@mac.com> <1377677883.64231.YahooMailNeo@web181605.mail.ne1.yahoo.com> <9A9F813B-30FA-4397-B216-6AF1A3A87116@mac.com> <20130830023718.GL67768@gerbil.cluepon.net> <522010B5.1030005@prgmr.com> Message-ID: <20130830034648.GN67768@gerbil.cluepon.net> On Thu, Aug 29, 2013 at 08:25:41PM -0700, Luke S. Crawford wrote: > > I have no idea how to solve this sort of problem automatically. > Ideally, if someone has a congested or down link, I'd prefer that they > not announce routes to that part of the internet, as I do have a > backup, but that isn't how it works. BGP best path routing decisions are made by completely irrelevent criteria like AS-PATH lengths and lower router-id's, and are completely blind to things that actualy matter like latency, capacity, packet loss, etc. Fundamentally it's impossible to fix automatically with the current routing protocols, and at best the protocol extensions like BGP AIGP (which could help at least convey some of the data, like the "oh crap I just got rerouted to a different exit with much higher latency" situation you mentioned) are still a long way from being practically usable. At best you can aim your default/tie breaks towards networks you have "more faith in", but that doesn't mean much in practice. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From morrowc.lists at gmail.com Fri Aug 30 05:33:21 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 30 Aug 2013 01:33:21 -0400 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: References: <521F5E63.9090702@sentex.net> Message-ID: On Thu, Aug 29, 2013 at 10:50 AM, Don Wilder wrote: > I wrote a script in Linux that watches for unauthorized login attempts and > adds the ip address to the blocked list in my firewall. You might want to > search sourceforge for a DYN Firewall and modify it from there. > because fail2ban was too hard to install? or because you just wanted to test yourself? From owen at delong.com Fri Aug 30 05:47:44 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Aug 2013 22:47:44 -0700 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <20130830011600.1091838FEF4F@drugs.dv.isc.org> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <20130830011600.1091838FEF4F@drugs.dv.isc.org> Message-ID: <2EA20DE3-A87C-400D-9B2A-54A7F9EF7988@delong.com> On Aug 29, 2013, at 18:15 , Mark Andrews wrote: > > In message .com>, Christopher Palmer writes: >> This is what I'm concerned about: >> >> """ >> 1. If I originate IP packet fragments, such as an 8000 byte NFS packet >> broken into 1500 byte fragments, what's the probability of some host >> before the other endpoint dropping one or all of those fragments? >> """ > > For wide area NFS I would be using TCP not UDP. If you can't use > TCP you should ensure that the firewalls at both ends pass fragmented > UDP packet. NFS is generally not open to the world so fragmentation > and NFS is essentially a local issue. Fragments don't get routinely > dropped in the core. However, passing fragmented UDP packets has its own (undesirable) set of security implications. Of course running NFS over an unencrypted path in the wild is, well, something with additional (undesirable) set of security implications. (IOW, this should be happening inside a VPN) > Ensure that the firealls at both ends pass ICMP/ICMPv6 PTB. Only > idiots block all ICMP/ICMPv6. Yes there are a lot of idiots in the > world. +1 This cannot be stressed enough. Owen From saku at ytti.fi Fri Aug 30 05:59:24 2013 From: saku at ytti.fi (Saku Ytti) Date: Fri, 30 Aug 2013 08:59:24 +0300 Subject: subrate SFP? In-Reply-To: <521FB143.5000206@bogus.com> References: <20130829130830.GA3850@pob.ytti.fi> <521FB143.5000206@bogus.com> Message-ID: I got quite a bit of replies from sellers selling me cuSFP, insisting they work. So I'd like to clear up on this. For 10/100 to work on SFP slot, the PHY in the host needs to be multirate. Exception is SGMII which supposedly supports magic mode where SFP can ask it to send same bit 10 times, then SFP can discard 9/10 bits, to remain very dumb yet deliver 100M client on 1GE host. RGMII does not support this trick and this trick does not bring you down to 10M. One box that we have right now, which can't do any of this is ME-4924. There is absolutely no reason that you couldn't deliver 'media converter' or '2 port switch' in a SFP casing, to get that 1 10/100 port in every 4500-X or EX4550 port you need to cater some legacy. If my desire is odd (2 people have expressed off list they want same) this won't be built. But if this is somewhat common demand and missing product, we can certainly get such SFP built. Obviously this SFP would cost bit more than normal cuSFP, as it needs to do rudimentary buffering, packet dropping and it needs to have frame parser. On 29 August 2013 23:38, joel jaeggli wrote: > On 8/29/13 6:08 AM, Saku Ytti wrote: > > How do people deal with situation where you need <=48 SFP/SFP+ ports, but > > you occasionally need one or two cu 10/100 ports? > arista 7050s support 100 Mb/s on their copper sfp I have leveraged that, > if you can break out the 40Gb/s ports you have as many as 64 ports of > 10Gb/s. there are other switches that I've seen do this but they're not > common. > > My problem is mostly around PDU/CDU management, in racks that otherwise > would be 10Gb/s only and in general I've addressed it with dedicated > switches that support many of these devices rather than just two. > > For some reason it's becoming quite rare for SFP port to natively support > > 10M and 100M rates. > > > > Technically obviously solution to me would be subrate SFP, which presents > > itself as 1GE to host, offering 100M or 10M to client. This would > obviously > > break QoS at the host as host would still think it's 1GE and SFP itself > > would need to drop+buffer. But for my applications it would be fine, the > > 10M or 100M ports are typical some MGMT access interfaces. > > I can't imagine such SFP being complex or expensive, considering we have > E1 > > over IP in a SFP, which includes control-plane and forwarding-plane > inside > > SFP form-factor > > > > Is this demand peculiar? Could I source such SFP somewhere by showing > there > > is demand? > > > > Putting 2 port switches or fibre converters with external PSU just to > > support few ports seem dirty. > > -- ++ytti From mohta at necom830.hpcl.titech.ac.jp Fri Aug 30 06:39:39 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 30 Aug 2013 15:39:39 +0900 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <20130830011600.1091838FEF4F@drugs.dv.isc.org> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <20130830011600.1091838FEF4F@drugs.dv.isc.org> Message-ID: <52203E2B.9090006@necom830.hpcl.titech.ac.jp> Mark Andrews wrote: > Ensure that the firealls at both ends pass ICMP/ICMPv6 PTB. Only > idiots block all ICMP/ICMPv6. Yes there are a lot of idiots in the > world. The worst idiots are people who designed ICMPv6 [RFC2463] as: (e.2) a packet destined to an IPv6 multicast address (there are two exceptions to this rule: (1) the Packet Too Big Message - Section 3.2 - to allow Path MTU discovery to work for IPv6 multicast, and (2) the Parameter Problem Message, Code 2 - Section 3.4 - reporting an unrecognized IPv6 option that has the Option Type highest-order two bits set to 10), or which makes it necessary, unless you are idiots, to filter ICMPv6 PTB against certain packets, including but not limited to, multicast ones. Masataka Ohta From brandon at rd.bbc.co.uk Fri Aug 30 08:56:12 2013 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 30 Aug 2013 09:56:12 +0100 (BST) Subject: subrate SFP? Message-ID: <201308300856.JAA29671@sunf10.rd.bbc.co.uk> > There is absolutely no reason that you couldn't deliver 'media converter' > or '2 port switch' in a SFP casing Yes, similar devices exist http://www.rad.com/10/SFP-Format-TDM-Pseudowire-Gateway/10267/ so it probably just needs more demand brandon From saku at ytti.fi Fri Aug 30 09:00:59 2013 From: saku at ytti.fi (Saku Ytti) Date: Fri, 30 Aug 2013 12:00:59 +0300 Subject: subrate SFP? In-Reply-To: <201308300856.JAA29671@sunf10.rd.bbc.co.uk> References: <201308300856.JAA29671@sunf10.rd.bbc.co.uk> Message-ID: I actually emailed RAD, MethodE and Avago yesterday and pitched the idea. MiTOP is my exact justification why it should technically be feasible. I guess it would be easier to pitch, if there would be commitment to buy, but I don't personally need many units, just 1-2 here and there. On 30 August 2013 11:56, Brandon Butterworth wrote: > > There is absolutely no reason that you couldn't deliver 'media converter' > > or '2 port switch' in a SFP casing > > Yes, similar devices exist > > http://www.rad.com/10/SFP-Format-TDM-Pseudowire-Gateway/10267/ > > so it probably just needs more demand > > brandon > -- ++ytti From sthaug at nethelp.no Fri Aug 30 09:46:29 2013 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 30 Aug 2013 11:46:29 +0200 (CEST) Subject: subrate SFP? In-Reply-To: References: <201308300856.JAA29671@sunf10.rd.bbc.co.uk> Message-ID: <20130830.114629.74707509.sthaug@nethelp.no> > I actually emailed RAD, MethodE and Avago yesterday and pitched the idea. > > MiTOP is my exact justification why it should technically be feasible. > > I guess it would be easier to pitch, if there would be commitment to buy, > but I don't personally need many units, just 1-2 here and there. I doubt you'd want to pay MiTOP prices, though. Steinar Haug, AS 2116 From jamie at photon.com Fri Aug 30 11:42:04 2013 From: jamie at photon.com (Jamie Bowden) Date: Fri, 30 Aug 2013 11:42:04 +0000 Subject: subrate SFP? In-Reply-To: References: <20130829130830.GA3850@pob.ytti.fi> <521FB143.5000206@bogus.com> Message-ID: <465966A5F5B867419F604CD3E604C1E54D6DD033@PRA-DCA-MAIL.pra.ray.com> > From: Saku Ytti [mailto:saku at ytti.fi] > I got quite a bit of replies from sellers selling me cuSFP, insisting they > work. > > So I'd like to clear up on this. For 10/100 to work on SFP slot, the PHY in > the host needs to be multirate. Exception is SGMII which supposedly > supports magic mode where SFP can ask it to send same bit 10 times, then > SFP can discard 9/10 bits, to remain very dumb yet deliver 100M client on > 1GE host. > > RGMII does not support this trick and this trick does not bring you down to > 10M. One box that we have right now, which can't do any of this is ME-4924. > > There is absolutely no reason that you couldn't deliver 'media converter' > or '2 port switch' in a SFP casing, to get that 1 10/100 port in every > 4500-X or EX4550 port you need to cater some legacy. If my desire is odd (2 > people have expressed off list they want same) this won't be built. But if > this is somewhat common demand and missing product, we can certainly get > such SFP built. > > Obviously this SFP would cost bit more than normal cuSFP, as it needs to do > rudimentary buffering, packet dropping and it needs to have frame parser. Considering that Dell and HP at least are shipping brand new hardware with IPMI/BMC/iLO/whatever management ports that can only speak 100mbit when every other Ethernet interface in the box at least gigabit, having a useful way to talk to that port without having to keep separate switching hardware around would be nice. I'm not holding my breath, but you know, along with a pony, this would be nice. Jamie From randy at psg.com Fri Aug 30 11:58:26 2013 From: randy at psg.com (Randy Bush) Date: Fri, 30 Aug 2013 20:58:26 +0900 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <521F0530.2000105@NLnetLabs.nl> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <20130827065522.GA26981@pob.ytti.fi> <521C6725.8070508@ripe.net> <20130827112436.GA29165@pob.ytti.fi> <521F0530.2000105@NLnetLabs.nl> Message-ID: > In a study using the RIPE Atlas probes, we have used a heuristic to > figure out where the fragments where dropped. And from the Atlas > probes where IP fragments did not arrive, there is a high likelihood > the problem is with the last hop to the Atlas probe. i wonder if this is correlated with the high number of probes being behind nats. randy From ag4ve.us at gmail.com Fri Aug 30 12:55:52 2013 From: ag4ve.us at gmail.com (Shawn Wilson) Date: Fri, 30 Aug 2013 08:55:52 -0400 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: References: <521F5E63.9090702@sentex.net> Message-ID: Christopher Morrow wrote: >On Thu, Aug 29, 2013 at 10:50 AM, Don Wilder >wrote: >> I wrote a script in Linux that watches for unauthorized login >attempts and >> adds the ip address to the blocked list in my firewall. You might >want to >> search sourceforge for a DYN Firewall and modify it from there. >> > >because fail2ban was too hard to install? or because you just wanted >to test yourself? Actually I did the same. I use ipset lists (generally with a timeout) and take a regex or two and black / white list from a YAML file and just take (possibly multiple inputs) from piping tail -F. I also store addresses for future reference (by the script or otherwise). This is quite maintainable as I can look at a list of people who have attacked the mail server and compare it to web attacks. Each process is a different type of service (different config file) and probably a different ipset. Due to ipset not actually doing anything until I make an iptables rule for it, I can run my script in a test mode (by default) and just see what happens (check it's logs and the ipset list it generates). I haven't found the need for this yet but I can use cymru to look up how big their net is (see geocidr for an example of how to do this in perl) and use a hash:net ipset type and cover a whole net. Basically what I'm saying in doing it this way is quite expandable and isn't very hard and I can do tons of stuff that fail2ban can't (I don't think - it's been a while since I looked). From morrowc.lists at gmail.com Fri Aug 30 14:00:06 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 30 Aug 2013 10:00:06 -0400 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: References: <521F5E63.9090702@sentex.net> Message-ID: On Fri, Aug 30, 2013 at 8:55 AM, Shawn Wilson wrote: > > > Christopher Morrow wrote: >>On Thu, Aug 29, 2013 at 10:50 AM, Don Wilder >>wrote: >>> I wrote a script in Linux that watches for unauthorized login >>attempts and >>> adds the ip address to the blocked list in my firewall. You might >>want to >>> search sourceforge for a DYN Firewall and modify it from there. >>> >> >>because fail2ban was too hard to install? or because you just wanted >>to test yourself? > > Actually I did the same. I use ipset lists (generally with a timeout) and take a regex or two and black / white list from a YAML file and just take (possibly multiple inputs) from piping tail -F. I also store addresses for future reference (by the script or otherwise). > > This is quite maintainable as I can look at a list of people who have attacked the mail server and compare it to web attacks. Each process is a different type of service (different config file) and probably a different ipset. Due to ipset not actually doing anything until I make an iptables rule for it, I can run my script in a test mode (by default) and just see what happens (check it's logs and the ipset list it generates). I haven't found the need for this yet but I can use cymru to look up how big their net is (see geocidr for an example of how to do this in perl) and use a hash:net ipset type and cover a whole net. > > Basically what I'm saying in doing it this way is quite expandable and isn't very hard and I can do tons of stuff that fail2ban can't (I don't think - it's been a while since I looked). you seem to be describing what fail2ban does... that and some grep of syslog for fail2ban messages. If your solution works then great! :) From benno at NLnetLabs.nl Fri Aug 30 14:36:39 2013 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Fri, 30 Aug 2013 16:36:39 +0200 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <20130827065522.GA26981@pob.ytti.fi> <521C6725.8070508@ripe.net> <20130827112436.GA29165@pob.ytti.fi> <521F0530.2000105@NLnetLabs.nl> Message-ID: <5220ADF7.6030204@NLnetLabs.nl> On 08/30/2013 01:58 PM, Randy Bush wrote: >> In a study using the RIPE Atlas probes, we have used a heuristic to >> figure out where the fragments where dropped. And from the Atlas >> probes where IP fragments did not arrive, there is a high likelihood >> the problem is with the last hop to the Atlas probe. > > i wonder if this is correlated with the high number of probes being > behind nats. That would be a viable explanation, although we have not tried to fingerprint the probes to figure out if this was true. If we will rerun the experiments in the future, we should spent more effort into identifying the router/middlebox that is giving the IP fragmentation problems (drops or blocking PMTUD ICMP). -- Benno -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From ag4ve.us at gmail.com Fri Aug 30 15:17:37 2013 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 30 Aug 2013 11:17:37 -0400 Subject: Parsing Syslog and Acting on it, using other input too In-Reply-To: References: <521F5E63.9090702@sentex.net> Message-ID: Ah it seems they do: https://github.com/fail2ban/fail2ban/blob/master/config/action.d/iptables-ipset-proto6.conf IDK enough about fail2ban to know whether I can assign a per proto or per log type config (I assume I can). In which casethis does what my script does and then some. I would probably dump out a ipset save on exit and try to 'restore' on resume (which /I/ do) and I'm sure there's a way fail2ban can check a store of addresses and check what network a host belongs to (instead of just a host). So, fail2ban is probably the way to go. On Fri, Aug 30, 2013 at 10:00 AM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > On Fri, Aug 30, 2013 at 8:55 AM, Shawn Wilson wrote: > > > > > > Christopher Morrow wrote: > >>On Thu, Aug 29, 2013 at 10:50 AM, Don Wilder > >>wrote: > >>> I wrote a script in Linux that watches for unauthorized login > >>attempts and > >>> adds the ip address to the blocked list in my firewall. You might > >>want to > >>> search sourceforge for a DYN Firewall and modify it from there. > >>> > >> > >>because fail2ban was too hard to install? or because you just wanted > >>to test yourself? > > > > Actually I did the same. I use ipset lists (generally with a timeout) > and take a regex or two and black / white list from a YAML file and just > take (possibly multiple inputs) from piping tail -F. I also store addresses > for future reference (by the script or otherwise). > > > > This is quite maintainable as I can look at a list of people who have > attacked the mail server and compare it to web attacks. Each process is a > different type of service (different config file) and probably a different > ipset. Due to ipset not actually doing anything until I make an iptables > rule for it, I can run my script in a test mode (by default) and just see > what happens (check it's logs and the ipset list it generates). I haven't > found the need for this yet but I can use cymru to look up how big their > net is (see geocidr for an example of how to do this in perl) and use a > hash:net ipset type and cover a whole net. > > > > Basically what I'm saying in doing it this way is quite expandable and > isn't very hard and I can do tons of stuff that fail2ban can't (I don't > think - it's been a while since I looked). > > you seem to be describing what fail2ban does... that and some grep of > syslog for fail2ban messages. If your solution works then great! :) > From tdurack at gmail.com Fri Aug 30 15:30:24 2013 From: tdurack at gmail.com (Tim Durack) Date: Fri, 30 Aug 2013 11:30:24 -0400 Subject: subrate SFP? In-Reply-To: References: <201308300856.JAA29671@sunf10.rd.bbc.co.uk> Message-ID: I think this is a great idea. Maybe not a huge market, but I would buy them, instead of having to use dumb transceivers. It would be interesting to have some other smart SFP options too, like macsec for example... Tim:> On Fri, Aug 30, 2013 at 5:00 AM, Saku Ytti wrote: > I actually emailed RAD, MethodE and Avago yesterday and pitched the idea. > > MiTOP is my exact justification why it should technically be feasible. > > I guess it would be easier to pitch, if there would be commitment to buy, > but I don't personally need many units, just 1-2 here and there. > > > > On 30 August 2013 11:56, Brandon Butterworth wrote: > > > > There is absolutely no reason that you couldn't deliver 'media > converter' > > > or '2 port switch' in a SFP casing > > > > Yes, similar devices exist > > > > http://www.rad.com/10/SFP-Format-TDM-Pseudowire-Gateway/10267/ > > > > so it probably just needs more demand > > > > brandon > > > > > > -- > ++ytti > -- Tim:> From ken.gilmour at gmail.com Fri Aug 30 16:03:51 2013 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Fri, 30 Aug 2013 17:03:51 +0100 Subject: Google corporate network engineer Message-ID: Hello, Is there a Google corporate network engineer here who can contact me off list please? It's regarding some issues with connectivity to the Google corporate network services and load balancing (not Google apps). Thanks! Ken From cscora at apnic.net Fri Aug 30 18:34:02 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 31 Aug 2013 04:34:02 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201308301834.r7UIY2Gs016552@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 31 Aug, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 465107 Prefixes after maximum aggregation: 187550 Deaggregation factor: 2.48 Unique aggregates announced to Internet: 231015 Total ASes present in the Internet Routing Table: 44850 Prefixes per ASN: 10.37 Origin-only ASes present in the Internet Routing Table: 35058 Origin ASes announcing only one prefix: 16251 Transit ASes present in the Internet Routing Table: 5917 Transit-only ASes present in the Internet Routing Table: 178 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 29 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 5356 Unregistered ASNs in the Routing Table: 1757 Number of 32-bit ASNs allocated by the RIRs: 4989 Number of 32-bit ASNs visible in the Routing Table: 3875 Prefixes from 32-bit ASNs in the Routing Table: 11812 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 352 Number of addresses announced to Internet: 2638983692 Equivalent to 157 /8s, 75 /16s and 178 /24s Percentage of available address space announced: 71.3 Percentage of allocated address space announced: 71.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.9 Total number of prefixes smaller than registry allocations: 162731 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 110153 Total APNIC prefixes after maximum aggregation: 33429 APNIC Deaggregation factor: 3.30 Prefixes being announced from the APNIC address blocks: 112046 Unique aggregates announced from the APNIC address blocks: 46620 APNIC Region origin ASes present in the Internet Routing Table: 4873 APNIC Prefixes per ASN: 22.99 APNIC Region origin ASes announcing only one prefix: 1230 APNIC Region transit ASes present in the Internet Routing Table: 828 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 650 Number of APNIC addresses announced to Internet: 727650304 Equivalent to 43 /8s, 95 /16s and 16 /24s Percentage of available APNIC address space announced: 85.0 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: 161368 Total ARIN prefixes after maximum aggregation: 80974 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 161870 Unique aggregates announced from the ARIN address blocks: 75307 ARIN Region origin ASes present in the Internet Routing Table: 15853 ARIN Prefixes per ASN: 10.21 ARIN Region origin ASes announcing only one prefix: 6023 ARIN Region transit ASes present in the Internet Routing Table: 1667 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: 20 Number of ARIN addresses announced to Internet: 1070990592 Equivalent to 63 /8s, 214 /16s and 5 /24s Percentage of available ARIN address space announced: 56.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 119263 Total RIPE prefixes after maximum aggregation: 60940 RIPE Deaggregation factor: 1.96 Prefixes being announced from the RIPE address blocks: 123132 Unique aggregates announced from the RIPE address blocks: 79169 RIPE Region origin ASes present in the Internet Routing Table: 17385 RIPE Prefixes per ASN: 7.08 RIPE Region origin ASes announcing only one prefix: 8240 RIPE Region transit ASes present in the Internet Routing Table: 2817 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2392 Number of RIPE addresses announced to Internet: 657235428 Equivalent to 39 /8s, 44 /16s and 157 /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: 50836 Total LACNIC prefixes after maximum aggregation: 9620 LACNIC Deaggregation factor: 5.28 Prefixes being announced from the LACNIC address blocks: 55531 Unique aggregates announced from the LACNIC address blocks: 25704 LACNIC Region origin ASes present in the Internet Routing Table: 2000 LACNIC Prefixes per ASN: 27.77 LACNIC Region origin ASes announcing only one prefix: 563 LACNIC Region transit ASes present in the Internet Routing Table: 375 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: 807 Number of LACNIC addresses announced to Internet: 135924264 Equivalent to 8 /8s, 26 /16s and 10 /24s Percentage of available LACNIC address space announced: 81.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 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: 11573 Total AfriNIC prefixes after maximum aggregation: 2537 AfriNIC Deaggregation factor: 4.56 Prefixes being announced from the AfriNIC address blocks: 12176 Unique aggregates announced from the AfriNIC address blocks: 3888 AfriNIC Region origin ASes present in the Internet Routing Table: 652 AfriNIC Prefixes per ASN: 18.67 AfriNIC Region origin ASes announcing only one prefix: 195 AfriNIC Region transit ASes present in the Internet Routing Table: 138 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 46511616 Equivalent to 2 /8s, 197 /16s and 182 /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 2872 11560 900 Korea Telecom (KIX) 17974 2668 903 91 PT TELEKOMUNIKASI INDONESIA 7545 2062 321 112 TPG Internet Pty Ltd 4755 1768 391 190 TATA Communications formerly 9829 1492 1220 44 BSNL National Internet Backbo 9583 1227 92 506 Sify Limited 9498 1181 309 70 BHARTI Airtel Ltd. 4808 1155 2128 337 CNCGROUP IP network: China169 7552 1139 1080 13 Vietel Corporation 24560 1089 394 160 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 3069 3689 62 bellsouth.net, inc. 18566 2065 382 184 Covad Communications 22773 2042 2933 124 Cox Communications, Inc. 1785 2006 679 125 PaeTec Communications, Inc. 20115 1673 1645 629 Charter Communications 4323 1615 1103 408 Time Warner Telecom 701 1522 11119 797 UUNET Technologies, Inc. 30036 1348 301 643 Mediacom Communications Corp 7018 1311 11277 827 AT&T WorldNet Services 11492 1220 218 366 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 1642 544 16 Corbina telecom 2118 1368 97 13 EUnet/RELCOM Autonomous Syste 34984 1307 244 221 BILISIM TELEKOM 31148 982 43 18 FreeNet ISP 20940 980 351 756 Akamai Technologies European 6830 895 2367 428 UPC Distribution Services 13188 846 99 72 Educational Network 8551 751 370 41 Bezeq International 12479 687 797 53 Uni2 Autonomous System 58113 541 55 339 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 3225 1695 101 NET Servicos de Comunicao S.A 10620 2614 421 238 TVCABLE BOGOTA 7303 1733 1158 223 Telecom Argentina Stet-France 18881 1452 844 20 Global Village Telecom 8151 1287 2774 389 UniNet S.A. de C.V. 11830 945 364 15 Instituto Costarricense de El 27947 839 94 91 Telconet S.A 6503 790 434 61 AVANTEL, S.A. 6147 734 374 25 Telefonica Del Peru 3816 723 302 83 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 1861 112 5 MOBITEL 24863 870 274 30 LINKdotNET AS number 6713 543 633 26 Itissalat Al-MAGHRIB 8452 435 956 9 TEDATA 24835 291 80 8 RAYA Telecom - Egypt 3741 258 921 217 The Internet Solution 36992 222 501 28 Etisalat MISR 15706 221 32 6 Sudatel Internet Exchange Aut 29571 220 17 12 Ci Telecom Autonomous system 12258 193 28 71 Vodacom Internet Company 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 28573 3225 1695 101 NET Servicos de Comunicao S.A 6389 3069 3689 62 bellsouth.net, inc. 4766 2872 11560 900 Korea Telecom (KIX) 17974 2668 903 91 PT TELEKOMUNIKASI INDONESIA 10620 2614 421 238 TVCABLE BOGOTA 18566 2065 382 184 Covad Communications 7545 2062 321 112 TPG Internet Pty Ltd 22773 2042 2933 124 Cox Communications, Inc. 1785 2006 679 125 PaeTec Communications, Inc. 36998 1861 112 5 MOBITEL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3069 3007 bellsouth.net, inc. 17974 2668 2577 PT TELEKOMUNIKASI INDONESIA 10620 2614 2376 TVCABLE BOGOTA 4766 2872 1972 Korea Telecom (KIX) 7545 2062 1950 TPG Internet Pty Ltd 22773 2042 1918 Cox Communications, Inc. 18566 2065 1881 Covad Communications 1785 2006 1881 PaeTec Communications, Inc. 36998 1861 1856 MOBITEL 8402 1642 1626 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 30621 UNALLOCATED 12.151.74.0/23 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 100.100.0.0/24 4847 China Networks Inter-Exchange Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.90.128.0/18 27418 OUTOFWALL INC. 23.90.192.0/18 36086 Broad Communications Technolo 23.91.0.0/19 40676 Psychz Networks 23.91.32.0/19 36315 Servpac Inc. 23.92.16.0/21 8001 Net Access Corporation 23.92.24.0/22 6939 Hurricane Electric 23.92.48.0/20 62471 SupremeBytes, LLC 23.92.64.0/24 54540 Incero LLC 23.92.65.0/24 54540 Incero LLC 23.92.66.0/24 54540 Incero LLC 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:93 /12:250 /13:480 /14:907 /15:1620 /16:12771 /17:6674 /18:11082 /19:22660 /20:32276 /21:34963 /22:49128 /23:42939 /24:246733 /25:878 /26:986 /27:460 /28:44 /29:75 /30:17 /31:0 /32:14 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2016 2065 Covad Communications 36998 1826 1861 MOBITEL 6389 1714 3069 bellsouth.net, inc. 8402 1374 1642 Corbina telecom 22773 1329 2042 Cox Communications, Inc. 30036 1211 1348 Mediacom Communications Corp 11492 1181 1220 Cable One 1785 1078 2006 PaeTec Communications, Inc. 6983 1025 1153 ITC^Deltacom 10620 944 2614 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:800 2:789 3:3 4:19 5:911 6:19 8:602 12:1895 13:2 14:872 15:11 16:3 17:11 18:19 20:18 23:370 24:1741 27:1555 31:1406 32:45 33:2 34:5 36:73 37:1842 38:902 39:4 40:179 41:3239 42:244 44:9 46:1958 47:4 49:665 50:838 52:12 54:37 55:6 57:26 58:1162 59:623 60:336 61:1415 62:1220 63:1989 64:4569 65:2293 66:4176 67:2072 68:1087 69:3303 70:863 71:496 72:2003 74:2536 75:327 76:302 77:1162 78:1054 79:628 80:1315 81:1022 82:634 83:584 84:579 85:1237 86:479 87:1046 88:539 89:1819 90:158 91:5589 92:636 93:1668 94:2023 95:1528 96:524 97:347 98:1041 99:44 100:29 101:597 103:3223 105:519 106:139 107:210 108:497 109:1869 110:953 111:1114 112:568 113:791 114:711 115:1032 116:973 117:804 118:1126 119:1292 120:364 121:740 122:1868 123:1240 124:1384 125:1418 128:610 129:223 130:311 131:671 132:351 133:160 134:282 135:67 136:259 137:267 138:347 139:178 140:197 141:321 142:552 143:383 144:493 145:100 146:531 147:490 148:685 149:354 150:151 151:561 152:415 153:194 154:30 155:481 156:274 157:407 158:282 159:750 160:350 161:460 162:622 163:222 164:628 165:561 166:255 167:605 168:1033 169:126 170:1081 171:191 172:25 173:1601 174:517 175:495 176:1194 177:2105 178:1908 179:118 180:1520 181:680 182:1244 183:444 184:640 185:791 186:2480 187:1375 188:1914 189:1281 190:7042 192:6946 193:5846 194:4702 195:3591 196:1334 197:1002 198:4647 199:5442 200:6017 201:2604 202:8934 203:8905 204:4525 205:2597 206:2838 207:2900 208:3994 209:3633 210:2936 211:1556 212:2252 213:2052 214:918 215:101 216:5304 217:1648 218:623 219:314 220:1277 221:555 222:324 223:506 End of report From tabris at tabris.net Tue Aug 27 20:35:28 2013 From: tabris at tabris.net (tabris) Date: Tue, 27 Aug 2013 13:35:28 -0700 Subject: looking for hostname geographic hint validation In-Reply-To: <20130827193357.GP67165@caida.org> References: <20130827193357.GP67165@caida.org> Message-ID: <521D0D90.1010204@tabris.net> On 08/27/2013 12:33 PM, Bradley Huffaker wrote: > We are currently working on an algorithm that automatically detects > geographic hints inside of hostnames. At this point we are seeking > operators who can validate some of our inferences. Please contact me > if you can valid one of the inferences below or can provide us with one > we have missed. > > ########################################### > # Inferences > ########################################### > > (International Air Transport Association airport code) > http://en.wikipedia.org/wiki/International_Air_Transport_Association_airport_code > International Civil Aviation Organization airport code > http://en.wikipedia.org/wiki/International_Civil_Aviation_Organization_airport_code > COMMON LANGUAGE Location Identifier Code > http://en.wikipedia.org/wiki/CLLI > largest populated city with the given name > for example "sandiego" is "San Diego, CA, US" > .yahoo.com > not in every case is iata helpful for yahoo. There is lax.yahoo.com and sjc.yahoo.com, but that's really only true for a few limited peering-points. for non-US, most of the actual data centres have names related to the country. in US often more city related, but even that's a bit hairy with places like 'mud.yahoo.com' peering points are still somewhat more random, may be city, country, or partner related ['the' is in london, for example] From mpetach at netflight.com Fri Aug 30 21:45:09 2013 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 30 Aug 2013 14:45:09 -0700 Subject: looking for hostname geographic hint validation In-Reply-To: <521D0D90.1010204@tabris.net> References: <20130827193357.GP67165@caida.org> <521D0D90.1010204@tabris.net> Message-ID: On Tue, Aug 27, 2013 at 1:35 PM, tabris wrote: > On 08/27/2013 12:33 PM, Bradley Huffaker wrote: > > We are currently working on an algorithm that automatically detects > > geographic hints inside of hostnames. At this point we are seeking > > operators who can validate some of our inferences. Please contact me > > if you can valid one of the inferences below or can provide us with one > > we have missed. > > > > ########################################### > > # Inferences > > ########################################### > > > > (International Air Transport Association airport code) > > > http://en.wikipedia.org/wiki/International_Air_Transport_Association_airport_code > > International Civil Aviation Organization airport code > > > http://en.wikipedia.org/wiki/International_Civil_Aviation_Organization_airport_code > > COMMON LANGUAGE Location Identifier Code > > http://en.wikipedia.org/wiki/CLLI > > largest populated city with the given name > > for example "sandiego" is "San Diego, CA, US" > > .yahoo.com > > > not in every case is iata helpful for yahoo. > > There is lax.yahoo.com and sjc.yahoo.com, but that's really only true > for a few limited peering-points. > for non-US, most of the actual data centres have names related to the > country. in US often more city related, but even that's a bit hairy with > places like 'mud.yahoo.com' > Hey, MUD made sense at the time; it's the "Mid US Datacenter". :P (now, good luck fitting that into any pattern scheme...) > peering points are still somewhat more random, may be city, country, or > partner related ['the' is in london, for example] THE makes sense; everyone knows TeleHouse East. I actually didn't even know about the IATA acronym until this thread, so I can honestly say it didn't enter into the naming discussions; I dare say there's a lot of other networks out there in a similar situation. Hitting 93% accuracy is actually pretty mindblowing from my perspective, given how random some of the naming choices are. ^_^; Matt From cidr-report at potaroo.net Fri Aug 30 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Aug 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201308302200.r7UM00TA042344@wattle.apnic.net> This report has been generated at Fri Aug 30 21:13:28 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 23-08-13 475628 270610 24-08-13 476232 270671 25-08-13 476677 270524 26-08-13 476502 270544 27-08-13 476404 272206 28-08-13 479770 272778 29-08-13 479591 271300 30-08-13 479696 271126 AS Summary 45021 Number of ASes in routing system 18534 Number of ASes announcing only one prefix 4172 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 117919968 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'). --- 30Aug13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 479732 271245 208487 43.5% All ASes AS6389 3069 65 3004 97.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 3225 472 2753 85.4% NET Servi?os de Comunica??o S.A. AS17974 2667 259 2408 90.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 4172 2020 2152 51.6% WINDSTREAM - Windstream Communications Inc AS4766 2872 915 1957 68.1% KIXS-AS-KR Korea Telecom AS22773 2045 132 1913 93.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2065 468 1597 77.3% COVAD - Covad Communications Co. AS10620 2615 1039 1576 60.3% Telmex Colombia S.A. AS3356 3244 1715 1529 47.1% LEVEL3 Level 3 Communications AS36998 1862 394 1468 78.8% SDN-MOBITEL AS4323 2970 1533 1437 48.4% TWTC - tw telecom holdings, inc. AS18881 1452 67 1385 95.4% Global Village Telecom AS2118 1368 53 1315 96.1% RELCOM-AS OOO "NPO Relcom" AS7303 1733 455 1278 73.7% Telecom Argentina S.A. AS4755 1766 585 1181 66.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1139 91 1048 92.0% VIETEL-AS-AP Vietel Corporation AS22561 1197 212 985 82.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS1785 2006 1155 851 42.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS11830 946 117 829 87.6% Instituto Costarricense de Electricidad y Telecom. AS18101 982 179 803 81.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1155 397 758 65.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7545 2066 1340 726 35.1% TPG-INTERNET-AP TPG Telecom Limited AS701 1523 801 722 47.4% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS13977 854 140 714 83.6% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS8151 1290 587 703 54.5% Uninet S.A. de C.V. AS855 736 55 681 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6983 1153 484 669 58.0% ITCDELTA - ITC^Deltacom AS24560 1089 430 659 60.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 759 133 626 82.5% GIGAINFRA Softbank BB Corp. AS33363 1639 1030 609 37.2% BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC Total 55659 17323 38336 68.9% Top 30 total Possible Bogus Routes 23.92.128.0/17 AS42981 RES-PL RES.PL ISP S.C. 27.54.116.0/22 AS55452 27.54.116.0/24 AS55452 27.54.119.0/24 AS55452 31.13.184.0/21 AS42981 RES-PL RES.PL ISP S.C. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.182.96.0/23 AS15830 TELECITY-LON TELECITYGROUP INTERNATIONAL LIMITED 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. 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 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.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 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 80.68.144.0/20 AS33982 82.103.0.0/18 AS30901 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.205.188.0/22 AS47983 91.209.163.0/24 AS48445 91.212.54.0/24 AS21409 IKOULA Ikoula Net SAS 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 96.45.48.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.49.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.50.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.51.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.52.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.53.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.54.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.55.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.56.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.57.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.58.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.59.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.60.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.61.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.62.0/24 AS33475 RSN-1 - RockSolid Network, Inc. 96.45.63.0/24 AS33475 RSN-1 - RockSolid Network, 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.13.28.0/24 AS56309 SIAMDATA-TH 558/402 Ratchadapisek rd, 103.13.29.0/24 AS56309 SIAMDATA-TH 558/402 Ratchadapisek rd, 103.13.30.0/24 AS56309 SIAMDATA-TH 558/402 Ratchadapisek rd, 103.13.31.0/24 AS56309 SIAMDATA-TH 558/402 Ratchadapisek rd, 103.224.163.0/24 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 103.224.188.0/23 AS13251 ASIAN-AS-AP Asian Broadcasting Network (M) Sdn Bhd 109.71.156.0/23 AS21246 IPKO-AS Ipko Telecommunications LLC 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.40.184.0/24 AS19821 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.144.0/20 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 185.34.76.0/22 AS50387 RDI-AS Yureco Spolka Akcyjna 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.124.252.0/22 AS7303 Telecom Argentina S.A. 193.33.66.0/23 AS39874 193.33.112.0/23 AS8586 OBSL-AS TalkTalk Communications Limited 193.34.108.0/22 AS42270 MAYNET-AS MAYNET SRL 193.109.15.0/24 AS12690 MKSNET-AS MKS Autonomous System 193.109.224.0/24 AS47427 193.111.125.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.111.155.0/24 AS44581 SE-ALLTELE AllTele Allmanna Svenska Telefonaktiebolaget 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 194.50.82.0/24 AS16276 OVH OVH Systems 194.79.48.0/22 AS39117 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.117.250.0/23 AS41412 MIVITEC-AS MIVITEC GmbH 194.126.219.0/24 AS34545 194.169.237.0/24 AS12968 CDP Netia SA 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 201.77.96.0/20 AS28639 Daniela Ropke da Rosa 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 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.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 203.191.48.0/20 AS24175 VINAREN-AS-AP VietNam Research and Education Network 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 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.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 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.68.244.0/22 AS17140 208.68.244.0/23 AS17140 208.68.246.0/23 AS17140 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 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.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 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.90.64.0/22 AS16415 PRCNET-DOM - Precision Response Corporation 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.160.81.0/24 AS36184 209.160.83.0/24 AS36184 209.160.84.0/24 AS36184 209.160.86.0/24 AS36184 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.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.151.192.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 216.151.200.0/21 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 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 Aug 30 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Aug 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201308302200.r7UM01F5042367@wattle.apnic.net> BGP Update Report Interval: 22-Aug-13 -to- 29-Aug-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3593 61034 2.5% 256.4 -- FRONTIER-EPIX - Frontier Communications of America, Inc. 2 - AS27738 41907 1.7% 72.8 -- Ecuadortelecom S.A. 3 - AS8402 40274 1.7% 21.7 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS9829 31450 1.3% 23.9 -- BSNL-NIB National Internet Backbone 5 - AS18403 31330 1.3% 53.1 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 6 - AS28573 28643 1.2% 8.7 -- NET Servi?os de Comunica??o S.A. 7 - AS55714 25129 1.0% 97.8 -- APNIC-FIBERLINK-PK Fiberlink Pvt.Ltd 8 - AS2118 22648 0.9% 16.5 -- RELCOM-AS OOO "NPO Relcom" 9 - AS9416 18951 0.8% 321.2 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 10 - AS14287 18878 0.8% 349.6 -- TRIAD-TELECOM - Triad Telecom, Inc. 11 - AS4538 17187 0.7% 31.5 -- ERX-CERNET-BKB China Education and Research Network Center 12 - AS50710 16692 0.7% 69.5 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services 13 - AS4775 16377 0.7% 195.0 -- GLOBE-TELECOM-AS Globe Telecoms 14 - AS9498 15148 0.6% 12.8 -- BBIL-AP BHARTI Airtel Ltd. 15 - AS4755 14230 0.6% 8.1 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 16 - AS647 12307 0.5% 83.7 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 17 - AS10620 12255 0.5% 4.9 -- Telmex Colombia S.A. 18 - AS38654 11671 0.5% 1945.2 -- INES-NETWORK INES Corporation. 19 - AS7545 11591 0.5% 6.8 -- TPG-INTERNET-AP TPG Telecom Limited 20 - AS15003 11434 0.5% 13.7 -- NOBIS-TECH - Nobis Technology Group, LLC TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS37367 3547 0.1% 3547.0 -- CALLKEY 2 - AS6174 7031 0.3% 3515.5 -- SPRINTLINK8 - Sprint 3 - AS22335 3163 0.1% 3163.0 -- MREN - Metropolitan Research and Education Network 4 - AS42334 2667 0.1% 2667.0 -- BBP-AS Broadband Plus s.a.l. 5 - AS53008 10271 0.4% 2567.8 -- Pontal Cabo Ltda 6 - AS37425 4681 0.2% 2340.5 -- Somcable 7 - AS38654 11671 0.5% 1945.2 -- INES-NETWORK INES Corporation. 8 - AS19301 3843 0.2% 1921.5 -- CERIDIAN-TAX - CERIDIAN TAX SERVICE, INC 9 - AS33648 3747 0.2% 1249.0 -- ELEPHANT - ColoFlorida / Elephant Outlook 10 - AS6629 9090 0.4% 909.0 -- NOAA-AS - NOAA 11 - AS14758 4922 0.2% 820.3 -- SJILLC-ASN - Vision Communications 12 - AS43884 776 0.0% 776.0 -- EG-CONSULTING-AS EG Information Consulting Ltd 13 - AS48612 9723 0.4% 694.5 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 14 - AS1880 4834 0.2% 604.2 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 15 - AS44265 2235 0.1% 558.8 -- SMOLTELECOM-NET Smoltelecom Ltd 16 - AS22688 988 0.0% 494.0 -- DOLGENCORP - Dollar General Corporation 17 - AS16608 8133 0.3% 478.4 -- KENTEC - Kentec Communications, Inc. 18 - AS57201 430 0.0% 430.0 -- EDF-AS Estonian Defence Forces 19 - AS28698 1235 0.1% 411.7 -- UUNETZM-AS 20 - AS19406 4395 0.2% 399.5 -- TWRS-MA - Towerstream I, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 199.224.95.0/24 12162 0.5% AS3593 -- FRONTIER-EPIX - Frontier Communications of America, Inc. 2 - 209.74.11.0/24 12160 0.5% AS3593 -- FRONTIER-EPIX - Frontier Communications of America, Inc. 3 - 199.224.82.0/24 12160 0.5% AS3593 -- FRONTIER-EPIX - Frontier Communications of America, Inc. 4 - 205.238.218.0/24 12159 0.5% AS3593 -- FRONTIER-EPIX - Frontier Communications of America, Inc. 5 - 199.224.78.0/24 12158 0.5% AS3593 -- FRONTIER-EPIX - Frontier Communications of America, Inc. 6 - 61.95.239.0/24 11838 0.5% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 7 - 150.39.0.0/16 11666 0.5% AS38654 -- INES-NETWORK INES Corporation. 8 - 177.185.160.0/20 10256 0.4% AS53008 -- Pontal Cabo Ltda 9 - 92.246.207.0/24 9507 0.4% AS48612 -- RTC-ORENBURG-AS CJSC "Comstar-Regions" 10 - 203.118.232.0/21 9399 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 11 - 203.118.224.0/21 9384 0.4% AS9416 -- MULTIMEDIA-AS-AP Hoshin Multimedia Center Inc. 12 - 192.58.232.0/24 8998 0.3% AS6629 -- NOAA-AS - NOAA 13 - 202.154.17.0/24 8768 0.3% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 14 - 194.219.56.0/24 8563 0.3% AS1241 -- FORTHNET-GR Forthnet 17 - 204.29.132.0/23 4827 0.2% AS1880 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 18 - 41.79.196.0/24 4621 0.2% AS37425 -- Somcable 19 - 64.187.64.0/23 4503 0.2% AS16608 -- KENTEC - Kentec Communications, Inc. 20 - 69.38.178.0/24 4385 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 bhuffake at caida.org Fri Aug 30 22:25:57 2013 From: bhuffake at caida.org (Bradley Huffaker) Date: Fri, 30 Aug 2013 15:25:57 -0700 Subject: looking for hostname geographic hint validation In-Reply-To: References: <20130827193357.GP67165@caida.org> <521D0D90.1010204@tabris.net> Message-ID: <20130830222557.GA30655@caida.org> On Fri, Aug 30, 2013 at 02:45:09PM -0700, Matthew Petach wrote: > Hitting 93% accuracy is actually pretty mindblowing > from my perspective, given how random some of > the naming choices are. ^_^; This is the number of times we think we have an answer and it is wrong. It does not include the number of times we failed to find an answer that is there. Although we have plans to search for nonstandard names in the future, we curreently do not look for them and so can't get them wrong. -- the value of a world model is not how accurately it captures reality but how often it leads us to take appropriate action From johnl at iecc.com Fri Aug 30 22:27:36 2013 From: johnl at iecc.com (John Levine) Date: 30 Aug 2013 22:27:36 -0000 Subject: Is the FBI's DNSSEC broken? Message-ID: <20130830222736.23659.qmail@joyce.lan> I don't claim to be a big DNSSEC expert, but this looks just plain wrong to me, and unbound agrees, turning it into a SERVFAIL. Here's a lookup that succeeds, an A record for mail.ic.fbi.gov: $ dig @ns1.fbi.gov mail.ic.fbi.gov a +dnssec ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7222 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 65235 ;; QUESTION SECTION: ;mail.ic.fbi.gov. IN A ;; ANSWER SECTION: mail.ic.fbi.gov. 600 IN A 153.31.119.142 mail.ic.fbi.gov. 600 IN RRSIG A 7 4 600 20131124123847 20130826123847 32497 fbi.gov. dYs+1bPdO+8y3T5ij8qSn0BvTDv7X51wi++HV681rKzlK5SLKrZiGryV ow67iO30CWwztI3d5oCF7/6bEn3NetWq9IajeM19aorIdJMA6tAp1BQI EZMTcCsnInSIn2IRb3V2MXXOBx6r6wMt7ptNfp/Tro89h2K7q+Pgp0O2 WdU= ;; AUTHORITY SECTION: fbi.gov. 600 IN NS ns3.fbi.gov. fbi.gov. 600 IN NS ns5.fbi.gov. fbi.gov. 600 IN NS ns4.fbi.gov. fbi.gov. 600 IN NS ns2.fbi.gov. fbi.gov. 600 IN NS ns1.fbi.gov. fbi.gov. 600 IN NS ns6.fbi.gov. fbi.gov. 600 IN RRSIG NS 7 2 600 20131124123847 20130826123847 32497 fbi.gov. l/AcT+Pmr/5yosWyvP3zbFIJE7f07F+AA8eh1X3qv8ulw9FbC0DhZfSo 1f5ctD6DIb613ButzKG01PdMzIknMroraOyGyRcAq27qYXzKRE0cTqhv UWz15jLa7N7YKYccR8Hmt6GY1DJitY41EwQP7Z2Fpac9yPTRnybc4mTS 4eY= Here's a query for the same name, but for AAAA which it doesn't have: $ dig @ns1.fbi.gov mail.ic.fbi.gov aaaa +dnssec ; <<>> DiG 9.8.3-P4 <<>> @ns1.fbi.gov mail.ic.fbi.gov aaaa +dnssec ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41056 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 65235 ;; QUESTION SECTION: ;mail.ic.fbi.gov. IN AAAA ;; AUTHORITY SECTION: fbi.gov. 600 IN SOA ns1.fbi.gov. dns-admin.fbi.gov. 2013082601 7200 3600 2592000 43200 95RIPFTKTJC9I7J8HDAIA7CM6L279FSR.fbi.gov. 43200 IN NSEC3 1 0 10 BBAB 97S2G907NEFOJ79P721E4FEQ9LR3IT1S A RRSIG fbi.gov. 600 IN RRSIG SOA 7 2 600 20131124123847 20130826123847 32497 fbi.gov. QgsdhUT7AHic8tJv39br+994eoyJ4c8/SuQr35dRudceE/bYyZV26IPI 4qnR8Cy35WoepW12bhhhY0Ug26Qy81KWcWHYPw0Wa7g5Ig8Pw27l8gCV J7NDY6O5jTb4MMc9THTPKEvXjeX/YE4060HrbJXo1U93qhdILkGTvno7 3hA= Shouldn't there be some more stuff there in the authority section, like an NSEC3 and RRSIG for mail.ic.fbi.gov? Am I missing something, or is it broken? The server says it's from Ultradns. R's, John From rvandolson at esri.com Fri Aug 30 22:35:11 2013 From: rvandolson at esri.com (Ray Van Dolson) Date: Fri, 30 Aug 2013 15:35:11 -0700 Subject: Is the FBI's DNSSEC broken? In-Reply-To: <20130830222736.23659.qmail@joyce.lan> References: <20130830222736.23659.qmail@joyce.lan> Message-ID: <20130830223510.GA10878@esri.com> On Fri, Aug 30, 2013 at 10:27:36PM +0000, John Levine wrote: > I don't claim to be a big DNSSEC expert, but this looks just plain > wrong to me, and unbound agrees, turning it into a SERVFAIL. > > Here's a lookup that succeeds, an A record for mail.ic.fbi.gov: > > $ dig @ns1.fbi.gov mail.ic.fbi.gov a +dnssec > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7222 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 65235 > ;; QUESTION SECTION: > ;mail.ic.fbi.gov. IN A > > ;; ANSWER SECTION: > mail.ic.fbi.gov. 600 IN A 153.31.119.142 > mail.ic.fbi.gov. 600 IN RRSIG A 7 4 600 20131124123847 20130826123847 32497 fbi.gov. dYs+1bPdO+8y3T5ij8qSn0BvTDv7X51wi++HV681rKzlK5SLKrZiGryV ow67iO30CWwztI3d5oCF7/6bEn3NetWq9IajeM19aorIdJMA6tAp1BQI EZMTcCsnInSIn2IRb3V2MXXOBx6r6wMt7ptNfp/Tro89h2K7q+Pgp0O2 WdU= > > ;; AUTHORITY SECTION: > fbi.gov. 600 IN NS ns3.fbi.gov. > fbi.gov. 600 IN NS ns5.fbi.gov. > fbi.gov. 600 IN NS ns4.fbi.gov. > fbi.gov. 600 IN NS ns2.fbi.gov. > fbi.gov. 600 IN NS ns1.fbi.gov. > fbi.gov. 600 IN NS ns6.fbi.gov. > fbi.gov. 600 IN RRSIG NS 7 2 600 20131124123847 20130826123847 32497 fbi.gov. l/AcT+Pmr/5yosWyvP3zbFIJE7f07F+AA8eh1X3qv8ulw9FbC0DhZfSo 1f5ctD6DIb613ButzKG01PdMzIknMroraOyGyRcAq27qYXzKRE0cTqhv UWz15jLa7N7YKYccR8Hmt6GY1DJitY41EwQP7Z2Fpac9yPTRnybc4mTS 4eY= > > Here's a query for the same name, but for AAAA which it doesn't have: > > $ dig @ns1.fbi.gov mail.ic.fbi.gov aaaa +dnssec > > ; <<>> DiG 9.8.3-P4 <<>> @ns1.fbi.gov mail.ic.fbi.gov aaaa +dnssec > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41056 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 65235 > ;; QUESTION SECTION: > ;mail.ic.fbi.gov. IN AAAA > > ;; AUTHORITY SECTION: > fbi.gov. 600 IN SOA ns1.fbi.gov. dns-admin.fbi.gov. 2013082601 7200 3600 2592000 43200 > 95RIPFTKTJC9I7J8HDAIA7CM6L279FSR.fbi.gov. 43200 IN NSEC3 1 0 10 BBAB 97S2G907NEFOJ79P721E4FEQ9LR3IT1S A RRSIG > fbi.gov. 600 IN RRSIG SOA 7 2 600 20131124123847 20130826123847 32497 fbi.gov. QgsdhUT7AHic8tJv39br+994eoyJ4c8/SuQr35dRudceE/bYyZV26IPI 4qnR8Cy35WoepW12bhhhY0Ug26Qy81KWcWHYPw0Wa7g5Ig8Pw27l8gCV J7NDY6O5jTb4MMc9THTPKEvXjeX/YE4060HrbJXo1U93qhdILkGTvno7 3hA= > > Shouldn't there be some more stuff there in the authority section, > like an NSEC3 and RRSIG for mail.ic.fbi.gov? > > Am I missing something, or is it broken? The server says it's from > Ultradns. > > R's, > John Hi John; I don't think you're alone on this! Ref this thread (an issue we ran into with accepting mail from ic.fbi.gov due to DNSSEC validation failure) from July[1]. Have done my best to get someone's attention to fix the issue, but so far no joy. Ray [1] https://lists.isc.org/pipermail/bind-users/2013-July/091140.html From marka at isc.org Fri Aug 30 23:02:49 2013 From: marka at isc.org (Mark Andrews) Date: Sat, 31 Aug 2013 09:02:49 +1000 Subject: Is the FBI's DNSSEC broken? In-Reply-To: Your message of "Fri, 30 Aug 2013 15:35:11 -0700." <20130830223510.GA10878@esri.com> References: <20130830222736.23659.qmail@joyce.lan> <20130830223510.GA10878@esri.com> Message-ID: <20130830230249.4546C390797D@drugs.dv.isc.org> In message <20130830223510.GA10878 at esri.com>, Ray Van Dolson writes: > On Fri, Aug 30, 2013 at 10:27:36PM +0000, John Levine wrote: > > I don't claim to be a big DNSSEC expert, but this looks just plain > > wrong to me, and unbound agrees, turning it into a SERVFAIL. > > > > Here's a lookup that succeeds, an A record for mail.ic.fbi.gov: > > > > $ dig @ns1.fbi.gov mail.ic.fbi.gov a +dnssec > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7222 > > ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 1 > > ;; WARNING: recursion requested but not available > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags: do; udp: 65235 > > ;; QUESTION SECTION: > > ;mail.ic.fbi.gov. IN A > > > > ;; ANSWER SECTION: > > mail.ic.fbi.gov. 600 IN A 153.31.119.142 > > mail.ic.fbi.gov. 600 IN RRSIG A 7 4 600 20131124123847 201308 > 26123847 32497 fbi.gov. dYs+1bPdO+8y3T5ij8qSn0BvTDv7X51wi++HV681rKzlK5SLKrZiG > ryV ow67iO30CWwztI3d5oCF7/6bEn3NetWq9IajeM19aorIdJMA6tAp1BQI EZMTcCsnInSIn2IR > b3V2MXXOBx6r6wMt7ptNfp/Tro89h2K7q+Pgp0O2 WdU= > > > > ;; AUTHORITY SECTION: > > fbi.gov. 600 IN NS ns3.fbi.gov. > > fbi.gov. 600 IN NS ns5.fbi.gov. > > fbi.gov. 600 IN NS ns4.fbi.gov. > > fbi.gov. 600 IN NS ns2.fbi.gov. > > fbi.gov. 600 IN NS ns1.fbi.gov. > > fbi.gov. 600 IN NS ns6.fbi.gov. > > fbi.gov. 600 IN RRSIG NS 7 2 600 20131124123847 20130 > 826123847 32497 fbi.gov. l/AcT+Pmr/5yosWyvP3zbFIJE7f07F+AA8eh1X3qv8ulw9FbC0Dh > ZfSo 1f5ctD6DIb613ButzKG01PdMzIknMroraOyGyRcAq27qYXzKRE0cTqhv UWz15jLa7N7YKYc > cR8Hmt6GY1DJitY41EwQP7Z2Fpac9yPTRnybc4mTS 4eY= > > > > Here's a query for the same name, but for AAAA which it doesn't have: > > > > $ dig @ns1.fbi.gov mail.ic.fbi.gov aaaa +dnssec > > > > ; <<>> DiG 9.8.3-P4 <<>> @ns1.fbi.gov mail.ic.fbi.gov aaaa +dnssec > > ; (2 servers found) > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41056 > > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1 > > ;; WARNING: recursion requested but not available > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags: do; udp: 65235 > > ;; QUESTION SECTION: > > ;mail.ic.fbi.gov. IN AAAA > > > > ;; AUTHORITY SECTION: > > fbi.gov. 600 IN SOA ns1.fbi.gov. dns-admin.fbi.gov. > 2013082601 7200 3600 2592000 43200 > > 95RIPFTKTJC9I7J8HDAIA7CM6L279FSR.fbi.gov. 43200 IN NSEC3 1 0 10 BBAB 97 > S2G907NEFOJ79P721E4FEQ9LR3IT1S A RRSIG > > fbi.gov. 600 IN RRSIG SOA 7 2 600 20131124123847 2013 > 0826123847 32497 fbi.gov. QgsdhUT7AHic8tJv39br+994eoyJ4c8/SuQr35dRudceE/bYyZV > 26IPI 4qnR8Cy35WoepW12bhhhY0Ug26Qy81KWcWHYPw0Wa7g5Ig8Pw27l8gCV J7NDY6O5jTb4MM > c9THTPKEvXjeX/YE4060HrbJXo1U93qhdILkGTvno7 3hA= > > > > Shouldn't there be some more stuff there in the authority section, > > like an NSEC3 and RRSIG for mail.ic.fbi.gov? The NSEC3 is there and it is correct. What is missing is the signature for the NSEC3. % nsec3hash BBAB 1 10 mail.ic.fbi.gov 95RIPFTKTJC9I7J8HDAIA7CM6L279FSR (salt=BBAB, hash=1, iterations=10) % Mark > > Am I missing something, or is it broken? The server says it's from > > Ultradns. > > > > R's, > > John > > Hi John; > > I don't think you're alone on this! Ref this thread (an issue we ran > into with accepting mail from ic.fbi.gov due to DNSSEC validation > failure) from July[1]. > > Have done my best to get someone's attention to fix the issue, but so > far no joy. > > Ray > > [1] https://lists.isc.org/pipermail/bind-users/2013-July/091140.html > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mpetach at netflight.com Fri Aug 30 23:09:21 2013 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 30 Aug 2013 16:09:21 -0700 Subject: looking for hostname geographic hint validation In-Reply-To: <20130830222557.GA30655@caida.org> References: <20130827193357.GP67165@caida.org> <521D0D90.1010204@tabris.net> <20130830222557.GA30655@caida.org> Message-ID: On Fri, Aug 30, 2013 at 3:25 PM, Bradley Huffaker wrote: > On Fri, Aug 30, 2013 at 02:45:09PM -0700, Matthew Petach wrote: > > Hitting 93% accuracy is actually pretty mindblowing > > from my perspective, given how random some of > > the naming choices are. ^_^; > > This is the number of times we think we have an answer and it is wrong. > Ah, so that would include cases like thinking CH1 and CHE might be nearby, rather than halfway around the planet, but wouldn't include things like MUD, where there wouldn't even be a guess at an answer. > It does not include the number of times we failed to find an answer that > is there. Although we have plans to search for nonstandard names in the > future, we currently do not look for them and so can't get them wrong. > Thanks for the clarification around the number--makes much more sense now. :) Matt From saku at ytti.fi Sat Aug 31 06:26:55 2013 From: saku at ytti.fi (Saku Ytti) Date: Sat, 31 Aug 2013 09:26:55 +0300 Subject: subrate SFP? In-Reply-To: References: <201308300856.JAA29671@sunf10.rd.bbc.co.uk> Message-ID: <20130831062655.GA29105@pob.ytti.fi> On (2013-08-30 11:30 -0400), Tim Durack wrote: > It would be interesting to have some other smart SFP options too, like > macsec for example... Or HQoS in a SFP, for that one port which kills your ability to get away with cheap L3-switch style box :) But tbh the moment you'll need control-plane in the SFP, it becomes complicated for me to deploy, as then I need to figure out configuration backups, provisioning support etc. -- ++ytti From emile.aben at ripe.net Sat Aug 31 09:02:45 2013 From: emile.aben at ripe.net (Emile Aben) Date: Sat, 31 Aug 2013 11:02:45 +0200 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <5220ADF7.6030204@NLnetLabs.nl> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <20130827065522.GA26981@pob.ytti.fi> <521C6725.8070508@ripe.net> <20130827112436.GA29165@pob.ytti.fi> <521F0530.2000105@NLnetLabs.nl> <5220ADF7.6030204@NLnetLabs.nl> Message-ID: <5221B135.9010707@ripe.net> On 30/08/2013 16:36, Benno Overeinder wrote: > On 08/30/2013 01:58 PM, Randy Bush wrote: >>> In a study using the RIPE Atlas probes, we have used a heuristic to >>> figure out where the fragments where dropped. And from the Atlas >>> probes where IP fragments did not arrive, there is a high likelihood >>> the problem is with the last hop to the Atlas probe. >> >> i wonder if this is correlated with the high number of probes being >> behind nats. > > That would be a viable explanation, although we have not tried to > fingerprint the probes to figure out if this was true. > > If we will rerun the experiments in the future, we should spent more > effort into identifying the router/middlebox that is giving the IP > fragmentation problems (drops or blocking PMTUD ICMP). Maybe this provides a bit of insight: >From a test last week from all RIPE Atlas probes to a single "known good" MTU 1500 host I compared probes where I had both a ping test with ipv4.len 1020 and ipv4.len 1502. behind NAT probes: 12% 1020 bytes ping worked while 1502 failed non-NATted probes: 6% "" hth, Emile Aben RIPE NCC From randy at psg.com Sat Aug 31 11:13:46 2013 From: randy at psg.com (Randy Bush) Date: Sat, 31 Aug 2013 20:13:46 +0900 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <5221B135.9010707@ripe.net> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <20130827065522.GA26981@pob.ytti.fi> <521C6725.8070508@ripe.net> <20130827112436.GA29165@pob.ytti.fi> <521F0530.2000105@NLnetLabs.nl> <5220ADF7.6030204@NLnetLabs.nl> <5221B135.9010707@ripe.net> Message-ID: could you please test with ipv6? thanks! randy From randy at psg.com Sat Aug 31 11:09:18 2013 From: randy at psg.com (Randy Bush) Date: Sat, 31 Aug 2013 20:09:18 +0900 Subject: IP Fragmentation - Not reliable over the Internet? In-Reply-To: <5221B135.9010707@ripe.net> References: <6e53114d968f40f097a83640d90f9acf@BN1PR03MB171.namprd03.prod.outlook.com> <20130827065522.GA26981@pob.ytti.fi> <521C6725.8070508@ripe.net> <20130827112436.GA29165@pob.ytti.fi> <521F0530.2000105@NLnetLabs.nl> <5220ADF7.6030204@NLnetLabs.nl> <5221B135.9010707@ripe.net> Message-ID: >>> i wonder if this is correlated with the high number of probes being >>> behind nats. > > Maybe this provides a bit of insight: > From a test last week from all RIPE Atlas probes to a single "known > good" MTU 1500 host I compared probes where I had both a ping test with > ipv4.len 1020 and ipv4.len 1502. > behind NAT probes: 12% 1020 bytes ping worked while 1502 failed > non-NATted probes: 6% "" this needs publication on your adventure game of a web site, please. it will seriously 'inform' some discussion going back and forth on ietf lists. randy From mysidia at gmail.com Sat Aug 31 12:47:24 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 31 Aug 2013 07:47:24 -0500 Subject: subrate SFP? In-Reply-To: <465966A5F5B867419F604CD3E604C1E54D6DD033@PRA-DCA-MAIL.pra.ray.com> References: <20130829130830.GA3850@pob.ytti.fi> <521FB143.5000206@bogus.com> <465966A5F5B867419F604CD3E604C1E54D6DD033@PRA-DCA-MAIL.pra.ray.com> Message-ID: On Fri, Aug 30, 2013 at 6:42 AM, Jamie Bowden wrote: > > From: Saku Ytti [mailto:saku at ytti.fi] > Considering that Dell and HP at least are shipping brand new hardware with > IPMI/BMC/iLO/whatever management ports that can only speak 100mbit when > every other Ethernet interface in the box at least gigabit, having a useful > way to talk to that port without having to keep separate switching hardware > around would be nice. I'm not holding my breath, but you know, along with > a pony, this would be nice. > Eh? That may have been the case a few years ago, but HP ILO4 and iDRAC7 specifically list 10/100/1000 even when using in dedicated port mode. And even in prior versions, you could have the port linking up at 1Gbps, by operating the management in Shared port mode (Sharing the management with the server's Eth0). I expect over time: support for linking up at 10/100 will get rarer and much more expensive. The niche status a 10/100 media converter as an SFP would have if produced is likely to mean it would retail at $2000+ per port device. It probably just makes more sense to go find an old obsolete top of rack switch, like a Cat3750 to get the small fraction of legacy copper ports required for out of band network and server management, which: by the way, should be part of a separate switching infrastructure anyways, to increase the chance it stays operational and useful for troubleshooting, in the event the production network experiences outage or has other issues requiring diagnosis. > Jamie -- -JH From charles-lists at knownelement.com Sat Aug 31 17:13:20 2013 From: charles-lists at knownelement.com (Charles N Wyble) Date: Sat, 31 Aug 2013 12:13:20 -0500 Subject: subrate SFP? In-Reply-To: References: <20130829130830.GA3850@pob.ytti.fi> <521FB143.5000206@bogus.com> <465966A5F5B867419F604CD3E604C1E54D6DD033@PRA-DCA-MAIL.pra.ray.com> Message-ID: On hp proliant gen8 servers with management and ilo on same port, with the server off the ports show up as 100mbps. Jimmy Hess wrote: >On Fri, Aug 30, 2013 at 6:42 AM, Jamie Bowden wrote: > >> > From: Saku Ytti [mailto:saku at ytti.fi] >> Considering that Dell and HP at least are shipping brand new hardware >with >> IPMI/BMC/iLO/whatever management ports that can only speak 100mbit >when >> every other Ethernet interface in the box at least gigabit, having a >useful >> way to talk to that port without having to keep separate switching >hardware >> around would be nice. I'm not holding my breath, but you know, along >with >> a pony, this would be nice. >> > >Eh? That may have been the case a few years ago, but HP ILO4 and >iDRAC7 specifically list 10/100/1000 even when using in dedicated >port >mode. > >And even in prior versions, you could have the port linking up at >1Gbps, >by operating the management in Shared port mode (Sharing the >management >with the server's Eth0). > >I expect over time: support for linking up at 10/100 will get rarer >and >much more expensive. > > >The niche status a 10/100 media converter as an SFP would have if >produced > is likely to mean it would retail at $2000+ per port device. > > >It probably just makes more sense to go find an old obsolete top of >rack >switch, like a Cat3750 to get the small fraction of legacy copper >ports >required for out of band network and server management, which: by the >way, should be part of a separate switching infrastructure anyways, >to >increase the chance it stays operational and useful for >troubleshooting, in >the event the production network experiences outage or has other issues >requiring diagnosis. > > > >> Jamie > >-- >-JH -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From joelja at bogus.com Sat Aug 31 19:38:34 2013 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 31 Aug 2013 12:38:34 -0700 Subject: subrate SFP? In-Reply-To: References: <20130829130830.GA3850@pob.ytti.fi> <521FB143.5000206@bogus.com> <465966A5F5B867419F604CD3E604C1E54D6DD033@PRA-DCA-MAIL.pra.ray.com> Message-ID: WOL uses 100Mb/s, the phy draws less that way. Sent from my iPhone On Aug 31, 2013, at 10:13, Charles N Wyble wrote: > On hp proliant gen8 servers with management and ilo on same port, with the server off the ports show up as 100mbps. > > Jimmy Hess wrote: >> On Fri, Aug 30, 2013 at 6:42 AM, Jamie Bowden wrote: >> >>>> From: Saku Ytti [mailto:saku at ytti.fi] >>> Considering that Dell and HP at least are shipping brand new hardware >> with >>> IPMI/BMC/iLO/whatever management ports that can only speak 100mbit >> when >>> every other Ethernet interface in the box at least gigabit, having a >> useful >>> way to talk to that port without having to keep separate switching >> hardware >>> around would be nice. I'm not holding my breath, but you know, along >> with >>> a pony, this would be nice. >> >> Eh? That may have been the case a few years ago, but HP ILO4 and >> iDRAC7 specifically list 10/100/1000 even when using in dedicated >> port >> mode. >> >> And even in prior versions, you could have the port linking up at >> 1Gbps, >> by operating the management in Shared port mode (Sharing the >> management >> with the server's Eth0). >> >> I expect over time: support for linking up at 10/100 will get rarer >> and >> much more expensive. >> >> >> The niche status a 10/100 media converter as an SFP would have if >> produced >> is likely to mean it would retail at $2000+ per port device. >> >> >> It probably just makes more sense to go find an old obsolete top of >> rack >> switch, like a Cat3750 to get the small fraction of legacy copper >> ports >> required for out of band network and server management, which: by the >> way, should be part of a separate switching infrastructure anyways, >> to >> increase the chance it stays operational and useful for >> troubleshooting, in >> the event the production network experiences outage or has other issues >> requiring diagnosis. >> >> >> >>> Jamie >> >> -- >> -JH > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > From babydr at baby-dragons.com Sat Aug 31 20:05:00 2013 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Sat, 31 Aug 2013 12:05:00 -0800 (AKDT) Subject: couldn't get address for 'w.au': no more , Message-ID: Hello All , Are the roots for .au lost in the haze someplace ? During my attempts to reach http://www.coker.com.au/bonnie++/ I tried a 'dig www.coker.com.au +trace' Did some roots change recently ? Tia, JimL Which yielded ... ; <<>> DiG 9.9.3-P2 <<>> www.coker.com.au +trace ;; global options: +cmd . 7424 IN NS i.root-servers.net. . 7424 IN NS m.root-servers.net. . 7424 IN NS k.root-servers.net. . 7424 IN NS a.root-servers.net. . 7424 IN NS h.root-servers.net. . 7424 IN NS d.root-servers.net. . 7424 IN NS c.root-servers.net. . 7424 IN NS l.root-servers.net. . 7424 IN NS e.root-servers.net. . 7424 IN NS g.root-servers.net. . 7424 IN NS j.root-servers.net. . 7424 IN NS b.root-servers.net. . 7424 IN NS f.root-servers.net. . 517152 IN RRSIG NS 8 0 518400 20130907000000 20130830230000 49656 . lWj707jP5hxvgq8BwU5+IVeyuE/p3wcEmuQRfzuneoFClny1L/xyaT53 IkhG57jFzRPsXbuvOM6J/9tZzkbyuN20b5T0QLuxJVQsZT20pzWSIZ54 MVcVd2HTRtq+Gr0OetDI3THRkgK06IVH0yyKrPqDCQI/iHbc+iljg21f lmc= ;; Received 857 bytes from 50.0.96.199#53(50.0.96.199) in 195 ms au. 172800 IN NS z.au. au. 172800 IN NS y.au. au. 172800 IN NS x.au. au. 172800 IN NS w.au. au. 172800 IN NS v.au. au. 172800 IN NS u.au. au. 172800 IN NS s.au. au. 172800 IN NS r.au. au. 172800 IN NS b.au. au. 172800 IN NS a.au. au. 86400 IN NSEC aw. NS RRSIG NSEC au. 86400 IN RRSIG NSEC 8 1 86400 20130907000000 20130830230000 49656 . LZo++i1OBOYRDncdZe8aAuO1TaWgCWVXVc/aquFb0oT0LBNAbkPljT55 dQV8jlrsZyZ0QbAm09P29wuq1UBuca6a1YX72DZrvfDeqX+1oXaAlEPd ZfFl2eQsao39AZPlRVfVVw18am5VX8V4K/VmYgBeq1lmV52OVqYz2UVB ygQ= dig: couldn't get address for 'z.au': no more -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 3237 Holden Road | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | +------------------------------------------------------------------+ From nick at pelagiris.org Sat Aug 31 20:48:21 2013 From: nick at pelagiris.org (Nick B) Date: Sat, 31 Aug 2013 16:48:21 -0400 Subject: subrate SFP? In-Reply-To: References: <20130829130830.GA3850@pob.ytti.fi> <521FB143.5000206@bogus.com> <465966A5F5B867419F604CD3E604C1E54D6DD033@PRA-DCA-MAIL.pra.ray.com> Message-ID: Ah, I needed *another* reason to murder WOL in it's sleep. Thanks! Nick On Sat, Aug 31, 2013 at 3:38 PM, Joel Jaeggli wrote: > WOL uses 100Mb/s, the phy draws less that way. > > Sent from my iPhone > > On Aug 31, 2013, at 10:13, Charles N Wyble > wrote: > > > On hp proliant gen8 servers with management and ilo on same port, with > the server off the ports show up as 100mbps. > > > > Jimmy Hess wrote: > >> On Fri, Aug 30, 2013 at 6:42 AM, Jamie Bowden wrote: > >> > >>>> From: Saku Ytti [mailto:saku at ytti.fi] > >>> Considering that Dell and HP at least are shipping brand new hardware > >> with > >>> IPMI/BMC/iLO/whatever management ports that can only speak 100mbit > >> when > >>> every other Ethernet interface in the box at least gigabit, having a > >> useful > >>> way to talk to that port without having to keep separate switching > >> hardware > >>> around would be nice. I'm not holding my breath, but you know, along > >> with > >>> a pony, this would be nice. > >> > >> Eh? That may have been the case a few years ago, but HP ILO4 and > >> iDRAC7 specifically list 10/100/1000 even when using in dedicated > >> port > >> mode. > >> > >> And even in prior versions, you could have the port linking up at > >> 1Gbps, > >> by operating the management in Shared port mode (Sharing the > >> management > >> with the server's Eth0). > >> > >> I expect over time: support for linking up at 10/100 will get rarer > >> and > >> much more expensive. > >> > >> > >> The niche status a 10/100 media converter as an SFP would have if > >> produced > >> is likely to mean it would retail at $2000+ per port device. > >> > >> > >> It probably just makes more sense to go find an old obsolete top of > >> rack > >> switch, like a Cat3750 to get the small fraction of legacy copper > >> ports > >> required for out of band network and server management, which: by the > >> way, should be part of a separate switching infrastructure anyways, > >> to > >> increase the chance it stays operational and useful for > >> troubleshooting, in > >> the event the production network experiences outage or has other issues > >> requiring diagnosis. > >> > >> > >> > >>> Jamie > >> > >> -- > >> -JH > > > > -- > > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > > > From szlists at szarka.org Sat Aug 31 20:51:36 2013 From: szlists at szarka.org (Rob Szarka) Date: Sat, 31 Aug 2013 16:51:36 -0400 Subject: couldn't get address for 'w.au': no more , In-Reply-To: References: Message-ID: <52225758.1010904@szarka.org> On 8/31/2013 4:05 PM, Mr. James W. Laferriere wrote: > Hello All , Are the roots for .au lost in the haze someplace ? FWIW, I'm seeing records for both w.au and z.au from here: w.au. 172800 IN A 37.209.192.5 ;; Received 38 bytes from 2001:dcd:4::5#53(2001:dcd:4::5) in 108 ms z.au. 172800 IN A 37.209.198.5 ;; Received 38 bytes from 2001:dcd:4::5#53(2001:dcd:4::5) in 107 ms From nanog at jima.us Sat Aug 31 21:58:23 2013 From: nanog at jima.us (Jima) Date: Sat, 31 Aug 2013 15:58:23 -0600 Subject: subrate SFP? In-Reply-To: References: <20130829130830.GA3850@pob.ytti.fi> <521FB143.5000206@bogus.com> <465966A5F5B867419F604CD3E604C1E54D6DD033@PRA-DCA-MAIL.pra.ray.com> Message-ID: <522266FF.70402@jima.us> Unless I missed something, iLO is always on when the machine has power; as such, WOL shouldn't be coming into play on reasonably modern HP servers. (That said, the power draw is likely still the reason, although I can't readily confirm Charles' observation on my only rackmount Gen8.) Jima On 2013-08-31 13:38, Joel Jaeggli wrote: > WOL uses 100Mb/s, the phy draws less that way. > > Sent from my iPhone > > On Aug 31, 2013, at 10:13, Charles N Wyble wrote: > >> On hp proliant gen8 servers with management and ilo on same port, with the server off the ports show up as 100mbps. >> >> Jimmy Hess wrote: >>> On Fri, Aug 30, 2013 at 6:42 AM, Jamie Bowden wrote: >>> >>>>> From: Saku Ytti [mailto:saku at ytti.fi] >>>> Considering that Dell and HP at least are shipping brand new hardware >>> with >>>> IPMI/BMC/iLO/whatever management ports that can only speak 100mbit >>> when >>>> every other Ethernet interface in the box at least gigabit, having a >>> useful >>>> way to talk to that port without having to keep separate switching >>> hardware >>>> around would be nice. I'm not holding my breath, but you know, along >>> with >>>> a pony, this would be nice. >>> >>> Eh? That may have been the case a few years ago, but HP ILO4 and >>> iDRAC7 specifically list 10/100/1000 even when using in dedicated >>> port >>> mode. >>> >>> And even in prior versions, you could have the port linking up at >>> 1Gbps, >>> by operating the management in Shared port mode (Sharing the >>> management >>> with the server's Eth0). >>> >>> I expect over time: support for linking up at 10/100 will get rarer >>> and >>> much more expensive. >>> >>> >>> The niche status a 10/100 media converter as an SFP would have if >>> produced >>> is likely to mean it would retail at $2000+ per port device. >>> >>> >>> It probably just makes more sense to go find an old obsolete top of >>> rack >>> switch, like a Cat3750 to get the small fraction of legacy copper >>> ports >>> required for out of band network and server management, which: by the >>> way, should be part of a separate switching infrastructure anyways, >>> to >>> increase the chance it stays operational and useful for >>> troubleshooting, in >>> the event the production network experiences outage or has other issues >>> requiring diagnosis. >>> >>> >>> >>>> Jamie >>> >>> -- >>> -JH >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> > From ben+nanog at list-subs.com Wed Aug 28 15:07:44 2013 From: ben+nanog at list-subs.com (Ben) Date: Wed, 28 Aug 2013 16:07:44 +0100 Subject: looking for hostname geographic hint validation In-Reply-To: <20130827193357.GP67165@caida.org> References: <20130827193357.GP67165@caida.org> Message-ID: <521E1240.2060303@list-subs.com> Dear Bradley, So basically you're asking others to do your homework for you ? The only useful purpose your list serves is to demonstrate why people shouldn't try to build fancy algorithms that rely on an entirely unreliable datasource. All you end up with are hacked together algorithms that contain a whole load of assumptions and will be obsolete by the time you release version 1.0 because people will have changed their naming conventions a million times. For example, picking one example from your list .... ([^a-z]+[a-z]+\d*){3}.ic.ac.uk ic.ac.uk = Imperial College. A well known and respected ivory towers institution in the UK. The vast majority of their campus sites are located in London and only one or to outside London in South East England. It is therefore very unlikely they'll be using IATA code, infact, last time I checked they were using conventions such as hostname.doc.ic.ac.uk, hostname.ch.ic.ac.uk. Far from being IATA codes, the intermediate subdomains actually refer to departments (DepartmentOfComputing and CHemistry in the two I quoted). Sorry to rain on your parade, but someone had to say it. From stenrulz at gmail.com Sat Aug 31 11:44:57 2013 From: stenrulz at gmail.com (sten rulz) Date: Sat, 31 Aug 2013 21:44:57 +1000 Subject: 10G Router Message-ID: Hello, I am currently looking into a 10G router that will support the below requirements and hopefully not be too costly. Do you know of any models to stay away due to issues or that you would recommend? - 4x+ 10GBE ports - BGPv4/v6 - Small number of RU preferred - Support for 2-4 full routing tables - 2 10GBE ports down to switches - 2 10GBE for up-streams but would prefer more to support IXs. I have been looking into a few options including; Brocade CER 2024C-4X, Broacde MLXE-4 with 10Gx8-X, Juniper MX80, Cumulus Linux, etc. Some quick notes: - 4x 10GBE ports is a bit low for the Brocade CER - Not sure how the CER will handle a few routing tables and 10G+ traffic - The MLX and MX80 is very high costs from what I have seen - The MX80 has 4x 10GBE ports but at less allows an extra 4 via MIC - Decent number of real use case reviews for the MX80 - Possibly use cumulus networks if there are any systems that meet the requirements Thanks Steven