From dschmid at tlsn.net Sun Feb 1 03:25:23 2015 From: dschmid at tlsn.net (David Schmid) Date: Sun, 1 Feb 2015 03:25:23 +0000 Subject: Indiana Dark Fiber In-Reply-To: <11088525.6972.1422721460950.JavaMail.mhammett@ThunderFuck> References: <28396930.6942.1422720983076.JavaMail.mhammett@ThunderFuck> <11088525.6972.1422721460950.JavaMail.mhammett@ThunderFuck> Message-ID: Mike, IFN is a rural service provider in Indiana that may have dark fiber or optical wave service where you need it. They are a member of a larger coop, Indatel Group. IG has a national fiber presence comprised of state to state telecom coops. http://ifncom.co/network/state-fiber-map/ http://www.indatel.com/index.html David Schmid Operations Manager Texas Lone Star Network 512-784-0824 dschmid at tlsn.net Www.tlsn.net On 1/31/15, 10:25 AM, "Mike Hammett" wrote: >Any recommendations for dark fiber between Indianapolis and Fort Wayne? I >see a few routes, but that doesn't mean they actually sell dark fiber. >The company that we've partnered with asked a couple companies (Zayo, IFN >and one of the Time Warners) and came up short. Seems odd because Zayo >lists dark fiber routes to within 1.5 miles of the Fort Wayne location, >but figured I'd look to see what companies I was missing that actually >did dark fiber. > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > > > From bohn at adelphi.edu Sun Feb 1 14:41:52 2015 From: bohn at adelphi.edu (Dennis Bohn) Date: Sun, 1 Feb 2015 09:41:52 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: Message-ID: We are substantially larger and use Aruba, but I am wondering why no one has mentioned Meraki (now cisco-meraki). We tried one of their give-away aps and it seemed fine, with the 'cloud management.' I am not advocating Meraki, just curious. best, Dennis Bohn Manager of Network and Systems Adelphi University bohn at adelphi.edu 5168773327 On Fri, Jan 30, 2015 at 6:28 PM, Eric C. Miller wrote: > +1 Xirrus, especially for the multi radio arrays. Crowded common areas > benefit from sector antennas attached to individual radios. Also, there XMS > server is really useful for managing a large cluster. Ubiquiti UniFi is > good for smaller installations, but I wouldn't trust them for enterprise > level reliability. > > > > Eric Miller, CCNP > Network Engineering Consultant > (407) 257-5115 > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Lyon > Sent: Thursday, January 29, 2015 12:17 AM > To: Manuel Marín > Cc: NANOG > Subject: Re: Recommended wireless AP for 400 users office > > Check out Xirrus > On Jan 28, 2015 9:08 PM, "Manuel Marín" wrote: > > > Dear nanog community > > > > I was wondering if you can recommend or share your experience with APs > > that you can use in locations that have 300-500 users. I friend > > recommended me Ruckus Wireless, it would be great if you can share > > your experience with Ruckus or with a similar vendor. My experience > > with ubiquity for this type of requirement was not that good. > > > > Thank you and have a great day > > > From baldur.norddahl at gmail.com Sun Feb 1 14:44:21 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 1 Feb 2015 15:44:21 +0100 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: <20150130212335.568df5a0@envy.fud.no> References: <20150130174453.485e9105@envy.fud.no> <20150130194628.08ba77a2@envy.fud.no> <20150130212335.568df5a0@envy.fud.no> Message-ID: Den 30/01/2015 21.23 skrev "Tore Anderson" : > Kabel Deutschland, T-Mobile USA, and Facebook are examples of companies > who have already or are in the process of moving their network > infrastructure to IPv6-only. Without going bust. Assuming larger service providers are using MPLS in some form, is this even possible? How long will we be forced to have an IPv4 backbone due to MPLS? From nanog at ics-il.net Sun Feb 1 14:54:33 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 1 Feb 2015 08:54:33 -0600 (CST) Subject: Recommended wireless AP for 400 users office In-Reply-To: Message-ID: <24849061.7731.1422802496240.JavaMail.mhammett@ThunderFuck> I try to avoid anything that Cisco has touched. Also not a fan of their stop paying our recurring fee and the device becomes a brick policy. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Dennis Bohn" To: "Eric C. Miller" Cc: "NANOG" Sent: Sunday, February 1, 2015 8:41:52 AM Subject: Re: Recommended wireless AP for 400 users office We are substantially larger and use Aruba, but I am wondering why no one has mentioned Meraki (now cisco-meraki). We tried one of their give-away aps and it seemed fine, with the 'cloud management.' I am not advocating Meraki, just curious. best, Dennis Bohn Manager of Network and Systems Adelphi University bohn at adelphi.edu 5168773327 On Fri, Jan 30, 2015 at 6:28 PM, Eric C. Miller wrote: > +1 Xirrus, especially for the multi radio arrays. Crowded common areas > benefit from sector antennas attached to individual radios. Also, there XMS > server is really useful for managing a large cluster. Ubiquiti UniFi is > good for smaller installations, but I wouldn't trust them for enterprise > level reliability. > > > > Eric Miller, CCNP > Network Engineering Consultant > (407) 257-5115 > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Lyon > Sent: Thursday, January 29, 2015 12:17 AM > To: Manuel Marín > Cc: NANOG > Subject: Re: Recommended wireless AP for 400 users office > > Check out Xirrus > On Jan 28, 2015 9:08 PM, "Manuel Marín" wrote: > > > Dear nanog community > > > > I was wondering if you can recommend or share your experience with APs > > that you can use in locations that have 300-500 users. I friend > > recommended me Ruckus Wireless, it would be great if you can share > > your experience with Ruckus or with a similar vendor. My experience > > with ubiquity for this type of requirement was not that good. > > > > Thank you and have a great day > > > From paul at nashnetworks.ca Sun Feb 1 14:55:17 2015 From: paul at nashnetworks.ca (Paul Nash) Date: Sun, 1 Feb 2015 09:55:17 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: Message-ID: I have tried Meraki for a large deployment, and was significantly underwhelmed. PF performance was poor compared to Ruckus, meshing was erratic, Radius auth only worked with one Radius server (a cloud-based service). The final straw was when we were trying to debug the Radius auth problem with a Meraki tech, who started sniffing our network traffic from California or wherever, without us needing to do anything. Can you say “security hole”? Like “great gaping security chasm”? As soon as they did that, I disconnected everything and shipped it back to them. Never considered them for anything ever again. paul > On Feb 1, 2015, at 9:41 AM, Dennis Bohn wrote: > > We are substantially larger and use Aruba, but I am wondering why no one > has mentioned Meraki (now cisco-meraki). We tried one of their give-away > aps and it seemed fine, with the 'cloud management.' I am not advocating > Meraki, just curious. > best, > > > Dennis Bohn > Manager of Network and Systems > Adelphi University > bohn at adelphi.edu > 5168773327 > > On Fri, Jan 30, 2015 at 6:28 PM, Eric C. Miller > wrote: > >> +1 Xirrus, especially for the multi radio arrays. Crowded common areas >> benefit from sector antennas attached to individual radios. Also, there XMS >> server is really useful for managing a large cluster. Ubiquiti UniFi is >> good for smaller installations, but I wouldn't trust them for enterprise >> level reliability. >> >> >> >> Eric Miller, CCNP >> Network Engineering Consultant >> (407) 257-5115 >> >> >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Lyon >> Sent: Thursday, January 29, 2015 12:17 AM >> To: Manuel Marín >> Cc: NANOG >> Subject: Re: Recommended wireless AP for 400 users office >> >> Check out Xirrus >> On Jan 28, 2015 9:08 PM, "Manuel Marín" wrote: >> >>> Dear nanog community >>> >>> I was wondering if you can recommend or share your experience with APs >>> that you can use in locations that have 300-500 users. I friend >>> recommended me Ruckus Wireless, it would be great if you can share >>> your experience with Ruckus or with a similar vendor. My experience >>> with ubiquity for this type of requirement was not that good. >>> >>> Thank you and have a great day >>> >> From bill at herrin.us Sun Feb 1 16:38:52 2015 From: bill at herrin.us (William Herrin) Date: Sun, 1 Feb 2015 11:38:52 -0500 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: <20150130174453.485e9105@envy.fud.no> References: <20150130174453.485e9105@envy.fud.no> Message-ID: On Fri, Jan 30, 2015 at 3:23 PM, Tore Anderson wrote: > Kabel Deutschland, T-Mobile USA, and Facebook are examples of companies > who have already or are in the process of moving their network > infrastructure to IPv6-only. Without going bust. Hi Tore, T-Mobile uses something called 464XLAT. Don't let the "translation" part fool you: it's a tunnel. IPv4 in one side, IPv4 out the other. Kabel Deutschland uses something called "Dual Stack Lite." It's also a tunnel: the Kabel-owned CPE encapsulates the customer's IPv4 packets within IPv6 and delivers them to the Kabel's IPv4 carrier NAT box. So sure, if you don't mind dissembling a little bit you can say that they moved their "infrastructure" to IPv6-only. In my mind, tunnelling IPv4 over IPv6 where it both enters and exits the carrier's area of control as an IPv4 packet doesn't count as "IPv6-only." On Fri, Jan 30, 2015 at 11:44 AM, Tore Anderson wrote: > If everyone could just dual-stack their networks, they > might as well single-stack them on IPv4 instead; there would be no > point whatsoever in transitioning to IPv6 for anyone. What do you mean "if"? Carrier NAT means we *can* single-stack on IPv4 for the next 20 to 30 years, if we're so inclined. We'd have to rely on address markets to move the needed public IPs from low-value applications to high-value ones. When you take back all the globally routable IPs assigned to grandma's webmail PC and Joe's cell phone there are plenty left to support growth in server counts. Yes, Joe's cell phone really does have that many IPs. Worse, IPv6's promises are falling one by one. You saw an example in this thread: Eric wants to break up his announcements for traffic engineering purposes because, as it turns out, one announcement per ISP isn't actually enough, Registry practices aren't the primary drivers behind routing disaggregation. That was a bad assumption baked in to IPv6's addressing strategy. Years ago I cracked a joke about IPv6: http://bill.herrin.us/network/ipxl.html These days I don't know whether to laugh or cry. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From owen at delong.com Sun Feb 1 18:17:16 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 1 Feb 2015 10:17:16 -0800 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: <20150130174453.485e9105@envy.fud.no> Message-ID: <889B3C4F-4426-4710-AD35-A6B908FD6084@delong.com> > Worse, IPv6's promises are falling one by one. You saw an example in > this thread: Eric wants to break up his announcements for traffic > engineering purposes because, as it turns out, one announcement per > ISP isn't actually enough, Registry practices aren't the primary > drivers behind routing disaggregation. That was a bad assumption baked > in to IPv6's addressing strategy. Traffic engineering still won’t be anywhere near as bad as the current IPv4 routing table, so no, that doesn’t indicate a failure in the promise of IPv6. Traffic engineering (and other factors) will probably prevent the ideal of one prefix advertised per ASN, but IPv6 will still likely top out somewhere around 4 or 5 on average vs. the current IPv4 average which is north of 10 last time I looked. That’s still a pretty substantial win. Further, technology in routers continues to advance and we are starting to see routers capable of holding very large routing tables. (So far, necessary to cope with the abomination of keeping IPv4 on life support). Once IPv4 can be deprecated, even just in the backbone, it’s a huge win in terms of routing slots available. Further, your statement about registry practices doesn’t hold water. It wasn’t a bad assumption, it was the facts on the ground as they existed for IPv4 at the time. In the 20 years since, the world has changed. Registry practices aren’t a factor in IPv6, but they are, in fact, still a factor (though somewhat less than they used to be) in IPv4. > Years ago I cracked a joke about IPv6: http://bill.herrin.us/network/ipxl.html I didn’t realize you thought it was a joke. I thought it was just more of your misguided railing against IPv6 because you love NAT so much for reasons passing understanding. > These days I don't know whether to laugh or cry. Given your past statements and apparent position along with the fact that despite various efforts, IPv6 deployment continues to accelerate, I’m guessing cry, but that’s certainly your decision. Owen From tore at fud.no Sun Feb 1 19:10:00 2015 From: tore at fud.no (Tore Anderson) Date: Sun, 1 Feb 2015 20:10:00 +0100 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: <20150130174453.485e9105@envy.fud.no> Message-ID: <20150201201000.44064ba0@envy.fud.no> * William Herrin > T-Mobile uses something called 464XLAT. Don't let the "translation" > part fool you: it's a tunnel. IPv4 in one side, IPv4 out the other. 464XLAT is not a tunnel. Protocol translation is substantially different from tunneling. With tunneling, the original layer-3 header is kept intact as it is encapsulated inside another layer-3 header. With translation, the original layer-3 header is removed and replaced with another layer-3 header. They come with a different set of trade-offs, such as: - Protocol translation may be lossy (e.g., exotic IPv4 options may not survive the translation to IPv6 and would therefore not reappear after translation back to IPv4). Tunneling, OTOH, is not lossy. - Tunneling moves the original layer-4 header into another encapsulation layer, so e.g. an ACL attempting to match an IPv6 HTTP packet using something like "next-header tcp, dst port 80" will not work. With translation, it will. > Kabel Deutschland uses something called "Dual Stack Lite." It's also a > tunnel: the Kabel-owned CPE encapsulates the customer's IPv4 packets > within IPv6 and delivers them to the Kabel's IPv4 carrier NAT box. Yep. DS-Lite is indeed tunneling. > So sure, if you don't mind dissembling a little bit you can say that > they moved their "infrastructure" to IPv6-only. In my mind, tunnelling > IPv4 over IPv6 where it both enters and exits the carrier's area of > control as an IPv4 packet doesn't count as "IPv6-only." I guess we disagree about the definitions, then. In my view, a dual-stack network is one where IPv4 and IPv6 are running side-by-side like "ships in the night" with no fate sharing. You might be running two different IGP protocols (like OSPFv2 and OSPFv3) and a duplicated set of iBGP sessions. ACLs and the like must exist both for IPv4 and IPv6. And so on. If you turn off one protocol, and the other one keeps on running just like before. This is in contrast with a single-stack network; turn off that single stack, and nothing works. That doesn't mean that cannot simultaneously transport other layer-3 protocols across that single-stack network; just that there is a clear distinction between which is the main layer-3 protocol and others being transported across it. You might very well simultaneously transport IPv6, AppleTalk, and IPX/SPX across an IPv4-only network - but that doesn't mean that the network is "quad-stack" - IMHO, it's still single-stack IPv4. > On Fri, Jan 30, 2015 at 11:44 AM, Tore Anderson wrote: > > If everyone could just dual-stack their networks, they > > might as well single-stack them on IPv4 instead; there would be no > > point whatsoever in transitioning to IPv6 for anyone. > > What do you mean "if"? Carrier NAT means we *can* single-stack on IPv4 > for the next 20 to 30 years, if we're so inclined. I suppose that's true - if you ignore that a number of other folks are deploying IPv6 to deal with their IPv4 exhaustion, and that products and services are being put to market that recommends the use of IPv6 connectivity above NATed IPv4 (e.g., Xbox One). So much earlier than 30 years from now you'll be wanting to have IPv6 in your network anyway, and once you come to that realisation you might also realise that operating a dual-stack network for those 30 years is not going to be any fun at all due to the increased complexity it causes. Especially if the IPv4 part of that dual-stack network is in itself getting increasingly complex due to more and more NAT being added to deal with growth. So IMHO dual-stack is a bad recommendation, or at least it is rather shortsighted. If you're in a position to do single-stack IPv6-only with IPv4 as a service (like T-Mobile USA or Kabel Deutschland), you'll end up with a much simpler network that it'll be much easier to maintain over the years. This also facilitates the use of IPv4 address sharing solutions like lw4o6 and MAP, whose stateless nature makes them vastly superior to traditional stateful Carrier Grade NAT44 boxes. YMMV, of course. Tore From baldur.norddahl at gmail.com Sun Feb 1 23:25:44 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 2 Feb 2015 00:25:44 +0100 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: <20150201201000.44064ba0@envy.fud.no> References: <20150130174453.485e9105@envy.fud.no> <20150201201000.44064ba0@envy.fud.no> Message-ID: On 1 February 2015 at 20:10, Tore Anderson wrote: > - Tunneling moves the original layer-4 header into another > encapsulation layer, so e.g. an ACL attempting to match an IPv6 HTTP > packet using something like "next-header tcp, dst port 80" will not > work. With translation, it will. > But on the other hand you will mess up with the routing of the network. In our network both IPv4 and IPv6 are routed to different transit points depending on the destination. With translation you need to ensure that the traffic passes a translation point before it leaves the network. If that translation involves NAT, then you also need to ensure that the return traffic hits the same translation device. On some links you might need twice as much capacity if the traffic needs to travel both ways due to the exit point being in one direction and the translation device in the other direction. In our dual stack setup we have none of this worry. The majority of our traffic never goes through a datacenter. It will be MPLS tagged and sent of to the correct edge router directly - for both v4 and v6 traffic. > > I guess we disagree about the definitions, then. > > In my view, a dual-stack network is one where IPv4 and IPv6 are running > side-by-side like "ships in the night" with no fate sharing. You might > be running two different IGP protocols (like OSPFv2 and OSPFv3) and a > duplicated set of iBGP sessions. ACLs and the like must exist both for > IPv4 and IPv6. And so on. If you turn off one protocol, and the other > one keeps on running just like before. > By that definition my dual stack network is single stack: kill ipv4 and MPLS goes down => everything is down. On the other hand there are actually two IPv4 networks, since the IPv4 network under MPLS does not carry internet traffic directly. BOTH IPv4 and IPv6 can be said to be tunneled through the MPLS network. I do not see the point in making this mess even bigger by adding another layer by shoehorning v4 traffic into v6 packets. > So much earlier than 30 years from now you'll be wanting to have IPv6 > in your network anyway, and once you come to that realisation you might > also realise that operating a dual-stack network for those 30 years is > not going to be any fun at all due to the increased complexity it > causes. Especially if the IPv4 part of that dual-stack network is in > itself getting increasingly complex due to more and more NAT being > added to deal with growth. > > So IMHO dual-stack is a bad recommendation, or at least it is rather > shortsighted. If you're in a position to do single-stack IPv6-only with > IPv4 as a service (like T-Mobile USA or Kabel Deutschland), you'll end > up with a much simpler network that it'll be much easier to maintain > over the years. This also facilitates the use of IPv4 address sharing > solutions like lw4o6 and MAP, whose stateless nature makes them vastly > superior to traditional stateful Carrier Grade NAT44 boxes. > > I fail to see the complexity. You are advocating that I should have spent money on more equipment and force my users to use a ISP supplied CPE (currently my users can use any CPE they want). On the other hand, there is little actual complexity to route both protocols in the backbone. We do not run two IGP protocols and all the iBGP sessions are MP-BGP which takes care of both v4 and v6. I see it the other way, trying to have only v6 in the backbone will add substantial complexity. It requires me to buy into some kind of carrier NAT, which it is not time for yet. It forces me to ban older CPEs, which might even be IPv6 capable. There are still brand new CPEs which can not do this correctly. Regards, Baldur From eric at ericheather.com Mon Feb 2 01:51:42 2015 From: eric at ericheather.com (Eric C. Miller) Date: Mon, 2 Feb 2015 01:51:42 +0000 Subject: Recommended wireless AP for 400 users office In-Reply-To: <24849061.7731.1422802496240.JavaMail.mhammett@ThunderFuck> References: <24849061.7731.1422802496240.JavaMail.mhammett@ThunderFuck> Message-ID: That's it. Step 1, buy the equipment at full price. Step 2, pay for the cloud management license, yearly. Step 3, no extended warranty option, so pay full price if equipment from step one fails. We just dumped our meraki deployment because of it: ---- >Dear Helpdesk, >Thank you for being a valued Meraki customer. Our records show that your Meraki Cloud license has expired. > >If you wish to continue using your Meraki networks, you must renew your license immediately. If you choose not to renew, your Meraki systems will cease to provide network access on February 28, 2015. If you have recently made a Meraki purchase, please add your >license key to your Dashboard account. ---- Eric Miller, CCNP Network Engineering Consultant (407) 257-5115 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Sunday, February 01, 2015 9:55 AM To: NANOG Subject: Re: Recommended wireless AP for 400 users office I try to avoid anything that Cisco has touched. Also not a fan of their stop paying our recurring fee and the device becomes a brick policy. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Dennis Bohn" To: "Eric C. Miller" Cc: "NANOG" Sent: Sunday, February 1, 2015 8:41:52 AM Subject: Re: Recommended wireless AP for 400 users office We are substantially larger and use Aruba, but I am wondering why no one has mentioned Meraki (now cisco-meraki). We tried one of their give-away aps and it seemed fine, with the 'cloud management.' I am not advocating Meraki, just curious. best, Dennis Bohn Manager of Network and Systems Adelphi University bohn at adelphi.edu 5168773327 On Fri, Jan 30, 2015 at 6:28 PM, Eric C. Miller wrote: > +1 Xirrus, especially for the multi radio arrays. Crowded common areas > benefit from sector antennas attached to individual radios. Also, > there XMS server is really useful for managing a large cluster. > Ubiquiti UniFi is good for smaller installations, but I wouldn't trust > them for enterprise level reliability. > > > > Eric Miller, CCNP > Network Engineering Consultant > (407) 257-5115 > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Lyon > Sent: Thursday, January 29, 2015 12:17 AM > To: Manuel Marín > Cc: NANOG > Subject: Re: Recommended wireless AP for 400 users office > > Check out Xirrus > On Jan 28, 2015 9:08 PM, "Manuel Marín" wrote: > > > Dear nanog community > > > > I was wondering if you can recommend or share your experience with APs > > that you can use in locations that have 300-500 users. I friend > > recommended me Ruckus Wireless, it would be great if you can share > > your experience with Ruckus or with a similar vendor. My experience > > with ubiquity for this type of requirement was not that good. > > > > Thank you and have a great day > > > From mlewis at techcompute.net Mon Feb 2 02:53:33 2015 From: mlewis at techcompute.net (Lewis, Mitchell T.) Date: Sun, 01 Feb 2015 21:53:33 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: <24849061.7731.1422802496240.JavaMail.mhammett@ThunderFuck> Message-ID: <54CEE6AD.6020909@itgeekdom.net> "If you choose not to renew, your Meraki systems will cease to provide network access on February 28, 2015." I find that interesting as it is my understanding (confirmed by Meraki documents the last I knew) the Meraki Cloud's functionality is carried out on the control domain & does not have any involvement in packet forwarding(my limited testing with Meraki equipment confirmed this). I knew that access to change configuration might disappear but, I was not aware that the data plane could be interrupted as well. That is a excellent item for me to investigate further as I have investigated Meraki as a solution in the past. On a side note, those of you in this situation described below-you may want to take a peek at this: https://meraki.cisco.com/support/#policies:gpl . Does not provide an "enterprise" solution but never the less may get you out of a jam if needed until replacement equipment can be purchased etc. Mitchell T. Lewis Mlewis at Techcompute.Net LinkedIn Profile:www.linkedin.com/in/mlewisitg Mobile: (203)816-0371 A computer will do what you tell it to do, but that may be much different from what you had in mind. ~Joseph Weizenbaum On 02/01/2015 08:51 PM, Eric C. Miller wrote: > That's it. Step 1, buy the equipment at full price. Step 2, pay for the cloud management license, yearly. Step 3, no extended warranty option, so pay full price if equipment from step one fails. > > We just dumped our meraki deployment because of it: > > ---- > >> Dear Helpdesk, >> Thank you for being a valued Meraki customer. Our records show that your Meraki Cloud license has expired. >> >> If you wish to continue using your Meraki networks, you must renew your license immediately. If you choose not to renew, your Meraki systems will cease to provide network access on February 28, 2015. If you have recently made a Meraki purchase, please add your >license key to your Dashboard account. > ---- > > > > > Eric Miller, CCNP > Network Engineering Consultant > (407) 257-5115 > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Sunday, February 01, 2015 9:55 AM > To: NANOG > Subject: Re: Recommended wireless AP for 400 users office > > I try to avoid anything that Cisco has touched. > > Also not a fan of their stop paying our recurring fee and the device becomes a brick policy. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Dennis Bohn" > To: "Eric C. Miller" > Cc: "NANOG" > Sent: Sunday, February 1, 2015 8:41:52 AM > Subject: Re: Recommended wireless AP for 400 users office > > We are substantially larger and use Aruba, but I am wondering why no one has mentioned Meraki (now cisco-meraki). We tried one of their give-away aps and it seemed fine, with the 'cloud management.' I am not advocating Meraki, just curious. > best, > > > Dennis Bohn > Manager of Network and Systems > Adelphi University > bohn at adelphi.edu > 5168773327 > > On Fri, Jan 30, 2015 at 6:28 PM, Eric C. Miller > wrote: > >> +1 Xirrus, especially for the multi radio arrays. Crowded common areas >> benefit from sector antennas attached to individual radios. Also, >> there XMS server is really useful for managing a large cluster. >> Ubiquiti UniFi is good for smaller installations, but I wouldn't trust >> them for enterprise level reliability. >> >> >> >> Eric Miller, CCNP >> Network Engineering Consultant >> (407) 257-5115 >> >> >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Lyon >> Sent: Thursday, January 29, 2015 12:17 AM >> To: Manuel Marín >> Cc: NANOG >> Subject: Re: Recommended wireless AP for 400 users office >> >> Check out Xirrus >> On Jan 28, 2015 9:08 PM, "Manuel Marín" wrote: >> >>> Dear nanog community >>> >>> I was wondering if you can recommend or share your experience with APs >>> that you can use in locations that have 300-500 users. I friend >>> recommended me Ruckus Wireless, it would be great if you can share >>> your experience with Ruckus or with a similar vendor. My experience >>> with ubiquity for this type of requirement was not that good. >>> >>> Thank you and have a great day >>> From tore at fud.no Mon Feb 2 06:34:50 2015 From: tore at fud.no (Tore Anderson) Date: Mon, 2 Feb 2015 07:34:50 +0100 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: <20150130174453.485e9105@envy.fud.no> <20150201201000.44064ba0@envy.fud.no> Message-ID: <20150202073450.34676f57@echo.ms.redpill-linpro.com> Hi Baldur, * Baldur Norddahl > On 1 February 2015 at 20:10, Tore Anderson wrote: > > > - Tunneling moves the original layer-4 header into another > > encapsulation layer, so e.g. an ACL attempting to match an IPv6 > > HTTP packet using something like "next-header tcp, dst port 80" > > will not work. With translation, it will. > > But on the other hand you will mess up with the routing of the > network. In our network both IPv4 and IPv6 are routed to different > transit points depending on the destination. With translation you > need to ensure that the traffic passes a translation point before it > leaves the network. Sure, but you could scatter these translation points all over your network, so that the flow of traffic remains optimal. You could enable the translation functionality on your aggregation and/or your border routers, for example. The traffic would need to pass those anyway, so there's no real change to how traffic is being routed. > If that translation involves NAT, then you also need to ensure that > the return traffic hits the same translation device. No, with stateless solutions like MAP and lw6o4, there is no such requirement. Anycast them or use ECMP towards them however way you like. This is in my view one of the great advantages of such solutions over IPv4 CGN. To the best of my knowledge, there exists no stateless IPv4 sharing mechanism. So the CGN-ed traffic must flow bidirectionally across the same translation device, which then could easily become a choke point. Also, should the CGN device fail, all the existing sessions it was handling would be disrupted. > > In my view, a dual-stack network is one where IPv4 and IPv6 are > > running side-by-side like "ships in the night" with no fate > > sharing. You might be running two different IGP protocols (like > > OSPFv2 and OSPFv3) and a duplicated set of iBGP sessions. ACLs and > > the like must exist both for IPv4 and IPv6. And so on. If you turn > > off one protocol, and the other one keeps on running just like > > before. > > By that definition my dual stack network is single stack: kill ipv4 > and MPLS goes down => everything is down. > > On the other hand there are actually two IPv4 networks, since the IPv4 > network under MPLS does not carry internet traffic directly. BOTH > IPv4 and IPv6 can be said to be tunneled through the MPLS network. While MPLS certainly blurs the lines a bit, based on your description I think that your network could reasonably be described as single-stack MPLS/IPv4-only at its core, while IPv6 (using 6PE I guess?) and another instance of IPv4 (distinct from the one used for MPLS signaling) is being transported as a "service" across that single-stack network. > I do not see the point in making this mess even bigger by adding > another layer by shoehorning v4 traffic into v6 packets. Agreed, considering that you seem to already be enjoying the benefits of having a single-stack network. That is after all what I am saying folks should be considering, rather than automatically going down the dual-stack road. While you're using MPLS instead of IPv6, the principle is similar. > I fail to see the complexity. You are advocating that I should have > spent money on more equipment and force my users to use a ISP > supplied CPE (currently my users can use any CPE they want). I'm just advocating that people should seriously *consider* it, especially if they're buidling something new. I'm not saying it's for everyone everywhere, nor for you specifically. For a provider that controls the user equipment, going IPv6-only certainly a possibility, as demonstrated by T-Mobile USA and Kabel Deutschland. If OTOH there is a requirment to support legacy IPv4-only CPEs, then clearly IPv6-only isn't going to work out too well. Tore From tim at pelican.org Mon Feb 2 10:24:29 2015 From: tim at pelican.org (Tim Franklin) Date: Mon, 2 Feb 2015 10:24:29 +0000 (GMT) Subject: Recommended wireless AP for 400 users office In-Reply-To: References: <24849061.7731.1422802496240.JavaMail.mhammett@ThunderFuck> Message-ID: <1425909285.2664.1422872669445.JavaMail.zimbra@pelican.org> > That's it. Step 1, buy the equipment at full price. Step 2, pay for the cloud > management license, yearly. Step 3, no extended warranty option, so pay full > price if equipment from step one fails. As long as you're doing step 2 (which you *have* to, otherwise it's a brick), isn't step 3 "report device as failed, new device shipped to site, plug in cable, sucks down config of old device from the cloud, up and running again"? I only so far have the demo gear from one of their (rather good) training courses, which has a couple of years left to run, rather than any live deployments, but that's my understanding of the support model from the meetings I've had with them to date. Regards, Tim. From m.hallgren at free.fr Mon Feb 2 12:53:16 2015 From: m.hallgren at free.fr (Michael Hallgren) Date: Mon, 02 Feb 2015 13:53:16 +0100 Subject: Checkpoint IPS Message-ID: <54CF733C.1030205@free.fr> Hi, Someone has positive or negative experience running Checkpoint IPS cluster over ``long distance'' synch. network? Real life limitations? Alternatives? Timers? Cheers, mh From Anthony.Herman at mattersight.com Mon Feb 2 18:17:13 2015 From: Anthony.Herman at mattersight.com (Herman, Anthony) Date: Mon, 2 Feb 2015 18:17:13 +0000 Subject: Cisco Nexus Message-ID: Nanog, I would like to poll the collective for experiences both positive and negative with the Nexus line. More specifically I am interested in hearing about FEX with N2K at the ToR and if this has indeed made any impact on Opex as well as non-obvious shortcomings to using the fabric extenders. Also if anyone is using any of the Nexus line for I/O convergence (FCoE) I would be interested in hearing your experience with this as well. Thank you in advance, -A From jamann at mt.gov Mon Feb 2 18:28:15 2015 From: jamann at mt.gov (Mann, Jason) Date: Mon, 2 Feb 2015 18:28:15 +0000 Subject: Cisco Nexus In-Reply-To: References: Message-ID: <8E594056E7C55C4F996A8A380A5FB6F34087CE40@doaisd5237.state.mt.ads> The biggest thing we ran into was no support of spanning-tree on the FEX's. The way we are setup, being STATE government, our agency controls the network up to the FEX port. Beyond that, the agency's were in control of what they plugged into our FEX ports. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Herman, Anthony Sent: Monday, February 02, 2015 11:17 AM To: nanog at nanog.org Subject: Cisco Nexus Nanog, I would like to poll the collective for experiences both positive and negative with the Nexus line. More specifically I am interested in hearing about FEX with N2K at the ToR and if this has indeed made any impact on Opex as well as non-obvious shortcomings to using the fabric extenders. Also if anyone is using any of the Nexus line for I/O convergence (FCoE) I would be interested in hearing your experience with this as well. Thank you in advance, -A From davidbass570 at gmail.com Mon Feb 2 18:51:04 2015 From: davidbass570 at gmail.com (David Bass) Date: Mon, 2 Feb 2015 12:51:04 -0600 Subject: Cisco Nexus In-Reply-To: References: Message-ID: The n2k ToR is not a great design for user or storage interfaces if most of your traffic is east/west. It is great as a low cost ilo/drac/choose your oob port, or if most of your traffic is north/south. Biggest thing to remember is that it is not a switch, and has limitations such as not connecting other switches to it. Like anything else you have to understand the product so that you don't engineer something that it wasn't designed to do. Lots of very large companies using Nexus gear... That being said I prefer Arista when I'm architecting DCs. > On Feb 2, 2015, at 12:17 PM, Herman, Anthony wrote: > > Nanog, > > I would like to poll the collective for experiences both positive and negative with the Nexus line. More specifically I am interested in hearing about FEX with N2K at the ToR and if this has indeed made any impact on Opex as well as non-obvious shortcomings to using the fabric extenders. Also if anyone is using any of the Nexus line for I/O convergence (FCoE) I would be interested in hearing your experience with this as well. > > Thank you in advance, > > -A From drohan at gmail.com Mon Feb 2 19:09:22 2015 From: drohan at gmail.com (Daniel Rohan) Date: Mon, 2 Feb 2015 11:09:22 -0800 Subject: Cisco Nexus In-Reply-To: References: Message-ID: I think it depends on what the upstream product from the FEX is and what your requirements are. Last I checked, eVPC was not supported on the N7K, but it was supported as an option on the N5K platform. eVPC being the dual homed FEX to two a pair of N7K's running a VPC cluster. I know this is an old post, but here's a good one that explains precisely what I mean: If you look at the N5K verified scalability guide, you see this: Maximum FEXs dual homed to a vPC Cisco Nexus 5500 Series Switch Pair: 24 http://www.cisco.com/en/US/docs/switches/datacenter/nexus5500/sw/configuration_limits/b_N5500_Config_Limits_602N11_chapter_01.html If you look at the N7K verified scalability guide, there is *no* mention of dual-homed fex architectures: http://www.cisco.com/en/US/docs/switches/datacenter/sw/verified_scalability/b_Cisco_Nexus_7000_Series_NX-OS_Verified_Scalability_Guide.html#reference_E1ED6266546C444093CC27DEB0E1B38E If I'm wrong and someone is dual homing 2K FEXs to 7K VPC pairs, please correct me. If you're interested in latency numbers fex-to-fex, here are some numbers provided to me by our SE: http://jumboframe.net/jumboframe/2013/5/5/n2k-fex-to-fex-latency-and-a-reader-follow-up As you can see, these numbers are decent, but you'd have to be very careful in choosing your FEX model if you're looking for better than average store and forward performance out of your FEX. On Mon, Feb 2, 2015 at 10:17 AM, Herman, Anthony < Anthony.Herman at mattersight.com> wrote: > Nanog, > > I would like to poll the collective for experiences both positive and > negative with the Nexus line. More specifically I am interested in hearing > about FEX with N2K at the ToR and if this has indeed made any impact on > Opex as well as non-obvious shortcomings to using the fabric extenders. > Also if anyone is using any of the Nexus line for I/O convergence (FCoE) I > would be interested in hearing your experience with this as well. > > Thank you in advance, > > -A > From george.herbert at gmail.com Mon Feb 2 19:19:31 2015 From: george.herbert at gmail.com (George Herbert) Date: Mon, 2 Feb 2015 11:19:31 -0800 Subject: Cisco Nexus In-Reply-To: References: Message-ID: <235C3335-3FAC-44E9-9E39-8544ECB31368@gmail.com> I wasn't the implementing engineer but I've been at two places that did that, a larger game company and a network gear manufacturer in their engineering support computational hubs. I was there during planning and rollout at the game company, very early in the Nexus lifespan. Both sites brought the FEXes back to 5500s; one used a 6-something for core, the other a pair of 7ks. Game company was more east-west, telco eqpt was very heavy east west. In both cases it's working fine. George William Herbert Sent from my iPhone > On Feb 2, 2015, at 10:17 AM, "Herman, Anthony" wrote: > > Nanog, > > I would like to poll the collective for experiences both positive and negative with the Nexus line. More specifically I am interested in hearing about FEX with N2K at the ToR and if this has indeed made any impact on Opex as well as non-obvious shortcomings to using the fabric extenders. Also if anyone is using any of the Nexus line for I/O convergence (FCoE) I would be interested in hearing your experience with this as well. > > Thank you in advance, > > -A From chris at marget.com Mon Feb 2 19:28:53 2015 From: chris at marget.com (Chris Marget) Date: Mon, 2 Feb 2015 14:28:53 -0500 Subject: Cisco Nexus In-Reply-To: References: Message-ID: There are some unfortunate limitations in classifying incoming traffic. It's been a while, but I think the rule is that Nexus 2000 devices can only classify based on incoming 802.1p cos values. It's a pretty strange and disappointing limitation for an edge device where you're less likely to have incoming dot1q tags and you're less likely to trust the other end of the link to mark its own traffic. /chris From joelja at bogus.com Mon Feb 2 19:43:42 2015 From: joelja at bogus.com (joel jaeggli) Date: Mon, 02 Feb 2015 13:43:42 -0600 Subject: Looking for a FreeDSL / free.fr dns Message-ID: <54CFD36E.1020607@bogus.com> Hello folks, We (Fastly) are seeing some funny performance issues with the recursive resolvers inside Free from the vantage point of our customers and atlas probes embedded in the network. I'd love to talk to somebody with the ability to look, about what's going on. Thanks joel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From nicotine at warningg.com Tue Feb 3 00:24:15 2015 From: nicotine at warningg.com (Brandon Ewing) Date: Mon, 2 Feb 2015 18:24:15 -0600 Subject: Cisco Nexus In-Reply-To: References: Message-ID: <20150203002415.GB23129@radiological.warningg.com> On Mon, Feb 02, 2015 at 12:51:04PM -0600, David Bass wrote: > The n2k ToR is not a great design for user or storage interfaces if most of your traffic is east/west. It is great as a low cost ilo/drac/choose your oob port, or if most of your traffic is north/south. Biggest thing to remember is that it is not a switch, and has limitations such as not connecting other switches to it. Like anything else you have to understand the product so that you don't engineer something that it wasn't designed to do. > And remember -- The Nexus 2K performs absolutely ZERO local switching -- all frames received from client ports are just copied to the upstream device, so it can handle the frame/packet forwarding logic. -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From streiner at cluebyfour.org Mon Feb 2 20:49:56 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 2 Feb 2015 15:49:56 -0500 (EST) Subject: Cisco Nexus In-Reply-To: <20150203002415.GB23129@radiological.warningg.com> References: <20150203002415.GB23129@radiological.warningg.com> Message-ID: On Mon, 2 Feb 2015, Brandon Ewing wrote: > On Mon, Feb 02, 2015 at 12:51:04PM -0600, David Bass wrote: >> The n2k ToR is not a great design for user or storage interfaces if most of your traffic is east/west. It is great as a low cost ilo/drac/choose your oob port, or if most of your traffic is north/south. Biggest thing to remember is that it is not a switch, and has limitations such as not connecting other switches to it. Like anything else you have to understand the product so that you don't engineer something that it wasn't designed to do. >> > > And remember -- The Nexus 2K performs absolutely ZERO local switching -- all > frames received from client ports are just copied to the upstream device, so > it can handle the frame/packet forwarding logic. Also remember that the Nexus (5K, at least) does cut-through switching. If you receive an errored frame on one port, the switch can and often will happily forward those errored frames once it figures out the destination MAC address(es). jms From george.herbert at gmail.com Tue Feb 3 01:03:06 2015 From: george.herbert at gmail.com (George Herbert) Date: Mon, 2 Feb 2015 17:03:06 -0800 Subject: Cisco Nexus In-Reply-To: <20150203002415.GB23129@radiological.warningg.com> References: <20150203002415.GB23129@radiological.warningg.com> Message-ID: > Brandon Ewing wrote: > >> David Bass wrote: >> The n2k ToR is not a great design for user or storage interfaces if most of your traffic is east/west. It is great as a low cost ilo/drac/choose your oob port, or if most of your traffic is north/south. Biggest thing to remember is that it is not a switch, and has limitations such as not connecting other switches to it. Like anything else you have to understand the product so that you don't engineer something that it wasn't designed to do. > > And remember -- The Nexus 2K performs absolutely ZERO local switching -- all > frames received from client ports are just copied to the upstream device, so > it can handle the frame/packet forwarding logic. What this really does is force you to consider how much of your East-West is rack-local, versus off rack. Rack-local-heavy hurts as badly as off rack, with FEX. If you want to / can localize E/W tighter than that then you want real TOR switching. If the average E-W is cross rack then the FEX are performance equivalent. For random distributions this comes at a few racks. For intentional distributions it's probably better to TOR switch from day one. George William Herbert Sent from my iPhone From rps at maine.edu Tue Feb 3 12:18:49 2015 From: rps at maine.edu (Ray Soucy) Date: Tue, 3 Feb 2015 07:18:49 -0500 Subject: Cisco Nexus In-Reply-To: References: Message-ID: I have a small setup, Nexus 2 x 5596UP + 12 x 2248TP FEX, 2 x B22DELL, 2 x B22HP, 1 x C2248PQ-10GE. Been using this setup since 2012, so it's getting a bit long in the tooth. It's in an Active-Active setup because there wasn't much guidance at the time on which way to go. There are some restrictions with an AA setup you probably want to avoid. We currently don't do any FCoE because we're mostly a NetApp and NFS environment. The performance and stability have been great. It works well for a traditional environment with a lot of wired ports to stand-alone servers. If you do a lot with virtualization it's not a great solution. You really want to avoid connecting VM host servers to FEX ports because of all the restrictions that come with it. One restriction that's a real PITA for me right now is that a FEX port can't be a promiscuous trunk port if you're using PVLAN. Using config-sync has been a lot of trouble. There are a lot of actions that will verify OK but then fail. The result is that things are partially configured and the whole system gets out of sync not letting you make any other changes; the fix is having to manually go in to each switch to try and get the configuration to match (which requires comparing the running-configuration to the running switch-profile configuration). On Mon, Feb 2, 2015 at 1:17 PM, Herman, Anthony wrote: > Nanog, > > I would like to poll the collective for experiences both positive and negative with the Nexus line. More specifically I am interested in hearing about FEX with N2K at the ToR and if this has indeed made any impact on Opex as well as non-obvious shortcomings to using the fabric extenders. Also if anyone is using any of the Nexus line for I/O convergence (FCoE) I would be interested in hearing your experience with this as well. > > Thank you in advance, > > -A -- 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 eugen at imacandi.net Tue Feb 3 15:21:13 2015 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Tue, 3 Feb 2015 17:21:13 +0200 Subject: Checkpoint IPS In-Reply-To: <54CF733C.1030205@free.fr> References: <54CF733C.1030205@free.fr> Message-ID: On Mon, Feb 2, 2015 at 2:53 PM, Michael Hallgren wrote: > Hi, > > Someone has positive or negative experience running > Checkpoint IPS cluster over ``long distance'' synch. > network? Real life limitations? Alternatives? Timers? > > You can do "stretched" with Check Point as long as the network delay is less than around 70-100 msec RTT or so. If you do this, run your firewalls in Active/Standby modes. From jcurran at arin.net Tue Feb 3 15:26:49 2015 From: jcurran at arin.net (John Curran) Date: Tue, 3 Feb 2015 15:26:49 +0000 Subject: Don't Miss the ARIN Public Policy Consultation at NANOG 63 References: <54CA59B0.50009@arin.net> Message-ID: <837FA4D8-D494-4DE7-A3BB-8E761819FC5B@corp.arin.net> NANOGers - If you are in San Antonio, feel free to join us for a discussion of address policy in Salon M at 9:30 AM. /John John Curran President and CEO ARIN Begin forwarded message: Date: January 29, 2015 at 10:02:56 AM CST From: ARIN > To: > Subject: [arin-announce] Don't Miss the ARIN Public Policy Consultation at NANOG 63 ar Don't forget to mark your calendar and join us for ARIN's Public Policy Consultation (PPC), which will be held during NANOG 63 in San Antonio, Texas on Tuesday, 3 February 2015, from 9:30 - 1:00 PM CST. The policy consultation is part of ARIN's Policy Development Process, and it is an open public discussion of Internet number resource policy. ARIN will offer a webcast, live transcript, and Jabber chat options for remote participants. Registered remote participants can submit comments and questions to the discussions during the meeting. Details are available at: https://www.arin.net/ppcnanog63 Registered NANOG 63 attendees do not need to register to participate in this session. If you plan to attend only the ARIN PPC and are not registered for NANOG, you must register for the ARIN PPC at: https://www.arin.net/ppcregister There is no registration fee for this ARIN session, and it does not provide you entry to any other NANOG programming or social events. Current policy proposals up for discussion at this meeting are: Draft Policy ARIN-2014-1: Out of Region Use Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate Draft Policy ARIN-2014-19: New MDN Allocation Based on Past Utilization Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4 Draft Policy ARIN-2014-22: Removal of Minimum in Section 4.10 Text available at: https://www.arin.net/policy/proposals/ Register to attend in person or remotely today! Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From m.hallgren at free.fr Tue Feb 3 15:41:45 2015 From: m.hallgren at free.fr (Michael Hallgren) Date: Tue, 03 Feb 2015 16:41:45 +0100 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> Message-ID: <54D0EC39.40209@free.fr> Le 03/02/2015 16:21, Eugeniu Patrascu a écrit : > On Mon, Feb 2, 2015 at 2:53 PM, Michael Hallgren > wrote: > > Hi, > > Someone has positive or negative experience running > Checkpoint IPS cluster over ``long distance'' synch. > network? Real life limitations? Alternatives? Timers? > > > You can do "stretched" with Check Point as long as the network delay > is less than around 70-100 msec RTT or so. If you do this, run your > firewalls in Active/Standby modes. > Thanks Eugeniu, I see what you mean. The specific case I'm looking at is about asymmetric routing, though. Cheers, mh From Lee at asgard.org Tue Feb 3 21:34:24 2015 From: Lee at asgard.org (Lee Howard) Date: Tue, 03 Feb 2015 16:34:24 -0500 Subject: Public Policy Approaches to IPv4-IPv6 Transition Message-ID: If you are a monarch or regulator, or just curious, and want to compare stories of what other countries have done to promote IPv6 (as in my presentation today, https://www.nanog.org/meetings/abstract?id=2486) you can download the working paper at: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2417079 Note that this is a working paper. I appreciate the several offers for more information on countries where our story is incomplete. Lee From jamesb2147 at gmail.com Wed Feb 4 02:30:39 2015 From: jamesb2147 at gmail.com (Sean Hunter) Date: Tue, 3 Feb 2015 20:30:39 -0600 Subject: Recommended wireless AP for 400 users office In-Reply-To: <1425909285.2664.1422872669445.JavaMail.zimbra@pelican.org> References: <24849061.7731.1422802496240.JavaMail.mhammett@ThunderFuck> <1425909285.2664.1422872669445.JavaMail.zimbra@pelican.org> Message-ID: I happen to administer a deployment of almost exclusively Meraki gear; ~140 switches (mix of MS42 and MS22) and ~400 AP's (almost all MR16's). I would *not* recommend them for this situation. If you've got a low-usage scenario, they might be fine. The tech support quality has noticeably declined over the last 2 years we've been running their gear, and the really amazing fact about that is that I'm working with the same people (read: Cisco is making them script-following support monkeys rather than techs) who generally know me by name. That is another "interesting" point with Meraki. I've helped them identify several bugs, some of which were very serious. We regularly have to ship back switches after an update. We've encountered a RADIUS auth issue where users were being randomly diverted into the wrong VLAN in the middle of a wireless session (they weren't even roaming or anything). The RADIUS issue was actually really interesting; it dumped users into our management VLAN which very quickly depleted the DHCP pool. About 20% of our 4000 wireless devices were in the wrong VLAN and unable to get on the internet (yikes!) and suddenly our AP's started bouncing because they lost their DHCP leases, couldn't get new ones, lost contact with the Meraki cloud controller, and started rebooting every few minutes (the MR16's don't boot quickly, either). It was terrifying and horrible, especially because that was the 2nd time it occurred for us. We're *still* running a custom Meraki firmware that's a year old because they have, twice now, reported that the fixed the RADIUS issue, only to have us experience this when we updated them all at once. We've had similarly critical firmware regressions on the wired side of things, aside from the normal slew of issues ("What do you mean your firmware upgrade disabled the uplink port?"). If provided a do-over, I'd select Ubiquiti today, or another of the more professional vendors. Meraki's gear is cool, the Dashboard is a *dream* to work with, I love the built-in remote packet captures, and they're probably fine for most small deployments, but Meraki isn't ready for prime time yet. I feel like a beta-tester rather than a customer, and the support is getting worse when, if they're going to act like a startup (read: move fast and break things), they really need for it to get better. RE: Aforementioned criticisms from this thread: 1) Meraki makes you buy hardware, licenses, and more hardware when the first dies. Response: Almost 100% wrong. I read each warranty and suggest you do the same for any gear you buy. The stuff we use (MR16's, MR22's, and MR42's) has cost-free replacement warranty coverage as long as you hold a valid license. The one exception are the outdoor AP's, which only have a 1 year warranty, which is rather crappy on Meraki's part, because the license fees are the same no matter your model of AP (indoor, outdoor, big and expensive, or small and cheap). 2) Meraki switching/AP functionality is/is not tied to cloud controller functionality. Response: It is and it isn't. First, you must have a valid license or 30 days later your network ceases to function. All of it. Completely ceases. They haven't been flexible on this and we even got within 2 days of it expiring when we first installed ours. Our sales rep was sympathetic but unhelpful, even after taking our money for the license. :/ Second, we've had our cloud controller go down and life went on. However, we've also had our AP's be unable to get a DHCP lease and start rebooting every few minutes. You tell me what that's worth. I think that might be $0.05 worth. ;) On Mon, Feb 2, 2015 at 4:24 AM, Tim Franklin wrote: > > That's it. Step 1, buy the equipment at full price. Step 2, pay for the > cloud > > management license, yearly. Step 3, no extended warranty option, so pay > full > > price if equipment from step one fails. > > As long as you're doing step 2 (which you *have* to, otherwise it's a > brick), isn't step 3 "report device as failed, new device shipped to site, > plug in cable, sucks down config of old device from the cloud, up and > running again"? > > I only so far have the demo gear from one of their (rather good) training > courses, which has a couple of years left to run, rather than any live > deployments, but that's my understanding of the support model from the > meetings I've had with them to date. > > Regards, > Tim. > From charlesg at unixrealm.com Wed Feb 4 04:02:49 2015 From: charlesg at unixrealm.com (Charles Gagnon) Date: Tue, 3 Feb 2015 23:02:49 -0500 Subject: Verizon FiOS contact? Message-ID: Anyone from VZ FiOS network on the list who would be interested in discussing something. We host in Equinix/NY4 and have internet provided by Internap. Several of our users have been complaining of speed issues and our own speed tests confirm severe bandwidth degradation (we're talking 0.5Mbps download speeds) but only for FiOS customers. From anywhere to Internap is fine. >From FiOS to anywhere else is also fine. But there is a definite reproducible issues from FiOS (tested in NYC, Westchester and NJ) to Internap in NY4. Internap informed us other customers are having issues from FiOS as well but it seems they can't reach anyone at VZ who will engage on this. They claim each user must file a repair request with VZ. We are encouraging our users to do so but I'm not holding my breath. Cheers, -- Charles Gagnon charlesg at unixrealm.com From morrowc.lists at gmail.com Wed Feb 4 04:35:17 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 3 Feb 2015 23:35:17 -0500 Subject: Verizon FiOS contact? In-Reply-To: References: Message-ID: On Tue, Feb 3, 2015 at 11:02 PM, Charles Gagnon wrote: > Anyone from VZ FiOS network on the list who would be interested in > discussing something. > > We host in Equinix/NY4 and have internet provided by Internap. Several of > our users have been complaining of speed issues and our own speed tests > confirm severe bandwidth degradation (we're talking 0.5Mbps download > speeds) but only for FiOS customers. From anywhere to Internap is fine. > From FiOS to anywhere else is also fine. But there is a definite > reproducible issues from FiOS (tested in NYC, Westchester and NJ) to > Internap in NY4. > > Internap informed us other customers are having issues from FiOS as well > but it seems they can't reach anyone at VZ who will engage on this. They > claim each user must file a repair request with VZ. We are encouraging our > users to do so but I'm not holding my breath. guessing here, but I bet if someone from internap called the vz sales folks and there'd be a solution in 30-90 days (standard install interval). From contact at winterei.se Wed Feb 4 04:51:33 2015 From: contact at winterei.se (Paul S.) Date: Wed, 04 Feb 2015 13:51:33 +0900 Subject: Verizon FiOS contact? In-Reply-To: References: Message-ID: <54D1A555.4050305@winterei.se> isn't pnap a direct vz customer either way? I know it's in the DFW blend which we have, not sure about NY. It shouldn't be out of their ability to complain. On 2/4/2015 午後 01:35, Christopher Morrow wrote: > On Tue, Feb 3, 2015 at 11:02 PM, Charles Gagnon wrote: >> Anyone from VZ FiOS network on the list who would be interested in >> discussing something. >> >> We host in Equinix/NY4 and have internet provided by Internap. Several of >> our users have been complaining of speed issues and our own speed tests >> confirm severe bandwidth degradation (we're talking 0.5Mbps download >> speeds) but only for FiOS customers. From anywhere to Internap is fine. >> From FiOS to anywhere else is also fine. But there is a definite >> reproducible issues from FiOS (tested in NYC, Westchester and NJ) to >> Internap in NY4. >> >> Internap informed us other customers are having issues from FiOS as well >> but it seems they can't reach anyone at VZ who will engage on this. They >> claim each user must file a repair request with VZ. We are encouraging our >> users to do so but I'm not holding my breath. > guessing here, but I bet if someone from internap called the vz sales > folks and there'd be a solution in 30-90 days (standard install > interval). From paul at nashnetworks.ca Wed Feb 4 12:24:21 2015 From: paul at nashnetworks.ca (Paul Nash) Date: Wed, 4 Feb 2015 07:24:21 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: <24849061.7731.1422802496240.JavaMail.mhammett@ThunderFuck> <1425909285.2664.1422872669445.JavaMail.zimbra@pelican.org> Message-ID: > I love the built-in remote packet captures, You, the NSA, and lots and lots of hackers, ALL love the remote packet capture. If Meraki support can turn it on, so can someone who penetrates their systems (by getting a job there or by hacking), and then they get to see everything happening INSIDE your network. Not just your WAN traffic, which would be bad enough. paul From rps at maine.edu Wed Feb 4 13:31:46 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 4 Feb 2015 08:31:46 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: <24849061.7731.1422802496240.JavaMail.mhammett@ThunderFuck> <1425909285.2664.1422872669445.JavaMail.zimbra@pelican.org> Message-ID: Honestly, in a lot of cases you don't even need a device to support packet capture as a feature to add it as a feature once its compromised. This is just FUD IMHO. On Wed, Feb 4, 2015 at 7:24 AM, Paul Nash wrote: >> I love the built-in remote packet captures, > > You, the NSA, and lots and lots of hackers, ALL love the remote packet capture. If Meraki support can turn it on, so can someone who penetrates their systems (by getting a job there or by hacking), and then they get to see everything happening INSIDE your network. Not just your WAN traffic, which would be bad enough. > > paul -- 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 paul at nashnetworks.ca Wed Feb 4 13:48:53 2015 From: paul at nashnetworks.ca (Paul Nash) Date: Wed, 4 Feb 2015 08:48:53 -0500 Subject: Recommended wireless AP for 400 users office In-Reply-To: References: <24849061.7731.1422802496240.JavaMail.mhammett@ThunderFuck> <1425909285.2664.1422872669445.JavaMail.zimbra@pelican.org> Message-ID: <00BD060C-DE26-4B02-B475-923CF15BD474@nashnetworks.ca> It’s the “remote capture” that scares me. I was testing some Meraki kit, called their NOC to try to debug some Radius issues, tech tells me “oh yes, I can see your traffic going hither and yon between the test client and test server that are both in your office, and looking at the packet contents I can see ….” With Ruckus (or almost any other) gear, I have to either open up a hole through my firewall or grab the packet traces and send them to the tech folk. They don’t have uncontrolled access to my internal traffic out of the box. paul > On Feb 4, 2015, at 8:31 AM, Ray Soucy wrote: > > Honestly, in a lot of cases you don't even need a device to support > packet capture as a feature to add it as a feature once its > compromised. This is just FUD IMHO. > > On Wed, Feb 4, 2015 at 7:24 AM, Paul Nash wrote: >>> I love the built-in remote packet captures, >> >> You, the NSA, and lots and lots of hackers, ALL love the remote packet capture. If Meraki support can turn it on, so can someone who penetrates their systems (by getting a job there or by hacking), and then they get to see everything happening INSIDE your network. Not just your WAN traffic, which would be bad enough. >> >> paul > > > > -- > 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 eugen at imacandi.net Wed Feb 4 16:07:33 2015 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 4 Feb 2015 18:07:33 +0200 Subject: Checkpoint IPS In-Reply-To: <54D0EC39.40209@free.fr> References: <54CF733C.1030205@free.fr> <54D0EC39.40209@free.fr> Message-ID: On Tue, Feb 3, 2015 at 5:41 PM, Michael Hallgren wrote: > Le 03/02/2015 16:21, Eugeniu Patrascu a écrit : > > On Mon, Feb 2, 2015 at 2:53 PM, Michael Hallgren > wrote: > >> Hi, >> >> Someone has positive or negative experience running >> Checkpoint IPS cluster over ``long distance'' synch. >> network? Real life limitations? Alternatives? Timers? >> >> > You can do "stretched" with Check Point as long as the network delay is > less than around 70-100 msec RTT or so. If you do this, run your firewalls > in Active/Standby modes. > > > Thanks Eugeniu, I see what you mean. The specific case I'm looking at is > about asymmetric routing, though. > Firewalls/IPS and asymmetric routing don't play nice. Try to change your setup/design so that traffic enters/leaves your network segments through the same security device. From rdobbins at arbor.net Wed Feb 4 16:19:25 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 04 Feb 2015 23:19:25 +0700 Subject: Checkpoint IPS In-Reply-To: <54CF733C.1030205@free.fr> References: <54CF733C.1030205@free.fr> Message-ID: On 2 Feb 2015, at 19:53, Michael Hallgren wrote: > Real life limitations? ----------------------------------- Roland Dobbins From tech at allpointsbroadband.com Wed Feb 4 19:11:54 2015 From: tech at allpointsbroadband.com (Timothy Nowaczyk) Date: Wed, 4 Feb 2015 14:11:54 -0500 Subject: Hulu NOC contact request. Message-ID: We are an ISP and some of our customers are being blocked from Hulu because Hulu thinks they’re using a proxy service even though the customers have a straight pipe to the internet. Is there anyone on here from Hulu that can help me get my IPs unblocked? Please contact me off-list. Thanks, Tim Nowaczyk -- Timothy A. Nowaczyk Senior Network Manager All Points Broadband +1.703.554.6622 (o) +1.571.318.9434 (c) tnowaczyk at allpointsbroadband.com From m.hallgren at free.fr Thu Feb 5 06:51:56 2015 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 05 Feb 2015 07:51:56 +0100 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D0EC39.40209@free.fr> Message-ID: <54D3130C.6010003@free.fr> Le 04/02/2015 17:07, Eugeniu Patrascu a écrit : > On Tue, Feb 3, 2015 at 5:41 PM, Michael Hallgren > wrote: > > Le 03/02/2015 16:21, Eugeniu Patrascu a écrit : >> On Mon, Feb 2, 2015 at 2:53 PM, Michael Hallgren >> > wrote: >> >> Hi, >> >> Someone has positive or negative experience running >> Checkpoint IPS cluster over ``long distance'' synch. >> network? Real life limitations? Alternatives? Timers? >> >> >> You can do "stretched" with Check Point as long as the network >> delay is less than around 70-100 msec RTT or so. If you do this, >> run your firewalls in Active/Standby modes. >> > > Thanks Eugeniu, I see what you mean. The specific case I'm looking > at is about asymmetric routing, though. > > > Firewalls/IPS and asymmetric routing don't play nice. Try to change > your setup/design so that traffic enters/leaves your network segments > through the same security device. I know. However, I fail to see symmetric traffic flow as ``natural'', apart from maybe at the extreme edge of a network. So, need another inspection strategy I think. Thanks, mh From m.hallgren at free.fr Thu Feb 5 06:55:43 2015 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 05 Feb 2015 07:55:43 +0100 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> Message-ID: <54D313EF.4080305@free.fr> Le 04/02/2015 17:19, Roland Dobbins a écrit : > On 2 Feb 2015, at 19:53, Michael Hallgren wrote: > >> Real life limitations? > Right ;-) Among many other nice ones, I like: `` ‘IPS’ devices require artificially-engineered topological symmetry- can have a negative impact on resiliency via path diversity.'' Cheers, mh > > ----------------------------------- > Roland Dobbins From rdobbins at arbor.net Thu Feb 5 07:01:43 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 05 Feb 2015 14:01:43 +0700 Subject: Checkpoint IPS In-Reply-To: <54D3130C.6010003@free.fr> References: <54CF733C.1030205@free.fr> <54D0EC39.40209@free.fr> <54D3130C.6010003@free.fr> Message-ID: On 5 Feb 2015, at 13:51, Michael Hallgren wrote: > So, need another inspection strategy I think. The real question is, why 'inspect', at all? ----------------------------------- Roland Dobbins From m.hallgren at free.fr Thu Feb 5 07:46:45 2015 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 05 Feb 2015 08:46:45 +0100 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D0EC39.40209@free.fr> <54D3130C.6010003@free.fr> Message-ID: <54D31FE5.3010909@free.fr> Le 05/02/2015 08:01, Roland Dobbins a écrit : > On 5 Feb 2015, at 13:51, Michael Hallgren wrote: > >> So, need another inspection strategy I think. > The real question is, why 'inspect', at all? Yes, that's an even more interesting discussion! mh > > ----------------------------------- > Roland Dobbins From terry.baranski.list at gmail.com Thu Feb 5 12:57:47 2015 From: terry.baranski.list at gmail.com (Terry Baranski) Date: Thu, 5 Feb 2015 07:57:47 -0500 Subject: Checkpoint IPS In-Reply-To: <54D313EF.4080305@free.fr> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> Message-ID: <000801d04143$57b9c0f0$072d42d0$@gmail.com> On 5 Feb 2015, at 01:56, Michael Hallgren wrote: > Le 04/02/2015 17:19, Roland Dobbins a écrit : >> >> Real life limitations? >> https://app.box.com/s/a3oqqlgwe15j8svojvzl > > Right ;-) Among many other nice ones, I like: > > `` ‘IPS’ devices require artificially-engineered topological symmetry- > can have a negative impact on resiliency via path diversity.'' Dang, I thought this quote was from an April 1st RFC when I first read it. I hate to be the bearer of bad news, but everything we do is "artificial". There are no routers in nature, no IP packets, no fiber optics. There is no such thing as "natural engineering" -- engineering is "artificial" by definition. So when you're configuring artificially-engineered protocols on your artificially-engineered router so that your artificially-engineered network can transmit artificially-engineered packets, adding some extra artificially-engineered logic to enforce symmetry won't break the bank, I promise. And when done properly it has absolutely no impact on resilience and path diversity, and will do you all the good in the world from a troubleshooting perspective (those of you who operate networks). The whole presentation is frankly just odd to me. It looks at one specific CND thread (DDoS), and attempts to address it by throwing out the baby with the bathwater. It says to eliminate state at all costs, but then at the end advocates for reverse proxies -- which are stateful, and which therefore create the same "problems" as firewalls and IPSs. The idea of ripping out firewall/IPS devices and replacing them with router ACLs is something that, if I were an attacker, I would definitely encourage all of my targets to do. Firewalls aren't so much the big issue -- one can theoretically use router ACLs for basic L3/L4 blocks, though they scale horribly from an O&M perspective, are more prone to configuration errors, and their manageability is poor. But there's no overstating the usefulness of a properly-tuned IPS for attack prevention, and the comment in the brief comparing an IPS to "[Having] your email client set to alert you to incoming mail" is so bizarre that I wouldn't even know how to counter it. (I know you're out there Roland and my intention isn't to get into a big thing with you. But the artificial-engineering thing gave me a chuckle.) On 5 Feb 2015, at 02:49, Michael Hallgren wrote: > Le 05/02/2015 08:01, Roland Dobbins a écrit : >> >> The real question is, why 'inspect', at all? > > Yes, that's an even more interesting discussion! Only if your assets aren't targets. :-) -Terry From michael.holstein at csuohio.edu Thu Feb 5 13:13:26 2015 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Thu, 5 Feb 2015 13:13:26 +0000 Subject: Checkpoint IPS In-Reply-To: <000801d04143$57b9c0f0$072d42d0$@gmail.com> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr>,<000801d04143$57b9c0f0$072d42d0$@gmail.com> Message-ID: <1423142005906.59768@csuohio.edu> >> `` ‘IPS’ devices require artificially-engineered topological symmetry- >> can have a negative impact on resiliency via path diversity.'' > >Dang, I thought this quote was from an April 1st RFC when I first read it. > >I hate to be the bearer of bad news, but everything we do is "artificial". >There are no routers in nature, no IP packets, no fiber optics. There is no >such thing as "natural engineering" -- engineering is "artificial" by >definition. You're forgetting that such things are rarely read (in time) by the people that actually implement and use such a product .. that language is targeted at the pointy-haired crowd. Salespeople *hate* it when they get a technical resource instead of a management one because "it's magic, it's artificial intelligence, etc." just doesn't fly with us. Personally I'm of the belief that *all* IPS systems are equally worthless, unless the goal is to just check a box on a form. Sure they will give you pretty graphs of script-kiddie attempts but that's just the noise in which the skilled attack will get lost. You have to do everything else right, you can't just plug the "magic box" inline and expect to relax. My 0.02. Michael Holstein Cleveland State University 2 From deleskie at gmail.com Thu Feb 5 13:15:17 2015 From: deleskie at gmail.com (jim deleskie) Date: Thu, 5 Feb 2015 09:15:17 -0400 Subject: Checkpoint IPS In-Reply-To: <000801d04143$57b9c0f0$072d42d0$@gmail.com> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> Message-ID: mh, you know that forcing traffic to be symmetrical is evil, and while backbone traffic and inspection don't play nice, there are very legit reasons why, in many cases edge traffic must be open for inspection. I'm on my way to the office, feel free to ping me if you want to discuss. Or maybe I could use it as a reason to come visit its been a while since we've had a chance to vis-a-vis :) -jim On Thu, Feb 5, 2015 at 8:57 AM, Terry Baranski < terry.baranski.list at gmail.com> wrote: > On 5 Feb 2015, at 01:56, Michael Hallgren wrote: > > Le 04/02/2015 17:19, Roland Dobbins a écrit : > >> > >> Real life limitations? > >> https://app.box.com/s/a3oqqlgwe15j8svojvzl > > > > Right ;-) Among many other nice ones, I like: > > > > `` ‘IPS’ devices require artificially-engineered topological symmetry- > > can have a negative impact on resiliency via path diversity.'' > > Dang, I thought this quote was from an April 1st RFC when I first read it. > > I hate to be the bearer of bad news, but everything we do is "artificial". > There are no routers in nature, no IP packets, no fiber optics. There is no > such thing as "natural engineering" -- engineering is "artificial" by > definition. > > So when you're configuring artificially-engineered protocols on your > artificially-engineered router so that your artificially-engineered network > can transmit artificially-engineered packets, adding some extra > artificially-engineered logic to enforce symmetry won't break the bank, I > promise. And when done properly it has absolutely no impact on resilience > and path diversity, and will do you all the good in the world from a > troubleshooting perspective (those of you who operate networks). > > The whole presentation is frankly just odd to me. It looks at one specific > CND thread (DDoS), and attempts to address it by throwing out the baby with > the bathwater. It says to eliminate state at all costs, but then at the end > advocates for reverse proxies -- which are stateful, and which therefore > create the same "problems" as firewalls and IPSs. > > The idea of ripping out firewall/IPS devices and replacing them with router > ACLs is something that, if I were an attacker, I would definitely encourage > all of my targets to do. Firewalls aren't so much the big issue -- one can > theoretically use router ACLs for basic L3/L4 blocks, though they scale > horribly from an O&M perspective, are more prone to configuration errors, > and their manageability is poor. But there's no overstating the usefulness > of a properly-tuned IPS for attack prevention, and the comment in the brief > comparing an IPS to "[Having] your email client set to alert you to > incoming > mail" is so bizarre that I wouldn't even know how to counter it. > > (I know you're out there Roland and my intention isn't to get into a big > thing with you. But the artificial-engineering thing gave me a chuckle.) > > On 5 Feb 2015, at 02:49, Michael Hallgren wrote: > > Le 05/02/2015 08:01, Roland Dobbins a écrit : > >> > >> The real question is, why 'inspect', at all? > > > > Yes, that's an even more interesting discussion! > > Only if your assets aren't targets. :-) > > -Terry > > > From rdobbins at arbor.net Thu Feb 5 13:19:44 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 05 Feb 2015 20:19:44 +0700 Subject: Checkpoint IPS In-Reply-To: <1423142005906.59768@csuohio.edu> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <1423142005906.59768@csuohio.edu> Message-ID: On 5 Feb 2015, at 20:13, Michael O Holstein wrote: > Personally I'm of the belief that *all* IPS systems are equally > worthless, unless the goal is to just check a box on a form. Concur 100%. Securing hosts/applications/services themselves is the way to protect them from compromise. ----------------------------------- Roland Dobbins From Patrick.Darden at p66.com Thu Feb 5 13:25:59 2015 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Thu, 5 Feb 2015 13:25:59 +0000 Subject: Checkpoint IPS In-Reply-To: <1423142005906.59768@csuohio.edu> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr>,<000801d04143$57b9c0f0$072d42d0$@gmail.com> <1423142005906.59768@csuohio.edu> Message-ID: <61929e3d3ede405aa1c025f97af8477c@BRTEXMB02.phillips66.net> Like most tools, IPSes are only as good as the people using them. +10 "you can't just plug the "magic box" inline and expect to relax" IPSes can't replace a well administered modern firewall, with default deny, well defined protocols with sanity checking, etc. But imho they can help--e.g. with an internal well-protected network that shouldn't even be able to be attacked, but some dude picked up a usb key in the parking lot and plugged it into his PC to see what was on it. No firewall will help with this--but an IDS/IPS will. And no box is magic (another +10), despite the marketing droids' nebulous talk of clouds and AI and harnessing the power of the nuclear-nano-crowd-source. They all need active attention by knowledgeable and intelligent people. --p -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael O Holstein Sent: Thursday, February 05, 2015 7:13 AM To: nanog at nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS Personally I'm of the belief that *all* IPS systems are equally worthless, unless the goal is to just check a box on a form. Sure they will give you pretty graphs of script-kiddie attempts but that's just the noise in which the skilled attack will get lost. You have to do everything else right, you can't just plug the "magic box" inline and expect to relax. Michael Holstein Cleveland State University 2 From terry.baranski.list at gmail.com Thu Feb 5 13:28:53 2015 From: terry.baranski.list at gmail.com (Terry Baranski) Date: Thu, 5 Feb 2015 08:28:53 -0500 Subject: Checkpoint IPS In-Reply-To: <1423142005906.59768@csuohio.edu> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr>, <000801d04143$57b9c0f0$072d42d0$@gmail.com> <1423142005906.59768@csuohio.edu> Message-ID: <000201d04147$afc28a30$0f479e90$@gmail.com> On 5 Feb 2015, at 08:13, Michael Hallgren wrote: > > Sure they will give you pretty graphs of script-kiddie attempts but > that's just the noise in which the skilled attack will get lost. Sorry but this is not even in the neighborhood of what a properly-implemented IPS does. I can certainly see why you think they're worthless though. :-) -Terry -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael O Holstein Sent: Thursday, February 05, 2015 8:13 AM To: nanog at nanog.org Subject: Re: Checkpoint IPS >> `` 'IPS' devices require artificially-engineered topological symmetry- >> can have a negative impact on resiliency via path diversity.'' > >Dang, I thought this quote was from an April 1st RFC when I first read it. > >I hate to be the bearer of bad news, but everything we do is "artificial". >There are no routers in nature, no IP packets, no fiber optics. There is no >such thing as "natural engineering" -- engineering is "artificial" by >definition. You're forgetting that such things are rarely read (in time) by the people that actually implement and use such a product .. that language is targeted at the pointy-haired crowd. Salespeople *hate* it when they get a technical resource instead of a management one because "it's magic, it's artificial intelligence, etc." just doesn't fly with us. Personally I'm of the belief that *all* IPS systems are equally worthless, unless the goal is to just check a box on a form. Sure they will give you pretty graphs of script-kiddie attempts but that's just the noise in which the skilled attack will get lost. You have to do everything else right, you can't just plug the "magic box" inline and expect to relax. My 0.02. Michael Holstein Cleveland State University 2= From Patrick.Darden at p66.com Thu Feb 5 13:30:11 2015 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Thu, 5 Feb 2015 13:30:11 +0000 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <1423142005906.59768@csuohio.edu> Message-ID: <5f8f2108b6da4681b83ab961cfe13eb6@BRTEXMB02.phillips66.net> " Securing hosts/applications/services themselves is the way to protect them from compromise." Can't go wrong with defense in depth. I'd definitely throw securing routers in there, throw in firewalls, periodic internal scanning for idiot mistakes, audits, etc. I still think IPS/IDSes can be wielded to good effect in several different scenarios--e.g. just before the core switch (or spanning the core switch) of a PCN network, alerting to anything going on intra vs. inter. --p -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins Sent: Thursday, February 05, 2015 7:20 AM To: nanog at nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS On 5 Feb 2015, at 20:13, Michael O Holstein wrote: > Personally I'm of the belief that *all* IPS systems are equally > worthless, unless the goal is to just check a box on a form. Concur 100%. Securing hosts/applications/services themselves is the way to protect them from compromise. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Thu Feb 5 13:34:36 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 05 Feb 2015 20:34:36 +0700 Subject: Checkpoint IPS In-Reply-To: <000801d04143$57b9c0f0$072d42d0$@gmail.com> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> Message-ID: On 5 Feb 2015, at 19:57, Terry Baranski wrote: > I hate to be the bearer of bad news, but everything we do is > "artificial". There are no routers in nature, no IP packets, no fiber > optics. There is no such thing as "natural engineering" -- engineering > is "artificial" by definition. This isn't even worthy of comment, so I won't. > But there's no overstating the usefulness of a properly-tuned IPS for > attack prevention I've never heard a plausible anecdote, much less seen meaningful statistics, of these devices actually 'preventing' anything. I have, however, run into many, many situations in which these devices demonstrably degraded the security posture of network operators, particularly when placed in front of servers or broadband access networks. For example, they're laughably easy to DDoS due to state exhaustion - which is what is the main point of the presentation you reference. And the fact that well-known evasion techniques still work against these devices today, coupled with the undeniable proliferation of compromised hosts residing within networks supposedly 'protected' by these devices, militates against your proposition. ----------------------------------- Roland Dobbins From m.hallgren at free.fr Thu Feb 5 13:56:00 2015 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 05 Feb 2015 14:56:00 +0100 Subject: Checkpoint IPS In-Reply-To: <000801d04143$57b9c0f0$072d42d0$@gmail.com> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> Message-ID: <54D37670.5060005@free.fr> Le 05/02/2015 13:57, Terry Baranski a écrit : > On 5 Feb 2015, at 01:56, Michael Hallgren wrote: >> Le 04/02/2015 17:19, Roland Dobbins a écrit : >>> Real life limitations? >>> https://app.box.com/s/a3oqqlgwe15j8svojvzl >> Right ;-) Among many other nice ones, I like: >> >> `` ‘IPS’ devices require artificially-engineered topological symmetry- >> can have a negative impact on resiliency via path diversity.'' > Dang, I thought this quote was from an April 1st RFC when I first read it. > > I hate to be the bearer of bad news, but everything we do is "artificial". > There are no routers in nature, no IP packets, no fiber optics. There is no > such thing as "natural engineering" -- engineering is "artificial" by > definition. > > So when you're configuring artificially-engineered protocols on your > artificially-engineered router so that your artificially-engineered network > can transmit artificially-engineered packets, adding some extra > artificially-engineered logic to enforce symmetry won't break the bank, I > promise. And when done properly it has absolutely no impact on resilience > and path diversity, and will do you all the good in the world from a > troubleshooting perspective (those of you who operate networks). Depends on the underlying physical network... (which may be quite costly to ``fix''). mh > > The whole presentation is frankly just odd to me. It looks at one specific > CND thread (DDoS), and attempts to address it by throwing out the baby with > the bathwater. It says to eliminate state at all costs, but then at the end > advocates for reverse proxies -- which are stateful, and which therefore > create the same "problems" as firewalls and IPSs. > > The idea of ripping out firewall/IPS devices and replacing them with router > ACLs is something that, if I were an attacker, I would definitely encourage > all of my targets to do. Firewalls aren't so much the big issue -- one can > theoretically use router ACLs for basic L3/L4 blocks, though they scale > horribly from an O&M perspective, are more prone to configuration errors, > and their manageability is poor. But there's no overstating the usefulness > of a properly-tuned IPS for attack prevention, and the comment in the brief > comparing an IPS to "[Having] your email client set to alert you to incoming > mail" is so bizarre that I wouldn't even know how to counter it. > > (I know you're out there Roland and my intention isn't to get into a big > thing with you. But the artificial-engineering thing gave me a chuckle.) > > On 5 Feb 2015, at 02:49, Michael Hallgren wrote: >> Le 05/02/2015 08:01, Roland Dobbins a écrit : >>> The real question is, why 'inspect', at all? >> Yes, that's an even more interesting discussion! > Only if your assets aren't targets. :-) > > -Terry > > From m.hallgren at free.fr Thu Feb 5 14:06:12 2015 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 05 Feb 2015 15:06:12 +0100 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> Message-ID: <54D378D4.6040304@free.fr> Le 05/02/2015 14:15, jim deleskie a écrit : > mh, Hi there Jim :-) > > you know that forcing traffic to be symmetrical is evil, Voilà ! > and while backbone traffic and inspection don't play nice, there are > very legit reasons why, in many cases edge traffic must be open for > inspection. Yes, right, often some such `control' is on wish-lists. > I'm on my way to the office, feel free to ping me if you want to > discuss. Or maybe I could use it as a reason to come visit its been > a while since we've had a chance to vis-a-vis :) With pleasure! Yes, too long time... TTYS, mh > > > -jim > > On Thu, Feb 5, 2015 at 8:57 AM, Terry Baranski > > > wrote: > > On 5 Feb 2015, at 01:56, Michael Hallgren wrote: > > Le 04/02/2015 17:19, Roland Dobbins a écrit : > >> > >> Real life limitations? > >> https://app.box.com/s/a3oqqlgwe15j8svojvzl > > > > Right ;-) Among many other nice ones, I like: > > > > `` ‘IPS’ devices require artificially-engineered topological > symmetry- > > can have a negative impact on resiliency via path diversity.'' > > Dang, I thought this quote was from an April 1st RFC when I first > read it. > > I hate to be the bearer of bad news, but everything we do is > "artificial". > There are no routers in nature, no IP packets, no fiber optics. > There is no > such thing as "natural engineering" -- engineering is "artificial" by > definition. > > So when you're configuring artificially-engineered protocols on your > artificially-engineered router so that your > artificially-engineered network > can transmit artificially-engineered packets, adding some extra > artificially-engineered logic to enforce symmetry won't break the > bank, I > promise. And when done properly it has absolutely no impact on > resilience > and path diversity, and will do you all the good in the world from a > troubleshooting perspective (those of you who operate networks). > > The whole presentation is frankly just odd to me. It looks at one > specific > CND thread (DDoS), and attempts to address it by throwing out the > baby with > the bathwater. It says to eliminate state at all costs, but then > at the end > advocates for reverse proxies -- which are stateful, and which > therefore > create the same "problems" as firewalls and IPSs. > > The idea of ripping out firewall/IPS devices and replacing them > with router > ACLs is something that, if I were an attacker, I would definitely > encourage > all of my targets to do. Firewalls aren't so much the big issue -- > one can > theoretically use router ACLs for basic L3/L4 blocks, though they > scale > horribly from an O&M perspective, are more prone to configuration > errors, > and their manageability is poor. But there's no overstating the > usefulness > of a properly-tuned IPS for attack prevention, and the comment in > the brief > comparing an IPS to "[Having] your email client set to alert you > to incoming > mail" is so bizarre that I wouldn't even know how to counter it. > > (I know you're out there Roland and my intention isn't to get into > a big > thing with you. But the artificial-engineering thing gave me a > chuckle.) > > On 5 Feb 2015, at 02:49, Michael Hallgren wrote: > > Le 05/02/2015 08:01, Roland Dobbins a écrit : > >> > >> The real question is, why 'inspect', at all? > > > > Yes, that's an even more interesting discussion! > > Only if your assets aren't targets. :-) > > -Terry > > > From david at nines.nl Thu Feb 5 14:10:07 2015 From: david at nines.nl (David Jansen) Date: Thu, 5 Feb 2015 14:10:07 +0000 Subject: Dynamic routing on firewalls. Message-ID: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Hi, We have used dynamic routing on firewall in the old days. We did experience several severe outages due to this setup (OSPF en Cisco). As you will understand i’m not eager to go back to this solution but I am curious about your point of views. Is it advisory to so these days? Kind regards, David From m.hallgren at free.fr Thu Feb 5 14:11:52 2015 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 05 Feb 2015 15:11:52 +0100 Subject: Checkpoint IPS In-Reply-To: <000201d04147$afc28a30$0f479e90$@gmail.com> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr>, <000801d04143$57b9c0f0$072d42d0$@gmail.com> <1423142005906.59768@csuohio.edu> <000201d04147$afc28a30$0f479e90$@gmail.com> Message-ID: <54D37A28.2010301@free.fr> Le 05/02/2015 14:28, Terry Baranski a écrit : > On 5 Feb 2015, at 08:13, Michael Hallgren wrote: >> Sure they will give you pretty graphs of script-kiddie attempts but >> that's just the noise in which the skilled attack will get lost. No, Terry, I didn't write that ! :-) Cheers, mh > Sorry but this is not even in the neighborhood of what a > properly-implemented IPS does. > > I can certainly see why you think they're worthless though. :-) > > -Terry > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael O Holstein > Sent: Thursday, February 05, 2015 8:13 AM > To: nanog at nanog.org > Subject: Re: Checkpoint IPS > > >>> `` 'IPS' devices require artificially-engineered topological symmetry- >>> can have a negative impact on resiliency via path diversity.'' >> Dang, I thought this quote was from an April 1st RFC when I first read it. >> >> I hate to be the bearer of bad news, but everything we do is "artificial". >> There are no routers in nature, no IP packets, no fiber optics. There is no >> such thing as "natural engineering" -- engineering is "artificial" by >> definition. > You're forgetting that such things are rarely read (in time) by the people > that actually implement and use such a product .. that language is targeted > at the pointy-haired crowd. > Salespeople *hate* it when they get a technical resource instead of a > management one because "it's magic, it's artificial intelligence, etc." just > doesn't fly with us. > > Personally I'm of the belief that *all* IPS systems are equally worthless, > unless the goal is to just check a box on a form. Sure they will give you > pretty graphs of script-kiddie attempts but that's just the noise in which > the skilled attack will get lost. You have to do everything else right, you > can't just plug the "magic box" inline and expect to relax. > > My 0.02. > > Michael Holstein > Cleveland State University > 2= > From terry.baranski.list at gmail.com Thu Feb 5 14:31:49 2015 From: terry.baranski.list at gmail.com (Terry Baranski) Date: Thu, 5 Feb 2015 09:31:49 -0500 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> Message-ID: On Thu, Feb 5, 2015 at 8:34 AM, Roland Dobbins wrote: > I've never heard a plausible anecdote, much less seen meaningful statistics, > of these devices actually 'preventing' anything. People tend to hear what they want to hear. Surely your claim can't be that an IPS has never, in the history of Earth, prevented an attack or exploit. So it's unclear to me what you're actually trying to say here. > And the fact that well-known evasion techniques still work against these > devices today, coupled with the undeniable proliferation of compromised > hosts residing within networks supposedly 'protected' by these devices, > militates against your proposition. Your tendency of making blanket statements is somewhat baffling given the multitude of intricacies, details, and varying circumstances involved in a complex topic like this. To me, it's indicative of an overly-simplified and/or biased way of looking at things. In any case, go ahead and stick with your router ACLs and (stateful!) proxies. Different strokes. -Terry From eugen at imacandi.net Thu Feb 5 14:42:26 2015 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 5 Feb 2015 16:42:26 +0200 Subject: Dynamic routing on firewalls. In-Reply-To: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Message-ID: On Thu, Feb 5, 2015 at 4:10 PM, David Jansen wrote: > Hi, > > We have used dynamic routing on firewall in the old days. We did > experience several severe outages due to this setup (OSPF en Cisco). As you > will understand i’m not eager to go back to this solution but I am curious > about your point of views. > > Is it advisory to so these days? > > Any specific firewall in mind? As this depends from vendor to vendor. I've had some issues with OSPF and CheckPoint firewalls when the firewalls would be overloaded and started dropping packets at the interface level causing adjacencies to go down, but I solved this by using BGP instead and the routing issues went away. On Juniper things tend work OK. Other than this, make sure you don't run into asymmetric routing as connections might get dropped because the firewall does not know about them or packets arrive out of order and the firewall cannot reassemble all of them. From rps at maine.edu Thu Feb 5 14:51:28 2015 From: rps at maine.edu (Ray Soucy) Date: Thu, 5 Feb 2015 09:51:28 -0500 Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Message-ID: It all depends how much of the firewall functionality is implemented in CPU. The biggest problem is that firewalls that implement functionality in software usually saturate CPU when stressed (e.g. DOS) and routing protocols start dropping. I'm a strong believer in having a router that can do basic filtering in hardware (specifically uRPF) as the first line of defense in a DOS attack and then using a firewall behind that to reach your security policy goals. We have a pretty large network so we've expanded the concept of RTBH filtering internally and use a small ISR (currently 1841) to inject routes into our network to disable hosts using uRPF at the first router they hit. The entire thing is scripted and works very well at containing problematic hosts centrally. The other thing to watch out for IMHO is the NGFW hype. I haven't seen a NGFW that can actually do everything it claims to at the same time and meet advertised performance levels. You're much better off splitting up the workload and having a series of components architected to work with each other. On Thu, Feb 5, 2015 at 9:42 AM, Eugeniu Patrascu wrote: > On Thu, Feb 5, 2015 at 4:10 PM, David Jansen wrote: > >> Hi, >> >> We have used dynamic routing on firewall in the old days. We did >> experience several severe outages due to this setup (OSPF en Cisco). As you >> will understand i'm not eager to go back to this solution but I am curious >> about your point of views. >> >> Is it advisory to so these days? >> >> > Any specific firewall in mind? As this depends from vendor to vendor. > > I've had some issues with OSPF and CheckPoint firewalls when the firewalls > would be overloaded and started dropping packets at the interface level > causing adjacencies to go down, but I solved this by using BGP instead and > the routing issues went away. > > On Juniper things tend work OK. > > Other than this, make sure you don't run into asymmetric routing as > connections might get dropped because the firewall does not know about them > or packets arrive out of order and the firewall cannot reassemble all of > them. -- 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 david at nines.nl Thu Feb 5 14:52:49 2015 From: david at nines.nl (David Jansen) Date: Thu, 5 Feb 2015 14:52:49 +0000 Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Message-ID: <495916A5-56A9-4B6D-898C-C500ED5DCE9B@nines.nl> Hi Eugeniu, On 05 Feb 2015, at 15:42, Eugeniu Patrascu > wrote: Any specific firewall in mind? As this depends from vendor to vendor. We are using Cisco (ASA). I've had some issues with OSPF and CheckPoint firewalls when the firewalls would be overloaded and started dropping packets at the interface level causing adjacencies to go down, but I solved this by using BGP instead and the routing issues went away. The last time we were working with OSPF and Cisco was on a fwsm (cisco pix blade). Interesting to know that more vendors do have problems with OSPF on firewalls. Also good to hear that BGP seemed to have solved your problem. Kind regards, David From ml at kenweb.org Thu Feb 5 14:53:24 2015 From: ml at kenweb.org (ML) Date: Thu, 05 Feb 2015 09:53:24 -0500 Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Message-ID: <54D383E4.40502@kenweb.org> On 2/5/2015 9:42 AM, Eugeniu Patrascu wrote: > On Juniper things tend work OK. Other than this, make sure you don't > run into asymmetric routing as connections might get dropped because > the firewall does not know about them or packets arrive out of order > and the firewall cannot reassemble all of them. Agreed. Assymmetric routing is not your friend unless you plan accordingly. I use OSPF and BGP quite a bit on Juniper SRX. Works great. From david at nines.nl Thu Feb 5 14:57:34 2015 From: david at nines.nl (David Jansen) Date: Thu, 5 Feb 2015 14:57:34 +0000 Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Message-ID: <92E41E0D-B595-4521-A906-7EABF3127E3B@nines.nl> Hi Ray On 05 Feb 2015, at 15:51, Ray Soucy > wrote: You're much better off splitting up the workload and having a series of components architected to work with each other. Especially in case of datacenter- or enterprise solutions i do agree. Thanks From nick at foobar.org Thu Feb 5 15:12:57 2015 From: nick at foobar.org (Nick Hilliard) Date: Thu, 05 Feb 2015 15:12:57 +0000 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> Message-ID: <54D38879.708@foobar.org> On 05/02/2015 13:15, jim deleskie wrote: > you know that forcing traffic to be symmetrical is evil it's not evil; it's stupid because enforcing symmetry creates a potentially unnatural stress in a network which will revert to asymmetry, given half a chance. Nick From Valdis.Kletnieks at vt.edu Thu Feb 5 16:43:58 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 05 Feb 2015 11:43:58 -0500 Subject: Checkpoint IPS In-Reply-To: Your message of "Thu, 05 Feb 2015 07:51:56 +0100." <54D3130C.6010003@free.fr> References: <54CF733C.1030205@free.fr> <54D0EC39.40209@free.fr> <54D3130C.6010003@free.fr> Message-ID: <3732.1423154638@turing-police.cc.vt.edu> On Thu, 05 Feb 2015 07:51:56 +0100, Michael Hallgren said: > I know. However, I fail to see symmetric traffic flow as ``natural'', > apart from maybe at the extreme edge of a network. So, need another > inspection strategy I think. Firewalls aren't much help except at that extreme edge, anyhow. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Feb 5 16:46:55 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 05 Feb 2015 11:46:55 -0500 Subject: Checkpoint IPS In-Reply-To: Your message of "Thu, 05 Feb 2015 09:31:49 -0500." References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> Message-ID: <3923.1423154815@turing-police.cc.vt.edu> On Thu, 05 Feb 2015 09:31:49 -0500, Terry Baranski said: > People tend to hear what they want to hear. Surely your claim can't be that > an IPS has never, in the history of Earth, prevented an attack or exploit. > So it's unclear to me what you're actually trying to say here. Count up the number of *actual* attacks they have stopped that wouldn't have been stopped otherwise, and contrast it to the number of times they've been used as the *basis* for an attack (DDoS via state exhaustion, for starters) or their failure has caused operational issues. Remember that one of the three security pillars is "Availability". Still think they're a good idea? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Jack.Stonebraker at mygrande.com Thu Feb 5 17:24:59 2015 From: Jack.Stonebraker at mygrande.com (Jack Stonebraker) Date: Thu, 5 Feb 2015 17:24:59 +0000 Subject: Input Regarding Cogent and NTT Message-ID: <1C88157B8801CB448C108286C81ECB631B8C4F@SRV-SAM-MBOX02.lan.thrifty.net> My organization is currently shopping for some additional Transit Capacity to augment our existing interconnects. We've got around 8 distinct AS's that we're receiving transit routes from, followed by a handful of Public IX's and Private PNI's to AS's that warrant them. That said, the networks that are on our radar are Cogent and NTT. I've done some due diligence poking around on their Looking Glass, but I'd love to hear any user experiences from the community, both from a Layer 3 Perspective, as well as an Operational Perspective (Working with the businesses themselves). Feel free to contact me off-list and thanks in advance for your time. [cid:image002.jpg at 01CFE2F3.A6F973D0] Jack Stonebraker | Sr. IP Network Engineer (512) 878-5627 | jack.stonebraker at mygrande.com Grande Communications Networks 401 Carlson Circle | San Marcos, Texas | 78666 From ray at oneunified.net Thu Feb 5 17:38:13 2015 From: ray at oneunified.net (Raymond Burkholder) Date: Thu, 5 Feb 2015 13:38:13 -0400 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> Message-ID: <08cd01d0416a$84c92d20$8e5b8760$@oneunified.net> > > But there's no overstating the usefulness of a properly-tuned IPS for > > attack prevention > > I've never heard a plausible anecdote, much less seen meaningful statistics, > of these devices actually 'preventing' anything. I think it depends upon where you put them, and whether or not you have skilled people involved. Given good placement, and experienced management, I have seen the usefulness of these devices ... by personally reviewing the logs and being the recipient of drop alerts of the devices in terms of what they can reject. > > I have, however, run into many, many situations in which these devices > demonstrably degraded the security posture of network operators, > particularly when placed in front of servers or broadband access networks. > For example, they're laughably easy to DDoS due to state exhaustion - which > is what is the main point of the presentation you reference. Sometimes we get in to corner cases too easily where the negative is easily applied. Yes, they can be DDoS'd. Yes they can be useless in the hands of the unskilled and unknowing. On the other hand, given good placement in strategic places, and maintained appropriately, they can live up the their expectations. > > And the fact that well-known evasion techniques still work against these > devices today, coupled with the undeniable proliferation of compromised > hosts residing within networks supposedly 'protected' by these devices, > militates against your proposition. Well.... again, yes, they may not get all zero-day exploits. That is another corner case. But they can certainly prevent getting hit by the same old stuff over and over again. I've seen drop rules for the Bash issue, and the openssl issue put in place, and when implemented, prevent the further spread of the malicious payloads. There must some sort of value in that? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From rdobbins at arbor.net Thu Feb 5 17:47:54 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 06 Feb 2015 00:47:54 +0700 Subject: Checkpoint IPS In-Reply-To: <08cd01d0416a$84c92d20$8e5b8760$@oneunified.net> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <08cd01d0416a$84c92d20$8e5b8760$@oneunified.net> Message-ID: On 6 Feb 2015, at 0:38, Raymond Burkholder wrote: > There must some sort of value in that? No - patch the servers. ----------------------------------- Roland Dobbins From santiago.martinez.uk at gmail.com Thu Feb 5 15:06:00 2015 From: santiago.martinez.uk at gmail.com (santiago martinez) Date: Thu, 5 Feb 2015 15:06:00 +0000 Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Message-ID: Hi, We are running Juniper SRX5000 family with around 40ish routing-instances, most of them using OSPFv2 without any issues. The RIBs are not too big, just a couple of them with thousands routes. I know that some guys are testing a similar environment on Fortigates and I'm not aware of any issues with routing so far. We also have SRX's running BGP+BFD (srx240) and again no issues at all. As Eugeniu mentioned, just be careful with the asymmetric routing, then is straight forward. Hope it helps. Santiago On Thu, Feb 5, 2015 at 2:42 PM, Eugeniu Patrascu wrote: > On Thu, Feb 5, 2015 at 4:10 PM, David Jansen wrote: > > > Hi, > > > > We have used dynamic routing on firewall in the old days. We did > > experience several severe outages due to this setup (OSPF en Cisco). As > you > > will understand i’m not eager to go back to this solution but I am > curious > > about your point of views. > > > > Is it advisory to so these days? > > > > > Any specific firewall in mind? As this depends from vendor to vendor. > > I've had some issues with OSPF and CheckPoint firewalls when the firewalls > would be overloaded and started dropping packets at the interface level > causing adjacencies to go down, but I solved this by using BGP instead and > the routing issues went away. > > On Juniper things tend work OK. > > Other than this, make sure you don't run into asymmetric routing as > connections might get dropped because the firewall does not know about them > or packets arrive out of order and the firewall cannot reassemble all of > them. > From mhuff at ox.com Thu Feb 5 17:55:53 2015 From: mhuff at ox.com (Matthew Huff) Date: Thu, 5 Feb 2015 17:55:53 +0000 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <08cd01d0416a$84c92d20$8e5b8760$@oneunified.net> Message-ID: What if you are a hosting company and those aren't your servers to patch? What about the time to patch 200+ servers versus configuring one location? What if you have to schedule the staff and maintenance window to patch the servers? What if you have legacy equipment that you must continue using, but the vendor is slow to provide the patch. There is a huge difference in what is good network/security designs between content providers, transit networks, eyeball networks, corporate networks, universities, etc... One size doesn't fit all. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 aim: matthewbhuff        | Fax:   914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins Sent: Thursday, February 5, 2015 12:48 PM To: nanog at nanog.org Subject: Re: Checkpoint IPS On 6 Feb 2015, at 0:38, Raymond Burkholder wrote: > There must some sort of value in that? No - patch the servers. ----------------------------------- Roland Dobbins From phiber at phiber.org Thu Feb 5 18:00:37 2015 From: phiber at phiber.org (Christopher Rogers) Date: Thu, 5 Feb 2015 10:00:37 -0800 Subject: Input Regarding Cogent and NTT In-Reply-To: <1C88157B8801CB448C108286C81ECB631B8C4F@SRV-SAM-MBOX02.lan.thrifty.net> References: <1C88157B8801CB448C108286C81ECB631B8C4F@SRV-SAM-MBOX02.lan.thrifty.net> Message-ID: NTT is awesome. Extremely responsive, sales guys aren't pushy, noc is great, and lots of NTT guys are here on nanog. Cogent is not. Their sales guys love to scrape whois records too, and won't leave you the hell alone. I've used both extensively, and now typically just avoid cogent. -chris Am 05.02.2015 09:26 schrieb "Jack Stonebraker" < Jack.Stonebraker at mygrande.com>: > My organization is currently shopping for some additional Transit Capacity > to augment our existing interconnects. We've got around 8 distinct AS's > that we're receiving transit routes from, followed by a handful of Public > IX's and Private PNI's to AS's that warrant them. That said, the networks > that are on our radar are Cogent and NTT. I've done some due diligence > poking around on their Looking Glass, but I'd love to hear any user > experiences from the community, both from a Layer 3 Perspective, as well as > an Operational Perspective (Working with the businesses themselves). Feel > free to contact me off-list and thanks in advance for your time. > > [cid:image002.jpg at 01CFE2F3.A6F973D0] > > > Jack Stonebraker | Sr. IP Network Engineer > (512) 878-5627 | jack.stonebraker at mygrande.com john.hogan at mygrande.com> > Grande Communications Networks > 401 Carlson Circle | San Marcos, Texas | 78666 > > > > > From contact at winterei.se Thu Feb 5 18:10:10 2015 From: contact at winterei.se (Paul S.) Date: Fri, 06 Feb 2015 03:10:10 +0900 Subject: Input Regarding Cogent and NTT In-Reply-To: References: <1C88157B8801CB448C108286C81ECB631B8C4F@SRV-SAM-MBOX02.lan.thrifty.net> Message-ID: <54D3B202.8030204@winterei.se> As a current Cogent customer, my experience on the service side of things is similar. Very responsive (I called on a Sunday and had someone with good enough clue + router access pick up instantly.) NOC is competent, and my sales guys (I've had two so far) are not pushy at all. I don't have any real complaints. I'd rate them higher than most of my other upstreams as far as NOC competency goes. On 2/6/2015 午前 03:00, Christopher Rogers wrote: > NTT is awesome. Extremely responsive, sales guys aren't pushy, noc is > great, and lots of NTT guys are here on nanog. > > Cogent is not. Their sales guys love to scrape whois records too, and > won't leave you the hell alone. > > I've used both extensively, and now typically just avoid cogent. > > -chris > Am 05.02.2015 09:26 schrieb "Jack Stonebraker" < > Jack.Stonebraker at mygrande.com>: > >> My organization is currently shopping for some additional Transit Capacity >> to augment our existing interconnects. We've got around 8 distinct AS's >> that we're receiving transit routes from, followed by a handful of Public >> IX's and Private PNI's to AS's that warrant them. That said, the networks >> that are on our radar are Cogent and NTT. I've done some due diligence >> poking around on their Looking Glass, but I'd love to hear any user >> experiences from the community, both from a Layer 3 Perspective, as well as >> an Operational Perspective (Working with the businesses themselves). Feel >> free to contact me off-list and thanks in advance for your time. >> >> [cid:image002.jpg at 01CFE2F3.A6F973D0] >> >> >> Jack Stonebraker | Sr. IP Network Engineer >> (512) 878-5627 | jack.stonebraker at mygrande.com> john.hogan at mygrande.com> >> Grande Communications Networks >> 401 Carlson Circle | San Marcos, Texas | 78666 >> >> >> >> >> From rdobbins at arbor.net Thu Feb 5 18:11:24 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 06 Feb 2015 01:11:24 +0700 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <08cd01d0416a$84c92d20$8e5b8760$@oneunified.net> Message-ID: <23BD3BAB-AC30-4D4C-8A96-B4CEA39A610D@arbor.net> On 6 Feb 2015, at 0:55, Matthew Huff wrote: > What if you are a hosting company and those aren't your servers to > patch? Then it isn't the operator's problem. > What about the time to patch 200+ servers versus configuring one > location? Operators should have sufficient automation to do this quickly. If not, they're Doing It Wrong. > What if you have to schedule the staff and maintenance window to patch > the servers? See above. > What if you have legacy equipment that you must continue using, but > the vendor is slow to provide the patch. There are other ways (reverse proxies, on-box systems like ModSecurity, et. al.); or take them offline. ----------------------------------- Roland Dobbins From mhuff at ox.com Thu Feb 5 18:26:18 2015 From: mhuff at ox.com (Matthew Huff) Date: Thu, 5 Feb 2015 18:26:18 +0000 Subject: Checkpoint IPS In-Reply-To: <23BD3BAB-AC30-4D4C-8A96-B4CEA39A610D@arbor.net> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <08cd01d0416a$84c92d20$8e5b8760$@oneunified.net> <23BD3BAB-AC30-4D4C-8A96-B4CEA39A610D@arbor.net> Message-ID: <05b5e0a1b6964a9ea15cdbd04166d1c5@pur-vm-exch13n1.ox.com> You make so many assumptions, it completely negates any reasonable point you are trying to make: > There are other ways (reverse proxies, on-box systems like ModSecurity, > et. al.); or take them offline. What if the box isn't Linux? What if it isn't a web server. What if proxies don't work well with the protocol the boxes uses. What if it's an appliance a business unit made you setup. There a thousands of permutations like that. Many times you don't get to make the correct choices, you have to work with what you have. Any IPS, statefull firewall, application level gateways, proxies, etc. have their places. In a content provider network (facebook, etc...) only using stateless protection because of massive DDOS is a reasonable argument. But like I said, one size doesn't fit all, or in this case, many. Like it's been said before, I strongly support my competitors following your advice. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 aim: matthewbhuff        | Fax:   914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins Sent: Thursday, February 5, 2015 1:11 PM To: nanog at nanog.org Subject: Re: Checkpoint IPS On 6 Feb 2015, at 0:55, Matthew Huff wrote: > What if you are a hosting company and those aren't your servers to > patch? Then it isn't the operator's problem. > What about the time to patch 200+ servers versus configuring one > location? Operators should have sufficient automation to do this quickly. If not, they're Doing It Wrong. > What if you have to schedule the staff and maintenance window to patch > the servers? See above. > What if you have legacy equipment that you must continue using, but > the vendor is slow to provide the patch. There are other ways (reverse proxies, on-box systems like ModSecurity, et. al.); or take them offline. ----------------------------------- Roland Dobbins From nanog at ics-il.net Thu Feb 5 18:29:42 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 5 Feb 2015 12:29:42 -0600 (CST) Subject: Input Regarding Cogent and NTT In-Reply-To: <1C88157B8801CB448C108286C81ECB631B8C4F@SRV-SAM-MBOX02.lan.thrifty.net> Message-ID: <18569385.12790.1423160951030.JavaMail.mhammett@ThunderFuck> A lot of people knock Cogent, but the best way to get to Cogent's customer's is probably through Cogent. Given that they do have a very large network, they're worth picking up even if you only use them for customer routes. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Jack Stonebraker" To: nanog at nanog.org Sent: Thursday, February 5, 2015 11:24:59 AM Subject: Input Regarding Cogent and NTT My organization is currently shopping for some additional Transit Capacity to augment our existing interconnects. We've got around 8 distinct AS's that we're receiving transit routes from, followed by a handful of Public IX's and Private PNI's to AS's that warrant them. That said, the networks that are on our radar are Cogent and NTT. I've done some due diligence poking around on their Looking Glass, but I'd love to hear any user experiences from the community, both from a Layer 3 Perspective, as well as an Operational Perspective (Working with the businesses themselves). Feel free to contact me off-list and thanks in advance for your time. [cid:image002.jpg at 01CFE2F3.A6F973D0] Jack Stonebraker | Sr. IP Network Engineer (512) 878-5627 | jack.stonebraker at mygrande.com Grande Communications Networks 401 Carlson Circle | San Marcos, Texas | 78666 From rdobbins at arbor.net Thu Feb 5 18:40:49 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 06 Feb 2015 01:40:49 +0700 Subject: Checkpoint IPS In-Reply-To: <05b5e0a1b6964a9ea15cdbd04166d1c5@pur-vm-exch13n1.ox.com> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <08cd01d0416a$84c92d20$8e5b8760$@oneunified.net> <23BD3BAB-AC30-4D4C-8A96-B4CEA39A610D@arbor.net> <05b5e0a1b6964a9ea15cdbd04166d1c5@pur-vm-exch13n1.ox.com> Message-ID: <520EE96E-4248-4490-8981-996BFFC597DC@arbor.net> On 6 Feb 2015, at 1:26, Matthew Huff wrote: > Like it's been said before, I strongly support my competitors > following your advice. Sorry - I've done the jobs, all of them. They can be done properly, and are done properly by clueful operators. Oh, and what are operators who deploy these things supposed to do about *vulnerabilities in these devices themselves*? That's a huge problem, they present a juicy attack surface, and exploits are discovered regularly. That's in the presentation, as well. I've heard these same tired arguments over and over again. Folks tend to change their tune when their entire production infrastructure is rendered unavailable by a tiny DDoS which could be sourced from a single smartphone; it's just sad that so many are only ready to listen and learn after they've suffered serious production-impacting outages. If all it took to achieve *real* security - as opposed to 'compliance' or vendor marketing 'security' - were to write a check or cut a P.O. and drop some middlebox/middleblade in the network, we wouldn't be in the permanent state of security emergency in which we find ourselves. *Real* security mostly consists of *doing things*. It requires skilled, experienced people who have both broad and deep expertise across the entire OSI model, are well-versed in architecture and the operational arts, and who understand all the implications of scale. Unfortunately, such people are relatively rare, even within the self-selected ranks of network operators - as several posts on this thread clearly demonstrate. ----------------------------------- Roland Dobbins From rmayer at nerd-residenz.de Thu Feb 5 18:49:35 2015 From: rmayer at nerd-residenz.de (Ralph J.Mayer) Date: Thu, 5 Feb 2015 19:49:35 +0100 Subject: Dynamic routing on firewalls. In-Reply-To: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Message-ID: Hi David, a router is a router and a firewall is a firewall. Especially a Cisco ASA is no router, period. A router in front of the firewall is my choice, it also keeps broadcasts from the firewall + can do uRPF. rm From patrick at ianai.net Thu Feb 5 18:54:43 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 5 Feb 2015 12:54:43 -0600 Subject: Input Regarding Cogent and NTT In-Reply-To: <18569385.12790.1423160951030.JavaMail.mhammett@ThunderFuck> References: <18569385.12790.1423160951030.JavaMail.mhammett@ThunderFuck> Message-ID: <5A91D901-A935-4659-A7BB-73DF1D1D6E0A@ianai.net> By that logic, and giving you the benefit of the doubt that you follow your own advice, you have 15-20 upstreams? I've never tried that on a standard network with BGP as the only tool. See any interesting operational stuff with that many upstreams? Also, while many people knock Cogent, I would submit that many people have bad first-hand experiences with Cogent (including me). Every network has its bad days. Even the best companies screw customers from time-to-time. But the preponderance of evidence is a useful guidepost. Cogent is large, but does not have even half the customers NTT has. Do "lots of people knock NTT"? Given NTT's much larger number of customers, shouldn't that mean they have more knocks? If not, I submit the disparity is a useful datapoint when choosing a provider. -- TTFN, patrick Composed on a virtual keyboard, please forgive typos. > On Feb 5, 2015, at 12:29, Mike Hammett wrote: > > A lot of people knock Cogent, but the best way to get to Cogent's customer's is probably through Cogent. Given that they do have a very large network, they're worth picking up even if you only use them for customer routes. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Jack Stonebraker" > To: nanog at nanog.org > Sent: Thursday, February 5, 2015 11:24:59 AM > Subject: Input Regarding Cogent and NTT > > My organization is currently shopping for some additional Transit Capacity to augment our existing interconnects. We've got around 8 distinct AS's that we're receiving transit routes from, followed by a handful of Public IX's and Private PNI's to AS's that warrant them. That said, the networks that are on our radar are Cogent and NTT. I've done some due diligence poking around on their Looking Glass, but I'd love to hear any user experiences from the community, both from a Layer 3 Perspective, as well as an Operational Perspective (Working with the businesses themselves). Feel free to contact me off-list and thanks in advance for your time. > > [cid:image002.jpg at 01CFE2F3.A6F973D0] > > > Jack Stonebraker | Sr. IP Network Engineer > (512) 878-5627 | jack.stonebraker at mygrande.com > Grande Communications Networks > 401 Carlson Circle | San Marcos, Texas | 78666 > > > > From nanog at ics-il.net Thu Feb 5 19:13:57 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 5 Feb 2015 13:13:57 -0600 (CST) Subject: Input Regarding Cogent and NTT In-Reply-To: <5A91D901-A935-4659-A7BB-73DF1D1D6E0A@ianai.net> Message-ID: <6381098.12911.1423163603350.JavaMail.mhammett@ThunderFuck> Working on it. ;-) Being an eyeball network, most of my traffic just goes to NetFlix, Akamai, LimeLight, FaceBook, Google, etc. anyway. Peer what you can peer, Cogent for customer routes, then grab a couple nicer carriers and call it a day. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Patrick W. Gilmore" To: nanog at nanog.org Sent: Thursday, February 5, 2015 12:54:43 PM Subject: Re: Input Regarding Cogent and NTT By that logic, and giving you the benefit of the doubt that you follow your own advice, you have 15-20 upstreams? I've never tried that on a standard network with BGP as the only tool. See any interesting operational stuff with that many upstreams? Also, while many people knock Cogent, I would submit that many people have bad first-hand experiences with Cogent (including me). Every network has its bad days. Even the best companies screw customers from time-to-time. But the preponderance of evidence is a useful guidepost. Cogent is large, but does not have even half the customers NTT has. Do "lots of people knock NTT"? Given NTT's much larger number of customers, shouldn't that mean they have more knocks? If not, I submit the disparity is a useful datapoint when choosing a provider. -- TTFN, patrick Composed on a virtual keyboard, please forgive typos. > On Feb 5, 2015, at 12:29, Mike Hammett wrote: > > A lot of people knock Cogent, but the best way to get to Cogent's customer's is probably through Cogent. Given that they do have a very large network, they're worth picking up even if you only use them for customer routes. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Jack Stonebraker" > To: nanog at nanog.org > Sent: Thursday, February 5, 2015 11:24:59 AM > Subject: Input Regarding Cogent and NTT > > My organization is currently shopping for some additional Transit Capacity to augment our existing interconnects. We've got around 8 distinct AS's that we're receiving transit routes from, followed by a handful of Public IX's and Private PNI's to AS's that warrant them. That said, the networks that are on our radar are Cogent and NTT. I've done some due diligence poking around on their Looking Glass, but I'd love to hear any user experiences from the community, both from a Layer 3 Perspective, as well as an Operational Perspective (Working with the businesses themselves). Feel free to contact me off-list and thanks in advance for your time. > > [cid:image002.jpg at 01CFE2F3.A6F973D0] > > > Jack Stonebraker | Sr. IP Network Engineer > (512) 878-5627 | jack.stonebraker at mygrande.com > Grande Communications Networks > 401 Carlson Circle | San Marcos, Texas | 78666 > > > > From owen at delong.com Thu Feb 5 19:15:23 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Feb 2015 15:15:23 -0400 Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Message-ID: Some Juniper models actually do a very good job of being both. In reality, a Firewall _IS_ a router, even if it's a bad one. Anything that moves packets from one interface to another is a router. Of course, the support for routing protocols is a useful feature in a router and one of the areas where firewalls often fall short. Where you want to put things (in front, behind, etc.) really depends on your topology and the problem you are trying to solve. Personally, I like to keep the firewalls as close to the end hosts as possible. This tends to greatly simplify security policies and make them MUCH easier (and more reliable) to audit. Owen > On Feb 5, 2015, at 2:49 PM, Ralph J.Mayer wrote: > > Hi David, > > a router is a router and a firewall is a firewall. > > Especially a Cisco ASA is no router, period. > > A router in front of the firewall is my choice, it also keeps broadcasts from the firewall + can do uRPF. > > > rm From terry.baranski.list at gmail.com Thu Feb 5 19:26:07 2015 From: terry.baranski.list at gmail.com (Terry Baranski) Date: Thu, 5 Feb 2015 14:26:07 -0500 Subject: Checkpoint IPS In-Reply-To: <3923.1423154815@turing-police.cc.vt.edu> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <3923.1423154815@turing-police.cc.vt.edu> Message-ID: On 6 Feb 2015, at 11:46, Valdis Kletnieks wrote: > Count up the number of *actual* attacks they have stopped > that wouldn't have been stopped otherwise Many. > and contrast it > to the number of times they've been used as the *basis* for > an attack (DDoS via state exhaustion, for starters) Zero, on my networks. > or their failure has caused operational issues. Zero, on my networks. Unless "operation issues" means traffic fails over without a hitch. > Still think they're a good idea? Yep. And thanks for asking. If you can't deploy IPS's in such a way that they don't make your network less secure via DDoS susceptibility, or reduce availability due to non-existent or subpar redundancy/survivability engineering, then you shouldn't deploy IPS's. -Terry On Thu, Feb 5, 2015 at 11:46 AM, wrote: > On Thu, 05 Feb 2015 09:31:49 -0500, Terry Baranski said: > > > People tend to hear what they want to hear. Surely your claim can't be > that > > an IPS has never, in the history of Earth, prevented an attack or > exploit. > > So it's unclear to me what you're actually trying to say here. > > Count up the number of *actual* attacks they have stopped that wouldn't > have been stopped otherwise, and contrast it to the number of times they've > been used as the *basis* for an attack (DDoS via state exhaustion, for > starters) > or their failure has caused operational issues. Remember that one of the > three security pillars is "Availability". > > Still think they're a good idea? > From terry.baranski.list at gmail.com Thu Feb 5 19:29:39 2015 From: terry.baranski.list at gmail.com (Terry Baranski) Date: Thu, 5 Feb 2015 14:29:39 -0500 Subject: Checkpoint IPS In-Reply-To: <520EE96E-4248-4490-8981-996BFFC597DC@arbor.net> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <08cd01d0416a$84c92d20$8e5b8760$@oneunified.net> <23BD3BAB-AC30-4D4C-8A96-B4CEA39A610D@arbor.net> <05b5e0a1b6964a9ea15cdbd04166d1c5@pur-vm-exch13n1.ox.com> <520EE96E-4248-4490-8981-996BFFC597DC@arbor.net> Message-ID: On 6 Feb 2015, at 1:40pm, Roland Dobbins wrote: > *Real* security mostly consists of *doing things*. It requires skilled, experienced > people who have both broad and deep expertise across the entire OSI model, are > well-versed in architecture and the operational arts, and who understand all the > implications of scale. And if there's one person qualified to comment on what "real security" is, it's a person who has "never heard a plausible anecdote of [IPS] devices actually 'preventing' anything." :-) -Terry On Thu, Feb 5, 2015 at 1:40 PM, Roland Dobbins wrote: > > On 6 Feb 2015, at 1:26, Matthew Huff wrote: > > Like it's been said before, I strongly support my competitors following >> your advice. >> > > Sorry - I've done the jobs, all of them. They can be done properly, and > are done properly by clueful operators. > > Oh, and what are operators who deploy these things supposed to do about > *vulnerabilities in these devices themselves*? That's a huge problem, they > present a juicy attack surface, and exploits are discovered regularly. > That's in the presentation, as well. > > I've heard these same tired arguments over and over again. Folks tend to > change their tune when their entire production infrastructure is rendered > unavailable by a tiny DDoS which could be sourced from a single smartphone; > it's just sad that so many are only ready to listen and learn after they've > suffered serious production-impacting outages. > > If all it took to achieve *real* security - as opposed to 'compliance' or > vendor marketing 'security' - were to write a check or cut a P.O. and drop > some middlebox/middleblade in the network, we wouldn't be in the permanent > state of security emergency in which we find ourselves. > > *Real* security mostly consists of *doing things*. It requires skilled, > experienced people who have both broad and deep expertise across the entire > OSI model, are well-versed in architecture and the operational arts, and > who understand all the implications of scale. > > Unfortunately, such people are relatively rare, even within the > self-selected ranks of network operators - as several posts on this thread > clearly demonstrate. > > ----------------------------------- > Roland Dobbins > From magicsata at gmail.com Thu Feb 5 19:35:13 2015 From: magicsata at gmail.com (Alistair Mackenzie) Date: Thu, 5 Feb 2015 19:35:13 +0000 Subject: Input Regarding Cogent and NTT In-Reply-To: <6381098.12911.1423163603350.JavaMail.mhammett@ThunderFuck> References: <5A91D901-A935-4659-A7BB-73DF1D1D6E0A@ianai.net> <6381098.12911.1423163603350.JavaMail.mhammett@ThunderFuck> Message-ID: Don't be surprised if cogent contact you for even posting this. They did it to me when I asked for hibernia. On 5 Feb 2015 19:16, "Mike Hammett" wrote: > Working on it. ;-) > > Being an eyeball network, most of my traffic just goes to NetFlix, Akamai, > LimeLight, FaceBook, Google, etc. anyway. Peer what you can peer, Cogent > for customer routes, then grab a couple nicer carriers and call it a day. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Patrick W. Gilmore" > To: nanog at nanog.org > Sent: Thursday, February 5, 2015 12:54:43 PM > Subject: Re: Input Regarding Cogent and NTT > > By that logic, and giving you the benefit of the doubt that you follow > your own advice, you have 15-20 upstreams? > > I've never tried that on a standard network with BGP as the only tool. See > any interesting operational stuff with that many upstreams? > > Also, while many people knock Cogent, I would submit that many people have > bad first-hand experiences with Cogent (including me). > > Every network has its bad days. Even the best companies screw customers > from time-to-time. But the preponderance of evidence is a useful guidepost. > Cogent is large, but does not have even half the customers NTT has. Do > "lots of people knock NTT"? Given NTT's much larger number of customers, > shouldn't that mean they have more knocks? > > If not, I submit the disparity is a useful datapoint when choosing a > provider. > > -- > TTFN, > patrick > > Composed on a virtual keyboard, please forgive typos. > > > > On Feb 5, 2015, at 12:29, Mike Hammett wrote: > > > > A lot of people knock Cogent, but the best way to get to Cogent's > customer's is probably through Cogent. Given that they do have a very large > network, they're worth picking up even if you only use them for customer > routes. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > > > > > ----- Original Message ----- > > > > From: "Jack Stonebraker" > > To: nanog at nanog.org > > Sent: Thursday, February 5, 2015 11:24:59 AM > > Subject: Input Regarding Cogent and NTT > > > > My organization is currently shopping for some additional Transit > Capacity to augment our existing interconnects. We've got around 8 distinct > AS's that we're receiving transit routes from, followed by a handful of > Public IX's and Private PNI's to AS's that warrant them. That said, the > networks that are on our radar are Cogent and NTT. I've done some due > diligence poking around on their Looking Glass, but I'd love to hear any > user experiences from the community, both from a Layer 3 Perspective, as > well as an Operational Perspective (Working with the businesses > themselves). Feel free to contact me off-list and thanks in advance for > your time. > > > > [cid:image002.jpg at 01CFE2F3.A6F973D0] > > > > > > Jack Stonebraker | Sr. IP Network Engineer > > (512) 878-5627 | jack.stonebraker at mygrande.com john.hogan at mygrande.com> > > Grande Communications Networks > > 401 Carlson Circle | San Marcos, Texas | 78666 > > > > > > > > > > From nanog at ics-il.net Thu Feb 5 19:41:44 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 5 Feb 2015 13:41:44 -0600 (CST) Subject: Input Regarding Cogent and NTT In-Reply-To: Message-ID: <19213156.13034.1423165265508.JavaMail.mhammett@ThunderFuck> They are persistent, but by no means the most persistent vendor I work with. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Alistair Mackenzie" Cc: "NANOG" Sent: Thursday, February 5, 2015 1:35:13 PM Subject: Re: Input Regarding Cogent and NTT Don't be surprised if cogent contact you for even posting this. They did it to me when I asked for hibernia. On 5 Feb 2015 19:16, "Mike Hammett" wrote: > Working on it. ;-) > > Being an eyeball network, most of my traffic just goes to NetFlix, Akamai, > LimeLight, FaceBook, Google, etc. anyway. Peer what you can peer, Cogent > for customer routes, then grab a couple nicer carriers and call it a day. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Patrick W. Gilmore" > To: nanog at nanog.org > Sent: Thursday, February 5, 2015 12:54:43 PM > Subject: Re: Input Regarding Cogent and NTT > > By that logic, and giving you the benefit of the doubt that you follow > your own advice, you have 15-20 upstreams? > > I've never tried that on a standard network with BGP as the only tool. See > any interesting operational stuff with that many upstreams? > > Also, while many people knock Cogent, I would submit that many people have > bad first-hand experiences with Cogent (including me). > > Every network has its bad days. Even the best companies screw customers > from time-to-time. But the preponderance of evidence is a useful guidepost. > Cogent is large, but does not have even half the customers NTT has. Do > "lots of people knock NTT"? Given NTT's much larger number of customers, > shouldn't that mean they have more knocks? > > If not, I submit the disparity is a useful datapoint when choosing a > provider. > > -- > TTFN, > patrick > > Composed on a virtual keyboard, please forgive typos. > > > > On Feb 5, 2015, at 12:29, Mike Hammett wrote: > > > > A lot of people knock Cogent, but the best way to get to Cogent's > customer's is probably through Cogent. Given that they do have a very large > network, they're worth picking up even if you only use them for customer > routes. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > > > > > ----- Original Message ----- > > > > From: "Jack Stonebraker" > > To: nanog at nanog.org > > Sent: Thursday, February 5, 2015 11:24:59 AM > > Subject: Input Regarding Cogent and NTT > > > > My organization is currently shopping for some additional Transit > Capacity to augment our existing interconnects. We've got around 8 distinct > AS's that we're receiving transit routes from, followed by a handful of > Public IX's and Private PNI's to AS's that warrant them. That said, the > networks that are on our radar are Cogent and NTT. I've done some due > diligence poking around on their Looking Glass, but I'd love to hear any > user experiences from the community, both from a Layer 3 Perspective, as > well as an Operational Perspective (Working with the businesses > themselves). Feel free to contact me off-list and thanks in advance for > your time. > > > > [cid:image002.jpg at 01CFE2F3.A6F973D0] > > > > > > Jack Stonebraker | Sr. IP Network Engineer > > (512) 878-5627 | jack.stonebraker at mygrande.com john.hogan at mygrande.com> > > Grande Communications Networks > > 401 Carlson Circle | San Marcos, Texas | 78666 > > > > > > > > > > From rdobbins at arbor.net Thu Feb 5 19:55:11 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 06 Feb 2015 02:55:11 +0700 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <08cd01d0416a$84c92d20$8e5b8760$@oneunified.net> <23BD3BAB-AC30-4D4C-8A96-B4CEA39A610D@arbor.net> <05b5e0a1b6964a9ea15cdbd04166d1c5@pur-vm-exch13n1.ox.com> <520EE96E-4248-4490-8981-996BFFC597DC@arbor.net> Message-ID: <46AEEC29-B601-4189-8E13-E77579C1FE5D@arbor.net> On 6 Feb 2015, at 2:29, Terry Baranski wrote: > And if there's one person qualified to comment on what "real security" > is, it's a person who has "never heard a plausible anecdote of [IPS] > devices actually 'preventing' anything." :-) That's right - especially if such a person spent a not-inconsiderable amount of time working for the world's largest manufacturer of such devices, and heard no such plausible anecdote during his time there, even though he asked repeatedly for same. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Thu Feb 5 19:59:26 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 06 Feb 2015 02:59:26 +0700 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <3923.1423154815@turing-police.cc.vt.edu> Message-ID: <684B0991-27AF-42EB-8972-EF340F1C6860@arbor.net> On 6 Feb 2015, at 2:26, Terry Baranski wrote: > Zero, on my networks. Which highlights the importance of broadness of experience, of knowledge and understanding of the experiences of others, and understanding of the implications of scale. > If you can't deploy IPS's in such a way that they don't make your > network > less secure via DDoS susceptibility, or reduce availability due to > non-existent or subpar redundancy/survivability engineering, then you > shouldn't deploy IPS's. By their very nature, it's impossible to do so. ----------------------------------- Roland Dobbins From contact at nullivex.com Thu Feb 5 20:05:00 2015 From: contact at nullivex.com (Bryan Tong) Date: Thu, 5 Feb 2015 13:05:00 -0700 Subject: Input Regarding Cogent and NTT In-Reply-To: <19213156.13034.1423165265508.JavaMail.mhammett@ThunderFuck> References: <19213156.13034.1423165265508.JavaMail.mhammett@ThunderFuck> Message-ID: We've been on Cogent for 3 years now. I have to say the experience has been nice. Good sales, great NOC. We even had a dirty fiber issue with their uplink (due to the MMA owner) and Cogent stayed on the phone with me for hours and got it handled before we hung up the phone. So great NOC too. On Thu, Feb 5, 2015 at 12:41 PM, Mike Hammett wrote: > They are persistent, but by no means the most persistent vendor I work > with. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Alistair Mackenzie" > Cc: "NANOG" > Sent: Thursday, February 5, 2015 1:35:13 PM > Subject: Re: Input Regarding Cogent and NTT > > Don't be surprised if cogent contact you for even posting this. > > They did it to me when I asked for hibernia. > On 5 Feb 2015 19:16, "Mike Hammett" wrote: > > > Working on it. ;-) > > > > Being an eyeball network, most of my traffic just goes to NetFlix, > Akamai, > > LimeLight, FaceBook, Google, etc. anyway. Peer what you can peer, Cogent > > for customer routes, then grab a couple nicer carriers and call it a day. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > > > > > ----- Original Message ----- > > > > From: "Patrick W. Gilmore" > > To: nanog at nanog.org > > Sent: Thursday, February 5, 2015 12:54:43 PM > > Subject: Re: Input Regarding Cogent and NTT > > > > By that logic, and giving you the benefit of the doubt that you follow > > your own advice, you have 15-20 upstreams? > > > > I've never tried that on a standard network with BGP as the only tool. > See > > any interesting operational stuff with that many upstreams? > > > > Also, while many people knock Cogent, I would submit that many people > have > > bad first-hand experiences with Cogent (including me). > > > > Every network has its bad days. Even the best companies screw customers > > from time-to-time. But the preponderance of evidence is a useful > guidepost. > > Cogent is large, but does not have even half the customers NTT has. Do > > "lots of people knock NTT"? Given NTT's much larger number of customers, > > shouldn't that mean they have more knocks? > > > > If not, I submit the disparity is a useful datapoint when choosing a > > provider. > > > > -- > > TTFN, > > patrick > > > > Composed on a virtual keyboard, please forgive typos. > > > > > > > On Feb 5, 2015, at 12:29, Mike Hammett wrote: > > > > > > A lot of people knock Cogent, but the best way to get to Cogent's > > customer's is probably through Cogent. Given that they do have a very > large > > network, they're worth picking up even if you only use them for customer > > routes. > > > > > > > > > > > > > > > ----- > > > Mike Hammett > > > Intelligent Computing Solutions > > > http://www.ics-il.com > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Jack Stonebraker" > > > To: nanog at nanog.org > > > Sent: Thursday, February 5, 2015 11:24:59 AM > > > Subject: Input Regarding Cogent and NTT > > > > > > My organization is currently shopping for some additional Transit > > Capacity to augment our existing interconnects. We've got around 8 > distinct > > AS's that we're receiving transit routes from, followed by a handful of > > Public IX's and Private PNI's to AS's that warrant them. That said, the > > networks that are on our radar are Cogent and NTT. I've done some due > > diligence poking around on their Looking Glass, but I'd love to hear any > > user experiences from the community, both from a Layer 3 Perspective, as > > well as an Operational Perspective (Working with the businesses > > themselves). Feel free to contact me off-list and thanks in advance for > > your time. > > > > > > [cid:image002.jpg at 01CFE2F3.A6F973D0] > > > > > > > > > Jack Stonebraker | Sr. IP Network Engineer > > > (512) 878-5627 | jack.stonebraker at mygrande.com > john.hogan at mygrande.com> > > > Grande Communications Networks > > > 401 Carlson Circle | San Marcos, Texas | 78666 > > > > > > > > > > > > > > > > > > -- eSited LLC (701) 390-9638 From davidbass570 at gmail.com Thu Feb 5 20:41:35 2015 From: davidbass570 at gmail.com (David Bass) Date: Thu, 5 Feb 2015 14:41:35 -0600 Subject: Metaswitch ax1000 as a RR Message-ID: I have a client looking to implement x86 based route reflectors, and was looking at the ax1000. I'm wondering if anyone has implemented it yet, and what your experience has been? Any other alternatives would also be appreciated. This customer does standard L3 VPNs, and VPLS services so the software has to support that. Thanks! From nick.rose at enzu.com Thu Feb 5 18:22:31 2015 From: nick.rose at enzu.com (Nick Rose) Date: Thu, 5 Feb 2015 13:22:31 -0500 Subject: Input Regarding Cogent and NTT In-Reply-To: <54D3B202.8030204@winterei.se> References: <1C88157B8801CB448C108286C81ECB631B8C4F@SRV-SAM-MBOX02.lan.thrifty.net> <54D3B202.8030204@winterei.se> Message-ID: <004201d04170$b76dbfb0$26493f10$@enzu.com> Yeah cogent is great, accept for that time they dropped a /15 for no reason and took 24 hours to get it back up. Aside from that it's been a great experience. Regards, Nick Rose | CTO Enzu Inc. nick.rose at enzu.com www.enzu.com -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul S. Sent: Thursday, February 05, 2015 1:10 PM To: nanog at nanog.org Subject: Re: Input Regarding Cogent and NTT As a current Cogent customer, my experience on the service side of things is similar. Very responsive (I called on a Sunday and had someone with good enough clue + router access pick up instantly.) NOC is competent, and my sales guys (I've had two so far) are not pushy at all. I don't have any real complaints. I'd rate them higher than most of my other upstreams as far as NOC competency goes. On 2/6/2015 午前 03:00, Christopher Rogers wrote: > NTT is awesome. Extremely responsive, sales guys aren't pushy, noc is > great, and lots of NTT guys are here on nanog. > > Cogent is not. Their sales guys love to scrape whois records too, and > won't leave you the hell alone. > > I've used both extensively, and now typically just avoid cogent. > > -chris > Am 05.02.2015 09:26 schrieb "Jack Stonebraker" < > Jack.Stonebraker at mygrande.com>: > >> My organization is currently shopping for some additional Transit >> Capacity to augment our existing interconnects. We've got around 8 >> distinct AS's that we're receiving transit routes from, followed by a >> handful of Public IX's and Private PNI's to AS's that warrant them. >> That said, the networks that are on our radar are Cogent and NTT. >> I've done some due diligence poking around on their Looking Glass, >> but I'd love to hear any user experiences from the community, both >> from a Layer 3 Perspective, as well as an Operational Perspective >> (Working with the businesses themselves). Feel free to contact me off-list and thanks in advance for your time. >> >> [cid:image002.jpg at 01CFE2F3.A6F973D0] >> >> >> Jack Stonebraker | Sr. IP Network Engineer >> (512) 878-5627 | jack.stonebraker at mygrande.com> john.hogan at mygrande.com> >> Grande Communications Networks >> 401 Carlson Circle | San Marcos, Texas | 78666 >> >> >> >> >> From terry.baranski.list at gmail.com Thu Feb 5 21:24:05 2015 From: terry.baranski.list at gmail.com (Terry Baranski) Date: Thu, 5 Feb 2015 16:24:05 -0500 Subject: Checkpoint IPS In-Reply-To: <684B0991-27AF-42EB-8972-EF340F1C6860@arbor.net> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <3923.1423154815@turing-police.cc.vt.edu> <684B0991-27AF-42EB-8972-EF340F1C6860@arbor.net> Message-ID: <004101d0418a$12a415a0$37ec40e0$@gmail.com> On 6 Feb 2015, at 3:01, Roland Dobbins wrote: > Which highlights the importance of broadness of experience, of > knowledge and understanding of the experiences of others, and > understanding of the implications of scale. It highlights the importance of knowing what you're doing in the real world, on networks that exist and which you actually understand intimately, end-to-end. And maybe also of not working for vendors, since these two things are often mutually exclusive. > By their very nature, it's impossible to do so. Nope. But in any case, I've violated what I said this morning about not turning this into a big back-and-forth. (Sorry.) -Terry From rdobbins at arbor.net Thu Feb 5 21:47:31 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 06 Feb 2015 04:47:31 +0700 Subject: Checkpoint IPS In-Reply-To: <004101d0418a$12a415a0$37ec40e0$@gmail.com> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <3923.1423154815@turing-police.cc.vt.edu> <684B0991-27AF-42EB-8972-EF340F1C6860@arbor.net> <004101d0418a$12a415a0$37ec40e0$@gmail.com> Message-ID: On 6 Feb 2015, at 4:24, Terry Baranski wrote: > It highlights the importance of knowing what you're doing in the real > world, on networks that exist and which you actually understand > intimately, > end-to-end. Absolutely. At least one of the parties in this discussion has such knowledge of and experience on real-world networks of considerable scale, and is not infrequently engaged hands-on in the preservation of availability on said networks in fraught circumstances. > And maybe also of not working for vendors, since these two things are > often mutually exclusive. Again, absolutely. At least one of the parties has seen firsthand the extremely negative impact of the devices in question on a broad array of large-scale production networks ever since said devices were first introduced in the 1990s, having been awakened at 0Dark30 on numerous occasions with pleas for assistance because 'the network is down', 'the data center is offline', 'our entire wireless broadband network is down', et. al., due to the manifest failings of such devices. Anyways, enough. This topic has been thoroughly discussed multiple times on this list and on others of an operational nature; if you believe it wise to discount the well-understood negative impact of such devices on availability, that is your choice. ----------------------------------- Roland Dobbins From surfer at mauigateway.com Thu Feb 5 21:55:04 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 5 Feb 2015 13:55:04 -0800 Subject: mpls over microwave Message-ID: <20150205135504.39F63F7A@m0048136.ppops.net> Anyone doing MPLS over microwave radios? Please share your experiences on list or off. scott From adairw at amarillowireless.net Thu Feb 5 21:57:30 2015 From: adairw at amarillowireless.net (Adair Winter) Date: Thu, 5 Feb 2015 15:57:30 -0600 Subject: mpls over microwave In-Reply-To: <20150205135504.39F63F7A@m0048136.ppops.net> References: <20150205135504.39F63F7A@m0048136.ppops.net> Message-ID: We are. What would you like to know? On Thu, Feb 5, 2015 at 3:55 PM, Scott Weeks wrote: > > > Anyone doing MPLS over microwave radios? Please > share your experiences on list or off. > > scott > -- Adair Winter VP, Network Operations / Owner Amarillo Wireless | 806.316.5071 C: 806.231.7180 http://www.amarillowireless.net From nanog at ics-il.net Thu Feb 5 21:57:49 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 5 Feb 2015 15:57:49 -0600 (CST) Subject: mpls over microwave In-Reply-To: <20150205135504.39F63F7A@m0048136.ppops.net> Message-ID: <6403766.13356.1423173483834.JavaMail.mhammett@ThunderFuck> Shouldn't really be any different as long as your gear supports the appropriate MTUs. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Scott Weeks" To: nanog at nanog.org Sent: Thursday, February 5, 2015 3:55:04 PM Subject: mpls over microwave Anyone doing MPLS over microwave radios? Please share your experiences on list or off. scott From surfer at mauigateway.com Thu Feb 5 22:06:43 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 5 Feb 2015 14:06:43 -0800 Subject: mpls over microwave Message-ID: <20150205140643.39F63C53@m0048136.ppops.net> On Thu, Feb 5, 2015 at 3:55 PM, Scott Weeks wrote: > Anyone doing MPLS over microwave radios? Please > share your experiences on list or off. --- adairw at amarillowireless.net wrote: From: Adair Winter We are. What would you like to know? --------------------------------------------- What kind of radios? What kind of hand off? What kind of router does the radio connect to? Any gotchas I should watch out for? scott From Nathan_Sipes at kindermorgan.com Thu Feb 5 22:14:22 2015 From: Nathan_Sipes at kindermorgan.com (Sipes, Nathan) Date: Thu, 5 Feb 2015 22:14:22 +0000 Subject: mpls over microwave In-Reply-To: <6403766.13356.1423173483834.JavaMail.mhammett@ThunderFuck> References: <20150205135504.39F63F7A@m0048136.ppops.net> <6403766.13356.1423173483834.JavaMail.mhammett@ThunderFuck> Message-ID: <13AB87E4E441E94ABE3F62F72C111A381FA4A891@COSEX2.kindermorgan.com> I have been running MPLS over TDM and Ethernet microwave for about 8 years and the only issues are with microwave fade. Nathan Sipes Principal Network Architect Tel: 713-369-9866 FAX: 303-763-3510  Kinder Morgan 1001 Louisiana St KMB 548 Houston, TX 77002 Nathan_Sipes at kindermorgan.com -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Thursday, February 5, 2015 3:58 PM To: nanog at nanog.org Subject: Re: mpls over microwave Shouldn't really be any different as long as your gear supports the appropriate MTUs. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Scott Weeks" To: nanog at nanog.org Sent: Thursday, February 5, 2015 3:55:04 PM Subject: mpls over microwave Anyone doing MPLS over microwave radios? Please share your experiences on list or off. scott From chkuhtz at microsoft.com Thu Feb 5 22:17:56 2015 From: chkuhtz at microsoft.com (Christian Kuhtz) Date: Thu, 5 Feb 2015 22:17:56 +0000 Subject: mpls over microwave In-Reply-To: <20150205135504.39F63F7A@m0048136.ppops.net> References: <20150205135504.39F63F7A@m0048136.ppops.net> Message-ID: Not doing anymore, but I have in a previous life. It works. What's more important is how you engineered your radios and what you're using... Best regards, Christian -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Weeks Sent: Thursday, February 5, 2015 1:55 PM To: nanog at nanog.org Subject: mpls over microwave Anyone doing MPLS over microwave radios? Please share your experiences on list or off. scott From elouie at techintegrity.com Thu Feb 5 22:31:46 2015 From: elouie at techintegrity.com (Eric Louie) Date: Thu, 5 Feb 2015 14:31:46 -0800 Subject: mpls over microwave In-Reply-To: <20150205135504.39F63F7A@m0048136.ppops.net> References: <20150205135504.39F63F7A@m0048136.ppops.net> Message-ID: I work for a fixed wireless provider, and our mpls-capable backhauls are all running mpls with 9200 MTU with no problem. The only weirdness I encounter is if I have multiple equal-cost routes to the same location, one over MPLS and one not, end up having ping/unreachable issues from my monitoring equipment. The solution has been to cost one path (the MPLS) lower than the other. The only other problem I had was with radio's that didn't support larger 9000+ byte MTU packets - we've phased that radio out for now. if you run MPLS with 1500 byte MTU, you'll have issues with 1500 byte packets with the DF-bit set. That was a nasty discovery in the production network, your mileage will not vary with that problem. eric at techintegrity dot com 619-335-8148 voice & text www.techintegrity.com ericlouie on Twitter On Thu, Feb 5, 2015 at 1:55 PM, Scott Weeks wrote: > > > Anyone doing MPLS over microwave radios? Please > share your experiences on list or off. > > scott > From skeeve+nanog at eintellegonetworks.com Thu Feb 5 22:51:06 2015 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Fri, 6 Feb 2015 09:51:06 +1100 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <1423142005906.59768@csuohio.edu> Message-ID: +100% agree. ...Skeeve *Skeeve Stevens - Founder & Chief Network Architect* eintellego Networks Pty Ltd Email: skeeve at eintellegonetworks.com ; Web: eintellegonetworks.com Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks ; Twitter: eintellego LinkedIn: /in/skeeve ; Expert360: Profile The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering On Fri, Feb 6, 2015 at 12:19 AM, Roland Dobbins wrote: > > On 5 Feb 2015, at 20:13, Michael O Holstein wrote: > > Personally I'm of the belief that *all* IPS systems are equally >> worthless, unless the goal is to just check a box on a form. >> > > Concur 100%. > > Securing hosts/applications/services themselves is the way to protect them > from compromise. > > ----------------------------------- > Roland Dobbins > From davidbass570 at gmail.com Thu Feb 5 23:06:50 2015 From: davidbass570 at gmail.com (David Bass) Date: Thu, 5 Feb 2015 17:06:50 -0600 Subject: mpls over microwave In-Reply-To: <20150205135504.39F63F7A@m0048136.ppops.net> References: <20150205135504.39F63F7A@m0048136.ppops.net> Message-ID: <59A154F6-071F-4A21-A9E0-316EC7280096@gmail.com> Done it, and it works well. Used Motorola radios, and the key is the radio and building that part of the infrastructure right. The MPLS is just another IP packet to the wireless. Always used Ethernet handoffs on the radios to keep things simple. Make sure you have good line of site, have ample fade or lack of, and you take vegetation growth in to consideration. Also make sure you buy stuff that handles jumbo frames and enable that, so that you don't have issues with fragmentation. > On Feb 5, 2015, at 3:55 PM, Scott Weeks wrote: > > > > Anyone doing MPLS over microwave radios? Please > share your experiences on list or off. > > scott From surfer at mauigateway.com Thu Feb 5 23:17:16 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 5 Feb 2015 15:17:16 -0800 Subject: mpls over microwave Message-ID: <20150205151716.3838A7DD@m0048140.ppops.net> --- davidbass570 at gmail.com wrote: Always used Ethernet handoffs on the radios to keep things simple. --------------------------------- Had to run off to a meeting. Back now. This is one thing I was worried about. I'm not doing the radio part. Someone else is. I didn't know if folks do pure Ethernet or if it's an IP hand off. If it's an IP addressed hand off, I have to come out of MPLS, cross the link, then go back into MPLS. Thanks for the pointers on packet size. I will be sure to check into that. scott From eksffa at freebsdbrasil.com.br Thu Feb 5 23:40:02 2015 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Thu, 05 Feb 2015 21:40:02 -0200 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> Message-ID: <54D3FF52.2040005@freebsdbrasil.com.br> > On 05/02/2015, at 12:31, Terry Baranski > wrote: > > On Thu, Feb 5, 2015 at 8:34 AM, Roland Dobbins wrote: > >> I've never heard a plausible anecdote, much less seen meaningful > statistics, >> of these devices actually 'preventing' anything. > > People tend to hear what they want to hear. Surely your claim can't be > that > an IPS has never, in the history of Earth, prevented an attack or exploit. > So it's unclear to me what you're actually trying to say here. > >> And the fact that well-known evasion techniques still work against these >> devices today, coupled with the undeniable proliferation of compromised >> hosts residing within networks supposedly 'protected' by these devices, >> militates against your proposition. > > Your tendency of making blanket statements is somewhat baffling given the > multitude of intricacies, details, and varying circumstances involved in a > complex topic like this. To me, it's indicative of an overly-simplified > and/or biased way of looking at things. > > In any case, go ahead and stick with your router ACLs and (stateful!) > proxies. Different strokes. > > -Terry There's room for a good engineered strategy for protection which won't turn into a point of failure in the overall networking topology. For decades, since first rainbow series books were written and military “strategy” started to be added to information security, it’s always been about defense in depth and layered defense. Today those buzzwords became an incredibly “bullshit bingo” on sales force strategy on selling magical boxes and people tend to forget the basics. Layers and the “depth” is not a theory just to be added to drawings and keynote presentations. Considering a simplistic topology for 3-tier (4 if you count T0) depth protection strategy: (Internet)--[Tier-0]--(Core Router)--[Tier1]--(core switch)--[Tier2]--(DMZ)--[Tier3]--(Golden Secret) One security layer (tier, whatever) is there to try to fill the gap from the previous one. How deep you have to dig depends on who you are. If you are the end organization willing to protect the golden secret, how complex is your topology, or if you are the carrier, the telecom the company worried only about BGP, PPS, BPS and availability other than the actual value for what's the real target for the attack (if not availability) In summary, in my experience what will (not) work is: 1) Tier 0 & Tier 1 On border, core, (Tier0) or on Tier-1 protection layers (typical “firewall/dmz” topological position) - Memory and CPU exaustion will shut down your operations (increase latency and decrease availability) easily, if you have a Protecting Inbound Proxy (Web Application Firewall, for the sales jargon), Stateful Firewall or IPS. The thing here is, you are insane or naive if you believe a finite state machine with finite resources can protect you from a virtually infinite (unlimited) source of attacks. No matter how much RAM you have, how much CPU cycles you have, they are finite, and since those “amazing stateful w/ deep inspection, scrub, normalization and reassembly” features on a firewall will demand at least 4K RAM per session and a couple CPU cycles per test, you have a whole “line rate” (1.4Mpps / 14Mpps for 1GbE 10GbE ports) attack potential, and come on, if a single or a 3-way packets sequence will cost you a state, it’s an easy math count to find out you are in a bad position trying to “secure” those Tier0 and Tier1 topological locations. It's just easier and cheaper for the one attacking, than for your amazing firewall or IPS. So what to do here? Try to get rid of most automated/scripted/simple attack you can. You can do ingress filtering, a lot of BCP, protection against SNMP/NTP/DNS amplification, verify reverse path, (verrevpath, antipsoof, verrevreachability), and many good / effective (but limited) protection with ACL, data plane protection mechanisms, BGP blackholing, Null Routing (sending stuff to disc0 on BSD, null0 on Cisco, etc) and Stateles Firewalling. Also, an IDS sensor might fit here, because if CPU/Memory starvation happens on an IDS sensor, the worst thing will happen is some packets getting routed without proper processing. But still, they will get routed. Always stateles, always simple tests. No Layer7 inspection of any form, no load balancer, WAF, whatever. No regex, hell no! No memory pointers that can point to dark processor/memory locations (again, no regex). 2) On Tier 2 protection (A defense depth that comes after core protection and after Tier-1): - Will miserably fail if you use stateful firewall in excess - Will fail even quicker if you use a WAF or IPS Many “security engineers” and “security experts” (or worse, security tools vendors and developers) excessively use stateful tests on transport protocols that are simply… stateles. What good you have on stateful firewalling… ICMP? UDP? DDP? IGMP? come on, all those state timers are worthless and your memory limits will reach very soon. Remember, in the average, 4K RAM at least, per stateful session. Much more resources are needed for IPS, much much more for inbound proxy (WAF), not to mention CPU. Will you add an IPS here? What for, other than easing putting down and making your network and services unavailable? Proxy? Mod Security? Hell no! Not here. Did you check how many regex and rules you have in the “base_rules” collection for a Top 10 OWASP protection on Mod Security? What about vendor specifics rules, or Sans Top 25 specifics. This is just not the place. Also, let’s rationale, what is your real benefit on deep inspection stateful filtering on those SSH sessions allowing for your trusted locations only? Really, what good will it make? Drop it stateles, allow it stateles! If you really believe stateful worths something for protocols such as SSH, do it somewhere else (Tier3 or host-based). Focus on stateful protection only for what really needs some protection of this kind. Packets related, fragile services for packets arbitrarily assembled. Maybe SIP (SIP, not RTP), HTTPS, HTTP. Layer3/Layer4 fragile and public services, after some stateles inspection was already done on Tier1, should deserve stateful protection only. Not your whole network! Not your whole set of services or services. And no ICMP, no UDP do deserve stateful. Also, pick up a good tool for this. Most sysadmins, security guys or network operators never notice how their tools may betray 'em hardly (by deault). For example one use OpenBSD PF firewall, every rule you make will “automagically” become an stateful rule. And this is not good! This is terrible! This “auto” behavior makes the security engineer blind, since the rules he is writing is not the rules he is adding to kernel. OpenBSD’s PF has a “no state” option and nobody uses it! It means you are doing it wrong… UDP/ICMP/TCP rules always have “keep state” added, if you don’t explicitly set “no state”. Beware! The same is valid for Linux Netfilter, and 9 in 10 commercial firewalls (checkpoint, mikrotik, fortinet, whatever…). FreeBSD’s ipfw on the other hand is stateles by default. It means if you don’t explicitly add “keep-state” there, it’s stateles. Which is good, unless you explicitly want a rule to be stateful. It’s excellent as a default behavior for protection layers not close to your "golden egg provider". On the other hand, ipfw by default has a limit of 4096 states which is TOO LOW. Beware too! Regarding IPS/WAF/Proxy or “Next Generation” firewalls, this is not the place to add it. On the other hand you need some level of extra protection firewalls will not provide, and some Layer7 inspection on Tier2 will be good. But not Proxy! Not mod security! and not IPS! (no WAF) IMHO, an IDS will fit good here. IDS, not IPS, not IDP. Not a magical solution… Why, from my past experiences, an IDS approach here will fit? Due it’s passive nature. If your IDS (say, Suricata, Bro, keeping on open source, or your commercial option of choice) starves on CPU or memory, what’s the worst thing to happen? You will have a high number of PPS on that perimeter port passing without getting processed/inspected. Your overall security will decrease, but you still have Tier3 (and maybe other tiers) to fulfill the gap! Packets that still can be processed should have active response in place taking care of a lot of attacks. What I mean is, if you have limited (and you do have limited) processing and memory power, say you can IDS inspect 400Kpps but a 1Mpps attack is ongoing, you have 40% inspection power, but packets not processed still get routed! Without latency and without packet loss because it’s an IDS and not an IPS. It’s not inline. It’s passive, sitting there. Limited resources, priority and lower kernel CPU scheduler relevance. And for those 40% (very bad scenario I am drawing here) you still have active response in place, rerouting, reconfiguring stateles firewall, stateles ACLs and null routes on upper tiers (tier 0, tier 1, routers, switches) and lower tiers (tier 3 reconfigured upon tier 2 decision). What you will do is try to fill the gap on next tiers, or increase your filtering capabilities that are still stateles or passive. For many business, this is the end for added protection layers. A big ISP, transport provider, content delivery business... more protection from this point is something for the specific end business, and completely related to their needs, their business model, process, responsibilities and overall evaluated requirements. Not a general model to fit. But for everyone else up to this tier you have relevant security mechanisms and tecnology added, and still low starvation/exaustion risks due to the stateles and passive nature of the approach. 3) On Tier 3, a protection strategy for your “golden eggs” provider, the golden secret, your business secret and intelligence Usually, this protection level is for the corporate strategy. The business, not the carrier, the service provider or the network operator. And is a business specific requirement. Meaning it may not exist at all! Now, for me, here is where you add more stateful inspection (still, only what is actually efficient, not that god damn echo reply/request wasting memory to be tracked down - useless!). Here is a good place for a WAF, after firewall and IDS protection took place. WAF is a not a panaceia for anything, it's aimed for specific attacks against applications and protocols, is not resilient to coward attacks (volumetric, L3/L4 exaustion, etc). And a proxy in the end is always a web server, so inherits all it's fragility, and therefore it must be protected as well, before it can actually protect anything else. Host Intrusion Detection central servers (receiving information gathered from HIDS on the actual hosts) also fits Tier3. As well as other host-based controls that may add telemetry information to a central location. Talking about telemetry, it's important everywhere, and while generating flows or snmp info grabbing may impact processing usage on critical core devices, those extra added boxes should also passively help telemetry, with flow generation or minimum capability for snmp servings. Nothing here is new. I am talking about, again, basic stuff discussed for decades on colored cover military books, drafts, discussions and BCPs and really old stuff discussed for people who may be already dead, sometimes (Itojun and other samurais' missed). I'm only mentioning the basic 3 tech domains (firewall, ids, proxy), but the other two basic (pen test, vuln scan) that are more process than technology are important as well. For me, and again this is very personal opinion, I never run an IPS unless the customer "really wants to" (or a stupid compliance requirement really requires to). An IDS+Active Response is as good as IPS, and the only extra benefit an IPS will add compared to IDS is related to "single packet attacks", that ones that will pass quickly enough before the active response blocks it. But "single packet" attacks are related to poorly written software (or unpatched / not fixed software) since it's not really an attack, it's a trigger to bad code misbehavior and should be addressed on the host. This is a very simple model, and easy to understand. However how many situations we've seen big companies getting completely unavailable or AAA getting broken because people insist to buy (and sell) "miracle boxes" added to core locations, and those miracle boxes will have amazing deep inspection firewalls or IPS or DLP (whatever it means, Data Loss, Data Leak, it means whatever you want to buy)... There may be a place for those stuff, but it's not on core. Nor on second level protection layers. In the end, ISO27002, PCI-DSS, CIA and AAA triads, what are they worth if you add an IPS to your core? When memory is exausted, processing is starved, you will have packet loss, latency, or you will be completely offline. And what's CIA if you "security features" are breaking Integrity due to missing packets, or breaking full Availability at all? What you have from CIA? Only confidentiality? Better take that plug off. Same for AAA, if Authorization and Authentication are broken or failed due to exaustion/starvation what you get? Accounting/Auditing? So you will sit and read the logs to find out what went wrong? Discouraging firewall/IDS/proxy protection layers is as bad as over leveraging it. Dosage is what distinguishes the poison from the vaccine. -- Patrick Tracanelli FreeBSD Brasil Tel.: (31) 3516-0800 http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From nicholas.oas at gmail.com Fri Feb 6 00:02:58 2015 From: nicholas.oas at gmail.com (Nicholas Oas) Date: Thu, 5 Feb 2015 19:02:58 -0500 Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Message-ID: A router behind the firewall is nice too. It insulates the firewall from direct end-user traffic. It also makes for a cleaner cutover from one firewall to another. (Instead of the edge getting stuck ARPs their perspective of the network remains unchanged.) It also allows for stateless ACLs on both ends of the firewall. On Thu, Feb 5, 2015 at 1:49 PM, Ralph J.Mayer wrote: > Hi David, > > a router is a router and a firewall is a firewall. > > Especially a Cisco ASA is no router, period. > > A router in front of the firewall is my choice, it also keeps broadcasts > from the firewall + can do uRPF. > > > rm From joe at nethead.com Fri Feb 6 01:02:16 2015 From: joe at nethead.com (Joe Hamelin) Date: Thu, 5 Feb 2015 17:02:16 -0800 Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Message-ID: > On Feb 5, 2015, at 2:49 PM, Ralph J.Mayer wrote: > a router is a router and a firewall is a firewall. > Especially a Cisco ASA is no router, period. Man-o-man did I find that out when we had to renumber our network after we got bought by the French. Oh, I'll just pop on a secondary address on this interface... What? Needed to go through fits just to get a hairpin route in the thing. The ASA series is good at what it does, just don't plan on it acting like router IOS. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From SNaslund at medline.com Fri Feb 6 02:38:42 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 6 Feb 2015 02:38:42 +0000 Subject: mpls over microwave In-Reply-To: <6403766.13356.1423173483834.JavaMail.mhammett@ThunderFuck> References: <20150205135504.39F63F7A@m0048136.ppops.net>, <6403766.13356.1423173483834.JavaMail.mhammett@ThunderFuck> Message-ID: <5F596032-4D9C-4FBE-B2B2-FB9576EBE6B7@medline.com> We run Dragonwave systems and have no issues at all. MPLS in itself doesn't make a difference since the gear is a straight Ethernet link. Just make sure your gear handles your frame sizes and tagging and you should be good. As long as your radio link is engineered right you should have high reliability. The key is having enough margin to maintain links during fades. So for example our link runs at -34 dbm and our receivers are good down to about -65 dbm at this rate. That gives us a roughly 35 dbm margin for degradation before the modems will change modulation a to a lower speed. Here in chicago we have seen maybe a total of an hour of weather related fade in a 10 years period on a 20 mile link running 600 Mbps. They are very popular for low latency since they actually have less latency than fiber. The high frequency traders pay big bucks to get on the microwaves between markets because of that trait. Microwaves through air are faster than photons in a fiber cable. Steven Naslund Chicago IL Sent from my iPhone > On Feb 5, 2015, at 4:03 PM, Mike Hammett wrote: > > Shouldn't really be any different as long as your gear supports the appropriate MTUs. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Scott Weeks" > To: nanog at nanog.org > Sent: Thursday, February 5, 2015 3:55:04 PM > Subject: mpls over microwave > > > > Anyone doing MPLS over microwave radios? Please > share your experiences on list or off. > > scott > From jeffm at iglou.com Fri Feb 6 03:19:43 2015 From: jeffm at iglou.com (Jeff McAdams) Date: Thu, 5 Feb 2015 22:19:43 -0500 (EST) Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Message-ID: <6290.74.129.32.29.1423192783.iglou@webmail.iglou.com> On Thu, February 5, 2015 20:02, Joe Hamelin wrote: >> On Feb 5, 2015, at 2:49 PM, Ralph J.Mayer >> wrote: >> a router is a router and a firewall is a firewall. Especially a Cisco ASA >> is no router, period. > > Man-o-man did I find that out when we had to renumber our network after > we got bought by the French. > Oh, I'll just pop on a secondary address on this interface... What? > Needed to go through fits just to get a hairpin route in the thing. > The ASA series is good at what it does, just don't plan on it acting like > router IOS. Sorry, but I'm with Owen. Square : Rectangle :: Firewall : Router A firewall is a router, despite how much so many security folk try to deny it. And firewalls that seem to try to intentionally be crappy routers (ie, ASAs) have no place in my network. If it can't be a decent router, then its going to suck as a firewall too, because a firewall has to be able to play nice with the rest of the network, and if they can't do that, then I have no use for them. I'll get a firewall that does. -- Jeff From surfer at mauigateway.com Fri Feb 6 05:41:38 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 5 Feb 2015 21:41:38 -0800 Subject: mpls over microwave Message-ID: <20150205214138.39D978CC@m0005311.ppops.net> Thanks everyone, I feel a lot more confident on this project after this discussion. I will be working with a comm engineer who'll be doing the various radio links. I just need to be sure he can make the best decision as we're moving from ATM to MPLS and he doesn't understand the networking part and I only understand the basics of microwave links. scott From dhooper at gold.net.au Fri Feb 6 02:46:54 2015 From: dhooper at gold.net.au (Daniel Hooper) Date: Fri, 6 Feb 2015 02:46:54 +0000 Subject: mpls over microwave In-Reply-To: <5F596032-4D9C-4FBE-B2B2-FB9576EBE6B7@medline.com> References: <20150205135504.39F63F7A@m0048136.ppops.net>, <6403766.13356.1423173483834.JavaMail.mhammett@ThunderFuck> <5F596032-4D9C-4FBE-B2B2-FB9576EBE6B7@medline.com> Message-ID: <7daf18bbcd2c4aa59596c698f1c3a7ac@MX-10.team.emerge.net.au> Aviat Networks has recently released a microwave router with MPLS features, it's basically a router inside the microwave indoor unit. What we've found what hurts with anything over microwave is when you're running n+n links over long haul and the RF modulation steps down on one of those links and decreases your bandwidth, the Aviat solution is apparently meant to solve this with the RF cards talking directly to the on-board router and giving your MPLS nodes a kick to shift traffic in the right direction. -Daniel -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Naslund, Steve Sent: Friday, 6 February 2015 10:39 AM To: nanog at nanog.org Subject: Re: mpls over microwave We run Dragonwave systems and have no issues at all. MPLS in itself doesn't make a difference since the gear is a straight Ethernet link. Just make sure your gear handles your frame sizes and tagging and you should be good. As long as your radio link is engineered right you should have high reliability. The key is having enough margin to maintain links during fades. So for example our link runs at -34 dbm and our receivers are good down to about -65 dbm at this rate. That gives us a roughly 35 dbm margin for degradation before the modems will change modulation a to a lower speed. Here in chicago we have seen maybe a total of an hour of weather related fade in a 10 years period on a 20 mile link running 600 Mbps. They are very popular for low latency since they actually have less latency than fiber. The high frequency traders pay big bucks to get on the microwaves between markets because of that trait. Microwaves through air are faster than photons in a fiber cable. Steven Naslund Chicago IL Sent from my iPhone > On Feb 5, 2015, at 4:03 PM, Mike Hammett wrote: > > Shouldn't really be any different as long as your gear supports the appropriate MTUs. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Scott Weeks" > To: nanog at nanog.org > Sent: Thursday, February 5, 2015 3:55:04 PM > Subject: mpls over microwave > > > > Anyone doing MPLS over microwave radios? Please share your experiences > on list or off. > > scott > From rps at maine.edu Fri Feb 6 13:08:38 2015 From: rps at maine.edu (Ray Soucy) Date: Fri, 6 Feb 2015 08:08:38 -0500 Subject: Checkpoint IPS In-Reply-To: <54D3FF52.2040005@freebsdbrasil.com.br> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> Message-ID: An IPS doesn't have to be in line. It can be something watching a tap and scripted to use something else to block traffic (e.g. hardware filtering options on a router that can handle it). An IDS tied into an internal RTBH setup to leverage uRPF filtering in hardware can be pretty effective at detecting and blocking the typical UDP attacks out there before they reach systems that don't handle that as gracefully (e.g. firewalls or host systems). Even if you keep it from being automated and just have it be an IDS that you can have a human respond to is pretty valuable. On Thu, Feb 5, 2015 at 6:40 PM, Patrick Tracanelli wrote: > >> On 05/02/2015, at 12:31, Terry Baranski >> wrote: >> >> On Thu, Feb 5, 2015 at 8:34 AM, Roland Dobbins wrote: >> >>> I've never heard a plausible anecdote, much less seen meaningful >> >> statistics, >>> >>> of these devices actually 'preventing' anything. >> >> >> People tend to hear what they want to hear. Surely your claim can't be >> that >> an IPS has never, in the history of Earth, prevented an attack or exploit. >> So it's unclear to me what you're actually trying to say here. >> >>> And the fact that well-known evasion techniques still work against these >>> devices today, coupled with the undeniable proliferation of compromised >>> hosts residing within networks supposedly 'protected' by these devices, >>> militates against your proposition. >> >> >> Your tendency of making blanket statements is somewhat baffling given the >> multitude of intricacies, details, and varying circumstances involved in a >> complex topic like this. To me, it's indicative of an overly-simplified >> and/or biased way of looking at things. >> >> In any case, go ahead and stick with your router ACLs and (stateful!) >> proxies. Different strokes. >> >> -Terry > > > There's room for a good engineered strategy for protection which won't turn > into a point of failure in the overall networking topology. > > For decades, since first rainbow series books were written and military > "strategy" started to be added to information security, it's always been > about defense in depth and layered defense. Today those buzzwords became an > incredibly "bullshit bingo" on sales force strategy on selling magical boxes > and people tend to forget the basics. Layers and the "depth" is not a theory > just to be added to drawings and keynote presentations. > > Considering a simplistic topology for 3-tier (4 if you count T0) depth > protection strategy: > > (Internet)--[Tier-0]--(Core Router)--[Tier1]--(core > switch)--[Tier2]--(DMZ)--[Tier3]--(Golden Secret) > > One security layer (tier, whatever) is there to try to fill the gap from the > previous one. > > How deep you have to dig depends on who you are. If you are the end > organization willing to protect the golden secret, how complex is your > topology, or if you are the carrier, the telecom the company worried only > about BGP, PPS, BPS and availability other than the actual value for what's > the real target for the attack (if not availability) > > In summary, in my experience what will (not) work is: > > 1) Tier 0 & Tier 1 > On border, core, (Tier0) or on Tier-1 protection layers (typical > "firewall/dmz" topological position) > > - Memory and CPU exaustion will shut down your operations (increase latency > and decrease availability) easily, if you have a Protecting Inbound Proxy > (Web Application Firewall, for the sales jargon), Stateful Firewall or IPS. > > The thing here is, you are insane or naive if you believe a finite state > machine with finite resources can protect you from a virtually infinite > (unlimited) source of attacks. No matter how much RAM you have, how much CPU > cycles you have, they are finite, and since those "amazing stateful w/ deep > inspection, scrub, normalization and reassembly" features on a firewall will > demand at least 4K RAM per session and a couple CPU cycles per test, you > have a whole "line rate" (1.4Mpps / 14Mpps for 1GbE 10GbE ports) attack > potential, and come on, if a single or a 3-way packets sequence will cost > you a state, it's an easy math count to find out you are in a bad position > trying to "secure" those Tier0 and Tier1 topological locations. It's just > easier and cheaper for the one attacking, than for your amazing firewall or > IPS. > > So what to do here? Try to get rid of most automated/scripted/simple attack > you can. You can do ingress filtering, a lot of BCP, protection against > SNMP/NTP/DNS amplification, verify reverse path, (verrevpath, antipsoof, > verrevreachability), and many good / effective (but limited) protection with > ACL, data plane protection mechanisms, BGP blackholing, Null Routing > (sending stuff to disc0 on BSD, null0 on Cisco, etc) and Stateles > Firewalling. > > Also, an IDS sensor might fit here, because if CPU/Memory starvation happens > on an IDS sensor, the worst thing will happen is some packets getting routed > without proper processing. But still, they will get routed. > > Always stateles, always simple tests. No Layer7 inspection of any form, no > load balancer, WAF, whatever. No regex, hell no! No memory pointers that > can point to dark processor/memory locations (again, no regex). > > 2) On Tier 2 protection (A defense depth that comes after core protection > and after Tier-1): > > - Will miserably fail if you use stateful firewall in excess > - Will fail even quicker if you use a WAF or IPS > > Many "security engineers" and "security experts" (or worse, security tools > vendors and developers) excessively use stateful tests on transport > protocols that are simply... stateles. > > What good you have on stateful firewalling... ICMP? UDP? DDP? IGMP? come on, > all those state timers are worthless and your memory limits will reach very > soon. Remember, in the average, 4K RAM at least, per stateful session. Much > more resources are needed for IPS, much much more for inbound proxy (WAF), > not to mention CPU. > > Will you add an IPS here? What for, other than easing putting down and > making your network and services unavailable? > > Proxy? Mod Security? Hell no! Not here. Did you check how many regex and > rules you have in the "base_rules" collection for a Top 10 OWASP protection > on Mod Security? What about vendor specifics rules, or Sans Top 25 > specifics. > > This is just not the place. > > Also, let's rationale, what is your real benefit on deep inspection stateful > filtering on those SSH sessions allowing for your trusted locations only? > Really, what good will it make? Drop it stateles, allow it stateles! If you > really believe stateful worths something for protocols such as SSH, do it > somewhere else (Tier3 or host-based). > > Focus on stateful protection only for what really needs some protection of > this kind. Packets related, fragile services for packets arbitrarily > assembled. Maybe SIP (SIP, not RTP), HTTPS, HTTP. Layer3/Layer4 fragile and > public services, after some stateles inspection was already done on Tier1, > should deserve stateful protection only. Not your whole network! Not your > whole set of services or services. > > And no ICMP, no UDP do deserve stateful. > > Also, pick up a good tool for this. > > Most sysadmins, security guys or network operators never notice how their > tools may betray 'em hardly (by deault). > > For example one use OpenBSD PF firewall, every rule you make will > "automagically" become an stateful rule. And this is not good! This is > terrible! This "auto" behavior makes the security engineer blind, since the > rules he is writing is not the rules he is adding to kernel. > > OpenBSD's PF has a "no state" option and nobody uses it! It means you are > doing it wrong... UDP/ICMP/TCP rules always have "keep state" added, if you > don't explicitly set "no state". Beware! > > The same is valid for Linux Netfilter, and 9 in 10 commercial firewalls > (checkpoint, mikrotik, fortinet, whatever...). > > FreeBSD's ipfw on the other hand is stateles by default. It means if you > don't explicitly add "keep-state" there, it's stateles. Which is good, > unless you explicitly want a rule to be stateful. It's excellent as a > default behavior for protection layers not close to your "golden egg > provider". On the other hand, ipfw by default has a limit of 4096 states > which is TOO LOW. Beware too! > > Regarding IPS/WAF/Proxy or "Next Generation" firewalls, this is not the > place to add it. > > On the other hand you need some level of extra protection firewalls will not > provide, and some Layer7 inspection on Tier2 will be good. > > But not Proxy! Not mod security! and not IPS! (no WAF) > > IMHO, an IDS will fit good here. > > IDS, not IPS, not IDP. Not a magical solution... > > Why, from my past experiences, an IDS approach here will fit? Due it's > passive nature. If your IDS (say, Suricata, Bro, keeping on open source, or > your commercial option of choice) starves on CPU or memory, what's the worst > thing to happen? > > You will have a high number of PPS on that perimeter port passing without > getting processed/inspected. Your overall security will decrease, but you > still have Tier3 (and maybe other tiers) to fulfill the gap! Packets that > still can be processed should have active response in place taking care of a > lot of attacks. > > What I mean is, if you have limited (and you do have limited) processing > and memory power, say you can IDS inspect 400Kpps but a 1Mpps attack is > ongoing, you have 40% inspection power, but packets not processed still get > routed! Without latency and without packet loss because it's an IDS and not > an IPS. It's not inline. It's passive, sitting there. Limited resources, > priority and lower kernel CPU scheduler relevance. > > And for those 40% (very bad scenario I am drawing here) you still have > active response in place, rerouting, reconfiguring stateles firewall, > stateles ACLs and null routes on upper tiers (tier 0, tier 1, routers, > switches) and lower tiers (tier 3 reconfigured upon tier 2 decision). > > What you will do is try to fill the gap on next tiers, or increase your > filtering capabilities that are still stateles or passive. > > For many business, this is the end for added protection layers. A big ISP, > transport provider, content delivery business... more protection from this > point is something for the specific end business, and completely related to > their needs, their business model, process, responsibilities and overall > evaluated requirements. Not a general model to fit. > > But for everyone else up to this tier you have relevant security mechanisms > and tecnology added, and still low starvation/exaustion risks due to the > stateles and passive nature of the approach. > > 3) On Tier 3, a protection strategy for your "golden eggs" provider, the > golden secret, your business secret and intelligence > > Usually, this protection level is for the corporate strategy. The business, > not the carrier, the service provider or the network operator. And is a > business specific requirement. Meaning it may not exist at all! > > Now, for me, here is where you add more stateful inspection (still, only > what is actually efficient, not that god damn echo reply/request wasting > memory to be tracked down - useless!). > > Here is a good place for a WAF, after firewall and IDS protection took > place. WAF is a not a panaceia for anything, it's aimed for specific attacks > against applications and protocols, is not resilient to coward attacks > (volumetric, L3/L4 exaustion, etc). And a proxy in the end is always a web > server, so inherits all it's fragility, and therefore it must be protected > as well, before it can actually protect anything else. > > Host Intrusion Detection central servers (receiving information gathered > from HIDS on the actual hosts) also fits Tier3. As well as other host-based > controls that may add telemetry information to a central location. > > Talking about telemetry, it's important everywhere, and while generating > flows or snmp info grabbing may impact processing usage on critical core > devices, those extra added boxes should also passively help telemetry, with > flow generation or minimum capability for snmp servings. > > Nothing here is new. I am talking about, again, basic stuff discussed for > decades on colored cover military books, drafts, discussions and BCPs and > really old stuff discussed for people who may be already dead, sometimes > (Itojun and other samurais' missed). I'm only mentioning the basic 3 tech > domains (firewall, ids, proxy), but the other two basic (pen test, vuln > scan) that are more process than technology are important as well. > > For me, and again this is very personal opinion, I never run an IPS unless > the customer "really wants to" (or a stupid compliance requirement really > requires to). An IDS+Active Response is as good as IPS, and the only extra > benefit an IPS will add compared to IDS is related to "single packet > attacks", that ones that will pass quickly enough before the active response > blocks it. But "single packet" attacks are related to poorly written > software (or unpatched / not fixed software) since it's not really an > attack, it's a trigger to bad code misbehavior and should be addressed on > the host. > > This is a very simple model, and easy to understand. However how many > situations we've seen big companies getting completely unavailable or AAA > getting broken because people insist to buy (and sell) "miracle boxes" added > to core locations, and those miracle boxes will have amazing deep inspection > firewalls or IPS or DLP (whatever it means, Data Loss, Data Leak, it means > whatever you want to buy)... > > There may be a place for those stuff, but it's not on core. Nor on second > level protection layers. > > In the end, ISO27002, PCI-DSS, CIA and AAA triads, what are they worth if > you add an IPS to your core? When memory is exausted, processing is starved, > you will have packet loss, latency, or you will be completely offline. And > what's CIA if you "security features" are breaking Integrity due to missing > packets, or breaking full Availability at all? What you have from CIA? Only > confidentiality? Better take that plug off. Same for AAA, if Authorization > and Authentication are broken or failed due to exaustion/starvation what you > get? Accounting/Auditing? So you will sit and read the logs to find out what > went wrong? > > Discouraging firewall/IDS/proxy protection layers is as bad as over > leveraging it. > > Dosage is what distinguishes the poison from the vaccine. > > -- > Patrick Tracanelli > FreeBSD Brasil > Tel.: (31) 3516-0800 > http://www.freebsdbrasil.com.br > "Long live Hanin Elias, Kim Deal!" > > -- 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 rdobbins at arbor.net Fri Feb 6 14:18:08 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 06 Feb 2015 21:18:08 +0700 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> Message-ID: <2A67E810-FBEE-4CB7-B73C-EA0F4C6EB31A@arbor.net> On 6 Feb 2015, at 20:08, Ray Soucy wrote: > An IDS tied into an internal RTBH setup to leverage uRPF filtering in > hardware can be pretty effective at detecting and blocking the typical > UDP attacks out there before they reach systems that don't handle that > as gracefully (e.g. firewalls or host systems). Using flow telemetry for this scales much, much better. One could easily set something like this up using open source flow telemetry collection/analysis tools. Of course, giving attackers the ability to spoof the IP addresses of their choice and then induce your network infrastructure into blocking said IP addresses isn't necessarily optimal, IMHO. I'm not a big fan of any kind of auto-mitigation for this reason - it's best to have a human operator in the loop. If one is determined to do this kind of auto-mitigation, it's probably a good idea to whitelist certain things which ought never to be S/RTBHed via appropriate route filtering on the trigger and/or edge devices where traffic will be dropped. ----------------------------------- Roland Dobbins From Patrick.Darden at p66.com Fri Feb 6 14:27:25 2015 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Fri, 6 Feb 2015 14:27:25 +0000 Subject: Checkpoint IPS In-Reply-To: <54D3FF52.2040005@freebsdbrasil.com.br> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> Message-ID: IPSes are like any security technology, they are only as good as their implementor/administrator. I've seen some installations just set up defaults and leave them that way without any maintenance nor much oversight of alarms. I've even seen some that do 0-day implementation of new signatures, and get some legitimate or even ALL traffic blocked by a bad signature (Astaro/Sophos UTM) update back in ~2004. On the other hand, I've seen some great implementations--some of which did a FANTASTIC job of making a network auditable, some of which made a network less liable legally and financially, and quite a few that made a network more secure. To me, the big drawback of an IPS is, no matter how well integrated, implemented, and maintained--it's fundamental nature is flawed. Instead of default-deny with white lists, it is default-allow with black lists. It will always lag behind. It will always allow infinitely large holes. That's why I prefer an OSI complete firewall instead, or else an IPS in detect mode only, or in certain cases an IPS used in a specific case, e.g. a WAF or SAF for a server/application/zone that is specifically fuzzy or will not adhere to security principles (vendor demilitarized zones, enclaves, whatever the buzz-word is at the moment). I understand the whole argument against state, and dismiss it. That's throwing the baby out with the bathwater. It isn't perfect, it can be overcome via DDOS and saturation, so we should get rid of it. Tanks can be destroyed by bazookas, whatever. Tanks are still useful in the battlefield if utilized properly. Firewalls and IPSes are the same way. --p From SNaslund at medline.com Fri Feb 6 14:32:46 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 6 Feb 2015 14:32:46 +0000 Subject: mpls over microwave In-Reply-To: <20150205214138.39D978CC@m0005311.ppops.net> References: <20150205214138.39D978CC@m0005311.ppops.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4015724A0D5@MUNPRDMBXA1.medline.com> I would try to recommend finding a microwave guy that knows IP. Quite a lot of them do now since most of their installs are IP traffic backhaul. Steven Naslund Chicago IL >-----Original Message-----> >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Weeks >Sent: Thursday, February 05, 2015 11:42 PM >To: nanog at nanog.org >Subject: Re: mpls over microwave >Thanks everyone, >I feel a lot more confident on this project after this discussion. I will be working with a comm engineer who'll be doing the various radio links. >I just need to be sure he can make the best decision as we're moving from ATM to MPLS and he doesn't understand the networking part and I only understand the basics of microwave links. >scott From eksffa at freebsdbrasil.com.br Fri Feb 6 14:52:35 2015 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Fri, 6 Feb 2015 12:52:35 -0200 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> Message-ID: <0BBB5E8B-E820-4B0B-BE72-D13C0567DD06@freebsdbrasil.com.br> Hello, > On 06/02/2015, at 11:08, Ray Soucy wrote: > > An IPS doesn't have to be in line. AFAIK this is basically what defines an IPS. > It can be something watching a tap and scripted to use something else > to block traffic (e.g. hardware filtering options on a router that can > handle it). You are naming IPS on what is actually an IDS+Active Response as I mentioned before (my #1 option of choice). Not been online won’t for instance prevent the so called single packet attacks and therefore what should be the advantage of an IPS over an IDS is just thrown away. Which, again, I accept what’s missed for what I still have. But I don’t think it can be named IPS acting passively+actively, since it’s not actually not preventing. > An IDS tied into an internal RTBH setup to leverage uRPF filtering in > hardware can be pretty effective at detecting and blocking the typical > UDP attacks out there before they reach systems that don't handle that > as gracefully (e.g. firewalls or host systems). That’s exactly the point I agree and adopt. Maybe a first packet will pass, but it takes longer anyway to be deterministic whether the traffic is common or attack traffic. It’s an IPs there and exausting/starving won’t cause issues to the network, only to it’s own capability. > Even if you keep it > from being automated and just have it be an IDS that you can have a > human respond to is pretty valuable. Not a coincidence that Bejtlich’s NSM101and TCP/IP Weapons School courses are usually sold out on Black Hat. Valuable humans behind the tools will always provide better benefits than what vendors may generically sell/deliver. > > > On Thu, Feb 5, 2015 at 6:40 PM, Patrick Tracanelli > wrote: >> >>> On 05/02/2015, at 12:31, Terry Baranski >>> wrote: >>> >>> On Thu, Feb 5, 2015 at 8:34 AM, Roland Dobbins wrote: >>> >>>> I've never heard a plausible anecdote, much less seen meaningful >>> >>> statistics, >>>> >>>> of these devices actually 'preventing' anything. >>> >>> >>> People tend to hear what they want to hear. Surely your claim can't be >>> that >>> an IPS has never, in the history of Earth, prevented an attack or exploit. >>> So it's unclear to me what you're actually trying to say here. >>> >>>> And the fact that well-known evasion techniques still work against these >>>> devices today, coupled with the undeniable proliferation of compromised >>>> hosts residing within networks supposedly 'protected' by these devices, >>>> militates against your proposition. >>> >>> >>> Your tendency of making blanket statements is somewhat baffling given the >>> multitude of intricacies, details, and varying circumstances involved in a >>> complex topic like this. To me, it's indicative of an overly-simplified >>> and/or biased way of looking at things. >>> >>> In any case, go ahead and stick with your router ACLs and (stateful!) >>> proxies. Different strokes. >>> >>> -Terry >> >> >> There's room for a good engineered strategy for protection which won't turn >> into a point of failure in the overall networking topology. >> >> For decades, since first rainbow series books were written and military >> "strategy" started to be added to information security, it's always been >> about defense in depth and layered defense. Today those buzzwords became an >> incredibly "bullshit bingo" on sales force strategy on selling magical boxes >> and people tend to forget the basics. Layers and the "depth" is not a theory >> just to be added to drawings and keynote presentations. >> >> Considering a simplistic topology for 3-tier (4 if you count T0) depth >> protection strategy: >> >> (Internet)--[Tier-0]--(Core Router)--[Tier1]--(core >> switch)--[Tier2]--(DMZ)--[Tier3]--(Golden Secret) >> >> One security layer (tier, whatever) is there to try to fill the gap from the >> previous one. >> >> How deep you have to dig depends on who you are. If you are the end >> organization willing to protect the golden secret, how complex is your >> topology, or if you are the carrier, the telecom the company worried only >> about BGP, PPS, BPS and availability other than the actual value for what's >> the real target for the attack (if not availability) >> >> In summary, in my experience what will (not) work is: >> >> 1) Tier 0 & Tier 1 >> On border, core, (Tier0) or on Tier-1 protection layers (typical >> "firewall/dmz" topological position) >> >> - Memory and CPU exaustion will shut down your operations (increase latency >> and decrease availability) easily, if you have a Protecting Inbound Proxy >> (Web Application Firewall, for the sales jargon), Stateful Firewall or IPS. >> >> The thing here is, you are insane or naive if you believe a finite state >> machine with finite resources can protect you from a virtually infinite >> (unlimited) source of attacks. No matter how much RAM you have, how much CPU >> cycles you have, they are finite, and since those "amazing stateful w/ deep >> inspection, scrub, normalization and reassembly" features on a firewall will >> demand at least 4K RAM per session and a couple CPU cycles per test, you >> have a whole "line rate" (1.4Mpps / 14Mpps for 1GbE 10GbE ports) attack >> potential, and come on, if a single or a 3-way packets sequence will cost >> you a state, it's an easy math count to find out you are in a bad position >> trying to "secure" those Tier0 and Tier1 topological locations. It's just >> easier and cheaper for the one attacking, than for your amazing firewall or >> IPS. >> >> So what to do here? Try to get rid of most automated/scripted/simple attack >> you can. You can do ingress filtering, a lot of BCP, protection against >> SNMP/NTP/DNS amplification, verify reverse path, (verrevpath, antipsoof, >> verrevreachability), and many good / effective (but limited) protection with >> ACL, data plane protection mechanisms, BGP blackholing, Null Routing >> (sending stuff to disc0 on BSD, null0 on Cisco, etc) and Stateles >> Firewalling. >> >> Also, an IDS sensor might fit here, because if CPU/Memory starvation happens >> on an IDS sensor, the worst thing will happen is some packets getting routed >> without proper processing. But still, they will get routed. >> >> Always stateles, always simple tests. No Layer7 inspection of any form, no >> load balancer, WAF, whatever. No regex, hell no! No memory pointers that >> can point to dark processor/memory locations (again, no regex). >> >> 2) On Tier 2 protection (A defense depth that comes after core protection >> and after Tier-1): >> >> - Will miserably fail if you use stateful firewall in excess >> - Will fail even quicker if you use a WAF or IPS >> >> Many "security engineers" and "security experts" (or worse, security tools >> vendors and developers) excessively use stateful tests on transport >> protocols that are simply... stateles. >> >> What good you have on stateful firewalling... ICMP? UDP? DDP? IGMP? come on, >> all those state timers are worthless and your memory limits will reach very >> soon. Remember, in the average, 4K RAM at least, per stateful session. Much >> more resources are needed for IPS, much much more for inbound proxy (WAF), >> not to mention CPU. >> >> Will you add an IPS here? What for, other than easing putting down and >> making your network and services unavailable? >> >> Proxy? Mod Security? Hell no! Not here. Did you check how many regex and >> rules you have in the "base_rules" collection for a Top 10 OWASP protection >> on Mod Security? What about vendor specifics rules, or Sans Top 25 >> specifics. >> >> This is just not the place. >> >> Also, let's rationale, what is your real benefit on deep inspection stateful >> filtering on those SSH sessions allowing for your trusted locations only? >> Really, what good will it make? Drop it stateles, allow it stateles! If you >> really believe stateful worths something for protocols such as SSH, do it >> somewhere else (Tier3 or host-based). >> >> Focus on stateful protection only for what really needs some protection of >> this kind. Packets related, fragile services for packets arbitrarily >> assembled. Maybe SIP (SIP, not RTP), HTTPS, HTTP. Layer3/Layer4 fragile and >> public services, after some stateles inspection was already done on Tier1, >> should deserve stateful protection only. Not your whole network! Not your >> whole set of services or services. >> >> And no ICMP, no UDP do deserve stateful. >> >> Also, pick up a good tool for this. >> >> Most sysadmins, security guys or network operators never notice how their >> tools may betray 'em hardly (by deault). >> >> For example one use OpenBSD PF firewall, every rule you make will >> "automagically" become an stateful rule. And this is not good! This is >> terrible! This "auto" behavior makes the security engineer blind, since the >> rules he is writing is not the rules he is adding to kernel. >> >> OpenBSD's PF has a "no state" option and nobody uses it! It means you are >> doing it wrong... UDP/ICMP/TCP rules always have "keep state" added, if you >> don't explicitly set "no state". Beware! >> >> The same is valid for Linux Netfilter, and 9 in 10 commercial firewalls >> (checkpoint, mikrotik, fortinet, whatever...). >> >> FreeBSD's ipfw on the other hand is stateles by default. It means if you >> don't explicitly add "keep-state" there, it's stateles. Which is good, >> unless you explicitly want a rule to be stateful. It's excellent as a >> default behavior for protection layers not close to your "golden egg >> provider". On the other hand, ipfw by default has a limit of 4096 states >> which is TOO LOW. Beware too! >> >> Regarding IPS/WAF/Proxy or "Next Generation" firewalls, this is not the >> place to add it. >> >> On the other hand you need some level of extra protection firewalls will not >> provide, and some Layer7 inspection on Tier2 will be good. >> >> But not Proxy! Not mod security! and not IPS! (no WAF) >> >> IMHO, an IDS will fit good here. >> >> IDS, not IPS, not IDP. Not a magical solution... >> >> Why, from my past experiences, an IDS approach here will fit? Due it's >> passive nature. If your IDS (say, Suricata, Bro, keeping on open source, or >> your commercial option of choice) starves on CPU or memory, what's the worst >> thing to happen? >> >> You will have a high number of PPS on that perimeter port passing without >> getting processed/inspected. Your overall security will decrease, but you >> still have Tier3 (and maybe other tiers) to fulfill the gap! Packets that >> still can be processed should have active response in place taking care of a >> lot of attacks. >> >> What I mean is, if you have limited (and you do have limited) processing >> and memory power, say you can IDS inspect 400Kpps but a 1Mpps attack is >> ongoing, you have 40% inspection power, but packets not processed still get >> routed! Without latency and without packet loss because it's an IDS and not >> an IPS. It's not inline. It's passive, sitting there. Limited resources, >> priority and lower kernel CPU scheduler relevance. >> >> And for those 40% (very bad scenario I am drawing here) you still have >> active response in place, rerouting, reconfiguring stateles firewall, >> stateles ACLs and null routes on upper tiers (tier 0, tier 1, routers, >> switches) and lower tiers (tier 3 reconfigured upon tier 2 decision). >> >> What you will do is try to fill the gap on next tiers, or increase your >> filtering capabilities that are still stateles or passive. >> >> For many business, this is the end for added protection layers. A big ISP, >> transport provider, content delivery business... more protection from this >> point is something for the specific end business, and completely related to >> their needs, their business model, process, responsibilities and overall >> evaluated requirements. Not a general model to fit. >> >> But for everyone else up to this tier you have relevant security mechanisms >> and tecnology added, and still low starvation/exaustion risks due to the >> stateles and passive nature of the approach. >> >> 3) On Tier 3, a protection strategy for your "golden eggs" provider, the >> golden secret, your business secret and intelligence >> >> Usually, this protection level is for the corporate strategy. The business, >> not the carrier, the service provider or the network operator. And is a >> business specific requirement. Meaning it may not exist at all! >> >> Now, for me, here is where you add more stateful inspection (still, only >> what is actually efficient, not that god damn echo reply/request wasting >> memory to be tracked down - useless!). >> >> Here is a good place for a WAF, after firewall and IDS protection took >> place. WAF is a not a panaceia for anything, it's aimed for specific attacks >> against applications and protocols, is not resilient to coward attacks >> (volumetric, L3/L4 exaustion, etc). And a proxy in the end is always a web >> server, so inherits all it's fragility, and therefore it must be protected >> as well, before it can actually protect anything else. >> >> Host Intrusion Detection central servers (receiving information gathered >> from HIDS on the actual hosts) also fits Tier3. As well as other host-based >> controls that may add telemetry information to a central location. >> >> Talking about telemetry, it's important everywhere, and while generating >> flows or snmp info grabbing may impact processing usage on critical core >> devices, those extra added boxes should also passively help telemetry, with >> flow generation or minimum capability for snmp servings. >> >> Nothing here is new. I am talking about, again, basic stuff discussed for >> decades on colored cover military books, drafts, discussions and BCPs and >> really old stuff discussed for people who may be already dead, sometimes >> (Itojun and other samurais' missed). I'm only mentioning the basic 3 tech >> domains (firewall, ids, proxy), but the other two basic (pen test, vuln >> scan) that are more process than technology are important as well. >> >> For me, and again this is very personal opinion, I never run an IPS unless >> the customer "really wants to" (or a stupid compliance requirement really >> requires to). An IDS+Active Response is as good as IPS, and the only extra >> benefit an IPS will add compared to IDS is related to "single packet >> attacks", that ones that will pass quickly enough before the active response >> blocks it. But "single packet" attacks are related to poorly written >> software (or unpatched / not fixed software) since it's not really an >> attack, it's a trigger to bad code misbehavior and should be addressed on >> the host. >> >> This is a very simple model, and easy to understand. However how many >> situations we've seen big companies getting completely unavailable or AAA >> getting broken because people insist to buy (and sell) "miracle boxes" added >> to core locations, and those miracle boxes will have amazing deep inspection >> firewalls or IPS or DLP (whatever it means, Data Loss, Data Leak, it means >> whatever you want to buy)... >> >> There may be a place for those stuff, but it's not on core. Nor on second >> level protection layers. >> >> In the end, ISO27002, PCI-DSS, CIA and AAA triads, what are they worth if >> you add an IPS to your core? When memory is exausted, processing is starved, >> you will have packet loss, latency, or you will be completely offline. And >> what's CIA if you "security features" are breaking Integrity due to missing >> packets, or breaking full Availability at all? What you have from CIA? Only >> confidentiality? Better take that plug off. Same for AAA, if Authorization >> and Authentication are broken or failed due to exaustion/starvation what you >> get? Accounting/Auditing? So you will sit and read the logs to find out what >> went wrong? >> >> Discouraging firewall/IDS/proxy protection layers is as bad as over >> leveraging it. >> >> Dosage is what distinguishes the poison from the vaccine. >> >> -- >> Patrick Tracanelli >> FreeBSD Brasil >> Tel.: (31) 3516-0800 >> http://www.freebsdbrasil.com.br >> "Long live Hanin Elias, Kim Deal!" >> >> > > > > -- > 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 -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601 at sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From jmaslak at antelope.net Fri Feb 6 15:25:27 2015 From: jmaslak at antelope.net (Joel Maslak) Date: Fri, 6 Feb 2015 08:25:27 -0700 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <08cd01d0416a$84c92d20$8e5b8760$@oneunified.net> Message-ID: On Thu, Feb 5, 2015 at 10:47 AM, Roland Dobbins wrote: > > On 6 Feb 2015, at 0:38, Raymond Burkholder wrote: > > > There must some sort of value in that? > > No - patch the servers. > Patching servers protects against >0 Day attacks only. This does not protect against 0 day attacks, unless you know of an OS vendor that writes good code without security holes. What type of device needed depends on risk, what you are protecting, what attacks are important, etc. It's not a simple matter of "firewall bad" or "firewall good". I won't even get into the stateless-vs-stateful debate, because it's more complex than "stateful bad" (*cough* SIP *cough*). Nor will I mention that it depends on what your protecting to figure out how much of each of availability or confidentiality or integrity you need - you might need lots of integrity but little availability, for instance. From Patrick.Darden at p66.com Fri Feb 6 15:34:53 2015 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Fri, 6 Feb 2015 15:34:53 +0000 Subject: Checkpoint IPS In-Reply-To: <0BBB5E8B-E820-4B0B-BE72-D13C0567DD06@freebsdbrasil.com.br> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> <0BBB5E8B-E820-4B0B-BE72-D13C0567DD06@freebsdbrasil.com.br> Message-ID: <14e22829b1ae4f018451e191a7a83e45@BRTEXMB02.phillips66.net> Absolutely. > Valuable humans behind the tools will always provide better benefits than what vendors may generically sell/deliver. From skakaroukas at rolaware.com Fri Feb 6 11:45:48 2015 From: skakaroukas at rolaware.com (Spyros Kakaroukas) Date: Fri, 6 Feb 2015 11:45:48 +0000 Subject: mpls over microwave In-Reply-To: <20150205135504.39F63F7A@m0048136.ppops.net> References: <20150205135504.39F63F7A@m0048136.ppops.net> Message-ID: Hey, We run few mpls links ( 7600s/3600s on the mpls side mostly ) over Ceragon wireless gear. Nothing too fancy, I just treat them as switches ( or even just "cables" for some boxes, not doing mac learning at all ). No issues whatsoever on the networking side. My thoughts and words are my own. Kind Regards, Spyros -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Weeks Sent: Thursday, February 05, 2015 11:55 PM To: nanog at nanog.org Subject: mpls over microwave Anyone doing MPLS over microwave radios? Please share your experiences on list or off. scott This e-mail and any attachment(s) contained within are confidential and are intended only for the use of the individual to whom they are addressed. The information contained in this communication may be privileged, or exempt from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete the communication without retaining any copies. Rolaware Hellas SA is not responsible for, nor endorses, any opinion, recommendation, conclusion, solicitation, offer or agreement or any information contained in this communication. From rdobbins at arbor.net Fri Feb 6 16:08:31 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 06 Feb 2015 23:08:31 +0700 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> Message-ID: <15AB2602-8A05-43E8-A139-2831851EE6DD@arbor.net> On 6 Feb 2015, at 21:27, Darden, Patrick wrote: > I understand the whole argument against state, and dismiss it. One can 'dismiss' the speed of light in a vacuum or the Planck constant, but that doesn't exempt one from their constraints. ----------------------------------- Roland Dobbins From tim at bobbroadband.com Fri Feb 6 16:11:46 2015 From: tim at bobbroadband.com (Huffman, Timothy) Date: Fri, 6 Feb 2015 16:11:46 +0000 Subject: mpls over microwave In-Reply-To: References: <20150205135504.39F63F7A@m0048136.ppops.net> Message-ID: <403E423F9B5CB4499965EDE05C50BF1DB707A9@CWWAPP471.windstream.com> We run MPLS over wireless links of all kinds quite extensively. The key is to make sure that packet loss is at a minimum (duh), and to ensure that your wireless links have a large enough MTU to pass the additional bytes for each label. Other than that, we treat the wireless links as wires. -- Tim Huffman Staff Manager - Engineering | Windstream 999 Oak Creek Dr | Lombard, IL 60148 timothy.huffman at windstream.com | windstreambusiness.com o: 630.590.6012 | m: 630.340.1925 | f: 630.986.2496 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Spyros Kakaroukas Sent: Friday, February 06, 2015 5:46 AM To: 'surfer at mauigateway.com'; nanog at nanog.org Subject: RE: mpls over microwave Hey, We run few mpls links ( 7600s/3600s on the mpls side mostly ) over Ceragon wireless gear. Nothing too fancy, I just treat them as switches ( or even just "cables" for some boxes, not doing mac learning at all ). No issues whatsoever on the networking side. My thoughts and words are my own. Kind Regards, Spyros -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Weeks Sent: Thursday, February 05, 2015 11:55 PM To: nanog at nanog.org Subject: mpls over microwave Anyone doing MPLS over microwave radios? Please share your experiences on list or off. scott This e-mail and any attachment(s) contained within are confidential and are intended only for the use of the individual to whom they are addressed. The information contained in this communication may be privileged, or exempt from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete the communication without retaining any copies. Rolaware Hellas SA is not responsible for, nor endorses, any opinion, recommendation, conclusion, solicitation, offer or agreement or any information contained in this communication. ---------------------------------------------------------------------- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. From Patrick.Darden at p66.com Fri Feb 6 16:23:09 2015 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Fri, 6 Feb 2015 16:23:09 +0000 Subject: Checkpoint IPS In-Reply-To: <15AB2602-8A05-43E8-A139-2831851EE6DD@arbor.net> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> <15AB2602-8A05-43E8-A139-2831851EE6DD@arbor.net> Message-ID: <12896a45c4544bd8802ef1204949fa3a@BRTEXMB02.phillips66.net> And when your opinion is an acknowledged universal constant, I will tip my hat to you. In the meantime, your argument is extremely soundbitey--sounds great, but stupid. --p -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins Sent: Friday, February 06, 2015 10:09 AM To: nanog at nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS On 6 Feb 2015, at 21:27, Darden, Patrick wrote: > I understand the whole argument against state, and dismiss it. One can 'dismiss' the speed of light in a vacuum or the Planck constant, but that doesn't exempt one from their constraints. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Fri Feb 6 16:31:54 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 06 Feb 2015 23:31:54 +0700 Subject: Checkpoint IPS In-Reply-To: <12896a45c4544bd8802ef1204949fa3a@BRTEXMB02.phillips66.net> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> <15AB2602-8A05-43E8-A139-2831851EE6DD@arbor.net> <12896a45c4544bd8802ef1204949fa3a@BRTEXMB02.phillips66.net> Message-ID: <4715E281-B72B-4A1D-BE80-623C007D4CB4@arbor.net> On 6 Feb 2015, at 23:23, Darden, Patrick wrote: > And when your opinion is an acknowledged universal constant, I will > tip my hat to you. It's been a constant for the last couple of decades - I can't count the number of times I've been involved in mitigating penny-ante DDoS attacks which succeeded *solely* due to state exhaustion on stateful firewalls, 'IPS' devices, and load-balancers. I've seen a 20gb/sec commercial stateful firewall taken down by a 3mb/sec spoofed SYN-flood. I've seen a 10gb/sec commercial load-balancer taken down by 60 second at 6kpps - yes, 6kpps - of HOIC. And so on, and so forth. 'Dismiss' it all you like, but it's a real issue, as others on this list know from bitter experience. ----------------------------------- Roland Dobbins From colinj at gt86car.org.uk Fri Feb 6 16:32:25 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Fri, 6 Feb 2015 16:32:25 +0000 Subject: Checkpoint IPS In-Reply-To: <12896a45c4544bd8802ef1204949fa3a@BRTEXMB02.phillips66.net> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> <15AB2602-8A05-43E8-A139-2831851EE6DD@arbor.net> <12896a45c4544bd8802ef1204949fa3a@BRTEXMB02.phillips66.net> Message-ID: Thought I would add Astaro IPS works great, great functionality and does prevent ddos and exploits. Colin From billt at mahagonny.com Fri Feb 6 16:39:18 2015 From: billt at mahagonny.com (Bill Thompson) Date: Fri, 06 Feb 2015 08:39:18 -0800 Subject: Dynamic routing on firewalls. In-Reply-To: <6290.74.129.32.29.1423192783.iglou@webmail.iglou.com> References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <6290.74.129.32.29.1423192783.iglou@webmail.iglou.com> Message-ID: Just because a cat has kittens in the oven, you don't call them biscuits. A firewall can route, but it is not a router. Both have specialized tasks. You can fix a car with a swiss army knife, but why would you want to? -- Bill Thompson billt at mahagonny.com On February 5, 2015 7:19:43 PM PST, Jeff McAdams wrote: > >On Thu, February 5, 2015 20:02, Joe Hamelin wrote: >>> On Feb 5, 2015, at 2:49 PM, Ralph J.Mayer >>> wrote: >>> a router is a router and a firewall is a firewall. Especially a >Cisco ASA >>> is no router, period. >> >> Man-o-man did I find that out when we had to renumber our network >after >> we got bought by the French. > >> Oh, I'll just pop on a secondary address on this interface... What? > >> Needed to go through fits just to get a hairpin route in the thing. > >> The ASA series is good at what it does, just don't plan on it acting >like >> router IOS. > >Sorry, but I'm with Owen. > >Square : Rectangle :: Firewall : Router > >A firewall is a router, despite how much so many security folk try to >deny >it. And firewalls that seem to try to intentionally be crappy routers >(ie, ASAs) have no place in my network. > >If it can't be a decent router, then its going to suck as a firewall >too, >because a firewall has to be able to play nice with the rest of the >network, and if they can't do that, then I have no use for them. I'll >get >a firewall that does. From Patrick.Darden at p66.com Fri Feb 6 16:44:14 2015 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Fri, 6 Feb 2015 16:44:14 +0000 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> <15AB2602-8A05-43E8-A139-2831851EE6DD@arbor.net> <12896a45c4544bd8802ef1204949fa3a@BRTEXMB02.phillips66.net> Message-ID: Sorry, didn't mean to imply otherwise. Had an incident back in ~2004 where an IPS signature update closed ALL network traffic. Including fix-it updates. Definitely a case where the IPS caused major difficulties for a network. --p -----Original Message----- From: Colin Johnston [mailto:colinj at gt86car.org.uk] Sent: Friday, February 06, 2015 10:32 AM To: Darden, Patrick Cc: Colin Johnston; Roland Dobbins; nanog at nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS Thought I would add Astaro IPS works great, great functionality and does prevent ddos and exploits. Colin From colinj at gt86car.org.uk Fri Feb 6 16:46:10 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Fri, 6 Feb 2015 16:46:10 +0000 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> <15AB2602-8A05-43E8-A139-2831851EE6DD@arbor.net> <12896a45c4544bd8802ef1204949fa3a@BRTEXMB02.phillips66.net> Message-ID: Yes, update can cause problems, same as router code updates as well. but update is price of progress. Col > On 6 Feb 2015, at 16:44, Darden, Patrick wrote: > > > Sorry, didn't mean to imply otherwise. Had an incident back in ~2004 where an IPS signature update closed ALL network traffic. Including fix-it updates. Definitely a case where the IPS caused major difficulties for a network. > > --p > > -----Original Message----- > From: Colin Johnston [mailto:colinj at gt86car.org.uk] > Sent: Friday, February 06, 2015 10:32 AM > To: Darden, Patrick > Cc: Colin Johnston; Roland Dobbins; nanog at nanog.org > Subject: [EXTERNAL]Re: Checkpoint IPS > > Thought I would add > > Astaro IPS works great, great functionality and does prevent ddos and exploits. > > Colin > From Patrick.Darden at p66.com Fri Feb 6 16:47:29 2015 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Fri, 6 Feb 2015 16:47:29 +0000 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> <15AB2602-8A05-43E8-A139-2831851EE6DD@arbor.net> <12896a45c4544bd8802ef1204949fa3a@BRTEXMB02.phillips66.net> Message-ID: Auto-Update can cause problems. I take the stance that updates should be verified in a CERT or ISO first, before being operationalized. --p -----Original Message----- From: Colin Johnston [mailto:colinj at gt86car.org.uk] Sent: Friday, February 06, 2015 10:46 AM To: Darden, Patrick Cc: Colin Johnston; Roland Dobbins; nanog at nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS Yes, update can cause problems, same as router code updates as well. but update is price of progress. Col > On 6 Feb 2015, at 16:44, Darden, Patrick wrote: > > > Sorry, didn't mean to imply otherwise. Had an incident back in ~2004 where an IPS signature update closed ALL network traffic. Including fix-it updates. Definitely a case where the IPS caused major difficulties for a network. > > --p > > -----Original Message----- > From: Colin Johnston [mailto:colinj at gt86car.org.uk] > Sent: Friday, February 06, 2015 10:32 AM > To: Darden, Patrick > Cc: Colin Johnston; Roland Dobbins; nanog at nanog.org > Subject: [EXTERNAL]Re: Checkpoint IPS > > Thought I would add > > Astaro IPS works great, great functionality and does prevent ddos and exploits. > > Colin > From colinj at gt86car.org.uk Fri Feb 6 16:49:09 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Fri, 6 Feb 2015 16:49:09 +0000 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> <15AB2602-8A05-43E8-A139-2831851EE6DD@arbor.net> <12896a45c4544bd8802ef1204949fa3a@BRTEXMB02.phillips66.net> Message-ID: <7B72D2C3-76D9-4281-9FAB-ABD2F4BA57DB@gt86car.org.uk> yes, using new rules via test ips good best practice as well. > On 6 Feb 2015, at 16:47, Darden, Patrick wrote: > > > Auto-Update can cause problems. I take the stance that updates should be verified in a CERT or ISO first, before being operationalized. > --p > > -----Original Message----- > From: Colin Johnston [mailto:colinj at gt86car.org.uk] > Sent: Friday, February 06, 2015 10:46 AM > To: Darden, Patrick > Cc: Colin Johnston; Roland Dobbins; nanog at nanog.org > Subject: [EXTERNAL]Re: Checkpoint IPS > > Yes, update can cause problems, same as router code updates as well. > but update is price of progress. > > Col > >> On 6 Feb 2015, at 16:44, Darden, Patrick wrote: >> >> >> Sorry, didn't mean to imply otherwise. Had an incident back in ~2004 where an IPS signature update closed ALL network traffic. Including fix-it updates. Definitely a case where the IPS caused major difficulties for a network. >> >> --p >> >> -----Original Message----- >> From: Colin Johnston [mailto:colinj at gt86car.org.uk] >> Sent: Friday, February 06, 2015 10:32 AM >> To: Darden, Patrick >> Cc: Colin Johnston; Roland Dobbins; nanog at nanog.org >> Subject: [EXTERNAL]Re: Checkpoint IPS >> >> Thought I would add >> >> Astaro IPS works great, great functionality and does prevent ddos and exploits. >> >> Colin >> > From lists at mtin.net Fri Feb 6 17:14:27 2015 From: lists at mtin.net (Justin Wilson - MTIN) Date: Fri, 6 Feb 2015 12:14:27 -0500 Subject: Input Regarding Cogent and NTT In-Reply-To: <1C88157B8801CB448C108286C81ECB631B8C4F@SRV-SAM-MBOX02.lan.thrifty.net> References: <1C88157B8801CB448C108286C81ECB631B8C4F@SRV-SAM-MBOX02.lan.thrifty.net> Message-ID: <9C770E40-5A65-47FB-AC51-C5C096B7012C@mtin.net> Cogent has been very good in my experience. They have some issues they need to work out, but are pretty solid. We have had some issues where they have said they are doing maintenance on such and such night and it comes a day early. We have also seen some routing weirdness when it comes to route selection. Ive had a connection, server, something on Cogent for about 12 years now. I started with a server in Chicago at the Board of Trade building. At that time Cogent was the home of cheap web-hosts, ware, and porn. I remember a year or so after I had that server the big folks like ATT and some others de-peered with Cogent. Many of the web-sites I was hosting were simply not reachable for a few days from a big majority of the Internet. I think the sheer amount of web-sites and content convinced the big folks to bring up the peering. I was working for a large dial-up ISP at the time and remember getting call after call about someone not being able to reach their favorite web-site. Cogent tech support has always been top notch. They answer the phone and I have always been directed to an engineer that can help right away. As of 6 months ago their ticketing system still sucked, but I think everyone’s does. LOL. This is my on-list stuff. I can go into more detail if anyone wants to know. Justin Wilson j2sw at mtin.net http://www.mtin.net Managed Services – xISP Solutions – Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering – Transit – Internet Exchange > On Feb 5, 2015, at 12:24 PM, Jack Stonebraker wrote: > > My organization is currently shopping for some additional Transit Capacity to augment our existing interconnects. We've got around 8 distinct AS's that we're receiving transit routes from, followed by a handful of Public IX's and Private PNI's to AS's that warrant them. That said, the networks that are on our radar are Cogent and NTT. I've done some due diligence poking around on their Looking Glass, but I'd love to hear any user experiences from the community, both from a Layer 3 Perspective, as well as an Operational Perspective (Working with the businesses themselves). Feel free to contact me off-list and thanks in advance for your time. > > [cid:image002.jpg at 01CFE2F3.A6F973D0] > > > Jack Stonebraker | Sr. IP Network Engineer > (512) 878-5627 | jack.stonebraker at mygrande.com > Grande Communications Networks > 401 Carlson Circle | San Marcos, Texas | 78666 > > > > From colton.conor at gmail.com Fri Feb 6 17:26:55 2015 From: colton.conor at gmail.com (Colton Conor) Date: Fri, 6 Feb 2015 11:26:55 -0600 Subject: Provider to Blend with Level3 Message-ID: We have a network that is single homed with Level3 at this time in Dallas. They already have BGP and their own ASN and IP setup. Who would you recommend for a second provider in Dallas to blend with Level3? Assuming Level3 and this other provider would be the only two in the blend for a long time to come? Client was talking to TWT, but now that they are being bought by Level3 that doesn't make much sense. From CrawfordS at evangel.edu Fri Feb 6 17:57:37 2015 From: CrawfordS at evangel.edu (Crawford, Scott) Date: Fri, 6 Feb 2015 17:57:37 +0000 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: <6D484C0A-8BB8-4145-AC95-2F9C9D8961CD@delong.com> References: <6D484C0A-8BB8-4145-AC95-2F9C9D8961CD@delong.com> Message-ID: On Jan 30, 2015, at 07:37 , Owen DeLong wrote: > /48 for all customer sites is not at all unreasonable and is fully supported by ARIN policy. >Where Bill is correct is that some customers may have more than one site. The official >policy definition of a site is a single building or structure, or, in the case of a multi-tenant >building or structure, a single tenant within that building. Yes, this could technically >mean that a college dorm contains thousands of sites and could justify thousands of /48s. Is this your recommendation for colleges? Or, are you simply pointing out a possible interpretation of ARIN policy? From dougb at dougbarton.us Fri Feb 6 18:09:45 2015 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 06 Feb 2015 10:09:45 -0800 Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <6290.74.129.32.29.1423192783.iglou@webmail.iglou.com> Message-ID: <54D50369.1020907@dougbarton.us> On 2/6/15 8:39 AM, Bill Thompson wrote: > You can fix a car with a swiss army knife, but why would you want to? Is it a metric swiss army knife? From cscora at apnic.net Fri Feb 6 18:12:34 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Feb 2015 04:12:34 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201502061812.t16ICYvC019777@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 07 Feb, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 531413 Prefixes after maximum aggregation (per Origin AS): 203223 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 258742 Total ASes present in the Internet Routing Table: 49323 Prefixes per ASN: 10.77 Origin-only ASes present in the Internet Routing Table: 36426 Origin ASes announcing only one prefix: 16291 Transit ASes present in the Internet Routing Table: 6256 Transit-only ASes present in the Internet Routing Table: 171 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 108 Max AS path prepend of ASN ( 60548) 101 Prefixes from unregistered ASNs in the Routing Table: 1729 Unregistered ASNs in the Routing Table: 422 Number of 32-bit ASNs allocated by the RIRs: 8523 Number of 32-bit ASNs visible in the Routing Table: 6641 Prefixes from 32-bit ASNs in the Routing Table: 24025 Number of bogon 32-bit ASNs visible in the Routing Table: 6 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 366 Number of addresses announced to Internet: 2723652128 Equivalent to 162 /8s, 87 /16s and 162 /24s Percentage of available address space announced: 73.6 Percentage of allocated address space announced: 73.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.2 Total number of prefixes smaller than registry allocations: 180263 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 131329 Total APNIC prefixes after maximum aggregation: 38230 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 136555 Unique aggregates announced from the APNIC address blocks: 55629 APNIC Region origin ASes present in the Internet Routing Table: 5025 APNIC Prefixes per ASN: 27.18 APNIC Region origin ASes announcing only one prefix: 1231 APNIC Region transit ASes present in the Internet Routing Table: 882 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 107 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1290 Number of APNIC addresses announced to Internet: 741427840 Equivalent to 44 /8s, 49 /16s and 74 /24s Percentage of available APNIC address space announced: 86.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 175419 Total ARIN prefixes after maximum aggregation: 86719 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 177355 Unique aggregates announced from the ARIN address blocks: 83028 ARIN Region origin ASes present in the Internet Routing Table: 16477 ARIN Prefixes per ASN: 10.76 ARIN Region origin ASes announcing only one prefix: 6085 ARIN Region transit ASes present in the Internet Routing Table: 1723 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 21 Number of ARIN region 32-bit ASNs visible in the Routing Table: 338 Number of ARIN addresses announced to Internet: 1060286496 Equivalent to 63 /8s, 50 /16s and 176 /24s Percentage of available ARIN address space announced: 56.1 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: 129626 Total RIPE prefixes after maximum aggregation: 64254 RIPE Deaggregation factor: 2.02 Prefixes being announced from the RIPE address blocks: 135915 Unique aggregates announced from the RIPE address blocks: 83195 RIPE Region origin ASes present in the Internet Routing Table: 17842 RIPE Prefixes per ASN: 7.62 RIPE Region origin ASes announcing only one prefix: 8129 RIPE Region transit ASes present in the Internet Routing Table: 2942 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 108 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3422 Number of RIPE addresses announced to Internet: 692703616 Equivalent to 41 /8s, 73 /16s and 209 /24s Percentage of available RIPE address space announced: 100.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 58338 Total LACNIC prefixes after maximum aggregation: 11023 LACNIC Deaggregation factor: 5.29 Prefixes being announced from the LACNIC address blocks: 67733 Unique aggregates announced from the LACNIC address blocks: 31528 LACNIC Region origin ASes present in the Internet Routing Table: 2402 LACNIC Prefixes per ASN: 28.20 LACNIC Region origin ASes announcing only one prefix: 639 LACNIC Region transit ASes present in the Internet Routing Table: 482 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 34 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1502 Number of LACNIC addresses announced to Internet: 167694592 Equivalent to 9 /8s, 254 /16s and 209 /24s Percentage of available LACNIC address space announced: 100.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12498 Total AfriNIC prefixes after maximum aggregation: 2953 AfriNIC Deaggregation factor: 4.23 Prefixes being announced from the AfriNIC address blocks: 13489 Unique aggregates announced from the AfriNIC address blocks: 5037 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 18.35 AfriNIC Region origin ASes announcing only one prefix: 207 AfriNIC Region transit ASes present in the Internet Routing Table: 156 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 89 Number of AfriNIC addresses announced to Internet: 61107456 Equivalent to 3 /8s, 164 /16s and 109 /24s Percentage of available AfriNIC address space announced: 60.7 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2882 11553 912 Korea Telecom 17974 2823 904 77 PT Telekomunikasi Indonesia 7545 2506 336 127 TPG Telecom Limited 4755 1973 421 202 TATA Communications formerly 4538 1758 4190 71 China Education and Research 9829 1686 1325 36 National Internet Backbone 9808 1527 6719 19 Guangdong Mobile Communicatio 4808 1460 2218 436 CNCGROUP IP network China169 9583 1392 115 572 Sify Limited 9498 1296 336 97 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 2980 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 3356 2566 10683 471 Level 3 Communications, Inc. 18566 2042 379 183 MegaPath Corporation 20115 1853 1827 447 Charter Communications 6983 1622 866 244 EarthLink, Inc. 4323 1621 1037 406 tw telecom holdings, inc. 30036 1543 322 497 Mediacom Communications Corp 701 1392 11268 679 MCI Communications Services, 22561 1331 411 240 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1968 301 355 TELLCOM ILETISIM HIZMETLERI A 20940 1553 605 1159 Akamai International B.V. 8402 1373 544 15 OJSC "Vimpelcom" 6849 1233 356 25 JSC "Ukrtelecom" 31148 1045 45 21 Freenet Ltd. 13188 1040 97 60 TOV "Bank-Inform" 8551 901 373 48 Bezeq International-Ltd 9198 848 349 25 JSC Kazakhtelecom 12479 848 793 85 France Telecom Espana SA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3049 498 262 Telmex Colombia S.A. 28573 2343 2141 111 NET Servi�os de Comunica��o S 7303 1771 1173 234 Telecom Argentina S.A. 6147 1713 374 30 Telefonica del Peru S.A.A. 8151 1515 3113 430 Uninet S.A. de C.V. 6503 1227 421 57 Axtel, S.A.B. de C.V. 7738 1001 1882 42 Telemar Norte Leste S.A. 26615 920 2325 35 Tim Celular S.A. 3816 908 395 150 COLOMBIA TELECOMUNICACIONES S 18881 862 1037 23 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1537 958 13 TE-AS 24863 958 284 26 Link Egypt (Link.NET) 36903 479 241 90 Office National des Postes et 36992 373 845 30 ETISALAT MISR 37492 324 144 64 Orange Tunisie 24835 295 144 9 Vodafone Data 3741 250 921 209 Internet Solutions 29571 234 21 12 Cote d'Ivoire Telecom 36947 197 807 13 Telecom Algeria 15706 176 32 6 Sudatel (Sudan Telecom Co. Lt Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3049 498 262 Telmex Colombia S.A. 22773 2980 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 4766 2882 11553 912 Korea Telecom 17974 2823 904 77 PT Telekomunikasi Indonesia 3356 2566 10683 471 Level 3 Communications, Inc. 7545 2506 336 127 TPG Telecom Limited 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2343 2141 111 NET Servi�os de Comunica��o S 18566 2042 379 183 MegaPath Corporation 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 2891 2840 BellSouth.net Inc. 22773 2980 2839 Cox Communications Inc. 17974 2823 2746 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2506 2379 TPG Telecom Limited 28573 2343 2232 NET Servi�os de Comunica��o S 3356 2566 2095 Level 3 Communications, Inc. 4766 2882 1970 Korea Telecom 18566 2042 1859 MegaPath Corporation 4755 1973 1771 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 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.92.160.0/24 14013 EPSON America (Factory Automa 23.92.161.0/24 14013 EPSON America (Factory Automa 23.252.224.0/20 62502 >>UNKNOWN<< 23.252.224.0/21 62502 >>UNKNOWN<< 23.252.232.0/21 62502 >>UNKNOWN<< 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:32 /11:92 /12:264 /13:504 /14:996 /15:1718 /16:12968 /17:7125 /18:12114 /19:25000 /20:35654 /21:38441 /22:57531 /23:50240 /24:285716 /25:1166 /26:1095 /27:680 /28:17 /29:12 /30:7 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2197 2980 Cox Communications Inc. 18566 1997 2042 MegaPath Corporation 6389 1671 2891 BellSouth.net Inc. 30036 1388 1543 Mediacom Communications Corp 6983 1313 1622 EarthLink, Inc. 34984 1271 1968 TELLCOM ILETISIM HIZMETLERI A 6147 1257 1713 Telefonica del Peru S.A.A. 11492 1131 1189 CABLE ONE, INC. 10620 1074 3049 Telmex Colombia S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1477 2:665 3:1 4:97 5:1732 6:21 8:1407 12:1843 13:4 14:1258 15:17 16:2 17:40 20:48 23:1130 24:1677 27:1857 31:1472 32:39 33:2 34:5 35:2 36:121 37:1906 38:990 39:10 40:233 41:3023 42:262 43:1007 44:23 45:109 46:2104 47:34 49:787 50:791 52:12 54:66 55:4 56:8 57:32 58:1202 59:679 60:457 61:1762 62:1304 63:1905 64:4415 65:2255 66:4083 67:2017 68:1042 69:3276 70:939 71:432 72:1952 74:2611 75:314 76:409 77:1482 78:1281 79:786 80:1313 81:1318 82:814 83:678 84:674 85:1325 86:379 87:1071 88:516 89:1755 90:139 91:5892 92:802 93:2222 94:1941 95:2076 96:425 97:337 98:1053 99:47 100:69 101:788 103:6646 104:1192 105:62 106:204 107:883 108:608 109:2013 110:1074 111:1463 112:753 113:1021 114:839 115:1253 116:1322 117:1027 118:1695 119:1422 120:451 121:1039 122:2181 123:1711 124:1482 125:1551 128:635 129:373 130:375 131:1091 132:480 133:167 134:396 135:88 136:312 137:299 138:458 139:173 140:227 141:420 142:636 143:446 144:524 145:110 146:671 147:551 148:1086 149:417 150:559 151:590 152:486 153:248 154:312 155:721 156:399 157:332 158:265 159:976 160:368 161:630 162:1888 163:390 164:650 165:669 166:322 167:705 168:1004 169:141 170:1437 171:223 172:45 173:1588 174:686 175:620 176:1436 177:3694 178:2103 179:878 180:1908 181:1572 182:1705 183:601 184:741 185:2828 186:2688 187:1795 188:2016 189:1540 190:7743 191:865 192:8091 193:5562 194:4061 195:3627 196:1685 197:912 198:5459 199:5516 200:6529 201:2935 202:9543 203:9056 204:4660 205:2732 206:3004 207:2975 208:3951 209:3878 210:3493 211:1827 212:2431 213:2294 214:837 215:69 216:5541 217:1806 218:668 219:466 220:1441 221:798 222:464 223:656 End of report From surfer at mauigateway.com Fri Feb 6 19:25:41 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 6 Feb 2015 11:25:41 -0800 Subject: mpls over microwave Message-ID: <20150206112541.56F63404@m0048138.ppops.net> >-----Original Message-----> >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Weeks >Thanks everyone, > I feel a lot more confident on this project after > this discussion. I will be working with a comm > engineer who'll be doing the various radio links. > I just need to be sure he can make the best > decision as we're moving from ATM to MPLS and he > doesn't understand the networking part and I only > understand the basics of microwave links. --- SNaslund at medline.com wrote: From: "Naslund, Steve" I would try to recommend finding a microwave guy that knows IP. Quite a lot of them do now since most of their installs are IP traffic backhaul. ----------------------------------------------- There is no choice in this situation. I get what I get and make it work. And, it is hard to find technical folks *way* out in the country on a dot in the middle of the Pacific Ocean. :-) scott From faisal at snappytelecom.net Fri Feb 6 20:15:29 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 6 Feb 2015 20:15:29 +0000 (GMT) Subject: Provider to Blend with Level3 In-Reply-To: References: Message-ID: <257304164.1034049.1423253729805.JavaMail.zimbra@snappytelecom.net> We approach this in the following empirical manner. 1) Who is available to you easily and within the budget. 2) Where is the other side of the network connectivity consumers ? i.e. do you need good connectivity to Cable Network ? ATT Broadband ? Europe ? Mexico ? Latin America ? 3) What is the bulk of the traffic type ? Consumer (Video / You Tube ? Netflix ? ) Business ? etc based on the answers to above, I would look at the bgp.he.net to see each options upstream connectivity, and check with peeringdb to see what could be their peering relationships.... finding one that does not have a directly Level3 relationship would be preferred. Also, don't forget to do traffic engineering to nullify the Level3 traffic engineering, (They prefer to keep traffic on-net even if there are better paths available out of their network). Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Colton Conor" > To: "NANOG" > Sent: Friday, February 6, 2015 12:26:55 PM > Subject: Provider to Blend with Level3 > > We have a network that is single homed with Level3 at this time in Dallas. > They already have BGP and their own ASN and IP setup. Who would you > recommend for a second provider in Dallas to blend with Level3? Assuming > Level3 and this other provider would be the only two in the blend for a > long time to come? Client was talking to TWT, but now that they are being > bought by Level3 that doesn't make much sense. > From D.Lasher at f5.com Fri Feb 6 16:32:39 2015 From: D.Lasher at f5.com (Donn Lasher) Date: Fri, 6 Feb 2015 16:32:39 +0000 Subject: mpls over microwave In-Reply-To: <20150205151716.3838A7DD@m0048140.ppops.net> Message-ID: One more add: Properly engineered, fixed wireless links can have better-than-wireline availability. Two jobs ago, we had customer links with zero dropped packets in 5 years, which is outstanding compared to most copper-based services. Properly engineered, however, is the key. Make sure whom-ever is building your links looks at vendor specs, builds a real link budget (including losses from connectors, cable, grounding, etc) properly weather seals everything, and try to get at least a a 20db fade margin if you can. If the things I just mentioned are confusing to your RF guy, you might want to get outside help. On 2/5/15, 3:17 PM, "Scott Weeks" wrote: > >Had to run off to a meeting. Back now. This is >one thing I was worried about. I'm not doing the >radio part. Someone else is. I didn't know if >folks do pure Ethernet or if it's an IP hand off. > >If it's an IP addressed hand off, I have to come >out of MPLS, cross the link, then go back into >MPLS. > >Thanks for the pointers on packet size. I will >be sure to check into that. > >Scott From alex at alexwacker.com Fri Feb 6 17:35:14 2015 From: alex at alexwacker.com (Alex Wacker) Date: Fri, 6 Feb 2015 12:35:14 -0500 Subject: Provider to Blend with Level3 In-Reply-To: References: Message-ID: With how many people cogent connects with, it is almost never a bad idea to have them in your mix. On Fri, Feb 6, 2015 at 12:26 PM, Colton Conor wrote: > We have a network that is single homed with Level3 at this time in Dallas. > They already have BGP and their own ASN and IP setup. Who would you > recommend for a second provider in Dallas to blend with Level3? Assuming > Level3 and this other provider would be the only two in the blend for a > long time to come? Client was talking to TWT, but now that they are being > bought by Level3 that doesn't make much sense. From nanog at ics-il.net Fri Feb 6 20:47:47 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 6 Feb 2015 14:47:47 -0600 (CST) Subject: Provider to Blend with Level3 In-Reply-To: <257304164.1034049.1423253729805.JavaMail.zimbra@snappytelecom.net> Message-ID: <2635776.15902.1423255676510.JavaMail.mhammett@ThunderFuck> I don't know how accurate it is, but here's a site that more plainly spells out upstream\peer\customer: https://radar.qrator.net/ ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Faisal Imtiaz" To: "Colton Conor" Cc: "NANOG" Sent: Friday, February 6, 2015 2:15:29 PM Subject: Re: Provider to Blend with Level3 We approach this in the following empirical manner. 1) Who is available to you easily and within the budget. 2) Where is the other side of the network connectivity consumers ? i.e. do you need good connectivity to Cable Network ? ATT Broadband ? Europe ? Mexico ? Latin America ? 3) What is the bulk of the traffic type ? Consumer (Video / You Tube ? Netflix ? ) Business ? etc based on the answers to above, I would look at the bgp.he.net to see each options upstream connectivity, and check with peeringdb to see what could be their peering relationships.... finding one that does not have a directly Level3 relationship would be preferred. Also, don't forget to do traffic engineering to nullify the Level3 traffic engineering, (They prefer to keep traffic on-net even if there are better paths available out of their network). Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Colton Conor" > To: "NANOG" > Sent: Friday, February 6, 2015 12:26:55 PM > Subject: Provider to Blend with Level3 > > We have a network that is single homed with Level3 at this time in Dallas. > They already have BGP and their own ASN and IP setup. Who would you > recommend for a second provider in Dallas to blend with Level3? Assuming > Level3 and this other provider would be the only two in the blend for a > long time to come? Client was talking to TWT, but now that they are being > bought by Level3 that doesn't make much sense. > From cidr-report at potaroo.net Fri Feb 6 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Feb 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201502062200.t16M00jV096167@wattle.apnic.net> This report has been generated at Fri Feb 6 21:14:23 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 30-01-15 535593 295029 31-01-15 535725 294851 01-02-15 535758 295558 02-02-15 536071 295227 03-02-15 536401 293285 04-02-15 536630 293544 05-02-15 537306 294063 06-02-15 537226 294611 AS Summary 49580 Number of ASes in routing system 19856 Number of ASes announcing only one prefix 3090 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120442368 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 06Feb15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 537228 294453 242775 45.2% All ASes AS6389 2890 69 2821 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS22773 2982 172 2810 94.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2823 77 2746 97.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 18 2455 99.3% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2339 312 2027 86.7% NET Servi�os de Comunica��o S.A.,BR AS4755 1972 252 1720 87.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4766 2882 1320 1562 54.2% KIXS-AS-KR Korea Telecom,KR AS6147 1719 160 1559 90.7% Telefonica del Peru S.A.A.,PE AS7303 1771 284 1487 84.0% Telecom Argentina S.A.,AR AS9808 1526 55 1471 96.4% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS10620 3090 1636 1454 47.1% Telmex Colombia S.A.,CO AS20115 1854 520 1334 72.0% CHARTER-NET-HKY-NC - Charter Communications,US AS8402 1357 25 1332 98.2% CORBINA-AS OJSC "Vimpelcom",RU AS7545 2553 1256 1297 50.8% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1628 408 1220 74.9% TWTC - tw telecom holdings, inc.,US AS18566 2041 869 1172 57.4% MEGAPATH5-US - MegaPath Corporation,US AS9498 1289 182 1107 85.9% BBIL-AP BHARTI Airtel Ltd.,IN AS6849 1230 134 1096 89.1% UKRTELNET JSC UKRTELECOM,UA AS7552 1141 53 1088 95.4% VIETEL-AS-AP Viettel Corporation,VN AS34984 1968 893 1075 54.6% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS3356 2568 1501 1067 41.5% LEVEL3 - Level 3 Communications, Inc.,US AS22561 1332 300 1032 77.5% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7738 1000 84 916 91.6% Telemar Norte Leste S.A.,BR AS6983 1621 713 908 56.0% ITCDELTA - Earthlink, Inc.,US AS38285 983 113 870 88.5% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS18881 862 24 838 97.2% Global Village Telecom,BR AS4538 1776 957 819 46.1% ERX-CERNET-BKB China Education and Research Network Center,CN AS8151 1520 717 803 52.8% Uninet S.A. de C.V.,MX AS26615 920 137 783 85.1% Tim Celular S.A.,BR AS8551 1092 313 779 71.3% BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone,IL Total 55202 13554 41648 75.4% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.92.160.0/24 AS14013 EPSON-ROBOTS - EPSON America (Factory Automation/Robotics),US 23.92.161.0/24 AS14013 EPSON-ROBOTS - EPSON America (Factory Automation/Robotics),US 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, Inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS23937 103.20.101.0/24 AS23937 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.30.252.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.244.20.0/22 AS58754 103.244.20.0/24 AS58754 103.244.21.0/24 AS58754 103.244.22.0/24 AS58754 103.244.23.0/24 AS58754 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.252.200.0/24 AS56300 MYHOSTING-AS-AP MYHOSTING,SG 103.252.201.0/24 AS56300 MYHOSTING-AS-AP MYHOSTING,SG 103.252.202.0/24 AS56300 MYHOSTING-AS-AP MYHOSTING,SG 103.252.203.0/24 AS56300 MYHOSTING-AS-AP MYHOSTING,SG 103.253.100.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 185.87.56.0/22 AS8916 PORTFAST Portfast Ltd,GB 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.106.32.0/22 AS49873 -Reserved AS-,ZZ 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 197.149.188.0/22 AS37282 MAINONE,NG 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.204.144.0/21 AS36007 -Reserved AS-,ZZ 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.175.8.0/23 AS23858 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 6 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Feb 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201502062200.t16M01a0096180@wattle.apnic.net> BGP Update Report Interval: 29-Jan-15 -to- 05-Feb-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 272647 6.5% 2198.8 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 151291 3.6% 90.4 -- BSNL-NIB National Internet Backbone,IN 3 - AS3816 62061 1.5% 114.1 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 4 - AS53563 59929 1.4% 7491.1 -- XPLUSONE - X Plus One Solutions, Inc.,US 5 - AS8452 38477 0.9% 18.3 -- TE-AS TE-AS,EG 6 - AS51964 31841 0.8% 88.9 -- ORANGE-BUSINESS-SERVICES-IPSN-ASN Equant Inc.,FR 7 - AS9583 28712 0.7% 21.9 -- SIFY-AS-IN Sify Limited,IN 8 - AS48159 28597 0.7% 95.3 -- TIC-AS Telecommunication Infrastructure Company,IR 9 - AS60725 26037 0.6% 2002.8 -- O3B-AS O3b Limited,JE 10 - AS8402 23179 0.6% 133.2 -- CORBINA-AS OJSC "Vimpelcom",RU 11 - AS17974 22998 0.6% 8.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 12 - AS42337 22453 0.5% 136.9 -- RESPINA-AS Respina Networks & Beyond PJSC,IR 13 - AS23342 22314 0.5% 22314.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 14 - AS38197 21893 0.5% 26.2 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 15 - AS197914 20789 0.5% 20789.0 -- STOCKHO-AS Stockho Hosting SARL,FR 16 - AS27738 20735 0.5% 26.5 -- Ecuadortelecom S.A.,EC 17 - AS25563 19652 0.5% 4913.0 -- WEBLAND-AS Webland AG, Autonomous System,CH 18 - AS11054 19087 0.5% 795.3 -- LIVEPERSON - LivePerson, Inc.,US 19 - AS10620 19074 0.5% 7.4 -- Telmex Colombia S.A.,CO 20 - AS34170 18808 0.5% 186.2 -- AZTELEKOM Azerbaijan Telecomunication ISP,AZ TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23342 22314 0.5% 22314.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 2 - AS197914 20789 0.5% 20789.0 -- STOCKHO-AS Stockho Hosting SARL,FR 3 - AS61039 16246 0.4% 16246.0 -- ZMZ OAO ZMZ,RU 4 - AS53563 59929 1.4% 7491.1 -- XPLUSONE - X Plus One Solutions, Inc.,US 5 - AS25563 19652 0.5% 4913.0 -- WEBLAND-AS Webland AG, Autonomous System,CH 6 - AS33721 4881 0.1% 4881.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 7 - AS198005 7258 0.2% 3629.0 -- UNI-AS UNI BAHRAIN TELECOM Bsc closed,SA 8 - AS6775 18764 0.5% 3127.3 -- BACKBONE_EHF_EUROPE Backbone ehf,CH 9 - AS47680 14546 0.3% 2909.2 -- NHCS EOBO Limited,IE 10 - AS201224 2247 0.1% 2247.0 -- MYOWNAS PE Evgeny Tikhomirov,RU 11 - AS45606 11225 0.3% 2245.0 -- 12 - AS23752 272647 6.5% 2198.8 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 13 - AS132242 2162 0.1% 2162.0 -- HOGARTHWW-SG Hogarth Worldwide Pte,SG 14 - AS60725 26037 0.6% 2002.8 -- O3B-AS O3b Limited,JE 15 - AS62174 1993 0.1% 1993.0 -- INTERPAN-AS INTERPAN LTD.,BG 16 - AS20151 1907 0.1% 1907.0 -- MCW-12-01 - Mountain Computer Wizards, Inc.,US 17 - AS198053 1872 0.0% 1872.0 -- AMTEL VECTRA S.A.,PL 18 - AS197957 1708 0.0% 1708.0 -- KERBB Ker Broadband Communications Ltd,IE 19 - AS6629 10520 0.2% 1502.9 -- NOAA-AS - NOAA,US 20 - AS33440 12005 0.3% 1500.6 -- WEBRULON-NETWORK - webRulon, LLC,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.64.0/21 138229 3.2% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.88.0/21 133081 3.0% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 199.38.164.0/23 59920 1.4% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 4 - 64.29.130.0/24 22314 0.5% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 5 - 130.0.192.0/21 20789 0.5% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 6 - 79.134.225.0/24 18755 0.4% AS6775 -- BACKBONE_EHF_EUROPE Backbone ehf,CH 7 - 91.235.169.0/24 16246 0.4% AS61039 -- ZMZ OAO ZMZ,RU 8 - 91.193.202.0/24 15846 0.4% AS42081 -- SPEEDY-NET-AS Speedy net EAD,BG 9 - 88.87.160.0/19 14530 0.3% AS47680 -- NHCS EOBO Limited,IE 10 - 162.249.183.0/24 13395 0.3% AS60725 -- O3B-AS O3b Limited,JE 11 - 185.26.155.0/24 12607 0.3% AS60725 -- O3B-AS O3b Limited,JE 12 - 192.58.232.0/24 10514 0.2% AS6629 -- NOAA-AS - NOAA,US 13 - 42.83.48.0/20 9839 0.2% AS18135 -- BTV BTV Cable television,JP 14 - 196.43.144.0/23 9371 0.2% AS327687 -- RENU,UG 15 - 199.191.120.0/22 7998 0.2% AS15177 -- STARTOUCH-WA1 - STARTOUCH INC,US AS46392 -- GCPOWERNET - Grant County Powernet, Inc.,US 16 - 162.249.210.0/24 7724 0.2% AS27435 -- OPSOURCE-INC - Dimension Data Cloud Solutions, Inc.,US 17 - 178.174.96.0/19 6820 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 18 - 92.43.216.0/21 6477 0.1% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 19 - 185.84.192.0/22 6350 0.1% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 20 - 153.126.42.0/24 5518 0.1% AS10013 -- FBDC FreeBit Co.,Ltd.,JP 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 timoid at timoid.org Fri Feb 6 23:18:34 2015 From: timoid at timoid.org (Tim Warnock) Date: Fri, 6 Feb 2015 23:18:34 +0000 Subject: mpls over microwave In-Reply-To: <20150206112541.56F63404@m0048138.ppops.net> References: <20150206112541.56F63404@m0048138.ppops.net> Message-ID: > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott > Weeks > Sent: Saturday, 7 February 2015 5:26 AM > To: nanog at nanog.org > Subject: RE: mpls over microwave > > > There is no choice in this situation. I get what > I get and make it work. And, it is hard to find > technical folks *way* out in the country on a dot > in the middle of the Pacific Ocean. :-) > > scott Hi Scott, Just a few tips from someone who did some of the RF engineering and ran a mpls network in a previous job :- Watch your MTUs. Also, watch out for flow control - talk to your radio vendor to see if you will need it enabled. Good luck :) -Tim From ccosta92630 at gmail.com Sat Feb 7 00:05:28 2015 From: ccosta92630 at gmail.com (Chris Costa) Date: Fri, 6 Feb 2015 16:05:28 -0800 Subject: Looking for a Consolidated Communications (AS5742) contact Message-ID: Hoping to speak with a Consolidated Communications (AS5742) engineer regarding routing in Illinois region towards Gaikai (AS33353). Thanks, Chris Costa From nanog at ics-il.net Sat Feb 7 02:06:21 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 6 Feb 2015 20:06:21 -0600 (CST) Subject: Looking for a Consolidated Communications (AS5742) contact In-Reply-To: Message-ID: <21405872.16408.1423274757068.JavaMail.mhammett@ThunderFuck> This is the third or fourth request I've seen lately. I'm assuming they don't have anyone on here. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Chris Costa" To: nanog at nanog.org Sent: Friday, February 6, 2015 6:05:28 PM Subject: Looking for a Consolidated Communications (AS5742) contact Hoping to speak with a Consolidated Communications (AS5742) engineer regarding routing in Illinois region towards Gaikai (AS33353). Thanks, Chris Costa From jra at baylink.com Sat Feb 7 02:10:58 2015 From: jra at baylink.com (Jay Ashworth) Date: Fri, 6 Feb 2015 21:10:58 -0500 (EST) Subject: Looking for a Consolidated Communications (AS5742) contact In-Reply-To: <21405872.16408.1423274757068.JavaMail.mhammett@ThunderFuck> Message-ID: <3000335.1743.1423275057960.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mike Hammett" > This is the third or fourth request I've seen lately. I'm assuming > they don't have anyone on here. Not necessarily. Some people reply privately, so as not to come out of the closet. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From nanog at ics-il.net Sat Feb 7 02:16:46 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 6 Feb 2015 20:16:46 -0600 (CST) Subject: Looking for a Consolidated Communications (AS5742) contact In-Reply-To: <3000335.1743.1423275057960.JavaMail.root@benjamin.baylink.com> Message-ID: <12855346.16445.1423275382556.JavaMail.mhammett@ThunderFuck> Yeah, but it's the same guy looking for the same people for the same issue. I know it sucks to have things not working right, but they're probably not here. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Jay Ashworth" To: "NANOG" Sent: Friday, February 6, 2015 8:10:58 PM Subject: Re: Looking for a Consolidated Communications (AS5742) contact ----- Original Message ----- > From: "Mike Hammett" > This is the third or fourth request I've seen lately. I'm assuming > they don't have anyone on here. Not necessarily. Some people reply privately, so as not to come out of the closet. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From ccosta92630 at gmail.com Sat Feb 7 03:06:49 2015 From: ccosta92630 at gmail.com (Chris Costa) Date: Fri, 6 Feb 2015 19:06:49 -0800 Subject: Looking for a Consolidated Communications (AS5742) contact In-Reply-To: <12855346.16445.1423275382556.JavaMail.mhammett@ThunderFuck> References: <3000335.1743.1423275057960.JavaMail.root@benjamin.baylink.com> <12855346.16445.1423275382556.JavaMail.mhammett@ThunderFuck> Message-ID: Oops, sorry. Didn't think those other requests got through the moderator. :) On Feb 6, 2015 6:18 PM, "Mike Hammett" wrote: > Yeah, but it's the same guy looking for the same people for the same > issue. I know it sucks to have things not working right, but they're > probably not here. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Jay Ashworth" > To: "NANOG" > Sent: Friday, February 6, 2015 8:10:58 PM > Subject: Re: Looking for a Consolidated Communications (AS5742) contact > > ----- Original Message ----- > > From: "Mike Hammett" > > > This is the third or fourth request I've seen lately. I'm assuming > > they don't have anyone on here. > > Not necessarily. > > Some people reply privately, so as not to come out of the closet. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 > > From mark.tinka at seacom.mu Sat Feb 7 08:17:07 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 07 Feb 2015 10:17:07 +0200 Subject: Input Regarding Cogent and NTT In-Reply-To: References: <19213156.13034.1423165265508.JavaMail.mhammett@ThunderFuck> Message-ID: <54D5CA03.2050902@seacom.mu> On 5/Feb/15 22:05, Bryan Tong wrote: > We've been on Cogent for 3 years now. > > I have to say the experience has been nice. Good sales, great NOC. We even > had a dirty fiber issue with their uplink (due to the MMA owner) and Cogent > stayed on the phone with me for hours and got it handled before we hung up > the phone. So great NOC too. We pick up Cogent as one of our upstreams, primarily for who they have on-net that others do not (or can be accessed "shorter" through). We haven't had any major issues. The sales folk were persistent, but the turn-up was good as has been contact with the NOC (primarily to get BGP prefixes updated regularly). We use NTT too, and a bunch of others, and the experience has generally been the same, i.e., nothing major to complain about. Then again, close to 70% of our non-African traffic is peered away at the 4x major exchange points in Europe, and the upstreams only cover the rest. So there could be some co-relation there. Mark. From mark.tinka at seacom.mu Sat Feb 7 08:18:50 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 07 Feb 2015 10:18:50 +0200 Subject: Metaswitch ax1000 as a RR In-Reply-To: References: Message-ID: <54D5CA6A.9040008@seacom.mu> On 5/Feb/15 22:41, David Bass wrote: > I have a client looking to implement x86 based route reflectors, and was looking at the ax1000. I'm wondering if anyone has implemented it yet, and what your experience has been? > > Any other alternatives would also be appreciated. This customer does standard L3 VPNs, and VPLS services so the software has to support that. I have spoken about our success in using Cisco's CSR1000v on ESXi on x86_64 hardware previously on this list. Yes, the licenses will cost you (both VMware and CSR1000v). KVM is supported, but I haven't tried it. Suffice it to say, Cisco seem to be putting most of their energy into ESXi. Mark. From mark.tinka at seacom.mu Sat Feb 7 08:20:37 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 07 Feb 2015 10:20:37 +0200 Subject: mpls over microwave In-Reply-To: References: <20150205135504.39F63F7A@m0048136.ppops.net> Message-ID: <54D5CAD5.4000909@seacom.mu> On 6/Feb/15 00:31, Eric Louie wrote: > I work for a fixed wireless provider, and our mpls-capable backhauls are > all running mpls with 9200 MTU with no problem. The only weirdness I > encounter is if I have multiple equal-cost routes to the same location, one > over MPLS and one not, end up having ping/unreachable issues from my > monitoring equipment. The solution has been to cost one path (the MPLS) > lower than the other. The only other problem I had was with radio's that > didn't support larger 9000+ byte MTU packets - we've phased that radio out > for now. if you run MPLS with 1500 byte MTU, you'll have issues with 1500 > byte packets with the DF-bit set. That was a nasty discovery in the > production network, your mileage will not vary with that problem. I'm curious why you'd have multiple paths in your network (equal-cost to boot) where some support and others don't. Mark. From nick at fluency.net.uk Sat Feb 7 13:28:57 2015 From: nick at fluency.net.uk (Nick Ryce) Date: Sat, 7 Feb 2015 13:28:57 +0000 Subject: Metaswitch ax1000 as a RR In-Reply-To: <54D5CA6A.9040008@seacom.mu> References: <54D5CA6A.9040008@seacom.mu> Message-ID: We have the CSR1000v on KVM with the premium 10mbps license as a RR it is works perfectly. We did have to play about with the nic drivers and found that the e1000 seems to be the most stable. N Nick Ryce Network Architect, Fluency Communications Ltd T: +44 (0)845 874 7000 www.fluency.net.uk nick at fluency.net.uk On 07/02/2015 08:18, "Mark Tinka" wrote: > >On 5/Feb/15 22:41, David Bass wrote: >> I have a client looking to implement x86 based route reflectors, and >>was looking at the ax1000. I'm wondering if anyone has implemented it >>yet, and what your experience has been? >> >> Any other alternatives would also be appreciated. This customer does >>standard L3 VPNs, and VPLS services so the software has to support that. >> > >I have spoken about our success in using Cisco's CSR1000v on ESXi on >x86_64 hardware previously on this list. > >Yes, the licenses will cost you (both VMware and CSR1000v). KVM is >supported, but I haven't tried it. Suffice it to say, Cisco seem to be >putting most of their energy into ESXi. > >Mark. > From mark.tinka at seacom.mu Sat Feb 7 15:33:05 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 07 Feb 2015 17:33:05 +0200 Subject: Metaswitch ax1000 as a RR In-Reply-To: References: <54D5CA6A.9040008@seacom.mu> Message-ID: <54D63031.6080504@seacom.mu> On 7/Feb/15 15:28, Nick Ryce wrote: > We have the CSR1000v on KVM with the premium 10mbps license as a RR it is > works perfectly. We did have to play about with the nic drivers and found > that the e1000 seems to be the most stable. That's great to hear. We deployed on VMware ESXi with a Premium license for 8GB RAM (which gives you 500Mbps, not that you need it). The installation wasn't problematic, just don't live by Cisco's instructions re: the VM - not very useful :-). Mark. From nanog at ics-il.net Sat Feb 7 17:41:40 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 7 Feb 2015 11:41:40 -0600 (CST) Subject: Low cost WDM gear In-Reply-To: <23216412.825.1423330808325.JavaMail.mhammett@ThunderFuck> Message-ID: <740018.831.1423330891727.JavaMail.mhammett@ThunderFuck> I know there are various Asian vendors for low cost (less than $500) muxes to throw 16 or however many colors onto a strand. However, they don't work so well when you don't control the optics used on both sides (therefore must use standard wavelengths), obviously only do a handful of channels and have a distance limitation. What solutions are out there that don't cost an arm and a leg? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From mmg at transtelco.net Sat Feb 7 17:49:29 2015 From: mmg at transtelco.net (=?UTF-8?Q?Manuel_Mar=C3=ADn?=) Date: Sat, 7 Feb 2015 10:49:29 -0700 Subject: Low cost WDM gear In-Reply-To: <740018.831.1423330891727.JavaMail.mhammett@ThunderFuck> References: <23216412.825.1423330808325.JavaMail.mhammett@ThunderFuck> <740018.831.1423330891727.JavaMail.mhammett@ThunderFuck> Message-ID: Hi Mike I can recommend a couple of vendors that provide cost effective solutions. Ekinops & Packetlight. On Saturday, February 7, 2015, Mike Hammett wrote: > I know there are various Asian vendors for low cost (less than $500) muxes > to throw 16 or however many colors onto a strand. However, they don't work > so well when you don't control the optics used on both sides (therefore > must use standard wavelengths), obviously only do a handful of channels and > have a distance limitation. > > What solutions are out there that don't cost an arm and a leg? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > -- TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: *+52 656-257-1109* CONFIDENTIALITY NOTICE: This communication is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient of this information, you are notified that any use, dissemination, distribution, or copying of the communication is strictly prohibited. AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la persona o entidad a la que se dirige y puede contener información privilegiada, confidencial y exenta de divulgación bajo la legislación aplicable. Si no es el destinatario de esta información, se le notifica que cualquier uso, difusión, distribución o copia de la comunicación está estrictamente prohibido. From nanog at ics-il.net Sat Feb 7 17:52:19 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 7 Feb 2015 11:52:19 -0600 (CST) Subject: Low cost WDM gear In-Reply-To: <740018.831.1423330891727.JavaMail.mhammett@ThunderFuck> Message-ID: <31789515.861.1423331533265.JavaMail.mhammett@ThunderFuck> For clarification, I do know that the mainstream vendors can take standard wavelengths and can do long distances, but that's where the arms and legs come in. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mike Hammett" To: "NANOG" Sent: Saturday, February 7, 2015 11:41:40 AM Subject: Low cost WDM gear I know there are various Asian vendors for low cost (less than $500) muxes to throw 16 or however many colors onto a strand. However, they don't work so well when you don't control the optics used on both sides (therefore must use standard wavelengths), obviously only do a handful of channels and have a distance limitation. What solutions are out there that don't cost an arm and a leg? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From kenneth.mcrae at me.com Sat Feb 7 17:55:57 2015 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Sat, 07 Feb 2015 17:55:57 +0000 (GMT) Subject: Low cost WDM gear Message-ID: Mike, I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware equipment.  The FiberStore gear was a huge disappointment (excessive loss, poor technical support, refusal to issue refund without threatening legal action, etc.).   I have had good results from the OSI equipment so far.  I run passive muxes for CWDM (8 - 16 channels). On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: Hi Mike I can recommend a couple of vendors that provide cost effective solutions. Ekinops & Packetlight. On Saturday, February 7, 2015, Mike Hammett wrote: I know there are various Asian vendors for low cost (less than $500) muxes to throw 16 or however many colors onto a strand. However, they don't work so well when you don't control the optics used on both sides (therefore must use standard wavelengths), obviously only do a handful of channels and have a distance limitation. What solutions are out there that don't cost an arm and a leg? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com -- TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: *+52 656-257-1109* CONFIDENTIALITY NOTICE: This communication is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient of this information, you are notified that any use, dissemination, distribution, or copying of the communication is strictly prohibited. AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la persona o entidad a la que se dirige y puede contener información privilegiada, confidencial y exenta de divulgación bajo la legislación aplicable. Si no es el destinatario de esta información, se le notifica que cualquier uso, difusión, distribución o copia de la comunicación está estrictamente prohibido. From morrowc.lists at gmail.com Sat Feb 7 18:02:11 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 7 Feb 2015 13:02:11 -0500 Subject: Low cost WDM gear In-Reply-To: References: Message-ID: would be good for mike to define 'long distances' here, is it: 2km 30km 300km 3000km Probably the 30-60k range is what you mean by 'long distances' but... clarity might help. On Sat, Feb 7, 2015 at 12:55 PM, Kenneth McRae wrote: > Mike, > > I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware > equipment. The FiberStore gear was a huge disappointment (excessive loss, > poor technical support, refusal to issue refund without threatening legal > action, etc.). I have had good results from the OSI equipment so far. I > run passive muxes for CWDM (8 - 16 channels). > > On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: > > Hi Mike > > I can recommend a couple of vendors that provide cost effective solutions. > Ekinops & Packetlight. > > On Saturday, February 7, 2015, Mike Hammett wrote: > > I know there are various Asian vendors for low cost (less than $500) muxes > to throw 16 or however many colors onto a strand. However, they don't work > so well when you don't control the optics used on both sides (therefore > must use standard wavelengths), obviously only do a handful of channels and > have a distance limitation. > What solutions are out there that don't cost an arm and a leg? > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > -- > TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: *+52 > 656-257-1109* > > CONFIDENTIALITY NOTICE: This communication is intended only for the use > of the individual or entity to which it is addressed and may contain > information that is privileged, confidential, and exempt from disclosure > under applicable law. If you are not the intended recipient of this > information, you are notified that any use, dissemination, distribution, or > copying of the communication is strictly prohibited. > > AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la > persona o entidad a la que se dirige y puede contener información > privilegiada, confidencial y exenta de divulgación bajo la legislación > aplicable. Si no es el destinatario de esta información, se le notifica que > cualquier uso, difusión, distribución o copia de la comunicación está > estrictamente prohibido. From nanog at ics-il.net Sat Feb 7 18:04:46 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 7 Feb 2015 12:04:46 -0600 (CST) Subject: Low cost WDM gear In-Reply-To: Message-ID: <5739795.895.1423332278146.JavaMail.mhammett@ThunderFuck> One particular route I'm looking at is 185 miles, so of the options presented 300 km is closest. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Christopher Morrow" To: "Kenneth McRae" Cc: "NANOG" Sent: Saturday, February 7, 2015 12:02:11 PM Subject: Re: Low cost WDM gear would be good for mike to define 'long distances' here, is it: 2km 30km 300km 3000km Probably the 30-60k range is what you mean by 'long distances' but... clarity might help. On Sat, Feb 7, 2015 at 12:55 PM, Kenneth McRae wrote: > Mike, > > I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware > equipment. The FiberStore gear was a huge disappointment (excessive loss, > poor technical support, refusal to issue refund without threatening legal > action, etc.). I have had good results from the OSI equipment so far. I > run passive muxes for CWDM (8 - 16 channels). > > On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: > > Hi Mike > > I can recommend a couple of vendors that provide cost effective solutions. > Ekinops & Packetlight. > > On Saturday, February 7, 2015, Mike Hammett wrote: > > I know there are various Asian vendors for low cost (less than $500) muxes > to throw 16 or however many colors onto a strand. However, they don't work > so well when you don't control the optics used on both sides (therefore > must use standard wavelengths), obviously only do a handful of channels and > have a distance limitation. > What solutions are out there that don't cost an arm and a leg? > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > -- > TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: *+52 > 656-257-1109* > > CONFIDENTIALITY NOTICE: This communication is intended only for the use > of the individual or entity to which it is addressed and may contain > information that is privileged, confidential, and exempt from disclosure > under applicable law. If you are not the intended recipient of this > information, you are notified that any use, dissemination, distribution, or > copying of the communication is strictly prohibited. > > AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la > persona o entidad a la que se dirige y puede contener información > privilegiada, confidencial y exenta de divulgación bajo la legislación > aplicable. Si no es el destinatario de esta información, se le notifica que > cualquier uso, difusión, distribución o copia de la comunicación está > estrictamente prohibido. From kenneth.mcrae at me.com Sat Feb 7 18:17:35 2015 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Sat, 07 Feb 2015 18:17:35 +0000 (GMT) Subject: Low cost WDM gear Message-ID: Are you looking for an active or passive solution? On Feb 07, 2015, at 10:06 AM, Mike Hammett wrote: One particular route I'm looking at is 185 miles, so of the options presented 300 km is closest. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Christopher Morrow" To: "Kenneth McRae" Cc: "NANOG" Sent: Saturday, February 7, 2015 12:02:11 PM Subject: Re: Low cost WDM gear would be good for mike to define 'long distances' here, is it: 2km 30km 300km 3000km Probably the 30-60k range is what you mean by 'long distances' but... clarity might help. On Sat, Feb 7, 2015 at 12:55 PM, Kenneth McRae wrote: Mike, I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware equipment. The FiberStore gear was a huge disappointment (excessive loss, poor technical support, refusal to issue refund without threatening legal action, etc.). I have had good results from the OSI equipment so far. I run passive muxes for CWDM (8 - 16 channels). On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: Hi Mike I can recommend a couple of vendors that provide cost effective solutions. Ekinops & Packetlight. On Saturday, February 7, 2015, Mike Hammett wrote: I know there are various Asian vendors for low cost (less than $500) muxes to throw 16 or however many colors onto a strand. However, they don't work so well when you don't control the optics used on both sides (therefore must use standard wavelengths), obviously only do a handful of channels and have a distance limitation. What solutions are out there that don't cost an arm and a leg? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com -- TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: *+52 656-257-1109* CONFIDENTIALITY NOTICE: This communication is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient of this information, you are notified that any use, dissemination, distribution, or copying of the communication is strictly prohibited. AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la persona o entidad a la que se dirige y puede contener información privilegiada, confidencial y exenta de divulgación bajo la legislación aplicable. Si no es el destinatario de esta información, se le notifica que cualquier uso, difusión, distribución o copia de la comunicación está estrictamente prohibido. From nanog at ics-il.net Sat Feb 7 18:31:28 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 7 Feb 2015 12:31:28 -0600 (CST) Subject: Low cost WDM gear In-Reply-To: Message-ID: <19313017.971.1423333877909.JavaMail.mhammett@ThunderFuck> Well, I'm not an expert in the world of long haul optics, but I think I'd want active over passive for the ability to use standard interfaces on the equipment (routers, switches, etc.) at either end. Then again, maybe something has changed that I don't know about. I would also think active would be better able to go those 185 mile distances than passive. I assume I'd need an amplifier in the middle to even make it that far. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Kenneth McRae" To: "Mike Hammett" Cc: "NANOG" Sent: Saturday, February 7, 2015 12:17:35 PM Subject: Re: Low cost WDM gear Are you looking for an active or passive solution? On Feb 07, 2015, at 10:06 AM, Mike Hammett wrote: One particular route I'm looking at is 185 miles, so of the options presented 300 km is closest. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Christopher Morrow" < morrowc.lists at gmail.com > To: "Kenneth McRae" < kenneth.mcrae at me.com > Cc: "NANOG" < nanog at nanog.org > Sent: Saturday, February 7, 2015 12:02:11 PM Subject: Re: Low cost WDM gear would be good for mike to define 'long distances' here, is it: 2km 30km 300km 3000km Probably the 30-60k range is what you mean by 'long distances' but... clarity might help. On Sat, Feb 7, 2015 at 12:55 PM, Kenneth McRae < kenneth.mcrae at me.com > wrote:
Mike,
I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware
equipment. The FiberStore gear was a huge disappointment (excessive loss,
poor technical support, refusal to issue refund without threatening legal
action, etc.). I have had good results from the OSI equipment so far. I
run passive muxes for CWDM (8 - 16 channels).
On Feb 07, 2015, at 09:51 AM, Manuel Marín < mmg at transtelco.net > wrote:
Hi Mike
I can recommend a couple of vendors that provide cost effective solutions.
Ekinops & Packetlight.
On Saturday, February 7, 2015, Mike Hammett < nanog at ics-il.net > wrote:
I know there are various Asian vendors for low cost (less than $500) muxes
to throw 16 or however many colors onto a strand. However, they don't work
so well when you don't control the optics used on both sides (therefore
must use standard wavelengths), obviously only do a handful of channels and
have a distance limitation.
What solutions are out there that don't cost an arm and a leg?
-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
--
TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: *+52
656-257-1109*
CONFIDENTIALITY NOTICE: This communication is intended only for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, confidential, and exempt from disclosure
under applicable law. If you are not the intended recipient of this
information, you are notified that any use, dissemination, distribution, or
copying of the communication is strictly prohibited.
AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la
persona o entidad a la que se dirige y puede contener información
privilegiada, confidencial y exenta de divulgación bajo la legislación
aplicable. Si no es el destinatario de esta información, se le notifica que
cualquier uso, difusión, distribución o copia de la comunicación está
estrictamente prohibido.
From rodrigo at 1telecom.com.br Sat Feb 7 18:34:47 2015 From: rodrigo at 1telecom.com.br (Rodrigo 1telecom) Date: Sat, 7 Feb 2015 15:34:47 -0300 Subject: Low cost WDM gear In-Reply-To: References: Message-ID: <30B336F2-7610-408A-8DE1-020B24DB87E9@1telecom.com.br> Hi kenneth... which the distance do you have from side A to side B when you using passive solutions from fiberstore( mux and demux)? I buy this mux and demux(4 channels single fiber) and only make a test about 60km( mux side A and demux on side B) with sfp+10gb for 80km... ( only see ddm on my ex3300( about -19db for 60km). Test switch access with ssh and pinging tests... What kind os issue do you have? For distances less than 60km is this solution good? Thanks!!! Enviado via iPhone  Grupo Connectoway > Em 07/02/2015, às 14:55, Kenneth McRae escreveu: > > Mike, > > I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware equipment. The FiberStore gear was a huge disappointment (excessive loss, poor technical support, refusal to issue refund without threatening legal action, etc.). I have had good results from the OSI equipment so far. I run passive muxes for CWDM (8 - 16 channels). > > On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: > > Hi Mike > > I can recommend a couple of vendors that provide cost effective solutions. > Ekinops & Packetlight. > > On Saturday, February 7, 2015, Mike Hammett wrote: > > I know there are various Asian vendors for low cost (less than $500) muxes > to throw 16 or however many colors onto a strand. However, they don't work > so well when you don't control the optics used on both sides (therefore > must use standard wavelengths), obviously only do a handful of channels and > have a distance limitation. > What solutions are out there that don't cost an arm and a leg? > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > -- > TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: *+52 > 656-257-1109* > > CONFIDENTIALITY NOTICE: This communication is intended only for the use > of the individual or entity to which it is addressed and may contain > information that is privileged, confidential, and exempt from disclosure > under applicable law. If you are not the intended recipient of this > information, you are notified that any use, dissemination, distribution, or > copying of the communication is strictly prohibited. > > AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la > persona o entidad a la que se dirige y puede contener información > privilegiada, confidencial y exenta de divulgación bajo la legislación > aplicable. Si no es el destinatario de esta información, se le notifica que > cualquier uso, difusión, distribución o copia de la comunicación está > estrictamente prohibido. From kenneth.mcrae at me.com Sat Feb 7 19:04:10 2015 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Sat, 07 Feb 2015 19:04:10 +0000 (GMT) Subject: Low cost WDM gear Message-ID: <68212b43-4395-4567-929c-29cb6fad21d1@me.com> Hi Enviado, I cannot recommend FiberStore as I had a bad experience with them.  I needed to cover only 3km from A to B side.  When using 10km optics, I saw a loss of over 5db  with their passive mux inserted into the path which created a total loss of over -20db which is outside of the tolerances for our equipment with 10km SFP+.  Using another vendors low insertion loss mux corrected our issue.  I am sure if you are using an 80km optic, you may be able to tolerate a higher insertion loss to cover < 60km.  I also notice that their CDWM optics averaged about 3db less in power output when compared to other vendors. Thanks Kenneth On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom wrote: Hi kenneth... which the distance do you have from side A to side B when you using passive solutions from fiberstore( mux and demux)? I buy this mux and demux(4 channels single fiber) and only make a test about 60km( mux side A and demux on side B) with sfp+10gb for 80km... ( only see ddm on my ex3300( about -19db for 60km). Test switch access with ssh and pinging tests... What kind os issue do you have? For distances less than 60km is this solution good? Thanks!!! Enviado via iPhone  Grupo Connectoway Em 07/02/2015, às 14:55, Kenneth McRae escreveu: Mike, I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware equipment. The FiberStore gear was a huge disappointment (excessive loss, poor technical support, refusal to issue refund without threatening legal action, etc.). I have had good results from the OSI equipment so far. I run passive muxes for CWDM (8 - 16 channels). On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: Hi Mike I can recommend a couple of vendors that provide cost effective solutions. Ekinops & Packetlight. On Saturday, February 7, 2015, Mike Hammett wrote: I know there are various Asian vendors for low cost (less than $500) muxes to throw 16 or however many colors onto a strand. However, they don't work so well when you don't control the optics used on both sides (therefore must use standard wavelengths), obviously only do a handful of channels and have a distance limitation. What solutions are out there that don't cost an arm and a leg? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com -- TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: *+52 656-257-1109* CONFIDENTIALITY NOTICE: This communication is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient of this information, you are notified that any use, dissemination, distribution, or copying of the communication is strictly prohibited. AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la persona o entidad a la que se dirige y puede contener información privilegiada, confidencial y exenta de divulgación bajo la legislación aplicable. Si no es el destinatario de esta información, se le notifica que cualquier uso, difusión, distribución o copia de la comunicación está estrictamente prohibido. From kenneth.mcrae at me.com Sat Feb 7 19:12:01 2015 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Sat, 07 Feb 2015 19:12:01 +0000 (GMT) Subject: Low cost WDM gear Message-ID: <55f63173-8c22-4b2b-8b2c-1b09ee265085@me.com> Yeah, you can get up to 80km on a passive unit using SFP+ and up to 120km using XFP.  To cover the distance you are considering, you would need to insert an amplifier.  Depending on the number of channels you require, a passive solution with an amplified would still be less expensive than an active solution.  When I was conducting my research, I could not find an active solution under $25K. On Feb 07, 2015, at 10:32 AM, Mike Hammett wrote: Well, I'm not an expert in the world of long haul optics, but I think I'd want active over passive for the ability to use standard interfaces on the equipment (routers, switches, etc.) at either end. Then again, maybe something has changed that I don't know about. I would also think active would be better able to go those 185 mile distances than passive. I assume I'd need an amplifier in the middle to even make it that far. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Kenneth McRae" To: "Mike Hammett" Cc: "NANOG" Sent: Saturday, February 7, 2015 12:17:35 PM Subject: Re: Low cost WDM gear Are you looking for an active or passive solution? On Feb 07, 2015, at 10:06 AM, Mike Hammett wrote: One particular route I'm looking at is 185 miles, so of the options presented 300 km is closest. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Christopher Morrow" < morrowc.lists at gmail.com > To: "Kenneth McRae" < kenneth.mcrae at me.com > Cc: "NANOG" < nanog at nanog.org > Sent: Saturday, February 7, 2015 12:02:11 PM Subject: Re: Low cost WDM gear would be good for mike to define 'long distances' here, is it: 2km 30km 300km 3000km Probably the 30-60k range is what you mean by 'long distances' but... clarity might help. On Sat, Feb 7, 2015 at 12:55 PM, Kenneth McRae < kenneth.mcrae at me.com > wrote:
Mike,
I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware
equipment. The FiberStore gear was a huge disappointment (excessive loss,
poor technical support, refusal to issue refund without threatening legal
action, etc.). I have had good results from the OSI equipment so far. I
run passive muxes for CWDM (8 - 16 channels).
On Feb 07, 2015, at 09:51 AM, Manuel Marín < mmg at transtelco.net > wrote:
Hi Mike
I can recommend a couple of vendors that provide cost effective solutions.
Ekinops & Packetlight.
On Saturday, February 7, 2015, Mike Hammett < nanog at ics-il.net > wrote:
I know there are various Asian vendors for low cost (less than $500) muxes
to throw 16 or however many colors onto a strand. However, they don't work
so well when you don't control the optics used on both sides (therefore
must use standard wavelengths), obviously only do a handful of channels and
have a distance limitation.
What solutions are out there that don't cost an arm and a leg?
-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
--
TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: *+52
656-257-1109*
CONFIDENTIALITY NOTICE: This communication is intended only for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, confidential, and exempt from disclosure
under applicable law. If you are not the intended recipient of this
information, you are notified that any use, dissemination, distribution, or
copying of the communication is strictly prohibited.
AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la
persona o entidad a la que se dirige y puede contener información
privilegiada, confidencial y exenta de divulgación bajo la legislación
aplicable. Si no es el destinatario de esta información, se le notifica que
cualquier uso, difusión, distribución o copia de la comunicación está
estrictamente prohibido.
From nanog08 at mulligan.org Sat Feb 7 19:16:56 2015 From: nanog08 at mulligan.org (Geoff Mulligan) Date: Sat, 07 Feb 2015 12:16:56 -0700 Subject: AOL email support Message-ID: <54D664A8.1010407@mulligan.org> Could anyone from AOL contact me regarding email issues. Geoff Mulligan Presidential Innovation Fellow Alumni - The White House From bedard.phil at gmail.com Sat Feb 7 19:17:48 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Sat, 07 Feb 2015 14:17:48 -0500 Subject: Low cost WDM gear In-Reply-To: <5739795.895.1423332278146.JavaMail.mhammett@ThunderFuck> References: <5739795.895.1423332278146.JavaMail.mhammett@ThunderFuck> Message-ID: <1B3F9E60-9B88-4D63-BED6-975E1180E78F@gmail.com> Is this for 10G? I'm kind of assuming 10G. What kind of equipment is being plugged into these? 300km is way beyond what you'll get with a passive solution, it's definitely in the "long-haul" terrtory. If you are launching out of a router the best pluggable optic you can generally get is rated at 80km, 10GBase-ZR, but even a passive mux at each end shaves some of that distance off. 300km is going to require amplifiers at intervals across the span. Who is providing the fiber? I'd start talking to traditional transport vendors. Ekinops as mentioned is probably decent at a lower price, Adva works well and isn't all that expensive, even Cisco has gear reasonably priced. If you want to cover 300km on a fiber span though "cheap" isn't really a word I would describe. It's why people lease circuits. :) Phil On 2/7/15, 18:04, "Mike Hammett" wrote: >One particular route I'm looking at is 185 miles, so of the options >presented 300 km is closest. ;-) > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >----- Original Message ----- > >From: "Christopher Morrow" >To: "Kenneth McRae" >Cc: "NANOG" >Sent: Saturday, February 7, 2015 12:02:11 PM >Subject: Re: Low cost WDM gear > >would be good for mike to define 'long distances' here, is it: >2km >30km >300km >3000km > >Probably the 30-60k range is what you mean by 'long distances' but... >clarity might help. > >On Sat, Feb 7, 2015 at 12:55 PM, Kenneth McRae >wrote: >> Mike, >> >> I just replaced a bunch of FiberStore WDM passive muxes with OSI >>Hardware >> equipment. The FiberStore gear was a huge disappointment (excessive >>loss, >> poor technical support, refusal to issue refund without threatening >>legal >> action, etc.). I have had good results from the OSI equipment so far. I >> run passive muxes for CWDM (8 - 16 channels). >> >> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: >> >> Hi Mike >> >> I can recommend a couple of vendors that provide cost effective >>solutions. >> Ekinops & Packetlight. >> >> On Saturday, February 7, 2015, Mike Hammett wrote: >> >> I know there are various Asian vendors for low cost (less than $500) >>muxes >> to throw 16 or however many colors onto a strand. However, they don't >>work >> so well when you don't control the optics used on both sides (therefore >> must use standard wavelengths), obviously only do a handful of channels >>and >> have a distance limitation. >> What solutions are out there that don't cost an arm and a leg? >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> -- >> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: >>*+52 >> 656-257-1109* >> >> CONFIDENTIALITY NOTICE: This communication is intended only for the use >> of the individual or entity to which it is addressed and may contain >> information that is privileged, confidential, and exempt from >>disclosure >> under applicable law. If you are not the intended recipient of this >> information, you are notified that any use, dissemination, >>distribution, or >> copying of the communication is strictly prohibited. >> >> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la >> persona o entidad a la que se dirige y puede contener información >> privilegiada, confidencial y exenta de divulgación bajo la legislación >> aplicable. Si no es el destinatario de esta información, se le notifica >>que >> cualquier uso, difusión, distribución o copia de la comunicación está >> estrictamente prohibido. > From nanog at ics-il.net Sat Feb 7 19:21:08 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 7 Feb 2015 13:21:08 -0600 (CST) Subject: Low cost WDM gear In-Reply-To: <55f63173-8c22-4b2b-8b2c-1b09ee265085@me.com> Message-ID: <29346087.1086.1423336850286.JavaMail.mhammett@ThunderFuck> Any tips on getting other people to use colored optics or is it not the issue that I'd expect it to be? This particular application would be to connect two datacenters together over dark fiber and transport customers across as needed. I could see it being a little difficult to get someone to buy special optics (even if you can source generic ones) for your route. I wouldn't have an issue, but then again, I'm fairly easygoing... and "thrifty." Another scenario before me is within a datacenter when trying to save on cross connect charges. Spending a few thousand bucks once sure beats $300/month forever. I'm working with several other ISPs, some of which don't want another entity to be between them and their upstream. [Cut rambling short.] I guess the short of it is, active solutions are expensive, so do that or don't. ;-) I did get an AlcaLu quote under $25k once, but it wasn't far under. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Kenneth McRae" To: "Mike Hammett" Cc: "NANOG" Sent: Saturday, February 7, 2015 1:12:01 PM Subject: Re: Low cost WDM gear Yeah, you can get up to 80km on a passive unit using SFP+ and up to 120km using XFP. To cover the distance you are considering, you would need to insert an amplifier. Depending on the number of channels you require, a passive solution with an amplified would still be less expensive than an active solution. When I was conducting my research, I could not find an active solution under $25K. On Feb 07, 2015, at 10:32 AM, Mike Hammett wrote: Well, I'm not an expert in the world of long haul optics, but I think I'd want active over passive for the ability to use standard interfaces on the equipment (routers, switches, etc.) at either end. Then again, maybe something has changed that I don't know about. I would also think active would be better able to go those 185 mile distances than passive. I assume I'd need an amplifier in the middle to even make it that far. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Kenneth McRae" < kenneth.mcrae at me.com > To: "Mike Hammett" < nanog at ics-il.net > Cc: "NANOG" < nanog at nanog.org > Sent: Saturday, February 7, 2015 12:17:35 PM Subject: Re: Low cost WDM gear Are you looking for an active or passive solution? On Feb 07, 2015, at 10:06 AM, Mike Hammett < nanog at ics-il.net > wrote: One particular route I'm looking at is 185 miles, so of the options presented 300 km is closest. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Christopher Morrow" < morrowc.lists at gmail.com > To: "Kenneth McRae" < kenneth.mcrae at me.com > Cc: "NANOG" < nanog at nanog.org > Sent: Saturday, February 7, 2015 12:02:11 PM Subject: Re: Low cost WDM gear would be good for mike to define 'long distances' here, is it: 2km 30km 300km 3000km Probably the 30-60k range is what you mean by 'long distances' but... clarity might help. On Sat, Feb 7, 2015 at 12:55 PM, Kenneth McRae < kenneth.mcrae at me.com > wrote:
Mike,
I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware
equipment. The FiberStore gear was a huge disappointment (excessive loss,
poor technical support, refusal to issue refund without threatening legal
action, etc.). I have had good results from the OSI equipment so far. I
run passive muxes for CWDM (8 - 16 channels).
On Feb 07, 2015, at 09:51 AM, Manuel Marín < mmg at transtelco.net > wrote:
Hi Mike
I can recommend a couple of vendors that provide cost effective solutions.
Ekinops & Packetlight.
On Saturday, February 7, 2015, Mike Hammett < nanog at ics-il.net > wrote:
I know there are various Asian vendors for low cost (less than $500) muxes
to throw 16 or however many colors onto a strand. However, they don't work
so well when you don't control the optics used on both sides (therefore
must use standard wavelengths), obviously only do a handful of channels and
have a distance limitation.
What solutions are out there that don't cost an arm and a leg?
-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
--
TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: *+52
656-257-1109*
CONFIDENTIALITY NOTICE: This communication is intended only for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, confidential, and exempt from disclosure
under applicable law. If you are not the intended recipient of this
information, you are notified that any use, dissemination, distribution, or
copying of the communication is strictly prohibited.
AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la
persona o entidad a la que se dirige y puede contener información
privilegiada, confidencial y exenta de divulgación bajo la legislación
aplicable. Si no es el destinatario de esta información, se le notifica que
cualquier uso, difusión, distribución o copia de la comunicación está
estrictamente prohibido.
From mark.tinka at seacom.mu Sat Feb 7 19:26:28 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 07 Feb 2015 21:26:28 +0200 Subject: Low cost WDM gear In-Reply-To: <1B3F9E60-9B88-4D63-BED6-975E1180E78F@gmail.com> References: <5739795.895.1423332278146.JavaMail.mhammett@ThunderFuck> <1B3F9E60-9B88-4D63-BED6-975E1180E78F@gmail.com> Message-ID: <54D666E4.3030609@seacom.mu> On 7/Feb/15 21:17, Phil Bedard wrote: > Is this for 10G? I'm kind of assuming 10G. What kind of equipment is > being plugged into these? 300km is way beyond what you'll get with a > passive solution, it's definitely in the "long-haul" terrtory. If you are > launching out of a router the best pluggable optic you can generally get > is rated at 80km, 10GBase-ZR, but even a passive mux at each end shaves > some of that distance off. > > 300km is going to require amplifiers at intervals across the span. Who is > providing the fiber? I'd start talking to traditional transport vendors. > Ekinops as mentioned is probably decent at a lower price, Adva works well > and isn't all that expensive, even Cisco has gear reasonably priced. If > you want to cover 300km on a fiber span though "cheap" isn't really a word > I would describe. It's why people lease circuits. :) Agree - US$500 (or thereabout) to cover 300km at a reasonable speed with some reliability and manageability is a stretch (no pun intended). Mark. From nanog at ics-il.net Sat Feb 7 19:32:14 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 7 Feb 2015 13:32:14 -0600 (CST) Subject: Low cost WDM gear In-Reply-To: <1B3F9E60-9B88-4D63-BED6-975E1180E78F@gmail.com> Message-ID: <13363836.1143.1423337516982.JavaMail.mhammett@ThunderFuck> Multiple 10G, yes. I'll reach out to the vendors mentioned to see how they line up, but it looks like I need to look into amps for the passive gear. There's 8 huts between the two ends, so no shortage of opportunities to amplify the signal. I'll know more about that when I get the amount of loss along the route. Most people I know leasing circuits are doing so because dark isn't available or is otherwise ass expensive due to above shortage. The last quote I got for dark out of a useful facility was like $2M. 100+ miles was like $200k, the last 10 miles or whatever was the balance. Even $100k for gear (two sides and some amps) pales in comparison to $2k+ a month for the next 20 years for a single channel. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Phil Bedard" To: "Mike Hammett" , "NANOG" Sent: Saturday, February 7, 2015 1:17:48 PM Subject: Re: Low cost WDM gear Is this for 10G? I'm kind of assuming 10G. What kind of equipment is being plugged into these? 300km is way beyond what you'll get with a passive solution, it's definitely in the "long-haul" terrtory. If you are launching out of a router the best pluggable optic you can generally get is rated at 80km, 10GBase-ZR, but even a passive mux at each end shaves some of that distance off. 300km is going to require amplifiers at intervals across the span. Who is providing the fiber? I'd start talking to traditional transport vendors. Ekinops as mentioned is probably decent at a lower price, Adva works well and isn't all that expensive, even Cisco has gear reasonably priced. If you want to cover 300km on a fiber span though "cheap" isn't really a word I would describe. It's why people lease circuits. :) Phil On 2/7/15, 18:04, "Mike Hammett" wrote: >One particular route I'm looking at is 185 miles, so of the options >presented 300 km is closest. ;-) > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >----- Original Message ----- > >From: "Christopher Morrow" >To: "Kenneth McRae" >Cc: "NANOG" >Sent: Saturday, February 7, 2015 12:02:11 PM >Subject: Re: Low cost WDM gear > >would be good for mike to define 'long distances' here, is it: >2km >30km >300km >3000km > >Probably the 30-60k range is what you mean by 'long distances' but... >clarity might help. > >On Sat, Feb 7, 2015 at 12:55 PM, Kenneth McRae >wrote: >> Mike, >> >> I just replaced a bunch of FiberStore WDM passive muxes with OSI >>Hardware >> equipment. The FiberStore gear was a huge disappointment (excessive >>loss, >> poor technical support, refusal to issue refund without threatening >>legal >> action, etc.). I have had good results from the OSI equipment so far. I >> run passive muxes for CWDM (8 - 16 channels). >> >> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: >> >> Hi Mike >> >> I can recommend a couple of vendors that provide cost effective >>solutions. >> Ekinops & Packetlight. >> >> On Saturday, February 7, 2015, Mike Hammett wrote: >> >> I know there are various Asian vendors for low cost (less than $500) >>muxes >> to throw 16 or however many colors onto a strand. However, they don't >>work >> so well when you don't control the optics used on both sides (therefore >> must use standard wavelengths), obviously only do a handful of channels >>and >> have a distance limitation. >> What solutions are out there that don't cost an arm and a leg? >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> -- >> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: >>*+52 >> 656-257-1109* >> >> CONFIDENTIALITY NOTICE: This communication is intended only for the use >> of the individual or entity to which it is addressed and may contain >> information that is privileged, confidential, and exempt from >>disclosure >> under applicable law. If you are not the intended recipient of this >> information, you are notified that any use, dissemination, >>distribution, or >> copying of the communication is strictly prohibited. >> >> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la >> persona o entidad a la que se dirige y puede contener información >> privilegiada, confidencial y exenta de divulgación bajo la legislación >> aplicable. Si no es el destinatario de esta información, se le notifica >>que >> cualquier uso, difusión, distribución o copia de la comunicación está >> estrictamente prohibido. > From nanog at ics-il.net Sat Feb 7 19:34:29 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 7 Feb 2015 13:34:29 -0600 (CST) Subject: Low cost WDM gear In-Reply-To: <54D666E4.3030609@seacom.mu> Message-ID: <1729849.1159.1423337654278.JavaMail.mhammett@ThunderFuck> Oh, I had no fantasies that the $500 Chinese muxes would do the distance. Actually quite the opposite in that I knew they couldn't, so looking for alternative solutions that didn't break the bank. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mark Tinka" To: nanog at nanog.org Sent: Saturday, February 7, 2015 1:26:28 PM Subject: Re: Low cost WDM gear On 7/Feb/15 21:17, Phil Bedard wrote: > Is this for 10G? I'm kind of assuming 10G. What kind of equipment is > being plugged into these? 300km is way beyond what you'll get with a > passive solution, it's definitely in the "long-haul" terrtory. If you are > launching out of a router the best pluggable optic you can generally get > is rated at 80km, 10GBase-ZR, but even a passive mux at each end shaves > some of that distance off. > > 300km is going to require amplifiers at intervals across the span. Who is > providing the fiber? I'd start talking to traditional transport vendors. > Ekinops as mentioned is probably decent at a lower price, Adva works well > and isn't all that expensive, even Cisco has gear reasonably priced. If > you want to cover 300km on a fiber span though "cheap" isn't really a word > I would describe. It's why people lease circuits. :) Agree - US$500 (or thereabout) to cover 300km at a reasonable speed with some reliability and manageability is a stretch (no pun intended). Mark. From bedard.phil at gmail.com Sat Feb 7 19:55:58 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Sat, 07 Feb 2015 14:55:58 -0500 Subject: Metaswitch ax1000 as a RR In-Reply-To: References: Message-ID: <1E8CF98D-1FAC-4A4E-B27A-93B1FCBFB9BA@gmail.com> I've been testing various vRR solutions recently but haven't taken a long look at Metaswitch, but I may contact them. On paper, their RR doesn't support all the AFI/SAFI combinations I require. There are a few commercial options which have come to market very recently namely: ALU VSR Juniper vMX (vRR version) Cisco XRv (IOS-XR) Cisco CSR1000v (IOS-XE) I can't give exact numbers, but all of them are much faster on pretty basic newish Xeon hardware than a Cisco ASR9K/Juniper MX with the latest and greatest RP, while using almost no CPU really. They don't need much RAM either, 8-16GB is more than enough. XRv and the CSR1000v will run under ESX fine, and are packaged/documented to deploy that way. vMX/VSR will but it's not really a supported/documented thing yet, they are currently supported running under Qemu/KVM. One issue with VSR/xRV under ESX right now is they have no "display" drivers/output, so you have to use a virtual serial port which is only supported with the Enterprise+ version of ESX for some inane reason. XRv is 32-bit for now, the others are all 64-bit. CSR1000v has definitey been around the longest. XRv, vMX, and VSR all get built the same time as the router software now so they get features when the router software does. You will find more features in them than the CSR1000v and new service provider features will be in XR before XE. For instance Cisco has something called Optimized Route Reflection where a vRR will simulate the IGP network rooted at each client and send the best BGP paths specific to each client. It means you can have a centralized RR without running into the issue of it selecting paths based on its position in the network vs. the client. That's a beta XRv thing but I don't know if you'll ever see it in XE. All of them support pretty much every major AFI/SAFI. Pricing wise the CSR1000v is going to easily be the cheapest option. Phil On 2/5/15, 20:41, "David Bass" wrote: >I have a client looking to implement x86 based route reflectors, and was >looking at the ax1000. I'm wondering if anyone has implemented it yet, >and what your experience has been? > >Any other alternatives would also be appreciated. This customer does >standard L3 VPNs, and VPLS services so the software has to support that. > >Thanks! > > From mark.tinka at seacom.mu Sat Feb 7 20:09:28 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 07 Feb 2015 22:09:28 +0200 Subject: Metaswitch ax1000 as a RR In-Reply-To: <1E8CF98D-1FAC-4A4E-B27A-93B1FCBFB9BA@gmail.com> References: <1E8CF98D-1FAC-4A4E-B27A-93B1FCBFB9BA@gmail.com> Message-ID: <54D670F8.8050604@seacom.mu> On 7/Feb/15 21:55, Phil Bedard wrote: > CSR1000v has definitey been around the longest. XRv, vMX, and VSR all get > built the same time as the router software now so they get features when > the router software does. Junos 14.2R2 just released a few days ago, which officially brings vMX to the market. That said, pricing is not yet (officially) available, but one can get code to test from your SE in the interim. > You will find more features in them than the > CSR1000v and new service provider features will be in XR before XE. For > instance Cisco has something called Optimized Route Reflection where a vRR > will simulate the IGP network rooted at each client and send the best BGP > paths specific to each client. It means you can have a centralized RR > without running into the issue of it selecting paths based on its position > in the network vs. the client. That's a beta XRv thing but I don't know > if you'll ever see it in XE. This was one of the reasons shifting the RR functionality to a VM on x86 hardware compelled us to go this route. Much cheaper and more sustainable to deploy a box at site to avoid this issue until the tech. (BGP-ORR) becomes more widely available from the community/vendors. I believe it's being worked on under: http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-08 Cheers, Mark. From bedard.phil at gmail.com Sat Feb 7 20:10:19 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Sat, 07 Feb 2015 15:10:19 -0500 Subject: Low cost WDM gear In-Reply-To: <13363836.1143.1423337516982.JavaMail.mhammett@ThunderFuck> References: <1B3F9E60-9B88-4D63-BED6-975E1180E78F@gmail.com> <13363836.1143.1423337516982.JavaMail.mhammett@ThunderFuck> Message-ID: <10BEFAE3-670E-4428-AEF1-8A68738D4631@gmail.com> Sure, everyone has different needs and there are certainly lots of use cases for having your own fiber. You can look into passive muxes and amps, if you have enough places to amplify along the way shouldn't be a big deal. Companies like PacketLight (also mentioned) make 1RU amplifiers. Phil On 2/7/15, 19:32, "Mike Hammett" wrote: >Multiple 10G, yes. I'll reach out to the vendors mentioned to see how >they line up, but it looks like I need to look into amps for the passive >gear. There's 8 huts between the two ends, so no shortage of >opportunities to amplify the signal. I'll know more about that when I get >the amount of loss along the route. > >Most people I know leasing circuits are doing so because dark isn't >available or is otherwise ass expensive due to above shortage. The last >quote I got for dark out of a useful facility was like $2M. 100+ miles >was like $200k, the last 10 miles or whatever was the balance. Even $100k >for gear (two sides and some amps) pales in comparison to $2k+ a month >for the next 20 years for a single channel. > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >----- Original Message ----- > >From: "Phil Bedard" >To: "Mike Hammett" , "NANOG" >Sent: Saturday, February 7, 2015 1:17:48 PM >Subject: Re: Low cost WDM gear > >Is this for 10G? I'm kind of assuming 10G. What kind of equipment is >being plugged into these? 300km is way beyond what you'll get with a >passive solution, it's definitely in the "long-haul" terrtory. If you are >launching out of a router the best pluggable optic you can generally get >is rated at 80km, 10GBase-ZR, but even a passive mux at each end shaves >some of that distance off. > >300km is going to require amplifiers at intervals across the span. Who is >providing the fiber? I'd start talking to traditional transport vendors. >Ekinops as mentioned is probably decent at a lower price, Adva works well >and isn't all that expensive, even Cisco has gear reasonably priced. If >you want to cover 300km on a fiber span though "cheap" isn't really a >word >I would describe. It's why people lease circuits. :) > >Phil > > > >On 2/7/15, 18:04, "Mike Hammett" wrote: > >>One particular route I'm looking at is 185 miles, so of the options >>presented 300 km is closest. ;-) >> >> >> >> >>----- >>Mike Hammett >>Intelligent Computing Solutions >>http://www.ics-il.com >> >>----- Original Message ----- >> >>From: "Christopher Morrow" >>To: "Kenneth McRae" >>Cc: "NANOG" >>Sent: Saturday, February 7, 2015 12:02:11 PM >>Subject: Re: Low cost WDM gear >> >>would be good for mike to define 'long distances' here, is it: >>2km >>30km >>300km >>3000km >> >>Probably the 30-60k range is what you mean by 'long distances' but... >>clarity might help. >> >>On Sat, Feb 7, 2015 at 12:55 PM, Kenneth McRae >>wrote: >>> Mike, >>> >>> I just replaced a bunch of FiberStore WDM passive muxes with OSI >>>Hardware >>> equipment. The FiberStore gear was a huge disappointment (excessive >>>loss, >>> poor technical support, refusal to issue refund without threatening >>>legal >>> action, etc.). I have had good results from the OSI equipment so far. >>>I >>> run passive muxes for CWDM (8 - 16 channels). >>> >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: >>> >>> Hi Mike >>> >>> I can recommend a couple of vendors that provide cost effective >>>solutions. >>> Ekinops & Packetlight. >>> >>> On Saturday, February 7, 2015, Mike Hammett wrote: >>> >>> I know there are various Asian vendors for low cost (less than $500) >>>muxes >>> to throw 16 or however many colors onto a strand. However, they don't >>>work >>> so well when you don't control the optics used on both sides >>>(therefore >>> must use standard wavelengths), obviously only do a handful of >>>channels >>>and >>> have a distance limitation. >>> What solutions are out there that don't cost an arm and a leg? >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> -- >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | >>>MX: >>>*+52 >>> 656-257-1109* >>> >>> CONFIDENTIALITY NOTICE: This communication is intended only for the >>>use >>> of the individual or entity to which it is addressed and may contain >>> information that is privileged, confidential, and exempt from >>>disclosure >>> under applicable law. If you are not the intended recipient of this >>> information, you are notified that any use, dissemination, >>>distribution, or >>> copying of the communication is strictly prohibited. >>> >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la >>> persona o entidad a la que se dirige y puede contener información >>> privilegiada, confidencial y exenta de divulgación bajo la legislación >>> aplicable. Si no es el destinatario de esta información, se le >>>notifica >>>que >>> cualquier uso, difusión, distribución o copia de la comunicación está >>> estrictamente prohibido. >> > > From rodrigo at 1telecom.com.br Sat Feb 7 20:24:43 2015 From: rodrigo at 1telecom.com.br (Rodrigo 1telecom) Date: Sat, 7 Feb 2015 17:24:43 -0300 Subject: Low cost WDM gear In-Reply-To: <68212b43-4395-4567-929c-29cb6fad21d1@me.com> References: <68212b43-4395-4567-929c-29cb6fad21d1@me.com> Message-ID: <29880E85-A533-40EE-84F2-975CFDB28263@1telecom.com.br> What others vendors do you using? Here in Brazil only PADTEC have this passive solution... Some days ago Digitel contact me to show your multiplex solution... Is a active solution... We import this from fiberstore, but i don't know others vendors to buy 10G sfp+ cwdm and this mux/demux... Enviado via iPhone  Grupo Connectoway > Em 07/02/2015, às 16:04, Kenneth McRae escreveu: > > Hi Enviado, > > I cannot recommend FiberStore as I had a bad experience with them. I needed to cover only 3km from A to B side. When using 10km optics, I saw a loss of over 5db with their passive mux inserted into the path which created a total loss of over -20db which is outside of the tolerances for our equipment with 10km SFP+. Using another vendors low insertion loss mux corrected our issue. I am sure if you are using an 80km optic, you may be able to tolerate a higher insertion loss to cover < 60km. I also notice that their CDWM optics averaged about 3db less in power output when compared to other vendors. > > Thanks > > Kenneth > >> On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom wrote: >> > >> Hi kenneth... which the distance do you have from side A to side B when you using passive solutions from fiberstore( mux and demux)? >> I buy this mux and demux(4 channels single fiber) and only make a test about 60km( mux side A and demux on side B) with sfp+10gb for 80km... ( only see ddm on my ex3300( about -19db for 60km). Test switch access with ssh and pinging tests... >> What kind os issue do you have? For distances less than 60km is this solution good? >> Thanks!!! >> >> Enviado via iPhone  >> Grupo Connectoway >> >>> Em 07/02/2015, às 14:55, Kenneth McRae escreveu: >>> Mike, >>> I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware equipment. The FiberStore gear was a huge disappointment (excessive loss, poor technical support, refusal to issue refund without threatening legal action, etc.). I have had good results from the OSI equipment so far. I run passive muxes for CWDM (8 - 16 channels). >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: >>> Hi Mike >>> I can recommend a couple of vendors that provide cost effective solutions. >>> Ekinops & Packetlight. >>> On Saturday, February 7, 2015, Mike Hammett wrote: >>> I know there are various Asian vendors for low cost (less than $500) muxes >>> to throw 16 or however many colors onto a strand. However, they don't work >>> so well when you don't control the optics used on both sides (therefore >>> must use standard wavelengths), obviously only do a handful of channels and >>> have a distance limitation. >>> What solutions are out there that don't cost an arm and a leg? >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> -- >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: *+52 >>> 656-257-1109* >>> CONFIDENTIALITY NOTICE: This communication is intended only for the use >>> of the individual or entity to which it is addressed and may contain >>> information that is privileged, confidential, and exempt from disclosure >>> under applicable law. If you are not the intended recipient of this >>> information, you are notified that any use, dissemination, distribution, or >>> copying of the communication is strictly prohibited. >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la >>> persona o entidad a la que se dirige y puede contener información >>> privilegiada, confidencial y exenta de divulgación bajo la legislación >>> aplicable. Si no es el destinatario de esta información, se le notifica que >>> cualquier uso, difusión, distribución o copia de la comunicación está >>> estrictamente prohibido. From faisal at snappytelecom.net Sat Feb 7 20:30:50 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 7 Feb 2015 20:30:50 +0000 (GMT) Subject: Low cost WDM gear In-Reply-To: <68212b43-4395-4567-929c-29cb6fad21d1@me.com> References: <68212b43-4395-4567-929c-29cb6fad21d1@me.com> Message-ID: <996194635.1043809.1423341050734.JavaMail.zimbra@snappytelecom.net> Kenneth, I am sorry, but it sounds like you made a mistake in not calculating loss of the devices in the path, and are blaming a Mfg for the mistake... They clearly list the insertion loss for the different muxes in the specs on their website. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Kenneth McRae" > To: "Rodrigo 1telecom" > Cc: "NANOG" > Sent: Saturday, February 7, 2015 2:04:10 PM > Subject: Re: Low cost WDM gear > > Hi Enviado, > > I cannot recommend FiberStore as I had a bad experience with them.  I needed > to cover only 3km from A to B side.  When using 10km optics, I saw a loss of > over 5db  with their passive mux inserted into the path which created a > total loss of over -20db which is outside of the tolerances for our > equipment with 10km SFP+.  Using another vendors low insertion loss mux > corrected our issue.  I am sure if you are using an 80km optic, you may be > able to tolerate a higher insertion loss to cover < 60km.  I also notice > that their CDWM optics averaged about 3db less in power output when compared > to other vendors. > > Thanks > > Kenneth > > On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom > wrote: > > Hi kenneth... which the distance do you have from side A to side B when you > using passive solutions from fiberstore( mux and demux)? > I buy this mux and demux(4 channels single fiber) and only make a test about > 60km( mux side A and demux on side B) with sfp+10gb for 80km... ( only see > ddm on my ex3300( about -19db for 60km). Test switch access with ssh and > pinging tests... > What kind os issue do you have? For distances less than 60km is this solution > good? > Thanks!!! > > Enviado via iPhone  > Grupo Connectoway > > Em 07/02/2015, às 14:55, Kenneth McRae escreveu: > Mike, > I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware > equipment. The FiberStore gear was a huge disappointment (excessive loss, > poor technical support, refusal to issue refund without threatening legal > action, etc.). I have had good results from the OSI equipment so far. I run > passive muxes for CWDM (8 - 16 channels). > On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: > Hi Mike > I can recommend a couple of vendors that provide cost effective solutions. > Ekinops & Packetlight. > On Saturday, February 7, 2015, Mike Hammett wrote: > I know there are various Asian vendors for low cost (less than $500) muxes > to throw 16 or however many colors onto a strand. However, they don't work > so well when you don't control the optics used on both sides (therefore > must use standard wavelengths), obviously only do a handful of channels and > have a distance limitation. > What solutions are out there that don't cost an arm and a leg? > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > -- > TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: *+52 > 656-257-1109* > CONFIDENTIALITY NOTICE: This communication is intended only for the use > of the individual or entity to which it is addressed and may contain > information that is privileged, confidential, and exempt from disclosure > under applicable law. If you are not the intended recipient of this > information, you are notified that any use, dissemination, distribution, or > copying of the communication is strictly prohibited. > AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la > persona o entidad a la que se dirige y puede contener información > privilegiada, confidencial y exenta de divulgación bajo la legislación > aplicable. Si no es el destinatario de esta información, se le notifica que > cualquier uso, difusión, distribución o copia de la comunicación está > estrictamente prohibido. From faisal at snappytelecom.net Sat Feb 7 20:40:26 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 7 Feb 2015 20:40:26 +0000 (GMT) Subject: Low cost WDM gear In-Reply-To: <13363836.1143.1423337516982.JavaMail.mhammett@ThunderFuck> References: <13363836.1143.1423337516982.JavaMail.mhammett@ThunderFuck> Message-ID: <257647570.1043912.1423341626600.JavaMail.zimbra@snappytelecom.net> Mike, Lighting up dark fiber is very similar to doing fixed wireless links (which you are familiar with). There are different components involved in making a solutions work.... for each of the problems you have stated there is solution, and yes you have to calculate the loss and match power / optics to make it work. FYI.. all CWDM/DWDM Muxes are passive ... :) Active components (can be external or integrated). If you want to do a direct run, from DC to DC using the Dark Fiber, you will need to have signal regeneration (or you may be able to get away with amps). It is commonly expected for the transport provider to hand off the live circuit using standard SFP/SFP+, which means that they have to use a 'media converter' of some sorts to covert from Colorized Light to Standard 1330 or 880nm hand off. If you want more info, hit me off list. Regards. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Mike Hammett" > To: "NANOG" > Sent: Saturday, February 7, 2015 2:32:14 PM > Subject: Re: Low cost WDM gear > > Multiple 10G, yes. I'll reach out to the vendors mentioned to see how they > line up, but it looks like I need to look into amps for the passive gear. > There's 8 huts between the two ends, so no shortage of opportunities to > amplify the signal. I'll know more about that when I get the amount of loss > along the route. > > Most people I know leasing circuits are doing so because dark isn't available > or is otherwise ass expensive due to above shortage. The last quote I got > for dark out of a useful facility was like $2M. 100+ miles was like $200k, > the last 10 miles or whatever was the balance. Even $100k for gear (two > sides and some amps) pales in comparison to $2k+ a month for the next 20 > years for a single channel. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Phil Bedard" > To: "Mike Hammett" , "NANOG" > Sent: Saturday, February 7, 2015 1:17:48 PM > Subject: Re: Low cost WDM gear > > Is this for 10G? I'm kind of assuming 10G. What kind of equipment is > being plugged into these? 300km is way beyond what you'll get with a > passive solution, it's definitely in the "long-haul" terrtory. If you are > launching out of a router the best pluggable optic you can generally get > is rated at 80km, 10GBase-ZR, but even a passive mux at each end shaves > some of that distance off. > > 300km is going to require amplifiers at intervals across the span. Who is > providing the fiber? I'd start talking to traditional transport vendors. > Ekinops as mentioned is probably decent at a lower price, Adva works well > and isn't all that expensive, even Cisco has gear reasonably priced. If > you want to cover 300km on a fiber span though "cheap" isn't really a word > I would describe. It's why people lease circuits. :) > > Phil > > > > On 2/7/15, 18:04, "Mike Hammett" wrote: > > >One particular route I'm looking at is 185 miles, so of the options > >presented 300 km is closest. ;-) > > > > > > > > > >----- > >Mike Hammett > >Intelligent Computing Solutions > >http://www.ics-il.com > > > >----- Original Message ----- > > > >From: "Christopher Morrow" > >To: "Kenneth McRae" > >Cc: "NANOG" > >Sent: Saturday, February 7, 2015 12:02:11 PM > >Subject: Re: Low cost WDM gear > > > >would be good for mike to define 'long distances' here, is it: > >2km > >30km > >300km > >3000km > > > >Probably the 30-60k range is what you mean by 'long distances' but... > >clarity might help. > > > >On Sat, Feb 7, 2015 at 12:55 PM, Kenneth McRae > >wrote: > >> Mike, > >> > >> I just replaced a bunch of FiberStore WDM passive muxes with OSI > >>Hardware > >> equipment. The FiberStore gear was a huge disappointment (excessive > >>loss, > >> poor technical support, refusal to issue refund without threatening > >>legal > >> action, etc.). I have had good results from the OSI equipment so far. I > >> run passive muxes for CWDM (8 - 16 channels). > >> > >> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: > >> > >> Hi Mike > >> > >> I can recommend a couple of vendors that provide cost effective > >>solutions. > >> Ekinops & Packetlight. > >> > >> On Saturday, February 7, 2015, Mike Hammett wrote: > >> > >> I know there are various Asian vendors for low cost (less than $500) > >>muxes > >> to throw 16 or however many colors onto a strand. However, they don't > >>work > >> so well when you don't control the optics used on both sides (therefore > >> must use standard wavelengths), obviously only do a handful of channels > >>and > >> have a distance limitation. > >> What solutions are out there that don't cost an arm and a leg? > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> > >> -- > >> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: > >>*+52 > >> 656-257-1109* > >> > >> CONFIDENTIALITY NOTICE: This communication is intended only for the use > >> of the individual or entity to which it is addressed and may contain > >> information that is privileged, confidential, and exempt from > >>disclosure > >> under applicable law. If you are not the intended recipient of this > >> information, you are notified that any use, dissemination, > >>distribution, or > >> copying of the communication is strictly prohibited. > >> > >> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la > >> persona o entidad a la que se dirige y puede contener información > >> privilegiada, confidencial y exenta de divulgación bajo la legislación > >> aplicable. Si no es el destinatario de esta información, se le notifica > >>que > >> cualquier uso, difusión, distribución o copia de la comunicación está > >> estrictamente prohibido. > > > > > From faisal at snappytelecom.net Sat Feb 7 20:44:19 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 7 Feb 2015 20:44:19 +0000 (GMT) Subject: Low cost WDM gear In-Reply-To: <29880E85-A533-40EE-84F2-975CFDB28263@1telecom.com.br> References: <68212b43-4395-4567-929c-29cb6fad21d1@me.com> <29880E85-A533-40EE-84F2-975CFDB28263@1telecom.com.br> Message-ID: <1283742745.1043960.1423341859204.JavaMail.zimbra@snappytelecom.net> If you pay close attention to the Spec Sheets, on power output, insertion loss, sensitivity, and do the proper calculation for your link, then using anyone's products, passive or active will work unless the devices do not meet specified specs. If you don't do your homework, cals on the design, loss, and just buy stuff based on whatever, then it does not matter who the mfg. is, you are very very likely to be surprised in a bad way. :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Rodrigo 1telecom" > To: "Kenneth McRae" > Cc: "NANOG" > Sent: Saturday, February 7, 2015 3:24:43 PM > Subject: Re: Low cost WDM gear > > What others vendors do you using? Here in Brazil only PADTEC have this > passive solution... Some days ago Digitel contact me to show your multiplex > solution... Is a active solution... > We import this from fiberstore, but i don't know others vendors to buy 10G > sfp+ cwdm and this mux/demux... > > Enviado via iPhone  > Grupo Connectoway > > > Em 07/02/2015, às 16:04, Kenneth McRae escreveu: > > > > Hi Enviado, > > > > I cannot recommend FiberStore as I had a bad experience with them. I > > needed to cover only 3km from A to B side. When using 10km optics, I saw > > a loss of over 5db with their passive mux inserted into the path which > > created a total loss of over -20db which is outside of the tolerances for > > our equipment with 10km SFP+. Using another vendors low insertion loss > > mux corrected our issue. I am sure if you are using an 80km optic, you > > may be able to tolerate a higher insertion loss to cover < 60km. I also > > notice that their CDWM optics averaged about 3db less in power output when > > compared to other vendors. > > > > Thanks > > > > Kenneth > > > >> On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom > >> wrote: > >> > > > >> Hi kenneth... which the distance do you have from side A to side B when > >> you using passive solutions from fiberstore( mux and demux)? > >> I buy this mux and demux(4 channels single fiber) and only make a test > >> about 60km( mux side A and demux on side B) with sfp+10gb for 80km... ( > >> only see ddm on my ex3300( about -19db for 60km). Test switch access with > >> ssh and pinging tests... > >> What kind os issue do you have? For distances less than 60km is this > >> solution good? > >> Thanks!!! > >> > >> Enviado via iPhone  > >> Grupo Connectoway > >> > >>> Em 07/02/2015, às 14:55, Kenneth McRae escreveu: > >>> Mike, > >>> I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware > >>> equipment. The FiberStore gear was a huge disappointment (excessive > >>> loss, poor technical support, refusal to issue refund without > >>> threatening legal action, etc.). I have had good results from the OSI > >>> equipment so far. I run passive muxes for CWDM (8 - 16 channels). > >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: > >>> Hi Mike > >>> I can recommend a couple of vendors that provide cost effective > >>> solutions. > >>> Ekinops & Packetlight. > >>> On Saturday, February 7, 2015, Mike Hammett wrote: > >>> I know there are various Asian vendors for low cost (less than $500) > >>> muxes > >>> to throw 16 or however many colors onto a strand. However, they don't > >>> work > >>> so well when you don't control the optics used on both sides (therefore > >>> must use standard wavelengths), obviously only do a handful of channels > >>> and > >>> have a distance limitation. > >>> What solutions are out there that don't cost an arm and a leg? > >>> ----- > >>> Mike Hammett > >>> Intelligent Computing Solutions > >>> http://www.ics-il.com > >>> -- > >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: > >>> *+52 > >>> 656-257-1109* > >>> CONFIDENTIALITY NOTICE: This communication is intended only for the use > >>> of the individual or entity to which it is addressed and may contain > >>> information that is privileged, confidential, and exempt from disclosure > >>> under applicable law. If you are not the intended recipient of this > >>> information, you are notified that any use, dissemination, distribution, > >>> or > >>> copying of the communication is strictly prohibited. > >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la > >>> persona o entidad a la que se dirige y puede contener información > >>> privilegiada, confidencial y exenta de divulgación bajo la legislación > >>> aplicable. Si no es el destinatario de esta información, se le notifica > >>> que > >>> cualquier uso, difusión, distribución o copia de la comunicación está > >>> estrictamente prohibido. > From kenneth.mcrae at me.com Sat Feb 7 20:46:20 2015 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Sat, 07 Feb 2015 20:46:20 +0000 (GMT) Subject: Low cost WDM gear Message-ID: <4db12fe1-b833-4aeb-b2a8-d19d2f4d8636@me.com> Faisal, I worked directly with FiberStore's engineers to determine the optics and mux needed for my use case.  They recommended the mux and the optics for the 3km distance.   You can always buy stronger optics, but that is not point I am making.   I provided the scale and scope of the project and they provided the BOM to deliver the required service.  When the equipment failed, FiberStore refused to honor their return policy and issue an RMA until we threatened legal action.  Same sales scenario with OSI Hardware..  They provide the BOM with passive muxes and 10km optics and it works with no problem. In this scenario, I can definitely blame the manufacturer.  No to mention the terrible technical support that they offer. On Feb 07, 2015, at 12:30 PM, Faisal Imtiaz wrote: Kenneth, I am sorry, but it sounds like you made a mistake in not calculating loss of the devices in the path, and are blaming a Mfg for the mistake... They clearly list the insertion loss for the different muxes in the specs on their website. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- From: "Kenneth McRae" To: "Rodrigo 1telecom" Cc: "NANOG" Sent: Saturday, February 7, 2015 2:04:10 PM Subject: Re: Low cost WDM gear Hi Enviado, I cannot recommend FiberStore as I had a bad experience with them.  I needed to cover only 3km from A to B side.  When using 10km optics, I saw a loss of over 5db  with their passive mux inserted into the path which created a total loss of over -20db which is outside of the tolerances for our equipment with 10km SFP+.  Using another vendors low insertion loss mux corrected our issue.  I am sure if you are using an 80km optic, you may be able to tolerate a higher insertion loss to cover < 60km.  I also notice that their CDWM optics averaged about 3db less in power output when compared to other vendors. Thanks Kenneth On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom wrote: Hi kenneth... which the distance do you have from side A to side B when you using passive solutions from fiberstore( mux and demux)? I buy this mux and demux(4 channels single fiber) and only make a test about 60km( mux side A and demux on side B) with sfp+10gb for 80km... ( only see ddm on my ex3300( about -19db for 60km). Test switch access with ssh and pinging tests... What kind os issue do you have? For distances less than 60km is this solution good? Thanks!!! Enviado via iPhone  Grupo Connectoway Em 07/02/2015, às 14:55, Kenneth McRae escreveu: Mike, I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware equipment. The FiberStore gear was a huge disappointment (excessive loss, poor technical support, refusal to issue refund without threatening legal action, etc.). I have had good results from the OSI equipment so far. I run passive muxes for CWDM (8 - 16 channels). On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: Hi Mike I can recommend a couple of vendors that provide cost effective solutions. Ekinops & Packetlight. On Saturday, February 7, 2015, Mike Hammett wrote: I know there are various Asian vendors for low cost (less than $500) muxes to throw 16 or however many colors onto a strand. However, they don't work so well when you don't control the optics used on both sides (therefore must use standard wavelengths), obviously only do a handful of channels and have a distance limitation. What solutions are out there that don't cost an arm and a leg? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com -- TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: *+52 656-257-1109* CONFIDENTIALITY NOTICE: This communication is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient of this information, you are notified that any use, dissemination, distribution, or copying of the communication is strictly prohibited. AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la persona o entidad a la que se dirige y puede contener información privilegiada, confidencial y exenta de divulgación bajo la legislación aplicable. Si no es el destinatario de esta información, se le notifica que cualquier uso, difusión, distribución o copia de la comunicación está estrictamente prohibido. From nanog at ics-il.net Sat Feb 7 20:48:37 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 7 Feb 2015 14:48:37 -0600 (CST) Subject: Low cost WDM gear In-Reply-To: <1283742745.1043960.1423341859204.JavaMail.zimbra@snappytelecom.net> Message-ID: <26642115.1304.1423342090362.JavaMail.mhammett@ThunderFuck> I'm surprised how many people (operators and vendors) in the fixed wireless space don't get down to the specs (or provide the proper info) to just figure out how it'll work before hanging the gear. I shouldn't be surprised, though. People are lazy (myself included). ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Faisal Imtiaz" To: "Rodrigo 1telecom" Cc: "NANOG" Sent: Saturday, February 7, 2015 2:44:19 PM Subject: Re: Low cost WDM gear If you pay close attention to the Spec Sheets, on power output, insertion loss, sensitivity, and do the proper calculation for your link, then using anyone's products, passive or active will work unless the devices do not meet specified specs. If you don't do your homework, cals on the design, loss, and just buy stuff based on whatever, then it does not matter who the mfg. is, you are very very likely to be surprised in a bad way. :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Rodrigo 1telecom" > To: "Kenneth McRae" > Cc: "NANOG" > Sent: Saturday, February 7, 2015 3:24:43 PM > Subject: Re: Low cost WDM gear > > What others vendors do you using? Here in Brazil only PADTEC have this > passive solution... Some days ago Digitel contact me to show your multiplex > solution... Is a active solution... > We import this from fiberstore, but i don't know others vendors to buy 10G > sfp+ cwdm and this mux/demux... > > Enviado via iPhone  > Grupo Connectoway > > > Em 07/02/2015, às 16:04, Kenneth McRae escreveu: > > > > Hi Enviado, > > > > I cannot recommend FiberStore as I had a bad experience with them. I > > needed to cover only 3km from A to B side. When using 10km optics, I saw > > a loss of over 5db with their passive mux inserted into the path which > > created a total loss of over -20db which is outside of the tolerances for > > our equipment with 10km SFP+. Using another vendors low insertion loss > > mux corrected our issue. I am sure if you are using an 80km optic, you > > may be able to tolerate a higher insertion loss to cover < 60km. I also > > notice that their CDWM optics averaged about 3db less in power output when > > compared to other vendors. > > > > Thanks > > > > Kenneth > > > >> On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom > >> wrote: > >> > > > >> Hi kenneth... which the distance do you have from side A to side B when > >> you using passive solutions from fiberstore( mux and demux)? > >> I buy this mux and demux(4 channels single fiber) and only make a test > >> about 60km( mux side A and demux on side B) with sfp+10gb for 80km... ( > >> only see ddm on my ex3300( about -19db for 60km). Test switch access with > >> ssh and pinging tests... > >> What kind os issue do you have? For distances less than 60km is this > >> solution good? > >> Thanks!!! > >> > >> Enviado via iPhone  > >> Grupo Connectoway > >> > >>> Em 07/02/2015, às 14:55, Kenneth McRae escreveu: > >>> Mike, > >>> I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware > >>> equipment. The FiberStore gear was a huge disappointment (excessive > >>> loss, poor technical support, refusal to issue refund without > >>> threatening legal action, etc.). I have had good results from the OSI > >>> equipment so far. I run passive muxes for CWDM (8 - 16 channels). > >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: > >>> Hi Mike > >>> I can recommend a couple of vendors that provide cost effective > >>> solutions. > >>> Ekinops & Packetlight. > >>> On Saturday, February 7, 2015, Mike Hammett wrote: > >>> I know there are various Asian vendors for low cost (less than $500) > >>> muxes > >>> to throw 16 or however many colors onto a strand. However, they don't > >>> work > >>> so well when you don't control the optics used on both sides (therefore > >>> must use standard wavelengths), obviously only do a handful of channels > >>> and > >>> have a distance limitation. > >>> What solutions are out there that don't cost an arm and a leg? > >>> ----- > >>> Mike Hammett > >>> Intelligent Computing Solutions > >>> http://www.ics-il.com > >>> -- > >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: > >>> *+52 > >>> 656-257-1109* > >>> CONFIDENTIALITY NOTICE: This communication is intended only for the use > >>> of the individual or entity to which it is addressed and may contain > >>> information that is privileged, confidential, and exempt from disclosure > >>> under applicable law. If you are not the intended recipient of this > >>> information, you are notified that any use, dissemination, distribution, > >>> or > >>> copying of the communication is strictly prohibited. > >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la > >>> persona o entidad a la que se dirige y puede contener información > >>> privilegiada, confidencial y exenta de divulgación bajo la legislación > >>> aplicable. Si no es el destinatario de esta información, se le notifica > >>> que > >>> cualquier uso, difusión, distribución o copia de la comunicación está > >>> estrictamente prohibido. > From kenneth.mcrae at me.com Sat Feb 7 20:49:16 2015 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Sat, 07 Feb 2015 20:49:16 +0000 (GMT) Subject: Low cost WDM gear Message-ID: <62dceecf-9668-4cba-bcaa-ae9f2337f974@me.com> That's why I engage the engineering resources on their end to make sure the chosen candidate will support the use case.  I have now performed an A/B comparison and the FiberStore gear is inferior.  Excessive loss on the mux and optics.  On Feb 07, 2015, at 12:44 PM, Faisal Imtiaz wrote: If you pay close attention to the Spec Sheets, on power output, insertion loss, sensitivity, and do the proper calculation for your link, then using anyone's products, passive or active will work unless the devices do not meet specified specs. If you don't do your homework, cals on the design, loss, and just buy stuff based on whatever, then it does not matter who the mfg. is, you are very very likely to be surprised in a bad way. :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- From: "Rodrigo 1telecom" To: "Kenneth McRae" Cc: "NANOG" Sent: Saturday, February 7, 2015 3:24:43 PM Subject: Re: Low cost WDM gear What others vendors do you using? Here in Brazil only PADTEC have this passive solution... Some days ago Digitel contact me to show your multiplex solution... Is a active solution... We import this from fiberstore, but i don't know others vendors to buy 10G sfp+ cwdm and this mux/demux... Enviado via iPhone  Grupo Connectoway > Em 07/02/2015, às 16:04, Kenneth McRae escreveu: > > Hi Enviado, > > I cannot recommend FiberStore as I had a bad experience with them. I > needed to cover only 3km from A to B side. When using 10km optics, I saw > a loss of over 5db with their passive mux inserted into the path which > created a total loss of over -20db which is outside of the tolerances for > our equipment with 10km SFP+. Using another vendors low insertion loss > mux corrected our issue. I am sure if you are using an 80km optic, you > may be able to tolerate a higher insertion loss to cover < 60km. I also > notice that their CDWM optics averaged about 3db less in power output when > compared to other vendors. > > Thanks > > Kenneth > >> On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom >> wrote: >> > >> Hi kenneth... which the distance do you have from side A to side B when >> you using passive solutions from fiberstore( mux and demux)? >> I buy this mux and demux(4 channels single fiber) and only make a test >> about 60km( mux side A and demux on side B) with sfp+10gb for 80km... ( >> only see ddm on my ex3300( about -19db for 60km). Test switch access with >> ssh and pinging tests... >> What kind os issue do you have? For distances less than 60km is this >> solution good? >> Thanks!!! >> >> Enviado via iPhone  >> Grupo Connectoway >> >>> Em 07/02/2015, às 14:55, Kenneth McRae escreveu: >>> Mike, >>> I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware >>> equipment. The FiberStore gear was a huge disappointment (excessive >>> loss, poor technical support, refusal to issue refund without >>> threatening legal action, etc.). I have had good results from the OSI >>> equipment so far. I run passive muxes for CWDM (8 - 16 channels). >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: >>> Hi Mike >>> I can recommend a couple of vendors that provide cost effective >>> solutions. >>> Ekinops & Packetlight. >>> On Saturday, February 7, 2015, Mike Hammett wrote: >>> I know there are various Asian vendors for low cost (less than $500) >>> muxes >>> to throw 16 or however many colors onto a strand. However, they don't >>> work >>> so well when you don't control the optics used on both sides (therefore >>> must use standard wavelengths), obviously only do a handful of channels >>> and >>> have a distance limitation. >>> What solutions are out there that don't cost an arm and a leg? >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> -- >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: >>> *+52 >>> 656-257-1109* >>> CONFIDENTIALITY NOTICE: This communication is intended only for the use >>> of the individual or entity to which it is addressed and may contain >>> information that is privileged, confidential, and exempt from disclosure >>> under applicable law. If you are not the intended recipient of this >>> information, you are notified that any use, dissemination, distribution, >>> or >>> copying of the communication is strictly prohibited. >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la >>> persona o entidad a la que se dirige y puede contener información >>> privilegiada, confidencial y exenta de divulgación bajo la legislación >>> aplicable. Si no es el destinatario de esta información, se le notifica >>> que >>> cualquier uso, difusión, distribución o copia de la comunicación está >>> estrictamente prohibido. From faisal at snappytelecom.net Sat Feb 7 20:56:29 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 7 Feb 2015 20:56:29 +0000 (GMT) Subject: Low cost WDM gear In-Reply-To: <62dceecf-9668-4cba-bcaa-ae9f2337f974@me.com> References: <62dceecf-9668-4cba-bcaa-ae9f2337f974@me.com> Message-ID: <114973743.1044200.1423342589006.JavaMail.zimbra@snappytelecom.net> More power to you .... I always get a chuckle out of statements such as ... "Compared FiberStore to another Vendor"... It was pointed out to me long time ago.... when someone said.. "My Chevy is better than a Ford".... Someone pointed out, hey, which Chevy ? the Chevette ? or the Corvette ? and Which Ford the Fiesta or Mustang ? Every mfg. has a lots and lots of products, and they are always getting improved... One has to pay attention to the specs.. even the same model products at different times don't have the same specs ! :) 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: "Kenneth McRae" > To: "Faisal Imtiaz" > Cc: "Rodrigo 1telecom" , "NANOG" > Sent: Saturday, February 7, 2015 3:49:16 PM > Subject: Re: Low cost WDM gear > That's why I engage the engineering resources on their end to make sure the > chosen candidate will support the use case. I have now performed an A/B > comparison and the FiberStore gear is inferior. Excessive loss on the mux > and optics. > On Feb 07, 2015, at 12:44 PM, Faisal Imtiaz wrote: > > If you pay close attention to the Spec Sheets, on power output, insertion > > loss, sensitivity, and do the proper calculation for your link, then using > > anyone's products, passive or active will work unless the devices do not > > meet specified specs. > > > If you don't do your homework, cals on the design, loss, and just buy stuff > > based on whatever, then it does not matter who the mfg. is, you are very > > very likely to be surprised in a bad way. > > > :) > > > Faisal Imtiaz > > > Snappy Internet & Telecom > > > ----- Original Message ----- > > > > From: "Rodrigo 1telecom" < rodrigo at 1telecom.com.br > > > > > > > To: "Kenneth McRae" < kenneth.mcrae at me.com > > > > > > > Cc: "NANOG" < nanog at nanog.org > > > > > > > Sent: Saturday, February 7, 2015 3:24:43 PM > > > > > > Subject: Re: Low cost WDM gear > > > > > > What others vendors do you using? Here in Brazil only PADTEC have this > > > > > > passive solution... Some days ago Digitel contact me to show your > > > multiplex > > > > > > solution... Is a active solution... > > > > > > We import this from fiberstore, but i don't know others vendors to buy > > > 10G > > > > > > sfp+ cwdm and this mux/demux... > > > > > > Enviado via iPhone  > > > > > > Grupo Connectoway > > > > > > > Em 07/02/2015, às 16:04, Kenneth McRae < kenneth.mcrae at me.com > > > > > escreveu: > > > > > > > > > > > > > > Hi Enviado, > > > > > > > > > > > > > > I cannot recommend FiberStore as I had a bad experience with them. I > > > > > > > needed to cover only 3km from A to B side. When using 10km optics, I > > > > saw > > > > > > > a loss of over 5db with their passive mux inserted into the path which > > > > > > > created a total loss of over -20db which is outside of the tolerances > > > > for > > > > > > > our equipment with 10km SFP+. Using another vendors low insertion loss > > > > > > > mux corrected our issue. I am sure if you are using an 80km optic, you > > > > > > > may be able to tolerate a higher insertion loss to cover < 60km. I also > > > > > > > notice that their CDWM optics averaged about 3db less in power output > > > > when > > > > > > > compared to other vendors. > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Kenneth > > > > > > > > > > > > > >> On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom < > > > >> rodrigo at 1telecom.com.br > > > >> > > > > > > > >> wrote: > > > > > > >> > > > > > > > > > > > > > >> Hi kenneth... which the distance do you have from side A to side B > > > >> when > > > > > > >> you using passive solutions from fiberstore( mux and demux)? > > > > > > >> I buy this mux and demux(4 channels single fiber) and only make a test > > > > > > >> about 60km( mux side A and demux on side B) with sfp+10gb for 80km... > > > >> ( > > > > > > >> only see ddm on my ex3300( about -19db for 60km). Test switch access > > > >> with > > > > > > >> ssh and pinging tests... > > > > > > >> What kind os issue do you have? For distances less than 60km is this > > > > > > >> solution good? > > > > > > >> Thanks!!! > > > > > > >> > > > > > > >> Enviado via iPhone  > > > > > > >> Grupo Connectoway > > > > > > >> > > > > > > >>> Em 07/02/2015, às 14:55, Kenneth McRae < kenneth.mcrae at me.com > > > > >>> escreveu: > > > > > > >>> Mike, > > > > > > >>> I just replaced a bunch of FiberStore WDM passive muxes with OSI > > > >>> Hardware > > > > > > >>> equipment. The FiberStore gear was a huge disappointment (excessive > > > > > > >>> loss, poor technical support, refusal to issue refund without > > > > > > >>> threatening legal action, etc.). I have had good results from the OSI > > > > > > >>> equipment so far. I run passive muxes for CWDM (8 - 16 channels). > > > > > > >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín < mmg at transtelco.net > > > > >>> wrote: > > > > > > >>> Hi Mike > > > > > > >>> I can recommend a couple of vendors that provide cost effective > > > > > > >>> solutions. > > > > > > >>> Ekinops & Packetlight. > > > > > > >>> On Saturday, February 7, 2015, Mike Hammett < nanog at ics-il.net > > > > >>> wrote: > > > > > > >>> I know there are various Asian vendors for low cost (less than $500) > > > > > > >>> muxes > > > > > > >>> to throw 16 or however many colors onto a strand. However, they don't > > > > > > >>> work > > > > > > >>> so well when you don't control the optics used on both sides > > > >>> (therefore > > > > > > >>> must use standard wavelengths), obviously only do a handful of > > > >>> channels > > > > > > >>> and > > > > > > >>> have a distance limitation. > > > > > > >>> What solutions are out there that don't cost an arm and a leg? > > > > > > >>> ----- > > > > > > >>> Mike Hammett > > > > > > >>> Intelligent Computing Solutions > > > > > > >>> http://www.ics-il.com > > > > > > >>> -- > > > > > > >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | > > > >>> MX: > > > > > > >>> *+52 > > > > > > >>> 656-257-1109* > > > > > > >>> CONFIDENTIALITY NOTICE: This communication is intended only for the > > > >>> use > > > > > > >>> of the individual or entity to which it is addressed and may contain > > > > > > >>> information that is privileged, confidential, and exempt from > > > >>> disclosure > > > > > > >>> under applicable law. If you are not the intended recipient of this > > > > > > >>> information, you are notified that any use, dissemination, > > > >>> distribution, > > > > > > >>> or > > > > > > >>> copying of the communication is strictly prohibited. > > > > > > >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de > > > >>> la > > > > > > >>> persona o entidad a la que se dirige y puede contener información > > > > > > >>> privilegiada, confidencial y exenta de divulgación bajo la > > > >>> legislación > > > > > > >>> aplicable. Si no es el destinatario de esta información, se le > > > >>> notifica > > > > > > >>> que > > > > > > >>> cualquier uso, difusión, distribución o copia de la comunicación está > > > > > > >>> estrictamente prohibido. > > > From kenneth.mcrae at me.com Sat Feb 7 21:01:29 2015 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Sat, 07 Feb 2015 21:01:29 +0000 (GMT) Subject: Low cost WDM gear Message-ID: <260a6f21-a629-4210-88e1-459c842b3f0a@me.com> That's true up to a point.  Specs are only as good as the entity providing the data.  I can tell you a few stories about specs and some MAJOR fails by a major network equipment manufacturer failing to meet advertised specs.  When you engage the engineering folks to assist in a build, they should know the true specs of their gear better than anyone else.  If they say for a certain distance that A+B will work, then that is exactly what I expect. That is pretty basic. On Feb 07, 2015, at 12:56 PM, Faisal Imtiaz wrote: More power to you ....  I always get a chuckle out of statements such as ... "Compared FiberStore to another Vendor"...   It was pointed out to me long time ago.... when someone said.. "My Chevy is better than a Ford".... Someone pointed out, hey, which Chevy ?  the Chevette ? or the Corvette ? and Which Ford the Fiesta or Mustang ? Every mfg. has a lots and lots of products, and they are always getting improved... One has to pay attention to the specs.. even the same model products at different times don't have the same specs ! :) 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 From: "Kenneth McRae" To: "Faisal Imtiaz" Cc: "Rodrigo 1telecom" , "NANOG" Sent: Saturday, February 7, 2015 3:49:16 PM Subject: Re: Low cost WDM gear That's why I engage the engineering resources on their end to make sure the chosen candidate will support the use case.  I have now performed an A/B comparison and the FiberStore gear is inferior.  Excessive loss on the mux and optics.  On Feb 07, 2015, at 12:44 PM, Faisal Imtiaz wrote: If you pay close attention to the Spec Sheets, on power output, insertion loss, sensitivity, and do the proper calculation for your link, then using anyone's products, passive or active will work unless the devices do not meet specified specs. If you don't do your homework, cals on the design, loss, and just buy stuff based on whatever, then it does not matter who the mfg. is, you are very very likely to be surprised in a bad way. :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- From: "Rodrigo 1telecom" To: "Kenneth McRae" Cc: "NANOG" Sent: Saturday, February 7, 2015 3:24:43 PM Subject: Re: Low cost WDM gear What others vendors do you using? Here in Brazil only PADTEC have this passive solution... Some days ago Digitel contact me to show your multiplex solution... Is a active solution... We import this from fiberstore, but i don't know others vendors to buy 10G sfp+ cwdm and this mux/demux... Enviado via iPhone  Grupo Connectoway > Em 07/02/2015, às 16:04, Kenneth McRae escreveu: > > Hi Enviado, > > I cannot recommend FiberStore as I had a bad experience with them. I > needed to cover only 3km from A to B side. When using 10km optics, I saw > a loss of over 5db with their passive mux inserted into the path which > created a total loss of over -20db which is outside of the tolerances for > our equipment with 10km SFP+. Using another vendors low insertion loss > mux corrected our issue. I am sure if you are using an 80km optic, you > may be able to tolerate a higher insertion loss to cover < 60km. I also > notice that their CDWM optics averaged about 3db less in power output when > compared to other vendors. > > Thanks > > Kenneth > >> On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom >> wrote: >> > >> Hi kenneth... which the distance do you have from side A to side B when >> you using passive solutions from fiberstore( mux and demux)? >> I buy this mux and demux(4 channels single fiber) and only make a test >> about 60km( mux side A and demux on side B) with sfp+10gb for 80km... ( >> only see ddm on my ex3300( about -19db for 60km). Test switch access with >> ssh and pinging tests... >> What kind os issue do you have? For distances less than 60km is this >> solution good? >> Thanks!!! >> >> Enviado via iPhone  >> Grupo Connectoway >> >>> Em 07/02/2015, às 14:55, Kenneth McRae escreveu: >>> Mike, >>> I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware >>> equipment. The FiberStore gear was a huge disappointment (excessive >>> loss, poor technical support, refusal to issue refund without >>> threatening legal action, etc.). I have had good results from the OSI >>> equipment so far. I run passive muxes for CWDM (8 - 16 channels). >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: >>> Hi Mike >>> I can recommend a couple of vendors that provide cost effective >>> solutions. >>> Ekinops & Packetlight. >>> On Saturday, February 7, 2015, Mike Hammett wrote: >>> I know there are various Asian vendors for low cost (less than $500) >>> muxes >>> to throw 16 or however many colors onto a strand. However, they don't >>> work >>> so well when you don't control the optics used on both sides (therefore >>> must use standard wavelengths), obviously only do a handful of channels >>> and >>> have a distance limitation. >>> What solutions are out there that don't cost an arm and a leg? >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> -- >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: >>> *+52 >>> 656-257-1109* >>> CONFIDENTIALITY NOTICE: This communication is intended only for the use >>> of the individual or entity to which it is addressed and may contain >>> information that is privileged, confidential, and exempt from disclosure >>> under applicable law. If you are not the intended recipient of this >>> information, you are notified that any use, dissemination, distribution, >>> or >>> copying of the communication is strictly prohibited. >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la >>> persona o entidad a la que se dirige y puede contener información >>> privilegiada, confidencial y exenta de divulgación bajo la legislación >>> aplicable. Si no es el destinatario de esta información, se le notifica >>> que >>> cualquier uso, difusión, distribución o copia de la comunicación está >>> estrictamente prohibido. From simon at slimey.org Sat Feb 7 21:06:46 2015 From: simon at slimey.org (Simon Lockhart) Date: Sat, 7 Feb 2015 21:06:46 +0000 Subject: Low cost WDM gear In-Reply-To: <114973743.1044200.1423342589006.JavaMail.zimbra@snappytelecom.net> References: <62dceecf-9668-4cba-bcaa-ae9f2337f974@me.com> <114973743.1044200.1423342589006.JavaMail.zimbra@snappytelecom.net> Message-ID: <20150207210645.GK25821@virtual.bogons.net> > That's why I engage the engineering resources on their end to make sure the > chosen candidate will support the use case. I have now performed an A/B > comparison and the FiberStore gear is inferior. Excessive loss on the mux > and optics. Just for comparison sake, I should say that we've bought passive DWDM muxes and SFP+'s from FibreStore, and we've had good experiences. At the lower end of the market, production quality can definitely vary, which means significant variances in optical losses. When we ordered from FibreStore, we specified the Optical Loss values that we were able to accept. They tested the muxes before shipping, and selected the ones which fitted our requirements. Out of all the SFP's we bought, there were one or two DoA. FibreStore replaced this without issue. I think the important thing to remember (particularly when buying "cheap") is that you need to know what you're buying, and what the risks are. With this in mind, it's possible to save money and get a decent product with some careful specification and management of the purchasing process. If you're not too sure what you're after, then I'd suggest spending more money and buying from a supplier who's more set up to hand-hold you through the process. Simon From faisal at snappytelecom.net Sat Feb 7 21:17:07 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 7 Feb 2015 21:17:07 +0000 (GMT) Subject: Low cost WDM gear In-Reply-To: <260a6f21-a629-4210-88e1-459c842b3f0a@me.com> References: <260a6f21-a629-4210-88e1-459c842b3f0a@me.com> Message-ID: <124688083.1045039.1423343827808.JavaMail.zimbra@snappytelecom.net> My point is...... ... The thing to rely on is/are the Specs. If the Specs are right or specs are wrong, that is what determines the product's mfg shortcoming (defect). Mfg. Engineers are people, just like you and me.... and people can make mistakes... Being an Engineer, when I ask someone to do the design work, I ask them to explain it, and this way I double check their work.... Yes Mfg. Engineers are known to F***up too. While it is expected to be disappointed when something does not work.. and having a bad taste for dealing with that mfg, claiming that all of that mfg products are bad is a whole different issue. I deal with FiberStore, my experience have been very different, when stuff purchased from them, did not meet the specs, they took it back no questions asked. 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: "Kenneth McRae" > To: "Faisal Imtiaz" > Cc: "Rodrigo 1telecom" , "NANOG" > Sent: Saturday, February 7, 2015 4:01:29 PM > Subject: Re: Low cost WDM gear > That's true up to a point. Specs are only as good as the entity providing the > data. I can tell you a few stories about specs and some MAJOR fails by a > major network equipment manufacturer failing to meet advertised specs. When > you engage the engineering folks to assist in a build, they should know the > true specs of their gear better than anyone else. If they say for a certain > distance that A+B will work, then that is exactly what I expect. > That is pretty basic. > On Feb 07, 2015, at 12:56 PM, Faisal Imtiaz wrote: > > More power to you .... > > > I always get a chuckle out of statements such as ... "Compared FiberStore > > to > > another Vendor"... > > > It was pointed out to me long time ago.... when someone said.. "My Chevy is > > better than a Ford".... > > > Someone pointed out, hey, which Chevy ? the Chevette ? or the Corvette ? > > and > > Which Ford the Fiesta or Mustang ? > > > Every mfg. has a lots and lots of products, and they are always getting > > improved... > > > One has to pay attention to the specs.. even the same model products at > > different times don't have the same specs ! > > > :) > > > 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: "Kenneth McRae" > > > > > > To: "Faisal Imtiaz" > > > > > > Cc: "Rodrigo 1telecom" , "NANOG" > > > > > > > > > Sent: Saturday, February 7, 2015 3:49:16 PM > > > > > > Subject: Re: Low cost WDM gear > > > > > > That's why I engage the engineering resources on their end to make sure > > > the > > > chosen candidate will support the use case. I have now performed an A/B > > > comparison and the FiberStore gear is inferior. Excessive loss on the mux > > > and optics. > > > > > > On Feb 07, 2015, at 12:44 PM, Faisal Imtiaz > > > wrote: > > > > > > > If you pay close attention to the Spec Sheets, on power output, > > > > insertion > > > > loss, sensitivity, and do the proper calculation for your link, then > > > > using > > > > anyone's products, passive or active will work unless the devices do > > > > not > > > > meet specified specs. > > > > > > > > > > If you don't do your homework, cals on the design, loss, and just buy > > > > stuff > > > > based on whatever, then it does not matter who the mfg. is, you are > > > > very > > > > very likely to be surprised in a bad way. > > > > > > > > > > :) > > > > > > > > > > Faisal Imtiaz > > > > > > > > > > Snappy Internet & Telecom > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Rodrigo 1telecom" < rodrigo at 1telecom.com.br > > > > > > > > > > > > > > > > To: "Kenneth McRae" < kenneth.mcrae at me.com > > > > > > > > > > > > > > > > Cc: "NANOG" < nanog at nanog.org > > > > > > > > > > > > > > > > Sent: Saturday, February 7, 2015 3:24:43 PM > > > > > > > > > > > > > > > Subject: Re: Low cost WDM gear > > > > > > > > > > > > > > > What others vendors do you using? Here in Brazil only PADTEC have > > > > > this > > > > > > > > > > > > > > > passive solution... Some days ago Digitel contact me to show your > > > > > multiplex > > > > > > > > > > > > > > > solution... Is a active solution... > > > > > > > > > > > > > > > We import this from fiberstore, but i don't know others vendors to > > > > > buy > > > > > 10G > > > > > > > > > > > > > > > sfp+ cwdm and this mux/demux... > > > > > > > > > > > > > > > Enviado via iPhone  > > > > > > > > > > > > > > > Grupo Connectoway > > > > > > > > > > > > > > > > Em 07/02/2015, às 16:04, Kenneth McRae < kenneth.mcrae at me.com > > > > > > > escreveu: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Enviado, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I cannot recommend FiberStore as I had a bad experience with them. > > > > > > I > > > > > > > > > > > > > > > > needed to cover only 3km from A to B side. When using 10km optics, > > > > > > I > > > > > > saw > > > > > > > > > > > > > > > > a loss of over 5db with their passive mux inserted into the path > > > > > > which > > > > > > > > > > > > > > > > created a total loss of over -20db which is outside of the > > > > > > tolerances > > > > > > for > > > > > > > > > > > > > > > > our equipment with 10km SFP+. Using another vendors low insertion > > > > > > loss > > > > > > > > > > > > > > > > mux corrected our issue. I am sure if you are using an 80km optic, > > > > > > you > > > > > > > > > > > > > > > > may be able to tolerate a higher insertion loss to cover < 60km. I > > > > > > also > > > > > > > > > > > > > > > > notice that their CDWM optics averaged about 3db less in power > > > > > > output > > > > > > when > > > > > > > > > > > > > > > > compared to other vendors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kenneth > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom < > > > > > >> rodrigo at 1telecom.com.br > > > > > >> > > > > > > > > > > > > > > > > >> wrote: > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> Hi kenneth... which the distance do you have from side A to side B > > > > > >> when > > > > > > > > > > > > > > > >> you using passive solutions from fiberstore( mux and demux)? > > > > > > > > > > > > > > > >> I buy this mux and demux(4 channels single fiber) and only make a > > > > > >> test > > > > > > > > > > > > > > > >> about 60km( mux side A and demux on side B) with sfp+10gb for > > > > > >> 80km... > > > > > >> ( > > > > > > > > > > > > > > > >> only see ddm on my ex3300( about -19db for 60km). Test switch > > > > > >> access > > > > > >> with > > > > > > > > > > > > > > > >> ssh and pinging tests... > > > > > > > > > > > > > > > >> What kind os issue do you have? For distances less than 60km is > > > > > >> this > > > > > > > > > > > > > > > >> solution good? > > > > > > > > > > > > > > > >> Thanks!!! > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> Enviado via iPhone  > > > > > > > > > > > > > > > >> Grupo Connectoway > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >>> Em 07/02/2015, às 14:55, Kenneth McRae < kenneth.mcrae at me.com > > > > > > >>> escreveu: > > > > > > > > > > > > > > > >>> Mike, > > > > > > > > > > > > > > > >>> I just replaced a bunch of FiberStore WDM passive muxes with OSI > > > > > >>> Hardware > > > > > > > > > > > > > > > >>> equipment. The FiberStore gear was a huge disappointment > > > > > >>> (excessive > > > > > > > > > > > > > > > >>> loss, poor technical support, refusal to issue refund without > > > > > > > > > > > > > > > >>> threatening legal action, etc.). I have had good results from the > > > > > >>> OSI > > > > > > > > > > > > > > > >>> equipment so far. I run passive muxes for CWDM (8 - 16 channels). > > > > > > > > > > > > > > > >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín < mmg at transtelco.net > > > > > > >>> wrote: > > > > > > > > > > > > > > > >>> Hi Mike > > > > > > > > > > > > > > > >>> I can recommend a couple of vendors that provide cost effective > > > > > > > > > > > > > > > >>> solutions. > > > > > > > > > > > > > > > >>> Ekinops & Packetlight. > > > > > > > > > > > > > > > >>> On Saturday, February 7, 2015, Mike Hammett < nanog at ics-il.net > > > > > > >>> wrote: > > > > > > > > > > > > > > > >>> I know there are various Asian vendors for low cost (less than > > > > > >>> $500) > > > > > > > > > > > > > > > >>> muxes > > > > > > > > > > > > > > > >>> to throw 16 or however many colors onto a strand. However, they > > > > > >>> don't > > > > > > > > > > > > > > > >>> work > > > > > > > > > > > > > > > >>> so well when you don't control the optics used on both sides > > > > > >>> (therefore > > > > > > > > > > > > > > > >>> must use standard wavelengths), obviously only do a handful of > > > > > >>> channels > > > > > > > > > > > > > > > >>> and > > > > > > > > > > > > > > > >>> have a distance limitation. > > > > > > > > > > > > > > > >>> What solutions are out there that don't cost an arm and a leg? > > > > > > > > > > > > > > > >>> ----- > > > > > > > > > > > > > > > >>> Mike Hammett > > > > > > > > > > > > > > > >>> Intelligent Computing Solutions > > > > > > > > > > > > > > > >>> http://www.ics-il.com > > > > > > > > > > > > > > > >>> -- > > > > > > > > > > > > > > > >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* > > > > > >>> | > > > > > >>> MX: > > > > > > > > > > > > > > > >>> *+52 > > > > > > > > > > > > > > > >>> 656-257-1109* > > > > > > > > > > > > > > > >>> CONFIDENTIALITY NOTICE: This communication is intended only for > > > > > >>> the > > > > > >>> use > > > > > > > > > > > > > > > >>> of the individual or entity to which it is addressed and may > > > > > >>> contain > > > > > > > > > > > > > > > >>> information that is privileged, confidential, and exempt from > > > > > >>> disclosure > > > > > > > > > > > > > > > >>> under applicable law. If you are not the intended recipient of > > > > > >>> this > > > > > > > > > > > > > > > >>> information, you are notified that any use, dissemination, > > > > > >>> distribution, > > > > > > > > > > > > > > > >>> or > > > > > > > > > > > > > > > >>> copying of the communication is strictly prohibited. > > > > > > > > > > > > > > > >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso > > > > > >>> de > > > > > >>> la > > > > > > > > > > > > > > > >>> persona o entidad a la que se dirige y puede contener información > > > > > > > > > > > > > > > >>> privilegiada, confidencial y exenta de divulgación bajo la > > > > > >>> legislación > > > > > > > > > > > > > > > >>> aplicable. Si no es el destinatario de esta información, se le > > > > > >>> notifica > > > > > > > > > > > > > > > >>> que > > > > > > > > > > > > > > > >>> cualquier uso, difusión, distribución o copia de la comunicación > > > > > >>> está > > > > > > > > > > > > > > > >>> estrictamente prohibido. > > > > > > > > > > From faisal at snappytelecom.net Sat Feb 7 21:22:57 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 7 Feb 2015 21:22:57 +0000 (GMT) Subject: Low cost WDM gear In-Reply-To: <20150207210645.GK25821@virtual.bogons.net> References: <62dceecf-9668-4cba-bcaa-ae9f2337f974@me.com> <114973743.1044200.1423342589006.JavaMail.zimbra@snappytelecom.net> <20150207210645.GK25821@virtual.bogons.net> Message-ID: <2026486532.1045066.1423344177088.JavaMail.zimbra@snappytelecom.net> Agreed, and to add one more little point.. Now they have DWDM & CWDM Muxes which have an even lower insertion loss .. (new products, currently not listed on the website). .... Like they say.... "This is not your Father's Oldsmobile"... Nothing hardly stands stills or remains the same in this business... :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Simon Lockhart" > To: "NANOG" > Sent: Saturday, February 7, 2015 4:06:46 PM > Subject: Re: Low cost WDM gear > > > That's why I engage the engineering resources on their end to make sure the > > chosen candidate will support the use case. I have now performed an A/B > > comparison and the FiberStore gear is inferior. Excessive loss on the mux > > and optics. > > Just for comparison sake, I should say that we've bought passive DWDM muxes > and > SFP+'s from FibreStore, and we've had good experiences. > > At the lower end of the market, production quality can definitely vary, which > means significant variances in optical losses. When we ordered from > FibreStore, > we specified the Optical Loss values that we were able to accept. They tested > the muxes before shipping, and selected the ones which fitted our > requirements. > > Out of all the SFP's we bought, there were one or two DoA. FibreStore > replaced > this without issue. > > I think the important thing to remember (particularly when buying "cheap") is > that you need to know what you're buying, and what the risks are. With this > in > mind, it's possible to save money and get a decent product with some careful > specification and management of the purchasing process. > > If you're not too sure what you're after, then I'd suggest spending more > money > and buying from a supplier who's more set up to hand-hold you through the > process. > > Simon > From kenneth.mcrae at me.com Sat Feb 7 21:24:18 2015 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Sat, 07 Feb 2015 21:24:18 +0000 (GMT) Subject: Low cost WDM gear Message-ID: <12540dbc-1940-47b8-aa41-d7dd1d05dda6@me.com> Point taken on the specs..  Still doesn't excuse poor customer service and tech support.  I never expect to be told that no refund will be issued when I am dissatisfied with the product.   A request for RMA because something is not working as expected should not have to be escalated to the President of the company.  Other than that I am sure FiberStore is a great company :-) On Feb 07, 2015, at 01:17 PM, Faisal Imtiaz wrote: My point is......     ... The thing to rely on is/are the Specs.             If the Specs are right or specs are wrong, that is what determines the product's mfg shortcoming (defect).     Mfg. Engineers are people, just like you and me.... and people can make mistakes...      Being an Engineer, when I ask someone to do the design work, I ask them to explain it, and this way I double check their work.... Yes Mfg. Engineers are known to  F***up too. While it is expected to be disappointed when something does not work.. and having a bad taste for dealing with that mfg, claiming that all of that mfg products are bad is a whole different issue. I deal with FiberStore, my experience have been very different, when stuff purchased from them, did not meet the specs, they took it back no questions asked. 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 From: "Kenneth McRae" To: "Faisal Imtiaz" Cc: "Rodrigo 1telecom" , "NANOG" Sent: Saturday, February 7, 2015 4:01:29 PM Subject: Re: Low cost WDM gear That's true up to a point.  Specs are only as good as the entity providing the data.  I can tell you a few stories about specs and some MAJOR fails by a major network equipment manufacturer failing to meet advertised specs.  When you engage the engineering folks to assist in a build, they should know the true specs of their gear better than anyone else.  If they say for a certain distance that A+B will work, then that is exactly what I expect. That is pretty basic. On Feb 07, 2015, at 12:56 PM, Faisal Imtiaz wrote: More power to you ....  I always get a chuckle out of statements such as ... "Compared FiberStore to another Vendor"...   It was pointed out to me long time ago.... when someone said.. "My Chevy is better than a Ford".... Someone pointed out, hey, which Chevy ?  the Chevette ? or the Corvette ? and Which Ford the Fiesta or Mustang ? Every mfg. has a lots and lots of products, and they are always getting improved... One has to pay attention to the specs.. even the same model products at different times don't have the same specs ! :) 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 From: "Kenneth McRae" To: "Faisal Imtiaz" Cc: "Rodrigo 1telecom" , "NANOG" Sent: Saturday, February 7, 2015 3:49:16 PM Subject: Re: Low cost WDM gear That's why I engage the engineering resources on their end to make sure the chosen candidate will support the use case.  I have now performed an A/B comparison and the FiberStore gear is inferior.  Excessive loss on the mux and optics.  On Feb 07, 2015, at 12:44 PM, Faisal Imtiaz wrote: If you pay close attention to the Spec Sheets, on power output, insertion loss, sensitivity, and do the proper calculation for your link, then using anyone's products, passive or active will work unless the devices do not meet specified specs. If you don't do your homework, cals on the design, loss, and just buy stuff based on whatever, then it does not matter who the mfg. is, you are very very likely to be surprised in a bad way. :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- From: "Rodrigo 1telecom" To: "Kenneth McRae" Cc: "NANOG" Sent: Saturday, February 7, 2015 3:24:43 PM Subject: Re: Low cost WDM gear What others vendors do you using? Here in Brazil only PADTEC have this passive solution... Some days ago Digitel contact me to show your multiplex solution... Is a active solution... We import this from fiberstore, but i don't know others vendors to buy 10G sfp+ cwdm and this mux/demux... Enviado via iPhone  Grupo Connectoway > Em 07/02/2015, às 16:04, Kenneth McRae escreveu: > > Hi Enviado, > > I cannot recommend FiberStore as I had a bad experience with them. I > needed to cover only 3km from A to B side. When using 10km optics, I saw > a loss of over 5db with their passive mux inserted into the path which > created a total loss of over -20db which is outside of the tolerances for > our equipment with 10km SFP+. Using another vendors low insertion loss > mux corrected our issue. I am sure if you are using an 80km optic, you > may be able to tolerate a higher insertion loss to cover < 60km. I also > notice that their CDWM optics averaged about 3db less in power output when > compared to other vendors. > > Thanks > > Kenneth > >> On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom >> wrote: >> > >> Hi kenneth... which the distance do you have from side A to side B when >> you using passive solutions from fiberstore( mux and demux)? >> I buy this mux and demux(4 channels single fiber) and only make a test >> about 60km( mux side A and demux on side B) with sfp+10gb for 80km... ( >> only see ddm on my ex3300( about -19db for 60km). Test switch access with >> ssh and pinging tests... >> What kind os issue do you have? For distances less than 60km is this >> solution good? >> Thanks!!! >> >> Enviado via iPhone  >> Grupo Connectoway >> >>> Em 07/02/2015, às 14:55, Kenneth McRae escreveu: >>> Mike, >>> I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware >>> equipment. The FiberStore gear was a huge disappointment (excessive >>> loss, poor technical support, refusal to issue refund without >>> threatening legal action, etc.). I have had good results from the OSI >>> equipment so far. I run passive muxes for CWDM (8 - 16 channels). >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: >>> Hi Mike >>> I can recommend a couple of vendors that provide cost effective >>> solutions. >>> Ekinops & Packetlight. >>> On Saturday, February 7, 2015, Mike Hammett wrote: >>> I know there are various Asian vendors for low cost (less than $500) >>> muxes >>> to throw 16 or however many colors onto a strand. However, they don't >>> work >>> so well when you don't control the optics used on both sides (therefore >>> must use standard wavelengths), obviously only do a handful of channels >>> and >>> have a distance limitation. >>> What solutions are out there that don't cost an arm and a leg? >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> -- >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: >>> *+52 >>> 656-257-1109* >>> CONFIDENTIALITY NOTICE: This communication is intended only for the use >>> of the individual or entity to which it is addressed and may contain >>> information that is privileged, confidential, and exempt from disclosure >>> under applicable law. If you are not the intended recipient of this >>> information, you are notified that any use, dissemination, distribution, >>> or >>> copying of the communication is strictly prohibited. >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la >>> persona o entidad a la que se dirige y puede contener información >>> privilegiada, confidencial y exenta de divulgación bajo la legislación >>> aplicable. Si no es el destinatario de esta información, se le notifica >>> que >>> cualquier uso, difusión, distribución o copia de la comunicación está >>> estrictamente prohibido. From faisal at snappytelecom.net Sat Feb 7 21:25:57 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 7 Feb 2015 21:25:57 +0000 (GMT) Subject: Low cost WDM gear In-Reply-To: <260a6f21-a629-4210-88e1-459c842b3f0a@me.com> References: <260a6f21-a629-4210-88e1-459c842b3f0a@me.com> Message-ID: <1337068328.1045206.1423344357351.JavaMail.zimbra@snappytelecom.net> BTW, I hope you realize that FiberStore is not a mfg. but a "Seller/broker". they have to rely on the specs provided to them from the MFG. In the Far East, mfg, distribution, sales is organized is a slightly different manner than the West. :) 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: "Kenneth McRae" > To: "Faisal Imtiaz" > Cc: "Rodrigo 1telecom" , "NANOG" > Sent: Saturday, February 7, 2015 4:01:29 PM > Subject: Re: Low cost WDM gear > That's true up to a point. Specs are only as good as the entity providing the > data. I can tell you a few stories about specs and some MAJOR fails by a > major network equipment manufacturer failing to meet advertised specs. When > you engage the engineering folks to assist in a build, they should know the > true specs of their gear better than anyone else. If they say for a certain > distance that A+B will work, then that is exactly what I expect. > That is pretty basic. > On Feb 07, 2015, at 12:56 PM, Faisal Imtiaz wrote: > > More power to you .... > > > I always get a chuckle out of statements such as ... "Compared FiberStore > > to > > another Vendor"... > > > It was pointed out to me long time ago.... when someone said.. "My Chevy is > > better than a Ford".... > > > Someone pointed out, hey, which Chevy ? the Chevette ? or the Corvette ? > > and > > Which Ford the Fiesta or Mustang ? > > > Every mfg. has a lots and lots of products, and they are always getting > > improved... > > > One has to pay attention to the specs.. even the same model products at > > different times don't have the same specs ! > > > :) > > > 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: "Kenneth McRae" > > > > > > To: "Faisal Imtiaz" > > > > > > Cc: "Rodrigo 1telecom" , "NANOG" > > > > > > > > > Sent: Saturday, February 7, 2015 3:49:16 PM > > > > > > Subject: Re: Low cost WDM gear > > > > > > That's why I engage the engineering resources on their end to make sure > > > the > > > chosen candidate will support the use case. I have now performed an A/B > > > comparison and the FiberStore gear is inferior. Excessive loss on the mux > > > and optics. > > > > > > On Feb 07, 2015, at 12:44 PM, Faisal Imtiaz > > > wrote: > > > > > > > If you pay close attention to the Spec Sheets, on power output, > > > > insertion > > > > loss, sensitivity, and do the proper calculation for your link, then > > > > using > > > > anyone's products, passive or active will work unless the devices do > > > > not > > > > meet specified specs. > > > > > > > > > > If you don't do your homework, cals on the design, loss, and just buy > > > > stuff > > > > based on whatever, then it does not matter who the mfg. is, you are > > > > very > > > > very likely to be surprised in a bad way. > > > > > > > > > > :) > > > > > > > > > > Faisal Imtiaz > > > > > > > > > > Snappy Internet & Telecom > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Rodrigo 1telecom" < rodrigo at 1telecom.com.br > > > > > > > > > > > > > > > > To: "Kenneth McRae" < kenneth.mcrae at me.com > > > > > > > > > > > > > > > > Cc: "NANOG" < nanog at nanog.org > > > > > > > > > > > > > > > > Sent: Saturday, February 7, 2015 3:24:43 PM > > > > > > > > > > > > > > > Subject: Re: Low cost WDM gear > > > > > > > > > > > > > > > What others vendors do you using? Here in Brazil only PADTEC have > > > > > this > > > > > > > > > > > > > > > passive solution... Some days ago Digitel contact me to show your > > > > > multiplex > > > > > > > > > > > > > > > solution... Is a active solution... > > > > > > > > > > > > > > > We import this from fiberstore, but i don't know others vendors to > > > > > buy > > > > > 10G > > > > > > > > > > > > > > > sfp+ cwdm and this mux/demux... > > > > > > > > > > > > > > > Enviado via iPhone  > > > > > > > > > > > > > > > Grupo Connectoway > > > > > > > > > > > > > > > > Em 07/02/2015, às 16:04, Kenneth McRae < kenneth.mcrae at me.com > > > > > > > escreveu: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Enviado, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I cannot recommend FiberStore as I had a bad experience with them. > > > > > > I > > > > > > > > > > > > > > > > needed to cover only 3km from A to B side. When using 10km optics, > > > > > > I > > > > > > saw > > > > > > > > > > > > > > > > a loss of over 5db with their passive mux inserted into the path > > > > > > which > > > > > > > > > > > > > > > > created a total loss of over -20db which is outside of the > > > > > > tolerances > > > > > > for > > > > > > > > > > > > > > > > our equipment with 10km SFP+. Using another vendors low insertion > > > > > > loss > > > > > > > > > > > > > > > > mux corrected our issue. I am sure if you are using an 80km optic, > > > > > > you > > > > > > > > > > > > > > > > may be able to tolerate a higher insertion loss to cover < 60km. I > > > > > > also > > > > > > > > > > > > > > > > notice that their CDWM optics averaged about 3db less in power > > > > > > output > > > > > > when > > > > > > > > > > > > > > > > compared to other vendors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kenneth > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom < > > > > > >> rodrigo at 1telecom.com.br > > > > > >> > > > > > > > > > > > > > > > > >> wrote: > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> Hi kenneth... which the distance do you have from side A to side B > > > > > >> when > > > > > > > > > > > > > > > >> you using passive solutions from fiberstore( mux and demux)? > > > > > > > > > > > > > > > >> I buy this mux and demux(4 channels single fiber) and only make a > > > > > >> test > > > > > > > > > > > > > > > >> about 60km( mux side A and demux on side B) with sfp+10gb for > > > > > >> 80km... > > > > > >> ( > > > > > > > > > > > > > > > >> only see ddm on my ex3300( about -19db for 60km). Test switch > > > > > >> access > > > > > >> with > > > > > > > > > > > > > > > >> ssh and pinging tests... > > > > > > > > > > > > > > > >> What kind os issue do you have? For distances less than 60km is > > > > > >> this > > > > > > > > > > > > > > > >> solution good? > > > > > > > > > > > > > > > >> Thanks!!! > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> Enviado via iPhone  > > > > > > > > > > > > > > > >> Grupo Connectoway > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >>> Em 07/02/2015, às 14:55, Kenneth McRae < kenneth.mcrae at me.com > > > > > > >>> escreveu: > > > > > > > > > > > > > > > >>> Mike, > > > > > > > > > > > > > > > >>> I just replaced a bunch of FiberStore WDM passive muxes with OSI > > > > > >>> Hardware > > > > > > > > > > > > > > > >>> equipment. The FiberStore gear was a huge disappointment > > > > > >>> (excessive > > > > > > > > > > > > > > > >>> loss, poor technical support, refusal to issue refund without > > > > > > > > > > > > > > > >>> threatening legal action, etc.). I have had good results from the > > > > > >>> OSI > > > > > > > > > > > > > > > >>> equipment so far. I run passive muxes for CWDM (8 - 16 channels). > > > > > > > > > > > > > > > >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín < mmg at transtelco.net > > > > > > >>> wrote: > > > > > > > > > > > > > > > >>> Hi Mike > > > > > > > > > > > > > > > >>> I can recommend a couple of vendors that provide cost effective > > > > > > > > > > > > > > > >>> solutions. > > > > > > > > > > > > > > > >>> Ekinops & Packetlight. > > > > > > > > > > > > > > > >>> On Saturday, February 7, 2015, Mike Hammett < nanog at ics-il.net > > > > > > >>> wrote: > > > > > > > > > > > > > > > >>> I know there are various Asian vendors for low cost (less than > > > > > >>> $500) > > > > > > > > > > > > > > > >>> muxes > > > > > > > > > > > > > > > >>> to throw 16 or however many colors onto a strand. However, they > > > > > >>> don't > > > > > > > > > > > > > > > >>> work > > > > > > > > > > > > > > > >>> so well when you don't control the optics used on both sides > > > > > >>> (therefore > > > > > > > > > > > > > > > >>> must use standard wavelengths), obviously only do a handful of > > > > > >>> channels > > > > > > > > > > > > > > > >>> and > > > > > > > > > > > > > > > >>> have a distance limitation. > > > > > > > > > > > > > > > >>> What solutions are out there that don't cost an arm and a leg? > > > > > > > > > > > > > > > >>> ----- > > > > > > > > > > > > > > > >>> Mike Hammett > > > > > > > > > > > > > > > >>> Intelligent Computing Solutions > > > > > > > > > > > > > > > >>> http://www.ics-il.com > > > > > > > > > > > > > > > >>> -- > > > > > > > > > > > > > > > >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* > > > > > >>> | > > > > > >>> MX: > > > > > > > > > > > > > > > >>> *+52 > > > > > > > > > > > > > > > >>> 656-257-1109* > > > > > > > > > > > > > > > >>> CONFIDENTIALITY NOTICE: This communication is intended only for > > > > > >>> the > > > > > >>> use > > > > > > > > > > > > > > > >>> of the individual or entity to which it is addressed and may > > > > > >>> contain > > > > > > > > > > > > > > > >>> information that is privileged, confidential, and exempt from > > > > > >>> disclosure > > > > > > > > > > > > > > > >>> under applicable law. If you are not the intended recipient of > > > > > >>> this > > > > > > > > > > > > > > > >>> information, you are notified that any use, dissemination, > > > > > >>> distribution, > > > > > > > > > > > > > > > >>> or > > > > > > > > > > > > > > > >>> copying of the communication is strictly prohibited. > > > > > > > > > > > > > > > >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso > > > > > >>> de > > > > > >>> la > > > > > > > > > > > > > > > >>> persona o entidad a la que se dirige y puede contener información > > > > > > > > > > > > > > > >>> privilegiada, confidencial y exenta de divulgación bajo la > > > > > >>> legislación > > > > > > > > > > > > > > > >>> aplicable. Si no es el destinatario de esta información, se le > > > > > >>> notifica > > > > > > > > > > > > > > > >>> que > > > > > > > > > > > > > > > >>> cualquier uso, difusión, distribución o copia de la comunicación > > > > > >>> está > > > > > > > > > > > > > > > >>> estrictamente prohibido. > > > > > > > > > > From faisal at snappytelecom.net Sat Feb 7 21:27:53 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 7 Feb 2015 21:27:53 +0000 (GMT) Subject: Low cost WDM gear In-Reply-To: <12540dbc-1940-47b8-aa41-d7dd1d05dda6@me.com> References: <12540dbc-1940-47b8-aa41-d7dd1d05dda6@me.com> Message-ID: <171479625.1045226.1423344473602.JavaMail.zimbra@snappytelecom.net> Maybe, your experience was the pivotal event that became a turning point in their customer service attitudes... :) 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: "Kenneth McRae" > To: "Faisal Imtiaz" > Cc: "Rodrigo 1telecom" , "NANOG" > Sent: Saturday, February 7, 2015 4:24:18 PM > Subject: Re: Low cost WDM gear > Point taken on the specs.. Still doesn't excuse poor customer service and > tech support. I never expect to be told that no refund will be issued when I > am dissatisfied with the product. A request for RMA because something is not > working as expected should not have to be escalated to the President of the > company. > Other than that I am sure FiberStore is a great company :-) > On Feb 07, 2015, at 01:17 PM, Faisal Imtiaz wrote: > > My point is...... > > > ... The thing to rely on is/are the Specs. > > > If the Specs are right or specs are wrong, that is what determines the > > product's mfg shortcoming (defect). > > > Mfg. Engineers are people, just like you and me.... and people can make > > mistakes... > > > Being an Engineer, when I ask someone to do the design work, I ask them to > > explain it, and this way I double check their work.... Yes Mfg. Engineers > > are known to F***up too. > > > While it is expected to be disappointed when something does not work.. and > > having a bad taste for dealing with that mfg, claiming that all of that mfg > > products are bad is a whole different issue. > > > I deal with FiberStore, my experience have been very different, when stuff > > purchased from them, did not meet the specs, they took it back no questions > > asked. > > > 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: "Kenneth McRae" > > > > > > To: "Faisal Imtiaz" > > > > > > Cc: "Rodrigo 1telecom" , "NANOG" > > > > > > > > > Sent: Saturday, February 7, 2015 4:01:29 PM > > > > > > Subject: Re: Low cost WDM gear > > > > > > That's true up to a point. Specs are only as good as the entity providing > > > the > > > data. I can tell you a few stories about specs and some MAJOR fails by a > > > major network equipment manufacturer failing to meet advertised specs. > > > When > > > you engage the engineering folks to assist in a build, they should know > > > the > > > true specs of their gear better than anyone else. If they say for a > > > certain > > > distance that A+B will work, then that is exactly what I expect. > > > > > > That is pretty basic. > > > > > > On Feb 07, 2015, at 12:56 PM, Faisal Imtiaz > > > wrote: > > > > > > > More power to you .... > > > > > > > > > > I always get a chuckle out of statements such as ... "Compared > > > > FiberStore > > > > to > > > > another Vendor"... > > > > > > > > > > It was pointed out to me long time ago.... when someone said.. "My > > > > Chevy > > > > is > > > > better than a Ford".... > > > > > > > > > > Someone pointed out, hey, which Chevy ? the Chevette ? or the Corvette > > > > ? > > > > and > > > > Which Ford the Fiesta or Mustang ? > > > > > > > > > > Every mfg. has a lots and lots of products, and they are always getting > > > > improved... > > > > > > > > > > One has to pay attention to the specs.. even the same model products at > > > > different times don't have the same specs ! > > > > > > > > > > :) > > > > > > > > > > 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: "Kenneth McRae" > > > > > > > > > > > > > > > To: "Faisal Imtiaz" > > > > > > > > > > > > > > > Cc: "Rodrigo 1telecom" , "NANOG" > > > > > > > > > > > > > > > > > > > > Sent: Saturday, February 7, 2015 3:49:16 PM > > > > > > > > > > > > > > > Subject: Re: Low cost WDM gear > > > > > > > > > > > > > > > That's why I engage the engineering resources on their end to make > > > > > sure > > > > > the > > > > > chosen candidate will support the use case. I have now performed an > > > > > A/B > > > > > comparison and the FiberStore gear is inferior. Excessive loss on the > > > > > mux > > > > > and optics. > > > > > > > > > > > > > > > On Feb 07, 2015, at 12:44 PM, Faisal Imtiaz > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > If you pay close attention to the Spec Sheets, on power output, > > > > > > insertion > > > > > > loss, sensitivity, and do the proper calculation for your link, > > > > > > then > > > > > > using > > > > > > anyone's products, passive or active will work unless the devices > > > > > > do > > > > > > not > > > > > > meet specified specs. > > > > > > > > > > > > > > > > > > > > > If you don't do your homework, cals on the design, loss, and just > > > > > > buy > > > > > > stuff > > > > > > based on whatever, then it does not matter who the mfg. is, you are > > > > > > very > > > > > > very likely to be surprised in a bad way. > > > > > > > > > > > > > > > > > > > > > :) > > > > > > > > > > > > > > > > > > > > > Faisal Imtiaz > > > > > > > > > > > > > > > > > > > > > Snappy Internet & Telecom > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > > > > > From: "Rodrigo 1telecom" < rodrigo at 1telecom.com.br > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: "Kenneth McRae" < kenneth.mcrae at me.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: "NANOG" < nanog at nanog.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: Saturday, February 7, 2015 3:24:43 PM > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: Low cost WDM gear > > > > > > > > > > > > > > > > > > > > > > > > > > > > What others vendors do you using? Here in Brazil only PADTEC have > > > > > > > this > > > > > > > > > > > > > > > > > > > > > > > > > > > > passive solution... Some days ago Digitel contact me to show your > > > > > > > multiplex > > > > > > > > > > > > > > > > > > > > > > > > > > > > solution... Is a active solution... > > > > > > > > > > > > > > > > > > > > > > > > > > > > We import this from fiberstore, but i don't know others vendors > > > > > > > to > > > > > > > buy > > > > > > > 10G > > > > > > > > > > > > > > > > > > > > > > > > > > > > sfp+ cwdm and this mux/demux... > > > > > > > > > > > > > > > > > > > > > > > > > > > > Enviado via iPhone  > > > > > > > > > > > > > > > > > > > > > > > > > > > > Grupo Connectoway > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Em 07/02/2015, às 16:04, Kenneth McRae < kenneth.mcrae at me.com > > > > > > > > > escreveu: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Enviado, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I cannot recommend FiberStore as I had a bad experience with > > > > > > > > them. > > > > > > > > I > > > > > > > > > > > > > > > > > > > > > > > > > > > > > needed to cover only 3km from A to B side. When using 10km > > > > > > > > optics, > > > > > > > > I > > > > > > > > saw > > > > > > > > > > > > > > > > > > > > > > > > > > > > > a loss of over 5db with their passive mux inserted into the > > > > > > > > path > > > > > > > > which > > > > > > > > > > > > > > > > > > > > > > > > > > > > > created a total loss of over -20db which is outside of the > > > > > > > > tolerances > > > > > > > > for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > our equipment with 10km SFP+. Using another vendors low > > > > > > > > insertion > > > > > > > > loss > > > > > > > > > > > > > > > > > > > > > > > > > > > > > mux corrected our issue. I am sure if you are using an 80km > > > > > > > > optic, > > > > > > > > you > > > > > > > > > > > > > > > > > > > > > > > > > > > > > may be able to tolerate a higher insertion loss to cover < > > > > > > > > 60km. > > > > > > > > I > > > > > > > > also > > > > > > > > > > > > > > > > > > > > > > > > > > > > > notice that their CDWM optics averaged about 3db less in power > > > > > > > > output > > > > > > > > when > > > > > > > > > > > > > > > > > > > > > > > > > > > > > compared to other vendors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kenneth > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom < > > > > > > > >> rodrigo at 1telecom.com.br > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> Hi kenneth... which the distance do you have from side A to > > > > > > > >> side > > > > > > > >> B > > > > > > > >> when > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> you using passive solutions from fiberstore( mux and demux)? > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> I buy this mux and demux(4 channels single fiber) and only > > > > > > > >> make > > > > > > > >> a > > > > > > > >> test > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> about 60km( mux side A and demux on side B) with sfp+10gb for > > > > > > > >> 80km... > > > > > > > >> ( > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> only see ddm on my ex3300( about -19db for 60km). Test switch > > > > > > > >> access > > > > > > > >> with > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> ssh and pinging tests... > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> What kind os issue do you have? For distances less than 60km > > > > > > > >> is > > > > > > > >> this > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> solution good? > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> Thanks!!! > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> Enviado via iPhone  > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> Grupo Connectoway > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Em 07/02/2015, às 14:55, Kenneth McRae < kenneth.mcrae at me.com > > > > > > > >>> > > > > > > > > >>> escreveu: > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Mike, > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> I just replaced a bunch of FiberStore WDM passive muxes with > > > > > > > >>> OSI > > > > > > > >>> Hardware > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> equipment. The FiberStore gear was a huge disappointment > > > > > > > >>> (excessive > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> loss, poor technical support, refusal to issue refund without > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> threatening legal action, etc.). I have had good results from > > > > > > > >>> the > > > > > > > >>> OSI > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> equipment so far. I run passive muxes for CWDM (8 - 16 > > > > > > > >>> channels). > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín < > > > > > > > >>> mmg at transtelco.net > > > > > > > >>> > > > > > > > > >>> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Hi Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> I can recommend a couple of vendors that provide cost > > > > > > > >>> effective > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> solutions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Ekinops & Packetlight. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> On Saturday, February 7, 2015, Mike Hammett < > > > > > > > >>> nanog at ics-il.net > > > > > > > >>> > > > > > > > > >>> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> I know there are various Asian vendors for low cost (less > > > > > > > >>> than > > > > > > > >>> $500) > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> muxes > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> to throw 16 or however many colors onto a strand. However, > > > > > > > >>> they > > > > > > > >>> don't > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> work > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> so well when you don't control the optics used on both sides > > > > > > > >>> (therefore > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> must use standard wavelengths), obviously only do a handful > > > > > > > >>> of > > > > > > > >>> channels > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> and > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> have a distance limitation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> What solutions are out there that don't cost an arm and a > > > > > > > >>> leg? > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> ----- > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Mike Hammett > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Intelligent Computing Solutions > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> http://www.ics-il.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 > > > > > > > >>> 915-217-2232* > > > > > > > >>> | > > > > > > > >>> MX: > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> *+52 > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> 656-257-1109* > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> CONFIDENTIALITY NOTICE: This communication is intended only > > > > > > > >>> for > > > > > > > >>> the > > > > > > > >>> use > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> of the individual or entity to which it is addressed and may > > > > > > > >>> contain > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> information that is privileged, confidential, and exempt from > > > > > > > >>> disclosure > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> under applicable law. If you are not the intended recipient > > > > > > > >>> of > > > > > > > >>> this > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> information, you are notified that any use, dissemination, > > > > > > > >>> distribution, > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> or > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> copying of the communication is strictly prohibited. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el > > > > > > > >>> uso > > > > > > > >>> de > > > > > > > >>> la > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> persona o entidad a la que se dirige y puede contener > > > > > > > >>> información > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> privilegiada, confidencial y exenta de divulgación bajo la > > > > > > > >>> legislación > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> aplicable. Si no es el destinatario de esta información, se > > > > > > > >>> le > > > > > > > >>> notifica > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> que > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> cualquier uso, difusión, distribución o copia de la > > > > > > > >>> comunicación > > > > > > > >>> está > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> estrictamente prohibido. > > > > > > > > > > > > > > > > > > > > > From kenneth.mcrae at me.com Sat Feb 7 21:28:41 2015 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Sat, 07 Feb 2015 21:28:41 +0000 (GMT) Subject: Low cost WDM gear Message-ID: <0d5ef0aa-309b-46a3-b8f5-7144b47df538@me.com> All the more reason to bring in engineering with accurate data when engaging with customers.  I kinda figured that FiberStore was a broker when I was told that all technical support issues had to be directed through the sale rep.  On Feb 07, 2015, at 01:26 PM, Faisal Imtiaz wrote: BTW, I hope you realize that FiberStore is not a mfg. but a "Seller/broker".  they have to rely on the specs provided to them from the MFG.  In the Far East, mfg, distribution, sales is organized is a slightly different manner than the West. :) 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 From: "Kenneth McRae" To: "Faisal Imtiaz" Cc: "Rodrigo 1telecom" , "NANOG" Sent: Saturday, February 7, 2015 4:01:29 PM Subject: Re: Low cost WDM gear That's true up to a point.  Specs are only as good as the entity providing the data.  I can tell you a few stories about specs and some MAJOR fails by a major network equipment manufacturer failing to meet advertised specs.  When you engage the engineering folks to assist in a build, they should know the true specs of their gear better than anyone else.  If they say for a certain distance that A+B will work, then that is exactly what I expect. That is pretty basic. On Feb 07, 2015, at 12:56 PM, Faisal Imtiaz wrote: More power to you ....  I always get a chuckle out of statements such as ... "Compared FiberStore to another Vendor"...   It was pointed out to me long time ago.... when someone said.. "My Chevy is better than a Ford".... Someone pointed out, hey, which Chevy ?  the Chevette ? or the Corvette ? and Which Ford the Fiesta or Mustang ? Every mfg. has a lots and lots of products, and they are always getting improved... One has to pay attention to the specs.. even the same model products at different times don't have the same specs ! :) 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 From: "Kenneth McRae" To: "Faisal Imtiaz" Cc: "Rodrigo 1telecom" , "NANOG" Sent: Saturday, February 7, 2015 3:49:16 PM Subject: Re: Low cost WDM gear That's why I engage the engineering resources on their end to make sure the chosen candidate will support the use case.  I have now performed an A/B comparison and the FiberStore gear is inferior.  Excessive loss on the mux and optics.  On Feb 07, 2015, at 12:44 PM, Faisal Imtiaz wrote: If you pay close attention to the Spec Sheets, on power output, insertion loss, sensitivity, and do the proper calculation for your link, then using anyone's products, passive or active will work unless the devices do not meet specified specs. If you don't do your homework, cals on the design, loss, and just buy stuff based on whatever, then it does not matter who the mfg. is, you are very very likely to be surprised in a bad way. :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- From: "Rodrigo 1telecom" To: "Kenneth McRae" Cc: "NANOG" Sent: Saturday, February 7, 2015 3:24:43 PM Subject: Re: Low cost WDM gear What others vendors do you using? Here in Brazil only PADTEC have this passive solution... Some days ago Digitel contact me to show your multiplex solution... Is a active solution... We import this from fiberstore, but i don't know others vendors to buy 10G sfp+ cwdm and this mux/demux... Enviado via iPhone  Grupo Connectoway > Em 07/02/2015, às 16:04, Kenneth McRae escreveu: > > Hi Enviado, > > I cannot recommend FiberStore as I had a bad experience with them. I > needed to cover only 3km from A to B side. When using 10km optics, I saw > a loss of over 5db with their passive mux inserted into the path which > created a total loss of over -20db which is outside of the tolerances for > our equipment with 10km SFP+. Using another vendors low insertion loss > mux corrected our issue. I am sure if you are using an 80km optic, you > may be able to tolerate a higher insertion loss to cover < 60km. I also > notice that their CDWM optics averaged about 3db less in power output when > compared to other vendors. > > Thanks > > Kenneth > >> On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom >> wrote: >> > >> Hi kenneth... which the distance do you have from side A to side B when >> you using passive solutions from fiberstore( mux and demux)? >> I buy this mux and demux(4 channels single fiber) and only make a test >> about 60km( mux side A and demux on side B) with sfp+10gb for 80km... ( >> only see ddm on my ex3300( about -19db for 60km). Test switch access with >> ssh and pinging tests... >> What kind os issue do you have? For distances less than 60km is this >> solution good? >> Thanks!!! >> >> Enviado via iPhone  >> Grupo Connectoway >> >>> Em 07/02/2015, às 14:55, Kenneth McRae escreveu: >>> Mike, >>> I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware >>> equipment. The FiberStore gear was a huge disappointment (excessive >>> loss, poor technical support, refusal to issue refund without >>> threatening legal action, etc.). I have had good results from the OSI >>> equipment so far. I run passive muxes for CWDM (8 - 16 channels). >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: >>> Hi Mike >>> I can recommend a couple of vendors that provide cost effective >>> solutions. >>> Ekinops & Packetlight. >>> On Saturday, February 7, 2015, Mike Hammett wrote: >>> I know there are various Asian vendors for low cost (less than $500) >>> muxes >>> to throw 16 or however many colors onto a strand. However, they don't >>> work >>> so well when you don't control the optics used on both sides (therefore >>> must use standard wavelengths), obviously only do a handful of channels >>> and >>> have a distance limitation. >>> What solutions are out there that don't cost an arm and a leg? >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> -- >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: >>> *+52 >>> 656-257-1109* >>> CONFIDENTIALITY NOTICE: This communication is intended only for the use >>> of the individual or entity to which it is addressed and may contain >>> information that is privileged, confidential, and exempt from disclosure >>> under applicable law. If you are not the intended recipient of this >>> information, you are notified that any use, dissemination, distribution, >>> or >>> copying of the communication is strictly prohibited. >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la >>> persona o entidad a la que se dirige y puede contener información >>> privilegiada, confidencial y exenta de divulgación bajo la legislación >>> aplicable. Si no es el destinatario de esta información, se le notifica >>> que >>> cualquier uso, difusión, distribución o copia de la comunicación está >>> estrictamente prohibido. From kenneth.mcrae at me.com Sat Feb 7 21:30:25 2015 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Sat, 07 Feb 2015 21:30:25 +0000 (GMT) Subject: Low cost WDM gear Message-ID: I will live vicariously though your experiences with them.  I'm good on FiberStore.  :-) Thanks for the feedback.. On Feb 07, 2015, at 01:27 PM, Faisal Imtiaz wrote: Maybe, your experience was the pivotal event that became a turning point in their customer service attitudes...  :) 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 From: "Kenneth McRae" To: "Faisal Imtiaz" Cc: "Rodrigo 1telecom" , "NANOG" Sent: Saturday, February 7, 2015 4:24:18 PM Subject: Re: Low cost WDM gear Point taken on the specs..  Still doesn't excuse poor customer service and tech support.  I never expect to be told that no refund will be issued when I am dissatisfied with the product.   A request for RMA because something is not working as expected should not have to be escalated to the President of the company.  Other than that I am sure FiberStore is a great company :-) On Feb 07, 2015, at 01:17 PM, Faisal Imtiaz wrote: My point is......     ... The thing to rely on is/are the Specs.             If the Specs are right or specs are wrong, that is what determines the product's mfg shortcoming (defect).     Mfg. Engineers are people, just like you and me.... and people can make mistakes...      Being an Engineer, when I ask someone to do the design work, I ask them to explain it, and this way I double check their work.... Yes Mfg. Engineers are known to  F***up too. While it is expected to be disappointed when something does not work.. and having a bad taste for dealing with that mfg, claiming that all of that mfg products are bad is a whole different issue. I deal with FiberStore, my experience have been very different, when stuff purchased from them, did not meet the specs, they took it back no questions asked. 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 From: "Kenneth McRae" To: "Faisal Imtiaz" Cc: "Rodrigo 1telecom" , "NANOG" Sent: Saturday, February 7, 2015 4:01:29 PM Subject: Re: Low cost WDM gear That's true up to a point.  Specs are only as good as the entity providing the data.  I can tell you a few stories about specs and some MAJOR fails by a major network equipment manufacturer failing to meet advertised specs.  When you engage the engineering folks to assist in a build, they should know the true specs of their gear better than anyone else.  If they say for a certain distance that A+B will work, then that is exactly what I expect. That is pretty basic. On Feb 07, 2015, at 12:56 PM, Faisal Imtiaz wrote: More power to you ....  I always get a chuckle out of statements such as ... "Compared FiberStore to another Vendor"...   It was pointed out to me long time ago.... when someone said.. "My Chevy is better than a Ford".... Someone pointed out, hey, which Chevy ?  the Chevette ? or the Corvette ? and Which Ford the Fiesta or Mustang ? Every mfg. has a lots and lots of products, and they are always getting improved... One has to pay attention to the specs.. even the same model products at different times don't have the same specs ! :) 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 From: "Kenneth McRae" To: "Faisal Imtiaz" Cc: "Rodrigo 1telecom" , "NANOG" Sent: Saturday, February 7, 2015 3:49:16 PM Subject: Re: Low cost WDM gear That's why I engage the engineering resources on their end to make sure the chosen candidate will support the use case.  I have now performed an A/B comparison and the FiberStore gear is inferior.  Excessive loss on the mux and optics.  On Feb 07, 2015, at 12:44 PM, Faisal Imtiaz wrote: If you pay close attention to the Spec Sheets, on power output, insertion loss, sensitivity, and do the proper calculation for your link, then using anyone's products, passive or active will work unless the devices do not meet specified specs. If you don't do your homework, cals on the design, loss, and just buy stuff based on whatever, then it does not matter who the mfg. is, you are very very likely to be surprised in a bad way. :) Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- From: "Rodrigo 1telecom" To: "Kenneth McRae" Cc: "NANOG" Sent: Saturday, February 7, 2015 3:24:43 PM Subject: Re: Low cost WDM gear What others vendors do you using? Here in Brazil only PADTEC have this passive solution... Some days ago Digitel contact me to show your multiplex solution... Is a active solution... We import this from fiberstore, but i don't know others vendors to buy 10G sfp+ cwdm and this mux/demux... Enviado via iPhone  Grupo Connectoway > Em 07/02/2015, às 16:04, Kenneth McRae escreveu: > > Hi Enviado, > > I cannot recommend FiberStore as I had a bad experience with them. I > needed to cover only 3km from A to B side. When using 10km optics, I saw > a loss of over 5db with their passive mux inserted into the path which > created a total loss of over -20db which is outside of the tolerances for > our equipment with 10km SFP+. Using another vendors low insertion loss > mux corrected our issue. I am sure if you are using an 80km optic, you > may be able to tolerate a higher insertion loss to cover < 60km. I also > notice that their CDWM optics averaged about 3db less in power output when > compared to other vendors. > > Thanks > > Kenneth > >> On Feb 07, 2015, at 10:33 AM, Rodrigo 1telecom >> wrote: >> > >> Hi kenneth... which the distance do you have from side A to side B when >> you using passive solutions from fiberstore( mux and demux)? >> I buy this mux and demux(4 channels single fiber) and only make a test >> about 60km( mux side A and demux on side B) with sfp+10gb for 80km... ( >> only see ddm on my ex3300( about -19db for 60km). Test switch access with >> ssh and pinging tests... >> What kind os issue do you have? For distances less than 60km is this >> solution good? >> Thanks!!! >> >> Enviado via iPhone  >> Grupo Connectoway >> >>> Em 07/02/2015, às 14:55, Kenneth McRae escreveu: >>> Mike, >>> I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware >>> equipment. The FiberStore gear was a huge disappointment (excessive >>> loss, poor technical support, refusal to issue refund without >>> threatening legal action, etc.). I have had good results from the OSI >>> equipment so far. I run passive muxes for CWDM (8 - 16 channels). >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: >>> Hi Mike >>> I can recommend a couple of vendors that provide cost effective >>> solutions. >>> Ekinops & Packetlight. >>> On Saturday, February 7, 2015, Mike Hammett wrote: >>> I know there are various Asian vendors for low cost (less than $500) >>> muxes >>> to throw 16 or however many colors onto a strand. However, they don't >>> work >>> so well when you don't control the optics used on both sides (therefore >>> must use standard wavelengths), obviously only do a handful of channels >>> and >>> have a distance limitation. >>> What solutions are out there that don't cost an arm and a leg? >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> -- >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: >>> *+52 >>> 656-257-1109* >>> CONFIDENTIALITY NOTICE: This communication is intended only for the use >>> of the individual or entity to which it is addressed and may contain >>> information that is privileged, confidential, and exempt from disclosure >>> under applicable law. If you are not the intended recipient of this >>> information, you are notified that any use, dissemination, distribution, >>> or >>> copying of the communication is strictly prohibited. >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la >>> persona o entidad a la que se dirige y puede contener información >>> privilegiada, confidencial y exenta de divulgación bajo la legislación >>> aplicable. Si no es el destinatario de esta información, se le notifica >>> que >>> cualquier uso, difusión, distribución o copia de la comunicación está >>> estrictamente prohibido. From nellermann at broadaspect.com Sat Feb 7 22:22:13 2015 From: nellermann at broadaspect.com (Nick Ellermann) Date: Sat, 7 Feb 2015 22:22:13 +0000 Subject: Low cost WDM gear In-Reply-To: <740018.831.1423330891727.JavaMail.mhammett@ThunderFuck> References: <23216412.825.1423330808325.JavaMail.mhammett@ThunderFuck> <740018.831.1423330891727.JavaMail.mhammett@ThunderFuck> Message-ID: <6675f6e41e65425992e91ede3e6ed824@exchange.broadaspect.local> Mike, Look into SolidOptics. www.Solidoptics.com Great Mux and Add-drops, plus fantastic optics. We are not optical engineers so when we have had questions about new links their team has always been open about what will and what won't work based on what we are trying to accomplish. We are only using their CWDM passive mux and various optics, been extremely happy on price and performance. No issues. Sincerely, Nick Ellermann – CTO & VP Cloud Services BroadAspect   E: nellermann at broadaspect.com P: 703-297-4639 F: 703-996-4443   THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Saturday, February 07, 2015 12:42 PM To: NANOG Subject: Low cost WDM gear I know there are various Asian vendors for low cost (less than $500) muxes to throw 16 or however many colors onto a strand. However, they don't work so well when you don't control the optics used on both sides (therefore must use standard wavelengths), obviously only do a handful of channels and have a distance limitation. What solutions are out there that don't cost an arm and a leg? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From tdurack at gmail.com Sat Feb 7 22:32:44 2015 From: tdurack at gmail.com (Tim Durack) Date: Sat, 7 Feb 2015 17:32:44 -0500 Subject: Low cost WDM gear In-Reply-To: <5739795.895.1423332278146.JavaMail.mhammett@ThunderFuck> References: <5739795.895.1423332278146.JavaMail.mhammett@ThunderFuck> Message-ID: You can do ~500km without inline amplifier sites using EDFA+Raman+ROPA, but you are going to need some serious optical engineering to make that work. The more standard way to do it is amplifier sites every 80-100km for EDFA. If you are doing 10GigE you will need to allow for DCM also. On Sat, Feb 7, 2015 at 1:04 PM, Mike Hammett wrote: > One particular route I'm looking at is 185 miles, so of the options > presented 300 km is closest. ;-) > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Christopher Morrow" > To: "Kenneth McRae" > Cc: "NANOG" > Sent: Saturday, February 7, 2015 12:02:11 PM > Subject: Re: Low cost WDM gear > > would be good for mike to define 'long distances' here, is it: > 2km > 30km > 300km > 3000km > > Probably the 30-60k range is what you mean by 'long distances' but... > clarity might help. > > On Sat, Feb 7, 2015 at 12:55 PM, Kenneth McRae > wrote: > > Mike, > > > > I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware > > equipment. The FiberStore gear was a huge disappointment (excessive loss, > > poor technical support, refusal to issue refund without threatening legal > > action, etc.). I have had good results from the OSI equipment so far. I > > run passive muxes for CWDM (8 - 16 channels). > > > > On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: > > > > Hi Mike > > > > I can recommend a couple of vendors that provide cost effective > solutions. > > Ekinops & Packetlight. > > > > On Saturday, February 7, 2015, Mike Hammett wrote: > > > > I know there are various Asian vendors for low cost (less than $500) > muxes > > to throw 16 or however many colors onto a strand. However, they don't > work > > so well when you don't control the optics used on both sides (therefore > > must use standard wavelengths), obviously only do a handful of channels > and > > have a distance limitation. > > What solutions are out there that don't cost an arm and a leg? > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > > > -- > > TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: > *+52 > > 656-257-1109* > > > > CONFIDENTIALITY NOTICE: This communication is intended only for the use > > of the individual or entity to which it is addressed and may contain > > information that is privileged, confidential, and exempt from disclosure > > under applicable law. If you are not the intended recipient of this > > information, you are notified that any use, dissemination, distribution, > or > > copying of the communication is strictly prohibited. > > > > AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la > > persona o entidad a la que se dirige y puede contener información > > privilegiada, confidencial y exenta de divulgación bajo la legislación > > aplicable. Si no es el destinatario de esta información, se le notifica > que > > cualquier uso, difusión, distribución o copia de la comunicación está > > estrictamente prohibido. > > -- Tim:> From colinj at gt86car.org.uk Sat Feb 7 23:28:54 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Sat, 7 Feb 2015 23:28:54 +0000 Subject: Low cost WDM gear In-Reply-To: References: <5739795.895.1423332278146.JavaMail.mhammett@ThunderFuck> Message-ID: <535121FF-3722-4DF4-B1D1-C17D2BCCE08E@gt86car.org.uk> Yes can do long distances without need to amplifier site (train tracks for example) but you need to make sure ground is stable and if using track bed of train track that the ballast is good and stable else ground tremors affect the signal quality. Colin > On 7 Feb 2015, at 22:32, Tim Durack wrote: > > You can do ~500km without inline amplifier sites using EDFA+Raman+ROPA, but > you are going to need some serious optical engineering to make that work. > The more standard way to do it is amplifier sites every 80-100km for EDFA. > If you are doing 10GigE you will need to allow for DCM also. > > On Sat, Feb 7, 2015 at 1:04 PM, Mike Hammett wrote: > >> One particular route I'm looking at is 185 miles, so of the options >> presented 300 km is closest. ;-) >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> ----- Original Message ----- >> >> From: "Christopher Morrow" >> To: "Kenneth McRae" >> Cc: "NANOG" >> Sent: Saturday, February 7, 2015 12:02:11 PM >> Subject: Re: Low cost WDM gear >> >> would be good for mike to define 'long distances' here, is it: >> 2km >> 30km >> 300km >> 3000km >> >> Probably the 30-60k range is what you mean by 'long distances' but... >> clarity might help. >> >> On Sat, Feb 7, 2015 at 12:55 PM, Kenneth McRae >> wrote: >>> Mike, >>> >>> I just replaced a bunch of FiberStore WDM passive muxes with OSI Hardware >>> equipment. The FiberStore gear was a huge disappointment (excessive loss, >>> poor technical support, refusal to issue refund without threatening legal >>> action, etc.). I have had good results from the OSI equipment so far. I >>> run passive muxes for CWDM (8 - 16 channels). >>> >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: >>> >>> Hi Mike >>> >>> I can recommend a couple of vendors that provide cost effective >> solutions. >>> Ekinops & Packetlight. >>> >>> On Saturday, February 7, 2015, Mike Hammett wrote: >>> >>> I know there are various Asian vendors for low cost (less than $500) >> muxes >>> to throw 16 or however many colors onto a strand. However, they don't >> work >>> so well when you don't control the optics used on both sides (therefore >>> must use standard wavelengths), obviously only do a handful of channels >> and >>> have a distance limitation. >>> What solutions are out there that don't cost an arm and a leg? >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> -- >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: >> *+52 >>> 656-257-1109* >>> >>> CONFIDENTIALITY NOTICE: This communication is intended only for the use >>> of the individual or entity to which it is addressed and may contain >>> information that is privileged, confidential, and exempt from disclosure >>> under applicable law. If you are not the intended recipient of this >>> information, you are notified that any use, dissemination, distribution, >> or >>> copying of the communication is strictly prohibited. >>> >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de la >>> persona o entidad a la que se dirige y puede contener información >>> privilegiada, confidencial y exenta de divulgación bajo la legislación >>> aplicable. Si no es el destinatario de esta información, se le notifica >> que >>> cualquier uso, difusión, distribución o copia de la comunicación está >>> estrictamente prohibido. >> >> > > > -- > Tim:> From carlos at race.com Sun Feb 8 00:38:44 2015 From: carlos at race.com (Carlos Alcantar) Date: Sun, 8 Feb 2015 00:38:44 +0000 Subject: Metaswitch ax1000 as a RR In-Reply-To: References: Message-ID: I can¹t speak for this product specifically as we do not use it, but on metaswitch voice platforms there support is impecable. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com On 2/5/15, 12:41 PM, "David Bass" wrote: >I have a client looking to implement x86 based route reflectors, and was >looking at the ax1000. I'm wondering if anyone has implemented it yet, >and what your experience has been? > >Any other alternatives would also be appreciated. This customer does >standard L3 VPNs, and VPLS services so the software has to support that. > >Thanks! > > > From owen at delong.com Sun Feb 8 01:17:59 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 7 Feb 2015 17:17:59 -0800 Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <6290.74.129.32.29.1423192783.iglou@webmail.iglou.com> Message-ID: <8EC4553E-CE27-4271-9671-809B72675748@delong.com> A good firewall can also be a good router. Of course you can find firewalls that are crappy routers and you can find routers that are crappy firewalls, but generally, the two are not mutually exclusive. Owen > On Feb 6, 2015, at 08:39 , Bill Thompson wrote: > > Just because a cat has kittens in the oven, you don't call them biscuits. A firewall can route, but it is not a router. Both have specialized tasks. You can fix a car with a swiss army knife, but why would you want to? > -- > Bill Thompson > billt at mahagonny.com > > On February 5, 2015 7:19:43 PM PST, Jeff McAdams wrote: >> >> On Thu, February 5, 2015 20:02, Joe Hamelin wrote: >>>> On Feb 5, 2015, at 2:49 PM, Ralph J.Mayer >>>> wrote: >>>> a router is a router and a firewall is a firewall. Especially a >> Cisco ASA >>>> is no router, period. >>> >>> Man-o-man did I find that out when we had to renumber our network >> after >>> we got bought by the French. >> >>> Oh, I'll just pop on a secondary address on this interface... What? >> >>> Needed to go through fits just to get a hairpin route in the thing. >> >>> The ASA series is good at what it does, just don't plan on it acting >> like >>> router IOS. >> >> Sorry, but I'm with Owen. >> >> Square : Rectangle :: Firewall : Router >> >> A firewall is a router, despite how much so many security folk try to >> deny >> it. And firewalls that seem to try to intentionally be crappy routers >> (ie, ASAs) have no place in my network. >> >> If it can't be a decent router, then its going to suck as a firewall >> too, >> because a firewall has to be able to play nice with the rest of the >> network, and if they can't do that, then I have no use for them. I'll >> get >> a firewall that does. From kmedcalf at dessus.com Sun Feb 8 01:49:41 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 07 Feb 2015 18:49:41 -0700 Subject: scaling linux-based router hardware recommendations In-Reply-To: <54C8F85B.8050807@seacom.mu> Message-ID: How is that a problem? --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Tinka >Sent: Wednesday, 28 January, 2015 07:55 >To: nanog at nanog.org >Subject: Re: scaling linux-based router hardware recommendations > >On 28/1/15 16:45, Colin Johnston wrote: >> qnx os based router works well with powerpc, could be pushed far higher >load than intel based chips > >The problem being that QNX is a 32-bit kernel. > >Mark. From cb.list6 at gmail.com Sun Feb 8 04:05:29 2015 From: cb.list6 at gmail.com (Ca By) Date: Sat, 7 Feb 2015 20:05:29 -0800 Subject: Checkpoint IPS In-Reply-To: <4715E281-B72B-4A1D-BE80-623C007D4CB4@arbor.net> References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> <15AB2602-8A05-43E8-A139-2831851EE6DD@arbor.net> <12896a45c4544bd8802ef1204949fa3a@BRTEXMB02.phillips66.net> <4715E281-B72B-4A1D-BE80-623C007D4CB4@arbor.net> Message-ID: On Friday, February 6, 2015, Roland Dobbins wrote: > > On 6 Feb 2015, at 23:23, Darden, Patrick wrote: > > And when your opinion is an acknowledged universal constant, I will tip >> my hat to you. >> > > It's been a constant for the last couple of decades - I can't count the > number of times I've been involved in mitigating penny-ante DDoS attacks > which succeeded *solely* due to state exhaustion on stateful firewalls, > 'IPS' devices, and load-balancers. > > I've seen a 20gb/sec commercial stateful firewall taken down by a 3mb/sec > spoofed SYN-flood. > > I've seen a 10gb/sec commercial load-balancer taken down by 60 second at > 6kpps - yes, 6kpps - of HOIC. > > And so on, and so forth. > > 'Dismiss' it all you like, but it's a real issue, as others on this list > know from bitter experience. Hi, Roland is right. 99% of network based security products are pure snake oil. Patch you servers, know your base line, statelessly filter unwanted traffic, rtbh as needed, sleep well at night. Bye. > ----------------------------------- > Roland Dobbins > From eksffa at freebsdbrasil.com.br Sun Feb 8 14:02:12 2015 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Sun, 8 Feb 2015 12:02:12 -0200 Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Message-ID: <18568D32-108A-4C17-9911-A7D468B938FA@freebsdbrasil.com.br> Hello, > > Some Juniper models actually do a very good job of being both. > > In reality, a Firewall _IS_ a router, even if it's a bad one. Anything that moves packets from one interface to another is a router. Technically it’s quite not a precise assumption. While routing is much likely an IP core need and OSI Layer 3 related mechanism, a firewall does not have to basic L3 forwarding. It can be a bridged/bright firewall, may fit in front of a router, protecting it, and carrying. Not routing anything. In fact in a fail-safe scenario (from availability perspective) a bridged firewall may be shut down completely and a Bypass por pair taking place will keep traffic flowing, “moving packets from one port to another” without actually ever been a router. I have recently added netmap-ipfw in front of BGP routers protecting ‘em from DDoS attacks, adding line-rate firewalling capabilities to a commodity x86/64 box or a T5 card for 10GbE/40GbE, and netmap-ipfw itself acts like mentioned, passing packets back and forth between interfaces without ever routing anything. > Of course, the support for routing protocols is a useful feature in a router and one of the areas where firewalls often fall short. > > Where you want to put things (in front, behind, etc.) really depends on your topology and the problem you are trying to solve. > > Personally, I like to keep the firewalls as close to the end hosts as possible. This tends to greatly simplify security policies and make them MUCH easier (and more reliable) to audit. I agree. A firewall belongs better closer to the end hosts being protected. Maybe protection of the router is the only exception when RTBH will not fit the task (or just won’t be enough). Therefore, close to the end host usually means far from the core routers. Unless one is really considering a CPE device doing poorly jobs of “a router and a firewall”... -- Patrick Tracanelli From bpnoc.lists at gmail.com Sun Feb 8 13:40:56 2015 From: bpnoc.lists at gmail.com (BPNoC Group) Date: Sun, 8 Feb 2015 11:40:56 -0200 Subject: Dynamic routing on firewalls. In-Reply-To: <8EC4553E-CE27-4271-9671-809B72675748@delong.com> References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <6290.74.129.32.29.1423192783.iglou@webmail.iglou.com> <8EC4553E-CE27-4271-9671-809B72675748@delong.com> Message-ID: > > > > Of course you can find firewalls that are crappy routers and you can find > routers that are crappy firewalls, but generally, the two are not mutually > exclusive. > I completely disagree w/ such or similar statements. On the vendor datasheet it says different. On books it says different. And on real life it's different. Firewalls are firewalls. Routers are routers. Routers should do some very basic filtering (stateles, ACLs, data plane protection...) and firewalls should do basic static routing. And things should not go far beyond that. If you keep thinking like that you will soon believe an L3 switch is a firewall too. Firewalls and routers belong to different places in a serious topology. Only small networks should have both functions in the same box. It raises risks, makes different kernel tasks competing to each other for the same resources. You may run out of states, memory and CPU specially if mixing NAT & tunneling beyond firewalling and routing. A router nowadays has many tasks to accomplish, from 6to4, dual stacking, to multiple routing services (bgp, ospf, bfd). Don't add extra duties to the box. Multiple purpose systems that can act like both things (say, a Linux box), but it's just not right to have more than one critical service in the same box. They should be distributed along your network. A firewall in front of the router, a firewall after the router in front of the servers. I just had a huge problem with an engineer who decided that a router should be his CGN, and when the number of translated sessions run above the expected and planned capacity, the box just sit down unresponsive. All of this company (and it's a banking company, not an ISP who just pays some SLA debit and it's good to go) connectivity was offline due to this confusion of service profiles on the same box, and all, means servers and hosts with registered IP addresses, not only RFC1918 addresses that needed to be translated. We just split the functions, distributed firewall and CGN to different boxes and topologies in a much more logical way and the "auto DoS feature" just went away. So, please, don't insist. A firewall is a firewall. A router is a router. A translation box is another alien. Unless you are SMB or willing to pay over dimensioned boxes to mix all duties up together, which will be more expensive than distributing the services alongside the network. > > Owen > > > On Feb 6, 2015, at 08:39 , Bill Thompson wrote: > > > > Just because a cat has kittens in the oven, you don't call them > biscuits. A firewall can route, but it is not a router. Both have > specialized tasks. You can fix a car with a swiss army knife, but why would > you want to? > > -- > > Bill Thompson > > billt at mahagonny.com > > > > On February 5, 2015 7:19:43 PM PST, Jeff McAdams > wrote: > >> > >> On Thu, February 5, 2015 20:02, Joe Hamelin wrote: > >>>> On Feb 5, 2015, at 2:49 PM, Ralph J.Mayer > >>>> wrote: > >>>> a router is a router and a firewall is a firewall. Especially a > >> Cisco ASA > >>>> is no router, period. > >>> > >>> Man-o-man did I find that out when we had to renumber our network > >> after > >>> we got bought by the French. > >> > >>> Oh, I'll just pop on a secondary address on this interface... What? > >> > >>> Needed to go through fits just to get a hairpin route in the thing. > >> > >>> The ASA series is good at what it does, just don't plan on it acting > >> like > >>> router IOS. > >> > >> Sorry, but I'm with Owen. > >> > >> Square : Rectangle :: Firewall : Router > >> > >> A firewall is a router, despite how much so many security folk try to > >> deny > >> it. And firewalls that seem to try to intentionally be crappy routers > >> (ie, ASAs) have no place in my network. > >> > >> If it can't be a decent router, then its going to suck as a firewall > >> too, > >> because a firewall has to be able to play nice with the rest of the > >> network, and if they can't do that, then I have no use for them. I'll > >> get > >> a firewall that does. > > From bpnoc.lists at gmail.com Sun Feb 8 14:24:56 2015 From: bpnoc.lists at gmail.com (BPNoC Group) Date: Sun, 8 Feb 2015 12:24:56 -0200 Subject: suny.edu / ASN54226 anyone? please contact me off-list Message-ID: Someone from Sunynet? Please contact-me off list to clarify if you are BGP transit to to a certain ASN spoofing my CIDR or if bgp as-path is artificially messed. Tried contact on sunny at suny.edu w/o success. From jeffm at iglou.com Sun Feb 8 14:48:14 2015 From: jeffm at iglou.com (Jeff McAdams) Date: Sun, 8 Feb 2015 09:48:14 -0500 (EST) Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <6290.74.129.32.29.1423192783.iglou@webmail.iglou.com> <8EC4553E-CE27-4271-9671-809B72675748@delong.com> Message-ID: <19417.74.129.32.29.1423406894.iglou@webmail.iglou.com> You're missing the point. I would never advocate for trying to deploy a Juniper MX in the role of a firewall to provide a security boundary. I would never try to deploy a Juniper SRX to provide a huge number of GRE tunnel terminations or other sorts of aggregations of large numbers of connections or however you might describe a typical router role. But that SRX does have different IP addresses in different networks on its various interfaces, and when traffic transits through the SRX, it looks at the layer 3 addressing information to determine where the traffic needs to be sent. Ergo, it is a router. You can deny it all you want, but you're only shooting yourself in the foot by not acknowledging that and dealing with its implications. And as a router, if a vendor wants me to put it on my network, it better dern well be a well behaved router to begin with, and in my network, that means OSPF and BGP. Only once it behaves as a router can its efficacy as a firewall really be considered. I completely agree that you don't want to overload any particular device with too many functions. I've got MXes that terminate a large number of GRE tunnels, but I've also SRXes terminating a large number of IPSec tunnels that are basically acting as routers because they can handle the large quantity of crypto operations involved better than an MX. But while the SRXes that terminate the large number of IPSec tunnels do some amount of firewalling, and I only did that grudgingly because of financial reasons. The firewalling will probably be moved off to a separate set of SRXes as this project grows. -- Jeff On Sun, February 8, 2015 08:40, BPNoC Group wrote: >> >> >> >> Of course you can find firewalls that are crappy routers and you can >> find routers that are crappy firewalls, but generally, the two are not >> mutually exclusive. >> > > I completely disagree w/ such or similar statements. > On the vendor datasheet it says different. On books it says different. > And on real life it's different. > > > Firewalls are firewalls. Routers are routers. Routers should do some very > basic filtering (stateles, ACLs, data plane protection...) and firewalls > should do basic static routing. And things should not go far beyond > that. > > If you keep thinking like that you will soon believe an L3 switch is a > firewall too. > > Firewalls and routers belong to different places in a serious topology. > > > Only small networks should have both functions in the same box. It raises > risks, makes different kernel tasks competing to each other for the same > resources. You may run out of states, memory and CPU specially if mixing > NAT & tunneling beyond firewalling and routing. A router nowadays has > many tasks to accomplish, from 6to4, dual stacking, to multiple routing > services (bgp, ospf, bfd). Don't add extra duties to the box. > > > Multiple purpose systems that can act like both things (say, a Linux > box), but it's just not right to have more than one critical service in > the same box. They should be distributed along your network. A firewall in > front of the router, a firewall after the router in front of the servers. > > I just had a huge problem with an engineer who decided that a router > should be his CGN, and when the number of translated sessions run above > the expected and planned capacity, the box just sit down unresponsive. All > of this company (and it's a banking company, not an ISP who just pays some > SLA > debit and it's good to go) connectivity was offline due to this confusion > of service profiles on the same box, and all, means servers and hosts > with registered IP addresses, not only RFC1918 addresses that needed to be > translated. > > We just split the functions, distributed firewall and CGN to different > boxes and topologies in a much more logical way and the "auto DoS feature" > just went away. > > So, please, don't insist. A firewall is a firewall. A router is a router. > A > translation box is another alien. Unless you are SMB or willing to pay > over dimensioned boxes to mix all duties up together, which will be more > expensive than distributing the services alongside the network. > > > >> >> Owen >> >> >>> On Feb 6, 2015, at 08:39 , Bill Thompson wrote: >>> >>> >>> Just because a cat has kittens in the oven, you don't call them >>> >> biscuits. A firewall can route, but it is not a router. Both have >> specialized tasks. You can fix a car with a swiss army knife, but why >> would you want to? >>> -- >>> Bill Thompson >>> billt at mahagonny.com >>> >>> On February 5, 2015 7:19:43 PM PST, Jeff McAdams >>> >> wrote: >> >>>> >>>> On Thu, February 5, 2015 20:02, Joe Hamelin wrote: >>>> >>>>>> On Feb 5, 2015, at 2:49 PM, Ralph J.Mayer >>>>>> >>>>>> wrote: >>>>>> a router is a router and a firewall is a firewall. Especially a >>>> Cisco ASA >>>> >>>>>> is no router, period. >>>>> >>>>> Man-o-man did I find that out when we had to renumber our network >>>>> >>>> after >>>>> we got bought by the French. >>>> >>>>> Oh, I'll just pop on a secondary address on this interface... >>>>> What? >>>>> >>>> >>>>> Needed to go through fits just to get a hairpin route in the >>>>> thing. >>>> >>>>> The ASA series is good at what it does, just don't plan on it >>>>> acting >>>> like >>>>> router IOS. >>>> >>>> Sorry, but I'm with Owen. >>>> >>>> >>>> Square : Rectangle :: Firewall : Router >>>> >>>> >>>> A firewall is a router, despite how much so many security folk try >>>> to deny it. And firewalls that seem to try to intentionally be >>>> crappy routers (ie, ASAs) have no place in my network. >>>> >>>> >>>> If it can't be a decent router, then its going to suck as a >>>> firewall too, because a firewall has to be able to play nice with the >>>> rest of the network, and if they can't do that, then I have no use >>>> for them. I'll get a firewall that does. >> >> > -- Jeff From bpnoc.lists at gmail.com Sun Feb 8 15:49:01 2015 From: bpnoc.lists at gmail.com (BPNoC Group) Date: Sun, 8 Feb 2015 13:49:01 -0200 Subject: Dynamic routing on firewalls. In-Reply-To: <19417.74.129.32.29.1423406894.iglou@webmail.iglou.com> References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <6290.74.129.32.29.1423192783.iglou@webmail.iglou.com> <8EC4553E-CE27-4271-9671-809B72675748@delong.com> <19417.74.129.32.29.1423406894.iglou@webmail.iglou.com> Message-ID: On Sun, Feb 8, 2015 at 12:48 PM, Jeff McAdams wrote: > You're missing the point. > I'm not missing, I'm just diverting the point. As I mentioned from a Linux box example, the fact that it can both act as a router and a firewall does not mean it should. I disagree with the simplistic idea that if a firewall L3 forwards, it's a router, or if a router has ACLs capabilities, it's a firewall. Someone just illustrated how a mission-critical placed firewall protecting a BGP router may do it bridged, without actually routing not a single extra hop. > I would never advocate for trying to deploy a Juniper MX in the role of a > firewall to provide a security boundary. I would never try to deploy a > Juniper SRX to provide a huge number of GRE tunnel terminations or other > sorts of aggregations of large numbers of connections or however you might > describe a typical router role. > So we agree! I completely agree that you don't want to overload any particular device > with too many functions. I've got MXes that terminate a large number of > GRE tunnels, but I've also SRXes terminating a large number of IPSec > tunnels that are basically acting as routers because they can handle the > large quantity of crypto operations involved better than an MX. But while > the SRXes that terminate the large number of IPSec tunnels do some amount > of firewalling, and I only did that grudgingly because of financial > reasons. Yes, I understand budget restrictions sometimes takes to accumulating functions on the same box. But the notion that matters is that although a firewall *can* be, technically, implemented in the same node, it just belongs to somewhere else, in a distributed / separed box. > The firewalling will probably be moved off to a separate set of > SRXes as this project grows. > Yeah, in the end we mostly agree. > > -- > Jeff > > On Sun, February 8, 2015 08:40, BPNoC Group wrote: > >> > > >> > >> > >> Of course you can find firewalls that are crappy routers and you can > >> find routers that are crappy firewalls, but generally, the two are not > >> mutually exclusive. > >> > > > > I completely disagree w/ such or similar statements. > > On the vendor datasheet it says different. On books it says different. > > And on real life it's different. > > > > > > Firewalls are firewalls. Routers are routers. Routers should do some very > > basic filtering (stateles, ACLs, data plane protection...) and firewalls > > should do basic static routing. And things should not go far beyond > > that. > > > > If you keep thinking like that you will soon believe an L3 switch is a > > firewall too. > > > > Firewalls and routers belong to different places in a serious topology. > > > > > > Only small networks should have both functions in the same box. It raises > > risks, makes different kernel tasks competing to each other for the same > > resources. You may run out of states, memory and CPU specially if mixing > > NAT & tunneling beyond firewalling and routing. A router nowadays has > > many tasks to accomplish, from 6to4, dual stacking, to multiple routing > > services (bgp, ospf, bfd). Don't add extra duties to the box. > > > > > > Multiple purpose systems that can act like both things (say, a Linux > > box), but it's just not right to have more than one critical service in > > the same box. They should be distributed along your network. A firewall > in > > front of the router, a firewall after the router in front of the servers. > > > > I just had a huge problem with an engineer who decided that a router > > should be his CGN, and when the number of translated sessions run above > > the expected and planned capacity, the box just sit down unresponsive. > All > > of this company (and it's a banking company, not an ISP who just pays > some > > SLA > > debit and it's good to go) connectivity was offline due to this confusion > > of service profiles on the same box, and all, means servers and hosts > > with registered IP addresses, not only RFC1918 addresses that needed to > be > > translated. > > > > We just split the functions, distributed firewall and CGN to different > > boxes and topologies in a much more logical way and the "auto DoS > feature" > > just went away. > > > > So, please, don't insist. A firewall is a firewall. A router is a router. > > A > > translation box is another alien. Unless you are SMB or willing to pay > > over dimensioned boxes to mix all duties up together, which will be more > > expensive than distributing the services alongside the network. > > > > > > > >> > >> Owen > >> > >> > >>> On Feb 6, 2015, at 08:39 , Bill Thompson wrote: > >>> > >>> > >>> Just because a cat has kittens in the oven, you don't call them > >>> > >> biscuits. A firewall can route, but it is not a router. Both have > >> specialized tasks. You can fix a car with a swiss army knife, but why > >> would you want to? > >>> -- > >>> Bill Thompson > >>> billt at mahagonny.com > >>> > >>> On February 5, 2015 7:19:43 PM PST, Jeff McAdams > >>> > >> wrote: > >> > >>>> > >>>> On Thu, February 5, 2015 20:02, Joe Hamelin wrote: > >>>> > >>>>>> On Feb 5, 2015, at 2:49 PM, Ralph J.Mayer > >>>>>> > >>>>>> wrote: > >>>>>> a router is a router and a firewall is a firewall. Especially a > >>>> Cisco ASA > >>>> > >>>>>> is no router, period. > >>>>> > >>>>> Man-o-man did I find that out when we had to renumber our network > >>>>> > >>>> after > >>>>> we got bought by the French. > >>>> > >>>>> Oh, I'll just pop on a secondary address on this interface... > >>>>> What? > >>>>> > >>>> > >>>>> Needed to go through fits just to get a hairpin route in the > >>>>> thing. > >>>> > >>>>> The ASA series is good at what it does, just don't plan on it > >>>>> acting > >>>> like > >>>>> router IOS. > >>>> > >>>> Sorry, but I'm with Owen. > >>>> > >>>> > >>>> Square : Rectangle :: Firewall : Router > >>>> > >>>> > >>>> A firewall is a router, despite how much so many security folk try > >>>> to deny it. And firewalls that seem to try to intentionally be > >>>> crappy routers (ie, ASAs) have no place in my network. > >>>> > >>>> > >>>> If it can't be a decent router, then its going to suck as a > >>>> firewall too, because a firewall has to be able to play nice with the > >>>> rest of the network, and if they can't do that, then I have no use > >>>> for them. I'll get a firewall that does. > >> > >> > > > > > -- > Jeff > > From bpnoc.lists at gmail.com Sun Feb 8 16:00:03 2015 From: bpnoc.lists at gmail.com (BPNoC Group) Date: Sun, 8 Feb 2015 14:00:03 -0200 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> <15AB2602-8A05-43E8-A139-2831851EE6DD@arbor.net> <12896a45c4544bd8802ef1204949fa3a@BRTEXMB02.phillips66.net> <4715E281-B72B-4A1D-BE80-623C007D4CB4@arbor.net> Message-ID: On Sun, Feb 8, 2015 at 2:05 AM, Ca By wrote: > On Friday, February 6, 2015, Roland Dobbins wrote: > > > > > On 6 Feb 2015, at 23:23, Darden, Patrick wrote: > > > > And when your opinion is an acknowledged universal constant, I will tip > >> my hat to you. > >> > > > > It's been a constant for the last couple of decades - I can't count the > > number of times I've been involved in mitigating penny-ante DDoS attacks > > which succeeded *solely* due to state exhaustion on stateful firewalls, > > 'IPS' devices, and load-balancers. > > > > I've seen a 20gb/sec commercial stateful firewall taken down by a 3mb/sec > > spoofed SYN-flood. > > > > I've seen a 10gb/sec commercial load-balancer taken down by 60 second at > > 6kpps - yes, 6kpps - of HOIC. > > > > And so on, and so forth. > > > > 'Dismiss' it all you like, but it's a real issue, as others on this list > > know from bitter experience. > > > > Hi, > > Roland is right. 99% of network based security products are pure snake > oil. Patch you servers, know your base line, statelessly filter unwanted > traffic, rtbh as needed, sleep well at night. > > Bye. > Yeah, but Mr Tracanelli has a wider point. A firewall or IDS has its place near the core, due to exhaustion not taking core routing down and taking your availability away, while still adding security to it. While stateful firewall / IPS / proxy belongs somewhere else deeper in the network, closer to business logic than core/border. Mr Dobbins' slides/presentation gives an idea that a proxy (waf, whatever) fits sitting unprotected among routers and application servers, while its also stateful and fragile enough to deserve previous protection. > > > > ----------------------------------- > > Roland Dobbins > > > From rdobbins at arbor.net Sun Feb 8 18:26:30 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 09 Feb 2015 01:26:30 +0700 Subject: Checkpoint IPS In-Reply-To: References: <54CF733C.1030205@free.fr> <54D313EF.4080305@free.fr> <000801d04143$57b9c0f0$072d42d0$@gmail.com> <54D3FF52.2040005@freebsdbrasil.com.br> <15AB2602-8A05-43E8-A139-2831851EE6DD@arbor.net> <12896a45c4544bd8802ef1204949fa3a@BRTEXMB02.phillips66.net> <4715E281-B72B-4A1D-BE80-623C007D4CB4@arbor.net> Message-ID: <06FB6B4E-A6BD-46B2-85B4-127C89E87756@arbor.net> On 8 Feb 2015, at 23:00, BPNoC Group wrote: > Mr Dobbins' slides/presentation gives an idea that a proxy (waf, > whatever) fits sitting unprotected among routers and application > servers, while its also stateful and fragile enough to deserve > previous protection. from p.16 of the presentation in question: 'If stateful firewalls cannot be immediately removed from the architecture, they must be protected against DDoS via S/RTBH, flowspec, IDMS, et. al., just like servers!' from p.19 of the presentation in question: 'Load-balancers must be protected against DDoS - stateless ACLs for policy enforcement, S/RTBH, flowspec, IDMS, and so forth.' from p.28 of the presentation in question: 'Reverse-proxy farms must be protected from DDoS via S/RTBH, flowspec, IDMS, et. al.' ----------------------------------- Roland Dobbins From thegameiam at yahoo.com Sun Feb 8 22:07:18 2015 From: thegameiam at yahoo.com (David Barak) Date: Sun, 8 Feb 2015 17:07:18 -0500 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: <20150130174453.485e9105@envy.fud.no> Message-ID: > On Jan 30, 2015, at 9:49 PM, Owen DeLong wrote: > > >> On Jan 30, 2015, at 18:07 , William Herrin wrote: >> How about this: when Verizon starts decommissioning its IPv4 >> infrastructure on the basis that IPv6 is widespread enough to no >> longer require the expense of dual-stack, IPv6 will have achieved >> ubiquity. > > Um, no. The judgment of one traditional telephone company is hardly where I would look to contemplate the future of the internet. Then AT&T, Comcast, Cox, Level3, etc, could be reasonable examples? I think the general point is worth considering - when v4 gear is regularly being pulled out of commission by large carriers because "who needs it?" and replaced with v6 only gear, we will have achieved true ubiquity. I think you'll see v4 for quite a while. Heck, I still run across SNA, Token Ring, and other really old stuff occasionally... David Barak Sent from a mobile device, please forgive autocorrection. From tshaw at oitc.com Sun Feb 8 22:48:57 2015 From: tshaw at oitc.com (TR Shaw) Date: Sun, 8 Feb 2015 17:48:57 -0500 Subject: UVerse question Message-ID: <4EDAE180-503A-4C88-9101-5A77A3EEA90C@oitc.com> Any suggestions on what to tell ATT to get IPv6 added to a current account and upgrade a 2wire router to 4wire with halfway decent performance and capability? Any and all help would be appreciated. Tom From lyle at lcrcomputer.net Sun Feb 8 23:52:39 2015 From: lyle at lcrcomputer.net (Lyle Giese) Date: Sun, 08 Feb 2015 17:52:39 -0600 Subject: UVerse question In-Reply-To: <4EDAE180-503A-4C88-9101-5A77A3EEA90C@oitc.com> References: <4EDAE180-503A-4C88-9101-5A77A3EEA90C@oitc.com> Message-ID: <54D7F6C7.20903@lcrcomputer.net> The second half is easy. Do it your self. Turn the 2wire router into a transparent device and put your own router in doing the PPPoE for you. pfSense and M0n0wall support IPv6. I am in AT&T territory, but don't use them for Internet.(I use the local cable company). But I know that several of my customers do have IPv6 connectivity already both on DSL and uVerse here in the Chicago Suburan area. Lyle Giese LCR Computer Services, Inc. On 02/08/15 16:48, TR Shaw wrote: > Any suggestions on what to tell ATT to get IPv6 added to a current account and upgrade a 2wire router to 4wire with halfway decent performance and capability? > > Any and all help would be appreciated. > > Tom From owen at delong.com Mon Feb 9 00:48:58 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 8 Feb 2015 16:48:58 -0800 Subject: Dynamic routing on firewalls. In-Reply-To: <18568D32-108A-4C17-9911-A7D468B938FA@freebsdbrasil.com.br> References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <18568D32-108A-4C17-9911-A7D468B938FA@freebsdbrasil.com.br> Message-ID: <364F7CA4-9630-44E8-8494-28F786092965@delong.com> > On Feb 8, 2015, at 06:02 , Patrick Tracanelli wrote: > > Hello, > >> >> Some Juniper models actually do a very good job of being both. >> >> In reality, a Firewall _IS_ a router, even if it's a bad one. Anything that moves packets from one interface to another is a router. > > Technically it’s quite not a precise assumption. While routing is much likely an IP core need and OSI Layer 3 related mechanism, a firewall does not have to basic L3 forwarding. It can be a bridged/bright firewall, may fit in front of a router, protecting it, and carrying. Not routing anything. In fact in a fail-safe scenario (from availability perspective) a bridged firewall may be shut down completely and a Bypass por pair taking place will keep traffic flowing, “moving packets from one port to another” without actually ever been a router. Technically true, but bridged firewalls are pretty much passe these days in the real world. As a general rule, when the firewall is shut down, one usually doesn’t want the packets flowing past un-hindered. The fact that this is kind of the default of what happens with bridged firewalls is just one of the many reasons hardly anyone still uses such a thing. > I have recently added netmap-ipfw in front of BGP routers protecting ‘em from DDoS attacks, adding line-rate firewalling capabilities to a commodity x86/64 box or a T5 card for 10GbE/40GbE, and netmap-ipfw itself acts like mentioned, passing packets back and forth between interfaces without ever routing anything. Sure, there are all kinds of things one can do. Some of them are good ideas, many of them are not. If it works in your environment and you’re OK with the failure modes and other tradeoffs, then more power to you. > >> Of course, the support for routing protocols is a useful feature in a router and one of the areas where firewalls often fall short. >> >> Where you want to put things (in front, behind, etc.) really depends on your topology and the problem you are trying to solve. >> >> Personally, I like to keep the firewalls as close to the end hosts as possible. This tends to greatly simplify security policies and make them MUCH easier (and more reliable) to audit. > > I agree. A firewall belongs better closer to the end hosts being protected. Maybe protection of the router is the only exception when RTBH will not fit the task (or just won’t be enough). DDoS mitigation on site is a questionable and usually losing proposition at best. Other than DDoS mitigation, any good router should be perfectly capable of protecting itself. For protecting a router from DDoS that it cannot properly protect itself, one needs to be able to control or alter the delivery of packets across the upstream link from the upstream side anyway. That is best done by an off-site service such as Akamai’s Prolexic. > Therefore, close to the end host usually means far from the core routers. Unless one is really considering a CPE device doing poorly jobs of “a router and a firewall”… Depends on the nature of your network. I know lots of datacenter networks where the end hosts are not more than one or two hops removed from the core routers. I would hardly refer to those networks as a CPE device doing a poor job of “router and firewall”. Owen From owen at delong.com Mon Feb 9 00:58:49 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 8 Feb 2015 16:58:49 -0800 Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <6290.74.129.32.29.1423192783.iglou@webmail.iglou.com> <8EC4553E-CE27-4271-9671-809B72675748@delong.com> Message-ID: <4B7EAB2A-D322-4945-A9CE-68148DA83804@delong.com> > On Feb 8, 2015, at 05:40 , BPNoC Group wrote: > >> >> >> >> Of course you can find firewalls that are crappy routers and you can find >> routers that are crappy firewalls, but generally, the two are not mutually >> exclusive. >> > > I completely disagree w/ such or similar statements. > On the vendor datasheet it says different. On books it says different. > And on real life it's different. No, really it does not. > > Firewalls are firewalls. Routers are routers. Routers should do some very > basic filtering (stateles, ACLs, data plane protection...) and firewalls > should do basic static routing. And things should not go far beyond that. We can agree to disagree. > If you keep thinking like that you will soon believe an L3 switch is a > firewall too. An L3 switch is just another kind of router and if it’s got the ability for its switching matrix to include a packet classifier that can be preprogrammed for the appropriate firewall functions at line rate in hardware, then, yes, it’s a perfectly fine firewall, and, probably about the only solution that’s really going to work in a high line-rate scenario, actually. > Firewalls and routers belong to different places in a serious topology. You and I apparently have very different ideas of serous topologies. > Only small networks should have both functions in the same box. It raises > risks, makes different kernel tasks competing to each other for the same > resources. You may run out of states, memory and CPU specially if mixing > NAT & tunneling beyond firewalling and routing. A router nowadays has many > tasks to accomplish, from 6to4, dual stacking, to multiple routing services > (bgp, ospf, bfd). Don't add extra duties to the box. If you are firewalling so far away from the edge that any of this matters, you have already lost and your topology is very hard to consider “serious” in my opinion. > Multiple purpose systems that can act like both things (say, a Linux box), > but it's just not right to have more than one critical service in the same > box. They should be distributed along your network. A firewall in front of > the router, a firewall after the router in front of the servers. I’m thinking more like a large Juniper with an ESPIC or other services interface hardware solution. > I just had a huge problem with an engineer who decided that a router should > be his CGN, and when the number of translated sessions run above the > expected and planned capacity, the box just sit down unresponsive. All of > this company (and it's a banking company, not an ISP who just pays some SLA > debit and it's good to go) connectivity was offline due to this confusion > of service profiles on the same box, and all, means servers and hosts with > registered IP addresses, not only RFC1918 addresses that needed to be > translated. You can always choose the wrong box for the job. I bet I can point to plenty of routers that could have handled his CGN needs just fine and had plenty of memory to hold all of his translated sessions. This is no different than if he chose an incorrect CGN box that was purpose-built. Your example is like saying “The 2514 was not adequate as a 100Mbps firewall, so all routers are inadequate as firewalls”. The 2514 was not adequate or even capable of being a 100Mbps router. > We just split the functions, distributed firewall and CGN to different > boxes and topologies in a much more logical way and the "auto DoS feature" > just went away. That’s certainly one viable solution. Maybe even the right one for that particular space. However, it does not change anything I said. > So, please, don't insist. A firewall is a firewall. A router is a router. A > translation box is another alien. Unless you are SMB or willing to pay over > dimensioned boxes to mix all duties up together, which will be more > expensive than distributing the services alongside the network. Technically, a router is any device which takes an IP datagram on one interface and delivers it to an interface with a different network number (whether the same (hairpin) or another interface) after decrementing the TTL or Hop Count (depending on whether IPv4 or IPv6). Other than the (rather silly in virtually all circumstances) Layer 2 firewalls mentioned earlier, every firewall is technically a router. Not every router is a firewall, though there are plenty of routers that are also very capable firewalls. I will grant you that there are virtually no purpose-built firewalls that make good routers, but that’s yet another issue truly unrelated to what I said. As to translation devices, well, those also have no place in a serious topology other than dealing with limitations of an aging and hopefully soon to be deprecated protocol that should have been obsoleted years ago. Owen > > > >> >> Owen >> >>> On Feb 6, 2015, at 08:39 , Bill Thompson wrote: >>> >>> Just because a cat has kittens in the oven, you don't call them >> biscuits. A firewall can route, but it is not a router. Both have >> specialized tasks. You can fix a car with a swiss army knife, but why would >> you want to? >>> -- >>> Bill Thompson >>> billt at mahagonny.com >>> >>> On February 5, 2015 7:19:43 PM PST, Jeff McAdams >> wrote: >>>> >>>> On Thu, February 5, 2015 20:02, Joe Hamelin wrote: >>>>>> On Feb 5, 2015, at 2:49 PM, Ralph J.Mayer >>>>>> wrote: >>>>>> a router is a router and a firewall is a firewall. Especially a >>>> Cisco ASA >>>>>> is no router, period. >>>>> >>>>> Man-o-man did I find that out when we had to renumber our network >>>> after >>>>> we got bought by the French. >>>> >>>>> Oh, I'll just pop on a secondary address on this interface... What? >>>> >>>>> Needed to go through fits just to get a hairpin route in the thing. >>>> >>>>> The ASA series is good at what it does, just don't plan on it acting >>>> like >>>>> router IOS. >>>> >>>> Sorry, but I'm with Owen. >>>> >>>> Square : Rectangle :: Firewall : Router >>>> >>>> A firewall is a router, despite how much so many security folk try to >>>> deny >>>> it. And firewalls that seem to try to intentionally be crappy routers >>>> (ie, ASAs) have no place in my network. >>>> >>>> If it can't be a decent router, then its going to suck as a firewall >>>> too, >>>> because a firewall has to be able to play nice with the rest of the >>>> network, and if they can't do that, then I have no use for them. I'll >>>> get >>>> a firewall that does. >> >> From cvuljanic at gmail.com Mon Feb 9 01:21:19 2015 From: cvuljanic at gmail.com (Craig) Date: Sun, 8 Feb 2015 20:21:19 -0500 Subject: Dynamic routing on firewalls. In-Reply-To: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Message-ID: Setup a multi tenant setup between Nexus 7K and Juniper Net screen 5400 FW using OSPF. It went OK and worked. However when under traffic load/ less than. Desirable results... OSPF peer failure / bounces etc. However using BGP with Juniper SRX FW has been working great. No issues thus far. On Feb 5, 2015 9:11 AM, "David Jansen" wrote: > Hi, > > We have used dynamic routing on firewall in the old days. We did > experience several severe outages due to this setup (OSPF en Cisco). As you > will understand i’m not eager to go back to this solution but I am curious > about your point of views. > > Is it advisory to so these days? > > Kind regards, > David > > > From tony at wicks.co.nz Mon Feb 9 01:35:35 2015 From: tony at wicks.co.nz (Tony Wicks) Date: Mon, 9 Feb 2015 14:35:35 +1300 Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> Message-ID: <00d301d04408$b3ff3b20$1bfdb160$@wicks.co.nz> I have some use cases where I have Fortinet firewalls running full ospf/ospfv3/bgp and it all pretty much just works without any issues. The CLI is a bit cumbersome, but apart from that its fine. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Craig Sent: Monday, 9 February 2015 2:21 p.m. To: David Jansen Cc: nanog group Subject: Re: Dynamic routing on firewalls. Setup a multi tenant setup between Nexus 7K and Juniper Net screen 5400 FW using OSPF. It went OK and worked. However when under traffic load/ less than. Desirable results... OSPF peer failure / bounces etc. However using BGP with Juniper SRX FW has been working great. No issues thus far. On Feb 5, 2015 9:11 AM, "David Jansen" wrote: > Hi, > > We have used dynamic routing on firewall in the old days. We did > experience several severe outages due to this setup (OSPF en Cisco). > As you will understand i’m not eager to go back to this solution but I > am curious about your point of views. > > Is it advisory to so these days? > > Kind regards, > David > > > From lobna_gouda at hotmail.com Mon Feb 9 01:48:01 2015 From: lobna_gouda at hotmail.com (lobna gouda) Date: Mon, 9 Feb 2015 01:48:01 +0000 Subject: Has anyone imagined what could be the future HCI Message-ID: Has anyone imagined this? away on increasing processing power or visual clearance of what we already have, what could be the next HCI? From dan at tangledhelix.com Mon Feb 9 03:55:24 2015 From: dan at tangledhelix.com (Dan Lowe) Date: Sun, 08 Feb 2015 22:55:24 -0500 Subject: UVerse question In-Reply-To: <4EDAE180-503A-4C88-9101-5A77A3EEA90C@oitc.com> References: <4EDAE180-503A-4C88-9101-5A77A3EEA90C@oitc.com> Message-ID: <1423454124.2864283.224802645.45F7A907@webmail.messagingengine.com> On Sun, Feb 8, 2015, at 05:48 PM, TR Shaw wrote: > Any suggestions on what to tell ATT to get IPv6 added to a current > account and upgrade a 2wire router to 4wire with halfway decent > performance and capability? I have no advice on the equipment upgrade, but I was able to add IPv6 to my account by visiting this page http://www.att.com/esupport/ipv6.jsp and running the compatibility test. Once it determined that I didn't have IPv6, it offered to turn it on. A few minutes later, my router had an IPv6 subnet configured. A co-worker pointed me to this link, and it worked similarly for him. He's in the Santa Rosa, CA market, and I'm in the Cleveland, OH market. Dan From maxtul at netassist.ua Mon Feb 9 07:16:48 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 09 Feb 2015 09:16:48 +0200 Subject: Provider to Blend with Level3 In-Reply-To: References: Message-ID: <54D85EE0.9060305@netassist.ua> Hi! If you have he.net there - it will be the best choise. On 06.02.15 19:26, Colton Conor wrote: > We have a network that is single homed with Level3 at this time in Dallas. > They already have BGP and their own ASN and IP setup. Who would you > recommend for a second provider in Dallas to blend with Level3? Assuming > Level3 and this other provider would be the only two in the blend for a > long time to come? Client was talking to TWT, but now that they are being > bought by Level3 that doesn't make much sense. > From rsk at gsp.org Mon Feb 9 08:59:52 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 9 Feb 2015 03:59:52 -0500 Subject: Dynamic routing on firewalls. In-Reply-To: References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <6290.74.129.32.29.1423192783.iglou@webmail.iglou.com> <8EC4553E-CE27-4271-9671-809B72675748@delong.com> Message-ID: <20150209085952.GA4984@gsp.org> On Sun, Feb 08, 2015 at 11:40:56AM -0200, BPNoC Group wrote: > Firewalls are firewalls. Routers are routers. Routers should do some very > basic filtering (stateles, ACLs, data plane protection...) and firewalls > should do basic static routing. And things should not go far beyond that. This is, at a network level, an echo of the "Software Tools" philosophy that has served us exceedingly well for decades. Tools should do one thing, they should do it well, and if/when we need to do more than one thing, we should use tools in combination. There's another advantage to this: if firewalls and routers &etc are not the same system, then they can run different software on different operating systems on different architectures -- providing a significant measure of insulation against attacks unique to one particular combination. ---rsk From vaibhav.area0 at gmail.com Mon Feb 9 07:29:52 2015 From: vaibhav.area0 at gmail.com (vaibhav nikam) Date: Mon, 9 Feb 2015 12:59:52 +0530 Subject: Provider to Blend with Level3 In-Reply-To: <54D85EE0.9060305@netassist.ua> References: <54D85EE0.9060305@netassist.ua> Message-ID: Hi, You can check with CenturyLink Regards ------------ Vaib On Mon, Feb 9, 2015 at 12:46 PM, Max Tulyev wrote: > Hi! > > If you have he.net there - it will be the best choise. > > On 06.02.15 19:26, Colton Conor wrote: > > We have a network that is single homed with Level3 at this time in > Dallas. > > They already have BGP and their own ASN and IP setup. Who would you > > recommend for a second provider in Dallas to blend with Level3? Assuming > > Level3 and this other provider would be the only two in the blend for a > > long time to come? Client was talking to TWT, but now that they are being > > bought by Level3 that doesn't make much sense. > > > > From jason at unlimitednet.us Mon Feb 9 12:23:33 2015 From: jason at unlimitednet.us (Jason Canady) Date: Mon, 09 Feb 2015 07:23:33 -0500 Subject: Provider to Blend with Level3 In-Reply-To: References: <54D85EE0.9060305@netassist.ua> Message-ID: <54D8A6C5.6010300@unlimitednet.us> Another good choice would be Cogent, AS174. We use Cogent along with Level 3. I'd say 2/3 of our traffic is on Level 3 and 1/3 on Cogent. It's been a great blend for us. Justin Wilson recently made some great comments about Cogent on Feb 6, reference subject: Re: Input Regarding Cogent and NTT. At this point, I would fully rely on Cogent for maintenance or outages on Level 3. A year and a half ago, they had some problems between providers such as Comcast. With Netflix getting direct connections, this is now resolved. -- Jason Canady Unlimited Net, LLC www.unlimitednet.us twitter: @unlimitednet On 2/9/15 2:29 AM, vaibhav nikam wrote: > Hi, > > You can check with CenturyLink > > Regards > ------------ > Vaib > > On Mon, Feb 9, 2015 at 12:46 PM, Max Tulyev wrote: > >> Hi! >> >> If you have he.net there - it will be the best choise. >> >> On 06.02.15 19:26, Colton Conor wrote: >>> We have a network that is single homed with Level3 at this time in >> Dallas. >>> They already have BGP and their own ASN and IP setup. Who would you >>> recommend for a second provider in Dallas to blend with Level3? Assuming >>> Level3 and this other provider would be the only two in the blend for a >>> long time to come? Client was talking to TWT, but now that they are being >>> bought by Level3 that doesn't make much sense. >>> >> From eugen at imacandi.net Mon Feb 9 13:13:48 2015 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Mon, 9 Feb 2015 15:13:48 +0200 Subject: Dynamic routing on firewalls. In-Reply-To: <20150209085952.GA4984@gsp.org> References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <6290.74.129.32.29.1423192783.iglou@webmail.iglou.com> <8EC4553E-CE27-4271-9671-809B72675748@delong.com> <20150209085952.GA4984@gsp.org> Message-ID: On Mon, Feb 9, 2015 at 10:59 AM, Rich Kulawiec wrote: > On Sun, Feb 08, 2015 at 11:40:56AM -0200, BPNoC Group wrote: > > Firewalls are firewalls. Routers are routers. Routers should do some very > > basic filtering (stateles, ACLs, data plane protection...) and firewalls > > should do basic static routing. And things should not go far beyond that. > > This is, at a network level, an echo of the "Software Tools" philosophy > that has served us exceedingly well for decades. Tools should do one > thing, they should do it well, and if/when we need to do more than one > thing, we should use tools in combination. > And then reality comes and disagrees with you :) I am a fan of the "use the right tool for the right job", but it is not always possible due to economical/technical/political reasons. I had situations where running dynamic routing on firewalls was the way to go to allow for geographic distribution of traffic without having to touch routers and/or firewalls when adding/deleting subnets. Devices would just learn routes and if permitted by the firewalls, traffic would pass. > There's another advantage to this: if firewalls and routers &etc > are not the same system, then they can run different software on > different operating systems on different architectures -- providing > a significant measure of insulation against attacks unique to one > particular combination. > > This is a bit of a fallacy, because considering all things equal, a router looks at only Layer 3/4 headers to route a packet, whereby a firewall will look more deeper up the stack (considering a simple scenario, not considering MPLS stuff). Even if they run the same OS but with different functions enabled, a firewall having a vulnerability because it mishandles TCP packets with SYN/RST flags set, it does not mean it will be vulnerable as a router. I know companies running firewall back to back from different vendors just to make sure that they are secure if someone "hacks" one of the firewalls. My point is that: 1) you can run dynamic routing on a firewall without issues 2) it depends on the situation if it advisable to do so 3) there is no size fits all scenario whereby it is verboten to have anything else than static routes on a firewall 4) you have to consider the pros/cons about doing it or not doing it From Valdis.Kletnieks at vt.edu Mon Feb 9 13:16:02 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 Feb 2015 08:16:02 -0500 Subject: Has anyone imagined what could be the future HCI In-Reply-To: Your message of "Mon, 09 Feb 2015 01:48:01 +0000." References: Message-ID: <207976.1423487762@turing-police.cc.vt.edu> On Mon, 09 Feb 2015 01:48:01 +0000, lobna gouda said: > Has anyone imagined this? away on increasing processing power or visual > clearance of what we already have, what could be the next HCI? Yes, somebody has imagined it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From eksffa at freebsdbrasil.com.br Mon Feb 9 13:54:04 2015 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Mon, 9 Feb 2015 11:54:04 -0200 Subject: Dynamic routing on firewalls. In-Reply-To: <364F7CA4-9630-44E8-8494-28F786092965@delong.com> References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <18568D32-108A-4C17-9911-A7D468B938FA@freebsdbrasil.com.br> <364F7CA4-9630-44E8-8494-28F786092965@delong.com> Message-ID: > On 08/02/2015, at 22:48, Owen DeLong wrote: > >> >> On Feb 8, 2015, at 06:02 , Patrick Tracanelli wrote: >> >> Hello, >> >>> >>> Some Juniper models actually do a very good job of being both. >>> >>> In reality, a Firewall _IS_ a router, even if it's a bad one. Anything that moves packets from one interface to another is a router. >> >> Technically it’s quite not a precise assumption. While routing is much likely an IP core need and OSI Layer 3 related mechanism, a firewall does not have to basic L3 forwarding. It can be a bridged/bright firewall, may fit in front of a router, protecting it, and carrying. Not routing anything. In fact in a fail-safe scenario (from availability perspective) a bridged firewall may be shut down completely and a Bypass por pair taking place will keep traffic flowing, “moving packets from one port to another” without actually ever been a router. > > Technically true, but bridged firewalls are pretty much passe these days in the real world. As a general rule, when the firewall is shut down, one usually doesn’t want the packets flowing past un-hindered. The fact that this is kind of the default of what happens with bridged firewalls is just one of the many reasons hardly anyone still uses such a thing. Hello Owen, I didn’t get your point. On a bridged firewall you can have the behavior you want, whatever it is. Passing packets with firewall is down, but the box still up. Dropping everything if packet is down. Combining bypass ports + STP you can have the set of availability you wish better for your scenario, from simply bypassing everything like you have no box there, if a software or power failure occurs, or having an active failover bridged together on the bypass port, allowing for full firewalling redundancy if the primary box fails. So you are no leaking options if you are doing it on L2 instead of L3. You have additional ease, redundancy won’t require VRRP or similar stuff since it’s not L3 related. To clarify, I am not saying a bridged firewall is a better option for every sort of scenario. Usually I do L3 firewall with the box being an extra hop on the topology, doing CARP for IP reduncancy, etc. But back to the point that a firewall doesn’t need to L3 forward, I like the idea of having a L2 firewall whenever an extra routing hop is not desired, and still won’t lack features and redundancy options. >> I have recently added netmap-ipfw in front of BGP routers protecting ‘em from DDoS attacks, adding line-rate firewalling capabilities to a commodity x86/64 box or a T5 card for 10GbE/40GbE, and netmap-ipfw itself acts like mentioned, passing packets back and forth between interfaces without ever routing anything. > > Sure, there are all kinds of things one can do. Some of them are good ideas, many of them are not. If it works in your environment and you’re OK with the failure modes and other tradeoffs, then more power to you. I’m still missing what you are pointing as failure modes or tradeoffs. IPFW does a pretty decent job on L2 filtering, with a particular exception of “ipfw fwd” which won’t work by default under this setup. I can drop unwanted L2 traffic - in fact I like to only allow IPv4,v6 and ARP by default on LLC, cisco discovery and RARP when needed, everything else dropped on L2. Therefore whenever I decide to add it bright, I still don’t miss anything. >>> Of course, the support for routing protocols is a useful feature in a router and one of the areas where firewalls often fall short. >>> >>> Where you want to put things (in front, behind, etc.) really depends on your topology and the problem you are trying to solve. >>> >>> Personally, I like to keep the firewalls as close to the end hosts as possible. This tends to greatly simplify security policies and make them MUCH easier (and more reliable) to audit. >> >> I agree. A firewall belongs better closer to the end hosts being protected. Maybe protection of the router is the only exception when RTBH will not fit the task (or just won’t be enough). > > DDoS mitigation on site is a questionable and usually losing proposition at best. Other than DDoS mitigation, any good router should be perfectly capable of protecting itself. For protecting a router from DDoS that it cannot properly protect itself, one needs to be able to control or alter the delivery of packets across the upstream link from the upstream side anyway. That is best done by an off-site service such as Akamai’s Prolexic. Sadly true just in theory. On real world, people still run weak and low power boxes as routers, ranging from old Cisco boxes to Routerboards, Edgerouters and x86 boxes without any special card or technologies such as DNA, DPDK, Netmap, and therefore boxes that can’t hardly protect themselves against simple DDoS, while they still can route and do their job on calm water, won’t behave well on storms. We are not always talking about big telcos and people who can rely on an efficient and well dimensioned Juniper box. Frequently, the “routers vs firewall” or “stateful vs stateles on the same box” confusion discussed on other recent threads in this group, just happens, and we get relatively big companies adding stuff like sonicwalls, fortinets, with BGP + a mix of security features on the same box, and certainly those boxes can’t hardly protect itself (but people still believe they can protect the whole network behind it). So, whether it’s caused by low power boxes or bad projects, the need for router protection is more often than it should. >> Therefore, close to the end host usually means far from the core routers. Unless one is really considering a CPE device doing poorly jobs of “a router and a firewall”… > > Depends on the nature of your network. I know lots of datacenter networks where the end hosts are not more than one or two hops removed from the core routers. I would hardly refer to those networks as a CPE device doing a poor job of “router and firewall”. Yes, I may refer to a linux box, a VyOS, Endian, OpenBSD PF or a sonicwall box 2 hops after the core router a bad option for accumulating router+firewall functions if they are not protected on upper hops. Not due to any kind of feature or scalability miss (except for OpenBSD’s kernel and therefore firewall not scaling beyond CPU0). But due to their default behavior ranging from not protecting data plane from simple problems like ARP storm, up to the fact they will, by default, waste state entries for ordinary stuff like filtering. So, yes, they are usually doing poor jobs of being a router and a firewall. We see it very often, co-location setups failing due to exhaustion of resources or inability to self protect when uncalm packet flows reach their racks on data centers, but still the whole DC and previous hops still run perfectly up, available and unaffected. Sure it’s when they will earn/charge extra by adding firewall services… because customer boxes where doing their poor jobs of being both. So, back to the point, unless very well projected or engineered, they will need earlier protection. I have just recently run into a situation where a Fortigate box that should add protection and balancing on a data center colo, just died exhausted by simple memory starvation. No matter the real cause (people tend to use those boxes doing everything they can do at once, and expecting it to work under uncontrolled circumstances), for the customer it was their core node. For the datacenter it was an end host. For me it was just a box doing bad jobs of being more than it should at once, and it had to be protected. A couple months ago I have run into another scenario where a Juniper MX5 box was suffering from UDP DDoS with low packet size. It’s still not clear for me why Juniper was not sustaining the attack traffic, if it was a bad configuration or because the pps rate was close to 1GbE ports line rate limit, and the company in question didn’t want to pay for MX series upgrade to have 10G ports just for attack contention. We added a netmap-ipfw in front of the Juniper box with T5 10GbE ports filtering the profiled packet sized, and filtering other UDP patterns, which lead the Juniper box to do it’s routing job again without ever being upgraded to 10G licensed MX versions. Sure an off-site protection would do the job before upstream. But no need for that many gun powder to kill such a small sized animal :) And just like most DDoS, it didn’t least forever. And again, it was a non L3 forwarding firewall; no extra hop or relevant change in the topology. Sure L3 firewalls are more usual, it’s always been, it’s not a “nowadays” momentum. But a bright firewall still have its relevant place in the network, and it’s a firewall with no missing piece of functionality, IMHE. -- Patrick Tracanelli From Valdis.Kletnieks at vt.edu Mon Feb 9 14:14:16 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 Feb 2015 09:14:16 -0500 Subject: Dynamic routing on firewalls. In-Reply-To: Your message of "Mon, 09 Feb 2015 11:54:04 -0200." References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <18568D32-108A-4C17-9911-A7D468B938FA@freebsdbrasil.com.br> <364F7CA4-9630-44E8-8494-28F786092965@delong.com> Message-ID: <211781.1423491256@turing-police.cc.vt.edu> On Mon, 09 Feb 2015 11:54:04 -0200, Patrick Tracanelli said: > On a bridged firewall you can have the behavior you want, whatever it is. Passing packets with firewall is down, but the box still up. Owen's point is that passing packets if the firewall is down is really poor security-wise. If you run in that configuration, I simply DoS your firewall (probably from one set of IP addresses), and then once it has fallen over and is being bypassed, I send my *real* malicious traffic from some other IP address, totally uninspected and unhindered. Much hilarity, hijinks, and pwnage ensues. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From lobna_gouda at hotmail.com Mon Feb 9 14:24:48 2015 From: lobna_gouda at hotmail.com (lobna gouda) Date: Mon, 9 Feb 2015 14:24:48 +0000 Subject: Has anyone imagined what could be the future HCI In-Reply-To: <207976.1423487762@turing-police.cc.vt.edu> References: , <207976.1423487762@turing-police.cc.vt.edu> Message-ID: Thanks Valdis! i am sure someone has imagined it:) was asking about the community imagination , my though it would be all virtualized on the cloud, on a bigger scale not the one we have now. Were it will end up not to buy any laptops, smartphone...etc. No processing or availability limits, your views? > To: lobna_gouda at hotmail.com > CC: nanog at nanog.org > Subject: Re: Has anyone imagined what could be the future HCI > From: Valdis.Kletnieks at vt.edu > Date: Mon, 9 Feb 2015 08:16:02 -0500 > > On Mon, 09 Feb 2015 01:48:01 +0000, lobna gouda said: > > Has anyone imagined this? away on increasing processing power or visual > > clearance of what we already have, what could be the next HCI? > > Yes, somebody has imagined it. > From Valdis.Kletnieks at vt.edu Mon Feb 9 14:33:58 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 Feb 2015 09:33:58 -0500 Subject: Has anyone imagined what could be the future HCI In-Reply-To: Your message of "Mon, 09 Feb 2015 14:24:48 +0000." References: , <207976.1423487762@turing-police.cc.vt.edu> Message-ID: <212783.1423492438@turing-police.cc.vt.edu> On Mon, 09 Feb 2015 14:24:48 +0000, lobna gouda said: > Thanks Valdis! i am sure someone has imagined it:) was asking about the > community imagination - my though it would be all virtualized on the cloud HCI can't be in the cloud. MCI has to happen in the same room as the H. And this is the wrong place to ask - for the most part, this list is about moving the bytes across the wires, so mostly leve 2-4 in the stack. Level 6-7 is for someplace else to discuss. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From eksffa at freebsdbrasil.com.br Mon Feb 9 14:56:37 2015 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Mon, 9 Feb 2015 12:56:37 -0200 Subject: Dynamic routing on firewalls. In-Reply-To: <211781.1423491256@turing-police.cc.vt.edu> References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <18568D32-108A-4C17-9911-A7D468B938FA@freebsdbrasil.com.br> <364F7CA4-9630-44E8-8494-28F786092965@delong.com> <211781.1423491256@turing-police.cc.vt.edu> Message-ID: <15CE3299-E2B7-47B5-9050-CD4061EE3E3B@freebsdbrasil.com.br> > On 09/02/2015, at 12:14, Valdis.Kletnieks at vt.edu wrote: > > On Mon, 09 Feb 2015 11:54:04 -0200, Patrick Tracanelli said: > >> On a bridged firewall you can have the behavior you want, whatever it is. Passing packets with firewall is down, but the box still up. > > Owen's point is that passing packets if the firewall is down is really poor > security-wise. If you run in that configuration, I simply DoS your firewall > (probably from one set of IP addresses), and then once it has fallen over and > is being bypassed, I send my *real* malicious traffic from some other IP > address, totally uninspected and unhindered. Much hilarity, hijinks, and > pwnage ensues. Hello Valdis, If this is really the point, I don’t know what system you are talking about, that will behave like that. If I run a closed firewall, kernel-path, and it’s unable process, and therefore “allow” the traffic, it will drop. If I run it netmap-ipfw and it’s unable to move the packet from one port to the other, it will drop. So there’s no point where a bridge implicits traffic bypass upon starvation/exaustion, unless this is your option to do so, or a default system behavior, in this case a system that should not act for this purpose. If I remember well (and I remember some effusive expressions like “L2 functions easily enabled at scale on a Junos Trio system”), on a Juniper box bridging is processed on Trio chip - even without IRB set up, as well as firewall (limited matching conditions in a bridged domain). If you can exhaust TRIO from your DoS approach (and the idea is that you can’t exhaust it without exhausting line rate first), you will have no bridging anyway, since L2 learning and forwarding will also be resource starved. But this is just all theoretical, as I mentioned you will probably reach line rate limit first if the box is not configured wrong or wrongly planned. -- Patrick Tracanelli From Valdis.Kletnieks at vt.edu Mon Feb 9 15:25:45 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 Feb 2015 10:25:45 -0500 Subject: Dynamic routing on firewalls. In-Reply-To: Your message of "Mon, 09 Feb 2015 12:56:37 -0200." <15CE3299-E2B7-47B5-9050-CD4061EE3E3B@freebsdbrasil.com.br> References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <18568D32-108A-4C17-9911-A7D468B938FA@freebsdbrasil.com.br> <364F7CA4-9630-44E8-8494-28F786092965@delong.com> <211781.1423491256@turing-police.cc.vt.edu> <15CE3299-E2B7-47B5-9050-CD4061EE3E3B@freebsdbrasil.com.br> Message-ID: <215947.1423495545@turing-police.cc.vt.edu> On Mon, 09 Feb 2015 12:56:37 -0200, Patrick Tracanelli said: > > On 09/02/2015, at 12:14, Valdis.Kletnieks at vt.edu wrote: > > On Mon, 09 Feb 2015 11:54:04 -0200, Patrick Tracanelli said: > >> On a bridged firewall you can have the behavior you want, whatever it is. Passing packets with firewall is down, but the box still up. > > > > Owen's point is that passing packets if the firewall is down is really poor > > security-wise. If you run in that configuration, I simply DoS your firewall > > (probably from one set of IP addresses), and then once it has fallen over and > > is being bypassed, I send my *real* malicious traffic from some other IP > > address, totally uninspected and unhindered. Much hilarity, hijinks, and > > pwnage ensues. > > Hello Valdis, > > If this is really the point, I don���t know what system you are talking about The one *you* mentioned - "passing packets with firewall is down". Owen was pointing out that is a silly configuration: On 08/02/2015, at 22:48, Owen DeLong wrote: > Technically true, but bridged firewalls are pretty much passe these days in the > real world. As a general rule, when the firewall is shut down, one usually > doesn���t want the packets flowing past un-hindered. The fact that this is kind > of the default of what happens with bridged firewalls is just one of the many > reasons hardly anyone still uses such a thing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From eksffa at freebsdbrasil.com.br Mon Feb 9 15:47:10 2015 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Mon, 9 Feb 2015 13:47:10 -0200 Subject: Dynamic routing on firewalls. In-Reply-To: <215947.1423495545@turing-police.cc.vt.edu> References: <4715C1CF-2944-4025-8C04-1AED5DCD19D1@nines.nl> <18568D32-108A-4C17-9911-A7D468B938FA@freebsdbrasil.com.br> <364F7CA4-9630-44E8-8494-28F786092965@delong.com> <211781.1423491256@turing-police.cc.vt.edu> <15CE3299-E2B7-47B5-9050-CD4061EE3E3B@freebsdbrasil.com.br> <215947.1423495545@turing-police.cc.vt.edu> Message-ID: <02710116-929D-4DAE-BE82-EE1BB3E2D83F@freebsdbrasil.com.br> > On 09/02/2015, at 13:25, Valdis.Kletnieks at vt.edu wrote: > > On Mon, 09 Feb 2015 12:56:37 -0200, Patrick Tracanelli said: >>> On 09/02/2015, at 12:14, Valdis.Kletnieks at vt.edu wrote: >>> On Mon, 09 Feb 2015 11:54:04 -0200, Patrick Tracanelli said: >>>> On a bridged firewall you can have the behavior you want, whatever it is. Passing packets with firewall is down, but the box still up. >>> >>> Owen's point is that passing packets if the firewall is down is really poor >>> security-wise. If you run in that configuration, I simply DoS your firewall >>> (probably from one set of IP addresses), and then once it has fallen over and >>> is being bypassed, I send my *real* malicious traffic from some other IP >>> address, totally uninspected and unhindered. Much hilarity, hijinks, and >>> pwnage ensues. >> >> Hello Valdis, >> >> If this is really the point, I don’t know what system you are talking about > > The one *you* mentioned - "passing packets with firewall is down". Owen > was pointing out that is a silly configuration: An explicit decision regarding bypass ports, as I mentioned if someone does not want a redundant approach and doesn’t want availability issues if power is down or system is overloaded. Not an inherit behavior or a must. Not related to being L2 our L3. Just a mentioned possibility. Not a limitation, not a recommendation. In the previous e-mail I mentioned “whatever option you want” upon failure, traffic still flowing, traffic bypassed, traffic dropped, L2+STP redundancy, no redundancy at all. So please don’t refer to one single option and pointing it as a failure of the methodology nature if you consider a decision/project error, and in this case just do it the other way, opting out from bypass and dropping or failing over, upon exhaustion or failure. Back to the point, doesn’t have to be different or limited from what you get in L3 firewalling. > > On 08/02/2015, at 22:48, Owen DeLong wrote: >> Technically true, but bridged firewalls are pretty much passe these days in the >> real world. As a general rule, when the firewall is shut down, one usually >> doesn’t want the packets flowing past un-hindered. The fact that this is kind >> of the default of what happens with bridged firewalls is just one of the many >> reasons hardly anyone still uses such a thing. -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601 at sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From v.bajpai at jacobs-university.de Mon Feb 9 16:19:36 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Mon, 9 Feb 2015 16:19:36 +0000 Subject: [request]: host a probe for v6 measurements In-Reply-To: <8B0BCD73-0EC1-462A-A303-6FA710A237DC@jacobs-university.de> References: <8B0BCD73-0EC1-462A-A303-6FA710A237DC@jacobs-university.de> Message-ID: Dear NANOG, > On 19 Jan 2015, at 14:33, Bajpai, Vaibhav wrote: [...] > We are currently looking for volunteers in US with native IPv6 lines > to help us in our v6 measurement research. Thanks to you, we have shipped 15 probes to North America (some of which are already starting to come up online). Here [1] is the current situation of our SamKnows deployment. [1] http://goo.gl/E1DIZr We still have probes that we can ship out. If you happen to receive native v6 connectivity (residential or otherwise) irrespective of your location and would like to help us out, get in touch with us. Thank you so much! Best, Vaibhav ===================================================== Vaibhav Bajpai Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From JKrejci at usinternet.com Mon Feb 9 16:32:43 2015 From: JKrejci at usinternet.com (Justin Krejci) Date: Mon, 9 Feb 2015 16:32:43 +0000 Subject: Comcast Static IP Changed With New Modem? Message-ID: <3E9C67DA261AC349B60FF3609F5E211D716D5B88@USI-2K10EX01-MT.usicorp.usinternet.com> Has anyone run into the situation where their static IP address from Comcast (on the business class cable modem Internet service) was changed when the modem was replaced? We have a remote site that uses Comcast as a backup Internet connection and when we went to use it recently our VPN tunnel would not establish. After working with the Comcast support group we discovered Comcast changed our static IP address. I am working through trying to figure out the when and the why with Comcast still and suspect it was changed when the modem was replaced back in December. The modem was replaced by Comcast as our previous modem was apparently EOL'ed. We're now setting up additional monitoring to verify the accessibility of our remote site via the Comcast connection so we don't have any future uh-ohs when we need to use our backup connection and it too is not fully functional. TIA, -Justin From lists at mtin.net Mon Feb 9 16:41:34 2015 From: lists at mtin.net (Justin Wilson - MTIN) Date: Mon, 9 Feb 2015 11:41:34 -0500 Subject: Comcast Static IP Changed With New Modem? In-Reply-To: <3E9C67DA261AC349B60FF3609F5E211D716D5B88@USI-2K10EX01-MT.usicorp.usinternet.com> References: <3E9C67DA261AC349B60FF3609F5E211D716D5B88@USI-2K10EX01-MT.usicorp.usinternet.com> Message-ID: Seen this happen quite often with Comcast. They simply didn’t provision the new modem. A simple call to them should correct it. Done it two or 3 times in the past 6 months. Justin Justin Wilson j2sw at mtin.net http://www.mtin.net Managed Services – xISP Solutions – Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering – Transit – Internet Exchange > On Feb 9, 2015, at 11:32 AM, Justin Krejci wrote: > > Has anyone run into the situation where their static IP address from Comcast (on the business class cable modem Internet service) was changed when the modem was replaced? > > We have a remote site that uses Comcast as a backup Internet connection and when we went to use it recently our VPN tunnel would not establish. After working with the Comcast support group we discovered Comcast changed our static IP address. I am working through trying to figure out the when and the why with Comcast still and suspect it was changed when the modem was replaced back in December. The modem was replaced by Comcast as our previous modem was apparently EOL'ed. > > We're now setting up additional monitoring to verify the accessibility of our remote site via the Comcast connection so we don't have any future uh-ohs when we need to use our backup connection and it too is not fully functional. > > TIA, > -Justin > From zeusdadog at gmail.com Mon Feb 9 16:48:09 2015 From: zeusdadog at gmail.com (Jay Nakamura) Date: Mon, 9 Feb 2015 11:48:09 -0500 Subject: Comcast Static IP Changed With New Modem? In-Reply-To: <3E9C67DA261AC349B60FF3609F5E211D716D5B88@USI-2K10EX01-MT.usicorp.usinternet.com> References: <3E9C67DA261AC349B60FF3609F5E211D716D5B88@USI-2K10EX01-MT.usicorp.usinternet.com> Message-ID: Yes, this is very common. You are lucky to even get a working static IP when they replace a modem. A lot of times they forget to assign one or assigned one that doesn't work. No, most of the time they won't tell you the IP changed. Couple time I was told where my IP and default gateway wasn't in the same subnet. (example, static IP was x.x.x.4/30 and default gateway was x.x.x.3). Surprisingly, it didn't work. It took me 30 minutes each time to convince them that won't work. On Mon, Feb 9, 2015 at 11:32 AM, Justin Krejci wrote: > Has anyone run into the situation where their static IP address from > Comcast (on the business class cable modem Internet service) was changed > when the modem was replaced? > > We have a remote site that uses Comcast as a backup Internet connection > and when we went to use it recently our VPN tunnel would not establish. > After working with the Comcast support group we discovered Comcast changed > our static IP address. I am working through trying to figure out the when > and the why with Comcast still and suspect it was changed when the modem > was replaced back in December. The modem was replaced by Comcast as our > previous modem was apparently EOL'ed. > > We're now setting up additional monitoring to verify the accessibility of > our remote site via the Comcast connection so we don't have any future > uh-ohs when we need to use our backup connection and it too is not fully > functional. > > TIA, > -Justin > From josh at imaginenetworksllc.com Mon Feb 9 16:49:45 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 9 Feb 2015 11:49:45 -0500 Subject: Comcast Static IP Changed With New Modem? In-Reply-To: References: <3E9C67DA261AC349B60FF3609F5E211D716D5B88@USI-2K10EX01-MT.usicorp.usinternet.com> Message-ID: With Time Warner Cable in my region that is expected 100% of the time. Every single cable modem replacement requires you to initialize the static IP configuration. I expect the cable operators to operate similarly. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Feb 9, 2015 at 11:41 AM, Justin Wilson - MTIN wrote: > Seen this happen quite often with Comcast. They simply didn’t provision > the new modem. A simple call to them should correct it. Done it two or 3 > times in the past 6 months. > > Justin > > > Justin Wilson j2sw at mtin.net > http://www.mtin.net > Managed Services – xISP Solutions – Data Centers > http://www.thebrotherswisp.com > Podcast about xISP topics > http://www.midwest-ix.com > Peering – Transit – Internet Exchange > > > On Feb 9, 2015, at 11:32 AM, Justin Krejci > wrote: > > > > Has anyone run into the situation where their static IP address from > Comcast (on the business class cable modem Internet service) was changed > when the modem was replaced? > > > > We have a remote site that uses Comcast as a backup Internet connection > and when we went to use it recently our VPN tunnel would not establish. > After working with the Comcast support group we discovered Comcast changed > our static IP address. I am working through trying to figure out the when > and the why with Comcast still and suspect it was changed when the modem > was replaced back in December. The modem was replaced by Comcast as our > previous modem was apparently EOL'ed. > > > > We're now setting up additional monitoring to verify the accessibility > of our remote site via the Comcast connection so we don't have any future > uh-ohs when we need to use our backup connection and it too is not fully > functional. > > > > TIA, > > -Justin > > > > From bob at FiberInternetCenter.com Mon Feb 9 16:55:46 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 9 Feb 2015 08:55:46 -0800 Subject: Has anyone imagined what could be the future HCI In-Reply-To: References: , <207976.1423487762@turing-police.cc.vt.edu> Message-ID: <28887072e961614d9eb466c25083fec0.squirrel@66.201.44.180> This group is the most imaginative I have ever participated in. I imagine stuff like that all the time. Most here love science & "fiction". Helps makes for good group of problems solvers. At NANOG meetings I often imagine it as a comic con without all the dressing up. :-) However, the discussions here are about issues and problems directly related equipment and configurations of moving packets. Imagine this...if we discussed other stuff we would become so distracted, we would probably never get much done and everyone's Internet would suck. Thank You Bob Evans CTO Fiber Internet Center The views expressed are my own and are often stolen, acquired or somehow become those of others before I get to profit on them. But, I don't care. :-) > Thanks Valdis! i am sure someone has imagined it:) was asking about the > community imagination , my though it would be all virtualized on the > cloud, on a bigger scale not the one we have now. Were it will end up not > to buy any laptops, smartphone...etc. No processing or availability > limits, your views? > >> To: lobna_gouda at hotmail.com >> CC: nanog at nanog.org >> Subject: Re: Has anyone imagined what could be the future HCI >> From: Valdis.Kletnieks at vt.edu >> Date: Mon, 9 Feb 2015 08:16:02 -0500 >> >> On Mon, 09 Feb 2015 01:48:01 +0000, lobna gouda said: >> > Has anyone imagined this? away on increasing processing power or >> visual >> > clearance of what we already have, what could be the next HCI? >> >> Yes, somebody has imagined it. >> > From Cliff.Bowles at apollo.edu Mon Feb 9 19:54:46 2015 From: Cliff.Bowles at apollo.edu (Cliff Bowles) Date: Mon, 9 Feb 2015 19:54:46 +0000 Subject: Need recommendations for high-feature, high-density L3 Switch Message-ID: We have some aging infrastructure and need to start budgeting next-gen. * The network has several small routers as individual edges to peers, WAN, SIP services. * It has a couple 6509s as Internet edge (full tables, 2 carriers, no transit, simple policies) * It has some Nexus 7K as an aggregation layer for all the server pods * It has some 6509s as a backbone to interconnect the aggregation layers and inter-site links. * We do run VRFs/MPLS across our backbone with L3, L2 and L1 services. Nothing super fancy, but it's a requirement. Two approaches: 1 - Look at ASR9010 (or something similar) to replace all of the above. Pros: It has the density, it has features, port buffers, seems to have good granular virtualization, seems to have a good reputation amongst heavy users. Cons: It is very expensive fully populated and there is some oversubscription on the higher-density cards. 2 - Look at one solution to consolidate all edge routers and a separate solution to consolidate backbone/aggregation. Pros: Less density required at the edge layers, so a cheaper solution is possible; Not requiring full BGP tables and port buffers at the backbone/agg layer widens the selection a LOT considering the number of vendors with high-feature/high-density L3 switches. Cons: Now we are looking at 4 boxes per data center rather than 2. So... Is there something in the same class as the ASR9000s that also have a good reputation? Will need at least 48 ports of 10G, 24x1Gb, limited oversubscription, good feature sets, not astronomically priced. If we can't find the perfect fit, we will just look at two separate solutions. Also... has anyone used a CSR1000v or Vyatta VM-based solution on something like a Pluribus? I know you can run them on any server, but there are vendors like Pluribus who integrate the server hardware with a full-feature physical switch. (Their E68 is the one we are considering) I'm assuming you aren't going to get anywhere near the features and performance of an ASR9010, but... can you get close? Thanks. CWB From corbe at corbe.net Mon Feb 9 20:18:22 2015 From: corbe at corbe.net (Daniel Corbe) Date: Mon, 09 Feb 2015 15:18:22 -0500 Subject: Need recommendations for high-feature, high-density L3 Switch In-Reply-To: (Cliff Bowles's message of "Mon, 9 Feb 2015 19:54:46 +0000") References: Message-ID: <874mquj0tt.fsf@corbe.net> Cliff Bowles writes: > We have some aging infrastructure and need to start budgeting next-gen. > > > * The network has several small routers as individual edges to peers, WAN, SIP services. > > * It has a couple 6509s as Internet edge (full tables, 2 carriers, no transit, simple policies) > > * It has some Nexus 7K as an aggregation layer for all the server pods > > * It has some 6509s as a backbone to interconnect the aggregation layers and inter-site links. > > * We do run VRFs/MPLS across our backbone with L3, L2 and L1 > services. Nothing super fancy, but it's a requirement. You could always roll the 6509s into 6800 series stuff if you're married to Cisco for Campus style switches in your distribution network. But I really hate the Sup2T. In my admittedly limited scope, they have a pretty high failure rate. If you want something simple that still supports MPLS and VPLS, you can't really beat Brocade for port density. I getting ready to rip out 6 sets of 6509s and replace them with 16 slot MLXe chasis. And if I were in your shoes I'd be looking at either ASR9K or Juniper MX series stuff to replace the 6509s that you have on your edge. I can't speak much for the server-facing stuff on your network though. -Daniel From elouie at techintegrity.com Mon Feb 9 20:41:13 2015 From: elouie at techintegrity.com (Eric Louie) Date: Mon, 9 Feb 2015 12:41:13 -0800 Subject: mpls over microwave In-Reply-To: <54D5CAD5.4000909@seacom.mu> References: <20150205135504.39F63F7A@m0048136.ppops.net> <54D5CAD5.4000909@seacom.mu> Message-ID: because I have a partial implementation of MPLS routers. Whether the routers support MPLS or not, the routing on an OSPF level doesn't depend on MPLS being enabled. Eventually everything will be MPLS-capable. The MPLS network is not multiple-path. The OSPF network is. On Sat, Feb 7, 2015 at 12:20 AM, Mark Tinka wrote: > > On 6/Feb/15 00:31, Eric Louie wrote: > > I work for a fixed wireless provider, and our mpls-capable backhauls are > > all running mpls with 9200 MTU with no problem. The only weirdness I > > encounter is if I have multiple equal-cost routes to the same location, > one > > over MPLS and one not, end up having ping/unreachable issues from my > > monitoring equipment. The solution has been to cost one path (the MPLS) > > lower than the other. The only other problem I had was with radio's that > > didn't support larger 9000+ byte MTU packets - we've phased that radio > out > > for now. if you run MPLS with 1500 byte MTU, you'll have issues with > 1500 > > byte packets with the DF-bit set. That was a nasty discovery in the > > production network, your mileage will not vary with that problem. > > I'm curious why you'd have multiple paths in your network (equal-cost to > boot) where some support and others don't. > > Mark. > From smeuse at mara.org Mon Feb 9 20:55:53 2015 From: smeuse at mara.org (Steve Meuse) Date: Mon, 9 Feb 2015 15:55:53 -0500 Subject: Need recommendations for high-feature, high-density L3 Switch In-Reply-To: References: Message-ID: On Mon, Feb 9, 2015 at 2:54 PM, Cliff Bowles wrote: > > 1 - Look at ASR9010 (or something similar) to replace all of the above. > Pros: It has the density, it has features, port buffers, seems to have good > granular virtualization, seems to have a good reputation amongst heavy > users. Cons: It is very expensive fully populated and there is some > oversubscription on the higher-density cards. > Depending on what level of redundancy you require, the 24x10 cards are not oversubscribed, and we've had good luck with them, and the platform in general. If you need 36x10 per slot, look at the 9912 chassis. The one card I would avoid is the 16x10, not due to any particular bug, but due to the way that it's oversubscribed. Two ports share a 15Gb/s NPU, depending on your port usage, that can be a major pain to deal with. -Steve From mark.tinka at seacom.mu Tue Feb 10 06:12:21 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 10 Feb 2015 08:12:21 +0200 Subject: Need recommendations for high-feature, high-density L3 Switch In-Reply-To: References: Message-ID: <54D9A145.3080005@seacom.mu> On 9/Feb/15 21:54, Cliff Bowles wrote: > So... Is there something in the same class as the ASR9000s that also have a good reputation? Will need at least 48 ports of 10G, 24x1Gb, limited oversubscription, good feature sets, not astronomically priced. If we can't find the perfect fit, we will just look at two separate solutions. If Cisco and Juniper are your friends, I'd certainly look into the MX and ASR9000 platforms. They are routers with decent Layer 2 features. You want that, rather than taking a switch that has decent Layer 3 features. On the MX and ASR9000, there is a line card for everyone. Just dig into it and you'll find what you need. Bear in mind that some line cards are available, but not yet advertised online, or are just about to go live. So talking to the vendors helps. Those with experience on other vendors can chime in. Mark. From mark.tinka at seacom.mu Tue Feb 10 06:13:21 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 10 Feb 2015 08:13:21 +0200 Subject: Need recommendations for high-feature, high-density L3 Switch In-Reply-To: <874mquj0tt.fsf@corbe.net> References: <874mquj0tt.fsf@corbe.net> Message-ID: <54D9A181.3060901@seacom.mu> On 9/Feb/15 22:18, Daniel Corbe wrote: > You could always roll the 6509s into 6800 series stuff if you're married > to Cisco for Campus style switches in your distribution network. But I > really hate the Sup2T. In my admittedly limited scope, they have a > pretty high failure rate. We run 6880's as our core switches (Layer 2 only, though), and have been happy with them. One was DoA, and another needed a fan tray replacement. But these are only 2x units out of over 20x, so not too bad. Mark. From tb at tburke.us Tue Feb 10 08:03:58 2015 From: tb at tburke.us (Tim Burke) Date: Tue, 10 Feb 2015 02:03:58 -0600 Subject: UVerse question In-Reply-To: <4EDAE180-503A-4C88-9101-5A77A3EEA90C@oitc.com> References: <4EDAE180-503A-4C88-9101-5A77A3EEA90C@oitc.com> Message-ID: <2265F892-8E5F-437F-9B3B-2BEA0D1374FF@tburke.us> What is a “4wire” modem? Is that a Chinese knockoff of a 2wire brand? ;-) Or are you referring to a pair-bonded modem? AT&T seems to only offer the pair-bonded device (in most cases, a Motorola NVG589) when you have their 45mbps “Power” service. If anything, you could always upgrade to the 45mbps service just to get the new modem, and then downgrade after you get the modem installed. The newer modems, including the 589, provide IPv6 support using 6rd. The compatibility test previously mentioned will determine if your current device is capable of IPv6. The older equipment has firmware updates available that will provide IPv6 connectivity. > On Feb 8, 2015, at 4:48 PM, TR Shaw wrote: > > Any suggestions on what to tell ATT to get IPv6 added to a current account and upgrade a 2wire router to 4wire with halfway decent performance and capability? > > Any and all help would be appreciated. > > Tom From khelms at zcorum.com Tue Feb 10 13:25:15 2015 From: khelms at zcorum.com (Scott Helms) Date: Tue, 10 Feb 2015 08:25:15 -0500 Subject: UVerse question In-Reply-To: <2265F892-8E5F-437F-9B3B-2BEA0D1374FF@tburke.us> References: <4EDAE180-503A-4C88-9101-5A77A3EEA90C@oitc.com> <2265F892-8E5F-437F-9B3B-2BEA0D1374FF@tburke.us> Message-ID: AT&T will do a bonded VDSL2 connection in cases where a single connection isn't getting enough throughput. Also, be aware that the device may now be branded as an Arris, but Tim is correct that it's normally a NVG589 for new installs. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Tue, Feb 10, 2015 at 3:03 AM, Tim Burke wrote: > What is a “4wire” modem? Is that a Chinese knockoff of a 2wire brand? ;-) > Or are you referring to a pair-bonded modem? > > AT&T seems to only offer the pair-bonded device (in most cases, a Motorola > NVG589) when you have their 45mbps “Power” service. If anything, you could > always upgrade to the 45mbps service just to get the new modem, and then > downgrade after you get the modem installed. The newer modems, including > the 589, provide IPv6 support using 6rd. > > The compatibility test previously mentioned will determine if your current > device is capable of IPv6. The older equipment has firmware updates > available that will provide IPv6 connectivity. > > > On Feb 8, 2015, at 4:48 PM, TR Shaw wrote: > > > > Any suggestions on what to tell ATT to get IPv6 added to a current > account and upgrade a 2wire router to 4wire with halfway decent performance > and capability? > > > > Any and all help would be appreciated. > > > > Tom > > From rps at maine.edu Tue Feb 10 13:31:22 2015 From: rps at maine.edu (Ray Soucy) Date: Tue, 10 Feb 2015 08:31:22 -0500 Subject: FTTx Active-Ethernet Hardware Message-ID: One thing I'm personally interested in is the growth of municipal FTTx that's starting to happen around the US and possibly applying that model to highly rural areas (e.g. 10 mile long town with no side streets, existing utility polls, 250 or so homes) and doing a realistic cost analysis of what that would take. What options are out there for Active-Ethernet hardware. Ideally something that could handle G.8032 and 802.1ad in hardware for the distribution side (24 or 48-port SFP metro switch) and something inexpensive for the access side but still managed (e.g. a 4-port switch with an SFP uplink supporting Q-in-Q). I'm really looking for something cheap to keep costs down for a proof-of-concept. The stuff from Cisco and even Ciena is a bit more expensive than my target. -- 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 nanog at ics-il.net Tue Feb 10 13:34:30 2015 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 10 Feb 2015 07:34:30 -0600 (CST) Subject: FTTx Active-Ethernet Hardware In-Reply-To: Message-ID: <15020604.4147.1423575243412.JavaMail.mhammett@ThunderFuck> Check out Mikrotik, Planet and TP-Link. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Ray Soucy" To: "NANOG" Sent: Tuesday, February 10, 2015 7:31:22 AM Subject: FTTx Active-Ethernet Hardware One thing I'm personally interested in is the growth of municipal FTTx that's starting to happen around the US and possibly applying that model to highly rural areas (e.g. 10 mile long town with no side streets, existing utility polls, 250 or so homes) and doing a realistic cost analysis of what that would take. What options are out there for Active-Ethernet hardware. Ideally something that could handle G.8032 and 802.1ad in hardware for the distribution side (24 or 48-port SFP metro switch) and something inexpensive for the access side but still managed (e.g. a 4-port switch with an SFP uplink supporting Q-in-Q). I'm really looking for something cheap to keep costs down for a proof-of-concept. The stuff from Cisco and even Ciena is a bit more expensive than my target. -- 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 mark.tinka at seacom.mu Tue Feb 10 13:59:51 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 10 Feb 2015 15:59:51 +0200 Subject: FTTx Active-Ethernet Hardware In-Reply-To: References: Message-ID: <54DA0ED7.5090604@seacom.mu> On 10/Feb/15 15:31, Ray Soucy wrote: > I'm really looking for something cheap to keep costs down for a > proof-of-concept. The stuff from Cisco and even Ciena is a bit more > expensive than my target. I hear Cisco were discontinuing the ME2600X, but not sure if that is still happening. Do you find that unit too expensive still? Mark. From maxtul at netassist.ua Tue Feb 10 14:25:40 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Tue, 10 Feb 2015 16:25:40 +0200 Subject: FTTx Active-Ethernet Hardware In-Reply-To: <15020604.4147.1423575243412.JavaMail.mhammett@ThunderFuck> References: <15020604.4147.1423575243412.JavaMail.mhammett@ThunderFuck> Message-ID: <54DA14E4.9020201@netassist.ua> We are using TP-LINK for ETTH, and it seems very good with a fair price. Only the problem is they like to make completely another device and sell it as the same part number but another "hardware revision" which is only written by small letters on the device itself. So you have to keep an eye on it. On 10.02.15 15:34, Mike Hammett wrote: > Check out Mikrotik, Planet and TP-Link. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Ray Soucy" > To: "NANOG" > Sent: Tuesday, February 10, 2015 7:31:22 AM > Subject: FTTx Active-Ethernet Hardware > > One thing I'm personally interested in is the growth of municipal FTTx > that's starting to happen around the US and possibly applying that > model to highly rural areas (e.g. 10 mile long town with no side > streets, existing utility polls, 250 or so homes) and doing a > realistic cost analysis of what that would take. > > What options are out there for Active-Ethernet hardware. Ideally > something that could handle G.8032 and 802.1ad in hardware for the > distribution side (24 or 48-port SFP metro switch) and something > inexpensive for the access side but still managed (e.g. a 4-port > switch with an SFP uplink supporting Q-in-Q). > > I'm really looking for something cheap to keep costs down for a > proof-of-concept. The stuff from Cisco and even Ciena is a bit more > expensive than my target. > > > > From lists at billmerriam.com Tue Feb 10 14:41:27 2015 From: lists at billmerriam.com (Bill Merriam) Date: Tue, 10 Feb 2015 09:41:27 -0500 Subject: UVerse question In-Reply-To: <4EDAE180-503A-4C88-9101-5A77A3EEA90C@oitc.com> References: <4EDAE180-503A-4C88-9101-5A77A3EEA90C@oitc.com> Message-ID: <20150210094127.514b9de2@giga.billmerriam.com> On Sun, 8 Feb 2015 17:48:57 -0500 TR Shaw wrote: > Any suggestions on what to tell ATT to get IPv6 added to a current > account and upgrade a 2wire router to 4wire with halfway decent > performance and capability? > > Any and all help would be appreciated. > > Tom If ATT is still using 6rd then you don't need a hardware change to use it. 6rd is like a 6to4 tunnel with special features. You can run it on your router or other machines. Openwrt supports it. Here is a brief how to, google for more help: http://www.litech.org/6rd/ For ATT, basically, 2602:300::/28 (6rdPrefix/6rdPrefixLen) and 12.83.49.81 (6rdBRIPv4Address, which is an anycast) is all you need to get it running. IPv4MaskLen is 0 (use the whole IPv4 address within IPv6, but notice that due to 6rdPrefixLen being /28 (instead of the more conventional /32) you have to do some one-nibble shifting, but the plus side is that you do get a /60 in the end). If your IP number is not static then your IPv6 address won't be either. Of course you could always try 6to4, where the prefix is 2002::/16 and the anycast relay router is 192.88.99.1. This will work if ATT resolves the anycast address. Or you could set up a Hurricane Electric 6in4 tunnel. So, with ATT residential, I think you get 3 half assed choices, 6rd, 6in4 and 6to4 (if they support it). Bill From rps at maine.edu Tue Feb 10 14:42:09 2015 From: rps at maine.edu (Ray Soucy) Date: Tue, 10 Feb 2015 09:42:09 -0500 Subject: FTTx Active-Ethernet Hardware In-Reply-To: <15020604.4147.1423575243412.JavaMail.mhammett@ThunderFuck> References: <15020604.4147.1423575243412.JavaMail.mhammett@ThunderFuck> Message-ID: Price and functionality-wise Planet MGSW-28240F and GSD-1020S look pretty close to what I'm looking for. Anyone have real experience with using them on a large scale? Performance? On Tue, Feb 10, 2015 at 8:34 AM, Mike Hammett wrote: > Check out Mikrotik, Planet and TP-Link. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Ray Soucy" > To: "NANOG" > Sent: Tuesday, February 10, 2015 7:31:22 AM > Subject: FTTx Active-Ethernet Hardware > > One thing I'm personally interested in is the growth of municipal FTTx > that's starting to happen around the US and possibly applying that > model to highly rural areas (e.g. 10 mile long town with no side > streets, existing utility polls, 250 or so homes) and doing a > realistic cost analysis of what that would take. > > What options are out there for Active-Ethernet hardware. Ideally > something that could handle G.8032 and 802.1ad in hardware for the > distribution side (24 or 48-port SFP metro switch) and something > inexpensive for the access side but still managed (e.g. a 4-port > switch with an SFP uplink supporting Q-in-Q). > > I'm really looking for something cheap to keep costs down for a > proof-of-concept. The stuff from Cisco and even Ciena is a bit more > expensive than my target. > > > > > -- > 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 > -- 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 swmike at swm.pp.se Tue Feb 10 14:43:12 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 10 Feb 2015 15:43:12 +0100 (CET) Subject: FTTx Active-Ethernet Hardware In-Reply-To: References: Message-ID: On Tue, 10 Feb 2015, Ray Soucy wrote: > What options are out there for Active-Ethernet hardware. Ideally > something that could handle G.8032 and 802.1ad in hardware for the > distribution side (24 or 48-port SFP metro switch) and something > inexpensive for the access side but still managed (e.g. a 4-port switch > with an SFP uplink supporting Q-in-Q). These kinds of devices are quite popular here in Sweden where we basically have no PON what so ever (I know of no major PON deployments, everything is active ethernet either over CAT5e/CAT6 or fiber): http://inteno.se/store/tabid/141/categoryid/130/productid/783/default.aspx http://inteno.se/store/tabid/141/categoryid/130/productid/771/default.aspx http://inteno.se/store/tabid/141/categoryid/130/productid/442/default.aspx (I am not affiliated with Inteno, I just know they are quite common in the market here and the above list is to provide examples of producs used here) They typically use BiDi optics to run bidirectional fiber over single strand, in some cases in conjunction with hardware that runs HFC on the other strand. > I'm really looking for something cheap to keep costs down for a > proof-of-concept. The stuff from Cisco and even Ciena is a bit more > expensive than my target. Typically people here tend to buy regular enterprise hardware, but still that can do the BCP38 kind of stuff needed to deliver a proper secure end user connection. List of some vendors here: http://secureenduserconnection.se/certified-products/ http://secureenduserconnection.se/wp-content/uploads/2012/02/SEC-Secure-End-user-Connection-2014-05-30.pdf is a good document to make sure your network follows as well. -- Mikael Abrahamsson email: swmike at swm.pp.se From mkaipov at outlook.com Tue Feb 10 14:51:59 2015 From: mkaipov at outlook.com (Murat Kaipov) Date: Tue, 10 Feb 2015 17:51:59 +0300 Subject: FTTx Active-Ethernet Hardware In-Reply-To: References: <15020604.4147.1423575243412.JavaMail.mhammett@ThunderFuck> Message-ID: We are small ISP. We used Linksys SPS208G for access level, and Cisco ME3400 for aggregation purposes. On Core level we use Cisco3560, now we have some plans to migrate to Cat 6500. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ray Soucy Sent: Tuesday, February 10, 2015 5:42 PM To: Mike Hammett Cc: NANOG Subject: Re: FTTx Active-Ethernet Hardware Price and functionality-wise Planet MGSW-28240F and GSD-1020S look pretty close to what I'm looking for. Anyone have real experience with using them on a large scale? Performance? On Tue, Feb 10, 2015 at 8:34 AM, Mike Hammett wrote: > Check out Mikrotik, Planet and TP-Link. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "Ray Soucy" > To: "NANOG" > Sent: Tuesday, February 10, 2015 7:31:22 AM > Subject: FTTx Active-Ethernet Hardware > > One thing I'm personally interested in is the growth of municipal FTTx > that's starting to happen around the US and possibly applying that > model to highly rural areas (e.g. 10 mile long town with no side > streets, existing utility polls, 250 or so homes) and doing a > realistic cost analysis of what that would take. > > What options are out there for Active-Ethernet hardware. Ideally > something that could handle G.8032 and 802.1ad in hardware for the > distribution side (24 or 48-port SFP metro switch) and something > inexpensive for the access side but still managed (e.g. a 4-port > switch with an SFP uplink supporting Q-in-Q). > > I'm really looking for something cheap to keep costs down for a > proof-of-concept. The stuff from Cisco and even Ciena is a bit more > expensive than my target. > > > > > -- > 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 > -- 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 ammar at fastreturn.net Tue Feb 10 14:52:24 2015 From: ammar at fastreturn.net (Ammar Zuberi) Date: Tue, 10 Feb 2015 18:52:24 +0400 Subject: FTTx Active-Ethernet Hardware In-Reply-To: References: <15020604.4147.1423575243412.JavaMail.mhammett@ThunderFuck> Message-ID: <082C4CBD-B05E-4101-878D-3FAF222B0031@fastreturn.net> Hi, Here in Dubai they have a wide FTTH deployment (almost 80% of homes and offices) with almost no copper in the service provider networks. They use these Planet devices in every deployment I've taken a look at so far. Ammar > On 10 Feb 2015, at 6:42 pm, Ray Soucy wrote: > > Price and functionality-wise Planet MGSW-28240F and GSD-1020S look > pretty close to what I'm looking for. Anyone have real experience > with using them on a large scale? Performance? > >> On Tue, Feb 10, 2015 at 8:34 AM, Mike Hammett wrote: >> Check out Mikrotik, Planet and TP-Link. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> >> ----- Original Message ----- >> >> From: "Ray Soucy" >> To: "NANOG" >> Sent: Tuesday, February 10, 2015 7:31:22 AM >> Subject: FTTx Active-Ethernet Hardware >> >> One thing I'm personally interested in is the growth of municipal FTTx >> that's starting to happen around the US and possibly applying that >> model to highly rural areas (e.g. 10 mile long town with no side >> streets, existing utility polls, 250 or so homes) and doing a >> realistic cost analysis of what that would take. >> >> What options are out there for Active-Ethernet hardware. Ideally >> something that could handle G.8032 and 802.1ad in hardware for the >> distribution side (24 or 48-port SFP metro switch) and something >> inexpensive for the access side but still managed (e.g. a 4-port >> switch with an SFP uplink supporting Q-in-Q). >> >> I'm really looking for something cheap to keep costs down for a >> proof-of-concept. The stuff from Cisco and even Ciena is a bit more >> expensive than my target. >> >> >> >> >> -- >> 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 > > > > -- > 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 rps at maine.edu Tue Feb 10 15:05:48 2015 From: rps at maine.edu (Ray Soucy) Date: Tue, 10 Feb 2015 10:05:48 -0500 Subject: FTTx Active-Ethernet Hardware In-Reply-To: <082C4CBD-B05E-4101-878D-3FAF222B0031@fastreturn.net> References: <15020604.4147.1423575243412.JavaMail.mhammett@ThunderFuck> <082C4CBD-B05E-4101-878D-3FAF222B0031@fastreturn.net> Message-ID: Thank you, this is useful information. From your perspective as a user, do things seem fairly stable? On Tue, Feb 10, 2015 at 9:52 AM, Ammar Zuberi wrote: > Hi, > > Here in Dubai they have a wide FTTH deployment (almost 80% of homes and offices) with almost no copper in the service provider networks. > > They use these Planet devices in every deployment I've taken a look at so far. > > Ammar > >> On 10 Feb 2015, at 6:42 pm, Ray Soucy wrote: >> >> Price and functionality-wise Planet MGSW-28240F and GSD-1020S look >> pretty close to what I'm looking for. Anyone have real experience >> with using them on a large scale? Performance? >> >>> On Tue, Feb 10, 2015 at 8:34 AM, Mike Hammett wrote: >>> Check out Mikrotik, Planet and TP-Link. >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: "Ray Soucy" >>> To: "NANOG" >>> Sent: Tuesday, February 10, 2015 7:31:22 AM >>> Subject: FTTx Active-Ethernet Hardware >>> >>> One thing I'm personally interested in is the growth of municipal FTTx >>> that's starting to happen around the US and possibly applying that >>> model to highly rural areas (e.g. 10 mile long town with no side >>> streets, existing utility polls, 250 or so homes) and doing a >>> realistic cost analysis of what that would take. >>> >>> What options are out there for Active-Ethernet hardware. Ideally >>> something that could handle G.8032 and 802.1ad in hardware for the >>> distribution side (24 or 48-port SFP metro switch) and something >>> inexpensive for the access side but still managed (e.g. a 4-port >>> switch with an SFP uplink supporting Q-in-Q). >>> >>> I'm really looking for something cheap to keep costs down for a >>> proof-of-concept. The stuff from Cisco and even Ciena is a bit more >>> expensive than my target. >>> >>> >>> >>> >>> -- >>> 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 >> >> >> >> -- >> 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 -- 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 math at sizone.org Tue Feb 10 17:12:16 2015 From: math at sizone.org (Ken Chase) Date: Tue, 10 Feb 2015 12:12:16 -0500 Subject: Need recommendations for high-feature, high-density L3 Switch In-Reply-To: <874mquj0tt.fsf@corbe.net> References: <874mquj0tt.fsf@corbe.net> Message-ID: <20150210171216.GB24463@sizone.org> how about all in 1U (interconnect room switch, $$$/u) /kc -- Ken Chase - math at sizone.org Toronto Canada From DMelancon at venyu.com Tue Feb 10 17:25:09 2015 From: DMelancon at venyu.com (Dustin Melancon) Date: Tue, 10 Feb 2015 17:25:09 +0000 Subject: IPv6 allocation plan, security, and 6-to-4 conversion In-Reply-To: References: Message-ID: Hey Eric, I did not see anyone else post this, but the NANOG BCOP (Best Current Operating Practices) group has released the following document to help guide new IPv6 allocation plans which you and others may find helpful: http://bcop.nanog.org/images/6/62/BCOP-IPv6_Subnetting.pdf Another useful document from Department of Defense on IPv6 Addressing: http://www.v6.dren.net/AddressingPlans.pdf BCOP Conclusions 1. Every individual network segment requires at a minimum, one /64 prefix 2. Only subnet on nibble boundaries 3. Implement a hierarchical addressing plan to allow for aggregation a. Each individual site should be allocated a /48 prefix 4. One /48 from each region should be reserved for infrastructure a. Loopbacks should be allocated from the top /64 b. Point-to-point links should be allocated a /64 and configured with a /126 or /127 5. Sites/PoPs/locations and regions, etc. should be laid out such that within each level of the hierarchy, each subnet prefix is of equal size a. Each ³site² should likewise have an equalized internal hierarchy Regarding your management block, I would use the recommendation above to maintain a /48 in each region for management with the top /64 used for loopbacks. However I definitely would NOT bother removing this network from your advertised blocks as there are much better ways to implement security and it would screw with your ability to cleanly aggregate your IPv6 allocation. Thanks, Dustin Melancon Sr. Network Engineer Venyu From ammar at fastreturn.net Tue Feb 10 17:38:48 2015 From: ammar at fastreturn.net (Ammar Zuberi) Date: Tue, 10 Feb 2015 21:38:48 +0400 Subject: FTTx Active-Ethernet Hardware In-Reply-To: References: <15020604.4147.1423575243412.JavaMail.mhammett@ThunderFuck> <082C4CBD-B05E-4101-878D-3FAF222B0031@fastreturn.net> Message-ID: Hi, Generally, I haven’t seen many issues. I see our home Internet slow down once in a while, but I doubt its anything to do with the Planet devices but more so with the way the provider operates their network. Ammar > On Feb 10, 2015, at 7:05 PM, Ray Soucy wrote: > > Thank you, this is useful information. From your perspective as a > user, do things seem fairly stable? > > On Tue, Feb 10, 2015 at 9:52 AM, Ammar Zuberi wrote: >> Hi, >> >> Here in Dubai they have a wide FTTH deployment (almost 80% of homes and offices) with almost no copper in the service provider networks. >> >> They use these Planet devices in every deployment I've taken a look at so far. >> >> Ammar >> >>> On 10 Feb 2015, at 6:42 pm, Ray Soucy wrote: >>> >>> Price and functionality-wise Planet MGSW-28240F and GSD-1020S look >>> pretty close to what I'm looking for. Anyone have real experience >>> with using them on a large scale? Performance? >>> >>>> On Tue, Feb 10, 2015 at 8:34 AM, Mike Hammett wrote: >>>> Check out Mikrotik, Planet and TP-Link. >>>> >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> From: "Ray Soucy" >>>> To: "NANOG" >>>> Sent: Tuesday, February 10, 2015 7:31:22 AM >>>> Subject: FTTx Active-Ethernet Hardware >>>> >>>> One thing I'm personally interested in is the growth of municipal FTTx >>>> that's starting to happen around the US and possibly applying that >>>> model to highly rural areas (e.g. 10 mile long town with no side >>>> streets, existing utility polls, 250 or so homes) and doing a >>>> realistic cost analysis of what that would take. >>>> >>>> What options are out there for Active-Ethernet hardware. Ideally >>>> something that could handle G.8032 and 802.1ad in hardware for the >>>> distribution side (24 or 48-port SFP metro switch) and something >>>> inexpensive for the access side but still managed (e.g. a 4-port >>>> switch with an SFP uplink supporting Q-in-Q). >>>> >>>> I'm really looking for something cheap to keep costs down for a >>>> proof-of-concept. The stuff from Cisco and even Ciena is a bit more >>>> expensive than my target. >>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>> >>> >>> >>> -- >>> 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 > > > > -- > 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 frnkblk at iname.com Tue Feb 10 19:35:47 2015 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 10 Feb 2015 13:35:47 -0600 Subject: FTTx Active-Ethernet Hardware In-Reply-To: References: Message-ID: <000a01d04568$c4bf96b0$4e3ec410$@iname.com> Unless each customer has in their own L3 domain, you'll also want some kind of L2 isolation between ports (and also MFF) and IP source address verification (so that people can't spoof addresses) for both DHPC and static IP customers. And don't forget the IPv6 equivalents. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ray Soucy Sent: Tuesday, February 10, 2015 7:31 AM To: NANOG Subject: FTTx Active-Ethernet Hardware One thing I'm personally interested in is the growth of municipal FTTx that's starting to happen around the US and possibly applying that model to highly rural areas (e.g. 10 mile long town with no side streets, existing utility polls, 250 or so homes) and doing a realistic cost analysis of what that would take. What options are out there for Active-Ethernet hardware. Ideally something that could handle G.8032 and 802.1ad in hardware for the distribution side (24 or 48-port SFP metro switch) and something inexpensive for the access side but still managed (e.g. a 4-port switch with an SFP uplink supporting Q-in-Q). I'm really looking for something cheap to keep costs down for a proof-of-concept. The stuff from Cisco and even Ciena is a bit more expensive than my target. -- 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 mark.tinka at seacom.mu Tue Feb 10 21:27:08 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 10 Feb 2015 23:27:08 +0200 Subject: FTTx Active-Ethernet Hardware In-Reply-To: <000a01d04568$c4bf96b0$4e3ec410$@iname.com> References: <000a01d04568$c4bf96b0$4e3ec410$@iname.com> Message-ID: <54DA77AC.70704@seacom.mu> On 10/Feb/15 21:35, Frank Bulk wrote: > Unless each customer has in their own L3 domain, you'll also want some kind > of L2 isolation between ports (and also MFF) and IP source address > verification (so that people can't spoof addresses) for both DHPC and static > IP customers. And don't forget the IPv6 equivalents. You can get all that in a decent Active-E-based AN (as you would in a GPON AN). But then the price starts to go up if you want this in software as opposed to doing funky things. Cisco's ME2600X was, for me, one of the first proper Active-E FTTH AN's with features required in FTTH deployments (split horizon for Layer 2 customer separation, DHCP Option 82 support, per-port level trTCM ingress and egress policing and queuing, EVC's, e.t.c.). I understand it is now being replaced by the ASR920, which is a little odd if you look at port density differences between the two alone. For the GPON-centric, it is also being replaced by Cisco's ME4605 GPON AN. Final date to buy any ME2600X's will be June 2015. Mark. From khomyakov.andrey at gmail.com Wed Feb 11 00:27:26 2015 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Tue, 10 Feb 2015 19:27:26 -0500 Subject: Comcast New England dropped for 5-15 min? Anyone Message-ID: Hey, anyone had problems just now? My team and I at homes lost internet access for about 10 min. I also had many sites drop off. Still digging, but maybe trouble upstream? I'm in 50.133.128.0/17 at home. --Andrey From mailvortex at gmail.com Wed Feb 11 01:44:22 2015 From: mailvortex at gmail.com (Ben Scott) Date: Tue, 10 Feb 2015 20:44:22 -0500 Subject: Comcast New England dropped for 5-15 min? Anyone In-Reply-To: References: Message-ID: On Tue, Feb 10, 2015 at 7:27 PM, Andrey Khomyakov wrote: > Hey, anyone had problems just now? My team and I at homes lost internet > access for about 10 min. I also had many sites drop off. Still digging, but > maybe trouble upstream? I'm in 50.133.128.0/17 at home. Yah, we lost two offices with Comcast feeds in northern Mass about two hours ago, and a cow-orker reports his home feed in southern NH went out around the same time. His is back but the offices are still down. Their phone support says they had a "massive outage" in the North-East, including MA, NH, CT, others. I think he even said Virgina. Now I'm on hold while they try to reset us. -- Ben From skeeve+nanog at eintellegonetworks.com Wed Feb 11 01:44:58 2015 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Wed, 11 Feb 2015 12:44:58 +1100 Subject: Cumulus List Message-ID: Hi all, I am looking to get a better understanding of some features of Cumulus Linux.... their pre-sales is a bit inundated, but I am wondering if there is a Cisco-NSP or something similar out there for Cumulus... Thanks :) ...Skeeve *Skeeve Stevens - Founder & Chief Network Architect* eintellego Networks Pty Ltd Email: skeeve at eintellegonetworks.com ; Web: eintellegonetworks.com Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks ; Twitter: eintellego LinkedIn: /in/skeeve ; Expert360: Profile The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering From kkadow at gmail.com Wed Feb 11 01:45:36 2015 From: kkadow at gmail.com (Kevin Kadow) Date: Tue, 10 Feb 2015 20:45:36 -0500 Subject: Comcast New England dropped for 5-15 min? Anyone In-Reply-To: References: Message-ID: On Tue, Feb 10, 2015 at 7:27 PM, Andrey Khomyakov < khomyakov.andrey at gmail.com> wrote: > Hey, anyone had problems just now? My team and I at homes lost internet > access for about 10 min. I also had many sites drop off. Still digging, but > maybe trouble upstream? I'm in 50.133.128.0/17 at home. > You were only out for 10-15 minutes? More like an hour in New Hampshire. traceroutes would die out in Needham, Woburn, or whatever 4.68.127.229 is. From doug at sdnessentials.com Wed Feb 11 01:53:20 2015 From: doug at sdnessentials.com (Doug Marschke) Date: Tue, 10 Feb 2015 17:53:20 -0800 Subject: Cumulus List Message-ID: I can help..contact me off list. Sent via the Samsung Galaxy Note® 4, an AT&T 4G LTE smartphone -------- Original message -------- From: Skeeve Stevens Date: 02/10/2015 5:44 PM (GMT-08:00) To: nanog at nanog.org Subject: Cumulus List Hi all, I am looking to get a better understanding of some features of Cumulus Linux.... their pre-sales is a bit inundated, but I am wondering if there is a Cisco-NSP or something similar out there for Cumulus... Thanks :) ...Skeeve *Skeeve Stevens - Founder & Chief Network Architect* eintellego Networks Pty Ltd Email: skeeve at eintellegonetworks.com ; Web: eintellegonetworks.com Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks ; Twitter: eintellego LinkedIn: /in/skeeve ; Expert360: Profile The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering From dbrisson at uvm.edu Wed Feb 11 01:52:48 2015 From: dbrisson at uvm.edu (Dan Brisson) Date: Tue, 10 Feb 2015 20:52:48 -0500 Subject: Comcast New England dropped for 5-15 min? Anyone In-Reply-To: References: Message-ID: <54DAB5F0.4080706@uvm.edu> FWIW...no problems here in Vermont on Comcast business. -dan Dan Brisson Network Engineer University of Vermont On 2/10/15 8:45 PM, Kevin Kadow wrote: > On Tue, Feb 10, 2015 at 7:27 PM, Andrey Khomyakov < > khomyakov.andrey at gmail.com> wrote: > >> Hey, anyone had problems just now? My team and I at homes lost internet >> access for about 10 min. I also had many sites drop off. Still digging, but >> maybe trouble upstream? I'm in 50.133.128.0/17 at home. >> > You were only out for 10-15 minutes? More like an hour in New Hampshire. > > traceroutes would die out in Needham, Woburn, or whatever 4.68.127.229 is. From khomyakov.andrey at gmail.com Wed Feb 11 02:52:29 2015 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Tue, 10 Feb 2015 21:52:29 -0500 Subject: Comcast New England dropped for 5-15 min? Anyone In-Reply-To: <54DAB5F0.4080706@uvm.edu> References: <54DAB5F0.4080706@uvm.edu> Message-ID: My boss has comcast at home in Milton, MA, said all was fine. Must have been prefix specific. Trace would die somewhere in level3 at the time. Was tracing to 8.8.8.8 On Tuesday, February 10, 2015, Dan Brisson wrote: > FWIW...no problems here in Vermont on Comcast business. > > -dan > > > Dan Brisson > Network Engineer > University of Vermont > > > > On 2/10/15 8:45 PM, Kevin Kadow wrote: > >> On Tue, Feb 10, 2015 at 7:27 PM, Andrey Khomyakov < >> khomyakov.andrey at gmail.com> wrote: >> >> Hey, anyone had problems just now? My team and I at homes lost internet >>> access for about 10 min. I also had many sites drop off. Still digging, >>> but >>> maybe trouble upstream? I'm in 50.133.128.0/17 at home. >>> >>> You were only out for 10-15 minutes? More like an hour in New >> Hampshire. >> >> traceroutes would die out in Needham, Woburn, or whatever 4.68.127.229 >> is. >> > > -- Sent from Gmail Mobile From carlos at race.com Wed Feb 11 05:11:28 2015 From: carlos at race.com (Carlos Alcantar) Date: Wed, 11 Feb 2015 05:11:28 +0000 Subject: FTTx Active-Ethernet Hardware In-Reply-To: <54DA77AC.70704@seacom.mu> References: <000a01d04568$c4bf96b0$4e3ec410$@iname.com> <54DA77AC.70704@seacom.mu> Message-ID: We run Calix GPON / AE Platform works fairly nicely but does have it¹s cost. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com On 2/10/15, 1:27 PM, "Mark Tinka" wrote: > >On 10/Feb/15 21:35, Frank Bulk wrote: >> Unless each customer has in their own L3 domain, you'll also want some >>kind >> of L2 isolation between ports (and also MFF) and IP source address >> verification (so that people can't spoof addresses) for both DHPC and >>static >> IP customers. And don't forget the IPv6 equivalents. > >You can get all that in a decent Active-E-based AN (as you would in a >GPON AN). But then the price starts to go up if you want this in >software as opposed to doing funky things. > >Cisco's ME2600X was, for me, one of the first proper Active-E FTTH AN's >with features required in FTTH deployments (split horizon for Layer 2 >customer separation, DHCP Option 82 support, per-port level trTCM >ingress and egress policing and queuing, EVC's, e.t.c.). > >I understand it is now being replaced by the ASR920, which is a little >odd if you look at port density differences between the two alone. > >For the GPON-centric, it is also being replaced by Cisco's ME4605 GPON AN. > >Final date to buy any ME2600X's will be June 2015. > >Mark. > > From randy at psg.com Wed Feb 11 08:22:53 2015 From: randy at psg.com (Randy Bush) Date: Wed, 11 Feb 2015 15:22:53 +0700 Subject: a hack for dealing with lack of control/data plane congruence at ix with rs Message-ID: https://datatracker.ietf.org/doc/draft-ymbk-idr-rs-bfd/ From xxnog at ledeuns.net Wed Feb 11 09:55:48 2015 From: xxnog at ledeuns.net (Denis Fondras) Date: Wed, 11 Feb 2015 10:55:48 +0100 Subject: FTTx Active-Ethernet Hardware In-Reply-To: References: <15020604.4147.1423575243412.JavaMail.mhammett@ThunderFuck> Message-ID: <20150211095547.GF2726@belenos> Hi, > Price and functionality-wise Planet MGSW-28240F and GSD-1020S look > pretty close to what I'm looking for. Anyone have real experience > with using them on a large scale? Performance? > Thank you for the pointer to MGSW-28240F. I am also curious to hear some feedback as the gear is awfully low-priced :) Denis From Joel.Snyder at Opus1.COM Wed Feb 11 12:10:39 2015 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Wed, 11 Feb 2015 14:10:39 +0200 Subject: Any recommendations for FXS/FXO hardware with Cisco Unified CME Message-ID: <54DB46BF.1090101@Opus1.COM> Folks: Since a lot of NSPs are also in the VoIP business, I was wondering if anyone has specific recommendations for low-density (2-8 ports) FXS/FXO hardware that they are using with Cisco PBX devices. (And I guess T1/E1 as well.) I know that typical IOS boxes can take modules/interfaces/whatever to handle FXS/FXO/T1/E1, but I'm trying to put some electrical distance between the Cisco PBX and the phone company to keep environmental problems (lightning, mostly) from blowing up the PBX. Cisco themselves seem to have cancelled almost all of their low-end hardware, leaving us with Sipura/Linksys. I have had good results with Audiocodes+Asterisk, but not in the Cisco PBX environment. Does anyone have boots-on-the-ground knowledge of good analog gateway choices that play very nicely with Cisco PBX? jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From jared at puck.nether.net Wed Feb 11 12:24:06 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 11 Feb 2015 07:24:06 -0500 Subject: Any recommendations for FXS/FXO hardware with Cisco Unified CME In-Reply-To: <54DB46BF.1090101@Opus1.COM> References: <54DB46BF.1090101@Opus1.COM> Message-ID: You may want to ask on the cisco-voip list as it’s most centrally focused on that. Do you mean with CM or CME (as suggested in your subject line?) We have generally been abandoning the Cisco devices as they haven’t released an ‘open’ phone in many years outside of what you mentioned, sipura/linksys. I’m similarly looking for a “good” handset of build quality like the 7940/7960 that doesn’t require CM, handles being behind NAT/nat traversal properly and can provision securely over a TCP transport. We have been provisioning PAP2T for people who need the single ports and been using the Cisco ISRs to do T1/E1 where we can’t talk SIP directly to someone. - Jared > On Feb 11, 2015, at 7:10 AM, Joel M Snyder wrote: > > Folks: > > Since a lot of NSPs are also in the VoIP business, I was wondering if anyone has specific recommendations for low-density (2-8 ports) FXS/FXO hardware that they are using with Cisco PBX devices. (And I guess T1/E1 as well.) > > I know that typical IOS boxes can take modules/interfaces/whatever to handle FXS/FXO/T1/E1, but I'm trying to put some electrical distance between the Cisco PBX and the phone company to keep environmental problems (lightning, mostly) from blowing up the PBX. > > Cisco themselves seem to have cancelled almost all of their low-end hardware, leaving us with Sipura/Linksys. I have had good results with Audiocodes+Asterisk, but not in the Cisco PBX environment. Does anyone have boots-on-the-ground knowledge of good analog gateway choices that play very nicely with Cisco PBX? > > jms > -- > Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 > Senior Partner, Opus One Phone: +1 520 324 0494 > jms at Opus1.COM http://www.opus1.com/jms From Joel.Snyder at Opus1.COM Wed Feb 11 12:49:39 2015 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Wed, 11 Feb 2015 14:49:39 +0200 Subject: Any recommendations for FXS/FXO hardware with Cisco Unified CME In-Reply-To: References: <54DB46BF.1090101@Opus1.COM> Message-ID: <54DB4FE3.1090004@Opus1.COM> On 2/11/15 2:24 PM, Jared Mauch wrote: > You may want to ask on the cisco-voip list as it’s most centrally focused on that. Thanks, will ask on the list. > Do you mean with CM or CME (as suggested in your subject line?) In this case, it's CME that I'm asking about. >I’m similarly looking for a “good” handset Have you taken a look at the Polycom IP phones? The physical quality is as good or better than Cisco, in my opinion (having used both a lot). And, you can provision with HTTPS secured by username/password, and if you really want you can use client/server TLS (i.e., both ends authenticate each other with certificates) for both HTTPS provisioning and for SIP signalling. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From tarko at lanparty.ee Wed Feb 11 12:49:29 2015 From: tarko at lanparty.ee (Tarko Tikan) Date: Wed, 11 Feb 2015 14:49:29 +0200 Subject: FTTx Active-Ethernet Hardware In-Reply-To: <54DA77AC.70704@seacom.mu> References: <000a01d04568$c4bf96b0$4e3ec410$@iname.com> <54DA77AC.70704@seacom.mu> Message-ID: <54DB4FD9.8000704@lanparty.ee> hey, > I understand it is now being replaced by the ASR920, which is a little > odd if you look at port density differences between the two alone. It is being replaced by ASR-920-24SZ-M - 24GE Fiber and 4-10GE: Modular PSU. I don't think this ASR920 has been announced yet :) -- tarko From aledm at qix.co.uk Wed Feb 11 13:11:47 2015 From: aledm at qix.co.uk (Aled Morris) Date: Wed, 11 Feb 2015 13:11:47 +0000 Subject: FTTx Active-Ethernet Hardware In-Reply-To: <54DB4FD9.8000704@lanparty.ee> References: <000a01d04568$c4bf96b0$4e3ec410$@iname.com> <54DA77AC.70704@seacom.mu> <54DB4FD9.8000704@lanparty.ee> Message-ID: http://www.cisco.com/c/en/us/products/collateral/routers/asr-920-series-aggregation-services-router/datasheet-c78-733397.html Aled On 11 February 2015 at 12:49, Tarko Tikan wrote: > hey, > > I understand it is now being replaced by the ASR920, which is a little >> odd if you look at port density differences between the two alone. >> > > It is being replaced by ASR-920-24SZ-M - 24GE Fiber and 4-10GE: Modular > PSU. I don't think this ASR920 has been announced yet :) > > -- > tarko > From bob at FiberInternetCenter.com Wed Feb 11 14:12:13 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 11 Feb 2015 06:12:13 -0800 Subject: Comcast New England dropped for 5-15 min? Anyone In-Reply-To: References: Message-ID: <02bd465103387276025babc351a433ea.squirrel@66.201.44.180> Since, we reduced ourselves to the level of troubleshooting consumer home access on a cable network. I can let you know that this happens to me at home, in silicon valley area of California routinely several times a week. In fact, so much that I have ATT, Comcast and Verizon hot spot for the rare event it happens to the first two at the same time. I simply flip between access points. The only thing I found worth the time it to test from home is to the destination points where our network has sessions with ATT, Comcast, etc.. With more than one consumer provider at here at home, it have happens often enough and it becomes clear that it's rarely worth the effort to troubleshoot from a consumer end point, unless of course if you work for them. Thank You Bob Evans CTO > Hey, anyone had problems just now? My team and I at homes lost internet > access for about 10 min. I also had many sites drop off. Still digging, > but > maybe trouble upstream? I'm in 50.133.128.0/17 at home. > > --Andrey > From khomyakov.andrey at gmail.com Wed Feb 11 14:54:59 2015 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Wed, 11 Feb 2015 09:54:59 -0500 Subject: Comcast New England dropped for 5-15 min? Anyone In-Reply-To: <02bd465103387276025babc351a433ea.squirrel@66.201.44.180> References: <02bd465103387276025babc351a433ea.squirrel@66.201.44.180> Message-ID: It wasn't intended to start troubleshooting end user's internet. It was more to know what is up when my customer hold queue goes up to a couple of thousand calls on hold and my monitoring system lights up like a christmas tree. --Andrey On Wed, Feb 11, 2015 at 9:12 AM, Bob Evans wrote: > Since, we reduced ourselves to the level of troubleshooting consumer home > access on a cable network. I can let you know that this happens to me at > home, in silicon valley area of California routinely several times a week. > In fact, so much that I have ATT, Comcast and Verizon hot spot for the > rare event it happens to the first two at the same time. I simply flip > between access points. The only thing I found worth the time it to test > from home is to the destination points where our network has sessions with > ATT, Comcast, etc.. With more than one consumer provider at here at home, > it have happens often enough and it becomes clear that it's rarely worth > the effort to troubleshoot from a consumer end point, unless of course if > you work for them. > > Thank You > Bob Evans > CTO > > > > > > Hey, anyone had problems just now? My team and I at homes lost internet > > access for about 10 min. I also had many sites drop off. Still digging, > > but > > maybe trouble upstream? I'm in 50.133.128.0/17 at home. > > > > --Andrey > > > > > From rafael at gav.ufsc.br Wed Feb 11 18:27:36 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Wed, 11 Feb 2015 12:27:36 -0600 Subject: Comcast Static IP Changed With New Modem? In-Reply-To: <3E9C67DA261AC349B60FF3609F5E211D716D5B88@USI-2K10EX01-MT.usicorp.usinternet.com> References: <3E9C67DA261AC349B60FF3609F5E211D716D5B88@USI-2K10EX01-MT.usicorp.usinternet.com> Message-ID: I've had a similar mistake happen with TWC. It's most likely a glitch in their config system which should use the gateway's mac address in order to assign a static IP on the docsis modem. Tech support should figure this out pretty quick without escalating it much further. I've had an instance where a second line/modem was added with the same gateway IP, and that brought us down for over a day until they got around to fixing it. My suggestions is to always keep your gateways/edges monitored with a service like Monitis. I use ping monitors every single minute from three different locations in the US (abroad available too) and get email/SMS/call whenever something fails once, twice, etc from one, two or more locations. Really cool monitoring system. Hope this helps. On Mon, Feb 9, 2015 at 10:32 AM, Justin Krejci wrote: > Has anyone run into the situation where their static IP address from > Comcast (on the business class cable modem Internet service) was changed > when the modem was replaced? > > We have a remote site that uses Comcast as a backup Internet connection > and when we went to use it recently our VPN tunnel would not establish. > After working with the Comcast support group we discovered Comcast changed > our static IP address. I am working through trying to figure out the when > and the why with Comcast still and suspect it was changed when the modem > was replaced back in December. The modem was replaced by Comcast as our > previous modem was apparently EOL'ed. > > We're now setting up additional monitoring to verify the accessibility of > our remote site via the Comcast connection so we don't have any future > uh-ohs when we need to use our backup connection and it too is not fully > functional. > > TIA, > -Justin > From rwebb at ropeguru.com Wed Feb 11 18:44:53 2015 From: rwebb at ropeguru.com (Robert Webb) Date: Wed, 11 Feb 2015 13:44:53 -0500 Subject: Comcast New England dropped for 5-15 min? Anyone In-Reply-To: References: <54DAB5F0.4080706@uvm.edu> Message-ID: Looks like there were at least a couple of others that saw issues also. http://www.dslreports.com/forum/r29852647-Connectivity-Comcast-down-Quincy-MA Robert On Tue, 10 Feb 2015 21:52:29 -0500 Andrey Khomyakov wrote: > My boss has comcast at home in Milton, MA, said all was fine. Must >have > been prefix specific. Trace would die somewhere in level3 at the >time. Was > tracing to 8.8.8.8 > > On Tuesday, February 10, 2015, Dan Brisson wrote: > >> FWIW...no problems here in Vermont on Comcast business. >> >> -dan >> >> >> Dan Brisson >> Network Engineer >> University of Vermont >> >> >> On 2/10/15 8:45 PM, Kevin Kadow wrote: >> >>> On Tue, Feb 10, 2015 at 7:27 PM, Andrey Khomyakov < >>> khomyakov.andrey at gmail.com> wrote: >>> >>> Hey, anyone had problems just now? My team and I at homes lost >>>internet >>>> access for about 10 min. I also had many sites drop off. Still >>>>digging, >>>> but >>>> maybe trouble upstream? I'm in 50.133.128.0/17 at home. >>>> >>>> You were only out for 10-15 minutes? More like an hour in New >>> Hampshire. >>> >>> traceroutes would die out in Needham, Woburn, or whatever >>>4.68.127.229 >>> is. >>> >> > -- > Sent from Gmail Mobile From cra at WPI.EDU Wed Feb 11 18:50:53 2015 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 11 Feb 2015 13:50:53 -0500 Subject: Comcast New England dropped for 5-15 min? Anyone In-Reply-To: References: <54DAB5F0.4080706@uvm.edu> Message-ID: <20150211185051.GN17460@angus.ind.WPI.EDU> I saw a problem only with my 50.176.16.0/21 subnet IP. My 24.147.20.0/21 subnet IP was working fine throughout. On Wed, Feb 11, 2015 at 01:44:53PM -0500, Robert Webb wrote: > Looks like there were at least a couple of others that saw issues also. > > http://www.dslreports.com/forum/r29852647-Connectivity-Comcast-down-Quincy-MA > > Robert > > On Tue, 10 Feb 2015 21:52:29 -0500 > Andrey Khomyakov wrote: > >My boss has comcast at home in Milton, MA, said all was fine. Must > >have > >been prefix specific. Trace would die somewhere in level3 at the > >time. Was > >tracing to 8.8.8.8 > > > >On Tuesday, February 10, 2015, Dan Brisson wrote: > > > >>FWIW...no problems here in Vermont on Comcast business. > >> > >>-dan > >> > >> > >>Dan Brisson > >>Network Engineer > >>University of Vermont > >> > >> > >>On 2/10/15 8:45 PM, Kevin Kadow wrote: > >> > >>>On Tue, Feb 10, 2015 at 7:27 PM, Andrey Khomyakov < > >>>khomyakov.andrey at gmail.com> wrote: > >>> > >>> Hey, anyone had problems just now? My team and I at homes > >>>lost internet > >>>>access for about 10 min. I also had many sites drop off. > >>>>Still digging, > >>>>but > >>>>maybe trouble upstream? I'm in 50.133.128.0/17 at home. > >>>> > >>>> You were only out for 10-15 minutes? More like an hour in New > >>>Hampshire. > >>> > >>>traceroutes would die out in Needham, Woburn, or whatever > >>>4.68.127.229 > >>>is. From ttauber at 1-4-5.net Wed Feb 11 19:27:24 2015 From: ttauber at 1-4-5.net (Tony Tauber) Date: Wed, 11 Feb 2015 14:27:24 -0500 Subject: Comcast New England dropped for 5-15 min? Anyone In-Reply-To: <20150211185051.GN17460@angus.ind.WPI.EDU> References: <54DAB5F0.4080706@uvm.edu> <20150211185051.GN17460@angus.ind.WPI.EDU> Message-ID: Hi folks, There was a problem with some prefixes New England rerouting properly during a topology change. We feel that problem has been corrected and would like to know if there were other problems seen overnight (after 0000 UTC) in that region. If you send to me, please include specific time and source/destination IP address information. Thanks, Tony On Wed, Feb 11, 2015 at 1:50 PM, Chuck Anderson wrote: > I saw a problem only with my 50.176.16.0/21 subnet IP. My > 24.147.20.0/21 subnet IP was working fine throughout. > > On Wed, Feb 11, 2015 at 01:44:53PM -0500, Robert Webb wrote: > > Looks like there were at least a couple of others that saw issues also. > > > > > http://www.dslreports.com/forum/r29852647-Connectivity-Comcast-down-Quincy-MA > > > > Robert > > > > On Tue, 10 Feb 2015 21:52:29 -0500 > > Andrey Khomyakov wrote: > > >My boss has comcast at home in Milton, MA, said all was fine. Must > > >have > > >been prefix specific. Trace would die somewhere in level3 at the > > >time. Was > > >tracing to 8.8.8.8 > > > > > >On Tuesday, February 10, 2015, Dan Brisson wrote: > > > > > >>FWIW...no problems here in Vermont on Comcast business. > > >> > > >>-dan > > >> > > >> > > >>Dan Brisson > > >>Network Engineer > > >>University of Vermont > > >> > > >> > > >>On 2/10/15 8:45 PM, Kevin Kadow wrote: > > >> > > >>>On Tue, Feb 10, 2015 at 7:27 PM, Andrey Khomyakov < > > >>>khomyakov.andrey at gmail.com> wrote: > > >>> > > >>> Hey, anyone had problems just now? My team and I at homes > > >>>lost internet > > >>>>access for about 10 min. I also had many sites drop off. > > >>>>Still digging, > > >>>>but > > >>>>maybe trouble upstream? I'm in 50.133.128.0/17 at home. > > >>>> > > >>>> You were only out for 10-15 minutes? More like an hour in New > > >>>Hampshire. > > >>> > > >>>traceroutes would die out in Needham, Woburn, or whatever > > >>>4.68.127.229 > > >>>is. > From faisal at snappytelecom.net Wed Feb 11 20:48:19 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Wed, 11 Feb 2015 20:48:19 +0000 (GMT) Subject: MultiMode Fiber Connectivity... (850nm) Power Question In-Reply-To: <909503074.1095472.1423687524675.JavaMail.zimbra@snappytelecom.net> Message-ID: <582468259.1095514.1423687699056.JavaMail.zimbra@snappytelecom.net> Hello, I was looking for feedback on the following question:- When connecting two MM SFP/SFP+/XFP 's together...(short range). What should be the best practice receive power range ? Is it true that if the rx power is higher than (x?) then it shortens the life of the optics ? (assumption being made here is that MAX Rx Power is not being exceed as per the spec sheets of the optics) 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 From bob at FiberInternetCenter.com Wed Feb 11 21:06:23 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 11 Feb 2015 13:06:23 -0800 Subject: MultiMode Fiber Connectivity... (850nm) Power Question In-Reply-To: <582468259.1095514.1423687699056.JavaMail.zimbra@snappytelecom.net> References: <582468259.1095514.1423687699056.JavaMail.zimbra@snappytelecom.net> Message-ID: Thank You Bob Evans CTO > Hello, > > I was looking for feedback on the following question:- > > When connecting two MM SFP/SFP+/XFP 's together...(short range). > > What should be the best practice receive power range ? > > Is it true that if the rx power is higher than (x?) then it shortens the > life of the optics ? Yes, but thats only true about single mode frequencies not multimode (MM) because those are not as powerful. All MM is expected to go a very limited distance, so levels are never high. We have MM 3 foot jumpers between gear running for years. > (assumption being made here is that MAX Rx Power is not being exceed as > per the spec sheets of the optics) > > 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 > From eric at lumaoptics.net Wed Feb 11 21:31:58 2015 From: eric at lumaoptics.net (Eric Litvin) Date: Wed, 11 Feb 2015 13:31:58 -0800 Subject: MultiMode Fiber Connectivity... (850nm) Power Question In-Reply-To: <582468259.1095514.1423687699056.JavaMail.zimbra@snappytelecom.net> References: <909503074.1095472.1423687524675.JavaMail.zimbra@snappytelecom.net> <582468259.1095514.1423687699056.JavaMail.zimbra@snappytelecom.net> Message-ID: Faisal, You don't need to worry about power range when connecting SR or LR. However, an ER or ZR on a loopback can damage Rx. The strength of the receiving signal is always under the tolerance allowed. The 850nm Light is attenuated very quickly because of the MMF and the 850nm light source. This light source is more like an LED than a Laser. The MTTF on any transceiver is 50,000 hours at room temperature. A bigger factor is high temperature, because the chip is a semiconductor. Eric Litvin President eric at lumaoptics.net Direct: (650)440-4382 Mobile:(*650)996-7270* Fax: (650) 618-1870 On Wed, Feb 11, 2015 at 12:48 PM, Faisal Imtiaz wrote: > Hello, > > I was looking for feedback on the following question:- > > When connecting two MM SFP/SFP+/XFP 's together...(short range). > > What should be the best practice receive power range ? > > Is it true that if the rx power is higher than (x?) then it shortens the > life of the optics ? > (assumption being made here is that MAX Rx Power is not being exceed as > per the spec sheets of the optics) > > 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 > -- Eric Litvin President eric at lumaoptics.net Direct: (650)440-4382 Mobile:(*650)996-7270 <650%29996-7270>* Fax: (650) 618-1870 From faisal at snappytelecom.net Wed Feb 11 21:33:40 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Wed, 11 Feb 2015 21:33:40 +0000 (GMT) Subject: MultiMode Fiber Connectivity... (850nm) Power Question In-Reply-To: References: <582468259.1095514.1423687699056.JavaMail.zimbra@snappytelecom.net> Message-ID: <1847081491.1096035.1423690420873.JavaMail.zimbra@snappytelecom.net> Thank you guys (Bob, Brandon & Eric) for the prompt answer. 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: "Bob Evans" > To: "Faisal Imtiaz" > Cc: "NANOG" > Sent: Wednesday, February 11, 2015 4:06:23 PM > Subject: Re: MultiMode Fiber Connectivity... (850nm) Power Question > > > Thank You > Bob Evans > CTO > > > > > > Hello, > > > > I was looking for feedback on the following question:- > > > > When connecting two MM SFP/SFP+/XFP 's together...(short range). > > > > What should be the best practice receive power range ? > > > > Is it true that if the rx power is higher than (x?) then it shortens the > > life of the optics ? > > Yes, but thats only true about single mode frequencies not multimode (MM) > because those are not as powerful. All MM is expected to go a very limited > distance, so levels are never high. We have MM 3 foot jumpers between gear > running for years. > > > (assumption being made here is that MAX Rx Power is not being exceed as > > per the spec sheets of the optics) > > > > 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 > > > > > From streiner at cluebyfour.org Wed Feb 11 17:41:23 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 11 Feb 2015 12:41:23 -0500 (EST) Subject: MultiMode Fiber Connectivity... (850nm) Power Question In-Reply-To: <582468259.1095514.1423687699056.JavaMail.zimbra@snappytelecom.net> References: <582468259.1095514.1423687699056.JavaMail.zimbra@snappytelecom.net> Message-ID: On Wed, 11 Feb 2015, Faisal Imtiaz wrote: > I was looking for feedback on the following question:- > > When connecting two MM SFP/SFP+/XFP 's together...(short range). > > What should be the best practice receive power range ? SX (1G) / SR (10G) / SR10 (100G) gear generally has a receive threshold that's higher than the maximum launch power. They are designed for short-reach applications (in-building, data center, etc), so no attenuation is needed. > Is it true that if the rx power is higher than (x?) then it shortens > the life of the optics ? > (assumption being made here is that MAX Rx Power is not being exceed as > per the spec sheets of the optics) On short-reach optics, this should never be a problem. On long-reach optics, receiver saturation will generally result in link errors/flaps, and possibly high rx power warnings (depending on the gear on the receiving end), however, these can be addressed using in-line attenuators. On very long-reach optics, such as ZX (1G) and ER/ZR (10G), it is possible to damage the receivers with too hot of a signal because they are designed for long spans and a certain amount of distance-based attenuation is factored into the optical power budget. jms From faisal at snappytelecom.net Wed Feb 11 21:46:24 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Wed, 11 Feb 2015 21:46:24 +0000 (GMT) Subject: MultiMode Fiber Connectivity... (850nm) Power Question In-Reply-To: References: <582468259.1095514.1423687699056.JavaMail.zimbra@snappytelecom.net> Message-ID: <524156189.1096392.1423691184181.JavaMail.zimbra@snappytelecom.net> Thanks Justin... Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Justin M. Streiner" > To: "NANOG" > Sent: Wednesday, February 11, 2015 12:41:23 PM > Subject: Re: MultiMode Fiber Connectivity... (850nm) Power Question > > On Wed, 11 Feb 2015, Faisal Imtiaz wrote: > > > I was looking for feedback on the following question:- > > > > When connecting two MM SFP/SFP+/XFP 's together...(short range). > > > > What should be the best practice receive power range ? > > SX (1G) / SR (10G) / SR10 (100G) gear generally has a receive threshold > that's higher than the maximum launch power. They are designed for > short-reach applications (in-building, data center, etc), so no > attenuation is needed. > > > Is it true that if the rx power is higher than (x?) then it shortens > > the life of the optics ? > > (assumption being made here is that MAX Rx Power is not being exceed as > > per the spec sheets of the optics) > > On short-reach optics, this should never be a problem. On long-reach > optics, receiver saturation will generally result in link errors/flaps, > and possibly high rx power warnings (depending on the gear on the > receiving end), however, these can be addressed using in-line attenuators. > > On very long-reach optics, such as ZX (1G) and ER/ZR (10G), it is possible > to damage the receivers with too hot of a signal because they are designed > for long spans and a certain amount of distance-based attenuation is > factored into the optical power budget. > > jms > From Daniel.Jameson at tdstelecom.com Wed Feb 11 21:54:14 2015 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Wed, 11 Feb 2015 21:54:14 +0000 Subject: MultiMode Fiber Connectivity... (850nm) Power Question In-Reply-To: <582468259.1095514.1423687699056.JavaMail.zimbra@snappytelecom.net> References: <909503074.1095472.1423687524675.JavaMail.zimbra@snappytelecom.net> <582468259.1095514.1423687699056.JavaMail.zimbra@snappytelecom.net> Message-ID: Usually on Multi-mode and Low-power single-mode optics the MaxOutputOpticalPower is less than or equal to the MaxInputOpticalPower, so it's not necessary to attenuate. The trade-off is optimized optics versus having an attenuator sticking out the front of the electronics. Something along the lines of -9.5 to -4 transmit power and -18 to 0 on the Receive power. Multi-Mode optics tend to be more application specific than single-mode A good rule of thumb is keep a minimum of 4dB off the bottom plus 20% of the optical budget, discounting any specific application the above optic would be optimal around -10dB. Daniel Jameson Manager - IP Network Engineering TDS Telecom -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Faisal Imtiaz Sent: Wednesday, February 11, 2015 2:48 PM To: NANOG Subject: MultiMode Fiber Connectivity... (850nm) Power Question Hello, I was looking for feedback on the following question:- When connecting two MM SFP/SFP+/XFP 's together...(short range). What should be the best practice receive power range ? Is it true that if the rx power is higher than (x?) then it shortens the life of the optics ? (assumption being made here is that MAX Rx Power is not being exceed as per the spec sheets of the optics) 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 From tom.kac at gmail.com Wed Feb 11 19:50:23 2015 From: tom.kac at gmail.com (Tom Kacprzynski) Date: Wed, 11 Feb 2015 13:50:23 -0600 Subject: Call for Presentations - CHI-NOG 05 Message-ID: *Call for Presentations* CHI-NOG 05 (Chicago Network Operators Group) May 14th 2015, Chicago, IL The Chicago Network Operators Group (CHI-NOG) is a vendor neutral organization of the networking industry. Our goal is to create a regional community of network professionals by presenting the latest technology trends, enabling collaboration, providing networking opportunities and offering certification advice. CHI-NOG will be hosting its first full-day conference on May 14th. For more information please see http://chinog.org. The CHI-NOG Program Committee is seeking proposals for presentations on relevant networking technologies with a focus on the following topics: * Network Automation * Interconnection/Peering/Cloud Exchanges * Low Latency Networks * Network Security * Internet Monitoring * Advanced BGP/MPLS Technologies * Software Define Networking * Cloud Networking Technologies * Network Operation * Networking Research and Reach Infrastructure * Open Source Networking Tools * Industry Certification *Session Format* Each presentation is 30 minutes, which includes a question and answer session. The duration can be extended per individual request to 60 minutes and will be considered by the program committee. Presentations should not contain any marketing material and should avoid discussion of commercial products but rather focus on the underlying technology. *Key Dates* * Call for Presentations ------------------------------------------------ 2/11/15 * Presentation Abstract Submission Deadline ------------------- 3/11/15 * Abstract Selection ---------------------------------------------------- 3/18/15 * Presentation Full Slides Submission Deadline ----------------- 4/15/15 * Final Selection --------------------------------------------------------- 4/29/15 * Conference ------------------------------------------------------------- 5/14/15 *Submission* Please submit presentation’s abstract proposal by filling out the submission form (http://chinog.org/meetings/chi-nog-05/abstract-submission/ ). Once your presentation is selected please provide the program committee with your photo and a short bio for web publication. The program committee is looking forward to your submission and attendance at the conference. From nellermann at broadaspect.com Thu Feb 12 02:06:23 2015 From: nellermann at broadaspect.com (Nick Ellermann) Date: Thu, 12 Feb 2015 02:06:23 +0000 Subject: Level3 routing issues today? Message-ID: Has anyone else having issues with Level3 routing traffic to the Godaddy ASN? Since about 1PM Eastern today we have had numerous customers claiming their internet was down, when it has only been a few websites they couldn't reach. It's been up and down on My FiOS link some today as well. But right Verizon seems fine they are hitting Qwest before Godaddy for where I live in VA. >From our network. (AS30259) we are going out (AS3356) and for the most part we reach our peering router in Northern Va, the we see 4.34.191.254 before time outs forever. Could this be a regional Level3 issues? Anyone from Level3 or GoDaddy that could comment? We have had an open Level3 ticket since about 4PM Eastern. Sincerely, Nick Ellermann - CTO & VP Cloud Services BroadAspect E: nellermann at broadaspect.com P: 703-297-4639 F: 703-996-4443 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. From skeeve+nanog at eintellegonetworks.com Thu Feb 12 08:12:11 2015 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Thu, 12 Feb 2015 19:12:11 +1100 Subject: Intellectual Property in Network Design Message-ID: Hi all, I have two perspectives I am trying to address with regard to network design and intellectual property. 1) The business who does the design - what are their rights? 2) The customer who asked for the rights from a consultant My personal thoughts are conflicting: - You create networks with standard protocols, configurations, etc... so it shouldn't be IP - But you can design things in interesting ways, with experience, skill, creativity.. maybe that should be IP? - But artwork are created with colors, paintbrushes, canvas... but the result is IP - A photographer takes a photo - it is IP - But how are 'how you do your Cisco/Juniper configs' possibly IP? - If I design a network one way for a customer and they want 'IP', does that mean I can't ever design a network like that again? What? I've seen a few telcos say that they own the IP related to the network design of their customers they deploy... which based on the above... feels uncomfortable... I'm really conflicted on this and wondering if anyone else has come across this situation. Perhaps any legal cases/precedent (note, I am not looking for legal advice :) If this email isn't appropriate for the list... sorry, and please feel free to respond off-line. ...Skeeve *Skeeve Stevens - Founder & Chief Network Architect* eintellego Networks Pty Ltd Email: skeeve at eintellegonetworks.com ; Web: eintellegonetworks.com Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks ; Twitter: eintellego LinkedIn: /in/skeeve ; Expert360: Profile The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering From woody at pch.net Thu Feb 12 08:45:11 2015 From: woody at pch.net (Bill Woodcock) Date: Thu, 12 Feb 2015 17:45:11 +0900 Subject: Intellectual Property in Network Design In-Reply-To: References: Message-ID: I include a "no intellectual property ownership is transferred between the Parties" clause in just about everything we do. Doesn't demand that any of the questions you raise be answered, but shuts the door to problems pretty firmly. -Bill > On Feb 12, 2015, at 17:20, Skeeve Stevens wrote: > > Hi all, > > I have two perspectives I am trying to address with regard to network > design and intellectual property. > > 1) The business who does the design - what are their rights? > > 2) The customer who asked for the rights from a consultant > > My personal thoughts are conflicting: > > - You create networks with standard protocols, configurations, etc... so it > shouldn't be IP > - But you can design things in interesting ways, with experience, skill, > creativity.. maybe that should be IP? > - But artwork are created with colors, paintbrushes, canvas... but the > result is IP > - A photographer takes a photo - it is IP > - But how are 'how you do your Cisco/Juniper configs' possibly IP? > - If I design a network one way for a customer and they want 'IP', does > that mean I can't ever design a network like that again? What? > > I've seen a few telcos say that they own the IP related to the network > design of their customers they deploy... which based on the above... feels > uncomfortable... > > I'm really conflicted on this and wondering if anyone else has come across > this situation. Perhaps any legal cases/precedent (note, I am not looking > for legal advice :) > > If this email isn't appropriate for the list... sorry, and please feel free > to respond off-line. > > ...Skeeve > > *Skeeve Stevens - Founder & Chief Network Architect* > eintellego Networks Pty Ltd > Email: skeeve at eintellegonetworks.com ; Web: eintellegonetworks.com > > Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve > > Facebook: eintellegonetworks ; > Twitter: eintellego > > LinkedIn: /in/skeeve ; Expert360: Profile > > > > The Experts Who The Experts Call > Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering From mark.tinka at seacom.mu Thu Feb 12 09:45:56 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 12 Feb 2015 11:45:56 +0200 Subject: FTTx Active-Ethernet Hardware In-Reply-To: <54DB4FD9.8000704@lanparty.ee> References: <000a01d04568$c4bf96b0$4e3ec410$@iname.com> <54DA77AC.70704@seacom.mu> <54DB4FD9.8000704@lanparty.ee> Message-ID: <54DC7654.80207@seacom.mu> On 11/Feb/15 14:49, Tarko Tikan wrote: > It is being replaced by ASR-920-24SZ-M - 24GE Fiber and 4-10GE: > Modular PSU. I don't think this ASR920 has been announced yet :) Well, it's on the web site, and our AM team gave us a price a few weeks ago. I'm just surprised why they'd do this, considering you need tons of ports in an FTTH setup, and the ASR920 is short on those. I've asked the BU to work on a 48-port switch re: the ASR920, as I think that would go well with the 4x 10Gbps uplink ports and make for a good upgrade path for the ME3600X/3800X. Cisco's thinking of getting 4x 10Gbps ports on the ASR920 (compared to 2x on the ME3600X/3800X) is if operators have customers that want to take 10Gbps ports, they can use the additional 10Gbps ports. Not sure how good an idea that is, as for me, I'd not be willing to tell customers we can do 10Gbps at a PoP with this device since I can only sell to one customer; two at the most if I'm being really pushy with the unit. I'd need some scalability. Mark. From randy at psg.com Thu Feb 12 10:19:27 2015 From: randy at psg.com (Randy Bush) Date: Thu, 12 Feb 2015 17:19:27 +0700 Subject: Intellectual Property in Network Design In-Reply-To: References: Message-ID: creative commons From skeeve+nanog at eintellegonetworks.com Thu Feb 12 12:36:33 2015 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Thu, 12 Feb 2015 23:36:33 +1100 Subject: Intellectual Property in Network Design In-Reply-To: References: Message-ID: Actually Bill... I have two (conflicting) perspectives as I said.... but to clarify: 1) A customer asked 'Can you make sure we have the IP for the network design' which I was wondering if it is even technically possible.... 2) If I design some amazing solutions... am I able to claim IP. My gut feeling is no to both of them... because, if it happen (VERY LIKELY) that somewhere, someone designs an network to the exact same specifications - to the config line - Would that mean they have infringed on my IP unknowingly, and how would I even know if I was unique in the first instance? What I am really looking for is some working, experience, precedence that backs up the view that IP on network design is actually not possible... which is my gut feeling. In the past I have always stated that, and it's never been challenged... and nor is it in this case... but, it is an important think I guess many of us should probably be aware of where we stand. ...Skeeve *Skeeve Stevens - Founder & Chief Network Architect* eintellego Networks Pty Ltd Email: skeeve at eintellegonetworks.com ; Web: eintellegonetworks.com Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks ; Twitter: eintellego LinkedIn: /in/skeeve ; Expert360: Profile The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering On Thu, Feb 12, 2015 at 7:45 PM, Bill Woodcock wrote: > > I include a "no intellectual property ownership is transferred between the > Parties" clause in just about everything we do. Doesn't demand that any of > the questions you raise be answered, but shuts the door to problems pretty > firmly. > > > -Bill > > > > On Feb 12, 2015, at 17:20, Skeeve Stevens < > skeeve+nanog at eintellegonetworks.com> wrote: > > > > Hi all, > > > > I have two perspectives I am trying to address with regard to network > > design and intellectual property. > > > > 1) The business who does the design - what are their rights? > > > > 2) The customer who asked for the rights from a consultant > > > > My personal thoughts are conflicting: > > > > - You create networks with standard protocols, configurations, etc... so > it > > shouldn't be IP > > - But you can design things in interesting ways, with experience, skill, > > creativity.. maybe that should be IP? > > - But artwork are created with colors, paintbrushes, canvas... but the > > result is IP > > - A photographer takes a photo - it is IP > > - But how are 'how you do your Cisco/Juniper configs' possibly IP? > > - If I design a network one way for a customer and they want 'IP', does > > that mean I can't ever design a network like that again? What? > > > > I've seen a few telcos say that they own the IP related to the network > > design of their customers they deploy... which based on the above... > feels > > uncomfortable... > > > > I'm really conflicted on this and wondering if anyone else has come > across > > this situation. Perhaps any legal cases/precedent (note, I am not > looking > > for legal advice :) > > > > If this email isn't appropriate for the list... sorry, and please feel > free > > to respond off-line. > > > > ...Skeeve > > > > *Skeeve Stevens - Founder & Chief Network Architect* > > eintellego Networks Pty Ltd > > Email: skeeve at eintellegonetworks.com ; Web: eintellegonetworks.com > > > > Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve > > > > Facebook: eintellegonetworks ; > > Twitter: eintellego > > > > LinkedIn: /in/skeeve ; Expert360: > Profile > > > > > > > > The Experts Who The Experts Call > > Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering > > From skeeve+nanog at eintellegonetworks.com Thu Feb 12 12:37:28 2015 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Thu, 12 Feb 2015 23:37:28 +1100 Subject: Intellectual Property in Network Design In-Reply-To: References: Message-ID: Hey Randy, I'm keen to see how you might think that fits in to the context? ...Skeeve *Skeeve Stevens - Founder & Chief Network Architect* eintellego Networks Pty Ltd Email: skeeve at eintellegonetworks.com ; Web: eintellegonetworks.com Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks ; Twitter: eintellego LinkedIn: /in/skeeve ; Expert360: Profile The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering 2015-02-12 21:19 GMT+11:00 Randy Bush : > creative commons > From randy at psg.com Thu Feb 12 12:42:07 2015 From: randy at psg.com (Randy Bush) Date: Thu, 12 Feb 2015 19:42:07 +0700 Subject: Intellectual Property in Network Design In-Reply-To: References: Message-ID: > I'm keen to see how you might think that fits in to the context? >> creative commons i prefer to be paid for being able to think, not for what i once thought. creative commons suits my needs for network designs. randy --- Q: Because it reverses the logical flow of conversation. A: Why is top posting frowned upon? From mark.tinka at seacom.mu Thu Feb 12 12:53:41 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 12 Feb 2015 14:53:41 +0200 Subject: Intellectual Property in Network Design In-Reply-To: References: Message-ID: <54DCA255.9010801@seacom.mu> On 12/Feb/15 14:36, Skeeve Stevens wrote: > > What I am really looking for is some working, experience, precedence that > backs up the view that IP on network design is actually not possible... > which is my gut feeling. I've designed some pretty unique and profitable features using tech. (not necessarily open standards, but available to anyone who buys the hardware) because I was able to interpret the feature better than the competition, and make it do things it wasn't originally intended for. Now, when I leave that company and repeat the same at new company (out of sheer fun, perhaps), can the previous company claim IP, or would I be the one to claim IP since I was the one who thought up the idea in the first place? Configurations between operators are all the same. How you put them together is what can set you apart in your market. I suppose your question is whether "how you put them together that sets up apart from the competition" is worth the IP debate. Mark. From imb at protected-networks.net Thu Feb 12 12:58:57 2015 From: imb at protected-networks.net (Michael Butler) Date: Thu, 12 Feb 2015 07:58:57 -0500 Subject: Intellectual Property in Network Design In-Reply-To: References: Message-ID: <54DCA391.30209@protected-networks.net> On 02/12/15 07:42, Randy Bush wrote: >> I'm keen to see how you might think that fits in to the context? >>> creative commons > > i prefer to be paid for being able to think, not for what i once > thought. creative commons suits my needs for network designs. And to compound the (perceived) problem, any IP embedded in a network design is almost always "prior art". It's not a rabbit-hole worth going down - I agree with Randy, imb From brandon at rd.bbc.co.uk Thu Feb 12 13:00:27 2015 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Thu, 12 Feb 2015 13:00:27 GMT Subject: Intellectual Property in Network Design Message-ID: <201502121300.NAA01760@sunf10.rd.bbc.co.uk> > Actually Bill... I have two (conflicting) perspectives as I said.... but to > clarify: > > 1) A customer asked 'Can you make sure we have the IP for the network > design' which I was wondering if it is even technically possible.... I think they mean "we don't want you coming back and trying to make any claim on us for anything we may do with the work you did for us" that may mean something like they extend it or roll out some more to the same design or start selling it as part of a system to their customers There's been legal cases with architects designing a store building for a chain and the chain then reusing the desing for more sites. I've not heard of it for networks and your customer wants to keep it that way. > 2) If I design some amazing solutions... am I able to claim IP. Doesn't matter but if you did they want the rights to it already brandon From mark.tinka at seacom.mu Thu Feb 12 13:05:22 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 12 Feb 2015 15:05:22 +0200 Subject: Intellectual Property in Network Design In-Reply-To: <54DCA391.30209@protected-networks.net> References: <54DCA391.30209@protected-networks.net> Message-ID: <54DCA512.1040809@seacom.mu> On 12/Feb/15 14:58, Michael Butler wrote: > > And to compound the (perceived) problem, any IP embedded in a network > design is almost always "prior art". It's not a rabbit-hole worth going > down - I agree with Randy, Agree. Mark. From alex at corp.nac.net Thu Feb 12 13:06:16 2015 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 12 Feb 2015 13:06:16 +0000 Subject: gmail spam help Message-ID: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> Is there anyone on-list that can help me with a world -> gmail email issue, where email is being considering spam by gmail erroneously? Thanks. From randy at psg.com Thu Feb 12 14:31:28 2015 From: randy at psg.com (Randy Bush) Date: Thu, 12 Feb 2015 21:31:28 +0700 Subject: Intellectual Property in Network Design In-Reply-To: <54DCA391.30209@protected-networks.net> References: <54DCA391.30209@protected-networks.net> Message-ID: > And to compound the (perceived) problem, any IP embedded in a network > design is almost always "prior art". It's not a rabbit-hole worth going > down - I agree with Randy, i have four lives. iij research, dev, ... our goal is to publish our ideas there are coworkers doing very innovative design for datacenter stuff. we do not patent, ... open source routing security design, specs, software, ... bsd and cc licensed. an open source crypto design and code project. bsd and cc licensed. and the last is giving away as much networking design and operational knowledge as i can to engineers in the developing world. steal this book! randy From josh at imaginenetworksllc.com Thu Feb 12 14:31:58 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 12 Feb 2015 09:31:58 -0500 Subject: gmail spam help In-Reply-To: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> Message-ID: Create a filter. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Feb 12, 2015 8:11 AM, "Alex Rubenstein" wrote: > Is there anyone on-list that can help me with a world -> gmail email > issue, where email is being considering spam by gmail erroneously? > > Thanks. > > > From nanog at ics-il.net Thu Feb 12 14:40:30 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 12 Feb 2015 08:40:30 -0600 (CST) Subject: gmail spam help In-Reply-To: Message-ID: <22247730.4956.1423752014624.JavaMail.mhammett@ThunderFuck> Don't use GMail for things you care about? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Josh Luthman" To: "Alex Rubenstein" Cc: "NANOG list" Sent: Thursday, February 12, 2015 8:31:58 AM Subject: Re: gmail spam help Create a filter. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Feb 12, 2015 8:11 AM, "Alex Rubenstein" wrote: > Is there anyone on-list that can help me with a world -> gmail email > issue, where email is being considering spam by gmail erroneously? > > Thanks. > > > From alex at corp.nac.net Thu Feb 12 15:41:32 2015 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 12 Feb 2015 15:41:32 +0000 Subject: gmail spam help In-Reply-To: References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> Message-ID: <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> I should have been clearer. I have been getting complaints from my sales folks that when they send emails to people who use gmail (either a gmail account or google apps) that they recipient is reporting that the email is ending up in the Spam folder. So, I tested this myself, sending an email from alex at corp.nac.net to rubenstein45 at gmail.com [cid:image001.png at 01D046AD.3B2FA890] This is curious to me, since @corp.nac.net is a small exchange implementation with only about 50 users behind it, and there is no question that there is no spamming going on from here. So, it’s not a question of adding a filter or not using gmail; it is not me who is using gmail in this problem. From: Josh Luthman [mailto:josh at imaginenetworksllc.com] Sent: Thursday, February 12, 2015 9:32 AM To: Alex Rubenstein Cc: NANOG list Subject: Re: gmail spam help Create a filter. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Feb 12, 2015 8:11 AM, "Alex Rubenstein" > wrote: Is there anyone on-list that can help me with a world -> gmail email issue, where email is being considering spam by gmail erroneously? Thanks. From khelms at zcorum.com Thu Feb 12 15:51:22 2015 From: khelms at zcorum.com (Scott Helms) Date: Thu, 12 Feb 2015 10:51:22 -0500 Subject: gmail spam help In-Reply-To: <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> Message-ID: I'd be interested to know how you can be so adamant about the lack of spam from this specific server. A great percentage of the spam hitting servers I have visibility into comes from very similar kinds of set ups because they tend to have little or no over sight in place. Also, lots of commercial email gets flagged as spam by users, even when they opted in for the email. If enough people flagged email from this server as spam it will cause Google to consider other email from the same small server as likely to be spam as well. Small systems, especially new ones, tend to unintentionally look like spam sources by not having proper reverse records, making sure you have SPF set up for the domain, etc. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Feb 12, 2015 at 10:41 AM, Alex Rubenstein wrote: > I should have been clearer. > > I have been getting complaints from my sales folks that when they send > emails to people who use gmail (either a gmail account or google apps) that > they recipient is reporting that the email is ending up in the Spam folder. > So, I tested this myself, sending an email from alex at corp.nac.net alex at corp.nac.net> to rubenstein45 at gmail.com > > > [cid:image001.png at 01D046AD.3B2FA890] > > This is curious to me, since @corp.nac.net is a small exchange > implementation with only about 50 users behind it, and there is no question > that there is no spamming going on from here. > > So, it’s not a question of adding a filter or not using gmail; it is not > me who is using gmail in this problem. > > > > From: Josh Luthman [mailto:josh at imaginenetworksllc.com] > Sent: Thursday, February 12, 2015 9:32 AM > To: Alex Rubenstein > Cc: NANOG list > Subject: Re: gmail spam help > > > Create a filter. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Feb 12, 2015 8:11 AM, "Alex Rubenstein" alex at corp.nac.net>> wrote: > Is there anyone on-list that can help me with a world -> gmail email > issue, where email is being considering spam by gmail erroneously? > > Thanks. > > From alex at corp.nac.net Thu Feb 12 15:54:52 2015 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 12 Feb 2015 15:54:52 +0000 Subject: gmail spam help In-Reply-To: References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> Message-ID: <748ed49076164b8b97b38a0b0dff0b95@exch2013-1.hq.nac.net> Mainly because I own it, and the people who use it. The server has been around 10+ years and has tight oversight. SPF is proper. This is a recent issue. From: Scott Helms [mailto:khelms at zcorum.com] Sent: Thursday, February 12, 2015 10:51 AM To: Alex Rubenstein Cc: Josh Luthman; NANOG list Subject: Re: gmail spam help I'd be interested to know how you can be so adamant about the lack of spam from this specific server. A great percentage of the spam hitting servers I have visibility into comes from very similar kinds of set ups because they tend to have little or no over sight in place. Also, lots of commercial email gets flagged as spam by users, even when they opted in for the email. If enough people flagged email from this server as spam it will cause Google to consider other email from the same small server as likely to be spam as well. Small systems, especially new ones, tend to unintentionally look like spam sources by not having proper reverse records, making sure you have SPF set up for the domain, etc. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Feb 12, 2015 at 10:41 AM, Alex Rubenstein > wrote: I should have been clearer. I have been getting complaints from my sales folks that when they send emails to people who use gmail (either a gmail account or google apps) that they recipient is reporting that the email is ending up in the Spam folder. So, I tested this myself, sending an email from alex at corp.nac.net> to rubenstein45 at gmail.com> [cid:image001.png at 01D046AD.3B2FA890] This is curious to me, since @corp.nac.net is a small exchange implementation with only about 50 users behind it, and there is no question that there is no spamming going on from here. So, it’s not a question of adding a filter or not using gmail; it is not me who is using gmail in this problem. From: Josh Luthman [mailto:josh at imaginenetworksllc.com] Sent: Thursday, February 12, 2015 9:32 AM To: Alex Rubenstein Cc: NANOG list Subject: Re: gmail spam help Create a filter. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Feb 12, 2015 8:11 AM, "Alex Rubenstein" >> wrote: Is there anyone on-list that can help me with a world -> gmail email issue, where email is being considering spam by gmail erroneously? Thanks. From bw-ml at mube.co.uk Thu Feb 12 15:59:18 2015 From: bw-ml at mube.co.uk (Ben Whorwood) Date: Thu, 12 Feb 2015 15:59:18 +0000 Subject: gmail spam help In-Reply-To: <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> Message-ID: <54DCCDD6.7010804@mube.co.uk> From dtaylor at vocalabs.com Thu Feb 12 16:06:19 2015 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Thu, 12 Feb 2015 10:06:19 -0600 Subject: gmail spam help In-Reply-To: <748ed49076164b8b97b38a0b0dff0b95@exch2013-1.hq.nac.net> References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> <748ed49076164b8b97b38a0b0dff0b95@exch2013-1.hq.nac.net> Message-ID: <54DCCF7B.10306@vocalabs.com> Possibly related: http://www.ahbl.org/content/changes-ahbl We had to manually remove it from spamassassin for our local installation, and I am pretty sure that a lot of sites still haven't figured it out so there's a lot of false positives being generated all over the place to throw off even filters that don't use it directly. On 02/12/2015 09:54 AM, Alex Rubenstein wrote: > Mainly because I own it, and the people who use it. The server has been around 10+ years and has tight oversight. SPF is proper. This is a recent issue. > > > > > > > From: Scott Helms [mailto:khelms at zcorum.com] > Sent: Thursday, February 12, 2015 10:51 AM > To: Alex Rubenstein > Cc: Josh Luthman; NANOG list > Subject: Re: gmail spam help > > I'd be interested to know how you can be so adamant about the lack of spam from this specific server. A great percentage of the spam hitting servers I have visibility into comes from very similar kinds of set ups because they tend to have little or no over sight in place. > > Also, lots of commercial email gets flagged as spam by users, even when they opted in for the email. If enough people flagged email from this server as spam it will cause Google to consider other email from the same small server as likely to be spam as well. Small systems, especially new ones, tend to unintentionally look like spam sources by not having proper reverse records, making sure you have SPF set up for the domain, etc. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Thu, Feb 12, 2015 at 10:41 AM, Alex Rubenstein > wrote: > I should have been clearer. > > I have been getting complaints from my sales folks that when they send emails to people who use gmail (either a gmail account or google apps) that they recipient is reporting that the email is ending up in the Spam folder. So, I tested this myself, sending an email from alex at corp.nac.net> to rubenstein45 at gmail.com> > > [cid:image001.png at 01D046AD.3B2FA890] > > This is curious to me, since @corp.nac.net is a small exchange implementation with only about 50 users behind it, and there is no question that there is no spamming going on from here. > > So, it’s not a question of adding a filter or not using gmail; it is not me who is using gmail in this problem. > > > > From: Josh Luthman [mailto:josh at imaginenetworksllc.com] > Sent: Thursday, February 12, 2015 9:32 AM > To: Alex Rubenstein > Cc: NANOG list > Subject: Re: gmail spam help > > > Create a filter. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Feb 12, 2015 8:11 AM, "Alex Rubenstein" >> wrote: > Is there anyone on-list that can help me with a world -> gmail email issue, where email is being considering spam by gmail erroneously? > > Thanks. > -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From khelms at zcorum.com Thu Feb 12 16:06:34 2015 From: khelms at zcorum.com (Scott Helms) Date: Thu, 12 Feb 2015 11:06:34 -0500 Subject: gmail spam help In-Reply-To: <748ed49076164b8b97b38a0b0dff0b95@exch2013-1.hq.nac.net> References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> <748ed49076164b8b97b38a0b0dff0b95@exch2013-1.hq.nac.net> Message-ID: Alex, I won't begin to claim to know the root cause behind this, but "I own it" isn't a good reason to say that no spam has come from it, indeed it's not even a reason to say that a great amount of spam hasn't come from it. The only way Google allows contact on these issues is via this form: https://support.google.com/mail/contact/msgdelivery I also see that your domain is listed by http://www.squidblacklist.org/ http://mxtoolbox.com/SuperTool.aspx?action=blacklist%3acorp.nac.net&run=toolpage Clearly it's not just Google that sees some issues, but your domain doesn't appear to be on any other email black lists, which generally means that a machine(s) on your network is/was compromised and being used in a phishing attack. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Feb 12, 2015 at 10:54 AM, Alex Rubenstein wrote: > Mainly because I own it, and the people who use it. The server has been > around 10+ years and has tight oversight. SPF is proper. This is a recent > issue. > > > > > > > > > > > > > > *From:* Scott Helms [mailto:khelms at zcorum.com] > *Sent:* Thursday, February 12, 2015 10:51 AM > *To:* Alex Rubenstein > *Cc:* Josh Luthman; NANOG list > *Subject:* Re: gmail spam help > > > > I'd be interested to know how you can be so adamant about the lack of spam > from this specific server. A great percentage of the spam hitting servers > I have visibility into comes from very similar kinds of set ups because > they tend to have little or no over sight in place. > > > > Also, lots of commercial email gets flagged as spam by users, even when > they opted in for the email. If enough people flagged email from this > server as spam it will cause Google to consider other email from the same > small server as likely to be spam as well. Small systems, especially new > ones, tend to unintentionally look like spam sources by not having proper > reverse records, making sure you have SPF set up for the domain, etc. > > > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > > On Thu, Feb 12, 2015 at 10:41 AM, Alex Rubenstein > wrote: > > I should have been clearer. > > I have been getting complaints from my sales folks that when they send > emails to people who use gmail (either a gmail account or google apps) that > they recipient is reporting that the email is ending up in the Spam folder. > So, I tested this myself, sending an email from alex at corp.nac.net alex at corp.nac.net> to rubenstein45 at gmail.com > > > [cid:image001.png at 01D046AD.3B2FA890] > > This is curious to me, since @corp.nac.net is a small exchange > implementation with only about 50 users behind it, and there is no question > that there is no spamming going on from here. > > So, it’s not a question of adding a filter or not using gmail; it is not > me who is using gmail in this problem. > > > > From: Josh Luthman [mailto:josh at imaginenetworksllc.com] > Sent: Thursday, February 12, 2015 9:32 AM > To: Alex Rubenstein > Cc: NANOG list > Subject: Re: gmail spam help > > > Create a filter. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Feb 12, 2015 8:11 AM, "Alex Rubenstein" alex at corp.nac.net>> wrote: > Is there anyone on-list that can help me with a world -> gmail email > issue, where email is being considering spam by gmail erroneously? > > Thanks. > > > From pmsac.nanog at gmail.com Thu Feb 12 16:08:08 2015 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Thu, 12 Feb 2015 16:08:08 +0000 Subject: gmail spam help In-Reply-To: <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> Message-ID: See https://support.google.com/mail/answer/81126 which may take you to https://support.google.com/mail/troubleshooter/2696779 and eventually to https://support.google.com/mail/contact/bulk_send_new?hl=en&rd=1 HTH. On 12 February 2015 at 15:41, Alex Rubenstein wrote: > I should have been clearer. > > I have been getting complaints from my sales folks that when they send > emails to people who use gmail (either a gmail account or google apps) that > they recipient is reporting that the email is ending up in the Spam folder. > So, I tested this myself, sending an email from alex at corp.nac.net alex at corp.nac.net> to rubenstein45 at gmail.com > > > [cid:image001.png at 01D046AD.3B2FA890] > > This is curious to me, since @corp.nac.net is a small exchange > implementation with only about 50 users behind it, and there is no question > that there is no spamming going on from here. > > So, it’s not a question of adding a filter or not using gmail; it is not > me who is using gmail in this problem. > > > > From: Josh Luthman [mailto:josh at imaginenetworksllc.com] > Sent: Thursday, February 12, 2015 9:32 AM > To: Alex Rubenstein > Cc: NANOG list > Subject: Re: gmail spam help > > > Create a filter. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Feb 12, 2015 8:11 AM, "Alex Rubenstein" alex at corp.nac.net>> wrote: > Is there anyone on-list that can help me with a world -> gmail email > issue, where email is being considering spam by gmail erroneously? > > Thanks. > > From skeeve+nanog at eintellegonetworks.com Thu Feb 12 16:12:08 2015 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Fri, 13 Feb 2015 03:12:08 +1100 Subject: Intellectual Property in Network Design In-Reply-To: <54DCA255.9010801@seacom.mu> References: <54DCA255.9010801@seacom.mu> Message-ID: Exactly my thoughts Mark.... ...Skeeve *Skeeve Stevens - Founder & Chief Network Architect* eintellego Networks Pty Ltd Email: skeeve at eintellegonetworks.com ; Web: eintellegonetworks.com Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks ; Twitter: eintellego LinkedIn: /in/skeeve ; Expert360: Profile The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering On Thu, Feb 12, 2015 at 11:53 PM, Mark Tinka wrote: > > On 12/Feb/15 14:36, Skeeve Stevens wrote: > > > > What I am really looking for is some working, experience, precedence that > > backs up the view that IP on network design is actually not possible... > > which is my gut feeling. > > I've designed some pretty unique and profitable features using tech. > (not necessarily open standards, but available to anyone who buys the > hardware) because I was able to interpret the feature better than the > competition, and make it do things it wasn't originally intended for. > > Now, when I leave that company and repeat the same at new company (out > of sheer fun, perhaps), can the previous company claim IP, or would I be > the one to claim IP since I was the one who thought up the idea in the > first place? > > Configurations between operators are all the same. How you put them > together is what can set you apart in your market. I suppose your > question is whether "how you put them together that sets up apart from > the competition" is worth the IP debate. > > Mark. > > > From skeeve+nanog at eintellegonetworks.com Thu Feb 12 16:15:19 2015 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Fri, 13 Feb 2015 03:15:19 +1100 Subject: Intellectual Property in Network Design In-Reply-To: <318468128.3773927.1423754878276.JavaMail.yahoo@mail.yahoo.com> References: <318468128.3773927.1423754878276.JavaMail.yahoo@mail.yahoo.com> Message-ID: I like this take on it... thanks David. ...Skeeve *Skeeve Stevens - Founder & Chief Network Architect* eintellego Networks Pty Ltd Email: skeeve at eintellegonetworks.com ; Web: eintellegonetworks.com Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks ; Twitter: eintellego LinkedIn: /in/skeeve ; Expert360: Profile The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering On Fri, Feb 13, 2015 at 2:27 AM, David Barak wrote: > On Thursday, February 12, 2015 7:38 AM, Skeeve Stevens < > skeeve+nanog at eintellegonetworks.com> wrote: > > > > >Actually Bill... I have two (conflicting) perspectives as I said.... but > to > clarify: > > >1) A customer asked 'Can you make sure we have the IP for the network > design' which I was wondering if it is even technically possible.... > > >2) If I design some amazing solutions... am I able to claim IP. > > It is worth differentiating between the design itself and the > documentation of said design. The latter is clearly and totally IP, and > you could present that to the customer as "theirs": theirs and not yours - > that is, you would use different templates, naming conventions, etc. if you > created from whole cloth a similar design for a different customer in a > similar situation. They may be attempting to make sure that their network > documents don't show up as examples or other presentations for other > customers. > > As an example, an architecture document or a network assessment would be > covered by copyright law, and as such could be assigned to the author, the > company which created it, or could be "work-for-hire" and assigned to the > hiring company, depending on the contract in question. > > As to an amazing design solution, the USPTO has rules for that - you could > patent your design, but in our line of work that'd be a high bar given > prior art. > > David Barak > Need Geek Rock? Try The Franchise: > http://www.cdbaby.com/all/thefranchise > > > > > > From bill at herrin.us Thu Feb 12 16:18:21 2015 From: bill at herrin.us (William Herrin) Date: Thu, 12 Feb 2015 11:18:21 -0500 Subject: Intellectual Property in Network Design In-Reply-To: References: Message-ID: On Thu, Feb 12, 2015 at 7:36 AM, Skeeve Stevens wrote: > Actually Bill... I have two (conflicting) perspectives as I said.... but to > clarify: > > 1) A customer asked 'Can you make sure we have the IP for the network > design' which I was wondering if it is even technically possible.... Hi Skeeve, IANAL but I play one when I can get away with it. This is usually covered as, "Contractor agrees to provide Customer with all documents, diagrams, software or other materials produced in the course of the contract. Contractor shall upon request assign all ownership of such materials to Customer. Contractor shall retain no copies of said material following termination of the contract." So yes, it's technically feasible. > 2) If I design some amazing solutions... am I able to claim IP. If it's copyrightable (a "solution" may be), then as a contractor (not an employee) the copyright vests in you. If the contract states that you agree to transfer it to the customer then you breach the contract if you don't. If the contract says the copyrights are theirs then at least that part of the contract is probably void. Barring W2 employment copyrights nearly always vest in the individual who first put them in to a tangible form. There are explicit and narrow exceptions in the law. Preface of a book. That sort of thing. It's unlikely you'll run afoul of any of them. Lawyers get this wrong shockingly often. IP doesn't vest in the customer and can't be transferred until it exists. The creator is a W2 employee. The contractor agrees to transfer it following creation. Just about everything else is void. If the contract doesn't say one way or another then the lawyer who wrote it was asleep at the wheel. However... the techniques used to produce the solution usually classify as ideas. You may be bound under non-disclosure terms to not share ideas produced for the customer within the scope of the customer's system but ideas are never property. You can't own them and neither can the customer. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bw-ml at mube.co.uk Thu Feb 12 16:27:56 2015 From: bw-ml at mube.co.uk (Ben Whorwood) Date: Thu, 12 Feb 2015 16:27:56 +0000 Subject: gmail spam help In-Reply-To: <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> Message-ID: <54DCD48C.9080900@mube.co.uk> It may be worth taking a look at the Bulk Senders Guidelines to make sure any additional steps suggested by Google (DKIM signing, etc) have been taken: https://support.google.com/mail/answer/81126?hl=en It may also be that other Gmail users have flagged your emails as spam in the past. Thanks, Ben Apologies, the content of my last email was stripped. On 12/02/15 15:41, Alex Rubenstein wrote: > I should have been clearer. > > I have been getting complaints from my sales folks that when they send emails to people who use gmail (either a gmail account or google apps) that they recipient is reporting that the email is ending up in the Spam folder. So, I tested this myself, sending an email from alex at corp.nac.net to rubenstein45 at gmail.com > > [cid:image001.png at 01D046AD.3B2FA890] > > This is curious to me, since @corp.nac.net is a small exchange implementation with only about 50 users behind it, and there is no question that there is no spamming going on from here. > > So, it’s not a question of adding a filter or not using gmail; it is not me who is using gmail in this problem. > > > > From: Josh Luthman [mailto:josh at imaginenetworksllc.com] > Sent: Thursday, February 12, 2015 9:32 AM > To: Alex Rubenstein > Cc: NANOG list > Subject: Re: gmail spam help > > > Create a filter. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Feb 12, 2015 8:11 AM, "Alex Rubenstein" > wrote: > Is there anyone on-list that can help me with a world -> gmail email issue, where email is being considering spam by gmail erroneously? > > Thanks. > From surfer at mauigateway.com Thu Feb 12 19:29:01 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 12 Feb 2015 11:29:01 -0800 Subject: mpls over microwave Message-ID: <20150212112901.39E3F8A4@m0005298.ppops.net> Just in case anyone looks this thread up in the future... We're likely going with Aviat and their "DAC GE card EXD-181-002" cards. >From the company: "Yes the Ethernet card does support jumbo frame size, IPV6 and MPLS EXP bits, QOS and VLANs with 802.1q tagging." scott From mel at beckman.org Thu Feb 12 19:38:04 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 12 Feb 2015 19:38:04 +0000 Subject: Gmail slow? Message-ID: <6D79414A-646C-49AF-BF21-CDC5301CFBBA@beckman.org> We are getting many complaints demo diverse networks on both coasts that Gmail is very sluggish, sometimes taking a 20 to 30 seconds to refresh the mail items list. Is anyone else seeing this? -mel beckman Becknet.com From josh at imaginenetworksllc.com Thu Feb 12 19:39:09 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 12 Feb 2015 14:39:09 -0500 Subject: Gmail slow? In-Reply-To: <6D79414A-646C-49AF-BF21-CDC5301CFBBA@beckman.org> References: <6D79414A-646C-49AF-BF21-CDC5301CFBBA@beckman.org> Message-ID: I'm on Google Apps and gmail.com (personal). Web interface, assuming that's what you're talking about. No problems from here. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Feb 12, 2015 at 2:38 PM, Mel Beckman wrote: > We are getting many complaints demo diverse networks on both coasts that > Gmail is very sluggish, sometimes taking a 20 to 30 seconds to refresh the > mail items list. Is anyone else seeing this? > > -mel beckman > Becknet.com From owen at delong.com Thu Feb 12 19:45:35 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Feb 2015 11:45:35 -0800 Subject: Intellectual Property in Network Design In-Reply-To: References: Message-ID: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> The extent to which this is technically feasible and how one must go about it actually varies greatly from jurisdiction to jurisdiction. Something well worth considering given the number of jurisdictions already mentioned in the current discussion. There are a number of possible concerns that the customer in question may be attempting to solve with their request. The first step is to identify which concern(s) they want to address. 1. Do they want to make sure that they have sufficient rights in the design that they can replicate/modify/otherwise use it without further compensating you? 2. Do they want to make sure that you surrender your rights in the design so that you are not able to provide an identical solution to another customer in the future and/or that you do not use their design as an example or case study for your marketing purposes? 3. Do they not really have a concern, but someone told them that it was important to ask this question? 4. Do they want to make sure this treated as a “work for hire” with all the legal implications that caries? There are probably others that I am not thinking of at the moment. Owen > On Feb 12, 2015, at 08:18 , William Herrin wrote: > > On Thu, Feb 12, 2015 at 7:36 AM, Skeeve Stevens > wrote: >> Actually Bill... I have two (conflicting) perspectives as I said.... but to >> clarify: >> >> 1) A customer asked 'Can you make sure we have the IP for the network >> design' which I was wondering if it is even technically possible.... > > Hi Skeeve, > > IANAL but I play one when I can get away with it. > > This is usually covered as, "Contractor agrees to provide Customer > with all documents, diagrams, software or other materials produced in > the course of the contract. Contractor shall upon request assign all > ownership of such materials to Customer. Contractor shall retain no > copies of said material following termination of the contract." > > So yes, it's technically feasible. > > >> 2) If I design some amazing solutions... am I able to claim IP. > > If it's copyrightable (a "solution" may be), then as a contractor (not > an employee) the copyright vests in you. If the contract states that > you agree to transfer it to the customer then you breach the contract > if you don't. > > If the contract says the copyrights are theirs then at least that part > of the contract is probably void. Barring W2 employment copyrights > nearly always vest in the individual who first put them in to a > tangible form. There are explicit and narrow exceptions in the law. > Preface of a book. That sort of thing. It's unlikely you'll run afoul > of any of them. > > Lawyers get this wrong shockingly often. IP doesn't vest in the > customer and can't be transferred until it exists. The creator is a W2 > employee. The contractor agrees to transfer it following creation. > Just about everything else is void. > > If the contract doesn't say one way or another then the lawyer who > wrote it was asleep at the wheel. > > However... the techniques used to produce the solution usually > classify as ideas. You may be bound under non-disclosure terms to not > share ideas produced for the customer within the scope of the > customer's system but ideas are never property. You can't own them and > neither can the customer. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: From aaron at heyaaron.com Thu Feb 12 22:13:56 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 12 Feb 2015 14:13:56 -0800 Subject: Vancouver WA Comcast Outage? Message-ID: We just lost a handful of customers in Vancouver WA on Comcast. Voice and data are out. Initial reports are saying a transformer blew down town. -A From frnkblk at iname.com Thu Feb 12 23:57:37 2015 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 12 Feb 2015 17:57:37 -0600 Subject: gmail spam help In-Reply-To: <54DCD48C.9080900@mube.co.uk> References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> <54DCD48C.9080900@mube.co.uk> Message-ID: <003101d0471f$ade2bae0$09a830a0$@iname.com> That's my thought, too -- add DKIM and also work through those Google forms. I didn't see any red flags when I checked an IP and your host against some email "measurement" sites. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ben Whorwood Sent: Thursday, February 12, 2015 10:28 AM To: nanog at nanog.org Subject: Re: gmail spam help It may be worth taking a look at the Bulk Senders Guidelines to make sure any additional steps suggested by Google (DKIM signing, etc) have been taken: https://support.google.com/mail/answer/81126?hl=en It may also be that other Gmail users have flagged your emails as spam in the past. Thanks, Ben Apologies, the content of my last email was stripped. On 12/02/15 15:41, Alex Rubenstein wrote: > I should have been clearer. > > I have been getting complaints from my sales folks that when they send emails to people who use gmail (either a gmail account or google apps) that they recipient is reporting that the email is ending up in the Spam folder. So, I tested this myself, sending an email from alex at corp.nac.net to rubenstein45 at gmail.com > > [cid:image001.png at 01D046AD.3B2FA890] > > This is curious to me, since @corp.nac.net is a small exchange implementation with only about 50 users behind it, and there is no question that there is no spamming going on from here. > > So, it’s not a question of adding a filter or not using gmail; it is not me who is using gmail in this problem. > > > > From: Josh Luthman [mailto:josh at imaginenetworksllc.com] > Sent: Thursday, February 12, 2015 9:32 AM > To: Alex Rubenstein > Cc: NANOG list > Subject: Re: gmail spam help > > > Create a filter. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Feb 12, 2015 8:11 AM, "Alex Rubenstein" > wrote: > Is there anyone on-list that can help me with a world -> gmail email issue, where email is being considering spam by gmail erroneously? > > Thanks. > From ahad at telcoinabox.com Fri Feb 13 00:43:14 2015 From: ahad at telcoinabox.com (Ahad Aboss) Date: Fri, 13 Feb 2015 11:43:14 +1100 Subject: Intellectual Property in Network Design In-Reply-To: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> Message-ID: <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> Hi Skeeve, In a sense, you are an artist as network architecture is an art in itself. It involves interaction with time, processes, people and things or an intersection between all. As an architect, you analyze customer needs and design a solution using your creative ideas to address their business driven needs today. In some ways, this is easier because creating a business centric network provides you some parameters to design within. You might mix and match technologies that will suite one business better than the other but it's your creative ideas. It's not secrets of their trade that you replicate or takeaway. You are master of the trade and you design a solution that works best for them. While some design principles for application service provider, enterprise, carrier or ISP have similarities, no two network is the same. If you don't claim IP on the design or publish company names you've done the designs for, under what jurisdiction can they claim what you designed is their IP? What if their requirement changes in 6 months from now? If a architect designs a road system in a particular way, does it mean he/she can't design another road again because of IP issue? I would tend to disagree. It may not answer your questions but I hope it provides some content to support your case :) Regards, Ahad -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Owen DeLong Sent: Friday, 13 February 2015 6:46 AM To: William Herrin Cc: nanog at nanog.org Subject: Re: Intellectual Property in Network Design The extent to which this is technically feasible and how one must go about it actually varies greatly from jurisdiction to jurisdiction. Something well worth considering given the number of jurisdictions already mentioned in the current discussion. There are a number of possible concerns that the customer in question may be attempting to solve with their request. The first step is to identify which concern(s) they want to address. 1. Do they want to make sure that they have sufficient rights in the design that they can replicate/modify/otherwise use it without further compensating you? 2. Do they want to make sure that you surrender your rights in the design so that you are not able to provide an identical solution to another customer in the future and/or that you do not use their design as an example or case study for your marketing purposes? 3. Do they not really have a concern, but someone told them that it was important to ask this question? 4. Do they want to make sure this treated as a "work for hire" with all the legal implications that caries? There are probably others that I am not thinking of at the moment. Owen > On Feb 12, 2015, at 08:18 , William Herrin wrote: > > On Thu, Feb 12, 2015 at 7:36 AM, Skeeve Stevens > wrote: >> Actually Bill... I have two (conflicting) perspectives as I said.... >> but to >> clarify: >> >> 1) A customer asked 'Can you make sure we have the IP for the network >> design' which I was wondering if it is even technically possible.... > > Hi Skeeve, > > IANAL but I play one when I can get away with it. > > This is usually covered as, "Contractor agrees to provide Customer > with all documents, diagrams, software or other materials produced in > the course of the contract. Contractor shall upon request assign all > ownership of such materials to Customer. Contractor shall retain no > copies of said material following termination of the contract." > > So yes, it's technically feasible. > > >> 2) If I design some amazing solutions... am I able to claim IP. > > If it's copyrightable (a "solution" may be), then as a contractor (not > an employee) the copyright vests in you. If the contract states that > you agree to transfer it to the customer then you breach the contract > if you don't. > > If the contract says the copyrights are theirs then at least that part > of the contract is probably void. Barring W2 employment copyrights > nearly always vest in the individual who first put them in to a > tangible form. There are explicit and narrow exceptions in the law. > Preface of a book. That sort of thing. It's unlikely you'll run afoul > of any of them. > > Lawyers get this wrong shockingly often. IP doesn't vest in the > customer and can't be transferred until it exists. The creator is a W2 > employee. The contractor agrees to transfer it following creation. > Just about everything else is void. > > If the contract doesn't say one way or another then the lawyer who > wrote it was asleep at the wheel. > > However... the techniques used to produce the solution usually > classify as ideas. You may be bound under non-disclosure terms to not > share ideas produced for the customer within the scope of the > customer's system but ideas are never property. You can't own them and > neither can the customer. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: From ops.lists at gmail.com Fri Feb 13 01:04:25 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 13 Feb 2015 06:34:25 +0530 Subject: gmail spam help In-Reply-To: <54DCCF7B.10306@vocalabs.com> References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> <748ed49076164b8b97b38a0b0dff0b95@exch2013-1.hq.nac.net> <54DCCF7B.10306@vocalabs.com> Message-ID: Please. Gmail isn't ever likely to use long dead hobbyist block lists. On Feb 12, 2015 9:38 PM, "Daniel Taylor" wrote: > Possibly related: http://www.ahbl.org/content/changes-ahbl > > We had to manually remove it from spamassassin for our local installation, > and I am pretty sure that a lot of sites still haven't figured it out so > there's a lot of false positives being generated all over the place to > throw off even filters that don't use it directly. > > On 02/12/2015 09:54 AM, Alex Rubenstein wrote: > >> Mainly because I own it, and the people who use it. The server has been >> around 10+ years and has tight oversight. SPF is proper. This is a recent >> issue. >> >> >> >> >> >> >> From: Scott Helms [mailto:khelms at zcorum.com] >> Sent: Thursday, February 12, 2015 10:51 AM >> To: Alex Rubenstein >> Cc: Josh Luthman; NANOG list >> Subject: Re: gmail spam help >> >> I'd be interested to know how you can be so adamant about the lack of >> spam from this specific server. A great percentage of the spam hitting >> servers I have visibility into comes from very similar kinds of set ups >> because they tend to have little or no over sight in place. >> >> Also, lots of commercial email gets flagged as spam by users, even when >> they opted in for the email. If enough people flagged email from this >> server as spam it will cause Google to consider other email from the same >> small server as likely to be spam as well. Small systems, especially new >> ones, tend to unintentionally look like spam sources by not having proper >> reverse records, making sure you have SPF set up for the domain, etc. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Thu, Feb 12, 2015 at 10:41 AM, Alex Rubenstein > > wrote: >> I should have been clearer. >> >> I have been getting complaints from my sales folks that when they send >> emails to people who use gmail (either a gmail account or google apps) that >> they recipient is reporting that the email is ending up in the Spam folder. >> So, I tested this myself, sending an email from alex at corp.nac.net> alex at corp.nac.net>> >> to rubenstein45 at gmail.com> rubenstein45 at gmail.com> >> >> [cid:image001.png at 01D046AD.3B2FA890] >> >> This is curious to me, since @corp.nac.net is a >> small exchange implementation with only about 50 users behind it, and there >> is no question that there is no spamming going on from here. >> >> So, it’s not a question of adding a filter or not using gmail; it is not >> me who is using gmail in this problem. >> >> >> >> From: Josh Luthman [mailto:josh at imaginenetworksllc.com> josh at imaginenetworksllc.com>] >> Sent: Thursday, February 12, 2015 9:32 AM >> To: Alex Rubenstein >> Cc: NANOG list >> Subject: Re: gmail spam help >> >> >> Create a filter. >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> On Feb 12, 2015 8:11 AM, "Alex Rubenstein" > @corp.nac.net>>> >> wrote: >> Is there anyone on-list that can help me with a world -> gmail email >> issue, where email is being considering spam by gmail erroneously? >> >> Thanks. >> >> > > -- > Daniel Taylor VP Operations Vocal Laboratories, Inc. > dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 > > From richard at pedantictheory.com Fri Feb 13 01:08:25 2015 From: richard at pedantictheory.com (Richard Porter) Date: Thu, 12 Feb 2015 18:08:25 -0700 Subject: Intellectual Property in Network Design In-Reply-To: <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> Message-ID: <35067942-5BAB-4D34-9B6E-C80A1B02CA0C@pedantictheory.com> > On Feb 12, 2015, at 5:43 PM, Ahad Aboss wrote: > > Hi Skeeve, > > In a sense, you are an artist as network architecture is an art in itself. > It involves interaction with time, processes, people and things or an > intersection between all. And to that, artwork would fall under copyright *Sarcasm*? +1 on art form! More like an abstract martial art really. PacketFu! > > As an architect, you analyze customer needs and design a solution using > your creative ideas to address their business driven needs today. In some > ways, this is easier because creating a If you are a consultant wouldn’t that fall under work for hire? If you are an employee? Check the contract, I am betting there is a clause for IP ownership! > business centric network provides you some parameters to design within. > You might mix and match technologies that will suite one business better > than the other but it's your creative ideas. It's not secrets of their > trade that you replicate or takeaway. You are master of the trade and you > design a solution that works best for them. > > While some design principles for application service provider, enterprise, > carrier or ISP have similarities, no two network is the same. > > If you don't claim IP on the design or publish company names you've done > the designs for, under what jurisdiction can they claim what you designed > is their IP? What if their requirement changes in 6 months from now? > > If a architect designs a road system in a particular way, does it mean > he/she can't design another road again because of IP issue? > > I would tend to disagree. +1 > > It may not answer your questions but I hope it provides some content to > support your case :) > > Regards, > Ahad > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Owen DeLong > Sent: Friday, 13 February 2015 6:46 AM > To: William Herrin > Cc: nanog at nanog.org > Subject: Re: Intellectual Property in Network Design > > The extent to which this is technically feasible and how one must go about > it actually varies greatly from jurisdiction to jurisdiction. > > Something well worth considering given the number of jurisdictions already > mentioned in the current discussion. > > There are a number of possible concerns that the customer in question may > be attempting to solve with their request. The first step is to identify > which concern(s) they want to address. > > 1. Do they want to make sure that they have sufficient rights > in > the design that they can replicate/modify/otherwise use it > without further compensating you? > > 2. Do they want to make sure that you surrender your rights > in > the design so that you are not able to provide an > identical > solution to another customer in the future and/or that you > do > not use their design as an example or case study for your > marketing purposes? > > 3. Do they not really have a concern, but someone told them > that it was important to ask this question? > > 4. Do they want to make sure this treated as a "work for > hire" > with all the legal implications that caries? > > There are probably others that I am not thinking of at the moment. > > Owen > >> On Feb 12, 2015, at 08:18 , William Herrin wrote: >> >> On Thu, Feb 12, 2015 at 7:36 AM, Skeeve Stevens >> wrote: >>> Actually Bill... I have two (conflicting) perspectives as I said.... >>> but to >>> clarify: >>> >>> 1) A customer asked 'Can you make sure we have the IP for the network >>> design' which I was wondering if it is even technically possible.... >> >> Hi Skeeve, >> >> IANAL but I play one when I can get away with it. >> >> This is usually covered as, "Contractor agrees to provide Customer >> with all documents, diagrams, software or other materials produced in >> the course of the contract. Contractor shall upon request assign all >> ownership of such materials to Customer. Contractor shall retain no >> copies of said material following termination of the contract." >> >> So yes, it's technically feasible. >> >> >>> 2) If I design some amazing solutions... am I able to claim IP. >> >> If it's copyrightable (a "solution" may be), then as a contractor (not >> an employee) the copyright vests in you. If the contract states that >> you agree to transfer it to the customer then you breach the contract >> if you don't. >> >> If the contract says the copyrights are theirs then at least that part >> of the contract is probably void. Barring W2 employment copyrights >> nearly always vest in the individual who first put them in to a >> tangible form. There are explicit and narrow exceptions in the law. >> Preface of a book. That sort of thing. It's unlikely you'll run afoul >> of any of them. >> >> Lawyers get this wrong shockingly often. IP doesn't vest in the >> customer and can't be transferred until it exists. The creator is a W2 >> employee. The contractor agrees to transfer it following creation. >> Just about everything else is void. >> >> If the contract doesn't say one way or another then the lawyer who >> wrote it was asleep at the wheel. >> >> However... the techniques used to produce the solution usually >> classify as ideas. You may be bound under non-disclosure terms to not >> share ideas produced for the customer within the scope of the >> customer's system but ideas are never property. You can't own them and >> neither can the customer. >> >> Regards, >> Bill Herrin >> >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Owner, Dirtside Systems ......... Web: From dtaylor at vocalabs.com Fri Feb 13 02:09:41 2015 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Thu, 12 Feb 2015 20:09:41 -0600 Subject: gmail spam help In-Reply-To: References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> <748ed49076164b8b97b38a0b0dff0b95@exch2013-1.hq.nac.net> <54DCCF7B.10306@vocalabs.com> Message-ID: <54DD5CE5.7020809@vocalabs.com> Of course not, and I didn't mean to imply that they were. I was surprised to see it still present *anywhere* (this was in a major Linux distribution, and may still be), and that hidden presence may be polluting data streams used by even the most responsible vendors unless they are running entirely self-contained. On 02/12/2015 07:04 PM, Suresh Ramasubramanian wrote: > > Please. Gmail isn't ever likely to use long dead hobbyist block lists. > > On Feb 12, 2015 9:38 PM, "Daniel Taylor" > wrote: > > Possibly related: http://www.ahbl.org/content/changes-ahbl > > We had to manually remove it from spamassassin for our local > installation, and I am pretty sure that a lot of sites still > haven't figured it out so there's a lot of false positives being > generated all over the place to throw off even filters that don't > use it directly. > > On 02/12/2015 09:54 AM, Alex Rubenstein wrote: > > Mainly because I own it, and the people who use it. The server > has been around 10+ years and has tight oversight. SPF is > proper. This is a recent issue. > > > > > > > From: Scott Helms [mailto:khelms at zcorum.com > ] > Sent: Thursday, February 12, 2015 10:51 AM > To: Alex Rubenstein > Cc: Josh Luthman; NANOG list > Subject: Re: gmail spam help > > I'd be interested to know how you can be so adamant about the > lack of spam from this specific server. A great percentage of > the spam hitting servers I have visibility into comes from > very similar kinds of set ups because they tend to have little > or no over sight in place. > > Also, lots of commercial email gets flagged as spam by users, > even when they opted in for the email. If enough people > flagged email from this server as spam it will cause Google to > consider other email from the same small server as likely to > be spam as well. Small systems, especially new ones, tend to > unintentionally look like spam sources by not having proper > reverse records, making sure you have SPF set up for the > domain, etc. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Thu, Feb 12, 2015 at 10:41 AM, Alex Rubenstein > >> wrote: > I should have been clearer. > > I have been getting complaints from my sales folks that when > they send emails to people who use gmail (either a gmail > account or google apps) that they recipient is reporting that > the email is ending up in the Spam folder. So, I tested this > myself, sending an email from alex at corp.nac.net > > >> to rubenstein45 at gmail.com > > >> > > [cid:image001.png at 01D046AD.3B2FA890] > > This is curious to me, since @corp.nac.net > is a small exchange > implementation with only about 50 users behind it, and there > is no question that there is no spamming going on from here. > > So, it’s not a question of adding a filter or not using gmail; > it is not me who is using gmail in this problem. > > > > From: Josh Luthman [mailto:josh at imaginenetworksllc.com > >] > Sent: Thursday, February 12, 2015 9:32 AM > To: Alex Rubenstein > Cc: NANOG list > Subject: Re: gmail spam help > > > Create a filter. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Feb 12, 2015 8:11 AM, "Alex Rubenstein" > >>> wrote: > Is there anyone on-list that can help me with a world -> gmail > email issue, where email is being considering spam by gmail > erroneously? > > Thanks. > > > > -- > Daniel Taylor VP Operations Vocal > Laboratories, Inc. > dtaylor at vocalabs.com > http://www.vocalabs.com/ (612)235-5711 > From ops.lists at gmail.com Fri Feb 13 02:09:36 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 13 Feb 2015 07:39:36 +0530 Subject: gmail spam help In-Reply-To: <54DD5CE5.7020809@vocalabs.com> References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> <748ed49076164b8b97b38a0b0dff0b95@exch2013-1.hq.nac.net> <54DCCF7B.10306@vocalabs.com> <54DD5CE5.7020809@vocalabs.com> Message-ID: Which distro is it that has dnsbl filtering on by default, and also defaulting to shady no name blocklists? I have yet to see a case where turning this sort of thing on first and kicking self later wasn't because of a clueless sysadmin. On Feb 13, 2015 7:36 AM, "Daniel Taylor" wrote: > Of course not, and I didn't mean to imply that they were. > > I was surprised to see it still present *anywhere* (this was in a major > Linux distribution, and may still be), and that hidden presence may be > polluting data streams used by even the most responsible vendors unless > they are running entirely self-contained. > > On 02/12/2015 07:04 PM, Suresh Ramasubramanian wrote: > >> >> Please. Gmail isn't ever likely to use long dead hobbyist block lists. >> >> On Feb 12, 2015 9:38 PM, "Daniel Taylor" > dtaylor at vocalabs.com>> wrote: >> >> Possibly related: http://www.ahbl.org/content/changes-ahbl >> >> We had to manually remove it from spamassassin for our local >> installation, and I am pretty sure that a lot of sites still >> haven't figured it out so there's a lot of false positives being >> generated all over the place to throw off even filters that don't >> use it directly. >> >> On 02/12/2015 09:54 AM, Alex Rubenstein wrote: >> >> Mainly because I own it, and the people who use it. The server >> has been around 10+ years and has tight oversight. SPF is >> proper. This is a recent issue. >> >> >> >> >> >> >> From: Scott Helms [mailto:khelms at zcorum.com >> ] >> Sent: Thursday, February 12, 2015 10:51 AM >> To: Alex Rubenstein >> Cc: Josh Luthman; NANOG list >> Subject: Re: gmail spam help >> >> I'd be interested to know how you can be so adamant about the >> lack of spam from this specific server. A great percentage of >> the spam hitting servers I have visibility into comes from >> very similar kinds of set ups because they tend to have little >> or no over sight in place. >> >> Also, lots of commercial email gets flagged as spam by users, >> even when they opted in for the email. If enough people >> flagged email from this server as spam it will cause Google to >> consider other email from the same small server as likely to >> be spam as well. Small systems, especially new ones, tend to >> unintentionally look like spam sources by not having proper >> reverse records, making sure you have SPF set up for the >> domain, etc. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Thu, Feb 12, 2015 at 10:41 AM, Alex Rubenstein >> > > >> wrote: >> I should have been clearer. >> >> I have been getting complaints from my sales folks that when >> they send emails to people who use gmail (either a gmail >> account or google apps) that they recipient is reporting that >> the email is ending up in the Spam folder. So, I tested this >> myself, sending an email from alex at corp.nac.net >> > >> > >> to rubenstein45 at gmail.com >> > >> > >> >> >> [cid:image001.png at 01D046AD.3B2FA890] >> >> This is curious to me, since @corp.nac.net >> is a small exchange >> implementation with only about 50 users behind it, and there >> is no question that there is no spamming going on from here. >> >> So, it’s not a question of adding a filter or not using gmail; >> it is not me who is using gmail in this problem. >> >> >> >> From: Josh Luthman [mailto:josh at imaginenetworksllc.com >> > imaginenetworksllc.com >> >] >> Sent: Thursday, February 12, 2015 9:32 AM >> To: Alex Rubenstein >> Cc: NANOG list >> Subject: Re: gmail spam help >> >> >> Create a filter. >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> On Feb 12, 2015 8:11 AM, "Alex Rubenstein" > > >> > >>> wrote: >> Is there anyone on-list that can help me with a world -> gmail >> email issue, where email is being considering spam by gmail >> erroneously? >> >> Thanks. >> >> >> >> -- Daniel Taylor VP Operations Vocal >> Laboratories, Inc. >> dtaylor at vocalabs.com >> http://www.vocalabs.com/ (612)235-5711 >> >> > From wwaites at tardis.ed.ac.uk Fri Feb 13 09:55:25 2015 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Fri, 13 Feb 2015 09:55:25 +0000 (GMT) Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> Message-ID: <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> On Fri, 13 Feb 2015 11:43:14 +1100, Ahad Aboss said: > In a sense, you are an artist as network architecture > is an art in itself. It involves interaction with time, > processes, people and things or an intersection between all. This Friday's off-topic post for NANOG: Doing art is creative practice directed to uncover something new and not pre-conceived. Successful acts of art produce something that not only wasn't there before but that nobody thought could be there. The art is the change in thinking that results. Whatever else is left over is residue. An engineer or architect in the usual setting, no matter how skilled, is not doing art because the whole activity is pre-conceived. Even a clean and elegant design is not usually intended to show beautiful connections between ideas the same way poetry or mathematics might. Hiring an engineer for this purpose almost never happens in industry. Rather the purpose is to make a thing that does what it is intended to do. It is craft, or second-order residue. Useful, possibly difficult, but not art. Some people want to claim ownership of a recipe for predictably creating residue of a certain kind. An artist knows that this is not good for doing art because nothing new can come from it. If they are committed to their practice, they will not seek to prevent others from using an old recipe. Why would they? They have already moved on. Some older thoughts on the topic: http://archive.groovy.net/syntac/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From dtaylor at vocalabs.com Fri Feb 13 14:57:54 2015 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Fri, 13 Feb 2015 08:57:54 -0600 Subject: gmail spam help In-Reply-To: References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> <748ed49076164b8b97b38a0b0dff0b95@exch2013-1.hq.nac.net> <54DCCF7B.10306@vocalabs.com> <54DD5CE5.7020809@vocalabs.com> Message-ID: <54DE10F2.6010609@vocalabs.com> More than one, but I found it here: https://bugs.launchpad.net/ubuntu/+source/spamassassin/+bug/1412830 They did patch it after it finally became a problem, I don't know about any other distributions. On 02/12/2015 08:09 PM, Suresh Ramasubramanian wrote: > > Which distro is it that has dnsbl filtering on by default, and also > defaulting to shady no name blocklists? > > I have yet to see a case where turning this sort of thing on first and > kicking self later wasn't because of a clueless sysadmin. > > On Feb 13, 2015 7:36 AM, "Daniel Taylor" > wrote: > > Of course not, and I didn't mean to imply that they were. > > I was surprised to see it still present *anywhere* (this was in a > major Linux distribution, and may still be), and that hidden > presence may be polluting data streams used by even the most > responsible vendors unless they are running entirely self-contained. > > On 02/12/2015 07:04 PM, Suresh Ramasubramanian wrote: > > > Please. Gmail isn't ever likely to use long dead hobbyist > block lists. > > On Feb 12, 2015 9:38 PM, "Daniel Taylor" >> wrote: > > Possibly related: http://www.ahbl.org/content/changes-ahbl > > We had to manually remove it from spamassassin for our local > installation, and I am pretty sure that a lot of sites still > haven't figured it out so there's a lot of false positives > being > generated all over the place to throw off even filters > that don't > use it directly. > > On 02/12/2015 09:54 AM, Alex Rubenstein wrote: > > Mainly because I own it, and the people who use it. > The server > has been around 10+ years and has tight oversight. SPF is > proper. This is a recent issue. > > > > > > > From: Scott Helms [mailto:khelms at zcorum.com > > >] > Sent: Thursday, February 12, 2015 10:51 AM > To: Alex Rubenstein > Cc: Josh Luthman; NANOG list > Subject: Re: gmail spam help > > I'd be interested to know how you can be so adamant > about the > lack of spam from this specific server. A great > percentage of > the spam hitting servers I have visibility into comes from > very similar kinds of set ups because they tend to > have little > or no over sight in place. > > Also, lots of commercial email gets flagged as spam by > users, > even when they opted in for the email. If enough people > flagged email from this server as spam it will cause > Google to > consider other email from the same small server as > likely to > be spam as well. Small systems, especially new ones, > tend to > unintentionally look like spam sources by not having > proper > reverse records, making sure you have SPF set up for the > domain, etc. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Thu, Feb 12, 2015 at 10:41 AM, Alex Rubenstein > > > > >>> wrote: > I should have been clearer. > > I have been getting complaints from my sales folks > that when > they send emails to people who use gmail (either a gmail > account or google apps) that they recipient is > reporting that > the email is ending up in the Spam folder. So, I > tested this > myself, sending an email from alex at corp.nac.net > > > > >> > > > >>> to rubenstein45 at gmail.com > > > > >> > > > >>> > > [cid:image001.png at 01D046AD.3B2FA890] > > This is curious to me, since @corp.nac.net > > is a small > exchange > implementation with only about 50 users behind it, and > there > is no question that there is no spamming going on from > here. > > So, it’s not a question of adding a filter or not > using gmail; > it is not me who is using gmail in this problem. > > > > From: Josh Luthman [mailto:josh at imaginenetworksllc.com > > > > >>] > Sent: Thursday, February 12, 2015 9:32 AM > To: Alex Rubenstein > Cc: NANOG list > Subject: Re: gmail spam help > > > Create a filter. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Feb 12, 2015 8:11 AM, "Alex Rubenstein" > > > > >> > > > >>>> wrote: > Is there anyone on-list that can help me with a world > -> gmail > email issue, where email is being considering spam by > gmail > erroneously? > > Thanks. > > > > -- Daniel Taylor VP Operations Vocal > Laboratories, Inc. > dtaylor at vocalabs.com > > > http://www.vocalabs.com/ (612)235-5711 > > -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From bill at herrin.us Fri Feb 13 15:28:25 2015 From: bill at herrin.us (William Herrin) Date: Fri, 13 Feb 2015 10:28:25 -0500 Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> Message-ID: On Fri, Feb 13, 2015 at 8:54 AM, Skeeve Stevens < skeeve at eintellegonetworks.com> wrote: > On Fri, Feb 13, 2015 at 8:55 PM, William Waites wrote: >> An engineer or architect in the usual setting, no matter how skilled, >> is not doing art because the whole activity is pre-conceived. Even a > > Excellent perspective... Howdy, I have to disagree with you there. This particular ship sailed four decades ago when CONTU found computer software to be copyrightable and the subsequent legislation and litigation agreed. If a router configuration turns out not to be art, it isn't because the engineer had to follow practical rules to create it. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From pfunix at gmail.com Fri Feb 13 16:02:40 2015 From: pfunix at gmail.com (Beavis) Date: Fri, 13 Feb 2015 10:02:40 -0600 Subject: Dark Fiber in Latin America Message-ID: All, I'm looking for some general information of a dark fiber provider in latin america countries namely Nicaragua and Costa Rica. Any info is greatly appreciated. Please contact me off list. thanks, -Beavis -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/ From alejandroacostaalamo at gmail.com Fri Feb 13 16:15:06 2015 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Fri, 13 Feb 2015 11:45:06 -0430 Subject: Dark Fiber in Latin America In-Reply-To: References: Message-ID: <54DE230A.5090807@gmail.com> Hi Beavis, Just in case, there is a Lacnog mailing list.., the URL: https://mail.lacnic.net/mailman/listinfo/lacnog In case you don't get a response here you might want to try thee. Alejandro, El 2/13/2015 a las 11:32 AM, Beavis escribió: > All, > > I'm looking for some general information of a dark fiber provider in latin > america countries namely Nicaragua and Costa Rica. Any info is greatly > appreciated. > > Please contact me off list. > > > thanks, > -Beavis > > From Valdis.Kletnieks at vt.edu Fri Feb 13 17:25:25 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 13 Feb 2015 12:25:25 -0500 Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: Your message of "Fri, 13 Feb 2015 10:28:25 -0500." References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> Message-ID: <4841.1423848325@turing-police.cc.vt.edu> On Fri, 13 Feb 2015 10:28:25 -0500, William Herrin said: > I have to disagree with you there. This particular ship sailed four decades > ago when CONTU found computer software to be copyrightable and the > subsequent legislation and litigation agreed. The output of "craft" is copyrightable even if it doesn't count as "art", as long as it meets the requirement of 17 USC 102(a)(1) - "literary works". The issue with software wasn't if it was "art", but if it was a literary work (they struggled for a while with the concept of machine-readable versus human readable). "Furthermore, the House Report discussing the Act states: The term "literary works" does not connote any criterion of literary merit or qualitative value: it includes catalogs, directories, and similar factual, reference, or instructional works and compilations of data. It also includes computer data bases, and computer programs to the extent that they incorporate authorship in the programmer's expression of original ideas, as distinguished from the ideas themselves. {FN8: H.R. Rep. No. 94-1476 at 54} http://digital-law-online.info/lpdi1.0/treatise17.html If catalogs and directories are covered, config files are... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From andy at newslink.com Fri Feb 13 17:40:06 2015 From: andy at newslink.com (Andy Ringsmuth) Date: Fri, 13 Feb 2015 11:40:06 -0600 Subject: Intrusion Detection recommendations Message-ID: NANOG'ers, I've been tasked by our company president to learn about, investigate and recommend an intrusion detection system for our company. We're a smaller outfit, less than 100 employees, entirely Apple-based. Macs, iPhones, some Mac Mini servers, etc., and a fiber connection to the world. We are protected by a FreeBSD firewall setup, and we stay current on updates/patches from Apple and FreeBSD, but that's as far as my expertise goes. Initially, what do people recommend for: 1. Crash course in intrusion detection as a whole 2. Suggestions or recommendations for intrusion detection hardware or software 3. Other things I'm likely overlooking Thank you all in advance for your wisdom. ---- 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 mel at beckman.org Fri Feb 13 17:45:10 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 13 Feb 2015 17:45:10 +0000 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: Unless you need regulatory-grade IDS, your best bet is a Unified Threat Management (UTM) appliance, essentially any modern enterprise grade firewall such as a Cisco ASA, Fortigate, SonicWall, etc. These all have built-in IDS/IPS options for a fee. -mel On Feb 13, 2015, at 9:40 AM, Andy Ringsmuth wrote: > NANOG'ers, > > I've been tasked by our company president to learn about, investigate and recommend an intrusion detection system for our company. > > We're a smaller outfit, less than 100 employees, entirely Apple-based. Macs, iPhones, some Mac Mini servers, etc., and a fiber connection to the world. We are protected by a FreeBSD firewall setup, and we stay current on updates/patches from Apple and FreeBSD, but that's as far as my expertise goes. > > Initially, what do people recommend for: > > 1. Crash course in intrusion detection as a whole > 2. Suggestions or recommendations for intrusion detection hardware or software > 3. Other things I'm likely overlooking > > Thank you all in advance for your wisdom. > > > ---- > 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 joquendo at e-fensive.net Fri Feb 13 17:25:21 2015 From: joquendo at e-fensive.net (J. Oquendo) Date: Fri, 13 Feb 2015 11:25:21 -0600 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: <20150213172521.GA240@e-fensive.net> On Fri, 13 Feb 2015, Andy Ringsmuth wrote: > NANOG'ers, > > I've been tasked by our company president to learn about, investigate and recommend an intrusion detection system for our company. > > We're a smaller outfit, less than 100 employees, entirely Apple-based. Macs, iPhones, some Mac Mini servers, etc., and a fiber connection to the world. We are protected by a FreeBSD firewall setup, and we stay current on updates/patches from Apple and FreeBSD, but that's as far as my expertise goes. > > Initially, what do people recommend for: > > 1. Crash course in intrusion detection as a whole > 2. Suggestions or recommendations for intrusion detection hardware or software > 3. Other things I'm likely overlooking > > Thank you all in advance for your wisdom. I'd have a look at Alien Vault if you don't want to fork out heavy money and have a geek enough staff who doesn't mind butchering it up. It can be plug and play to an extent yet at the same time, if not configured properly it becomes useless. On the other hand, if you don't want to waste precious time in the event of say incident response to an actual event, then I would opt for QRadar. IDS/IPS is a mere buzzword. Detection comes via way of knowledge: "Who knows/has seen, that N traffic is malicious" often based on signatures. Then of course you get all the nifty buzzwords: "but we use heuristic doohickey reverse nacho cheese technology!" Prevention is a paradox. If it did prevent then why did you get notified via a tweet that you were compromised before you even knew you were. IDS works like this (in theory): Look at all logs, and all traffic patterns. Compare this data (often) to a config file of known knowns, if it matches what we have seen then it MUST be an attack. IPS works like this: Sell someone an IDS appliance or software and tell them it's IPS. It won't stop a huge portion of attacks since it is well... IDS but boy does it have a cooler name. ITS (Intrusion Tolerance) works like this: Ok, so we won't stop them, we can't prevent them, but boy oh boy can we tolerate them! All work off of a broken premise of "known knowns" and not one vendor will ever come clean on this. I have had the opportunity (or misfortune take your pick) to have analyzed quite a bit of malware, intrusions, and so forth. I have seen how rapidly some of the attacks change, so I know firsthand why IDS, IPS, and others fail. Now let me be fair... IDS/IPS are good as a HSSS (new buzzword) Hind Sight Security System, but will only prevent, and detect what is known. Your best goal is to perform a combination security and network analysis PRIOR to implementing any system. In doing so, you create logic suitable to your environment. For example, you have a DB that is supposed to ONLY communicate internally, a better approach would be to go on to that machine, and use the local machine's firewall rule to create a rule that says: ONLY CONNECTIONS FROM HERE TO THERE ARE ALLOWED ALL OTHERS GET BLOCKED, then alert when something strays. Most of these systems lack because of the design prior to, and after their implementations. Organizations haven't taken the time to map data, processes, and create even a simple baseline to work with. This leads to these types of systems (IPS, IDS, SIEM, ITS, blah blah blah) generating all sorts of false positives. These false positives often overwhelm the users tasked with the administration of the systems. Thousands of alerts which often go unchecked until it is too late. thee end. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463 https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463 From joquendo at e-fensive.net Fri Feb 13 17:29:25 2015 From: joquendo at e-fensive.net (J. Oquendo) Date: Fri, 13 Feb 2015 11:29:25 -0600 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: <20150213172925.GB240@e-fensive.net> On Fri, 13 Feb 2015, Mel Beckman wrote: > Unless you need regulatory-grade IDS, your best bet is a Unified Threat Management (UTM) appliance, essentially any modern enterprise grade firewall such as a Cisco ASA, Fortigate, SonicWall, etc. These all have built-in IDS/IPS options for a fee. > > -mel > With all due respect, is regulatory-grade IDS the same as say "military-grade" encryption? -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463 https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463 From richo at psych0tik.net Fri Feb 13 18:03:31 2015 From: richo at psych0tik.net (Richo Healey) Date: Fri, 13 Feb 2015 10:03:31 -0800 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: <20150213180331.GA66024@xenia.local> On 13/02/15 17:45 +0000, Mel Beckman wrote: >Unless you need regulatory-grade IDS, your best bet is a Unified Threat Management (UTM) appliance, essentially any modern enterprise grade firewall such as a Cisco ASA, Fortigate, SonicWall, etc. These all have built-in IDS/IPS options for a fee. > > -mel > Flip over these, or ideally watch the talk before deploying an ASA (or some other black-box security appliance that tries to be All Things to All People) https://ruxcon.org.au/assets/2014/slides/Breaking%20Bricks%20Ruxcon%202014.pdf -- richo From cscora at apnic.net Fri Feb 13 18:11:17 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 14 Feb 2015 04:11:17 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201502131811.t1DIBHlt027682@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 14 Feb, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 532541 Prefixes after maximum aggregation (per Origin AS): 203597 Deaggregation factor: 2.62 Unique aggregates announced (without unneeded subnets): 259474 Total ASes present in the Internet Routing Table: 49402 Prefixes per ASN: 10.78 Origin-only ASes present in the Internet Routing Table: 36461 Origin ASes announcing only one prefix: 16309 Transit ASes present in the Internet Routing Table: 6259 Transit-only ASes present in the Internet Routing Table: 169 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 108 Max AS path prepend of ASN ( 60548) 101 Prefixes from unregistered ASNs in the Routing Table: 1744 Unregistered ASNs in the Routing Table: 432 Number of 32-bit ASNs allocated by the RIRs: 8597 Number of 32-bit ASNs visible in the Routing Table: 6682 Prefixes from 32-bit ASNs in the Routing Table: 24277 Number of bogon 32-bit ASNs visible in the Routing Table: 5 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 399 Number of addresses announced to Internet: 2731541796 Equivalent to 162 /8s, 208 /16s and 5 /24s Percentage of available address space announced: 73.8 Percentage of allocated address space announced: 73.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.2 Total number of prefixes smaller than registry allocations: 180324 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 131568 Total APNIC prefixes after maximum aggregation: 38312 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 136903 Unique aggregates announced from the APNIC address blocks: 55612 APNIC Region origin ASes present in the Internet Routing Table: 5026 APNIC Prefixes per ASN: 27.24 APNIC Region origin ASes announcing only one prefix: 1228 APNIC Region transit ASes present in the Internet Routing Table: 874 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 107 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1307 Number of APNIC addresses announced to Internet: 747848064 Equivalent to 44 /8s, 147 /16s and 65 /24s Percentage of available APNIC address space announced: 87.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 176091 Total ARIN prefixes after maximum aggregation: 86886 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 178136 Unique aggregates announced from the ARIN address blocks: 83478 ARIN Region origin ASes present in the Internet Routing Table: 16488 ARIN Prefixes per ASN: 10.80 ARIN Region origin ASes announcing only one prefix: 6086 ARIN Region transit ASes present in the Internet Routing Table: 1717 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 21 Number of ARIN region 32-bit ASNs visible in the Routing Table: 344 Number of ARIN addresses announced to Internet: 1060672032 Equivalent to 63 /8s, 56 /16s and 146 /24s Percentage of available ARIN address space announced: 56.1 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: 129257 Total RIPE prefixes after maximum aggregation: 64399 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 135576 Unique aggregates announced from the RIPE address blocks: 83258 RIPE Region origin ASes present in the Internet Routing Table: 17867 RIPE Prefixes per ASN: 7.59 RIPE Region origin ASes announcing only one prefix: 8152 RIPE Region transit ASes present in the Internet Routing Table: 2956 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 108 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3435 Number of RIPE addresses announced to Internet: 693150596 Equivalent to 41 /8s, 80 /16s and 163 /24s Percentage of available RIPE address space announced: 100.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 58626 Total LACNIC prefixes after maximum aggregation: 10984 LACNIC Deaggregation factor: 5.34 Prefixes being announced from the LACNIC address blocks: 68030 Unique aggregates announced from the LACNIC address blocks: 31719 LACNIC Region origin ASes present in the Internet Routing Table: 2405 LACNIC Prefixes per ASN: 28.29 LACNIC Region origin ASes announcing only one prefix: 637 LACNIC Region transit ASes present in the Internet Routing Table: 484 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1507 Number of LACNIC addresses announced to Internet: 167711744 Equivalent to 9 /8s, 255 /16s and 20 /24s Percentage of available LACNIC address space announced: 100.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12523 Total AfriNIC prefixes after maximum aggregation: 2972 AfriNIC Deaggregation factor: 4.21 Prefixes being announced from the AfriNIC address blocks: 13497 Unique aggregates announced from the AfriNIC address blocks: 5048 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 18.36 AfriNIC Region origin ASes announcing only one prefix: 206 AfriNIC Region transit ASes present in the Internet Routing Table: 155 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 89 Number of AfriNIC addresses announced to Internet: 61703424 Equivalent to 3 /8s, 173 /16s and 133 /24s Percentage of available AfriNIC address space announced: 61.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 2872 11553 911 Korea Telecom 17974 2824 904 77 PT Telekomunikasi Indonesia 7545 2565 336 128 TPG Telecom Limited 4755 1972 421 203 TATA Communications formerly 4538 1758 4190 71 China Education and Research 9829 1686 1325 36 National Internet Backbone 9808 1536 8639 18 Guangdong Mobile Communicatio 4808 1451 2218 436 CNCGROUP IP network China169 9583 1395 116 574 Sify Limited 9498 1299 336 97 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 2982 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 3356 2567 10683 475 Level 3 Communications, Inc. 18566 2042 379 183 MegaPath Corporation 20115 1848 1828 446 Charter Communications 4323 1621 1037 406 tw telecom holdings, inc. 6983 1621 850 242 EarthLink, Inc. 30036 1551 322 481 Mediacom Communications Corp 701 1391 11268 678 MCI Communications Services, 22561 1333 411 240 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1965 300 353 TELLCOM ILETISIM HIZMETLERI A 20940 1594 622 1184 Akamai International B.V. 8402 1357 544 15 OJSC "Vimpelcom" 6849 1198 356 25 JSC "Ukrtelecom" 31148 1045 45 21 Freenet Ltd. 13188 1043 97 61 TOV "Bank-Inform" 8551 903 373 48 Bezeq International-Ltd 12479 860 793 86 France Telecom Espana SA 9198 847 349 25 JSC Kazakhtelecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3098 502 222 Telmex Colombia S.A. 28573 2330 2141 111 NET Servi�os de Comunica��o S 7303 1780 1182 231 Telecom Argentina S.A. 6147 1586 374 30 Telefonica del Peru S.A.A. 8151 1547 3107 453 Uninet S.A. de C.V. 6503 1195 421 58 Axtel, S.A.B. de C.V. 7738 1001 1882 42 Telemar Norte Leste S.A. 3816 921 396 148 COLOMBIA TELECOMUNICACIONES S 26615 921 2325 35 Tim Celular S.A. 18881 863 1037 23 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1546 958 13 TE-AS 24863 958 284 26 Link Egypt (Link.NET) 36903 479 241 90 Office National des Postes et 36992 373 845 30 ETISALAT MISR 37492 330 160 66 Orange Tunisie 24835 297 144 9 Vodafone Data 3741 250 921 209 Internet Solutions 29571 229 21 12 Cote d'Ivoire Telecom 36947 197 807 13 Telecom Algeria 15706 176 32 6 Sudatel (Sudan Telecom Co. Lt Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3098 502 222 Telmex Colombia S.A. 22773 2982 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 4766 2872 11553 911 Korea Telecom 17974 2824 904 77 PT Telekomunikasi Indonesia 3356 2567 10683 475 Level 3 Communications, Inc. 7545 2565 336 128 TPG Telecom Limited 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2330 2141 111 NET Servi�os de Comunica��o S 18566 2042 379 183 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 2982 2841 Cox Communications Inc. 6389 2891 2840 BellSouth.net Inc. 17974 2824 2747 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2565 2437 TPG Telecom Limited 28573 2330 2219 NET Servi�os de Comunica��o S 3356 2567 2092 Level 3 Communications, Inc. 4766 2872 1961 Korea Telecom 18566 2042 1859 MegaPath Corporation 4755 1972 1769 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 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.92.160.0/24 14013 EPSON America (Factory Automa 23.92.161.0/24 14013 EPSON America (Factory Automa 23.226.112.0/20 62788 Bitfinite LLC 23.252.224.0/20 62502 >>UNKNOWN<< 23.252.224.0/21 62502 >>UNKNOWN<< 23.252.232.0/21 62502 >>UNKNOWN<< 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:34 /11:92 /12:265 /13:504 /14:998 /15:1722 /16:12967 /17:7140 /18:12114 /19:24896 /20:35717 /21:38485 /22:57601 /23:50331 /24:286619 /25:1187 /26:1099 /27:690 /28:17 /29:14 /30:8 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2199 2982 Cox Communications Inc. 18566 1997 2042 MegaPath Corporation 6389 1671 2891 BellSouth.net Inc. 30036 1396 1551 Mediacom Communications Corp 6983 1313 1621 EarthLink, Inc. 34984 1274 1965 TELLCOM ILETISIM HIZMETLERI A 11492 1133 1191 CABLE ONE, INC. 6147 1127 1586 Telefonica del Peru S.A.A. 10620 1101 3098 Telmex Colombia S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1469 2:670 3:1 4:97 5:1726 6:21 8:1412 12:1842 13:4 14:1291 15:16 16:2 17:42 18:21 20:49 23:1137 24:1682 27:1850 31:1430 32:39 33:2 34:5 35:2 36:119 37:1914 38:1006 39:9 40:234 41:3022 42:269 43:1045 44:25 45:191 46:2085 47:34 49:790 50:787 52:12 54:66 55:4 56:8 57:33 58:1200 59:681 60:459 61:1759 62:1299 63:1917 64:4426 65:2260 66:4079 67:2026 68:1041 69:3274 70:965 71:435 72:1968 74:2619 75:314 76:409 77:1457 78:1256 79:777 80:1316 81:1321 82:816 83:678 84:677 85:1328 86:379 87:1078 88:494 89:1755 90:139 91:5925 92:808 93:2179 94:1944 95:2085 96:425 97:339 98:1053 99:47 100:73 101:808 103:6727 104:1229 105:62 106:218 107:884 108:608 109:2024 110:1075 111:1477 112:764 113:1026 114:851 115:1252 116:1320 117:1031 118:1696 119:1421 120:444 121:1049 122:2167 123:1726 124:1488 125:1569 128:628 129:373 130:380 131:1110 132:478 133:167 134:399 135:88 136:311 137:300 138:465 139:173 140:227 141:422 142:629 143:451 144:523 145:111 146:682 147:561 148:1104 149:466 150:560 151:748 152:486 153:248 154:313 155:721 156:402 157:331 158:265 159:988 160:368 161:632 162:1894 163:389 164:655 165:668 166:322 167:703 168:1002 169:150 170:1441 171:223 172:42 173:1591 174:688 175:623 176:1438 177:3730 178:2079 179:865 180:1917 181:1574 182:1692 183:601 184:740 185:2865 186:2709 187:1795 188:2001 189:1547 190:7779 191:845 192:8110 193:5544 194:4055 195:3629 196:1677 197:917 198:5495 199:5522 200:6509 201:2961 202:9552 203:9058 204:4656 205:2736 206:3008 207:2986 208:3956 209:3900 210:3489 211:1833 212:2468 213:2245 214:848 215:69 216:5560 217:1806 218:673 219:464 220:1457 221:790 222:464 223:645 End of report From bill at herrin.us Fri Feb 13 18:36:43 2015 From: bill at herrin.us (William Herrin) Date: Fri, 13 Feb 2015 13:36:43 -0500 Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: <4841.1423848325@turing-police.cc.vt.edu> References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> <4841.1423848325@turing-police.cc.vt.edu> Message-ID: On Fri, Feb 13, 2015 at 12:25 PM, wrote: > The issue with software wasn't if it was "art", but if it was a literary work > (they struggled for a while with the concept of machine-readable versus human > readable). > > If catalogs and directories are covered, config files are... :) Smells like a Friday challenge for who can produce the most "artistic" yet functionally correct Cisco configuration. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From Valdis.Kletnieks at vt.edu Fri Feb 13 19:02:03 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 13 Feb 2015 14:02:03 -0500 Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: Your message of "Fri, 13 Feb 2015 13:36:43 -0500." References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> <4841.1423848325@turing-police.cc.vt.edu> Message-ID: <9547.1423854123@turing-police.cc.vt.edu> On Fri, 13 Feb 2015 13:36:43 -0500, William Herrin said: > On Fri, Feb 13, 2015 at 12:25 PM, wrote: > > If catalogs and directories are covered, config files are... :) > > Smells like a Friday challenge for who can produce the most "artistic" > yet functionally correct Cisco configuration. All too many of them read like either Edgar Allen Poe or HP Lovecraft. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mel at beckman.org Fri Feb 13 20:02:12 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 13 Feb 2015 20:02:12 +0000 Subject: Intrusion Detection recommendations In-Reply-To: <20150213172925.GB240@e-fensive.net> References: , <20150213172925.GB240@e-fensive.net> Message-ID: <5D34E0CB-A7E9-4092-87E6-E71ECBB1B55C@beckman.org> JO, IDS to meet PCI or HIPAA requirements is "regulatory grade". It meets specific notification and logging requirements. SNORT-based systems fall into this category. -mel beckman > On Feb 13, 2015, at 10:00 AM, "J. Oquendo" wrote: > >> On Fri, 13 Feb 2015, Mel Beckman wrote: >> >> Unless you need regulatory-grade IDS, your best bet is a Unified Threat Management (UTM) appliance, essentially any modern enterprise grade firewall such as a Cisco ASA, Fortigate, SonicWall, etc. These all have built-in IDS/IPS options for a fee. >> >> -mel > > With all due respect, is regulatory-grade IDS the same as > say "military-grade" encryption? > > -- > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM > > "Where ignorance is our master, there is no possibility of > real peace" - Dalai Lama > > 0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463 > https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463 From rafael at gav.ufsc.br Fri Feb 13 20:37:33 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 13 Feb 2015 14:37:33 -0600 Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: <4841.1423848325@turing-police.cc.vt.edu> References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> <4841.1423848325@turing-police.cc.vt.edu> Message-ID: Thank you for looking up facts, laws, etc... The rest is merely opinion, and wouldn't necessarily help someone trying to protect their network designs. On Fri, Feb 13, 2015 at 11:25 AM, wrote: > On Fri, 13 Feb 2015 10:28:25 -0500, William Herrin said: > > > I have to disagree with you there. This particular ship sailed four > decades > > ago when CONTU found computer software to be copyrightable and the > > subsequent legislation and litigation agreed. > > The output of "craft" is copyrightable even if it doesn't count as "art", > as long as it meets the requirement of 17 USC 102(a)(1) - "literary works". > > The issue with software wasn't if it was "art", but if it was a literary > work > (they struggled for a while with the concept of machine-readable versus > human > readable). > > "Furthermore, the House Report discussing the Act states: > The term "literary works" does not connote any criterion of literary merit > or > qualitative value: it includes catalogs, directories, and similar factual, > reference, or instructional works and compilations of data. It also > includes > computer data bases, and computer programs to the extent that they > incorporate > authorship in the programmer's expression of original ideas, as > distinguished from the ideas themselves. {FN8: H.R. Rep. No. 94-1476 at 54} > > http://digital-law-online.info/lpdi1.0/treatise17.html > > If catalogs and directories are covered, config files are... :) > > From rafael at gav.ufsc.br Fri Feb 13 20:45:46 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 13 Feb 2015 14:45:46 -0600 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: I am a huge fan of FreeBSD, but for a medium/large business I'd definitely use a fairly well tested security appliance like Cisco's ASA. Depending on the traffic you have on your fiber uplink, you can get a redundant pair of ASAs running for less than $2,000 in the US. I just find it less stressful to use a solution like ASA rather than worrying about patching your kernel every so often and worrying about possible vulns in the ipfw/pf codes. That, and you have to make sure EVERYTHING is taken into account when you create your rules, which requires some intense knowledge on either ipfw, pf or both. I am not an expert in intrusion detection, so with regards to that, I'd just setup a honeypot and monitor activity. You can also regularly run penetration tests on your own network and see how well you are protected. Just make sure the appropriate people know about these tests so you don't get wrongfully reported. Rafael On Fri, Feb 13, 2015 at 11:40 AM, Andy Ringsmuth wrote: > NANOG'ers, > > I've been tasked by our company president to learn about, investigate and > recommend an intrusion detection system for our company. > > We're a smaller outfit, less than 100 employees, entirely Apple-based. > Macs, iPhones, some Mac Mini servers, etc., and a fiber connection to the > world. We are protected by a FreeBSD firewall setup, and we stay current on > updates/patches from Apple and FreeBSD, but that's as far as my expertise > goes. > > Initially, what do people recommend for: > > 1. Crash course in intrusion detection as a whole > 2. Suggestions or recommendations for intrusion detection hardware or > software > 3. Other things I'm likely overlooking > > Thank you all in advance for your wisdom. > > > ---- > 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 smb at cs.columbia.edu Fri Feb 13 20:56:29 2015 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 13 Feb 2015 15:56:29 -0500 Subject: Intellectual Property in Network Design In-Reply-To: References: Message-ID: On 12 Feb 2015, at 3:12, Skeeve Stevens wrote: > Hi all, > > I have two perspectives I am trying to address with regard to network > design and intellectual property. > > 1) The business who does the design - what are their rights? > > 2) The customer who asked for the rights from a consultant > > My personal thoughts are conflicting: > > - You create networks with standard protocols, configurations, etc... > so it > shouldn't be IP > - But you can design things in interesting ways, with experience, > skill, > creativity.. maybe that should be IP? > - But artwork are created with colors, paintbrushes, canvas... but the > result is IP > - A photographer takes a photo - it is IP > - But how are 'how you do your Cisco/Juniper configs' possibly IP? > - If I design a network one way for a customer and they want 'IP', > does > that mean I can't ever design a network like that again? What? > > I've seen a few telcos say that they own the IP related to the network > design of their customers they deploy... which based on the above... > feels > uncomfortable... > > I'm really conflicted on this and wondering if anyone else has come > across > this situation. Perhaps any legal cases/precedent (note, I am not > looking > for legal advice :) > > If this email isn't appropriate for the list... sorry, and please feel > free > to respond off-line. > > ...Skeeve You really need to get real legal advice. There are a fair number of deep legal issues here, as best I can tell (and I'm not a lawyer); there may not be anything that's actually legally protectable. Of course, the other party may have a lawyer who thinks the opposite, and there may or may not be enough case law to come to a reasonably probable common answer. So--decide what your preference is (I tend to agree with Randy, but that's me), and learn what your lawyer thinks of the general question. Then ask the lawyer what to do if there are conflicting opinions on whether or not it can be protected, and to draft language consistent with your preference and that belief for the contract. --Steve Bellovin, https://www.cs.columbia.edu/~smb From joquendo at e-fensive.net Fri Feb 13 20:43:00 2015 From: joquendo at e-fensive.net (J. Oquendo) Date: Fri, 13 Feb 2015 14:43:00 -0600 Subject: Intrusion Detection recommendations In-Reply-To: <5D34E0CB-A7E9-4092-87E6-E71ECBB1B55C@beckman.org> References: <5D34E0CB-A7E9-4092-87E6-E71ECBB1B55C@beckman.org> Message-ID: <20150213204300.GA4104@e-fensive.net> On Fri, 13 Feb 2015, Mel Beckman wrote: > JO, > > IDS to meet PCI or HIPAA requirements is "regulatory grade". It meets specific notification and logging requirements. SNORT-based systems fall into this category. > tl;dr (even I don't read what I write) You failed to see the snark in "military grade" crypto comment. This thought process is what causes many organizations to fail repeatedly. Relying on what the herd says. PCI, HIPAA, FINRA, FISMA, and all of the other regulatory guidelines, standards, baselines, and mandates spew from the manufacturing industry's ISO (BS pick your poisonous acronym). Call it SADHD (or Security ADHD) but I don't get why everyone keeps running around like dogs chasing their tails. Let's look at HIPAA where everyone is scrambling to replace Windows based on the word of the herd. Here is the rule: "Unsupported and unpatched environments are vulnerable to security risks. This may result in an officially recognized control failure by an internal or external audit body, leading to suspension of certifications, and/or public notification of the organization's inability to maintain its systems and customer information" Do you chuck Windows XP? It'd be easier to in theory but not in practice, however NO ONE EVER SAID: "thou shall chuck XP" (http://www.hhs.gov/ocr/privacy/hipaa/faq/securityrule/2014.html) "The Security Rule was written to allow flexibility for covered entities to implement security measures that best fit their organizational needs. The Security Rule does not specify minimum requirements for personal computer operating systems" Organizations keep relying on half-decent guidelines for remedies to their problems. By you thinking that you are going to plop in any "regulatory grade" *anything* and find security, you are doing not only yourself a huge disservice, but also to your clients. These pieces of technology (IPS, IDS, FWs, HIPS, NIPS, etc) are only capable of doing what you tell them to. Neither the Payment Card Industry, NIST, or even the President of your country (or Premier, or whatever else) should be telling you how to secure your organization. YOU need to know the ins and outs, take the proper steps and THEN use these technologies when you're done with your risk assessments. If you're relying solely on what others tell you is "regulatory-grade" or "military-grade" or any other kind of grade, your bound to be right up there with Target, Anthem, Citi, JP Morgan Chase, a wikipedia-length list of compromised companies. When doing pentesting work, I fill up IPS and IDS with so many false positives, the analysts are FORCED to ignore the results while I shimmy my shiny right on by. I know based on experience what someone is going to do when they see a kabillion alerts light up their dashboard. http://seclists.org/incidents/2000/Aug/277 The approach: "Let me cater to what they say I should do" versus: "Let me figure out what my organization does, needs to do, and how to get to the proper point" is mind boggling. I wish there were a statistical database of compromised companies, and the tools they used, frameworks they followed, and regulatory nonsense they needed to comply with was listed. Most of these regulatory mandates are based off of half-baked models that are partially good when followed thoroughly. However, they are ONLY partially good when an organization goes beyond the normal banter: "thou shall apply this" - Does not mean: plop in an IPS and call it a day. For the most part though, this practice of half-baked security will continue, vendors will make bucketloads of money, consumers of IPS/IDS devices will still complain how much the product sucks, and I as a pentester... I stay happy as it keeps me steadily enjoying Five Guys' burgers -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463 https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463 From rsk at gsp.org Fri Feb 13 21:27:12 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 13 Feb 2015 16:27:12 -0500 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: <20150213212711.GA16425@gsp.org> On Fri, Feb 13, 2015 at 02:45:46PM -0600, Rafael Possamai wrote: > I am a huge fan of FreeBSD, but for a medium/large business I'd definitely > use a fairly well tested security appliance like Cisco's ASA. Closed-source software is faith-based security. ---rsk From jkristal at gmail.com Thu Feb 12 17:18:50 2015 From: jkristal at gmail.com (Jeremiah Kristal) Date: Thu, 12 Feb 2015 12:18:50 -0500 Subject: Custom fiber for FTT* deployment Message-ID: I am researching a project that would involve running fiber to several thousand kiosks in a dense metro area. My $dayjob owns very dense metro fiber footpring in the metro in question, but splicing costs are high, and I prefer not to strand a lot of backbone fibers if at all possible. The customer's plan is to have a hub connected with a 10G link, and 9 spokes connected to the hub via a 1G link. The initial plan was to build laterals to the hub site, connect the hub site to backbone fiber that runs to a site with 10G switches, build laterals to each of the spoke sites, and have each of the spokes connected to backbone fiber pairs to the hub lateral and then to the hub Ethernet switches. I've been thinking about a more efficient way to do this, and I thought that I had read something on this list several years ago about custom fiber bundles with something like X pairs of different lengths in a single bundle. I would ideally like to be able to order a bundle with 10 pairs of SM fiber, with 2 pairs being 200' long, 2 pairs being 400' long, 2 pairs being 600' long, 2 pairs being 800' long, and the remaining 2 pairs being 1000' long. Has anyone ordered this type of fiber bundle before, and could you recommend a vendor that I can speak with about this? Jeremiah From jkristal at gmail.com Fri Feb 13 20:09:19 2015 From: jkristal at gmail.com (Jeremiah Kristal) Date: Fri, 13 Feb 2015 15:09:19 -0500 Subject: Customer fiber for FTT* deployment Message-ID: Apologies if this comes through twice, it's been waiting for moderation for 30 hours or so. I am researching a project that would involve running fiber to several thousand kiosks in a dense metro area. My $dayjob owns very dense metro fiber footpring in the metro in question, but splicing costs are high, and I prefer not to strand a lot of backbone fibers if at all possible. The customer's plan is to have a hub connected with a 10G link, and 9 spokes connected to the hub via a 1G link. The initial plan was to build laterals to the hub site, connect the hub site to backbone fiber that runs to a site with 10G switches, build laterals to each of the spoke sites, and have each of the spokes connected to backbone fiber pairs to the hub lateral and then to the hub Ethernet switches. I've been thinking about a more efficient way to do this, and I thought that I had read something on this list several years ago about custom fiber bundles with something like X pairs of different lengths in a single bundle. I would ideally like to be able to order a bundle with 10 pairs of SM fiber, with 2 pairs being 200' long, 2 pairs being 400' long, 2 pairs being 600' long, 2 pairs being 800' long, and the remaining 2 pairs being 1000' long. Has anyone ordered this type of fiber bundle before, and could you recommend a vendor that I can speak with about this? Jeremiah From naoto.mm at gmail.com Thu Feb 12 07:32:28 2015 From: naoto.mm at gmail.com (NAOTO MATSUMOTO) Date: Thu, 12 Feb 2015 16:32:28 +0900 Subject: FYI: An Easy way to build a server cluster without top of rack switches (MEMO) Message-ID: Hi all! We wrote up TIPS memo "an easy way to build a server cluster without top of rack switches" concept. This model have a reduce switches and cables costs and high network durability by lightweight and simple configuration. if you interest in, please try to do yourself this concept ;-) An Easy way to build a server cluster without top of rack switches (MEMO) http://slidesha.re/1EduYXM Best regards, -- Naoto MATSUMOTO From alexjasonleahu at gmail.com Thu Feb 12 14:48:16 2015 From: alexjasonleahu at gmail.com (Alex Leahu) Date: Thu, 12 Feb 2015 08:48:16 -0600 Subject: gmail spam help In-Reply-To: <22247730.4956.1423752014624.JavaMail.mhammett@ThunderFuck> References: <22247730.4956.1423752014624.JavaMail.mhammett@ThunderFuck> Message-ID: If it's email you are sending from your domain that's getting marked as spam make sure that you have a reverse DNS setup, an SPF record, and DKIM signing helps too. Alex On Feb 12, 2015 8:42 AM, "Mike Hammett" wrote: > Don't use GMail for things you care about? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Josh Luthman" > To: "Alex Rubenstein" > Cc: "NANOG list" > Sent: Thursday, February 12, 2015 8:31:58 AM > Subject: Re: gmail spam help > > Create a filter. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Feb 12, 2015 8:11 AM, "Alex Rubenstein" wrote: > > > Is there anyone on-list that can help me with a world -> gmail email > > issue, where email is being considering spam by gmail erroneously? > > > > Thanks. > > > > > > > > From dboisseleau at fonex.com Thu Feb 12 23:42:26 2015 From: dboisseleau at fonex.com (David Boisseleau) Date: Thu, 12 Feb 2015 23:42:26 +0000 Subject: Low cost WDM gear In-Reply-To: <535121FF-3722-4DF4-B1D1-C17D2BCCE08E@gt86car.org.uk> References: <5739795.895.1423332278146.JavaMail.mhammett@ThunderFuck> <535121FF-3722-4DF4-B1D1-C17D2BCCE08E@gt86car.org.uk> Message-ID: Hi Mike, You should try CYAN inc and the Z series. (US based) Very solid platform and very strong warranty. David Boisseleau -----Original Message----- From: NANOG [mailto:nanog-bounces+dboisseleau=fonex.com at nanog.org] On Behalf Of Colin Johnston Sent: February-07-15 6:29 PM To: Tim Durack Cc: NANOG Subject: Re: Low cost WDM gear Yes can do long distances without need to amplifier site (train tracks for example) but you need to make sure ground is stable and if using track bed of train track that the ballast is good and stable else ground tremors affect the signal quality. Colin > On 7 Feb 2015, at 22:32, Tim Durack wrote: > > You can do ~500km without inline amplifier sites using > EDFA+Raman+ROPA, but you are going to need some serious optical engineering to make that work. > The more standard way to do it is amplifier sites every 80-100km for EDFA. > If you are doing 10GigE you will need to allow for DCM also. > > On Sat, Feb 7, 2015 at 1:04 PM, Mike Hammett wrote: > >> One particular route I'm looking at is 185 miles, so of the options >> presented 300 km is closest. ;-) >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> ----- Original Message ----- >> >> From: "Christopher Morrow" >> To: "Kenneth McRae" >> Cc: "NANOG" >> Sent: Saturday, February 7, 2015 12:02:11 PM >> Subject: Re: Low cost WDM gear >> >> would be good for mike to define 'long distances' here, is it: >> 2km >> 30km >> 300km >> 3000km >> >> Probably the 30-60k range is what you mean by 'long distances' but... >> clarity might help. >> >> On Sat, Feb 7, 2015 at 12:55 PM, Kenneth McRae >> wrote: >>> Mike, >>> >>> I just replaced a bunch of FiberStore WDM passive muxes with OSI >>> Hardware equipment. The FiberStore gear was a huge disappointment >>> (excessive loss, poor technical support, refusal to issue refund >>> without threatening legal action, etc.). I have had good results >>> from the OSI equipment so far. I run passive muxes for CWDM (8 - 16 channels). >>> >>> On Feb 07, 2015, at 09:51 AM, Manuel Marín wrote: >>> >>> Hi Mike >>> >>> I can recommend a couple of vendors that provide cost effective >> solutions. >>> Ekinops & Packetlight. >>> >>> On Saturday, February 7, 2015, Mike Hammett wrote: >>> >>> I know there are various Asian vendors for low cost (less than $500) >> muxes >>> to throw 16 or however many colors onto a strand. However, they >>> don't >> work >>> so well when you don't control the optics used on both sides >>> (therefore must use standard wavelengths), obviously only do a >>> handful of channels >> and >>> have a distance limitation. >>> What solutions are out there that don't cost an arm and a leg? >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> -- >>> TRANSTELCO| Manuel Marin | VP Engineering | US: *+1 915-217-2232* | MX: >> *+52 >>> 656-257-1109* >>> >>> CONFIDENTIALITY NOTICE: This communication is intended only for the >>> use of the individual or entity to which it is addressed and may >>> contain information that is privileged, confidential, and exempt >>> from disclosure under applicable law. If you are not the intended >>> recipient of this information, you are notified that any use, >>> dissemination, distribution, >> or >>> copying of the communication is strictly prohibited. >>> >>> AVISO DE CONFIDENCIALIDAD: Esta comunicación es sólo para el uso de >>> la persona o entidad a la que se dirige y puede contener información >>> privilegiada, confidencial y exenta de divulgación bajo la >>> legislación aplicable. Si no es el destinatario de esta información, >>> se le notifica >> que >>> cualquier uso, difusión, distribución o copia de la comunicación >>> está estrictamente prohibido. >> >> > > > -- > Tim:> From dj at techwebhosting.com Thu Feb 12 15:58:31 2015 From: dj at techwebhosting.com (DJ Anderson) Date: Thu, 12 Feb 2015 06:58:31 -0900 (AKST) Subject: gmail spam help In-Reply-To: References: <5a28a08e199f4a07bb00295fc784d37d@exch2013-1.hq.nac.net> <2a66901afc7246e989d9e393d3740855@exch2013-1.hq.nac.net> Message-ID: <30C88180-4512-451C-90D1-73405693F2EA@techwebhosting.com> A good tool to test all that is mxtoolbox.com. They have black list checks and SMTP tests that will check your PTR records and other things. They also provide free weekly blacklist checks for one domain. DJ Anderson Sent from my iPhone > On Feb 12, 2015, at 10:53 AM, Scott Helms wrote: > > I'd be interested to know how you can be so adamant about the lack of spam > from this specific server. A great percentage of the spam hitting servers > I have visibility into comes from very similar kinds of set ups because > they tend to have little or no over sight in place. > > Also, lots of commercial email gets flagged as spam by users, even when > they opted in for the email. If enough people flagged email from this > server as spam it will cause Google to consider other email from the same > small server as likely to be spam as well. Small systems, especially new > ones, tend to unintentionally look like spam sources by not having proper > reverse records, making sure you have SPF set up for the domain, etc. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > >> On Thu, Feb 12, 2015 at 10:41 AM, Alex Rubenstein wrote: >> >> I should have been clearer. >> >> I have been getting complaints from my sales folks that when they send >> emails to people who use gmail (either a gmail account or google apps) that >> they recipient is reporting that the email is ending up in the Spam folder. >> So, I tested this myself, sending an email from alex at corp.nac.net> alex at corp.nac.net> to rubenstein45 at gmail.com> >> [cid:image001.png at 01D046AD.3B2FA890] >> >> This is curious to me, since @corp.nac.net is a small exchange >> implementation with only about 50 users behind it, and there is no question >> that there is no spamming going on from here. >> >> So, it’s not a question of adding a filter or not using gmail; it is not >> me who is using gmail in this problem. >> >> >> >> From: Josh Luthman [mailto:josh at imaginenetworksllc.com] >> Sent: Thursday, February 12, 2015 9:32 AM >> To: Alex Rubenstein >> Cc: NANOG list >> Subject: Re: gmail spam help >> >> >> Create a filter. >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> On Feb 12, 2015 8:11 AM, "Alex Rubenstein" > alex at corp.nac.net>> wrote: >> Is there anyone on-list that can help me with a world -> gmail email >> issue, where email is being considering spam by gmail erroneously? >> >> Thanks. >> >> From gaswarsaw-latam at outlook.com Fri Feb 13 18:55:00 2015 From: gaswarsaw-latam at outlook.com (Warsaw LATAM Operations Group) Date: Fri, 13 Feb 2015 13:55:00 -0500 Subject: Vancouver WA Comcast Outage? In-Reply-To: References: Message-ID: > From: aaron at heyaaron.com > Date: Thu, 12 Feb 2015 14:13:56 -0800 > Subject: Vancouver WA Comcast Outage? > To: nanog at nanog.org > > We just lost a handful of customers in Vancouver WA on Comcast. > Voice and data are out. > > Initial reports are saying a transformer blew down town. Service still degraded for you? Today it's me with long duration partial outage and very poor connectivity trying to reach Portland via Vancouver hop, on Comcast network. Still no relevant response for my open ticket from their party. From gaswarsaw-latam at outlook.com Fri Feb 13 18:48:03 2015 From: gaswarsaw-latam at outlook.com (Warsaw LATAM Operations Group) Date: Fri, 13 Feb 2015 13:48:03 -0500 Subject: Dark Fiber in Latin America In-Reply-To: <54DE230A.5090807@gmail.com> References: , <54DE230A.5090807@gmail.com> Message-ID: > Date: Fri, 13 Feb 2015 11:45:06 -0430 > From: alejandroacostaalamo at gmail.com > To: nanog at nanog.org > Subject: Re: Dark Fiber in Latin America > > Hi Beavis, > Just in case, there is a Lacnog mailing list.., the URL: > https://mail.lacnic.net/mailman/listinfo/lacnog > In case you don't get a response here you might want to try thee. > > Alejandro, Did you try ufinet / Fenosa? We use both their dark fibre and transport services in several LATAM locations, including both locations you are looking for providers. A while ago we had some problems with long lead times for new connections but it might have normalized. Worths giving a try. Regards, > > > El 2/13/2015 a las 11:32 AM, Beavis escribió: > > All, > > > > I'm looking for some general information of a dark fiber provider in latin > > america countries namely Nicaragua and Costa Rica. Any info is greatly > > appreciated. > > > > Please contact me off list. > > > > > > thanks, > > -Beavis > > > > > From rafael at gav.ufsc.br Fri Feb 13 21:45:30 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 13 Feb 2015 15:45:30 -0600 Subject: Intrusion Detection recommendations In-Reply-To: <20150213212711.GA16425@gsp.org> References: <20150213212711.GA16425@gsp.org> Message-ID: What is the alternative then... Does he have the time to become a BSD guru and master ipfw and pf? Probably not feasible with all other job duties, unless he locks himself in his mom's basement for the next 5 years. On Fri, Feb 13, 2015 at 3:27 PM, Rich Kulawiec wrote: > On Fri, Feb 13, 2015 at 02:45:46PM -0600, Rafael Possamai wrote: > > I am a huge fan of FreeBSD, but for a medium/large business I'd > definitely > > use a fairly well tested security appliance like Cisco's ASA. > > Closed-source software is faith-based security. > > ---rsk > From cidr-report at potaroo.net Fri Feb 13 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Feb 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201502132200.t1DM00Yu014069@wattle.apnic.net> This report has been generated at Fri Feb 13 21:14:25 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 06-02-15 537226 294411 07-02-15 536997 294672 08-02-15 537472 294846 09-02-15 537682 295006 10-02-15 537711 296080 11-02-15 537678 295979 12-02-15 537820 294638 13-02-15 538035 294858 AS Summary 49655 Number of ASes in routing system 19863 Number of ASes announcing only one prefix 3098 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120442368 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 13Feb15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 538481 294885 243596 45.2% All ASes AS6389 2890 69 2821 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS22773 2985 172 2813 94.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2824 77 2747 97.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 14 2459 99.4% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2330 313 2017 86.6% NET Servi�os de Comunica��o S.A.,BR AS4755 1971 245 1726 87.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4766 2872 1316 1556 54.2% KIXS-AS-KR Korea Telecom,KR AS7303 1788 279 1509 84.4% Telecom Argentina S.A.,AR AS9808 1535 56 1479 96.4% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS10620 3098 1646 1452 46.9% Telmex Colombia S.A.,CO AS6147 1587 154 1433 90.3% Telefonica del Peru S.A.A.,PE AS7545 2586 1220 1366 52.8% TPG-INTERNET-AP TPG Telecom Limited,AU AS20115 1849 517 1332 72.0% CHARTER-NET-HKY-NC - Charter Communications,US AS8402 1342 25 1317 98.1% CORBINA-AS OJSC "Vimpelcom",RU AS4323 1628 408 1220 74.9% TWTC - tw telecom holdings, inc.,US AS9498 1300 111 1189 91.5% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2041 869 1172 57.4% MEGAPATH5-US - MegaPath Corporation,US AS7552 1146 57 1089 95.0% VIETEL-AS-AP Viettel Corporation,VN AS22561 1333 252 1081 81.1% AS22561 - CenturyTel Internet Holdings, Inc.,US AS34984 1965 891 1074 54.7% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS3356 2571 1503 1068 41.5% LEVEL3 - Level 3 Communications, Inc.,US AS6983 1622 565 1057 65.2% ITCDELTA - Earthlink, Inc.,US AS6849 1195 210 985 82.4% UKRTELNET JSC UKRTELECOM,UA AS7738 1000 84 916 91.6% Telemar Norte Leste S.A.,BR AS38285 983 133 850 86.5% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS18881 863 30 833 96.5% Global Village Telecom,BR AS4538 1776 957 819 46.1% ERX-CERNET-BKB China Education and Research Network Center,CN AS8151 1551 740 811 52.3% Uninet S.A. de C.V.,MX AS26615 921 137 784 85.1% Tim Celular S.A.,BR AS4780 1082 302 780 72.1% SEEDNET Digital United Inc.,TW Total 55107 13352 41755 75.8% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.92.160.0/24 AS14013 EPSON-ROBOTS - EPSON America (Factory Automation/Robotics),US 23.92.161.0/24 AS14013 EPSON-ROBOTS - EPSON America (Factory Automation/Robotics),US 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.40.48.0/20 AS21859 C3 - C3 Networks Inc,US 45.42.36.0/24 AS30466 CAXD - Cable Axion Digitel Inc.,CA 45.42.37.0/24 AS30466 CAXD - Cable Axion Digitel Inc.,CA 45.42.38.0/24 AS30466 CAXD - Cable Axion Digitel Inc.,CA 45.42.39.0/24 AS30466 CAXD - Cable Axion Digitel Inc.,CA 45.42.40.0/24 AS62941 VARIANCEM-AS - VarianceM,US 45.42.41.0/24 AS62941 VARIANCEM-AS - VarianceM,US 45.42.42.0/24 AS62941 VARIANCEM-AS - VarianceM,US 45.42.43.0/24 AS62941 VARIANCEM-AS - VarianceM,US 45.42.44.0/24 AS62941 VARIANCEM-AS - VarianceM,US 45.42.45.0/24 AS62941 VARIANCEM-AS - VarianceM,US 45.42.46.0/24 AS62941 VARIANCEM-AS - VarianceM,US 45.42.47.0/24 AS62941 VARIANCEM-AS - VarianceM,US 45.42.52.0/22 AS63317 DESERT-CLOUD - Desert Cloud, LLC,US 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, Inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 100.42.176.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc.,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS23937 103.20.101.0/24 AS23937 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.244.20.0/22 AS58754 103.244.20.0/24 AS58754 103.244.21.0/24 AS58754 103.244.22.0/24 AS58754 103.244.23.0/24 AS58754 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.100.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 160.234.128.0/17 AS37962 CNNIC-SGATHER-AP Beijing Sgather Telecom Engineering Co.Ltd.,CN 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.224.128.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc.,US 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 185.87.232.0/22 AS20178 TECH-MEDIA-AS Tech-Media Sp. z o.o.,PL 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.106.32.0/22 AS49873 -Reserved AS-,ZZ 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 197.149.188.0/22 AS37282 MAINONE,NG 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.30.136.0/23 AS46636 NATCOWEB - NatCoWeb Corp.,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.204.144.0/21 AS36007 -Reserved AS-,ZZ 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 , 202.45.10.0/24 AS24327 , 202.45.11.0/24 AS24327 , 202.47.160.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.161.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.162.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.164.0/24 AS9833 , 202.47.165.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.166.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.167.0/24 AS56111 AGARTO-MY Agarto Sdn Bhd,MY 202.47.169.0/24 AS9833 , 202.47.170.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.171.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.172.0/24 AS9833 , 202.47.173.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.174.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.175.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.176.0/24 AS9833 , 202.47.177.0/24 AS9833 , 202.47.178.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.179.0/24 AS9833 , 202.47.180.0/24 AS9833 , 202.47.181.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.185.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.190.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.28.240.0/20 AS10148 UNIMELB-AS-AP The University of Melbourne, Melbourne, Victoria,AU 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.175.8.0/23 AS23858 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.15.240.0/22 AS36212 -Reserved AS-,ZZ 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.70.168.0/22 AS4436 AS-GTT-4436 - nLayer Communications, Inc.,US 208.70.172.0/22 AS4436 AS-GTT-4436 - nLayer Communications, Inc.,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.96.0/22 AS4436 AS-GTT-4436 - nLayer Communications, Inc.,US 208.93.100.0/22 AS4436 AS-GTT-4436 - nLayer Communications, Inc.,US 208.93.216.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 13 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Feb 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201502132200.t1DM01gb014086@wattle.apnic.net> BGP Update Report Interval: 05-Feb-15 -to- 12-Feb-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 260831 4.7% 1890.1 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS27194 181162 3.3% 90581.0 -- REALLYFAST - ReallyFast.net,US 3 - AS9829 133632 2.4% 79.2 -- BSNL-NIB National Internet Backbone,IN 4 - AS61894 94291 1.7% 23572.8 -- FreeBSD Brasil LTDA,BR 5 - AS53563 57787 1.1% 5778.7 -- XPLUSONE - X Plus One Solutions, Inc.,US 6 - AS36947 54890 1.0% 262.6 -- ALGTEL-AS,DZ 7 - AS17974 48847 0.9% 17.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 8 - AS6147 47352 0.9% 27.0 -- Telefonica del Peru S.A.A.,PE 9 - AS8452 41602 0.8% 25.4 -- TE-AS TE-AS,EG 10 - AS25563 34077 0.6% 8519.2 -- WEBLAND-AS Webland AG, Autonomous System,CH 11 - AS55714 33537 0.6% 149.7 -- APNIC-FIBERLINK-PK Fiberlink Pvt.Ltd,PK 12 - AS8402 33235 0.6% 22.7 -- CORBINA-AS OJSC "Vimpelcom",RU 13 - AS51964 32478 0.6% 67.5 -- ORANGE-BUSINESS-SERVICES-IPSN-ASN Equant Inc.,FR 14 - AS10620 32159 0.6% 10.4 -- Telmex Colombia S.A.,CO 15 - AS3462 30874 0.6% 114.3 -- HINET Data Communication Business Group,TW 16 - AS42337 26508 0.5% 166.7 -- RESPINA-AS Respina Networks & Beyond PJSC,IR 17 - AS39891 23394 0.4% 9.5 -- ALJAWWALSTC-AS Saudi Telecom Company JSC,SA 18 - AS60725 23207 0.4% 1160.3 -- O3B-AS O3b Limited,JE 19 - AS14840 22433 0.4% 659.8 -- COMMCORP COMUNICACOES LTDA,BR 20 - AS23342 22142 0.4% 567.7 -- UNITEDLAYER - Unitedlayer, Inc.,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS27194 181162 3.3% 90581.0 -- REALLYFAST - ReallyFast.net,US 2 - AS61894 94291 1.7% 23572.8 -- FreeBSD Brasil LTDA,BR 3 - AS61039 16164 0.3% 16164.0 -- ZMZ OAO ZMZ,RU 4 - AS25563 34077 0.6% 8519.2 -- WEBLAND-AS Webland AG, Autonomous System,CH 5 - AS26264 7649 0.1% 7649.0 -- TVI-AS - TVI Inc,US 6 - AS197914 21790 0.4% 7263.3 -- STOCKHO-AS Stockho Hosting SARL,FR 7 - AS53563 57787 1.1% 5778.7 -- XPLUSONE - X Plus One Solutions, Inc.,US 8 - AS50104 4281 0.1% 4281.0 -- SATORP-AS SAUDI ARAMCO TOTAL Refining and Petrochemical Company,SA 9 - AS33721 4110 0.1% 4110.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 10 - AS62174 3419 0.1% 3419.0 -- INTERPAN-AS INTERPAN LTD.,BG 11 - AS33440 10610 0.2% 2652.5 -- WEBRULON-NETWORK - webRulon, LLC,US 12 - AS47680 10690 0.2% 2138.0 -- NHCS EOBO Limited,IE 13 - AS23752 260831 4.7% 1890.1 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 14 - AS6775 15016 0.3% 1877.0 -- BACKBONE_EHF_EUROPE Backbone ehf,CH 15 - AS20151 1662 0.0% 1662.0 -- MCW-12-01 - Mountain Computer Wizards, Inc.,US 16 - AS52355 3051 0.1% 1525.5 -- Jalasoft Corp.,BO 17 - AS45606 7627 0.1% 1525.4 -- 18 - AS198053 1507 0.0% 1507.0 -- AMTEL VECTRA S.A.,PL 19 - AS63269 1498 0.0% 1498.0 -- DYONYX - DYONYX L.P,US 20 - AS262149 3609 0.1% 1203.0 -- Sistemas Fratec S.A.,CR TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 129883 2.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 128839 2.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 177.10.158.0/24 94179 1.7% AS61894 -- FreeBSD Brasil LTDA,BR 4 - 162.246.92.0/22 90669 1.6% AS27194 -- REALLYFAST - ReallyFast.net,US 5 - 162.208.40.0/22 90493 1.6% AS27194 -- REALLYFAST - ReallyFast.net,US 6 - 199.38.164.0/23 57762 1.0% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 7 - 105.96.0.0/22 51057 0.9% AS36947 -- ALGTEL-AS,DZ 8 - 64.29.130.0/24 21919 0.4% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 9 - 130.0.192.0/21 21786 0.4% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 10 - 91.235.169.0/24 16164 0.3% AS61039 -- ZMZ OAO ZMZ,RU 11 - 91.193.202.0/24 15108 0.3% AS42081 -- SPEEDY-NET-AS Speedy net EAD,BG 12 - 79.134.225.0/24 14962 0.3% AS6775 -- BACKBONE_EHF_EUROPE Backbone ehf,CH 13 - 162.249.183.0/24 11983 0.2% AS60725 -- O3B-AS O3b Limited,JE 14 - 92.43.216.0/21 11655 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 15 - 185.84.192.0/22 11381 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 16 - 42.83.48.0/20 11205 0.2% AS18135 -- BTV BTV Cable television,JP 17 - 185.26.155.0/24 11151 0.2% AS60725 -- O3B-AS O3b Limited,JE 18 - 178.174.96.0/19 11038 0.2% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 19 - 88.87.160.0/19 10655 0.2% AS47680 -- NHCS EOBO Limited,IE 20 - 192.58.232.0/24 9886 0.2% AS6629 -- NOAA-AS - NOAA,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cory.haessler at cniteam.com Thu Feb 12 19:16:01 2015 From: cory.haessler at cniteam.com (Cory Haessler) Date: Thu, 12 Feb 2015 14:16:01 -0500 Subject: Accessing YouTube Video from a single /24 Message-ID: <54DCFBF1.3040609@cniteam.com> NANOG Request for a Google / Youtube network eng. to contact me off list to help troubleshooting. Thanks, ------------------------------------------------------------------- Cory Haessler | CNI | Network Operations Center Manager | 888-618-4638 www.cniteam.com; www.ifnetwork.biz 13888 County Rd. 25A | Wapakoneta, Ohio 45895 ------------------------------------------------------------------- From Valdis.Kletnieks at vt.edu Fri Feb 13 22:09:28 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 13 Feb 2015 17:09:28 -0500 Subject: Intrusion Detection recommendations In-Reply-To: Your message of "Fri, 13 Feb 2015 15:45:30 -0600." References: <20150213212711.GA16425@gsp.org> Message-ID: <19909.1423865368@turing-police.cc.vt.edu> On Fri, 13 Feb 2015 15:45:30 -0600, Rafael Possamai said: > What is the alternative then... Does he have the time to become a BSD guru > and master ipfw and pf? Probably not feasible with all other job duties, > unless he locks himself in his mom's basement for the next 5 years. By the time you learn enough about security that the box is actually securing something rather than just filling a checkbox on a form, mastering ipwf/pf is the least of your worries.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From joquendo at e-fensive.net Fri Feb 13 21:42:38 2015 From: joquendo at e-fensive.net (J. Oquendo) Date: Fri, 13 Feb 2015 15:42:38 -0600 Subject: Intrusion Detection recommendations In-Reply-To: References: <20150213212711.GA16425@gsp.org> Message-ID: <20150213214238.GA5223@e-fensive.net> On Fri, 13 Feb 2015, Rafael Possamai wrote: > What is the alternative then... Does he have the time to become a BSD guru > and master ipfw and pf? Probably not feasible with all other job duties, > unless he locks himself in his mom's basement for the next 5 years. > The alternative is to understand what his network does, what it was designed to do, and what he needs it to do. The end solution (IPS, IDS, ASA, whatever you want to throw in) should be just that, an END solution once he has taken the time to assess risk. This is a concept many miss. As for "testing" ... So you own a house, you hire an assessor to analyze your property, write a report for you on your vulnerabilities. "You have 12 windows. OMFG Someone can break one of those windows and steal your family jewels!" Vendor gets paid and leaves you with a headache. 12 windows? So what... Behind those windows are a rabid pitbull I never feed. Wanna take a chance to break in? Pentest... "So you own a house, same windows, now you're paying someone to get in." Let me tell you how pentesting fails. Pentesting fails because most companies get all bent out of shapes based on Internet history of systems, and applications crashing from a simple network scan. Ask your next pentesting client (if this pentesting is your primary function) to allow you to perform a no-holds barred pentest including social engineering. You'll get the deer in headlights look. I discussed this recently with a client who wanted to be snarky: "Oh you'll never get in my systems" and I decided to inform him about reality... Reality: Hardcore attackers are NOT charging down the castle road with a log trying to break down the castle wall. They're sending client side attacks (phishing emails, waterhole attacks). It's more cost effective for an attacker to do this versus trying to defeat the router, the switching with all its VLAN glory (that gets vlan hoppped), the L7 firewalls, the load balancers, the IPS, and then the IPS. Its useless, noisy, and just not cost effective when you think about it. IPS, IDS does little because they're RARELY applied in a proper fashion. As for tinkering, geekiness. If you can't at least wrap your head around the concept, then I don't know why you'd want to be on this list. Further, IPS/IDS is better suited to be inverted (Extrusion Detection) as you WILL NEVER (CAN NEVER) stop someone from knocking on your door. So you block every APNIC block thinking "Phew I just blocked 100% of APTs" until you get whacked from a hosting company in the US. What have you accomplished? On the EXTRUSION side of the equation, knowing your network, and how it works makes more sense. Your focus gets shifted to the following logic: (rule) SHOW ME ANYTHING LEAVING MY NETWORK THAT IS OVER 1MB ON A SUNDAY MORNING 2AM ... This anomaly means a hell of a lot more than watching all of the internet trash that will hit your door (egree ifaces) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463 https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463 From listas at esds.com.br Fri Feb 13 22:19:39 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Fri, 13 Feb 2015 20:19:39 -0200 Subject: Verizon webmail support Message-ID: Could anyone from Verizon webmail service contact me regarding access issues? Thanks in advance. -- Eduardo Schoedler From gaswarsaw-latam at outlook.com Sat Feb 14 00:48:44 2015 From: gaswarsaw-latam at outlook.com (Warsaw LATAM Operations Group) Date: Fri, 13 Feb 2015 19:48:44 -0500 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: Hello Andy, I believe you are very good set up the way you are in technology. I see you are surrounded by BSD systems everywhere, on servers, mobile and desktop. And I suggest you keep running FreeBSD for this new security requirement you have. We run FreeBSD as IDS/IPS system on several sites, and pfSense on a couple others. From my experience, we started using Snort, the common path people usually follow, but under certain circumstances, the drop ratio (unprocessed packets) started to raise a lot, and we looked for options. Tried Bro and Suricata and with some help from one of our servers supplier we decided to give Suricata a tuning and special try, and it became our primary option for IDS. Therefore I strongly suggest you start researching around Bro vs Snort vs Suricata and try to reach your conclusions from your own findings. But if you ask me for suggestion, as a long time user for Snort, I deprecated it in favor of Suricata. So my primary suggestion is Suricata + FreeBSD as IDP. Suricata is a very serious Project with very good software provided. We run ServerU networking servers, and they are the vendor who supported us. Usually they offer their own software solution called ProApps, it's a system made on top of FreeBSD which you have full root access etc, a plain old good FreeBSD system, but with nice auto update features and a helpful web GUI which allows me to delegate IDS operations to different level of staff operators on my team. They allow using for their ProApps solution on ServerU hardware, so if intend to add new hardware to your project, it might worth a try. I find the tool very powerful and very complete. On pfSense side you have a third party package made by community members, it also has a nice GUI, good deployment practices, but is Snort based. At one special location we needed even more performance for packets capturing, and we added Suricata running in Netmap mode, and it raised performance three times on the same box. So if you are looking for something easy, ready and supported, go for ServerU+ProApps. If you are looking for plain good open source arranged the way want to, you can have just the same with FreeBSD + Suricata & Friends. Should you want to do everything by yourself, FreeBSD + Suricata + Barnyard2 + Sguil + Snortsam is my suggested path way to go, with Richard Beijtlichs' books on your hand for good analysis learning and IDS best common operation practices. And maybe I can be of any help, private mail me if you want to. Regards, > From: andy at newslink.com > Subject: Intrusion Detection recommendations > Date: Fri, 13 Feb 2015 11:40:06 -0600 > To: nanog at nanog.org > > NANOG'ers, > > I've been tasked by our company president to learn about, investigate and recommend an intrusion detection system for our company. > > We're a smaller outfit, less than 100 employees, entirely Apple-based. Macs, iPhones, some Mac Mini servers, etc., and a fiber connection to the world. We are protected by a FreeBSD firewall setup, and we stay current on updates/patches from Apple and FreeBSD, but that's as far as my expertise goes. > > Initially, what do people recommend for: > > 1. Crash course in intrusion detection as a whole > 2. Suggestions or recommendations for intrusion detection hardware or software > 3. Other things I'm likely overlooking > > Thank you all in advance for your wisdom. > > > ---- > 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 mel at beckman.org Sat Feb 14 01:06:04 2015 From: mel at beckman.org (Mel Beckman) Date: Sat, 14 Feb 2015 01:06:04 +0000 Subject: Intrusion Detection recommendations In-Reply-To: <20150213204300.GA4104@e-fensive.net> References: <5D34E0CB-A7E9-4092-87E6-E71ECBB1B55C@beckman.org>, <20150213204300.GA4104@e-fensive.net> Message-ID: <4682013C-F4F9-4193-82D1-33BF19F14A84@beckman.org> tl;dr dc -mel > On Feb 13, 2015, at 1:13 PM, "J. Oquendo" wrote: > >> On Fri, 13 Feb 2015, Mel Beckman wrote: >> >> JO, >> >> IDS to meet PCI or HIPAA requirements is "regulatory grade". It meets specific notification and logging requirements. SNORT-based systems fall into this category. > > tl;dr (even I don't read what I write) > > You failed to see the snark in "military grade" crypto > comment. This thought process is what causes many > organizations to fail repeatedly. Relying on what the herd > says. PCI, HIPAA, FINRA, FISMA, and all of the other > regulatory guidelines, standards, baselines, and mandates > spew from the manufacturing industry's ISO (BS pick your > poisonous acronym). Call it SADHD (or Security ADHD) but I > don't get why everyone keeps running around like dogs > chasing their tails. > > Let's look at HIPAA where everyone is scrambling to replace > Windows based on the word of the herd. Here is the rule: > > "Unsupported and unpatched environments are vulnerable to > security risks. This may result in an officially recognized > control failure by an internal or external audit body, > leading to suspension of certifications, and/or public > notification of the organization's inability to maintain > its systems and customer information" > > Do you chuck Windows XP? It'd be easier to in theory but not > in practice, however NO ONE EVER SAID: "thou shall chuck XP" > (http://www.hhs.gov/ocr/privacy/hipaa/faq/securityrule/2014.html) > > "The Security Rule was written to allow flexibility for > covered entities to implement security measures that best > fit their organizational needs. The Security Rule does > not specify minimum requirements for personal computer > operating systems" > > Organizations keep relying on half-decent guidelines for > remedies to their problems. By you thinking that you are > going to plop in any "regulatory grade" *anything* and find > security, you are doing not only yourself a huge disservice, > but also to your clients. These pieces of technology (IPS, > IDS, FWs, HIPS, NIPS, etc) are only capable of doing what > you tell them to. Neither the Payment Card Industry, NIST, > or even the President of your country (or Premier, or > whatever else) should be telling you how to secure your > organization. YOU need to know the ins and outs, take the > proper steps and THEN use these technologies when you're > done with your risk assessments. > > If you're relying solely on what others tell you is > "regulatory-grade" or "military-grade" or any other kind of > grade, your bound to be right up there with Target, Anthem, > Citi, JP Morgan Chase, a wikipedia-length list of > compromised companies. > > When doing pentesting work, I fill up IPS and IDS with so > many false positives, the analysts are FORCED to ignore the > results while I shimmy my shiny right on by. I know based on > experience what someone is going to do when they see a > kabillion alerts light up their dashboard. > > http://seclists.org/incidents/2000/Aug/277 > > The approach: "Let me cater to what they say I should do" > versus: "Let me figure out what my organization does, needs > to do, and how to get to the proper point" is mind boggling. > I wish there were a statistical database of compromised > companies, and the tools they used, frameworks they followed, > and regulatory nonsense they needed to comply with was listed. > Most of these regulatory mandates are based off of half-baked > models that are partially good when followed thoroughly. > However, they are ONLY partially good when an organization > goes beyond the normal banter: "thou shall apply this" - Does > not mean: plop in an IPS and call it a day. For the most part > though, this practice of half-baked security will continue, > vendors will make bucketloads of money, consumers of IPS/IDS > devices will still complain how much the product sucks, and > I as a pentester... I stay happy as it keeps me steadily > enjoying Five Guys' burgers > > > > -- > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM > > "Where ignorance is our master, there is no possibility of > real peace" - Dalai Lama > > 0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463 > https://pgp.mit.edu/pks/lookup?op=get&search=0xFC837AF59D8A4463 From ammar at fastreturn.net Sat Feb 14 01:10:40 2015 From: ammar at fastreturn.net (Ammar Zuberi) Date: Sat, 14 Feb 2015 05:10:40 +0400 Subject: GTT NOC Message-ID: Hi all, Does anyone know of a direct phone number for someone with somewhat authority at GTT? Our prefix has been hijacked by a customer of theirs and we haven’t received any kind of response to our email and the guys on the phone seem to not speak very good English. Any ideas? Ammar. From mel at beckman.org Sat Feb 14 01:11:00 2015 From: mel at beckman.org (Mel Beckman) Date: Sat, 14 Feb 2015 01:11:00 +0000 Subject: Intrusion Detection recommendations In-Reply-To: <20150213212711.GA16425@gsp.org> References: , <20150213212711.GA16425@gsp.org> Message-ID: Of course it is. You say that like faith is a bad thing. The illogic of claiming to have no faith in anything is this: it's impractical to assume the role of quality assurance for everything in your life. The question is your faith reasonable. Ever use an elevator? Faith. Drive a car? Faith. Drive through a green light? Faith. Faith. Faith. Show me a man who has no faith, and I'll show you a man who is paralyzed. (Not a sexist statement; woman seem to have few problems with Faith). -mel > On Feb 13, 2015, at 1:27 PM, "Rich Kulawiec" wrote: > >> On Fri, Feb 13, 2015 at 02:45:46PM -0600, Rafael Possamai wrote: >> I am a huge fan of FreeBSD, but for a medium/large business I'd definitely >> use a fairly well tested security appliance like Cisco's ASA. > > Closed-source software is faith-based security. > > ---rsk From jason at unlimitednet.us Sat Feb 14 01:20:44 2015 From: jason at unlimitednet.us (Jason Canady) Date: Fri, 13 Feb 2015 20:20:44 -0500 Subject: GTT NOC In-Reply-To: References: Message-ID: <4861F48E-6F5D-40CB-84BA-276E495CDF50@unlimitednet.us> Hi Ammar, Sorry to hear this has happened. I do not have any contact info, but have you tried announcing more specific prefixes to override the hijacker? Jason On Feb 13, 2015, at 20:10, Ammar Zuberi wrote: > Hi all, > > Does anyone know of a direct phone number for someone with somewhat authority at GTT? Our prefix has been hijacked by a customer of theirs and we haven’t received any kind of response to our email and the guys on the phone seem to not speak very good English. > > Any ideas? > > Ammar. From adam at davenpro.com Sat Feb 14 01:51:22 2015 From: adam at davenpro.com (Adam Davenport) Date: Fri, 13 Feb 2015 20:51:22 -0500 Subject: GTT NOC In-Reply-To: References: Message-ID: <54DEAA1A.2090400@davenpro.com> Ammar, Feel free to contact me off-list, and I'd be happy to take a look into this issue for you. Thanks! On 2/13/2015 8:10 PM, Ammar Zuberi wrote: > Hi all, > > Does anyone know of a direct phone number for someone with somewhat authority at GTT? Our prefix has been hijacked by a customer of theirs and we haven’t received any kind of response to our email and the guys on the phone seem to not speak very good English. > > Any ideas? > > Ammar. From ahad at telcoinabox.com Sat Feb 14 02:13:42 2015 From: ahad at telcoinabox.com (Ahad Aboss) Date: Sat, 14 Feb 2015 13:13:42 +1100 Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> Message-ID: William, I beg to differ though this is getting slightly off topic. Art = something different, unexpected, not quite in your ordinary experience yet related to your ordinary experience. Art is connected to what we experience every day but it represents some kind of transformation of the everyday. Something that is not actually entirely real, it can’t be found by locating it. It requires human intervention, it’s the finger print if you will, of our existence in the world that has its impact on things that we transform through the use of imagination. How can architecture being an interaction of time, process, flow, people and things be art? The answer is elegance. It inspires people to see things in a new way and the interaction with people is the clearest point where architecture becomes an art. Properly architected network not only need to work well now, they must also provide a foundation for business and transform business, provide boundaries for information and people, and yet enable collaboration. We are entering an age of agile service creation with virtualized IT infrastructure, breaking down old constraints in many domains, including the delivery of services. No need to dwell further in to this era of SDN and NFV. To achieve all this, network designs must go beyond mechanical algorithms, and even beyond the uncertain empirical, into the world of abstract concept, mathematical theory, and raw power. Network architecture is not just about configuring routers, switches, firewalls or load balancers. One must think beyond that. How does technology drive the business? What is the perception of the network within the organization? What is the perception of the technology stance beyond the organization? If competitors see your network design, will they wonder why they didn’t think of it, or just wonder why it works at all? If a potential partner sees your network design, will they see the future or the past? All these things contribute art to the world of network architecture. Here is a question for you; When you observe a beautifully architected building, what do you see? (Link to some examples) http://www.azuremagazine.com/article/2014-top-10-architecture-projects/ Is it all about noticing the details, making observation about textures, lines materials, shapes, proportions, light and shadow? Or do we agree that architects don't only deal with buildings - they think of people, places, materials, philosophy and history, and only then consider the actual building? Ahad -----Original Message----- From: William Waites [mailto:wwaites at tardis.ed.ac.uk] Sent: Friday, 13 February 2015 8:55 PM To: ahad at telcoinabox.com Cc: skeeve at eintellegonetworks.com; owen at delong.com; bill at herrin.us; nanog at nanog.org Subject: [OT] Re: Intellectual Property in Network Design On Fri, 13 Feb 2015 11:43:14 +1100, Ahad Aboss said: > In a sense, you are an artist as network architecture > is an art in itself. It involves interaction with time, > processes, people and things or an intersection between all. This Friday's off-topic post for NANOG: Doing art is creative practice directed to uncover something new and not pre-conceived. Successful acts of art produce something that not only wasn't there before but that nobody thought could be there. The art is the change in thinking that results. Whatever else is left over is residue. An engineer or architect in the usual setting, no matter how skilled, is not doing art because the whole activity is pre-conceived. Even a clean and elegant design is not usually intended to show beautiful connections between ideas the same way poetry or mathematics might. Hiring an engineer for this purpose almost never happens in industry. Rather the purpose is to make a thing that does what it is intended to do. It is craft, or second-order residue. Useful, possibly difficult, but not art. Some people want to claim ownership of a recipe for predictably creating residue of a certain kind. An artist knows that this is not good for doing art because nothing new can come from it. If they are committed to their practice, they will not seek to prevent others from using an old recipe. Why would they? They have already moved on. Some older thoughts on the topic: http://archive.groovy.net/syntac/ From mysidia at gmail.com Sat Feb 14 03:50:44 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 13 Feb 2015 21:50:44 -0600 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: On Fri, Feb 13, 2015 at 11:40 AM, Andy Ringsmuth wrote: > NANOG'ers, > I've been tasked by our company president to learn about, investigate and recommend an intrusion detection system for our company. An important thing to realize is that an Intrusion Detection System is not a "product" you can buy. And if your org. is 100 people, you should probably think about engaging some professional security services firms to help, starting with a basic Info. security and physical security audit from an independent third party. An intrusion detection system consists of an infrastructure stack containing vigilant dedicated human beings, devices, various software for instrumenting the network in different ways and analyzing collected data, documentation, business, and security processes within the organization. Without enough of all those pieces, there are plenty of off-the-shelf IPS offerings, BUT using one could very well instill a false sense of security, because you have no idea if the product is actually doing a good job at what it is supposed to do, and not just presenting a "perception" of security mostly by tackling just whatever bugs or malware is appearing in the news headlines of the day. Also, there is the matter of being equipped with suitable analysis and response plans to be prepared for the time that the IDS alarm actually goes off, and to be able to determine if it's actually legitimately a false alarm, something meriting investigation, or if it represents an emergency. > We're a smaller outfit, less than 100 employees, entirely Apple-based. Macs, iPhones, some Mac Mini servers, etc. [snip] -- -JH From kmedcalf at dessus.com Sat Feb 14 05:42:30 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 13 Feb 2015 22:42:30 -0700 Subject: Intrusion Detection recommendations In-Reply-To: Message-ID: <324b2ab9d8378a4c94f68b881bf9d362@mail.dessus.com> German Shepherd Dogs are wonderful intrusion detection devices. In a lot of cases they also server as excellent intrusion prevention devices as well. (Must be Friday night) :-) --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Andy Ringsmuth >Sent: Friday, 13 February, 2015 10:40 >To: NANOG >Subject: Intrusion Detection recommendations > >NANOG'ers, > >I've been tasked by our company president to learn about, investigate and >recommend an intrusion detection system for our company. > >We're a smaller outfit, less than 100 employees, entirely Apple-based. >Macs, iPhones, some Mac Mini servers, etc., and a fiber connection to the >world. We are protected by a FreeBSD firewall setup, and we stay current >on updates/patches from Apple and FreeBSD, but that's as far as my >expertise goes. > >Initially, what do people recommend for: > >1. Crash course in intrusion detection as a whole >2. Suggestions or recommendations for intrusion detection hardware or >software >3. Other things I'm likely overlooking > >Thank you all in advance for your wisdom. > > >---- >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 ammar at fastreturn.net Sat Feb 14 08:06:22 2015 From: ammar at fastreturn.net (Ammar Zuberi) Date: Sat, 14 Feb 2015 12:06:22 +0400 Subject: GTT NOC In-Reply-To: <54DEAA1A.2090400@davenpro.com> References: <54DEAA1A.2090400@davenpro.com> Message-ID: Hi all, Thanks so much for the responses. It looks like the issue has now been resolved! Ammar > On 14 Feb 2015, at 5:51 am, Adam Davenport wrote: > > Ammar, > > Feel free to contact me off-list, and I'd be happy to take a look into this issue for you. Thanks! > >> On 2/13/2015 8:10 PM, Ammar Zuberi wrote: >> Hi all, >> >> Does anyone know of a direct phone number for someone with somewhat authority at GTT? Our prefix has been hijacked by a customer of theirs and we haven’t received any kind of response to our email and the guys on the phone seem to not speak very good English. >> >> Any ideas? >> >> Ammar. > From randy at psg.com Sat Feb 14 08:38:54 2015 From: randy at psg.com (Randy Bush) Date: Sat, 14 Feb 2015 17:38:54 +0900 Subject: Intrusion Detection recommendations Message-ID: > I've been tasked by our company president to learn about, investigate and > recommend an intrusion detection system for our company. > > We're a smaller outfit, less than 100 employees, entirely Apple-based. > Macs, iPhones, some Mac Mini servers, etc., and a fiber connection to the > world. We are protected by a FreeBSD firewall setup, and we stay current > on updates/patches from Apple and FreeBSD, but that's as far as my > expertise goes. > > Initially, what do people recommend for: > > 1. Crash course in intrusion detection as a whole > 2. Suggestions or recommendations for intrusion detection hardware or > software > 3. Other things I'm likely overlooking if you were comfortable enough with freebsd to use it as a firewall, you can run your traffic through, or mirror it to, a freebsd box running https://www.bro.org/ or https://www.snort.org/ two quite reasonable and powerful open source systems randy From skeeve+nanog at eintellegonetworks.com Sat Feb 14 11:21:00 2015 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Sat, 14 Feb 2015 22:21:00 +1100 Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> Message-ID: My views are that if artistic endeavour is involved, then it is IP. Architecture is certainly that... the look... but, the pipes, sewerage, electricity, door locks... are not. They are products, bought of the shelf and assembled. It would be debatable if there is artistic endeavour in Network Architecture. Sure, there are clever approaches... such as Facebooks Fabric they released recently... https://code.facebook.com/posts/360346274145943/introducing-data-center-fabric-the-next-generation-facebook-data-center-network/ - is this something they could have claimed IP over? (I know they didn't, but COULD they have?). Personally, I don't think so. Sure some awesomely smart engineers designed this... but did they 'create' anything to do it? ...Skeeve *Skeeve Stevens - Founder & Chief Network Architect* eintellego Networks Pty Ltd Email: skeeve at eintellegonetworks.com ; Web: eintellegonetworks.com Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks ; Twitter: eintellego LinkedIn: /in/skeeve ; Expert360: Profile The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering On Sat, Feb 14, 2015 at 1:13 PM, Ahad Aboss wrote: > William, > > > > I beg to differ though this is getting slightly off topic. > > > > Art = something different, unexpected, not quite in your ordinary > experience yet related to your ordinary experience. > > Art is connected to what we experience every day but it represents some > kind of transformation of the everyday. Something that is not actually > entirely real, it can’t be found by locating it. It requires human > intervention, it’s the finger print if you will, of our existence in the > world that has its impact on things that we transform through the use of > imagination. > > > > How can architecture being an interaction of time, process, flow, people > and things be art? The answer is elegance. It inspires people to see things > in a new way and the interaction with people is the clearest point where > architecture becomes an art. > > > > Properly architected network not only need to work well now, they must > also provide a foundation for business and transform business, provide > boundaries for information and people, and yet enable collaboration. > > > > We are entering an age of agile service creation with virtualized IT > infrastructure, breaking down old constraints in many domains, including > the delivery of services. No need to dwell further in to this era of SDN > and NFV. > > > > To achieve all this, network designs must go beyond mechanical algorithms, > and even beyond the uncertain empirical, into the world of abstract > concept, mathematical theory, and raw power. > > > > Network architecture is not just about configuring routers, switches, > firewalls or load balancers. One must think beyond that. > > > > How does technology drive the business? > > What is the perception of the network within the organization? > > What is the perception of the technology stance beyond the organization? > > If competitors see your network design, will they wonder why they didn’t > think of it, or just wonder why it works at all? If a potential partner > sees your network design, will they see the future or the past? > > > > All these things contribute art to the world of network architecture. > > > > Here is a question for you; > > > > When you observe a beautifully architected building, what do you see? > > > > (Link to some examples) > http://www.azuremagazine.com/article/2014-top-10-architecture-projects/ > > > > Is it all about noticing the details, making observation about textures, > lines materials, shapes, proportions, light and shadow? > > > > Or do we agree that architects don't only deal with buildings - they think > of people, places, materials, philosophy and history, and only then > consider the actual building? > > > > Ahad > > > > -----Original Message----- > From: William Waites [mailto:wwaites at tardis.ed.ac.uk] > Sent: Friday, 13 February 2015 8:55 PM > To: ahad at telcoinabox.com > Cc: skeeve at eintellegonetworks.com; owen at delong.com; bill at herrin.us; > nanog at nanog.org > Subject: [OT] Re: Intellectual Property in Network Design > > > > On Fri, 13 Feb 2015 11:43:14 +1100, Ahad Aboss > said: > > > > > In a sense, you are an artist as network architecture > > > is an art in itself. It involves interaction with time, > > > processes, people and things or an intersection between all. > > > > This Friday's off-topic post for NANOG: > > > > Doing art is creative practice directed to uncover something new and not > pre-conceived. Successful acts of art produce something that not only > wasn't there before but that nobody thought could be there. The art is the > change in thinking that results. Whatever else is left over is residue. > > > > An engineer or architect in the usual setting, no matter how skilled, is > not doing art because the whole activity is pre-conceived. Even a clean and > elegant design is not usually intended to show beautiful connections > between ideas the same way poetry or mathematics might. Hiring an engineer > for this purpose almost never happens in industry. Rather the purpose is to > make a thing that does what it is intended to do. It is craft, or > second-order residue. Useful, possibly difficult, but not art. > > > > Some people want to claim ownership of a recipe for predictably creating > residue of a certain kind. An artist knows that this is not good for doing > art because nothing new can come from it. If they are committed to their > practice, they will not seek to prevent others from using an old recipe. > Why would they? They have already moved on. > > > > Some older thoughts on the topic: http://archive.groovy.net/syntac/ > From daniel.eckert at microsoft.com Fri Feb 13 22:08:21 2015 From: daniel.eckert at microsoft.com (Dan Eckert) Date: Fri, 13 Feb 2015 22:08:21 +0000 Subject: An Easy way to build a server cluster without top of rack switches (MEMO) In-Reply-To: References: Message-ID: I'm having a hard time seeing how this reduces cable costs or increases network durability. Each individual server is well connected to 3-4 other servers in the rack, but the rack still only has two uplinks. For many servers in the rack you're adding 3-4 routing hops between an end node and the rack uplink. Additionally, with only 2 external links tied to 2 specific nodes, you introduce more risks. If one of the uplink nodes fails, you've got to re-route all of the nodes that were using it as the shortest path to now exit through the other uplink node -- the worst case in the example then increases from the original 4-hops-to-exit to now 7-hops-to-exit. As far as cable costs go, you might have slightly shorter cables, but far more complex wiring pattern -- so in essence you're trading off a small amount of cable cost for a higher amount of installation and troubleshooting cost. Also, using this layout, you dramatically reduce the effective bandwidth available between devices, since per-device links now have to be used for backhaul/transport in addition to device-specific traffic. Finally, you have to manage per-server routing service configurations to make this work -- more points of failure and increased setup/troubleshooting cost. In a ToR switch scenario, you do one config on one switch, plug in the cables, and you're done -- problems happen, you go to the one switch, not chasing a needle through a haystack of interconnected servers. If your RU count is worth more than the combination of increased installation, server configuration, troubleshooting, latency, and capacity costs, then this is a good solution. Either way, it's a neat idea and a fun thought experiment to work through. Thanks! Dan -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of NAOTO MATSUMOTO Sent: Wednesday, February 11, 2015 11:32 PM To: nanog at nanog.org Subject: FYI: An Easy way to build a server cluster without top of rack switches (MEMO) Hi all! We wrote up TIPS memo "an easy way to build a server cluster without top of rack switches" concept. This model have a reduce switches and cables costs and high network durability by lightweight and simple configuration. if you interest in, please try to do yourself this concept ;-) An Easy way to build a server cluster without top of rack switches (MEMO) http://slidesha.re/1EduYXM Best regards, -- Naoto MATSUMOTO From harrison.hung at gmail.com Sat Feb 14 11:26:24 2015 From: harrison.hung at gmail.com (Harrison Hung) Date: Sat, 14 Feb 2015 19:26:24 +0800 Subject: Seeking Yahoo Network Engineer Message-ID: Hi NANOG. It was suggested I try this list to contact a Yahoo Network Engineer to help me with this problem I'm seeing. I have around 200-300 of my Yahoo hosting customers experiencing this issue where http requests to their websites are timing out. For the last week, I've been trying to reach out to Yahoo Hosting for last week regarding timeouts for http requests from multiple datacenters. Can a Yahoo Network engineer contact me to assist on diagnosing this issue off list? Thanks. My email is at harrison.hung at gmail.com Thanks a bunch. Or other suggestions are welcome as to how I can escalate this issue with Yahoo. Regards, Harrison From rsk at gsp.org Sat Feb 14 12:19:24 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 14 Feb 2015 07:19:24 -0500 Subject: Intrusion Detection recommendations In-Reply-To: References: <20150213212711.GA16425@gsp.org> Message-ID: <20150214121924.GA9898@gsp.org> On Fri, Feb 13, 2015 at 03:45:30PM -0600, Rafael Possamai wrote: > What is the alternative then... Does he have the time to become a BSD guru > and master ipfw and pf? Probably not feasible with all other job duties, > unless he locks himself in his mom's basement for the next 5 years. I know this will come a shock, but there are now a plethora of how-to's and tutorials and books and FAQs and examples for pf. Getting from zero to a first-order working configuration, especially for someone already familiar with FreeBSD (as in this case) should not entail more than a couple of days of reading and tinkering. And it's most definitely not necessary to become a BSD guru in order to run: pfctl -f /etc/pf.conf Obviously complex use cases will require more understanding, but that's a constant regardless of the platform. There's really no point-and-drool shortcut for actually understanding what your network's doing, why it's doing it, and how it's doing it in sufficient depth to figure out which parts of that are goodness and which are dubious -- worse. To quote Ranum, "How can you call yourself a 'Chief Technology Officer' if you have no idea what your technology is doing?" ---rsk From streiner at cluebyfour.org Sat Feb 14 09:28:10 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 14 Feb 2015 04:28:10 -0500 (EST) Subject: Intrusion Detection recommendations In-Reply-To: <20150213212711.GA16425@gsp.org> References: <20150213212711.GA16425@gsp.org> Message-ID: On Fri, 13 Feb 2015, Rich Kulawiec wrote: > On Fri, Feb 13, 2015 at 02:45:46PM -0600, Rafael Possamai wrote: >> I am a huge fan of FreeBSD, but for a medium/large business I'd definitely >> use a fairly well tested security appliance like Cisco's ASA. > > Closed-source software is faith-based security. The ASA, like so many network/security appliances anymore, runs Linux (or *BSD) under the hood, however I don't know how old or horribly mangled it is. jms From math at sizone.org Sat Feb 14 16:09:10 2015 From: math at sizone.org (Ken Chase) Date: Sat, 14 Feb 2015 11:09:10 -0500 Subject: An Easy way to build a server cluster without top of rack switches (MEMO) In-Reply-To: References: Message-ID: <20150214160910.GP3260@sizone.org> We did similar way back in the day (2001?) when GBE switches were ridiculously expensive and we wanted many nodes instead of expensive gear. The (deplorably hot!) NatSemi 83820 gbe cards were a mere $40 or something however. Uplink for loading data via NFS/control was the onboard FE (via desktop 8 port Surecoms), but 2x GBE was used for inter-node. GROMACS, a molecular modeller, only talked to adjacent nodes, so we just hooked up a linear network A-B-C-D-E-F-A in a loop. With 40 nodes though, some nodes had 3 cards in them however to effectively make two separate smaller cluster loops (A-B-C-A and D-E-F-D for eg) without having to visit the machine and move cards around. Perfectly reasonable where A talks to B and C or F only. A ridiculous concept for A talking to C however. Latency on the network was our big thing for GROMACS' speed of course, thus the GBE, so multihop would have been totally anathema. While our cluster ran about twice as slow per job (with no net gain in speed beyond 16-20 nodes due to latency catching up with us) as the way more pricey competing quote's infiniband-based solution, their total of 8 nodes were no match for us running 5 jobs in parallel on our 40 nodes for the same cost :) Considering the lab had multiple grad students in it, there was ample opportunity for running multiple jobs at the same time - while this may have thrashed the CPU cache (and increased our memory requirements slightly) in terms of pure compute efficiency, the end throughput per dollar and happiness-per-grad-student was far higher. Feel free to trawl the archives on beowulf-l ca. 2001-2 for more details of dirt cheap cluster design (or reply to me directly). Here's some pics of the cluster, but please keep in mind we were young and foolish. :) http://sizone.org/m/i/velocet/cluster_construction/133-3371_IMG.JPG.html /kc On Fri, Feb 13, 2015 at 10:08:21PM +0000, Dan Eckert said: >I'm having a hard time seeing how this reduces cable costs or increases network durability. Each individual server is well connected to 3-4 other servers in the rack, but the rack still only has two uplinks. For many servers in the rack you're adding 3-4 routing hops between an end node and the rack uplink. > >Additionally, with only 2 external links tied to 2 specific nodes, you introduce more risks. If one of the uplink nodes fails, you've got to re-route all of the nodes that were using it as the shortest path to now exit through the other uplink node -- the worst case in the example then increases from the original 4-hops-to-exit to now 7-hops-to-exit. > >As far as cable costs go, you might have slightly shorter cables, but far more complex wiring pattern -- so in essence you're trading off a small amount of cable cost for a higher amount of installation and troubleshooting cost. > >Also, using this layout, you dramatically reduce the effective bandwidth available between devices, since per-device links now have to be used for backhaul/transport in addition to device-specific traffic. > >Finally, you have to manage per-server routing service configurations to make this work -- more points of failure and increased setup/troubleshooting cost. In a ToR switch scenario, you do one config on one switch, plug in the cables, and you're done -- problems happen, you go to the one switch, not chasing a needle through a haystack of interconnected servers. > >If your RU count is worth more than the combination of increased installation, server configuration, troubleshooting, latency, and capacity costs, then this is a good solution. Either way, it's a neat idea and a fun thought experiment to work through. > >Thanks! >Dan > > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of NAOTO MATSUMOTO >Sent: Wednesday, February 11, 2015 11:32 PM >To: nanog at nanog.org >Subject: FYI: An Easy way to build a server cluster without top of rack switches (MEMO) > >Hi all! > >We wrote up TIPS memo "an easy way to build a server cluster without top of rack switches" concept. > >This model have a reduce switches and cables costs and high network durability by lightweight and simple configuration. > >if you interest in, please try to do yourself this concept ;-) > > >An Easy way to build a server cluster without top of rack switches (MEMO) http://slidesha.re/1EduYXM > > >Best regards, >-- >Naoto MATSUMOTO -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From rafael at gav.ufsc.br Sat Feb 14 18:09:29 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sat, 14 Feb 2015 12:09:29 -0600 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: Thanks for the awesome response, you have valid points. This could be me trying to simplify things by suggesting something like Cisco ASA, but the FreeBSD solution will need much more than just a well written ipfw or pf set of rules. In his scenario, I would also most likely need to setup VPN, CARP, etc, which requires decent amount of knowledge. If you use newer NICs, most likely will need to go with 10.0 or higher, which requires constant updates/patches since it's new release. On Sat, Feb 14, 2015 at 11:31 AM, BPNoC Group wrote: > On Fri, Feb 13, 2015 at 6:45 PM, Rafael Possamai > wrote: > >> I am a huge fan of FreeBSD, but for a medium/large business I'd definitely >> use a fairly well tested security appliance like Cisco's ASA. > > > Or maybe Juniper, Cisco's Ironport, IPSO? > > They are all FreeBSD based, big and large critical networks ready. > > FreeBSD's ipfw codebase exists for longer than most commercial products > you somehow believe to be more mature. So, FreeBSD's firewalling code at > least, as well tested as commercial vendors products. > > >> Depending on >> the traffic you have on your fiber uplink, you can get a redundant pair of >> ASAs running for less than $2,000 in the US. > > > For this traffic rate the best part on a commercial product is just > irrelevant: good specifics hardware. Whatever can be done with a USD 2K > Cisco based solution can be done on cheap low capacity x86 hardware with > FreeBSD. > > >> I just find it less stressful >> to use a solution like ASA rather than worrying about patching your kernel >> every so often and worrying about possible vulns in the ipfw/pf codes. >> > > One does not need to svn update, build kernel, build world if he does not > want to. It's just a matter of adding freebsd-update to crontab (or having > you own manual updating cycle in place). > > >> That, and you have to make sure EVERYTHING is taken into account when you >> create your rules, which requires some intense knowledge on either ipfw, >> pf >> or both. >> > > Another point I am completely inclined to disagree. > > My team is made up of junior level, trainees, to +20yr experience > professionals. > > There is absolutely no relevant learning curve for someone who has > configured a Cisco or Juniper firewall to a PF or IPFW firewall. If the > guys comes from a Linux background he finds ridiculously simple to have a > PF firewall up and running, after all for someone used to that weird > iptables syntax and semantics, a firewall where rules are linear and > natural syntax are a piece of cake. > > For new professionals, they quickly learn PF/IPFW better than Linux or > Fortigate which is another product we also have in place (heterogenous / > mixed team and technologies here). > > The tool is just the tool, it should a matter of what the tool can or can > not do, but not a matter on how to use it. Cisco ASA and PF are completely > different animals, sure, but learning 'em from scratch or coming from other > animals like Linux or Fortigate is straightforward. > > While products like fortigate have a nice GUI interface, it's just limited > and low productive. My team tendo to configura fortinet on CLI, and guess > what? Fortinet team are usually joked by BSD team when they see someone > using Fortinet cli. > > It just takes 5 times more to configure several "edit" blocks, creating > objects, putting it all together to have a simple firewall rule in the end, > when the BSD guys do a one line rule with macros and tables sorted all for > equivalent "object" advantages. Nobody cares for GUI in my team, but if a > fancy GUI is required they send pfSense screenshots for the Fortinet guys > just to keep the making fun... > > I strongly believe in the idea that open source has it's place and > commercial products have their place on different scenarios and > requirements. And in this scenario Mr Andy is asking about, IMO there's no > reason not to go with open source BSD. > > Specially because he seems already familiar with FreeBSD. > > I am not an expert in intrusion detection, so with regards to that, I'd >> just setup a honeypot and monitor activity. You can also regularly run >> penetration tests on your own network and see how well you are protected. >> Just make sure the appropriate people know about these tests so you don't >> get wrongfully reported. >> > > Not the same thing, same goal or same results. > > >> >> >> Rafael >> >> >> On Fri, Feb 13, 2015 at 11:40 AM, Andy Ringsmuth >> wrote: >> >> > NANOG'ers, >> > >> > I've been tasked by our company president to learn about, investigate >> and >> > recommend an intrusion detection system for our company. >> > >> > We're a smaller outfit, less than 100 employees, entirely Apple-based. >> > Macs, iPhones, some Mac Mini servers, etc., and a fiber connection to >> the >> > world. We are protected by a FreeBSD firewall setup, and we stay >> current on >> > updates/patches from Apple and FreeBSD, but that's as far as my >> expertise >> > goes. >> > >> > Initially, what do people recommend for: >> > >> > 1. Crash course in intrusion detection as a whole >> > 2. Suggestions or recommendations for intrusion detection hardware or >> > software >> > 3. Other things I'm likely overlooking >> > >> > Thank you all in advance for your wisdom. >> > >> > >> > ---- >> > 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 mpetach at netflight.com Sat Feb 14 18:11:14 2015 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 14 Feb 2015 10:11:14 -0800 Subject: Seeking Yahoo Network Engineer In-Reply-To: References: Message-ID: (placeholder, responded off-list) Matt On Sat, Feb 14, 2015 at 3:26 AM, Harrison Hung wrote: > Hi NANOG. > > It was suggested I try this list to contact a Yahoo Network Engineer to > help me with this problem I'm seeing. I have around 200-300 of my Yahoo > hosting customers experiencing this issue where http requests to their > websites are timing out. > > For the last week, I've been trying to reach out to Yahoo Hosting for last > week regarding timeouts for http requests from multiple datacenters. > > Can a Yahoo Network engineer contact me to assist on diagnosing this issue > off list? Thanks. My email is at harrison.hung at gmail.com > > Thanks a bunch. Or other suggestions are welcome as to how I can escalate > this issue with Yahoo. > > Regards, > > Harrison > > From joe at gonetforward.com Sat Feb 14 18:42:16 2015 From: joe at gonetforward.com (Joe Renwick) Date: Sat, 14 Feb 2015 10:42:16 -0800 Subject: Trouble with USA to France Connectivty Message-ID: Hello, I have a client who hosts a web facing service on the west coast of the United States. He has a number of customers in France who have been reporting connectivity issues starting about ten days ago. He has been hosting with us for a number of years and this appears to be the first time he has had these issues. Anyone else having similar issues? Thanks for the time, -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD Inc. Mobile: 619-972-7793 For Emergency Support Email "emergency at gonetforward.com" and the on call engineer will be paged. From mysidia at gmail.com Sat Feb 14 18:57:29 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 14 Feb 2015 12:57:29 -0600 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: On Sat, Feb 14, 2015 at 2:38 AM, Randy Bush wrote: Bro, SNORT, SGUIL, Tcpdump, and Wireshark are some nice tools. By itself, a single install of Snort/Bro is not necessarily a complete IDS, as it cannot inspect the contents of outgoing SSL sessions, so there can still be Javascript/attacks against the browser, or SQL injection attempts encapsulated in the encrypted tunnels; I am not aware of an open source tool to help you with SSH/SSL interception/SSL decryption for implementation of network-based IDS. You also need a hand-crafted rule for each threat that you want Snort to identify... Most likely this entails making decisions about what commercial ruleset(s) you want to use and then buying the appropriate subscriptions. > if you were comfortable enough with freebsd to use it as a firewall, you > can run your traffic through, or mirror it to, a freebsd box running > https://www.bro.org/ or > https://www.snort.org/ > two quite reasonable and powerful open source systems > > randy -- -JH From nicolas-ml at deffayet.com Sat Feb 14 19:38:15 2015 From: nicolas-ml at deffayet.com (Nicolas DEFFAYET) Date: Sat, 14 Feb 2015 20:38:15 +0100 Subject: Trouble with USA to France Connectivty In-Reply-To: References: Message-ID: <1423942695.16434.13.camel@fr-wks3.corp.novso.com> On Sat, 2015-02-14 at 10:42 -0800, Joe Renwick wrote: Hello Joe, > I have a client who hosts a web facing service on the west coast of the > United States. He has a number of customers in France who have been > reporting connectivity issues starting about ten days ago. He has been > hosting with us for a number of years and this appears to be the first time > he has had these issues. What's the networks on US side and on France side ? Thanks -- Nicolas DEFFAYET From charles at thefnf.org Sat Feb 14 20:03:05 2015 From: charles at thefnf.org (Charles N Wyble) Date: Sat, 14 Feb 2015 14:03:05 -0600 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: <1EB89900-1441-42A1-8D0E-147D051A6619@thefnf.org> Checkout security onion. Its got a pretty nice suite of tools and can run a (or many) dedicated sensor system and communicate back to a central system. As for SSL MITM, see the recent nanog thread for a full layer 2 to layer 8 ramifications of that activity. For ssh mitm, I don't know of any tools. I'm looking for one. On February 14, 2015 12:57:29 PM CST, Jimmy Hess wrote: >On Sat, Feb 14, 2015 at 2:38 AM, Randy Bush wrote: > >Bro, SNORT, SGUIL, Tcpdump, and Wireshark are some nice tools. > >By itself, a single install of Snort/Bro is not necessarily a complete >IDS, as it cannot inspect the contents of outgoing SSL sessions, so >there can still be Javascript/attacks against the browser, or SQL >injection attempts encapsulated in the encrypted tunnels; I am not >aware of an open source tool to help you with SSH/SSL interception/SSL >decryption for implementation of network-based IDS. > >You also need a hand-crafted rule for each threat that you want Snort >to identify... >Most likely this entails making decisions about what commercial >ruleset(s) you want to use and then buying the appropriate >subscriptions. > > >> if you were comfortable enough with freebsd to use it as a firewall, >you >> can run your traffic through, or mirror it to, a freebsd box running >> https://www.bro.org/ or >> https://www.snort.org/ >> two quite reasonable and powerful open source systems >> >> randy >-- >-JH > >!DSPAM:54df9aed198762108866735! -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From bpnoc.lists at gmail.com Sat Feb 14 17:31:04 2015 From: bpnoc.lists at gmail.com (BPNoC Group) Date: Sat, 14 Feb 2015 15:31:04 -0200 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: On Fri, Feb 13, 2015 at 6:45 PM, Rafael Possamai wrote: > I am a huge fan of FreeBSD, but for a medium/large business I'd definitely > use a fairly well tested security appliance like Cisco's ASA. Or maybe Juniper, Cisco's Ironport, IPSO? They are all FreeBSD based, big and large critical networks ready. FreeBSD's ipfw codebase exists for longer than most commercial products you somehow believe to be more mature. So, FreeBSD's firewalling code at least, as well tested as commercial vendors products. > Depending on > the traffic you have on your fiber uplink, you can get a redundant pair of > ASAs running for less than $2,000 in the US. For this traffic rate the best part on a commercial product is just irrelevant: good specifics hardware. Whatever can be done with a USD 2K Cisco based solution can be done on cheap low capacity x86 hardware with FreeBSD. > I just find it less stressful > to use a solution like ASA rather than worrying about patching your kernel > every so often and worrying about possible vulns in the ipfw/pf codes. > One does not need to svn update, build kernel, build world if he does not want to. It's just a matter of adding freebsd-update to crontab (or having you own manual updating cycle in place). > That, and you have to make sure EVERYTHING is taken into account when you > create your rules, which requires some intense knowledge on either ipfw, pf > or both. > Another point I am completely inclined to disagree. My team is made up of junior level, trainees, to +20yr experience professionals. There is absolutely no relevant learning curve for someone who has configured a Cisco or Juniper firewall to a PF or IPFW firewall. If the guys comes from a Linux background he finds ridiculously simple to have a PF firewall up and running, after all for someone used to that weird iptables syntax and semantics, a firewall where rules are linear and natural syntax are a piece of cake. For new professionals, they quickly learn PF/IPFW better than Linux or Fortigate which is another product we also have in place (heterogenous / mixed team and technologies here). The tool is just the tool, it should a matter of what the tool can or can not do, but not a matter on how to use it. Cisco ASA and PF are completely different animals, sure, but learning 'em from scratch or coming from other animals like Linux or Fortigate is straightforward. While products like fortigate have a nice GUI interface, it's just limited and low productive. My team tendo to configura fortinet on CLI, and guess what? Fortinet team are usually joked by BSD team when they see someone using Fortinet cli. It just takes 5 times more to configure several "edit" blocks, creating objects, putting it all together to have a simple firewall rule in the end, when the BSD guys do a one line rule with macros and tables sorted all for equivalent "object" advantages. Nobody cares for GUI in my team, but if a fancy GUI is required they send pfSense screenshots for the Fortinet guys just to keep the making fun... I strongly believe in the idea that open source has it's place and commercial products have their place on different scenarios and requirements. And in this scenario Mr Andy is asking about, IMO there's no reason not to go with open source BSD. Specially because he seems already familiar with FreeBSD. I am not an expert in intrusion detection, so with regards to that, I'd > just setup a honeypot and monitor activity. You can also regularly run > penetration tests on your own network and see how well you are protected. > Just make sure the appropriate people know about these tests so you don't > get wrongfully reported. > Not the same thing, same goal or same results. > > > Rafael > > > On Fri, Feb 13, 2015 at 11:40 AM, Andy Ringsmuth > wrote: > > > NANOG'ers, > > > > I've been tasked by our company president to learn about, investigate and > > recommend an intrusion detection system for our company. > > > > We're a smaller outfit, less than 100 employees, entirely Apple-based. > > Macs, iPhones, some Mac Mini servers, etc., and a fiber connection to the > > world. We are protected by a FreeBSD firewall setup, and we stay current > on > > updates/patches from Apple and FreeBSD, but that's as far as my expertise > > goes. > > > > Initially, what do people recommend for: > > > > 1. Crash course in intrusion detection as a whole > > 2. Suggestions or recommendations for intrusion detection hardware or > > software > > 3. Other things I'm likely overlooking > > > > Thank you all in advance for your wisdom. > > > > > > ---- > > 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 bpnoc.lists at gmail.com Sat Feb 14 18:04:24 2015 From: bpnoc.lists at gmail.com (BPNoC Group) Date: Sat, 14 Feb 2015 16:04:24 -0200 Subject: Intrusion Detection recommendations In-Reply-To: <20150214121924.GA9898@gsp.org> References: <20150213212711.GA16425@gsp.org> <20150214121924.GA9898@gsp.org> Message-ID: On Sat, Feb 14, 2015 at 10:19 AM, Rich Kulawiec wrote: > On Fri, Feb 13, 2015 at 03:45:30PM -0600, Rafael Possamai wrote: > > What is the alternative then... Does he have the time to become a BSD > guru > > and master ipfw and pf? Probably not feasible with all other job duties, > > unless he locks himself in his mom's basement for the next 5 years. > Are we really talking "ipfw add deny udp from any to any 123 not in via $lan" where? Or are we talking "iptables -A INPUT -s 0/0 -p udp -m udp --dport 123 -j DROP"? Or maybe we are talking "config firewall local-in-policy \n edit #id \n set intf ifacename\n set srcaddr any\n set dstaddr any\n set service previosly_configured_object\n set action deny\n next\n end\n" ? Nobody needs to lock himself down on a basement to learn PF or IPFW. While this might not be true for other firewalling systems, it can't be easier than it's on BSD. All it takes is proper networking skills. The tool is just simple to do what you want to do if you know how you want it (TCP/IP skills, not PF skills required). I know this will come a shock, but there are now a plethora of how-to's > and tutorials and books and FAQs and examples for pf. Getting from zero > to a first-order working configuration, especially for someone already > familiar with FreeBSD (as in this case) should not entail more than a > couple of days of reading and tinkering. And it's most definitely not > necessary to become a BSD guru in order to run: > Not to mention PF's documentation, IPFW documentation and Handbook chapter... > > pfctl -f /etc/pf.conf > > Obviously complex use cases will require more understanding, but that's a > constant regardless of the platform. Agree, networking skills are required, not PF/IPFW skills as they are easy and well documented tools. Easier and more performing than most other firewalling tools and options, or as easy as other easy ones like Cisco ASA. But back to Andy's original point: As someone else mentioned before, I dropped Snort in favor of Suricata + Bro, and they are the tools I would also suggest. Do it FreeBSD + Suricata and/or Bro. And remember, IDS is not a service you set up and forget. The most important point is to learn how to do proper analysis on what you are seeing and understand volumetric vs unusual single attacks, inspect payload, L7 content and have a daily analysis cycle if you can't have dedicated personnel to do that continuosly. This is not different if you go how brew open source, "packed ready" opensource (pfSense) or proprietary / commercial. I also agree with someone who suggested Bejlich's SIEM (NSM) book, and I would recommend Shon Harrys, Miller et. al SIEM book as well! Regards, From rsk at gsp.org Sat Feb 14 22:29:05 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 14 Feb 2015 17:29:05 -0500 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: <20150214222905.GA12330@gsp.org> On Sat, Feb 14, 2015 at 12:57:29PM -0600, Jimmy Hess wrote: > By itself, a single install of Snort/Bro is not necessarily a complete > IDS, as it cannot inspect the contents of outgoing SSL sessions, so > there can still be Javascript/attacks against the browser, or SQL > injection attempts encapsulated in the encrypted tunnels; [...] This reminds me to bring up a point that can't be stressed enough: it's just as important to block *outbound* traffic as inbound. Ask Anthem. Or Target. Or the ghosts of the Trojans. ;) If you have subsets of systems that have no need to make an outbound connection, ever, then don't let them. "block all log" is not only your friend here, but it's your instant IDS, because if those systems aren't supposed to be sending outbound traffic, and so much as a single packet turns up in the logs, then something is going on that you'd very much like to find out about. [1] If you can't block all traffic, fine, block all and then permit the 5-tuple {source, dest, source port, dest port, proto} that is required to allow the necessary functionality. And again, *anything* else is a sign of a problem. And if you can't block all traffic *everywhere*, then at least block everywhere you can. Start with the Spamhaus DROP and EDROP lists (actually: block these directionally): http://www.spamhaus.org/drop And then, if you can, use these: http://okean.com/asianspamblocks.html And then, if you can, use these: http://ipdeny.com/ For example: you have an internal database server. Every night, some cron job kicks off and builds an exportable subset of that data, which is then rsync'd to a production web server somewhere. So that internal database server only needs to reach 1 host on 1 port with 1 protocol. Block all, then just allow that. Another example: you sell stuff, but only in the US and Canada. Why would you allow traffic from Ukraine or Paraguay or Syria to reach your ecommerce web server? There is no positive outcome for you in letting that happen. So don't. Use ipdeny.com, allow the US and CA, block the world. (YES, you can still be attacked from those networks, and YES your IDS/IPS will light up like a Xmas tree when you are, but at least you won't have to wade through page after page of logs about attacks from Taiwan...because you dropped their packets on the floor.) Default-deny is your best friend and should be the first rule in every firewall everywhere. It's defense-by-default. Default permit is like allowing everyone into the bank vault and then walking through the crowd trying to decide who to kick out. So anywhere you possibly can, block everything and then only allow traffic that's necessary to accomplish the task(s) at hand. I don't know if this approach would have saved Anthem or Target or any of the rest. Maybe. Maybe not. But (a) it may save the next one and (b) it has a fighting chance of causing intrusions to make enough noise in the logs that someone will notice and say "That's funny..." before the roof caves in and Krebs has to write a blog entry about it. ---rsk [1] But how will those systems do software updates? From your local mirror, which is the only system that can reach out to one of the "real" mirrors. From mpetach at netflight.com Sun Feb 15 00:13:25 2015 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 14 Feb 2015 16:13:25 -0800 Subject: Intrusion Detection recommendations In-Reply-To: <20150213204300.GA4104@e-fensive.net> References: <5D34E0CB-A7E9-4092-87E6-E71ECBB1B55C@beckman.org> <20150213204300.GA4104@e-fensive.net> Message-ID: On Fri, Feb 13, 2015 at 12:43 PM, J. Oquendo wrote: [...] > For the most part > though, this practice of half-baked security will continue, > vendors will make bucketloads of money, consumers of IPS/IDS > devices will still complain how much the product sucks, and > I as a pentester... I stay happy as it keeps me steadily > enjoying Five Guys' burgers > Seriously? Five Guys? Man, In-n-Out is *so* much better than Five Guys...that has*got* to be a troll posting, just to get people like me out of the woodwork... From aaron at heyaaron.com Sun Feb 15 00:14:48 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Sat, 14 Feb 2015 16:14:48 -0800 Subject: Vancouver WA Comcast Outage? In-Reply-To: References: Message-ID: Things have been running well for us since about an hour after things came back up. -A On Fri, Feb 13, 2015 at 10:55 AM, Warsaw LATAM Operations Group wrote: > > >> From: aaron at heyaaron.com >> Date: Thu, 12 Feb 2015 14:13:56 -0800 >> Subject: Vancouver WA Comcast Outage? >> To: nanog at nanog.org >> >> We just lost a handful of customers in Vancouver WA on Comcast. >> Voice and data are out. >> >> Initial reports are saying a transformer blew down town. > > Service still degraded for you? > > Today it's me with long duration partial outage and very poor connectivity > trying to reach Portland via Vancouver hop, on Comcast network. Still no > relevant response for my open ticket from their party. > > From mysidia at gmail.com Sun Feb 15 00:19:20 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 14 Feb 2015 18:19:20 -0600 Subject: Intrusion Detection recommendations In-Reply-To: References: <20150213212711.GA16425@gsp.org> <20150214121924.GA9898@gsp.org> Message-ID: On Sat, Feb 14, 2015 at 12:04 PM, BPNoC Group wrote: The thing to note about ipfw, is it only provides you with essentially 5-tuple based access lists based on source and destination, as this functions strictly by looking at packet headers. There's no ipfw rule you can make that will tell ipfw to Allow outgoing port 80 connections, but only if the protocol is HTTP. Don't allow outgoing SMTP or SSH connections over port 80. Often.... for a network with endpoints, almost everything outbound you want to allow will be going out on port 80 or 443, And almost everything outbound you need to reject will also be going out on port 80 or 443. If the syntax is a challenge for you at all, there are tools such as fwbuilder, or PfSense appliance with web GUI that can be used to construct the configuration.. The sticking point with pf, or iptables, or whatever you use should not be the syntax or the command language. But the question of *what* to allow, and how to appropriately structure that choice/requirement of what to allow in order to ensure the applications work correctly and minimize the exposure. This is not strictly a matter of coming up with rules or language syntax, but if done right includes analysis and reconfiguration of applications in order to ensure that legitimate traffic is as predictable and well-understood as possible. For example... Since 80 and 443 are such trouble, you might structure the "allow" by setting up a suitable proxy server on LAN, require all clients to use it, and on the ipfw device it is strictly a "Deny all". > Are we really talking "ipfw add deny udp from any to any 123 not in via > $lan" where? > > Or are we talking "iptables -A INPUT -s 0/0 -p udp -m udp --dport 123 -j > DROP"? -- -JH From Valdis.Kletnieks at vt.edu Sun Feb 15 01:11:18 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 14 Feb 2015 20:11:18 -0500 Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: Your message of "Sat, 14 Feb 2015 22:21:00 +1100." References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> Message-ID: <81790.1423962678@turing-police.cc.vt.edu> On Sat, 14 Feb 2015 22:21:00 +1100, Skeeve Stevens said: > Personally, I don't think so. Sure some awesomely smart engineers designed > this... but did they 'create' anything to do it? I already cited legislative history that indicates that even things like phone directories are suitable for copyright protection. That "creation" bar is pretty darned low. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From randy at psg.com Sun Feb 15 01:32:08 2015 From: randy at psg.com (Randy Bush) Date: Sun, 15 Feb 2015 10:32:08 +0900 Subject: Trouble with USA to France Connectivty In-Reply-To: References: Message-ID: > I have a client who hosts a web facing service on the west coast of > the United States. He has a number of customers in France who have > been reporting connectivity issues starting about ten days ago. He has > been hosting with us for a number of years and this appears to be the > first time he has had these issues. as you have given no actual technical data, my guess is was a bad baguette; a real tragedy. randy From bill at herrin.us Sun Feb 15 02:15:42 2015 From: bill at herrin.us (William Herrin) Date: Sat, 14 Feb 2015 21:15:42 -0500 Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> Message-ID: On Fri, Feb 13, 2015 at 10:26 PM, Skeeve Stevens < skeeve at eintellegonetworks.com> wrote: > My views are that if artistic endeavour is involved, then it is IP. > Architecture is certainly that... the look... but, the pipes, sewerage, > electricity, door locks... are not. They are products, bought of the shelf > and assembled. > Hi Skeeve, I think I see where you're getting hung up. The whole thing is intellectual property (IP). Including all of the parts. The pipes, the wires, the locks, all of it. But that doesn't necessarily mean that each part is protectable independent of the rest. Copyright law basically says that if there is any substantive creative input into a work's creation then the work is not only copyrightable, unless the author explicitly says different it's also copyrighted. Throw a paint filled balloon at a canvas and the resulting splatter is copyrighted. Consider: do more unforced choices, more optional choices, more creative choices go in to the production of a router configuration? Of course they do. One can be snobbish about whether that qualifies as art, but it's certainly intellectual property (IP). The catch here is that independent creation is proof against copyright violation. So if there really are only three ways to configure something, you will never successfully enforce the fact that your configuration used one of them. Just because your router configuration is copyrighted doesn't mean someone else can't create exactly the same configuration. And their version will carry a full copyright too. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From owen at delong.com Sun Feb 15 05:49:20 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 14 Feb 2015 21:49:20 -0800 Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> Message-ID: > Copyright law basically says that if there is any substantive creative input into a work's creation then the work is not only copyrightable, unless the author explicitly says different it's also copyrighted. Throw a paint filled balloon at a canvas and the resulting splatter is copyrighted. Consider: do more unforced choices, more optional choices, more creative choices go in to the production of a router configuration? Of course they do. > > One can be snobbish about whether that qualifies as art, but it's certainly intellectual property (IP). This assumes that Copyright is the only IP protection out there. There are actually two distinct realms of IP protection afforded in the US. Most other nations have a similar division. Copyright is for works of original creation, but cannot cover a process, practice, or device. Patents, on the other hand, cover processes, practices, and devices, etc. On a theoretical level, a network design and/or it’s documentation, configuration files, etc. could be and likely are copyright(-able,-ed). On a theoretical level, if you come up with some truly novel non-obvious reduction to practice of some particular process, you might well be able to patent it. While independent creation is a defense for copyright, it is irrelevant to a patent. Prior art can be a valid defense for a patent, but independently arriving at the same conclusion from independent development is not, in itself, a valid defense. (Showing that the patent is obvious, a minimal evolutionary step, or other such trivialization can be a valid defense.) However, all of the technicalities on this stuff vary from jurisdiction to jurisdiction. The broad strokes have been normalized through treaties for the most part, but details and technicalities still vary quite a bit. As such, if it really matters, get good local legal advice from all involved countries. Owen From bill at herrin.us Sun Feb 15 14:57:38 2015 From: bill at herrin.us (William Herrin) Date: Sun, 15 Feb 2015 09:57:38 -0500 Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> Message-ID: On Sun, Feb 15, 2015 at 12:49 AM, Owen DeLong wrote: > This assumes that Copyright is the only IP protection out there. There > are actually two distinct realms of IP protection afforded in the US. Actually, there are four: copyright, patent, trademark and trade secret. A network configuration could fall under either copyright or trade secret. It won't fall under trademark and it's hard to imagine how a network configuration of a general shape anticipated by the router manufacturer could fall under patent. Not with the double-whammy of prior art and the recent rulings to the effect that adding "on a computer" to a technique is insufficient to make it patentable. > However, all of the technicalities on this stuff vary from jurisdiction to jurisdiction. > The broad strokes have been normalized through treaties for the most part, but > details and technicalities still vary quite a bit. There are only so many jurisdictions with distinct law in North America. You know, this being NANOG and all. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jbates at paradoxnetworks.net Sun Feb 15 15:53:46 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Sun, 15 Feb 2015 09:53:46 -0600 Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> Message-ID: <54E0C10A.2020606@paradoxnetworks.net> On 2/15/2015 8:57 AM, William Herrin wrote: > On Sun, Feb 15, 2015 at 12:49 AM, Owen DeLong wrote: >> This assumes that Copyright is the only IP protection out there. There >> are actually two distinct realms of IP protection afforded in the US. > Actually, there are four: copyright, patent, trademark and trade > secret. A network configuration could fall under either copyright or > trade secret. It won't fall under trademark and it's hard to imagine > how a network configuration of a general shape anticipated by the > router manufacturer could fall under patent. Not with the > double-whammy of prior art and the recent rulings to the effect that > adding "on a computer" to a technique is insufficient to make it > patentable. > > I also believe it is important to note that only certain pieces retain protection. Uniquely entered data forms the basis, which protects the whole. Retaining a full copy of the config or even portions of the config which contain unique data would be a violation. This not only applies to IP Addresses entered, but also applies to routing policies. As you exceed the basics of a policy(qualified as trivial, anyone would draw that single circle with a compass), you enter into the realm of artistry. It is not that another config cannot do something similar, it just can't do it word for word. Changing the identifiers in the policies is probably not enough if you have a 50+ line policy that doesn't have prior art. Most engineers know when they've crossed the line from trivial/mundane into creative. It tends to be linked to our pride. One thing to be careful of and definitely to seek a lawyer's advice on is the "transference of IP". This is because it can be retroactive. If you've created a set of policies that you use normally with clients that do not retain IP, then a transference of IP could take your rights away. You lose the prior art because you were the artist and you've given your rights to that art to someone else (which is one reason some companies want IP; legal protection). One way around this, most likely, is to establish your art as public domain (allowing you continued use of the foundation work, while losing the more specific details associated with that one project). By doing so, you may be able to protect the art itself. A lawyer would know best, of course. Jack From colin.bodor at imperium.ca Sat Feb 14 22:55:41 2015 From: colin.bodor at imperium.ca (Colin Bodor) Date: Sat, 14 Feb 2015 22:55:41 +0000 Subject: Intrusion Detection recommendations References: <20150214222905.GA12330@gsp.org> Message-ID: Hello, I don't mean to hijack this thread, but I suppose its related -- I didn't know spamhaus could provide a BGP feed of "bad" prefixes like that (for a price it seems). Is anyone aware of other "free" providers of such naughty prefixes via BGP? I know Team Cymru has a bogon list that you can get via BGP session, just not aware of any others and these seem like a pretty good idea to have setup on your core. Thanks -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rich Kulawiec Sent: Saturday, February 14, 2015 3:29 PM To: nanog at nanog.org Subject: Re: Intrusion Detection recommendations On Sat, Feb 14, 2015 at 12:57:29PM -0600, Jimmy Hess wrote: > By itself, a single install of Snort/Bro is not necessarily a complete > IDS, as it cannot inspect the contents of outgoing SSL sessions, so > there can still be Javascript/attacks against the browser, or SQL > injection attempts encapsulated in the encrypted tunnels; [...] This reminds me to bring up a point that can't be stressed enough: it's just as important to block *outbound* traffic as inbound. Ask Anthem. Or Target. Or the ghosts of the Trojans. ;) If you have subsets of systems that have no need to make an outbound connection, ever, then don't let them. "block all log" is not only your friend here, but it's your instant IDS, because if those systems aren't supposed to be sending outbound traffic, and so much as a single packet turns up in the logs, then something is going on that you'd very much like to find out about. [1] If you can't block all traffic, fine, block all and then permit the 5-tuple {source, dest, source port, dest port, proto} that is required to allow the necessary functionality. And again, *anything* else is a sign of a problem. And if you can't block all traffic *everywhere*, then at least block everywhere you can. Start with the Spamhaus DROP and EDROP lists (actually: block these directionally): http://www.spamhaus.org/drop And then, if you can, use these: http://okean.com/asianspamblocks.html And then, if you can, use these: http://ipdeny.com/ For example: you have an internal database server. Every night, some cron job kicks off and builds an exportable subset of that data, which is then rsync'd to a production web server somewhere. So that internal database server only needs to reach 1 host on 1 port with 1 protocol. Block all, then just allow that. Another example: you sell stuff, but only in the US and Canada. Why would you allow traffic from Ukraine or Paraguay or Syria to reach your ecommerce web server? There is no positive outcome for you in letting that happen. So don't. Use ipdeny.com, allow the US and CA, block the world. (YES, you can still be attacked from those networks, and YES your IDS/IPS will light up like a Xmas tree when you are, but at least you won't have to wade through page after page of logs about attacks from Taiwan...because you dropped their packets on the floor.) Default-deny is your best friend and should be the first rule in every firewall everywhere. It's defense-by-default. Default permit is like allowing everyone into the bank vault and then walking through the crowd trying to decide who to kick out. So anywhere you possibly can, block everything and then only allow traffic that's necessary to accomplish the task(s) at hand. I don't know if this approach would have saved Anthem or Target or any of the rest. Maybe. Maybe not. But (a) it may save the next one and (b) it has a fighting chance of causing intrusions to make enough noise in the logs that someone will notice and say "That's funny..." before the roof caves in and Krebs has to write a blog entry about it. ---rsk [1] But how will those systems do software updates? From your local mirror, which is the only system that can reach out to one of the "real" mirrors. From gerard at shelbybb.com Sun Feb 15 04:03:42 2015 From: gerard at shelbybb.com (Gerard Dupont III) Date: Sat, 14 Feb 2015 23:03:42 -0500 Subject: FTTx Active-Ethernet Hardware In-Reply-To: <20150211095547.GF2726@belenos> References: <15020604.4147.1423575243412.JavaMail.mhammett@ThunderFuck> <20150211095547.GF2726@belenos> Message-ID: We have several of them in service for almost 18 months now. Overall I'm happy with them, but I have had some minor issues. I had an issue where DHCP Option 82 information was incorrect and support had a new firmware fix within 72 hours. When trying to access the oldest events in the detailed system log after months of uptime will cause the switch to reboot. I have an issue where SFP's won't fully power up or turn on when inserted. Move the SFP to a different port and it will work fine. OR if you leave it in the non working port and power cycle the switch it will then work fine. May just be an incompatibility with the cheap fiberstore SFPs. Other than that I can't think of anything else. We're not doing anything fancy on them. Just single vlan per port. Gerard On Wed, Feb 11, 2015 at 4:55 AM, Denis Fondras wrote: > Hi, > > > Price and functionality-wise Planet MGSW-28240F and GSD-1020S look > > pretty close to what I'm looking for. Anyone have real experience > > with using them on a large scale? Performance? > > > > Thank you for the pointer to MGSW-28240F. I am also curious to hear some > feedback as the gear is awfully low-priced :) > > Denis > From davewaters1970 at gmail.com Sun Feb 15 16:04:57 2015 From: davewaters1970 at gmail.com (Dave Waters) Date: Sun, 15 Feb 2015 21:34:57 +0530 Subject: Interesting BFD discussion on reddit Message-ID: http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple_way_to_secure_bfd/ Authentication mechanisms defined for IGPs cannot be used to protect BFD since the rate at which packets are processed in BFD is very high. Dave From colin.bodor at imperium.ca Sun Feb 15 20:04:20 2015 From: colin.bodor at imperium.ca (Colin Bodor) Date: Sun, 15 Feb 2015 20:04:20 +0000 Subject: PCH INOC DBA Message-ID: Is this still in use? I am trying to setup an account but the account creation process seems broken. I may be late to the party but it looks like a really cool idea assuming people still use it and its active. From saku at ytti.fi Sun Feb 15 22:25:40 2015 From: saku at ytti.fi (Saku Ytti) Date: Mon, 16 Feb 2015 00:25:40 +0200 Subject: Interesting BFD discussion on reddit In-Reply-To: References: Message-ID: <20150215222540.GA15215@pob.ytti.fi> On (2015-02-15 21:34 +0530), Dave Waters wrote: Hey, > http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple_way_to_secure_bfd/ > > Authentication mechanisms defined for IGPs cannot be used to protect BFD > since the rate at which packets are processed in BFD is very high. Not sure I understand the draft[0] correctly, but I suppose it only protects you from forced state-change attack. Attacker can't force you to go from up=>down or down=>up, but attacker could force routers to keep BFD state? I wonder if Trio, EZChip and friends could do SHA in NPU, my guess is yes they could, but perhaps there is even more appropriate hash for this use-case. I'm not entirely convinced doing hash for each BFD packet is impractical. [0] http://www.ietf.org/id/draft-mahesh-bfd-authentication-00.txt -- ++ytti From Valdis.Kletnieks at vt.edu Sun Feb 15 22:34:51 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 15 Feb 2015 17:34:51 -0500 Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: Your message of "Sun, 15 Feb 2015 09:53:46 -0600." <54E0C10A.2020606@paradoxnetworks.net> References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> <54E0C10A.2020606@paradoxnetworks.net> Message-ID: <48665.1424039691@turing-police.cc.vt.edu> On Sun, 15 Feb 2015 09:53:46 -0600, Jack Bates said: > want IP; legal protection). One way around this, most likely, is to > establish your art as public domain (allowing you continued use of the > foundation work, while losing the more specific details associated with > that one project). By doing so, you may be able to protect the art > itself. A lawyer would know best, of course. Actually, doesn't even take a laweyer. "Public domain" has a very specific meaning, and is probably *not* what you want in this case. It basically means "I disavow ownership and all rights to this, and anybody can take this and do whatever they want with it, including making money off it". Most importantly, you can't even waive liability - this is why stuff like the MIT X11 or similar licenses got created - you need to keep your rights in order to attach a "by taking this, you promise not to sue me to my skivvies".clause. If you put it in the public domain, somebody can take it, change it, use it, make a ton of money off it, and then *still* sue you to your skivvies if it malfunctions (say, their network breaks because you didn't include any anti-DDoS support, but you could have, and they get hit with one). Now here's were you want to double-check with a lawyer. Make your base code a Creative Commons BY-NC-ND license - people can make copies of it, but can't make derivative works (in other words, they can't make changes to fit their environment) or use it for commercial purposes (which is a game stopper if you're trying to make money off it). You still have all rights, so you can then negotiate the rights to the difference between your base and the particular client's install, That may still be non-optimal for your use, because everybdoy can make a copoy - but if you were OK with public domain, that's probably not a show-stopper here. Would be if you wanted to keep trade secrecy status on your base (so consult a good IP lawyer ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From woody at pch.net Sun Feb 15 22:49:39 2015 From: woody at pch.net (Bill Woodcock) Date: Sun, 15 Feb 2015 14:49:39 -0800 Subject: PCH INOC DBA In-Reply-To: References: Message-ID: > On Feb 15, 2015, at 12:04 PM, Colin Bodor wrote: > Is this still in use? I am trying to setup an account but the account creation process seems broken. I may be late to the party but it looks like a really cool idea assuming people still use it and its active. It’s still in very active use, however the new-account setup front-end is in perl, and something has broken it. Rather than try to beat it back into shape, we’ve been focusing on completing our already-started transition from SER to BE6K on the back-end, which has an associated new front-end provisioning system, that’s largely overlapping with our regular PCH user-account system. INOC-DBA has only been sporadically funded by our donors, so it’s currently only got two FTE assigned to it, when it really should be closer to four. So, short story is that it’s working for the people who have been using it all along, but it’s broken for anyone who hadn’t already completed the setup process before the old perl provisioning system went to hell in a handbasket. We’re covering all its costs out of overhead right now, so there’s not enough funding to be actively working on both the old system and the new one, so we’re focusing on the new one, and trying to get it into production as quickly as possible. If you’d like to get an account started, you can use our regular PCH user-account system to start an account, and the next-gen INOC-DBA provisioning will let you add on all of the SIP and jabber information as soon as it’s in production. https://pch.net/account In any event, our apologies to everyone. I’ve cc’d Ashwin Mathew, who’s the INOC-DBA manager, so anyone with specific questions, or who’s able to help out with the project, can contact him directly. -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 woody at pch.net Sun Feb 15 22:52:10 2015 From: woody at pch.net (Bill Woodcock) Date: Sun, 15 Feb 2015 14:52:10 -0800 Subject: PCH INOC DBA In-Reply-To: References: Message-ID: <0D113DF6-6D9D-4C9D-88C7-1F049C0C5DE9@pch.net> > On Feb 15, 2015, at 2:49 PM, Bill Woodcock wrote: > We’ve been focusing on completing our already-started transition from SER to BE6K on the back-end Sorry, prototyping in BE6K, production will be BE7K. -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 larrysheldon at cox.net Mon Feb 16 02:37:40 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Sun, 15 Feb 2015 20:37:40 -0600 Subject: [OT] Re: Intellectual Property in Network Design In-Reply-To: References: <8D91E690-6CD5-4908-9717-42FB7578482D@delong.com> <6c779d004606ac07f09fb8747a3d5ff0@mail.gmail.com> <20150213.095525.589467744425988438.wwaites@tardis.ed.ac.uk> Message-ID: <54E157F4.7060800@cox.net> On 2/15/2015 09:53, Jack Bates wrote: > Most engineers know when they've crossed the line from trivial/mundane > into creative. It tends to be linked to our pride. I wish it did not so often be driven by the thought that this may be an opportunity to game the system for personal gain. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From naoto.mm at gmail.com Mon Feb 16 03:23:41 2015 From: naoto.mm at gmail.com (NAOTO MATSUMOTO) Date: Mon, 16 Feb 2015 12:23:41 +0900 Subject: An Easy way to build a server cluster without top of rack switches (MEMO) In-Reply-To: References: Message-ID: Hi Dan and ken. I respect your great works. Certainly, our scenario was network classics and it just does not "one size fits all" network architecture. Many people tried to built centralized and decentralized networks many years ago, some guys output implementation like this. Interconnect of K computer (torus fusion) https://www.fujitsu.com/global/Images/fujitsu-hpc-roadmap-beyond-petascale-computing.pdf I agree with you point. Our approach have to do more simple way on physical and logical network engineering, and change the mindset, I think. (e.g. network cabling procedure and troubleshooting and handling) But, some guys need more cost effective server cluster environment and they does't care network latency like Low-End Web Hosting. e.g. Intel Diversity of Server workloads http://bit.ly/1BgFH65 [JPG]. Now, Many people do not use Dijkstra and automaton theory on the server side, but it is great mechanism for network durability if they controlled. The Ethernet NIC's bandwidth is increasing day by day, the cost is decreasing too. I say again, our scenario is not "one size fits all" network architecture, but we believe that something will happen for some guys works. ;-) best regards, -- Naoto MATSUMOTO On Sat, Feb 14, 2015 at 7:08 AM, Dan Eckert wrote: > I'm having a hard time seeing how this reduces cable costs or increases > network durability. Each individual server is well connected to 3-4 other > servers in the rack, but the rack still only has two uplinks. For many > servers in the rack you're adding 3-4 routing hops between an end node and > the rack uplink. > > Additionally, with only 2 external links tied to 2 specific nodes, you > introduce more risks. If one of the uplink nodes fails, you've got to > re-route all of the nodes that were using it as the shortest path to now > exit through the other uplink node -- the worst case in the example then > increases from the original 4-hops-to-exit to now 7-hops-to-exit. > > As far as cable costs go, you might have slightly shorter cables, but far > more complex wiring pattern -- so in essence you're trading off a small > amount of cable cost for a higher amount of installation and > troubleshooting cost. > > Also, using this layout, you dramatically reduce the effective bandwidth > available between devices, since per-device links now have to be used for > backhaul/transport in addition to device-specific traffic. > > Finally, you have to manage per-server routing service configurations to > make this work -- more points of failure and increased > setup/troubleshooting cost. In a ToR switch scenario, you do one config on > one switch, plug in the cables, and you're done -- problems happen, you go > to the one switch, not chasing a needle through a haystack of > interconnected servers. > > If your RU count is worth more than the combination of increased > installation, server configuration, troubleshooting, latency, and capacity > costs, then this is a good solution. Either way, it's a neat idea and a > fun thought experiment to work through. > > Thanks! > Dan > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of NAOTO MATSUMOTO > Sent: Wednesday, February 11, 2015 11:32 PM > To: nanog at nanog.org > Subject: FYI: An Easy way to build a server cluster without top of rack > switches (MEMO) > > Hi all! > > We wrote up TIPS memo "an easy way to build a server cluster without top > of rack switches" concept. > > This model have a reduce switches and cables costs and high network > durability by lightweight and simple configuration. > > if you interest in, please try to do yourself this concept ;-) > > > An Easy way to build a server cluster without top of rack switches (MEMO) > http://slidesha.re/1EduYXM > > > Best regards, > -- > Naoto MATSUMOTO > From glen.kent at gmail.com Mon Feb 16 03:25:17 2015 From: glen.kent at gmail.com (Glen Kent) Date: Mon, 16 Feb 2015 08:55:17 +0530 Subject: Interesting BFD discussion on reddit In-Reply-To: <20150215222540.GA15215@pob.ytti.fi> References: <20150215222540.GA15215@pob.ytti.fi> Message-ID: > > > > I wonder if Trio, EZChip and friends could do SHA in NPU, my guess is yes > they > could, but perhaps there is even more appropriate hash for this use-case. > I'm not entirely convinced doing hash for each BFD packet is impractical. > > [0] http://www.ietf.org/id/draft-mahesh-bfd-authentication-00.txt You might want to take a look at: http://www.ietf.org/proceedings/89/slides/slides-89-mpls-9.pdf Look at the slides 11 onwards. Doing HMAC calculation for each packet adversely affects the number of concurrent sessions that can be supported. Glen. > > -- > ++ytti > From frnkblk at iname.com Mon Feb 16 03:38:36 2015 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 15 Feb 2015 21:38:36 -0600 Subject: FW: HTTPv6 access to www.centurylink.com and www.qwest.com are down In-Reply-To: <8B9D122A1836AF4BB23B7966A4EABEC20AD4E774@pcscmail001.MUTUALTEL.MTCNET.NET> References: <8B9D122A1836AF4BB23B7966A4EABEC20AD4E774@pcscmail001.MUTUALTEL.MTCNET.NET> Message-ID: <001601d0499a$0c1eca00$245c5e00$@iname.com> Emails to what I thought were CenturyLink's NOC have gone unanswered, and the other email address resulted in an automated "you're not allowed to send emails to that group". Frank -----Original Message----- From: Frank Bulk Sent: Thursday, February 12, 2015 8:22 AM To: network at centurytel.net; 'noc at qwest.net' Subject: HTTPv6 access to www.centurylink.com and www.qwest.com are down According to our monitoring system, HTTPv6 access to www.centurylink.com and www.qwest.com have been down since 12:05 am U.S. Central, responding with a "Connection refused". I've tested from two vantage points to confirm that it's not just our prefix. Diagnostic output can be found below. Regards, Frank Bulk Premier Communications root at nagios:~/tmp/ipv6# wget -6 www.centurylink.com --2015-02-12 08:18:22-- http://www.centurylink.com/ Resolving www.centurylink.com... 2001:428:b21:1::20 Connecting to www.centurylink.com|2001:428:b21:1::20|:80... failed: Connection refused. root at nagios:~/tmp/ipv6# root at nagios:~/tmp/ipv6# tcptraceroute6 www.centurylink.com traceroute to www.centurylink.com (2001:428:b21:1::20) from 2607:fe28:0:1000::5, port 80, from port 60661, 30 hops max, 60 bytes packets 1 router-core.mtcnet.net (2607:fe28:0:1000::1) 0.555 ms 19.811 ms 1.632 ms 2 sxct.sxcy.mtcnet.net (2607:fe28:11:1002::197) 0.185 ms 0.196 ms 0.115 ms 3 v6-premier.sxcy-mlx.fbnt.netins.net (2001:5f8:7f0a:2::1) 1.641 ms 1.617 ms 1.585 ms 4 v6-ins-db4-te-0-6-0-4-219.desm.netins.net (2001:5f8:1:1::1) 8.146 ms 8.003 ms 8.051 ms 5 v6-ins-dc1-te-7-4.desm.netins.net (2001:5f8::26:2) 8.035 ms 7.954 ms 7.928 ms 6 2610:18:18b:c000::11 (2610:18:18b:c000::11) 12.925 ms 12.941 ms 12.896 ms 7 mcr1.minneapolis-mn.us.xo.net (2610:18::30b8) 22.254 ms 22.234 ms 22.238 ms 8 2610:18::5802 (2610:18::5802) 32.891 ms 25.156 ms 22.868 ms 9 2610:18::2072 (2610:18::2072) 23.894 ms 22.264 ms 22.759 ms 10 2610:18:16:3000::da (2610:18:16:3000::da) 18.543 ms 18.513 ms 18.569 ms 11 2001:428::205:171:2:52 (2001:428::205:171:2:52) 28.482 ms 28.512 ms 28.549 ms 12 2001:428:1c02:2::2 (2001:428:1c02:2::2) 28.254 ms 28.277 ms 28.238 ms 13 * 2001:428:b21:fc03::2 (2001:428:b21:fc03::2) 28.871 ms 28.608 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * root at nagios:~/tmp/ipv6# From saku at ytti.fi Mon Feb 16 12:46:22 2015 From: saku at ytti.fi (Saku Ytti) Date: Mon, 16 Feb 2015 14:46:22 +0200 Subject: Interesting BFD discussion on reddit In-Reply-To: References: <20150215222540.GA15215@pob.ytti.fi> Message-ID: <20150216124622.GA13534@pob.ytti.fi> On (2015-02-16 08:55 +0530), Glen Kent wrote: Hey, > You might want to take a look at: > http://www.ietf.org/proceedings/89/slides/slides-89-mpls-9.pdf > > Look at the slides 11 onwards. > > Doing HMAC calculation for each packet adversely affects the number of > concurrent sessions that can be supported. I don't understand the slidedeck. Lets take slide 13, 'hardware support' for authentication. Why in quotes? What hardware is doing the hashing here? Which hash algo? How many cycles per byte for BFD how many more for BFD with algoX? On x86 CPUs it's anything from 1 to 20 cycles per byte, depending on hash algorithm, but HW implementation would be much more efficient. Of course if HW is done serial to the BFD receive/send, then there is non-zero performance cost regardless of how fast the HW is. Separate parallel HW implementation is probably not practical today, as you'd need to use what ever primitives your NPU has? So practical question would ask, what algo is implementable in Trio/EZchip and how would it impact the cycles per BFD packet? Page 14 appears to be only slide doing HW in auth, but I can't be sure, as first example claims 'auth in soft', second does not. Is there only one example in whole slidedeck with auth in hardware, if so, how come ratio in the first example and last examaple in page 14 is same 1/8th, implying HW brings 0 benefit? -- ++ytti From rea+nanog at grid.kiae.ru Mon Feb 16 14:50:58 2015 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Mon, 16 Feb 2015 17:50:58 +0300 Subject: Interesting BFD discussion on reddit In-Reply-To: References: <20150215222540.GA15215@pob.ytti.fi> Message-ID: Mon, Feb 16, 2015 at 08:55:17AM +0530, Glen Kent wrote: > > I wonder if Trio, EZChip and friends could do SHA in NPU, my guess > > is yes they could, but perhaps there is even more appropriate hash > > for this use-case. I'm not entirely convinced doing hash for each > > BFD packet is impractical. > > > > [0] http://www.ietf.org/id/draft-mahesh-bfd-authentication-00.txt > > > You might want to take a look at: > http://www.ietf.org/proceedings/89/slides/slides-89-mpls-9.pdf > > Look at the slides 11 onwards. Were these people doing some real implementation in-hardware or were just theoretizing? I see "prediction" label for the number of authenticated sessions -- do you have an idea what that means? And on slide 14 you have smaller session limit numbers for BFD fully implemented in hardware than for hw-assisted case (slide 12). It makes me think that this presentation should either be supplemented with talking people or there are some errors in it. Or I am completely missing some fine point here. > Doing HMAC calculation for each packet adversely affects the number > of concurrent sessions that can be supported. Without mentioning the scope (which hardware and software) this assertion is either trivial or useless, sorry. TSO, frame checksums and other stuff hadn't been implemented in-hardware for ages, but now it is here and there all the time. And /me is interested why can't BFD be done on the interface chip level: it is point-to-point on L2 for the majority of cases. -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From chris at aperturefiber.com Mon Feb 16 23:58:53 2015 From: chris at aperturefiber.com (Chris Garrett) Date: Mon, 16 Feb 2015 17:58:53 -0600 Subject: Century Link contact Message-ID: Is there someone from the CenturyLink network ops group who would be willing to contact me off list? I have an issue with stability on a large number of customer circuits and it’s on the verge of getting very ugly. Thank you. From glen.kent at gmail.com Tue Feb 17 00:41:59 2015 From: glen.kent at gmail.com (Glen Kent) Date: Tue, 17 Feb 2015 06:11:59 +0530 Subject: Interesting BFD discussion on reddit In-Reply-To: References: <20150215222540.GA15215@pob.ytti.fi> Message-ID: http://www.ietf.org/proceedings/90/agenda.html -> MPLS WG was heldin Sovereign on 4th March @ 1300-1400 http://www.ietf.org/audio/ietf89/ will you the audio recording for this talk. >From the MOM http://www.ietf.org/proceedings/89/minutes/minutes-89-mpls its clear that there is no disagreement about NOT doing BFD authentication in hardware -- similar to what is claimed by the presenter. I think the hardware used was Broadcom. They have a few chipsets which do MD5 and (possibly) SHA in hardware for BFD -- which i have been told is pretty much useless when you start scaling. Glen On Mon, Feb 16, 2015 at 8:20 PM, Eygene Ryabinkin wrote: > Mon, Feb 16, 2015 at 08:55:17AM +0530, Glen Kent wrote: > > > I wonder if Trio, EZChip and friends could do SHA in NPU, my guess > > > is yes they could, but perhaps there is even more appropriate hash > > > for this use-case. I'm not entirely convinced doing hash for each > > > BFD packet is impractical. > > > > > > [0] http://www.ietf.org/id/draft-mahesh-bfd-authentication-00.txt > > > > > > You might want to take a look at: > > http://www.ietf.org/proceedings/89/slides/slides-89-mpls-9.pdf > > > > Look at the slides 11 onwards. > > Were these people doing some real implementation in-hardware or were > just theoretizing? I see "prediction" label for the number of > authenticated sessions -- do you have an idea what that means? > > And on slide 14 you have smaller session limit numbers for BFD fully > implemented in hardware than for hw-assisted case (slide 12). > > It makes me think that this presentation should either be supplemented > with talking people or there are some errors in it. Or I am completely > missing some fine point here. > > > Doing HMAC calculation for each packet adversely affects the number > > of concurrent sessions that can be supported. > > Without mentioning the scope (which hardware and software) this > assertion is either trivial or useless, sorry. TSO, frame checksums > and other stuff hadn't been implemented in-hardware for ages, but > now it is here and there all the time. > > And /me is interested why can't BFD be done on the interface chip > level: it is point-to-point on L2 for the majority of cases. > -- > Eygene Ryabinkin, National Research Centre "Kurchatov Institute" > > Always code as if the guy who ends up maintaining your code will be > a violent psychopath who knows where you live. > From rs at seastrom.com Tue Feb 17 01:33:17 2015 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 16 Feb 2015 20:33:17 -0500 Subject: Interesting BFD discussion on reddit In-Reply-To: (Dave Waters's message of "Sun, 15 Feb 2015 21:34:57 +0530") References: Message-ID: <8661b1725e.fsf@valhalla.seastrom.com> Dave Waters writes: > http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple_way_to_secure_bfd/ > > Authentication mechanisms defined for IGPs cannot be used to protect BFD > since the rate at which packets are processed in BFD is very high. > > Dave One might profitably ask why BFD wasn't designed to take advantage of high-TTL-shadowing, a la draft-gill-btsh. -r From rs at seastrom.com Tue Feb 17 02:50:02 2015 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 16 Feb 2015 21:50:02 -0500 Subject: Interesting BFD discussion on reddit In-Reply-To: (Dave Waters's message of "Tue, 17 Feb 2015 07:42:20 +0530") References: <8661b1725e.fsf@valhalla.seastrom.com> Message-ID: <86y4nxuu91.fsf@valhalla.seastrom.com> Many moons ago, Mike O'Dell had a pithy observation about "can" vs. "should" that is escaping me at this moment, which is a pity since it almost certainly applies here. -r Dave Waters writes: > Because BFD packets can get routed across multiple hops. Unlike EBGP where you connect to a > peer in a different AS and you have a direct connection, BFD packets can traverse multiple > hops to reach the endpoint. > > > > In case of multihop BFD the BFD packets also get re-routed when the topology changes so you > can almost never bet on the TTL value to secure the protocol. > > > > Dave > > > > On Tue, Feb 17, 2015 at 7:03 AM, Rob Seastrom <[[rs at seastrom.com]]> wrote: > > Dave Waters <[[davewaters1970 at gmail.com]]> writes: > > > > [[http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple_way_to_secure_bfd/]] > > > > Authentication mechanisms defined for IGPs cannot be used to protect BFD > > since the rate at which packets are processed in BFD is very high. > > > > Dave > > > > > One might profitably ask why BFD wasn't designed to take advantage of > high-TTL-shadowing, a la draft-gill-btsh. > > -r > > > From glen.kent at gmail.com Tue Feb 17 06:17:04 2015 From: glen.kent at gmail.com (Glen Kent) Date: Tue, 17 Feb 2015 11:47:04 +0530 Subject: Low BW between Mountain View and OR -- why? Message-ID: Hi, I have a server in Mountain View and i am doing a speedtest with a server in Oregon. I see that the upload/download BW that i am getting is low -- around 10.0Mbps and 5.0Mbps. gkent at ubuntu:~/ics$ speedtest-cli --server 4082 Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from Comcast Cable (50.250.251.210)... Hosted by Eastern Oregon Net, Inc. (La Grande, OR) [913.33 km]: 120.959 ms Testing download speed........................................ Download: 5.08 Mbits/s Testing upload speed.................................................. Upload: 10.89 Mbits/s When i check my connectivity with a server in NYC, its much better, though the server is much further away. gkent at ubuntu:~/ics$ speedtest-cli --server 2947 Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from Comcast Cable (50.250.251.210)... Hosted by Atlantic Metro (New York City, NY) [4129.02 km]: 307.568 ms Testing download speed........................................ Download: 38.52 Mbits/s Testing upload speed.................................................. Upload: 10.62 Mbits/s I am trying to understand why this is so? I would wager that NYC being further away would give me a worse throughput than OR, but the speedtest tells me otherwise. The 2nd and more puzzling observation is that while OR is giving a download of around 5.08Mbps, it will improve and become much better later in the day. There are times when i see it going up as high as 48Mbps. Sometimes while a transfer is in progress i see that my download suddenly goes down from 48Mbps to 2Mbps. Can somebody here tell me why such a drastic fluctuation is seen? Thanks, Glen From mike.lyon at gmail.com Tue Feb 17 06:40:27 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 16 Feb 2015 22:40:27 -0800 Subject: Low BW between Mountain View and OR -- why? In-Reply-To: References: Message-ID: Try a traceroute to the site in Orefon and see where the bottle neck is? Could also be that the speedtest server in OR is bogged down... -Mike On Feb 16, 2015 10:18 PM, "Glen Kent" wrote: > Hi, > > I have a server in Mountain View and i am doing a speedtest with a server > in Oregon. I see that the upload/download BW that i am getting is low -- > around 10.0Mbps and 5.0Mbps. > > gkent at ubuntu:~/ics$ speedtest-cli --server 4082 > Retrieving speedtest.net configuration... > Retrieving speedtest.net server list... > Testing from Comcast Cable (50.250.251.210)... > Hosted by Eastern Oregon Net, Inc. (La Grande, OR) [913.33 km]: 120.959 ms > Testing download speed........................................ > Download: 5.08 Mbits/s > Testing upload speed.................................................. > Upload: 10.89 Mbits/s > > When i check my connectivity with a server in NYC, its much better, though > the server is much further away. > > gkent at ubuntu:~/ics$ speedtest-cli --server 2947 > Retrieving speedtest.net configuration... > Retrieving speedtest.net server list... > Testing from Comcast Cable (50.250.251.210)... > Hosted by Atlantic Metro (New York City, NY) [4129.02 km]: 307.568 ms > Testing download speed........................................ > Download: 38.52 Mbits/s > Testing upload speed.................................................. > Upload: 10.62 Mbits/s > > I am trying to understand why this is so? I would wager that NYC being > further away would give me a worse throughput than OR, but the speedtest > tells me otherwise. > > The 2nd and more puzzling observation is that while OR is giving a download > of around 5.08Mbps, it will improve and become much better later in the > day. There are times when i see it going up as high as 48Mbps. > > Sometimes while a transfer is in progress i see that my download suddenly > goes down from 48Mbps to 2Mbps. > > Can somebody here tell me why such a drastic fluctuation is seen? > > Thanks, Glen > From rea+nanog at grid.kiae.ru Tue Feb 17 07:06:44 2015 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Tue, 17 Feb 2015 10:06:44 +0300 Subject: Low BW between Mountain View and OR -- why? In-Reply-To: References: Message-ID: Tue, Feb 17, 2015 at 11:47:04AM +0530, Glen Kent wrote: > I have a server in Mountain View and i am doing a speedtest with a > server in Oregon. I see that the upload/download BW that i am > getting is low -- around 10.0Mbps and 5.0Mbps. > > gkent at ubuntu:~/ics$ speedtest-cli --server 4082 > Retrieving speedtest.net configuration... > Retrieving speedtest.net server list... > Testing from Comcast Cable (50.250.251.210)... > Hosted by Eastern Oregon Net, Inc. (La Grande, OR) [913.33 km]: 120.959 ms > Testing download speed........................................ > Download: 5.08 Mbits/s > Testing upload speed.................................................. > Upload: 10.89 Mbits/s > > When i check my connectivity with a server in NYC, its much better, though > the server is much further away. > > gkent at ubuntu:~/ics$ speedtest-cli --server 2947 > Retrieving speedtest.net configuration... > Retrieving speedtest.net server list... > Testing from Comcast Cable (50.250.251.210)... > Hosted by Atlantic Metro (New York City, NY) [4129.02 km]: 307.568 ms > Testing download speed........................................ > Download: 38.52 Mbits/s > Testing upload speed.................................................. > Upload: 10.62 Mbits/s > > I am trying to understand why this is so? I would wager that NYC being > further away would give me a worse throughput than OR, but the speedtest > tells me otherwise. Packet loss or just congestion on the path (resulting in packet loss again) that makes your TCP windows to shrink and not letting you to get close to either your allocated BW on the channel to OR or your maximal throughput per TCP stream that is governed by the maximal size of the TCP buffer? There could be some shaping as well, but this might be not your case, since it fluctuates. However, many interesting things could happen. iperf in UDP mode should give you fairly good overview of what't happening with bandwidth and packet loss. And iperf in TCP mode with varying number of streams (and obtained scaling of throughput or lack of it) should give you some hints on what's possibly going on. I also assume that you're talking about TCP and your bandwidth-delay product is used to tune TCP buffer sizes. If not, I'd recommend checking http://www.psc.edu/index.php/networking/641-tcp-tune > The 2nd and more puzzling observation is that while OR is giving a > download of around 5.08Mbps, it will improve and become much better > later in the day. There are times when i see it going up as high as > 48Mbps. > > Sometimes while a transfer is in progress i see that my download > suddenly goes down from 48Mbps to 2Mbps. Varying routing during the day, fluctuating congestion and many other things could happen. Probably here something like smokeping will give you an overview of the RTT (if it varies) and loss on the ICMP. ICMP loss isn't neccessarily coupled to UDP/TCP due to the QoS and other stuff that can happen on WAN, so it will provide just additional hints, not the complete answer. > Can somebody here tell me why such a drastic fluctuation is seen? No answers here, sorry, just some hints and possibilities. -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From saku at ytti.fi Tue Feb 17 07:36:06 2015 From: saku at ytti.fi (Saku Ytti) Date: Tue, 17 Feb 2015 09:36:06 +0200 Subject: Interesting BFD discussion on reddit In-Reply-To: <8661b1725e.fsf@valhalla.seastrom.com> References: <8661b1725e.fsf@valhalla.seastrom.com> Message-ID: <20150217073606.GA7567@pob.ytti.fi> On (2015-02-16 20:33 -0500), Rob Seastrom wrote: Hey, > One might profitably ask why BFD wasn't designed to take advantage of > high-TTL-shadowing, a la draft-gill-btsh. RFC5881, section 5 in page 4 --- If BFD authentication is not in use on a session, all BFD Control packets for the session MUST be sent with a Time to Live (TTL) or Hop Limit value of 255. All received BFD Control packets that are demultiplexed to the session MUST be discarded if the received TTL or Hop Limit is not equal to 255. A discussion of this mechanism can be found in [GTSM]. --- -- ++ytti From saku at ytti.fi Tue Feb 17 07:43:24 2015 From: saku at ytti.fi (Saku Ytti) Date: Tue, 17 Feb 2015 09:43:24 +0200 Subject: Interesting BFD discussion on reddit In-Reply-To: References: <20150215222540.GA15215@pob.ytti.fi> Message-ID: <20150217074324.GB7567@pob.ytti.fi> On (2015-02-17 06:11 +0530), Glen Kent wrote: > I think the hardware used was Broadcom. They have a few chipsets which do > MD5 and (possibly) SHA in hardware for BFD -- which i have been told is > pretty much useless when you start scaling. Thanks. I'd be more interested to see performance for Trio, EZChip and perhaps even pq3/qoriq SEC2/SEC3. Real platforms, deployed in volume today. but I guess this data, at least for Trio would be very difficult to acquire. However pq3/qoriq would, in my mind, be software implementation, as it's control-plane CPU, which means BFD would have to be punted as well. -- ++ytti From davewaters1970 at gmail.com Tue Feb 17 02:12:20 2015 From: davewaters1970 at gmail.com (Dave Waters) Date: Tue, 17 Feb 2015 07:42:20 +0530 Subject: Interesting BFD discussion on reddit In-Reply-To: <8661b1725e.fsf@valhalla.seastrom.com> References: <8661b1725e.fsf@valhalla.seastrom.com> Message-ID: Because BFD packets can get routed across multiple hops. Unlike EBGP where you connect to a peer in a different AS and you have a direct connection, BFD packets can traverse multiple hops to reach the endpoint. In case of multihop BFD the BFD packets also get re-routed when the topology changes so you can almost never bet on the TTL value to secure the protocol. Dave On Tue, Feb 17, 2015 at 7:03 AM, Rob Seastrom wrote: > > Dave Waters writes: > > > > http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple_way_to_secure_bfd/ > > > > Authentication mechanisms defined for IGPs cannot be used to protect BFD > > since the rate at which packets are processed in BFD is very high. > > > > Dave > > One might profitably ask why BFD wasn't designed to take advantage of > high-TTL-shadowing, a la draft-gill-btsh. > > -r > > > From kemp at network-services.uoregon.edu Tue Feb 17 09:23:37 2015 From: kemp at network-services.uoregon.edu (John Kemp) Date: Tue, 17 Feb 2015 01:23:37 -0800 Subject: Low BW between Mountain View and OR -- why? In-Reply-To: References: Message-ID: <54E30899.1040800@network-services.uoregon.edu> You are probably testing with different sites in Oregon. La Grande is different than Portland/Salem/Corvallis, etc. I would expect traffic to eastern Oregon to be slow. /jgk On 2/16/2015 11:06 PM, Eygene Ryabinkin wrote: > Tue, Feb 17, 2015 at 11:47:04AM +0530, Glen Kent wrote: >> I have a server in Mountain View and i am doing a speedtest with a >> server in Oregon. I see that the upload/download BW that i am >> getting is low -- around 10.0Mbps and 5.0Mbps. >> >> gkent at ubuntu:~/ics$ speedtest-cli --server 4082 >> Retrieving speedtest.net configuration... >> Retrieving speedtest.net server list... >> Testing from Comcast Cable (50.250.251.210)... >> Hosted by Eastern Oregon Net, Inc. (La Grande, OR) [913.33 km]: 120.959 ms >> Testing download speed........................................ >> Download: 5.08 Mbits/s >> Testing upload speed.................................................. >> Upload: 10.89 Mbits/s >> >> When i check my connectivity with a server in NYC, its much better, though >> the server is much further away. >> >> gkent at ubuntu:~/ics$ speedtest-cli --server 2947 >> Retrieving speedtest.net configuration... >> Retrieving speedtest.net server list... >> Testing from Comcast Cable (50.250.251.210)... >> Hosted by Atlantic Metro (New York City, NY) [4129.02 km]: 307.568 ms >> Testing download speed........................................ >> Download: 38.52 Mbits/s >> Testing upload speed.................................................. >> Upload: 10.62 Mbits/s >> >> I am trying to understand why this is so? I would wager that NYC being >> further away would give me a worse throughput than OR, but the speedtest >> tells me otherwise. > Packet loss or just congestion on the path (resulting in packet loss > again) that makes your TCP windows to shrink and not letting you to > get close to either your allocated BW on the channel to OR or your > maximal throughput per TCP stream that is governed by the maximal size > of the TCP buffer? There could be some shaping as well, but this > might be not your case, since it fluctuates. However, many interesting > things could happen. > > iperf in UDP mode should give you fairly good overview of what't > happening with bandwidth and packet loss. And iperf in TCP mode with > varying number of streams (and obtained scaling of throughput or lack > of it) should give you some hints on what's possibly going on. > > I also assume that you're talking about TCP and your bandwidth-delay > product is used to tune TCP buffer sizes. If not, I'd recommend > checking > http://www.psc.edu/index.php/networking/641-tcp-tune > >> The 2nd and more puzzling observation is that while OR is giving a >> download of around 5.08Mbps, it will improve and become much better >> later in the day. There are times when i see it going up as high as >> 48Mbps. >> >> Sometimes while a transfer is in progress i see that my download >> suddenly goes down from 48Mbps to 2Mbps. > Varying routing during the day, fluctuating congestion and many other > things could happen. Probably here something like smokeping will give > you an overview of the RTT (if it varies) and loss on the ICMP. ICMP > loss isn't neccessarily coupled to UDP/TCP due to the QoS and other > stuff that can happen on WAN, so it will provide just additional hints, > not the complete answer. > >> Can somebody here tell me why such a drastic fluctuation is seen? > No answers here, sorry, just some hints and possibilities. From skeeve+nanog at eintellegonetworks.com Tue Feb 17 10:29:30 2015 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Tue, 17 Feb 2015 21:29:30 +1100 Subject: Job: Head of Network Operations - NEXTDC - Sydney Australia - 457 Available Message-ID: Hi all, On Seek.com.au - http://www.seek.com.au/job/28150202?pos=1&type=standout I know a bit about this role, so feel free to chat to me offline if you are wondering if you are suitable.... or just apply directly :) I'm helping them find the right person... hardest thing is knowing who is out there and looking for a role like this. I will be in Japan at the Apricot/APNIC conference in a couple of weeks if you're there and you are interested in the role and would like to catch-up and chat about it. ...Skeeve *Skeeve Stevens - Founder & Chief Network Architect* eintellego Networks Pty Ltd Email: skeeve at eintellegonetworks.com ; Web: eintellegonetworks.com Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks ; Twitter: eintellego LinkedIn: /in/skeeve ; Expert360: Profile The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering From mmethw2003 at gmail.com Tue Feb 17 11:35:49 2015 From: mmethw2003 at gmail.com (Methsri Wickramarathna) Date: Tue, 17 Feb 2015 17:05:49 +0530 Subject: Usage Graphing per Subnet Message-ID: Hi All, I have a requirement to plot a usage graph per subnet. As an example. I have a 192.168.1.0/24 subnet divided among 32 customers where each one will get a /29 [ 192.168.1.0/29 => Customer A ; 192.168.1.8/29 => Customer B etc... ] ... Is there any tool to graph the usage of entire /24 subnet ??? -- -- ~~( ŊëŌ )~~ From ak at ghostnet.de Tue Feb 17 11:47:12 2015 From: ak at ghostnet.de (Armin Kneip) Date: Tue, 17 Feb 2015 12:47:12 +0100 Subject: Usage Graphing per Subnet In-Reply-To: References: Message-ID: <54E32A40.9050102@ghostnet.de> Hi, pmacct is your friend! http://www.pmacct.net/ Regards, Armin Am 17.02.2015 um 12:35 schrieb Methsri Wickramarathna: > Hi All, I have a requirement to plot a usage graph per subnet. As an > example. > > I have a 192.168.1.0/24 subnet divided among 32 customers where each one > will get a /29 [ 192.168.1.0/29 => Customer A ; 192.168.1.8/29 => Customer > B etc... ] ... > > Is there any tool to graph the usage of entire /24 subnet ??? > -- Mit freundlichen Grüßen // Kind regards Armin Kneip GHOSTnet GmbH Kaiser-Friedrich-Promenade 65 D-61348 Bad Homburg v.d.H (Germany) Office +49 (0) 6172 185025 Fax +49 (0) 6172 185029 Internet: www.ghostnet.de Mail: noc at ghostnet.de Sitz: Kaiser-Friedrich-Promenade 65, D-61348 Bad Homburg v.d.H. Amtsgericht Bad Homburg v.d.H. HRB 8637, UST-ID-Nr. DE206435465 Geschäftsführer: Sebastian Grafmüller From david at mailplus.nl Tue Feb 17 12:00:53 2015 From: david at mailplus.nl (David Hofstee) Date: Tue, 17 Feb 2015 13:00:53 +0100 Subject: Usage Graphing per Subnet In-Reply-To: References: Message-ID: <78C35D6C1A82D243B830523B4193CF5F9280FBDF37@SBS1.blinker.local> http://graphviz.org/ David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Methsri Wickramarathna Verzonden: Tuesday, February 17, 2015 12:36 PM Aan: nanog at nanog.org Onderwerp: Usage Graphing per Subnet Hi All, I have a requirement to plot a usage graph per subnet. As an example. I have a 192.168.1.0/24 subnet divided among 32 customers where each one will get a /29 [ 192.168.1.0/29 => Customer A ; 192.168.1.8/29 => Customer B etc... ] ... Is there any tool to graph the usage of entire /24 subnet ??? -- -- ~~( ŊëŌ )~~ From karsten_thomann at linfre.de Tue Feb 17 12:04:41 2015 From: karsten_thomann at linfre.de (Karsten Thomann) Date: Tue, 17 Feb 2015 13:04:41 +0100 Subject: Usage Graphing per Subnet In-Reply-To: <54E32A40.9050102@ghostnet.de> References: <54E32A40.9050102@ghostnet.de> Message-ID: <54E32E59.6030401@linfre.de> Hi, I'm not sure how it is exactly build, but if every /29 uses it's own port a tool like cacti/graphite where you're aggregating all required ports within one graph is easier. Regards Karsten Am 17.02.2015 12:47, schrieb Armin Kneip: > Hi, > > pmacct is your friend! > > http://www.pmacct.net/ > > > Regards, > Armin > > > Am 17.02.2015 um 12:35 schrieb Methsri Wickramarathna: >> Hi All, I have a requirement to plot a usage graph per subnet. As an >> example. >> >> I have a 192.168.1.0/24 subnet divided among 32 customers where each one >> will get a /29 [ 192.168.1.0/29 => Customer A ; 192.168.1.8/29 => Customer >> B etc... ] ... >> >> Is there any tool to graph the usage of entire /24 subnet ??? >> From listas at esds.com.br Tue Feb 17 12:13:36 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Tue, 17 Feb 2015 10:13:36 -0200 Subject: Usage Graphing per Subnet In-Reply-To: References: Message-ID: Run sflows/netlows/ipfix. -- Eduardo Schoedler 2015-02-17 9:35 GMT-02:00 Methsri Wickramarathna : > Hi All, > I have a requirement to plot a usage graph per subnet. As an example. > > I have a 192.168.1.0/24 subnet divided among 32 customers where each one > will get a /29 [ 192.168.1.0/29 => Customer A ; 192.168.1.8/29 => Customer > B etc... ] ... > > Is there any tool to graph the usage of entire /24 subnet ??? > > -- > -- > > ~~( ŊëŌ )~~ -- Eduardo Schoedler From randy at psg.com Tue Feb 17 13:39:14 2015 From: randy at psg.com (Randy Bush) Date: Tue, 17 Feb 2015 22:39:14 +0900 Subject: Job: Head of Network Operations - NEXTDC - Sydney Australia - 457 Available In-Reply-To: References: Message-ID: > hardest thing is knowing the aups of the mailing lists you're spamming. no grown-ups look at offers from spammers From mmethw2003 at gmail.com Tue Feb 17 16:31:18 2015 From: mmethw2003 at gmail.com (Methsri Wickramarathna) Date: Tue, 17 Feb 2015 22:01:18 +0530 Subject: Usage Graphing per Subnet In-Reply-To: <54E32E59.6030401@linfre.de> References: <54E32A40.9050102@ghostnet.de> <54E32E59.6030401@linfre.de> Message-ID: Thanks Armin , I will try the SW you have mentioned seems like it's not easy to install though :) :) Karsten, I just bought out an example... my company has 2X18's and out of it we are using considerable amount of /24s to access internet . Some subnets are given without proper documentation , so it's very hard to do what you have proposed. What I can do is to install some kind of SW and gather info from my gateway routers :( .....it's helpful if some one can guide me through this :) ... On Tue, Feb 17, 2015 at 5:34 PM, Karsten Thomann wrote: > Hi, > > I'm not sure how it is exactly build, but if every /29 uses it's own port > a tool like cacti/graphite where you're aggregating all required ports > within one graph is easier. > > Regards > Karsten > > Am 17.02.2015 12:47, schrieb Armin Kneip: > > Hi, >> >> pmacct is your friend! >> >> http://www.pmacct.net/ >> >> >> Regards, >> Armin >> >> >> Am 17.02.2015 um 12:35 schrieb Methsri Wickramarathna: >> >>> Hi All, I have a requirement to plot a usage graph per subnet. As an >>> example. >>> >>> I have a 192.168.1.0/24 subnet divided among 32 customers where each one >>> will get a /29 [ 192.168.1.0/29 => Customer A ; 192.168.1.8/29 => >>> Customer >>> B etc... ] ... >>> >>> Is there any tool to graph the usage of entire /24 subnet ??? >>> >>> > -- -- ________´$$$$`_____________________________,,,_ _______´$$$$$$$`_________________________´$$$` ________`$$$$$$$`______,,________,,_______´$$$$´ _________`$$$$$$$`____´$$`_____´$$`____´$$$$$´ __________`$$$$$$$`_´$$$$$`_´$$$$$`__´$$$$$$$´ ___________`$$$$$$$_$$$$$$$_$$$$$$$_´$$$$$$$´_ ____________`$$$$$$_$$$$$$$_$$$$$$$`´$$$$$$´_ ___,,,,,,______`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_ _´$$$$$`____`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_ ´$$$$$$$$$`´$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_ ´$$$$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_ ___`$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$_$$$$$$´_ ______`$$$$$$$$$$$$$_$$$$$__$$_$$$$$$_$$´_ _______`$$$$$$$$$$$$,___,$$$$,_____,$$$$$´_ _________`$$$$$$$$$$$$$$$$$$$$$$$$$$$$$´_ __________`$$$$$$$$$$$$$$$$$$$$$$$$$$$´_ ____________`$$$$$$$$$$$$$$$$$$$$$$$$´_ _______________`$$$$$$$$$$$$$$$$$$$$´_ ~~( ŊëŌ )~~ From hugo at slabnet.com Tue Feb 17 16:37:34 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 17 Feb 2015 08:37:34 -0800 Subject: Interesting BFD discussion on reddit In-Reply-To: References: <8661b1725e.fsf@valhalla.seastrom.com> Message-ID: <20150217163734.GC5718@bamboo.slabnet.com> >Because BFD packets can get routed across multiple hops. Unlike EBGP where >you connect to a peer in a different AS and you have a direct connection, >BFD packets can traverse multiple hops to reach the endpoint. Then what's this "multihop" knob I have available in my BGP config? Again, as Rob pointed out, "can" vs. "should" is a good consideration here, but unless I'm missing something both EBGP and BFD "can" do multihop...so...? -- Hugo On Tue 2015-Feb-17 07:42:20 +0530, Dave Waters wrote: >Because BFD packets can get routed across multiple hops. Unlike EBGP where >you connect to a peer in a different AS and you have a direct connection, >BFD packets can traverse multiple hops to reach the endpoint. > >In case of multihop BFD the BFD packets also get re-routed when the >topology changes so you can almost never bet on the TTL value to secure the >protocol. > >Dave > >On Tue, Feb 17, 2015 at 7:03 AM, Rob Seastrom wrote: > >> >> Dave Waters writes: >> >> > >> http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple_way_to_secure_bfd/ >> > >> > Authentication mechanisms defined for IGPs cannot be used to protect BFD >> > since the rate at which packets are processed in BFD is very high. >> > >> > Dave >> >> One might profitably ask why BFD wasn't designed to take advantage of >> high-TTL-shadowing, a la draft-gill-btsh. >> >> -r >> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From ray at oneunified.net Tue Feb 17 17:02:26 2015 From: ray at oneunified.net (Raymond Burkholder) Date: Tue, 17 Feb 2015 13:02:26 -0400 Subject: Usage Graphing per Subnet In-Reply-To: References: <54E32A40.9050102@ghostnet.de> <54E32E59.6030401@linfre.de> Message-ID: <13f301d04ad3$82195ec0$864c1c40$@oneunified.net> > >> > >>> Hi All, I have a requirement to plot a usage graph per subnet. As an > >>> example. > >>> > >>> I have a 192.168.1.0/24 subnet divided among 32 customers where each > >>> one will get a /29 [ 192.168.1.0/29 => Customer A ; 192.168.1.8/29 > >>> => Customer B etc... ] ... > >>> > >>> Is there any tool to graph the usage of entire /24 subnet ??? I use nfdump/nfsen for this sort of thing. It requires netflow export on your devices. I then I create a shadow profile for each subnet I wish to chart. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From karsten_thomann at linfre.de Tue Feb 17 18:23:08 2015 From: karsten_thomann at linfre.de (Karsten Thomann) Date: Tue, 17 Feb 2015 18:23:08 +0000 Subject: Usage Graphing per Subnet In-Reply-To: References: <54E32E59.6030401@linfre.de> Message-ID: <5938700.Yg2D3a4Z4C@linne> Hi, in this case I fully agree with Armin's advice, only wanted to provide a possible way to archive an easy result without activation of netflow/sflow which is possible if all subnets had dedicated ports somewhere in the net. I don't know what information you want to get from your routers, as there are many ways to get a result depending on the information you want and the used vendors. Regards Karsten Am Dienstag, 17. Februar 2015, 22:01:18 schrieb Methsri Wickramarathna: > Thanks Armin , > I will try the SW you have mentioned seems like it's not easy to install > though :) :) > > Karsten, > I just bought out an example... my company has 2X18's and out of it we are > using considerable amount of /24s to access internet . Some subnets are > given without proper documentation , so it's very hard to do what you have > proposed. > What I can do is to install some kind of SW and gather info from my gateway > routers :( .....it's helpful if some one can guide me through this :) ... > > On Tue, Feb 17, 2015 at 5:34 PM, Karsten Thomann > wrote: > > Hi, > > > > I'm not sure how it is exactly build, but if every /29 uses it's own port > > a tool like cacti/graphite where you're aggregating all required ports > > within one graph is easier. > > > > Regards > > Karsten > > > > Am 17.02.2015 12:47, schrieb Armin Kneip: > > Hi, > > > >> pmacct is your friend! > >> > >> http://www.pmacct.net/ > >> > >> > >> Regards, > >> Armin > >> > >> Am 17.02.2015 um 12:35 schrieb Methsri Wickramarathna: > >>> Hi All, I have a requirement to plot a usage graph per subnet. As an > >>> example. > >>> > >>> I have a 192.168.1.0/24 subnet divided among 32 customers where each one > >>> will get a /29 [ 192.168.1.0/29 => Customer A ; 192.168.1.8/29 => > >>> Customer > >>> B etc... ] ... > >>> > >>> Is there any tool to graph the usage of entire /24 subnet ??? From sotnickd-nanog at ddv.com Tue Feb 17 18:38:05 2015 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Tue, 17 Feb 2015 10:38:05 -0800 Subject: Comcast Business IPv6 issues Message-ID: Hi NANOG, I am a Comcast business Internet subscriber and have been struggling with having my assigned IPv6 /64 block changing every time Comcast pushes out a firmware update to my (Motorola BitSurfer) CM. It seems rather silly that my IPv4 address has not changed in the six months I've been a Comcast business customer, yet my IPv6 address changes every few weeks, always after a reset command is sent from the head-end to my CM (or after power outage). My *home* Comcast IPv6 address has not changed in over a year, and the same applies for my IPv4 address, so something is different about the way Comcast is treating their IPv6 business customers. This is getting quite frustrating as I run my security cameras over IPv6 and when the addresses change out from under me, things obviously break. Any insights here from the wise hivemind of Nanog or from Comcast network folks? Any chance static IPv6 will be available to business customers? While I am on the subject — ip6.arpa reverse DNS delegation would also be a nice thing to have if and when static IPv6 addressing is made available. :) Thanks! David Sotnick -- DDV Studios From lists at mtin.net Tue Feb 17 18:44:03 2015 From: lists at mtin.net (Justin Wilson - MTIN) Date: Tue, 17 Feb 2015 13:44:03 -0500 Subject: Comcast Business IPv6 issues In-Reply-To: References: Message-ID: <303662CE-25F4-4B73-A67E-C693C6C236EF@mtin.net> I don’t think they have a clear policy for V6. I can tell everytime my Comcast cable modem is updated because I lose all ipv6 connectivity. Right now I am in one of those periods. I can’t get ipv6 to pass the modem. Customer support tells me it’s not an issue and must be on my end. My he.net tunnels won’t even work. Justin Justin Wilson j2sw at mtin.net http://www.mtin.net Managed Services – xISP Solutions – Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering – Transit – Internet Exchange > On Feb 17, 2015, at 1:38 PM, David Sotnick wrote: > > Hi NANOG, > > I am a Comcast business Internet subscriber and have been struggling with > having my assigned IPv6 /64 block changing every time Comcast pushes out a > firmware update to my (Motorola BitSurfer) CM. > > It seems rather silly that my IPv4 address has not changed in the six > months I've been a Comcast business customer, yet my IPv6 address changes > every few weeks, always after a reset command is sent from the head-end to > my CM (or after power outage). > > My *home* Comcast IPv6 address has not changed in over a year, and the same > applies for my IPv4 address, so something is different about the way > Comcast is treating their IPv6 business customers. > > This is getting quite frustrating as I run my security cameras over IPv6 > and when the addresses change out from under me, things obviously break. > > Any insights here from the wise hivemind of Nanog or from Comcast network > folks? Any chance static IPv6 will be available to business customers? > > While I am on the subject — ip6.arpa reverse DNS delegation would also be a > nice thing to have if and when static IPv6 addressing is made available. :) > > Thanks! > > David Sotnick > -- > DDV Studios > From larrysheldon at cox.net Tue Feb 17 21:34:26 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 17 Feb 2015 15:34:26 -0600 Subject: Usage Graphing per Subnet In-Reply-To: References: Message-ID: <54E3B3E2.2060004@cox.net> On 2/17/2015 05:35, Methsri Wickramarathna wrote: > I have a requirement to plot a usage graph per subnet. As an example. > > I have a 192.168.1.0/24 subnet divided among 32 customers where each one > will get a /29 [ 192.168.1.0/29 => Customer A ; 192.168.1.8/29 => Customer > B etc... ] ... > > Is there any tool to graph the usage of entire /24 subnet ??? If MRTG can't do it, it can't be did. http://en.wikipedia.org/wiki/Multi_Router_Traffic_Grapher http://oss.oetiker.ch/mrtg/ -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From skeeve+nanog at eintellegonetworks.com Tue Feb 17 21:36:08 2015 From: skeeve+nanog at eintellegonetworks.com (Skeeve Stevens) Date: Wed, 18 Feb 2015 08:36:08 +1100 Subject: Job: Head of Network Operations - NEXTDC - Sydney Australia - 457 Available In-Reply-To: References: Message-ID: I wasn't aware it was... as someone else politely pointed out. But Randy, feel absolutely free not to ever look at anything I ever post or apply for any job with anyone I am associated with. ...Skeeve *Skeeve Stevens - Founder & Chief Network Architect* eintellego Networks Pty Ltd Email: skeeve at eintellegonetworks.com ; Web: eintellegonetworks.com Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks ; Twitter: eintellego LinkedIn: /in/skeeve ; Expert360: Profile The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering On Wed, Feb 18, 2015 at 12:39 AM, Randy Bush wrote: > > hardest thing is knowing > > the aups of the mailing lists you're spamming. > > no grown-ups look at offers from spammers > From mmethw2003 at gmail.com Wed Feb 18 03:10:27 2015 From: mmethw2003 at gmail.com (Methsri Wickramarathna) Date: Wed, 18 Feb 2015 08:40:27 +0530 Subject: Usage Graphing per Subnet In-Reply-To: <5938700.Yg2D3a4Z4C@linne> References: <54E32E59.6030401@linfre.de> <5938700.Yg2D3a4Z4C@linne> Message-ID: Karsten , thanks for replying.... It's like this I don't want to take router info, only thing i want is to graph the usage of my entire IP block per subnet wise. Normaly we are using CACTI , MRTG , Observium etc... to gather router information such as CPU , errors , usage etc... All the systems mentioned above use SNMP to gather info and when it comes to usage it only poll to a particular interface and plot the usage ......I hope you had an idea about my requirement :) On Tue, Feb 17, 2015 at 11:53 PM, Karsten Thomann wrote: > Hi, > > in this case I fully agree with Armin's advice, only wanted to provide a > possible way to archive an easy result without activation of netflow/sflow > which is possible if all subnets had dedicated ports somewhere in the net. > > I don't know what information you want to get from your routers, as there > are > many ways to get a result depending on the information you want and the > used > vendors. > > Regards > Karsten > > Am Dienstag, 17. Februar 2015, 22:01:18 schrieb Methsri Wickramarathna: > > Thanks Armin , > > I will try the SW you have mentioned seems like it's not easy to install > > though :) :) > > > > Karsten, > > I just bought out an example... my company has 2X18's and out of it we > are > > using considerable amount of /24s to access internet . Some subnets are > > given without proper documentation , so it's very hard to do what you > have > > proposed. > > What I can do is to install some kind of SW and gather info from my > gateway > > routers :( .....it's helpful if some one can guide me through this :) ... > > > > On Tue, Feb 17, 2015 at 5:34 PM, Karsten Thomann < > karsten_thomann at linfre.de> > > wrote: > > > Hi, > > > > > > I'm not sure how it is exactly build, but if every /29 uses it's own > port > > > a tool like cacti/graphite where you're aggregating all required ports > > > within one graph is easier. > > > > > > Regards > > > Karsten > > > > > > Am 17.02.2015 12:47, schrieb Armin Kneip: > > > Hi, > > > > > >> pmacct is your friend! > > >> > > >> http://www.pmacct.net/ > > >> > > >> > > >> Regards, > > >> Armin > > >> > > >> Am 17.02.2015 um 12:35 schrieb Methsri Wickramarathna: > > >>> Hi All, I have a requirement to plot a usage graph per subnet. As an > > >>> example. > > >>> > > >>> I have a 192.168.1.0/24 subnet divided among 32 customers where > each one > > >>> will get a /29 [ 192.168.1.0/29 => Customer A ; 192.168.1.8/29 => > > >>> Customer > > >>> B etc... ] ... > > >>> > > >>> Is there any tool to graph the usage of entire /24 subnet ??? > > -- -- ________´$$$$`_____________________________,,,_ _______´$$$$$$$`_________________________´$$$` ________`$$$$$$$`______,,________,,_______´$$$$´ _________`$$$$$$$`____´$$`_____´$$`____´$$$$$´ __________`$$$$$$$`_´$$$$$`_´$$$$$`__´$$$$$$$´ ___________`$$$$$$$_$$$$$$$_$$$$$$$_´$$$$$$$´_ ____________`$$$$$$_$$$$$$$_$$$$$$$`´$$$$$$´_ ___,,,,,,______`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_ _´$$$$$`____`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_ ´$$$$$$$$$`´$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_ ´$$$$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_ ___`$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$_$$$$$$´_ ______`$$$$$$$$$$$$$_$$$$$__$$_$$$$$$_$$´_ _______`$$$$$$$$$$$$,___,$$$$,_____,$$$$$´_ _________`$$$$$$$$$$$$$$$$$$$$$$$$$$$$$´_ __________`$$$$$$$$$$$$$$$$$$$$$$$$$$$´_ ____________`$$$$$$$$$$$$$$$$$$$$$$$$´_ _______________`$$$$$$$$$$$$$$$$$$$$´_ ~~( ŊëŌ )~~ From mmethw2003 at gmail.com Wed Feb 18 03:21:52 2015 From: mmethw2003 at gmail.com (Methsri Wickramarathna) Date: Wed, 18 Feb 2015 08:51:52 +0530 Subject: Usage Graphing per Subnet In-Reply-To: References: <54E32E59.6030401@linfre.de> <5938700.Yg2D3a4Z4C@linne> Message-ID: Chris , Thanks for the info... Let me explain my requirement .... My company has 3 upstream providers and we are serving more than 400 customers ..In that case we have to manage our upstream capacity... When considering capacity managing normally we just transfer a /24 from congested Up stream provider to non congested provider. Issue we have is we don't know exactly the usage of a /24 subnet before transfer. I hope you get an idea about my requirement :) :) :) On Wed, Feb 18, 2015 at 8:40 AM, Methsri Wickramarathna < mmethw2003 at gmail.com> wrote: > Karsten , thanks for replying.... > It's like this I don't want to take router info, only thing i want is to > graph the usage of my entire IP block per subnet wise. > Normaly we are using CACTI , MRTG , Observium etc... to gather router > information such as CPU , errors , usage etc... > > All the systems mentioned above use SNMP to gather info and when it comes > to usage it only poll to a particular interface and plot the usage ......I > hope you had an idea about my requirement :) > > > On Tue, Feb 17, 2015 at 11:53 PM, Karsten Thomann < > karsten_thomann at linfre.de> wrote: > >> Hi, >> >> in this case I fully agree with Armin's advice, only wanted to provide a >> possible way to archive an easy result without activation of netflow/sflow >> which is possible if all subnets had dedicated ports somewhere in the net. >> >> I don't know what information you want to get from your routers, as there >> are >> many ways to get a result depending on the information you want and the >> used >> vendors. >> >> Regards >> Karsten >> >> Am Dienstag, 17. Februar 2015, 22:01:18 schrieb Methsri Wickramarathna: >> > Thanks Armin , >> > I will try the SW you have mentioned seems like it's not easy to install >> > though :) :) >> > >> > Karsten, >> > I just bought out an example... my company has 2X18's and out of it we >> are >> > using considerable amount of /24s to access internet . Some subnets are >> > given without proper documentation , so it's very hard to do what you >> have >> > proposed. >> > What I can do is to install some kind of SW and gather info from my >> gateway >> > routers :( .....it's helpful if some one can guide me through this :) >> ... >> > >> > On Tue, Feb 17, 2015 at 5:34 PM, Karsten Thomann < >> karsten_thomann at linfre.de> >> > wrote: >> > > Hi, >> > > >> > > I'm not sure how it is exactly build, but if every /29 uses it's own >> port >> > > a tool like cacti/graphite where you're aggregating all required ports >> > > within one graph is easier. >> > > >> > > Regards >> > > Karsten >> > > >> > > Am 17.02.2015 12:47, schrieb Armin Kneip: >> > > Hi, >> > > >> > >> pmacct is your friend! >> > >> >> > >> http://www.pmacct.net/ >> > >> >> > >> >> > >> Regards, >> > >> Armin >> > >> >> > >> Am 17.02.2015 um 12:35 schrieb Methsri Wickramarathna: >> > >>> Hi All, I have a requirement to plot a usage graph per subnet. As an >> > >>> example. >> > >>> >> > >>> I have a 192.168.1.0/24 subnet divided among 32 customers where >> each one >> > >>> will get a /29 [ 192.168.1.0/29 => Customer A ; 192.168.1.8/29 => >> > >>> Customer >> > >>> B etc... ] ... >> > >>> >> > >>> Is there any tool to graph the usage of entire /24 subnet ??? >> >> > > > -- > -- > ________´$$$$`_____________________________,,,_ > _______´$$$$$$$`_________________________´$$$` > ________`$$$$$$$`______,,________,,_______´$$$$´ > _________`$$$$$$$`____´$$`_____´$$`____´$$$$$´ > __________`$$$$$$$`_´$$$$$`_´$$$$$`__´$$$$$$$´ > ___________`$$$$$$$_$$$$$$$_$$$$$$$_´$$$$$$$´_ > ____________`$$$$$$_$$$$$$$_$$$$$$$`´$$$$$$´_ > ___,,,,,,______`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_ > _´$$$$$`____`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_ > ´$$$$$$$$$`´$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_ > ´$$$$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_ > ___`$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$_$$$$$$´_ > ______`$$$$$$$$$$$$$_$$$$$__$$_$$$$$$_$$´_ > _______`$$$$$$$$$$$$,___,$$$$,_____,$$$$$´_ > _________`$$$$$$$$$$$$$$$$$$$$$$$$$$$$$´_ > __________`$$$$$$$$$$$$$$$$$$$$$$$$$$$´_ > ____________`$$$$$$$$$$$$$$$$$$$$$$$$´_ > _______________`$$$$$$$$$$$$$$$$$$$$´_ > > ~~( ŊëŌ )~~ > -- -- ________´$$$$`_____________________________,,,_ _______´$$$$$$$`_________________________´$$$` ________`$$$$$$$`______,,________,,_______´$$$$´ _________`$$$$$$$`____´$$`_____´$$`____´$$$$$´ __________`$$$$$$$`_´$$$$$`_´$$$$$`__´$$$$$$$´ ___________`$$$$$$$_$$$$$$$_$$$$$$$_´$$$$$$$´_ ____________`$$$$$$_$$$$$$$_$$$$$$$`´$$$$$$´_ ___,,,,,,______`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_ _´$$$$$`____`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_ ´$$$$$$$$$`´$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_ ´$$$$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_ ___`$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$_$$$$$$´_ ______`$$$$$$$$$$$$$_$$$$$__$$_$$$$$$_$$´_ _______`$$$$$$$$$$$$,___,$$$$,_____,$$$$$´_ _________`$$$$$$$$$$$$$$$$$$$$$$$$$$$$$´_ __________`$$$$$$$$$$$$$$$$$$$$$$$$$$$´_ ____________`$$$$$$$$$$$$$$$$$$$$$$$$´_ _______________`$$$$$$$$$$$$$$$$$$$$´_ ~~( ŊëŌ )~~ From streiner at cluebyfour.org Wed Feb 18 03:58:02 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 17 Feb 2015 22:58:02 -0500 (EST) Subject: Usage Graphing per Subnet In-Reply-To: References: <54E32E59.6030401@linfre.de> <5938700.Yg2D3a4Z4C@linne> Message-ID: On Wed, 18 Feb 2015, Methsri Wickramarathna wrote: > My company has 3 upstream providers and we are serving more than 400 > customers ..In that case we have to manage our upstream capacity... When > considering capacity managing normally we just transfer a /24 from > congested Up stream provider to non congested provider. > Issue we have is we don't know exactly the usage of a /24 subnet before > transfer. Netflow/sflow/IPFIX is most likely going to be the easiest/cleanest way to get the data you want. I would also recommend announcing a consistent set of prefixes to all 3 providers, and using mechanisms like AS-PATH prepending and/or whatever BGP communities each provider offers to do things like tweak preferences or do selective prepending, rather than shuffling prefixes between providers to achieve some level of traffic engineering, and also keeping your announcements aggregated as much as possible. Less routing table bloat and churn is a good thing. jms From rvandolson at esri.com Wed Feb 18 14:28:16 2015 From: rvandolson at esri.com (Ray Van Dolson) Date: Wed, 18 Feb 2015 06:28:16 -0800 Subject: OT - Small DNS "appliances" for remote offices. Message-ID: <20150218142816.GA17905@esri.com> Hopefully not too far off topic for this list. Am looking for options to deploy DNS caching resolvers at remote locations where there may only be minimal infrastructure (FW and Cisco equipment) and limited options for installing a noisier, more power hugnry servers or appliances from a vendor. Stuff like Infoblox is too expensive. We're BIND-based and leaning to stick that way, but open to other options if they present themselves. Am considering the Soekris net6501-50. I can dump a Linux image on there with our DNS config, indudstrial grade design, and OK performance. If the thing fails, clients will hopefully not notice due to anycast which will just hit another DNS server somewhere else on the network albeit with additional latency. We ship out a replacement device rather than mucking with trying to repair. There's also stuff like this[1] which probably gives me more horsepower on my CPU, but maybe not as reliable. Maybe I'm overengineering this. What do others do at smaller remote sites? Also considering putting resolvers only at "hub" locations in our MPLS network based on some latency-based radius. Ray [1] http://www.newegg.com/Mini-Booksize-Barebone-PCs/SubCategory/ID-309 From shaavik at soc.lib.md.us Wed Feb 18 15:00:01 2015 From: shaavik at soc.lib.md.us (Steve Haavik) Date: Wed, 18 Feb 2015 10:00:01 -0500 (EST) Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <20150218142816.GA17905@esri.com> References: <20150218142816.GA17905@esri.com> Message-ID: Well, if they ever manage to get them into production, I'm hoping to talk my boss into buying some of these. http://www.fit-pc.com/web/products/fitlet/ We'd just need to figure out a rackmount bracket of some sort. Hide them in the case of our previous gen hardware maybe??? Screw them to a cheap rackmount shelf??? Failing that, I've pointed out that we could afford to put a Raspberry Pi in every one of our sites for less than we paid for the last batch of dns servers. From alter3d at alter3d.ca Wed Feb 18 15:03:27 2015 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Wed, 18 Feb 2015 10:03:27 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <20150218142816.GA17905@esri.com> References: <20150218142816.GA17905@esri.com> Message-ID: <54E4A9BF.5000006@alter3d.ca> Not "industrial grade", but Raspberry Pis are pretty great for this kind of low-horsepower application. Throw 2 at each site for redundancy and you have a low-powered, physically small, cheap, dead silent, easily replaceable system for ~$150 per site. Same idea as the Soekris -- just ship out replacements instead of trying to repair -- but even cheaper. Between having 2 (or more) at each site, plus cross-site redundancy via anycast, it would be pretty robust (and cheap enough that you could have cold-spares at each site). On 02/18/2015 09:28 AM, Ray Van Dolson wrote: > Hopefully not too far off topic for this list. > > Am looking for options to deploy DNS caching resolvers at remote > locations where there may only be minimal infrastructure (FW and Cisco > equipment) and limited options for installing a noisier, more power > hugnry servers or appliances from a vendor. Stuff like Infoblox is > too expensive. > > We're BIND-based and leaning to stick that way, but open to other > options if they present themselves. > > Am considering the Soekris net6501-50. I can dump a Linux image on > there with our DNS config, indudstrial grade design, and OK > performance. If the thing fails, clients will hopefully not notice due > to anycast which will just hit another DNS server somewhere else on the > network albeit with additional latency. We ship out a replacement > device rather than mucking with trying to repair. > > There's also stuff like this[1] which probably gives me more horsepower > on my CPU, but maybe not as reliable. > > Maybe I'm overengineering this. What do others do at smaller remote > sites? Also considering putting resolvers only at "hub" locations in > our MPLS network based on some latency-based radius. > > Ray > > [1] http://www.newegg.com/Mini-Booksize-Barebone-PCs/SubCategory/ID-309 From colinj at gt86car.org.uk Wed Feb 18 15:04:01 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Wed, 18 Feb 2015 15:04:01 +0000 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <20150218142816.GA17905@esri.com> References: <20150218142816.GA17905@esri.com> Message-ID: <0E66E0D7-6619-4B29-8E24-AFAC61BB05C0@gt86car.org.uk> use a vm dns appliance on the same machine as your vm router instance Colin > On 18 Feb 2015, at 14:28, Ray Van Dolson wrote: > > Hopefully not too far off topic for this list. > > Am looking for options to deploy DNS caching resolvers at remote > locations where there may only be minimal infrastructure (FW and Cisco > equipment) and limited options for installing a noisier, more power > hugnry servers or appliances from a vendor. Stuff like Infoblox is > too expensive. > > We're BIND-based and leaning to stick that way, but open to other > options if they present themselves. > > Am considering the Soekris net6501-50. I can dump a Linux image on > there with our DNS config, indudstrial grade design, and OK > performance. If the thing fails, clients will hopefully not notice due > to anycast which will just hit another DNS server somewhere else on the > network albeit with additional latency. We ship out a replacement > device rather than mucking with trying to repair. > > There's also stuff like this[1] which probably gives me more horsepower > on my CPU, but maybe not as reliable. > > Maybe I'm overengineering this. What do others do at smaller remote > sites? Also considering putting resolvers only at "hub" locations in > our MPLS network based on some latency-based radius. > > Ray > > [1] http://www.newegg.com/Mini-Booksize-Barebone-PCs/SubCategory/ID-309 From BScavotto at BBandT.com Tue Feb 17 13:39:05 2015 From: BScavotto at BBandT.com (Scavotto, Brian) Date: Tue, 17 Feb 2015 13:39:05 +0000 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: I'm not sure if it's been mentioned, but for a business of your size...check out SecurityOnion. It's everything you need in one easy package and it's free. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Andy Ringsmuth Sent: Friday, February 13, 2015 12:40 PM To: NANOG Subject: Intrusion Detection recommendations NANOG'ers, I've been tasked by our company president to learn about, investigate and recommend an intrusion detection system for our company. We're a smaller outfit, less than 100 employees, entirely Apple-based. Macs, iPhones, some Mac Mini servers, etc., and a fiber connection to the world. We are protected by a FreeBSD firewall setup, and we stay current on updates/patches from Apple and FreeBSD, but that's as far as my expertise goes. Initially, what do people recommend for: 1. Crash course in intrusion detection as a whole 2. Suggestions or recommendations for intrusion detection hardware or software 3. Other things I'm likely overlooking Thank you all in advance for your wisdom. ---- 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 The information in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission. From rs at seastrom.com Wed Feb 18 15:22:24 2015 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 18 Feb 2015 10:22:24 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <54E4A9BF.5000006@alter3d.ca> (Peter Kristolaitis's message of "Wed, 18 Feb 2015 10:03:27 -0500") References: <20150218142816.GA17905@esri.com> <54E4A9BF.5000006@alter3d.ca> Message-ID: <86r3tn6y8f.fsf@valhalla.seastrom.com> Peter Kristolaitis writes: > Not "industrial grade", but Raspberry Pis are pretty great for this > kind of low-horsepower application. Throw 2 at each site for > redundancy and you have a low-powered, physically small, cheap, dead > silent, easily replaceable system for ~$150 per site. The Pi is low-powered in more ways than one. Last fall I ran some (admittedly fairly simple minded) DNS benchmarks against a Raspberry Pi Model B and an ODROID U3. Particularly if you have DNSSEC validation enabled, the Pi is underwhelming in performance (81 qps in the validation case, 164 without). The U3 is circa 325 qps with or without DNSSEC validation on, which suggests that something else other than crypto-computes is the long pole in the tent. I haven't gotten motivated to try this against the ODROID-C1 that I acquired later in December, nor have I sourced a Raspberry Pi 2. For anyone who's feeling motivated to do this (please send along results!), the methodology I used is at http://technotes.seastrom.com/node/53 -r PS: don't miss the opportunity to run real honest-to-god isc-dhcpd on same machine rather than whatever your router provides you; you'll be glad you did. From mel at beckman.org Wed Feb 18 15:42:38 2015 From: mel at beckman.org (Mel Beckman) Date: Wed, 18 Feb 2015 15:42:38 +0000 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <86r3tn6y8f.fsf@valhalla.seastrom.com> References: <20150218142816.GA17905@esri.com> <54E4A9BF.5000006@alter3d.ca>,<86r3tn6y8f.fsf@valhalla.seastrom.com> Message-ID: <5B106864-69EA-4625-BE77-76F033CE503C@beckman.org> We use Mac Minis; $500 each anywhere plus $25 (!) for all the server components, dead silent, and ready to go with Bind installed out of the box. You can also enable dhcpd and all manner of other stock BSD services. There are "helper" GUI tools for the non-CLI admin built into the Server toolkit. Way fast, extremely secure, and IPv6 ready. http://arstechnica.com/apple/2014/11/a-power-users-guide-to-os-x-server-yosemite-edition/11/ Yes, this hardware costs a bit more than the mini box Pcs,mbut you make up for that in reduced setup labor. -mel beckman > On Feb 18, 2015, at 7:22 AM, "Rob Seastrom" wrote: > > > Peter Kristolaitis writes: > >> Not "industrial grade", but Raspberry Pis are pretty great for this >> kind of low-horsepower application. Throw 2 at each site for >> redundancy and you have a low-powered, physically small, cheap, dead >> silent, easily replaceable system for ~$150 per site. > > The Pi is low-powered in more ways than one. Last fall I ran some > (admittedly fairly simple minded) DNS benchmarks against a Raspberry > Pi Model B and an ODROID U3. > > Particularly if you have DNSSEC validation enabled, the Pi is > underwhelming in performance (81 qps in the validation case, 164 > without). > > The U3 is circa 325 qps with or without DNSSEC validation on, which > suggests that something else other than crypto-computes is the long > pole in the tent. > > I haven't gotten motivated to try this against the ODROID-C1 that I > acquired later in December, nor have I sourced a Raspberry Pi 2. For > anyone who's feeling motivated to do this (please send along > results!), the methodology I used is at http://technotes.seastrom.com/node/53 > > -r > > PS: don't miss the opportunity to run real honest-to-god isc-dhcpd on > same machine rather than whatever your router provides you; you'll be > glad you did. > From wayne at staff.msen.com Wed Feb 18 15:44:47 2015 From: wayne at staff.msen.com (Michael R. Wayne) Date: Wed, 18 Feb 2015 10:44:47 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <20150218142816.GA17905@esri.com> References: <20150218142816.GA17905@esri.com> Message-ID: <20150218154447.GA10676@manor.msen.com> On Wed, Feb 18, 2015 at 06:28:16AM -0800, Ray Van Dolson wrote: > > Am looking for options to deploy DNS caching resolvers at remote > locations where there may only be minimal infrastructure I suspect that this could be done using an ERLite but have not actually tried it. From cma at cmadams.net Wed Feb 18 15:45:22 2015 From: cma at cmadams.net (Chris Adams) Date: Wed, 18 Feb 2015 09:45:22 -0600 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <86r3tn6y8f.fsf@valhalla.seastrom.com> References: <20150218142816.GA17905@esri.com> <54E4A9BF.5000006@alter3d.ca> <86r3tn6y8f.fsf@valhalla.seastrom.com> Message-ID: <20150218154522.GA8569@cmadams.net> Once upon a time, Rob Seastrom said: > The Pi is low-powered in more ways than one. Last fall I ran some > (admittedly fairly simple minded) DNS benchmarks against a Raspberry > Pi Model B and an ODROID U3. The Pi is not really the right tool for any "production" job IMHO. Even if you are restricting yourself to cheap single-board ARM systems, there are better choices like BeagleBone, Cubieboard, etc. If you need a little more power (and want x86 to make things easier), go for a Minnowboard or the like. All of these are "hobbiest" solutions though. If you want cheap and compact DNS for a not-too-high request rate, just get a cheap wifi router that'll run a flavor of Open Source firmware (I prefer OpenWRT). Disable the wifi and run dnsmasq or bind (peruse the OpenWRT supported device page to check RAM capacity). Beyond that, or if you want a rack-mount solution, get an Atom CPU based barebones, like a SuperMicro, use an SSD, and it'll be relatively quiet (and at least the SuperMicros have IPMI built in for remote management). -- Chris Adams From anders at abundo.se Wed Feb 18 16:10:30 2015 From: anders at abundo.se (=?UTF-8?Q?Anders_L=C3=B6winger?=) Date: Wed, 18 Feb 2015 17:10:30 +0100 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <20150218154522.GA8569@cmadams.net> References: <20150218142816.GA17905@esri.com> <54E4A9BF.5000006@alter3d.ca> <86r3tn6y8f.fsf@valhalla.seastrom.com> <20150218154522.GA8569@cmadams.net> Message-ID: I really like the Intel NUC. Standard x86 hardware, multiple choices of CPUs, runs debian/ubuntu/fedora etc with zero modifications. /Anders MVH / Regards Anders Löwinger Founder, Senior Consultant Abundo AB Murkelgränd 6 94471 Piteåhttp://abundo.se office: +46 911 400021 mobile: +46 72 206 0322 2015-02-18 16:45 GMT+01:00 Chris Adams : > Once upon a time, Rob Seastrom said: > > The Pi is low-powered in more ways than one. Last fall I ran some > > (admittedly fairly simple minded) DNS benchmarks against a Raspberry > > Pi Model B and an ODROID U3. > > The Pi is not really the right tool for any "production" job IMHO. Even > if you are restricting yourself to cheap single-board ARM systems, there > are better choices like BeagleBone, Cubieboard, etc. If you need a > little more power (and want x86 to make things easier), go for a > Minnowboard or the like. All of these are "hobbiest" solutions though. > > If you want cheap and compact DNS for a not-too-high request rate, just > get a cheap wifi router that'll run a flavor of Open Source firmware (I > prefer OpenWRT). Disable the wifi and run dnsmasq or bind (peruse the > OpenWRT supported device page to check RAM capacity). > > Beyond that, or if you want a rack-mount solution, get an Atom CPU based > barebones, like a SuperMicro, use an SSD, and it'll be relatively quiet > (and at least the SuperMicros have IPMI built in for remote management). > > -- > Chris Adams > From david.reader at zeninternet.co.uk Wed Feb 18 16:55:25 2015 From: david.reader at zeninternet.co.uk (David Reader) Date: Wed, 18 Feb 2015 16:55:25 +0000 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <20150218142816.GA17905@esri.com> References: <20150218142816.GA17905@esri.com> Message-ID: <20150218165525.d352813a.david.reader@zeninternet.co.uk> On Wed, 18 Feb 2015 06:28:16 -0800 Ray Van Dolson wrote: > Hopefully not too far off topic for this list. > > Am looking for options to deploy DNS caching resolvers at remote > locations > We're BIND-based and leaning to stick that way, but open to other > options if they present themselves. I've found that "unbound" is lighter on the machine, but it does depends what you require feature-wise and/or operationally, of course. > Am considering the Soekris net6501-50. I can dump a Linux image on > there with our DNS config, indudstrial grade design, and OK > performance. If the thing fails, clients will hopefully not notice due > to anycast which will just hit another DNS server somewhere else on the > network albeit with additional latency. We ship out a replacement > device rather than mucking with trying to repair. If you're looking at Soekris, you might also find the PCEngines products interesting. The "APU" series appears similar at a glance - and they do offer a case (not rackmount, sadly - although 3rd parties might) to suit. http://www.pcengines.ch/apu.htm At the lower end, the "ALIX" boards are available in a standard 100mm x 160mm "eurocard" format which makes them very easy to rack up.. https://www.dropbox.com/s/81p75pyz1ngsvm6/DSCN0916.JPG?dl=0 Whichever way you do it, a small low-power box running entirely from flash or ssd is likely to be a good "fit and forget" (security updates aside!) solution. If you want to run from a cheap flash card, and are a linux shop, http://linux.voyage.hk/ is a debian-derived system targetting the PCEngines boards which runs with a read-only filesystem. d. From techravingmad at gmail.com Wed Feb 18 17:13:40 2015 From: techravingmad at gmail.com (Glenn Robuck) Date: Wed, 18 Feb 2015 11:13:40 -0600 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <20150218165525.d352813a.david.reader@zeninternet.co.uk> References: <20150218142816.GA17905@esri.com> <20150218165525.d352813a.david.reader@zeninternet.co.uk> Message-ID: We recently installed one of these basically as digital signage, but I think it should work fine for your needs too. We've had no issues with it at all. (we installed ubuntu) It's the ECS Liva mini-pc http://www.ecs.com.tw/ECSWebSite/Product/Product_LIVA.aspx?DetailID=1560&LanID=0 On Wed, Feb 18, 2015 at 10:55 AM, David Reader < david.reader at zeninternet.co.uk> wrote: > On Wed, 18 Feb 2015 06:28:16 -0800 > Ray Van Dolson wrote: > > > Hopefully not too far off topic for this list. > > > > Am looking for options to deploy DNS caching resolvers at remote > > locations > > > We're BIND-based and leaning to stick that way, but open to other > > options if they present themselves. > > I've found that "unbound" is lighter on the machine, but it does depends > what you require feature-wise and/or operationally, of course. > > > Am considering the Soekris net6501-50. I can dump a Linux image on > > there with our DNS config, indudstrial grade design, and OK > > performance. If the thing fails, clients will hopefully not notice due > > to anycast which will just hit another DNS server somewhere else on the > > network albeit with additional latency. We ship out a replacement > > device rather than mucking with trying to repair. > > If you're looking at Soekris, you might also find the PCEngines products > interesting. > > The "APU" series appears similar at a glance - and they do offer a case > (not rackmount, sadly - although 3rd parties might) to suit. > > http://www.pcengines.ch/apu.htm > > At the lower end, the "ALIX" boards are available in a standard 100mm x > 160mm "eurocard" format which makes them very easy to rack up.. > > https://www.dropbox.com/s/81p75pyz1ngsvm6/DSCN0916.JPG?dl=0 > > Whichever way you do it, a small low-power box running entirely from flash > or ssd is likely to be a good "fit and forget" (security updates aside!) > solution. > > If you want to run from a cheap flash card, and are a linux shop, > http://linux.voyage.hk/ is a debian-derived system targetting the > PCEngines boards which runs with a read-only filesystem. > > d. > From michael.bubb at gmail.com Wed Feb 18 17:32:35 2015 From: michael.bubb at gmail.com (Michael Bubb) Date: Wed, 18 Feb 2015 12:32:35 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <20150218142816.GA17905@esri.com> References: <20150218142816.GA17905@esri.com> Message-ID: What is your desired cost per unit? Reminds me of needing small pfsense based boxes a few years back. Used this company's hardware: http://www.logicsupply.com/computers/solutions/firewall-networking/ I bet you could get something fairly rugged and low maintenance for $400 or so. On Wed, Feb 18, 2015 at 9:28 AM, Ray Van Dolson wrote: > Hopefully not too far off topic for this list. > > Am looking for options to deploy DNS caching resolvers at remote > locations where there may only be minimal infrastructure (FW and Cisco > equipment) and limited options for installing a noisier, more power > hugnry servers or appliances from a vendor. Stuff like Infoblox is > too expensive. > > We're BIND-based and leaning to stick that way, but open to other > options if they present themselves. > > Am considering the Soekris net6501-50. I can dump a Linux image on > there with our DNS config, indudstrial grade design, and OK > performance. If the thing fails, clients will hopefully not notice due > to anycast which will just hit another DNS server somewhere else on the > network albeit with additional latency. We ship out a replacement > device rather than mucking with trying to repair. > > There's also stuff like this[1] which probably gives me more horsepower > on my CPU, but maybe not as reliable. > > Maybe I'm overengineering this. What do others do at smaller remote > sites? Also considering putting resolvers only at "hub" locations in > our MPLS network based on some latency-based radius. > > Ray > > [1] http://www.newegg.com/Mini-Booksize-Barebone-PCs/SubCategory/ID-309 > -- Michael Bubb +1.646.783.8769 | KD2DTY Resume - http://mbubb.devio.us/res/resume.html *noli timere* From lists at mtin.net Wed Feb 18 18:01:22 2015 From: lists at mtin.net (Justin Wilson - MTIN) Date: Wed, 18 Feb 2015 13:01:22 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: References: <20150218142816.GA17905@esri.com> Message-ID: <3DF4E794-78D1-43D3-B41E-87FE7803242F@mtin.net> Have you looked at Mikrotik? www.mikrotik.com It may be lacking for DNS options you want, but worth a look. Justin Justin Wilson j2sw at mtin.net http://www.mtin.net Managed Services – xISP Solutions – Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering – Transit – Internet Exchange > On Feb 18, 2015, at 12:32 PM, Michael Bubb wrote: > > What is your desired cost per unit? > > Reminds me of needing small pfsense based boxes a few years back. Used this > company's hardware: > > http://www.logicsupply.com/computers/solutions/firewall-networking/ > > I bet you could get something fairly rugged and low maintenance for $400 or > so. > > On Wed, Feb 18, 2015 at 9:28 AM, Ray Van Dolson wrote: > >> Hopefully not too far off topic for this list. >> >> Am looking for options to deploy DNS caching resolvers at remote >> locations where there may only be minimal infrastructure (FW and Cisco >> equipment) and limited options for installing a noisier, more power >> hugnry servers or appliances from a vendor. Stuff like Infoblox is >> too expensive. >> >> We're BIND-based and leaning to stick that way, but open to other >> options if they present themselves. >> >> Am considering the Soekris net6501-50. I can dump a Linux image on >> there with our DNS config, indudstrial grade design, and OK >> performance. If the thing fails, clients will hopefully not notice due >> to anycast which will just hit another DNS server somewhere else on the >> network albeit with additional latency. We ship out a replacement >> device rather than mucking with trying to repair. >> >> There's also stuff like this[1] which probably gives me more horsepower >> on my CPU, but maybe not as reliable. >> >> Maybe I'm overengineering this. What do others do at smaller remote >> sites? Also considering putting resolvers only at "hub" locations in >> our MPLS network based on some latency-based radius. >> >> Ray >> >> [1] http://www.newegg.com/Mini-Booksize-Barebone-PCs/SubCategory/ID-309 >> > > > > -- > Michael Bubb +1.646.783.8769 | KD2DTY > Resume - http://mbubb.devio.us/res/resume.html > > *noli timere* > From eliezer at ngtech.co.il Wed Feb 18 19:37:26 2015 From: eliezer at ngtech.co.il (Eliezer Croitoru) Date: Wed, 18 Feb 2015 21:37:26 +0200 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <20150218142816.GA17905@esri.com> References: <20150218142816.GA17905@esri.com> Message-ID: <54E4E9F6.8020406@ngtech.co.il> Hey Ray, Most tiny routers with 64MB ram are able to run a cache dns service while not all of them have the same level such as BIND but rather dnsmasq. I think that it's not always a bad choice and it depends on what other infrastructure needs you have in these remote locations. Someone mentioned mikrotik and they use some kind of caching daemon which might even be dnsmasq under the hood. I would first make sure what is the reliability that you need which means if you have a FW and Cisco then you will might want something more then a basic TP-LINK router.(which maybe the right choice...) Assuming this infrastructure is big enough you will prefer a basic mikrotik for the cost and support. All The Bests, Eliezer On 18/02/2015 16:28, Ray Van Dolson wrote: > Hopefully not too far off topic for this list. > > Am looking for options to deploy DNS caching resolvers at remote > locations where there may only be minimal infrastructure (FW and Cisco > equipment) and limited options for installing a noisier, more power > hugnry servers or appliances from a vendor. Stuff like Infoblox is > too expensive. From rs at seastrom.com Wed Feb 18 19:43:54 2015 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 18 Feb 2015 14:43:54 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <3DF4E794-78D1-43D3-B41E-87FE7803242F@mtin.net> (Justin Wilson's message of "Wed, 18 Feb 2015 13:01:22 -0500") References: <20150218142816.GA17905@esri.com> <3DF4E794-78D1-43D3-B41E-87FE7803242F@mtin.net> Message-ID: <863863t37p.fsf@valhalla.seastrom.com> Justin Wilson - MTIN writes: > Have you looked at Mikrotik? > www.mikrotik.com > > It may be lacking for DNS options you want, but worth a look. I'd definitely recommend mikrotik for a cheap and cheerful router. DNS server (the original subject of this message)? Not so much. -r From joe at nethead.com Wed Feb 18 20:44:23 2015 From: joe at nethead.com (Joe Hamelin) Date: Wed, 18 Feb 2015 12:44:23 -0800 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <863863t37p.fsf@valhalla.seastrom.com> References: <20150218142816.GA17905@esri.com> <3DF4E794-78D1-43D3-B41E-87FE7803242F@mtin.net> <863863t37p.fsf@valhalla.seastrom.com> Message-ID: I used one of these for a NAT/DNS box running FreeBSD for connection to our WiFi system. One nice thing is the 4 real serial ports. http://www.amazon.com/Qotom-I37C4-Bluetooth-Computer-Industrial-Computer/dp/B00MQKJYY0 -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Wed, Feb 18, 2015 at 11:43 AM, Rob Seastrom wrote: > > Justin Wilson - MTIN writes: > > > Have you looked at Mikrotik? > > www.mikrotik.com > > > > It may be lacking for DNS options you want, but worth a look. > > I'd definitely recommend mikrotik for a cheap and cheerful router. > > DNS server (the original subject of this message)? Not so much. > > -r > > From mcole.mailinglists at gmail.com Wed Feb 18 15:21:42 2015 From: mcole.mailinglists at gmail.com (Maxwell Cole) Date: Wed, 18 Feb 2015 10:21:42 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <54E4A9BF.5000006@alter3d.ca> References: <20150218142816.GA17905@esri.com> <54E4A9BF.5000006@alter3d.ca> Message-ID: <54E4AE06.8010804@gmail.com> +1 for the pi, The new model has a quad core and 1GB of ram which should be more than enough for a DNS. On 2/18/15 10:03 AM, Peter Kristolaitis wrote: > Not "industrial grade", but Raspberry Pis are pretty great for this > kind of low-horsepower application. Throw 2 at each site for > redundancy and you have a low-powered, physically small, cheap, dead > silent, easily replaceable system for ~$150 per site. Same idea as > the Soekris -- just ship out replacements instead of trying to repair > -- but even cheaper. > > Between having 2 (or more) at each site, plus cross-site redundancy > via anycast, it would be pretty robust (and cheap enough that you > could have cold-spares at each site). > > > > On 02/18/2015 09:28 AM, Ray Van Dolson wrote: >> Hopefully not too far off topic for this list. >> >> Am looking for options to deploy DNS caching resolvers at remote >> locations where there may only be minimal infrastructure (FW and Cisco >> equipment) and limited options for installing a noisier, more power >> hugnry servers or appliances from a vendor. Stuff like Infoblox is >> too expensive. >> >> We're BIND-based and leaning to stick that way, but open to other >> options if they present themselves. >> >> Am considering the Soekris net6501-50. I can dump a Linux image on >> there with our DNS config, indudstrial grade design, and OK >> performance. If the thing fails, clients will hopefully not notice due >> to anycast which will just hit another DNS server somewhere else on the >> network albeit with additional latency. We ship out a replacement >> device rather than mucking with trying to repair. >> >> There's also stuff like this[1] which probably gives me more horsepower >> on my CPU, but maybe not as reliable. >> >> Maybe I'm overengineering this. What do others do at smaller remote >> sites? Also considering putting resolvers only at "hub" locations in >> our MPLS network based on some latency-based radius. >> >> Ray >> >> [1] http://www.newegg.com/Mini-Booksize-Barebone-PCs/SubCategory/ID-309 > > From vwittkop at nanog.org Wed Feb 18 21:47:09 2015 From: vwittkop at nanog.org (Valerie Wittkop) Date: Wed, 18 Feb 2015 16:47:09 -0500 Subject: [NANOG-announce] Don't Forget: ARIN+NANOG On The Road - Orlando Message-ID: <0F655601-DB7D-40EF-8696-5C6F5C3F1E5F@nanog.org> The next On The Road event is just a few short days away… We invite you to join us at: ARIN+NANOG On The Road - Orlando Tuesday, 24 February 2015 9:00 AM – 5:00 PM; Reception: 5:00 PM – 6:30 PM Eastern Time Register at: https://www.nanog.org/meetings/road5/registration ARIN + NANOG On The Road is hosted by the American Registry for Internet Numbers (ARIN ) and the North American Network Operators’ Group (NANOG ). If you are, or will be, in the Orlando area, we invite you to attend this meeting . The agenda features an “Open Internet Debate” keynote address; sessions will include an ARIN Overview along with policies under discussion, DNSSEC & RPKI, presentations on IPv6, Traceroute, updates on local IX activities, and an introduction to BGP. This free event, held at the Holiday Inn Resort Orlando-Lake Buena Vista, will also feature interactive discussions and networking opportunities. Lunch will be provided and there will be two drawings for $100 Amazon gift cards. Please register today! Make ARIN+NANOG On The Road your first step toward learning how you can take the wheel and steer the future of the Internet. Please share this invitation with anyone you feel may benefit from attending this meeting. Learn more about On The Road events here . Feel free to contact us at nanog-support at nanog.org if you have any questions. Regards, Valerie Valerie Wittkop NANOG Program 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 rsk at gsp.org Wed Feb 18 22:11:23 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 18 Feb 2015 17:11:23 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <20150218142816.GA17905@esri.com> References: <20150218142816.GA17905@esri.com> Message-ID: <20150218221123.GA14885@gsp.org> Find someone unloading 50 old, physically small desktop PCs. Buy the lot. Drop OpenBSD and BIND on them, ship 3 to every site, run 1 or 2 live with the leftovers as on-site spares. If one breaks, wipe the disk and send the box to recycling. (Just checked: someone on a certain auction site is selling a lot of 64 HP Compaq 8000 (3.16GHz, 2GB) systems, current price $1K.) ---rsk From peterl at standingwave.org Wed Feb 18 22:31:00 2015 From: peterl at standingwave.org (Peter Loron) Date: Wed, 18 Feb 2015 14:31:00 -0800 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <54E4AE06.8010804@gmail.com> References: <20150218142816.GA17905@esri.com> <54E4A9BF.5000006@alter3d.ca> <54E4AE06.8010804@gmail.com> Message-ID: And the new CPU is ARM7 so hardfloat is supported. Should make a nifty DNS box. -Pete On 2015-02-18 07:21, Maxwell Cole wrote: > +1 for the pi, > > The new model has a quad core and 1GB of ram which should be more than > enough for a DNS. > > On 2/18/15 10:03 AM, Peter Kristolaitis wrote: >> Not "industrial grade", but Raspberry Pis are pretty great for this >> kind of low-horsepower application. Throw 2 at each site for >> redundancy and you have a low-powered, physically small, cheap, dead >> silent, easily replaceable system for ~$150 per site. Same idea as >> the Soekris -- just ship out replacements instead of trying to repair >> -- but even cheaper. >> >> Between having 2 (or more) at each site, plus cross-site redundancy >> via anycast, it would be pretty robust (and cheap enough that you >> could have cold-spares at each site). >> >> >> >> On 02/18/2015 09:28 AM, Ray Van Dolson wrote: >>> Hopefully not too far off topic for this list. >>> >>> Am looking for options to deploy DNS caching resolvers at remote >>> locations where there may only be minimal infrastructure (FW and >>> Cisco >>> equipment) and limited options for installing a noisier, more power >>> hugnry servers or appliances from a vendor. Stuff like Infoblox is >>> too expensive. >>> >>> We're BIND-based and leaning to stick that way, but open to other >>> options if they present themselves. >>> >>> Am considering the Soekris net6501-50. I can dump a Linux image on >>> there with our DNS config, indudstrial grade design, and OK >>> performance. If the thing fails, clients will hopefully not notice >>> due >>> to anycast which will just hit another DNS server somewhere else on >>> the >>> network albeit with additional latency. We ship out a replacement >>> device rather than mucking with trying to repair. >>> >>> There's also stuff like this[1] which probably gives me more >>> horsepower >>> on my CPU, but maybe not as reliable. >>> >>> Maybe I'm overengineering this. What do others do at smaller remote >>> sites? Also considering putting resolvers only at "hub" locations in >>> our MPLS network based on some latency-based radius. >>> >>> Ray >>> >>> [1] >>> http://www.newegg.com/Mini-Booksize-Barebone-PCs/SubCategory/ID-309 >> >> From nellermann at broadaspect.com Wed Feb 18 22:31:34 2015 From: nellermann at broadaspect.com (Nick Ellermann) Date: Wed, 18 Feb 2015 22:31:34 +0000 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <54E4AE06.8010804@gmail.com> References: <20150218142816.GA17905@esri.com> <54E4A9BF.5000006@alter3d.ca>,<54E4AE06.8010804@gmail.com> Message-ID: Sounds coo with the pi idea. Not sure of the cache level you need but we have great success with fortigates performing firewall and local DNS host even for a small remote site that is part of an MS AD via a VPN tunnel. It can be setup and managed just like a DNS server. No extra devices to learn or manage! Nick Ellermann ~Sent from my iPhone~ On Feb 18, 2015, at 4:08 PM, Maxwell Cole wrote: +1 for the pi, The new model has a quad core and 1GB of ram which should be more than enough for a DNS. > On 2/18/15 10:03 AM, Peter Kristolaitis wrote: > Not "industrial grade", but Raspberry Pis are pretty great for this kind of low-horsepower application. Throw 2 at each site for redundancy and you have a low-powered, physically small, cheap, dead silent, easily replaceable system for ~$150 per site. Same idea as the Soekris -- just ship out replacements instead of trying to repair -- but even cheaper. > > Between having 2 (or more) at each site, plus cross-site redundancy via anycast, it would be pretty robust (and cheap enough that you could have cold-spares at each site). > > > >> On 02/18/2015 09:28 AM, Ray Van Dolson wrote: >> Hopefully not too far off topic for this list. >> >> Am looking for options to deploy DNS caching resolvers at remote >> locations where there may only be minimal infrastructure (FW and Cisco >> equipment) and limited options for installing a noisier, more power >> hugnry servers or appliances from a vendor. Stuff like Infoblox is >> too expensive. >> >> We're BIND-based and leaning to stick that way, but open to other >> options if they present themselves. >> >> Am considering the Soekris net6501-50. I can dump a Linux image on >> there with our DNS config, indudstrial grade design, and OK >> performance. If the thing fails, clients will hopefully not notice due >> to anycast which will just hit another DNS server somewhere else on the >> network albeit with additional latency. We ship out a replacement >> device rather than mucking with trying to repair. >> >> There's also stuff like this[1] which probably gives me more horsepower >> on my CPU, but maybe not as reliable. >> >> Maybe I'm overengineering this. What do others do at smaller remote >> sites? Also considering putting resolvers only at "hub" locations in >> our MPLS network based on some latency-based radius. >> >> Ray >> >> [1] http://www.newegg.com/Mini-Booksize-Barebone-PCs/SubCategory/ID-309 From baldur.norddahl at gmail.com Wed Feb 18 22:32:14 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 18 Feb 2015 23:32:14 +0100 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <20150218221123.GA14885@gsp.org> References: <20150218142816.GA17905@esri.com> <20150218221123.GA14885@gsp.org> Message-ID: That option is expensive in power fees... Den 18/02/2015 23.12 skrev "Rich Kulawiec" : > > Find someone unloading 50 old, physically small desktop PCs. Buy the > lot. Drop OpenBSD and BIND on them, ship 3 to every site, run 1 or 2 > live with the leftovers as on-site spares. If one breaks, wipe the disk > and send the box to recycling. > > (Just checked: someone on a certain auction site is selling a lot of 64 > HP Compaq 8000 (3.16GHz, 2GB) systems, current price $1K.) > > ---rsk > From rwebb at ropeguru.com Wed Feb 18 23:08:46 2015 From: rwebb at ropeguru.com (Robert Webb) Date: Wed, 18 Feb 2015 18:08:46 -0500 Subject: OT - Small DNS "appliances" for remote offices. Message-ID: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> What I do not like about the Pi is the network port is on the USB bus and thus limited to USB speeds. 
-------- Original message --------
From: Maxwell Cole
Date:02/18/2015 4:30 PM (GMT-05:00)
To: "nanog at nanog.org >> 'NANOG list'"
Subject: Re: OT - Small DNS "appliances" for remote offices.
From peterl at standingwave.org Wed Feb 18 23:44:28 2015 From: peterl at standingwave.org (Peter Loron) Date: Wed, 18 Feb 2015 15:44:28 -0800 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> Message-ID: <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> For any site where you would use a Pi as the DNS cache, it won't be an issue. DNS isn't that heavy at those query rates. Yeah, it would be awesome if they'd been able to get a SoC that included ethernet. -Pete On 2015-02-18 15:08, Robert Webb wrote: > What I do not like about the Pi is the network port is on the USB bus > and thus limited to USB speeds.  > >
-------- Original message --------
From: Maxwell Cole >
Date:02/18/2015 4:30 PM > (GMT-05:00)
To: "nanog at nanog.org >> 'NANOG list'" >
Subject: Re: OT - Small DNS "appliances" > for remote offices.
>
From peterl at standingwave.org Wed Feb 18 23:45:26 2015 From: peterl at standingwave.org (Peter Loron) Date: Wed, 18 Feb 2015 15:45:26 -0800 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: References: <20150218142816.GA17905@esri.com> <20150218221123.GA14885@gsp.org> Message-ID: Not to mention reliability issues with old machines...fans failing, leaky capacitors, etc, etc. -Pete On 2015-02-18 14:32, Baldur Norddahl wrote: > That option is expensive in power fees... > Den 18/02/2015 23.12 skrev "Rich Kulawiec" : > >> >> Find someone unloading 50 old, physically small desktop PCs. Buy the >> lot. Drop OpenBSD and BIND on them, ship 3 to every site, run 1 or 2 >> live with the leftovers as on-site spares. If one breaks, wipe the >> disk >> and send the box to recycling. >> >> (Just checked: someone on a certain auction site is selling a lot of >> 64 >> HP Compaq 8000 (3.16GHz, 2GB) systems, current price $1K.) >> >> ---rsk >> From nanog08 at mulligan.org Thu Feb 19 00:02:49 2015 From: nanog08 at mulligan.org (Geoff Mulligan) Date: Wed, 18 Feb 2015 17:02:49 -0700 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> Message-ID: <54E52829.8090509@mulligan.org> I have used the BeagleBone to run a few simple servers. I don't know if the ethernet port on the Bone is on the USB bus. It is slightly more expensive than a PI, but they have worked well for me. Geoff On 02/18/2015 04:44 PM, Peter Loron wrote: > For any site where you would use a Pi as the DNS cache, it won't be an > issue. DNS isn't that heavy at those query rates. > > Yeah, it would be awesome if they'd been able to get a SoC that > included ethernet. > > -Pete > > On 2015-02-18 15:08, Robert Webb wrote: >> What I do not like about the Pi is the network port is on the USB bus >> and thus limited to USB speeds. >> >>
-------- Original message --------
From: Maxwell Cole >>
Date:02/18/2015 4:30 PM >> (GMT-05:00)
To: "nanog at nanog.org >> 'NANOG list'" >>
Subject: Re: OT - Small DNS "appliances" >> for remote offices.
>>
From baconzombie at gmail.com Thu Feb 19 00:20:21 2015 From: baconzombie at gmail.com (Bacon Zombie) Date: Thu, 19 Feb 2015 01:20:21 +0100 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <54E52829.8090509@mulligan.org> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> Message-ID: You also have to watch out for issues with the Pi corrupting SD cards. On 19 Feb 2015 01:04, "Geoff Mulligan" wrote: > I have used the BeagleBone to run a few simple servers. I don't know if > the ethernet port on the Bone is on the USB bus. It is slightly more > expensive than a PI, but they have worked well for me. > > Geoff > > On 02/18/2015 04:44 PM, Peter Loron wrote: > >> For any site where you would use a Pi as the DNS cache, it won't be an >> issue. DNS isn't that heavy at those query rates. >> >> Yeah, it would be awesome if they'd been able to get a SoC that included >> ethernet. >> >> -Pete >> >> On 2015-02-18 15:08, Robert Webb wrote: >> >>> What I do not like about the Pi is the network port is on the USB bus >>> and thus limited to USB speeds. >>> >>>
-------- Original message --------
From: Maxwell Cole >>>
Date:02/18/2015 4:30 PM >>> (GMT-05:00)
To: "nanog at nanog.org >> 'NANOG list'" >>>
Subject: Re: OT - Small DNS "appliances" >>> for remote offices.
>>>
>>> >> > From nanog08 at mulligan.org Thu Feb 19 00:27:56 2015 From: nanog08 at mulligan.org (Geoff Mulligan) Date: Wed, 18 Feb 2015 17:27:56 -0700 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> Message-ID: <54E52E0C.9070900@mulligan.org> The BeagleBone Black uses flash memory to hold the system image which allows it to boot quickly. I'm running Ubuntu Trusty 14.04 and it seems stable. Geoff *-- Presidential Innovation Fellow | The White House* On 02/18/2015 05:20 PM, Bacon Zombie wrote: > You also have to watch out for issues with the Pi corrupting SD cards. > On 19 Feb 2015 01:04, "Geoff Mulligan" wrote: > >> I have used the BeagleBone to run a few simple servers. I don't know if >> the ethernet port on the Bone is on the USB bus. It is slightly more >> expensive than a PI, but they have worked well for me. >> >> Geoff >> >> On 02/18/2015 04:44 PM, Peter Loron wrote: >> >>> For any site where you would use a Pi as the DNS cache, it won't be an >>> issue. DNS isn't that heavy at those query rates. >>> >>> Yeah, it would be awesome if they'd been able to get a SoC that included >>> ethernet. >>> >>> -Pete >>> >>> On 2015-02-18 15:08, Robert Webb wrote: >>> >>>> What I do not like about the Pi is the network port is on the USB bus >>>> and thus limited to USB speeds. >>>> >>>>
-------- Original message --------
From: Maxwell Cole >>>>
Date:02/18/2015 4:30 PM >>>> (GMT-05:00)
To: "nanog at nanog.org >> 'NANOG list'" >>>>
Subject: Re: OT - Small DNS "appliances" >>>> for remote offices.
>>>>
>>>> From rs at seastrom.com Thu Feb 19 01:23:37 2015 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 18 Feb 2015 20:23:37 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> (Robert Webb's message of "Wed, 18 Feb 2015 18:08:46 -0500") References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> Message-ID: <86r3tmitie.fsf@valhalla.seastrom.com> "Robert Webb" writes: > What I do not like about the Pi is the network port is on the USB > bus and thus limited to USB speeds.  Pretty much all of the ARM boards have their ethernet ports on HSIC channels (480mbit/sec, no-transceiver-phy USB for on-board use - maximum length is 10cm). The Pi-B shares the single HSIC channel with the USB hub for the keyboard and mice. It seems from looking at block diagrams and lsusb output that the ODROID U3 has an SoC with multiple HSIC channels and dedicate one to to the ethernet (though the "bus" vs "port" distinction is suspect). pi at raspi-b ~ $ lsusb -t /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/3p, 480M |__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M pi at raspi-b ~ $ root at odroid:~# lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=s5p-ehci/3p, 480M |__ Port 2: Dev 2, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M |__ Port 3: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M root at odroid:~# But 480 is greater than 100, and none of the Pis have ethernet faster than 10/100. The long pole in the tent is definitely not the USB, and single stream tcp throughput is fine. pi at raspi-b ~ $ curl -o /dev/null http://172.30.250.101/bigfile % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 989M 100 989M 0 0 11.1M 0 0:01:28 0:01:28 --:--:-- 11.1M pi at raspi-b ~ $ -r From bill at herrin.us Thu Feb 19 02:37:37 2015 From: bill at herrin.us (William Herrin) Date: Wed, 18 Feb 2015 21:37:37 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <86r3tn6y8f.fsf@valhalla.seastrom.com> References: <20150218142816.GA17905@esri.com> <54E4A9BF.5000006@alter3d.ca> <86r3tn6y8f.fsf@valhalla.seastrom.com> Message-ID: On Wed, Feb 18, 2015 at 10:22 AM, Rob Seastrom wrote: > The Pi is low-powered in more ways than one. Last fall I ran some > (admittedly fairly simple minded) DNS benchmarks against a Raspberry > Pi Model B and an ODROID U3. > > Particularly if you have DNSSEC validation enabled, the Pi is > underwhelming in performance (81 qps in the validation case, 164 > without). > > The U3 is circa 325 qps with or without DNSSEC validation on, which > suggests that something else other than crypto-computes is the long > pole in the tent. Hi Rob, Interesting. The odroid has a 1700 mhz processor, the pi a 700 mhz processor. Except for the validation anomaly your results are self-consistent. > Caveats: This is just returning NXDOMAIN against a TLD for which > (after the first run) there is already cached information that the TLD > is bogus, so this test doesn't involve traffic actually leaving the box. Given your testing methodology, the difference between validating and non-validating makes no sense to me. Once the records are cached bind should only be passing a flag around? Weird. On Wed, Feb 18, 2015 at 6:44 PM, Peter Loron wrote: > For any site where you would use a Pi as the DNS cache, it won't be an > issue. DNS isn't that heavy at those query rates. Yes and no. DNS is a lynchpin service. All connections stall until the DNS provides an IP address. So you kinda want low latency in your DNS lookups. If a fast server three hops away can respond faster than a slow server on the same LAN, the server three hops away is a better choice. A point in favor of the Raspberry Pi -- there's a heckuva lot of accessories already built for it. Including various cases and even a few different rackmount cases. And a wealth of "how do you do it?" and "why did it do this?" information available with just a few google search terms. The communities supporting the other hardware options are not nearly so large. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From seitz at bsd-unix.net Thu Feb 19 03:51:55 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Wed, 18 Feb 2015 22:51:55 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <86r3tmitie.fsf@valhalla.seastrom.com> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86r3tmitie.fsf@valhalla.seastrom.com> Message-ID: <20150219035155.GA13222@bsd-unix.net> On Wed, Feb 18, 2015 at 08:23:37PM -0500, Rob Seastrom wrote: > > "Robert Webb" writes: > > > What I do not like about the Pi is the network port is on the USB > > bus and thus limited to USB speeds.?? > > Pretty much all of the ARM boards have their ethernet ports on HSIC > channels (480mbit/sec, no-transceiver-phy USB for on-board use - > maximum length is 10cm). > Agreed the long pole at a small site for DNS won't be the USB bus. Might I recommend the following: odroid-c1 + eMMC module + RTC battery + case + power adapter. Should run you about $75 *AND* wouldn't be bad for running NTP as well. The gig-e port on the C1 has been observed to push 405Mbps TX and 940Mbps+ RX via iperf. -- Bryan G. Seitz From listas at esds.com.br Thu Feb 19 03:56:54 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Thu, 19 Feb 2015 01:56:54 -0200 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <20150218142816.GA17905@esri.com> References: <20150218142816.GA17905@esri.com> Message-ID: Consider change your resolver to Unbound. Much better. -- Eduardo Schoedler Em quarta-feira, 18 de fevereiro de 2015, Ray Van Dolson < rvandolson at esri.com> escreveu: > Hopefully not too far off topic for this list. > > Am looking for options to deploy DNS caching resolvers at remote > locations where there may only be minimal infrastructure (FW and Cisco > equipment) and limited options for installing a noisier, more power > hugnry servers or appliances from a vendor. Stuff like Infoblox is > too expensive. > > We're BIND-based and leaning to stick that way, but open to other > options if they present themselves. > > Am considering the Soekris net6501-50. I can dump a Linux image on > there with our DNS config, indudstrial grade design, and OK > performance. If the thing fails, clients will hopefully not notice due > to anycast which will just hit another DNS server somewhere else on the > network albeit with additional latency. We ship out a replacement > device rather than mucking with trying to repair. > > There's also stuff like this[1] which probably gives me more horsepower > on my CPU, but maybe not as reliable. > > Maybe I'm overengineering this. What do others do at smaller remote > sites? Also considering putting resolvers only at "hub" locations in > our MPLS network based on some latency-based radius. > > Ray > > [1] http://www.newegg.com/Mini-Booksize-Barebone-PCs/SubCategory/ID-309 > -- Eduardo Schoedler From mmg at transtelco.net Thu Feb 19 05:15:46 2015 From: mmg at transtelco.net (=?UTF-8?Q?Manuel_Mar=C3=ADn?=) Date: Wed, 18 Feb 2015 22:15:46 -0700 Subject: Access switch for small business recommendation Message-ID: Dear nanog community I'm looking for a cost effective access switch for FTTB active fiber deployments. We are currently using Accedian demarcation devices but it's probably an overkill for customers that only require a basic internet service. The basic requirements we are looking for are: * Vlan support in order to deploy multiple services * 1 or 2 SFP ports * 4 10/100/1000 * Dying gasp (in order to identify if the equipment is down because power issue) * Rate limit per port * SNMP support to check SFP DDM values * Rack mountable I would appreciate if you can share what you use for these type of requirements. Thank you and have a great day Regards From rs at seastrom.com Thu Feb 19 11:18:43 2015 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 19 Feb 2015 06:18:43 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <20150219035155.GA13222@bsd-unix.net> (Bryan Seitz's message of "Wed, 18 Feb 2015 22:51:55 -0500") References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86r3tmitie.fsf@valhalla.seastrom.com> <20150219035155.GA13222@bsd-unix.net> Message-ID: <8661ay87zg.fsf@valhalla.seastrom.com> Bryan Seitz writes: > odroid-c1 + eMMC module + RTC battery + case + power adapter. > Should run you about $75 *AND* wouldn't be bad for running NTP as > well. I haven't looked into the details of the clock, so "wouldn't be bad" is probably true, "notably good", well, that would be a task for someone with experience doing clock benchmarking and who can describe MAVAR without looking it up. > The gig-e port on the C1 has been observed to push 405Mbps TX and > 940Mbps+ RX via iperf. The 405 Mbps for TX. I've seen around 30 Mbyte/sec on single stream TCP RX. Got 99.5 Mbyte/sec from a Mac Mini in the same subnet so that's not a limit of the host on the other end of the benchmark. I call shenanigans on the 940 Mbps iperf number though. The HSIC bus is only 480 Mbit/sec. Two pints of beer in a one pint glass would be some trick. -r From denys at visp.net.lb Thu Feb 19 12:38:01 2015 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Thu, 19 Feb 2015 14:38:01 +0200 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <54E52E0C.9070900@mulligan.org> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> <54E52E0C.9070900@mulligan.org> Message-ID: Beaglebone has gigabit mac, but due some errata it is not used in gigabit mode, it is 100M (which is maybe enough for small office). But it is "hardware" mac. Another hardware MAC on inexpensive board it is Odroid-C1. But stability of all this boards in heavy networking use is under question, i didn't tested them yet intensively for same purpose. On 2015-02-19 02:27, Geoff Mulligan wrote: > The BeagleBone Black uses flash memory to hold the system image which > allows it to boot quickly. I'm running Ubuntu Trusty 14.04 and it > seems stable. > > Geoff > > *-- > Presidential Innovation Fellow | The White House* > > On 02/18/2015 05:20 PM, Bacon Zombie wrote: >> You also have to watch out for issues with the Pi corrupting SD cards. >> On 19 Feb 2015 01:04, "Geoff Mulligan" wrote: >> >>> I have used the BeagleBone to run a few simple servers. I don't know >>> if >>> the ethernet port on the Bone is on the USB bus. It is slightly more >>> expensive than a PI, but they have worked well for me. >>> >>> Geoff >>> >>> On 02/18/2015 04:44 PM, Peter Loron wrote: >>> >>>> For any site where you would use a Pi as the DNS cache, it won't be >>>> an >>>> issue. DNS isn't that heavy at those query rates. >>>> >>>> Yeah, it would be awesome if they'd been able to get a SoC that >>>> included >>>> ethernet. >>>> >>>> -Pete >>>> >>>> On 2015-02-18 15:08, Robert Webb wrote: >>>> >>>>> What I do not like about the Pi is the network port is on the USB >>>>> bus >>>>> and thus limited to USB speeds. >>>>> >>>>>
-------- Original message --------
From: Maxwell >>>>> Cole >>>>>
Date:02/18/2015 4:30 PM >>>>> (GMT-05:00)
To: "nanog at nanog.org >> 'NANOG list'" >>>>>
Subject: Re: OT - Small DNS >>>>> "appliances" >>>>> for remote offices.
>>>>>
>>>>> --- Best regards, Denys From rs at seastrom.com Thu Feb 19 13:13:09 2015 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 19 Feb 2015 08:13:09 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: (Denys Fedoryshchenko's message of "Thu, 19 Feb 2015 14:38:01 +0200") References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> <54E52E0C.9070900@mulligan.org> Message-ID: <86h9uinixm.fsf@valhalla.seastrom.com> Denys Fedoryshchenko writes: > Beaglebone has gigabit mac, but due some errata it is not used in > gigabit mode, it is 100M (which is maybe enough for small office). But > it is "hardware" mac. The Beaglebone Black rev C BOM calls out the ethernet phy chip as LAN8710A-EZC-TR which is 10/100 so there's your constraint. The MAC is built into the SoC and according to the datasheet the AM3358B is 10/100/1000. > Another hardware MAC on inexpensive board it is Odroid-C1. Difficulty: hardware MAC tells you nothing about how it's connected, either on the board or internally in the SoC. Ethernet on Multibus and Ethernet on PCIe (neither likely on an embedded ARM ;-) are both "hardware MAC" yet the bus-constrained bandwidths will differ by several orders of magnitude. -r From denys at visp.net.lb Thu Feb 19 13:26:36 2015 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Thu, 19 Feb 2015 15:26:36 +0200 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <86h9uinixm.fsf@valhalla.seastrom.com> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> <54E52E0C.9070900@mulligan.org> <86h9uinixm.fsf@valhalla.seastrom.com> Message-ID: <2a0ea2ff5079661c0e9863348943e992@visp.net.lb> On 2015-02-19 15:13, Rob Seastrom wrote: > Denys Fedoryshchenko writes: > >> Beaglebone has gigabit mac, but due some errata it is not used in >> gigabit mode, it is 100M (which is maybe enough for small office). But >> it is "hardware" mac. > > The Beaglebone Black rev C BOM calls out the ethernet phy chip as > LAN8710A-EZC-TR which is 10/100 so there's your constraint. The MAC > is built into the SoC and according to the datasheet the AM3358B is > 10/100/1000. > >> Another hardware MAC on inexpensive board it is Odroid-C1. > > Difficulty: hardware MAC tells you nothing about how it's connected, > either on the board or internally in the SoC. Ethernet on Multibus > and Ethernet on PCIe (neither likely on an embedded ARM ;-) are both > "hardware MAC" yet the bus-constrained bandwidths will differ by > several orders of magnitude. > > -r Well, i guess for DNS it wont matter much(400Mbit or full capacity). But stability of driverand archievable pps rate on it, due poor code - can be a question. And mostly this products are "Network enabled", but networking are very "lightly" used, not as it is used on appliances, 24/7 traffic, sometimes malicious. About Beaglebone, probably reason is this errata: "While the AM335x GP EVM has a Gb Ethernet PHY, AR8031A, on the base board, the PCB was designed to use internal clock delay mode of the RGMII interface and the AM335x does not support the internal clock delay mode. Therefore, if operating the Ethernet in Gb mode, there may be problems with the performance/function due to this. The AR8031A PHY supports internal delay mode. This can be enabled by software to guarantee Gb operation. However, this cannot be done to enable internal delay mode for Ethernet booting of course. " Or maybe they just put 100Mbit PHY to make BOM cost less. As far as i know, Raspberry PI ethernet over USB might be fine for DNS too, but before it had issues with large data transfers (ethernet driver hangs). No idea about now. --- Best regards, Denys From jsklein at gmail.com Thu Feb 19 13:51:17 2015 From: jsklein at gmail.com (Joe Klein) Date: Thu, 19 Feb 2015 08:51:17 -0500 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: I now have a few moments to discuss Security Onion, and why it works well for a many small and mid-sided organization. Security Onion is a Linux distro for IDS, NSM, and log management. The whole thing can be run on a single, or separated systems, based on the needs, network and security architecture, and budget. From a IDS sensor standpoint it contains;1. Snort, Suricata – Focused on network-based signature detection, or what I call “the barn door is open, and the horse is gone” detection. This is because someone needs to be compromised, take to time to send out signatures (or purchase them) before you can use them. Great if the attack is against everyone, or a small community of people that will share this information, but not so good if you are the target.2. Bro – Network based packet and protocol classifier, which when configured, preform:a. Internal intelligence analysisb. Full session, Bidirectional net flow analysisc. File extractiond. Network Reconnaissancee. Behavior and statically analysis on the flowf. And much more3. OSSEC – A comprehensive host based intrusion detection system with fine grained application/server specific policies across multiple platforms such as Linux, Solaris, AIX, HP-UX, BSD, Windows, Mac and Vmware ESX. To catch the traffic, you have:1. Sguil: The Analyst Console for Network Security Monitoring2. Squert is a web application that is used to query and view event data stored in a Sguil database (typically IDS alert data). Squert is a visual tool that attempts to provide additional context to events through the use of metadata, time series representations and weighted and logically grouped result sets. The hope is that these views will prompt questions that otherwise may not have been asked.3. Snorby is a ruby on rails web application for network security monitoring that interfaces with current popular intrusion detection systems (Snort, Suricata and Sagan). The basic fundamental concepts behind Snorby are *simplicity*, organization and power. The project goal is to create a free, open source and highly competitive application for network monitoring for both private and enterprise use.4. ELSA is a centralized syslog framework built on Syslog-NG, MySQL, and Sphinx full-text search. It provides a fully asynchronous web-based query interface that normalizes logs and makes searching billions of them for arbitrary strings as easy as searching the web. Packet Capture and analysis: 1. Xplico is a network forensics analysis tool (NFAT), which is a software that reconstructs the contents of acquisitions performed with a packet sniffer (e.g. Wireshark, tcpdump, Netsniff-ng).2. NetworkMiner is a Network Forensic Analysis Tool (NFAT) for Windows (but also works in Linux / Mac OS X / FreeBSD). NetworkMiner can be used as a passive network sniffer/packet capturing tool in order to detect operating systems, sessions, hostnames, open ports etc. without putting any traffic on the network. NetworkMiner can also parse PCAP files for off-line analysis and to regenerate/reassemble transmitted files and certificates from PCAP files. The only thing you are missing is a SEIM, which I recommend the ELK stack. This includes:1. elasticsearch - for distributed restful search and analytics2. logstash - manage events and logs - elasticsearch works seamlessly with logstash to collect, parse, index, and search logs3. kibana - visualize logs and time-stamped data - elasticsearch works seamlessly with kibana to let you see and interact with your dataAll of the above items are Open Source, have free and paid training and support, if needed. One can save millions of dollars and get the newest capabilities. Contact me off list if you have questions. Disclosure: I do not sell these products, but I use them. Joe Klein "Inveniam viam aut faciam" On Fri, Feb 13, 2015 at 12:40 PM, Andy Ringsmuth wrote: > NANOG'ers, > > I've been tasked by our company president to learn about, investigate and > recommend an intrusion detection system for our company. > > We're a smaller outfit, less than 100 employees, entirely Apple-based. > Macs, iPhones, some Mac Mini servers, etc., and a fiber connection to the > world. We are protected by a FreeBSD firewall setup, and we stay current on > updates/patches from Apple and FreeBSD, but that's as far as my expertise > goes. > > Initially, what do people recommend for: > > 1. Crash course in intrusion detection as a whole > 2. Suggestions or recommendations for intrusion detection hardware or > software > 3. Other things I'm likely overlooking > > Thank you all in advance for your wisdom. > > > ---- > 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 Patrick.Darden at p66.com Thu Feb 19 13:59:15 2015 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Thu, 19 Feb 2015 13:59:15 +0000 Subject: Intrusion Detection recommendations In-Reply-To: References: <20150213212711.GA16425@gsp.org> Message-ID: <058cab743af44a769e8bae4e57c10915@BRTEXMB02.phillips66.net> I believe the ASA was first developed as the PIX on Plan 9. The OS that came out of that was originally called Finesse OS, but was later renamed as PIX OS. After Cisco purchased the PIX and renamed it to the ASA, they began using a Linux kernel around PIX OS V8. --p -----Original Message----- From: NANOG [mailto:nanog-bounces+patrick.darden=p66.com at nanog.org] On Behalf Of Justin M. Streiner Sent: Saturday, February 14, 2015 3:28 AM To: nanog at nanog.org Subject: [EXTERNAL]Re: Intrusion Detection recommendations On Fri, 13 Feb 2015, Rich Kulawiec wrote: > On Fri, Feb 13, 2015 at 02:45:46PM -0600, Rafael Possamai wrote: >> I am a huge fan of FreeBSD, but for a medium/large business I'd >> definitely use a fairly well tested security appliance like Cisco's ASA. > > Closed-source software is faith-based security. The ASA, like so many network/security appliances anymore, runs Linux (or *BSD) under the hood, however I don't know how old or horribly mangled it is. jms From Patrick.Darden at p66.com Thu Feb 19 14:01:50 2015 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Thu, 19 Feb 2015 14:01:50 +0000 Subject: Intrusion Detection recommendations In-Reply-To: References: Message-ID: These are all excellent tools for a dedicated knowledgeable network security person to use. The most important element being the dedicated knowledgeable network security person. --p -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jimmy Hess Sent: Saturday, February 14, 2015 12:57 PM To: Randy Bush Cc: North American Network Operators' Group Subject: [EXTERNAL]Re: Intrusion Detection recommendations On Sat, Feb 14, 2015 at 2:38 AM, Randy Bush wrote: Bro, SNORT, SGUIL, Tcpdump, and Wireshark are some nice tools. By itself, a single install of Snort/Bro is not necessarily a complete IDS, as it cannot inspect the contents of outgoing SSL sessions, so there can still be Javascript/attacks against the browser, or SQL injection attempts encapsulated in the encrypted tunnels; I am not aware of an open source tool to help you with SSH/SSL interception/SSL decryption for implementation of network-based IDS. You also need a hand-crafted rule for each threat that you want Snort to identify... Most likely this entails making decisions about what commercial ruleset(s) you want to use and then buying the appropriate subscriptions. > if you were comfortable enough with freebsd to use it as a firewall, > you can run your traffic through, or mirror it to, a freebsd box running > https://www.bro.org/ or > https://www.snort.org/ > two quite reasonable and powerful open source systems > > randy -- -JH From Patrick.Darden at p66.com Thu Feb 19 14:07:18 2015 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Thu, 19 Feb 2015 14:07:18 +0000 Subject: Intrusion Detection recommendations In-Reply-To: <20150214222905.GA12330@gsp.org> References: <20150214222905.GA12330@gsp.org> Message-ID: +10 The original SANS DDOS task force, and many others since, have emphasized this. Filter your Outbound! Bogons for obvious reasons, BGP3 to keep routing multipliers, non-internals to keep from being used as an amplifier network, the list goes on. Be a good network neighbor. --p -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rich Kulawiec Sent: Saturday, February 14, 2015 4:29 PM To: nanog at nanog.org Subject: [EXTERNAL]Re: Intrusion Detection recommendations . . . This reminds me to bring up a point that can't be stressed enough: it's just as important to block *outbound* traffic as inbound. Ask Anthem. Or Target. Or the ghosts of the Trojans. ;) . . . . From david.reader at zeninternet.co.uk Thu Feb 19 14:52:42 2015 From: david.reader at zeninternet.co.uk (David Reader) Date: Thu, 19 Feb 2015 14:52:42 +0000 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <2a0ea2ff5079661c0e9863348943e992@visp.net.lb> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> <54E52E0C.9070900@mulligan.org> <86h9uinixm.fsf@valhalla.seastrom.com> <2a0ea2ff5079661c0e9863348943e992@visp.net.lb> Message-ID: <20150219145242.ad8145e6.david.reader@zeninternet.co.uk> On Thu, 19 Feb 2015 15:26:36 +0200 Denys Fedoryshchenko wrote: > As far as i know, Raspberry PI ethernet over USB might be fine for DNS > too, but before it had issues with > large data transfers (ethernet driver hangs). No idea about now. On Thu, 19 Feb 2015 15:26:36 +0200 Denys Fedoryshchenko wrote: > As far as i know, Raspberry PI ethernet over USB might be fine for DNS > too, but before it had issues with > large data transfers (ethernet driver hangs). No idea about now. AIUI the problem with the RPi isn't so much that the Ethernet NIC sits on a USB interface, it's that the RPi USB interface is very basic and requires a great deal of host interaction to work. It presents a very high interrupt load, and that can lead to problems. Remember that the RPi, fantastic as it is, was developed as a low cost educational aid. It can be used with great success in other fields, but you should consider its limitations. I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. d. From listas at esds.com.br Thu Feb 19 14:57:08 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Thu, 19 Feb 2015 12:57:08 -0200 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <20150219145242.ad8145e6.david.reader@zeninternet.co.uk> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> <54E52E0C.9070900@mulligan.org> <86h9uinixm.fsf@valhalla.seastrom.com> <2a0ea2ff5079661c0e9863348943e992@visp.net.lb> <20150219145242.ad8145e6.david.reader@zeninternet.co.uk> Message-ID: People, processor of this hardware will be killed before the 100M ethernet be the problem. -- Eduardo Schoedler 2015-02-19 12:52 GMT-02:00 David Reader : > On Thu, 19 Feb 2015 15:26:36 +0200 > Denys Fedoryshchenko wrote: > > > As far as i know, Raspberry PI ethernet over USB might be fine for DNS > > too, but before it had issues with > > large data transfers (ethernet driver hangs). No idea about now. > > On Thu, 19 Feb 2015 15:26:36 +0200 > Denys Fedoryshchenko wrote: > > > As far as i know, Raspberry PI ethernet over USB might be fine for DNS > > too, but before it had issues with > > large data transfers (ethernet driver hangs). No idea about now. > > AIUI the problem with the RPi isn't so much that the Ethernet NIC sits on > a USB interface, it's that the RPi USB interface is very basic and requires > a great deal of host interaction to work. It presents a very high interrupt > load, and that can lead to problems. > > Remember that the RPi, fantastic as it is, was developed as a low cost > educational aid. It can be used with great success in other fields, but you > should consider its limitations. > > I'm using several to connect sensors, actuators, and such to a private > network, which it's great for - but I'd think at least twice before > deploying one as a public-serving host in user-experience-critical role in > a remote location. > > d. > -- Eduardo Schoedler From tdurack at gmail.com Thu Feb 19 16:06:40 2015 From: tdurack at gmail.com (Tim Durack) Date: Thu, 19 Feb 2015 11:06:40 -0500 Subject: draft-ietf-mpls-ldp-ipv6-16 Message-ID: I notice draft-ietf-mpls-ldp-ipv6-16 was posted February 11, 2015. What is the chance of getting working code this decade? I would quite like to play with this new fangled IPv6 widget... (Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last piece for me.) -- Tim:> From Valdis.Kletnieks at vt.edu Thu Feb 19 16:26:22 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 19 Feb 2015 11:26:22 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: Your message of "Thu, 19 Feb 2015 14:52:42 +0000." <20150219145242.ad8145e6.david.reader@zeninternet.co.uk> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> <54E52E0C.9070900@mulligan.org> <86h9uinixm.fsf@valhalla.seastrom.com> <2a0ea2ff5079661c0e9863348943e992@visp.net.lb> <20150219145242.ad8145e6.david.reader@zeninternet.co.uk> Message-ID: <3309.1424363182@turing-police.cc.vt.edu> On Thu, 19 Feb 2015 14:52:42 +0000, David Reader said: > I'm using several to connect sensors, actuators, and such to a private > network, which it's great for - but I'd think at least twice before deploying > one as a public-serving host in user-experience-critical role in a remote > location. I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mansaxel at besserwisser.org Thu Feb 19 16:35:45 2015 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 19 Feb 2015 17:35:45 +0100 Subject: draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: References: Message-ID: <20150219163545.GF9160@besserwisser.org> Subject: draft-ietf-mpls-ldp-ipv6-16 Date: Thu, Feb 19, 2015 at 11:06:40AM -0500 Quoting Tim Durack (tdurack at gmail.com): > I notice draft-ietf-mpls-ldp-ipv6-16 was posted February 11, 2015. > > What is the chance of getting working code this decade? I would quite like > to play with this new fangled IPv6 widget... > > (Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last > piece for me.) One of the vendors has promised v6 ldp "this year" (as in 2015). Given the interesting bugs that surfaced when we tried a couple years ago, well, I'm at least breathing shallowly. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm having a BIG BANG THEORY!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From bedard.phil at gmail.com Thu Feb 19 17:03:21 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Thu, 19 Feb 2015 12:03:21 -0500 Subject: draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: References: Message-ID: <01137268-DC2E-497B-948D-DBA5EBFECDD5@gmail.com> ASR9K IOS-XR 5.3.0 Release Notes: IPv6 Support in MPLS LDP: Starting from release 5.3.0, support for native MPLS LDP over IPv6 is enabled to continue providing existing services seamlessly while enabling new ones. The attributes and capabilities of the existing MPLS LDP have been extended to be IPv6 aware. This is based off the -12 draft, that LDP over v6 draft has seen a lot of contention for various reasons. Details at: http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/mp ls/configuration/guide/b-mpls-cg53x-asr9k/b-mpls-cg53x-asr9k_chapter_010.ht ml#concept_FA2F48EE4A2044458FE25897118AFBA4 If you have CCO access you can download the 5.3.0 XRv VMs and play around with it. Phil On 2/19/15, 16:06, "Tim Durack" wrote: >I notice draft-ietf-mpls-ldp-ipv6-16 was posted February 11, 2015. > >What is the chance of getting working code this decade? I would quite like >to play with this new fangled IPv6 widget... > >(Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last >piece for me.) > >-- >Tim:> From owen at delong.com Thu Feb 19 18:15:46 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Feb 2015 10:15:46 -0800 Subject: Intrusion Detection recommendations In-Reply-To: <058cab743af44a769e8bae4e57c10915@BRTEXMB02.phillips66.net> References: <20150213212711.GA16425@gsp.org> <058cab743af44a769e8bae4e57c10915@BRTEXMB02.phillips66.net> Message-ID: <386E0247-B00D-4E8F-8611-669DDD503152@delong.com> The PIX was originally developed as a “Network Translation, Inc.” box (translation.com ). (John Mayes, Brantley Coile, Johnson Wu) Cisco continued the PIX name for many years and through some major changes to the operating system. A later round of major changes had it renamed to ASA. Up through PIX 7 the PIX and ASA ran the same code releases. With PIX 8, PIX continued on the Finesse OS line, but ASA went to a Linux kernel. http://en.wikipedia.org/wiki/Cisco_PIX Owen Cisco bought that and renamed it PIX > On Feb 19, 2015, at 5:59 AM, Darden, Patrick wrote: > > I believe the ASA was first developed as the PIX on Plan 9. The OS that came out of that was originally called Finesse OS, but was later renamed as PIX OS. After Cisco purchased the PIX and renamed it to the ASA, they began using a Linux kernel around PIX OS V8. > > --p > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+patrick.darden=p66.com at nanog.org] On Behalf Of Justin M. Streiner > Sent: Saturday, February 14, 2015 3:28 AM > To: nanog at nanog.org > Subject: [EXTERNAL]Re: Intrusion Detection recommendations > > On Fri, 13 Feb 2015, Rich Kulawiec wrote: > >> On Fri, Feb 13, 2015 at 02:45:46PM -0600, Rafael Possamai wrote: >>> I am a huge fan of FreeBSD, but for a medium/large business I'd >>> definitely use a fairly well tested security appliance like Cisco's ASA. >> >> Closed-source software is faith-based security. > > The ASA, like so many network/security appliances anymore, runs Linux (or > *BSD) under the hood, however I don't know how old or horribly mangled it is. > > jms From seitz at bsd-unix.net Thu Feb 19 18:37:17 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Thu, 19 Feb 2015 13:37:17 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <8661ay87zg.fsf@valhalla.seastrom.com> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86r3tmitie.fsf@valhalla.seastrom.com> <20150219035155.GA13222@bsd-unix.net> <8661ay87zg.fsf@valhalla.seastrom.com> Message-ID: <20150219183717.GA36665@bsd-unix.net> On Thu, Feb 19, 2015 at 06:18:43AM -0500, Rob Seastrom wrote: > > Bryan Seitz writes: > > > odroid-c1 + eMMC module + RTC battery + case + power adapter. > > Should run you about $75 *AND* wouldn't be bad for running NTP as > > well. > > I haven't looked into the details of the clock, so "wouldn't be bad" > is probably true, "notably good", well, that would be a task for > someone with experience doing clock benchmarking and who can describe > MAVAR without looking it up. > > > The gig-e port on the C1 has been observed to push 405Mbps TX and > > 940Mbps+ RX via iperf. > > The 405 Mbps for TX. I've seen around 30 Mbyte/sec on single stream > TCP RX. Got 99.5 Mbyte/sec from a Mac Mini in the same subnet so > that's not a limit of the host on the other end of the benchmark. > > I call shenanigans on the 940 Mbps iperf number though. The HSIC bus > is only 480 Mbit/sec. Two pints of beer in a one pint glass would be > some trick. http://dn.odroid.com/homebackup/201411241452444193.jpg I don't think it lives on the 480Mbit/sec limited bus here. [ 3] local 192.168.1.4 port 53391 connected with 192.168.1.21 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 488 MBytes 409 Mbits/sec [ 4] local 192.168.1.4 port 5001 connected with 192.168.1.21 port 34581 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 1.09 GBytes 939 Mbits/sec -- Bryan G. Seitz From mark.tinka at seacom.mu Thu Feb 19 19:27:45 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 19 Feb 2015 21:27:45 +0200 Subject: draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: <01137268-DC2E-497B-948D-DBA5EBFECDD5@gmail.com> References: <01137268-DC2E-497B-948D-DBA5EBFECDD5@gmail.com> Message-ID: <54E63931.6000909@seacom.mu> On 19/Feb/15 19:03, Phil Bedard wrote: > ASR9K IOS-XR 5.3.0 Release Notes: > > IPv6 Support in MPLS LDP: Starting from release 5.3.0, support for native > MPLS LDP over IPv6 is enabled to continue providing existing services > seamlessly while enabling new ones. The attributes and capabilities of the > existing MPLS LDP have been extended to be IPv6 aware. > > This is based off the -12 draft, that LDP over v6 draft has seen a lot of > contention for various reasons. > > Details at: > > http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/mp > ls/configuration/guide/b-mpls-cg53x-asr9k/b-mpls-cg53x-asr9k_chapter_010.ht > ml#concept_FA2F48EE4A2044458FE25897118AFBA4 > > If you have CCO access you can download the 5.3.0 XRv VMs and play around > with it. Getting IPv6 support in LDP is one thing. This is one document that we need to keep track to know what MPLS applications currently running off of LDPv4 still need to be ported to run over LDPv6: http://tools.ietf.org/html/draft-george-mpls-ipv6-only-gap-04 Mark. From denys at visp.net.lb Thu Feb 19 19:32:48 2015 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Thu, 19 Feb 2015 21:32:48 +0200 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <3309.1424363182@turing-police.cc.vt.edu> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> <54E52E0C.9070900@mulligan.org> <86h9uinixm.fsf@valhalla.seastrom.com> <2a0ea2ff5079661c0e9863348943e992@visp.net.lb> <20150219145242.ad8145e6.david.reader@zeninternet.co.uk> <3309.1424363182@turing-police.cc.vt.edu> Message-ID: <38b98679e5ec3e8362b9c83e5a6e581a@visp.net.lb> On 2015-02-19 18:26, Valdis.Kletnieks at vt.edu wrote: > On Thu, 19 Feb 2015 14:52:42 +0000, David Reader said: > >> I'm using several to connect sensors, actuators, and such to a private >> network, which it's great for - but I'd think at least twice before >> deploying >> one as a public-serving host in user-experience-critical role in a >> remote >> location. > > I have a Pi that's found a purpose in life as a remote smokeping sensor > and > related network monitoring, a task it does quite nicely. > > Note that they just released the Pi 2, which goes from the original > single-core > ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All > at the > same price point. That may change the calculus. I admit not having > gotten one > in hand to play with yet. Weird thing - it still has Ethernet over ugly USB 2.0 That kills any interest to run it for any serious networking applications. --- Best regards, Denys From mel at beckman.org Thu Feb 19 19:47:48 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 19 Feb 2015 19:47:48 +0000 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <38b98679e5ec3e8362b9c83e5a6e581a@visp.net.lb> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> <54E52E0C.9070900@mulligan.org> <86h9uinixm.fsf@valhalla.seastrom.com> <2a0ea2ff5079661c0e9863348943e992@visp.net.lb> <20150219145242.ad8145e6.david.reader@zeninternet.co.uk> <3309.1424363182@turing-police.cc.vt.edu> <38b98679e5ec3e8362b9c83e5a6e581a@visp.net.lb> Message-ID: <2AFD8B2B-9655-4149-B57D-BBEB6B3C383D@beckman.org> If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS. I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding. Total time from unboxing to working DNS: 20 minutes. The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients. You get Apple's warranty and full support. Any Apple store can do testing and repair. And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests. Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions. -mel On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko wrote: > On 2015-02-19 18:26, Valdis.Kletnieks at vt.edu wrote: >> On Thu, 19 Feb 2015 14:52:42 +0000, David Reader said: >>> I'm using several to connect sensors, actuators, and such to a private >>> network, which it's great for - but I'd think at least twice before deploying >>> one as a public-serving host in user-experience-critical role in a remote >>> location. >> I have a Pi that's found a purpose in life as a remote smokeping sensor and >> related network monitoring, a task it does quite nicely. >> Note that they just released the Pi 2, which goes from the original single-core >> ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the >> same price point. That may change the calculus. I admit not having gotten one >> in hand to play with yet. > Weird thing - it still has Ethernet over ugly USB 2.0 > That kills any interest to run it for any serious networking applications. > > --- > Best regards, > Denys From colinj at gt86car.org.uk Thu Feb 19 19:51:14 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 19 Feb 2015 19:51:14 +0000 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <2AFD8B2B-9655-4149-B57D-BBEB6B3C383D@beckman.org> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> <54E52E0C.9070900@mulligan.org> <86h9uinixm.fsf@valhalla.seastrom.com> <2a0ea2ff5079661c0e9863348943e992@visp.net.lb> <20150219145242.ad8145e6.david.reader@zeninternet.co.uk> <3309.1424363182@turing-police.cc.vt.edu> <38b98679e5ec3e8362b9c83e5a6e581a@visp.net.lb> <2AFD8B2B-9655-4149-B57D-BBEB6B3C383D@beckman.org> Message-ID: <39722399-B151-4DC3-9C5A-8FF0797F4576@gt86car.org.uk> older apple tv will work as well :) Colin > On 19 Feb 2015, at 19:47, Mel Beckman wrote: > > If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS. > > I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding. > > Total time from unboxing to working DNS: 20 minutes. > > The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients. > > You get Apple's warranty and full support. Any Apple store can do testing and repair. > > And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests. > > Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions. > > -mel > > On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko > wrote: > >> On 2015-02-19 18:26, Valdis.Kletnieks at vt.edu wrote: >>> On Thu, 19 Feb 2015 14:52:42 +0000, David Reader said: >>>> I'm using several to connect sensors, actuators, and such to a private >>>> network, which it's great for - but I'd think at least twice before deploying >>>> one as a public-serving host in user-experience-critical role in a remote >>>> location. >>> I have a Pi that's found a purpose in life as a remote smokeping sensor and >>> related network monitoring, a task it does quite nicely. >>> Note that they just released the Pi 2, which goes from the original single-core >>> ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the >>> same price point. That may change the calculus. I admit not having gotten one >>> in hand to play with yet. >> Weird thing - it still has Ethernet over ugly USB 2.0 >> That kills any interest to run it for any serious networking applications. >> >> --- >> Best regards, >> Denys > From ktims at stargate.ca Thu Feb 19 20:43:01 2015 From: ktims at stargate.ca (Keenan Tims) Date: Thu, 19 Feb 2015 12:43:01 -0800 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <2AFD8B2B-9655-4149-B57D-BBEB6B3C383D@beckman.org> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> <54E52E0C.9070900@mulligan.org> <86h9uinixm.fsf@valhalla.seastrom.com> <2a0ea2ff5079661c0e9863348943e992@visp.net.lb> <20150219145242.ad8145e6.david.reader@zeninternet.co.uk> <3309.1424363182@turing-police.cc.vt.edu> <38b98679e5ec3e8362b9c83e5a6e581a@visp.net.lb> <2AFD8B2B-9655-4149-B57D-BBEB6B3C383D@beckman.org> Message-ID: <54E64AD5.6040701@stargate.ca> If you have a lot of locations, as I believe Ray is looking for, all of this is a manual process you need to do for each instance. That is slow and inefficient. If you're doing more than a few, you probably want something you can PXE boot for provisioning and manage with your preferred DevOps tools. It also sounds like he wants to run anycast for this service, so probably needs a BGP speaker and other site-specific configuration that I assume is not covered by the cookie-cutter OSX tools. Of course you could still do it this way with a Mac Mini running some other OS, but why would you want to when there are plenty of other mini-PC options that are more appropriate? Also: With Apple dropping their Pro products and leaving customers in the lurch, and no longer having any actual server hardware, I would have very little confidence in their server software product's quality or likely longevity. And of course they're mum on their plans, so it's impossible to plan around if they decide to exit the market. Keenan On 02/19/2015 11:47 AM, Mel Beckman wrote: > If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS. > > I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding. > > Total time from unboxing to working DNS: 20 minutes. > > The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients. > > You get Apple's warranty and full support. Any Apple store can do testing and repair. > > And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests. > > Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions. > > -mel > > On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko > wrote: > >> On 2015-02-19 18:26, Valdis.Kletnieks at vt.edu wrote: >>> On Thu, 19 Feb 2015 14:52:42 +0000, David Reader said: >>>> I'm using several to connect sensors, actuators, and such to a private >>>> network, which it's great for - but I'd think at least twice before deploying >>>> one as a public-serving host in user-experience-critical role in a remote >>>> location. >>> I have a Pi that's found a purpose in life as a remote smokeping sensor and >>> related network monitoring, a task it does quite nicely. >>> Note that they just released the Pi 2, which goes from the original single-core >>> ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the >>> same price point. That may change the calculus. I admit not having gotten one >>> in hand to play with yet. >> Weird thing - it still has Ethernet over ugly USB 2.0 >> That kills any interest to run it for any serious networking applications. >> >> --- >> Best regards, >> Denys > From mel at beckman.org Thu Feb 19 20:55:51 2015 From: mel at beckman.org (Mel Beckman) Date: Thu, 19 Feb 2015 20:55:51 +0000 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <54E64AD5.6040701@stargate.ca> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> <54E52E0C.9070900@mulligan.org> <86h9uinixm.fsf@valhalla.seastrom.com> <2a0ea2ff5079661c0e9863348943e992@visp.net.lb> <20150219145242.ad8145e6.david.reader@zeninternet.co.uk> <3309.1424363182@turing-police.cc.vt.edu> <38b98679e5ec3e8362b9c83e5a6e581a@visp.net.lb> <2AFD8B2B-9655-4149-B57D-BBEB6B3C383D@beckman.org>, <54E64AD5.6040701@stargate.ca> Message-ID: <5725295C-B743-4655-92AA-6F44B81EF944@beckman.org> Keenan, Red. Herrings. You can provision macs over the network. That's one of the functions of Mac OSX Server OS. It's trivial to then promote them to servers themselves. All remotely. Also, the Mac is running a full BIND9 implementation, not some cutdown version. Yes the GUI is minimal, but there's no need to use the GUI, and you don't even have a GUI on other platforms for the most part. BGP speaker? Come on, you're gilding the lily. Yes, Apple is silent about its plans. But the Mac Mini and Server OS have been well supported for over a decade. I don't know why you're bringing server hardware into this, the whole point of the discussion is to avoid using server hardware. And how much open source "road map" has failed to materialize? Lots! The future-proofing argument cuts both ways, my friend. You may have little confidence in Apple, but the rest of the world seems to have great confidence. Just look at Apple's stock performance and market cap. As a famous scientist one said: "The absence of data is not data." :-) -mel beckman On Feb 19, 2015, at 12:43 PM, "Keenan Tims" > wrote: If you have a lot of locations, as I believe Ray is looking for, all of this is a manual process you need to do for each instance. That is slow and inefficient. If you're doing more than a few, you probably want something you can PXE boot for provisioning and manage with your preferred DevOps tools. It also sounds like he wants to run anycast for this service, so probably needs a BGP speaker and other site-specific configuration that I assume is not covered by the cookie-cutter OSX tools. Of course you could still do it this way with a Mac Mini running some other OS, but why would you want to when there are plenty of other mini-PC options that are more appropriate? Also: With Apple dropping their Pro products and leaving customers in the lurch, and no longer having any actual server hardware, I would have very little confidence in their server software product's quality org likely longevity. And of course they're mum on their plans, so it's impossible to plan around if they decide to exit the market. Keenan On 02/19/2015 11:47 AM, Mel Beckman wrote: If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS. I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding. Total time from unboxing to working DNS: 20 minutes. The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients. You get Apple's warranty and full support. Any Apple store can do testing and repair. And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests. Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions. -mel On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko > wrote: On 2015-02-19 18:26, Valdis.Kletnieks at vt.edu wrote: On Thu, 19 Feb 2015 14:52:42 +0000, David Reader said: I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location. I have a Pi that's found a purpose in life as a remote smokeping sensor and related network monitoring, a task it does quite nicely. Note that they just released the Pi 2, which goes from the original single-core ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the same price point. That may change the calculus. I admit not having gotten one in hand to play with yet. Weird thing - it still has Ethernet over ugly USB 2.0 That kills any interest to run it for any serious networking applications. --- Best regards, Denys From colinj at gt86car.org.uk Thu Feb 19 21:06:16 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 19 Feb 2015 21:06:16 +0000 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: <5725295C-B743-4655-92AA-6F44B81EF944@beckman.org> References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> <54E52E0C.9070900@mulligan.org> <86h9uinixm.fsf@valhalla.seastrom.com> <2a0ea2ff5079661c0e9863348943e992@visp.net.lb> <20150219145242.ad8145e6.david.reader@zeninternet.co.uk> <3309.1424363182@turing-police.cc.vt.edu> <38b98679e5ec3e8362b9c83e5a6e581a@visp.net.lb> <2AFD8B2B-9655-4149-B57D-BBEB6B3C383D@beckman.org> <, > <54E64AD5.6040701@stargate.ca> <5725295C-B743-4655-92AA-6F44B81EF944@beckman.org> Message-ID: <4AEB5382-AD8F-47E3-9DBE-2AAB0F7EAC9A@gt86car.org.uk> here here, apple kits rocks for low end server work, sun kit rocks for high end server work. Colin > On 19 Feb 2015, at 20:55, Mel Beckman wrote: > > Keenan, > > Red. Herrings. > > You can provision macs over the network. That's one of the functions of Mac OSX Server OS. It's trivial to then promote them to servers themselves. All remotely. > > Also, the Mac is running a full BIND9 implementation, not some cutdown version. Yes the GUI is minimal, but there's no need to use the GUI, and you don't even have a GUI on other platforms for the most part. > > BGP speaker? Come on, you're gilding the lily. > > Yes, Apple is silent about its plans. But the Mac Mini and Server OS have been well supported for over a decade. I don't know why you're bringing server hardware into this, the whole point of the discussion is to avoid using server hardware. And how much open source "road map" has failed to materialize? Lots! The future-proofing argument cuts both ways, my friend. > > You may have little confidence in Apple, but the rest of the world seems to have great confidence. Just look at Apple's stock performance and market cap. > > As a famous scientist one said: "The absence of data is not data." :-) > > -mel beckman > > On Feb 19, 2015, at 12:43 PM, "Keenan Tims" > wrote: > > If you have a lot of locations, as I believe Ray is looking for, all of > this is a manual process you need to do for each instance. That is slow > and inefficient. If you're doing more than a few, you probably want > something you can PXE boot for provisioning and manage with your > preferred DevOps tools. It also sounds like he wants to run anycast for > this service, so probably needs a BGP speaker and other site-specific > configuration that I assume is not covered by the cookie-cutter OSX > tools. Of course you could still do it this way with a Mac Mini running > some other OS, but why would you want to when there are plenty of other > mini-PC options that are more appropriate? > > Also: With Apple dropping their Pro products and leaving customers in > the lurch, and no longer having any actual server hardware, I would have > very little confidence in their server software product's quality org > likely longevity. And of course they're mum on their plans, so it's > impossible to plan around if they decide to exit the market. > > Keenan > > On 02/19/2015 11:47 AM, Mel Beckman wrote: > If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS. > > I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding. > > Total time from unboxing to working DNS: 20 minutes. > > The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients. > > You get Apple's warranty and full support. Any Apple store can do testing and repair. > > And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests. > > Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions. > > -mel > > On Feb 19, 2015, at 11:32 AM, Denys Fedoryshchenko > > wrote: > > On 2015-02-19 18:26, Valdis.Kletnieks at vt.edu wrote: > On Thu, 19 Feb 2015 14:52:42 +0000, David Reader said: > I'm using several to connect sensors, actuators, and such to a private > network, which it's great for - but I'd think at least twice before deploying > one as a public-serving host in user-experience-critical role in a remote > location. > I have a Pi that's found a purpose in life as a remote smokeping sensor and > related network monitoring, a task it does quite nicely. > Note that they just released the Pi 2, which goes from the original single-core > ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the > same price point. That may change the calculus. I admit not having gotten one > in hand to play with yet. > Weird thing - it still has Ethernet over ugly USB 2.0 > That kills any interest to run it for any serious networking applications. > > --- > Best regards, > Denys > From frnkblk at iname.com Thu Feb 19 22:17:12 2015 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 19 Feb 2015 16:17:12 -0600 Subject: HTTPv6 access to www.centurylink.com and www.qwest.com are down In-Reply-To: <001601d0499a$0c1eca00$245c5e00$@iname.com> References: <8B9D122A1836AF4BB23B7966A4EABEC20AD4E774@pcscmail001.MUTUALTEL.MTCNET.NET> <001601d0499a$0c1eca00$245c5e00$@iname.com> Message-ID: <002301d04c91$cf54e280$6dfea780$@iname.com> I never heard back from anyone, but the two sites came back up 1:59 pm Central time, so it was down just over a week. Now it Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Frank Bulk Sent: Sunday, February 15, 2015 9:39 PM To: nanog at nanog.org Subject: FW: HTTPv6 access to www.centurylink.com and www.qwest.com are down Emails to what I thought were CenturyLink's NOC have gone unanswered, and the other email address resulted in an automated "you're not allowed to send emails to that group". Frank -----Original Message----- From: Frank Bulk Sent: Thursday, February 12, 2015 8:22 AM To: network at centurytel.net; 'noc at qwest.net' Subject: HTTPv6 access to www.centurylink.com and www.qwest.com are down According to our monitoring system, HTTPv6 access to www.centurylink.com and www.qwest.com have been down since 12:05 am U.S. Central, responding with a "Connection refused". I've tested from two vantage points to confirm that it's not just our prefix. Diagnostic output can be found below. Regards, Frank Bulk Premier Communications root at nagios:~/tmp/ipv6# wget -6 www.centurylink.com --2015-02-12 08:18:22-- http://www.centurylink.com/ Resolving www.centurylink.com... 2001:428:b21:1::20 Connecting to www.centurylink.com|2001:428:b21:1::20|:80... failed: Connection refused. root at nagios:~/tmp/ipv6# root at nagios:~/tmp/ipv6# tcptraceroute6 www.centurylink.com traceroute to www.centurylink.com (2001:428:b21:1::20) from 2607:fe28:0:1000::5, port 80, from port 60661, 30 hops max, 60 bytes packets 1 router-core.mtcnet.net (2607:fe28:0:1000::1) 0.555 ms 19.811 ms 1.632 ms 2 sxct.sxcy.mtcnet.net (2607:fe28:11:1002::197) 0.185 ms 0.196 ms 0.115 ms 3 v6-premier.sxcy-mlx.fbnt.netins.net (2001:5f8:7f0a:2::1) 1.641 ms 1.617 ms 1.585 ms 4 v6-ins-db4-te-0-6-0-4-219.desm.netins.net (2001:5f8:1:1::1) 8.146 ms 8.003 ms 8.051 ms 5 v6-ins-dc1-te-7-4.desm.netins.net (2001:5f8::26:2) 8.035 ms 7.954 ms 7.928 ms 6 2610:18:18b:c000::11 (2610:18:18b:c000::11) 12.925 ms 12.941 ms 12.896 ms 7 mcr1.minneapolis-mn.us.xo.net (2610:18::30b8) 22.254 ms 22.234 ms 22.238 ms 8 2610:18::5802 (2610:18::5802) 32.891 ms 25.156 ms 22.868 ms 9 2610:18::2072 (2610:18::2072) 23.894 ms 22.264 ms 22.759 ms 10 2610:18:16:3000::da (2610:18:16:3000::da) 18.543 ms 18.513 ms 18.569 ms 11 2001:428::205:171:2:52 (2001:428::205:171:2:52) 28.482 ms 28.512 ms 28.549 ms 12 2001:428:1c02:2::2 (2001:428:1c02:2::2) 28.254 ms 28.277 ms 28.238 ms 13 * 2001:428:b21:fc03::2 (2001:428:b21:fc03::2) 28.871 ms 28.608 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * root at nagios:~/tmp/ipv6# From joshua.riesenweber at outlook.com Wed Feb 18 23:02:36 2015 From: joshua.riesenweber at outlook.com (Joshua Riesenweber) Date: Thu, 19 Feb 2015 09:02:36 +1000 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: References: <20150218142816.GA17905@esri.com> <20150218221123.GA14885@gsp.org>, Message-ID: If you're already installing a Cisco router, maybe look at an SRE-V module? You could install a VM/OS on the router. Cheers,Josh From domenick.petrella at gmail.com Thu Feb 19 00:24:26 2015 From: domenick.petrella at gmail.com (Domenick Petrella) Date: Thu, 19 Feb 2015 00:24:26 +0000 Subject: OT - Small DNS "appliances" for remote offices. References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> Message-ID: The BeagleBone's ethernet is directly connected to the SoC, so you would get a higher throughput ceiling than the rpi. On Wed, Feb 18, 2015, 19:03 Geoff Mulligan wrote: > I have used the BeagleBone to run a few simple servers. I don't know if > the ethernet port on the Bone is on the USB bus. It is slightly more > expensive than a PI, but they have worked well for me. > > Geoff > > On 02/18/2015 04:44 PM, Peter Loron wrote: > > For any site where you would use a Pi as the DNS cache, it won't be an > > issue. DNS isn't that heavy at those query rates. > > > > Yeah, it would be awesome if they'd been able to get a SoC that > > included ethernet. > > > > -Pete > > > > On 2015-02-18 15:08, Robert Webb wrote: > >> What I do not like about the Pi is the network port is on the USB bus > >> and thus limited to USB speeds. > >> > >>
-------- Original message --------
From: Maxwell Cole > >>
Date:02/18/2015 4:30 PM > >> (GMT-05:00)
To: "nanog at nanog.org >> 'NANOG list'" > >>
Subject: Re: OT - Small DNS "appliances" > >> for remote offices.
> >>
> > From wesley.george at twcable.com Fri Feb 20 00:36:48 2015 From: wesley.george at twcable.com (George, Wes) Date: Thu, 19 Feb 2015 19:36:48 -0500 Subject: draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: <54E63931.6000909@seacom.mu> References: <01137268-DC2E-497B-948D-DBA5EBFECDD5@gmail.com> <54E63931.6000909@seacom.mu> Message-ID: On 2/19/15, 2:27 PM, "Mark Tinka" wrote: > >Getting IPv6 support in LDP is one thing. > >This is one document that we need to keep track to know what MPLS >applications currently running off of LDPv4 still need to be ported to >run over LDPv6: > > http://tools.ietf.org/html/draft-george-mpls-ipv6-only-gap-04 The document has come out the other side of the IETF sausage grinder now: https://tools.ietf.org/html/rfc7439 Unfortunately, it's just a list of the gaps. It is worth leaning on your vendors of choice to ensure that they have people focused on addressing these issues, as not all of them have volunteers to write the documents necessary to close those gaps yet. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From geekgirl at gmail.com Fri Feb 20 00:59:28 2015 From: geekgirl at gmail.com (Leslie) Date: Thu, 19 Feb 2015 16:59:28 -0800 Subject: Call For Presentations RIPE 70, submission deadline 1 March 2015 In-Reply-To: <54B52458.9070803@NLnetLabs.nl> References: <54B52458.9070803@NLnetLabs.nl> Message-ID: Just a reminder that this deadline is coming up! We can't wait to see your submissions :) Leslie On Tue, Jan 13, 2015 at 5:57 AM, Benno Overeinder wrote: > Dear colleagues, > > Please find the CFP for RIPE 70 below. > > The deadline for submissions is 1 March 2015. > > Please also note that speakers do not receive any extra reduction or > funding towards the meeting fee at the RIPE Meetings. > > Kind regards, > > Benno Overeinder > for the 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 70 will take place from 11-15 May 2015 in Amsterdam, The Netherlands. > > 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 70. 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://ripe70.ripe.net/submit-topic/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 > 1 March 2015, using the meeting submission system at > https://ripe70.ripe.net/submit-topic/submission-form/. Proposals > submitted after this date will be considered on a space-available > basis. > > Important Dates regarding RIPE 70 can be found at: > https://ripe70.ripe.net/programme/important-dates/ > > - Lightning talks should also be submitted using the meeting submission > system (https://ripe70.ripe.net/submit-topic/submission-form/) 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 at > https://ripe70.ripe.net/submit-topic/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 panellists, presenters and moderators. > > - Due to potential technical issues, it is expected that most, if not > all, presenters/panellists 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. > > > -- > Benno J. Overeinder > NLnet Labs > http://www.nlnetlabs.nl/ From randy at psg.com Fri Feb 20 03:07:44 2015 From: randy at psg.com (Randy Bush) Date: Fri, 20 Feb 2015 12:07:44 +0900 Subject: v6 deagg Message-ID: in a discussion with some fellow researchers, the subject of ipv6 deaggregation arose; will it be less or more than we see in ipv4? in http://archive.psg.com/jsac-deagg.pdf it was thought that multi-homing, traffic engineering, and the /24 pollution disease were the drivers. multi-homing seems to be increasing, while the other two were stable as a relative measure to total growth. so, at first blush, we thought v6 would be about the same as v4. but then we considered that v6 allocations seem to be /32s, and the longest propagating route seems to be /48, leaving 16 bits with which the deaggregators can play. while in v4 it was /24s out of a /19 or /20, four or five bits. this does not bode well. randy From bmanning at isi.edu Fri Feb 20 03:16:20 2015 From: bmanning at isi.edu (manning bill) Date: Thu, 19 Feb 2015 19:16:20 -0800 Subject: v6 deagg In-Reply-To: References: Message-ID: <1589DCC3-6396-4FF0-8CF9-C9EB386AA057@isi.edu> and then there are the loons who will locally push /64 or longer, some of which may leak. even if things were sane & nothing longer than a /32 were to be in the table, are we not looking at the functional equivalent of v4 host routes? /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 19February2015Thursday, at 19:07, Randy Bush wrote: > in a discussion with some fellow researchers, the subject of ipv6 > deaggregation arose; will it be less or more than we see in ipv4? > > in http://archive.psg.com/jsac-deagg.pdf it was thought that > multi-homing, traffic engineering, and the /24 pollution disease were > the drivers. multi-homing seems to be increasing, while the other two > were stable as a relative measure to total growth. > > so, at first blush, we thought v6 would be about the same as v4. > > but then we considered that v6 allocations seem to be /32s, and the > longest propagating route seems to be /48, leaving 16 bits with which > the deaggregators can play. while in v4 it was /24s out of a /19 or > /20, four or five bits. > > this does not bode well. > > randy From nanog at jima.us Fri Feb 20 03:29:33 2015 From: nanog at jima.us (Jima) Date: Thu, 19 Feb 2015 20:29:33 -0700 Subject: v6 deagg In-Reply-To: <1589DCC3-6396-4FF0-8CF9-C9EB386AA057@isi.edu> References: <1589DCC3-6396-4FF0-8CF9-C9EB386AA057@isi.edu> Message-ID: <54E6AA1D.3080108@jima.us> That might be a little more valid once we move past 2000::/3 -- at the moment, more like IPv4 /29s. Alas, /48 seems to be the generally accepted maximum prefix length, so, yeah, this could be unfortunate. Jima On 2015-02-19 20:16, manning bill wrote: > and then there are the loons who will locally push /64 or longer, some of which may leak. > > even if things were sane & nothing longer than a /32 were to be in the table, are we not looking at the functional > equivalent of v4 host routes? > > /bill > PO Box 12317 > Marina del Rey, CA 90295 > 310.322.8102 > > On 19February2015Thursday, at 19:07, Randy Bush wrote: > >> in a discussion with some fellow researchers, the subject of ipv6 >> deaggregation arose; will it be less or more than we see in ipv4? >> >> in http://archive.psg.com/jsac-deagg.pdf it was thought that >> multi-homing, traffic engineering, and the /24 pollution disease were >> the drivers. multi-homing seems to be increasing, while the other two >> were stable as a relative measure to total growth. >> >> so, at first blush, we thought v6 would be about the same as v4. >> >> but then we considered that v6 allocations seem to be /32s, and the >> longest propagating route seems to be /48, leaving 16 bits with which >> the deaggregators can play. while in v4 it was /24s out of a /19 or >> /20, four or five bits. >> >> this does not bode well. >> >> randy > From brent at brentrjones.com Fri Feb 20 03:46:30 2015 From: brent at brentrjones.com (Brent Jones) Date: Thu, 19 Feb 2015 19:46:30 -0800 Subject: v6 deagg In-Reply-To: <54E6AA1D.3080108@jima.us> References: <1589DCC3-6396-4FF0-8CF9-C9EB386AA057@isi.edu> <54E6AA1D.3080108@jima.us> Message-ID: Instead, we may find network equipment vendors might ship with larger/faster TCAM, and faster processing to handle increasing routing table demands. We've been hearing "the end is nigh!" for a decade, and as far as I can tell, we are no closer to the end than when we started. Maybe some equipment refresh cycles will increase, and some providers will have to make a choice to upgrade sooner than later. But, as network engineers and architects, surely we all know that nothing is static, and growth will continue to accelerate. Better be ready, or some of us will be left behind. On Thu, Feb 19, 2015 at 7:29 PM, Jima wrote: > That might be a little more valid once we move past 2000::/3 -- at the > moment, more like IPv4 /29s. > > Alas, /48 seems to be the generally accepted maximum prefix length, so, > yeah, this could be unfortunate. > > Jima > > > On 2015-02-19 20:16, manning bill wrote: > >> and then there are the loons who will locally push /64 or longer, some of >> which may leak. >> >> even if things were sane & nothing longer than a /32 were to be in the >> table, are we not looking at the functional >> equivalent of v4 host routes? >> >> /bill >> PO Box 12317 >> Marina del Rey, CA 90295 >> 310.322.8102 >> >> On 19February2015Thursday, at 19:07, Randy Bush wrote: >> >> in a discussion with some fellow researchers, the subject of ipv6 >>> deaggregation arose; will it be less or more than we see in ipv4? >>> >>> in http://archive.psg.com/jsac-deagg.pdf it was thought that >>> multi-homing, traffic engineering, and the /24 pollution disease were >>> the drivers. multi-homing seems to be increasing, while the other two >>> were stable as a relative measure to total growth. >>> >>> so, at first blush, we thought v6 would be about the same as v4. >>> >>> but then we considered that v6 allocations seem to be /32s, and the >>> longest propagating route seems to be /48, leaving 16 bits with which >>> the deaggregators can play. while in v4 it was /24s out of a /19 or >>> /20, four or five bits. >>> >>> this does not bode well. >>> >>> randy >>> >> >> > -- Brent Jones brent at brentrjones.com From morrowc.lists at gmail.com Fri Feb 20 04:53:53 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 19 Feb 2015 23:53:53 -0500 Subject: OT - Small DNS "appliances" for remote offices. In-Reply-To: References: <6kuidte0ccrph68sp1cmbrwy.1424300924779@email.android.com> <86e4922f5c8ff3b961a7e3859b1bf43b@standingwave.org> <54E52829.8090509@mulligan.org> Message-ID: On Wed, Feb 18, 2015 at 7:24 PM, Domenick Petrella wrote: > The BeagleBone's ethernet is directly connected to the SoC, so you would > get a higher throughput ceiling than the rpi. > sounds super important... question though, what's the expected average/normal/budgeted rate for the remote office connection to the intertubes? + or 1 10mbps ? From morrowc.lists at gmail.com Fri Feb 20 05:25:06 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 20 Feb 2015 00:25:06 -0500 Subject: v6 deagg In-Reply-To: <1589DCC3-6396-4FF0-8CF9-C9EB386AA057@isi.edu> References: <1589DCC3-6396-4FF0-8CF9-C9EB386AA057@isi.edu> Message-ID: On Thu, Feb 19, 2015 at 10:16 PM, manning bill wrote: > and then there are the loons who will locally push /64 or longer, some of which may leak. > 2001:2b8:46:bbbb::/64 ... a fairly extensive list actually.... > show route table inet6.0 | grep ^2 | except /4[876543210] | except /3 | except /2 | count Count: 297 lines Some are likely my local network's interfaces (so skip ~50 or so? to be generous) and some might be my provider's customers? (but they shouldn't send me shorter than a /48, right?) -chris (note on another observation point I don't see this sort of thing so perhaps it's just one upstream in a collection... I'll ask them seperately) From saku at ytti.fi Fri Feb 20 08:07:26 2015 From: saku at ytti.fi (Saku Ytti) Date: Fri, 20 Feb 2015 10:07:26 +0200 Subject: v6 deagg In-Reply-To: References: Message-ID: <20150220080726.GA23425@pob.ytti.fi> On (2015-02-20 12:07 +0900), Randy Bush wrote: Hey, > in a discussion with some fellow researchers, the subject of ipv6 > deaggregation arose; will it be less or more than we see in ipv4? Is deaggregation inherently undesirable? In some RIR LIR will not get new allocation, just because LIR lacks INET connectivity between their datacenter or pop. This wasn't issue in IPv4, because you actually could reasonably fill your IPv4 allocation and were eligible for another allocation for your discontinuous locations. Clearly there are valid routing reasons why >1 network from single company has to appears in DFZ. Having RIR allocate another network or having LIR deaggregate have exact same cost to RIB/FIB, yet they are different. Multiple allocation gives additional scrutiny, network must pass RIR policy to be able to exist. Deagrregation is entirely uncontrolled, we don't know from route object the reason for it, valid reasons and invalid reasons are grouped in same pool. What is the correct solution here? Deaggregate or allocate space you don't need? Or some others solution, should route object creation be limited to LIR and be controlled by specific policy? It would allow inject information about the reason for it. Correct solution is not to use some so called 'strict' ipv6 filters, which break Internet, by not allowing discontinuous pops having connectivity. -- ++ytti From mark.tinka at seacom.mu Fri Feb 20 08:30:06 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 20 Feb 2015 10:30:06 +0200 Subject: draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: References: <01137268-DC2E-497B-948D-DBA5EBFECDD5@gmail.com> <54E63931.6000909@seacom.mu> Message-ID: <54E6F08E.1000604@seacom.mu> On 20/Feb/15 02:36, George, Wes wrote: > > The document has come out the other side of the IETF sausage grinder now: > https://tools.ietf.org/html/rfc7439 > > Unfortunately, it's just a list of the gaps. > It is worth leaning on your vendors of choice to ensure that they have > people focused on addressing these issues, as not all of them have > volunteers to write the documents necessary to close those gaps yet. Looking at how long it has taken the community to react to the LDPv6 draft (been chasing everyone since 2007, personally), my priority to get a working MPLSv6 domain has gone from 1 to a lot lower. I'd like to see it get done, but I'm going to be focusing on getting better native IPv6 in the code/hardware before I chase the vendors for a working MPLSv6 solution. They just have no interest because there is no incremental revenue - and given the community are focused on other things, threatening not to buy kit due to lack of MPLSv6 support is not a practical avenue, unfortunately. Mark. From brandon at rd.bbc.co.uk Fri Feb 20 09:26:39 2015 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 20 Feb 2015 09:26:39 GMT Subject: v6 deagg Message-ID: <201502200926.JAA12911@sunf10.rd.bbc.co.uk> > From: Saku Ytti > Is deaggregation inherently undesirable? I'd say yes when the only limit to deaggregation is /48. Given the opportunity people will do whatever they see fit at everyone elses expense > What is the correct solution here? Deaggregate or allocate space you don't > need? Whichever comes with sensible deagg control. The desired effect is people advertise exactly sufficient prefixes and, I'd say, a simple universal mechanism for everyone else to limit them to that so they don't feel the need to advertise more to prevent hijacks etc. > Or some others solution, should route object creation be limited to LIR > and be controlled by specific policy? It would allow inject information about > the reason for it. There is always a good reason to the person doing it. > Correct solution is not to use some so called 'strict' ipv6 filters, which > break Internet, by not allowing discontinuous pops having connectivity. Yes, strict would be best if based on good data. With no prefix length police there is no good data, RIPE gave up and said /48 everywhere removing the simpler mechanism to do this (I've not noticed what the others are doing) brandon From swmike at swm.pp.se Fri Feb 20 09:42:03 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 20 Feb 2015 10:42:03 +0100 (CET) Subject: v6 deagg In-Reply-To: <20150220080726.GA23425@pob.ytti.fi> References: <20150220080726.GA23425@pob.ytti.fi> Message-ID: On Fri, 20 Feb 2015, Saku Ytti wrote: > Correct solution is not to use some so called 'strict' ipv6 filters, > which break Internet, by not allowing discontinuous pops having > connectivity. Before, the practical level of de-agg was at /24 for IPv4. This meant only larger organisations could do it. With automation in the network space increasing, and with /48 being justifiable to any site, and with /48 being the typical DFZ routing filter, we now have the possibility of a lot more entities seeing IP address based multihoming and "PI" being possible. I don't like where this is headed. There are millions of entities that are justifiable to announce a /48 into DFZ. Do we want this to happen? By allowing it, we're not putting any pressure to invent solutions for graceful address migration with continous services, and instead putting the pressure on the DFZ infrastructure. Is this the correct tradeoff? How many smaller than /32 in the IPv6 DFZ do we allow before we need to start to worry? In these discussions I frequently interact with people who don't want to limit things until they are actually a problem. So when will this become a problem? 100k de-agged routes? 200k? 500k? 1M? >From a technical point of view, I have little interest in my router handling the fact that an office at the other side of the planet shut down their router, and learning this via DFZ. -- Mikael Abrahamsson email: swmike at swm.pp.se From shopik at inblock.ru Fri Feb 20 10:13:57 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Fri, 20 Feb 2015 13:13:57 +0300 Subject: v6 deagg In-Reply-To: References: <20150220080726.GA23425@pob.ytti.fi> Message-ID: <54E708E5.1040308@inblock.ru> On 20/02/15 12:42, Mikael Abrahamsson wrote: > I don't like where this is headed. There are millions of entities that > are justifiable to announce a /48 into DFZ. Do we want this to happen? rfc6115 have good overview and recommendation. IPv6 clearly need separation of identification of endpoints and routing information to that endpoint. We already have broadband operators who fully deagg their IPv4 space. And just one ISP IPv6 with /32 deagg will take 65536 routes. From saku at ytti.fi Fri Feb 20 11:39:59 2015 From: saku at ytti.fi (Saku Ytti) Date: Fri, 20 Feb 2015 13:39:59 +0200 Subject: draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: References: Message-ID: <20150220113959.GA8476@pob.ytti.fi> On (2015-02-19 11:06 -0500), Tim Durack wrote: > What is the chance of getting working code this decade? I would quite like > to play with this new fangled IPv6 widget... > > (Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last > piece for me.) Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to accept IPv6 next-hop in BGP LU, but probably does not work out-of-the-box? Isn't Segment Routing implementation day1 IPV4+IPV6 in XR? -- ++ytti From tdurack at gmail.com Fri Feb 20 14:00:07 2015 From: tdurack at gmail.com (Tim Durack) Date: Fri, 20 Feb 2015 09:00:07 -0500 Subject: draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: <20150220113959.GA8476@pob.ytti.fi> References: <20150220113959.GA8476@pob.ytti.fi> Message-ID: On Fri, Feb 20, 2015 at 6:39 AM, Saku Ytti wrote: > On (2015-02-19 11:06 -0500), Tim Durack wrote: > > > What is the chance of getting working code this decade? I would quite > like > > to play with this new fangled IPv6 widget... > > > > (Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last > > piece for me.) > > Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to > accept > IPv6 next-hop in BGP LU, but probably does not work out-of-the-box? > Isn't Segment Routing implementation day1 IPV4+IPV6 in XR? > > -- > ++ytti > I would gladly take OSPFv2/OSPFv3/ISIS+SR over LDP, but I'm seeing that is not all that is needed. I also need some flavor of L2VPN (eVPN) and L3VPN (VPNv4/VPNv6) working over IPv6. IPv6 control plane this decade may yet be optimistic. -- Tim:> From naoto.mm at gmail.com Fri Feb 20 14:50:52 2015 From: naoto.mm at gmail.com (NAOTO MATSUMOTO) Date: Fri, 20 Feb 2015 23:50:52 +0900 Subject: An Easy way to build a server cluster without top of rack switches (MEMO) In-Reply-To: References: Message-ID: BTW: This scenario's combination has another portion for us like as below. High Availability Server Clustering without ILB(Internal Load Balancer) (MEMO) http://slidesha.re/1vld6uB -- Naoto MATSUMOTO On Mon, Feb 16, 2015 at 12:23 PM, NAOTO MATSUMOTO wrote: > Hi Dan and ken. > > I respect your great works. > > Certainly, our scenario was network classics and it just does not "one > size fits all" network architecture. > Many people tried to built centralized and decentralized networks many > years ago, some guys output > implementation like this. > > > Interconnect of K computer (torus fusion) > > https://www.fujitsu.com/global/Images/fujitsu-hpc-roadmap-beyond-petascale-computing.pdf > > > I agree with you point. Our approach have to do more simple way on > physical and logical > network engineering, and change the mindset, I think. > (e.g. network cabling procedure and troubleshooting and handling) > > But, some guys need more cost effective server cluster environment and > they does't care > network latency like Low-End Web Hosting. > > > e.g. Intel Diversity of Server workloads http://bit.ly/1BgFH65 [JPG]. > > > Now, Many people do not use Dijkstra and automaton theory on the server > side, > but it is great mechanism for network durability if they controlled. > > The Ethernet NIC's bandwidth is increasing day by day, the cost is > decreasing too. > > I say again, our scenario is not "one size fits all" network architecture, > but we believe that something will happen for some guys works. ;-) > > best regards, > > -- > Naoto MATSUMOTO > > > > On Sat, Feb 14, 2015 at 7:08 AM, Dan Eckert > wrote: > >> I'm having a hard time seeing how this reduces cable costs or increases >> network durability. Each individual server is well connected to 3-4 other >> servers in the rack, but the rack still only has two uplinks. For many >> servers in the rack you're adding 3-4 routing hops between an end node and >> the rack uplink. >> >> Additionally, with only 2 external links tied to 2 specific nodes, you >> introduce more risks. If one of the uplink nodes fails, you've got to >> re-route all of the nodes that were using it as the shortest path to now >> exit through the other uplink node -- the worst case in the example then >> increases from the original 4-hops-to-exit to now 7-hops-to-exit. >> >> As far as cable costs go, you might have slightly shorter cables, but far >> more complex wiring pattern -- so in essence you're trading off a small >> amount of cable cost for a higher amount of installation and >> troubleshooting cost. >> >> Also, using this layout, you dramatically reduce the effective bandwidth >> available between devices, since per-device links now have to be used for >> backhaul/transport in addition to device-specific traffic. >> >> Finally, you have to manage per-server routing service configurations to >> make this work -- more points of failure and increased >> setup/troubleshooting cost. In a ToR switch scenario, you do one config on >> one switch, plug in the cables, and you're done -- problems happen, you go >> to the one switch, not chasing a needle through a haystack of >> interconnected servers. >> >> If your RU count is worth more than the combination of increased >> installation, server configuration, troubleshooting, latency, and capacity >> costs, then this is a good solution. Either way, it's a neat idea and a >> fun thought experiment to work through. >> >> Thanks! >> Dan >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of NAOTO MATSUMOTO >> Sent: Wednesday, February 11, 2015 11:32 PM >> To: nanog at nanog.org >> Subject: FYI: An Easy way to build a server cluster without top of rack >> switches (MEMO) >> >> Hi all! >> >> We wrote up TIPS memo "an easy way to build a server cluster without top >> of rack switches" concept. >> >> This model have a reduce switches and cables costs and high network >> durability by lightweight and simple configuration. >> >> if you interest in, please try to do yourself this concept ;-) >> >> >> An Easy way to build a server cluster without top of rack switches (MEMO) >> http://slidesha.re/1EduYXM >> >> >> Best regards, >> -- >> Naoto MATSUMOTO >> > > From maillist at webjogger.net Fri Feb 20 15:21:40 2015 From: maillist at webjogger.net (Adam Greene) Date: Fri, 20 Feb 2015 10:21:40 -0500 Subject: LiveAction? Message-ID: <02d801d04d20$edda18d0$c98e4a70$@webjogger.net> Hi all, Has anyone used this product? http://www.liveaction.com/ Cisco seems to tout it: http://www.cisco.com/c/en/us/solutions/enterprise-networks/intelligent-wan/i ndex.html (scroll down) We're evaluating it as a way to manage customer bandwidth utilization on our service provider network. To me, it looks like an affordable alternative to deploying extremely expensive bandwidth management appliances. It's centrally managed on a VM, and I like that it does not impose scalability limitations like some bandwidth management vendors who charge every time you want to push more bandwidth through their devices. Interested in whether anyone has rolled it out and how their experience has been. Thanks, Adam From bryn.sadler at essensys.co.uk Fri Feb 20 16:15:00 2015 From: bryn.sadler at essensys.co.uk (Bryn Sadler) Date: Fri, 20 Feb 2015 16:15:00 +0000 Subject: NYC Metro Ethernet Providers Message-ID: Hi all, We're currently a UK based managed service provider looking to open up in the New York area. Part of our service model involves buying quite a lot of L2 ethernet tails from customer prems back to our DCs, usually 100Mb and 1Gb, but sometimes smaller 10-50Mb services for backups. I was wondering if anyone on the list would be able to recommend reliable providers in that region, we'd essentially just want pure Layer 2 so we can run our own VLANs etc across them, with a number of circuits aggregated and handed off in a DC as a trunk, each circuit as an SPVLAN that we can then strip. Thanks in advance for any feedback, Bryn Sadler From amitchell at isipp.com Fri Feb 20 17:08:02 2015 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Fri, 20 Feb 2015 10:08:02 -0700 Subject: What would you do about questionable domain pointing A record to your IP address? Message-ID: <99269447-57E1-4B93-BC51-8BFA2D24F9AC@isipp.com> All, We have a rather strange situation (well, strange to me, at least). We have an email reputation accreditation applicant, who otherwise looks clean, however there is a very strange and somewhat concerning domain being pointed to one of the applicant's IP addresses Let's call the domain example.com, and the IP address 127.0.0.1, for these purposes. Applicant is assigned 127.0.0.1. the rDNS correctly goes to their own domain. However, example.com (which in reality is a concerning domain name) claims 127.0.0.1 as their A record. Of course, example.com is registered privately, and their DNS provider is one who is...umm... "known to provide dns for domains seen in spam." As I see it, the applicant's options are: a) just not worry about it and keep an eye on it b) publish a really tight spf record on it, so if they are somehow compromised, email appearing to come from example.com and 127.0.0.1 should be denied c) not use the IP address at all (it's part of a substantially larger block) d) two or more of the above. Thoughts? What would you do? Thanks! Anne Anne P. Mitchell, Esq. CEO/President ISIPP SuretyMail Email Reputation, Accreditation & Certification Your mail system + SuretyMail accreditation = delivered to their inbox! http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Author: Section 6 of the Federal CAN-SPAM Act of 2003 Member, California Bar Cyberspace Law Committee Ret. Professor of Law, Lincoln Law School of San Jose 303-731-2121 | amitchell at isipp.com | @AnnePMitchell | Facebook/AnnePMitchell From jbates at paradoxnetworks.net Fri Feb 20 17:23:22 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Fri, 20 Feb 2015 11:23:22 -0600 Subject: v6 deagg In-Reply-To: <54E708E5.1040308@inblock.ru> References: <20150220080726.GA23425@pob.ytti.fi> <54E708E5.1040308@inblock.ru> Message-ID: <54E76D8A.5030203@paradoxnetworks.net> On 2/20/2015 4:13 AM, Nikolay Shopik wrote: > > rfc6115 have good overview and recommendation. IPv6 clearly need > separation of identification of endpoints and routing information to > that endpoint. > > I'm not overly familiar, but I'm always good for new things if one process is supported. deagg X network to Y provider, ask provider to blackhole XY address in X. Not every provider has a good blackhole system. Sometimes you desire to move a subset of data to a single provider for purposes of discarding data. I believe some of the protocols allow multiple sub-identifiers for load balancing purposes, but I'm unsure how strictly they are adhered to or if they might be ignored. I know BGP blackholing is a coincidental abuse of how BGP works, but it is a commonly used one; especially when some city endusers now have more bandwidth than entire rural ISPs. DDOS/amplification isn't always necessary these days. :( Jack From d3e3e3 at gmail.com Fri Feb 20 17:38:17 2015 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 20 Feb 2015 12:38:17 -0500 Subject: What would you do about questionable domain pointing A record to your IP address? In-Reply-To: <99269447-57E1-4B93-BC51-8BFA2D24F9AC@isipp.com> References: <99269447-57E1-4B93-BC51-8BFA2D24F9AC@isipp.com> Message-ID: Hi, On Fri, Feb 20, 2015 at 12:08 PM, Anne P. Mitchell, Esq. wrote: > All, > > We have a rather strange situation (well, strange to me, at least). > > We have an email reputation accreditation applicant, who otherwise looks clean, however there is a very strange and somewhat concerning domain being pointed to one of the applicant's IP addresses Let's call the domain example.com, and the IP address 127.0.0.1, for these purposes. > > Applicant is assigned 127.0.0.1. the rDNS correctly goes to their own domain. > > However, example.com (which in reality is a concerning domain name) claims 127.0.0.1 as their A record. I don't think having an A record in the DNS is really a "claim". Let's say I want to send mail to company.example.com but I don't like them so much so I set up companySUCKS.foo.example.com pointing at their mail server either through an A record or a CNAME... Then, I believe, inside my mail, the mail could appear to be to person at companySUCKS.foo.example.com if it wasn't blocked by some security mechanism. Perhaps this is protected speech or, with a few changes, a parody or something. See Section 4.1.3 "You Can't Control What Names Point At You" in my RFC http://tools.ietf.org/html/rfc3675 A somewhat similar thing is in Section 4.1.4.1 of that RFC where I was on social mailing list with an innocuous name and someone had long set up a forwarder so that if you sent email to cat-torturers at other.example (real left hand side, obviously not the real right hand side). It would get sent to the social mailing list and the that address would appear in the "to:" line inside the mail. For that particular crowd, most people thought this was pretty funny, but it is the same sort of thing. > Of course, example.com is registered privately, and their DNS provider is one who is...umm... "known to provide dns for domains seen in spam." > > As I see it, the applicant's options are: > > a) just not worry about it and keep an eye on it > > b) publish a really tight spf record on it, so if they are somehow compromised, email appearing to come from example.com and 127.0.0.1 should be denied > > c) not use the IP address at all (it's part of a substantially larger block) > > d) two or more of the above. > > Thoughts? What would you do? If it isn't actually causing a problem, a) seems viable but you could certainly do b) or c) or both if you feel like it. Anyway, I'm not a lawyer... :-) Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com > Thanks! > > Anne > > Anne P. Mitchell, Esq. > CEO/President > ISIPP SuretyMail Email Reputation, Accreditation & Certification > Your mail system + SuretyMail accreditation = delivered to their inbox! > http://www.SuretyMail.com/ > http://www.SuretyMail.eu/ > > Author: Section 6 of the Federal CAN-SPAM Act of 2003 > Member, California Bar Cyberspace Law Committee > Ret. Professor of Law, Lincoln Law School of San Jose > 303-731-2121 | amitchell at isipp.com | @AnnePMitchell | Facebook/AnnePMitchell > > > From jbates at paradoxnetworks.net Fri Feb 20 17:53:52 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Fri, 20 Feb 2015 11:53:52 -0600 Subject: What would you do about questionable domain pointing A record to your IP address? In-Reply-To: <99269447-57E1-4B93-BC51-8BFA2D24F9AC@isipp.com> References: <99269447-57E1-4B93-BC51-8BFA2D24F9AC@isipp.com> Message-ID: <54E774B0.6020605@paradoxnetworks.net> On 2/20/2015 11:08 AM, Anne P. Mitchell, Esq. wrote: > a) just not worry about it and keep an eye on it If they have held the netblock for awhile and are already using the IP Address in question, this is fine. I presume that the servers don't actually respond for that domain (name-based web or domain based acceptance on a mail server). > b) publish a really tight spf record on it, so if they are somehow compromised, email appearing to come from example.com and 127.0.0.1 should be denied You must control a domain to control its SPF. This is not an option if they don't control the bad domain. DKIM or similar might be the more appropriate protocol? SPF protects domains, some of the other protocols protect the mail servers themselves. > c) not use the IP address at all (it's part of a substantially larger block) > > If it's a recently acquired netblock, then it may have a bad reputation due to prior use. Investigating the reputation and possibly avoiding that particular IP Address might be warranted. Jack From tdurack at gmail.com Fri Feb 20 18:00:39 2015 From: tdurack at gmail.com (Tim Durack) Date: Fri, 20 Feb 2015 13:00:39 -0500 Subject: [j-nsp] draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: <627266B72B856946BCD625D4B34B1916A31F96@INF-EXCH-MB-02.gammatelecom.com> References: <20150220113959.GA8476@pob.ytti.fi> <627266B72B856946BCD625D4B34B1916A31F96@INF-EXCH-MB-02.gammatelecom.com> Message-ID: On Fri, Feb 20, 2015 at 11:33 AM, Adam Vitkovsky wrote: > > Of Tim Durack > > Sent: 20 February 2015 14:00 > > IPv6 control plane this decade may yet be optimistic. > > > > And most importantly it's not actually needed it's just a whim of network > operators. > > adam > > > ------------------------------ > This email has been scanned for email related threats and delivered safely > by Mimecast. > For more information please visit http://www.mimecast.com > ------------------------------ > I don't consider unique addressing of infrastructure a whim. -- Tim:> From cscora at apnic.net Fri Feb 20 18:12:42 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Feb 2015 04:12:42 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201502201812.t1KICgDq022814@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 21 Feb, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 533255 Prefixes after maximum aggregation (per Origin AS): 204025 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 259930 Total ASes present in the Internet Routing Table: 49437 Prefixes per ASN: 10.79 Origin-only ASes present in the Internet Routing Table: 36458 Origin ASes announcing only one prefix: 16285 Transit ASes present in the Internet Routing Table: 6273 Transit-only ASes present in the Internet Routing Table: 171 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 107 Max AS path prepend of ASN ( 55644) 100 Prefixes from unregistered ASNs in the Routing Table: 1334 Unregistered ASNs in the Routing Table: 436 Number of 32-bit ASNs allocated by the RIRs: 8646 Number of 32-bit ASNs visible in the Routing Table: 6706 Prefixes from 32-bit ASNs in the Routing Table: 24396 Number of bogon 32-bit ASNs visible in the Routing Table: 5 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 400 Number of addresses announced to Internet: 2732253284 Equivalent to 162 /8s, 218 /16s and 224 /24s Percentage of available address space announced: 73.8 Percentage of allocated address space announced: 73.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.2 Total number of prefixes smaller than registry allocations: 180436 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 131658 Total APNIC prefixes after maximum aggregation: 38372 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 137114 Unique aggregates announced from the APNIC address blocks: 55712 APNIC Region origin ASes present in the Internet Routing Table: 5024 APNIC Prefixes per ASN: 27.29 APNIC Region origin ASes announcing only one prefix: 1220 APNIC Region transit ASes present in the Internet Routing Table: 872 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 107 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1310 Number of APNIC addresses announced to Internet: 747396800 Equivalent to 44 /8s, 140 /16s and 94 /24s Percentage of available APNIC address space announced: 87.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 176104 Total ARIN prefixes after maximum aggregation: 87045 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 178169 Unique aggregates announced from the ARIN address blocks: 83527 ARIN Region origin ASes present in the Internet Routing Table: 16498 ARIN Prefixes per ASN: 10.80 ARIN Region origin ASes announcing only one prefix: 6087 ARIN Region transit ASes present in the Internet Routing Table: 1714 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 352 Number of ARIN addresses announced to Internet: 1061271072 Equivalent to 63 /8s, 65 /16s and 182 /24s Percentage of available ARIN address space announced: 56.1 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: 129524 Total RIPE prefixes after maximum aggregation: 64588 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 135852 Unique aggregates announced from the RIPE address blocks: 83507 RIPE Region origin ASes present in the Internet Routing Table: 17873 RIPE Prefixes per ASN: 7.60 RIPE Region origin ASes announcing only one prefix: 8145 RIPE Region transit ASes present in the Internet Routing Table: 2965 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3456 Number of RIPE addresses announced to Internet: 693406084 Equivalent to 41 /8s, 84 /16s and 137 /24s Percentage of available RIPE address space announced: 100.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 58761 Total LACNIC prefixes after maximum aggregation: 10997 LACNIC Deaggregation factor: 5.34 Prefixes being announced from the LACNIC address blocks: 68139 Unique aggregates announced from the LACNIC address blocks: 31758 LACNIC Region origin ASes present in the Internet Routing Table: 2400 LACNIC Prefixes per ASN: 28.39 LACNIC Region origin ASes announcing only one prefix: 630 LACNIC Region transit ASes present in the Internet Routing Table: 490 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1499 Number of LACNIC addresses announced to Internet: 167785728 Equivalent to 10 /8s, 0 /16s and 53 /24s Percentage of available LACNIC address space announced: 100.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12620 Total AfriNIC prefixes after maximum aggregation: 2979 AfriNIC Deaggregation factor: 4.24 Prefixes being announced from the AfriNIC address blocks: 13581 Unique aggregates announced from the AfriNIC address blocks: 5066 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 18.48 AfriNIC Region origin ASes announcing only one prefix: 203 AfriNIC Region transit ASes present in the Internet Routing Table: 156 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 89 Number of AfriNIC addresses announced to Internet: 61893888 Equivalent to 3 /8s, 176 /16s and 109 /24s Percentage of available AfriNIC address space announced: 61.5 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2891 11553 911 Korea Telecom 17974 2826 904 77 PT Telekomunikasi Indonesia 7545 2580 336 128 TPG Telecom Limited 4755 1977 421 205 TATA Communications formerly 4538 1758 4190 71 China Education and Research 9829 1660 1325 36 National Internet Backbone 9808 1547 8717 29 Guangdong Mobile Communicatio 4808 1451 2218 436 CNCGROUP IP network China169 9583 1395 132 556 Sify Limited 9498 1299 336 97 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 2985 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 3356 2566 10684 480 Level 3 Communications, Inc. 18566 2041 379 183 MegaPath Corporation 20115 1849 1829 443 Charter Communications 4323 1623 1037 407 tw telecom holdings, inc. 6983 1623 850 242 EarthLink, Inc. 30036 1520 312 511 Mediacom Communications Corp 701 1391 11268 678 MCI Communications Services, 22561 1329 412 241 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1965 300 352 TELLCOM ILETISIM HIZMETLERI A 20940 1619 632 1202 Akamai International B.V. 8402 1344 544 15 OJSC "Vimpelcom" 6849 1199 356 25 JSC "Ukrtelecom" 31148 1045 45 21 Freenet Ltd. 13188 1044 97 61 TOV "Bank-Inform" 8551 903 373 48 Bezeq International-Ltd 12479 862 793 87 France Telecom Espana SA 9198 850 349 25 JSC Kazakhtelecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3117 506 213 Telmex Colombia S.A. 28573 2307 2141 111 NET Servi�os de Comunica��o S 7303 1788 1190 229 Telecom Argentina S.A. 6147 1589 374 30 Telefonica del Peru S.A.A. 8151 1543 3111 451 Uninet S.A. de C.V. 6503 1196 421 58 Axtel, S.A.B. de C.V. 7738 1001 1882 42 Telemar Norte Leste S.A. 26615 920 2325 35 Tim Celular S.A. 3816 910 395 151 COLOMBIA TELECOMUNICACIONES S 18881 858 1036 22 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1556 958 13 TE-AS 24863 965 284 26 Link Egypt (Link.NET) 36903 479 241 90 Office National des Postes et 36992 390 973 31 ETISALAT MISR 37492 319 155 71 Orange Tunisie 24835 299 144 9 Vodafone Data 3741 250 921 209 Internet Solutions 29571 234 21 12 Cote d'Ivoire Telecom 36947 195 712 14 Telecom Algeria 37054 188 19 6 Data Telecom Service Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3117 506 213 Telmex Colombia S.A. 22773 2985 2955 141 Cox Communications Inc. 4766 2891 11553 911 Korea Telecom 6389 2891 3688 51 BellSouth.net Inc. 17974 2826 904 77 PT Telekomunikasi Indonesia 7545 2580 336 128 TPG Telecom Limited 3356 2566 10684 480 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2307 2141 111 NET Servi�os de Comunica��o S 18566 2041 379 183 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 2985 2844 Cox Communications Inc. 6389 2891 2840 BellSouth.net Inc. 17974 2826 2749 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2580 2452 TPG Telecom Limited 28573 2307 2196 NET Servi�os de Comunica��o S 3356 2566 2086 Level 3 Communications, Inc. 4766 2891 1980 Korea Telecom 18566 2041 1858 MegaPath Corporation 4755 1977 1772 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 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 47092 UNALLOCATED 8.8.204.0/24 16410 The Reynolds and Rey 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.92.160.0/24 14013 EPSON America (Factory Automa 23.92.161.0/24 14013 EPSON America (Factory Automa 23.226.112.0/20 62788 Bitfinite LLC 23.252.224.0/20 62502 >>UNKNOWN<< 23.252.224.0/21 62502 >>UNKNOWN<< 23.252.232.0/21 62502 >>UNKNOWN<< 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:34 /11:92 /12:264 /13:504 /14:997 /15:1723 /16:12974 /17:7130 /18:12142 /19:24903 /20:35716 /21:38479 /22:57743 /23:50414 /24:287236 /25:1069 /26:1084 /27:670 /28:17 /29:14 /30:9 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2201 2985 Cox Communications Inc. 18566 1996 2041 MegaPath Corporation 6389 1671 2891 BellSouth.net Inc. 30036 1366 1520 Mediacom Communications Corp 6983 1314 1623 EarthLink, Inc. 34984 1274 1965 TELLCOM ILETISIM HIZMETLERI A 11492 1133 1191 CABLE ONE, INC. 6147 1132 1589 Telefonica del Peru S.A.A. 10620 1105 3117 Telmex Colombia S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1474 2:670 3:1 4:97 5:1716 6:21 8:1409 12:1842 13:4 14:1300 15:16 16:2 17:42 18:21 20:49 23:1163 24:1681 27:1851 31:1484 32:39 33:2 34:5 35:3 36:119 37:1862 38:1011 39:9 40:233 41:3046 42:259 43:1091 44:25 45:198 46:2116 47:34 49:795 50:783 52:12 54:66 55:4 56:8 57:33 58:1203 59:680 60:460 61:1765 62:1306 63:1914 64:4427 65:2263 66:4082 67:2023 68:1042 69:3284 70:965 71:435 72:1959 74:2620 75:314 76:404 77:1471 78:1255 79:778 80:1326 81:1332 82:813 83:680 84:682 85:1335 86:387 87:1082 88:501 89:1753 90:148 91:5915 92:808 93:2182 94:1958 95:2090 96:431 97:340 98:1054 99:45 100:73 101:800 103:6796 104:1266 105:61 106:217 107:886 108:611 109:2023 110:1078 111:1474 112:772 113:1030 114:853 115:1258 116:1332 117:1022 118:1688 119:1429 120:438 121:1044 122:2177 123:1718 124:1489 125:1564 128:628 129:373 130:380 131:1098 132:475 133:166 134:405 135:88 136:311 137:302 138:472 139:173 140:229 141:418 142:629 143:471 144:518 145:111 146:688 147:560 148:1104 149:458 150:563 151:748 152:485 153:239 154:325 155:725 156:403 157:331 158:264 159:991 160:372 161:633 162:1904 163:387 164:654 165:670 166:324 167:704 168:1003 169:149 170:1442 171:223 172:41 173:1580 174:688 175:622 176:1444 177:3757 178:2077 179:863 180:1918 181:1581 182:1705 183:603 184:743 185:2943 186:2669 187:1830 188:2012 189:1556 190:7744 191:877 192:8098 193:5562 194:4055 195:3632 196:1683 197:946 198:5501 199:5529 200:6537 201:2991 202:9552 203:9069 204:4655 205:2719 206:2978 207:2995 208:3953 209:3894 210:3492 211:1830 212:2467 213:2277 214:846 215:70 216:5544 217:1808 218:665 219:468 220:1457 221:790 222:463 223:654 End of report From bill at herrin.us Fri Feb 20 18:20:39 2015 From: bill at herrin.us (William Herrin) Date: Fri, 20 Feb 2015 13:20:39 -0500 Subject: What would you do about questionable domain pointing A record to your IP address? In-Reply-To: <99269447-57E1-4B93-BC51-8BFA2D24F9AC@isipp.com> References: <99269447-57E1-4B93-BC51-8BFA2D24F9AC@isipp.com> Message-ID: On Fri, Feb 20, 2015 at 12:08 PM, Anne P. Mitchell, Esq. wrote: > We have an email reputation accreditation applicant, who otherwise > looks clean, however there is a very strange and somewhat > concerning domain being pointed to one of the applicant's IP > addresses Let's call the domain example.com, and the IP > address 127.0.0.1, for these purposes. > > Applicant is assigned 127.0.0.1. the rDNS correctly goes to their own domain. > > However, example.com (which in reality is a concerning domain > name) claims 127.0.0.1 as their A record. Howdy, How does 127.0.0.1 behave when you access it and declare yourself to be seeking example.com? If it's a mail server, what happens when you try to mail postmaster at examplecompany.com? Do you get a no-relaying message or one of the other errors appropriate to a server not configured to handle mail for example.com? If it's a web server, what happens when your browser asks for Host: www.example,com? Do you get example.com's web page? Also check 3rd party databases to the extent possible. Can you find examples of dastardly example.com activity from 127.0.0.1 during a time the whois records say applicant had control of 127.0.0.1? You get the general idea. Check for things you know to be under the applicant's control. If they come up clean, they're clean. If they're dirty and they're sloppy enough to not clean up the example.com DNS zone file then they'll be sloppy elsewhere too. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From manager at monmouth.com Fri Feb 20 18:38:14 2015 From: manager at monmouth.com (Mark Stevens) Date: Fri, 20 Feb 2015 13:38:14 -0500 Subject: DNS Admin at Comcast Message-ID: <54E77F16.3000700@monmouth.com> If a DNS Admin at Comcast could contact me offline it would be great. This is concerning your IPV6 configured mail servers. Thanks, Mark From Jason_Livingood at cable.comcast.com Fri Feb 20 21:00:17 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 20 Feb 2015 21:00:17 +0000 Subject: DNS Admin at Comcast In-Reply-To: <54E77F16.3000700@monmouth.com> References: <54E77F16.3000700@monmouth.com> Message-ID: Sent a note off-list. - Jason On 2/20/15, 1:38 PM, "Mark Stevens" wrote: >If a DNS Admin at Comcast could contact me offline it would be great. >This is concerning your IPV6 configured mail servers. > >Thanks, > >Mark > > From saku at ytti.fi Fri Feb 20 21:17:52 2015 From: saku at ytti.fi (Saku Ytti) Date: Fri, 20 Feb 2015 23:17:52 +0200 Subject: draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: References: <20150220113959.GA8476@pob.ytti.fi> Message-ID: <20150220211752.GA17475@pob.ytti.fi> On (2015-02-20 09:00 -0500), Tim Durack wrote: Hey Tim, > I also need some flavor of L2VPN (eVPN) and L3VPN (VPNv4/VPNv6) working > over IPv6. L3VPN uses BGP exclusively for VPN label signalling, no need for LDP. For L2VPN only Martini uses LDP, but if you have choice, why wouldn't you choose Kompella, the scaling factor is superior, as you only have 2 signalling connection, instead of n*(n-1)/2 signalling sessions. And you get to capitalize on instantly available backuo path. Of course I know that in CSCO land Kompella isn't available on every platform where Martini is, so you indeed may need LDP for some time until old platforms are phased out. 'Luckily' these older platforms have dubious IPv6 anyhow, so you might opt them out from IPv6 deployment anyhow. > IPv6 control plane this decade may yet be optimistic. For greenfield it's doable today (only Kompella pseudowires), but IPv6-only would require 4PE, I don't know if that works/exists. -- ++ytti From cidr-report at potaroo.net Fri Feb 20 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Feb 2015 22:00:01 GMT Subject: The Cidr Report Message-ID: <201502202200.t1KM0169015907@wattle.apnic.net> This report has been generated at Fri Feb 20 21:14:25 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 13-02-15 538035 294739 14-02-15 538453 294684 15-02-15 538305 294704 16-02-15 538359 294312 17-02-15 538588 294957 18-02-15 538600 295168 19-02-15 538555 295850 20-02-15 538805 296396 AS Summary 49708 Number of ASes in routing system 19851 Number of ASes announcing only one prefix 3121 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120442368 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 20Feb15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 539262 296349 242913 45.0% All ASes AS22773 2985 170 2815 94.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2891 98 2793 96.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2826 77 2749 97.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 14 2459 99.4% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2306 312 1994 86.5% NET Servi�os de Comunica��o S.A.,BR AS4755 1976 247 1729 87.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4766 2891 1323 1568 54.2% KIXS-AS-KR Korea Telecom,KR AS7303 1788 279 1509 84.4% Telecom Argentina S.A.,AR AS7545 2599 1107 1492 57.4% TPG-INTERNET-AP TPG Telecom Limited,AU AS9808 1546 67 1479 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6147 1589 161 1428 89.9% Telefonica del Peru S.A.A.,PE AS10620 3121 1699 1422 45.6% Telmex Colombia S.A.,CO AS20115 1850 514 1336 72.2% CHARTER-NET-HKY-NC - Charter Communications,US AS8402 1329 26 1303 98.0% CORBINA-AS OJSC "Vimpelcom",RU AS4323 1630 409 1221 74.9% TWTC - tw telecom holdings, inc.,US AS8452 1783 578 1205 67.6% TE-AS TE-AS,EG AS9498 1300 111 1189 91.5% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2040 869 1171 57.4% MEGAPATH5-US - MegaPath Corporation,US AS7552 1146 57 1089 95.0% VIETEL-AS-AP Viettel Corporation,VN AS22561 1329 251 1078 81.1% AS22561 - CenturyTel Internet Holdings, Inc.,US AS34984 1965 891 1074 54.7% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS3356 2569 1502 1067 41.5% LEVEL3 - Level 3 Communications, Inc.,US AS6849 1196 243 953 79.7% UKRTELNET JSC UKRTELECOM,UA AS7738 1000 84 916 91.6% Telemar Norte Leste S.A.,BR AS38285 983 113 870 88.5% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4538 1776 939 837 47.1% ERX-CERNET-BKB China Education and Research Network Center,CN AS4780 1103 309 794 72.0% SEEDNET Digital United Inc.,TW AS26615 922 134 788 85.5% Tim Celular S.A.,BR AS8151 1547 763 784 50.7% Uninet S.A. de C.V.,MX AS24560 1212 429 783 64.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN Total 55671 13776 41895 75.3% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.92.160.0/24 AS14013 EPSON-ROBOTS - EPSON America (Factory Automation/Robotics),US 23.92.161.0/24 AS14013 EPSON-ROBOTS - EPSON America (Factory Automation/Robotics),US 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.45.128.0/17 AS63008 CONTINA - Contina,US 45.62.160.0/19 AS40440 CENTARRA - Centarra Networks Inc.,US 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, Inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 100.42.176.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc.,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS23937 103.20.101.0/24 AS23937 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.100.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.253.164.0/23 AS13317 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 160.234.128.0/17 AS37962 CNNIC-SGATHER-AP Beijing Sgather Telecom Engineering Co.Ltd.,CN 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.224.128.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc.,US 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.8.0.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.1.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.2.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.3.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.4.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.5.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.6.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.7.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.16.0/20 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.16.0/21 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.24.0/21 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.28.0/22 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.44.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.45.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.46.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.47.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.48.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.49.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.50.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.51.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.52.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.53.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.54.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.55.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.56.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.57.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.58.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.59.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.61.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.62.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.63.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.64.0/20 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.72.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.80.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.81.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.82.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.83.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.84.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.85.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.86.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.87.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.88.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.89.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.90.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.91.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.92.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.93.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.94.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.95.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.96.0/20 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.181.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 197.149.188.0/22 AS37282 MAINONE,NG 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.30.136.0/23 AS46636 NATCOWEB - NatCoWeb Corp.,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.204.144.0/21 AS36007 -Reserved AS-,ZZ 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.47.160.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.161.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.162.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.164.0/24 AS9833 202.47.165.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.166.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.167.0/24 AS56111 AGARTO-MY Agarto Sdn Bhd,MY 202.47.169.0/24 AS9833 202.47.170.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.171.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.172.0/24 AS9833 202.47.173.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.174.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.175.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.176.0/24 AS9833 202.47.177.0/24 AS9833 202.47.178.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.179.0/24 AS9833 202.47.180.0/24 AS9833 202.47.181.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.185.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.47.190.0/24 AS9930 TTNET-MY TIME dotCom Berhad,MY 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.175.8.0/23 AS23858 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.15.240.0/22 AS36212 -Reserved AS-,ZZ 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 20 22:00:02 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Feb 2015 22:00:02 GMT Subject: BGP Update Report Message-ID: <201502202200.t1KM02gR015937@wattle.apnic.net> BGP Update Report Interval: 12-Feb-15 -to- 19-Feb-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS61894 367710 7.2% 122570.0 -- FreeBSD Brasil LTDA,BR 2 - AS23752 271684 5.3% 1983.1 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS27194 218890 4.3% 109445.0 -- REALLYFAST - ReallyFast.net,US 4 - AS9829 119288 2.3% 70.5 -- BSNL-NIB National Internet Backbone,IN 5 - AS577 109681 2.1% 40.6 -- BACOM - Bell Canada,CA 6 - AS36947 71643 1.4% 312.9 -- ALGTEL-AS,DZ 7 - AS53563 57400 1.1% 5740.0 -- XPLUSONE - X Plus One Solutions, Inc.,US 8 - AS13188 40017 0.8% 38.1 -- BANKINFORM-AS CONTENT DELIVERY NETWORK LTD,UA 9 - AS8402 30288 0.6% 21.7 -- CORBINA-AS OJSC "Vimpelcom",RU 10 - AS8452 27196 0.5% 14.1 -- TE-AS TE-AS,EG 11 - AS3816 25388 0.5% 27.4 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 12 - AS42337 23301 0.5% 143.0 -- RESPINA-AS Respina Networks & Beyond PJSC,IR 13 - AS10620 22359 0.4% 7.2 -- Telmex Colombia S.A.,CO 14 - AS23342 22359 0.4% 588.4 -- UNITEDLAYER - Unitedlayer, Inc.,US 15 - AS28573 21680 0.4% 8.9 -- NET Servi�os de Comunica��o S.A.,BR 16 - AS197914 21019 0.4% 7006.3 -- STOCKHO-AS Stockho Hosting SARL,FR 17 - AS2734 18761 0.4% 694.9 -- CORESITE - CoreSite,US 18 - AS42081 18413 0.4% 312.1 -- SPEEDY-NET-AS Speedy net EAD,BG 19 - AS28024 18284 0.4% 304.7 -- Nuevatel PCS de Bolivia S.A.,BO 20 - AS14709 17921 0.3% 779.2 -- Telefonica Moviles Panama S.A.,PA TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS61894 367710 7.2% 122570.0 -- FreeBSD Brasil LTDA,BR 2 - AS27194 218890 4.3% 109445.0 -- REALLYFAST - ReallyFast.net,US 3 - AS61039 16564 0.3% 16564.0 -- ZMZ OAO ZMZ,RU 4 - AS46336 8839 0.2% 8839.0 -- GOODVILLE - Goodville Mutual Casualty Company,US 5 - AS50104 7629 0.1% 7629.0 -- SATORP-AS SAUDI ARAMCO TOTAL Refining and Petrochemical Company,SA 6 - AS197914 21019 0.4% 7006.3 -- STOCKHO-AS Stockho Hosting SARL,FR 7 - AS53563 57400 1.1% 5740.0 -- XPLUSONE - X Plus One Solutions, Inc.,US 8 - AS25563 16309 0.3% 4077.2 -- WEBLAND-AS Webland AG, Autonomous System,CH 9 - AS33721 3832 0.1% 3832.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 10 - AS33440 12758 0.2% 3189.5 -- WEBRULON-NETWORK - webRulon, LLC,US 11 - AS62174 2979 0.1% 2979.0 -- INTERPAN-AS INTERPAN LTD.,BG 12 - AS198053 2641 0.1% 2641.0 -- AMTEL VECTRA S.A.,PL 13 - AS23752 271684 5.3% 1983.1 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 14 - AS47680 9237 0.2% 1847.4 -- NHCS EOBO Limited,IE 15 - AS201149 1660 0.0% 1660.0 -- ITSNS ITS Network Solution sp z o o,PL 16 - AS9581 1565 0.0% 1565.0 -- TELSTRAGLOBAL-ID-AS-AP TTPL,HK 17 - AS56169 1560 0.0% 1560.0 -- SCOMM-AS-AP SEDCO COMMUNICATIONS SDN BHD,MY 18 - AS197957 1539 0.0% 1539.0 -- KERBB Ker Broadband Communications Ltd,IE 19 - AS262149 4046 0.1% 1348.7 -- Sistemas Fratec S.A.,CR 20 - AS45606 6636 0.1% 1327.2 -- TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 177.10.158.0/24 367707 7.0% AS61894 -- FreeBSD Brasil LTDA,BR 2 - 202.70.88.0/21 136788 2.6% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.64.0/21 134332 2.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 162.246.92.0/22 109482 2.1% AS27194 -- REALLYFAST - ReallyFast.net,US 5 - 162.208.40.0/22 109408 2.1% AS27194 -- REALLYFAST - ReallyFast.net,US 6 - 105.96.0.0/22 64808 1.2% AS36947 -- ALGTEL-AS,DZ 7 - 199.38.164.0/23 57376 1.1% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 8 - 64.29.130.0/24 22287 0.4% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 9 - 130.0.192.0/21 21017 0.4% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 10 - 23.34.208.0/21 18151 0.3% AS577 -- BACOM - Bell Canada,CA 11 - 91.235.169.0/24 16564 0.3% AS61039 -- ZMZ OAO ZMZ,RU 12 - 184.84.32.0/20 16281 0.3% AS577 -- BACOM - Bell Canada,CA 13 - 23.34.220.0/23 16254 0.3% AS577 -- BACOM - Bell Canada,CA 14 - 184.84.184.0/22 16222 0.3% AS577 -- BACOM - Bell Canada,CA 15 - 23.34.216.0/22 16213 0.3% AS577 -- BACOM - Bell Canada,CA 16 - 184.28.42.0/23 16203 0.3% AS577 -- BACOM - Bell Canada,CA 17 - 91.193.202.0/24 15662 0.3% AS42081 -- SPEEDY-NET-AS Speedy net EAD,BG 18 - 42.83.48.0/20 11802 0.2% AS18135 -- BTV BTV Cable television,JP 19 - 192.58.232.0/24 9587 0.2% AS6629 -- NOAA-AS - NOAA,US 20 - 88.87.160.0/19 9203 0.2% AS47680 -- NHCS EOBO Limited,IE 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 mark.tinka at seacom.mu Fri Feb 20 22:06:53 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 21 Feb 2015 00:06:53 +0200 Subject: draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: <20150220113959.GA8476@pob.ytti.fi> References: <20150220113959.GA8476@pob.ytti.fi> Message-ID: <54E7AFFD.3090502@seacom.mu> On 20/Feb/15 13:39, Saku Ytti wrote: > > Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to accept > IPv6 next-hop in BGP LU, but probably does not work out-of-the-box? > Isn't Segment Routing implementation day1 IPV4+IPV6 in XR? The last time I checked, MPLS support in SR for IPv6 is not a high priority, compared to TE for IPv4 MPLS. My thoughts that SR would automatically mean native label signaling in IS-IS and OSPFv3 were otherwise ambitious. Mark. From skhuraijam at liveops.com Fri Feb 20 22:17:25 2015 From: skhuraijam at liveops.com (Sudeep Khuraijam) Date: Fri, 20 Feb 2015 14:17:25 -0800 Subject: Interesting BFD discussion on reddit In-Reply-To: <20150217074324.GB7567@pob.ytti.fi> References: <20150215222540.GA15215@pob.ytti.fi> <20150217074324.GB7567@pob.ytti.fi> Message-ID: >On (2015-02-17 06:11 +0530), Glen Kent wrote: > >> I think the hardware used was Broadcom. They have a few chipsets which >>do >> MD5 and (possibly) SHA in hardware for BFD -- which i have been told is >> pretty much useless when you start scaling. While I don¹t fully understand the context of this particular test and the scaling limitation, there are merchant silicon, NPUs and even CPUs that do support MD5 and SHA at transport line rate requirements. BFD requirements are just a fraction of these capabilities. The option to negotiate capabilities should be available independent of scaling/cost/inefficiencies at present time. It is a matter of implementation/product design choice. Sudeep Khuraijam From jeff.tantsura at ericsson.com Fri Feb 20 22:29:57 2015 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Fri, 20 Feb 2015 22:29:57 +0000 Subject: draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: <54E7AFFD.3090502@seacom.mu> References: <20150220113959.GA8476@pob.ytti.fi>,<54E7AFFD.3090502@seacom.mu> Message-ID: <7B981046-FB9E-41F5-BA29-B5FEB2229348@ericsson.com> >From market prospective v6 SR is definitely lower priority. Comcast and few more are looking into native rather than v6 with MPLS encap. Wrt v4 - 2 weeks ago at EANTC in Berlin we have tested 3 implementations of ISIS SR v4 MPLS with L3VPN and 6VPE over SR tunnels. Worked very well, very few issues. So there's production quality code and interoperability - given the timeframe we have done a really good job in IETF :) Regards, Jeff > On Feb 20, 2015, at 2:09 PM, Mark Tinka wrote: > > > >> On 20/Feb/15 13:39, Saku Ytti wrote: >> >> Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to accept >> IPv6 next-hop in BGP LU, but probably does not work out-of-the-box? >> Isn't Segment Routing implementation day1 IPV4+IPV6 in XR? > > The last time I checked, MPLS support in SR for IPv6 is not a high > priority, compared to TE for IPv4 MPLS. > > My thoughts that SR would automatically mean native label signaling in > IS-IS and OSPFv3 were otherwise ambitious. > > Mark. From jeff.tantsura at ericsson.com Fri Feb 20 22:35:39 2015 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Fri, 20 Feb 2015 22:35:39 +0000 Subject: draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: <20150220211752.GA17475@pob.ytti.fi> References: <20150220113959.GA8476@pob.ytti.fi> , <20150220211752.GA17475@pob.ytti.fi> Message-ID: For L2VPN if you could make it work - go with EVPN day 1, it solves most of the issues present in both LDP and BGP VPLS implementations. Be aware of differences in PBB vs plain EVPN and platform support. EVPN, specifically multhoming/split horizon/some other stuff as well as presence of L3 (type 2/5) and complications of above brings lots of complexity into fast path processing and not every platform/NPU can do full spec. Regards, Jeff > On Feb 20, 2015, at 1:19 PM, Saku Ytti wrote: > > On (2015-02-20 09:00 -0500), Tim Durack wrote: > > Hey Tim, > >> I also need some flavor of L2VPN (eVPN) and L3VPN (VPNv4/VPNv6) working >> over IPv6. > > L3VPN uses BGP exclusively for VPN label signalling, no need for LDP. > > For L2VPN only Martini uses LDP, but if you have choice, why wouldn't you > choose Kompella, the scaling factor is superior, as you only have 2 signalling > connection, instead of n*(n-1)/2 signalling sessions. And you get to > capitalize on instantly available backuo path. > Of course I know that in CSCO land Kompella isn't available on every platform > where Martini is, so you indeed may need LDP for some time until old platforms > are phased out. 'Luckily' these older platforms have dubious IPv6 anyhow, so > you might opt them out from IPv6 deployment anyhow. > >> IPv6 control plane this decade may yet be optimistic. > > For greenfield it's doable today (only Kompella pseudowires), but IPv6-only > would require 4PE, I don't know if that works/exists. > > -- > ++ytti From tdurack at gmail.com Sat Feb 21 00:44:25 2015 From: tdurack at gmail.com (Tim Durack) Date: Fri, 20 Feb 2015 19:44:25 -0500 Subject: [j-nsp] draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: <627266B72B856946BCD625D4B34B1916A3215B@INF-EXCH-MB-02.gammatelecom.com> References: <20150220113959.GA8476@pob.ytti.fi> <627266B72B856946BCD625D4B34B1916A31F96@INF-EXCH-MB-02.gammatelecom.com> <627266B72B856946BCD625D4B34B1916A3215B@INF-EXCH-MB-02.gammatelecom.com> Message-ID: On Fri, Feb 20, 2015 at 6:02 PM, Adam Vitkovsky wrote: > Alright so would you mind sharing the business drivers that would make > you migrate your current production infrastructure to this new unproven > possibly buggy LDPv6 and 4PE/4VPE setup please? > > > > adam > Businesses bigger than me think there is a business driver for IPv6: http://meetings.ripe.net/ripe-54/presentations/IPv6_management.pdf http://www.internetsociety.org/deploy360/wp-content/uploads/2014/04/WorldIPv6Congress-IPv6_LH-v2.pdf IPv6 management of equipment is relatively easy. Once you've started down that path, you start looking at the protocol stuff, and wondering what to do about that. Maybe I should leave it alone until the business people figure it out for me :-) Tim:> From mansaxel at besserwisser.org Sat Feb 21 10:25:38 2015 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sat, 21 Feb 2015 11:25:38 +0100 Subject: v6 deagg In-Reply-To: References: <20150220080726.GA23425@pob.ytti.fi> Message-ID: <20150221102537.GA31907@besserwisser.org> Subject: Re: v6 deagg Date: Fri, Feb 20, 2015 at 10:42:03AM +0100 Quoting Mikael Abrahamsson (swmike at swm.pp.se): > From a technical point of view, I have little interest in my router > handling the fact that an office at the other side of the planet > shut down their router, and learning this via DFZ. I'm working at one of those organisations who have a /48 and am announcing it into DFZ. We have a situation where I might have another site with separate connectivity to the DFZ (but there is internal networking) which would entitle me to another /48 according to RIR rules. I did ask my LIR whether there is any thought given to the possibility of getting the next higher prefix, thus creating a /47. They did understand the "why" perfectly well, of course. However, apparently there is no such process or intention available from the RIR in question (RIPE), short of explicitly asking for that specific prefix. Of course this does not help every case, but supporting aggregation where possible certainly ought to be in-scope for most policy-making bodies in this area. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm wearing PAMPERS!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From sander at steffann.nl Sat Feb 21 12:48:48 2015 From: sander at steffann.nl (Sander Steffann) Date: Sat, 21 Feb 2015 13:48:48 +0100 Subject: v6 deagg In-Reply-To: <20150221102537.GA31907@besserwisser.org> References: <20150220080726.GA23425@pob.ytti.fi> <20150221102537.GA31907@besserwisser.org> Message-ID: Hi Mans, > I'm working at one of those organisations who have a /48 and am announcing > it into DFZ. We have a situation where I might have another site with > separate connectivity to the DFZ (but there is internal networking) > which would entitle me to another /48 according to RIR rules. Correct. > I did ask my LIR whether there is any thought given to the possibility of > getting the next higher prefix, thus creating a /47. They did understand > the "why" perfectly well, of course. > > However, apparently there is no such process or intention available > from the RIR in question (RIPE), short of explicitly asking for that > specific prefix. So you asked to grow the /48 to a /47? Was it accepted? Or did you want the RIR to automatically grow your first assignment when you request a second one without you having to ask? > Of course this does not help every case, but supporting aggregation > where possible certainly ought to be in-scope for most policy-making > bodies in this area. Then please take this to the appropriate policy-making body: address-policy-wg at ripe.net :-) Cheers! Sander From bill at herrin.us Sat Feb 21 19:06:37 2015 From: bill at herrin.us (William Herrin) Date: Sat, 21 Feb 2015 14:06:37 -0500 Subject: v6 deagg In-Reply-To: References: Message-ID: On Thu, Feb 19, 2015 at 10:07 PM, Randy Bush wrote: > but then we considered that v6 allocations seem to be /32s, and the > longest propagating route seems to be /48, leaving 16 bits with which > the deaggregators can play. while in v4 it was /24s out of a /19 or > /20, four or five bits. > > this does not bode well. Howdy, I took a look at what it might take to keep TE-based disaggregation under control back in 2009. This is what I came up with: http://lists.arin.net/pipermail/arin-ppml/2009-June/014351.html Needless to say, the sparse allocation expandable netmask strategy we're using instead doesn't have many levers we can grab for control. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From josh.rogers at twcable.com Sat Feb 21 14:28:16 2015 From: josh.rogers at twcable.com (Rogers, Josh) Date: Sat, 21 Feb 2015 09:28:16 -0500 Subject: draft-ietf-mpls-ldp-ipv6-16 Message-ID: RFC7349 is a nice summary of everything we¹re still missing wrt MPLS and is relatively recent so should be close to up to date. In addition to the MPLS shortcomings, it also touches on recent IGP updates: >3.2.3.1. Interior Gateway Protocol (IGP) > > RFC 3630 [RFC3630] specifies a method of adding traffic engineering > capabilities to OSPF Version 2. New TLVs and sub-TLVs were added in > RFC 5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF > Version 3. > > RFC 5305 [RFC5305] specifies a method of adding traffic engineering > capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC 6119 > [RFC6119] to extend TE capabilities to IPv6 networks. > > Gap: None. When you talk to your vendor, ask what code will support these RFC¹s. -Josh >On 2/21/15, 6:00 AM, "nanog-request at nanog.org" >wrote: > >>---------------------------------------------------------------------- >> >>Message: 1 >>Date: Fri, 20 Feb 2015 09:00:07 -0500 >>From: Tim Durack >>To: Saku Ytti >>Cc: "nanog at nanog.org" , Juniper-Nsp >> , "cisco-nsp at puck.nether.net" >> >>Subject: Re: draft-ietf-mpls-ldp-ipv6-16 >>Message-ID: >> >>Content-Type: text/plain; charset=UTF-8 >> >>On Fri, Feb 20, 2015 at 6:39 AM, Saku Ytti wrote: >> >>>On (2015-02-19 11:06 -0500), Tim Durack wrote: >>> >>>> What is the chance of getting working code this decade? I would quite >>>like >>>> to play with this new fangled IPv6 widget... >>>> >>>> (Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last >>>> piece for me.) >>> >>>Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to >>>accept >>>IPv6 next-hop in BGP LU, but probably does not work out-of-the-box? >>>Isn't Segment Routing implementation day1 IPV4+IPV6 in XR? >>> >>>-- >>> ++ytti >>> >> >>I would gladly take OSPFv2/OSPFv3/ISIS+SR over LDP, but I'm seeing that >>is >>not all that is needed. >> >>I also need some flavor of L2VPN (eVPN) and L3VPN (VPNv4/VPNv6) working >>over IPv6. >> >>IPv6 control plane this decade may yet be optimistic. >> >>-- >>Tim:> >> > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From mansaxel at besserwisser.org Sun Feb 22 07:36:15 2015 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 22 Feb 2015 08:36:15 +0100 Subject: v6 deagg In-Reply-To: References: <20150220080726.GA23425@pob.ytti.fi> <20150221102537.GA31907@besserwisser.org> Message-ID: <20150222073615.GB9849@besserwisser.org> Subject: Re: v6 deagg Date: Sat, Feb 21, 2015 at 01:48:48PM +0100 Quoting Sander Steffann (sander at steffann.nl): > > However, apparently there is no such process or intention available > > from the RIR in question (RIPE), short of explicitly asking for that > > specific prefix. > > So you asked to grow the /48 to a /47? Was it accepted? Or did you want the RIR to automatically grow your first assignment when you request a second one without you having to ask? So far have just discussed it with my LIR, but will reinit this. > > Of course this does not help every case, but supporting aggregation > > where possible certainly ought to be in-scope for most policy-making > > bodies in this area. > > Then please take this to the appropriate policy-making body: address-policy-wg at ripe.net :-) Considering this as well. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ... this must be what it's like to be a COLLEGE GRADUATE!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nick at foobar.org Sun Feb 22 16:21:04 2015 From: nick at foobar.org (Nick Hilliard) Date: Sun, 22 Feb 2015 16:21:04 +0000 Subject: draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: References: Message-ID: <54EA01F0.1060505@foobar.org> On 21/02/2015 14:28, Rogers, Josh wrote: > RFC7349 is a nice summary of everything we¹re still missing wrt MPLS and > is relatively recent so should be close to up to date. In addition to the > MPLS shortcomings, it also touches on recent IGP updates: rfc7439, not 7349: https://tools.ietf.org/html/rfc7439 Nick > >> 3.2.3.1. Interior Gateway Protocol (IGP) >> >> RFC 3630 [RFC3630] specifies a method of adding traffic engineering >> capabilities to OSPF Version 2. New TLVs and sub-TLVs were added in >> RFC 5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF >> Version 3. >> >> RFC 5305 [RFC5305] specifies a method of adding traffic engineering >> capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC 6119 >> [RFC6119] to extend TE capabilities to IPv6 networks. >> >> Gap: None. > > When you talk to your vendor, ask what code will support these RFC¹s. > > > -Josh > > > >> On 2/21/15, 6:00 AM, "nanog-request at nanog.org" >> wrote: >> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Fri, 20 Feb 2015 09:00:07 -0500 >>> From: Tim Durack >>> To: Saku Ytti >>> Cc: "nanog at nanog.org" , Juniper-Nsp >>> , "cisco-nsp at puck.nether.net" >>> >>> Subject: Re: draft-ietf-mpls-ldp-ipv6-16 >>> Message-ID: >>> >>> Content-Type: text/plain; charset=UTF-8 >>> >>> On Fri, Feb 20, 2015 at 6:39 AM, Saku Ytti wrote: >>> >>>> On (2015-02-19 11:06 -0500), Tim Durack wrote: >>>> >>>>> What is the chance of getting working code this decade? I would quite >>>> like >>>>> to play with this new fangled IPv6 widget... >>>>> >>>>> (Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last >>>>> piece for me.) >>>> >>>> Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to >>>> accept >>>> IPv6 next-hop in BGP LU, but probably does not work out-of-the-box? >>>> Isn't Segment Routing implementation day1 IPV4+IPV6 in XR? >>>> >>>> -- >>>> ++ytti >>>> >>> >>> I would gladly take OSPFv2/OSPFv3/ISIS+SR over LDP, but I'm seeing that >>> is >>> not all that is needed. >>> >>> I also need some flavor of L2VPN (eVPN) and L3VPN (VPNv4/VPNv6) working >>> over IPv6. >>> >>> IPv6 control plane this decade may yet be optimistic. >>> >>> -- >>> Tim:> >>> >> > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > From peterl at standingwave.org Mon Feb 23 06:25:17 2015 From: peterl at standingwave.org (Peter Loron) Date: Sun, 22 Feb 2015 22:25:17 -0800 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) In-Reply-To: References: Message-ID: <01B46F51-F1C0-4C4B-966D-A9C6B3AB264A@standingwave.org> Apologies for a bit off topic, but I’m trying to get an issue resolved and am having trouble reaching anybody who seems clue positive. From home via Comcast cable, I’m having trouble reaching some destinations. According to mtr, there is a particular node (be-11-pe02.11greatoaks.ca.ibone.comcast.net) which is suffering > 30% loss. Contacting the Comcast consumer support folks is useless (what are the lights on your modem doing? Did you power cycle it?). When this is happening, I usually am told they need to send a tech to my house. . Is there a way to drop a note to the NOC or other folks who would understand the info and be able to act on it? Thanks! -Pete > On Jan 23, 2015, at 09:14, Brzozowski, John wrote: > > Folks, > > The thread below was sent to me a few times, apologies for not catching it sooner. > > Janet, > > I sent you mail unicast with a request for some information. I am happy to help you out. > > For the larger NANOG audience, Comcast has recently launched IPv6 support for our BCI products, these are our DOCSIS based commercial offerings. This means that if you gateway device is in fact in RG mode you will be delegated a dynamic IPv6 prefix, by default customers are delegated a /56 prefix along with a single IPv6 address that is assigned to the WAN of the gateway device. IPv6 support applies to the following makes and models: > > SMC D3G CCR (http://mydeviceinfo.comcast.net/device.php?devid=216) > Cisco BWG (http://mydeviceinfo.comcast.net/device.php?devid=347) > Netgear CG3000D (http://mydeviceinfo.comcast.net/device.php?devid=347) > > For customers where you bring your own cable modem or have one of the above in bridge mode we have enabled IPv6 support for you as well. However, your router behind the modem must be running software and configured with IPv6 support. Specifically, your router needs to be support stateful DHCPv6 for IPv6 address and prefix acquisition. We have received a number of reports from customers that the Juniper SRX does not appear to properly support IPv6. We are working with Juniper and also recommend that you reach out to Juniper as well. > > Please keep checking http://www.comcast6.net for updates, we will post some additional information here in the next week or so. In the mean time if you have questions feel free to send me mail or post them here on the NANOG list. > > HTH, > > John > ========================================= > John Jason Brzozowski > Comcast Cable > p) 484-962-0060 > w) www.comcast6.net > e) john_brzozowski at cable.comcast.com > ========================================= > > > > -----Original Message----- > From: "nanog-request at nanog.org" > > Reply-To: NANOG > > Date: Friday, January 23, 2015 at 07:00 > To: NANOG > > Subject: NANOG Digest, Vol 84, Issue 23 > > Date: Thu, 22 Jan 2015 22:42:17 +0000 > From: Janet Sullivan > > To: "'nanog at nanog.org'" > > Subject: Comcast Support > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > I hate to use NANOG for this, but support has now ended a chat with me twice without fixing anything, they just kicked me off. > > I'm not getting an IPv6 address on the Comcast provided cable modem/router. I'm not getting a PD. My machines thus have no IPv6. I've hard reset my router 4 times while working with Comcast, and I've been told to do things like switch to a static IPv4 address, which shows a level of clue that is scary. And before that they were convinced it was a wireless problem even though I have a wired connection, and told them that multiple times. I've wasted two hours with Comcast today, and even when I asked for escalation I got nothing. Just hung up on. It's honestly the worst customer support I've ever received. I don't think I ever got them to understand the difference between IPv4 and IPv6. From md at Linux.IT Mon Feb 23 10:46:29 2015 From: md at Linux.IT (Marco d'Itri) Date: Mon, 23 Feb 2015 11:46:29 +0100 Subject: v6 deagg In-Reply-To: <20150220080726.GA23425@pob.ytti.fi> References: <20150220080726.GA23425@pob.ytti.fi> Message-ID: <20150223104629.GA1969@bongo.bofh.it> On Feb 20, Saku Ytti wrote: > Is deaggregation inherently undesirable? In some RIR LIR will not get new No. Excessive deaggregation is undesirable, but we lack a method to teach routers to enforce this subtlety and maybe also a wide agreement on what is excessive. > allocation, just because LIR lacks INET connectivity between their datacenter > or pop. > This wasn't issue in IPv4, because you actually could reasonably fill your > IPv4 allocation and were eligible for another allocation for your > discontinuous locations. But at least in the RIPE region this can be easily solved by deaggregating /32s out of your /29. -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 648 bytes Desc: not available URL: From Kevin_McElearney at cable.comcast.com Mon Feb 23 14:16:37 2015 From: Kevin_McElearney at cable.comcast.com (McElearney, Kevin) Date: Mon, 23 Feb 2015 14:16:37 +0000 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) In-Reply-To: <01B46F51-F1C0-4C4B-966D-A9C6B3AB264A@standingwave.org> References: <01B46F51-F1C0-4C4B-966D-A9C6B3AB264A@standingwave.org> Message-ID: You forgot to use the word “Shibboleet” when you called care. Contacted Peter off-list - Kevin On 2/23/15, 1:25 AM, "Peter Loron" wrote: >Apologies for a bit off topic, but I’m trying to get an issue resolved >and am having trouble reaching anybody who seems clue positive. > >From home via Comcast cable, I’m having trouble reaching some >destinations. According to mtr, there is a particular node >(be-11-pe02.11greatoaks.ca.ibone.comcast.net) which is suffering > 30% >loss. Contacting the Comcast consumer support folks is useless (what are >the lights on your modem doing? Did you power cycle it?). When this is >happening, I usually am told they need to send a tech to my house. >. > >Is there a way to drop a note to the NOC or other folks who would >understand the info and be able to act on it? > >Thanks! > >-Pete >> On Jan 23, 2015, at 09:14, Brzozowski, John >> wrote: >> >> Folks, >> >> The thread below was sent to me a few times, apologies for not catching >>it sooner. >> >> Janet, >> >> I sent you mail unicast with a request for some information. I am >>happy to help you out. >> >> For the larger NANOG audience, Comcast has recently launched IPv6 >>support for our BCI products, these are our DOCSIS based commercial >>offerings. This means that if you gateway device is in fact in RG mode >>you will be delegated a dynamic IPv6 prefix, by default customers are >>delegated a /56 prefix along with a single IPv6 address that is assigned >>to the WAN of the gateway device. IPv6 support applies to the following >>makes and models: >> >> SMC D3G CCR (http://mydeviceinfo.comcast.net/device.php?devid=216) >> Cisco BWG (http://mydeviceinfo.comcast.net/device.php?devid=347) >> Netgear CG3000D (http://mydeviceinfo.comcast.net/device.php?devid=347) >> >> For customers where you bring your own cable modem or have one of the >>above in bridge mode we have enabled IPv6 support for you as well. >>However, your router behind the modem must be running software and >>configured with IPv6 support. Specifically, your router needs to be >>support stateful DHCPv6 for IPv6 address and prefix acquisition. We >>have received a number of reports from customers that the Juniper SRX >>does not appear to properly support IPv6. We are working with Juniper >>and also recommend that you reach out to Juniper as well. >> >> Please keep checking http://www.comcast6.net for updates, we will post >>some additional information here in the next week or so. In the mean >>time if you have questions feel free to send me mail or post them here >>on the NANOG list. >> >> HTH, >> >> John >> ========================================= >> John Jason Brzozowski >> Comcast Cable >> p) 484-962-0060 >> w) www.comcast6.net >> e) john_brzozowski at cable.comcast.com >> ========================================= >> >> >> >> -----Original Message----- >> From: "nanog-request at nanog.org" >>> >> Reply-To: NANOG > >> Date: Friday, January 23, 2015 at 07:00 >> To: NANOG > >> Subject: NANOG Digest, Vol 84, Issue 23 >> >> Date: Thu, 22 Jan 2015 22:42:17 +0000 >> From: Janet Sullivan > >> To: "'nanog at nanog.org'" >>> >> Subject: Comcast Support >> Message-ID: >> >>>utlook.com>4.namprd07.prod.outlook.com>> >> Content-Type: text/plain; charset="us-ascii" >> >> I hate to use NANOG for this, but support has now ended a chat with me >>twice without fixing anything, they just kicked me off. >> >> I'm not getting an IPv6 address on the Comcast provided cable >>modem/router. I'm not getting a PD. My machines thus have no IPv6. >>I've hard reset my router 4 times while working with Comcast, and I've >>been told to do things like switch to a static IPv4 address, which shows >>a level of clue that is scary. And before that they were convinced it >>was a wireless problem even though I have a wired connection, and told >>them that multiple times. I've wasted two hours with Comcast today, and >>even when I asked for escalation I got nothing. Just hung up on. It's >>honestly the worst customer support I've ever received. I don't think I >>ever got them to understand the difference between IPv4 and IPv6. > > From ekgermann at cctec.com Mon Feb 23 15:02:44 2015 From: ekgermann at cctec.com (Eric Germann) Date: Mon, 23 Feb 2015 10:02:44 -0500 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Message-ID: Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. Users access apps in the VPC, not the other direction. The issue I'm trying to get around is the customers who need to connect have multiple overlapping RFC1918 space (including overlapping what was proposed for the VPC networks). Finding a hole that is big enough and not in use by someone else is nearly impossible AND the customers could go through mergers which make them renumber even more in to overlapping 1918 space. Initially, I was looking at doing something like (example IP’s): Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC <——> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) Classic overlapping subnets on both ends with allocations out of 100.64.0.0/10 to NAT in both directions. Each sees the other end in 100.64 space, but the mappings can get tricky and hard to keep track of (especially if you’re not a network engineer). In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in the VPC?” Then, the customer would be allocated a /28 or larger (depending on needs) to NAT on their side and NAT it once. After that, no more NAT for the VPC and it boils down to firewall rules. Their device needs to NAT outbound before it fires it down the tunnel which pfSense and ASA’s appear to be able to do. I prototyped this up over the weekend with multiple VPC’s in multiple regions and it “appears” to work fine. From the operator community, what are the downsides? Customers are businesses on dedicated business services vs. consumer cable modems (although there are a few on business class cable). Others are on MPLS and I’m hashing that out. The only one I can see is if the customer has a service provider with their external interface in 100.64 space. However, this approach would have a more specific in that space so it should fire it down the tunnel for their allocated customer block (/28) vs. their external side. Thoughts and thanks in advance. Eric From cb.list6 at gmail.com Mon Feb 23 15:52:36 2015 From: cb.list6 at gmail.com (Ca By) Date: Mon, 23 Feb 2015 07:52:36 -0800 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann wrote: > Currently engaged on a project where they’re building out a VPC > infrastructure for hosted applications. > > Users access apps in the VPC, not the other direction. > > The issue I'm trying to get around is the customers who need to connect > have multiple overlapping RFC1918 space (including overlapping what was > proposed for the VPC networks). Finding a hole that is big enough and not > in use by someone else is nearly impossible AND the customers could go > through mergers which make them renumber even more in to overlapping 1918 > space. > > Initially, I was looking at doing something like (example IP’s): > > > Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC <——> > NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) > > Classic overlapping subnets on both ends with allocations out of > 100.64.0.0/10 to NAT in both directions. Each sees the other end in > 100.64 space, but the mappings can get tricky and hard to keep track of > (especially if you’re not a network engineer). > > > In spitballing, the boat hasn’t sailed too far to say “Why not use > 100.64/10 in the VPC?” > > Then, the customer would be allocated a /28 or larger (depending on needs) > to NAT on their side and NAT it once. After that, no more NAT for the VPC > and it boils down to firewall rules. Their device needs to NAT outbound > before it fires it down the tunnel which pfSense and ASA’s appear to be > able to do. > > I prototyped this up over the weekend with multiple VPC’s in multiple > regions and it “appears” to work fine. > > From the operator community, what are the downsides? > > Customers are businesses on dedicated business services vs. consumer cable > modems (although there are a few on business class cable). Others are on > MPLS and I’m hashing that out. > > The only one I can see is if the customer has a service provider with > their external interface in 100.64 space. However, this approach would > have a more specific in that space so it should fire it down the tunnel for > their allocated customer block (/28) vs. their external side. > > Thoughts and thanks in advance. > > Eric > Wouldn't it be nice if Amazon supported IPv6 in VPC? I have disqualified several projects from using the "public cloud" and put them in the on-premise "private cloud" because Amazon is missing this key scaling feature -- ipv6. It is odd that Amazon, a company with scale deeply in its DNA, fails so hard on IPv6. I guess they have a lot of brittle technical debt they can't upgrade. I suggest you go with private cloud if possible. Or, you can double NAT non-unique IPv4 space. Regarding 100.64.0.0/10, despite what the RFCs may say, this space is just an augment of RFC1918 and i have already deployed it as such. CB From Jason_Livingood at cable.comcast.com Mon Feb 23 16:04:53 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Mon, 23 Feb 2015 16:04:53 +0000 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) In-Reply-To: <01B46F51-F1C0-4C4B-966D-A9C6B3AB264A@standingwave.org> References: <01B46F51-F1C0-4C4B-966D-A9C6B3AB264A@standingwave.org> Message-ID: FWIW, if you phone support you generally end up with a tier-1 person. In cases where people have more technical background, you may want to try things that land in more senior levels of Care (or even get checked by engineering directly) such as: - Customer support forums: http://forums.comcast.com/comcastsupport/ - Twitter: @ComcastCares https://twitter.com/comcastcares - Broadband Reports forum: http://www.dslreports.com/forum/comcast - Reddit: http://www.reddit.com/r/comcast - Jason On 2/23/15, 1:25 AM, "Peter Loron" > wrote: Apologies for a bit off topic, but I’m trying to get an issue resolved and am having trouble reaching anybody who seems clue positive From amitchell at isipp.com Mon Feb 23 16:19:36 2015 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Mon, 23 Feb 2015 09:19:36 -0700 Subject: What would you do about questionable domain pointing A record to your IP address? In-Reply-To: References: <99269447-57E1-4B93-BC51-8BFA2D24F9AC@isipp.com> Message-ID: Thank you, everyone, for all of the responses, both on and offlist! Anne Anne P. Mitchell, Esq. CEO/President ISIPP SuretyMail Email Reputation, Accreditation & Certification Your mail system + SuretyMail accreditation = delivered to their inbox! http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Author: Section 6 of the Federal CAN-SPAM Act of 2003 Member, California Bar Cyberspace Law Committee Ret. Professor of Law, Lincoln Law School of San Jose 303-731-2121 | amitchell at isipp.com | @AnnePMitchell | Facebook/AnnePMitchell From tony at swalter.com Mon Feb 23 17:24:29 2015 From: tony at swalter.com (Tony Patti) Date: Mon, 23 Feb 2015 12:24:29 -0500 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) In-Reply-To: References: <01B46F51-F1C0-4C4B-966D-A9C6B3AB264A@standingwave.org> Message-ID: <1a6901d04f8d$94852080$bd8f6180$@swalter.com> While Jason obviously has the most authoritative perspective, I want to also mention Comcast's "we're on it" department, and their self-described no-wait hotline at 866-671-5645, as has been publicly described (links below). http://www.comcast.com/onit http://dealnews.com/features/Comcast-Wants-to-Win-You-Over-with-an-Exclusive -No-Wait-Hotline/1119817.html http://www.theverge.com/2014/8/7/5971857/we-re-on-it-comcast-customer-servic e-employees-cards Tony Patti CIO S. Walter Packaging -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Livingood, Jason Sent: Monday, February 23, 2015 11:05 AM To: Peter Loron Cc: nanog at nanog.org Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23) FWIW, if you phone support you generally end up with a tier-1 person. In cases where people have more technical background, you may want to try things that land in more senior levels of Care (or even get checked by engineering directly) such as: - Customer support forums: http://forums.comcast.com/comcastsupport/ - Twitter: @ComcastCares https://twitter.com/comcastcares - Broadband Reports forum: http://www.dslreports.com/forum/comcast - Reddit: http://www.reddit.com/r/comcast - Jason On 2/23/15, 1:25 AM, "Peter Loron" > wrote: Apologies for a bit off topic, but I'm trying to get an issue resolved and am having trouble reaching anybody who seems clue positive From bill at herrin.us Mon Feb 23 17:58:24 2015 From: bill at herrin.us (William Herrin) Date: Mon, 23 Feb 2015 12:58:24 -0500 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: On Mon, Feb 23, 2015 at 10:02 AM, Eric Germann wrote: > In spitballing, the boat hasn't sailed too far to say "Why not > use 100.64/10 in the VPC?" > > The only one I can see is if the customer has a service provider > with their external interface in 100.64 space. However, this > approach would have a more specific in that space so it > should fire it down the tunnel for their allocated customer > block (/28) vs. their external side. Hi Eric, The main risk is more or less as you summarized it. Customer has no firewall or originates the VPN directly from their firewall. Customer buys a non-hosting commodity Internet product that uses carrier NAT to conserve IP addresses. The customer's assigned address AND NETMASK combined overlap some of the hosts you're trying to publish to them. Mitigations for that risk: Can you insist that the customer originate connections from inside their firewall (on RFC1918 space)? Most service providers using 100.64/10 either permit customers to opt out (getting dynamic globally routable addresses) or offer customers the opportunity to purchase static global addresses for a nominal fee. Are you comfortable telling impacted customers that they have to do so? A secondary risk comes in to play where a customer may wish to interact with another service provider doing the same thing as you. That essentially lands you back in the same problem you're having now with RFC1918. One more question you should consider: what is the nature of your customer's networks? Big corps that tend to stretch through 10/8 won't let their users originate VPN connections in the first place. They also don't touch 100.64/10 except where someone is publishing a service like yours. Meanwhile, home and SOHO users who are at liberty to originate VPNs might currently hold a 100.64/10 address. But they just about never use the off-bit /16s in 10/8. By off-bit I mean the ones with 4 or 5 random 1-bits in the second octet. My opinion: The likelihood of collisions in 100.64/10 increases significantly if you use them on servers. I would confine my use to client machines and try to put servers providing service to multiple organizations on globally unique IPs. Confining 100.64/10 to client machines, you're unlikely to encounter a problem you can't readily solve. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From lnguyen at opsource.net Mon Feb 23 15:57:05 2015 From: lnguyen at opsource.net (Luan Nguyen) Date: Mon, 23 Feb 2015 10:57:05 -0500 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: I put lots of these to good use http://en.wikipedia.org/wiki/Reserved_IP_addresses Regarding public cloud with ipv6 support, contact me off-list i might even get you a special discount On Mon, Feb 23, 2015 at 10:52 AM, Ca By wrote: > On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann wrote: > > > Currently engaged on a project where they’re building out a VPC > > infrastructure for hosted applications. > > > > Users access apps in the VPC, not the other direction. > > > > The issue I'm trying to get around is the customers who need to connect > > have multiple overlapping RFC1918 space (including overlapping what was > > proposed for the VPC networks). Finding a hole that is big enough and > not > > in use by someone else is nearly impossible AND the customers could go > > through mergers which make them renumber even more in to overlapping 1918 > > space. > > > > Initially, I was looking at doing something like (example IP’s): > > > > > > Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC > <——> > > NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) > > > > Classic overlapping subnets on both ends with allocations out of > > 100.64.0.0/10 to NAT in both directions. Each sees the other end in > > 100.64 space, but the mappings can get tricky and hard to keep track of > > (especially if you’re not a network engineer). > > > > > > In spitballing, the boat hasn’t sailed too far to say “Why not use > > 100.64/10 in the VPC?” > > > > Then, the customer would be allocated a /28 or larger (depending on > needs) > > to NAT on their side and NAT it once. After that, no more NAT for the > VPC > > and it boils down to firewall rules. Their device needs to NAT outbound > > before it fires it down the tunnel which pfSense and ASA’s appear to be > > able to do. > > > > I prototyped this up over the weekend with multiple VPC’s in multiple > > regions and it “appears” to work fine. > > > > From the operator community, what are the downsides? > > > > Customers are businesses on dedicated business services vs. consumer > cable > > modems (although there are a few on business class cable). Others are on > > MPLS and I’m hashing that out. > > > > The only one I can see is if the customer has a service provider with > > their external interface in 100.64 space. However, this approach would > > have a more specific in that space so it should fire it down the tunnel > for > > their allocated customer block (/28) vs. their external side. > > > > Thoughts and thanks in advance. > > > > Eric > > > > Wouldn't it be nice if Amazon supported IPv6 in VPC? > > I have disqualified several projects from using the "public cloud" and put > them in the on-premise "private cloud" because Amazon is missing this key > scaling feature -- ipv6. It is odd that Amazon, a company with scale > deeply in its DNA, fails so hard on IPv6. I guess they have a lot of > brittle technical debt they can't upgrade. > > I suggest you go with private cloud if possible. > > Or, you can double NAT non-unique IPv4 space. > > Regarding 100.64.0.0/10, despite what the RFCs may say, this space is just > an augment of RFC1918 and i have already deployed it as such. > > CB > From randy at psg.com Mon Feb 23 18:33:38 2015 From: randy at psg.com (Randy Bush) Date: Tue, 24 Feb 2015 03:33:38 +0900 Subject: v6 deagg In-Reply-To: <20150223104629.GA1969@bongo.bofh.it> References: <20150220080726.GA23425@pob.ytti.fi> <20150223104629.GA1969@bongo.bofh.it> Message-ID: > Excessive deaggregation is undesirable, but we lack a method to teach > routers to enforce this subtlety you might find http://www.route-aggregation.net/ interesting randy From peterl at standingwave.org Mon Feb 23 18:45:04 2015 From: peterl at standingwave.org (Peter Loron) Date: Mon, 23 Feb 2015 10:45:04 -0800 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) In-Reply-To: References: <01B46F51-F1C0-4C4B-966D-A9C6B3AB264A@standingwave.org> Message-ID: Ok, thanks. I was unaware there were Comcast support folks working those outlets. -Pete On 2015-02-23 08:04, Livingood, Jason wrote: > FWIW, if you phone support you generally end up with a tier-1 person. > In cases where people have more technical background, you may want to > try things that land in more senior levels of Care (or even get > checked by engineering directly) such as: > > - Customer support forums: http://forums.comcast.com/comcastsupport/ > [1] > - Twitter: @ComcastCares https://twitter.com/comcastcares [2] > - Broadband Reports forum: http://www.dslreports.com/forum/comcast [3] > > - Reddit: http://www.reddit.com/r/comcast [4] > > - Jason > > On 2/23/15, 1:25 AM, "Peter Loron" wrote: > >> Apologies for a bit off topic, but I’m trying to get an issue >> resolved and am having trouble reaching anybody who seems clue >> positive > > > > Links: > ------ > [1] http://forums.comcast.com/comcastsupport/ > [2] https://twitter.com/comcastcares > [3] http://www.dslreports.com/forum/comcast > [4] http://www.reddit.com/r/comcast From bensons at queuefull.net Mon Feb 23 18:52:18 2015 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 23 Feb 2015 13:52:18 -0500 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: <54EB76E2.30901@queuefull.net> Hi, Eric - Bill already described the salient points. The "transition" space is meant to be used for cases where there are multiple stacked NATs, such as CGN with CPE-based NAT. In theory, if the NAT implementations support it, one could use it repeatedly by stacking NAT on top of NAT ad nauseum, but the wisdom of doing so is questionable. If one uses it like additional RFC1918 space then routing could become more difficult, specifically in the case where hosts (e.g. VPC servers) are numbered with it. This is true because, in theory, you don't need the transition space to be routed on the "internal" network which avoids having NAT devices hold conflicting routes etc. Even if the edge NAT devices don't currently see conflicting routes to 100.64/10, if that changes in the future then client hosts may find themselves unable to reach the VPC hosts at that time. That being said, if you understand the risks that I described above, then it may work well for a "community of interest" type of inter-network that hosts non-global resources. From your description it sounds like that might be the situation you find yourself in. To be clear, it's not unwise to do so, but it does carry risk that needs to be evaluated (and documented). Cheers, -Benson > William Herrin > February 23, 2015 at 12:58 PM > > Hi Eric, > > The main risk is more or less as you summarized it. Customer has no > firewall or originates the VPN directly from their firewall. Customer > buys a non-hosting commodity Internet product that uses carrier NAT to > conserve IP addresses. The customer's assigned address AND NETMASK > combined overlap some of the hosts you're trying to publish to them. > > > > Mitigations for that risk: > > Can you insist that the customer originate connections from inside > their firewall (on RFC1918 space)? > > Most service providers using 100.64/10 either permit customers to opt > out (getting dynamic globally routable addresses) or offer customers > the opportunity to purchase static global addresses for a nominal fee. > Are you comfortable telling impacted customers that they have to do > so? > > > A secondary risk comes in to play where a customer may wish to > interact with another service provider doing the same thing as you. > That essentially lands you back in the same problem you're having now > with RFC1918. > > > One more question you should consider: what is the nature of your > customer's networks? Big corps that tend to stretch through 10/8 won't > let their users originate VPN connections in the first place. They > also don't touch 100.64/10 except where someone is publishing a > service like yours. Meanwhile, home and SOHO users who are at liberty > to originate VPNs might currently hold a 100.64/10 address. But they > just about never use the off-bit /16s in 10/8. By off-bit I mean the > ones with 4 or 5 random 1-bits in the second octet. > > > My opinion: The likelihood of collisions in 100.64/10 increases > significantly if you use them on servers. I would confine my use to > client machines and try to put servers providing service to multiple > organizations on globally unique IPs. Confining 100.64/10 to client > machines, you're unlikely to encounter a problem you can't readily > solve. > > Regards, > Bill Herrin > > > Eric Germann > February 23, 2015 at 10:02 AM > Currently engaged on a project where they’re building out a VPC > infrastructure for hosted applications. > > Users access apps in the VPC, not the other direction. > > The issue I'm trying to get around is the customers who need to > connect have multiple overlapping RFC1918 space (including overlapping > what was proposed for the VPC networks). Finding a hole that is big > enough and not in use by someone else is nearly impossible AND the > customers could go through mergers which make them renumber even more > in to overlapping 1918 space. > > Initially, I was looking at doing something like (example IP’s): > > > Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC > <——> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) > > Classic overlapping subnets on both ends with allocations out of > 100.64.0.0/10 to NAT in both directions. Each sees the other end in > 100.64 space, but the mappings can get tricky and hard to keep track > of (especially if you’re not a network engineer). > > > In spitballing, the boat hasn’t sailed too far to say “Why not use > 100.64/10 in the VPC?” > > Then, the customer would be allocated a /28 or larger (depending on > needs) to NAT on their side and NAT it once. After that, no more NAT > for the VPC and it boils down to firewall rules. Their device needs to > NAT outbound before it fires it down the tunnel which pfSense and > ASA’s appear to be able to do. > > I prototyped this up over the weekend with multiple VPC’s in multiple > regions and it “appears” to work fine. > > From the operator community, what are the downsides? > > Customers are businesses on dedicated business services vs. consumer > cable modems (although there are a few on business class cable). > Others are on MPLS and I’m hashing that out. > > The only one I can see is if the customer has a service provider with > their external interface in 100.64 space. However, this approach would > have a more specific in that space so it should fire it down the > tunnel for their allocated customer block (/28) vs. their external side. > > Thoughts and thanks in advance. > > Eric > > From john at west-canaan.net Mon Feb 23 20:28:58 2015 From: john at west-canaan.net (John Zettlemoyer) Date: Mon, 23 Feb 2015 15:28:58 -0500 Subject: AOL Postmaster Message-ID: Could someone from AOL who deals with the email systems please contact me off-list. Thank you. John Zettlemoyer WCiT LLC 856.310.1375 x221 john at wcit.net From mansaxel at besserwisser.org Mon Feb 23 20:43:13 2015 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Mon, 23 Feb 2015 21:43:13 +0100 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: <20150223204312.GG9849@besserwisser.org> Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Date: Mon, Feb 23, 2015 at 10:02:44AM -0500 Quoting Eric Germann (ekgermann at cctec.com): > Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. > Thoughts and thanks in advance. using the wasted /10 for this is pretty much equal to using RFC1918 space. IPv6 was invented to do this right. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 It's NO USE ... I've gone to "CLUB MED"!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From billpatterson84 at gmail.com Mon Feb 23 20:45:58 2015 From: billpatterson84 at gmail.com (Bill Patterson) Date: Mon, 23 Feb 2015 15:45:58 -0500 Subject: AOL Postmaster In-Reply-To: References: Message-ID: Did you suddenly start getting "AOL will not accept delivery of this message" bounce backs? On Feb 23, 2015 3:30 PM, "John Zettlemoyer" wrote: > Could someone from AOL who deals with the email systems please contact me > off-list. > Thank you. > > John Zettlemoyer > WCiT LLC > 856.310.1375 x221 > john at wcit.net > From john at west-canaan.net Mon Feb 23 20:56:14 2015 From: john at west-canaan.net (John Zettlemoyer) Date: Mon, 23 Feb 2015 15:56:14 -0500 Subject: AOL Postmaster In-Reply-To: References: Message-ID: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> No, started using an IP address that hasn’t been used since we got the range from Arin, and got this - 554- (RTR:BL) Tried to contact AOL through normal channels, and no response in over a week.  Feedback loop has been in place for years, and we check it every day (its clean). John Zettlemoyer From: Bill Patterson [mailto:billpatterson84 at gmail.com] Sent: Monday, February 23, 2015 3:46 PM To: John Zettlemoyer Cc: nanog at nanog.org Subject: Re: AOL Postmaster Did you suddenly start getting "AOL will not accept delivery of this message" bounce backs? On Feb 23, 2015 3:30 PM, "John Zettlemoyer" wrote: Could someone from AOL who deals with the email systems please contact me off-list. Thank you. John Zettlemoyer WCiT LLC 856.310.1375 x221 john at wcit.net From billpatterson84 at gmail.com Mon Feb 23 20:59:50 2015 From: billpatterson84 at gmail.com (Bill Patterson) Date: Mon, 23 Feb 2015 15:59:50 -0500 Subject: AOL Postmaster In-Reply-To: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> Message-ID: Ok, it took 21 days from the time I opened a ticket with them last month for them to respond to me. I ended up having to have our ISP update our rDNS. Not sure if it's something similar for you but I felt the same way after a week of waiting for a response from them. On Feb 23, 2015 3:56 PM, "John Zettlemoyer" wrote: > No, started using an IP address that hasn’t been used since we got the > range from Arin, and got this - 554- (RTR:BL) > > Tried to contact AOL through normal channels, and no response in over a > week. Feedback loop has been in place for years, and we check it every day > (its clean). > > > > John Zettlemoyer > > > > *From:* Bill Patterson [mailto:billpatterson84 at gmail.com] > *Sent:* Monday, February 23, 2015 3:46 PM > *To:* John Zettlemoyer > *Cc:* nanog at nanog.org > *Subject:* Re: AOL Postmaster > > > > Did you suddenly start getting "AOL will not accept delivery of this > message" bounce backs? > > On Feb 23, 2015 3:30 PM, "John Zettlemoyer" wrote: > > Could someone from AOL who deals with the email systems please contact me > off-list. > Thank you. > > John Zettlemoyer > WCiT LLC > 856.310.1375 x221 > john at wcit.net > From bill at herrin.us Tue Feb 24 01:22:02 2015 From: bill at herrin.us (William Herrin) Date: Mon, 23 Feb 2015 20:22:02 -0500 Subject: v6 deagg In-Reply-To: References: <20150220080726.GA23425@pob.ytti.fi> <20150223104629.GA1969@bongo.bofh.it> Message-ID: On Mon, Feb 23, 2015 at 1:33 PM, Randy Bush wrote: > you might find http://www.route-aggregation.net/ interesting Hi Randy, I found it very interesting. Wish I'd noticed when it was fresh. I don't fully understand the math yet but the algorithm doesn't smell right. As near as I can figure it may only be correct in a static system. If after convergence the disaggregate ceases to be reachable from the aggregate, there doesn't appear to be either enough information in the system or enough triggers traveling between routers for it to reconverge to a correct state. Deriving only from the information available to each router at each step, look at page 58 in the presentation and see if you can figure out what happens to the network in that start state when the link between u7 and u9 drops. Remember that all the slashed half-moons mean that the router in that position does not relay the disaggregate and, in most cases, does not know that the disaggregate exists. I've emailed the authors and asked them to clarify. I hope I'm wrong. I'm tried of being a killjoy on this sort of thing and it would be truly cool if it turns out they've cracked the problem. Regardless, if we could presume (with support from the registries) that disaggregates are always reachable from the aggregate (always TE, never downstream customers or discrete sites) and everybody with an address block was courteous enough to advertise an aggregate then it might be usable to control IPv6 deagg. Actually, as long as we could assume the first part we could probably have routers synthesize aggregates to cover the second. But without the first assumption it looks dysfunctional. I discussed the cutouts problem in my 2010 presentation to ARIN XXVI in Atlanta: https://bill.herrin.us/network/201010-cutouts.pdf Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From blair.trosper at gmail.com Tue Feb 24 02:03:43 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Mon, 23 Feb 2015 20:03:43 -0600 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: <20150223204312.GG9849@besserwisser.org> References: <20150223204312.GG9849@besserwisser.org> Message-ID: Might be ill-advised since AWS uses it themselves for their internal networking. Just traceroute to any API endpoint from an EC2/VPC resource or instance. :) On Mon, Feb 23, 2015 at 2:43 PM, Måns Nilsson wrote: > Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC > deployment Date: Mon, Feb 23, 2015 at 10:02:44AM -0500 Quoting Eric Germann > (ekgermann at cctec.com): > > Currently engaged on a project where they’re building out a VPC > infrastructure for hosted applications. > > > > > Thoughts and thanks in advance. > > using the wasted /10 for this is pretty much equal to using RFC1918 space. > > IPv6 was invented to do this right. > > -- > Måns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > It's NO USE ... I've gone to "CLUB MED"!! > From fred at web2objects.com Tue Feb 24 02:19:06 2015 From: fred at web2objects.com (Fred) Date: Tue, 24 Feb 2015 03:19:06 +0100 Subject: AOL Postmaster In-Reply-To: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> Message-ID: <54EBDF9A.8060402@web2objects.com> Having exactly the same issue. Also never received any response from AOL. Quite annoying. John Zettlemoyer: > No, started using an IP address that hasn’t been used since we got the range from Arin, and got this - 554- (RTR:BL) > Tried to contact AOL through normal channels, and no response in over a week. Feedback loop has been in place for years, and we check it every day (its clean). > > John Zettlemoyer > > > From: Bill Patterson [mailto:billpatterson84 at gmail.com] > Sent: Monday, February 23, 2015 3:46 PM > To: John Zettlemoyer > Cc: nanog at nanog.org > Subject: Re: AOL Postmaster > > Did you suddenly start getting "AOL will not accept delivery of this message" bounce backs? > On Feb 23, 2015 3:30 PM, "John Zettlemoyer" wrote: > Could someone from AOL who deals with the email systems please contact me off-list. > Thank you. > > John Zettlemoyer > WCiT LLC > 856.310.1375 x221 > john at wcit.net > From mysidia at gmail.com Tue Feb 24 03:33:41 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 23 Feb 2015 21:33:41 -0600 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: On Mon, Feb 23, 2015 at 9:02 AM, Eric Germann wrote: > In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in the VPC?” Read RFC6598. If you can assure the conditions are met that are listed in.... 4. Use of Shared CGN Space.. Then usage of the 100.64/10 shared space may be applicable, under other conditions it may be risky; the proper usage of IP addresses is in accordance with the standards or by the registrant under the right assignment agreements. If you are just needing space to squat on regardless of the standardized usage, then you might do anything you want --- you may as well use 25/8 or 11.0.0.0/8 internally, after taking steps to ensure you will not be leaking Reverse DNS queries, routes, or anything like that, this space is larger than a /10 and would provide more expansion flexibility. > Then, the customer would be allocated a /28 or larger (depending on needs) to NAT on their side and NAT it once. After that, no more NAT for the VPC and it boils down to firewall rules. Their device needs to NAT outbound before it fires it down the tunnel which pfSense and ASA’s appear to be able to do. > -- -JH From ekgermann at cctec.com Tue Feb 24 04:28:04 2015 From: ekgermann at cctec.com (Eric Germann) Date: Mon, 23 Feb 2015 23:28:04 -0500 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: <20150223204312.GG9849@besserwisser.org> Message-ID: Mulling over the implications of this. [root at ip-100-64-0-55 ~]# traceroute s3.amazonaws.com traceroute to s3.amazonaws.com (54.231.0.64), 30 hops max, 60 byte packets 1 ec2-79-125-0-202.eu-west-1.compute.amazonaws.com (79.125.0.202) 1.068 ms 0.824 ms 0.787 ms 2 178.236.1.18 (178.236.1.18) 1.193 ms 1.164 ms 0.869 ms 3 * * * 4 54.239.41.133 (54.239.41.133) 76.046 ms 76.029 ms 75.986 ms 5 54.239.41.166 (54.239.41.166) 76.314 ms 76.281 ms 76.244 ms 6 72.21.220.77 (72.21.220.77) 76.143 ms 76.054 ms 76.095 ms 7 205.251.245.224 (205.251.245.224) 76.346 ms 72.21.222.149 (72.21.222.149) 76.261 ms 205.251.245.230 (205.251.245.230) 76.360 ms 8 * * * ... 30 * * * but, [root at ip-100-64-0-55 ~]# wget https://s3.amazonaws.com --2015-02-24 04:20:18-- https://s3.amazonaws.com/ Resolving s3.amazonaws.com... 54.231.12.48 Connecting to s3.amazonaws.com|54.231.12.48|:443... connected. HTTP request sent, awaiting response... 307 Temporary Redirect Location: http://aws.amazon.com/s3/ [following] --2015-02-24 04:20:18-- http://aws.amazon.com/s3/ Resolving aws.amazon.com... 54.240.250.195 Connecting to aws.amazon.com|54.240.250.195|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: “index.html.1” [ <=> ] 179,606 158K/s in 1.1s 2015-02-24 04:20:20 (158 KB/s) - “index.html.1” saved [179606] ICMP would break from the intermediates, but ICMP from the API endpoint should still work. Will have to chew on this a bit overnight. EKG > On Feb 23, 2015, at 9:03 PM, Blair Trosper wrote: > > Might be ill-advised since AWS uses it themselves for their internal networking. Just traceroute to any API endpoint from an EC2/VPC resource or instance. :) > > On Mon, Feb 23, 2015 at 2:43 PM, Måns Nilsson > wrote: > Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Date: Mon, Feb 23, 2015 at 10:02:44AM -0500 Quoting Eric Germann (ekgermann at cctec.com ): > > Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. > > > > > Thoughts and thanks in advance. > > using the wasted /10 for this is pretty much equal to using RFC1918 space. > > IPv6 was invented to do this right. > > -- > Måns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > It's NO USE ... I've gone to "CLUB MED"!! > From randy at psg.com Tue Feb 24 04:48:31 2015 From: randy at psg.com (Randy Bush) Date: Tue, 24 Feb 2015 13:48:31 +0900 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: > Then usage of the 100.64/10 shared space may be applicable, under > other conditions it may be risky about as risky as the rest of private address space. randy From david at mailplus.nl Tue Feb 24 08:22:51 2015 From: david at mailplus.nl (David Hofstee) Date: Tue, 24 Feb 2015 09:22:51 +0100 Subject: AOL Postmaster In-Reply-To: <54EBDF9A.8060402@web2objects.com> References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> <54EBDF9A.8060402@web2objects.com> Message-ID: <78C35D6C1A82D243B830523B4193CF5F92817FEA64@SBS1.blinker.local> Same here. I want to solve things that they seem to have issues with. But when I ask what is wrong they either don't respond (in any meaningful manner) or say that they 'solved it', without me ever knowing what 'it' was. I prefer swimming in seaweed instead of contacting Yahoo (or MS for that matter). And the seaweed here is quite gross. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces at nanog.org] Namens Fred Verzonden: Tuesday, February 24, 2015 3:19 AM Aan: nanog at nanog.org Onderwerp: Re: AOL Postmaster Having exactly the same issue. Also never received any response from AOL. Quite annoying. John Zettlemoyer: > No, started using an IP address that hasn’t been used since we got the > range from Arin, and got this - 554- (RTR:BL) Tried to contact AOL through normal channels, and no response in over a week. Feedback loop has been in place for years, and we check it every day (its clean). > > John Zettlemoyer > > > From: Bill Patterson [mailto:billpatterson84 at gmail.com] > Sent: Monday, February 23, 2015 3:46 PM > To: John Zettlemoyer > Cc: nanog at nanog.org > Subject: Re: AOL Postmaster > > Did you suddenly start getting "AOL will not accept delivery of this message" bounce backs? > On Feb 23, 2015 3:30 PM, "John Zettlemoyer" wrote: > Could someone from AOL who deals with the email systems please contact me off-list. > Thank you. > > John Zettlemoyer > WCiT LLC > 856.310.1375 x221 > john at wcit.net > From rsk at gsp.org Tue Feb 24 12:36:12 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 24 Feb 2015 07:36:12 -0500 Subject: AOL Postmaster In-Reply-To: <54EBDF9A.8060402@web2objects.com> References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> <54EBDF9A.8060402@web2objects.com> Message-ID: <20150224123612.GA29601@gsp.org> On Tue, Feb 24, 2015 at 03:19:06AM +0100, Fred wrote: > Having exactly the same issue. Also never received any response from > AOL. Quite annoying. I've been waiting since January 26th for a response from dmarc-help at teamaol.com, which is their stipulated contact point for DMARC issues. Of course I wouldn't *need* a response about that if they hadn't implemented DMARC so foolishly. It seems that the days when Carl Hutzler ran the place -- and ran it well -- are now well behind them. I didn't always agree with their decisions, but it was obvious that they were working hard and trying to make AOL a good network neighbor, so even when I disagreed I could at least acknowledge their good intentions. It seems now that AOL is determined to permit unlimited abuse directed at the entire rest of the Internet while simultaneously making life as difficult as possible for everyone who *doesn't* abuse...and is counting on their size to make them immune from the consequences of that decision. ---rsk From colinj at gt86car.org.uk Tue Feb 24 12:56:36 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 24 Feb 2015 12:56:36 +0000 Subject: AOL Postmaster In-Reply-To: <20150224123612.GA29601@gsp.org> References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> <54EBDF9A.8060402@web2objects.com> <20150224123612.GA29601@gsp.org> Message-ID: <6D8F82F1-6209-4A42-A459-E9219A611786@gt86car.org.uk> block aol like china blocks with no engagement of comms as justification colin Sent from my iPhone > On 24 Feb 2015, at 12:36, Rich Kulawiec wrote: > >> On Tue, Feb 24, 2015 at 03:19:06AM +0100, Fred wrote: >> Having exactly the same issue. Also never received any response from >> AOL. Quite annoying. > > I've been waiting since January 26th for a response from dmarc-help at teamaol.com, > which is their stipulated contact point for DMARC issues. > > Of course I wouldn't *need* a response about that if they hadn't implemented > DMARC so foolishly. > > It seems that the days when Carl Hutzler ran the place -- and ran it well -- > are now well behind them. I didn't always agree with their decisions, > but it was obvious that they were working hard and trying to make AOL a > good network neighbor, so even when I disagreed I could at least acknowledge > their good intentions. It seems now that AOL is determined to permit > unlimited abuse directed at the entire rest of the Internet while > simultaneously making life as difficult as possible for everyone who > *doesn't* abuse...and is counting on their size to make them immune from > the consequences of that decision. > > ---rsk From ops.lists at gmail.com Tue Feb 24 13:03:08 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 24 Feb 2015 18:33:08 +0530 Subject: AOL Postmaster In-Reply-To: <6D8F82F1-6209-4A42-A459-E9219A611786@gt86car.org.uk> References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> <54EBDF9A.8060402@web2objects.com> <20150224123612.GA29601@gsp.org> <6D8F82F1-6209-4A42-A459-E9219A611786@gt86car.org.uk> Message-ID: And how many users do you have, again? On Feb 24, 2015 6:29 PM, "Colin Johnston" wrote: > block aol like china blocks with no engagement of comms as justification > > colin > > Sent from my iPhone > > > On 24 Feb 2015, at 12:36, Rich Kulawiec wrote: > > > >> On Tue, Feb 24, 2015 at 03:19:06AM +0100, Fred wrote: > >> Having exactly the same issue. Also never received any response from > >> AOL. Quite annoying. > > > > I've been waiting since January 26th for a response from > dmarc-help at teamaol.com, > > which is their stipulated contact point for DMARC issues. > > > > Of course I wouldn't *need* a response about that if they hadn't > implemented > > DMARC so foolishly. > > > > It seems that the days when Carl Hutzler ran the place -- and ran it > well -- > > are now well behind them. I didn't always agree with their decisions, > > but it was obvious that they were working hard and trying to make AOL a > > good network neighbor, so even when I disagreed I could at least > acknowledge > > their good intentions. It seems now that AOL is determined to permit > > unlimited abuse directed at the entire rest of the Internet while > > simultaneously making life as difficult as possible for everyone who > > *doesn't* abuse...and is counting on their size to make them immune from > > the consequences of that decision. > > > > ---rsk > From rsk at gsp.org Tue Feb 24 13:45:15 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 24 Feb 2015 08:45:15 -0500 Subject: AOL Postmaster In-Reply-To: References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> <54EBDF9A.8060402@web2objects.com> <20150224123612.GA29601@gsp.org> <6D8F82F1-6209-4A42-A459-E9219A611786@gt86car.org.uk> Message-ID: <20150224134515.GA22891@gsp.org> On Tue, Feb 24, 2015 at 06:33:08PM +0530, Suresh Ramasubramanian wrote: > And how many users do you have, again? So professionalism, competence, diligence, etc. are reserved for only the operations considered large enough? Good to know. ---rsk From Valdis.Kletnieks at vt.edu Tue Feb 24 14:21:49 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 24 Feb 2015 09:21:49 -0500 Subject: AOL Postmaster In-Reply-To: Your message of "Tue, 24 Feb 2015 08:45:15 -0500." <20150224134515.GA22891@gsp.org> References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> <54EBDF9A.8060402@web2objects.com> <20150224123612.GA29601@gsp.org> <6D8F82F1-6209-4A42-A459-E9219A611786@gt86car.org.uk> <20150224134515.GA22891@gsp.org> Message-ID: <2678.1424787709@turing-police.cc.vt.edu> On Tue, 24 Feb 2015 08:45:15 -0500, Rich Kulawiec said: > On Tue, Feb 24, 2015 at 06:33:08PM +0530, Suresh Ramasubramanian wrote: > > And how many users do you have, again? > > So professionalism, competence, diligence, etc. are reserved for > only the operations considered large enough? Good to know. No, but being able to ignore 800 pound gorillas *is* reserved for only the operations considered small enough.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jra at baylink.com Tue Feb 24 16:22:53 2015 From: jra at baylink.com (Jay Ashworth) Date: Tue, 24 Feb 2015 11:22:53 -0500 (EST) Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) In-Reply-To: Message-ID: <29372525.2006.1424794973821.JavaMail.root@benjamin.baylink.com> I thought you were just supposed to give your Geek License number. :-) #nothingScales ----- Original Message ----- > From: "Kevin McElearney" > To: "Peter Loron" , "John Brzozowski" > Cc: nanog at nanog.org > Sent: Monday, February 23, 2015 9:16:37 AM > Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23) > You forgot to use the word “Shibboleet” when you called care. > Contacted > Peter off-list > > > - Kevin > > On 2/23/15, 1:25 AM, "Peter Loron" wrote: > > >Apologies for a bit off topic, but I’m trying to get an issue > >resolved > >and am having trouble reaching anybody who seems clue positive. > > > >From home via Comcast cable, I’m having trouble reaching some > >destinations. According to mtr, there is a particular node > >(be-11-pe02.11greatoaks.ca.ibone.comcast.net) which is suffering > > >30% > >loss. Contacting the Comcast consumer support folks is useless (what > >are > >the lights on your modem doing? Did you power cycle it?). When this > >is > >happening, I usually am told they need to send a tech to my house. > >. > > > >Is there a way to drop a note to the NOC or other folks who would > >understand the info and be able to act on it? > > > >Thanks! > > > >-Pete > >> On Jan 23, 2015, at 09:14, Brzozowski, John > >> wrote: > >> > >> Folks, > >> > >> The thread below was sent to me a few times, apologies for not > >> catching > >>it sooner. > >> > >> Janet, > >> > >> I sent you mail unicast with a request for some information. I am > >>happy to help you out. > >> > >> For the larger NANOG audience, Comcast has recently launched IPv6 > >>support for our BCI products, these are our DOCSIS based commercial > >>offerings. This means that if you gateway device is in fact in RG > >>mode > >>you will be delegated a dynamic IPv6 prefix, by default customers > >>are > >>delegated a /56 prefix along with a single IPv6 address that is > >>assigned > >>to the WAN of the gateway device. IPv6 support applies to the > >>following > >>makes and models: > >> > >> SMC D3G CCR (http://mydeviceinfo.comcast.net/device.php?devid=216) > >> Cisco BWG (http://mydeviceinfo.comcast.net/device.php?devid=347) > >> Netgear CG3000D > >> (http://mydeviceinfo.comcast.net/device.php?devid=347) > >> > >> For customers where you bring your own cable modem or have one of > >> the > >>above in bridge mode we have enabled IPv6 support for you as well. > >>However, your router behind the modem must be running software and > >>configured with IPv6 support. Specifically, your router needs to be > >>support stateful DHCPv6 for IPv6 address and prefix acquisition. We > >>have received a number of reports from customers that the Juniper > >>SRX > >>does not appear to properly support IPv6. We are working with > >>Juniper > >>and also recommend that you reach out to Juniper as well. > >> > >> Please keep checking http://www.comcast6.net for updates, we will > >> post > >>some additional information here in the next week or so. In the mean > >>time if you have questions feel free to send me mail or post them > >>here > >>on the NANOG list. > >> > >> HTH, > >> > >> John > >> ========================================= > >> John Jason Brzozowski > >> Comcast Cable > >> p) 484-962-0060 > >> w) www.comcast6.net > >> e) john_brzozowski at cable.comcast.com > >> ========================================= > >> > >> > >> > >> -----Original Message----- > >> From: "nanog-request at nanog.org" > >>> > >> Reply-To: NANOG > > >> Date: Friday, January 23, 2015 at 07:00 > >> To: NANOG > > >> Subject: NANOG Digest, Vol 84, Issue 23 > >> > >> Date: Thu, 22 Jan 2015 22:42:17 +0000 > >> From: Janet Sullivan > >> > > >> To: "'nanog at nanog.org'" > >>> > >> Subject: Comcast Support > >> Message-ID: > >> > >> >>utlook.com >>4.namprd07.prod.outlook.com>> > >> Content-Type: text/plain; charset="us-ascii" > >> > >> I hate to use NANOG for this, but support has now ended a chat with > >> me > >>twice without fixing anything, they just kicked me off. > >> > >> I'm not getting an IPv6 address on the Comcast provided cable > >>modem/router. I'm not getting a PD. My machines thus have no IPv6. > >>I've hard reset my router 4 times while working with Comcast, and > >>I've > >>been told to do things like switch to a static IPv4 address, which > >>shows > >>a level of clue that is scary. And before that they were convinced > >>it > >>was a wireless problem even though I have a wired connection, and > >>told > >>them that multiple times. I've wasted two hours with Comcast today, > >>and > >>even when I asked for escalation I got nothing. Just hung up on. > >>It's > >>honestly the worst customer support I've ever received. I don't > >>think I > >>ever got them to understand the difference between IPv4 and IPv6. > > > > -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From bkain1 at ford.com Tue Feb 24 16:27:49 2015 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Tue, 24 Feb 2015 16:27:49 +0000 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) In-Reply-To: <29372525.2006.1424794973821.JavaMail.root@benjamin.baylink.com> References: <29372525.2006.1424794973821.JavaMail.root@benjamin.baylink.com> Message-ID: <7DB845D64966DC44A1CC592780539B4B012451FA@nafmbx47.exchange.ford.com> Ah, Comcast support. Those people who keep calling my Ford Motor Company phone, to threaten to shut off service to my home, which I don't have (I have uverse). They keep saying they will take my Ford number off the account (which of course, I don't know the account number because I don't have an account) and then they call again, with the same threat. Real winners. And yes, I've been saving the chats with support. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Ashworth Sent: Tuesday, February 24, 2015 11:23 AM To: NANOG Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23) I thought you were just supposed to give your Geek License number. :-) #nothingScales ----- Original Message ----- > From: "Kevin McElearney" > To: "Peter Loron" , "John Brzozowski" > Cc: nanog at nanog.org > Sent: Monday, February 23, 2015 9:16:37 AM > Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23) > You forgot to use the word “Shibboleet” when you called care. > Contacted > Peter off-list > > > - Kevin > > On 2/23/15, 1:25 AM, "Peter Loron" wrote: > > >Apologies for a bit off topic, but I’m trying to get an issue > >resolved > >and am having trouble reaching anybody who seems clue positive. > > > >From home via Comcast cable, I’m having trouble reaching some > >destinations. According to mtr, there is a particular node > >(be-11-pe02.11greatoaks.ca.ibone.comcast.net) which is suffering > > >30% > >loss. Contacting the Comcast consumer support folks is useless (what > >are > >the lights on your modem doing? Did you power cycle it?). When this > >is > >happening, I usually am told they need to send a tech to my house. > >. > > > >Is there a way to drop a note to the NOC or other folks who would > >understand the info and be able to act on it? > > > >Thanks! > > > >-Pete > >> On Jan 23, 2015, at 09:14, Brzozowski, John > >> wrote: > >> > >> Folks, > >> > >> The thread below was sent to me a few times, apologies for not > >> catching > >>it sooner. > >> > >> Janet, > >> > >> I sent you mail unicast with a request for some information. I am > >>happy to help you out. > >> > >> For the larger NANOG audience, Comcast has recently launched IPv6 > >>support for our BCI products, these are our DOCSIS based commercial > >>offerings. This means that if you gateway device is in fact in RG > >>mode > >>you will be delegated a dynamic IPv6 prefix, by default customers > >>are > >>delegated a /56 prefix along with a single IPv6 address that is > >>assigned > >>to the WAN of the gateway device. IPv6 support applies to the > >>following > >>makes and models: > >> > >> SMC D3G CCR (http://mydeviceinfo.comcast.net/device.php?devid=216) > >> Cisco BWG (http://mydeviceinfo.comcast.net/device.php?devid=347) > >> Netgear CG3000D > >> (http://mydeviceinfo.comcast.net/device.php?devid=347) > >> > >> For customers where you bring your own cable modem or have one of > >> the > >>above in bridge mode we have enabled IPv6 support for you as well. > >>However, your router behind the modem must be running software and > >>configured with IPv6 support. Specifically, your router needs to be > >>support stateful DHCPv6 for IPv6 address and prefix acquisition. We > >>have received a number of reports from customers that the Juniper > >>SRX > >>does not appear to properly support IPv6. We are working with > >>Juniper > >>and also recommend that you reach out to Juniper as well. > >> > >> Please keep checking http://www.comcast6.net for updates, we will > >> post > >>some additional information here in the next week or so. In the mean > >>time if you have questions feel free to send me mail or post them > >>here > >>on the NANOG list. > >> > >> HTH, > >> > >> John > >> ========================================= > >> John Jason Brzozowski > >> Comcast Cable > >> p) 484-962-0060 > >> w) www.comcast6.net > >> e) john_brzozowski at cable.comcast.com > >> ========================================= > >> > >> > >> > >> -----Original Message----- > >> From: "nanog-request at nanog.org" > >>> > >> Reply-To: NANOG > > >> Date: Friday, January 23, 2015 at 07:00 > >> To: NANOG > > >> Subject: NANOG Digest, Vol 84, Issue 23 > >> > >> Date: Thu, 22 Jan 2015 22:42:17 +0000 > >> From: Janet Sullivan > >> > > >> To: "'nanog at nanog.org'" > >>> > >> Subject: Comcast Support > >> Message-ID: > >> > >> >>utlook.com >>4.namprd07.prod.outlook.com>> > >> Content-Type: text/plain; charset="us-ascii" > >> > >> I hate to use NANOG for this, but support has now ended a chat with > >> me > >>twice without fixing anything, they just kicked me off. > >> > >> I'm not getting an IPv6 address on the Comcast provided cable > >>modem/router. I'm not getting a PD. My machines thus have no IPv6. > >>I've hard reset my router 4 times while working with Comcast, and > >>I've > >>been told to do things like switch to a static IPv4 address, which > >>shows > >>a level of clue that is scary. And before that they were convinced > >>it > >>was a wireless problem even though I have a wired connection, and > >>told > >>them that multiple times. I've wasted two hours with Comcast today, > >>and > >>even when I asked for escalation I got nothing. Just hung up on. > >>It's > >>honestly the worst customer support I've ever received. I don't > >>think I > >>ever got them to understand the difference between IPv4 and IPv6. > > > > -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From rafael at gav.ufsc.br Tue Feb 24 16:33:59 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Tue, 24 Feb 2015 10:33:59 -0600 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) In-Reply-To: <7DB845D64966DC44A1CC592780539B4B012451FA@nafmbx47.exchange.ford.com> References: <29372525.2006.1424794973821.JavaMail.root@benjamin.baylink.com> <7DB845D64966DC44A1CC592780539B4B012451FA@nafmbx47.exchange.ford.com> Message-ID: ​ On Tue, Feb 24, 2015 at 10:27 AM, Kain, Rebecca (.) wrote: > Ah, Comcast support. Those people who keep calling my Ford Motor Company > phone, to threaten to shut off service to my home, which I don't have (I > have uverse). They keep saying they will take my Ford number off the > account (which of course, I don't know the account number because I don't > have an account) and then they call again, with the same threat. > > Real winners. And yes, I've been saving the chats with support. > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jay Ashworth > Sent: Tuesday, February 24, 2015 11:23 AM > To: NANOG > Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23) > > I thought you were just supposed to give your Geek License number. :-) > > #nothingScales > > ----- Original Message ----- > > From: "Kevin McElearney" > > To: "Peter Loron" , "John Brzozowski" < > John_Brzozowski at Cable.Comcast.com> > > Cc: nanog at nanog.org > > Sent: Monday, February 23, 2015 9:16:37 AM > > Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23) > > You forgot to use the word “Shibboleet” when you called care. > > Contacted > > Peter off-list > > > > > > - Kevin > > > > On 2/23/15, 1:25 AM, "Peter Loron" wrote: > > > > >Apologies for a bit off topic, but I’m trying to get an issue > > >resolved > > >and am having trouble reaching anybody who seems clue positive. > > > > > >From home via Comcast cable, I’m having trouble reaching some > > >destinations. According to mtr, there is a particular node > > >(be-11-pe02.11greatoaks.ca.ibone.comcast.net) which is suffering > > > >30% > > >loss. Contacting the Comcast consumer support folks is useless (what > > >are > > >the lights on your modem doing? Did you power cycle it?). When this > > >is > > >happening, I usually am told they need to send a tech to my house. > > >. > > > > > >Is there a way to drop a note to the NOC or other folks who would > > >understand the info and be able to act on it? > > > > > >Thanks! > > > > > >-Pete > > >> On Jan 23, 2015, at 09:14, Brzozowski, John > > >> wrote: > > >> > > >> Folks, > > >> > > >> The thread below was sent to me a few times, apologies for not > > >> catching > > >>it sooner. > > >> > > >> Janet, > > >> > > >> I sent you mail unicast with a request for some information. I am > > >>happy to help you out. > > >> > > >> For the larger NANOG audience, Comcast has recently launched IPv6 > > >>support for our BCI products, these are our DOCSIS based commercial > > >>offerings. This means that if you gateway device is in fact in RG > > >>mode > > >>you will be delegated a dynamic IPv6 prefix, by default customers > > >>are > > >>delegated a /56 prefix along with a single IPv6 address that is > > >>assigned > > >>to the WAN of the gateway device. IPv6 support applies to the > > >>following > > >>makes and models: > > >> > > >> SMC D3G CCR (http://mydeviceinfo.comcast.net/device.php?devid=216) > > >> Cisco BWG (http://mydeviceinfo.comcast.net/device.php?devid=347) > > >> Netgear CG3000D > > >> (http://mydeviceinfo.comcast.net/device.php?devid=347) > > >> > > >> For customers where you bring your own cable modem or have one of > > >> the > > >>above in bridge mode we have enabled IPv6 support for you as well. > > >>However, your router behind the modem must be running software and > > >>configured with IPv6 support. Specifically, your router needs to be > > >>support stateful DHCPv6 for IPv6 address and prefix acquisition. We > > >>have received a number of reports from customers that the Juniper > > >>SRX > > >>does not appear to properly support IPv6. We are working with > > >>Juniper > > >>and also recommend that you reach out to Juniper as well. > > >> > > >> Please keep checking http://www.comcast6.net for updates, we will > > >> post > > >>some additional information here in the next week or so. In the mean > > >>time if you have questions feel free to send me mail or post them > > >>here > > >>on the NANOG list. > > >> > > >> HTH, > > >> > > >> John > > >> ========================================= > > >> John Jason Brzozowski > > >> Comcast Cable > > >> p) 484-962-0060 > > >> w) www.comcast6.net > > >> e) john_brzozowski at cable.comcast.com > > >> ========================================= > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: "nanog-request at nanog.org" > > >>> > > >> Reply-To: NANOG > > > >> Date: Friday, January 23, 2015 at 07:00 > > >> To: NANOG > > > >> Subject: NANOG Digest, Vol 84, Issue 23 > > >> > > >> Date: Thu, 22 Jan 2015 22:42:17 +0000 > > >> From: Janet Sullivan > > >> > > > >> To: "'nanog at nanog.org'" > > >>> > > >> Subject: Comcast Support > > >> Message-ID: > > >> > > > >> > >>utlook.com CY1PR0701MB1164F3448B35404BBAE671A8DC490 at CY1PR0701MB116 > > >>4.namprd07.prod.outlook.com>> > > >> Content-Type: text/plain; charset="us-ascii" > > >> > > >> I hate to use NANOG for this, but support has now ended a chat with > > >> me > > >>twice without fixing anything, they just kicked me off. > > >> > > >> I'm not getting an IPv6 address on the Comcast provided cable > > >>modem/router. I'm not getting a PD. My machines thus have no IPv6. > > >>I've hard reset my router 4 times while working with Comcast, and > > >>I've > > >>been told to do things like switch to a static IPv4 address, which > > >>shows > > >>a level of clue that is scary. And before that they were convinced > > >>it > > >>was a wireless problem even though I have a wired connection, and > > >>told > > >>them that multiple times. I've wasted two hours with Comcast today, > > >>and > > >>even when I asked for escalation I got nothing. Just hung up on. > > >>It's > > >>honestly the worst customer support I've ever received. I don't > > >>think I > > >>ever got them to understand the difference between IPv4 and IPv6. > > > > > > > > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land > Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > 1274 > From owen at delong.com Tue Feb 24 17:27:59 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Feb 2015 09:27:59 -0800 Subject: v6 deagg In-Reply-To: References: <1589DCC3-6396-4FF0-8CF9-C9EB386AA057@isi.edu> Message-ID: <0E7AFD3D-28E2-4D72-9661-5DFB099ACB28@delong.com> > On Feb 19, 2015, at 21:25 , Christopher Morrow wrote: > > On Thu, Feb 19, 2015 at 10:16 PM, manning bill wrote: >> and then there are the loons who will locally push /64 or longer, some of which may leak. >> > > 2001:2b8:46:bbbb::/64 > ... a fairly extensive list actually.... > >> show route table inet6.0 | grep ^2 | except /4[876543210] | except /3 | except /2 | count > Count: 297 lines > > Some are likely my local network's interfaces (so skip ~50 or so? to > be generous) and some might be my provider's customers? (but they > shouldn't send me shorter than a /48, right?) > > -chris > (note on another observation point I don't see this sort of thing so > perhaps it's just one upstream in a collection... I'll ask them > seperately) Your regular expression will not only count /49 and longer, it will also count /19 and shorter. In my routing table, there are at least some examples of such routes. Owen From jhellenthal at dataix.net Tue Feb 24 17:36:45 2015 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Tue, 24 Feb 2015 11:36:45 -0600 Subject: ControlNow / MailEssentials Admin Requested Message-ID: <89E71AF3-5B28-41EF-BA66-444B1DA2B3E9@dataix.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Could a clueful ControlNow smtp admin contact me off-ist. RE: na0102.smtpout.com - -- Jason Hellenthal JJH48-ARIN -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJU7LauAAoJEDLu+wRc4KcIMecIAI35ZHbTDyLWcSLtYkuM8oxP zvsDZhHtD5r3j0iUkhD0jDpEWS2F1wTkQwZ6fZDWfaLcrqM90y2F5jQMYkmQ1FZa IlyAOlOqqOGvzLAuhNlXEac92MoIGMK6bcgxl1LBunO2k7CyGa1j0kFn7e0df5jp vSD3J5Rt97AvnqWUjLxJ37wy2tDlVTZbYASvaW+bDRen2oeU0rZu8blHoWbMTILo V/9JOblSgMpp3NvyjfeZI7G5u/qswescr6zikErHfIMx0t3sO0NYnsmmgV9yXuJw +uswFRclM3MGs6ExKDkg3Vsu8rMv/6S/0BjF1v4hmIDOo6T/d2W0IybpTjnOtlo= =ikhw -----END PGP SIGNATURE----- From owen at delong.com Tue Feb 24 17:38:37 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Feb 2015 09:38:37 -0800 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: <54EB76E2.30901@queuefull.net> References: <54EB76E2.30901@queuefull.net> Message-ID: As one of the authors involved in what eventually became RFC6598, this isn’t entirely accurate. 100.64/10 is intended as space to be used by service providers for dealing with situations where additional shared private address space is required, but it must be distinct from the private address space in use by their customers. Stacked NAT in a CGN scenario is only the most common example of such a situation. The application described is another example, though if the application provider’s customers are with ISPs that start doing CGN and using RFC6598 for that process, some difficulties could arise which the application provider would have to be prepared to cope with. Owen > On Feb 23, 2015, at 10:52 , Benson Schliesser wrote: > > Hi, Eric - > > Bill already described the salient points. The "transition" space is meant to be used for cases where there are multiple stacked NATs, such as CGN with CPE-based NAT. In theory, if the NAT implementations support it, one could use it repeatedly by stacking NAT on top of NAT ad nauseum, but the wisdom of doing so is questionable. If one uses it like additional RFC1918 space then routing could become more difficult, specifically in the case where hosts (e.g. VPC servers) are numbered with it. This is true because, in theory, you don't need the transition space to be routed on the "internal" network which avoids having NAT devices hold conflicting routes etc. Even if the edge NAT devices don't currently see conflicting routes to 100.64/10, if that changes in the future then client hosts may find themselves unable to reach the VPC hosts at that time. > > That being said, if you understand the risks that I described above, then it may work well for a "community of interest" type of inter-network that hosts non-global resources. From your description it sounds like that might be the situation you find yourself in. To be clear, it's not unwise to do so, but it does carry risk that needs to be evaluated (and documented). > > Cheers, > -Benson > > >> William Herrin >> February 23, 2015 at 12:58 PM >> >> Hi Eric, >> >> The main risk is more or less as you summarized it. Customer has no >> firewall or originates the VPN directly from their firewall. Customer >> buys a non-hosting commodity Internet product that uses carrier NAT to >> conserve IP addresses. The customer's assigned address AND NETMASK >> combined overlap some of the hosts you're trying to publish to them. >> >> >> >> Mitigations for that risk: >> >> Can you insist that the customer originate connections from inside >> their firewall (on RFC1918 space)? >> >> Most service providers using 100.64/10 either permit customers to opt >> out (getting dynamic globally routable addresses) or offer customers >> the opportunity to purchase static global addresses for a nominal fee. >> Are you comfortable telling impacted customers that they have to do >> so? >> >> >> A secondary risk comes in to play where a customer may wish to >> interact with another service provider doing the same thing as you. >> That essentially lands you back in the same problem you're having now >> with RFC1918. >> >> >> One more question you should consider: what is the nature of your >> customer's networks? Big corps that tend to stretch through 10/8 won't >> let their users originate VPN connections in the first place. They >> also don't touch 100.64/10 except where someone is publishing a >> service like yours. Meanwhile, home and SOHO users who are at liberty >> to originate VPNs might currently hold a 100.64/10 address. But they >> just about never use the off-bit /16s in 10/8. By off-bit I mean the >> ones with 4 or 5 random 1-bits in the second octet. >> >> >> My opinion: The likelihood of collisions in 100.64/10 increases >> significantly if you use them on servers. I would confine my use to >> client machines and try to put servers providing service to multiple >> organizations on globally unique IPs. Confining 100.64/10 to client >> machines, you're unlikely to encounter a problem you can't readily >> solve. >> >> Regards, >> Bill Herrin >> >> >> Eric Germann >> February 23, 2015 at 10:02 AM >> Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. >> >> Users access apps in the VPC, not the other direction. >> >> The issue I'm trying to get around is the customers who need to connect have multiple overlapping RFC1918 space (including overlapping what was proposed for the VPC networks). Finding a hole that is big enough and not in use by someone else is nearly impossible AND the customers could go through mergers which make them renumber even more in to overlapping 1918 space. >> >> Initially, I was looking at doing something like (example IP’s): >> >> >> Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC <——> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) >> >> Classic overlapping subnets on both ends with allocations out of 100.64.0.0/10 to NAT in both directions. Each sees the other end in 100.64 space, but the mappings can get tricky and hard to keep track of (especially if you’re not a network engineer). >> >> >> In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in the VPC?” >> >> Then, the customer would be allocated a /28 or larger (depending on needs) to NAT on their side and NAT it once. After that, no more NAT for the VPC and it boils down to firewall rules. Their device needs to NAT outbound before it fires it down the tunnel which pfSense and ASA’s appear to be able to do. >> >> I prototyped this up over the weekend with multiple VPC’s in multiple regions and it “appears” to work fine. >> >> From the operator community, what are the downsides? >> >> Customers are businesses on dedicated business services vs. consumer cable modems (although there are a few on business class cable). Others are on MPLS and I’m hashing that out. >> >> The only one I can see is if the customer has a service provider with their external interface in 100.64 space. However, this approach would have a more specific in that space so it should fire it down the tunnel for their allocated customer block (/28) vs. their external side. >> >> Thoughts and thanks in advance. >> >> Eric >> >> From owen at delong.com Tue Feb 24 17:35:13 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Feb 2015 09:35:13 -0800 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: Amazon is not the only public cloud. There are several public clouds that can support IPv6 directly. I have done some work for and believe these guys do a good job: Host Virtual (vr.org ) In no particular order and I have no relationship with or loyalty or benefit associated with any of them. I neither endorse, nor decry any of the following: Linode SoftLayer RackSpace There are others that I am not recalling off the top of my head. Owen > On Feb 23, 2015, at 07:52 , Ca By wrote: > > On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann wrote: > >> Currently engaged on a project where they’re building out a VPC >> infrastructure for hosted applications. >> >> Users access apps in the VPC, not the other direction. >> >> The issue I'm trying to get around is the customers who need to connect >> have multiple overlapping RFC1918 space (including overlapping what was >> proposed for the VPC networks). Finding a hole that is big enough and not >> in use by someone else is nearly impossible AND the customers could go >> through mergers which make them renumber even more in to overlapping 1918 >> space. >> >> Initially, I was looking at doing something like (example IP’s): >> >> >> Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC <——> >> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) >> >> Classic overlapping subnets on both ends with allocations out of >> 100.64.0.0/10 to NAT in both directions. Each sees the other end in >> 100.64 space, but the mappings can get tricky and hard to keep track of >> (especially if you’re not a network engineer). >> >> >> In spitballing, the boat hasn’t sailed too far to say “Why not use >> 100.64/10 in the VPC?” >> >> Then, the customer would be allocated a /28 or larger (depending on needs) >> to NAT on their side and NAT it once. After that, no more NAT for the VPC >> and it boils down to firewall rules. Their device needs to NAT outbound >> before it fires it down the tunnel which pfSense and ASA’s appear to be >> able to do. >> >> I prototyped this up over the weekend with multiple VPC’s in multiple >> regions and it “appears” to work fine. >> >> From the operator community, what are the downsides? >> >> Customers are businesses on dedicated business services vs. consumer cable >> modems (although there are a few on business class cable). Others are on >> MPLS and I’m hashing that out. >> >> The only one I can see is if the customer has a service provider with >> their external interface in 100.64 space. However, this approach would >> have a more specific in that space so it should fire it down the tunnel for >> their allocated customer block (/28) vs. their external side. >> >> Thoughts and thanks in advance. >> >> Eric >> > > Wouldn't it be nice if Amazon supported IPv6 in VPC? > > I have disqualified several projects from using the "public cloud" and put > them in the on-premise "private cloud" because Amazon is missing this key > scaling feature -- ipv6. It is odd that Amazon, a company with scale > deeply in its DNA, fails so hard on IPv6. I guess they have a lot of > brittle technical debt they can't upgrade. > > I suggest you go with private cloud if possible. > > Or, you can double NAT non-unique IPv4 space. > > Regarding 100.64.0.0/10, despite what the RFCs may say, this space is just > an augment of RFC1918 and i have already deployed it as such. > > CB From cook at cookreport.com Tue Feb 24 17:53:02 2015 From: cook at cookreport.com (Gordon Cook) Date: Tue, 24 Feb 2015 12:53:02 -0500 Subject: routing issue? could someone from verizon FiOS please take a look? Message-ID: Verizon Fios cannot connect me to lavra.spb.ru This is the Russian site of the second most important monastery in Russia. It is reachable from Boston avra.spb.ru (91.218.229.131), 64 hops max, 52 byte packets 1 192.168.100.1 (192.168.100.1) 2.293 ms 0.815 ms 0.764 ms 2 100.64.0.129 (100.64.0.129) 1.108 ms 3.013 ms 1.068 ms 3 10.16.28.1 (10.16.28.1) 1.411 ms 1.277 ms 1.068 ms 4 10.16.13.1 (10.16.13.1) 4.796 ms 2.301 ms 5.207 ms 5 69.46.226.129.lightower.net (69.46.226.129) 4.380 ms 3.138 ms 4.630 ms 6 ae2.bstpmallj42.lightower.net (64.72.64.113) 3.768 ms 6.008 ms 3.888 ms 7 xe-4-0-2.bar2.boston1.level3.net (4.53.56.153) 6.030 ms 4.890 ms 7.058 ms 8 ae-231-3607.edge4.london1.level3.net (4.69.166.25) 91.525 ms 81.571 ms ae-232-3608.edge4.london1.level3.net (4.69.166.29) 81.327 ms 9 ae-231-3607.edge4.london1.level3.net (4.69.166.25) 78.121 ms ae-232-3608.edge4.london1.level3.net (4.69.166.29) 79.734 ms 78.890 ms 10 195.50.122.186 (195.50.122.186) 173.491 ms 133.054 ms 198.495 ms 11 * * * 12 oversun-gw.transtelecom.net (217.150.54.25) 210.399 ms 138.519 ms 139.291 ms 13 mr-o-rtc1-rsw-2.oversun.ru (94.198.48.154) 131.070 ms 131.007 ms 129.553 ms 14 mr-o-rtc5-rsw-2.oversun.ru (94.198.48.110) 140.012 ms 208.023 ms 145.352 ms 15 vip-h5.ihc-ru.net (91.218.229.131) 131.485 ms 133.319 ms 129.822 ms and from comcast and other locations apparently it has v6 routing info as well ..someone much more knowledgable than i suggested that this can be a source of reachability problems but here is what happens on my machine ordons-mac-pro:~ gordoncook$ traceroute lavra.spb.ru traceroute to lavra.spb.ru (92.242.140.21), 64 hops max, 52 byte packets 1 wireless_broadband_router (192.168.1.1) 0.654 ms 0.351 ms 0.295 ms 2 l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1) 4.607 ms 4.326 ms 7.869 ms 3 g0-1-0-0.cmdnnj-lcr-22.verizon-gni.net (130.81.223.100) 12.172 ms 9.502 ms 7.242 ms 4 xe-9-1-6-0.ny5030-bb-rtr2.verizon-gni.net (130.81.199.226) 15.080 ms xe-9-1-2-0.ny5030-bb-rtr2.verizon-gni.net (130.81.209.144) 8.986 ms xe-4-1-8-0.ny5030-bb-rtr2.verizon-gni.net (130.81.209.84) 22.085 ms 5 * * * 6 0.ae1.br2.nyc4.alter.net (140.222.229.91) 79.467 ms 77.046 ms 74.729 ms 7 204.255.168.114 (204.255.168.114) 85.591 ms 86.899 ms 204.255.168.110 (204.255.168.110) 87.011 ms 8 be2061.ccr42.jfk02.atlas.cogentco.com (154.54.3.69) 96.323 ms be2060.ccr41.jfk02.atlas.cogentco.com (154.54.31.9) 84.779 ms be2061.ccr42.jfk02.atlas.cogentco.com (154.54.3.69) 85.063 ms 9 be2482.ccr21.cle04.atlas.cogentco.com (154.54.27.157) 31.562 ms 31.990 ms be2483.ccr22.cle04.atlas.cogentco.com (154.54.29.201) 27.548 ms 10 be2351.ccr41.ord01.atlas.cogentco.com (154.54.44.85) 37.087 ms be2185.ccr42.ord01.atlas.cogentco.com (154.54.43.177) 42.273 ms be2351.ccr41.ord01.atlas.cogentco.com (154.54.44.85) 39.590 ms 11 be2157.ccr22.mci01.atlas.cogentco.com (154.54.6.117) 49.793 ms be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85) 50.583 ms be2157.ccr22.mci01.atlas.cogentco.com (154.54.6.117) 49.492 ms 12 be2133.ccr22.sfo01.atlas.cogentco.com (154.54.30.65) 77.446 ms be2132.ccr21.sfo01.atlas.cogentco.com (154.54.30.53) 77.060 ms be2133.ccr22.sfo01.atlas.cogentco.com (154.54.30.65) 77.001 ms 13 be2164.ccr21.sjc01.atlas.cogentco.com (154.54.28.34) 74.999 ms 74.569 ms be2165.ccr22.sjc01.atlas.cogentco.com (154.54.28.66) 74.852 ms 14 be2063.rcr21.b001848-1.sjc01.atlas.cogentco.com (154.54.1.162) 74.377 ms be2095.rcr21.b001848-1.sjc01.atlas.cogentco.com (154.54.3.138) 77.126 ms 89.476 ms 15 c1.sj.mpt.fiberinternetcenter.net (66.201.58.2) 82.483 ms 86.964 ms 80.094 ms 16 sanjose2.barefruit.co.uk (66.201.32.134) 125.112 ms 106.932 ms 124.778 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * 31 * * * 32 * * * 33 * * * 34 * * * 35 * * * 36 * * * 37 * * * 38 * * * 39 * * * 40 * unallocated.barefruit.co.uk (92.242.140.21) 111.898 ms * gordons-mac-pro:~ gordoncook$ PS: my FIOS contract is up in april. Any suggestion of how to avoid a $30 per month price increase would be greatly appreciated OFF list of course many thanks Gordon Cook COOK Report on Internet Protocol -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From blair.trosper at gmail.com Tue Feb 24 18:08:52 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 24 Feb 2015 12:08:52 -0600 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: I have an unimpeachable source at AWS that assures me they're working hard to deploy IPv6. As it was explained to me, since AWS was sort of first to the table -- well before IPv6 "popped", they had designed everything on the v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, which they're phasing out. But I'm assured they're rushing IPv6 deployment of CloudFront and other services as fast as they can. I'm assured of this. But you also have to appreciate the hassle of retrofitting a cloud platform of that scale, so I do not envy the task that AWS is undertaking. On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong wrote: > Amazon is not the only public cloud. > > There are several public clouds that can support IPv6 directly. > > I have done some work for and believe these guys do a good job: > > Host Virtual (vr.org ) > > In no particular order and I have no relationship with or loyalty or > benefit associated with any of them. I neither endorse, nor decry any of > the following: > > Linode > SoftLayer > RackSpace > > There are others that I am not recalling off the top of my head. > > Owen > > > On Feb 23, 2015, at 07:52 , Ca By wrote: > > > > On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann > wrote: > > > >> Currently engaged on a project where they’re building out a VPC > >> infrastructure for hosted applications. > >> > >> Users access apps in the VPC, not the other direction. > >> > >> The issue I'm trying to get around is the customers who need to connect > >> have multiple overlapping RFC1918 space (including overlapping what was > >> proposed for the VPC networks). Finding a hole that is big enough and > not > >> in use by someone else is nearly impossible AND the customers could go > >> through mergers which make them renumber even more in to overlapping > 1918 > >> space. > >> > >> Initially, I was looking at doing something like (example IP’s): > >> > >> > >> Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC > <——> > >> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) > >> > >> Classic overlapping subnets on both ends with allocations out of > >> 100.64.0.0/10 to NAT in both directions. Each sees the other end in > >> 100.64 space, but the mappings can get tricky and hard to keep track of > >> (especially if you’re not a network engineer). > >> > >> > >> In spitballing, the boat hasn’t sailed too far to say “Why not use > >> 100.64/10 in the VPC?” > >> > >> Then, the customer would be allocated a /28 or larger (depending on > needs) > >> to NAT on their side and NAT it once. After that, no more NAT for the > VPC > >> and it boils down to firewall rules. Their device needs to NAT outbound > >> before it fires it down the tunnel which pfSense and ASA’s appear to be > >> able to do. > >> > >> I prototyped this up over the weekend with multiple VPC’s in multiple > >> regions and it “appears” to work fine. > >> > >> From the operator community, what are the downsides? > >> > >> Customers are businesses on dedicated business services vs. consumer > cable > >> modems (although there are a few on business class cable). Others are > on > >> MPLS and I’m hashing that out. > >> > >> The only one I can see is if the customer has a service provider with > >> their external interface in 100.64 space. However, this approach would > >> have a more specific in that space so it should fire it down the tunnel > for > >> their allocated customer block (/28) vs. their external side. > >> > >> Thoughts and thanks in advance. > >> > >> Eric > >> > > > > Wouldn't it be nice if Amazon supported IPv6 in VPC? > > > > I have disqualified several projects from using the "public cloud" and > put > > them in the on-premise "private cloud" because Amazon is missing this > key > > scaling feature -- ipv6. It is odd that Amazon, a company with scale > > deeply in its DNA, fails so hard on IPv6. I guess they have a lot of > > brittle technical debt they can't upgrade. > > > > I suggest you go with private cloud if possible. > > > > Or, you can double NAT non-unique IPv4 space. > > > > Regarding 100.64.0.0/10, despite what the RFCs may say, this space is > just > > an augment of RFC1918 and i have already deployed it as such. > > > > CB > > From blair.trosper at gmail.com Tue Feb 24 18:10:14 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 24 Feb 2015 12:10:14 -0600 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: ADDENDUM: They're taking into consideration my suggestion of using IPv6 as a "universal" internal network so that the different regions could be interconnected without having to give up the region-independent use of 10.0.0.0/8, which I think would be an elegant solution. On Tue, Feb 24, 2015 at 12:08 PM, Blair Trosper wrote: > I have an unimpeachable source at AWS that assures me they're working hard > to deploy IPv6. As it was explained to me, since AWS was sort of first to > the table -- well before IPv6 "popped", they had designed everything on the > v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, which > they're phasing out. > > But I'm assured they're rushing IPv6 deployment of CloudFront and other > services as fast as they can. I'm assured of this. > > But you also have to appreciate the hassle of retrofitting a cloud > platform of that scale, so I do not envy the task that AWS is undertaking. > > On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong wrote: > >> Amazon is not the only public cloud. >> >> There are several public clouds that can support IPv6 directly. >> >> I have done some work for and believe these guys do a good job: >> >> Host Virtual (vr.org ) >> >> In no particular order and I have no relationship with or loyalty or >> benefit associated with any of them. I neither endorse, nor decry any of >> the following: >> >> Linode >> SoftLayer >> RackSpace >> >> There are others that I am not recalling off the top of my head. >> >> Owen >> >> > On Feb 23, 2015, at 07:52 , Ca By wrote: >> > >> > On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann >> wrote: >> > >> >> Currently engaged on a project where they’re building out a VPC >> >> infrastructure for hosted applications. >> >> >> >> Users access apps in the VPC, not the other direction. >> >> >> >> The issue I'm trying to get around is the customers who need to connect >> >> have multiple overlapping RFC1918 space (including overlapping what was >> >> proposed for the VPC networks). Finding a hole that is big enough and >> not >> >> in use by someone else is nearly impossible AND the customers could go >> >> through mergers which make them renumber even more in to overlapping >> 1918 >> >> space. >> >> >> >> Initially, I was looking at doing something like (example IP’s): >> >> >> >> >> >> Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC >> <——> >> >> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) >> >> >> >> Classic overlapping subnets on both ends with allocations out of >> >> 100.64.0.0/10 to NAT in both directions. Each sees the other end in >> >> 100.64 space, but the mappings can get tricky and hard to keep track of >> >> (especially if you’re not a network engineer). >> >> >> >> >> >> In spitballing, the boat hasn’t sailed too far to say “Why not use >> >> 100.64/10 in the VPC?” >> >> >> >> Then, the customer would be allocated a /28 or larger (depending on >> needs) >> >> to NAT on their side and NAT it once. After that, no more NAT for the >> VPC >> >> and it boils down to firewall rules. Their device needs to NAT >> outbound >> >> before it fires it down the tunnel which pfSense and ASA’s appear to be >> >> able to do. >> >> >> >> I prototyped this up over the weekend with multiple VPC’s in multiple >> >> regions and it “appears” to work fine. >> >> >> >> From the operator community, what are the downsides? >> >> >> >> Customers are businesses on dedicated business services vs. consumer >> cable >> >> modems (although there are a few on business class cable). Others are >> on >> >> MPLS and I’m hashing that out. >> >> >> >> The only one I can see is if the customer has a service provider with >> >> their external interface in 100.64 space. However, this approach would >> >> have a more specific in that space so it should fire it down the >> tunnel for >> >> their allocated customer block (/28) vs. their external side. >> >> >> >> Thoughts and thanks in advance. >> >> >> >> Eric >> >> >> > >> > Wouldn't it be nice if Amazon supported IPv6 in VPC? >> > >> > I have disqualified several projects from using the "public cloud" and >> put >> > them in the on-premise "private cloud" because Amazon is missing this >> key >> > scaling feature -- ipv6. It is odd that Amazon, a company with scale >> > deeply in its DNA, fails so hard on IPv6. I guess they have a lot of >> > brittle technical debt they can't upgrade. >> > >> > I suggest you go with private cloud if possible. >> > >> > Or, you can double NAT non-unique IPv4 space. >> > >> > Regarding 100.64.0.0/10, despite what the RFCs may say, this space is >> just >> > an augment of RFC1918 and i have already deployed it as such. >> > >> > CB >> >> > From ammar at fastreturn.net Tue Feb 24 18:11:00 2015 From: ammar at fastreturn.net (Ammar Zuberi) Date: Tue, 24 Feb 2015 22:11:00 +0400 Subject: routing issue? could someone from verizon FiOS please take a look? In-Reply-To: References: Message-ID: <35A2D4FA-0074-4C34-B88C-D29FAE4CCF48@fastreturn.net> Hi, I actually saw this issue a few weeks back but with a customer's website. It's actually not a routing issue, but a DNS issue. If you check the IPs that Verizon resolves for you, they'll be different from the IPs that other resolvers will resolve. It's weird, I know, but that's all the information I have for you. Hope I helped, Ammar. > On 24 Feb 2015, at 9:53 pm, Gordon Cook wrote: > > Verizon Fios cannot connect me to lavra.spb.ru > > This is the Russian site of the second most important monastery in Russia. > > It is reachable from Boston avra.spb.ru (91.218.229.131), 64 hops max, 52 byte packets > 1 192.168.100.1 (192.168.100.1) 2.293 ms 0.815 ms 0.764 ms > 2 100.64.0.129 (100.64.0.129) 1.108 ms 3.013 ms 1.068 ms > 3 10.16.28.1 (10.16.28.1) 1.411 ms 1.277 ms 1.068 ms > 4 10.16.13.1 (10.16.13.1) 4.796 ms 2.301 ms 5.207 ms > 5 69.46.226.129.lightower.net (69.46.226.129) 4.380 ms 3.138 ms 4.630 ms > 6 ae2.bstpmallj42.lightower.net (64.72.64.113) 3.768 ms 6.008 ms 3.888 ms > 7 xe-4-0-2.bar2.boston1.level3.net (4.53.56.153) 6.030 ms 4.890 ms 7.058 ms > 8 ae-231-3607.edge4.london1.level3.net (4.69.166.25) 91.525 ms 81.571 ms > ae-232-3608.edge4.london1.level3.net (4.69.166.29) 81.327 ms > 9 ae-231-3607.edge4.london1.level3.net (4.69.166.25) 78.121 ms > ae-232-3608.edge4.london1.level3.net (4.69.166.29) 79.734 ms 78.890 ms > 10 195.50.122.186 (195.50.122.186) 173.491 ms 133.054 ms 198.495 ms > 11 * * * > 12 oversun-gw.transtelecom.net (217.150.54.25) 210.399 ms 138.519 ms 139.291 ms > 13 mr-o-rtc1-rsw-2.oversun.ru (94.198.48.154) 131.070 ms 131.007 ms 129.553 ms > 14 mr-o-rtc5-rsw-2.oversun.ru (94.198.48.110) 140.012 ms 208.023 ms 145.352 ms > 15 vip-h5.ihc-ru.net (91.218.229.131) 131.485 ms 133.319 ms 129.822 ms > > and from comcast and other locations > > apparently it has v6 routing info as well ..someone much more knowledgable than i suggested that this can be a source of reachability problems > > but here is what happens on my machine > > ordons-mac-pro:~ gordoncook$ traceroute lavra.spb.ru > traceroute to lavra.spb.ru (92.242.140.21), 64 hops max, 52 byte packets > 1 wireless_broadband_router (192.168.1.1) 0.654 ms 0.351 ms 0.295 ms > 2 l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1) 4.607 ms 4.326 ms 7.869 ms > 3 g0-1-0-0.cmdnnj-lcr-22.verizon-gni.net (130.81.223.100) 12.172 ms 9.502 ms 7.242 ms > 4 xe-9-1-6-0.ny5030-bb-rtr2.verizon-gni.net (130.81.199.226) 15.080 ms > xe-9-1-2-0.ny5030-bb-rtr2.verizon-gni.net (130.81.209.144) 8.986 ms > xe-4-1-8-0.ny5030-bb-rtr2.verizon-gni.net (130.81.209.84) 22.085 ms > 5 * * * > 6 0.ae1.br2.nyc4.alter.net (140.222.229.91) 79.467 ms 77.046 ms 74.729 ms > 7 204.255.168.114 (204.255.168.114) 85.591 ms 86.899 ms > 204.255.168.110 (204.255.168.110) 87.011 ms > 8 be2061.ccr42.jfk02.atlas.cogentco.com (154.54.3.69) 96.323 ms > be2060.ccr41.jfk02.atlas.cogentco.com (154.54.31.9) 84.779 ms > be2061.ccr42.jfk02.atlas.cogentco.com (154.54.3.69) 85.063 ms > 9 be2482.ccr21.cle04.atlas.cogentco.com (154.54.27.157) 31.562 ms 31.990 ms > be2483.ccr22.cle04.atlas.cogentco.com (154.54.29.201) 27.548 ms > 10 be2351.ccr41.ord01.atlas.cogentco.com (154.54.44.85) 37.087 ms > be2185.ccr42.ord01.atlas.cogentco.com (154.54.43.177) 42.273 ms > be2351.ccr41.ord01.atlas.cogentco.com (154.54.44.85) 39.590 ms > 11 be2157.ccr22.mci01.atlas.cogentco.com (154.54.6.117) 49.793 ms > be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85) 50.583 ms > be2157.ccr22.mci01.atlas.cogentco.com (154.54.6.117) 49.492 ms > 12 be2133.ccr22.sfo01.atlas.cogentco.com (154.54.30.65) 77.446 ms > be2132.ccr21.sfo01.atlas.cogentco.com (154.54.30.53) 77.060 ms > be2133.ccr22.sfo01.atlas.cogentco.com (154.54.30.65) 77.001 ms > 13 be2164.ccr21.sjc01.atlas.cogentco.com (154.54.28.34) 74.999 ms 74.569 ms > be2165.ccr22.sjc01.atlas.cogentco.com (154.54.28.66) 74.852 ms > 14 be2063.rcr21.b001848-1.sjc01.atlas.cogentco.com (154.54.1.162) 74.377 ms > be2095.rcr21.b001848-1.sjc01.atlas.cogentco.com (154.54.3.138) 77.126 ms 89.476 ms > 15 c1.sj.mpt.fiberinternetcenter.net (66.201.58.2) 82.483 ms 86.964 ms 80.094 ms > 16 sanjose2.barefruit.co.uk (66.201.32.134) 125.112 ms 106.932 ms 124.778 ms > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > 31 * * * > 32 * * * > 33 * * * > 34 * * * > 35 * * * > 36 * * * > 37 * * * > 38 * * * > 39 * * * > 40 * unallocated.barefruit.co.uk (92.242.140.21) 111.898 ms * > gordons-mac-pro:~ gordoncook$ > > PS: my FIOS contract is up in april. Any suggestion of how to avoid a $30 per month price increase would be greatly appreciated > > OFF list of course many thanks > > Gordon Cook > > COOK Report on Internet Protocol From cb.list6 at gmail.com Tue Feb 24 18:15:23 2015 From: cb.list6 at gmail.com (Ca By) Date: Tue, 24 Feb 2015 10:15:23 -0800 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: On Tue, Feb 24, 2015 at 10:08 AM, Blair Trosper wrote: > I have an unimpeachable source at AWS that assures me they're working hard > to deploy IPv6. As it was explained to me, since AWS was sort of first to > the table -- well before IPv6 "popped", they had designed everything on the > v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, which > they're phasing out. > > But I'm assured they're rushing IPv6 deployment of CloudFront and other > services as fast as they can. I'm assured of this. > > talk is cheap. I suggest people use Cloudflare or Akamai for proper IPv6 CDN reach to major IPv6 eyeball networks at AT&T, Verizon, Comcast, and T-Mobile US -- all of which have major ipv6 deployments http://www.worldipv6launch.org/measurements/ > But you also have to appreciate the hassle of retrofitting a cloud > platform of that scale, so I do not envy the task that AWS is undertaking. > > work is hard > On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong wrote: > >> Amazon is not the only public cloud. >> >> There are several public clouds that can support IPv6 directly. >> >> I have done some work for and believe these guys do a good job: >> >> Host Virtual (vr.org ) >> >> >> In no particular order and I have no relationship with or loyalty or >> benefit associated with any of them. I neither endorse, nor decry any of >> the following: >> >> Linode >> SoftLayer >> RackSpace >> >> There are others that I am not recalling off the top of my head. >> >> Owen >> >> > On Feb 23, 2015, at 07:52 , Ca By wrote: >> > >> > On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann >> wrote: >> > >> >> Currently engaged on a project where they’re building out a VPC >> >> infrastructure for hosted applications. >> >> >> >> Users access apps in the VPC, not the other direction. >> >> >> >> The issue I'm trying to get around is the customers who need to connect >> >> have multiple overlapping RFC1918 space (including overlapping what was >> >> proposed for the VPC networks). Finding a hole that is big enough and >> not >> >> in use by someone else is nearly impossible AND the customers could go >> >> through mergers which make them renumber even more in to overlapping >> 1918 >> >> space. >> >> >> >> Initially, I was looking at doing something like (example IP’s): >> >> >> >> >> >> Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC >> <——> >> >> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) >> >> >> >> Classic overlapping subnets on both ends with allocations out of >> >> 100.64.0.0/10 to NAT in both directions. Each sees the other end in >> >> 100.64 space, but the mappings can get tricky and hard to keep track of >> >> (especially if you’re not a network engineer). >> >> >> >> >> >> In spitballing, the boat hasn’t sailed too far to say “Why not use >> >> 100.64/10 in the VPC?” >> >> >> >> Then, the customer would be allocated a /28 or larger (depending on >> needs) >> >> to NAT on their side and NAT it once. After that, no more NAT for the >> VPC >> >> and it boils down to firewall rules. Their device needs to NAT >> outbound >> >> before it fires it down the tunnel which pfSense and ASA’s appear to be >> >> able to do. >> >> >> >> I prototyped this up over the weekend with multiple VPC’s in multiple >> >> regions and it “appears” to work fine. >> >> >> >> From the operator community, what are the downsides? >> >> >> >> Customers are businesses on dedicated business services vs. consumer >> cable >> >> modems (although there are a few on business class cable). Others are >> on >> >> MPLS and I’m hashing that out. >> >> >> >> The only one I can see is if the customer has a service provider with >> >> their external interface in 100.64 space. However, this approach would >> >> have a more specific in that space so it should fire it down the >> tunnel for >> >> their allocated customer block (/28) vs. their external side. >> >> >> >> Thoughts and thanks in advance. >> >> >> >> Eric >> >> >> > >> > Wouldn't it be nice if Amazon supported IPv6 in VPC? >> > >> > I have disqualified several projects from using the "public cloud" and >> put >> > them in the on-premise "private cloud" because Amazon is missing this >> key >> > scaling feature -- ipv6. It is odd that Amazon, a company with scale >> > deeply in its DNA, fails so hard on IPv6. I guess they have a lot of >> > brittle technical debt they can't upgrade. >> > >> > I suggest you go with private cloud if possible. >> > >> > Or, you can double NAT non-unique IPv4 space. >> > >> > Regarding 100.64.0.0/10, despite what the RFCs may say, this space is >> just >> > an augment of RFC1918 and i have already deployed it as such. >> > >> > CB >> >> > From sander at steffann.nl Tue Feb 24 18:16:51 2015 From: sander at steffann.nl (Sander Steffann) Date: Tue, 24 Feb 2015 19:16:51 +0100 Subject: v6 deagg In-Reply-To: References: <20150220080726.GA23425@pob.ytti.fi> <20150223104629.GA1969@bongo.bofh.it> Message-ID: <0B8F7F24-16A2-41B2-A0C9-67840434A7DB@steffann.nl> Hi Bill, > I don't fully understand the math yet but the algorithm doesn't smell > right. As near as I can figure it may only be correct in a static > system. If after convergence the disaggregate ceases to be reachable > from the aggregate, there doesn't appear to be either enough > information in the system or enough triggers traveling between routers > for it to reconverge to a correct state. If a network announces an aggregate when they can't reach all more-specifics then things will already be broken. Don't announce address space that you can't handle traffic for... But true: without Dragon the more specific would still arrive via another path and it would still be reachable. Cheers, Sander From alex.buie at frozenfeline.net Tue Feb 24 18:18:27 2015 From: alex.buie at frozenfeline.net (Alex Buie) Date: Tue, 24 Feb 2015 13:18:27 -0500 Subject: OT: VPS with Routed IP space Message-ID: Anybody know of or have recommendations for providers of small VPS-line boxen (or alternative solutions) to serve as GRE endpoints? (for a small amount of IP addresses, /29 or /28 at most) I am finding a lot of places that will give you extra IPs on the box itself (oftentimes out of the provider's own larger unsubnetted prefix) but I am looking more for a setup with a single IP on the box and a prefix routed to it. TIA for your insight. Alex (if you or your company can do this, direct solicitations are okay too. do keep in mind it's just a personal project and I do not have larger commercial volume at this time) From patrick at ianai.net Tue Feb 24 18:22:26 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 24 Feb 2015 13:22:26 -0500 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: <6B24A6A9-9418-43C9-AD75-5245F2CB2B70@ianai.net> I personally find it amusing that companies try to have it both ways. "We are huge, you should use us instead of $LITTLE_GUY because our resources & scale make us better able to handle things. Oh, what, you want IPv6? We're too big to do that quickly...." But hey, I would try the same thing in their position. -- TTFN, patrick > On Feb 24, 2015, at 13:15 , Ca By wrote: > > On Tue, Feb 24, 2015 at 10:08 AM, Blair Trosper > wrote: > >> I have an unimpeachable source at AWS that assures me they're working hard >> to deploy IPv6. As it was explained to me, since AWS was sort of first to >> the table -- well before IPv6 "popped", they had designed everything on the >> v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, which >> they're phasing out. >> >> But I'm assured they're rushing IPv6 deployment of CloudFront and other >> services as fast as they can. I'm assured of this. >> >> > talk is cheap. I suggest people use Cloudflare or Akamai for proper IPv6 > CDN reach to major IPv6 eyeball networks at AT&T, Verizon, Comcast, and > T-Mobile US -- all of which have major ipv6 deployments > > http://www.worldipv6launch.org/measurements/ > > > > >> But you also have to appreciate the hassle of retrofitting a cloud >> platform of that scale, so I do not envy the task that AWS is undertaking. >> >> > work is hard > > >> On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong wrote: >> >>> Amazon is not the only public cloud. >>> >>> There are several public clouds that can support IPv6 directly. >>> >>> I have done some work for and believe these guys do a good job: >>> >>> Host Virtual (vr.org ) >>> >>> >>> In no particular order and I have no relationship with or loyalty or >>> benefit associated with any of them. I neither endorse, nor decry any of >>> the following: >>> >>> Linode >>> SoftLayer >>> RackSpace >>> >>> There are others that I am not recalling off the top of my head. >>> >>> Owen >>> >>>> On Feb 23, 2015, at 07:52 , Ca By wrote: >>>> >>>> On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann >>> wrote: >>>> >>>>> Currently engaged on a project where they’re building out a VPC >>>>> infrastructure for hosted applications. >>>>> >>>>> Users access apps in the VPC, not the other direction. >>>>> >>>>> The issue I'm trying to get around is the customers who need to connect >>>>> have multiple overlapping RFC1918 space (including overlapping what was >>>>> proposed for the VPC networks). Finding a hole that is big enough and >>> not >>>>> in use by someone else is nearly impossible AND the customers could go >>>>> through mergers which make them renumber even more in to overlapping >>> 1918 >>>>> space. >>>>> >>>>> Initially, I was looking at doing something like (example IP’s): >>>>> >>>>> >>>>> Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC >>> <——> >>>>> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) >>>>> >>>>> Classic overlapping subnets on both ends with allocations out of >>>>> 100.64.0.0/10 to NAT in both directions. Each sees the other end in >>>>> 100.64 space, but the mappings can get tricky and hard to keep track of >>>>> (especially if you’re not a network engineer). >>>>> >>>>> >>>>> In spitballing, the boat hasn’t sailed too far to say “Why not use >>>>> 100.64/10 in the VPC?” >>>>> >>>>> Then, the customer would be allocated a /28 or larger (depending on >>> needs) >>>>> to NAT on their side and NAT it once. After that, no more NAT for the >>> VPC >>>>> and it boils down to firewall rules. Their device needs to NAT >>> outbound >>>>> before it fires it down the tunnel which pfSense and ASA’s appear to be >>>>> able to do. >>>>> >>>>> I prototyped this up over the weekend with multiple VPC’s in multiple >>>>> regions and it “appears” to work fine. >>>>> >>>>> From the operator community, what are the downsides? >>>>> >>>>> Customers are businesses on dedicated business services vs. consumer >>> cable >>>>> modems (although there are a few on business class cable). Others are >>> on >>>>> MPLS and I’m hashing that out. >>>>> >>>>> The only one I can see is if the customer has a service provider with >>>>> their external interface in 100.64 space. However, this approach would >>>>> have a more specific in that space so it should fire it down the >>> tunnel for >>>>> their allocated customer block (/28) vs. their external side. >>>>> >>>>> Thoughts and thanks in advance. >>>>> >>>>> Eric >>>>> >>>> >>>> Wouldn't it be nice if Amazon supported IPv6 in VPC? >>>> >>>> I have disqualified several projects from using the "public cloud" and >>> put >>>> them in the on-premise "private cloud" because Amazon is missing this >>> key >>>> scaling feature -- ipv6. It is odd that Amazon, a company with scale >>>> deeply in its DNA, fails so hard on IPv6. I guess they have a lot of >>>> brittle technical debt they can't upgrade. >>>> >>>> I suggest you go with private cloud if possible. >>>> >>>> Or, you can double NAT non-unique IPv4 space. >>>> >>>> Regarding 100.64.0.0/10, despite what the RFCs may say, this space is >>> just >>>> an augment of RFC1918 and i have already deployed it as such. >>>> >>>> CB >>> >>> >> From lnguyen at opsource.net Tue Feb 24 18:27:30 2015 From: lnguyen at opsource.net (Luan Nguyen) Date: Tue, 24 Feb 2015 13:27:30 -0500 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: Shouldn't it be the other way around? Ipv6 as the unique universal external network and you can define your own IPv4 within your cloud context separate from the cloud provider network and from other customers. So if you have contexts in different region - you can interconnect using layer 3 or layer 2 - through the cloud provider network...bring your own IPv4. If you need internet access, you'll get NATted. If you need connections to your branches/HQs...etc, build your own tunnel or use the cloud provider - which by the way gives you your own vrf so no need to worry about overlapping anything. Noone heard of Dimension Data Cloud? :) On Tue, Feb 24, 2015 at 1:10 PM, Blair Trosper wrote: > ADDENDUM: They're taking into consideration my suggestion of using IPv6 as > a "universal" internal network so that the different regions could be > interconnected without having to give up the region-independent use of > 10.0.0.0/8, which I think would be an elegant solution. > > On Tue, Feb 24, 2015 at 12:08 PM, Blair Trosper > wrote: > > > I have an unimpeachable source at AWS that assures me they're working > hard > > to deploy IPv6. As it was explained to me, since AWS was sort of first > to > > the table -- well before IPv6 "popped", they had designed everything on > the > > v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, > which > > they're phasing out. > > > > But I'm assured they're rushing IPv6 deployment of CloudFront and other > > services as fast as they can. I'm assured of this. > > > > But you also have to appreciate the hassle of retrofitting a cloud > > platform of that scale, so I do not envy the task that AWS is > undertaking. > > > > On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong wrote: > > > >> Amazon is not the only public cloud. > >> > >> There are several public clouds that can support IPv6 directly. > >> > >> I have done some work for and believe these guys do a good job: > >> > >> Host Virtual (vr.org ) > >> > >> In no particular order and I have no relationship with or loyalty or > >> benefit associated with any of them. I neither endorse, nor decry any of > >> the following: > >> > >> Linode > >> SoftLayer > >> RackSpace > >> > >> There are others that I am not recalling off the top of my head. > >> > >> Owen > >> > >> > On Feb 23, 2015, at 07:52 , Ca By wrote: > >> > > >> > On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann > >> wrote: > >> > > >> >> Currently engaged on a project where they’re building out a VPC > >> >> infrastructure for hosted applications. > >> >> > >> >> Users access apps in the VPC, not the other direction. > >> >> > >> >> The issue I'm trying to get around is the customers who need to > connect > >> >> have multiple overlapping RFC1918 space (including overlapping what > was > >> >> proposed for the VPC networks). Finding a hole that is big enough > and > >> not > >> >> in use by someone else is nearly impossible AND the customers could > go > >> >> through mergers which make them renumber even more in to overlapping > >> 1918 > >> >> space. > >> >> > >> >> Initially, I was looking at doing something like (example IP’s): > >> >> > >> >> > >> >> Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC > >> <——> > >> >> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) > >> >> > >> >> Classic overlapping subnets on both ends with allocations out of > >> >> 100.64.0.0/10 to NAT in both directions. Each sees the other end in > >> >> 100.64 space, but the mappings can get tricky and hard to keep track > of > >> >> (especially if you’re not a network engineer). > >> >> > >> >> > >> >> In spitballing, the boat hasn’t sailed too far to say “Why not use > >> >> 100.64/10 in the VPC?” > >> >> > >> >> Then, the customer would be allocated a /28 or larger (depending on > >> needs) > >> >> to NAT on their side and NAT it once. After that, no more NAT for > the > >> VPC > >> >> and it boils down to firewall rules. Their device needs to NAT > >> outbound > >> >> before it fires it down the tunnel which pfSense and ASA’s appear to > be > >> >> able to do. > >> >> > >> >> I prototyped this up over the weekend with multiple VPC’s in multiple > >> >> regions and it “appears” to work fine. > >> >> > >> >> From the operator community, what are the downsides? > >> >> > >> >> Customers are businesses on dedicated business services vs. consumer > >> cable > >> >> modems (although there are a few on business class cable). Others > are > >> on > >> >> MPLS and I’m hashing that out. > >> >> > >> >> The only one I can see is if the customer has a service provider with > >> >> their external interface in 100.64 space. However, this approach > would > >> >> have a more specific in that space so it should fire it down the > >> tunnel for > >> >> their allocated customer block (/28) vs. their external side. > >> >> > >> >> Thoughts and thanks in advance. > >> >> > >> >> Eric > >> >> > >> > > >> > Wouldn't it be nice if Amazon supported IPv6 in VPC? > >> > > >> > I have disqualified several projects from using the "public cloud" and > >> put > >> > them in the on-premise "private cloud" because Amazon is missing this > >> key > >> > scaling feature -- ipv6. It is odd that Amazon, a company with scale > >> > deeply in its DNA, fails so hard on IPv6. I guess they have a lot of > >> > brittle technical debt they can't upgrade. > >> > > >> > I suggest you go with private cloud if possible. > >> > > >> > Or, you can double NAT non-unique IPv4 space. > >> > > >> > Regarding 100.64.0.0/10, despite what the RFCs may say, this space is > >> just > >> > an augment of RFC1918 and i have already deployed it as such. > >> > > >> > CB > >> > >> > > > From blair.trosper at gmail.com Tue Feb 24 18:59:15 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 24 Feb 2015 12:59:15 -0600 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: That's sort of what I meant to say. I did not articulate it well. The problem *with* AWS is that in VPC (or different regions), the internal network space is unique to each region. So, in theory, I could get 10.1.2.3 in two regions on two instances. In VPC, you can also designate your own subnets, which makes things a little more tough a la interconnecting the disparate regions. But, as you say, IPv6 would be an elegant solution to that problem...and that's what I meant to articulate. IPv6 as a region unification tool as well as an Internet-facing protocol. On Tue, Feb 24, 2015 at 12:27 PM, Luan Nguyen wrote: > Shouldn't it be the other way around? Ipv6 as the unique universal > external network and you can define your own IPv4 within your cloud context > separate from the cloud provider network and from other customers. So if > you have contexts in different region - you can interconnect using layer 3 > or layer 2 - through the cloud provider network...bring your own IPv4. If > you need internet access, you'll get NATted. If you need connections to > your branches/HQs...etc, build your own tunnel or use the cloud provider - > which by the way gives you your own vrf so no need to worry about > overlapping anything. > Noone heard of Dimension Data Cloud? :) > > On Tue, Feb 24, 2015 at 1:10 PM, Blair Trosper > wrote: > >> ADDENDUM: They're taking into consideration my suggestion of using IPv6 >> as >> a "universal" internal network so that the different regions could be >> interconnected without having to give up the region-independent use of >> 10.0.0.0/8, which I think would be an elegant solution. >> >> On Tue, Feb 24, 2015 at 12:08 PM, Blair Trosper >> wrote: >> >> > I have an unimpeachable source at AWS that assures me they're working >> hard >> > to deploy IPv6. As it was explained to me, since AWS was sort of first >> to >> > the table -- well before IPv6 "popped", they had designed everything on >> the >> > v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, >> which >> > they're phasing out. >> > >> > But I'm assured they're rushing IPv6 deployment of CloudFront and other >> > services as fast as they can. I'm assured of this. >> > >> > But you also have to appreciate the hassle of retrofitting a cloud >> > platform of that scale, so I do not envy the task that AWS is >> undertaking. >> > >> > On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong wrote: >> > >> >> Amazon is not the only public cloud. >> >> >> >> There are several public clouds that can support IPv6 directly. >> >> >> >> I have done some work for and believe these guys do a good job: >> >> >> >> Host Virtual (vr.org ) >> >> >> >> In no particular order and I have no relationship with or loyalty or >> >> benefit associated with any of them. I neither endorse, nor decry any >> of >> >> the following: >> >> >> >> Linode >> >> SoftLayer >> >> RackSpace >> >> >> >> There are others that I am not recalling off the top of my head. >> >> >> >> Owen >> >> >> >> > On Feb 23, 2015, at 07:52 , Ca By wrote: >> >> > >> >> > On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann >> >> wrote: >> >> > >> >> >> Currently engaged on a project where they’re building out a VPC >> >> >> infrastructure for hosted applications. >> >> >> >> >> >> Users access apps in the VPC, not the other direction. >> >> >> >> >> >> The issue I'm trying to get around is the customers who need to >> connect >> >> >> have multiple overlapping RFC1918 space (including overlapping what >> was >> >> >> proposed for the VPC networks). Finding a hole that is big enough >> and >> >> not >> >> >> in use by someone else is nearly impossible AND the customers could >> go >> >> >> through mergers which make them renumber even more in to overlapping >> >> 1918 >> >> >> space. >> >> >> >> >> >> Initially, I was looking at doing something like (example IP’s): >> >> >> >> >> >> >> >> >> Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to >> DC >> >> <——> >> >> >> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) >> >> >> >> >> >> Classic overlapping subnets on both ends with allocations out of >> >> >> 100.64.0.0/10 to NAT in both directions. Each sees the other end >> in >> >> >> 100.64 space, but the mappings can get tricky and hard to keep >> track of >> >> >> (especially if you’re not a network engineer). >> >> >> >> >> >> >> >> >> In spitballing, the boat hasn’t sailed too far to say “Why not use >> >> >> 100.64/10 in the VPC?” >> >> >> >> >> >> Then, the customer would be allocated a /28 or larger (depending on >> >> needs) >> >> >> to NAT on their side and NAT it once. After that, no more NAT for >> the >> >> VPC >> >> >> and it boils down to firewall rules. Their device needs to NAT >> >> outbound >> >> >> before it fires it down the tunnel which pfSense and ASA’s appear >> to be >> >> >> able to do. >> >> >> >> >> >> I prototyped this up over the weekend with multiple VPC’s in >> multiple >> >> >> regions and it “appears” to work fine. >> >> >> >> >> >> From the operator community, what are the downsides? >> >> >> >> >> >> Customers are businesses on dedicated business services vs. consumer >> >> cable >> >> >> modems (although there are a few on business class cable). Others >> are >> >> on >> >> >> MPLS and I’m hashing that out. >> >> >> >> >> >> The only one I can see is if the customer has a service provider >> with >> >> >> their external interface in 100.64 space. However, this approach >> would >> >> >> have a more specific in that space so it should fire it down the >> >> tunnel for >> >> >> their allocated customer block (/28) vs. their external side. >> >> >> >> >> >> Thoughts and thanks in advance. >> >> >> >> >> >> Eric >> >> >> >> >> > >> >> > Wouldn't it be nice if Amazon supported IPv6 in VPC? >> >> > >> >> > I have disqualified several projects from using the "public cloud" >> and >> >> put >> >> > them in the on-premise "private cloud" because Amazon is missing >> this >> >> key >> >> > scaling feature -- ipv6. It is odd that Amazon, a company with >> scale >> >> > deeply in its DNA, fails so hard on IPv6. I guess they have a lot of >> >> > brittle technical debt they can't upgrade. >> >> > >> >> > I suggest you go with private cloud if possible. >> >> > >> >> > Or, you can double NAT non-unique IPv4 space. >> >> > >> >> > Regarding 100.64.0.0/10, despite what the RFCs may say, this space >> is >> >> just >> >> > an augment of RFC1918 and i have already deployed it as such. >> >> > >> >> > CB >> >> >> >> >> > >> > > From baldur.norddahl at gmail.com Tue Feb 24 19:07:52 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 24 Feb 2015 20:07:52 +0100 Subject: OT: VPS with Routed IP space In-Reply-To: References: Message-ID: You just need to enable proxy ARP on the box to simulate a routed subnet. Den 24/02/2015 19.25 skrev "Alex Buie" : > Anybody know of or have recommendations for providers of small > VPS-line boxen (or alternative solutions) to serve as GRE endpoints? > (for a small amount of IP addresses, /29 or /28 at most) > > I am finding a lot of places that will give you extra IPs on the box > itself (oftentimes out of the provider's own larger unsubnetted > prefix) but I am looking more for a setup with a single IP on the box > and a prefix routed to it. > > TIA for your insight. > > Alex > > (if you or your company can do this, direct solicitations are okay > too. do keep in mind it's just a personal project and I do not have > larger commercial volume at this time) > From owen at delong.com Tue Feb 24 20:11:24 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 24 Feb 2015 12:11:24 -0800 Subject: OT: VPS with Routed IP space In-Reply-To: References: Message-ID: <6AACE066-6610-4AC7-AD5A-8450A30C6C7C@delong.com> Or NOT. That’s a horribly ugly thing to do in a situation where the desired behavior shouldn’t be that hard to achieve. Owen > On Feb 24, 2015, at 11:07 , Baldur Norddahl wrote: > > You just need to enable proxy ARP on the box to simulate a routed subnet. > Den 24/02/2015 19.25 skrev "Alex Buie" : > >> Anybody know of or have recommendations for providers of small >> VPS-line boxen (or alternative solutions) to serve as GRE endpoints? >> (for a small amount of IP addresses, /29 or /28 at most) >> >> I am finding a lot of places that will give you extra IPs on the box >> itself (oftentimes out of the provider's own larger unsubnetted >> prefix) but I am looking more for a setup with a single IP on the box >> and a prefix routed to it. >> >> TIA for your insight. >> >> Alex >> >> (if you or your company can do this, direct solicitations are okay >> too. do keep in mind it's just a personal project and I do not have >> larger commercial volume at this time) >> From zgiles at gmail.com Tue Feb 24 20:29:19 2015 From: zgiles at gmail.com (Zachary Giles) Date: Tue, 24 Feb 2015 15:29:19 -0500 Subject: OT: VPS with Routed IP space In-Reply-To: <6AACE066-6610-4AC7-AD5A-8450A30C6C7C@delong.com> References: <6AACE066-6610-4AC7-AD5A-8450A30C6C7C@delong.com> Message-ID: How about VPS providers who will do BGP... Do they exist? On Tue, Feb 24, 2015 at 3:11 PM, Owen DeLong wrote: > Or NOT. That’s a horribly ugly thing to do in a situation where the > desired behavior shouldn’t be that hard to achieve. > > Owen > > > On Feb 24, 2015, at 11:07 , Baldur Norddahl > wrote: > > > > You just need to enable proxy ARP on the box to simulate a routed subnet. > > Den 24/02/2015 19.25 skrev "Alex Buie" : > > > >> Anybody know of or have recommendations for providers of small > >> VPS-line boxen (or alternative solutions) to serve as GRE endpoints? > >> (for a small amount of IP addresses, /29 or /28 at most) > >> > >> I am finding a lot of places that will give you extra IPs on the box > >> itself (oftentimes out of the provider's own larger unsubnetted > >> prefix) but I am looking more for a setup with a single IP on the box > >> and a prefix routed to it. > >> > >> TIA for your insight. > >> > >> Alex > >> > >> (if you or your company can do this, direct solicitations are okay > >> too. do keep in mind it's just a personal project and I do not have > >> larger commercial volume at this time) > >> > > -- Zach Giles zgiles at gmail.com From nanog at techmonkeys.org Tue Feb 24 20:38:24 2015 From: nanog at techmonkeys.org (Jeff Fisher) Date: Tue, 24 Feb 2015 14:38:24 -0600 Subject: OT: VPS with Routed IP space In-Reply-To: References: <6AACE066-6610-4AC7-AD5A-8450A30C6C7C@delong.com> Message-ID: <54ECE140.2000405@techmonkeys.org> On 02/24/2015 02:29 PM, Zachary Giles wrote: > > How about VPS providers who will do BGP... Do they exist? > > Hit and miss I find. We do it for the odd client and haven't really had any issues. From colinj at gt86car.org.uk Tue Feb 24 20:52:32 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 24 Feb 2015 20:52:32 +0000 Subject: OT: VPS with Routed IP space In-Reply-To: References: <6AACE066-6610-4AC7-AD5A-8450A30C6C7C@delong.com> Message-ID: <122FF4CF-6F09-4D7F-8776-1D2DACC4CB79@gt86car.org.uk> deploy two utm's with bgp on the two internal and external interfaces col Sent from my iPhone > On 24 Feb 2015, at 20:29, Zachary Giles wrote: > > > How about VPS providers who will do BGP... Do they exist? > > >> On Tue, Feb 24, 2015 at 3:11 PM, Owen DeLong wrote: >> >> Or NOT. That’s a horribly ugly thing to do in a situation where the >> desired behavior shouldn’t be that hard to achieve. >> >> Owen >> >>>> On Feb 24, 2015, at 11:07 , Baldur Norddahl >>> wrote: >>> >>> You just need to enable proxy ARP on the box to simulate a routed subnet. >>> Den 24/02/2015 19.25 skrev "Alex Buie" : >>> >>>> Anybody know of or have recommendations for providers of small >>>> VPS-line boxen (or alternative solutions) to serve as GRE endpoints? >>>> (for a small amount of IP addresses, /29 or /28 at most) >>>> >>>> I am finding a lot of places that will give you extra IPs on the box >>>> itself (oftentimes out of the provider's own larger unsubnetted >>>> prefix) but I am looking more for a setup with a single IP on the box >>>> and a prefix routed to it. >>>> >>>> TIA for your insight. >>>> >>>> Alex >>>> >>>> (if you or your company can do this, direct solicitations are okay >>>> too. do keep in mind it's just a personal project and I do not have >>>> larger commercial volume at this time) > > > -- > Zach Giles > zgiles at gmail.com From raphael.timothy at gmail.com Tue Feb 24 21:48:56 2015 From: raphael.timothy at gmail.com (Tim Raphael) Date: Wed, 25 Feb 2015 05:48:56 +0800 Subject: OT: VPS with Routed IP space In-Reply-To: <54ECE140.2000405@techmonkeys.org> References: <6AACE066-6610-4AC7-AD5A-8450A30C6C7C@delong.com> <54ECE140.2000405@techmonkeys.org> Message-ID: <7F6A4AE0-AC78-456C-A07A-3F22E6E7C535@gmail.com> Same here, we do as well. But as per the OPs question: we will route additional space but you generally need a good reason for it. Regards, Tim Raphael > On 25 Feb 2015, at 4:38 am, Jeff Fisher wrote: > >> On 02/24/2015 02:29 PM, Zachary Giles wrote: >> >> How about VPS providers who will do BGP... Do they exist? >> > > Hit and miss I find. We do it for the odd client and haven't really had any issues. > > From g at 1337.io Tue Feb 24 22:02:23 2015 From: g at 1337.io (Gino O'Donnell) Date: Tue, 24 Feb 2015 14:02:23 -0800 Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment In-Reply-To: References: Message-ID: <54ECF4EF.4080608@1337.io> http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html On 2/24/15 10:59 AM, Blair Trosper wrote: > In VPC, you can also designate > your own subnets, which makes things a little more tough a la > interconnecting the disparate regions. > > On Tue, Feb 24, 2015 at 12:27 PM, Luan Nguyen wrote: > >> Shouldn't it be the other way around? Ipv6 as the unique universal >> external network and you can define your own IPv4 within your cloud context >> separate from the cloud provider network and from other customers. So if >> you have contexts in different region - you can interconnect using layer 3 >> or layer 2 - through the cloud provider network...bring your own IPv4. If >> you need internet access, you'll get NATted. If you need connections to >> your branches/HQs...etc, build your own tunnel or use the cloud provider - >> which by the way gives you your own vrf so no need to worry about >> overlapping anything. >> Noone heard of Dimension Data Cloud? :) >> >> On Tue, Feb 24, 2015 at 1:10 PM, Blair Trosper >> wrote: >> >>> ADDENDUM: They're taking into consideration my suggestion of using IPv6 >>> as >>> a "universal" internal network so that the different regions could be >>> interconnected without having to give up the region-independent use of >>> 10.0.0.0/8, which I think would be an elegant solution. >>> >>> On Tue, Feb 24, 2015 at 12:08 PM, Blair Trosper >>> wrote: >>> >>>> I have an unimpeachable source at AWS that assures me they're working >>> hard >>>> to deploy IPv6. As it was explained to me, since AWS was sort of first >>> to >>>> the table -- well before IPv6 "popped", they had designed everything on >>> the >>>> v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, >>> which >>>> they're phasing out. >>>> >>>> But I'm assured they're rushing IPv6 deployment of CloudFront and other >>>> services as fast as they can. I'm assured of this. >>>> >>>> But you also have to appreciate the hassle of retrofitting a cloud >>>> platform of that scale, so I do not envy the task that AWS is >>> undertaking. >>>> >>>> On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong wrote: >>>> >>>>> Amazon is not the only public cloud. >>>>> >>>>> There are several public clouds that can support IPv6 directly. >>>>> >>>>> I have done some work for and believe these guys do a good job: >>>>> >>>>> Host Virtual (vr.org ) >>>>> >>>>> In no particular order and I have no relationship with or loyalty or >>>>> benefit associated with any of them. I neither endorse, nor decry any >>> of >>>>> the following: >>>>> >>>>> Linode >>>>> SoftLayer >>>>> RackSpace >>>>> >>>>> There are others that I am not recalling off the top of my head. >>>>> >>>>> Owen >>>>> >>>>>> On Feb 23, 2015, at 07:52 , Ca By wrote: >>>>>> >>>>>> On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann >>>>> wrote: >>>>>> >>>>>>> Currently engaged on a project where they’re building out a VPC >>>>>>> infrastructure for hosted applications. >>>>>>> >>>>>>> Users access apps in the VPC, not the other direction. >>>>>>> >>>>>>> The issue I'm trying to get around is the customers who need to >>> connect >>>>>>> have multiple overlapping RFC1918 space (including overlapping what >>> was >>>>>>> proposed for the VPC networks). Finding a hole that is big enough >>> and >>>>> not >>>>>>> in use by someone else is nearly impossible AND the customers could >>> go >>>>>>> through mergers which make them renumber even more in to overlapping >>>>> 1918 >>>>>>> space. >>>>>>> >>>>>>> Initially, I was looking at doing something like (example IP’s): >>>>>>> >>>>>>> >>>>>>> Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to >>> DC >>>>> <——> >>>>>>> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) >>>>>>> >>>>>>> Classic overlapping subnets on both ends with allocations out of >>>>>>> 100.64.0.0/10 to NAT in both directions. Each sees the other end >>> in >>>>>>> 100.64 space, but the mappings can get tricky and hard to keep >>> track of >>>>>>> (especially if you’re not a network engineer). >>>>>>> >>>>>>> >>>>>>> In spitballing, the boat hasn’t sailed too far to say “Why not use >>>>>>> 100.64/10 in the VPC?” >>>>>>> >>>>>>> Then, the customer would be allocated a /28 or larger (depending on >>>>> needs) >>>>>>> to NAT on their side and NAT it once. After that, no more NAT for >>> the >>>>> VPC >>>>>>> and it boils down to firewall rules. Their device needs to NAT >>>>> outbound >>>>>>> before it fires it down the tunnel which pfSense and ASA’s appear >>> to be >>>>>>> able to do. >>>>>>> >>>>>>> I prototyped this up over the weekend with multiple VPC’s in >>> multiple >>>>>>> regions and it “appears” to work fine. >>>>>>> >>>>>>> From the operator community, what are the downsides? >>>>>>> >>>>>>> Customers are businesses on dedicated business services vs. consumer >>>>> cable >>>>>>> modems (although there are a few on business class cable). Others >>> are >>>>> on >>>>>>> MPLS and I’m hashing that out. >>>>>>> >>>>>>> The only one I can see is if the customer has a service provider >>> with >>>>>>> their external interface in 100.64 space. However, this approach >>> would >>>>>>> have a more specific in that space so it should fire it down the >>>>> tunnel for >>>>>>> their allocated customer block (/28) vs. their external side. >>>>>>> >>>>>>> Thoughts and thanks in advance. >>>>>>> >>>>>>> Eric >>>>>>> >>>>>> >>>>>> Wouldn't it be nice if Amazon supported IPv6 in VPC? >>>>>> >>>>>> I have disqualified several projects from using the "public cloud" >>> and >>>>> put >>>>>> them in the on-premise "private cloud" because Amazon is missing >>> this >>>>> key >>>>>> scaling feature -- ipv6. It is odd that Amazon, a company with >>> scale >>>>>> deeply in its DNA, fails so hard on IPv6. I guess they have a lot of >>>>>> brittle technical debt they can't upgrade. >>>>>> >>>>>> I suggest you go with private cloud if possible. >>>>>> >>>>>> Or, you can double NAT non-unique IPv4 space. >>>>>> >>>>>> Regarding 100.64.0.0/10, despite what the RFCs may say, this space >>> is >>>>> just >>>>>> an augment of RFC1918 and i have already deployed it as such. >>>>>> >>>>>> CB >>>>> >>>>> >>>> >>> >> >> -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From danieleiamartino at gmail.com Tue Feb 24 12:49:14 2015 From: danieleiamartino at gmail.com (Daniele Iamartino) Date: Tue, 24 Feb 2015 13:49:14 +0100 Subject: Quality of ROAs in RPKI repositories Message-ID: <54EC734A.7030601@gmail.com> Hi all, As part of my master thesis and research work at IIJ, I've created a page to monitor the "quality" of ROAs in all RIR's RPKI repositories. http://rpki.me/quality.html Overall, the ROAs are quite good. Of course there are problems: I found out some ROAs which are very likely to be mis-registrations and make several BGP announcements invalid. On the page you can see the list of those ROAs, and the list of BGP announcements related to each of them. I would suggest to check if any of your prefixes are on this list. These problems could be easily fixed by registering correct ROAs. What I do is basically origin-validating BGP announcements that I find in a RIB dump from LINX node of route-views, using ROAs taken from a validated RPKI cache (using rcynic). You can find other information on under the "what does this table mean?" button. I'm also keeping updated a page monitoring which DNS root servers have their BGP announcements covered by a valid ROA: http://rpki.me/dns.html I would appreciate to hear any comment or suggestion. Regards -- Daniele Iamartino Student at Politecnico di Milano, Italy From adrian at adrian.org Tue Feb 24 16:25:48 2015 From: adrian at adrian.org (Adrian Lamo) Date: Tue, 24 Feb 2015 16:25:48 +0000 Subject: AOL Postmaster In-Reply-To: References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> <54EBDF9A.8060402@web2objects.com> <20150224123612.GA29601@gsp.org> <6D8F82F1-6209-4A42-A459-E9219A611786@gt86car.org.uk> Message-ID: The quickest way of contacting the AOL Mail Team I'm aware of is through their Twitter account at @AOLMail (https://twitter.com/AOLMail). Tell them @6 sent you. ;) Cordially, A - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vox: +1 202 459 9800 x.1300 // secure: +1 410 874 0050 (phone calls need to be arranged in advance) e: adrian at 2600.COM // e: adrian.lamo at us.army.mil GPG/PGP public key: https://keybase.io/comsec/key.asc PGP Fingerprint (64 bit): 324B EE81 A275 E619 (COMSEC First! Verify fingerprint before using key.) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ El 2015-02-24 13:03, Suresh Ramasubramanian escribió: > And how many users do you have, again? > On Feb 24, 2015 6:29 PM, "Colin Johnston" > wrote: > >> block aol like china blocks with no engagement of comms as >> justification >> >> colin >> >> Sent from my iPhone >> >> > On 24 Feb 2015, at 12:36, Rich Kulawiec wrote: >> > >> >> On Tue, Feb 24, 2015 at 03:19:06AM +0100, Fred wrote: >> >> Having exactly the same issue. Also never received any response from >> >> AOL. Quite annoying. >> > >> > I've been waiting since January 26th for a response from >> dmarc-help at teamaol.com, >> > which is their stipulated contact point for DMARC issues. >> > >> > Of course I wouldn't *need* a response about that if they hadn't >> implemented >> > DMARC so foolishly. >> > >> > It seems that the days when Carl Hutzler ran the place -- and ran it >> well -- >> > are now well behind them. I didn't always agree with their decisions, >> > but it was obvious that they were working hard and trying to make AOL a >> > good network neighbor, so even when I disagreed I could at least >> acknowledge >> > their good intentions. It seems now that AOL is determined to permit >> > unlimited abuse directed at the entire rest of the Internet while >> > simultaneously making life as difficult as possible for everyone who >> > *doesn't* abuse...and is counting on their size to make them immune from >> > the consequences of that decision. >> > >> > ---rsk >> From elf at ubertel.net Tue Feb 24 21:42:25 2015 From: elf at ubertel.net (Michael Helmeste) Date: Tue, 24 Feb 2015 21:42:25 +0000 Subject: OT: VPS with Routed IP space In-Reply-To: References: <6AACE066-6610-4AC7-AD5A-8450A30C6C7C@delong.com> Message-ID: ARP Networks: https://www.arpnetworks.com/vps Routed IP space (v4 and v6) as well as BGP peering. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Zachary > Giles > Sent: Tuesday, February 24, 2015 12:29 PM > To: Owen DeLong > Cc: NANOG > Subject: Re: OT: VPS with Routed IP space > > > How about VPS providers who will do BGP... Do they exist? > > [...] > > > Den 24/02/2015 19.25 skrev "Alex Buie" : > > > > > >> Anybody know of or have recommendations for providers of small > > >> VPS-line boxen (or alternative solutions) to serve as GRE endpoints? > > [...] From morrowc.lists at gmail.com Tue Feb 24 22:32:08 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 24 Feb 2015 17:32:08 -0500 Subject: v6 deagg In-Reply-To: <0E7AFD3D-28E2-4D72-9661-5DFB099ACB28@delong.com> References: <1589DCC3-6396-4FF0-8CF9-C9EB386AA057@isi.edu> <0E7AFD3D-28E2-4D72-9661-5DFB099ACB28@delong.com> Message-ID: On Tue, Feb 24, 2015 at 12:27 PM, Owen DeLong wrote: > >> On Feb 19, 2015, at 21:25 , Christopher Morrow wrote: >> >> On Thu, Feb 19, 2015 at 10:16 PM, manning bill wrote: >>> and then there are the loons who will locally push /64 or longer, some of which may leak. >>> >> >> 2001:2b8:46:bbbb::/64 >> ... a fairly extensive list actually.... >> >>> show route table inet6.0 | grep ^2 | except /4[876543210] | except /3 | except /2 | count >> Count: 297 lines >> >> Some are likely my local network's interfaces (so skip ~50 or so? to >> be generous) and some might be my provider's customers? (but they >> shouldn't send me shorter than a /48, right?) >> >> -chris >> (note on another observation point I don't see this sort of thing so >> perhaps it's just one upstream in a collection... I'll ask them >> seperately) > > Your regular expression will not only count /49 and longer, it will also count /19 and shorter. > > In my routing table, there are at least some examples of such routes. yup, not very many and I think not enough to matter over all, give then actual point was I see many smaller (longer?) than /48 in the table. From dougb at dougbarton.us Tue Feb 24 22:59:42 2015 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 24 Feb 2015 14:59:42 -0800 Subject: OT: VPS with Routed IP space In-Reply-To: References: <6AACE066-6610-4AC7-AD5A-8450A30C6C7C@delong.com> Message-ID: <54ED025E.2050502@dougbarton.us> On 2/24/15 1:42 PM, Michael Helmeste wrote: > ARP Networks: https://www.arpnetworks.com/vps > > Routed IP space (v4 and v6) as well as BGP peering. +1 for Arp, I'm a happy customer (no other affiliation). FWIW, Doug From zgiles at gmail.com Tue Feb 24 23:59:29 2015 From: zgiles at gmail.com (Zachary Giles) Date: Tue, 24 Feb 2015 18:59:29 -0500 Subject: OT: VPS with Routed IP space In-Reply-To: <54ED025E.2050502@dougbarton.us> References: <6AACE066-6610-4AC7-AD5A-8450A30C6C7C@delong.com> <54ED025E.2050502@dougbarton.us> Message-ID: Thanks to those who mailed off-list for the BGP thread-jack. Seems like those providers that do BGP would probably route their own space to VPS as well.. (Like OP want. if I understand correctly). Some of them even state that they even SWIP the addresses, which is positive. On Tue, Feb 24, 2015 at 5:59 PM, Doug Barton wrote: > On 2/24/15 1:42 PM, Michael Helmeste wrote: > >> ARP Networks: https://www.arpnetworks.com/vps >> >> Routed IP space (v4 and v6) as well as BGP peering. >> > > +1 for Arp, I'm a happy customer (no other affiliation). > > FWIW, > > Doug > > > -- Zach Giles zgiles at gmail.com From bill at herrin.us Wed Feb 25 00:35:03 2015 From: bill at herrin.us (William Herrin) Date: Tue, 24 Feb 2015 19:35:03 -0500 Subject: v6 deagg In-Reply-To: <0B8F7F24-16A2-41B2-A0C9-67840434A7DB@steffann.nl> References: <20150220080726.GA23425@pob.ytti.fi> <20150223104629.GA1969@bongo.bofh.it> <0B8F7F24-16A2-41B2-A0C9-67840434A7DB@steffann.nl> Message-ID: On Tue, Feb 24, 2015 at 1:16 PM, Sander Steffann wrote: > Bill Herrin said: >> I don't fully understand the math yet but the algorithm doesn't smell >> right. As near as I can figure it may only be correct in a static >> system. If after convergence the disaggregate ceases to be reachable >> from the aggregate, there doesn't appear to be either enough >> information in the system or enough triggers traveling between routers >> for it to reconverge to a correct state. > > If a network announces an aggregate when they can't reach all > more-specifics then things will already be broken. Don't announce > address space that you can't handle traffic for... Howdy, That's... basically the opposite of how customer cutout routes work today. Funny thing about customers... when they go to the trouble of announcing a route to another ISP, they expect it to work even when the link to you fails. Not sure where they came up with such an unreasonable expectation. ;) Anyway, I heard back from DRAGON's authors. Paraphrasing: "An aggregate (e.g. 10.0.0.0/8) must be withdrawn if the aggregate's origin loses its direct route to the filterable disaggregate's origin (e.g. 10.2.3.0/24). The withdrawn aggregate is replaced with a synthesized set of announcements which fully cover the aggregate's address space excluding the unreachable disaggregate (e.g. 10.0.0.0/15, 10.2.0.0/23, 10.2.2.0/24, 10.2.4.0/22, 10.2.8.0/21, 10.2.16.0/20, etc.) When direct connectivity is restored, the aggregate is again announced and the synthetic announcements withdrawn." This overcomes my objection. The aggregate's origin can reasonably be programmed to trigger on the nearby disaggregate's withdrawal. System-wide withdrawal of the aggregate route is a sufficient trigger to cancel filtering on the disaggregate which should then fully propagate. And the overall savings should still be substantial even with transient synthetics in the table. I look forward to seeing how the authors address the many implications of this requirement. I'm not sold just yet but I am suitably impressed. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bill at herrin.us Wed Feb 25 00:45:43 2015 From: bill at herrin.us (William Herrin) Date: Tue, 24 Feb 2015 19:45:43 -0500 Subject: OT: VPS with Routed IP space In-Reply-To: References: Message-ID: On Tue, Feb 24, 2015 at 1:18 PM, Alex Buie wrote: > Anybody know of or have recommendations for providers of small > VPS-line boxen (or alternative solutions) to serve as GRE endpoints? > (for a small amount of IP addresses, /29 or /28 at most) > > I am finding a lot of places that will give you extra IPs on the box > itself (oftentimes out of the provider's own larger unsubnetted > prefix) but I am looking more for a setup with a single IP on the box > and a prefix routed to it. Hi Alex, You can usually deconfigure the extra IP's on the box and send them down the tunnel. At worst you do a little proxy arp to tell the router that your vps still serves those addresses. You'll find providers are reluctant to assign /28's and /29's to low-dollar VPS services. On Tue, Feb 24, 2015 at 3:29 PM, Zachary Giles wrote: > How about VPS providers who will do BGP... Do they exist? They do but it's BYOA and $10/mo generally doesn't cut it. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jared at puck.nether.net Wed Feb 25 01:04:27 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 24 Feb 2015 20:04:27 -0500 Subject: OT: VPS with Routed IP space In-Reply-To: References: Message-ID: <60FA5FCB-B1CD-4E5C-BC7E-29745E48734F@puck.nether.net> > On Feb 24, 2015, at 7:45 PM, William Herrin wrote: > > On Tue, Feb 24, 2015 at 1:18 PM, Alex Buie wrote: >> Anybody know of or have recommendations for providers of small >> VPS-line boxen (or alternative solutions) to serve as GRE endpoints? >> (for a small amount of IP addresses, /29 or /28 at most) >> >> I am finding a lot of places that will give you extra IPs on the box >> itself (oftentimes out of the provider's own larger unsubnetted >> prefix) but I am looking more for a setup with a single IP on the box >> and a prefix routed to it. > > Hi Alex, > > You can usually deconfigure the extra IP's on the box and send them > down the tunnel. At worst you do a little proxy arp to tell the router > that your vps still serves those addresses. > > You'll find providers are reluctant to assign /28's and /29's to > low-dollar VPS services. > > > On Tue, Feb 24, 2015 at 3:29 PM, Zachary Giles wrote: >> How about VPS providers who will do BGP... Do they exist? > > They do but it's BYOA and $10/mo generally doesn't cut it. Nat Morris has been doing this, here’s a presentation he has on this topic: http://www.slideshare.net/natmorris/anycast-on-a-shoe-string - Jared From eric at ericheather.com Wed Feb 25 01:09:15 2015 From: eric at ericheather.com (Eric C. Miller) Date: Wed, 25 Feb 2015 01:09:15 +0000 Subject: ARIN+NANOG On The Road Message-ID: Thank you to all who put this event on! It was fun getting to meet everyone :) Eric Miller, CCNP Network Engineering Consultant (407) 257-5115 From zgiles at gmail.com Wed Feb 25 01:14:40 2015 From: zgiles at gmail.com (Zachary Giles) Date: Tue, 24 Feb 2015 20:14:40 -0500 Subject: OT: VPS with Routed IP space In-Reply-To: <60FA5FCB-B1CD-4E5C-BC7E-29745E48734F@puck.nether.net> References: <60FA5FCB-B1CD-4E5C-BC7E-29745E48734F@puck.nether.net> Message-ID: never saw that post. right up my alley. Thanks! On Tue, Feb 24, 2015 at 8:04 PM, Jared Mauch wrote: > > > On Feb 24, 2015, at 7:45 PM, William Herrin wrote: > > > > On Tue, Feb 24, 2015 at 1:18 PM, Alex Buie > wrote: > >> Anybody know of or have recommendations for providers of small > >> VPS-line boxen (or alternative solutions) to serve as GRE endpoints? > >> (for a small amount of IP addresses, /29 or /28 at most) > >> > >> I am finding a lot of places that will give you extra IPs on the box > >> itself (oftentimes out of the provider's own larger unsubnetted > >> prefix) but I am looking more for a setup with a single IP on the box > >> and a prefix routed to it. > > > > Hi Alex, > > > > You can usually deconfigure the extra IP's on the box and send them > > down the tunnel. At worst you do a little proxy arp to tell the router > > that your vps still serves those addresses. > > > > You'll find providers are reluctant to assign /28's and /29's to > > low-dollar VPS services. > > > > > > On Tue, Feb 24, 2015 at 3:29 PM, Zachary Giles wrote: > >> How about VPS providers who will do BGP... Do they exist? > > > > They do but it's BYOA and $10/mo generally doesn't cut it. > > > Nat Morris has been doing this, here’s a presentation he has on this > topic: > > http://www.slideshare.net/natmorris/anycast-on-a-shoe-string > > - Jared -- Zach Giles zgiles at gmail.com From amitchell at isipp.com Wed Feb 25 01:42:44 2015 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Tue, 24 Feb 2015 18:42:44 -0700 Subject: AOL Postmaster Message-ID: For anyone having issues with AOL right now, if you would like, contact me offlist and I will see what I can do about getting it in front of our contact at AOL. Please be as specific as you can be about the issue, about who controls the IPs, about your own role and authority over the IPs and the email that flows through them, and please include at least one sample if possible. Anne Anne P. Mitchell, Esq. CEO/President ISIPP SuretyMail Email Reputation, Accreditation & Certification Your mail system + SuretyMail accreditation = delivered to their inbox! http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Author: Section 6 of the Federal CAN-SPAM Act of 2003 Member, California Bar Cyberspace Law Committee Ret. Professor of Law, Lincoln Law School of San Jose 303-731-2121 | amitchell at isipp.com | @AnnePMitchell | Facebook/AnnePMitchell From dseagrav at humancapitaldev.com Wed Feb 25 08:12:00 2015 From: dseagrav at humancapitaldev.com (Daniel Seagraves) Date: Wed, 25 Feb 2015 02:12:00 -0600 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) In-Reply-To: <7DB845D64966DC44A1CC592780539B4B012451FA@nafmbx47.exchange.ford.com> References: <29372525.2006.1424794973821.JavaMail.root@benjamin.baylink.com> <7DB845D64966DC44A1CC592780539B4B012451FA@nafmbx47.exchange.ford.com> Message-ID: On Feb 24, 2015, at 10:27 AM, Kain, Rebecca (.) wrote: > Ah, Comcast support. Those people who keep calling my Ford Motor Company phone, to threaten to shut off service to my home, which I don't have (I have uverse). They keep saying they will take my Ford number off the account (which of course, I don't know the account number because I don't have an account) and then they call again, with the same threat. > > Real winners. And yes, I've been saving the chats with support. Is it actually Comcast calling or is it just a debt collector saying they are Comcast? We have been getting at about a call a day for the past 5+ years looking for a Fred Sepp that skipped out on a $300 water bill. Each time they say they won’t call back, each time they sell the account to someone else. They’ll probably still be looking for him in another 5 years. From rsk at gsp.org Wed Feb 25 10:24:12 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 25 Feb 2015 05:24:12 -0500 Subject: AOL Postmaster In-Reply-To: References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> <54EBDF9A.8060402@web2objects.com> <20150224123612.GA29601@gsp.org> <6D8F82F1-6209-4A42-A459-E9219A611786@gt86car.org.uk> Message-ID: <20150225102412.GA21907@gsp.org> Their own announcement: http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ says that DMARC issues should be referred here: dmarc-help at teamaol.com (And before anyone asks, yes, the headers on mailing list traffic have been modified precisely as that page stipulates.) Perhaps it's too much to expect that in 2015 system and network admins will actually demonstrate baseline professionalism and competence by reading and answering role account email. ---rsk From bkain1 at ford.com Wed Feb 25 13:10:56 2015 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Wed, 25 Feb 2015 13:10:56 +0000 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) In-Reply-To: References: <29372525.2006.1424794973821.JavaMail.root@benjamin.baylink.com> <7DB845D64966DC44A1CC592780539B4B012451FA@nafmbx47.exchange.ford.com> Message-ID: <7DB845D64966DC44A1CC592780539B4B012466B9@nafmbx47.exchange.ford.com> No, it was Comcast. In December, it was to get him to pay his bill. In January, it was the same and in a chat with their support, they confirmed it's my Ford number on his account, but it's a guy's account and not at Ford's world headquarters, of course. They said they'd take my number off, which they didn't do. yesterday, they called to get their equipment back and I lost it on them. I had a support chat, then this post, then they answered my live journal, then "executive support" called me to confirm they were removing my phone number. I only really was concerned because my medical records were stolen and sold, a few years ago, so my social, and old DL and my ford phone number, were in there. They lost what could have been a potential customer by harassing me. if I had been stealing the service, calling me would not have helped but since I wasn't, they just pissed off a uverse (and potential future) Comcast client -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Daniel Seagraves Sent: Wednesday, February 25, 2015 3:12 AM To: nanog at nanog.org Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23) On Feb 24, 2015, at 10:27 AM, Kain, Rebecca (.) wrote: > Ah, Comcast support. Those people who keep calling my Ford Motor Company phone, to threaten to shut off service to my home, which I don't have (I have uverse). They keep saying they will take my Ford number off the account (which of course, I don't know the account number because I don't have an account) and then they call again, with the same threat. > > Real winners. And yes, I've been saving the chats with support. Is it actually Comcast calling or is it just a debt collector saying they are Comcast? We have been getting at about a call a day for the past 5+ years looking for a Fred Sepp that skipped out on a $300 water bill. Each time they say they won't call back, each time they sell the account to someone else. They'll probably still be looking for him in another 5 years. From math at sizone.org Wed Feb 25 13:55:18 2015 From: math at sizone.org (Ken Chase) Date: Wed, 25 Feb 2015 08:55:18 -0500 Subject: AOL Postmaster In-Reply-To: <20150225102412.GA21907@gsp.org> References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> <54EBDF9A.8060402@web2objects.com> <20150224123612.GA29601@gsp.org> <6D8F82F1-6209-4A42-A459-E9219A611786@gt86car.org.uk> <20150225102412.GA21907@gsp.org> Message-ID: <20150225135518.GH3593@sizone.org> Simple, one simply does not conduct business email over an AOL account. This is what I've been telling several of my customers about their contacts for a while now. /kc On Wed, Feb 25, 2015 at 05:24:12AM -0500, Rich Kulawiec said: > >Their own announcement: > > http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ > >says that DMARC issues should be referred here: > > dmarc-help at teamaol.com > >(And before anyone asks, yes, the headers on mailing list traffic >have been modified precisely as that page stipulates.) > >Perhaps it's too much to expect that in 2015 system and network admins >will actually demonstrate baseline professionalism and competence by >reading and answering role account email. > >---rsk -- Ken Chase - Toronto Canada From jfesler at gigo.com Wed Feb 25 17:49:09 2015 From: jfesler at gigo.com (Jason Fesler) Date: Wed, 25 Feb 2015 09:49:09 -0800 Subject: RIPE-631: IPv6 Troubleshooting for Residential ISP Helpdesks Message-ID: https://www.ripe.net/ripe/docs/ripe-631 We hope anyone deploying IPv6, and consequently staffing a help desk, to find this document useful. Please feel free to borrow and adapt it for your organization's needs. I'm sharing it here on NANOG because this document is not RIPE region specific. Disclaimer: this documents the use of http://test-ipv6.com/helpdesk - which I'm perhaps a bit biased about. That said, the bulk of the body of this work is coming from the community at large. -jason From johnstong at westmancom.com Wed Feb 25 21:09:06 2015 From: johnstong at westmancom.com (Graham Johnston) Date: Wed, 25 Feb 2015 21:09:06 +0000 Subject: Multiple Spanning Tree Instance 0 Message-ID: <49EE1A35457387418410F97564A3752B013673ECC2@MSG6.westman.int> We are planning a migration from Rapid PVST+ to Multiple Spanning Tree to better support a mixed vendor environment. My question today is about MST Instance 0. In practice do you map any VLANs there other than VLAN 1? Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. From billpatterson84 at gmail.com Wed Feb 25 21:40:50 2015 From: billpatterson84 at gmail.com (Bill Patterson) Date: Wed, 25 Feb 2015 16:40:50 -0500 Subject: AOL Postmaster In-Reply-To: <20150225135518.GH3593@sizone.org> References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> <54EBDF9A.8060402@web2objects.com> <20150224123612.GA29601@gsp.org> <6D8F82F1-6209-4A42-A459-E9219A611786@gt86car.org.uk> <20150225102412.GA21907@gsp.org> <20150225135518.GH3593@sizone.org> Message-ID: That was my first response as well. But that response was frowned upon by my customer service reps. On Feb 25, 2015 8:56 AM, "Ken Chase" wrote: > Simple, one simply does not conduct business email over an AOL account. > > This is what I've been telling several of my customers about their > contacts for a while now. > > /kc > > > On Wed, Feb 25, 2015 at 05:24:12AM -0500, Rich Kulawiec said: > > > >Their own announcement: > > > > > http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ > > > >says that DMARC issues should be referred here: > > > > dmarc-help at teamaol.com > > > >(And before anyone asks, yes, the headers on mailing list traffic > >have been modified precisely as that page stipulates.) > > > >Perhaps it's too much to expect that in 2015 system and network admins > >will actually demonstrate baseline professionalism and competence by > >reading and answering role account email. > > > >---rsk > > -- > Ken Chase - Toronto Canada > From owen at delong.com Wed Feb 25 22:46:52 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 25 Feb 2015 14:46:52 -0800 Subject: Comcast Support (from NANOG Digest, Vol 84, Issue 23) In-Reply-To: <7DB845D64966DC44A1CC592780539B4B012466B9@nafmbx47.exchange.ford.com> References: <29372525.2006.1424794973821.JavaMail.root@benjamin.baylink.com> <7DB845D64966DC44A1CC592780539B4B012451FA@nafmbx47.exchange.ford.com> <7DB845D64966DC44A1CC592780539B4B012466B9@nafmbx47.exchange.ford.com> Message-ID: <63442F26-9EC3-45C4-A4BB-329FC056B657@delong.com> I can assure you AT&T and Verizon have done equally bizarre, stupid, and annoying things. Owen > On Feb 25, 2015, at 05:10 , Kain, Rebecca (.) wrote: > > No, it was Comcast. In December, it was to get him to pay his bill. In January, it was the same and in a chat with their support, they confirmed it's my Ford number on his account, but it's a guy's account and not at Ford's world headquarters, of course. They said they'd take my number off, which they didn't do. yesterday, they called to get their equipment back and I lost it on them. I had a support chat, then this post, then they answered my live journal, then "executive support" called me to confirm they were removing my phone number. I only really was concerned because my medical records were stolen and sold, a few years ago, so my social, and old DL and my ford phone number, were in there. > > They lost what could have been a potential customer by harassing me. if I had been stealing the service, calling me would not have helped but since I wasn't, they just pissed off a uverse (and potential future) Comcast client > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Daniel Seagraves > Sent: Wednesday, February 25, 2015 3:12 AM > To: nanog at nanog.org > Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23) > > > On Feb 24, 2015, at 10:27 AM, Kain, Rebecca (.) wrote: > >> Ah, Comcast support. Those people who keep calling my Ford Motor Company phone, to threaten to shut off service to my home, which I don't have (I have uverse). They keep saying they will take my Ford number off the account (which of course, I don't know the account number because I don't have an account) and then they call again, with the same threat. >> >> Real winners. And yes, I've been saving the chats with support. > > Is it actually Comcast calling or is it just a debt collector saying they are Comcast? We have been getting at about a call a day for the past 5+ years looking for a Fred Sepp that skipped out on a $300 water bill. Each time they say they won't call back, each time they sell the account to someone else. They'll probably still be looking for him in another 5 years. > From ops.lists at gmail.com Thu Feb 26 01:54:35 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 26 Feb 2015 07:24:35 +0530 Subject: AOL Postmaster In-Reply-To: References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> <54EBDF9A.8060402@web2objects.com> <20150224123612.GA29601@gsp.org> <6D8F82F1-6209-4A42-A459-E9219A611786@gt86car.org.uk> <20150225102412.GA21907@gsp.org> <20150225135518.GH3593@sizone.org> Message-ID: You think every accountant, realtor, coffee shop etc uses their own domain? On Feb 26, 2015 3:12 AM, "Bill Patterson" wrote: > That was my first response as well. But that response was frowned upon by > my customer service reps. > On Feb 25, 2015 8:56 AM, "Ken Chase" wrote: > > > Simple, one simply does not conduct business email over an AOL account. > > > > This is what I've been telling several of my customers about their > > contacts for a while now. > > > > /kc > > > > > > On Wed, Feb 25, 2015 at 05:24:12AM -0500, Rich Kulawiec said: > > > > > >Their own announcement: > > > > > > > > > http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ > > > > > >says that DMARC issues should be referred here: > > > > > > dmarc-help at teamaol.com > > > > > >(And before anyone asks, yes, the headers on mailing list traffic > > >have been modified precisely as that page stipulates.) > > > > > >Perhaps it's too much to expect that in 2015 system and network admins > > >will actually demonstrate baseline professionalism and competence by > > >reading and answering role account email. > > > > > >---rsk > > > > -- > > Ken Chase - Toronto Canada > > > From math at sizone.org Thu Feb 26 04:20:22 2015 From: math at sizone.org (Ken Chase) Date: Wed, 25 Feb 2015 23:20:22 -0500 Subject: AOL Postmaster In-Reply-To: References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> <54EBDF9A.8060402@web2objects.com> <20150224123612.GA29601@gsp.org> <6D8F82F1-6209-4A42-A459-E9219A611786@gt86car.org.uk> <20150225102412.GA21907@gsp.org> <20150225135518.GH3593@sizone.org> Message-ID: <20150226042022.GD3583@sizone.org> they seem to use gmail and actually get their email. /kc On Thu, Feb 26, 2015 at 07:24:35AM +0530, Suresh Ramasubramanian said: > You think every accountant, realtor, coffee shop etc uses their own > domain? > -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From steve at blighty.com Thu Feb 26 12:52:58 2015 From: steve at blighty.com (Steve Atkins) Date: Thu, 26 Feb 2015 04:52:58 -0800 Subject: AOL Postmaster In-Reply-To: References: <14ff003b-e857-46c5-be40-366e86503548@west-canaan.net> <54EBDF9A.8060402@web2objects.com> <20150224123612.GA29601@gsp.org> <6D8F82F1-6209-4A42-A459-E9219A611786@gt86car.org.uk> <20150225102412.GA21907@gsp.org> <20150225135518.GH3593@sizone.org> Message-ID: On Feb 25, 2015, at 5:54 PM, Suresh Ramasubramanian wrote: > You think every accountant, realtor, coffee shop etc uses their own domain? No. But they should not, and in many cases *cannot*, rely on aol or yahoo addresses. It would suck for them to have to change all their contact information, business cards, and so on - but a) they chose their email provider unwisely and that's the cost of relying on an inappropriate vendor and b) they don't really need to - inbound mail to those addresses is mostly fine, so they just need to get a second email address and gradually migrate their outbound usage to that. Because the root cause of this issue is a long series of security mistakes by those providers, allowing 3rd parties to have access to user's (supposedly private) account information, the issue is specific to those providers, and there's no strong argument that other email providers are likely to make the same business choices. Cheers, Steve From blair.trosper at gmail.com Thu Feb 26 14:32:19 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 26 Feb 2015 08:32:19 -0600 Subject: Level 3 problems in Miami? Message-ID: Anyone else having massive trouble getting to endpoints beyond core routers in Miami on Level 3? I'm cut off (packets die) from Miami and Tampa after this specific router: po4-20g.ar1.mia2.gblx.net (67.16.134.218) If anyone from Level 3 could reach out, or if anyone knows what's going on and can say, I'd appreciate it. Thanks, Blair From blair.trosper at gmail.com Thu Feb 26 14:34:06 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 26 Feb 2015 08:34:06 -0600 Subject: Level 3 problems in Miami? In-Reply-To: References: Message-ID: Also seeing it after this one: po5.ar1.mia2.gblx.net (67.16.148.102) On Thu, Feb 26, 2015 at 8:32 AM, Blair Trosper wrote: > Anyone else having massive trouble getting to endpoints beyond core > routers in Miami on Level 3? > > I'm cut off (packets die) from Miami and Tampa after this specific router: > > po4-20g.ar1.mia2.gblx.net (67.16.134.218) > > If anyone from Level 3 could reach out, or if anyone knows what's going on > and can say, I'd appreciate it. > > Thanks, > Blair > From blair.trosper at gmail.com Thu Feb 26 14:59:00 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 26 Feb 2015 08:59:00 -0600 Subject: Level 3 problems in Miami? In-Reply-To: References: Message-ID: It's also failing in reverse from the Level 3 LG...doing a traceroute from Miami to myself, this is the result: 1 ae-1-51.edge4.Miami1.Level3.net (4.69.138.76) 0.591 ms 7.49 ms 0.540 ms 2 TWC-level3-40G.Miami.Level3.net (4.68.62.182) 0.668 ms 0.680 ms 15.2 ms 3 0.0.0.0 * * * 4 0.0.0.0 * * * 5 0.0.0.0 * * * Looks like it can't get any further than the interconnect router between Level 3 and TWC...can someone from Level 3 reach out or look into this please? On Thu, Feb 26, 2015 at 8:34 AM, Blair Trosper wrote: > Also seeing it after this one: > po5.ar1.mia2.gblx.net (67.16.148.102) > > On Thu, Feb 26, 2015 at 8:32 AM, Blair Trosper > wrote: > >> Anyone else having massive trouble getting to endpoints beyond core >> routers in Miami on Level 3? >> >> I'm cut off (packets die) from Miami and Tampa after this specific router: >> >> po4-20g.ar1.mia2.gblx.net (67.16.134.218) >> >> If anyone from Level 3 could reach out, or if anyone knows what's going >> on and can say, I'd appreciate it. >> >> Thanks, >> Blair >> > > From blair.trosper at gmail.com Thu Feb 26 16:05:23 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 26 Feb 2015 10:05:23 -0600 Subject: Level 3 problems in Miami? In-Reply-To: References: Message-ID: Level 3 confirms, ticket is open. On Thu, Feb 26, 2015 at 8:59 AM, Blair Trosper wrote: > It's also failing in reverse from the Level 3 LG...doing a traceroute from > Miami to myself, this is the result: > > 1 ae-1-51.edge4.Miami1.Level3.net (4.69.138.76) 0.591 ms 7.49 ms > 0.540 ms > 2 TWC-level3-40G.Miami.Level3.net (4.68.62.182) 0.668 ms 0.680 ms > 15.2 ms > 3 0.0.0.0 * * * > 4 0.0.0.0 * * * > 5 0.0.0.0 * * * > > Looks like it can't get any further than the interconnect router between > Level 3 and TWC...can someone from Level 3 reach out or look into this > please? > > On Thu, Feb 26, 2015 at 8:34 AM, Blair Trosper > wrote: > >> Also seeing it after this one: >> po5.ar1.mia2.gblx.net (67.16.148.102) >> >> On Thu, Feb 26, 2015 at 8:32 AM, Blair Trosper >> wrote: >> >>> Anyone else having massive trouble getting to endpoints beyond core >>> routers in Miami on Level 3? >>> >>> I'm cut off (packets die) from Miami and Tampa after this specific >>> router: >>> >>> po4-20g.ar1.mia2.gblx.net (67.16.134.218) >>> >>> If anyone from Level 3 could reach out, or if anyone knows what's going >>> on and can say, I'd appreciate it. >>> >>> Thanks, >>> Blair >>> >> >> > From s+Mailinglisten.nanog at sloc.de Thu Feb 26 17:58:34 2015 From: s+Mailinglisten.nanog at sloc.de (Sebastian Spies) Date: Thu, 26 Feb 2015 18:58:34 +0100 Subject: OT: VPS with Routed IP space In-Reply-To: <54ED025E.2050502@dougbarton.us> References: <6AACE066-6610-4AC7-AD5A-8450A30C6C7C@delong.com> <54ED025E.2050502@dougbarton.us> Message-ID: <54EF5ECA.4090309@sloc.de> Am 24.02.2015 um 23:59 schrieb Doug Barton: > On 2/24/15 1:42 PM, Michael Helmeste wrote: >> ARP Networks: https://www.arpnetworks.com/vps >> >> Routed IP space (v4 and v6) as well as BGP peering. > > +1 for Arp, I'm a happy customer (no other affiliation). > > We are going to do this at datapath.io using AWS and others soon. We do some BGP peering on your behalf and expose some parameters to the VPS via API. Best regards, Sebastian From jbates at paradoxnetworks.net Thu Feb 26 19:51:17 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Thu, 26 Feb 2015 13:51:17 -0600 Subject: v6 deagg In-Reply-To: References: <20150220080726.GA23425@pob.ytti.fi> <20150223104629.GA1969@bongo.bofh.it> <0B8F7F24-16A2-41B2-A0C9-67840434A7DB@steffann.nl> Message-ID: <54EF7935.3040904@paradoxnetworks.net> On 2/24/2015 6:35 PM, William Herrin wrote: > Anyway, I heard back from DRAGON's authors. Paraphrasing: "An > aggregate (e.g. 10.0.0.0/8) must be withdrawn if the aggregate's > origin loses its direct route to the filterable disaggregate's origin > (e.g. 10.2.3.0/24). The withdrawn aggregate is replaced with a > synthesized set of announcements which fully cover the aggregate's > address space excluding the unreachable disaggregate (e.g. > 10.0.0.0/15, 10.2.0.0/23, 10.2.2.0/24, 10.2.4.0/22, 10.2.8.0/21, > 10.2.16.0/20, etc.) When direct connectivity is restored, the > aggregate is again announced and the synthetic announcements > withdrawn." This overcomes my objection. The aggregate's origin can > reasonably be programmed to trigger on the nearby disaggregate's > withdrawal. System-wide withdrawal of the aggregate route is a > sufficient trigger to cancel filtering on the disaggregate which > should then fully propagate. And the overall savings should still be > substantial even with transient synthetics in the table. I look > forward to seeing how the authors address the many implications of > this requirement. I'm not sold just yet but I am suitably impressed. > Regards, Bill Herrin Yipee for huge amounts of automatic updates! I guess convergence latency is better than memory? So, how many /16 networks does a core network have which they hand out to customers that are multi-homed? What is the state of flux? Normally, we'd see the transition states of the more specific routes. Now we'll see multiple updates for each of those transition states (/24 removed so /16 is broken. Another /24 is removed so a /17 is broken, another /24 is removed so a /18 is broken). Provider X lost 50 multihomed customers spread across 20 aggregate networks. Process! Aggregates normally cover unassigned space as well. Do we now have to define to the router which space is supposed to be used and which is not so it knows when to break apart an aggregate? Removing a route "don't come this way!" is roughly the same as breaking the aggregate except for the extra processing time. It is likely that a node choosing between 2 aggregates would also be choosing the same between 2 more specific routes. Until convergence is done, it'd still route the wrong way in either case. One could stipulate that convergence might be slightly longer in this case due to update processing. Routing might be contrary to desire in cases where more specific route is advertised one way only and then an aggregate is used as a fallback. While the node filtering the more specific route may consider the path the same so it filters, the next node is making a choice between aggregates and may choose to send the traffic the other way because it's less AS hops; but don't worry, the 256k line backup will do just fine! Consider this simplistic model: A------B \ / C C is a business or ISP with it's own address space. It normally advertises an aggregate /20 to A and B. A and B local-pref C's routes because that's what transit providers do. C is under a DDOS attack. They issue a covering /24 to B and a /32 to B for blackhole service. B will propagate the /32 through it's entire network because the hop is to a discard (nifty!), however, the /24 will be the same as the /20, so it is filtered out. We can change the local-pref (go communities) of the /24 and that will allow it to propagate to A. A will accept the /24, presumably because the /24 doesn't match the selected /20 chosen (because of local pref). However! A--D---B \ / C D may or may not filter the /24 from B. It depends on their routing policy. A may only see the /20 from D and thus send all it's DDOS traffic on to C due to local-pref. Sorry, C. Next time, please manually change your BGP so you no longer advertise an aggregate. Oh, and it will be simpler for you to change if you just do /24 networks from now on and don't bother with the aggregate headache. SUMMARY: What is the cost if aggregates start being broke apart and not used because people want to insure their traffic does what they want? What is the cost of all these aggregate networks being broken up because their more specific routes aren't there? What is the cost of managing which smaller networks are supposed to be there and which are just unassigned currently to prevent aggregate breakup? Jack P.S. I didn't delve completely into all the documents and so perhaps I misunderstood or missed something important. My concerns may be completely unjustified. From lyndon at orthanc.ca Thu Feb 26 20:08:52 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 26 Feb 2015 12:08:52 -0800 (PST) Subject: protection.outlook.com SMTP support contact needed Message-ID: I'm running into TLS interoperability problems with some of the SMTP servers under the inbound.protection.outlook.com domain. Are there any Outlook postmasters lurking here that could contact me off list to help debug this? Thanks, --lyndon From mjwise at kapu.net Thu Feb 26 20:16:04 2015 From: mjwise at kapu.net (Michael J Wise) Date: Thu, 26 Feb 2015 12:16:04 -0800 Subject: protection.outlook.com SMTP support contact needed In-Reply-To: References: Message-ID: <2662df363238181497f1e9995ae52dd0.squirrel@secure.kapu.net> > I'm running into TLS interoperability problems with some of the SMTP > servers under the inbound.protection.outlook.com domain. Are there any > Outlook postmasters lurking here that could contact me off list to help > debug this? Maybe... But I'd check to see if you might be on a DNSBL first, just to be sure, as the Exchange Online Protection system doesn't advertise STARTTLS if your IP is blocked. What is the IP address that you are sending from? Otherwise, I would suggest having your recipient open a ticket with Customer Support for fastest resolution and traceability. Aloha mai Nai`a. -- " So this is how Liberty dies ... http://kapu.net/~mjwise/ " To Thunderous Applause. From j at arpa.com Thu Feb 26 21:16:25 2015 From: j at arpa.com (jamie rishaw) Date: Thu, 26 Feb 2015 15:16:25 -0600 Subject: [OT] Looking for dhs / fbi contact Message-ID: obviously off list, but who are we kidding ;) -- jamie rishaw // .com.arpa at j <- reverse it. ish. "I don't drink alcohol from that portion of the color spectrum." - Ron Swanson ( Nick Offerman ), "Parks and Recreation" From owen at delong.com Thu Feb 26 21:14:58 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 26 Feb 2015 13:14:58 -0800 Subject: OT: VPS with Routed IP space In-Reply-To: <54EF5ECA.4090309@sloc.de> References: <6AACE066-6610-4AC7-AD5A-8450A30C6C7C@delong.com> <54ED025E.2050502@dougbarton.us> <54EF5ECA.4090309@sloc.de> Message-ID: > On Feb 26, 2015, at 9:58 AM, Sebastian Spies wrote: > > > > Am 24.02.2015 um 23:59 schrieb Doug Barton: >> On 2/24/15 1:42 PM, Michael Helmeste wrote: >>> ARP Networks: https://www.arpnetworks.com/vps >>> >>> Routed IP space (v4 and v6) as well as BGP peering. >> >> +1 for Arp, I'm a happy customer (no other affiliation). >> >> > > We are going to do this at datapath.io using AWS and others soon. We do > some BGP peering on your behalf and expose some parameters to the VPS > via API. Since the requirement included IPv6, I’m not sure how you plan to use AWS. Owen From woody at pch.net Thu Feb 26 21:42:58 2015 From: woody at pch.net (Bill Woodcock) Date: Thu, 26 Feb 2015 13:42:58 -0800 Subject: [OT] Looking for dhs / fbi contact In-Reply-To: References: Message-ID: > On Feb 26, 2015, at 1:16 PM, jamie rishaw wrote: > > obviously off list, but who are we kidding ;) Uh, which? They’re unrelated agencies with completely different remits. -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 s+Mailinglisten.nanog at sloc.de Thu Feb 26 23:36:54 2015 From: s+Mailinglisten.nanog at sloc.de (Sebastian Spies) Date: Fri, 27 Feb 2015 00:36:54 +0100 Subject: OT: VPS with Routed IP space In-Reply-To: References: <6AACE066-6610-4AC7-AD5A-8450A30C6C7C@delong.com> <54ED025E.2050502@dougbarton.us> <54EF5ECA.4090309@sloc.de> Message-ID: <54EFAE16.5030600@sloc.de> Am 26.02.2015 um 22:14 schrieb Owen DeLong: >> On Feb 26, 2015, at 9:58 AM, Sebastian Spies wrote: >> >> >> >> Am 24.02.2015 um 23:59 schrieb Doug Barton: >>> On 2/24/15 1:42 PM, Michael Helmeste wrote: >>>> ARP Networks: https://www.arpnetworks.com/vps >>>> >>>> Routed IP space (v4 and v6) as well as BGP peering. >>> +1 for Arp, I'm a happy customer (no other affiliation). >>> >>> >> We are going to do this at datapath.io using AWS and others soon. We do >> some BGP peering on your behalf and expose some parameters to the VPS >> via API. > Since the requirement included IPv6, I’m not sure how you plan to use AWS. > You are right. Sorry for the sloppiness. OT: There is no way to even let two instances communicate with each other in the same VPC subnet using a protocol other than IPv4, although they transport ethernet headers (no VXLAN). Our only solution was to use v6 load balancers that tunnel with our endpoint on the other side of direct connect. From j at arpa.com Thu Feb 26 23:41:52 2015 From: j at arpa.com (jamie rishaw) Date: Thu, 26 Feb 2015 17:41:52 -0600 Subject: [OT] Looking for dhs / fbi contact In-Reply-To: References: Message-ID: Thanks for the off list reply. Oh, wait.. I was casting a wide net to fend off the "you got something?"ers but without addressing your question my query stands On Feb 26, 2015 3:43 PM, "Bill Woodcock" wrote: > > > On Feb 26, 2015, at 1:16 PM, jamie rishaw wrote: > > > > obviously off list, but who are we kidding ;) > > Uh, which? They're unrelated agencies with completely different remits. > > -Bill > > > > > From jared at puck.nether.net Thu Feb 26 23:47:24 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 26 Feb 2015 18:47:24 -0500 Subject: [OT] Looking for dhs / fbi contact In-Reply-To: References: Message-ID: Jamie, have you tried calling the local FBI office? I’ve had good luck with this when someone was sending me death threats and wanted them to have some good leads if something happened to me. You know where to find me if you want to ask questions off-list. Also, DHS is a sprawling agency, so depending on what you are looking for, you need to be a bit more specific, there are certain crimes that fall under the ICE/CBP side of the house vs USSS which depending on the nature of interagency cooperation is the lead for financial crimes. (Long history of why, but this is why counterfeit bills are USSS vs FBI). I doubt this helps, but there’s also NCFTA which you can contact as well. - Jared > On Feb 26, 2015, at 4:16 PM, jamie rishaw wrote: > > obviously off list, but who are we kidding ;) > > -- > jamie rishaw // .com.arpa at j <- reverse it. ish. > > "I don't drink alcohol from that portion of the color spectrum." > - Ron Swanson ( Nick Offerman ), "Parks and Recreation" From sotnickd-nanog at ddv.com Fri Feb 27 02:08:54 2015 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Thu, 26 Feb 2015 18:08:54 -0800 Subject: Sub-optimal routing to Google via IPv6 Message-ID: I have noticed that since we deployed IPv6 a number of years ago, that our IPv6 routes to Google's V6-enabled sites (e.g. www.google.com and www.youtube.com) traverse the CONUS from Oakland (where our primary Level 3 ISP connection is) to Washington D.C., New York, and then onto Google's network in New York, where the packets presumably pass across Google's internal networks. My traceroute [v0.71] hivemind (::) Thu Feb 26 18:03:44 2015 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Last Avg Best Wrst StDev 1. 2620:79:0:xxxx::ff7d 0.0% 0.4 0.4 0.4 0.4 0.0 2. 2620:79:0:xxxx::fd 0.0% 0.4 0.4 0.4 0.4 0.0 3. 2620:79:0:xxxx::249 0.0% 1.7 1.7 1.7 1.7 0.0 4. ge-6-24.car1.Oakland1.Level3.net 0.0% 316.3 316.3 316.3 316.3 0.0 5. vl-4043.edge1.SanJose1.Level3.net 0.0% 3.0 3.0 3.0 3.0 0.0 6. vl-4045.edge5.LosAngeles.Level3.net 0.0% 9.3 9.3 9.3 9.3 0.0 7. vl-4081.edge6.LosAngeles1.Level3.net 0.0% 9.2 9.2 9.2 9.2 0.0 8. vl-4041.edge1.Washington1.Level3.net 0.0% 116.5 116.5 116.5 116.5 0.0 9. vl-4080.edge2.Washington1.Level3.net 0.0% 75.0 75.0 75.0 75.0 0.0 10. vl-4068.edge2.Washington12.Level3.net 0.0% 75.5 75.5 75.5 75.5 0.0 11. vl-4047.car1.NewYork1.Level3.net 0.0% 76.5 76.5 76.5 76.5 0.0 12. vl-60.ear2.NewYork1.Level3.net 0.0% 110.2 110.2 110.2 110.2 0.0 13. Google-level3-30GB.NewYork1.Level3.net 0.0% 75.6 75.6 75.6 75.6 0.0 14. 2001:4860::1:0:3be 0.0% 76.1 76.1 76.1 76.1 0.0 15. 2001:4860::8:0:4397 0.0% 75.9 75.9 75.9 75.9 0.0 16. 2001:4860::8:0:5901 0.0% 73.5 73.5 73.5 73.5 0.0 17. 2001:4860::8:0:7894 0.0% 85.9 85.9 85.9 85.9 0.0 18. 2001:4860::8:0:79e5 0.0% 92.9 92.9 92.9 92.9 0.0 19. 2001:4860::8:0:6117 0.0% 73.5 73.5 73.5 73.5 0.0 20. 2001:4860::1:0:7ea 0.0% 71.9 71.9 71.9 71.9 0.0 21. 2001:4860:0:1::691 0.0% 72.1 72.1 72.1 72.1 0.0 22. ??? I haven't raised this issue with Level(3) yet, as I was wondering if this is really a Level(3) routing issue or a Google IPv6 routing issue? Thank for any insights. Regards, David Sotnick -- Pixar Emeryville, CA From charles at thefnf.org Fri Feb 27 02:45:21 2015 From: charles at thefnf.org (Charles N Wyble) Date: Thu, 26 Feb 2015 20:45:21 -0600 Subject: [OT] Looking for dhs / fbi contact In-Reply-To: References: Message-ID: They are in the phone book. Call them. Or walk into a field office near you. Don't bother nanog with such a generic / teasing question, its incredibly annoying. No one is going to provide you with a contact of any seriousness with such a generic query. On February 26, 2015 5:41:52 PM CST, jamie rishaw wrote: >Thanks for the off list reply. Oh, wait.. >I was casting a wide net to fend off the "you got something?"ers but >without addressing your question my query stands >On Feb 26, 2015 3:43 PM, "Bill Woodcock" wrote: > >> >> > On Feb 26, 2015, at 1:16 PM, jamie rishaw wrote: >> > >> > obviously off list, but who are we kidding ;) >> >> Uh, which? They're unrelated agencies with completely different >remits. >> >> -Bill >> >> >> >> >> > >!DSPAM:54efaf7b199101326251351! -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From chris at marget.com Fri Feb 27 11:03:24 2015 From: chris at marget.com (Chris Marget) Date: Fri, 27 Feb 2015 06:03:24 -0500 Subject: Multiple Spanning Tree Instance 0 In-Reply-To: <49EE1A35457387418410F97564A3752B013673ECC2@MSG6.westman.int> References: <49EE1A35457387418410F97564A3752B013673ECC2@MSG6.westman.int> Message-ID: On Wed, Feb 25, 2015 at 4:09 PM, Graham Johnston wrote: > We are planning a migration from Rapid PVST+ to Multiple Spanning Tree to > better support a mixed vendor environment. My question today is about MST > Instance 0. In practice do you map any VLANs there other than VLAN 1? I'd hoped to see some responses to this thread because I recently had some awkward moments with a vendor after discovering that their switch wouldn't allow me to map VLANs to STP instances in an arbitrary manner. I took the position that the implementation was faulty, their position was more along the lines of "Well, why would you want to do that anyway?" Addressing the question directly, I know of two switching platforms which force the operator to map VLANs other than 1 into instance 0. Some Broadcom FASTPATH based platforms fail to mention VLAN 4094 in any 'show spanning-tree' commands, but always maps it to instance 0. The implementation of MST available on Cumulus Linux only supports instance 0, maps all VLANs there. My Cumulus experience is a bit dated, this may have changed in the last year. /chris From larrysheldon at cox.net Fri Feb 27 14:05:32 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 27 Feb 2015 08:05:32 -0600 Subject: Verizon Policy Statement on Net Neutrality Message-ID: <54F079AC.8020103@cox.net> http://publicpolicy.verizon.com/blog/entry/fccs-throwback-thursday-move-imposes-1930s-rules-on-the-internet -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From littlefishguy at gmail.com Fri Feb 27 14:10:58 2015 From: littlefishguy at gmail.com (Scott Fisher) Date: Fri, 27 Feb 2015 09:10:58 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F079AC.8020103@cox.net> Message-ID: Funny, but in my honest opinion, unprofessional. Poor PR. On Fri, Feb 27, 2015 at 9:10 AM, Scott Fisher wrote: > Funny, but in my honest opinion, unprofessional. Poor PR. > > On Fri, Feb 27, 2015 at 9:05 AM, Larry Sheldon wrote: >> http://publicpolicy.verizon.com/blog/entry/fccs-throwback-thursday-move-imposes-1930s-rules-on-the-internet >> -- >> The unique Characteristics of System Administrators: >> >> The fact that they are infallible; and, >> >> The fact that they learn from their mistakes. >> >> >> Quis custodiet ipsos custodes > > > > -- > Scott -- Scott From nanog at ics-il.net Fri Feb 27 14:14:55 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 27 Feb 2015 08:14:55 -0600 (CST) Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: Message-ID: <29132477.7163.1425046469421.JavaMail.mhammett@ThunderFuck> You want 1930s telecom, you got it. ;-) Yes, I know telephone was available then. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Scott Fisher" To: "Larry Sheldon" , "NANOG list" Sent: Friday, February 27, 2015 8:10:58 AM Subject: Re: Verizon Policy Statement on Net Neutrality Funny, but in my honest opinion, unprofessional. Poor PR. On Fri, Feb 27, 2015 at 9:10 AM, Scott Fisher wrote: > Funny, but in my honest opinion, unprofessional. Poor PR. > > On Fri, Feb 27, 2015 at 9:05 AM, Larry Sheldon wrote: >> http://publicpolicy.verizon.com/blog/entry/fccs-throwback-thursday-move-imposes-1930s-rules-on-the-internet >> -- >> The unique Characteristics of System Administrators: >> >> The fact that they are infallible; and, >> >> The fact that they learn from their mistakes. >> >> >> Quis custodiet ipsos custodes > > > > -- > Scott -- Scott From jloiacon at csc.com Fri Feb 27 14:48:08 2015 From: jloiacon at csc.com (Joe Loiacono) Date: Fri, 27 Feb 2015 09:48:08 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F079AC.8020103@cox.net> Message-ID: Got your attention. Made a statement. Good for them. "NANOG" wrote on 02/27/2015 09:10:58 AM: > From: Scott Fisher > To: Larry Sheldon , NANOG list > Date: 02/27/2015 09:12 AM > Subject: Re: Verizon Policy Statement on Net Neutrality > Sent by: "NANOG" > > Funny, but in my honest opinion, unprofessional. Poor PR. > > On Fri, Feb 27, 2015 at 9:10 AM, Scott Fisher wrote: > > Funny, but in my honest opinion, unprofessional. Poor PR. > > > > On Fri, Feb 27, 2015 at 9:05 AM, Larry Sheldon wrote: > >> http://publicpolicy.verizon.com/blog/entry/fccs-throwback- > thursday-move-imposes-1930s-rules-on-the-internet > >> -- > >> The unique Characteristics of System Administrators: > >> > >> The fact that they are infallible; and, > >> > >> The fact that they learn from their mistakes. > >> > >> > >> Quis custodiet ipsos custodes > > > > > > > > -- > > Scott > > > > -- > Scott From rob at invaluement.com Fri Feb 27 14:50:16 2015 From: rob at invaluement.com (Rob McEwen) Date: Fri, 27 Feb 2015 09:50:16 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F079AC.8020103@cox.net> Message-ID: <54F08428.4000705@invaluement.com> Scott Fisher, I think Verizon's statement was brilliant, and entirely appropriate. Some people are going to have a hard time discovering that being in favor of Obama's version of "net neutrality"... will soon be just about as cool as having supported SOPA. btw - does anyone know if that thick book of regulations, you know... those hundreds of pages we weren't allowed to see before the vote... anyone know if that is available to the public now? If so, where? Rob McEwen On Fri, Feb 27, 2015 at 9:10 AM, Scott Fisher wrote: > Funny, but in my honest opinion, unprofessional. Poor PR. > > On Fri, Feb 27, 2015 at 9:05 AM, Larry Sheldon wrote: >> http://publicpolicy.verizon.com/blog/entry/fccs-throwback-thursday-move-imposes-1930s-rules-on-the-internet From nanog at ics-il.net Fri Feb 27 14:55:02 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 27 Feb 2015 08:55:02 -0600 (CST) Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F08428.4000705@invaluement.com> Message-ID: <15061035.7281.1425048878122.JavaMail.mhammett@ThunderFuck> They won't be available for days, weeks, months, etc. After the vote, they are subject to editorial review... which isn't so much editorial as whatever the hell they want. They could just be literally adding commas and capitalizing letters to completely changing the language of something. Whenever that day comes... ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Rob McEwen" To: nanog at nanog.org Sent: Friday, February 27, 2015 8:50:16 AM Subject: Re: Verizon Policy Statement on Net Neutrality Scott Fisher, I think Verizon's statement was brilliant, and entirely appropriate. Some people are going to have a hard time discovering that being in favor of Obama's version of "net neutrality"... will soon be just about as cool as having supported SOPA. btw - does anyone know if that thick book of regulations, you know... those hundreds of pages we weren't allowed to see before the vote... anyone know if that is available to the public now? If so, where? Rob McEwen On Fri, Feb 27, 2015 at 9:10 AM, Scott Fisher wrote: > Funny, but in my honest opinion, unprofessional. Poor PR. > > On Fri, Feb 27, 2015 at 9:05 AM, Larry Sheldon wrote: >> http://publicpolicy.verizon.com/blog/entry/fccs-throwback-thursday-move-imposes-1930s-rules-on-the-internet From iggdawg at gmail.com Fri Feb 27 14:54:54 2015 From: iggdawg at gmail.com (Ian Bowers) Date: Fri, 27 Feb 2015 09:54:54 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F08428.4000705@invaluement.com> References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com> Message-ID: "Blah blah politics". This is Verizon whining. plain and simple. On Fri, Feb 27, 2015 at 9:50 AM, Rob McEwen wrote: > Scott Fisher, > > I think Verizon's statement was brilliant, and entirely appropriate. Some > people are going to have a hard time discovering that being in favor of > Obama's version of "net neutrality"... will soon be just about as cool as > having supported SOPA. > > btw - does anyone know if that thick book of regulations, you know... > those hundreds of pages we weren't allowed to see before the vote... anyone > know if that is available to the public now? If so, where? > > Rob McEwen > > > > On Fri, Feb 27, 2015 at 9:10 AM, Scott Fisher > wrote: > >> Funny, but in my honest opinion, unprofessional. Poor PR. >> >> On Fri, Feb 27, 2015 at 9:05 AM, Larry Sheldon >> wrote: >> >>> http://publicpolicy.verizon.com/blog/entry/fccs-throwback- >>> thursday-move-imposes-1930s-rules-on-the-internet >>> >> > From jbates at paradoxnetworks.net Fri Feb 27 15:09:58 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Fri, 27 Feb 2015 09:09:58 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <15061035.7281.1425048878122.JavaMail.mhammett@ThunderFuck> References: <15061035.7281.1425048878122.JavaMail.mhammett@ThunderFuck> Message-ID: <54F088C6.5060003@paradoxnetworks.net> On 2/27/2015 8:55 AM, Mike Hammett wrote: > They won't be available for days, weeks, months, etc. After the vote, they are subject to editorial review... which isn't so much editorial as whatever the hell they want. They could just be literally adding commas and capitalizing letters to completely changing the language of something. > > Whenever that day comes... > > > I'm curious if the changes will effect the small ISPs concerning things like CALEA. On the other hand, I hope they ban the ability to pay for ESPN3 at an ISP level. I'm tired of the complaints from ISPs who can't get it and I'm tired of paying a portion of other people's access to it. Jack From michael.holstein at csuohio.edu Fri Feb 27 15:12:21 2015 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Fri, 27 Feb 2015 15:12:21 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com>, Message-ID: <1425050148370.97723@csuohio.edu> > I think Verizon's statement was brilliant, and entirely appropriate. Some > people are going to have a hard time discovering that being in favor of > Obama's version of "net neutrality"... will soon be just about as cool as > having supported SOPA. Morse code is just a different binary encoding. Also, commercial AM broadcasting started in the 20s, a couple decades past Marconi. Just think of all that innovation and investment that's been "stifled" over the last 50 years under Title II. Anyone remember having to "rent" their rotary phones from AT&T? -Mike. From bob at FiberInternetCenter.com Fri Feb 27 15:21:05 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 27 Feb 2015 07:21:05 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <1425050148370.97723@csuohio.edu> References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com>, <1425050148370.97723@csuohio.edu> Message-ID: <3a254bf25e26904f9b792f218ae66ab0.squirrel@66.201.44.180> > Just think of all that innovation and investment that's been "stifled" > over the last 50 years under Title II. > Anyone remember having to "rent" their rotary phones from AT&T? Yes, I am that old. You were not allowed to connect a phone of your own. Bob Evans CTO From mfidelman at meetinghouse.net Fri Feb 27 15:26:56 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 27 Feb 2015 10:26:56 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <3a254bf25e26904f9b792f218ae66ab0.squirrel@66.201.44.180> References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com>, <1425050148370.97723@csuohio.edu> <3a254bf25e26904f9b792f218ae66ab0.squirrel@66.201.44.180> Message-ID: <54F08CC0.5050109@meetinghouse.net> Bob Evans wrote: > >> Just think of all that innovation and investment that's been "stifled" >> over the last 50 years under Title II. >> Anyone remember having to "rent" their rotary phones from AT&T? > Yes, I am that old. You were not allowed to connect a phone of your own. > Let's also remember that it was regulatory action that enabled us to connect modems and phones to AT&T's network. (Can you say "Carterphone" decision) And it was Title II regulation, and the Computer Inquiries, that allowed the Internet to be assembled from circuits leased from AT&T long lines. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From littlefishguy at gmail.com Fri Feb 27 15:56:51 2015 From: littlefishguy at gmail.com (Scott Fisher) Date: Fri, 27 Feb 2015 10:56:51 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F08428.4000705@invaluement.com> References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com> Message-ID: I am not arguing that they have a valid complaint. I just think their method of doing so is a bit childish. It does get the point across, just not in the method I respect. Just my opinion though. On Fri, Feb 27, 2015 at 9:50 AM, Rob McEwen wrote: > Scott Fisher, > > I think Verizon's statement was brilliant, and entirely appropriate. Some > people are going to have a hard time discovering that being in favor of > Obama's version of "net neutrality"... will soon be just about as cool as > having supported SOPA. > > btw - does anyone know if that thick book of regulations, you know... those > hundreds of pages we weren't allowed to see before the vote... anyone know > if that is available to the public now? If so, where? > > Rob McEwen > > > > On Fri, Feb 27, 2015 at 9:10 AM, Scott Fisher > wrote: >> >> Funny, but in my honest opinion, unprofessional. Poor PR. >> >> On Fri, Feb 27, 2015 at 9:05 AM, Larry Sheldon >> wrote: >>> >>> >>> http://publicpolicy.verizon.com/blog/entry/fccs-throwback-thursday-move-imposes-1930s-rules-on-the-internet > > -- Scott From mfidelman at meetinghouse.net Fri Feb 27 16:04:31 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 27 Feb 2015 11:04:31 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com> Message-ID: <54F0958F.7070105@meetinghouse.net> I'd think they'd be better off with some jujitsu, along the lines of: "We've always practiced network neutrality, not like some of our competitors, this won't effect us at all and may enforce some good business practices on others" (As far as I can tell, Verizon has not played games with favoring their own content - for all intents and purposes, they operate FIOS as a common carrier - no funny throttling, no usage caps, etc.) I'm surprised they weren't a bit more vocal on the OTHER FCC decision of the day - preempting some state restrictions on municipal broadband builds - Verizon has been very active in pushing state laws to kill muni networks (even in places where they have no intention of building out). Miles Fidelman Scott Fisher wrote: > I am not arguing that they have a valid complaint. I just think their > method of doing so is a bit childish. It does get the point across, > just not in the method I respect. Just my opinion though. > > On Fri, Feb 27, 2015 at 9:50 AM, Rob McEwen wrote: >> Scott Fisher, >> >> I think Verizon's statement was brilliant, and entirely appropriate. Some >> people are going to have a hard time discovering that being in favor of >> Obama's version of "net neutrality"... will soon be just about as cool as >> having supported SOPA. >> >> btw - does anyone know if that thick book of regulations, you know... those >> hundreds of pages we weren't allowed to see before the vote... anyone know >> if that is available to the public now? If so, where? >> >> Rob McEwen >> >> >> >> On Fri, Feb 27, 2015 at 9:10 AM, Scott Fisher >> wrote: >>> Funny, but in my honest opinion, unprofessional. Poor PR. >>> >>> On Fri, Feb 27, 2015 at 9:05 AM, Larry Sheldon >>> wrote: >>>> >>>> http://publicpolicy.verizon.com/blog/entry/fccs-throwback-thursday-move-imposes-1930s-rules-on-the-internet >> > > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From stephen.carter at gltgc.org Fri Feb 27 16:07:18 2015 From: stephen.carter at gltgc.org (Stephen R. Carter) Date: Fri, 27 Feb 2015 16:07:18 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0958F.7070105@meetinghouse.net> References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com> <54F0958F.7070105@meetinghouse.net> Message-ID: The funniest thing about Verizon complaining about Title II, is that they used Title II to roll out their FIOS FTTP. I really am unsure of what they expected the outcome to be, and further proves the point of how big of a mess ISP¹s in this country are. Stephen Carter | IT Systems Administrator | Gun Lake Tribal Gaming Commission 1123 129th Avenue, Wayland, MI 49348 Phone 269.792.1773 On 2/27/15, 11:04 AM, "Miles Fidelman" wrote: >I'd think they'd be better off with some jujitsu, along the lines of: > >"We've always practiced network neutrality, not like some of our >competitors, this won't effect us at all and may enforce some good >business practices on others" > >(As far as I can tell, Verizon has not played games with favoring their >own content - for all intents and purposes, they operate FIOS as a >common carrier - no funny throttling, no usage caps, etc.) > >I'm surprised they weren't a bit more vocal on the OTHER FCC decision of >the day - preempting some state restrictions on municipal broadband >builds - Verizon has been very active in pushing state laws to kill muni >networks (even in places where they have no intention of building out). > >Miles Fidelman > >Scott Fisher wrote: >> I am not arguing that they have a valid complaint. I just think their >> method of doing so is a bit childish. It does get the point across, >> just not in the method I respect. Just my opinion though. >> >> On Fri, Feb 27, 2015 at 9:50 AM, Rob McEwen wrote: >>> Scott Fisher, >>> >>> I think Verizon's statement was brilliant, and entirely appropriate. >>>Some >>> people are going to have a hard time discovering that being in favor of >>> Obama's version of "net neutrality"... will soon be just about as cool >>>as >>> having supported SOPA. >>> >>> btw - does anyone know if that thick book of regulations, you know... >>>those >>> hundreds of pages we weren't allowed to see before the vote... anyone >>>know >>> if that is available to the public now? If so, where? >>> >>> Rob McEwen >>> >>> >>> >>> On Fri, Feb 27, 2015 at 9:10 AM, Scott Fisher >>> wrote: >>>> Funny, but in my honest opinion, unprofessional. Poor PR. >>>> >>>> On Fri, Feb 27, 2015 at 9:05 AM, Larry Sheldon >>>> wrote: >>>>> >>>>> >>>>>http://publicpolicy.verizon.com/blog/entry/fccs-throwback-thursday-mov >>>>>e-imposes-1930s-rules-on-the-internet >>> >> >> > > >-- >In theory, there is no difference between theory and practice. >In practice, there is. .... Yogi Berra >

The information contained in this electronic transmission (email) is confidential information and may be subject to attorney/client privilege. It is intended only for the use of the individual or entity named above. ANY DISTRIBUTION OR COPYING OF THIS MESSAGE IS PROHIBITED, except by the intended recipient. Attempts to intercept this message are in violation of 18 U.S.C. 2511(1) of the Electronic Communications Privacy Act (ECPA), which subjects the interceptor to fines, imprisonment and/or civil damages. From list at satchell.net Fri Feb 27 16:09:47 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 27 Feb 2015 08:09:47 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F08428.4000705@invaluement.com> References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com> Message-ID: <54F096CB.6000903@satchell.net> On 02/27/2015 06:50 AM, Rob McEwen wrote: > btw - does anyone know if that thick book of regulations, you know... > those hundreds of pages we weren't allowed to see before the vote... > anyone know if that is available to the public now? If so, where? It was in the FCC story: the rules (that thick book) will be published AFTER all the Commissoners have had a chance to write their pair-o-penny's worth and include their screeds with said publication. In other words, we have a month or two of quiet before the fur really starts to fly. From list at satchell.net Fri Feb 27 16:11:45 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 27 Feb 2015 08:11:45 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F079AC.8020103@cox.net> References: <54F079AC.8020103@cox.net> Message-ID: <54F09741.50806@satchell.net> On 02/27/2015 06:05 AM, Larry Sheldon wrote: > http://publicpolicy.verizon.com/blog/entry/fccs-throwback-thursday-move-imposes-1930s-rules-on-the-internet > OK. The Morse code I knew about, from news stories. What I didn't know is that the "translation" would be PDF of 1930s-style typewritten transcription on an old Underwood Portable that had seen much, much better days. Someone at Verizon is trying to make lemonade out of what they perceive as bitter, bitter lemons... From joe at nethead.com Fri Feb 27 16:12:57 2015 From: joe at nethead.com (Joe Hamelin) Date: Fri, 27 Feb 2015 08:12:57 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <3a254bf25e26904f9b792f218ae66ab0.squirrel@66.201.44.180> References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com> <1425050148370.97723@csuohio.edu> <3a254bf25e26904f9b792f218ae66ab0.squirrel@66.201.44.180> Message-ID: On Fri, Feb 27, 2015 at 7:21 AM, Bob Evans wrote: > > Yes, I am that old. You were not allowed to connect a phone of your own. But that didn't stop most of us old timers on this list. The first "digital" circuit that I played with as a kid was an old Strowger switch pulled from a junk yard. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From list at satchell.net Fri Feb 27 16:13:45 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 27 Feb 2015 08:13:45 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F088C6.5060003@paradoxnetworks.net> References: <15061035.7281.1425048878122.JavaMail.mhammett@ThunderFuck> <54F088C6.5060003@paradoxnetworks.net> Message-ID: <54F097B9.4060004@satchell.net> On 02/27/2015 07:09 AM, Jack Bates wrote: > I'm curious if the changes will effect the small ISPs concerning things > like CALEA. The first indications of any changes would be Cisco and Juniper announcing CALEA products in their low- and mid-line network products. Or there may be some near-startups that announce bolt-on network products to provide CALEA capability for those people who don't have deep pockets for new gear. From list at satchell.net Fri Feb 27 16:16:06 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 27 Feb 2015 08:16:06 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <3a254bf25e26904f9b792f218ae66ab0.squirrel@66.201.44.180> References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com>, <1425050148370.97723@csuohio.edu> <3a254bf25e26904f9b792f218ae66ab0.squirrel@66.201.44.180> Message-ID: <54F09846.1090804@satchell.net> On 02/27/2015 07:21 AM, Bob Evans wrote: > > >> Just think of all that innovation and investment that's been "stifled" >> over the last 50 years under Title II. >> Anyone remember having to "rent" their rotary phones from AT&T? > > Yes, I am that old. You were not allowed to connect a phone of your own. > Bob Evans > CTO > I still have a WeCo desk set that is marked "Bell System Property / Not For Sale" Carterfone, anyone? From yardiel at gmail.com Fri Feb 27 16:16:15 2015 From: yardiel at gmail.com (Yardiel D. Fuentes) Date: Fri, 27 Feb 2015 11:16:15 -0500 Subject: Last-call DoS/DoS Attack BCOP In-Reply-To: References: Message-ID: <88F2A9A6-1B7C-4B6E-BD79-390945C48B1E@gmail.com> Hello NANOGers, Following up on the below effort from last year, the DDoS/DoS Attack BCOP Draft document is ready for the last call 2-week period. After this period and unless notable objections are raised, the current document will be ratified as such. The current document can be found in the NANOG BCOP site -- link to current document found below: http://bcop.nanog.org/index.php/BCOP_Drafts Any additional community-wide comments or feedback in order to ensure quality documentation are not only very welcome but encouraged. Cheers, Yardiel Fuentes On Jul 2, 2014, at 6:48 PM, Yardiel D. Fuentes wrote: > > > OK NANOGers, > > Some of us got the call to arms from Chris G email below and the NANOG BCOP Committee and now we are interested in generating DoS attack-related Best Common Practices (BCOP) appeal to serve the entire NANOG community. > > This document, as other BCOP appeals are expected to be as brief as possible and to the point in order to keep it practical and useful. > > The goal is to generate a set of best practices of what to do before/during/after a DoS/DDoS attack -- including what seems to have worked best and what hasn't. Time dedicated to this effort should extensive and participation can be non-real-time given that it can be done over email with no need for conference calls if desired. > > DoS and DDoS attacks have been a topic that have captured high interest from NANOGers based on the archived list topics and email threads. So, now is your time to help shape a NANOG BCOP Appeal on this topic. > > Please contact me off-list if you want participate by either sharing your experience, expertise or opinions towards generating a DoS Attack BCOP. > > > Yardiel Fuentes > yardiel at gmail.com > twitter: #techguane > > > > On Jun 1, 2014, at 5:25 PM, Chris Grundemann wrote: > >> Hail NANOGers! >> >> As most of you hopefully know, NANOG now has a BCOP Ad Hoc Committee >> and we are pushing forward with new BCOPs! >> http://nanog.org/governance/bcop >> >> We currently have three BCOPs in active development: >> >> eBGP configuration, shepherd Bill Armstrong >> Public Peering Exchange update, shepherd Shawn Hsiao >> Ethernet OAM, shepherd Mark Calkins >> >> All three of these nascent BCOPs will be presented in the BCOP Track >> on Monday: http://nanog.org/meetings/abstract?id=2348 >> >> We have also collected a list of Appeals (BCOPs that need to be >> written): http://bcop.nanog.org/index.php/Appeals >> >> If you would like to help out with any of these BCOPs (or others yet >> to be identified) please join the BCOP mailing list and reach out to >> the shepherd (if applicable of course): >> http://mailman.nanog.org/mailman/listinfo/bcop >> >> Our committee is brand new and we are still finding and smoothing >> wrinkles, etc. We would love your help in any capacity. As a BCOP >> shepherd or SME or just to point out potential pit falls or room for >> improvement, with the process, the wiki, a BCOP or anything at all >> really. >> >> This is a bottom-up, community led effort and it will only succeed >> with your help - join us in creating what I believe will be a vital >> and long-lasting institution! >> >> Cheers, >> ~Chris >> >> -- >> @ChrisGrundemann >> http://chrisgrundemann.com > From rob at invaluement.com Fri Feb 27 16:18:37 2015 From: rob at invaluement.com (Rob McEwen) Date: Fri, 27 Feb 2015 11:18:37 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0958F.7070105@meetinghouse.net> References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com> <54F0958F.7070105@meetinghouse.net> Message-ID: <54F098DD.7020303@invaluement.com> On 2/27/2015 11:04 AM, Miles Fidelman wrote: > [VERISON should say...] this won't effect us at all Until those hundreds of pages are made public, how can anyone possibly know if that if that is even a truthful statement? Furthermore, what they SAY they intend to do with that authority... and what they COULD possibly do with such authority in the not-too-distant future... might be frighteningly different. FOR EXAMPLE... can I borrow your credit card? I'm just going to lock it in my safe and not use it until the next time we meet up again? (what I say I will do with it.. and what I COULD do with your credit card... could be frighteningly different!) But since we they did such a great job rolling out Obamacare with no "unintended consequences", I'm sure their promises and good intentions for their use of the authority over the packets moving across PRIVATELY-OWNED internet infrastructure... that they just voted themselves... will be just peachy, right? BTW - you should see my seashell collection... I keep it spread thoughout all the beaches of the entire world. Yesterday, I voted myself ownership over all of them. -- Rob McEwen From dmiller at tiggee.com Fri Feb 27 16:22:44 2015 From: dmiller at tiggee.com (David Miller) Date: Fri, 27 Feb 2015 11:22:44 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F096CB.6000903@satchell.net> References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com> <54F096CB.6000903@satchell.net> Message-ID: <54F099D4.9060102@tiggee.com> This PR reminds me of a story I heard about a few telegraph operators in the early 1930s. Mr. Nathan 'Nat' Flax and Mr. Hu Toob were telegraph operators for the mighty VerizonTelegraph Corporation. Misters Flax and Toob were able, through natural abilities and long practice, able to send telegraph messages faster than any other operators. They could dance their telegraph keys so fast that other operators, with lesser skills, could not reliably receive their messages. The VerizonTelegraph Corporation could have upgraded the skills of all of their operators to be able to receive these messages and then advertise their faster telegraph transmission speeds as a benefit to their customers. However, facing no competitive pressure for faster telegraph transmission speeds, the VerizonTelegraph Corporation decided instead to gum up the keys of Flax and Toob using inferior oils, sand, and bubblegum. Thus telegraph transmission speeds were slowed and the VerizonTelegraph Corporation went on to be the most successful telegraph company in the land today. -DMM On 02/27/2015 11:09 AM, Stephen Satchell wrote: > On 02/27/2015 06:50 AM, Rob McEwen wrote: >> btw - does anyone know if that thick book of regulations, you know... >> those hundreds of pages we weren't allowed to see before the vote... >> anyone know if that is available to the public now? If so, where? > It was in the FCC story: the rules (that thick book) will be published > AFTER all the Commissoners have had a chance to write their > pair-o-penny's worth and include their screeds with said publication. > In other words, we have a month or two of quiet before the fur really > starts to fly. From bill at herrin.us Fri Feb 27 16:34:37 2015 From: bill at herrin.us (William Herrin) Date: Fri, 27 Feb 2015 11:34:37 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <1425050148370.97723@csuohio.edu> References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com> <1425050148370.97723@csuohio.edu> Message-ID: On Fri, Feb 27, 2015 at 10:12 AM, Michael O Holstein wrote: > Just think of all that innovation and investment that's been "stifled" over the last 50 years under Title II. > Anyone remember having to "rent" their rotary phones from AT&T? No, but I remember in the late '90s AT&T demanding I mail them back the rotary phones that my grandmother had rented for 30 years. The bigest telcos were the architects of their own grief on Net Neutrality. No one should feel sorry for them. On Fri, Feb 27, 2015 at 11:04 AM, Miles Fidelman wrote: > (As far as I can tell, Verizon has not played games with favoring their own > content - for all intents and purposes, they operate FIOS as a common > carrier - no funny throttling, no usage caps, etc.) Throttled Netflix to unusability while selling FIOS TV? Still have much of their settlement-free peering choked hard while "paid peering" folks sail on by? Verizon is easily the worst offender. Regards, Bill "loving those 100ms pings" Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From wbn at drpeering.net Fri Feb 27 16:43:03 2015 From: wbn at drpeering.net (wbn) Date: Fri, 27 Feb 2015 08:43:03 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <3a254bf25e26904f9b792f218ae66ab0.squirrel@66.201.44.180> References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com> <, > <1425050148370.97723@csuohio.edu> <3a254bf25e26904f9b792f218ae66ab0.squirrel@66.201.44.180> Message-ID: <4873C051-3527-448C-822D-E280D621E4C8@drpeering.net> > On Feb 27, 2015, at 7:21 AM, Bob Evans wrote: > > > >> Just think of all that innovation and investment that's been "stifled" >> over the last 50 years under Title II. >> Anyone remember having to "rent" their rotary phones from AT&T? > > Yes, I am that old. You were not allowed to connect a phone of your own. Me too - I remember when my Dad got the nasty call from AT&T because he plugged in an unauthorized phone in the house - I guess they could tell from the additional resistance on the line. But the phone system worked pretty reliably back then - can’t say the same about today’s misc mash of systems. Anyway, back to the topic… this looks like most telecom debates: people latch onto one side or the other, the fight is in the context (problem statement and the definitions) but underneath it all there are actually reasonable perspectives on each side. Bill > Bob Evans > CTO > From nanog at ics-il.net Fri Feb 27 16:45:11 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 27 Feb 2015 10:45:11 -0600 (CST) Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: Message-ID: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> What about ISPs that aren't world-class dicks? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "William Herrin" Cc: "NANOG" Sent: Friday, February 27, 2015 10:34:37 AM Subject: Re: Verizon Policy Statement on Net Neutrality On Fri, Feb 27, 2015 at 10:12 AM, Michael O Holstein wrote: > Just think of all that innovation and investment that's been "stifled" over the last 50 years under Title II. > Anyone remember having to "rent" their rotary phones from AT&T? No, but I remember in the late '90s AT&T demanding I mail them back the rotary phones that my grandmother had rented for 30 years. The bigest telcos were the architects of their own grief on Net Neutrality. No one should feel sorry for them. On Fri, Feb 27, 2015 at 11:04 AM, Miles Fidelman wrote: > (As far as I can tell, Verizon has not played games with favoring their own > content - for all intents and purposes, they operate FIOS as a common > carrier - no funny throttling, no usage caps, etc.) Throttled Netflix to unusability while selling FIOS TV? Still have much of their settlement-free peering choked hard while "paid peering" folks sail on by? Verizon is easily the worst offender. Regards, Bill "loving those 100ms pings" Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From msa at latt.net Fri Feb 27 16:52:40 2015 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 27 Feb 2015 11:52:40 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> Message-ID: <20150227165240.GA13738@puck.nether.net> On Fri, Feb 27, 2015 at 10:45:11AM -0600, Mike Hammett wrote: > What about ISPs that aren't world-class dicks? The punishments will continue until they either fold or sell to the duopoly which is large enough to buy whatever act of Congress, court or FCC ruling they require... --msa From bhm at ufl.edu Fri Feb 27 17:03:35 2015 From: bhm at ufl.edu (Bruce H McIntosh) Date: Fri, 27 Feb 2015 12:03:35 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> Message-ID: <54F0A367.1020101@ufl.edu> On 2015-02-27 11:45, Mike Hammett wrote: > What about ISPs that aren't world-class dicks? > The REAL evil in the ISP marketplace is, of course, essentially entirely unremarked-upon - ASYMMETRY. For the Internet, as such, truly to live up to its promise to continue to revolutionize the world through free exchange of ideas, information, data and so forth, Joe Average User *MUST* have the same pipes going UP as he does coming DOWN. Just as an example, my service at home is what, 50 down/5 up? That structure is less conducive to free interchange and more conducive to the Big-Brother™-seal-of-approval mindless consumption of whatever content THEY™ deem necessary and sufficient to keep the bread and circus masses dull and uninvolved. Plus, the slow uplink speeds make remote backups dreadfully impractical for the home user. So let's see some symmetry in the offerings, ISPs, ok? -- ------------------------------------------------------------------------ Bruce H. McIntosh bhm at ufl.edu Senior Network Engineer http://net-services.ufl.edu University of Florida Network Services 352-273-1066 From lowen at pari.edu Fri Feb 27 17:05:18 2015 From: lowen at pari.edu (Lamar Owen) Date: Fri, 27 Feb 2015 12:05:18 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F079AC.8020103@cox.net> References: <54F079AC.8020103@cox.net> Message-ID: <54F0A3CE.4030800@pari.edu> On 02/27/2015 09:05 AM, Larry Sheldon wrote: > http://publicpolicy.verizon.com/blog/entry/fccs-throwback-thursday-move-imposes-1930s-rules-on-the-internet > Cute. Obviously they never watched the Leno segment where a pair of amateur radio ops using Morse code outperformed a couple of teens using texting, in terms of speed of communications. From Valdis.Kletnieks at vt.edu Fri Feb 27 17:05:52 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Feb 2015 12:05:52 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: Your message of "Fri, 27 Feb 2015 10:45:11 -0600." <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> Message-ID: <4820.1425056752@turing-police.cc.vt.edu> On Fri, 27 Feb 2015 10:45:11 -0600, Mike Hammett said: > What about ISPs that aren't world-class dicks? That's unfortunately a very YMMV problem. For instance, Comcast has (so far) provided the bandwidth I pay for, deployed very usable IPv6, not screwed up my bill, and the few times I've had to deal with their support structure it's gone amazingly smoothly. However, I'm told that other people have wildly divergent user experiences with them... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From nanog at ics-il.net Fri Feb 27 17:07:03 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 27 Feb 2015 11:07:03 -0600 (CST) Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0A367.1020101@ufl.edu> Message-ID: <11287607.8005.1425056798993.JavaMail.mhammett@ThunderFuck> More symmetry will happen when the home user does more things that care about symmetry. It's a simple allocation of spectrum (whether wireless, DSL or cable). MHz for upload are taken out of MHz for download. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Bruce H McIntosh" To: "NANOG" Sent: Friday, February 27, 2015 11:03:35 AM Subject: Re: Verizon Policy Statement on Net Neutrality On 2015-02-27 11:45, Mike Hammett wrote: > What about ISPs that aren't world-class dicks? > The REAL evil in the ISP marketplace is, of course, essentially entirely unremarked-upon - ASYMMETRY. For the Internet, as such, truly to live up to its promise to continue to revolutionize the world through free exchange of ideas, information, data and so forth, Joe Average User *MUST* have the same pipes going UP as he does coming DOWN. Just as an example, my service at home is what, 50 down/5 up? That structure is less conducive to free interchange and more conducive to the Big-Brother™-seal-of-approval mindless consumption of whatever content THEY™ deem necessary and sufficient to keep the bread and circus masses dull and uninvolved. Plus, the slow uplink speeds make remote backups dreadfully impractical for the home user. So let's see some symmetry in the offerings, ISPs, ok? -- ------------------------------------------------------------------------ Bruce H. McIntosh bhm at ufl.edu Senior Network Engineer http://net-services.ufl.edu University of Florida Network Services 352-273-1066 From Valdis.Kletnieks at vt.edu Fri Feb 27 17:13:36 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Feb 2015 12:13:36 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: Your message of "Fri, 27 Feb 2015 12:03:35 -0500." <54F0A367.1020101@ufl.edu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> Message-ID: <5221.1425057216@turing-police.cc.vt.edu> On Fri, 27 Feb 2015 12:03:35 -0500, Bruce H McIntosh said: > The REAL evil in the ISP marketplace is, of course, essentially entirely > unremarked-upon - ASYMMETRY. For the Internet, as such, truly to live > up to its promise to continue to revolutionize the world through free > exchange of ideas, information, data and so forth, Joe Average User > *MUST* have the same pipes going UP as he does coming DOWN. Just as an > example, my service at home is what, 50 down/5 up? That structure is > less conducive to free interchange Consider a group of 10 users, who all create new content. If each one creates at a constant rate of 5 mbits, they need 5 up. But to download all the new content from the other 9, they need close to 50 down. And when you expand to several billion people creating new content, you need a *huge* pipe down. Bottom line is that perfect symmetry isn't needed for content distribution - most people can't create content fast enough to clog their uplink, but have trouble picking and choosing what to downlink to fit in the available bandwidth. You'd be better off arguing from the basis of protocols and applications that need symmetric bandwidth (for instance, heavy use of Skype and similar, but with HD video - you'll need as big a pipe for your outbound video as you need for the inbound). Similar considerations will apply to at least some gaming models, bittorrent, and so on. You already noted the remote backup issue - keep focusing on that sort of thing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jbates at paradoxnetworks.net Fri Feb 27 17:15:24 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Fri, 27 Feb 2015 11:15:24 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0A367.1020101@ufl.edu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> Message-ID: <54F0A62C.70704@paradoxnetworks.net> On 2/27/2015 11:03 AM, Bruce H McIntosh wrote: > > The REAL evil in the ISP marketplace is, of course, essentially > entirely unremarked-upon - ASYMMETRY. For the Internet, as such, > truly to live up to its promise to continue to revolutionize the world > through free exchange of ideas, information, data and so forth, Joe > Average User *MUST* have the same pipes going UP as he does coming > DOWN. Just as an example, my service at home is what, 50 down/5 up? > That structure is less conducive to free interchange and more > conducive to the Big-Brother™-seal-of-approval mindless consumption of > whatever content THEY™ deem necessary and sufficient to keep the bread > and circus masses dull and uninvolved. Plus, the slow uplink speeds > make remote backups dreadfully impractical for the home user. So > let's see some symmetry in the offerings, ISPs, ok? > I'm all for this, except many technologies don't allow for it. Even if they did, you might see a lot less down in exchange for that upload. That may be fine for some, but would be undesired by others. I laugh every time I see a billboard locally that says, "Enjoy your free speed upgrade". They switched all their customers from ADSL to ADSL2 and gave them a slight download increase. Of course, ADSL2 has a slower upload limit. 500k may not seem a lot, but when you only had 1.5m to begin with, it's a considerable amount. From bill at herrin.us Fri Feb 27 17:18:07 2015 From: bill at herrin.us (William Herrin) Date: Fri, 27 Feb 2015 12:18:07 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> Message-ID: On Fri, Feb 27, 2015 at 11:45 AM, Mike Hammett wrote: > What about ISPs that aren't world-class dicks? They're still in business? In all seriousness though, that's a fair question. What are the downsides of Title II w/o tariffs for for ISPs who aren't engaging in Bad Behavior? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From khelms at zcorum.com Fri Feb 27 17:27:00 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 12:27:00 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0A62C.70704@paradoxnetworks.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <54F0A62C.70704@paradoxnetworks.net> Message-ID: Jack, I don't know what manufacturer you might be thinking of, but from a standards point of view ADSL2 and ADSL2+ both have faster upstream speeds than ADSL (G.dmt or T1.413) - ANSI T1.413 Issue 2 , up to 8 Mbit/s and 1 Mbit/s - G.dmt , ITU-T G.992.1, up to 10 Mbit/s and 1 Mbit/s - G.lite , ITU-T G.992.2, more noise and attenuation resistant than G.dmt, up to 1,536 kbit/s and 512 kbit/s - Asymmetric digital subscriber line 2 (ADSL2), ITU-T G.992.3, up to 12 Mbit/s and 3.5 Mbit/s - Asymmetric digital subscriber line 2 plus (ADSL2+), ITU-T G.992.5, up to 24 Mbit/s and 3.5 Mbit/s Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 12:15 PM, Jack Bates wrote: > On 2/27/2015 11:03 AM, Bruce H McIntosh wrote: > >> >> The REAL evil in the ISP marketplace is, of course, essentially entirely >> unremarked-upon - ASYMMETRY. For the Internet, as such, truly to live up >> to its promise to continue to revolutionize the world through free exchange >> of ideas, information, data and so forth, Joe Average User *MUST* have the >> same pipes going UP as he does coming DOWN. Just as an example, my service >> at home is what, 50 down/5 up? That structure is less conducive to free >> interchange and more conducive to the Big-Brother™-seal-of-approval >> mindless consumption of whatever content THEY™ deem necessary and >> sufficient to keep the bread and circus masses dull and uninvolved. Plus, >> the slow uplink speeds make remote backups dreadfully impractical for the >> home user. So let's see some symmetry in the offerings, ISPs, ok? >> >> > I'm all for this, except many technologies don't allow for it. Even if > they did, you might see a lot less down in exchange for that upload. That > may be fine for some, but would be undesired by others. > > I laugh every time I see a billboard locally that says, "Enjoy your free > speed upgrade". They switched all their customers from ADSL to ADSL2 and > gave them a slight download increase. Of course, ADSL2 has a slower upload > limit. 500k may not seem a lot, but when you only had 1.5m to begin with, > it's a considerable amount. > > From SNaslund at medline.com Fri Feb 27 17:27:08 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 27 Feb 2015 17:27:08 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0A367.1020101@ufl.edu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> That statement completely confuses me. Why is asymmetry evil? Does that not reflect what "Joe Average User" actually needs and wants? The statement that the average users *MUST* have the same pipes going UP as he does going DOWN does not reflect reality at all. Do a lot of your users want to stream 4K video to their friends UHD TV? Given that all transmission media has some sort of bandwidth limit it would seem to me that asymmetry is actually more fair for the user since he gets more of what he needs which is download speed. There is no technical reason that it can't be symmetric it is just a reflection of what the market wants. As an ISP I can tell you that a lot more people complaint about their download speeds than their upload speeds. Do you think that you (or the average home user) would be happier with 27.5 down and 27.5 up vs your 50 down and 5 up you have today? Don't tell me you want 50 down and 50 up because that is a different bandwidth total that requires a faster transmission media. Do you actually believe that average users are suffering with a 5 mbps upstream? I don't. I just don't see the average user "freely interchanging ideas" at more than 5 mbps. I don't feel like "Big Brother" forced me to watch Netflix and my next door neighbor just doesn't provide a lot of engaging HD content that I just must see. By the way, most carriers have plenty of symmetric offerings, it is just that they are marketed as business class not because we are evil but because that is the normal usage case. Remember that most offerings were symmetric up until DSL became available which allowed us to provide the faster downloads users actually wanted. Modems and TDM circuits were symmetric and everyone hated the fact that all this upstream went unused while people longed for better download speeds. Actually if the traffic patterns were actually more symmetric, the carriers would be happier because it would create a much more any-to-any flow and this net neutrality garbage would never have been an issue. In the real world, there are actually a handful of sites pushing tons of bandwidth in one direction to a lot of users. That is what it is until "Joe Average User" starts creating engaging content. >The REAL evil in the ISP marketplace is, of course, essentially entirely unremarked-upon - ASYMMETRY. For the Internet, as >such, truly to live up to its promise to continue to revolutionize the world through free exchange of ideas, information, >data and so forth, Joe Average User >*MUST* have the same pipes going UP as he does coming DOWN. Just as an example, my service at home is what, 50 down/5 up? >That structure is less conducive to free interchange and more conducive to the Big-Brother™-seal-of-approval mindless >consumption of whatever content THEY™ deem necessary and sufficient to keep the bread and circus masses dull and uninvolved. >Plus, the slow uplink speeds make remote backups dreadfully impractical for the home user. So let's see some symmetry in the >offerings, ISPs, ok? Steven Naslund Chicago IL From SNaslund at medline.com Fri Feb 27 17:32:28 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 27 Feb 2015 17:32:28 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0A62C.70704@paradoxnetworks.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <54F0A62C.70704@paradoxnetworks.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725DE3A@MUNPRDMBXA1.medline.com> Actually most users would perceive a download increase as a speed upgrade because they are not hitting the performance limits of the upstream. In the DSL world, there is a maximum reliable speed attainable due to the physics involved in high speed transmission over copper. More speed in one direction will definitely cause a corresponding decrease in the other direction, this is not a "maybe" this is a fact. If a DSL circuit is capable of 10 mbps total bandwidth you can slice the direction any way you want as long as it totals 10 mbps. Users want more download in general. >I'm all for this, except many technologies don't allow for it. Even if they did, you might see a lot less down in exchange for that upload. >That may be fine for some, but would be undesired by others. >I laugh every time I see a billboard locally that says, "Enjoy your free speed upgrade". They switched all their customers from ADSL to ADSL2 and gave them a slight download increase. Of course, ADSL2 has a slower upload limit. 500k >may not seem a lot, but when you only had 1.5m to begin with, it's a considerable amount. Steven Naslund Chicago IL From bhm at ufl.edu Fri Feb 27 17:34:26 2015 From: bhm at ufl.edu (Bruce H McIntosh) Date: Fri, 27 Feb 2015 12:34:26 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <5221.1425057216@turing-police.cc.vt.edu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> Message-ID: <54F0AAA2.20700@ufl.edu> On 2015-02-27 12:13, Valdis.Kletnieks at vt.edu wrote: > Consider a group of 10 users, who all create new content. If each one > creates at a constant rate of 5 mbits, they need 5 up. But to download > all the new content from the other 9, they need close to 50 down. > > And when you expand to several billion people creating new content, you need > a *huge* pipe down. Ok, I hadn't thought about it from that perspective. The scenario you laid out does make sense. > You'd be better off arguing from the basis of protocols and applications that > need symmetric bandwidth (for instance, heavy use of Skype and similar, but > with HD video - you'll need as big a pipe for your outbound video as you need > for the inbound). Similar considerations will apply to at least some gaming > models, bittorrent, and so on. You already noted the remote backup issue - keep > focusing on that sort of thing. Remote backup is the big bugaboo for me, having had 2 SSDs and a couple spinny platters eat themselves in the last year or so. It's a really irksome situation when I can, e.g. backup my entire work machine's /home partition to my home server in, say, X hours, but to back my home workstation's /home partition (a similar amount of cruft) up to the TSM server at work takes 10-15X hours, it makes backing up the home machine remotely (something the wife harps on incessantly after the crashes of last summer :) ) pretty impractical. And yes, I know what "incremental backups" are (TSM, remember? :) ) but jumpstarting that first full backup is a stumbling block to the whole scenario. *sigh* -- ------------------------------------------------------------------------ Bruce H. McIntosh bhm at ufl.edu Senior Network Engineer http://net-services.ufl.edu University of Florida Network Services 352-273-1066 From bhm at ufl.edu Fri Feb 27 17:37:10 2015 From: bhm at ufl.edu (Bruce H McIntosh) Date: Fri, 27 Feb 2015 12:37:10 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> Message-ID: <54F0AB46.3070707@ufl.edu> On 2015-02-27 12:27, Naslund, Steve wrote: > That statement completely confuses me. Why is asymmetry evil? Does that not reflect what "Joe Average User" actually needs and wants? The statement that the average users *MUST* have the same pipes going UP as he does going DOWN does not reflect reality at all. Do a lot of your users want to stream 4K video to their friends UHD TV? Given that all transmission media has some sort of bandwidth limit it would seem to me that asymmetry is actually more fair for the user since he gets more of what he needs which is download speed. There is no technical reason that it can't be symmetric it is just a reflection of what the market wants. As an ISP I can tell you that a lot more people complaint about their download speeds than their upload speeds. Do you think that you (or the average home user) would be happier with 27.5 down and 27.5 up vs your 50 down and 5 up you have today? Don't tell me you want 50 down and 50 up because that is a different bandwidth total that requi! res a fast er transmission media. > > Do you actually believe that average users are suffering with a 5 mbps upstream? I don't. I just don't see the average user "freely interchanging ideas" at more than 5 mbps. I don't feel like "Big Brother" forced me to watch Netflix and my next door neighbor just doesn't provide a lot of engaging HD content that I just must see. > I guess I know more than the "average" number of creative types who might be interested in things like video collaboration, music/video recording, sharing around large hunks of content to edit/modify/etc., and of course my previously mentioned hobby horse, backing it all up in a timely manner to someplace maybe not in the path of seasonal hurricanes :). -- ------------------------------------------------------------------------ Bruce H. McIntosh bhm at ufl.edu Senior Network Engineer http://net-services.ufl.edu University of Florida Network Services 352-273-1066 From davidbass570 at gmail.com Fri Feb 27 17:38:07 2015 From: davidbass570 at gmail.com (David Bass) Date: Fri, 27 Feb 2015 11:38:07 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <4820.1425056752@turing-police.cc.vt.edu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <4820.1425056752@turing-police.cc.vt.edu> Message-ID: <3442C27F-0B0B-42D3-BB54-E10DAACAE7DE@gmail.com> Let's not discuss Comcast and its performance in the customer service department so not to completely sidetrack the discussion... Sent from my iPhone > On Feb 27, 2015, at 11:05 AM, Valdis.Kletnieks at vt.edu wrote: > > On Fri, 27 Feb 2015 10:45:11 -0600, Mike Hammett said: >> What about ISPs that aren't world-class dicks? > > That's unfortunately a very YMMV problem. For instance, Comcast has (so far) > provided the bandwidth I pay for, deployed very usable IPv6, not screwed up my > bill, and the few times I've had to deal with their support structure it's gone > amazingly smoothly. However, I'm told that other people have wildly divergent > user experiences with them... :) > From SNaslund at medline.com Fri Feb 27 17:40:53 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 27 Feb 2015 17:40:53 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <54F0A62C.70704@paradoxnetworks.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725DE54@MUNPRDMBXA1.medline.com> These standards are for the interoperability of the equipment between vendors. There is no technical reason that you could not have one particular speed in one direction and any other speed in the opposite direction as long as you do not exceed the total bandwidth potential of the loop. In fact, in the pre-standards days of DSL we could dial up any speed you wanted in either direction (because the DSLAM and CPE were from the same manufacturer). In this case, the standard reflects what the customer wants, not a technical limitation. If people want a different ratio of up to downlink speed it could certainly be done. ADSL is by definition asymmetric. We also sold SDSL which is symmetric service and the primary buyers were generally businesses. See G.SHDSL if you want a standard for symmetric DSL. It's there, it is just not a popular. Steven Naslund Chicago IL >Jack, > >I don't know what manufacturer you might be thinking of, but from a standards point of view ADSL2 and ADSL2+ both have faster upstream speeds than ADSL (G.dmt or T1.413) > - ANSI T1.413 Issue 2 , > up to 8 Mbit/s and 1 Mbit/s > - G.dmt , ITU-T G.992.1, up to > 10 Mbit/s and 1 Mbit/s > - G.lite , ITU-T G.992.2, more > noise and attenuation resistant than G.dmt, up to 1,536 kbit/s and > 512 kbit/s > - Asymmetric digital subscriber line 2 > (ADSL2), > ITU-T G.992.3, up to 12 Mbit/s and 3.5 Mbit/s > - Asymmetric digital subscriber line 2 plus > >(ADSL2+), > ITU-T G.992.5, up to 24 Mbit/s and 3.5 Mbit/s From larrysheldon at cox.net Fri Feb 27 17:44:28 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 27 Feb 2015 11:44:28 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com> <, > <1425050148370.97723@csuohio.edu> <3a254bf25e26904f9b792f218ae66ab0.squirrel@66.201.44.180> Message-ID: <54F0ACFC.3020300@cox.net> On 2/27/2015 10:43, wbn wrote: > >> On Feb 27, 2015, at 7:21 AM, Bob Evans >> wrote: >> >> >> >>> Just think of all that innovation and investment that's been >>> "stifled" over the last 50 years under Title II. Anyone remember >>> having to "rent" their rotary phones from AT&T? >> >> Yes, I am that old. You were not allowed to connect a phone of your >> own. > > Me too - I remember when my Dad got the nasty call from AT&T because > he plugged in an unauthorized phone in the house - I guess they could > tell from the additional resistance on the line. But the phone system > worked pretty reliably back then - can’t say the same about today’s > misc mash of systems. We could could the number of ringers. > > Anyway, back to the topic… this looks like most telecom debates: > people latch onto one side or the other, the fight is in the context > (problem statement and the definitions) but underneath it all there > are actually reasonable perspectives on each side. "reasonable perspectives" are dependent on "side"--not many will be from MY side. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From SNaslund at medline.com Fri Feb 27 17:48:36 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 27 Feb 2015 17:48:36 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0AAA2.20700@ufl.edu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> How about this? Show me 10 users in the average neighborhood creating content at 5 mbps....Period. Only realistic app I see is home surveillance but I don't think you want everyone accessing that anyway. The truth is that the average user does not create content that anyone needs to see. This has not changed throughout the ages, the ratio of authors to readers, artists to art lovers, musicians to music lovers, YouTube cat video creator to cat video lovers, has never been a many to many relationship. On 2015-02-27 12:13, Valdis.Kletnieks at vt.edu wrote: > Consider a group of 10 users, who all create new content. If each one > creates at a constant rate of 5 mbits, they need 5 up. But to > download all the new content from the other 9, they need close to 50 down. > > And when you expand to several billion people creating new content, > you need a *huge* pipe down. Steven Naslund Chicago IL From stephen at sprunk.org Fri Feb 27 17:49:47 2015 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 27 Feb 2015 11:49:47 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <20150227165240.GA13738@puck.nether.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <20150227165240.GA13738@puck.nether.net> Message-ID: <54F0AE3B.2010209@sprunk.org> On 27-Feb-15 10:52, Majdi S. Abbas wrote: > On Fri, Feb 27, 2015 at 10:45:11AM -0600, Mike Hammett wrote: >> What about ISPs that aren't world-class dicks? > > The punishments will continue until they either fold or sell to the > duopoly which is large enough to buy whatever act of Congress, court > or FCC ruling they require... This case seems to prove that the telco/cable duopoly can't _always_ buy the FCC rulings they desire; every now and then, the US govt surprises us and actually represents the people. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2394 bytes Desc: S/MIME Cryptographic Signature URL: From jbates at paradoxnetworks.net Fri Feb 27 17:49:57 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Fri, 27 Feb 2015 11:49:57 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <54F0A62C.70704@paradoxnetworks.net> Message-ID: <54F0AE45.3070902@paradoxnetworks.net> On 2/27/2015 11:27 AM, Scott Helms wrote: > Jack, > > I don't know what manufacturer you might be thinking of, but from a > standards point of view ADSL2 and ADSL2+ both have faster upstream > speeds than ADSL (G.dmt or T1.413) > > Oh, standards wise, that is true. However, the gear they had (AFC) supported 8/1.5 for ADSL and I think 24/1 for ADSL2+. My point wasn't about standards, but an actual event. There is a perception that faster download is an upgrade, even if your upload is reduced. For the most part, they were right. Only a small percentage of the customers were upset at the upload decrease. The kicker was, the max downlink speed they allowed was 10. If they could have supported the right annex, they could have had more upload. Vendor limitations and such. :( Jack From jfesler at gigo.com Fri Feb 27 17:56:50 2015 From: jfesler at gigo.com (Jason Fesler) Date: Fri, 27 Feb 2015 09:56:50 -0800 Subject: L2 devices can break PMTUD Message-ID: I've come across two service providers in the last couple of weeks that have had issues with L2 devices eating IPv6 PMTUD packets. I am allowed to share some of the information from one of those service providers here. $ISP contacted me to ask more about why PMTUD was being reported as broken on Android, Linux, Mac - but not being reported on Windows. After some back and forth I was able to get $ISP to prove that ICMPv6 Packet Too Big messages were not making it to the client. Windows just happens to work around this issue. Ultimately, they narrowed it down to be the access switch. They set one up in a lab, and sure enough, they could reproduce the problem and actually capture packets upstream and downstream of it. Device in question: Calix E7-2 and E7-20. To the vendor's credit, Calix started investigating immediately. Within a business week they were able to confirm it was a bug and told the $ISP that the next maintenance release should have the fix. Last comment from $ISP: "I’m not sure if I shared with you that the issue did not occur if the VLAN was configured as a “TLAN” (transparent LAN). Of course, in the VLAN per service model (1:N) that isn’t set because you don’t’ want everyone flooding their broadcast and multicast traffic to everyone else." From bill at herrin.us Fri Feb 27 17:56:29 2015 From: bill at herrin.us (William Herrin) Date: Fri, 27 Feb 2015 12:56:29 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0A367.1020101@ufl.edu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> Message-ID: On Fri, Feb 27, 2015 at 12:03 PM, Bruce H McIntosh wrote: > The REAL evil in the ISP marketplace is, of course, essentially entirely > unremarked-upon - ASYMMETRY. Hi Bruce, We part ways there. I see nothing inherently wrong with asymmetric connections. I see nothing inherently wrong with whitelist-based services either: we'll sell you web access service, not general Internet service. I see nothing inherently wrong will selling measured-rate service: Gigabit port speed, $X/gigabyte prime time, free off prime. The idea that any particular Internet-related product must fit one specific mold like symmetry is abhorrent to me. BUT Deceit is Bad Behavior. If you sell me an X megabit per second Internet access service, you should do everything reasonably within your power to make sure I can access the Internet sites of my choice at X megabits per second. Monopoly abuse is Bad Behavior. Be it cross-subsidy (make competitive overbuilding impossible by covering infrastructure cost with funds from other high-margin products) product tying (that fiber optic channel is bundled with our version of Internet service alone) or double-billing (You, Mr. Disfavored Organization must pay for access to a customer base which has already paid us for access to you). These are the real evils in the ISP marketplace. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From lowen at pari.edu Fri Feb 27 17:58:29 2015 From: lowen at pari.edu (Lamar Owen) Date: Fri, 27 Feb 2015 12:58:29 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F08428.4000705@invaluement.com> References: <54F079AC.8020103@cox.net> Message-ID: <54F0B045.80409@pari.edu> On 02/27/2015 09:50 AM, Rob McEwen wrote: > btw - does anyone know if that thick book of regulations, you know... > those hundreds of pages we weren't allowed to see before the vote... > anyone know if that is available to the public now? If so, where? You were allowed to see the proposed rules in the NPRM's appendix A. The R&O will state which of those were adopted, which were reconsidered after reading the public comments, etc. Watch docket 14-28 and when the R&O (or MR&O maybe) is released you'll be able to read that. The R&O will contain a pointer to which section of 47CFR the rules will be in, and you can get those from multiple places. The easiest way is through eCFR (www.ecfr.gov), a part of the GPO, which publishes all these sorts of things. Now, the R&O isn't available yet, but the regs themselves are. Check out 47CFR§8.1-17, already available through the eCFR. Here's a link: http://www.ecfr.gov/cgi-bin/text-idx?SID=3f0ad879cf046fa8e4edd14261ef70f2&node=pt47.1.8&rgn=div5 That has got to be the smallest full section of 47CFR I've ever read..... From khelms at zcorum.com Fri Feb 27 17:59:09 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 12:59:09 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> Message-ID: This is true in our measurements today, even when subscribers are given symmetrical connections. It might change at some point in the future, especially when widespread IPv6 lets us get rid of NAT as a de facto deployment reality. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 12:48 PM, Naslund, Steve wrote: > How about this? Show me 10 users in the average neighborhood creating > content at 5 mbps....Period. Only realistic app I see is home surveillance > but I don't think you want everyone accessing that anyway. The truth is > that the average user does not create content that anyone needs to see. > This has not changed throughout the ages, the ratio of authors to readers, > artists to art lovers, musicians to music lovers, YouTube cat video creator > to cat video lovers, has never been a many to many relationship. > > On 2015-02-27 12:13, Valdis.Kletnieks at vt.edu wrote: > > Consider a group of 10 users, who all create new content. If each one > > creates at a constant rate of 5 mbits, they need 5 up. But to > > download all the new content from the other 9, they need close to 50 > down. > > > > And when you expand to several billion people creating new content, > > you need a *huge* pipe down. > > Steven Naslund > Chicago IL > > From jbates at paradoxnetworks.net Fri Feb 27 18:00:56 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Fri, 27 Feb 2015 12:00:56 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> Message-ID: <54F0B0D8.9080904@paradoxnetworks.net> On 2/27/2015 11:48 AM, Naslund, Steve wrote: > How about this? Show me 10 users in the average neighborhood creating content at 5 mbps....Period. Only realistic app I see is home surveillance but I don't think you want everyone accessing that anyway. The truth is that the average user does not create content that anyone needs to see. This has not changed throughout the ages, the ratio of authors to readers, artists to art lovers, musicians to music lovers, YouTube cat video creator to cat video lovers, has never been a many to many relationship. > > It is likely not to change when people don't have the available upload to begin with. This is compounded by the queue problems on end devices. How many more people would stream to twitch or youtube or skype if they didn't have to hear this, "Are you uploading? You're slowing down the download! I can't watch my movie!" Jack From SNaslund at medline.com Fri Feb 27 18:02:47 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 27 Feb 2015 18:02:47 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0AB46.3070707@ufl.edu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> <54F0AB46.3070707@ufl.edu> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725DEC0@MUNPRDMBXA1.medline.com> I think you may see more than average numbers of creative types at a university environment. Once you have a full time job you tend to have less time for "creative endeavors". I can say that having thousands of customers, the content producers are definitely a minority. I would even guess that most of your creative users still download more than they upload. It is simply math. A single person cannot create content as fast as they can consume it. The traffic is even becoming more asymmetric. You would have to create an awful lot of music and video collaboration and lots of documents to rival that 4K movie you want to watch. I can watch a movie every day without too much effort. I would be hard pressed to make that much music or content of my own. I am talking about real compelling content with value not an HD camera staring at a wall. Even backups are rarely an issue for the average user as long as their backup solution is intelligent enough to use bandwidth efficiently. Really, the average user's circuit is sitting idle most of the time in any case so if that backup takes all day to complete, no one cares. On this group we have to watch that we do not see ourselves as the "average user", we definitely are not. Bottom line is that symmetric technology is actually easier (and the original DSL technology which was mapping symmetric TDM channels onto copper loops), users just don't want to buy it in most cases. ADSL is what users want. >>I guess I know more than the "average" number of creative types who might be interested in things like video collaboration, music/video recording, sharing around large hunks of content to edit/modify/etc., and of course my >>previously mentioned hobby horse, backing it all up in a timely manner to someplace maybe not in the path of seasonal hurricanes :). Steven Naslund Chicago IL From bill at herrin.us Fri Feb 27 18:02:34 2015 From: bill at herrin.us (William Herrin) Date: Fri, 27 Feb 2015 13:02:34 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> Message-ID: On Fri, Feb 27, 2015 at 12:56 PM, William Herrin wrote: > double-billing (You, Mr. Disfavored Organization must pay for access > to a customer base which has already paid us for access to you). Imagine: We're sorry Mr. Homeowner, you do have a 200 amp electrical service but we limit power tool usage to 500 milliamps. We're in negotiation with Home Depot to increase that limit, so you should complain to them if you're unhappy. Surely you understand how unreasonable it is for Home Depot to sell you an electric drill and then pretend like we're supposed to provide you with electricity for it. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From khelms at zcorum.com Fri Feb 27 18:04:39 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 13:04:39 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0AE45.3070902@paradoxnetworks.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <54F0A62C.70704@paradoxnetworks.net> <54F0AE45.3070902@paradoxnetworks.net> Message-ID: AFC, the only shelf I worked on that would silently allow you to allocate so much bandwidth to the ADSL cards that voice wouldn't work.... Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 12:49 PM, Jack Bates wrote: > > On 2/27/2015 11:27 AM, Scott Helms wrote: > >> Jack, >> >> I don't know what manufacturer you might be thinking of, but from a >> standards point of view ADSL2 and ADSL2+ both have faster upstream speeds >> than ADSL (G.dmt or T1.413) >> >> >> > Oh, standards wise, that is true. However, the gear they had (AFC) > supported 8/1.5 for ADSL and I think 24/1 for ADSL2+. My point wasn't about > standards, but an actual event. There is a perception that faster download > is an upgrade, even if your upload is reduced. For the most part, they were > right. Only a small percentage of the customers were upset at the upload > decrease. > > The kicker was, the max downlink speed they allowed was 10. If they could > have supported the right annex, they could have had more upload. Vendor > limitations and such. :( > > > Jack > > From mfidelman at meetinghouse.net Fri Feb 27 18:04:59 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 27 Feb 2015 13:04:59 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> Message-ID: <54F0B1CB.4030808@meetinghouse.net> Naslund, Steve wrote: > That statement completely confuses me. Why is asymmetry evil? Does that not reflect what "Joe Average User" actually needs and wants? The statement that the average users *MUST* have the same pipes going UP as he does going DOWN does not reflect reality at all. Do a lot of your users want to stream 4K video to their friends UHD TV? Given that all transmission media has some sort of bandwidth limit it would seem to me that asymmetry is actually more fair for the user since he gets more of what he needs which is download speed. There is no technical reason that it can't be symmetric it is just a reflection of what the market wants. As an ISP I can tell you that a lot more people complaint about their download speeds than their upload speeds. Do you think that you (or the average home user) would be happier with 27.5 down and 27.5 up vs your 50 down and 5 up you have today? Don't tell me you want 50 down and 50 up because that is a different bandwidth total that requires a faster transmission media. > > Do you actually believe that average users are suffering with a 5 mbps upstream? I don't. I just don't see the average user "freely interchanging ideas" at more than 5 mbps. I don't feel like "Big Brother" forced me to watch Netflix and my next door neighbor just doesn't provide a lot of engaging HD content that I just must see. From a user point of view, it's not so much asymmetry as it is low peak upload speeds, which hurt you for things like: - network backup - video conferencing (NOT an argument for symmetry, though - your only sending your stream, you're receiving multiple streams) - uploading large files (5 minutes to upload the latest version of a report to the office, sending a large photo album or video of an event, particularly annoying, I expect to folks who shoot a lot of video Having said all that, has anyone else noticed that Verizon has been pushing symmetric bandwidth in their new FIOS plans? Not sure how well it's working though - a lot of the early deployment is BPON, which tops out at 155Mbps for uploads - theoretically, I have 25/25 service, but I've occasionally seen my uploads fall to 100kbps (yes that's a k). Highly intermittent though - Verizon's techs have been having lots of fun trying to track things down. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mel at beckman.org Fri Feb 27 18:06:47 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 27 Feb 2015 18:06:47 +0000 Subject: One FCC neutrality elephant: disabilities compliance Message-ID: http://www.fcc.gov/guides/telecommunications-access-people-disabilities http://www.fcc.gov/encyclopedia/title-iv-ada Section 255 of Title II applies to Internet providers now, as does section 225 of the Americans with Disabilities Act (ADA). These rules have such unbelievable broad statements as: "Accessibility and usability must be assessed for individual products and services. Accessibility features that can be incorporated into the design of products or services with very little or no difficulty or expense must be put in each and every product or service." "...require network architecture to be designed in a way that does not hinder access by people with disabilities. Network architecture covers the public switched telephone network, and includes hardware or software databases associated with routing telecommunications services." "Telecommunications service providers and equipment manufacturers must provide the FCC with the name and contact information of the person (or persons) in their companies who are authorized to resolve accessibility complaints." "Each common carrier providing telephone voice transmission services shall, not later than 3 years after July 26, 1990, provide in compliance with the regulations prescribed under this section, throughout the area in which it offers service, telecommunications relay services" "The term "telecommunications relay services" means telephone transmission services that provide the ability for an individual who has a hearing impairment or speech impairment to engage in communication by wire or radio with a hearing individual in a manner that is functionally equivalent to the ability of an individual who does not have a hearing impairment or speech impairment to communicate using voice communication services by wire or radio. Such term includes services that enable two-way communication between an individual who uses a TDD or other nonvoice terminal device and an individual who does not use such a device." Many news stories have been published about how ADA was exploited by scammers to extort money out of bricks-and-mortar businesses. Now these scams are coming to the ISP biz. http://www.adaabuse.com From mfidelman at meetinghouse.net Fri Feb 27 18:08:46 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 27 Feb 2015 13:08:46 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> Message-ID: <54F0B2AE.6030902@meetinghouse.net> Naslund, Steve wrote: > How about this? Show me 10 users in the average neighborhood creating content at 5 mbps....Period. Only realistic app I see is home surveillance but I don't think you want everyone accessing that anyway. The truth is that the average user does not create content that anyone needs to see. This has not changed throughout the ages, the ratio of authors to readers, artists to art lovers, musicians to music lovers, YouTube cat video creator to cat video lovers, has never been a many to many relationship. > > Hmm... my copy of crashplan is reporting 8mps of upload right now. Granted, that's not average, but it can be sustained for a while, whenever I shut down a virtual machine (Parallels on a Mac, the entire virtual image takes a while to back up - not all that uncommon). I also expect that most folks who buy a network backup service just use the default settings for when to do backups - which suggests an awful lot of backup traffic going on at the same time every night. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From bhm at ufl.edu Fri Feb 27 18:10:31 2015 From: bhm at ufl.edu (Bruce H McIntosh) Date: Fri, 27 Feb 2015 13:10:31 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0AE3B.2010209@sprunk.org> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <20150227165240.GA13738@puck.nether.net> <54F0AE3B.2010209@sprunk.org> Message-ID: <54F0B317.9060109@ufl.edu> On 2015-02-27 12:49, Stephen Sprunk wrote: > This case seems to prove that the telco/cable duopoly can't _always_ buy > the FCC rulings they desire; every now and then, the US govt surprises > us and actually represents the people. *snrk* Really? Ok, I'll let my Inner Cynic out for a romp - the US government generally tends to represent only itself, which is not precisely the same thing as the people. I'll go way out on a limb and post a quote from a polemic snark-piece recently posted on the Net Neutrality decision: === "Why is this so difficult to understand? When forced to choose between big corporations and big government, you should never choose big government because whatever you don’t like about the big corporations WILL ALSO BE PRESENT IN BIG GOVERNMENT, ONLY WORSE, AND WITH GUNS." === And when the big corporations and the big government are thoroughly cross-pollinated, we're doubly screwed. Rest assured, the Verizons and AT&Ts in the world will make out just FINE as the FCC starts regulating the crap out of the situation. The Rest of Us™? Probably not so much. :) -- ------------------------------------------------------------------------ Bruce H. McIntosh bhm at ufl.edu Senior Network Engineer http://net-services.ufl.edu University of Florida Network Services 352-273-1066 From bhm at ufl.edu Fri Feb 27 18:12:47 2015 From: bhm at ufl.edu (Bruce H McIntosh) Date: Fri, 27 Feb 2015 13:12:47 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0B045.80409@pari.edu> References: <54F08428.4000705@invaluement.com> <54F0B045.80409@pari.edu> Message-ID: <54F0B39F.802@ufl.edu> On 2015-02-27 12:58, Lamar Owen wrote: > On 02/27/2015 09:50 AM, Rob McEwen wrote: (*SNIP*) > Now, the R&O isn't available yet, but the regs themselves are. Check out > 47CFR§8.1-17, already available through the eCFR. Here's a link: > http://www.ecfr.gov/cgi-bin/text-idx?SID=3f0ad879cf046fa8e4edd14261ef70f2&node=pt47.1.8&rgn=div5 Awesome. Thanks for the info! -- ------------------------------------------------------------------------ Bruce H. McIntosh bhm at ufl.edu Senior Network Engineer http://net-services.ufl.edu University of Florida Network Services 352-273-1066 From cscora at apnic.net Fri Feb 27 18:12:37 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Feb 2015 04:12:37 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201502271812.t1RICbfd011604@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 28 Feb, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 533931 Prefixes after maximum aggregation (per Origin AS): 204366 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 260046 Total ASes present in the Internet Routing Table: 49503 Prefixes per ASN: 10.79 Origin-only ASes present in the Internet Routing Table: 36475 Origin ASes announcing only one prefix: 16258 Transit ASes present in the Internet Routing Table: 6262 Transit-only ASes present in the Internet Routing Table: 167 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 44 Max AS path prepend of ASN ( 55944) 41 Prefixes from unregistered ASNs in the Routing Table: 1309 Unregistered ASNs in the Routing Table: 429 Number of 32-bit ASNs allocated by the RIRs: 8696 Number of 32-bit ASNs visible in the Routing Table: 6766 Prefixes from 32-bit ASNs in the Routing Table: 24517 Number of bogon 32-bit ASNs visible in the Routing Table: 2 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 368 Number of addresses announced to Internet: 2732743460 Equivalent to 162 /8s, 226 /16s and 91 /24s Percentage of available address space announced: 73.8 Percentage of allocated address space announced: 73.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.2 Total number of prefixes smaller than registry allocations: 180550 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 131824 Total APNIC prefixes after maximum aggregation: 38376 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 137342 Unique aggregates announced from the APNIC address blocks: 55718 APNIC Region origin ASes present in the Internet Routing Table: 5023 APNIC Prefixes per ASN: 27.34 APNIC Region origin ASes announcing only one prefix: 1215 APNIC Region transit ASes present in the Internet Routing Table: 869 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 44 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1320 Number of APNIC addresses announced to Internet: 746245248 Equivalent to 44 /8s, 122 /16s and 204 /24s Percentage of available APNIC address space announced: 87.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 176333 Total ARIN prefixes after maximum aggregation: 87229 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 178302 Unique aggregates announced from the ARIN address blocks: 83615 ARIN Region origin ASes present in the Internet Routing Table: 16499 ARIN Prefixes per ASN: 10.81 ARIN Region origin ASes announcing only one prefix: 6080 ARIN Region transit ASes present in the Internet Routing Table: 1708 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 21 Number of ARIN region 32-bit ASNs visible in the Routing Table: 357 Number of ARIN addresses announced to Internet: 1061393696 Equivalent to 63 /8s, 67 /16s and 149 /24s Percentage of available ARIN address space announced: 56.1 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: 129975 Total RIPE prefixes after maximum aggregation: 64648 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 136276 Unique aggregates announced from the RIPE address blocks: 83689 RIPE Region origin ASes present in the Internet Routing Table: 17878 RIPE Prefixes per ASN: 7.62 RIPE Region origin ASes announcing only one prefix: 8135 RIPE Region transit ASes present in the Internet Routing Table: 2968 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3474 Number of RIPE addresses announced to Internet: 693542276 Equivalent to 41 /8s, 86 /16s and 157 /24s Percentage of available RIPE address space announced: 100.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 58681 Total LACNIC prefixes after maximum aggregation: 11081 LACNIC Deaggregation factor: 5.30 Prefixes being announced from the LACNIC address blocks: 68196 Unique aggregates announced from the LACNIC address blocks: 31605 LACNIC Region origin ASes present in the Internet Routing Table: 2403 LACNIC Prefixes per ASN: 28.38 LACNIC Region origin ASes announcing only one prefix: 623 LACNIC Region transit ASes present in the Internet Routing Table: 484 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1524 Number of LACNIC addresses announced to Internet: 167636224 Equivalent to 9 /8s, 253 /16s and 237 /24s Percentage of available LACNIC address space announced: 99.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12406 Total AfriNIC prefixes after maximum aggregation: 2988 AfriNIC Deaggregation factor: 4.15 Prefixes being announced from the AfriNIC address blocks: 13447 Unique aggregates announced from the AfriNIC address blocks: 5087 AfriNIC Region origin ASes present in the Internet Routing Table: 737 AfriNIC Prefixes per ASN: 18.25 AfriNIC Region origin ASes announcing only one prefix: 205 AfriNIC Region transit ASes present in the Internet Routing Table: 155 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 91 Number of AfriNIC addresses announced to Internet: 63479296 Equivalent to 3 /8s, 200 /16s and 158 /24s Percentage of available AfriNIC address space announced: 63.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2909 11553 912 Korea Telecom 17974 2819 904 77 PT Telekomunikasi Indonesia 7545 2566 336 127 TPG Telecom Limited 4755 1986 422 210 TATA Communications formerly 4538 1758 4190 71 China Education and Research 9829 1666 1325 36 National Internet Backbone 9808 1547 8717 29 Guangdong Mobile Communicatio 4808 1450 2228 432 CNCGROUP IP network China169 9583 1398 132 556 Sify Limited 9498 1298 334 96 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 2985 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 3356 2565 10700 482 Level 3 Communications, Inc. 18566 2041 379 183 MegaPath Corporation 20115 1850 1830 438 Charter Communications 6983 1625 866 244 EarthLink, Inc. 4323 1620 1037 406 tw telecom holdings, inc. 30036 1518 312 516 Mediacom Communications Corp 701 1391 11268 678 MCI Communications Services, 22561 1328 412 241 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1966 300 355 TELLCOM ILETISIM HIZMETLERI A 20940 1641 641 1214 Akamai International B.V. 8402 1348 544 15 OJSC "Vimpelcom" 6849 1199 356 25 JSC "Ukrtelecom" 13188 1047 98 59 TOV "Bank-Inform" 31148 1045 45 21 Freenet Ltd. 8551 904 373 48 Bezeq International-Ltd 12479 862 792 86 France Telecom Espana SA 9198 850 349 25 JSC Kazakhtelecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 2994 489 290 Telmex Colombia S.A. 28573 2324 2142 112 NET Servi�os de Comunica��o S 7303 1790 1190 230 Telecom Argentina S.A. 6147 1574 374 30 Telefonica del Peru S.A.A. 8151 1550 3117 453 Uninet S.A. de C.V. 6503 1201 421 58 Axtel, S.A.B. de C.V. 7738 1001 1882 42 Telemar Norte Leste S.A. 3816 924 400 150 COLOMBIA TELECOMUNICACIONES S 26615 922 2325 35 Tim Celular S.A. 18881 863 1036 22 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1415 958 13 TE-AS 24863 963 284 26 Link Egypt (Link.NET) 36903 479 241 90 Office National des Postes et 36992 402 1101 31 ETISALAT MISR 37492 319 155 71 Orange Tunisie 24835 299 144 9 Vodafone Data 3741 250 921 209 Internet Solutions 29571 234 21 12 Cote d'Ivoire Telecom 36947 191 712 14 Telecom Algeria 15706 174 32 6 Sudatel (Sudan Telecom Co. Lt Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 2994 489 290 Telmex Colombia S.A. 22773 2985 2955 141 Cox Communications Inc. 4766 2909 11553 912 Korea Telecom 6389 2891 3688 51 BellSouth.net Inc. 17974 2819 904 77 PT Telekomunikasi Indonesia 7545 2566 336 127 TPG Telecom Limited 3356 2565 10700 482 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2324 2142 112 NET Servi�os de Comunica��o S 18566 2041 379 183 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 2985 2844 Cox Communications Inc. 6389 2891 2840 BellSouth.net Inc. 17974 2819 2742 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2566 2439 TPG Telecom Limited 28573 2324 2212 NET Servi�os de Comunica��o S 3356 2565 2083 Level 3 Communications, Inc. 4766 2909 1997 Korea Telecom 18566 2041 1858 MegaPath Corporation 4755 1986 1776 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 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. 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.64.104.0/22 209 Qwest Communications Company, Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 Bitfinite LLC 23.252.224.0/20 62502 >>UNKNOWN<< 23.252.224.0/21 62502 >>UNKNOWN<< 23.252.232.0/21 62502 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 37.16.88.0/23 57652 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:34 /11:92 /12:264 /13:504 /14:994 /15:1723 /16:12962 /17:7136 /18:12168 /19:25053 /20:35715 /21:38496 /22:57710 /23:50459 /24:287681 /25:1078 /26:1112 /27:669 /28:17 /29:14 /30:9 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2201 2985 Cox Communications Inc. 18566 1996 2041 MegaPath Corporation 6389 1671 2891 BellSouth.net Inc. 30036 1364 1518 Mediacom Communications Corp 6983 1314 1625 EarthLink, Inc. 34984 1277 1966 TELLCOM ILETISIM HIZMETLERI A 11492 1125 1188 CABLE ONE, INC. 6147 1118 1574 Telefonica del Peru S.A.A. 10620 1055 2994 Telmex Colombia S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1489 2:671 3:1 4:98 5:1736 6:21 8:1421 12:1843 13:4 14:1304 15:16 16:2 17:42 18:21 20:49 23:1176 24:1673 27:1855 31:1475 32:39 33:2 34:5 35:3 36:119 37:1850 38:1012 39:10 40:234 41:2898 42:259 43:1112 44:25 45:218 46:2147 47:34 49:839 50:783 52:12 54:66 55:5 56:8 57:35 58:1210 59:681 60:462 61:1764 62:1312 63:1913 64:4443 65:2267 66:4092 67:2017 68:1046 69:3280 70:961 71:435 72:1959 74:2603 75:318 76:400 77:1482 78:1263 79:783 80:1316 81:1327 82:819 83:672 84:682 85:1343 86:388 87:1090 88:514 89:1758 90:149 91:5910 92:810 93:2180 94:1976 95:2101 96:431 97:339 98:1056 99:45 100:73 101:801 103:6863 104:1326 105:61 106:217 107:882 108:609 109:2010 110:1077 111:1481 112:747 113:1032 114:837 115:1262 116:1334 117:1022 118:1696 119:1437 120:441 121:1031 122:2182 123:1725 124:1491 125:1560 128:621 129:371 130:380 131:1117 132:477 133:167 134:411 135:88 136:311 137:303 138:502 139:174 140:227 141:419 142:631 143:464 144:529 145:110 146:687 147:561 148:1107 149:459 150:562 151:600 152:517 153:239 154:388 155:729 156:402 157:331 158:264 159:990 160:370 161:633 162:1914 163:409 164:665 165:674 166:324 167:704 168:1005 169:161 170:1458 171:225 172:41 173:1584 174:687 175:624 176:1465 177:3748 178:2076 179:867 180:1926 181:1603 182:1723 183:607 184:761 185:3009 186:2660 187:1835 188:2034 189:1565 190:7659 191:901 192:8119 193:5567 194:4066 195:3634 196:1625 197:978 198:5480 199:5518 200:6542 201:3000 202:9563 203:9078 204:4658 205:2733 206:2992 207:2993 208:3950 209:3913 210:3484 211:1846 212:2477 213:2274 214:844 215:69 216:5537 217:1803 218:667 219:468 220:1432 221:790 222:464 223:656 End of report From rob at invaluement.com Fri Feb 27 18:19:03 2015 From: rob at invaluement.com (Rob McEwen) Date: Fri, 27 Feb 2015 13:19:03 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0AE3B.2010209@sprunk.org> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <20150227165240.GA13738@puck.nether.net> <54F0AE3B.2010209@sprunk.org> Message-ID: <54F0B517.4050200@invaluement.com> On 2/27/2015 12:49 PM, Stephen Sprunk wrote: > This case seems to prove that the telco/cable duopoly can't _always_ > buy the FCC rulings they desire; every now and then, the US govt > surprises us and actually represents the people. I know that ISPs are not perfect. Nothing is perfect. But what is incredible about this whole debate... is (1) how few people are actually suffering right now. If "net neutrality" had never made the news... and you went out and talked to 10,000 people, and forced them to sit down and write out their top 100 problems in life... and compiled all 1 million answers... I doubt internet connectivity problems or slow internet speeds would come up more than a few times... if even once! (2) meanwhile, we're such spoiled brats because... the bandwidth usage per second... AND the total number of users... AND the usage scenarios... AND the amount of hours of usage per day per person... has all SKYROCKETED in the past 15 years. It is AMAZING that the ISPs have kept pace. And this wasn't easy. My business is spam filtering and e-mail hosting... and in that related business... the usage levels per dollar of revenue (literally.. the # of MBs per dollar of revenue) is order of magnitudes higher than it was 15 years ago... and, like others, I've had to do amazing things to keep things flowing well with the same basic $/user. (getting faster hardware wasn't even nearly enough) That wasn't easy. (3) when ISPs abuse their power, consumers can vote with their wallet to another access points. Yes, the choices are somewhat limited, but there are CHOICES (including 4G).. and, btw, there would have been MORE choices if the economy wasn't continuing to be anemic over the past several years. In contrast, when the government abuses their power, it is MUCH harder to move to another country. Plus, a bad ISP can only make someone's life so miserable. But an out-of-control government that has too much power can fine you, imprison you, IRS audit you, over-regulate you, legally (and illegally) spy on you, etc. (Just merely defining private networks as if they were "public airways"... is already a huge potential 4th amendment violation... why stop with cables moving data? Why not just make your hard drive... or your files in your filing cabnet part of their jurisdiction, too? Can they vote that in too? If you think not, tell me... what is stopping them that applies DIFFERENTLY from what they just did?) We're solving an almost non-existing problem.. by over-empowering an already out of control US government, with powers that we can't even begin to understand the extend of how they could be abused... to "fix" an industry that has done amazingly good things for consumers in recent years. -- Rob McEwen From lowen at pari.edu Fri Feb 27 18:28:33 2015 From: lowen at pari.edu (Lamar Owen) Date: Fri, 27 Feb 2015 13:28:33 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0B517.4050200@invaluement.com> References: Message-ID: <54F0B751.30008@pari.edu> On 02/27/2015 01:19 PM, Rob McEwen wrote: > We're solving an almost non-existing problem.. by over-empowering an > already out of control US government, with powers that we can't even > begin to understand the extend of how they could be abused... to "fix" > an industry that has done amazingly good things for consumers in > recent years. > You really should read 47CFR§8. It won't take you more than an hour or so, as it's only about 8 pages. The procedure for filing a complaint is pretty interesting, and requires the complainant to do some pretty involved things. (47CFR§8.14 for the complaint procedure, 47CFR§8.13 for the requirements for the pleading, etc). Note that the definitions found in 47CFR§8.11(a) and (b) are pretty specific in who is actually covered by 'net neutrality.' From mike at mtcc.com Fri Feb 27 18:34:11 2015 From: mike at mtcc.com (Michael Thomas) Date: Fri, 27 Feb 2015 10:34:11 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725DEC0@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> <54F0AB46.3070707@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DEC0@MUNPRDMBXA1.medline.com> Message-ID: <54F0B8A3.8000909@mtcc.com> On 02/27/2015 10:02 AM, Naslund, Steve wrote: > I am talking about real compelling content with value not an HD camera staring at a wall. Even backups are rarely an issue for the average user as long as their backup solution is intelligent enough to use bandwidth efficiently. Really, the average user's circuit is sitting idle most of the time in any case so if that backup takes all day to complete, no one cares. On this group we have to watch that we do not see ourselves as the "average user", we definitely are not. > As with everything I want it when I want it. It has nothing to do with aggregate bytes, but burst. If I'm uploading 4k content of baby's first birthday for all of the grandparents, they are not happy if the intertoobs busts a gasket. Mike From mel at beckman.org Fri Feb 27 18:34:57 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 27 Feb 2015 18:34:57 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> Message-ID: <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Bill, This is not feasible. ISPs work by oversubscription, so it's never possible for all (or even 10% of all) customers to simultaneously demand their full bandwidth. If ISPs had to reserve the full bandwidth sold to each customer in order to "do everything reasonably within your power to make sure I can access the Internet sites of my choice at X megabits per second", then broadband connections would cost thousands of dollars per month. Anyone who doesn't understand this fundamental fact of Internet distribution will be unable to engage in reasonable discussion about ISP practices. On Feb 27, 2015, at 9:56 AM, William Herrin > wrote: Deceit is Bad Behavior. If you sell me an X megabit per second Internet access service, you should do everything reasonably within your power to make sure I can access the Internet sites of my choice at X megabits per second. From lowen at pari.edu Fri Feb 27 18:52:02 2015 From: lowen at pari.edu (Lamar Owen) Date: Fri, 27 Feb 2015 13:52:02 -0500 Subject: One FCC neutrality elephant: disabilities compliance In-Reply-To: References: Message-ID: <54F0BCD2.50105@pari.edu> On 02/27/2015 01:06 PM, Mel Beckman wrote: > Section 255 of Title II applies to Internet providers now, as does section 225 of the Americans with Disabilities Act (ADA). These regulations are found in 47CFR§6, not 47CFR§8, which is the subject of docket 14-28. Not having read the actual R&O in docket 14-28, so basing the following statements on the NPRM instead. Since the NPRM had 47CFR§8 limited to 47CFR§8.11, and the actual amendment going to 47CFR§8.17, the adopted rules are different than originally proposed. You can read the proposed regulations yourself in FCC 14-61 ( http://apps.fcc.gov/ecfs/document/view?id=7521129942 ) pages 66-67. Yes, two pages. The actual regulations are a bit, but not much, longer. 47CFR§6 was already there before docket 14-28 came about. From eyeronic.design at gmail.com Fri Feb 27 18:54:12 2015 From: eyeronic.design at gmail.com (Mike Hale) Date: Fri, 27 Feb 2015 10:54:12 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0B517.4050200@invaluement.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <20150227165240.GA13738@puck.nether.net> <54F0AE3B.2010209@sprunk.org> <54F0B517.4050200@invaluement.com> Message-ID: "(3) when ISPs abuse their power, consumers can vote with their wallet to another access points." But they can't. That's the point. There is a massive dearth of legitimate competition in the broadband space for the vast majority of our population. And it's that lack of competition that has allowed Comcast et al to become the abusive bad actors they are. We're not replacing the ISPs with the Government. We're saying, in effect, that in exchange for government monopolies allowing you to become as big and profitable as you are, you now have to be slightly less douchy than you have been. On Fri, Feb 27, 2015 at 10:19 AM, Rob McEwen wrote: > On 2/27/2015 12:49 PM, Stephen Sprunk wrote: >> >> This case seems to prove that the telco/cable duopoly can't _always_ buy >> the FCC rulings they desire; every now and then, the US govt surprises us >> and actually represents the people. > > > I know that ISPs are not perfect. Nothing is perfect. But what is incredible > about this whole debate... is > > (1) how few people are actually suffering right now. If "net neutrality" had > never made the news... and you went out and talked to 10,000 people, and > forced them to sit down and write out their top 100 problems in life... and > compiled all 1 million answers... I doubt internet connectivity problems or > slow internet speeds would come up more than a few times... if even once! > > (2) meanwhile, we're such spoiled brats because... the bandwidth usage per > second... AND the total number of users... AND the usage scenarios... AND > the amount of hours of usage per day per person... has all SKYROCKETED in > the past 15 years. It is AMAZING that the ISPs have kept pace. And this > wasn't easy. My business is spam filtering and e-mail hosting... and in that > related business... the usage levels per dollar of revenue (literally.. the > # of MBs per dollar of revenue) is order of magnitudes higher than it was 15 > years ago... and, like others, I've had to do amazing things to keep things > flowing well with the same basic $/user. (getting faster hardware wasn't > even nearly enough) That wasn't easy. > > (3) when ISPs abuse their power, consumers can vote with their wallet to > another access points. Yes, the choices are somewhat limited, but there are > CHOICES (including 4G).. and, btw, there would have been MORE choices if the > economy wasn't continuing to be anemic over the past several years. In > contrast, when the government abuses their power, it is MUCH harder to move > to another country. Plus, a bad ISP can only make someone's life so > miserable. But an out-of-control government that has too much power can fine > you, imprison you, IRS audit you, over-regulate you, legally (and illegally) > spy on you, etc. (Just merely defining private networks as if they were > "public airways"... is already a huge potential 4th amendment violation... > why stop with cables moving data? Why not just make your hard drive... or > your files in your filing cabnet part of their jurisdiction, too? Can they > vote that in too? If you think not, tell me... what is stopping them that > applies DIFFERENTLY from what they just did?) > > We're solving an almost non-existing problem.. by over-empowering an already > out of control US government, with powers that we can't even begin to > understand the extend of how they could be abused... to "fix" an industry > that has done amazingly good things for consumers in recent years. > > -- > Rob McEwen > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From morrowc.lists at gmail.com Fri Feb 27 18:55:10 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 27 Feb 2015 13:55:10 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0B8A3.8000909@mtcc.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> <54F0AB46.3070707@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DEC0@MUNPRDMBXA1.medline.com> <54F0B8A3.8000909@mtcc.com> Message-ID: -.-- --- ..- / -.- -. --- .-- / .-- .... .- - / .-- --- ..- .-.. -.. / -- .- -.- . / - .... .. ... / .-- .... --- .-.. . / -.-. --- -. ...- . .-. ... .- - .. --- -. / -... . - - . .-. ..--.. / .. ..-. / .. - / .-- . .-. . / .. -. / -- --- .-. ... . / -.-. --- -.. . .-.-.- On Fri, Feb 27, 2015 at 1:34 PM, Michael Thomas wrote: > On 02/27/2015 10:02 AM, Naslund, Steve wrote: >> >> I am talking about real compelling content with value not an HD camera >> staring at a wall. Even backups are rarely an issue for the average user as >> long as their backup solution is intelligent enough to use bandwidth >> efficiently. Really, the average user's circuit is sitting idle most of the >> time in any case so if that backup takes all day to complete, no one cares. >> On this group we have to watch that we do not see ourselves as the "average >> user", we definitely are not. >> > > As with everything I want it when I want it. It has nothing to do with > aggregate bytes, but burst. If I'm uploading 4k content > of baby's first birthday for all of the grandparents, they are not happy if > the intertoobs busts a gasket. > > Mike From bill at herrin.us Fri Feb 27 18:54:47 2015 From: bill at herrin.us (William Herrin) Date: Fri, 27 Feb 2015 13:54:47 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: On Fri, Feb 27, 2015 at 1:34 PM, Mel Beckman wrote: > On Feb 27, 2015, at 9:56 AM, William Herrin > wrote: >> Deceit is Bad Behavior. If you sell me an X megabit per second >> Internet access service, you should do everything reasonably within >> your power to make sure I can access the Internet sites of my choice >> at X megabits per second. > This is not feasible. ISPs work by oversubscription, so it's never possible > for all (or even 10% of all) customers to simultaneously demand their full > bandwidth. If ISPs had to reserve the full bandwidth sold to each customer Hi Mel, Respectfully, that's a straw man argument. You alter the parameters of my criticism then proceed to show how the altered argument is unreasonable. All utilities work by oversubscription: electric, natural gas, water and sewer. When the sewer authority fouls up their oversubscription model and your pee ends up in my basement, guess who pays for the cleanup? They do. I have some unfortunate first-hand experience with this. > Anyone who doesn't understand [oversubscription] > will be unable to engage in reasonable discussion about ISP practices. You said it, not me. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From weaselkeeper at gmail.com Fri Feb 27 19:14:48 2015 From: weaselkeeper at gmail.com (Jim Richardson) Date: Fri, 27 Feb 2015 11:14:48 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0B751.30008@pari.edu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <20150227165240.GA13738@puck.nether.net> <54F0AE3B.2010209@sprunk.org> <54F0B517.4050200@invaluement.com> <54F0B751.30008@pari.edu> Message-ID: >From 47CFR§8.5b (b) A person engaged in the provision of mobile broadband Internet access service, insofar as such person is so engaged, shall not block consumers from accessing lawful Web sites, subject to reasonable network management; nor shall such person block applications that compete with the provider's voice or video telephony services, subject to reasonable network management. What's a "lawful" web site? On Fri, Feb 27, 2015 at 10:28 AM, Lamar Owen wrote: > On 02/27/2015 01:19 PM, Rob McEwen wrote: >> >> We're solving an almost non-existing problem.. by over-empowering an >> already out of control US government, with powers that we can't even begin >> to understand the extend of how they could be abused... to "fix" an industry >> that has done amazingly good things for consumers in recent years. >> > You really should read 47CFR§8. It won't take you more than an hour or so, > as it's only about 8 pages. > > The procedure for filing a complaint is pretty interesting, and requires the > complainant to do some pretty involved things. (47CFR§8.14 for the complaint > procedure, 47CFR§8.13 for the requirements for the pleading, etc). Note > that the definitions found in 47CFR§8.11(a) and (b) are pretty specific in > who is actually covered by 'net neutrality.' > From dtaylor at vocalabs.com Fri Feb 27 19:21:14 2015 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Fri, 27 Feb 2015 13:21:14 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> Message-ID: <54F0C3AA.3000400@vocalabs.com> But by this you are buying into the myth of the mean. It isn't that most, or even many, people would take advantage of equal upstream bandwidth, but that the few who would need to take extra measures unrelated to the generation of that content to be able to do so. Given symmetrical provisioning, no extra measures need to be taken when that 10 year old down the street turns out to be a master musician. On 02/27/2015 11:59 AM, Scott Helms wrote: > This is true in our measurements today, even when subscribers are given > symmetrical connections. It might change at some point in the future, > especially when widespread IPv6 lets us get rid of NAT as a de facto > deployment reality. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 12:48 PM, Naslund, Steve > wrote: > >> How about this? Show me 10 users in the average neighborhood creating >> content at 5 mbps....Period. Only realistic app I see is home surveillance >> but I don't think you want everyone accessing that anyway. The truth is >> that the average user does not create content that anyone needs to see. >> This has not changed throughout the ages, the ratio of authors to readers, >> artists to art lovers, musicians to music lovers, YouTube cat video creator >> to cat video lovers, has never been a many to many relationship. >> >> On 2015-02-27 12:13, Valdis.Kletnieks at vt.edu wrote: >>> Consider a group of 10 users, who all create new content. If each one >>> creates at a constant rate of 5 mbits, they need 5 up. But to >>> download all the new content from the other 9, they need close to 50 >> down. >>> And when you expand to several billion people creating new content, >>> you need a *huge* pipe down. >> Steven Naslund >> Chicago IL >> >> -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From khelms at zcorum.com Fri Feb 27 19:22:10 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 14:22:10 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: BIll, I have to take exception to your example. "All utilities work by oversubscription: electric, natural gas, water and sewer. When the sewer authority fouls up their oversubscription model and your pee ends up in my basement, guess who pays for the cleanup? They do." Water, gas, and to a great extent electrical systems do not work on oversubscription, ie their aggregate capacity meets or exceeds the needs of all their customers peak potential demand, at least from "normal" demand standpoint. If someone decides to go to every house in an area served by a water tower and turns on all the faucets at the same time, that's malicious behavior and will exceed the pressure the tower can provide, but I think we'd all(?) agree that's malicious behavior and not customer demand. The only one of those that really works that way is electrical power and even then it's not usually a matter of the lack of transmission, but a lack of generation during hot periods. Further, I don't believe that you can get the power company/water/gas company to pay for a failure to meet a capacity demand. Your example of the sewer system is also very dependent on circumstances. http://www.myfoxatlanta.com/story/21432309/sewage-spill-coon-rapids-homeowners-stuck-with-bill-after-backup http://www.horizonservicesinc.com/reference/tips-articles/sewer-backup-causes-prevention-coverag The most common point of contention is the lateral, which is almost always the home/business owner's responsibility http://www.sfgate.com/homeandgarden/sweatequity/article/Replacing-sewer-lateral-pricey-either-way-you-go-5328940.php A much more apt comparison for over subscription is of the course normal POTS service, but again I am not aware of any recompense you can get from your phone company if you get an "All circuits are busy message", though you can of course complain to the FCC. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 1:54 PM, William Herrin wrote: > On Fri, Feb 27, 2015 at 1:34 PM, Mel Beckman wrote: > > On Feb 27, 2015, at 9:56 AM, William Herrin > > wrote: > >> Deceit is Bad Behavior. If you sell me an X megabit per second > >> Internet access service, you should do everything reasonably within > >> your power to make sure I can access the Internet sites of my choice > >> at X megabits per second. > > > This is not feasible. ISPs work by oversubscription, so it's never > possible > > for all (or even 10% of all) customers to simultaneously demand their > full > > bandwidth. If ISPs had to reserve the full bandwidth sold to each > customer > > Hi Mel, > > Respectfully, that's a straw man argument. You alter the parameters of > my criticism then proceed to show how the altered argument is > unreasonable. > > All utilities work by oversubscription: electric, natural gas, water > and sewer. When the sewer authority fouls up their oversubscription > model and your pee ends up in my basement, guess who pays for the > cleanup? They do. > > I have some unfortunate first-hand experience with this. > > > > Anyone who doesn't understand [oversubscription] > > will be unable to engage in reasonable discussion about ISP practices. > > You said it, not me. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From bhm at ufl.edu Fri Feb 27 19:24:54 2015 From: bhm at ufl.edu (Bruce H McIntosh) Date: Fri, 27 Feb 2015 14:24:54 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <20150227165240.GA13738@puck.nether.net> <54F0AE3B.2010209@sprunk.org> <54F0B517.4050200@invaluement.com> <54F0B751.30008@pari.edu> Message-ID: <54F0C486.6010506@ufl.edu> On 2015-02-27 14:14, Jim Richardson wrote: > What's a "lawful" web site? > Now *there* is a $64,000 question. Even more interesting is, "Who gets to decide day to day the answer to that question?" :) -- ------------------------------------------------------------------------ Bruce H. McIntosh bhm at ufl.edu Senior Network Engineer http://net-services.ufl.edu University of Florida Network Services 352-273-1066 From khelms at zcorum.com Fri Feb 27 19:30:24 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 14:30:24 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0C3AA.3000400@vocalabs.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> Message-ID: Daniel, Well, I wouldn't call using the mean a "myth", after all understanding most customer behavior is what we all have to build our business cases around. If we throw out what customers use today and simply take a build it and they will come approach then I suspect there would fewer of us in this business. Even when we look at anomalous users we don't see symmetrical usage, ie top 10% of uploaders. We also see less contended seconds on their upstream than we do on the downstream. These observations are based on ~500k residential and business subscribers across North America using FTTH (mostly GPON), DOCSIS cable modems, and various flavors of DSL. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 2:21 PM, Daniel Taylor wrote: > But by this you are buying into the myth of the mean. > > It isn't that most, or even many, people would take advantage of equal > upstream bandwidth, but that the few who would need to take extra measures > unrelated to the generation of that content to be able to do so. > > Given symmetrical provisioning, no extra measures need to be taken when > that 10 year old down the street turns out to be a master musician. > > On 02/27/2015 11:59 AM, Scott Helms wrote: > >> This is true in our measurements today, even when subscribers are given >> symmetrical connections. It might change at some point in the future, >> especially when widespread IPv6 lets us get rid of NAT as a de facto >> deployment reality. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Fri, Feb 27, 2015 at 12:48 PM, Naslund, Steve >> wrote: >> >> How about this? Show me 10 users in the average neighborhood creating >>> content at 5 mbps....Period. Only realistic app I see is home >>> surveillance >>> but I don't think you want everyone accessing that anyway. The truth is >>> that the average user does not create content that anyone needs to see. >>> This has not changed throughout the ages, the ratio of authors to >>> readers, >>> artists to art lovers, musicians to music lovers, YouTube cat video >>> creator >>> to cat video lovers, has never been a many to many relationship. >>> >>> On 2015-02-27 12:13, Valdis.Kletnieks at vt.edu wrote: >>> >>>> Consider a group of 10 users, who all create new content. If each one >>>> creates at a constant rate of 5 mbits, they need 5 up. But to >>>> download all the new content from the other 9, they need close to 50 >>>> >>> down. >>> >>>> And when you expand to several billion people creating new content, >>>> you need a *huge* pipe down. >>>> >>> Steven Naslund >>> Chicago IL >>> >>> >>> > > -- > Daniel Taylor VP Operations Vocal Laboratories, Inc. > dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 > > From khelms at zcorum.com Fri Feb 27 19:32:26 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 14:32:26 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0C486.6010506@ufl.edu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <20150227165240.GA13738@puck.nether.net> <54F0AE3B.2010209@sprunk.org> <54F0B517.4050200@invaluement.com> <54F0B751.30008@pari.edu> <54F0C486.6010506@ufl.edu> Message-ID: While I view that statement with trepidation, my first guess would one that isn't in violation of state or federal law. About the only things I can think off hand, ie stuff we get told to take down as hosters today, are sites violating copyright law and child pornography. I hope that we don't see any additions to that list. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 2:24 PM, Bruce H McIntosh wrote: > > > On 2015-02-27 14:14, Jim Richardson wrote: > >> What's a "lawful" web site? >> >> Now *there* is a $64,000 question. Even more interesting is, "Who gets > to decide day to day the answer to that question?" :) > > -- > ------------------------------------------------------------------------ > Bruce H. McIntosh bhm at ufl.edu > Senior Network Engineer http://net-services.ufl.edu > University of Florida Network Services 352-273-1066 > From wwaites at tardis.ed.ac.uk Fri Feb 27 19:32:38 2015 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Fri, 27 Feb 2015 19:32:38 +0000 (GMT) Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> Message-ID: <20150227.193238.315861968627315258.wwaites@tardis.ed.ac.uk> It certainly seems to be Friday. On Fri, 27 Feb 2015 17:27:08 +0000, "Naslund, Steve" said: > That statement completely confuses me. Why is asymmetry evil? > Does that not reflect what "Joe Average User" actually needs and > wants? ... There is no technical reason that it can't be > symmetric it is just a reflection of what the market wants. This is a self-fulling prophecy. As long as the edge networks have asymmetry built into them popular programs and services will be developed that are structured to account for this. As long as the popular programs and services are made like this, the "average user" will not know that they might want something different. It doesn't have to be this way, its an artefact of a choice on the part of the larger (mostly telephone company) ISPs in the 1990s. It also happens to suit capital because it is more obvious how to make money at the expense of the users with an asymmetric network and centralised "Web 2.0" style services. Thankfully the cracks are starting to show. I was pleased to hear the surprised and shocked praise when I installed a symmetric radio service to someone in the neighbourhood and it was no longer painful for them to upload their photographs. Multi-party videoconferencing doesn't work well unless at least one participant (or a server) is on good, symmetric bandwidth. These are just boring mundane applications. Imagine the more interesting ones that might emerge if the restriction of asymmetry was no longer commonplace... -w -- /"\ | William Waites \ / ASCII Ribbon Campaign | School of Informatics X against HTML e-mail | University of Edinburgh / \ (still going) | http://tardis.ed.ac.uk/~wwaites/ -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From wwaites at tardis.ed.ac.uk Fri Feb 27 19:40:06 2015 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Fri, 27 Feb 2015 19:40:06 +0000 (GMT) Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0C486.6010506@ufl.edu> References: <54F0B751.30008@pari.edu> <54F0C486.6010506@ufl.edu> Message-ID: <20150227.194006.361624926196281759.wwaites@tardis.ed.ac.uk> On Fri, 27 Feb 2015 14:24:54 -0500, Bruce H McIntosh said: >> What's a "lawful" web site? >> > Now *there* is a $64,000 question. Even more interesting is, > "Who gets to decide day to day the answer to that question?" :) Over here we have some kind of an "answer" to that question... And it's not a very good one... -- /"\ | William Waites \ / ASCII Ribbon Campaign | School of Informatics X against HTML e-mail | University of Edinburgh / \ (still going) | http://tardis.ed.ac.uk/~wwaites/ -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From sclark at netwolves.com Fri Feb 27 19:42:29 2015 From: sclark at netwolves.com (Steve Clark) Date: Fri, 27 Feb 2015 14:42:29 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F0C8A5.60202@netwolves.com> <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> Message-ID: 1425066151197-007-00298323.sclark.netwolves.com@sclark66.netwolves.com Scott, Maybe if it the upstream bandwidth was there would be more applications to use it. I know it is a real pain to upload pics to Facebook, etc on my 1mbs uplink, or move things to work across my VPN. Steve On 02/27/2015 02:30 PM, Scott Helms wrote: > Daniel, > > Well, I wouldn't call using the mean a "myth", after all understanding most > customer behavior is what we all have to build our business cases around. > If we throw out what customers use today and simply take a build it and > they will come approach then I suspect there would fewer of us in this > business. > > Even when we look at anomalous users we don't see symmetrical usage, ie top > 10% of uploaders. We also see less contended seconds on their upstream > than we do on the downstream. These observations are based on ~500k > residential and business subscribers across North America using FTTH > (mostly GPON), DOCSIS cable modems, and various flavors of DSL. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 2:21 PM, Daniel Taylor wrote: > >> But by this you are buying into the myth of the mean. >> >> It isn't that most, or even many, people would take advantage of equal >> upstream bandwidth, but that the few who would need to take extra measures >> unrelated to the generation of that content to be able to do so. >> >> Given symmetrical provisioning, no extra measures need to be taken when >> that 10 year old down the street turns out to be a master musician. >> >> On 02/27/2015 11:59 AM, Scott Helms wrote: >> >>> This is true in our measurements today, even when subscribers are given >>> symmetrical connections. It might change at some point in the future, >>> especially when widespread IPv6 lets us get rid of NAT as a de facto >>> deployment reality. >>> >>> >>> Scott Helms >>> Vice President of Technology >>> ZCorum >>> (678) 507-5000 >>> -------------------------------- >>> http://twitter.com/kscotthelms >>> -------------------------------- >>> >>> On Fri, Feb 27, 2015 at 12:48 PM, Naslund, Steve >>> wrote: >>> >>> How about this? Show me 10 users in the average neighborhood creating >>>> content at 5 mbps....Period. Only realistic app I see is home >>>> surveillance >>>> but I don't think you want everyone accessing that anyway. The truth is >>>> that the average user does not create content that anyone needs to see. >>>> This has not changed throughout the ages, the ratio of authors to >>>> readers, >>>> artists to art lovers, musicians to music lovers, YouTube cat video >>>> creator >>>> to cat video lovers, has never been a many to many relationship. >>>> >>>> On 2015-02-27 12:13, Valdis.Kletnieks at vt.edu wrote: >>>> >>>>> Consider a group of 10 users, who all create new content. If each one >>>>> creates at a constant rate of 5 mbits, they need 5 up. But to >>>>> download all the new content from the other 9, they need close to 50 >>>>> >>>> down. >>>> >>>>> And when you expand to several billion people creating new content, >>>>> you need a *huge* pipe down. >>>>> >>>> Steven Naslund >>>> Chicago IL >>>> >>>> >>>> >> -- >> Daniel Taylor VP Operations Vocal Laboratories, Inc. >> dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 >> >> -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From mel at beckman.org Fri Feb 27 19:44:40 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 27 Feb 2015 19:44:40 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: Bill, In what way is my argument a straw man? I specifically address the assertion you make, that an ISP must deliver X Mbps whenever you demand it, by explaining the real world essential practice of oversubscription. Let's say you decide to start your own ISP, call it BillsNet. You buy a 1Gbps upstream pipe from Level3 for $6,000/month (a realistic price delivered to your facilities over fiber). You run wireless links to your customers via 100Mbps WiFi and a multi-gigabit redundant WiFi backbone, so that your only last-mile recurring cost is your labor to maintain your WISP network. Suppose, generously, that the going rate for 5x50Mbps broadband is $100/mo in your area (it's likely less). Only 20 customers can operate at full speed on this network (20 x 50Mbps = 1,000Mbps), so following your rule, you have to cap your income at $2,000/mo. You're losing $4,000/mo and you haven't yet spent a dime on salaries, hardware, deployment, or maintenance. I call this the "iron man" argument. ;) -mel On Feb 27, 2015, at 10:54 AM, William Herrin wrote: > On Fri, Feb 27, 2015 at 1:34 PM, Mel Beckman wrote: >> On Feb 27, 2015, at 9:56 AM, William Herrin >> wrote: >>> Deceit is Bad Behavior. If you sell me an X megabit per second >>> Internet access service, you should do everything reasonably within >>> your power to make sure I can access the Internet sites of my choice >>> at X megabits per second. > >> This is not feasible. ISPs work by oversubscription, so it's never possible >> for all (or even 10% of all) customers to simultaneously demand their full >> bandwidth. If ISPs had to reserve the full bandwidth sold to each customer > > Hi Mel, > > Respectfully, that's a straw man argument. You alter the parameters of > my criticism then proceed to show how the altered argument is > unreasonable. > > All utilities work by oversubscription: electric, natural gas, water > and sewer. When the sewer authority fouls up their oversubscription > model and your pee ends up in my basement, guess who pays for the > cleanup? They do. > > I have some unfortunate first-hand experience with this. > > >> Anyone who doesn't understand [oversubscription] >> will be unable to engage in reasonable discussion about ISP practices. > > You said it, not me. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: From jbates at paradoxnetworks.net Fri Feb 27 19:49:04 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Fri, 27 Feb 2015 13:49:04 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> Message-ID: <54F0CA30.7080706@paradoxnetworks.net> On 2/27/2015 1:30 PM, Scott Helms wrote: > Even when we look at anomalous users we don't see symmetrical usage, ie top > 10% of uploaders. We also see less contended seconds on their upstream > than we do on the downstream. These observations are based on ~500k > residential and business subscribers across North America using FTTH > (mostly GPON), DOCSIS cable modems, and various flavors of DSL. > > > It is my thought that when people ask for symmetrical circuits, they are really saying that they would like to see a higher upload. What they have is too slow for their needs. This is especially true for older technology that isn't in danger of being replaced anytime soon. Ideally, I suspect that most people would prefer a more variable approach, allowing for the complete frequency spectrum for upload and download and any combination in between. Let's be honest, it would be nice to utilize wasted download frequency to send something quicker. Once it gets past last mile, it is usually symmetric anyways. It's funny to watch someone spend an entire day uploading a video to youtube, though. Reminds me of the dialup days; just more data. Jack From Kevin_McElearney at cable.comcast.com Fri Feb 27 19:49:57 2015 From: Kevin_McElearney at cable.comcast.com (McElearney, Kevin) Date: Fri, 27 Feb 2015 19:49:57 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: [Sorry for top-posting] I actually think you are both right and partially wrong. It IS the ISPs responsibility to provide you with the broadband that was advertised and you paid for. This is also measured today by the FCC through Measuring Broadband America. http://data.fcc.gov/download/measuring-broadband-america/2014/2014-Fixed-Me asuring-Broadband-America-Report.pdf That said, your ISP is NOT “the Internet” and can’t guarantee “access the Internet sites of my choice at X megabits per second." While ISPs do take the phone call for all Internet problems (sometimes not very well), they certainly don’t control all levels of the QoE. ASPs may have server/site issues internally, CDNs may purposely throttle downloads (content owners contract commits), not all transit ISPs are created equal, TCP distance limitations, etc. What would be interesting is if all these rules/principals and transparency requirements were to be applied to all involved in the consumer QoE. - Kevin On 2/27/15, 1:34 PM, "Mel Beckman" wrote: >Bill, > >This is not feasible. ISPs work by oversubscription, so it's never >possible for all (or even 10% of all) customers to simultaneously demand >their full bandwidth. If ISPs had to reserve the full bandwidth sold to >each customer in order to "do everything reasonably within your power to >make sure I can access the Internet sites of my choice at X megabits per >second", then broadband connections would cost thousands of dollars per >month. > >Anyone who doesn't understand this fundamental fact of Internet >distribution will be unable to engage in reasonable discussion about ISP >practices. > >On Feb 27, 2015, at 9:56 AM, William Herrin >> > wrote: > >Deceit is Bad Behavior. If you sell me an X megabit per second >Internet access service, you should do everything reasonably within >your power to make sure I can access the Internet sites of my choice >at X megabits per second. > From khelms at zcorum.com Fri Feb 27 19:50:33 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 14:50:33 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0C8A5.60202@netwolves.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0C8A5.60202@netwolves.com> Message-ID: Steve, I'd be up in arms if all I had was a 1mbps uplink :) Having said that, the 10 mbps I get from Comcast right now is more than I need to do remote desktop, code check ins, and host of atypical uploading. I am absolutely not against good upstream rates! I do have a problem with people saying that we must/should have symmetrical connectivity simply because we don't see the market demand for that as of yet. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 2:42 PM, Steve Clark wrote: > Scott, > > Maybe if it the upstream bandwidth was there would be more applications to > use it. I know it is a real > pain to upload pics to Facebook, etc on my 1mbs uplink, or move things to > work across my VPN. > > Steve > > On 02/27/2015 02:30 PM, Scott Helms wrote: > > Daniel, > > Well, I wouldn't call using the mean a "myth", after all understanding most > customer behavior is what we all have to build our business cases around. > If we throw out what customers use today and simply take a build it and > they will come approach then I suspect there would fewer of us in this > business. > > Even when we look at anomalous users we don't see symmetrical usage, ie top > 10% of uploaders. We also see less contended seconds on their upstream > than we do on the downstream. These observations are based on ~500k > residential and business subscribers across North America using FTTH > (mostly GPON), DOCSIS cable modems, and various flavors of DSL. > > > Scott Helms > Vice President of Technology > ZCorum(678) 507-5000 > --------------------------------http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 2:21 PM, Daniel Taylor wrote: > > > But by this you are buying into the myth of the mean. > > It isn't that most, or even many, people would take advantage of equal > upstream bandwidth, but that the few who would need to take extra measures > unrelated to the generation of that content to be able to do so. > > Given symmetrical provisioning, no extra measures need to be taken when > that 10 year old down the street turns out to be a master musician. > > On 02/27/2015 11:59 AM, Scott Helms wrote: > > > This is true in our measurements today, even when subscribers are given > symmetrical connections. It might change at some point in the future, > especially when widespread IPv6 lets us get rid of NAT as a de facto > deployment reality. > > > Scott Helms > Vice President of Technology > ZCorum(678) 507-5000 > --------------------------------http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 12:48 PM, Naslund, Steve > wrote: > > How about this? Show me 10 users in the average neighborhood creating > > content at 5 mbps....Period. Only realistic app I see is home > surveillance > but I don't think you want everyone accessing that anyway. The truth is > that the average user does not create content that anyone needs to see. > This has not changed throughout the ages, the ratio of authors to > readers, > artists to art lovers, musicians to music lovers, YouTube cat video > creator > to cat video lovers, has never been a many to many relationship. > > On 2015-02-27 12:13, Valdis.Kletnieks at vt.edu wrote: > > > Consider a group of 10 users, who all create new content. If each one > creates at a constant rate of 5 mbits, they need 5 up. But to > download all the new content from the other 9, they need close to 50 > > > down. > > > And when you expand to several billion people creating new content, > you need a *huge* pipe down. > > > Steven Naslund > Chicago IL > > > > > -- > Daniel Taylor VP Operations Vocal Laboratories, Inc.dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 > > > > -- > Stephen Clark > *NetWolves Managed Services, LLC.* > Director of Technology > Phone: 813-579-3200 > Fax: 813-882-0209 > Email: steve.clark at netwolves.com > http://www.netwolves.com > From bill at herrin.us Fri Feb 27 19:50:22 2015 From: bill at herrin.us (William Herrin) Date: Fri, 27 Feb 2015 14:50:22 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: On Fri, Feb 27, 2015 at 2:22 PM, Scott Helms wrote: > I have to take exception to your example. > > Water, gas, and to a great extent electrical systems do not work on > oversubscription, ie their aggregate capacity meets or exceeds the needs of > all their customers peak potential demand, at least from "normal" demand > standpoint. Hi Scott, Do you propose that Internet access service should NOT be expected to meet peak "normal" demand? That would certainly make ISP operating models unique among public utilities. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From mike at mtcc.com Fri Feb 27 19:53:29 2015 From: mike at mtcc.com (Michael Thomas) Date: Fri, 27 Feb 2015 11:53:29 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0CA30.7080706@paradoxnetworks.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CA30.7080706@paradoxnetworks.net> Message-ID: <54F0CB39.8030602@mtcc.com> On 02/27/2015 11:49 AM, Jack Bates wrote: > > It is my thought that when people ask for symmetrical circuits, they > are really saying that they would like to see a higher upload. What > they have is too slow for their needs. This is especially true for > older technology that isn't in danger of being replaced anytime soon. > Ideally, I suspect that most people would prefer a more variable > approach, allowing for the complete frequency spectrum for upload and > download and any combination in between. Exactly. Mike From mel at beckman.org Fri Feb 27 19:57:20 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 27 Feb 2015 19:57:20 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: <70010365-D40C-4DCA-AF39-DD872755AB5E@beckman.org> Kevin, It is NOT the ISP's responsibility to provide you with X Mbps if that was advertised as "UP TO x Mbps" (which is exactly how every broadband provider advertises its service -- check your contract). We're not talking about the Internet's capacity here. We're talking about the physical limits of an ISPs own uplink connection to the Internet. That costs much more than the income from the number of users it takes to saturate the uplink. Any discussion of Internet backbone limitations, while these limitations do in fact exist, has nothing to do with ISP oversubscription, which some are claiming is deceitful. It's not deceitful, it's essential. See my earlier "iron man" example to Bill. -mel On Feb 27, 2015, at 11:49 AM, "McElearney, Kevin" wrote: > [Sorry for top-posting] > > I actually think you are both right and partially wrong. It IS the ISPs > responsibility to provide you with the broadband that was advertised and > you paid for. This is also measured today by the FCC through Measuring > Broadband America. > http://data.fcc.gov/download/measuring-broadband-america/2014/2014-Fixed-Me > asuring-Broadband-America-Report.pdf > > That said, your ISP is NOT “the Internet” and can’t guarantee “access the > Internet sites of my choice at X megabits per second." While ISPs do take > the phone call for all Internet problems (sometimes not very well), they > certainly don’t control all levels of the QoE. ASPs may have server/site > issues internally, CDNs may purposely throttle downloads (content owners > contract commits), not all transit ISPs are created equal, TCP distance > limitations, etc. > > What would be interesting is if all these rules/principals and > transparency requirements were to be applied to all involved in the > consumer QoE. > > - Kevin > > On 2/27/15, 1:34 PM, "Mel Beckman" wrote: > >> Bill, >> >> This is not feasible. ISPs work by oversubscription, so it's never >> possible for all (or even 10% of all) customers to simultaneously demand >> their full bandwidth. If ISPs had to reserve the full bandwidth sold to >> each customer in order to "do everything reasonably within your power to >> make sure I can access the Internet sites of my choice at X megabits per >> second", then broadband connections would cost thousands of dollars per >> month. >> >> Anyone who doesn't understand this fundamental fact of Internet >> distribution will be unable to engage in reasonable discussion about ISP >> practices. >> >> On Feb 27, 2015, at 9:56 AM, William Herrin >> > >> wrote: >> >> Deceit is Bad Behavior. If you sell me an X megabit per second >> Internet access service, you should do everything reasonably within >> your power to make sure I can access the Internet sites of my choice >> at X megabits per second. >> > From dtaylor at vocalabs.com Fri Feb 27 19:57:33 2015 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Fri, 27 Feb 2015 13:57:33 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> Message-ID: <54F0CC2D.9010900@vocalabs.com> The statistics certainly *should* be used when provisioning aggregate resources. But even if 1% of users would reasonably be using a fully symmetric link to its potential, that's a good reason to at least have such circuits available in the standard consumer mix, which they aren't today. On 02/27/2015 01:30 PM, Scott Helms wrote: > Daniel, > > Well, I wouldn't call using the mean a "myth", after all understanding > most customer behavior is what we all have to build our business cases > around. If we throw out what customers use today and simply take a > build it and they will come approach then I suspect there would fewer > of us in this business. > > Even when we look at anomalous users we don't see symmetrical usage, > ie top 10% of uploaders. We also see less contended seconds on their > upstream than we do on the downstream. These observations are based > on ~500k residential and business subscribers across North America > using FTTH (mostly GPON), DOCSIS cable modems, and various flavors of DSL. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 2:21 PM, Daniel Taylor > wrote: > > But by this you are buying into the myth of the mean. > > It isn't that most, or even many, people would take advantage of > equal upstream bandwidth, but that the few who would need to take > extra measures unrelated to the generation of that content to be > able to do so. > > Given symmetrical provisioning, no extra measures need to be taken > when that 10 year old down the street turns out to be a master > musician. > > On 02/27/2015 11:59 AM, Scott Helms wrote: > > This is true in our measurements today, even when subscribers > are given > symmetrical connections. It might change at some point in the > future, > especially when widespread IPv6 lets us get rid of NAT as a de > facto > deployment reality. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 12:48 PM, Naslund, Steve > > > wrote: > > How about this? Show me 10 users in the average > neighborhood creating > content at 5 mbps....Period. Only realistic app I see is > home surveillance > but I don't think you want everyone accessing that > anyway. The truth is > that the average user does not create content that anyone > needs to see. > This has not changed throughout the ages, the ratio of > authors to readers, > artists to art lovers, musicians to music lovers, YouTube > cat video creator > to cat video lovers, has never been a many to many > relationship. > > On 2015-02-27 12:13, Valdis.Kletnieks at vt.edu > wrote: > > Consider a group of 10 users, who all create new > content. If each one > creates at a constant rate of 5 mbits, they need 5 > up. But to > download all the new content from the other 9, they > need close to 50 > > down. > > And when you expand to several billion people creating > new content, > you need a *huge* pipe down. > > Steven Naslund > Chicago IL > > > > > -- > Daniel Taylor VP Operations Vocal > Laboratories, Inc. > dtaylor at vocalabs.com > http://www.vocalabs.com/ (612)235-5711 > > -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From rob at invaluement.com Fri Feb 27 19:58:06 2015 From: rob at invaluement.com (Rob McEwen) Date: Fri, 27 Feb 2015 14:58:06 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0B751.30008@pari.edu> References: <54F0B751.30008@pari.edu> Message-ID: <54F0CC4E.101@invaluement.com> On 2/27/2015 1:28 PM, Lamar Owen wrote: > You really should read 47CFR§8. It won't take you more than an hour > or so, as it's only about 8 pages. The bigger picture is (a) HOW they got this authority--self-defining it in, and (b) the potential abuse and 4th amendment violations, not just today's "foot in the door" details! Today's altruistic intentions... is a DIFFERENT ISSUE (though still important.. and I find much of their wording very open-ended... lots of "reasonables" in there.. and lots of possible protections or legal things that are EXTREMELY abusive... yet still universally considered legal!) To use an extreme example, if a democratically elected chief executive of a republic self-appointed himself a dictator-for-life, and stated that he would use those powers to imprison those who engage in human trafficking... would you really cheerleader him for fighting human trafficking and call his new authority a good thing? In the same way, I don't like the BASIS for this authority... and what it potentially means in the long term... besides what they state that they intend to do with this new authority they've appointed themselves in the short term. -- Rob McEwen +1 478-475-9032 From khelms at zcorum.com Fri Feb 27 20:01:59 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 15:01:59 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: Bill, The problem is in defining what is "normal" and "reasonable" when customers only know what those mean in regards to their behavior and not the larger customer base nor the behavior of the global network. I work with hundreds of access providers in North America, the Caribbean, and Europe so I've pretty much all of the current approaches to this and none of them work very well IMO. I have a customer on the west coast that has a very large Asian immigrant population and a very high percentage of the traffic from this access provider is going to and from Asia. This introduces a lot of variables that are far outside of the operator's control, so what's reasonable for this operator to do to ensure "reasonable" speeds when the links to Asia get saturated far upstream of them? They certainly could choose to buy alternative connectivity to that region, but then they'd have to raise rates and most of the time that extra connectivity isn't needed. BTW, the operator in this example has plenty capacity inside their DOCSIS and FTTH plant as well as plenty of capacity to two Tier 1 carriers. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 2:50 PM, William Herrin wrote: > On Fri, Feb 27, 2015 at 2:22 PM, Scott Helms wrote: > > I have to take exception to your example. > > > > Water, gas, and to a great extent electrical systems do not work on > > oversubscription, ie their aggregate capacity meets or exceeds the needs > of > > all their customers peak potential demand, at least from "normal" demand > > standpoint. > > Hi Scott, > > Do you propose that Internet access service should NOT be expected to > meet peak "normal" demand? That would certainly make ISP operating > models unique among public utilities. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From bill at herrin.us Fri Feb 27 20:02:10 2015 From: bill at herrin.us (William Herrin) Date: Fri, 27 Feb 2015 15:02:10 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: On Fri, Feb 27, 2015 at 2:44 PM, Mel Beckman wrote: > In what way is my argument a straw man? I specifically address > the assertion you make, that an ISP must deliver X Mbps > whenever you demand it, by explaining the real world > essential practice of oversubscription. You changed "whenever I demand it" to "all the time" and then proceeded to argue that if everybody used their whole bandwidth all the time, oversubscription wouldn't work and therefore Internet connections would cost thousands of dollars. Well sure, if every house used 200 amps all the time the electric gird would collapse. Yet somehow when my 120 amp tankless electric water heater kicks on for my morning shower I don't black out the city. How could that possibly be? It's a straw man, Mel. Own up to it and move on. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From mel at beckman.org Fri Feb 27 20:12:21 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 27 Feb 2015 20:12:21 +0000 Subject: One FCC neutrality elephant: disabilities compliance In-Reply-To: <54F0BCD2.50105@pari.edu> References: <54F0BCD2.50105@pari.edu> Message-ID: <2D167235-5C33-4CD9-B3B8-BC33E06AA0DA@beckman.org> Lamar, Two pages? Read the news, man. It's been widely reported that the actual Order runs to over 300 pages! http://www.npr.org/blogs/thetwo-way/2015/02/26/389259382 You say you haven't read the actual R&O. Nobody in the public sector, or even in Congress AFAIK, has read it. The Order's 300-plus pages were never publicly released or openly debated.This is another "you must pass it to see what's in it" debacle, without the luxury of having any semblance of democratic process or transparency. I wrote the FCC to ask for a copy of the Order, and here is the response I received: On Feb 27, 2015, at 11:08 AM, Will Wiquist > wrote: Good afternoon, Thank you for writing. The Order will be released to the public on the FCC website as soon as possible, following final edits, which will likely take a few weeks. The order is then sent to the Federal Register. This is the typical process for a final rule and order passed by the Commission. If you are reporting on this, you can attribute that statement to an FCC spokesperson. Very best regards, Will Despite the FCC's "best regards", this is the Obama administration pulling a fast one. They'll release the order months from now after they wait for the public to forget about it. "If you like your Internet, you can keep your Internet." On Feb 27, 2015, at 10:52 AM, Lamar Owen > wrote: On 02/27/2015 01:06 PM, Mel Beckman wrote: Section 255 of Title II applies to Internet providers now, as does section 225 of the Americans with Disabilities Act (ADA). These regulations are found in 47CFR§6, not 47CFR§8, which is the subject of docket 14-28. Not having read the actual R&O in docket 14-28, so basing the following statements on the NPRM instead. Since the NPRM had 47CFR§8 limited to 47CFR§8.11, and the actual amendment going to 47CFR§8.17, the adopted rules are different than originally proposed. You can read the proposed regulations yourself in FCC 14-61 ( http://apps.fcc.gov/ecfs/document/view?id=7521129942 ) pages 66-67. Yes, two pages. The actual regulations are a bit, but not much, longer. 47CFR§6 was already there before docket 14-28 came about. From bill at herrin.us Fri Feb 27 20:17:05 2015 From: bill at herrin.us (William Herrin) Date: Fri, 27 Feb 2015 15:17:05 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: On Fri, Feb 27, 2015 at 3:01 PM, Scott Helms wrote: > The problem is in defining what is "normal" and "reasonable" when customers > only know what those mean in regards to their behavior and not the larger > customer base nor the behavior of the global network. Hi Scott, "Normal" is whatever the user normally tries to do. "Reasonable" is whatever the user is willing to pay for. Any mismatch between the two finds its error in your marketing department. If your understanding of normal and reasonable radically diverges from this, you've made a mistake. It's exactly as simple as this. > I have a customer on the west coast that has a very large Asian immigrant > population and a very high percentage of the traffic from this access > provider is going to and from Asia. This introduces a lot of variables that > are far outside of the operator's control, so what's reasonable for this > operator to do to ensure "reasonable" speeds when the links to Asia get > saturated far upstream of them? They certainly could choose to buy > alternative connectivity to that region, but then they'd have to raise rates > and most of the time that extra connectivity isn't needed. So what are they doing? Playing it one-size-fits-all and giving this "very large" customer population no way to get acceptable speed to the portions of the Internet that population wants to reach? Seems like a competitive service provider focused on meeting that customer population's needs would do well. Any notion what has prevented that from happening? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From tom.taylor.stds at gmail.com Fri Feb 27 20:18:06 2015 From: tom.taylor.stds at gmail.com (Tom Taylor) Date: Fri, 27 Feb 2015 15:18:06 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: <54F0D0FE.5030307@gmail.com> On 27/02/2015 2:50 PM, William Herrin wrote: > On Fri, Feb 27, 2015 at 2:22 PM, Scott Helms wrote: >> I have to take exception to your example. >> >> Water, gas, and to a great extent electrical systems do not work on >> oversubscription, ie their aggregate capacity meets or exceeds the needs of >> all their customers peak potential demand, at least from "normal" demand >> standpoint. > > Hi Scott, > > Do you propose that Internet access service should NOT be expected to > meet peak "normal" demand? That would certainly make ISP operating > models unique among public utilities. > > Regards, > Bill Herrin > I've worked on both data network (Canada's X.25 Datapac) and circuit-switched network provisioning (Nortel's DMS switches, and some of my contributions appear in the ITU-T Orange Book). Circuit-switched provisioning had the useful concept of "grade of service". This meant that you set a target probability of delay or loss for a given load level on the network (Average Busy Season Busy Hour, 10 High Day Busy Hour, separate targets for each and provision to the most binding). The same general concepts surely apply to IP network provisioning: you know you can't economically serve all the traffic at the absolute peak, but you set reasonable targets, assure yourself by simulation and analysis that your design will meet the target, and build accordingly. Tom Taylor > > From mel at beckman.org Fri Feb 27 20:20:51 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 27 Feb 2015 20:20:51 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: Bill, I did not change "whenever I demand it" to "all the time". You're hand-waving now. I clearly said that users can't all demand their maximum bandwidth at the same time. That's nothing like "all the time." Every house can't use its 200 amps at the same time, which happens when everyone turns on their AC on a hot day. The electrical grid is not built to the worst case scenario, and it does in fact break down when those events happen. Your shower example is perfect. Yes, you can get 120A tankless water heating for a brief interval. But not "whenever you demand it." If you demand it while the everyone is experiencing an HVAC-induced brownout on a hot day, your won't get it. Period. You never responded to my "BillsNet" real-world example. Is that a straw-man argument too? -mel On Feb 27, 2015, at 12:02 PM, William Herrin > wrote: On Fri, Feb 27, 2015 at 2:44 PM, Mel Beckman > wrote: In what way is my argument a straw man? I specifically address the assertion you make, that an ISP must deliver X Mbps whenever you demand it, by explaining the real world essential practice of oversubscription. You changed "whenever I demand it" to "all the time" and then proceeded to argue that if everybody used their whole bandwidth all the time, oversubscription wouldn't work and therefore Internet connections would cost thousands of dollars. Well sure, if every house used 200 amps all the time the electric gird would collapse. Yet somehow when my 120 amp tankless electric water heater kicks on for my morning shower I don't black out the city. How could that possibly be? It's a straw man, Mel. Own up to it and move on. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From scott.brim at gmail.com Fri Feb 27 20:22:46 2015 From: scott.brim at gmail.com (Scott Brim) Date: Fri, 27 Feb 2015 15:22:46 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0C486.6010506@ufl.edu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <20150227165240.GA13738@puck.nether.net> <54F0AE3B.2010209@sprunk.org> <54F0B517.4050200@invaluement.com> <54F0B751.30008@pari.edu> <54F0C486.6010506@ufl.edu> Message-ID: On Fri, Feb 27, 2015 at 2:24 PM, Bruce H McIntosh wrote: > On 2015-02-27 14:14, Jim Richardson wrote: >> >> What's a "lawful" web site? >> > Now *there* is a $64,000 question. Even more interesting is, "Who gets to > decide day to day the answer to that question?" :) Common term in mobile operators. A mobile site is one that is not breaking the law, e.g. not distributing pirated materials or being used for other illegal activity. If a site is breaking the law, they can block it. From scott.brim at gmail.com Fri Feb 27 20:23:22 2015 From: scott.brim at gmail.com (Scott Brim) Date: Fri, 27 Feb 2015 15:23:22 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <20150227165240.GA13738@puck.nether.net> <54F0AE3B.2010209@sprunk.org> <54F0B517.4050200@invaluement.com> <54F0B751.30008@pari.edu> <54F0C486.6010506@ufl.edu> Message-ID: On Fri, Feb 27, 2015 at 3:22 PM, Scott Brim wrote: > Common term in mobile operators. A mobile site is one that is not I mean a legal site. Sigh. From khelms at zcorum.com Fri Feb 27 20:25:42 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 15:25:42 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0CC2D.9010900@vocalabs.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> Message-ID: Daniel, We'd have to come to some standard definition of, "But even if 1% of users would reasonably be using a fully symmetric link to its potential..." As I said, I have visibility into a large number of symmetric connections and without exception they'd fit well into a plan that offered upstreams with that had a fractional speed of the downstream. Now, keep in mind I'm not talking about 1/10 as a ratio here, but 1/5 would accommodate ~99.2% and 1/4 would fit ~99.9%. It's also important to note that all of these accounts are in the >25mbps down territory so their upstreams are >5mbps. What I see when I look at customer satisfaction ratings is a very strong correlation with low uplink speeds and a high satisfaction rate when we look at uplink speeds greater than 4mbps. What I don't see is an increase in customer satisfaction as upload speeds go past ~6mbps. Conversely, increases in customer satisfaction with correlate with increases in download speeds past ~30mbps before the correlation starts weakening. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 2:57 PM, Daniel Taylor wrote: > The statistics certainly *should* be used when provisioning aggregate > resources. > But even if 1% of users would reasonably be using a fully symmetric link > to its potential, that's a good reason to at least have such circuits > available in the standard consumer mix, which they aren't today. > > On 02/27/2015 01:30 PM, Scott Helms wrote: > >> Daniel, >> >> Well, I wouldn't call using the mean a "myth", after all understanding >> most customer behavior is what we all have to build our business cases >> around. If we throw out what customers use today and simply take a build >> it and they will come approach then I suspect there would fewer of us in >> this business. >> >> Even when we look at anomalous users we don't see symmetrical usage, ie >> top 10% of uploaders. We also see less contended seconds on their upstream >> than we do on the downstream. These observations are based on ~500k >> residential and business subscribers across North America using FTTH >> (mostly GPON), DOCSIS cable modems, and various flavors of DSL. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Fri, Feb 27, 2015 at 2:21 PM, Daniel Taylor > > wrote: >> >> But by this you are buying into the myth of the mean. >> >> It isn't that most, or even many, people would take advantage of >> equal upstream bandwidth, but that the few who would need to take >> extra measures unrelated to the generation of that content to be >> able to do so. >> >> Given symmetrical provisioning, no extra measures need to be taken >> when that 10 year old down the street turns out to be a master >> musician. >> >> On 02/27/2015 11:59 AM, Scott Helms wrote: >> >> This is true in our measurements today, even when subscribers >> are given >> symmetrical connections. It might change at some point in the >> future, >> especially when widespread IPv6 lets us get rid of NAT as a de >> facto >> deployment reality. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Fri, Feb 27, 2015 at 12:48 PM, Naslund, Steve >> > >> wrote: >> >> How about this? Show me 10 users in the average >> neighborhood creating >> content at 5 mbps....Period. Only realistic app I see is >> home surveillance >> but I don't think you want everyone accessing that >> anyway. The truth is >> that the average user does not create content that anyone >> needs to see. >> This has not changed throughout the ages, the ratio of >> authors to readers, >> artists to art lovers, musicians to music lovers, YouTube >> cat video creator >> to cat video lovers, has never been a many to many >> relationship. >> >> On 2015-02-27 12:13, Valdis.Kletnieks at vt.edu >> wrote: >> >> Consider a group of 10 users, who all create new >> content. If each one >> creates at a constant rate of 5 mbits, they need 5 >> up. But to >> download all the new content from the other 9, they >> need close to 50 >> >> down. >> >> And when you expand to several billion people creating >> new content, >> you need a *huge* pipe down. >> >> Steven Naslund >> Chicago IL >> >> >> >> >> -- Daniel Taylor VP Operations Vocal >> Laboratories, Inc. >> dtaylor at vocalabs.com >> http://www.vocalabs.com/ (612)235-5711 >> >> >> > > -- > Daniel Taylor VP Operations Vocal Laboratories, Inc. > dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 > > From Valdis.Kletnieks at vt.edu Fri Feb 27 20:35:14 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Feb 2015 15:35:14 -0500 Subject: One FCC neutrality elephant: disabilities compliance In-Reply-To: Your message of "Fri, 27 Feb 2015 20:12:21 +0000." <2D167235-5C33-4CD9-B3B8-BC33E06AA0DA@beckman.org> References: <54F0BCD2.50105@pari.edu> <2D167235-5C33-4CD9-B3B8-BC33E06AA0DA@beckman.org> Message-ID: <19998.1425069314@turing-police.cc.vt.edu> On Fri, 27 Feb 2015 20:12:21 +0000, Mel Beckman said: > Two pages? Read the news, man. It's been widely reported that the actual > Order runs to over 300 pages! It was also "widely reported" that the Affordable Care Act was 20,000 pages, when in fact it was about 1,900. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From dtaylor at vocalabs.com Fri Feb 27 20:36:03 2015 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Fri, 27 Feb 2015 14:36:03 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> Message-ID: <54F0D533.70100@vocalabs.com> My point is that the option should be there, at the consumer level. If not for fully symmetrical service (I admit that 50MB/s upstream is a tough pipe to fill), at least for significantly higher upstream service than is currently available in most neighborhoods. There are so many use cases for this, everything from personal game servers to on-line backups, that the lack of such offerings is an indication of an unhealthy market. On 02/27/2015 02:25 PM, Scott Helms wrote: > Daniel, > > We'd have to come to some standard definition of, "But even if 1% of > users would reasonably be using a fully symmetric link to its > potential..." > > As I said, I have visibility into a large number of symmetric > connections and without exception they'd fit well into a plan that > offered upstreams with that had a fractional speed of the downstream. > Now, keep in mind I'm not talking about 1/10 as a ratio here, but 1/5 > would accommodate ~99.2% and 1/4 would fit ~99.9%. It's also > important to note that all of these accounts are in the >25mbps down > territory so their upstreams are >5mbps. > > What I see when I look at customer satisfaction ratings is a very > strong correlation with low uplink speeds and a high satisfaction rate > when we look at uplink speeds greater than 4mbps. What I don't see is > an increase in customer satisfaction as upload speeds go past ~6mbps. > Conversely, increases in customer satisfaction with correlate with > increases in download speeds past ~30mbps before the correlation > starts weakening. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 2:57 PM, Daniel Taylor > wrote: > > The statistics certainly *should* be used when provisioning > aggregate resources. > But even if 1% of users would reasonably be using a fully > symmetric link to its potential, that's a good reason to at least > have such circuits available in the standard consumer mix, which > they aren't today. > > On 02/27/2015 01:30 PM, Scott Helms wrote: > > Daniel, > > Well, I wouldn't call using the mean a "myth", after all > understanding most customer behavior is what we all have to > build our business cases around. If we throw out what > customers use today and simply take a build it and they will > come approach then I suspect there would fewer of us in this > business. > > Even when we look at anomalous users we don't see symmetrical > usage, ie top 10% of uploaders. We also see less contended > seconds on their upstream than we do on the downstream. These > observations are based on ~500k residential and business > subscribers across North America using FTTH (mostly GPON), > DOCSIS cable modems, and various flavors of DSL. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 2:21 PM, Daniel Taylor > > >> > wrote: > > But by this you are buying into the myth of the mean. > > It isn't that most, or even many, people would take > advantage of > equal upstream bandwidth, but that the few who would need > to take > extra measures unrelated to the generation of that content > to be > able to do so. > > Given symmetrical provisioning, no extra measures need to > be taken > when that 10 year old down the street turns out to be a master > musician. > > On 02/27/2015 11:59 AM, Scott Helms wrote: > > This is true in our measurements today, even when > subscribers > are given > symmetrical connections. It might change at some > point in the > future, > especially when widespread IPv6 lets us get rid of NAT > as a de > facto > deployment reality. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 12:48 PM, Naslund, Steve > -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From Valdis.Kletnieks at vt.edu Fri Feb 27 20:36:38 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Feb 2015 15:36:38 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: Your message of "Fri, 27 Feb 2015 19:32:38 +0000." <20150227.193238.315861968627315258.wwaites@tardis.ed.ac.uk> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> <20150227.193238.315861968627315258.wwaites@tardis.ed.ac.uk> Message-ID: <20131.1425069398@turing-police.cc.vt.edu> On Fri, 27 Feb 2015 19:32:38 +0000, William Waites said: > for them to upload their photographs. Multi-party videoconferencing > doesn't work well unless at least one participant (or a server) is on > good, symmetric bandwidth. There's no need for good symmetric bandwidth. There's just need for good bandwidth. If my video requires 5MBit/sec in each direction, I only need 5MBit/sec in each direction. So provisioning a 50/10 that has at least 5 idle on both sides is suitable, but a 50/50 that only has 3 available on one side because somebody else is using 47 for other stuff isn't suitable. Now, if all you use the circuit for is videoconferencing, then yes, you'll end up with effectively needing near-symmetric bandwidth. However, I'm not seeing any reason to expect that we're going to move away from downstream-heavy applications anytime soon. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From pj at bind.com Wed Feb 25 00:14:28 2015 From: pj at bind.com (PJ) Date: Tue, 24 Feb 2015 16:14:28 -0800 Subject: Mobile/Cell multipoint latency monitoring Message-ID: Hello Nanog, I'm currently tasked with finding a solution that will either monitor or report on internet latency to our mobile game servers from various points worldwide but using cellular networks. Does anyone know of any provider who does this? From ryan.dirocco at totalserversolutions.com Thu Feb 26 15:01:48 2015 From: ryan.dirocco at totalserversolutions.com (Ryan DiRocco) Date: Thu, 26 Feb 2015 15:01:48 +0000 Subject: reachability to AS3215 / AS5511 Message-ID: Looking for a contact at orange 3215 / opentransit 5511 to resolve some reachability/blackhole issues for clients originating at 3215 reaching us at 46562. Please contact me off-list. From khelms at zcorum.com Fri Feb 27 20:42:17 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 15:42:17 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: '"Normal" is whatever the user normally tries to do.' That's simply not a realistic definition. There's no way to determine what a consumer will want to do before they sign up for the service. For that matter, it's impossible to determine what a customer will want 2 years after they've signed. Further, its impossible to understand what is normal without spying on your customers. '"Reasonable" is whatever the user is willing to pay for. Any mismatch between the two finds its error in your marketing department.' Reasonable pricing is what the market will bear as always, but what the market will bear versus what customers *expect* often greatly diverge. Anyone who wants to pay for a direct connection to a Tier 1 of their choice with SLAs can do so, but that's not that doesn't happen. 'Seems like a competitive service provider focused on meeting that customer population's needs would do well. Any notion what has prevented that from happening?' They *are *the alternative operator in this market. What's keeping anyone else from doing it better is that it's more expensive than customers will pay to "do it better". Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 3:17 PM, William Herrin wrote: > On Fri, Feb 27, 2015 at 3:01 PM, Scott Helms wrote: > > The problem is in defining what is "normal" and "reasonable" when > customers > > only know what those mean in regards to their behavior and not the larger > > customer base nor the behavior of the global network. > > Hi Scott, > > "Normal" is whatever the user normally tries to do. "Reasonable" is > whatever the user is willing to pay for. Any mismatch between the two > finds its error in your marketing department. > > If your understanding of normal and reasonable radically diverges from > this, you've made a mistake. It's exactly as simple as this. > > > > I have a customer on the west coast that has a very large Asian immigrant > > population and a very high percentage of the traffic from this access > > provider is going to and from Asia. This introduces a lot of variables > that > > are far outside of the operator's control, so what's reasonable for this > > operator to do to ensure "reasonable" speeds when the links to Asia get > > saturated far upstream of them? They certainly could choose to buy > > alternative connectivity to that region, but then they'd have to raise > rates > > and most of the time that extra connectivity isn't needed. > > So what are they doing? Playing it one-size-fits-all and giving this > "very large" customer population no way to get acceptable speed to the > portions of the Internet that population wants to reach? > > Seems like a competitive service provider focused on meeting that > customer population's needs would do well. Any notion what has > prevented that from happening? > > Regards, > Bill Herrin > > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From asr at latency.net Fri Feb 27 20:44:19 2015 From: asr at latency.net (Adam Rothschild) Date: Fri, 27 Feb 2015 15:44:19 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: I interpreted the FCC press release[*] to apply these provisions to "broadband access" providers only -- that is to say, not hosters, nor CDNs. It will indeed be interesting to see how this works once the full documentation is released. FWIW, -a [*] http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0226/DOC-332260A1.pdf On Fri, Feb 27, 2015 at 2:49 PM, McElearney, Kevin wrote: > [Sorry for top-posting] > > I actually think you are both right and partially wrong. It IS the ISPs > responsibility to provide you with the broadband that was advertised and > you paid for. This is also measured today by the FCC through Measuring > Broadband America. > http://data.fcc.gov/download/measuring-broadband-america/2014/2014-Fixed-Me > asuring-Broadband-America-Report.pdf > > That said, your ISP is NOT “the Internet” and can’t guarantee “access the > Internet sites of my choice at X megabits per second." While ISPs do take > the phone call for all Internet problems (sometimes not very well), they > certainly don’t control all levels of the QoE. ASPs may have server/site > issues internally, CDNs may purposely throttle downloads (content owners > contract commits), not all transit ISPs are created equal, TCP distance > limitations, etc. > > What would be interesting is if all these rules/principals and > transparency requirements were to be applied to all involved in the > consumer QoE. > > - Kevin > > On 2/27/15, 1:34 PM, "Mel Beckman" wrote: > >>Bill, >> >>This is not feasible. ISPs work by oversubscription, so it's never >>possible for all (or even 10% of all) customers to simultaneously demand >>their full bandwidth. If ISPs had to reserve the full bandwidth sold to >>each customer in order to "do everything reasonably within your power to >>make sure I can access the Internet sites of my choice at X megabits per >>second", then broadband connections would cost thousands of dollars per >>month. >> >>Anyone who doesn't understand this fundamental fact of Internet >>distribution will be unable to engage in reasonable discussion about ISP >>practices. >> >>On Feb 27, 2015, at 9:56 AM, William Herrin >>> >> wrote: >> >>Deceit is Bad Behavior. If you sell me an X megabit per second >>Internet access service, you should do everything reasonably within >>your power to make sure I can access the Internet sites of my choice >>at X megabits per second. >> > From mfidelman at meetinghouse.net Fri Feb 27 20:47:58 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 27 Feb 2015 15:47:58 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> Message-ID: <54F0D7FE.9030905@meetinghouse.net> Folks, Let's not go overboard here. Can we remember that most corporate and campus (and, for that matter home) networks are symmetric, at least at the edges. Personally, I figure that by deploying PON, the major carriers were just asking for trouble down the line. It's not like carrier-grade gigE switches are that much more expensive than PON gear. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From khelms at zcorum.com Fri Feb 27 20:53:37 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 15:53:37 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0D533.70100@vocalabs.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> Message-ID: "My point is that the option should be there, at the consumer level." Why? What's magical about symmetry? Is a customer better served by having a 5mbps/5mbps over a 25mbps/5mbps? "There are so many use cases for this, everything from personal game servers to on-line backups, that the lack of such offerings is an indication of an unhealthy market." Until we get NAT out of the way, this is actually much harder to leverage than you might think. I don't think there is anything special about symmetrical bandwidth, I do think upstream bandwidth usage is going up and will continue to go up, but I don't see any evidence in actual performance stats or customers sentiment to show that it's going up as fast as downstream demand. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 3:36 PM, Daniel Taylor wrote: > My point is that the option should be there, at the consumer level. > > If not for fully symmetrical service (I admit that 50MB/s upstream is a > tough pipe to fill), at least for significantly higher upstream service > than is currently available in most neighborhoods. > > There are so many use cases for this, everything from personal game > servers to on-line backups, that the lack of such offerings is an > indication of an unhealthy market. > > On 02/27/2015 02:25 PM, Scott Helms wrote: > >> Daniel, >> >> We'd have to come to some standard definition of, "But even if 1% of >> users would reasonably be using a fully symmetric link to its potential..." >> >> As I said, I have visibility into a large number of symmetric connections >> and without exception they'd fit well into a plan that offered upstreams >> with that had a fractional speed of the downstream. Now, keep in mind I'm >> not talking about 1/10 as a ratio here, but 1/5 would accommodate ~99.2% >> and 1/4 would fit ~99.9%. It's also important to note that all of these >> accounts are in the >25mbps down territory so their upstreams are >5mbps. >> >> What I see when I look at customer satisfaction ratings is a very strong >> correlation with low uplink speeds and a high satisfaction rate when we >> look at uplink speeds greater than 4mbps. What I don't see is an increase >> in customer satisfaction as upload speeds go past ~6mbps. Conversely, >> increases in customer satisfaction with correlate with increases in >> download speeds past ~30mbps before the correlation starts weakening. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Fri, Feb 27, 2015 at 2:57 PM, Daniel Taylor > > wrote: >> >> The statistics certainly *should* be used when provisioning >> aggregate resources. >> But even if 1% of users would reasonably be using a fully >> symmetric link to its potential, that's a good reason to at least >> have such circuits available in the standard consumer mix, which >> they aren't today. >> >> On 02/27/2015 01:30 PM, Scott Helms wrote: >> >> Daniel, >> >> Well, I wouldn't call using the mean a "myth", after all >> understanding most customer behavior is what we all have to >> build our business cases around. If we throw out what >> customers use today and simply take a build it and they will >> come approach then I suspect there would fewer of us in this >> business. >> >> Even when we look at anomalous users we don't see symmetrical >> usage, ie top 10% of uploaders. We also see less contended >> seconds on their upstream than we do on the downstream. These >> observations are based on ~500k residential and business >> subscribers across North America using FTTH (mostly GPON), >> DOCSIS cable modems, and various flavors of DSL. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Fri, Feb 27, 2015 at 2:21 PM, Daniel Taylor >> >> >> >> wrote: >> >> But by this you are buying into the myth of the mean. >> >> It isn't that most, or even many, people would take >> advantage of >> equal upstream bandwidth, but that the few who would need >> to take >> extra measures unrelated to the generation of that content >> to be >> able to do so. >> >> Given symmetrical provisioning, no extra measures need to >> be taken >> when that 10 year old down the street turns out to be a master >> musician. >> >> On 02/27/2015 11:59 AM, Scott Helms wrote: >> >> This is true in our measurements today, even when >> subscribers >> are given >> symmetrical connections. It might change at some >> point in the >> future, >> especially when widespread IPv6 lets us get rid of NAT >> as a de >> facto >> deployment reality. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Fri, Feb 27, 2015 at 12:48 PM, Naslund, Steve >> >> > -- > Daniel Taylor VP Operations Vocal Laboratories, Inc. > dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 > > From jeff at briworks.com Fri Feb 27 20:55:59 2015 From: jeff at briworks.com (Jeff Cornejo) Date: Fri, 27 Feb 2015 20:55:59 +0000 Subject: Mobile/Cell multipoint latency monitoring In-Reply-To: References: Message-ID: <7385EF30-9C67-4636-90A9-CCB887D583EC@briworks.com> http://www.netforecast.com has a product that may work for you. jeff cornejo blue ridge internetworks 321 east main st • suite 200 charlottesville va 22902 434.817.0707 x 2001 www.briworks.com Central Virginia’s technology authority since 2000. > On Feb 24, 2015, at 7:14 PM, PJ wrote: > > Hello Nanog, I'm currently tasked with finding a solution that will either > monitor or report on internet latency to our mobile game servers from > various points worldwide but using cellular networks. Does anyone know of > any provider who does this? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bill at herrin.us Fri Feb 27 20:59:59 2015 From: bill at herrin.us (William Herrin) Date: Fri, 27 Feb 2015 15:59:59 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: On Fri, Feb 27, 2015 at 3:20 PM, Mel Beckman wrote: > I did not change "whenever I demand it" to "all the time". You're > hand-waving now. I clearly said that users can't all demand their maximum > bandwidth at the same time. That's nothing like "all the time." Fine. You changed "whenever I demand it" to "at the same time as everybody else." The change still makes it a straw man argument. You introduce simultaneity, which you don't substantiate and which is not present in my statement. That red herring undermines your argument that doing, "everything reasonably within your power to make sure I can access the Internet sites of my choice" at full rate is "infeasible." > Your shower example is perfect. Yes, you can get 120A tankless water heating > for a brief interval. But not "whenever you demand it." I get it _every_ time I demand it because the local power company has done a good job with their oversubscription planning. Even with other households engaged in bathing activity during the morning hours.. > You never responded to my "BillsNet" real-world example. Is that a straw-man > argument too? That would be why I ignored it, yes. Would it make you happy if I pick it apart piece by piece or do you want to move on? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From dtaylor at vocalabs.com Fri Feb 27 21:05:24 2015 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Fri, 27 Feb 2015 15:05:24 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> Message-ID: <54F0DC14.1010801@vocalabs.com> On 02/27/2015 02:53 PM, Scott Helms wrote: > "My point is that the option should be there, at the consumer level." > > Why? What's magical about symmetry? Is a customer better served by > having a 5mbps/5mbps over a 25mbps/5mbps? > Why not 25/25? 50MB/s might be tough to fill, but even at home I can get good use out of the odd 25MB/s upstream burst for a few minutes. > > "There are so many use cases for this, everything from personal game > servers to on-line backups, that the lack of such offerings is an > indication of an unhealthy market." > > Until we get NAT out of the way, this is actually much harder to > leverage than you might think. I don't think there is anything > special about symmetrical bandwidth, I do think upstream bandwidth > usage is going up and will continue to go up, but I don't see any > evidence in actual performance stats or customers sentiment to show > that it's going up as fast as downstream demand. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 3:36 PM, Daniel Taylor > wrote: > > My point is that the option should be there, at the consumer level. > > If not for fully symmetrical service (I admit that 50MB/s upstream > is a tough pipe to fill), at least for significantly higher > upstream service than is currently available in most neighborhoods. > > There are so many use cases for this, everything from personal > game servers to on-line backups, that the lack of such offerings > is an indication of an unhealthy market. > > On 02/27/2015 02:25 PM, Scott Helms wrote: > > Daniel, > > We'd have to come to some standard definition of, "But even if > 1% of users would reasonably be using a fully symmetric link > to its potential..." > > As I said, I have visibility into a large number of symmetric > connections and without exception they'd fit well into a plan > that offered upstreams with that had a fractional speed of the > downstream. Now, keep in mind I'm not talking about 1/10 as a > ratio here, but 1/5 would accommodate ~99.2% and 1/4 would fit > ~99.9%. It's also important to note that all of these > accounts are in the >25mbps down territory so their upstreams > are >5mbps. > > What I see when I look at customer satisfaction ratings is a > very strong correlation with low uplink speeds and a high > satisfaction rate when we look at uplink speeds greater than > 4mbps. What I don't see is an increase in customer > satisfaction as upload speeds go past ~6mbps. Conversely, > increases in customer satisfaction with correlate with > increases in download speeds past ~30mbps before the > correlation starts weakening. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 2:57 PM, Daniel Taylor > > >> > wrote: > > The statistics certainly *should* be used when provisioning > aggregate resources. > But even if 1% of users would reasonably be using a fully > symmetric link to its potential, that's a good reason to > at least > have such circuits available in the standard consumer mix, > which > they aren't today. > > On 02/27/2015 01:30 PM, Scott Helms wrote: > > Daniel, > > Well, I wouldn't call using the mean a "myth", after all > understanding most customer behavior is what we all > have to > build our business cases around. If we throw out what > customers use today and simply take a build it and > they will > come approach then I suspect there would fewer of us > in this > business. > > Even when we look at anomalous users we don't see > symmetrical > usage, ie top 10% of uploaders. We also see less > contended > seconds on their upstream than we do on the > downstream. These > observations are based on ~500k residential and business > subscribers across North America using FTTH (mostly GPON), > DOCSIS cable modems, and various flavors of DSL. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 2:21 PM, Daniel Taylor > > > > >>> > wrote: > > But by this you are buying into the myth of the mean. > > It isn't that most, or even many, people would take > advantage of > equal upstream bandwidth, but that the few who > would need > to take > extra measures unrelated to the generation of that > content > to be > able to do so. > > Given symmetrical provisioning, no extra measures > need to > be taken > when that 10 year old down the street turns out to > be a master > musician. > > On 02/27/2015 11:59 AM, Scott Helms wrote: > > This is true in our measurements today, even when > subscribers > are given > symmetrical connections. It might change at some > point in the > future, > especially when widespread IPv6 lets us get > rid of NAT > as a de > facto > deployment reality. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > > > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 12:48 PM, Naslund, Steve > > > -- > Daniel Taylor VP Operations Vocal > Laboratories, Inc. > dtaylor at vocalabs.com > http://www.vocalabs.com/ (612)235-5711 > > -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From list at satchell.net Fri Feb 27 21:10:42 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 27 Feb 2015 13:10:42 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725DE54@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <54F0A62C.70704@paradoxnetworks.net> <9578293AE169674F9A048B2BC9A081B4015725DE54@MUNPRDMBXA1.medline.com> Message-ID: <54F0DD52.4040409@satchell.net> On 02/27/2015 09:40 AM, Naslund, Steve wrote: > If people want a different ratio of up to downlink speed it could > certainly be done. ADSL is by definition asymmetric. We also sold > SDSL which is symmetric service and the primary buyers were generally > businesses. See G.SHDSL if you want a standard for symmetric DSL. > It's there, it is just not a popular. When I was involved with private-loop provision, what I noticed here in northern Nevada is that the provisioning of T1 circuits moved from baseband signalling to SDSL. From the standpoint of cable management, the splatter from SDSL was MUCH lower than the splattering of baseband T1, so instead of being limited to a single T1 circuit per 25-pair bundle, you could have several circuits. TIA T1Q1 has quite a lot to say on this. From khelms at zcorum.com Fri Feb 27 21:11:52 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 16:11:52 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0DC14.1010801@vocalabs.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> Message-ID: Daniel, "50MB/s might be tough to fill, but even at home I can get good use out of the odd 25MB/s upstream burst for a few minutes." Which would you choose, 50/50 or 75/25? My point is not that upstream speed isn't valuable, but merely that demand for it isn't symmetrical and unless the market changes won't be in the near term. Downstream demand is growing, in most markets I can see, much faster than upstream demand. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From mel at beckman.org Fri Feb 27 21:13:30 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 27 Feb 2015 21:13:30 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> , Message-ID: <7DD59121-5D6F-47A4-885A-7544783BD29A@beckman.org> I'll move on. I'm sorry you're not interested in reasonable discussion. -mel beckman > On Feb 27, 2015, at 1:01 PM, "William Herrin" wrote: > >> On Fri, Feb 27, 2015 at 3:20 PM, Mel Beckman wrote: >> I did not change "whenever I demand it" to "all the time". You're >> hand-waving now. I clearly said that users can't all demand their maximum >> bandwidth at the same time. That's nothing like "all the time." > > Fine. You changed "whenever I demand it" to "at the same time as > everybody else." The change still makes it a straw man argument. You > introduce simultaneity, which you don't substantiate and which is not > present in my statement. That red herring undermines your argument > that doing, "everything reasonably within your power to make sure I > can access the Internet sites of my choice" at full rate is > "infeasible." > > >> Your shower example is perfect. Yes, you can get 120A tankless water heating >> for a brief interval. But not "whenever you demand it." > > I get it _every_ time I demand it because the local power company has > done a good job with their oversubscription planning. Even with other > households engaged in bathing activity during the morning hours.. > > >> You never responded to my "BillsNet" real-world example. Is that a straw-man >> argument too? > > That would be why I ignored it, yes. Would it make you happy if I pick > it apart piece by piece or do you want to move on? > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: From khelms at zcorum.com Fri Feb 27 21:16:52 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 16:16:52 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F0D7FE.9030905@meetinghouse.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D7FE.9030905@meetinghouse.net> Message-ID: Hardened carrier grade Ethernet gear appeared quite a time after PON gear did and until we got gear that could be deployed in cabinets the cost of the fiber plant being back hauled to the CO was much more expensive. Google decided to do GPON purely because of cost, they really wanted to do Active Ethernet but the economics didn't work out. "Can we remember that most corporate and campus (and, for that matter home) networks are symmetric, at least at the edges." Only if we're talking about Ethernet, your WiFi network is almost never symmetrical. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 3:47 PM, Miles Fidelman wrote: > Folks, > > Let's not go overboard here. Can we remember that most corporate and > campus (and, for that matter home) networks are symmetric, at least at the > edges. Personally, I figure that by deploying PON, the major carriers were > just asking for trouble down the line. It's not like carrier-grade gigE > switches are that much more expensive than PON gear. > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > From morrowc.lists at gmail.com Fri Feb 27 21:16:56 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 27 Feb 2015 16:16:56 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> Message-ID: On Fri, Feb 27, 2015 at 3:53 PM, Scott Helms wrote: > "My point is that the option should be there, at the consumer level." > > Why? What's magical about symmetry? Is a customer better served by having > a 5mbps/5mbps over a 25mbps/5mbps? it sort of depends on what the user is doing, right? there's some chatter that (queue akapella in 3...2....) upstream ack packet loss is actually more detrimental to user experience than downstream packet loss, so maybe more upstream just to protect (and simplify) ack management is helpful? > "There are so many use cases for this, everything from personal game > servers to on-line backups, that the lack of such offerings is an > indication of an unhealthy market." > > Until we get NAT out of the way, this is actually much harder to leverage > than you might think. I don't think there is anything special about because gameservers, backups, etc don't work just fine today in the 'world of nat' ??? I'm fairly certain that I can do backups to carbonite/etc with my nat working just fun, right? I'm also fairly certain that WoW (or whatever, hell I don't play games, so I'll just say: "Angband") etc that turn the fastest user in the group into a server also work just fine... > symmetrical bandwidth, I do think upstream bandwidth usage is going up and > will continue to go up, but I don't see any evidence in actual performance > stats or customers sentiment to show that it's going up as fast as > downstream demand. possibly because the places where this is available are so few and so far-between that 'users' don't generally know or see this? so ... err, they won't know if it's better for their usecases or not. From khelms at zcorum.com Fri Feb 27 21:21:00 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 16:21:00 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> Message-ID: Chris, "because gameservers, backups, etc don't work just fine today in the 'world of nat' ??? I'm fairly certain that I can do backups to carbonite/etc with my nat working just fun, right? I'm also fairly certain that WoW (or whatever, hell I don't play games, so I'll just say: "Angband") etc that turn the fastest user in the group into a server also work just fine..." Talk to someone at Carbonite and ask them how much effort they have to exert to make that work. Also, keep in mind that your game example is not someone running a game server as a residential subscriber, it's a residential subscriber accessing a server hosted on a dedicated network. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 4:16 PM, Christopher Morrow wrote: > On Fri, Feb 27, 2015 at 3:53 PM, Scott Helms wrote: > > "My point is that the option should be there, at the consumer level." > > > > Why? What's magical about symmetry? Is a customer better served by > having > > a 5mbps/5mbps over a 25mbps/5mbps? > > it sort of depends on what the user is doing, right? > there's some chatter that (queue akapella in 3...2....) upstream ack > packet loss is actually more detrimental to user experience than > downstream packet loss, so maybe more upstream just to protect (and > simplify) ack management is helpful? > > > "There are so many use cases for this, everything from personal game > > servers to on-line backups, that the lack of such offerings is an > > indication of an unhealthy market." > > > > Until we get NAT out of the way, this is actually much harder to leverage > > than you might think. I don't think there is anything special about > > because gameservers, backups, etc don't work just fine today in the > 'world of nat' ??? I'm fairly certain that I can do backups to > carbonite/etc with my nat working just fun, right? I'm also fairly > certain that WoW (or whatever, hell I don't play games, so I'll just > say: "Angband") etc that turn the fastest user in the group into a > server also work just fine... > > > symmetrical bandwidth, I do think upstream bandwidth usage is going up > and > > will continue to go up, but I don't see any evidence in actual > performance > > stats or customers sentiment to show that it's going up as fast as > > downstream demand. > > possibly because the places where this is available are so few and so > far-between that 'users' don't generally know or see this? so ... err, > they won't know if it's better for their usecases or not. > From list at satchell.net Fri Feb 27 21:27:53 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 27 Feb 2015 13:27:53 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <20150227165240.GA13738@puck.nether.net> <54F0AE3B.2010209@sprunk.org> <54F0B517.4050200@invaluement.com> <54F0B751.30008@pari.edu> <54F0C486.6010506@ufl.edu> Message-ID: <54F0E159.2000804@satchell.net> One of the FUD items I keep seeing from some factions is that the FCC will regulate content on the Internet in the same way as they did for television during the time of the "fairness doctrine". In particular, these people *expect* the FCC to take a page from the IRS and start putting up roadblocks, if not outright blocks, on political content on views that differs from the views of the controlling Administration. Now, the Fairness Doctrine was not part of Title II, I agree. But we never expected the IRS to play favorites with not-for-profit organizations, either. On 02/27/2015 11:32 AM, Scott Helms wrote: > While I view that statement with trepidation, my first guess would one that > isn't in violation of state or federal law. About the only things I can > think off hand, ie stuff we get told to take down as hosters today, are > sites violating copyright law and child pornography. I hope that we don't > see any additions to that list. >> On 2015-02-27 14:14, Jim Richardson wrote: >> >>> What's a "lawful" web site? >>> >>> Now *there* is a $64,000 question. Even more interesting is, "Who gets >> to decide day to day the answer to that question?" :) From jbates at paradoxnetworks.net Fri Feb 27 21:27:50 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Fri, 27 Feb 2015 15:27:50 -0600 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F0D7FE.9030905@meetinghouse.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D7FE.9030905@meetinghouse.net> Message-ID: <54F0E156.7050504@paradoxnetworks.net> On 2/27/2015 2:47 PM, Miles Fidelman wrote: > Folks, > > Let's not go overboard here. Can we remember that most corporate and > campus (and, for that matter home) networks are symmetric, at least at > the edges. Personally, I figure that by deploying PON, the major > carriers were just asking for trouble down the line. It's not like > carrier-grade gigE switches are that much more expensive than PON gear. > I'll disagree on the home part. I doubt that most homes are symmetric. Of course, what needs to happen is for standards bodies to start thinking more dynamic when they build their protocols where possible. Passive splitters obviously have the limitation of limiting frequencies, but our xDSL technologies and cable technologies do not have the restriction to my knowledge. Future protocols ideally would have a signaling band, recognition of frequency support bidirectionally and perhaps support dynamic allocation of those channels as-needed. If an end node is saturating the upload but not using the download, why shouldn't the system shift the frequency usage? If only 10mb/s is being used out of a 50mb/s circuit for download, why not allow that extra capacity to be used for upload, temporarily shifting it's direction? My 2 cents. I don't design these things, but you'd think people would start realizing that static allocation is kind of limiting. Giving someone 50mb/s with 20mb/s waste is annoying when they are saturating 3mb/s the opposite direction. Wouldn't it be cool if your backup at night could use 50mb/s upstream and drop your downstream to 5mb/s because you aren't downloading anything? For that matter, is there a reason we don't dynamically adjust frequencies on Ethernet? My servers would definitely love 1.8gb/s transmit since they receive very little. Jack From morrowc.lists at gmail.com Fri Feb 27 21:29:46 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 27 Feb 2015 16:29:46 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> Message-ID: On Fri, Feb 27, 2015 at 4:21 PM, Scott Helms wrote: > Chris, > > "because gameservers, backups, etc don't work just fine today in the > 'world of nat' ??? I'm fairly certain that I can do backups to > carbonite/etc with my nat working just fun, right? I'm also fairly > certain that WoW (or whatever, hell I don't play games, so I'll just > say: "Angband") etc that turn the fastest user in the group into a > server also work just fine..." > > Talk to someone at Carbonite and ask them how much effort they have to exert hopefully not much since it's rsync (or was). I'm not sure I care a lot though if they have to run a stun/ice server... that's part of the payment I make to them, right? > to make that work. Also, keep in mind that your game example is not someone > running a game server as a residential subscriber, it's a residential > subscriber accessing a server hosted on a dedicated network. no it wasn't. Blizzard or one of the others used to select the 'fastest player' to be the server for group play... my son has a minecraft server as well behind nat, his pals all over play on it just fine. It happens to have v6, but because the minecraft people are apparently stuck in 1972 only v4 is a configurable transport option, and the clients won't make AAAA queries so my AAAA is a wasted dns few bytes. Frankly folk that want to keep stomping up and down about NAT being a problem are delusional. Sure direct access is nice, it simple and whatnot, but ... really... stuff just works behind NAT as well. -chris From list at satchell.net Fri Feb 27 21:40:09 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 27 Feb 2015 13:40:09 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <70010365-D40C-4DCA-AF39-DD872755AB5E@beckman.org> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> <70010365-D40C-4DCA-AF39-DD872755AB5E@beckman.org> Message-ID: <54F0E439.9090208@satchell.net> On 02/27/2015 11:57 AM, Mel Beckman wrote: > It is NOT the ISP's responsibility to provide you with X Mbps if that > was advertised as "UP TO x Mbps" (which is exactly how every > broadband provider advertises its service -- check your contract). > We're not talking about the Internet's capacity here. We're talking > about the physical limits of an ISPs own uplink connection to the > Internet. That costs much more than the income from the number of > users it takes to saturate the uplink. If you want guarantees, you make sure your contract specifies those guarantees in the Service Level Agreement section. * Errored seconds * Minimum upstream bandwidth * Minimum downstream bandwidth The larger the bandwidth and fewer errored seconds, the higher the cost. With my "business-grade" cable service (Charter), I have *no* such guarantees. It's all "best effort". Indeed, with the SOHO/home grade equipment, you can't measure errored seconds at all -- if it's there, I haven't found it yet. Now, I run a mail server that serves my building, so my need is for more downstream capacity than upstream (I don't send a huge amount of mail). Unlike an ISP, I don't have people from the outside using POP or IMAP, so my mail server's outbound traffic is minimal. As for bulk data transfer, Dropbox works well enough with the asymmetric circuit. Even though there is no SLA, my service is better than the typical residential Internet provisioning. And I pay for that improvement, about 4x. From jbates at paradoxnetworks.net Fri Feb 27 21:40:03 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Fri, 27 Feb 2015 15:40:03 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> Message-ID: <54F0E433.6050809@paradoxnetworks.net> On 2/27/2015 3:21 PM, Scott Helms wrote: > Talk to someone at Carbonite and ask them how much effort they have to > exert to make that work. Also, keep in mind that your game example is not > someone running a game server as a residential subscriber, it's a > residential subscriber accessing a server hosted on a dedicated network. > > > Chris meant to say, "insert game console shooting game here". As a side note, most of my DDOS attacks on end-users these days are due to game console pissing matches rather than forum/irc. Jack From Curtis.Parish at mtsu.edu Fri Feb 27 21:38:20 2015 From: Curtis.Parish at mtsu.edu (Curtis L. Parish) Date: Fri, 27 Feb 2015 21:38:20 +0000 Subject: One FCC neutrality elephant: disabilities compliance In-Reply-To: <19998.1425069314@turing-police.cc.vt.edu> References: <54F0BCD2.50105@pari.edu> <2D167235-5C33-4CD9-B3B8-BC33E06AA0DA@beckman.org> <19998.1425069314@turing-police.cc.vt.edu> Message-ID: <848A0CCBF45ABC49B103A3733FA46C507EFCB3A2@MTEXMBC01.fsa.mtsu.edu> Way off topic but the Act may had around 2K pages but the rules and regulations go with it are at 20K and counting . That is what people are referring to. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Valdis.Kletnieks at vt.edu Sent: Friday, February 27, 2015 2:35 PM To: Mel Beckman Cc: Subject: Re: One FCC neutrality elephant: disabilities compliance On Fri, 27 Feb 2015 20:12:21 +0000, Mel Beckman said: > Two pages? Read the news, man. It's been widely reported that the > actual Order runs to over 300 pages! It was also "widely reported" that the Affordable Care Act was 20,000 pages, when in fact it was about 1,900. From khelms at zcorum.com Fri Feb 27 21:41:46 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 16:41:46 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> Message-ID: "hopefully not much since it's rsync (or was). I'm not sure I care a lot though if they have to run a stun/ice server... that's part of the payment I make to them, right?" Sure it is, but the point is if it's easier to deliver then the price will go down and more people will choose to use it. That's kind of my point. Carbonite (and others) have built a decent business, but imagine if their costs were cut by ~15% because they didn't have to deal with NAT transversal they could offer more services for the same amount of money or offer the same service for less. Either would result in more people using that kind of service. Imagine what *might *be possible if direct communication would work without port forwarding rules inside your neighborhood. "no it wasn't. Blizzard or one of the others used to select the 'fastest player' to be the server for group play..." That's not WoW, it might be Diablo III or StarCraft (both Blizzard products) "my son has a minecraft server as well behind nat, his pals all over play on it just fine. It happens to have v6, but because the minecraft people are apparently stuck in 1972 only v4 is a configurable transport option, and the clients won't make AAAA queries so my AAAA is a wasted dns few bytes. Frankly folk that want to keep stomping up and down about NAT being a problem are delusional. Sure direct access is nice, it simple and whatnot, but ... really... stuff just works behind NAT as well." It doesn't "just work" there is a real cost and complexity even if you're using UPNP or you're comfortable doing the port forwarding manually to get around it to a certain extent. Session border controllers cost tens of thousands of dollars to handle SIP sessions behind NAT. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 4:29 PM, Christopher Morrow wrote: > On Fri, Feb 27, 2015 at 4:21 PM, Scott Helms wrote: > > Chris, > > > > "because gameservers, backups, etc don't work just fine today in the > > 'world of nat' ??? I'm fairly certain that I can do backups to > > carbonite/etc with my nat working just fun, right? I'm also fairly > > certain that WoW (or whatever, hell I don't play games, so I'll just > > say: "Angband") etc that turn the fastest user in the group into a > > server also work just fine..." > > > > Talk to someone at Carbonite and ask them how much effort they have to > exert > > hopefully not much since it's rsync (or was). > I'm not sure I care a lot though if they have to run a stun/ice > server... that's part of the payment I make to them, right? > > > to make that work. Also, keep in mind that your game example is not > someone > > running a game server as a residential subscriber, it's a residential > > subscriber accessing a server hosted on a dedicated network. > > no it wasn't. Blizzard or one of the others used to select the > 'fastest player' to be the server for group play... > > my son has a minecraft server as well behind nat, his pals all over > play on it just fine. It happens to have v6, but because the minecraft > people are apparently stuck in 1972 only v4 is a configurable > transport option, and the clients won't make AAAA queries so my AAAA > is a wasted dns few bytes. > > Frankly folk that want to keep stomping up and down about NAT being a > problem are delusional. Sure direct access is nice, it simple and > whatnot, but ... really... stuff just works behind NAT as well. > > -chris > From Jason_Livingood at cable.comcast.com Fri Feb 27 21:46:25 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 27 Feb 2015 21:46:25 +0000 Subject: What is lawful content? [was VZ...] Message-ID: I¹m not sure who gets to definitively answer the question (I would guess that case law will develop around it but IANAL), but this sort of caveat has been in the Open Internet rules for awhile. In general it means ISPs can¹t block stuff like Facebook but have latitude to do stuff like block a site/IP address that may be the source of an attack, etc. - Jason On 2/27/15, 2:24 PM, "Bruce H McIntosh" wrote: > >On 2015-02-27 14:14, Jim Richardson wrote: >> What's a "lawful" web site? >> >Now *there* is a $64,000 question. Even more interesting is, "Who gets >to decide day to day the answer to that question?" :) From list at satchell.net Fri Feb 27 21:49:29 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 27 Feb 2015 13:49:29 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9A1524CD-F405-41CE-B613-4A5A38EABD4F@beckman.org> Message-ID: <54F0E669.50007@satchell.net> On 02/27/2015 12:44 PM, Adam Rothschild wrote: > I interpreted the FCC press release[*] to apply these provisions to > "broadband access" providers only -- that is to say, not hosters, nor > CDNs. It will indeed be interesting to see how this works once the > full documentation is released. So did I. Also, do you recall that the FCC changed the definition of "broadband" to require 25 Mbps downstream? Does this mean that all these rules on "broadband" don't apply to people providing Internet access service on classic ADSL? (#showerthought) From owen at delong.com Fri Feb 27 21:48:51 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Feb 2015 13:48:51 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F079AC.8020103@cox.net> References: <54F079AC.8020103@cox.net> Message-ID: <56B6EAC4-2BC7-48AB-B617-C95C069AD922@delong.com> While it’s amusing, it’s a serious distortion of the reality of the situation. Owen > On Feb 27, 2015, at 06:05 , Larry Sheldon wrote: > > http://publicpolicy.verizon.com/blog/entry/fccs-throwback-thursday-move-imposes-1930s-rules-on-the-internet > -- > The unique Characteristics of System Administrators: > > The fact that they are infallible; and, > > The fact that they learn from their mistakes. > > > Quis custodiet ipsos custodes From Jason_Livingood at cable.comcast.com Fri Feb 27 21:54:06 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 27 Feb 2015 21:54:06 +0000 Subject: Who is covered [was VZ...] Message-ID: I have the same question. No one will know for sure until the rules are released, but my guess is it potentially covers more than people may initially think. For example, I would guess many ³transit² networks will be covered since they also provide in many cases retail access to schools, hospitals, government, business, etc. It¹s not much of a stretch to see how CDNs, hosters, and others may be covered by at least parts of this, such as transparency/policy disclosure, maybe measurement. Blocking, throttling, and paid prioritization could also apply in some critical ways, especially given the % of Internet traffic that uses CDNs for example. Again, the key may be that there will be ambiguity that may only be sorted out as case law develops around each of these areas. But IANAL so I¹m just guessing like the rest of us for now! ;-) - Jason On 2/27/15, 3:44 PM, "Adam Rothschild" wrote: >I interpreted the FCC press release[*] to apply these provisions to >"broadband access" providers only -- that is to say, not hosters, nor >CDNs. It will indeed be interesting to see how this works once the full >documentation is released. > >FWIW, >-a > >[*] >http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0226/DOC-33 >2260A1.pdf > >On Fri, Feb 27, 2015 at 2:49 PM, McElearney, Kevin > wrote: >> [Sorry for top-posting] >> >> I actually think you are both right and partially wrong. It IS the ISPs >> responsibility to provide you with the broadband that was advertised and >> you paid for. This is also measured today by the FCC through Measuring >> Broadband America. >> >>http://data.fcc.gov/download/measuring-broadband-america/2014/2014-Fixed- >>Me >> asuring-Broadband-America-Report.pdf >> >> That said, your ISP is NOT ³the Internet² and can¹t guarantee ³access >>the >> Internet sites of my choice at X megabits per second." While ISPs do >>take >> the phone call for all Internet problems (sometimes not very well), they >> certainly don¹t control all levels of the QoE. ASPs may have >>server/site >> issues internally, CDNs may purposely throttle downloads (content owners >> contract commits), not all transit ISPs are created equal, TCP distance >> limitations, etc. >> >> What would be interesting is if all these rules/principals and >> transparency requirements were to be applied to all involved in the >> consumer QoE. >> >> - Kevin >> >> On 2/27/15, 1:34 PM, "Mel Beckman" wrote: >> >>>Bill, >>> >>>This is not feasible. ISPs work by oversubscription, so it's never >>>possible for all (or even 10% of all) customers to simultaneously demand >>>their full bandwidth. If ISPs had to reserve the full bandwidth sold to >>>each customer in order to "do everything reasonably within your power to >>>make sure I can access the Internet sites of my choice at X megabits per >>>second", then broadband connections would cost thousands of dollars per >>>month. >>> >>>Anyone who doesn't understand this fundamental fact of Internet >>>distribution will be unable to engage in reasonable discussion about ISP >>>practices. >>> >>>On Feb 27, 2015, at 9:56 AM, William Herrin >>>> >>> wrote: >>> >>>Deceit is Bad Behavior. If you sell me an X megabit per second >>>Internet access service, you should do everything reasonably within >>>your power to make sure I can access the Internet sites of my choice >>>at X megabits per second. >>> >> > From list at satchell.net Fri Feb 27 21:56:31 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 27 Feb 2015 13:56:31 -0800 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F0E156.7050504@paradoxnetworks.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D7FE.9030905@meetinghouse.net> <54F0E156.7050504@paradoxnetworks.net> Message-ID: <54F0E80F.50004@satchell.net> On 02/27/2015 01:27 PM, Jack Bates wrote: > My 2 cents. I don't design these things, but you'd think people would > start realizing that static allocation is kind of limiting. Giving > someone 50mb/s with 20mb/s waste is annoying when they are saturating > 3mb/s the opposite direction. Wouldn't it be cool if your backup at > night could use 50mb/s upstream and drop your downstream to 5mb/s > because you aren't downloading anything? That's possible with multicarrier technology, such as xDSL. When you get into the data-over-cable technology, you find a completely different story -- it's a system limitation that you have an upstream channel that is less efficient than the downstream channel because the upstream channel has to be accessed by a number of sources, with access control, whereas the downstream channel is nothing more than a broadcast pipe (just like 10base-2 Ethernet) where you pick your packets out of the stream. Other technologies have their quirks, too... From cidr-report at potaroo.net Fri Feb 27 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Feb 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201502272200.t1RM00F2003664@wattle.apnic.net> This report has been generated at Fri Feb 27 21:14:26 2015 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 20-02-15 538805 296230 21-02-15 539328 296368 22-02-15 539258 296450 23-02-15 539278 296680 24-02-15 539629 298059 25-02-15 540702 297505 26-02-15 538881 300039 27-02-15 541645 299392 AS Summary 49778 Number of ASes in routing system 19864 Number of ASes announcing only one prefix 3122 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120442368 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 27Feb15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 541748 299440 242308 44.7% All ASes AS22773 2985 170 2815 94.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2891 120 2771 95.8% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2819 77 2742 97.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 12 2461 99.5% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2328 311 2017 86.6% NET Servi�os de Comunica��o S.A.,BR AS4766 2909 1324 1585 54.5% KIXS-AS-KR Korea Telecom,KR AS7303 1790 280 1510 84.4% Telecom Argentina S.A.,AR AS9808 1546 67 1479 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS10620 3122 1701 1421 45.5% Telmex Colombia S.A.,CO AS6147 1574 160 1414 89.8% Telefonica del Peru S.A.A.,PE AS4755 1985 600 1385 69.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS6983 1623 249 1374 84.7% ITCDELTA - Earthlink, Inc.,US AS20115 1851 510 1341 72.4% CHARTER-NET-HKY-NC - Charter Communications,US AS8402 1332 25 1307 98.1% CORBINA-AS OJSC "Vimpelcom",RU AS7545 2587 1296 1291 49.9% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1627 407 1220 75.0% TWTC - tw telecom holdings, inc.,US AS8452 1767 572 1195 67.6% TE-AS TE-AS,EG AS9498 1300 111 1189 91.5% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2040 869 1171 57.4% MEGAPATH5-US - MegaPath Corporation,US AS7552 1134 54 1080 95.2% VIETEL-AS-AP Viettel Corporation,VN AS34984 1966 897 1069 54.4% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS3356 2569 1556 1013 39.4% LEVEL3 - Level 3 Communications, Inc.,US AS22561 1328 361 967 72.8% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6849 1196 259 937 78.3% UKRTELNET JSC UKRTELECOM,UA AS7738 1000 84 916 91.6% Telemar Norte Leste S.A.,BR AS38285 983 115 868 88.3% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4538 1776 939 837 47.1% ERX-CERNET-BKB China Education and Research Network Center,CN AS4780 1104 310 794 71.9% SEEDNET Digital United Inc.,TW AS26615 922 134 788 85.5% Tim Celular S.A.,BR AS24560 1195 421 774 64.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN Total 55722 13991 41731 74.9% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 23.252.224.0/20 AS62502 -Reserved AS-,ZZ 23.252.224.0/21 AS62502 -Reserved AS-,ZZ 23.252.232.0/21 AS62502 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 37.16.88.0/23 AS57652 -Reserved AS-,ZZ 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.24.0/23 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 -Reserved AS-,ZZ 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, Inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 67.210.0.0/20 AS62502 -Reserved AS-,ZZ 67.210.0.0/21 AS62502 -Reserved AS-,ZZ 67.210.8.0/21 AS62502 -Reserved AS-,ZZ 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 100.42.176.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc.,US 100.64.104.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.20.100.0/24 AS23937 103.20.101.0/24 AS23937 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.247.19.0/24 AS18107 ASN-IPSYSTEMS-AP IP SYSTEMS,AU 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.253.100.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.253.164.0/23 AS13317 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.217.156.0/22 AS62502 -Reserved AS-,ZZ 162.217.156.0/23 AS62502 -Reserved AS-,ZZ 162.217.158.0/23 AS62502 -Reserved AS-,ZZ 162.221.48.0/21 AS62502 -Reserved AS-,ZZ 162.221.48.0/22 AS62502 -Reserved AS-,ZZ 162.221.52.0/22 AS62502 -Reserved AS-,ZZ 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.223.64.0/21 AS62502 -Reserved AS-,ZZ 162.223.64.0/22 AS62502 -Reserved AS-,ZZ 162.223.68.0/22 AS62502 -Reserved AS-,ZZ 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.224.128.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc.,US 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.89.196.0/22 AS20122 IPBONE-AS Frieder Mueller,DE 185.89.204.0/24 AS20098 185.89.205.0/24 AS20098 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,FR 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 197.149.188.0/22 AS37282 MAINONE,NG 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.30.136.0/23 AS46636 NATCOWEB - NatCoWeb Corp.,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.204.144.0/21 AS36007 -Reserved AS-,ZZ 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.175.8.0/23 AS23858 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.189.0.0/19 AS46879 -Reserved AS-,ZZ 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.93.216.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 27 22:00:02 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Feb 2015 22:00:02 GMT Subject: BGP Update Report Message-ID: <201502272200.t1RM02Oh003692@wattle.apnic.net> BGP Update Report Interval: 19-Feb-15 -to- 26-Feb-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS2119 702188 10.3% 3221.0 -- TELENOR-NEXTEL Telenor Norge AS,NO 2 - AS61894 343019 5.0% 114339.7 -- FreeBSD Brasil LTDA,BR 3 - AS23752 255192 3.7% 2407.5 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - AS7782 177923 2.6% 29653.8 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 5 - AS393276 175604 2.6% 35120.8 -- CEA - Chugach Electric Association, Inc.,US 6 - AS9829 145184 2.1% 94.3 -- BSNL-NIB National Internet Backbone,IN 7 - AS2734 119185 1.8% 7449.1 -- CORESITE - CoreSite,US 8 - AS36947 74984 1.1% 357.1 -- ALGTEL-AS,DZ 9 - AS42081 61752 0.9% 823.4 -- SPEEDY-NET-AS Speedy net EAD,BG 10 - AS7908 58262 0.8% 366.4 -- BT LATAM Venezuela, S.A.,VE 11 - AS53563 57463 0.8% 28731.5 -- XPLUSONE - X Plus One Solutions, Inc.,US 12 - AS33885 55752 0.8% 3097.3 -- OWNIT Ownit Broadband AB,SE 13 - AS5619 54404 0.8% 3022.4 -- EVRY-NO EVRY AS,NO 14 - AS46230 50001 0.7% 2381.0 -- DUDROP - Dignitas Technology Inc,US 15 - AS28726 45632 0.7% 2281.6 -- ASN-EDB-UNIGRID EDB Drift AB,SE 16 - AS11664 45044 0.7% 93.6 -- Techtel LMDS Comunicaciones Interactivas S.A.,AR 17 - AS60717 43922 0.6% 3992.9 -- BAYONETTE Bayonette AS,NO 18 - AS61275 43553 0.6% 3350.2 -- ASN-NEAS Nordmore Energiverk AS,NO 19 - AS34984 41012 0.6% 24.5 -- TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR 20 - AS27194 38040 0.6% 19020.0 -- REALLYFAST - ReallyFast.net,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS61894 343019 5.0% 114339.7 -- FreeBSD Brasil LTDA,BR 2 - AS54970 35330 0.5% 35330.0 -- NORTHERN-AIR-CARGO - NORTHERN AIR CARGO,US 3 - AS393276 175604 2.6% 35120.8 -- CEA - Chugach Electric Association, Inc.,US 4 - AS7782 177923 2.6% 29653.8 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 5 - AS53563 57463 0.8% 28731.5 -- XPLUSONE - X Plus One Solutions, Inc.,US 6 - AS27194 38040 0.6% 19020.0 -- REALLYFAST - ReallyFast.net,US 7 - AS61039 15734 0.2% 15734.0 -- ZMZ OAO ZMZ,RU 8 - AS32643 14225 0.2% 14225.0 -- RDI - RESOURCE DATA, INC.,US 9 - AS47680 12258 0.2% 12258.0 -- NHCS EOBO Limited,IE 10 - AS131754 10524 0.1% 10524.0 -- IDNIC-UNMUL-AS-ID Universitas Mulawarman,ID 11 - AS18135 10229 0.1% 10229.0 -- BTV BTV Cable television,JP 12 - AS46336 7886 0.1% 7886.0 -- GOODVILLE - Goodville Mutual Casualty Company,US 13 - AS2734 119185 1.8% 7449.1 -- CORESITE - CoreSite,US 14 - AS25563 21856 0.3% 7285.3 -- WEBLAND-AS Webland AG, Autonomous System,CH 15 - AS197914 19126 0.3% 6375.3 -- STOCKHO-AS Stockho Hosting SARL,FR 16 - AS33356 5850 0.1% 5850.0 -- CTWS - Eagle-Tech Systems,US 17 - AS20151 4631 0.1% 4631.0 -- MCW-12-01 - Mountain Computer Wizards, Inc.,US 18 - AS59767 4554 0.1% 4554.0 -- NETNORDIC Netnordic Holding AS,NO 19 - AS33721 4021 0.1% 4021.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 20 - AS60717 43922 0.6% 3992.9 -- BAYONETTE Bayonette AS,NO TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 177.10.158.0/24 343001 4.9% AS61894 -- FreeBSD Brasil LTDA,BR 2 - 202.70.88.0/21 127362 1.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.64.0/21 124990 1.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 105.96.0.0/22 66980 1.0% AS36947 -- ALGTEL-AS,DZ 5 - 199.38.164.0/23 57460 0.8% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 6 - 192.206.58.0/24 35748 0.5% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 7 - 198.163.32.0/21 35708 0.5% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 8 - 162.211.56.0/21 35576 0.5% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 9 - 107.152.112.0/20 35474 0.5% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 10 - 104.254.224.0/21 35412 0.5% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 11 - 198.17.216.0/24 35330 0.5% AS54970 -- NORTHERN-AIR-CARGO - NORTHERN AIR CARGO,US 12 - 192.189.218.0/24 35202 0.5% AS393276 -- CEA - Chugach Electric Association, Inc.,US 13 - 192.189.215.0/24 35198 0.5% AS393276 -- CEA - Chugach Electric Association, Inc.,US 14 - 192.189.217.0/24 35096 0.5% AS393276 -- CEA - Chugach Electric Association, Inc.,US 15 - 192.189.219.0/24 35060 0.5% AS393276 -- CEA - Chugach Electric Association, Inc.,US 16 - 192.189.216.0/24 35048 0.5% AS393276 -- CEA - Chugach Electric Association, Inc.,US 17 - 66.128.148.0/24 23352 0.3% AS2734 -- CORESITE - CoreSite,US 18 - 66.128.148.0/22 23272 0.3% AS2734 -- CORESITE - CoreSite,US 19 - 67.212.149.0/24 23258 0.3% AS2734 -- CORESITE - CoreSite,US 20 - 66.128.149.0/24 23216 0.3% AS2734 -- CORESITE - CoreSite,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From owen at delong.com Fri Feb 27 21:58:05 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Feb 2015 13:58:05 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0958F.7070105@meetinghouse.net> References: <54F079AC.8020103@cox.net> <54F08428.4000705@invaluement.com> <54F0958F.7070105@meetinghouse.net> Message-ID: <9B01271E-2535-46F5-8649-71D4339ADE8F@delong.com> > On Feb 27, 2015, at 08:04 , Miles Fidelman wrote: > > I'd think they'd be better off with some jujitsu, along the lines of: > > "We've always practiced network neutrality, not like some of our competitors, this won't effect us at all and may enforce some good business practices on others” I think they’d be pretty hard pressed to say this with a straight face. Even if they could, anyone who is paying attention would know better. > (As far as I can tell, Verizon has not played games with favoring their own content - for all intents and purposes, they operate FIOS as a common carrier - no funny throttling, no usage caps, etc.) Verizon has been every bit as much involved in the let’s tax the big content providers for all we can games as any of the other eyeball providers. > I'm surprised they weren't a bit more vocal on the OTHER FCC decision of the day - preempting some state restrictions on municipal broadband builds - Verizon has been very active in pushing state laws to kill muni networks (even in places where they have no intention of building out). They prefer to do this in ways the public is less likely to notice what they are doing. The last thing they want is a big public backlash against their backroom dealings with lawmakers on this matter. The fact that the president called them out on it publicly is pretty much game over for that tactic anyway. Owen > > Miles Fidelman > > Scott Fisher wrote: >> I am not arguing that they have a valid complaint. I just think their >> method of doing so is a bit childish. It does get the point across, >> just not in the method I respect. Just my opinion though. >> >> On Fri, Feb 27, 2015 at 9:50 AM, Rob McEwen wrote: >>> Scott Fisher, >>> >>> I think Verizon's statement was brilliant, and entirely appropriate. Some >>> people are going to have a hard time discovering that being in favor of >>> Obama's version of "net neutrality"... will soon be just about as cool as >>> having supported SOPA. >>> >>> btw - does anyone know if that thick book of regulations, you know... those >>> hundreds of pages we weren't allowed to see before the vote... anyone know >>> if that is available to the public now? If so, where? >>> >>> Rob McEwen >>> >>> >>> >>> On Fri, Feb 27, 2015 at 9:10 AM, Scott Fisher >>> wrote: >>>> Funny, but in my honest opinion, unprofessional. Poor PR. >>>> >>>> On Fri, Feb 27, 2015 at 9:05 AM, Larry Sheldon >>>> wrote: >>>>> >>>>> http://publicpolicy.verizon.com/blog/entry/fccs-throwback-thursday-move-imposes-1930s-rules-on-the-internet >>> >> >> > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra From khelms at zcorum.com Fri Feb 27 22:05:02 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 17:05:02 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F0E80F.50004@satchell.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D7FE.9030905@meetinghouse.net> <54F0E156.7050504@paradoxnetworks.net> <54F0E80F.50004@satchell.net> Message-ID: Stephen is dead on here. In DOCSIS the downstream communication happens in one or more normal cable TV channel band, ie 6MHz channels from 54 MHz to 890MHz. The upstreams will be (in most cases) either 1.6 MHz, 3.2 MHz, or 6.4MHz wide and in the 5-42 MHz range. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 4:56 PM, Stephen Satchell wrote: > On 02/27/2015 01:27 PM, Jack Bates wrote: > > My 2 cents. I don't design these things, but you'd think people would > > start realizing that static allocation is kind of limiting. Giving > > someone 50mb/s with 20mb/s waste is annoying when they are saturating > > 3mb/s the opposite direction. Wouldn't it be cool if your backup at > > night could use 50mb/s upstream and drop your downstream to 5mb/s > > because you aren't downloading anything? > > That's possible with multicarrier technology, such as xDSL. When you > get into the data-over-cable technology, you find a completely different > story -- it's a system limitation that you have an upstream channel that > is less efficient than the downstream channel because the upstream > channel has to be accessed by a number of sources, with access control, > whereas the downstream channel is nothing more than a broadcast pipe > (just like 10base-2 Ethernet) where you pick your packets out of the > stream. > > Other technologies have their quirks, too... > > From morrowc.lists at gmail.com Fri Feb 27 22:05:51 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 27 Feb 2015 17:05:51 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> Message-ID: On Fri, Feb 27, 2015 at 4:41 PM, Scott Helms wrote: > "hopefully not much since it's rsync (or was). > I'm not sure I care a lot though if they have to run a stun/ice > server... that's part of the payment I make to them, right?" > > Sure it is, but the point is if it's easier to deliver then the price will > go down and more people will choose to use it. That's kind of my point. I don't know that price is the problem with carbonite, or any backup solution. I think most folk don't see why they OUGHT to backup their pictures/etc... until they needed to get them from a backup :( > Carbonite (and others) have built a decent business, but imagine if their > costs were cut by ~15% because they didn't have to deal with NAT transversal > they could offer more services for the same amount of money or offer the I doubt it's 15%, if it is... wow they seem to be doing it wrong. > same service for less. Either would result in more people using that kind > of service. > this is a point problem (backup for carbonite), there are lots of things that work 'just fine' with NAT (practically everything... it would seem) I'm not sure digging more into why carbonite/etc are 'hard' (because they aren't, because they are working...) is helpful. > Imagine what might be possible if direct communication would work without > port forwarding rules inside your neighborhood. I can imagine that, I have that silly thing that my dsl modem does (zeroconf or whatever crazy sauce my windows ME desktop does to tell the 'router' to open a port so johnny down the street can chat me). also I have ipv6, so i have open access directly to my internal network. (so do 70+% of the rest of the comcast user base... and TWC and ...) > "no it wasn't. Blizzard or one of the others used to select the > 'fastest player' to be the server for group play..." > > That's not WoW, it might be Diablo III or StarCraft (both Blizzard products) > you'll note in my first message about this (not the morse code one) I said I don't play games so call it angband (http://rephial.org/) > "my son has a minecraft server as well behind nat, his pals all over > play on it just fine. It happens to have v6, but because the minecraft > people are apparently stuck in 1972 only v4 is a configurable > transport option, and the clients won't make AAAA queries so my AAAA > is a wasted dns few bytes. > > Frankly folk that want to keep stomping up and down about NAT being a > problem are delusional. Sure direct access is nice, it simple and > whatnot, but ... really... stuff just works behind NAT as well." > > It doesn't "just work" there is a real cost and complexity even if you're > using UPNP or you're comfortable doing the port forwarding manually to get > around it to a certain extent. Session border controllers cost tens of > thousands of dollars to handle SIP sessions behind NAT. folk could deploy v6 though, eh? it's not costing THAT much I guess if they can't get off their duffs and deploy v6 on the consumer networks that don't already have v6 deployed. You can't be all: "NAT IS HARD!!! AND EXPENSIVE!!!" and not deploy v6. Frankly, SBCs exist for a whole host of reasons unrelated to NAT, so that's a fine red herring you've also brought up. -chris From khelms at zcorum.com Fri Feb 27 22:19:00 2015 From: khelms at zcorum.com (Scott Helms) Date: Fri, 27 Feb 2015 17:19:00 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> Message-ID: "I don't know that price is the problem with carbonite, or any backup solution. I think most folk don't see why they OUGHT to backup their pictures/etc... until they needed to get them from a backup :(" Are you really trying to say they wouldn't get more customers if they could lower their prices or alternatively increase marketing? "I doubt it's 15%, if it is... wow they seem to be doing it wrong." I invite you to try and do some of the programming tricks needed to work around NAT and the ongoing costs needed to run an external set of servers just to handle session state. 15% is probably underestimating the costs, but I don't have hard numbers to be any more precise. "this is a point problem (backup for carbonite), there are lots of things that work 'just fine' with NAT (practically everything... it would seem) I'm not sure digging more into why carbonite/etc are 'hard' (because they aren't, because they are working...) is helpful." Just because it's easy for you, doesn't have a thing to do with the effort that the Carbonite engineers and software folks had to put in to make it easy. "I can imagine that, I have that silly thing that my dsl modem does (zeroconf or whatever crazy sauce my windows ME desktop does to tell the 'router' to open a port so johnny down the street can chat me).' Wait, are you really running Windows ME???? "folk could deploy v6 though, eh? it's not costing THAT much I guess if they can't get off their duffs and deploy v6 on the consumer networks that don't already have v6 deployed. You can't be all: "NAT IS HARD!!! AND EXPENSIVE!!!" and not deploy v6." You're misunderstanding, IPv6 is expensive for the carriers and NAT is expensive for the OTT service providers and software companies. Both are hard and expensive, but to completely different groups. This is why Netflix, Google, Carbonite, Spotify, and host of other content or OTT services want the carriers to deploy IPv6. It's also why the carriers have been less than enthusiastic. They get the bulk of the cost while others get the bulk of the benefits. "Frankly, SBCs exist for a whole host of reasons unrelated to NAT, so that's a fine red herring you've also brought up." No, it's not. SBCs can and do a lot more than NAT transversal, but the reasons that SIP operators of any scale can't live without them is NAT. Anyone who tells you differently is misinformed Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Feb 27, 2015 at 5:05 PM, Christopher Morrow wrote: > On Fri, Feb 27, 2015 at 4:41 PM, Scott Helms wrote: > > "hopefully not much since it's rsync (or was). > > I'm not sure I care a lot though if they have to run a stun/ice > > server... that's part of the payment I make to them, right?" > > > > Sure it is, but the point is if it's easier to deliver then the price > will > > go down and more people will choose to use it. That's kind of my point. > > I don't know that price is the problem with carbonite, or any backup > solution. > I think most folk don't see why they OUGHT to backup their > pictures/etc... until they needed to get them from a backup :( > > > Carbonite (and others) have built a decent business, but imagine if their > > costs were cut by ~15% because they didn't have to deal with NAT > transversal > > they could offer more services for the same amount of money or offer the > > I doubt it's 15%, if it is... wow they seem to be doing it wrong. > > > same service for less. Either would result in more people using that > kind > > of service. > > > > this is a point problem (backup for carbonite), there are lots of > things that work 'just fine' with NAT (practically everything... it > would seem) I'm not sure digging more into why carbonite/etc are > 'hard' (because they aren't, because they are working...) is helpful. > > > Imagine what might be possible if direct communication would work without > > port forwarding rules inside your neighborhood. > > I can imagine that, I have that silly thing that my dsl modem does > (zeroconf or whatever crazy sauce my windows ME desktop does to tell > the 'router' to open a port so johnny down the street can chat me). > > also I have ipv6, so i have open access directly to my internal > network. (so do 70+% of the rest of the comcast user base... and TWC > and ...) > > > "no it wasn't. Blizzard or one of the others used to select the > > 'fastest player' to be the server for group play..." > > > > That's not WoW, it might be Diablo III or StarCraft (both Blizzard > products) > > > > you'll note in my first message about this (not the morse code one) I > said I don't play games so call it angband (http://rephial.org/) > > > "my son has a minecraft server as well behind nat, his pals all over > > play on it just fine. It happens to have v6, but because the minecraft > > people are apparently stuck in 1972 only v4 is a configurable > > transport option, and the clients won't make AAAA queries so my AAAA > > is a wasted dns few bytes. > > > > Frankly folk that want to keep stomping up and down about NAT being a > > problem are delusional. Sure direct access is nice, it simple and > > whatnot, but ... really... stuff just works behind NAT as well." > > > > It doesn't "just work" there is a real cost and complexity even if you're > > using UPNP or you're comfortable doing the port forwarding manually to > get > > around it to a certain extent. Session border controllers cost tens of > > thousands of dollars to handle SIP sessions behind NAT. > > folk could deploy v6 though, eh? it's not costing THAT much I guess if > they can't get off their duffs and deploy v6 on the consumer networks > that don't already have v6 deployed. > > You can't be all: "NAT IS HARD!!! AND EXPENSIVE!!!" and not deploy v6. > > Frankly, SBCs exist for a whole host of reasons unrelated to NAT, so > that's a fine red herring you've also brought up. > > -chris > From asr at latency.net Fri Feb 27 22:22:44 2015 From: asr at latency.net (Adam Rothschild) Date: Fri, 27 Feb 2015 17:22:44 -0500 Subject: Who is covered [was VZ...] In-Reply-To: References: Message-ID: I think "terminating access monopoly" is (rightly IMO) the litmus test for coverage, but I am not an attorney either... $0.02, -a On Fri, Feb 27, 2015 at 4:54 PM, Livingood, Jason wrote: > I have the same question. No one will know for sure until the rules are > released, but my guess is it potentially covers more than people may > initially think. > > For example, I would guess many ³transit² networks will be covered since > they also provide in many cases retail access to schools, hospitals, > government, business, etc. It¹s not much of a stretch to see how CDNs, > hosters, and others may be covered by at least parts of this, such as > transparency/policy disclosure, maybe measurement. Blocking, throttling, > and paid prioritization could also apply in some critical ways, especially > given the % of Internet traffic that uses CDNs for example. > > > Again, the key may be that there will be ambiguity that may only be sorted > out as case law develops around each of these areas. But IANAL so I¹m just > guessing like the rest of us for now! ;-) > > - Jason > > On 2/27/15, 3:44 PM, "Adam Rothschild" wrote: > >>I interpreted the FCC press release[*] to apply these provisions to >>"broadband access" providers only -- that is to say, not hosters, nor >>CDNs. It will indeed be interesting to see how this works once the full >>documentation is released. >> >>FWIW, >>-a >> >>[*] >>http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0226/DOC-33 >>2260A1.pdf >> >>On Fri, Feb 27, 2015 at 2:49 PM, McElearney, Kevin >> wrote: >>> [Sorry for top-posting] >>> >>> I actually think you are both right and partially wrong. It IS the ISPs >>> responsibility to provide you with the broadband that was advertised and >>> you paid for. This is also measured today by the FCC through Measuring >>> Broadband America. >>> >>>http://data.fcc.gov/download/measuring-broadband-america/2014/2014-Fixed- >>>Me >>> asuring-Broadband-America-Report.pdf >>> >>> That said, your ISP is NOT ³the Internet² and can¹t guarantee ³access >>>the >>> Internet sites of my choice at X megabits per second." While ISPs do >>>take >>> the phone call for all Internet problems (sometimes not very well), they >>> certainly don¹t control all levels of the QoE. ASPs may have >>>server/site >>> issues internally, CDNs may purposely throttle downloads (content owners >>> contract commits), not all transit ISPs are created equal, TCP distance >>> limitations, etc. >>> >>> What would be interesting is if all these rules/principals and >>> transparency requirements were to be applied to all involved in the >>> consumer QoE. >>> >>> - Kevin >>> >>> On 2/27/15, 1:34 PM, "Mel Beckman" wrote: >>> >>>>Bill, >>>> >>>>This is not feasible. ISPs work by oversubscription, so it's never >>>>possible for all (or even 10% of all) customers to simultaneously demand >>>>their full bandwidth. If ISPs had to reserve the full bandwidth sold to >>>>each customer in order to "do everything reasonably within your power to >>>>make sure I can access the Internet sites of my choice at X megabits per >>>>second", then broadband connections would cost thousands of dollars per >>>>month. >>>> >>>>Anyone who doesn't understand this fundamental fact of Internet >>>>distribution will be unable to engage in reasonable discussion about ISP >>>>practices. >>>> >>>>On Feb 27, 2015, at 9:56 AM, William Herrin >>>>> >>>> wrote: >>>> >>>>Deceit is Bad Behavior. If you sell me an X megabit per second >>>>Internet access service, you should do everything reasonably within >>>>your power to make sure I can access the Internet sites of my choice >>>>at X megabits per second. >>>> >>> >> > From patrick at ianai.net Fri Feb 27 22:23:44 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 27 Feb 2015 17:23:44 -0500 Subject: What is lawful content? [was VZ...] In-Reply-To: References: Message-ID: <13C5D0E6-2D15-430F-9A93-096C322C9A43@ianai.net> I am not a lawyer (in fact, I Am Not An Isp), but my understanding is this is pretty well settled. And it is not even weird or esoteric. If the content on the site is against the law in the jurisdiction in question, it is not legal (duh). Otherwise, yes it is, and no ISP gets to decide whether you can see it or not. Things like KP are obvious. Things like "adult" content here in the US are, for better or worse, also obvious (legal, in case you were wondering). Things like gambling are the question, as that changes per location. A better question is: Can ISPs sell things like "filtering" services for a fee? Blocking is disallowed. But that is blocking by the ISP. Affirmative requests from the end user to block things are probably OK. But ... has anyone seen the actual rules? -- TTFN, patrick > On Feb 27, 2015, at 16:46 , Livingood, Jason wrote: > > Iąm not sure who gets to definitively answer the question (I would guess > that case law will develop around it but IANAL), but this sort of caveat > has been in the Open Internet rules for awhile. In general it means ISPs > canąt block stuff like Facebook but have latitude to do stuff like block a > site/IP address that may be the source of an attack, etc. > > > - Jason > > On 2/27/15, 2:24 PM, "Bruce H McIntosh" wrote: >> >> On 2015-02-27 14:14, Jim Richardson wrote: >>> What's a "lawful" web site? >>> >> Now *there* is a $64,000 question. Even more interesting is, "Who gets >> to decide day to day the answer to that question?" :) From owen at delong.com Fri Feb 27 22:19:51 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Feb 2015 14:19:51 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <20150227165240.GA13738@puck.nether.net> <54F0AE3B.2010209@sprunk.org> <54F0B517.4050200@invaluement.com> <54F0B751.30008@pari.edu> Message-ID: <7AC0F5A4-67FA-47F2-B11F-8DD08439A790@delong.com> Any website which does not violate the law. In other words, if a lawful takedown order has been applied to a website, this code can’t be used to force an ISP to provide illegal access to said site. Owen > On Feb 27, 2015, at 11:14 , Jim Richardson wrote: > >> From 47CFR§8.5b > (b) A person engaged in the provision of mobile broadband Internet > access service, insofar as such person is so engaged, shall not block > consumers from accessing lawful Web sites, subject to reasonable > network management; nor shall such person block applications that > compete with the provider's voice or video telephony services, subject > to reasonable network management. > > What's a "lawful" web site? > > > On Fri, Feb 27, 2015 at 10:28 AM, Lamar Owen wrote: >> On 02/27/2015 01:19 PM, Rob McEwen wrote: >>> >>> We're solving an almost non-existing problem.. by over-empowering an >>> already out of control US government, with powers that we can't even begin >>> to understand the extend of how they could be abused... to "fix" an industry >>> that has done amazingly good things for consumers in recent years. >>> >> You really should read 47CFR§8. It won't take you more than an hour or so, >> as it's only about 8 pages. >> >> The procedure for filing a complaint is pretty interesting, and requires the >> complainant to do some pretty involved things. (47CFR§8.14 for the complaint >> procedure, 47CFR§8.13 for the requirements for the pleading, etc). Note >> that the definitions found in 47CFR§8.11(a) and (b) are pretty specific in >> who is actually covered by 'net neutrality.' >> From johnl at iecc.com Fri Feb 27 22:30:16 2015 From: johnl at iecc.com (John Levine) Date: 27 Feb 2015 22:30:16 -0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <11287607.8005.1425056798993.JavaMail.mhammett@ThunderFuck> Message-ID: <20150227223016.18403.qmail@ary.lan> In article <11287607.8005.1425056798993.JavaMail.mhammett at ThunderFuck> you write: >More symmetry will happen when the home user does more things that care about symmetry. It's a >simple allocation of spectrum (whether wireless, DSL or cable). MHz for upload are taken out of MHz >for download. It's more complicated than that. On cable systems, all of the upstream traffic has to contend for the available space, sort of like classic Ethernet. The faster you try to go, the more you lose to contention. With ADSL, there's only so much bandwidth per pair, and I doubt many users would want less download speed. There's also little reason to expect that many home users want symmetrical access. We weenies are atypical. Your normal broadband user watches video (which would better be sent as actual video over the cable, but that's a separate argument) and futzes with Facebook or Snapchat or the groovy app du jour. It's all mostly downstream traffic. R's, John From james.cutler at consultant.com Fri Feb 27 22:31:06 2015 From: james.cutler at consultant.com (James R Cutler) Date: Fri, 27 Feb 2015 17:31:06 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> Message-ID: <6C2AD229-D571-4220-8D7B-F2F8CC119185@consultant.com> > On Feb 27, 2015, at 4:11 PM, Scott Helms wrote: > > My point is not that upstream > speed isn't valuable, but merely that demand for it isn't symmetrical and > unless the market changes won't be in the near term. Downstream demand is > growing, in most markets I can see, much faster than upstream demand. The demand may not be symmetrical, but where demand exists, it is often for symmetrical speeds. Side note: Did I not read that asymmetric paths tend to exacerbate Buffer Bloat? James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 234 bytes Desc: Message signed with OpenPGP using GPGMail URL: From SNaslund at medline.com Fri Feb 27 22:32:29 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 27 Feb 2015 22:32:29 +0000 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F0E156.7050504@paradoxnetworks.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D7FE.9030905@meetinghouse.net> <54F0E156.7050504@paradoxnetworks.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725E373@MUNPRDMBXA1.medline.com> >I'll disagree on the home part. I doubt that most homes are symmetric. I agree, most homes are not symmetric, the two biggest services are cable modem and DSL which are usually asymmetric. >Of course, what needs to happen is for standards bodies to start thinking more dynamic when they build their protocols where possible. >Passive splitters obviously have the limitation of limiting frequencies, but our xDSL technologies and cable technologies do not have the restriction to my >knowledge. Future protocols ideally would have a signaling band, recognition of frequency support bidirectionally and perhaps support dynamic allocation of >those channels as-needed. >If an end node is saturating the upload but not using the download, why shouldn't the system shift the frequency usage? If only 10mb/s is being used out of >a 50mb/s circuit for download, why not allow that extra capacity to be used for upload, temporarily shifting it's direction? You could do that. The only issue is that you are putting in more intelligent CPE that has to be frequency agile and signal to the head end what is happening. Carriers are very sensitive to CPE costs so I don't think that is likely to happen especially since I think that DSL is not considered leading edge service any more. I would expect the carriers to devote more effort to FTTP efforts than to keep trying to advance DSL. >My 2 cents. I don't design these things, but you'd think people would start realizing that static allocation is kind of limiting. Giving someone 50mb/s with >20mb/s waste is annoying when they are saturating 3mb/s the opposite direction. Wouldn't it be cool if your backup at night could use 50mb/s upstream >and drop your downstream to 5mb/s because you aren't downloading anything? Again, not a technical problem. It is a CPE intelligence and cost issue. Unless a whole lot of customers want that, the money is not going to be spent to support that. >For that matter, is there a reason we don't dynamically adjust frequencies on Ethernet? My servers would definitely love 1.8gb/s transmit since they receive >very little. Sorry, no frequencies to play with on Ethernet. Ethernet is a baseband technology (i.e. DC voltage, not AC frequencies) One pair is transmitting, one pair is receiving in gigE. If you want to use both pairs in the same direction to double up the bandwidth, that could be done but it would not be Ethernet anymore. If you want to talk both ways on the same pair, that is half duplex, we've left that idea in the dust years ago. Steven Naslund Chicago IL From morrowc.lists at gmail.com Fri Feb 27 22:40:21 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 27 Feb 2015 17:40:21 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> Message-ID: On Fri, Feb 27, 2015 at 5:19 PM, Scott Helms wrote: > "I don't know that price is the problem with carbonite, or any backup > solution. > I think most folk don't see why they OUGHT to backup their > pictures/etc... until they needed to get them from a backup :(" > > Are you really trying to say they wouldn't get more customers if they could > lower their prices or alternatively increase marketing? no, what I'm saying is I don't think price sensitivity is the thing that moves folk from backup or not. (but again, this is all a red herring anyway) > "I doubt it's 15%, if it is... wow they seem to be doing it wrong." > > I invite you to try and do some of the programming tricks needed to work > around NAT and the ongoing costs needed to run an external set of servers > just to handle session state. 15% is probably underestimating the costs, > but I don't have hard numbers to be any more precise. > great, no citation... rsync -f /etc/rsyncd.conf problem solved. (well, wrap a shell script to re-create that config as you add/remove users) > "this is a point problem (backup for carbonite), there are lots of > things that work 'just fine' with NAT (practically everything... it > would seem) I'm not sure digging more into why carbonite/etc are > 'hard' (because they aren't, because they are working...) is helpful." > > Just because it's easy for you, doesn't have a thing to do with the effort > that the Carbonite engineers and software folks had to put in to make it > easy. > > "I can imagine that, I have that silly thing that my dsl modem does > (zeroconf or whatever crazy sauce my windows ME desktop does to tell > the 'router' to open a port so johnny down the street can chat me).' > > Wait, are you really running Windows ME???? > I also don't actually play Angband. > "folk could deploy v6 though, eh? it's not costing THAT much I guess if > they can't get off their duffs and deploy v6 on the consumer networks > that don't already have v6 deployed. > > You can't be all: "NAT IS HARD!!! AND EXPENSIVE!!!" and not deploy v6." > > You're misunderstanding, IPv6 is expensive for the carriers and NAT is > expensive for the OTT service providers and software companies. Both are > hard and expensive, but to completely different groups. This is why > Netflix, Google, Carbonite, Spotify, and host of other content or OTT > services want the carriers to deploy IPv6. It's also why the carriers have > been less than enthusiastic. They get the bulk of the cost while others get > the bulk of the benefits. actually I think folk want ipv6 because it'll be more stable and reliable and permit the same fast growth of the network and services. Also, don't confuse CGN with home-nat. > "Frankly, SBCs exist for a whole host of reasons unrelated to NAT, so > that's a fine red herring you've also brought up." > > No, it's not. SBCs can and do a lot more than NAT transversal, but the > reasons that SIP operators of any scale can't live without them is NAT. > Anyone who tells you differently is misinformed they also can't connect with their peers in a sane fashion. I suppose if they didn't want any of their customers to talk outside the singular service they could avoid sbcs as well... I think there are other things than SBC devices which are capable of making sip work too in the face of NAT. -chris From jbates at paradoxnetworks.net Fri Feb 27 22:40:28 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Fri, 27 Feb 2015 16:40:28 -0600 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D7FE.9030905@meetinghouse.net> <54F0E156.7050504@paradoxnetworks.net> <54F0E80F.50004@satchell.net> Message-ID: <54F0F25C.1000506@paradoxnetworks.net> Even so, what makes the channel assignments static? If the downstream bands are sitting idle, why can't they be reallocated for use by modems needing to send more? Or, presuming upstream isolation between modems, why can't multiple channels be dynamically allocated to a modem when there is availability and need? I'm not arguing how it is. Just saying. Why can't we do more? GMPLS shows we can get really annoying in our ability to automate in dynamic provisioning. I'd think fixing something like DOCSIS would be a cakewalk in comparison. Sorry, I'm just a network guy that plays with routers and servers. I expect more out of the geniuses that make stuff for me to play with. Jack On 2/27/2015 4:05 PM, Scott Helms wrote: > Stephen is dead on here. In DOCSIS the downstream communication happens in > one or more normal cable TV channel band, ie 6MHz channels from 54 MHz to > 890MHz. The upstreams will be (in most cases) either 1.6 MHz, 3.2 MHz, or > 6.4MHz wide and in the 5-42 MHz range. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 4:56 PM, Stephen Satchell wrote: > >> On 02/27/2015 01:27 PM, Jack Bates wrote: >>> My 2 cents. I don't design these things, but you'd think people would >>> start realizing that static allocation is kind of limiting. Giving >>> someone 50mb/s with 20mb/s waste is annoying when they are saturating >>> 3mb/s the opposite direction. Wouldn't it be cool if your backup at >>> night could use 50mb/s upstream and drop your downstream to 5mb/s >>> because you aren't downloading anything? >> That's possible with multicarrier technology, such as xDSL. When you >> get into the data-over-cable technology, you find a completely different >> story -- it's a system limitation that you have an upstream channel that >> is less efficient than the downstream channel because the upstream >> channel has to be accessed by a number of sources, with access control, >> whereas the downstream channel is nothing more than a broadcast pipe >> (just like 10base-2 Ethernet) where you pick your packets out of the >> stream. >> >> Other technologies have their quirks, too... >> >> From egon at egon.cc Fri Feb 27 22:43:01 2015 From: egon at egon.cc (James Downs) Date: Fri, 27 Feb 2015 14:43:01 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F09741.50806@satchell.net> References: <54F079AC.8020103@cox.net> <54F09741.50806@satchell.net> Message-ID: > On Feb 27, 2015, at 08:11, Stephen Satchell wrote: > > transcription on an old Underwood Portable that had seen much, much > better days. You’d think they could afford a new typewriter or two with all of the Universal Service fees they’ve been collecting and not providing. From SNaslund at medline.com Fri Feb 27 22:49:23 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 27 Feb 2015 22:49:23 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725E3EC@MUNPRDMBXA1.medline.com> On Fri, Feb 27, 2015 at 3:53 PM, Scott Helms wrote: > "My point is that the option should be there, at the consumer level." > > Why? What's magical about symmetry? Is a customer better served by > having a 5mbps/5mbps over a 25mbps/5mbps? If the option sells, it will be offered. It didn't. We offer symmetric DLS residentially and it went over like a lead balloon. > "There are so many use cases for this, everything from personal game > servers to on-line backups, that the lack of such offerings is an > indication of an unhealthy market." > > Until we get NAT out of the way, this is actually much harder to > leverage than you might think. I don't think there is anything > special about NAT is not that big an issue any more because everything from game server to backup software can deal with it. No need to re-invent the wheel to get around NAT. In fact, for backups it is completely a non-issue since there is going to be a client initiating the data push to a cloud server. > symmetrical bandwidth, I do think upstream bandwidth usage is going up > and will continue to go up, but I don't see any evidence in actual > performance stats or customers sentiment to show that it's going up as > fast as downstream demand. Of course, upstream bandwidth will increase but downstream will increase as much or I would suspect even more. It is very simple to explain. A song is uploaded to iTunes once and downloaded millions of times. An HD movie is upload once and view many times. Essentially whether it is music, video, web content, or any other media, it is normally an upload once download many operation. I am not saying that sometimes a residential user's traffic is not symmetric (Skype calls etc.) from time to time. It is just not what most residential users are concentrated on. As soon as people become more interested in high upload speeds, the market will react. In fact, most carriers would love a more symmetric user to user environment because most carrier backbones have to be very over-engineered based on traffic toward the consumer. Steven Naslund Chicago IL From johnl at iecc.com Fri Feb 27 22:51:27 2015 From: johnl at iecc.com (John Levine) Date: 27 Feb 2015 22:51:27 -0000 Subject: utility capacity, was Verizon Policy Statement on Net Neutrality In-Reply-To: Message-ID: <20150227225127.18489.qmail@ary.lan> >Water, gas, and to a great extent electrical systems do not work on >oversubscription, ie their aggregate capacity meets or exceeds the needs of >all their customers peak potential demand, at least from "normal" demand >standpoint. Hi, former municipal water and sewer commissioner here. We size the system to meet likely demand, but not peak demand. If it's a hot dry summer and everyone wants to water their lawn, or there's a big fire that's drawing a lot of water from hydrants, we can have capacity problems. We deal with it by interrupting service to a few large customers, a car wash and a golf course. But it's not really comparable to broadband service, because on the Internet, nearly every consumer end user device could easily saturate the entire network if it wanted to. It's like every house having a 100,000 gallon toilet. Better hope you don't have a lot of people flushing at once. R's, John From SNaslund at medline.com Fri Feb 27 22:52:57 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 27 Feb 2015 22:52:57 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <6C2AD229-D571-4220-8D7B-F2F8CC119185@consultant.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <6C2AD229-D571-4220-8D7B-F2F8CC119185@consultant.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725E400@MUNPRDMBXA1.medline.com> What is that statement based on? I have not seen any outcry for more symmetric speeds. Asymmetry in our networks causes a lot of engineering issues and if it were up to the carriers, we would much rather have more symmetric traffic patterns because it would make life easier for us. Remember that most carrier backbones are built of symmetric circuits. It would be nice but the users generally download more than they upload. That is the fact. Steven Naslund Chicago IL >The demand may not be symmetrical, but where demand exists, it is often for symmetrical speeds. > >Side note: Did I not read that asymmetric paths tend to exacerbate Buffer Bloat? >James R. Cutler >James.cutler at consultant.com >PGP keys at http://pgp.mit.edu From SNaslund at medline.com Fri Feb 27 23:00:18 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 27 Feb 2015 23:00:18 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0DD52.4040409@satchell.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <54F0A62C.70704@paradoxnetworks.net> <9578293AE169674F9A048B2BC9A081B4015725DE54@MUNPRDMBXA1.medline.com> <54F0DD52.4040409@satchell.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725E44F@MUNPRDMBXA1.medline.com> >When I was involved with private-loop provision, what I noticed here in northern Nevada is that the provisioning of T1 circuits moved from baseband signalling to SDSL. >From the standpoint of cable management, the splatter from SDSL was MUCH lower than the splattering of baseband T1, so instead of being limited to a single T1 circuit >per 25-pair bundle, you could have several circuits. > >TIA T1Q1 has quite a lot to say on this. Absolutely correct, the SDSL gets you around a lot of the inductance problems with baseband T-1s. For quite awhile now most carriers deliver T-1s using SDSL smartjacks. Some are single pair 1.5mbps bidirectional and on longer circuits they use two pairs each running 768 kbps. That technology is what DSL home service developed from and predates the ADSL standards which were create explicitly for internet users that want more downstream than upstream. Steven Naslund Chicago IL From james.cutler at consultant.com Fri Feb 27 23:01:32 2015 From: james.cutler at consultant.com (James R Cutler) Date: Fri, 27 Feb 2015 18:01:32 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725E400@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <6C2AD229-D571-4220-8D7B-F2F8CC119185@consultant.com> <9578293AE169674F9A048B2BC9A081B4015725E400@MUNPRDMBXA1.medline.com> Message-ID: <4C867EDF-5C47-4A30-9BDD-EF7798055C5F@consultant.com> > On Feb 27, 2015, at 5:52 PM, Naslund, Steve wrote: > > What is that statement based on? I have not seen any outcry for more symmetric speeds. Asymmetry in our networks causes a lot of engineering issues and if it were up to the carriers, we would much rather have more symmetric traffic patterns because it would make life easier for us. Remember that most carrier backbones are built of symmetric circuits. It would be nice but the users generally download more than they upload. That is the fact. > > Steven Naslund > Chicago IL > > >> The demand may not be symmetrical, but where demand exists, it is often for symmetrical speeds. >> >> Side note: Did I not read that asymmetric paths tend to exacerbate Buffer Bloat? > >> James R. Cutler >> James.cutler at consultant.com >> PGP keys at http://pgp.mit.edu > "the users generally download more than they upload.” may well be true, but is refers to bytes moved, not bytes per second. And, again, what about Buffer Bloat, especially due to considerably slower uplinks? James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 234 bytes Desc: Message signed with OpenPGP using GPGMail URL: From m.hallgren at free.fr Fri Feb 27 23:08:59 2015 From: m.hallgren at free.fr (Michael Hallgren) Date: Sat, 28 Feb 2015 00:08:59 +0100 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <7AC0F5A4-67FA-47F2-B11F-8DD08439A790@delong.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <20150227165240.GA13738@puck.nether.net> <54F0AE3B.2010209@sprunk.org> <54F0B517.4050200@invaluement.com> <54F0B751.30008@pari.edu> <7AC0F5A4-67FA-47F2-B11F-8DD08439A790@delong.com> Message-ID: <54F0F90B.4040402@free.fr> Le 27/02/2015 23:19, Owen DeLong a écrit : > Any website which does not violate the law. > > In other words, if a lawful takedown order So, subject to legal control rather than simply administrative. Right? mh > has been applied to a website, this code can’t be used to force an ISP to provide illegal access to said site. > > Owen > >> On Feb 27, 2015, at 11:14 , Jim Richardson wrote: >> >>> From 47CFR§8.5b >> (b) A person engaged in the provision of mobile broadband Internet >> access service, insofar as such person is so engaged, shall not block >> consumers from accessing lawful Web sites, subject to reasonable >> network management; nor shall such person block applications that >> compete with the provider's voice or video telephony services, subject >> to reasonable network management. >> >> What's a "lawful" web site? >> >> >> On Fri, Feb 27, 2015 at 10:28 AM, Lamar Owen wrote: >>> On 02/27/2015 01:19 PM, Rob McEwen wrote: >>>> We're solving an almost non-existing problem.. by over-empowering an >>>> already out of control US government, with powers that we can't even begin >>>> to understand the extend of how they could be abused... to "fix" an industry >>>> that has done amazingly good things for consumers in recent years. >>>> >>> You really should read 47CFR§8. It won't take you more than an hour or so, >>> as it's only about 8 pages. >>> >>> The procedure for filing a complaint is pretty interesting, and requires the >>> complainant to do some pretty involved things. (47CFR§8.14 for the complaint >>> procedure, 47CFR§8.13 for the requirements for the pleading, etc). Note >>> that the definitions found in 47CFR§8.11(a) and (b) are pretty specific in >>> who is actually covered by 'net neutrality.' >>> From SNaslund at medline.com Fri Feb 27 23:09:32 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 27 Feb 2015 23:09:32 +0000 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F0D7FE.9030905@meetinghouse.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D7FE.9030905@meetinghouse.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725E505@MUNPRDMBXA1.medline.com> Completely wrong. Sorry, but most network traffic is not symmetric. In corporate environments traffic flows much more heavily from server to client. Home networks are very highly asymmetric because upstream you see URL requests and downstream you have media streams. PON networks were designed so that the carrier can deliver internet and video services to you. The network was designed to deliver content to you not from you. Carrier grade gigE switches are not the issue, the issue is effectively getting the consumer what they want without super expensive CPE or overbuilding the network. Most consumers care about fast download speed so they can watch content. Period, this is a fact. Of course there are other cases but networks are designed to provide the services that the consumer wants. I can't believe that this is so hard to understand. Steven Naslund Chicago IL >Folks, >Let's not go overboard here. Can we remember that most corporate and campus (and, for that matter home) networks are symmetric, at least at the edges. Personally, >I figure that by deploying PON, the major carriers were just asking for trouble down the line. It's not like carrier-grade gigE switches are that much more expensive than >PON gear. >Miles Fidelman >-- >In theory, there is no difference between theory and practice. >In practice, there is. .... Yogi Berra From mansaxel at besserwisser.org Fri Feb 27 23:09:44 2015 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sat, 28 Feb 2015 00:09:44 +0100 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0CA30.7080706@paradoxnetworks.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CA30.7080706@paradoxnetworks.net> Message-ID: <20150227230942.GA24347@besserwisser.org> Subject: Re: Verizon Policy Statement on Net Neutrality Date: Fri, Feb 27, 2015 at 01:49:04PM -0600 Quoting Jack Bates (jbates at paradoxnetworks.net): > Ideally, I suspect that most people would prefer a more > variable approach, allowing for the complete frequency spectrum for > upload and download and any combination in between. What people want, at least once thay have tasted it, is optical last mile. And not that PON shit. The real stuff or bust. > Let's be honest, it would be nice to utilize wasted download > frequency to send something quicker. Any access technology with less than 1Gbit symmetrical bandwidth is 20th century. Doing greenfield with that is plainly stupid. There is business to be made from smaller upgrades to copper that is in place, but as soon as you dig (or set new poles in the ground), fiber is the only real alternative. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I like your SNOOPY POSTER!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From weaselkeeper at gmail.com Fri Feb 27 23:12:42 2015 From: weaselkeeper at gmail.com (Jim Richardson) Date: Fri, 27 Feb 2015 15:12:42 -0800 Subject: What is lawful content? [was VZ...] In-Reply-To: <13C5D0E6-2D15-430F-9A93-096C322C9A43@ianai.net> References: <13C5D0E6-2D15-430F-9A93-096C322C9A43@ianai.net> Message-ID: On Fri, Feb 27, 2015 at 2:23 PM, Patrick W. Gilmore wrote: > I am not a lawyer (in fact, I Am Not An Isp), but my understanding is this is pretty well settled. > > And it is not even weird or esoteric. If the content on the site is against the law in the jurisdiction in question, it is not legal (duh). Otherwise, yes it is, and no ISP gets to decide whether you can see it or not. Which is the "jurisdiction in question" ? the originating website? the ISP? the CDN network's corporate home? my home? From jbates at paradoxnetworks.net Fri Feb 27 23:22:49 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Fri, 27 Feb 2015 17:22:49 -0600 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725E373@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D7FE.9030905@meetinghouse.net> <54F0E156.7050504@paradoxnetworks.net> <9578293AE169674F9A048B2BC9A081B4015725E373@MUNPRDMBXA1.medline.com> Message-ID: <54F0FC49.5030706@paradoxnetworks.net> On 2/27/2015 4:32 PM, Naslund, Steve wrote: > You could do that. The only issue is that you are putting in more intelligent CPE that has to be frequency agile and signal to the head end what is happening. Carriers are very sensitive to CPE costs so I don't think that is likely to happen especially since I think that DSL is not considered leading edge service any more. I would expect the carriers to devote more effort to FTTP efforts than to keep trying to advance DSL. More intelligence in the chip that drives the connection. The CPE is generally wrapping around that chip. FTTP sounds great, but it just isn't appropriate in every scenario. > Sorry, no frequencies to play with on Ethernet. Ethernet is a baseband > technology (i.e. DC voltage, not AC frequencies) One pair is > transmitting, one pair is receiving in gigE. If you want to use both > pairs in the same direction to double up the bandwidth, that could be > done but it would not be Ethernet anymore. If you want to talk both > ways on the same pair, that is half duplex, we've left that idea in > the dust years ago. S I don't mean to argue, as I am by no means an expert, but I'm pretty sure that 1000Base-T is 4 pairs bidirectional. Wikipedia may have lied to me, though. My presumption is that anything supporting bidirectional communication on shared media can somehow shift that communication from symmetric to asymmetric dynamically. Jack From SNaslund at medline.com Fri Feb 27 23:24:17 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 27 Feb 2015 23:24:17 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <20150227.193238.315861968627315258.wwaites@tardis.ed.ac.uk> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> <20150227.193238.315861968627315258.wwaites@tardis.ed.ac.uk> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725E5B0@MUNPRDMBXA1.medline.com> >William Waites wrote: >This is a self-fulling prophecy. As long as the edge networks have asymmetry built into them popular programs and services will be developed that are structured to >account for this. As long as the popular programs and services are made like this, the "average user" >will not know that they might want something different. This is so wrong headed I don't know where to begin. As an ISP I build the network to provide what consumers want, that is how you stay in business and attract customers. >It doesn't have to be this way, its an artefact of a choice on the part of the larger (mostly telephone company) ISPs in the 1990s. It also happens to suit capital because it >is more obvious how to make money at the expense of the users with an asymmetric network and centralised "Web 2.0" style services. Wrong again. I was an ISP in the 1990s and our first DSL offerings were SDSL symmetric services to replace more expensive T-1 circuits. When we got into residential it was with SDSL and then the consumers wanted more downstream so ADSL was invented. I was there, I know this. I did not make more money because I sent traffic toward the user rather than up from the user. In fact, it cost us lots of money to beef up OUR connections to our Tier 1 providers to account for the high level of user download traffic. We would have loved it if all our users talked amongst themselves but that is not how the world works. >Thankfully the cracks are starting to show. I was pleased to hear the surprised and shocked praise when I installed a symmetric radio service to someone in the >neighbourhood and it was no longer painful for them to upload their photographs. Multi-party videoconferencing doesn't work well unless at least one participant (or a >server) is on good, symmetric bandwidth. These are just boring mundane applications. Imagine the more interesting ones that might emerge if the restriction of >asymmetry was no longer commonplace.. To that I will just say that if your average user spend as much time videoconferencing as they do watching streaming media then they are probably a business. Steven Naslund Chicago IL . From jbates at paradoxnetworks.net Fri Feb 27 23:25:41 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Fri, 27 Feb 2015 17:25:41 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <20150227230942.GA24347@besserwisser.org> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CA30.7080706@paradoxnetworks.net> <20150227230942.GA24347@besserwisser.org> Message-ID: <54F0FCF5.80006@paradoxnetworks.net> On 2/27/2015 5:09 PM, Måns Nilsson wrote: > What people want, at least once thay have tasted it, is optical last > mile. And not that PON shit. The real stuff or bust. Yeah. Then they complain when a tornado wipes out their power and they can't make a phone call. It's a real world. Things are not always what we want. I'm sorry, but while I could afford the tens of thousands of dollars to run power one mile to my house, I will not be seeing fiber anytime soon. As much as I hate it, looks like wireless point to point for awhile. :( Thinking of HAM radio to perhaps get help if things get really bad. >> Let's be honest, it would be nice to utilize wasted download >> frequency to send something quicker. > Any access technology with less than 1Gbit symmetrical bandwidth is > 20th century. Doing greenfield with that is plainly stupid. There > is business to be made from smaller upgrades to copper that is in place, > but as soon as you dig (or set new poles in the ground), fiber is the > only real alternative. It's hard to get DSL in some places in the country. Fiber? ha! Jack From deleskie at gmail.com Fri Feb 27 23:28:11 2015 From: deleskie at gmail.com (deleskie at gmail.com) Date: Fri, 27 Feb 2015 19:28:11 -0400 Subject: What is lawful content? [was VZ...] In-Reply-To: References: <13C5D0E6-2D15-430F-9A93-096C322C9A43@ianai.net> Message-ID: <20150227232811.5935253.20601.56670@gmail.com> I wonder if lawyer sit around all day and argue about CIDR notation Sent from my BlackBerry 10 smartphone on the Rogers network.   Original Message   From: Jim Richardson Sent: Friday, February 27, 2015 7:26 PM Cc: NANOG list Subject: Re: What is lawful content? [was VZ...] On Fri, Feb 27, 2015 at 2:23 PM, Patrick W. Gilmore wrote: > I am not a lawyer (in fact, I Am Not An Isp), but my understanding is this is pretty well settled. > > And it is not even weird or esoteric. If the content on the site is against the law in the jurisdiction in question, it is not legal (duh). Otherwise, yes it is, and no ISP gets to decide whether you can see it or not. Which is the "jurisdiction in question" ? the originating website? the ISP? the CDN network's corporate home? my home? From johnl at iecc.com Fri Feb 27 23:28:00 2015 From: johnl at iecc.com (John Levine) Date: 27 Feb 2015 23:28:00 -0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0D533.70100@vocalabs.com> Message-ID: <20150227232800.18584.qmail@ary.lan> In article <54F0D533.70100 at vocalabs.com> you write: >My point is that the option should be there, at the consumer level. It is. Just throttle your download speed to match your upload speed. R's, John From patrick at ianai.net Fri Feb 27 23:28:37 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 27 Feb 2015 18:28:37 -0500 Subject: What is lawful content? [was VZ...] In-Reply-To: References: <13C5D0E6-2D15-430F-9A93-096C322C9A43@ianai.net> Message-ID: On Feb 27, 2015, at 18:12 , Jim Richardson wrote: > On Fri, Feb 27, 2015 at 2:23 PM, Patrick W. Gilmore wrote: >> I am not a lawyer (in fact, I Am Not An Isp), but my understanding is this is pretty well settled. >> >> And it is not even weird or esoteric. If the content on the site is against the law in the jurisdiction in question, it is not legal (duh). Otherwise, yes it is, and no ISP gets to decide whether you can see it or not. > > Which is the "jurisdiction in question" ? the originating website? the > ISP? the CDN network's corporate home? my home? Again, well settled. It is where the end user is viewing the content _and_ where the content is served. If a CDN, then each node which serves the traffic must be in a place where it is legal. There are CDNs which do not serve all customers from all nodes for exactly this reason. -- TTFN, patrick From SNaslund at medline.com Fri Feb 27 23:32:22 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 27 Feb 2015 23:32:22 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0B2AE.6030902@meetinghouse.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0B2AE.6030902@meetinghouse.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725E60C@MUNPRDMBXA1.medline.com> That's my point. NANOG users are not the average user. For every one of you there are at least a thousand people who just want good Netflix connections and even if they might be backing up stuff remotely they are sending a few selfies and a couple Word docs. Steven Naslund Chicago IL >Hmm... my copy of crashplan is reporting 8mps of upload right now. >Granted, that's not average, but it can be sustained for a while, whenever I shut down a virtual machine (Parallels on a Mac, the entire virtual image takes a while to back >up - not all that uncommon). I also expect that most folks who buy a network backup service just use the default settings for when to do backups - which suggests an >awful lot of backup traffic going on at the same time every night. >Miles Fidelman From johnl at iecc.com Fri Feb 27 23:32:23 2015 From: johnl at iecc.com (John Levine) Date: 27 Feb 2015 23:32:23 -0000 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0E159.2000804@satchell.net> Message-ID: <20150227233223.18612.qmail@ary.lan> In article <54F0E159.2000804 at satchell.net> you write: >One of the FUD items I keep seeing from some factions is that the FCC >will regulate content on the Internet in the same way as they did for >television during the time of the "fairness doctrine". I agree, that's not going to happen. With the "legal content" rule, I expect some bottom feeding bulk mailers to sue claiming that their CAN SPAM compliant spam is legal, therefore the providers can't block it. R's, John From SNaslund at medline.com Fri Feb 27 23:39:30 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 27 Feb 2015 23:39:30 +0000 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F0FC49.5030706@paradoxnetworks.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D7FE.9030905@meetinghouse.net> <54F0E156.7050504@paradoxnetworks.net> <9578293AE169674F9A048B2BC9A081B4015725E373@MUNPRDMBXA1.medline.com> <54F0FC49.5030706@paradoxnetworks.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725E63D@MUNPRDMBXA1.medline.com> >> Sorry, no frequencies to play with on Ethernet. Ethernet is a baseband >> technology (i.e. DC voltage, not AC frequencies) One pair is >> transmitting, one pair is receiving in gigE. If you want to use both > >pairs in the same direction to double up the bandwidth, that could be > >done but it would not be Ethernet anymore. If you want to talk both > >ways on the same pair, that is half duplex, we've left that idea in > >the dust years ago. S >I don't mean to argue, as I am by no means an expert, but I'm pretty sure that 1000Base-T is 4 pairs bidirectional. Wikipedia may have lied to me, though. My >presumption is that anything supporting bidirectional communication on shared media can somehow shift that communication from symmetric to asymmetric >dynamically. No you are correct that when you are talking about 1000Base-T you are talking about four pairs bidirectionally which is a departure from 10 and 100 mbps Ethernet. That does not change the fact though that it is a baseband technology. You can't dynamically change that and still call it Ethernet. You are free to invent a new standard but it would be hard to do that given that 10G is available for those feeling pain at 1G. Steven Naslund Chicago IL From SNaslund at medline.com Fri Feb 27 23:42:50 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 27 Feb 2015 23:42:50 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0B0D8.9080904@paradoxnetworks.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0B0D8.9080904@paradoxnetworks.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725E66E@MUNPRDMBXA1.medline.com> Build it and they will come is a good way to go out of business in this industry. Steven Naslund Chicago IL > >It is likely not to change when people don't have the available upload to begin with. This is compounded by the queue problems on end devices. >How many more people would stream to twitch or youtube or skype if they didn't have to hear this, "Are you uploading? You're slowing down the download! I can't >watch my movie!" >Jack From Valdis.Kletnieks at vt.edu Fri Feb 27 23:42:50 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Feb 2015 18:42:50 -0500 Subject: What is lawful content? [was VZ...] In-Reply-To: Your message of "Fri, 27 Feb 2015 19:28:11 -0400." <20150227232811.5935253.20601.56670@gmail.com> References: <13C5D0E6-2D15-430F-9A93-096C322C9A43@ianai.net> <20150227232811.5935253.20601.56670@gmail.com> Message-ID: <36586.1425080570@turing-police.cc.vt.edu> On Fri, 27 Feb 2015 19:28:11 -0400, deleskie at gmail.com said: > I wonder if lawyer sit around all day and argue about CIDR notation Almost certainly not, because there's no murky gray areas about CIDR notation, much less ones that potentially affect how they do their jobs. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mel at beckman.org Fri Feb 27 23:44:02 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 27 Feb 2015 23:44:02 +0000 Subject: utility capacity, was Verizon Policy Statement on Net Neutrality In-Reply-To: <20150227225127.18489.qmail@ary.lan> References: , <20150227225127.18489.qmail@ary.lan> Message-ID: <2BCAFB3C-AA72-4573-A65C-F2DD626E5D23@beckman.org> John, That's an excellent point. Consider Google fiber, for example. And customer could theoretically demand a gigabit of traffic. Even Google admits that this doesn't scale and that they are highly oversubscribed. -mel beckman On Feb 27, 2015, at 3:05 PM, "John Levine" wrote: >> Water, gas, and to a great extent electrical systems do not work on >> oversubscription, ie their aggregate capacity meets or exceeds the needs of >> all their customers peak potential demand, at least from "normal" demand >> standpoint. > > Hi, former municipal water and sewer commissioner here. We size the > system to meet likely demand, but not peak demand. If it's a hot dry > summer and everyone wants to water their lawn, or there's a big fire > that's drawing a lot of water from hydrants, we can have capacity > problems. We deal with it by interrupting service to a few large > customers, a car wash and a golf course. > > But it's not really comparable to broadband service, because on the > Internet, nearly every consumer end user device could easily saturate > the entire network if it wanted to. It's like every house having a > 100,000 gallon toilet. Better hope you don't have a lot of people > flushing at once. > > R's, > John From mysidia at gmail.com Fri Feb 27 23:49:03 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 27 Feb 2015 17:49:03 -0600 Subject: What is lawful content? [was VZ...] In-Reply-To: <13C5D0E6-2D15-430F-9A93-096C322C9A43@ianai.net> References: <13C5D0E6-2D15-430F-9A93-096C322C9A43@ianai.net> Message-ID: On Fri, Feb 27, 2015 at 4:23 PM, Patrick W. Gilmore wrote: > Things like KP are obvious. Things like "adult" content here in the US are, for better or worse, also obvious (legal, in case you were wondering). I would prefer they replace use of the phrase "lawful internet traffic"; with "Internet traffic not prohibited by law and not related to a source, destination, or type of traffic prohibited specifically by provider's conspiciously published terms of service." The use of the phrase "LAWFUL" introduces ambiguity, since any traffic not specifically authorized by law could be said to be unlawful. Something neither prohibited nor stated to be allowed by law is by definition.... Unlawful as well.... > Things like gambling are the question, as that changes per location. -- -JH From owen at delong.com Fri Feb 27 23:44:58 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Feb 2015 15:44:58 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0F90B.4040402@free.fr> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <20150227165240.GA13738@puck.nether.net> <54F0AE3B.2010209@sprunk.org> <54F0B517.4050200@invaluement.com> <54F0B751.30008@pari.edu> <7AC0F5A4-67FA-47F2-B11F-8DD08439A790@delong.com> <54F0F90B.4040402@free.fr> Message-ID: <790657DC-94BF-4BBA-A56F-D514BFA3DFB6@delong.com> To the best of my knowledge, yes. Owen > On Feb 27, 2015, at 15:08 , Michael Hallgren wrote: > > Le 27/02/2015 23:19, Owen DeLong a écrit : >> Any website which does not violate the law. >> >> In other words, if a lawful takedown order > > So, subject to legal control rather than simply administrative. Right? > > mh > >> has been applied to a website, this code can’t be used to force an ISP to provide illegal access to said site. >> >> Owen >> >>> On Feb 27, 2015, at 11:14 , Jim Richardson wrote: >>> >>>> From 47CFR§8.5b >>> (b) A person engaged in the provision of mobile broadband Internet >>> access service, insofar as such person is so engaged, shall not block >>> consumers from accessing lawful Web sites, subject to reasonable >>> network management; nor shall such person block applications that >>> compete with the provider's voice or video telephony services, subject >>> to reasonable network management. >>> >>> What's a "lawful" web site? >>> >>> >>> On Fri, Feb 27, 2015 at 10:28 AM, Lamar Owen wrote: >>>> On 02/27/2015 01:19 PM, Rob McEwen wrote: >>>>> We're solving an almost non-existing problem.. by over-empowering an >>>>> already out of control US government, with powers that we can't even begin >>>>> to understand the extend of how they could be abused... to "fix" an industry >>>>> that has done amazingly good things for consumers in recent years. >>>>> >>>> You really should read 47CFR§8. It won't take you more than an hour or so, >>>> as it's only about 8 pages. >>>> >>>> The procedure for filing a complaint is pretty interesting, and requires the >>>> complainant to do some pretty involved things. (47CFR§8.14 for the complaint >>>> procedure, 47CFR§8.13 for the requirements for the pleading, etc). Note >>>> that the definitions found in 47CFR§8.11(a) and (b) are pretty specific in >>>> who is actually covered by 'net neutrality.' >>>> From jbates at paradoxnetworks.net Sat Feb 28 00:00:41 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Fri, 27 Feb 2015 18:00:41 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725E60C@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0B2AE.6030902@meetinghouse.net> <9578293AE169674F9A048B2BC9A081B4015725E60C@MUNPRDMBXA1.medline.com> Message-ID: <54F10529.1080207@paradoxnetworks.net> On 2/27/2015 5:32 PM, Naslund, Steve wrote: > That's my point. NANOG users are not the average user. For every one of you there are at least a thousand people who just want good Netflix connections and even if they might be backing up stuff remotely they are sending a few selfies and a couple Word docs. > > The next generation is growing up. They are streaming their games, spending huge amounts of time on skype in video groups, hosting servers, uploading video to youtube, and all kinds of things I don't do. Just the other day I got to hear about "oh, and I want my group to be able to watch this video with me on skype." What the companies aren't hearing yet, but what the parents are is.... "Dad, why can't we have more upload?" Jack From weaselkeeper at gmail.com Sat Feb 28 00:09:35 2015 From: weaselkeeper at gmail.com (Jim Richardson) Date: Fri, 27 Feb 2015 16:09:35 -0800 Subject: What is lawful content? [was VZ...] In-Reply-To: References: <13C5D0E6-2D15-430F-9A93-096C322C9A43@ianai.net> Message-ID: On Fri, Feb 27, 2015 at 3:28 PM, Patrick W. Gilmore wrote: > Again, well settled. > > It is where the end user is viewing the content _and_ where the content is served. If a CDN, then each node which serves the traffic must be in a place where it is legal. There are CDNs which do not serve all customers from all nodes for exactly this reason. Does this mean that viewing say, cartoons of mohammed, may or may not be 'illegal' for me to do, and result in my ISP being forced to block traffic, depending on what origin and route they take to get to me? Are we going to have the fedgov trying to enforce other country's censorship laws on us? From mfidelman at meetinghouse.net Sat Feb 28 00:47:11 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 27 Feb 2015 19:47:11 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F0E156.7050504@paradoxnetworks.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D7FE.9030905@meetinghouse.net> <54F0E156.7050504@paradoxnetworks.net> Message-ID: <54F1100F.9080605@meetinghouse.net> Jack Bates wrote: > On 2/27/2015 2:47 PM, Miles Fidelman wrote: >> Folks, >> >> Let's not go overboard here. Can we remember that most corporate and >> campus (and, for that matter home) networks are symmetric, at least >> at the edges. Personally, I figure that by deploying PON, the major >> carriers were just asking for trouble down the line. It's not like >> carrier-grade gigE switches are that much more expensive than PON gear. >> > > I'll disagree on the home part. I doubt that most homes are symmetric. Just to be clear - I'm talking about the local switch/router sitting on a home network, not the connection to the outside world. Last time I looked, commodity gigE switches were symmetric - good for network attached storage, media servers, that sort of thing. (Come to think of it, though, I've never paid attention to whether the WiFi side is symmetric.) Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mark.tinka at seacom.mu Sat Feb 28 04:02:09 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 28 Feb 2015 06:02:09 +0200 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <11287607.8005.1425056798993.JavaMail.mhammett@ThunderFuck> References: <11287607.8005.1425056798993.JavaMail.mhammett@ThunderFuck> Message-ID: <54F13DC1.7030507@seacom.mu> On 27/Feb/15 19:07, Mike Hammett wrote: > More symmetry will happen when the home user does more things that care about symmetry. It's a simple allocation of spectrum (whether wireless, DSL or cable). MHz for upload are taken out of MHz for download. But what comes first? I argue users will respond to their network conditions, without even knowing it. I have ADSL at my house. Because I sit on fibre at the office, I always forget that uploading an IOS or Junos image from my house to the data centre works terribly from home, until it hits me. Mark. From mark.tinka at seacom.mu Sat Feb 28 04:06:33 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 28 Feb 2015 06:06:33 +0200 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <5221.1425057216@turing-police.cc.vt.edu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> Message-ID: <54F13EC9.8070706@seacom.mu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27/Feb/15 19:13, Valdis.Kletnieks at vt.edu wrote: > > Consider a group of 10 users, who all create new content. If each one > creates at a constant rate of 5 mbits, they need 5 up. But to download > all the new content from the other 9, they need close to 50 down. > > And when you expand to several billion people creating new content, you need > a *huge* pipe down. Bottom line is that perfect symmetry isn't needed for > content distribution - most people can't create content fast enough to > clog their uplink, but have trouble picking and choosing what to downlink to > fit in the available bandwidth. Isn't this a phenomenon of the state of our (uplink) networks? Remove the restriction and see what happens? Mark. -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJU8T7JAAoJEGcZuYTeKm+Gni0P/A8j+pK4V6ipzfKHypGUeVJR QPxAGNpZiPG3xZhsiOvvYXyeFV3zvTYRj0m2BZzVfxrYSyT0FoB72xNxDLiALjIW 74l3stqWFAFUCW/5DG/A49VOsHAu0328f8PIlO10FbeusD6YDxJ5Y/w3pSQvNgEK NwaOsoQBomLLOzAVd+TwUfWw7WEqmp/nw8bohDMkpjvsyibf6G/ACZ7CrwTX7Ly9 vQDFUgNF//DkeDpl3QIPVTUch3wInK3BEhCkl5NnRo6DlILfoZdR9xafmXPU0ejH o+qGlLJoDkoieA8w/vht6WD8mPME75PlEsJdHLNM3I5270SfGfmqxtNpUofVP4hO ka4Hd6JngNXSdcLdSgl02QngnINyJ133dLd7p6kSSo2KG9eOga4838BzSzymQrNf +b4qbUjCyjjzAzJLtySrdNlrZxruR9kP5G3JX9uHbEaZ4z02raP33VBI6bvLnQvR 3FQ9Z5skRocTI2cwInUJpZjG8K1nIZINV2ivP8ah7mKo950o+BZ9NfhehOhjlx28 Dz4KZ2zak22zD7c9D2Wtkl4A14DxdCNOuCN1dh2Gl/uxcVrKXoPp0Max+FblaNyr mj0KnSJNkVc6I/SiHV5+WK8j+IBVJfs0/tA9uKXQgObmhmLhVejDSmteptbD6Pwh kIsFpVO7BdwQVGVUgrOh =nZQs -----END PGP SIGNATURE----- From owen at delong.com Sat Feb 28 04:23:47 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Feb 2015 20:23:47 -0800 Subject: What is lawful content? [was VZ...] In-Reply-To: References: <13C5D0E6-2D15-430F-9A93-096C322C9A43@ianai.net> Message-ID: <68F794FF-E6E1-4F06-9DDF-95D42F9A00B2@delong.com> > On Feb 27, 2015, at 15:49 , Jimmy Hess wrote: > > On Fri, Feb 27, 2015 at 4:23 PM, Patrick W. Gilmore wrote: >> Things like KP are obvious. Things like "adult" content here in the US are, for better or worse, also obvious (legal, in case you were wondering). > > I would prefer they replace use of the phrase "lawful internet > traffic"; with "Internet traffic not prohibited by law and not > related to a source, destination, or type of traffic prohibited > specifically by provider's conspiciously published terms of service." > > The use of the phrase "LAWFUL" introduces ambiguity, since any > traffic not specifically authorized by law could be said to be > unlawful. Since we are talking about US law, you are not correct. Anything not specifically prohibited by law in the US is lawful. > Something neither prohibited nor stated to be allowed by law is by > definition.... Unlawful as well…. Sorry, but no, that’s simply not accurate in the united states as legal terminology applies: From law.com (I’m too cheap to pay for a subscription to Black’s): unlawful adj. referring to any action which is in violation of a statute, federal or state constitution, or established legal precedents Ergo, lawful would be anything which is not in violation of a statute, federal or state constitution, or established legal precedents. Owen From jgreco at ns.sol.net Sat Feb 28 05:09:58 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 27 Feb 2015 23:09:58 -0600 (CST) Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F13EC9.8070706@seacom.mu> Message-ID: <201502280509.t1S59wab008596@aurora.sol.net> > On 27/Feb/15 19:13, Valdis.Kletnieks at vt.edu wrote: > > Consider a group of 10 users, who all create new content. If each one > > creates at a constant rate of 5 mbits, they need 5 up. But to download > > all the new content from the other 9, they need close to 50 down. > > > > And when you expand to several billion people creating new content, > you need > > a *huge* pipe down. Bottom line is that perfect symmetry isn't needed for > > content distribution - most people can't create content fast enough to > > clog their uplink, but have trouble picking and choosing what to > downlink to > > fit in the available bandwidth. > > Isn't this a phenomenon of the state of our (uplink) networks? > > Remove the restriction and see what happens? Only partially. It is also a phenomenon of having built the first broadband networks with that asymmetry, which in turn discouraged a whole host of potential applications, which in turn creates a sort of bizarre self-fulfilling prophecy: broadband networks don't see much call for tons of upstream because it wasn't available, and so there aren't lots of apps for it, and so users don't ask for it, and so the cycle continues. In many cases, users who had high upstream requirements have been instead working around the brokenness by, for example, renting a server at a datacenter. I know lots of gamers do this, etc. So even if we were to create massive new upstream capacity tomorrow, it might appear for many years that there's little interest. Consider streaming video. We theoretically had sufficient speed to do this at least ten years ago, but it took a long time for the technology to mature and catch on. However, it should be obvious that the best route to guaranteeing that new technologies do not develop is to keep the status quo. With wildly asymmetric speeds, upstream speeds are sometimes barely enough for the things we do today (and are already insufficient for network based backup strategies, etc). Just try uploading a DVD ISO image for VM deployment from home to work ... The current service offerings generally seem to avoid offering high upstream speeds entirely, and so effectively eliminate even the potential to explore the problem on a somewhat less-rigged basis. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From owen at delong.com Sat Feb 28 04:27:46 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Feb 2015 20:27:46 -0800 Subject: What is lawful content? [was VZ...] In-Reply-To: References: <13C5D0E6-2D15-430F-9A93-096C322C9A43@ianai.net> Message-ID: > On Feb 27, 2015, at 16:09 , Jim Richardson wrote: > > On Fri, Feb 27, 2015 at 3:28 PM, Patrick W. Gilmore wrote: >> Again, well settled. >> >> It is where the end user is viewing the content _and_ where the content is served. If a CDN, then each node which serves the traffic must be in a place where it is legal. There are CDNs which do not serve all customers from all nodes for exactly this reason. > > Does this mean that viewing say, cartoons of mohammed, may or may not > be 'illegal' for me to do, and result in my ISP being forced to block > traffic, depending on what origin and route they take to get to me? > > Are we going to have the fedgov trying to enforce other country's > censorship laws on us? This is absurd. The source server is under the jurisdiction of the sovereigns in that location. Any enforcement of their laws upon the source server is carried out at the source by them. The recipient client is under the jurisdictions of the sovereigns in that location. Any enforcement of their laws upon the recipient is carried out there by them. In the case of a US ISP, their local jurisdiction should (though I haven’t read the detailed rules yet) be pre-empted from content based interference by the federal preemption rules and the applicability of Title II. Federal law would still, however, apply, and so an ISP would not be allowed to route traffic to/from a site which they have been notified through proper due process is violating US law. Beyond the borders of the US, the FCC has little or no ability to enforce anything. Owen From weaselkeeper at gmail.com Sat Feb 28 04:33:51 2015 From: weaselkeeper at gmail.com (Jim Richardson) Date: Fri, 27 Feb 2015 20:33:51 -0800 Subject: What is lawful content? [was VZ...] In-Reply-To: References: <13C5D0E6-2D15-430F-9A93-096C322C9A43@ianai.net> Message-ID: I am sure The Gibson guitar company thought the same thing about the EPA. At least we can be sure that a TLA govt agency wouldn't be used to harass an administration's political opponents, right? On Fri, Feb 27, 2015 at 8:27 PM, Owen DeLong wrote: > >> On Feb 27, 2015, at 16:09 , Jim Richardson wrote: >> >> On Fri, Feb 27, 2015 at 3:28 PM, Patrick W. Gilmore wrote: >>> Again, well settled. >>> >>> It is where the end user is viewing the content _and_ where the content is served. If a CDN, then each node which serves the traffic must be in a place where it is legal. There are CDNs which do not serve all customers from all nodes for exactly this reason. >> >> Does this mean that viewing say, cartoons of mohammed, may or may not >> be 'illegal' for me to do, and result in my ISP being forced to block >> traffic, depending on what origin and route they take to get to me? >> >> Are we going to have the fedgov trying to enforce other country's >> censorship laws on us? > > > This is absurd. > > The source server is under the jurisdiction of the sovereigns in that location. Any enforcement of their laws upon the source server is carried out at the source by them. > > The recipient client is under the jurisdictions of the sovereigns in that location. Any enforcement of their laws upon the recipient is carried out there by them. > > In the case of a US ISP, their local jurisdiction should (though I haven’t read the detailed rules yet) be pre-empted from content based interference by the federal preemption rules and the applicability of Title II. Federal law would still, however, apply, and so an ISP would not be allowed to route traffic to/from a site which they have been notified through proper due process is violating US law. > > Beyond the borders of the US, the FCC has little or no ability to enforce anything. > > Owen > From mike at mtcc.com Sat Feb 28 04:47:36 2015 From: mike at mtcc.com (Michael Thomas) Date: Fri, 27 Feb 2015 20:47:36 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725E400@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <6C2AD229-D571-4220-8D7B-F2F8CC119185@consultant.com> <9578293AE169674F9A048B2BC9A081B4015725E400@MUNPRDMBXA1.medline.com> Message-ID: <54F14868.7040903@mtcc.com> On 02/27/2015 02:52 PM, Naslund, Steve wrote: > What is that statement based on? I have not seen any outcry for more symmetric speeds. Asymmetry in our networks causes a lot of engineering issues and if it were up to the carriers, we would much rather have more symmetric traffic patterns because it would make life easier for us. Remember that most carrier backbones are built of symmetric circuits. It would be nice but the users generally download more than they upload. That is the fact. > Average != Peak. Why is this so hard to understand? Mike From mark.tinka at seacom.mu Sat Feb 28 04:54:39 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 28 Feb 2015 06:54:39 +0200 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> Message-ID: <54F14A0F.5050308@seacom.mu> On 27/Feb/15 19:27, Naslund, Steve wrote: > That statement completely confuses me. Why is asymmetry evil? Does that not reflect what "Joe Average User" actually needs and wants? The statement that the average users *MUST* have the same pipes going UP as he does going DOWN does not reflect reality at all. Do a lot of your users want to stream 4K video to their friends UHD TV? Given that all transmission media has some sort of bandwidth limit it would seem to me that asymmetry is actually more fair for the user since he gets more of what he needs which is download speed. There is no technical reason that it can't be symmetric it is just a reflection of what the market wants. As an ISP I can tell you that a lot more people complaint about their download speeds than their upload speeds. Do you think that you (or the average home user) would be happier with 27.5 down and 27.5 up vs your 50 down and 5 up you have today? Don't tell me you want 50 down and 50 up because that is a different bandwidth total that requires a faster transmission media. The person at the other end of my Facetime call was frustrated that they couldn't see me when I took the call from my house (320Kbps up, ADSL) yet I could see them perfectly (4Mbps down, ADSL). Would I like for them to have been able to see me as I did them? Mark. From mark.tinka at seacom.mu Sat Feb 28 04:57:05 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 28 Feb 2015 06:57:05 +0200 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725DE54@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <54F0A62C.70704@paradoxnetworks.net> <9578293AE169674F9A048B2BC9A081B4015725DE54@MUNPRDMBXA1.medline.com> Message-ID: <54F14AA1.70901@seacom.mu> On 27/Feb/15 19:40, Naslund, Steve wrote: > We also sold SDSL which is symmetric service and the primary buyers were generally businesses. That was because of the way it was priced and marketed. Mark. From mark.tinka at seacom.mu Sat Feb 28 04:58:10 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 28 Feb 2015 06:58:10 +0200 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> Message-ID: <54F14AE2.9000006@seacom.mu> On 27/Feb/15 19:48, Naslund, Steve wrote: > How about this? Show me 10 users in the average neighborhood creating content at 5 mbps....Period. Only realistic app I see is home surveillance but I don't think you want everyone accessing that anyway. The truth is that the average user does not create content that anyone needs to see. This has not changed throughout the ages, the ratio of authors to readers, artists to art lovers, musicians to music lovers, YouTube cat video creator to cat video lovers, has never been a many to many relationship. The neighborhood getting together on Facetime to plot how to spend their days after the husbands have gone off to work comes to mind. But wait... Mark. From mark.tinka at seacom.mu Sat Feb 28 05:02:33 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 28 Feb 2015 07:02:33 +0200 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0B1CB.4030808@meetinghouse.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> <54F0B1CB.4030808@meetinghouse.net> Message-ID: <54F14BE9.4060403@seacom.mu> On 27/Feb/15 20:04, Miles Fidelman wrote: > > > Having said all that, has anyone else noticed that Verizon has been > pushing symmetric bandwidth in their new FIOS plans? Not sure how > well it's working though - a lot of the early deployment is BPON, > which tops out at 155Mbps for uploads - theoretically, I have 25/25 > service, but I've occasionally seen my uploads fall to 100kbps (yes > that's a k). Highly intermittent though - Verizon's techs have been > having lots of fun trying to track things down. And this is one of the reasons I think xPON is still the wrong way to go, if the industry feels symmetry is worth a dime. But, admittedly, that's just me... Mark. From owen at delong.com Sat Feb 28 05:07:10 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Feb 2015 21:07:10 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F14AE2.9000006@seacom.mu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F14AE2.9000006@seacom.mu> Message-ID: <16E90717-90BC-4794-9620-4C7FA6C7C479@delong.com> > On Feb 27, 2015, at 20:58 , Mark Tinka wrote: > > > > On 27/Feb/15 19:48, Naslund, Steve wrote: >> How about this? Show me 10 users in the average neighborhood creating content at 5 mbps....Period. Only realistic app I see is home surveillance but I don't think you want everyone accessing that anyway. The truth is that the average user does not create content that anyone needs to see. This has not changed throughout the ages, the ratio of authors to readers, artists to art lovers, musicians to music lovers, YouTube cat video creator to cat video lovers, has never been a many to many relationship. > > The neighborhood getting together on Facetime to plot how to spend their > days after the husbands have gone off to work comes to mind. > > But wait... > > Mark. Even in that case, Mark, you have a conference call where each person is sending a stream out to a rendezvous point that is then sending it back to N people where N is the number of people in the chat -1. So the downstream bandwidth will be N*upstream for each of them. Owen From mark.tinka at seacom.mu Sat Feb 28 05:12:53 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 28 Feb 2015 07:12:53 +0200 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <201502280509.t1S59wab008596@aurora.sol.net> References: <201502280509.t1S59wab008596@aurora.sol.net> Message-ID: <54F14E55.4040203@seacom.mu> On 28/Feb/15 07:09, Joe Greco wrote: > Only partially. It is also a phenomenon of having built the first > broadband networks with that asymmetry, which in turn discouraged a > whole host of potential applications, which in turn creates a sort > of bizarre self-fulfilling prophecy: broadband networks don't see > much call for tons of upstream because it wasn't available, and so > there aren't lots of apps for it, and so users don't ask for it, > and so the cycle continues. My point. It's not that folk don't ask for more uplink, but it's that they adjust to their situation because it's hard enough getting a sales person on the phone that knows what their doing, let along getting someone clued up to come install the damn thing. It's like cellphone toll quality - we've all accepted that if the call is unclear or drops, we simply ring our party back instead of doing something about it. We adapt to our network conditions where we know further argument will yield strokes and heart attacks. It does not mean we don't want better... > > In many cases, users who had high upstream requirements have been > instead working around the brokenness by, for example, renting a > server at a datacenter. I know lots of gamers do this, etc. A lot of my staff queue their uploads until they get to the office, where we have fibre to our PoP. That's saying much... > > So even if we were to create massive new upstream capacity tomorrow, > it might appear for many years that there's little interest. Consider > streaming video. We theoretically had sufficient speed to do this at > least ten years ago, but it took a long time for the technology to > mature and catch on. > > However, it should be obvious that the best route to guaranteeing that > new technologies do not develop is to keep the status quo. With > wildly asymmetric speeds, upstream speeds are sometimes barely enough > for the things we do today (and are already insufficient for network > based backup strategies, etc). Just try uploading a DVD ISO image > for VM deployment from home to work ... > > The current service offerings generally seem to avoid offering high > upstream speeds entirely, and so effectively eliminate even the > potential to explore the problem on a somewhat less-rigged basis. Agree - but fundamental change like this doesn't happen overnight. Whenever we start increasing upload speed, there will be reasonable latency until users start to take advantage. So the sooner, the sooner. Mark. From tagno25 at gmail.com Sat Feb 28 05:15:17 2015 From: tagno25 at gmail.com (Philip Dorr) Date: Fri, 27 Feb 2015 23:15:17 -0600 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F1100F.9080605@meetinghouse.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D7FE.9030905@meetinghouse.net> <54F0E156.7050504@paradoxnetworks.net> <54F1100F.9080605@meetinghouse.net> Message-ID: On Feb 27, 2015 6:48 PM, "Miles Fidelman" wrote: > > Jack Bates wrote: >> >> On 2/27/2015 2:47 PM, Miles Fidelman wrote: >>> >>> Folks, >>> >>> Let's not go overboard here. Can we remember that most corporate and campus (and, for that matter home) networks are symmetric, at least at the edges. Personally, I figure that by deploying PON, the major carriers were just asking for trouble down the line. It's not like carrier-grade gigE switches are that much more expensive than PON gear. >>> >> >> I'll disagree on the home part. I doubt that most homes are symmetric. > > > Just to be clear - I'm talking about the local switch/router sitting on a home network, not the connection to the outside world. Last time I looked, commodity gigE switches were symmetric - good for network attached storage, media servers, that sort of thing. (Come to think of it, though, I've never paid attention to whether the WiFi side is symmetric.) Commodity switches are symmetric for multiple reasons, but the biggest is probably because a server could be on any port and a client on any other port. WiFi has two separate data rate selections. The download could be at 300mbps and the upload only be at 1mbps. Or even the other way. WiFi is also half-duplex, so if the data rate is 300mbps, then the maximum you should expect is 150mbps. From mark.tinka at seacom.mu Sat Feb 28 05:15:10 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 28 Feb 2015 07:15:10 +0200 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <16E90717-90BC-4794-9620-4C7FA6C7C479@delong.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F14AE2.9000006@seacom.mu> <16E90717-90BC-4794-9620-4C7FA6C7C479@delong.com> Message-ID: <54F14EDE.8010005@seacom.mu> On 28/Feb/15 07:07, Owen DeLong wrote: > Even in that case, Mark, you have a conference call where each person is sending a stream out to a rendezvous point that is then sending it back to N people where N is the number of people in the chat -1. So the downstream bandwidth will be N*upstream for each of them. But you're assuming the video chat is the only thing taking place in the upward direction... When my wife is doing her iCloud backup, I can't log into a router to do some work without gouging my eyes out. Mark. From mark.tinka at seacom.mu Sat Feb 28 05:26:28 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 28 Feb 2015 07:26:28 +0200 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D7FE.9030905@meetinghouse.net> <54F0E156.7050504@paradoxnetworks.net> <54F1100F.9080605@meetinghouse.net> Message-ID: <54F15184.6070407@seacom.mu> On 28/Feb/15 07:15, Philip Dorr wrote: > > WiFi has two separate data rate selections. The download could be at > 300mbps and the upload only be at 1mbps. Or even the other way. WiFi is > also half-duplex, so if the data rate is 300mbps, then the maximum you > should expect is 150mbps. This is easy to fix. If one needs to push more than 150Mbps upload out of their home gateway, get 802.11ac or run a cable from your favorite spot at the house to a cheap but fast home switch you can pick up from the store. The more difficult problem is how your ISP offers you onward uplink to match what you can push out of your home, as this thread is addressing. Mark. From josmon at rigozsaurus.com Sat Feb 28 05:42:23 2015 From: josmon at rigozsaurus.com (John Osmon) Date: Fri, 27 Feb 2015 22:42:23 -0700 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: <20150227233223.18612.qmail@ary.lan> References: <54F0E159.2000804@satchell.net> <20150227233223.18612.qmail@ary.lan> Message-ID: <20150228054223.GA5915@jeeves.rigozsaurus.com> On Fri, Feb 27, 2015 at 11:32:23PM -0000, John Levine wrote: [...] > With the "legal content" rule, I expect some bottom feeding bulk > mailers to sue claiming that their CAN SPAM compliant spam is legal, > therefore the providers can't block it. Yeah... I've had a recurring nightmare for a while now. There are spammers that skate on the edge of "legal." Since they're legal, I can't drop their traffic anymore -- and they start filling my transit pipes. Then, they force me to privately peer with them... ...and then sue me to get bigger pipes... But hey -- at least it's neutral, so that's good. From collin at averysmallbird.com Sat Feb 28 05:48:07 2015 From: collin at averysmallbird.com (Collin Anderson) Date: Sat, 28 Feb 2015 14:48:07 +0900 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: <20150227233223.18612.qmail@ary.lan> References: <54F0E159.2000804@satchell.net> <20150227233223.18612.qmail@ary.lan> Message-ID: On Sat, Feb 28, 2015 at 8:32 AM, John Levine wrote: > With the "legal content" rule, I expect some bottom feeding bulk > mailers to sue claiming that their CAN SPAM compliant spam is legal, > therefore the providers can't block it. > How would this legal environment be any different than the pre-Verizon network neutrality rules for network management of SPAM? -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C. From owen at delong.com Sat Feb 28 05:48:54 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Feb 2015 21:48:54 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F14EDE.8010005@seacom.mu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F14AE2.9000006@seacom.mu> <16E90717-90BC-4794-9620-4C7FA6C7C479@delong.com> <54F14EDE.8010005@seacom.mu> Message-ID: <15477A98-E9AF-4AF9-AF27-6CFCD3A7F247@delong.com> > On Feb 27, 2015, at 21:15 , Mark Tinka wrote: > > > > On 28/Feb/15 07:07, Owen DeLong wrote: >> Even in that case, Mark, you have a conference call where each person is sending a stream out to a rendezvous point that is then sending it back to N people where N is the number of people in the chat -1. So the downstream bandwidth will be N*upstream for each of them. > > But you're assuming the video chat is the only thing taking place in the > upward direction... > > When my wife is doing her iCloud backup, I can't log into a router to do > some work without gouging my eyes out. No, I’m not assuming anything other than that you claimed the video chat justified a need for symmetry when in reality, it does not. I’m all for better upstream bandwidth to the home. I’d love to have everyone have 1G/1G capability even if it’s 100:1 oversubscribed on the upstream. However, I’d much rather have 384M/128M than 256M/256M to be honest. In general, I find my 30M/7M is not too terribly painful most of the time. Do I wish I had more upstream? Yes, but not as much as I wish I had more downstream. I think an ideal minimum that would probably be comfortable most of the time today would be 100M/30M. YMMV. Owen From mark.tinka at seacom.mu Sat Feb 28 06:23:54 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 28 Feb 2015 08:23:54 +0200 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <15477A98-E9AF-4AF9-AF27-6CFCD3A7F247@delong.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F14AE2.9000006@seacom.mu> <16E90717-90BC-4794-9620-4C7FA6C7C479@delong.com> <54F14EDE.8010005@seacom.mu> <15477A98-E9AF-4AF9-AF27-6CFCD3A7F247@delong.com> Message-ID: <54F15EFA.6050003@seacom.mu> On 28/Feb/15 07:48, Owen DeLong wrote: > No, I’m not assuming anything other than that you claimed the video chat justified a need for symmetry when in reality, it does not. > > I’m all for better upstream bandwidth to the home. I’d love to have everyone have 1G/1G capability even if it’s 100:1 oversubscribed on the upstream. > > However, I’d much rather have 384M/128M than 256M/256M to be honest. > > In general, I find my 30M/7M is not too terribly painful most of the time. Do I wish I had more upstream? Yes, but not as much as I wish I had more downstream. I think an ideal minimum that would probably be comfortable most of the time today would be 100M/30M. Limitations by technology are things we can't do anything about. ADSL, GPON, e.t.c. If one is taking Ethernet into the home, then a limitation on the uplink is a function of a direct or implicit rate limit imposed by the operator, and not by the hardware. In such cases, competition will ensure a reasonable level playing field for the consumer. With limitations in hardware, every operator has the same problem, so the issue is a non-starter. You're right, I do not necessarily need 1Gbps up, 1Gbps down. I just need enough to get me by. GPON gives you (what one would say) reasonable bandwidth upward, but then the uplink from the OLT to the BRAS becomes a choke point because GPON is, well, asymmetric. So then, some would ask, "What is the point of my 30Mbps up, 100Mbps down GPON?" YMM will really V, of course. Active-E is 1Gbps up, 1Gbps down. Uplink to the BRAS is 10Gbps/100Gbps up, 10Gbps/100Gbps down. Any limitations in upward (or downward) performance are not constructs of the hardware, but of how the network operator runs it. Mark. From owen at delong.com Sat Feb 28 08:51:04 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 28 Feb 2015 00:51:04 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F15EFA.6050003@seacom.mu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F14AE2.9000006@seacom.mu> <16E90717-90BC-4794-9620-4C7FA6C7C479@delong.com> <54F14EDE.8010005@seacom.mu> <15477A98-E9AF-4AF9-AF27-6CFCD3A7F247@delong.com> <54F15EFA.6050003@seacom.mu> Message-ID: > On Feb 27, 2015, at 22:23 , Mark Tinka wrote: > > > > On 28/Feb/15 07:48, Owen DeLong wrote: >> No, I’m not assuming anything other than that you claimed the video chat justified a need for symmetry when in reality, it does not. >> >> I’m all for better upstream bandwidth to the home. I’d love to have everyone have 1G/1G capability even if it’s 100:1 oversubscribed on the upstream. >> >> However, I’d much rather have 384M/128M than 256M/256M to be honest. >> >> In general, I find my 30M/7M is not too terribly painful most of the time. Do I wish I had more upstream? Yes, but not as much as I wish I had more downstream. I think an ideal minimum that would probably be comfortable most of the time today would be 100M/30M. > > Limitations by technology are things we can't do anything about. ADSL, > GPON, e.t.c. > > If one is taking Ethernet into the home, then a limitation on the uplink > is a function of a direct or implicit rate limit imposed by the > operator, and not by the hardware. In such cases, competition will > ensure a reasonable level playing field for the consumer. With > limitations in hardware, every operator has the same problem, so the > issue is a non-starter. Competition? What competition? I realize you’re not in the US, so perhaps there is some form of meaningful competition in Mauritius. There is no such thing in the US. It’s oligopolies at best and monopolies at worst. We have, unfortunately, allowed the natural monopoly that exists in infrastructure (layer 1) to be leveraged by private enterprise to form an effective monopoly on services. > You're right, I do not necessarily need 1Gbps up, 1Gbps down. I just > need enough to get me by. GPON gives you (what one would say) reasonable > bandwidth upward, but then the uplink from the OLT to the BRAS becomes a > choke point because GPON is, well, asymmetric. So then, some would ask, > "What is the point of my 30Mbps up, 100Mbps down GPON?" YMM will really > V, of course. > > Active-E is 1Gbps up, 1Gbps down. Uplink to the BRAS is 10Gbps/100Gbps > up, 10Gbps/100Gbps down. Any limitations in upward (or downward) > performance are not constructs of the hardware, but of how the network > operator runs it. The point here is that adequate up and adequate down are not necessarily defined by having them be equal. Yes, you get better uplink speeds on symmetrical technologies. That’s sort of inherent in the fact that asymmetrical technologies are all built for higher downstream speeds and lower upstream speeds. My point is that in the vast majority of cases, a hardware limitation where the downstream is faster than the upstream is not inappropriate for the vast majority of content consumers. The problem is that in most cases, consumers are not given adequate upstream bandwidth, regardless of the size of their downstream bandwidth. If you had a good solid 256Mbps up and 1Gbps down, I’m betting you would be a lot less upset about the asymmetrical nature of the circuit. Even if you continued to complain, I think you will admit that the vast majority of users would be quite happy. I know I would and I’m pretty upstream-heavy for the average residential user. Owen From mark.tinka at seacom.mu Sat Feb 28 09:22:27 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 28 Feb 2015 11:22:27 +0200 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F14AE2.9000006@seacom.mu> <16E90717-90BC-4794-9620-4C7FA6C7C479@delong.com> <54F14EDE.8010005@seacom.mu> <15477A98-E9AF-4AF9-AF27-6CFCD3A7F247@delong.com> <54F15EFA.6050003@seacom.mu> Message-ID: <54F188D3.5090205@seacom.mu> On 28/Feb/15 10:51, Owen DeLong wrote: > Competition? What competition? I realize you’re not in the US,... Yes, I know competition in the U.S. is not where it ought to be :-). My comment was more global, as we all use the same technologies around the world, even though you do get varying levels of market conditions as such. > so perhaps there is some form of meaningful competition in Mauritius. I am based in South Africa, which isn't saying much. The .mu domain throws everyone off :-). > > There is no such thing in the US. It’s oligopolies at best and monopolies at worst. > > We have, unfortunately, allowed the natural monopoly that exists in infrastructure (layer 1) to be leveraged by private enterprise to form an effective monopoly on services. I'll continue to postpone my immigration to those unions :-). > The point here is that adequate up and adequate down are not necessarily defined by having them be equal. Yes, you get better uplink speeds on symmetrical technologies. That’s sort of inherent in the fact that asymmetrical technologies are all built for higher downstream speeds and lower upstream speeds. I agree. > > My point is that in the vast majority of cases, a hardware limitation where the downstream is faster than the upstream is not inappropriate for the vast majority of content consumers. The problem is that in most cases, consumers are not given adequate upstream bandwidth, regardless of the size of their downstream bandwidth. This is where I disagree, because we are making the case for (the vast majority of) customers based on the technologies they/we have always used. We have seen what can happen to GSM networks when you put a smartphone in the hands of an ordinary Jane. Not even the mobile operators saw that one coming. Let us open up the uplink pipes and see what happens. If we keep on thinking that the patterns will always be the way they are today, the patterns will always be the way they are today. > > If you had a good solid 256Mbps up and 1Gbps down, I’m betting you would be a lot less upset about the asymmetrical nature of the circuit. Even if you continued to complain, I think you will admit that the vast majority of users would be quite happy. I know I would and I’m pretty upstream-heavy for the average residential user. Yes! I would be very happy with that if it were reasonably reliable, or degraded in a way that would at least leave me reasonably happy. Symmetric circuits significantly reduce the likelihood of degradation on the uplink more than asymmetric circuits do. So an asymmetric service on a symmetric network is more likely to perform better than any service on an asymmetric network. Ultimately, that is my point. Mark. From owen at delong.com Sat Feb 28 09:29:39 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 28 Feb 2015 01:29:39 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F188D3.5090205@seacom.mu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F14AE2.9000006@seacom.mu> <16E90717-90BC-4794-9620-4C7FA6C7C479@delong.com> <54F14EDE.8010005@seacom.mu> <15477A98-E9AF-4AF9-AF27-6CFCD3A7F247@delong.com> <54F15EFA.6050003@seacom.mu> <54F188D3.5090205@seacom.mu> Message-ID: <524C482F-A4BD-40DC-B1DB-30CC1BB52ADC@delong.com> > On Feb 28, 2015, at 01:22 , Mark Tinka wrote: > > > > On 28/Feb/15 10:51, Owen DeLong wrote: >> Competition? What competition? I realize you’re not in the US,... > > Yes, I know competition in the U.S. is not where it ought to be :-). > > My comment was more global, as we all use the same technologies around > the world, even though you do get varying levels of market conditions as > such. > >> so perhaps there is some form of meaningful competition in Mauritius. > > I am based in South Africa, which isn't saying much. > > The .mu domain throws everyone off :-). > >> >> There is no such thing in the US. It’s oligopolies at best and monopolies at worst. >> >> We have, unfortunately, allowed the natural monopoly that exists in infrastructure (layer 1) to be leveraged by private enterprise to form an effective monopoly on services. > > I'll continue to postpone my immigration to those unions :-). > >> The point here is that adequate up and adequate down are not necessarily defined by having them be equal. Yes, you get better uplink speeds on symmetrical technologies. That’s sort of inherent in the fact that asymmetrical technologies are all built for higher downstream speeds and lower upstream speeds. > > I agree. > >> >> My point is that in the vast majority of cases, a hardware limitation where the downstream is faster than the upstream is not inappropriate for the vast majority of content consumers. The problem is that in most cases, consumers are not given adequate upstream bandwidth, regardless of the size of their downstream bandwidth. > > This is where I disagree, because we are making the case for (the vast > majority of) customers based on the technologies they/we have always used. This is where I disagree with you. Look at it this way… I bet even you consume far more content than you produce. Everyone does. It is the nature of any one to many relationship. We consume content from many sources. We are but one source of content. Even if everyone produced the same amount of content, mathematically, you’d be consuming more than you are producing if everyone consumed everything. If you have an example of any concept of an application where an end-user is likely to need the same amount of bandwidth upstream as they do downstream, I’m all ears. Your first example utterly failed. Do you have a better example to offer? > We have seen what can happen to GSM networks when you put a smartphone > in the hands of an ordinary Jane. Not even the mobile operators saw that > one coming. Even phones consume asymmetrically and almost entirely down-stream. > Let us open up the uplink pipes and see what happens. If we keep on > thinking that the patterns will always be the way they are today, the > patterns will always be the way they are today. I’m all for bigger uplink pipes, but insisting on symmetry is absurd. > >> >> If you had a good solid 256Mbps up and 1Gbps down, I’m betting you would be a lot less upset about the asymmetrical nature of the circuit. Even if you continued to complain, I think you will admit that the vast majority of users would be quite happy. I know I would and I’m pretty upstream-heavy for the average residential user. > > Yes! I would be very happy with that if it were reasonably reliable, or > degraded in a way that would at least leave me reasonably happy. Not sure what you mean by “degraded in a way that would make you happy”. > > Symmetric circuits significantly reduce the likelihood of degradation on > the uplink more than asymmetric circuits do. So an asymmetric service on > a symmetric network is more likely to perform better than any service on > an asymmetric network. Ultimately, that is my point. This makes no sense whatsoever. Owen From wwaites at tardis.ed.ac.uk Sat Feb 28 09:47:12 2015 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Sat, 28 Feb 2015 09:47:12 +0000 (GMT) Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725E5B0@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> <20150227.193238.315861968627315258.wwaites@tardis.ed.ac.uk> <9578293AE169674F9A048B2BC9A081B4015725E5B0@MUNPRDMBXA1.medline.com> Message-ID: <20150228.094712.1305952464703391341.wwaites@tardis.ed.ac.uk> On Fri, 27 Feb 2015 23:24:17 +0000, "Naslund, Steve" said: > I was an ISP in the 1990s and our first DSL offerings were SDSL > symmetric services to replace more expensive T-1 circuits. When > we got into residential it was with SDSL and then the consumers > wanted more downstream so ADSL was invented. I was there, I > know this. So was I and my experience was different. We decided that it would be more profitable as a small ISP to re-sell Bell Canada's ADSL than to try to unbundle central offices all over the place. The arguments from the business side had nothing whatsoever to do with symmetry or lack thereof. The choice of technology was entirely by the ILEC. > To that I will just say that if your average user spend as much > time videoconferencing as they do watching streaming media then > they are probably a business. No, you misunderstand. I don't dispute that the area under end-user traffic statistics graphs is asymmetric. But that the maximum value -- particularly the instantaneous maximum value which you don't see with five minute sampling -- wants to be quite a lot higher than it can be with a very asymmetric circuit. If someone works from home one day a week and has a videoconference or too, we still want that to work well, right? And perfect symmetry is not necessary. Would I notice the difference between 60/60 and 60/40 or even 60/20? Probably not really as long as both numbers are significantly more than the expected peak rate. But 24/1.5, a factor of 16, is a very different story. -w -- William Waites | School of Informatics http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From mark.tinka at seacom.mu Sat Feb 28 11:11:51 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 28 Feb 2015 13:11:51 +0200 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <524C482F-A4BD-40DC-B1DB-30CC1BB52ADC@delong.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F14AE2.9000006@seacom.mu> <16E90717-90BC-4794-9620-4C7FA6C7C479@delong.com> <54F14EDE.8010005@seacom.mu> <15477A98-E9AF-4AF9-AF27-6CFCD3A7F247@delong.com> <54F15EFA.6050003@seacom.mu> <54F188D3.5090205@seacom.mu> <524C482F-A4BD-40DC-B1DB-30CC1BB52ADC@delong.com> Message-ID: <54F1A277.7030007@seacom.mu> On 28/Feb/15 11:29, Owen DeLong wrote: > This is where I disagree with you. > > Look at it this way… I bet even you consume far more content than you produce. Everyone does. It is the nature of any one to many relationship. You are assuming that I am the one, personally, producing that content. In the future, if the uplink is large enough, it may be our devices doing the producing, and not the humans who own them. Is that feasible? Certainly. Is it happening now? Not nearly enough, even if the tech. is already there. Between humans and devices, there could be an equilibrium between production and consumption. It's hard to say. My point is, let's not use yesterday's assumptions for today's or tomorrow's movement. Almost everything else has moved on (or is moving on). But I won't labour the point so much. In my part of the world, we are deploying fibre into areas and customers that have been traditionally served by asymmetric bandwidth. So in a couple of months or years, I'll be able to tell you what effect that has had on eye-ball patterns. Nothing like experience... > > > If you have an example of any concept of an application where an end-user is likely to need the same amount of bandwidth upstream as they do downstream, I’m all ears. Your first example utterly failed. Do you have a better example to offer? That is your point of view, Owen. Which I respect. I don't expect that we'll agree on all things, or even anything :-). Rather than talk so much about it, I am going to do it and see what happens. That, for me, is my point. If others can join, that'll be great! > Even phones consume asymmetrically and almost entirely down-stream. I was speaking about the evolution of expected usage patterns of a traditionally voice and SMS mobile network, not the 2G/3G/4G data (a)symmetry. Oh well... > I’m all for bigger uplink pipes, but insisting on symmetry is absurd. I agree that one does not need symmetry at all times. But the potential to guarantee symmetry is good enough; or rather, the potential to limit degradation of symmetry in the upward direction is important, purely from a technology or hardware standpoint. That is why, in my trial, we are pushing Ethernet on Active-E, and not anything else. We are less likely to fail at the symmetry game if we pushed any other tech. It does not mean that 1:1 symmetry is absolutely necessary for sustained performance, it just means you remove that issue from the equation Day 1. > Not sure what you mean by “degraded in a way that would make you happy”. On GPON, 30Mbps up, 100Mbps down seems reasonable. But because the uplink on GPON is asymmetric, that 30Mbps uplink could quickly disappear as the network is subscribed. On Active-E, 100Mbps up, 100Mbps down seems reasonable. Degradation of the uplink is a lot less likely due to the tech. (ceteris paribus). So if uplink degradation on an Active-E network were to occur, that 100Mbps would degrade a lot better than the 30Mbps on a GPON would. That's what I mean. > > This makes no sense whatsoever. I'll leave you to work it out... Mark. From mfidelman at meetinghouse.net Sat Feb 28 12:02:57 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 28 Feb 2015 07:02:57 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F14868.7040903@mtcc.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <6C2AD229-D571-4220-8D7B-F2F8CC119185@consultant.com> <9578293AE169674F9A048B2BC9A081B4015725E400@MUNPRDMBXA1.medline.com> <54F14868.7040903@mtcc.com> Message-ID: <54F1AE71.5010503@meetinghouse.net> Michael Thomas wrote: > > On 02/27/2015 02:52 PM, Naslund, Steve wrote: >> What is that statement based on? I have not seen any outcry for more >> symmetric speeds. Asymmetry in our networks causes a lot of >> engineering issues and if it were up to the carriers, we would much >> rather have more symmetric traffic patterns because it would make >> life easier for us. Remember that most carrier backbones are built >> of symmetric circuits. It would be nice but the users generally >> download more than they upload. That is the fact. >> > > Average != Peak. > > Why is this so hard to understand? Marketing, and the stupidity of marketeers. Seriously. I spent a few years of my life, back in the 1980s, consulting to various DoD agencies - and I can't tell you how many times my role was to defend ethernet purchases (made by IT departments) against Telcos who were pitching ISDN at the General Officer level ("you don't need these new-fangled ethernets, an ISDN switch will handle all the data you need). I also got dragged into some discussions with, then, New England Telephones ISDN marketing folks. At one point, after lots of talk about how 64kbps was all you'd ever need for any reasonable data activity I made the observation that uploading a 1MB file, over their ISDN X.25 packet service would cost something like $100 in usage fees and take two minutes. Their response was "who'd ever need to upload a 1MB file?" I kid you not. Of course, I later found out that NET did have some folks who understood - it's just they were all working on selling their brand new Frame Relay service - still only 64kb, but at least the cost was a bit more reasonable, and the marketeers understood what they were selling, and to whom. Meanwhile, today, we still see commercials talking about how much faster one can download an entire HD movie over cable system's higher speed service. Not generally how people are using the net. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jgreco at ns.sol.net Sat Feb 28 14:05:30 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 28 Feb 2015 08:05:30 -0600 (CST) Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <15477A98-E9AF-4AF9-AF27-6CFCD3A7F247@delong.com> Message-ID: <201502281405.t1SE5Uix018306@aurora.sol.net> (replying to a few different points by different people): > In general, I find my 30M/7M is not too terribly painful most of the = > time. Do I wish I had more upstream? Yes, but not as much as I wish I = > had more downstream. I think an ideal minimum that would probably be = > comfortable most of the time today would be 100M/30M. But around here, the best you can get is 50M/5M (cable) or 12M/1M (VDSL). The 5M upstream on the cable is also a fairly recent improvement, it used to be 1M as well - and still is for most non-"super ultra mega premium" tiers, I believe. > And perfect symmetry is not necessary. Would I notice the difference > between 60/60 and 60/40 or even 60/20? Probably not really as long as > both numbers are significantly more than the expected peak rate. But > 24/1.5, a factor of 16, is a very different story. And both those variables are the problem. The current service offerings have been carefully designed to balance existing technology and observed actual usage characteristics, leaving essentially nothing for future technological evolution to grow into. The problem is that if you make service offerings "significantly more than the expected peak rate," then there is no longer incentive for customers to buy more than the most basic tier of service. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From nanog at ics-il.net Sat Feb 28 14:19:09 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 28 Feb 2015 08:19:09 -0600 (CST) Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: Message-ID: <680216.136.1425133127434.JavaMail.mhammett@ThunderFuck> WiFi also has 50% overhead, so cut all modulation rates in half. That 300 meg modulation under the best conditions only does 150 megabit aggregate. The problem with WiFi is that IEEE keeps rolling out larger and larger channels when they're not even usable due to interference. IEEE needs to implement AP syncing and *SMALLER* channels. let hte AP dynamically control the size of the channel as needed. Only have a 25 meg Internet service? Use a 5 MHz channel, not 160 MHz. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Philip Dorr" To: "Miles Fidelman" Cc: nanog at nanog.org Sent: Friday, February 27, 2015 11:15:17 PM Subject: Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] On Feb 27, 2015 6:48 PM, "Miles Fidelman" wrote: > > Jack Bates wrote: >> >> On 2/27/2015 2:47 PM, Miles Fidelman wrote: >>> >>> Folks, >>> >>> Let's not go overboard here. Can we remember that most corporate and campus (and, for that matter home) networks are symmetric, at least at the edges. Personally, I figure that by deploying PON, the major carriers were just asking for trouble down the line. It's not like carrier-grade gigE switches are that much more expensive than PON gear. >>> >> >> I'll disagree on the home part. I doubt that most homes are symmetric. > > > Just to be clear - I'm talking about the local switch/router sitting on a home network, not the connection to the outside world. Last time I looked, commodity gigE switches were symmetric - good for network attached storage, media servers, that sort of thing. (Come to think of it, though, I've never paid attention to whether the WiFi side is symmetric.) Commodity switches are symmetric for multiple reasons, but the biggest is probably because a server could be on any port and a client on any other port. WiFi has two separate data rate selections. The download could be at 300mbps and the upload only be at 1mbps. Or even the other way. WiFi is also half-duplex, so if the data rate is 300mbps, then the maximum you should expect is 150mbps. From johnl at iecc.com Sat Feb 28 14:34:12 2015 From: johnl at iecc.com (John R. Levine) Date: 28 Feb 2015 09:34:12 -0500 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F0E159.2000804@satchell.net> <20150227233223.18612.qmail@ary.lan> Message-ID: >> With the "legal content" rule, I expect some bottom feeding bulk >> mailers to sue claiming that their CAN SPAM compliant spam is legal, >> therefore the providers can't block it. > > How would this legal environment be any different than the pre-Verizon > network neutrality rules for network management of SPAM? Until yesterday, there were no network neutrality rules, not for spam or for anything else. R's, John From rsk at gsp.org Sat Feb 28 14:53:37 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 28 Feb 2015 09:53:37 -0500 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F0E159.2000804@satchell.net> <20150227233223.18612.qmail@ary.lan> Message-ID: <20150228145212.GA14800@gsp.org> On Sat, Feb 28, 2015 at 02:48:07PM +0900, Collin Anderson wrote: > How would this legal environment be any different than the pre-Verizon > network neutrality rules for network management of SPAM? SPAM, being a product of the Hormel Corporation, is not a concern in this context. Spam, the slang term for unsolicited bulk email (UBE), is a form of denial-of-service attack and may/should be treated in the same way as other DoS attacks. ---rsk From james.cutler at consultant.com Sat Feb 28 15:04:56 2015 From: james.cutler at consultant.com (James R Cutler) Date: Sat, 28 Feb 2015 10:04:56 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <680216.136.1425133127434.JavaMail.mhammett@ThunderFuck> References: <680216.136.1425133127434.JavaMail.mhammett@ThunderFuck> Message-ID: <5665F1C8-A090-4503-BFA8-CF8174768B58@consultant.com> On Feb 28, 2015, at 9:19 AM, Mike Hammett wrote: > > Only have a 25 meg Internet service? Use a 5 MHz channel, not 160 MHz. So, if I use wireless to my, for example, Apple TV, I should limit the rate between my file server Mac and the Apple TV based on my Internet connection speed? I’m not certain that is reasonable. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 234 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sclark at netwolves.com Sat Feb 28 15:46:03 2015 From: sclark at netwolves.com (Steve Clark) Date: Sat, 28 Feb 2015 10:46:03 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F1E2BB.7000400@netwolves.com> <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> Message-ID: 1425138364993-030-00114996.sclark.netwolves.com@sclark66.netwolves.com On 02/27/2015 04:11 PM, Scott Helms wrote: > Daniel, > > > "50MB/s might be tough to fill, but even at home I can get good use out of > the odd 25MB/s upstream burst for a few minutes." > > Which would you choose, 50/50 or 75/25? My point is not that upstream > speed isn't valuable, but merely that demand for it isn't symmetrical and > unless the market changes won't be in the near term. Downstream demand is > growing, in most markets I can see, much faster than upstream demand. Scott, Who can foresee what APPs might come about if uplinks speeds weren't so low. I liken it to whoever said no one will ever need more than 640KB of memory. Regards, Steve > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From nanog at ics-il.net Sat Feb 28 15:57:55 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 28 Feb 2015 09:57:55 -0600 (CST) Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <5665F1C8-A090-4503-BFA8-CF8174768B58@consultant.com> Message-ID: <9934552.473.1425139050703.JavaMail.mhammett@ThunderFuck> Over 95% of the people don't do anything of the sort (probably much closer to 100 than 95). The most common usage is tablets and phones going to Facebook, YouTube and Netflix. Regular consumers couldn't care less about anything else. If you think otherwise, you've (perhaps thankfully) spent too long away from your standard consumer). ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "James R Cutler" To: "Mike Hammett" Cc: "NANOG" Sent: Saturday, February 28, 2015 9:04:56 AM Subject: Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] On Feb 28, 2015, at 9:19 AM, Mike Hammett < nanog at ics-il.net > wrote: Only have a 25 meg Internet service? Use a 5 MHz channel, not 160 MHz. So, if I use wireless to my, for example, Apple TV, I should limit the rate between my file server Mac and the Apple TV based on my Internet connection speed? I’m not certain that is reasonable. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu From list at satchell.net Sat Feb 28 16:12:50 2015 From: list at satchell.net (Stephen Satchell) Date: Sat, 28 Feb 2015 08:12:50 -0800 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <9934552.473.1425139050703.JavaMail.mhammett@ThunderFuck> References: <9934552.473.1425139050703.JavaMail.mhammett@ThunderFuck> Message-ID: <54F1E902.3080205@satchell.net> On 02/28/2015 07:57 AM, Mike Hammett wrote: > Over 95% of the people don't do anything of the sort (probably much > closer to 100 than 95). The most common usage is tablets and phones > going to Facebook, YouTube and Netflix. Regular consumers couldn't > care less about anything else. If you think otherwise, you've > (perhaps thankfully) spent too long away from your standard > consumer). Don't forget that Skype is becoming popular -- it's even on mainstream TV, think _Big Bang Theory_. Another class you are forgetting is telecommuters, who use VPNs to connect to their main office from home (or hotel/motel rooms). * Internet Messaging * Tele-meeting (GoToMeeting, CUSeeMe, Skype conference calls) * Web-based activites (data lookup, forms) * Bulk data transfer, both upload and download, via VPN Then there are the on-line gamers. The size of that community is suggested by the uproar that has occurred when Lizard Squid overloaded the various gaming networks. The usage patterns continue to change. Remember that NetFlix streaming is, in Internet years, still relatively new. YouTube introduced its own distortions into network usage that ISPs still battle. I will grant you that, today, traffic is still asymmetric. The ratio of downstream/upstream is changing, as well as the total amount of traffic. Who knows what tomorrow will bring? Developers are not sitting on their tails... From nanog at ics-il.net Sat Feb 28 16:20:20 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 28 Feb 2015 10:20:20 -0600 (CST) Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F1E902.3080205@satchell.net> Message-ID: <9053238.568.1425140397641.JavaMail.mhammett@ThunderFuck> I use Skype regularly. It doesn't require 10 megabits. No, I didn't forget about them. There's simply not that many of them. No game requires significant amounts of upload. I forgot nothing and none of what you presented changes my statement in any material manner. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Stephen Satchell" To: nanog at nanog.org Sent: Saturday, February 28, 2015 10:12:50 AM Subject: Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] On 02/28/2015 07:57 AM, Mike Hammett wrote: > Over 95% of the people don't do anything of the sort (probably much > closer to 100 than 95). The most common usage is tablets and phones > going to Facebook, YouTube and Netflix. Regular consumers couldn't > care less about anything else. If you think otherwise, you've > (perhaps thankfully) spent too long away from your standard > consumer). Don't forget that Skype is becoming popular -- it's even on mainstream TV, think _Big Bang Theory_. Another class you are forgetting is telecommuters, who use VPNs to connect to their main office from home (or hotel/motel rooms). * Internet Messaging * Tele-meeting (GoToMeeting, CUSeeMe, Skype conference calls) * Web-based activites (data lookup, forms) * Bulk data transfer, both upload and download, via VPN Then there are the on-line gamers. The size of that community is suggested by the uproar that has occurred when Lizard Squid overloaded the various gaming networks. The usage patterns continue to change. Remember that NetFlix streaming is, in Internet years, still relatively new. YouTube introduced its own distortions into network usage that ISPs still battle. I will grant you that, today, traffic is still asymmetric. The ratio of downstream/upstream is changing, as well as the total amount of traffic. Who knows what tomorrow will bring? Developers are not sitting on their tails... From khelms at zcorum.com Sat Feb 28 16:28:43 2015 From: khelms at zcorum.com (Scott Helms) Date: Sat, 28 Feb 2015 11:28:43 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54f1e2bd.4b6e2a0a.7413.ffffcae4SMTPIN_ADDED_BROKEN@mx.google.com> References: <54F1E2BB.7000400@netwolves.com> <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <54f1e2bd.4b6e2a0a.7413.ffffcae4SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: Steve, My point is that for lots and lots of people their uplink is not "so low". Even when I look at users with 25/25 and 50/50, many of the have been at those rates for >3 years we don't see changes in traffic patterns nor satisfaction as compared to users at similar download rates but lower uplink rates as long as we don't go below ~5 mbps on the uplink. On Feb 28, 2015 10:46 AM, "Steve Clark" wrote: > On 02/27/2015 04:11 PM, Scott Helms wrote: > > Daniel, > > > "50MB/s might be tough to fill, but even at home I can get good use out of > the odd 25MB/s upstream burst for a few minutes." > > Which would you choose, 50/50 or 75/25? My point is not that upstream > speed isn't valuable, but merely that demand for it isn't symmetrical and > unless the market changes won't be in the near term. Downstream demand is > growing, in most markets I can see, much faster than upstream demand. > > Scott, > > Who can foresee what APPs might come about if uplinks speeds weren't so > low. I liken it to > whoever said no one will ever need more than 640KB of memory. > > Regards, > Steve > > > > Scott Helms > Vice President of Technology > ZCorum(678) 507-5000 > --------------------------------http://twitter.com/kscotthelms > -------------------------------- > > > > > -- > Stephen Clark > *NetWolves Managed Services, LLC.* > Director of Technology > Phone: 813-579-3200 > Fax: 813-882-0209 > Email: steve.clark at netwolves.com > http://www.netwolves.com > From mike at mtcc.com Sat Feb 28 16:53:35 2015 From: mike at mtcc.com (Michael Thomas) Date: Sat, 28 Feb 2015 08:53:35 -0800 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <9053238.568.1425140397641.JavaMail.mhammett@ThunderFuck> References: <9053238.568.1425140397641.JavaMail.mhammett@ThunderFuck> Message-ID: <54F1F28F.4080909@mtcc.com> On 02/28/2015 08:20 AM, Mike Hammett wrote: > I use Skype regularly. It doesn't require 10 megabits. > > No, I didn't forget about them. There's simply not that many of them. > > No game requires significant amounts of upload. > > I forgot nothing and none of what you presented changes my statement in any material manner. > 20 years ago, your standard consumer didn't use the internet either so there definitely no business case for anything other than POTS. Mike From nanog at ics-il.net Sat Feb 28 16:54:20 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 28 Feb 2015 10:54:20 -0600 (CST) Subject: utility capacity, was Verizon Policy Statement on Net Neutrality In-Reply-To: <2BCAFB3C-AA72-4573-A65C-F2DD626E5D23@beckman.org> Message-ID: <9251070.804.1425142434875.JavaMail.mhammett@ThunderFuck> Selling 1 gig symmetric service to more than one person on GPON is definitely oversubscription. I'm completely fine with it, but the fiber\Google zealots think nothing could ever go wrong and they have the world by the [NSFW]. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mel Beckman" To: "John Levine" Cc: nanog at nanog.org Sent: Friday, February 27, 2015 5:44:02 PM Subject: Re: utility capacity, was Verizon Policy Statement on Net Neutrality John, That's an excellent point. Consider Google fiber, for example. And customer could theoretically demand a gigabit of traffic. Even Google admits that this doesn't scale and that they are highly oversubscribed. -mel beckman On Feb 27, 2015, at 3:05 PM, "John Levine" wrote: >> Water, gas, and to a great extent electrical systems do not work on >> oversubscription, ie their aggregate capacity meets or exceeds the needs of >> all their customers peak potential demand, at least from "normal" demand >> standpoint. > > Hi, former municipal water and sewer commissioner here. We size the > system to meet likely demand, but not peak demand. If it's a hot dry > summer and everyone wants to water their lawn, or there's a big fire > that's drawing a lot of water from hydrants, we can have capacity > problems. We deal with it by interrupting service to a few large > customers, a car wash and a golf course. > > But it's not really comparable to broadband service, because on the > Internet, nearly every consumer end user device could easily saturate > the entire network if it wanted to. It's like every house having a > 100,000 gallon toilet. Better hope you don't have a lot of people > flushing at once. > > R's, > John From jbates at paradoxnetworks.net Sat Feb 28 16:54:38 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Sat, 28 Feb 2015 10:54:38 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F1E2BB.7000400@netwolves.com> <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <54f1e2bd.4b6e2a0a.7413.ffffcae4SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <54F1F2CE.2000909@paradoxnetworks.net> On 2/28/2015 10:28 AM, Scott Helms wrote: > Steve, > > My point is that for lots and lots of people their uplink is not "so low". > Even when I look at users with 25/25 and 50/50, many of the have been at > those rates for >3 years we don't see changes in traffic patterns nor > satisfaction as compared to users at similar download rates but lower > uplink rates as long as we don't go below ~5 mbps on the uplink. > On Feb 28, 2015 10:46 AM, "Steve Clark" wrote: > > Of course you don't, and as long as we don't work towards fixing the problem, you will continue to see this. It's limitation of the masses. Developers generally base things on what the most number of users/customers can support. Consider the gaming industry. There are a LOT of PC games that now get substandard resolution textures because the textures were developed with a console in mind and they didn't want to spend extra having a PC specialized texture pack (for those few who have good graphics cards). There are more PC games for Windows than other operating systems. We are now starting to see better support for OSX and Linux; though it's still rather low. Consider skype group video calls. The download requirements change but the upload does not. This leads me to believe they are using an intermediate server. That is VERY un-skype-like in my opinion, but then they have to deal with what will work for a majority of the people. If a majority of the people had 50meg/50meg, skype development would probably support p2p for group video with HD support. In fact, it could be more versatile as each connection could negotiate what it feels is appropriate based on the limits of the sender and the recipient. This would be a good example of symmetric usage. However, with the masses still at 5meg or lower on upload, it would be silly to bother with. Just throw it to a rebroadcasting server and use the bandwidth there. It's not just about what's available, though. it's also about the users themselves. Usage of the average 80 year old is different than the average 40 year old. The current teenager definitely has different usage. In many ways, the bandwidth problem isn't much different than the NAT problems. Running servers and using bandwidth to compensate for edge network weaknesses is not ideal. When a majority do not suffer the problem, those who are in the minority will be told to complain to their ISP or "unsupported". Jack From nanog at ics-il.net Sat Feb 28 16:59:25 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 28 Feb 2015 10:59:25 -0600 (CST) Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F1F28F.4080909@mtcc.com> Message-ID: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> 20 years ago was into AOL's prime, so yes they did. Great, let's re-evaluate the system when demand necessitates it. For many systems, it's literally as simple as changing how many channels are allocated to what directions. By that logic, we would have been running 486s with 32 gigs of RAM because some people today use that much. *shakes head* Obviously the majority of the dissent here works with OPM. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Michael Thomas" To: nanog at nanog.org Sent: Saturday, February 28, 2015 10:53:35 AM Subject: Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] On 02/28/2015 08:20 AM, Mike Hammett wrote: > I use Skype regularly. It doesn't require 10 megabits. > > No, I didn't forget about them. There's simply not that many of them. > > No game requires significant amounts of upload. > > I forgot nothing and none of what you presented changes my statement in any material manner. > 20 years ago, your standard consumer didn't use the internet either so there definitely no business case for anything other than POTS. Mike From lowen at pari.edu Sat Feb 28 17:06:01 2015 From: lowen at pari.edu (Lamar Owen) Date: Sat, 28 Feb 2015 12:06:01 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: Message-ID: <54F1F579.6040207@pari.edu> On 02/27/2015 02:14 PM, Jim Richardson wrote: > From 47CFR§8.5b > (b) A person engaged in the provision of mobile broadband Internet > access service, insofar as such person is so engaged, shall not block > consumers from accessing lawful Web sites, subject to reasonable > network management; nor shall such person block applications that > compete with the provider's voice or video telephony services, subject > to reasonable network management. > > What's a "lawful" web site? That would likely be determined on a case-by-case basis during Commission review of a complaint, I would imagine, with each FCC document related to each case becoming part of the collection of precedent (whether said document is a NAL, NOV, or R&O would be somewhat immaterial). The obvious answer is 'a website that has no illegal content' but once something is brought to a hearing, what is 'obvious' doesn't really matter. If you want to read about the types of rationale that can be used to determine terms like 'lawful' in this context, search through Enforcement Bureau actions relating to 47CFR§73.3999 "Enforcement of 18 U.S.C. 1464 (restrictions on the transmission of obscene and indecent material)." For more technical considerations, you might find the collection of precedent on what satisfies 47CFR§73.1300, 1350, and 1400 to be more interesting reading, if you're into this sort of arcana. From mike at mtcc.com Sat Feb 28 17:23:06 2015 From: mike at mtcc.com (Michael Thomas) Date: Sat, 28 Feb 2015 09:23:06 -0800 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> Message-ID: <54F1F97A.2030000@mtcc.com> On 02/28/2015 08:59 AM, Mike Hammett wrote: > 20 years ago was into AOL's prime, so yes they did. > > Great, let's re-evaluate the system when demand necessitates it. For many systems, it's literally as simple as changing how many channels are allocated to what directions. > > By that logic, we would have been running 486s with 32 gigs of RAM because some people today use that much. *shakes head* Obviously the majority of the dissent here works with OPM. > > The point is that the incumbents (= telephants) at the time looked at even the minuscule AOL user base with disdain saying that their market share was irrelevant. Even into the early 2000's these same guys thought that voice was the only thing that really mattered because the new fangled internet users were outliers from their pots bread and butter. We now know those outliers were important. Being dismissive of them is dangerous. I think at this point, it's really not too much to ask for PHY's that can deliver decent upstream rates on demand to deal with the bursty nature of upstream traffic from eyeball networks. Nor is it too much to ask for l2/l3 shaping to deal with the internet equivalent of a synchronized toilet flush. From the consumer standpoint, I *really* don't think it's too much to ask that when I have the occasional 10 gig image to upload that it takes me << than a full day. This has nothing really to do with symmetry, per se. It's the need to adapt to what the traffic is *actually* doing at peak times, regardless of the average up/down byte count. Mike From lowen at pari.edu Sat Feb 28 17:24:23 2015 From: lowen at pari.edu (Lamar Owen) Date: Sat, 28 Feb 2015 12:24:23 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0E669.50007@satchell.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> Message-ID: <54F1F9C7.30307@pari.edu> On 02/27/2015 04:49 PM, Stephen Satchell wrote: > So did I. Also, do you recall that the FCC changed the definition of > "broadband" to require 25 Mbps downstream? Does this mean that all > these rules on "broadband" don't apply to people providing Internet > access service on classic ADSL? The FCC regulations do not have to use consistent definitions (and many times definitions are not consistent!); the local-to-the-section definition usually (but not always; it's always up for interpretation at hearing time!) trumps any other. The local definitions for the context of 47CFR§8 are found in §8.11, and do not mention required bandwidth. It seems to include any 'eyeball' network, regardless of bandwidth. The definition in 47CFR§8.11(a) is classic FCC wordsmithing. Think of 'scope of definition' as being similar to 'longest prefix matching' in routing, and it will be clear what is going on here. Hint: a particular section of the Rules can hijack a term out from under the general definitions, much like prefixes can be hijacked out from under their containing prefix. The difference is that in the Rules, a particular paragraph or subparagraph can hijack a term and say 'for the purposes of this paragraph, term 'A' means the opposite of what it means everywhere else' and that definition in that scope will stand the test of hearing. From lowen at pari.edu Sat Feb 28 17:32:33 2015 From: lowen at pari.edu (Lamar Owen) Date: Sat, 28 Feb 2015 12:32:33 -0500 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: <20150228145212.GA14800@gsp.org> References: <54F0E159.2000804@satchell.net> Message-ID: <54F1FBB1.2000200@pari.edu> On 02/28/2015 09:53 AM, Rich Kulawiec wrote: > ...Spam, the slang term for unsolicited bulk email (UBE), is a form of > denial-of-service attack and may/should be treated in the same way as > other DoS attacks. ---rsk 47CFR§8.11(d) Reasonable network management. A network management practice is reasonable if it is appropriate and tailored to achieving a legitimate network management purpose, taking into account the particular network architecture and technology of the broadband Internet access service. Classic FCC wordsmithing, and seems to cover the DoS case nicely when you look through the rest of §8 for instances of the term 'reasonable network management.' Yes, it is amorphous, ambiguous, and all those things regulations usually are. (Like being up for interpretation.) It remains to be seen whether §8 will survive appeal. From owen at delong.com Sat Feb 28 17:51:29 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 28 Feb 2015 09:51:29 -0800 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <9934552.473.1425139050703.JavaMail.mhammett@ThunderFuck> References: <9934552.473.1425139050703.JavaMail.mhammett@ThunderFuck> Message-ID: Mike, I call bullshit here. The sales of Apple TV, Google Chromecast, Amazon’s streaming stick, TiVO Stream, and other set-top boxes that stream room to room are just too high to believe that people are not using these devices to move A/V information within the home. Add to that the number of people who use tablet/cellular capabilities like AirPlay to stream content from their phone/tablet to their A/V systems and I think you’re well beyond 5% of the market and growing. Owen > On Feb 28, 2015, at 07:57 , Mike Hammett wrote: > > Over 95% of the people don't do anything of the sort (probably much closer to 100 than 95). The most common usage is tablets and phones going to Facebook, YouTube and Netflix. Regular consumers couldn't care less about anything else. If you think otherwise, you've (perhaps thankfully) spent too long away from your standard consumer). > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "James R Cutler" > To: "Mike Hammett" > Cc: "NANOG" > Sent: Saturday, February 28, 2015 9:04:56 AM > Subject: Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] > > On Feb 28, 2015, at 9:19 AM, Mike Hammett < nanog at ics-il.net > wrote: > > > > > > Only have a 25 meg Internet service? Use a 5 MHz channel, not 160 MHz. > > > > > So, if I use wireless to my, for example, Apple TV, I should limit the rate between my file server Mac and the Apple TV based on my Internet connection speed? > > > I’m not certain that is reasonable. > > > > > > > > James R. Cutler > James.cutler at consultant.com > PGP keys at http://pgp.mit.edu > > From nanog at ics-il.net Sat Feb 28 18:04:27 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 28 Feb 2015 12:04:27 -0600 (CST) Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: Message-ID: <17583756.1201.1425146641932.JavaMail.mhammett@ThunderFuck> You can call it, but the line has been disconnected. I know tons of people with those devices. What do they do with them? Netflix, Amazon, Youtube, etc. Less than 10% of even techies I know have in-home media... and they've already run copper or fiber everywhere anyway. In-home media is likely shrinking due to the market making it so convenient to do it online vs. having to rip or Torrent everything you could possibly ever want, store it and manage the interface to get it. Look at percentage of traffic that was Torrent 10 years ago and percentage of traffic today that is NetFlix. Do people do it? Yes. Do new people do it every day? Yes. Do normal people do it? No. Is it growing? No. Is it a large percentage of people? No. Even if it were a ton of people, would it be some flagrant violation of what I proposed? In no way whatsoever. I referred to dynamic channel sizes. 5, 10, 20, 30, 40 MHz would be more than sufficient. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Owen DeLong" To: "Mike Hammett" Cc: "NANOG" Sent: Saturday, February 28, 2015 11:51:29 AM Subject: Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] Mike, I call bullshit here. The sales of Apple TV, Google Chromecast, Amazon’s streaming stick, TiVO Stream, and other set-top boxes that stream room to room are just too high to believe that people are not using these devices to move A/V information within the home. Add to that the number of people who use tablet/cellular capabilities like AirPlay to stream content from their phone/tablet to their A/V systems and I think you’re well beyond 5% of the market and growing. Owen > On Feb 28, 2015, at 07:57 , Mike Hammett wrote: > > Over 95% of the people don't do anything of the sort (probably much closer to 100 than 95). The most common usage is tablets and phones going to Facebook, YouTube and Netflix. Regular consumers couldn't care less about anything else. If you think otherwise, you've (perhaps thankfully) spent too long away from your standard consumer). > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "James R Cutler" > To: "Mike Hammett" > Cc: "NANOG" > Sent: Saturday, February 28, 2015 9:04:56 AM > Subject: Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] > > On Feb 28, 2015, at 9:19 AM, Mike Hammett < nanog at ics-il.net > wrote: > > > > > > Only have a 25 meg Internet service? Use a 5 MHz channel, not 160 MHz. > > > > > So, if I use wireless to my, for example, Apple TV, I should limit the rate between my file server Mac and the Apple TV based on my Internet connection speed? > > > I’m not certain that is reasonable. > > > > > > > > James R. Cutler > James.cutler at consultant.com > PGP keys at http://pgp.mit.edu > > From lowen at pari.edu Sat Feb 28 18:06:43 2015 From: lowen at pari.edu (Lamar Owen) Date: Sat, 28 Feb 2015 13:06:43 -0500 Subject: One FCC neutrality elephant: disabilities compliance In-Reply-To: <2D167235-5C33-4CD9-B3B8-BC33E06AA0DA@beckman.org> References: Message-ID: <54F203B3.2090606@pari.edu> On 02/27/2015 03:12 PM, Mel Beckman wrote: > Two pages? Read the news, man. I'd rather read the actual regulations, from the source, in 47CFR§8. They're public. The enforcement won't come from what the news said. > You say you haven't read the actual R&O. Nobody in the public sector, > or even in Congress AFAIK, has read it. The Order's 300-plus pages > were never publicly released or openly debated.This is another "you > must pass it to see what's in it" debacle, without the luxury of > having any semblance of democratic process or transparency. The R&O is not limited to just the text of the actual regulations. The R&O will include the discussion and the rationale behind the adopted rules, along with quotes from those who commented on the action, and further language, including the derivation of the regulatory authority. The actual regulation, much shorter than the R&O, is already public, in 47CFR§8. The R&O is the 'what' plus the 'why,' 'how,' and 'when' whereas the new section in 47CFR is just the 'what.' It takes a lot more time to get the 'why,' 'how,' and 'when' into shape for publication than it does to get the 'what' into shape for publication. The enforcement will come from the 'what.' This is standard, normal, FCC procedure. The NPRM was 99 pages, plus, with proposed rules of two pages. The R&O is reported as being 300 pages perhaps, with actual adopted rules of about 8 pages (depending upon the font used; I took the eCFR version of 47CFR§8 and printed it to PDF, and that PDF ran 8 pages). This is not unusual, and is something I've seen many times. The process is quite transparent, just with greater latency than many people like, and you do need to know where to look, although the FCC has made it a lot easier to find stuff than it was a few years back. The statement from the FCC spokesperson doesn't quote a length; we'll see how long it will be. I personally look forward to reading it; FCC R&O's tend to be better reading than the resulting sections in 47CFR, but when the EB knocks on your door they're going to hold you to 47CFR, not the establishing R&O. This is a lot better than the days where you had to subscribe to a service, like Pike and Fischer's, to get even the Daily Digest, much less up to the day copies of the CFR, like we now can have. The latency for Commission actions is typically on the order of months; the NPRM's date is May 15, 2014. You can see more into this by looking at the docket's page at http://apps.fcc.gov/ecfs/proceeding/view?name=14-28 . There were over 2 million filings in this docket, with almost 7,000 in the last 30 days alone. I would imagine the first place to have the actual R&O text will be the docket's page linked above; you can even follow it with its RSS feed and get it as soon as its released. From james.cutler at consultant.com Sat Feb 28 18:14:12 2015 From: james.cutler at consultant.com (James R Cutler) Date: Sat, 28 Feb 2015 13:14:12 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <17583756.1201.1425146641932.JavaMail.mhammett@ThunderFuck> References: <17583756.1201.1425146641932.JavaMail.mhammett@ThunderFuck> Message-ID: <2A7D0994-CBB8-4EDF-9D61-65DEE1B5A71E@consultant.com> Mike, I’m probably happy that I am not normal, as are my clients not normal. Why are you descending to ad hominem rather than facts? James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu > On Feb 28, 2015, at 1:04 PM, Mike Hammett wrote: > > Do normal people do it? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 234 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lowen at pari.edu Sat Feb 28 18:48:12 2015 From: lowen at pari.edu (Lamar Owen) Date: Sat, 28 Feb 2015 13:48:12 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0CC4E.101@invaluement.com> References: Message-ID: <54F20D6C.9020809@pari.edu> On 02/27/2015 02:58 PM, Rob McEwen wrote: > On 2/27/2015 1:28 PM, Lamar Owen wrote: >> You really should read 47CFR§8. It won't take you more than an hour >> or so, as it's only about 8 pages. > > The bigger picture is (a) HOW they got this authority--self-defining > it in, and (b) the potential abuse and 4th amendment violations, not > just today's "foot in the door" details! How they got the authority is through the Communications Act of 1934, as passed and amended by our elected representatives in Congress, with the approval of our elected President. The largest amendments are from 1996, as I recall. The specific citations are 47 U.S.C. secs. 151, 152, 153, 154, 201, 218, 230, 251, 254, 256, 257, 301, 303, 304, 307, 309, 316, 332, 403, 503, 522, 536, 548, and 1302 (that list is from the Authority section of §8 itself, and will be elaborated upon in the R&O, likely with multiple paragraphs explaining why each of those enumerated sections of 47 USC apply here. Commission R&O's will typically spend a bit of time on the history of each relevant section, and it wouldn't surprise me in the least to see the Telecom Act of 1996 quoted there.). It will be interesting to see how the judiciary responds, or how Congress responds, for that matter, as Congress could always amend the Communications Act of 1934 again (subject to Executive approval, of course). In any case, the Report and Order will give us a lot more information on why the regulations read the way they do, and on how this authority is said to derive from the portions of the USC as passed by Congress (and signed by the President). And at that point things could get really interesting. Our govermental system of checks and balances at work. > In the same way, I don't like the BASIS for this authority... and what > it potentially means in the long term... besides what they state that > they intend to do with this new authority they've appointed themselves > in the short term. > Had some people not apparently taken advantage of the situation as it existed before the proceeding in docket 14-28, it's likely no regulatory actions would have been initiated. I'm not cheerleading by any means; I would much prefer less regulation than more in almost every situation; but the simple fact is that people do tend to abuse the lack of regulations long enough for regulatory agencies to take notice, and then everyone loses when regulations come. As an extreme example of how onerous regulations could be, if the Commission were to decide to decree that all ISP's have to use ATM cells instead of variable length IP packets on the last mile, they actually do have the regulatory authority to set that standard (they did exactly this for AM Stereo in the 80's, for IBOC HD Radio, and then the ATSC DTV standard (it was even an unfunded mandate in that case), not to mention the standards set in §68 for equipment connected to the public switched telephone network, etc). The FCC even auctioned off spectrum already in use by §15 wireless microphones and amended §15 making those wireless mics (in the 700MHz range) illegal to use, even though many are still out there. So it could be very much worse; this new section is one of the shortest sections of 47CFR I've ever read. Much, much, simpler and shorter than my bread and butter in 47CFR§§11, 73, and 101. Reading the R&O once it is released will be very interesting, at least in my opinion, since we'll get a glimpse into the rationale and the thought processes that went into each paragraph and subparagraph of this new section in 47CFR. I'm most interested in the rationale behind the pleading requirements, like requiring complainants to serve the complaint by hand delivery on the named defendant, requiring the complainant to serve two copies on the Market Disputes Resolution Division of the EB, etc. This seems to be a pretty high bar to filing a complaint; it's not like you can just fill out a form on the FCC website to report your ISP for violating 47CFR§8. Heh, part of the rationale might be the fact that they got over 2 million filings on this docket...... From mfidelman at meetinghouse.net Sat Feb 28 18:56:14 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 28 Feb 2015 13:56:14 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <9934552.473.1425139050703.JavaMail.mhammett@ThunderFuck> References: <9934552.473.1425139050703.JavaMail.mhammett@ThunderFuck> Message-ID: <54F20F4E.80804@meetinghouse.net> I think you underestimate how many broadband customers are folks who take work home from the office, or school). Heck, an awful lot of high school assignments involve writing papers and presentations jointly with other kids, and these days word documents and multi-media PPT presentations can get awfully large. Mike Hammett wrote: > Over 95% of the people don't do anything of the sort (probably much closer to 100 than 95). The most common usage is tablets and phones going to Facebook, YouTube and Netflix. Regular consumers couldn't care less about anything else. If you think otherwise, you've (perhaps thankfully) spent too long away from your standard consumer). > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > ----- Original Message ----- > > From: "James R Cutler" > To: "Mike Hammett" > Cc: "NANOG" > Sent: Saturday, February 28, 2015 9:04:56 AM > Subject: Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] > > On Feb 28, 2015, at 9:19 AM, Mike Hammett < nanog at ics-il.net > wrote: > > > > > > Only have a 25 meg Internet service? Use a 5 MHz channel, not 160 MHz. > > > > > So, if I use wireless to my, for example, Apple TV, I should limit the rate between my file server Mac and the Apple TV based on my Internet connection speed? > > > I’m not certain that is reasonable. > > > > > > > > James R. Cutler > James.cutler at consultant.com > PGP keys at http://pgp.mit.edu > > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman at meetinghouse.net Sat Feb 28 18:59:37 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 28 Feb 2015 13:59:37 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F1F97A.2030000@mtcc.com> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> Message-ID: <54F21019.8070700@meetinghouse.net> Michael Thomas wrote: > > On 02/28/2015 08:59 AM, Mike Hammett wrote: >> 20 years ago was into AOL's prime, so yes they did. >> >> Great, let's re-evaluate the system when demand necessitates it. For >> many systems, it's literally as simple as changing how many channels >> are allocated to what directions. >> >> By that logic, we would have been running 486s with 32 gigs of RAM >> because some people today use that much. *shakes head* Obviously the >> majority of the dissent here works with OPM. >> >> > > The point is that the incumbents (= telephants) at the time looked at > even the > minuscule AOL user base with disdain saying that their market share > was irrelevant. > Even into the early 2000's these same guys thought that voice was the > only thing > that really mattered because the new fangled internet users were > outliers from their > pots bread and butter. We now know those outliers were important. > Being dismissive > of them is dangerous. > Actually, I think the incumbents do get it, at this point - at least Verizon does. FIOS is a pretty nice offering, and they offer some pretty high speeds, both up and down. It's just that they've stopped their buildout with the large markets; but they've been a power behind the state level anti-municipal broadband laws. Kind of annoying that, in areas where they have no intention of building out, they want to stand in the way of folks who want to do it themselves. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman at meetinghouse.net Sat Feb 28 19:05:47 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 28 Feb 2015 14:05:47 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F1F2CE.2000909@paradoxnetworks.net> References: <54F1E2BB.7000400@netwolves.com> <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <54f1e2bd.4b6e2a0a.7413.ffffcae4SMTPIN_ADDED_BROKEN@mx.google.com> <54F1F2CE.2000909@paradoxnetworks.net> Message-ID: <54F2118B.5010801@meetinghouse.net> Jack Bates wrote: > On 2/28/2015 10:28 AM, Scott Helms wrote: >> Steve, >> >> My point is that for lots and lots of people their uplink is not "so >> low". >> Even when I look at users with 25/25 and 50/50, many of the have been at >> those rates for >3 years we don't see changes in traffic patterns nor >> satisfaction as compared to users at similar download rates but lower >> uplink rates as long as we don't go below ~5 mbps on the uplink. >> On Feb 28, 2015 10:46 AM, "Steve Clark" wrote: >> >> > > It's not just about what's available, though. it's also about the > users themselves. Usage of the average 80 year old is different than > the average 40 year old. The current teenager definitely has different > usage. That's a good point. (IMHO) email became a big market driver when students started graduating college and lost their email access. Today, students go to college, experience dorm rooms with gigE jacks in their dorm rooms connected back to high speed backbone nets. And they've been doing that for a decade. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nanog at ics-il.net Sat Feb 28 19:17:35 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 28 Feb 2015 13:17:35 -0600 (CST) Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <2A7D0994-CBB8-4EDF-9D61-65DEE1B5A71E@consultant.com> Message-ID: <13067329.29.1425151031749.JavaMail.mhammett@ThunderFuck> I also am happy that I am not normal, but that doesn't change what the general population does. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "James R Cutler" To: "Mike Hammett" Cc: "NANOG" Sent: Saturday, February 28, 2015 12:14:12 PM Subject: Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] Mike, I’m probably happy that I am not normal, as are my clients not normal. Why are you descending to ad hominem rather than facts? James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu On Feb 28, 2015, at 1:04 PM, Mike Hammett < nanog at ics-il.net > wrote: Do normal people do it? From nanog at ics-il.net Sat Feb 28 19:19:16 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 28 Feb 2015 13:19:16 -0600 (CST) Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F21019.8070700@meetinghouse.net> Message-ID: <30917540.32.1425151129830.JavaMail.mhammett@ThunderFuck> The folks that do want to do it themselves... are. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Miles Fidelman" To: nanog at nanog.org Sent: Saturday, February 28, 2015 12:59:37 PM Subject: Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] Michael Thomas wrote: > > On 02/28/2015 08:59 AM, Mike Hammett wrote: >> 20 years ago was into AOL's prime, so yes they did. >> >> Great, let's re-evaluate the system when demand necessitates it. For >> many systems, it's literally as simple as changing how many channels >> are allocated to what directions. >> >> By that logic, we would have been running 486s with 32 gigs of RAM >> because some people today use that much. *shakes head* Obviously the >> majority of the dissent here works with OPM. >> >> > > The point is that the incumbents (= telephants) at the time looked at > even the > minuscule AOL user base with disdain saying that their market share > was irrelevant. > Even into the early 2000's these same guys thought that voice was the > only thing > that really mattered because the new fangled internet users were > outliers from their > pots bread and butter. We now know those outliers were important. > Being dismissive > of them is dangerous. > Actually, I think the incumbents do get it, at this point - at least Verizon does. FIOS is a pretty nice offering, and they offer some pretty high speeds, both up and down. It's just that they've stopped their buildout with the large markets; but they've been a power behind the state level anti-municipal broadband laws. Kind of annoying that, in areas where they have no intention of building out, they want to stand in the way of folks who want to do it themselves. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From rob at invaluement.com Sat Feb 28 19:29:57 2015 From: rob at invaluement.com (Rob McEwen) Date: Sat, 28 Feb 2015 14:29:57 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F20D6C.9020809@pari.edu> References: <54F20D6C.9020809@pari.edu> Message-ID: <54F21735.9070608@invaluement.com> On 2/28/2015 1:48 PM, Lamar Owen wrote: >> The bigger picture is (a) HOW they got this authority--self-defining >> it in, and (b) the potential abuse and 4th amendment violations, not >> just today's "foot in the door" details! > How they got the authority is through the Communications Act of 1934, > as passed and amended by our elected representatives in Congress, with > the approval of our elected President. For roughly two decades of having a widely-publicly-used Internet, nobody realized that they already had this authority... until suddenly just now... we were just too stupid to see the obvious all those years, right? And how nice that the people who decided that this authority suddenly existed, are the ones who voted themselves that authority (referring to the vote on Thursday), and will be wielding that authority. Nobody has refuted my statement that their stated intentions for use of this authority, and their long term application of that authority, could be frighteningly different. What they say they will do for now... and what they COULD do in the future if this power grab stands--without anything more than another one of their little votes amongst themselves--could be very very different. FOR PERSPECTIVE... CONSIDER THIS HYPOTHETICAL: Suppose that the EPA was given a statutory power to monitor air quality (which is likely true, right)... decades later, a group of EPA officials have a little vote amongst themselves and they decide that they now define the air INSIDE your house is also covered by those same regulations and monitoring directives for outside air. Therefore, to carry out their task of monitoring the air inside your home, they conduct random warrent-less raids inside your homes, thus violating your 4th amendment rights. If the CO2 levels are too high (because someone likes to smoke), that person then gets fined, or their house gets bulldozed, etc. When asked about how they get that authority, someone like Lamar Owen points out that Congress gave them this authority in such-in-such clean air act past so many decades ago. I know that hypothetical example is even more preposterous than this net neutrality ruling... but probably not that much more! (in BOTH cases, the power grab involves an intrusion upon privately-owned space.. using a statute that was originally intended for public space) But the bigger picture isn't what the FCC STATES that they will do now.. it is what unelected FCC officials could do, with LITTLE accountability, in the future. Arguing for/against this power grab... only based on what they say they will do for now, is very naive. Future generations may ask us, "why didn't you stop this?" When we answer, "well, it wasn't implemented as badly when it first started". They'll reply, "but you should have checked to see how far this could go once that power grab was allowed (or ignored!)" -- Rob McEwen From lowen at pari.edu Sat Feb 28 20:25:56 2015 From: lowen at pari.edu (Lamar Owen) Date: Sat, 28 Feb 2015 15:25:56 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F21735.9070608@invaluement.com> References: Message-ID: <54F22454.90102@pari.edu> On 02/28/2015 02:29 PM, Rob McEwen wrote: > For roughly two decades of having a widely-publicly-used Internet, > nobody realized that they already had this authority... until suddenly > just now... we were just too stupid to see the obvious all those > years, right? Having authority and choosing to exercise it are two different things. Of course it was realized that they had this authority already; that's why these regulations were fought so strongly. > Nobody has refuted my statement that their stated intentions for use > of this authority, and their long term application of that authority, > could be frighteningly different. It's impossible to refute such a vaguely worded supposition. Refuting a 'could be' is like nailing gelatin to the wall, because virtually anything 'could be' even at vanishingly small probabilities. I 'could be' given a million dollars by a random strange tomorrow, but it's very unlikely. > > FOR PERSPECTIVE... CONSIDER THIS HYPOTHETICAL: Suppose that the EPA > was given a statutory power to monitor air quality (which is likely > true, right)... decades later, a group of EPA officials have a little > vote amongst themselves and they decide that they now define the air > INSIDE your house is also covered by those same regulations and > monitoring directives for outside air. Ok, I'll play along. So far, a reasonable analogy, except that such an ex parte action (a 'little vote amongst themselves') wouldn't survive judicial review. The FCC Commissioners didn't just 'have a little vote amongst themselves;' they held a complete, according to statute rulemaking proceeding. That is what our elected representatives have mandated that the FCC is to do when decisions need to be made. > Therefore, to carry out their task of monitoring the air inside your > home, they conduct random warrent-less raids inside your homes, thus > violating your 4th amendment rights. This is where your analogy drops off the deep end. The FCC will hear complaints from complainants who must follow a particular procedure and request specific relief after attempting to resolve the dispute by direct communication with the ISP in question. There aren't any 'raids' provided for by the current regulation; have you ever heard of any raids from a Title II action previously? There is no provision in the current regulation as passed for the FCC to do any monitoring; it's up to the complainant to make their case that the defendant violated 47CFR§8. This doesn't change the statute, just the regulations derived from the statute. To go with your analogy, as part of the newly added powers of the EPA under your hypothetical, it would now be possible for a complainant, after attempting to satisfy a 'inside the building unclean air' complaint with a particular establishment but failing, and having to go through a significant procedure, to get the EPA to rule that the owner of that establishment must provide relief to the complainant or be fined. No authority to raid, just authority to respond to complaints and fine accordingly. Any change to that rule requires another rulemaking proceeding. Before the FCC can change the wording to add any of your supposed power grab increases they will have to go through another full docket, with required public notices and the NPRM. And the courts can throw it all out. The FCC's primary power is economic, by fining. > I know that hypothetical example is even more preposterous than this > net neutrality ruling... but probably not that much more! (in BOTH > cases, the power grab involves an intrusion upon privately-owned > space.. using a statute that was originally intended for public space) The telecommunications infrastructure is in reality public space, not private, and has been for a really long time. Or are there any physical-layer facilities that are not regulated in some way? Let's see: 1.) Telephone copper and fiber? Nope, regulated as a common carrier already. 2.) Satellite? Nope, regulated. 3.) Wireless (3G, 4G)? Nope, regulated, and many of the spectrum auctions have strings attached, as Verizon Wireless found out last year. 4.) 2.4GHz ISM? Nope, regulated under §15 and subject to being further regulated. 5.) Municipal fiber? Nope, it's public by definition. 6.) Point to point optical? Maybe, but this is a vanishingly small number of links; I helped install one of these several years back. 7.) Point to point licensed microwave? Nope, regulated; license required. Even way back in NSFnet days the specter of regulation, in the form of discouragement of commercial traffic across the NSFnet, was present. I don't understand why people are so surprised at this ruling; the Internet is becoming a utility for the end user; it's no longer a free-for-all in the provider space. > > But the bigger picture isn't what the FCC STATES that they will do > now.. it is what unelected FCC officials could do, with LITTLE > accountability, in the future. FCC Commissioners are appointed, confirmed by the Senate, and have five year terms. Accountability here is from all three branches of the government, as it is possible to sue the FCC. From owen at delong.com Sat Feb 28 21:01:47 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 28 Feb 2015 13:01:47 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F20D6C.9020809@pari.edu> References: <54F0B751.30008@pari.edu> <54F0CC4E.101@invaluement.com> <54F20D6C.9020809@pari.edu> Message-ID: <5C25A66F-D7C3-4C15-A794-CBF52928E564@delong.com> >> In the same way, I don't like the BASIS for this authority... and what it potentially means in the long term... besides what they state that they intend to do with this new authority they've appointed themselves in the short term. >> > Had some people not apparently taken advantage of the situation as it existed before the proceeding in docket 14-28, it's likely no regulatory actions would have been initiated. There seems to be a lot of forgotten history in this discussion… The FCC tried a light-weight low-touch form of open internet regulation. $CABLECOs sued them and got it eliminated. Then they tried a different light-weight low-touch form of open internet regulation. $TELCOs sued them and got it eliminated. They were left with two basic choices at that point: 1. Allow the $TELCO and $CABLECO abuses working against an open internet to continue, which, frankly is what most of the more cynical among us expected, especially when Wheeler (who has traditionally been a mouthpiece for the $CABLE_LOBBY) announced his initial fast-lane proposal. 2. Use real authority and real regulations that exist and make the internet subject to those regulations, which appears to be what actually happened. > I'm not cheerleading by any means; I would much prefer less regulation than more in almost every situation; but the simple fact is that people do tend to abuse the lack of regulations long enough for regulatory agencies to take notice, and then everyone loses when regulations come. In this particular case, I think it is primarily $INCUMBENT_OLIGOPOLY_PROVIDERs which lose. As near as I can tell from what is in the actual regulations, everyone else pretty much wins. Yes, there are probably some tradeoffs and I’m sure that the incumbents will attempt to find ways to make this as painful as possible for consumers while they throw their typical temper tantrums. (Think they’re above temper tantrums, then look at Verizon’s blog in morse code.) > Reading the R&O once it is released will be very interesting, at least in my opinion, since we'll get a glimpse into the rationale and the thought processes that went into each paragraph and subparagraph of this new section in 47CFR. I'm most interested in the rationale behind the pleading requirements, like requiring complainants to serve the complaint by hand delivery on the named defendant, requiring the complainant to serve two copies on the Market Disputes Resolution Division of the EB, etc. This seems to be a pretty high bar to filing a complaint; it's not like you can just fill out a form on the FCC website to report your ISP for violating 47CFR§8. Heh, part of the rationale might be the fact that they got over 2 million filings on this docket...... I suspect that they want to be able to take real complaints seriously and not waste resources on a large number of frivolous complaints. Since the intent is to primarily deal with the B2B interactions between content and service providers where one is abusing the other to the detriment of the end-users, I suspect all the intended players have the resources to comply with the filing requirements fairly easily, but it prevents every Tom, Dick, and Johnny with a web browser from becoming an expensive PITA. Sort of a “You must be this tall to ride” process, for lack of a better term. However, that’s pure speculation on my part, and I agree reading the actual R&O will be interesting. Overall, I think this may well be the first (mostly) functional regulatory process to occur in recent memory. Owen From owen at delong.com Sat Feb 28 21:04:21 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 28 Feb 2015 13:04:21 -0800 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F21019.8070700@meetinghouse.net> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <54F21019.8070700@meetinghouse.net> Message-ID: <9B42A3E7-1C85-4C45-8CD7-2B725653E5A1@delong.com> > On Feb 28, 2015, at 10:59 , Miles Fidelman wrote: > > Michael Thomas wrote: >> >> On 02/28/2015 08:59 AM, Mike Hammett wrote: >>> 20 years ago was into AOL's prime, so yes they did. >>> >>> Great, let's re-evaluate the system when demand necessitates it. For many systems, it's literally as simple as changing how many channels are allocated to what directions. >>> >>> By that logic, we would have been running 486s with 32 gigs of RAM because some people today use that much. *shakes head* Obviously the majority of the dissent here works with OPM. >>> >>> >> >> The point is that the incumbents (= telephants) at the time looked at even the >> minuscule AOL user base with disdain saying that their market share was irrelevant. >> Even into the early 2000's these same guys thought that voice was the only thing >> that really mattered because the new fangled internet users were outliers from their >> pots bread and butter. We now know those outliers were important. Being dismissive >> of them is dangerous. >> > > Actually, I think the incumbents do get it, at this point - at least Verizon does. FIOS is a pretty nice offering, and they offer some pretty high speeds, both up and down. It's just that they've stopped their buildout with the large markets; but they've been a power behind the state level anti-municipal broadband laws. Kind of annoying that, in areas where they have no intention of building out, they want to stand in the way of folks who want to do it themselves. It’s not that they have no intention of building out… It’s that they want to get the right bribes^wkickbacks^wsubsidies to do so. If the city can build their own fiber, they’re a lot less likely to bribe^wpayoff^wsubsidize Verizon to do it for them. Also, if a municipality owns fiber, they might actually allow open competition on the services side of things which would not only be bad for FIOS, but might also be bad for VZW, too. Owen From owen at delong.com Sat Feb 28 21:21:41 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 28 Feb 2015 13:21:41 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F21735.9070608@invaluement.com> References: <54F20D6C.9020809@pari.edu> <54F21735.9070608@invaluement.com> Message-ID: <43710257-326B-4951-AAFE-93AC65B192C6@delong.com> > On Feb 28, 2015, at 11:29 , Rob McEwen wrote: > > On 2/28/2015 1:48 PM, Lamar Owen wrote: >>> The bigger picture is (a) HOW they got this authority--self-defining it in, and (b) the potential abuse and 4th amendment violations, not just today's "foot in the door" details! >> How they got the authority is through the Communications Act of 1934, as passed and amended by our elected representatives in Congress, with the approval of our elected President. > > For roughly two decades of having a widely-publicly-used Internet, nobody realized that they already had this authority... until suddenly just now... we were just too stupid to see the obvious all those years, right? And how nice that the people who decided that this authority suddenly existed, are the ones who voted themselves that authority (referring to the vote on Thursday), and will be wielding that authority. Actually, many people realized they had the authority, including, but not limited to the FCC, the incumbent Telco/Cablecos, and Congress. To the credit of the commission, they tried very hard to find ways not to use such heavy handed authority to prevent the current abuses by the Telco/Cablecos, but each of their major efforts was thwarted by lawsuits from those same Telcos and Cablecos. Now, you want to cry foul because, faced with essentially no other way to stop the current string of abuses, the FCC has chosen to use the one and only authority it has that will stand up in court? That’s absurd. The commissioners didn’t suddenly realize this authority existed, they have been trying to avoid using it in such a heavy handed manner until the organizations they were trying to regulate essentially left them no other choice. > Nobody has refuted my statement that their stated intentions for use of this authority, and their long term application of that authority, could be frighteningly different. What they say they will do for now... and what they COULD do in the future if this power grab stands--without anything more than another one of their little votes amongst themselves--could be very very different. Sure… Not the least of which is FCC commissioner appointments are not lifetime appointments and even if they were, they wouldn’t live forever, so you’re going to have a different commission at some point in the future. That’s also true of Congress, the supreme court (and don’t get me started on some of their gaffs, such as Plessey V. Ferguson, Citizens United, Hobby Lobby, etc.). This isn’t a power grab. It’s a very judicious exercise of power they’ve had for a long time which they waited as long as possible to exercise. If you don’t like this, then the people to blame are not the commissioners, but the incumbent telcos and cablecos that brought this on themselves by blocking every attempt at more gentle regulation. > FOR PERSPECTIVE... CONSIDER THIS HYPOTHETICAL: Suppose that the EPA was given a statutory power to monitor air quality (which is likely true, right)... decades later, a group of EPA officials have a little vote amongst themselves and they decide that they now define the air INSIDE your house is also covered by those same regulations and monitoring directives for outside air. Therefore, to carry out their task of monitoring the air inside your home, they conduct random warrent-less raids inside your homes, thus violating your 4th amendment rights. If the CO2 levels are too high (because someone likes to smoke), that person then gets fined, or their house gets bulldozed, etc. When asked about how they get that authority, someone like Lamar Owen points out that Congress gave them this authority in such-in-such clean air act past so many decades ago. First of all, congress can’t exceed the authority of the fourth amendment, so that wouldn’t fly and you know it. The constitution overrides congress, not the other way around. Nothing in the FCC ruling that I’ve seen seems to have any fourth amendment (or any other portion of the bill of rights) implications as near as I can tell, even with the (bizarre and absurd) extensions recently granted by the supreme court in Citizens United. What, exactly, is it that you find so objectionable in the actual ruling? (Please cite CFR section or quote the objectionable pieces in your response). What horrible consequences is it that you think can come from further FCC interpretation or application of this ruling? > I know that hypothetical example is even more preposterous than this net neutrality ruling... but probably not that much more! (in BOTH cases, the power grab involves an intrusion upon privately-owned space.. using a statute that was originally intended for public space) Yes… Quite a bit more given that your example is completely preposterous _AND_ unconstitutional, whereas this net neutrality ruling is simply the next step in an ongoing battle between consumers+content providers vs. the broadband oligopolies with the FCC (for once) siding with the consumer. > But the bigger picture isn't what the FCC STATES that they will do now.. it is what unelected FCC officials could do, with LITTLE accountability, in the future. Arguing for/against this power grab... only based on what they say they will do for now, is very naive. Future generations may ask us, "why didn't you stop this?" When we answer, "well, it wasn't implemented as badly when it first started". They'll reply, "but you should have checked to see how far this could go once that power grab was allowed (or ignored!)” FCC officials (as you call them) are political appointees. They do have accountability in that if the executive administration doesn’t like what they do, they’re out. Their regulatory authority is limited to that authority granted to them by congress. If future generations are going to judge us for federal power grabs, I’m betting this won’t be the one they pick. First, I don’t see this as a power grab. Second, even if it were such a thing, it so starkly pales in comparison to the actions of DHS, BATFE, TSA, NSA, FBI, et. al. under the auspices of the USAPATRIOT act and supreme court rulings like Citizens United that I cannot imagine it will even make it onto their radar screen. Owen From bzs at world.std.com Sat Feb 28 21:23:56 2015 From: bzs at world.std.com (Barry Shein) Date: Sat, 28 Feb 2015 16:23:56 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <20150227165240.GA13738@puck.nether.net> <54F0AE3B.2010209@sprunk.org> <54F0B517.4050200@invaluement.com> <54F0B751.30008@pari.edu> <54F0C486.6010506@ufl.edu> Message-ID: <21746.12780.627757.484835@world.std.com> Back in the USENET days we advertised that we carried acccess to all USENET groups. One day a customer called asking to speak to me and said he'd like to complain, we did NOT carry all USENET groups. I said ok which don't we carry, mistakes are possible, I'll add them. He got cagey. I said well how do you know we don't carry all groups if you can't seem to name which groups we don't carry? He continued to hem and haw. I said oh you mean like child porn? Well, he said, let's say that's so, it would still be fraudulent to claim you carry ALL groups if you don't carry those, right? I said wrong, if a druggist says he stocks all drugs that doesn't have to include illegal drugs. After offering him a reasonable refund i got him off the phone. As others have said let's hope that's all that's implied. On February 27, 2015 at 14:32 khelms at zcorum.com (Scott Helms) wrote: > While I view that statement with trepidation, my first guess would one that > isn't in violation of state or federal law. About the only things I can > think off hand, ie stuff we get told to take down as hosters today, are > sites violating copyright law and child pornography. I hope that we don't > see any additions to that list. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Fri, Feb 27, 2015 at 2:24 PM, Bruce H McIntosh wrote: > > > > > > > On 2015-02-27 14:14, Jim Richardson wrote: > > > >> What's a "lawful" web site? > >> > >> Now *there* is a $64,000 question. Even more interesting is, "Who gets > > to decide day to day the answer to that question?" :) > > > > -- > > ------------------------------------------------------------------------ > > Bruce H. McIntosh bhm at ufl.edu > > Senior Network Engineer http://net-services.ufl.edu > > University of Florida Network Services 352-273-1066 > > -- -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 bzs at world.std.com Sat Feb 28 21:34:02 2015 From: bzs at world.std.com (Barry Shein) Date: Sat, 28 Feb 2015 16:34:02 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0CA30.7080706@paradoxnetworks.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CA30.7080706@paradoxnetworks.net> Message-ID: <21746.13386.327364.144631@world.std.com> I'm always a little suspicious when "this is all customers want" is a cover for "this is all customers will get". It's like the time I was tossed from a local "all you can eat" buffet (in the days of my admittedly huge appetite) the owner telling me yes, that is *ALL* you can eat, goodbye! Prescriptive trying to pass as descriptive. -- -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 bzs at world.std.com Sat Feb 28 21:47:41 2015 From: bzs at world.std.com (Barry Shein) Date: Sat, 28 Feb 2015 16:47:41 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0C8A5.60202@netwolves.com> Message-ID: <21746.14205.601235.39167@world.std.com> On February 27, 2015 at 14:50 khelms at zcorum.com (Scott Helms) wrote: > > I am absolutely not against good upstream rates! I do have a problem with > people saying that we must/should have symmetrical connectivity simply > because we don't see the market demand for that as of yet. It's push/pull. Lousy upstream bandwidth leads to remote siting of web hosting for example. From that we should conclude people don't want to host their websites at home? Similar statements have been made about remote backup. These glib declarations of what the market wants are just that, glib and not really based on much anything. Besides, it's a (rapidly) moving target. People once argued that 56kbps symmetric (dial-up) was plenty for the average user. Then when ISDN promised 128kbps many thought it was amazing and should be put into every home and we'd finally have the internet we dreamed of, a lot of it was deployed in Europe and Japan. As I remember EFF (and others) fought long and hard for broader deployment of 2B+D ISDN in the US. As some of us who looked into the technology kept pointing out it was an inherent loser, too expensive to deploy very widely and never intended or designed for raw bandwidth distribution. Its economics depended on the telcos "owning" per msg email fees (it was designed in another era) etc so it was more a give away the cameras and sell the film sort of technology, they had to "own", i.e., be able to bill, the whole stack (email, etc.) as then perceived. There is a strong tendency to rationalize the current state of the technology. -- -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 gwardell at gwsystems.co.il Sat Feb 28 22:07:46 2015 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Sat, 28 Feb 2015 17:07:46 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F21019.8070700@meetinghouse.net> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <54F21019.8070700@meetinghouse.net> Message-ID: <00a201d053a2$fbbcdbd0$f3369370$@gwsystems.co.il> > Actually, I think the incumbents do get it, at this point - at least Verizon does. FIOS is a pretty nice offering, and they offer some pretty high speeds, > both up and down. I don't know about other markets, but in the DC market FIOS is not with business accounts, thus you can't get FIOS with static IPs, thus you can't have site to site VPNs for organizations with offices at various geographic locations using FIOS. Gary From gwardell at gwsystems.co.il Sat Feb 28 22:16:03 2015 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Sat, 28 Feb 2015 17:16:03 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F1F97A.2030000@mtcc.com> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> Message-ID: <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> > From the consumer standpoint, I *really* don't think it's too much to ask that when I have the occasional 10 gig image to upload that it takes me << > than a full day. This has nothing really to do with symmetry, per se. It's the need to adapt to what the traffic is *actually* doing at peak times, > regardless of the average up/down byte count. When I was a COX customer they took the average upstream traffic. Thus I could burst over the upstream limit, for a while, but not a long while. They would eventually clamp me. Gary From bzs at world.std.com Sat Feb 28 22:38:34 2015 From: bzs at world.std.com (Barry Shein) Date: Sat, 28 Feb 2015 17:38:34 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> Message-ID: <21746.17258.270398.162820@world.std.com> Can we stop the disingenuity? Asymmetric service was introduced to discourage home users from deploying "commercial" services. As were bandwidth caps. One can argue all sorts of other "benefits" of this but when this started that was the problem on the table: How do we forcibly distinguish commercial (i.e., more expensive) from non-commercial usage? Answer: Give them a lot less upload than download bandwidth. Originally these asymmetric, typically DSL, links were hundreds of kbits upstream, not a lot more than a dial-up line. That and NAT thereby making it difficult -- not impossible, the savvy were in the noise -- to map domain names to permanent IP addresses. That's all this was about. It's not about "that's all they need", "that's all they want", etc. Now that bandwidth is growing rapidly and asymmetric is often 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire medium-sized ISPs ran on less than 10mbps symmetric not long ago. But it still imposes an upper bound of sorts, along with addressing limitations and bandwidth caps. That's all this is about. The telcos for many decades distinguished "business" voice service from "residential" service, even for just one phone line, though they mostly just winged it and if they declared you were defrauding them by using a residential line for a business they might shut you off and/or back bill you. Residential was quite a bit cheaper, most importantly local "unlimited" (unmetered) talk was only available on residential lines. Business lines were even coded 1MB (one m b) service, one metered business (line). The history is clear and they've just reinvented the model for internet but proactively enforced by technology rather than studying your usage patterns or whatever they used to do, scan for business ads using "residential" numbers, beyond bandwidth usage analysis. And the CATV companies are trying to reinvent CATV pricing for internet, turn Netflix (e.g.) into an analogue of HBO and other premium CATV services. What's so difficult to understand here? -- -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 marka at isc.org Sat Feb 28 22:46:31 2015 From: marka at isc.org (Mark Andrews) Date: Sun, 01 Mar 2015 09:46:31 +1100 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: Your message of "Sat, 28 Feb 2015 17:16:03 -0500." <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> Message-ID: <20150228224632.CB39B2A930D4@rock.dv.isc.org> Home users should be able to upload a content in the same amount of time it takes to download content. It doesn't matter if they only do this occasionally. Without symetric speeds they can't do this. They are being given a slow path. Arguing otherwise is like saying that their time is not important. Yes, that capacity is sitting idle most of the time but so what! We really should be delivering connections where link speed is not the limiting factor. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog at ics-il.net Sat Feb 28 22:50:02 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 28 Feb 2015 16:50:02 -0600 (CST) Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21746.17258.270398.162820@world.std.com> Message-ID: <27896791.814.1425163775749.JavaMail.mhammett@ThunderFuck> Spoken by someone that apparently has no idea how things work. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Barry Shein" To: "NANOG" Sent: Saturday, February 28, 2015 4:38:34 PM Subject: Re: Verizon Policy Statement on Net Neutrality Can we stop the disingenuity? Asymmetric service was introduced to discourage home users from deploying "commercial" services. As were bandwidth caps. One can argue all sorts of other "benefits" of this but when this started that was the problem on the table: How do we forcibly distinguish commercial (i.e., more expensive) from non-commercial usage? Answer: Give them a lot less upload than download bandwidth. Originally these asymmetric, typically DSL, links were hundreds of kbits upstream, not a lot more than a dial-up line. That and NAT thereby making it difficult -- not impossible, the savvy were in the noise -- to map domain names to permanent IP addresses. That's all this was about. It's not about "that's all they need", "that's all they want", etc. Now that bandwidth is growing rapidly and asymmetric is often 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire medium-sized ISPs ran on less than 10mbps symmetric not long ago. But it still imposes an upper bound of sorts, along with addressing limitations and bandwidth caps. That's all this is about. The telcos for many decades distinguished "business" voice service from "residential" service, even for just one phone line, though they mostly just winged it and if they declared you were defrauding them by using a residential line for a business they might shut you off and/or back bill you. Residential was quite a bit cheaper, most importantly local "unlimited" (unmetered) talk was only available on residential lines. Business lines were even coded 1MB (one m b) service, one metered business (line). The history is clear and they've just reinvented the model for internet but proactively enforced by technology rather than studying your usage patterns or whatever they used to do, scan for business ads using "residential" numbers, beyond bandwidth usage analysis. And the CATV companies are trying to reinvent CATV pricing for internet, turn Netflix (e.g.) into an analogue of HBO and other premium CATV services. What's so difficult to understand here? -- -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 jbates at paradoxnetworks.net Sat Feb 28 22:49:56 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Sat, 28 Feb 2015 16:49:56 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21746.17258.270398.162820@world.std.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> Message-ID: <54F24614.8030805@paradoxnetworks.net> On 2/28/2015 4:38 PM, Barry Shein wrote: > Can we stop the disingenuity? > > Asymmetric service was introduced to discourage home users from > deploying "commercial" services. As were bandwidth caps. > Hmm, at one point I was going to ask if anyone else remembered a long time ago ISPs having something in their TOS about not hosting servers. It's been so long, I thought that perhaps I might be remembering wrong. > And the CATV companies are trying to reinvent CATV pricing for > internet, turn Netflix (e.g.) into an analogue of HBO and other > premium CATV services. > > What's so difficult to understand here? > You mean like how ESPN3 charges the ISP based on customers (who don't even care about ESPN) for access to their content instead of having customers create accounts and just pay for it themselves? It's extremely annoying, especially if you are small. It's a 2 way street. I really hope both sides lose. I love the ISP business, but I really hate the idea of having to negotiate pricing for every little thing. Honestly, if I could get away with transit only and not run a server, I might be happier. Jack From mike at mtcc.com Sat Feb 28 22:58:33 2015 From: mike at mtcc.com (Michael Thomas) Date: Sat, 28 Feb 2015 14:58:33 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21746.17258.270398.162820@world.std.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> Message-ID: <54F24819.1060808@mtcc.com> On 02/28/2015 02:38 PM, Barry Shein wrote: > Can we stop the disingenuity? > > Asymmetric service was introduced to discourage home users from > deploying "commercial" services. As were bandwidth caps. > > > Answer: Give them a lot less upload than download bandwidth. That's exactly how I remember why we are where we are now. Mike From clayton at mnsi.net Sat Feb 28 23:14:18 2015 From: clayton at mnsi.net (Clayton Zekelman) Date: Sat, 28 Feb 2015 18:14:18 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21746.17258.270398.162820@world.std.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> Message-ID: <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> You do of course realize that the asymmetry in CATV forward path/return path existed LONG before residential Internet access over cable networks exited? Sent from my iPhone > On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: > > > Can we stop the disingenuity? > > Asymmetric service was introduced to discourage home users from > deploying "commercial" services. As were bandwidth caps. > > One can argue all sorts of other "benefits" of this but when this > started that was the problem on the table: How do we forcibly > distinguish commercial (i.e., more expensive) from non-commercial > usage? > > Answer: Give them a lot less upload than download bandwidth. > > Originally these asymmetric, typically DSL, links were hundreds of > kbits upstream, not a lot more than a dial-up line. > > That and NAT thereby making it difficult -- not impossible, the savvy > were in the noise -- to map domain names to permanent IP addresses. > > That's all this was about. > > It's not about "that's all they need", "that's all they want", etc. > > Now that bandwidth is growing rapidly and asymmetric is often > 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire > medium-sized ISPs ran on less than 10mbps symmetric not long ago. But > it still imposes an upper bound of sorts, along with addressing > limitations and bandwidth caps. > > That's all this is about. > > The telcos for many decades distinguished "business" voice service > from "residential" service, even for just one phone line, though they > mostly just winged it and if they declared you were defrauding them by > using a residential line for a business they might shut you off and/or > back bill you. Residential was quite a bit cheaper, most importantly > local "unlimited" (unmetered) talk was only available on residential > lines. Business lines were even coded 1MB (one m b) service, one > metered business (line). > > The history is clear and they've just reinvented the model for > internet but proactively enforced by technology rather than studying > your usage patterns or whatever they used to do, scan for business ads > using "residential" numbers, beyond bandwidth usage analysis. > > And the CATV companies are trying to reinvent CATV pricing for > internet, turn Netflix (e.g.) into an analogue of HBO and other > premium CATV services. > > What's so difficult to understand here? > > -- > -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 nick at foobar.org Sat Feb 28 23:20:17 2015 From: nick at foobar.org (Nick Hilliard) Date: Sat, 28 Feb 2015 23:20:17 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21746.17258.270398.162820@world.std.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> Message-ID: <54F24D31.40200@foobar.org> On 28/02/2015 22:38, Barry Shein wrote: > Asymmetric service was introduced to discourage home users from > deploying "commercial" services. there were several reasons for asymmetric services, one of which was commercial. Another was that most users' bandwidth profiles were massively asymmetric to start with so it made sense for consumers to have more bandwidth in one direction than another. Another still was that cross-talk causes enough interference to prevent reverse adsl (i.e. greater bandwidth from customer to exchange) from working well. > As were bandwidth caps. Bandwidth caps were introduced in many cases to stop gratuitous abuse of service by the 1% of users who persistently ran their links at a rate that the pricing model they selected was not designed to handle. You've been around the block a bit so I'm sure you remember the days when transit was expensive and a major cost factor in running an isp. Some operators used and continue to use asymmetric bandwidth profiles and bandwidth caps as methods for driving up revenue rather than anything else in particular. International cellular roaming plans come to mind as one of the more egregious example of this, but there are many others. Nick From nanog at ics-il.net Sat Feb 28 23:20:31 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 28 Feb 2015 17:20:31 -0600 (CST) Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> Message-ID: <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> As I said earlier, there are only so many channels available. Channels added to upload are taken away from download. People use upload so infrequently it would be gross negligence on the provider's behalf. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Clayton Zekelman" To: "Barry Shein" Cc: "NANOG" Sent: Saturday, February 28, 2015 5:14:18 PM Subject: Re: Verizon Policy Statement on Net Neutrality You do of course realize that the asymmetry in CATV forward path/return path existed LONG before residential Internet access over cable networks exited? Sent from my iPhone > On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: > > > Can we stop the disingenuity? > > Asymmetric service was introduced to discourage home users from > deploying "commercial" services. As were bandwidth caps. > > One can argue all sorts of other "benefits" of this but when this > started that was the problem on the table: How do we forcibly > distinguish commercial (i.e., more expensive) from non-commercial > usage? > > Answer: Give them a lot less upload than download bandwidth. > > Originally these asymmetric, typically DSL, links were hundreds of > kbits upstream, not a lot more than a dial-up line. > > That and NAT thereby making it difficult -- not impossible, the savvy > were in the noise -- to map domain names to permanent IP addresses. > > That's all this was about. > > It's not about "that's all they need", "that's all they want", etc. > > Now that bandwidth is growing rapidly and asymmetric is often > 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire > medium-sized ISPs ran on less than 10mbps symmetric not long ago. But > it still imposes an upper bound of sorts, along with addressing > limitations and bandwidth caps. > > That's all this is about. > > The telcos for many decades distinguished "business" voice service > from "residential" service, even for just one phone line, though they > mostly just winged it and if they declared you were defrauding them by > using a residential line for a business they might shut you off and/or > back bill you. Residential was quite a bit cheaper, most importantly > local "unlimited" (unmetered) talk was only available on residential > lines. Business lines were even coded 1MB (one m b) service, one > metered business (line). > > The history is clear and they've just reinvented the model for > internet but proactively enforced by technology rather than studying > your usage patterns or whatever they used to do, scan for business ads > using "residential" numbers, beyond bandwidth usage analysis. > > And the CATV companies are trying to reinvent CATV pricing for > internet, turn Netflix (e.g.) into an analogue of HBO and other > premium CATV services. > > What's so difficult to understand here? > > -- > -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 mike at mtcc.com Sat Feb 28 23:25:16 2015 From: mike at mtcc.com (Michael Thomas) Date: Sat, 28 Feb 2015 15:25:16 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> Message-ID: <54F24E5C.1000407@mtcc.com> On 02/28/2015 03:14 PM, Clayton Zekelman wrote: > You do of course realize that the asymmetry in CATV forward path/return path existed LONG before residential Internet access over cable networks exited? The cable companies didn't want "servers" on residential customers either, and were animated by that. Cable didn't really have much of a return path at all at first -- I remember the stories of the crappy spectrum they were willing to allocate at first, but as I recall that was mainly because they hadn't transitioned to digital downstream and their analog down was pretty precious. Once they made that transition, the animus against residential "servers" was pretty much the only excuse -- I'm pretty sure they could map up/down/cable channels any way they wanted after that. Mike > > Sent from my iPhone > >> On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: >> >> >> Can we stop the disingenuity? >> >> Asymmetric service was introduced to discourage home users from >> deploying "commercial" services. As were bandwidth caps. >> >> One can argue all sorts of other "benefits" of this but when this >> started that was the problem on the table: How do we forcibly >> distinguish commercial (i.e., more expensive) from non-commercial >> usage? >> >> Answer: Give them a lot less upload than download bandwidth. >> >> Originally these asymmetric, typically DSL, links were hundreds of >> kbits upstream, not a lot more than a dial-up line. >> >> That and NAT thereby making it difficult -- not impossible, the savvy >> were in the noise -- to map domain names to permanent IP addresses. >> >> That's all this was about. >> >> It's not about "that's all they need", "that's all they want", etc. >> >> Now that bandwidth is growing rapidly and asymmetric is often >> 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire >> medium-sized ISPs ran on less than 10mbps symmetric not long ago. But >> it still imposes an upper bound of sorts, along with addressing >> limitations and bandwidth caps. >> >> That's all this is about. >> >> The telcos for many decades distinguished "business" voice service >> from "residential" service, even for just one phone line, though they >> mostly just winged it and if they declared you were defrauding them by >> using a residential line for a business they might shut you off and/or >> back bill you. Residential was quite a bit cheaper, most importantly >> local "unlimited" (unmetered) talk was only available on residential >> lines. Business lines were even coded 1MB (one m b) service, one >> metered business (line). >> >> The history is clear and they've just reinvented the model for >> internet but proactively enforced by technology rather than studying >> your usage patterns or whatever they used to do, scan for business ads >> using "residential" numbers, beyond bandwidth usage analysis. >> >> And the CATV companies are trying to reinvent CATV pricing for >> internet, turn Netflix (e.g.) into an analogue of HBO and other >> premium CATV services. >> >> What's so difficult to understand here? >> >> -- >> -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 Sat Feb 28 23:35:06 2015 From: clayton at mnsi.net (Clayton Zekelman) Date: Sat, 28 Feb 2015 18:35:06 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> References: <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> Message-ID: <6B8B9E2F-7833-492D-BBA8-F5B75C69D5B3@mnsi.net> And for historical reasons. The forward path started at TV channel 2. The return path was shoe horned in to the frequencies below that, which limited the amount of available spectrum for return path. Originally this didn't matter much because the only thing it was used for was set top box communications and occasionally sending video to the head end for community channel remote feeds. To change the split would require replacement of all the active and passive RF equipment in the network. Only now with he widespread conversion to digital cable are they able to free up enough spectrum to even consider moving the split at some point in the future. Sent from my iPhone > On Feb 28, 2015, at 6:20 PM, Mike Hammett wrote: > > As I said earlier, there are only so many channels available. Channels added to upload are taken away from download. People use upload so infrequently it would be gross negligence on the provider's behalf. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Clayton Zekelman" > To: "Barry Shein" > Cc: "NANOG" > Sent: Saturday, February 28, 2015 5:14:18 PM > Subject: Re: Verizon Policy Statement on Net Neutrality > > You do of course realize that the asymmetry in CATV forward path/return path existed LONG before residential Internet access over cable networks exited? > > Sent from my iPhone > >> On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: >> >> >> Can we stop the disingenuity? >> >> Asymmetric service was introduced to discourage home users from >> deploying "commercial" services. As were bandwidth caps. >> >> One can argue all sorts of other "benefits" of this but when this >> started that was the problem on the table: How do we forcibly >> distinguish commercial (i.e., more expensive) from non-commercial >> usage? >> >> Answer: Give them a lot less upload than download bandwidth. >> >> Originally these asymmetric, typically DSL, links were hundreds of >> kbits upstream, not a lot more than a dial-up line. >> >> That and NAT thereby making it difficult -- not impossible, the savvy >> were in the noise -- to map domain names to permanent IP addresses. >> >> That's all this was about. >> >> It's not about "that's all they need", "that's all they want", etc. >> >> Now that bandwidth is growing rapidly and asymmetric is often >> 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire >> medium-sized ISPs ran on less than 10mbps symmetric not long ago. But >> it still imposes an upper bound of sorts, along with addressing >> limitations and bandwidth caps. >> >> That's all this is about. >> >> The telcos for many decades distinguished "business" voice service >> from "residential" service, even for just one phone line, though they >> mostly just winged it and if they declared you were defrauding them by >> using a residential line for a business they might shut you off and/or >> back bill you. Residential was quite a bit cheaper, most importantly >> local "unlimited" (unmetered) talk was only available on residential >> lines. Business lines were even coded 1MB (one m b) service, one >> metered business (line). >> >> The history is clear and they've just reinvented the model for >> internet but proactively enforced by technology rather than studying >> your usage patterns or whatever they used to do, scan for business ads >> using "residential" numbers, beyond bandwidth usage analysis. >> >> And the CATV companies are trying to reinvent CATV pricing for >> internet, turn Netflix (e.g.) into an analogue of HBO and other >> premium CATV services. >> >> What's so difficult to understand here? >> >> -- >> -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 kmedcalf at dessus.com Sat Feb 28 23:51:11 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 28 Feb 2015 16:51:11 -0700 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F21735.9070608@invaluement.com> Message-ID: Except for the fact that the FCC decided that they wanted to give up Title II regulation of the internet because they were paid to do so by the telephants, they would have alwAYS had this power. The people who were bribed are simply dead and the current crop of "officials" (they are not representatives -- they are elected officials) do not feel obligated by the bribes accepted by their corrupt predecessors. --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rob McEwen >Sent: Saturday, 28 February, 2015 12:30 >To: nanog at nanog.org >Subject: Re: Verizon Policy Statement on Net Neutrality > >On 2/28/2015 1:48 PM, Lamar Owen wrote: >>> The bigger picture is (a) HOW they got this authority--self-defining >>> it in, and (b) the potential abuse and 4th amendment violations, not >>> just today's "foot in the door" details! >> How they got the authority is through the Communications Act of 1934, >> as passed and amended by our elected representatives in Congress, with >> the approval of our elected President. > >For roughly two decades of having a widely-publicly-used Internet, >nobody realized that they already had this authority... until suddenly >just now... we were just too stupid to see the obvious all those years, >right? And how nice that the people who decided that this authority >suddenly existed, are the ones who voted themselves that authority >(referring to the vote on Thursday), and will be wielding that authority. > >Nobody has refuted my statement that their stated intentions for use of >this authority, and their long term application of that authority, could >be frighteningly different. What they say they will do for now... and >what they COULD do in the future if this power grab stands--without >anything more than another one of their little votes amongst >themselves--could be very very different. > >FOR PERSPECTIVE... CONSIDER THIS HYPOTHETICAL: Suppose that the EPA was >given a statutory power to monitor air quality (which is likely true, >right)... decades later, a group of EPA officials have a little vote >amongst themselves and they decide that they now define the air INSIDE >your house is also covered by those same regulations and monitoring >directives for outside air. Therefore, to carry out their task of >monitoring the air inside your home, they conduct random warrent-less >raids inside your homes, thus violating your 4th amendment rights. If >the CO2 levels are too high (because someone likes to smoke), that >person then gets fined, or their house gets bulldozed, etc. When asked >about how they get that authority, someone like Lamar Owen points out >that Congress gave them this authority in such-in-such clean air act >past so many decades ago. > >I know that hypothetical example is even more preposterous than this net >neutrality ruling... but probably not that much more! (in BOTH cases, >the power grab involves an intrusion upon privately-owned space.. using >a statute that was originally intended for public space) > >But the bigger picture isn't what the FCC STATES that they will do now.. >it is what unelected FCC officials could do, with LITTLE accountability, >in the future. Arguing for/against this power grab... only based on what >they say they will do for now, is very naive. Future generations may ask >us, "why didn't you stop this?" When we answer, "well, it wasn't >implemented as badly when it first started". They'll reply, "but you >should have checked to see how far this could go once that power grab >was allowed (or ignored!)" > >-- >Rob McEwen From kmedcalf at dessus.com Sat Feb 28 23:57:35 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 28 Feb 2015 16:57:35 -0700 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <5C25A66F-D7C3-4C15-A794-CBF52928E564@delong.com> Message-ID: You are forgetting that the Internet and ISPs where originally common carriers and the FCC at the behest of the government decided to de-regulate so that they could raid, arrest, charge, fine and torture ISPs if their customers visited websites the governement did not like, sent email the government did not like, or posted to web forums something that the government did not like. Contrast that with things which remained common carriers (wireline telephone) wherein the carrier is not responsible for what the customer does using their telephone. --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Owen DeLong >Sent: Saturday, 28 February, 2015 14:02 >To: Lamar Owen >Cc: nanog at nanog.org >Subject: Re: Verizon Policy Statement on Net Neutrality > >>> In the same way, I don't like the BASIS for this authority... and what >it potentially means in the long term... besides what they state that >they intend to do with this new authority they've appointed themselves in >the short term. >>> >> Had some people not apparently taken advantage of the situation as it >existed before the proceeding in docket 14-28, it's likely no regulatory >actions would have been initiated. > >There seems to be a lot of forgotten history in this discussion... > >The FCC tried a light-weight low-touch form of open internet regulation. > >$CABLECOs sued them and got it eliminated. > >Then they tried a different light-weight low-touch form of open internet >regulation. > >$TELCOs sued them and got it eliminated. > >They were left with two basic choices at that point: > > 1. Allow the $TELCO and $CABLECO abuses working against an open >internet to continue, which, frankly > is what most of the more cynical among us expected, especially >when Wheeler (who has traditionally been > a mouthpiece for the $CABLE_LOBBY) announced his initial fast- >lane proposal. > > 2. Use real authority and real regulations that exist and make >the internet subject to those regulations, which > appears to be what actually happened. > >> I'm not cheerleading by any means; I would much prefer less regulation >than more in almost every situation; but the simple fact is that people >do tend to abuse the lack of regulations long enough for regulatory >agencies to take notice, and then everyone loses when regulations come. > >In this particular case, I think it is primarily >$INCUMBENT_OLIGOPOLY_PROVIDERs which lose. As near as I can tell from >what is in the actual regulations, everyone else pretty much wins. Yes, >there are probably some tradeoffs and I'm sure that the incumbents will >attempt to find ways to make this as painful as possible for consumers >while they throw their typical temper tantrums. (Think they're above >temper tantrums, then look at Verizon's blog in morse code.) > >> Reading the R&O once it is released will be very interesting, at least >in my opinion, since we'll get a glimpse into the rationale and the >thought processes that went into each paragraph and subparagraph of this >new section in 47CFR. I'm most interested in the rationale behind the >pleading requirements, like requiring complainants to serve the >complaint by hand delivery on the named defendant, requiring the >complainant to serve two copies on the Market Disputes Resolution >Division of the EB, etc. This seems to be a pretty high bar to filing a >complaint; it's not like you can just fill out a form on the FCC website >to report your ISP for violating 47CFR§8. Heh, part of the rationale >might be the fact that they got over 2 million filings on this >docket...... > >I suspect that they want to be able to take real complaints seriously and >not waste resources on a large number of frivolous complaints. Since the >intent is to primarily deal with the B2B interactions between content and >service providers where one is abusing the other to the detriment of the >end-users, I suspect all the intended players have the resources to >comply with the filing requirements fairly easily, but it prevents every >Tom, Dick, and Johnny with a web browser from becoming an expensive PITA. >Sort of a "You must be this tall to ride" process, for lack of a better >term. However, that's pure speculation on my part, and >I agree reading the actual R&O will be interesting. > >Overall, I think this may well be the first (mostly) functional >regulatory process to occur in recent memory. > >Owen