From owen at delong.com Mon Jun 1 01:07:03 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 31 May 2015 18:07:03 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> Message-ID: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> As I said before: Host Virtual (vr.org ) Softlayer (softlayer.com ) Linode (Linode.com ) All have full dual-stack support. I?m sure there are others. Owen > On May 31, 2015, at 2:49 PM, George, Wes wrote: > > > On 5/31/15, 3:11 PM, "Owen DeLong" wrote: > >> if they said ?We have a plan, and it will take X amount of time?, I would >> respect that. >> >> If they said ?We have a plan and we?re not sure how long it will take?, I >> would continue to poke >> them about sooner is better than later and having a target date helps >> people to plan. >> >> ?We don?t think IPv6 matters and we aren?t announcing any plans to get it >> implemented or any >> date by which it will be available?, on the other hand, being what they >> have actually repeatedly >> said to me until very recently, not so much. >> >> Now, they?re saying (essentially) ?We think IPv6 might matter, but we >> aren?t announcing >> any plans to get it implemented or any date by which it will be >> available? . To me, this >> is still a problematic situation for their customers. > > At the risk of feeding the troll... > > This isn't just an AWS problem. > > "All Compute Engine networks use the IPv4 protocol. Compute Engine > currently does not support IPv6. However, Google is a major advocate of > IPv6 and it is an important future direction." > https://cloud.google.com/compute/docs/networking > > > "The foundational work to enable IPv6 in the Azure environment is well > underway. However, we are unable to share a date when IPv6 support will be > generally available at this time." > > http://azure.microsoft.com/en-us/pricing/faq/ > > > This is only marginally better, as it acknowledges that it's important, > but still has no actual committed timeline and doesn't even reference any > available ELB hacks. > > Anyone else want to either name and shame, or highlight cloud providers > that actually *support* IPv6 as an alternative to these so that one might > be able to vote with one's wallet? > > > 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 morrowc.lists at gmail.com Mon Jun 1 02:46:02 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 31 May 2015 22:46:02 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> Message-ID: On Sun, May 31, 2015 at 9:07 PM, Owen DeLong wrote: > As I said before: > > Host Virtual (vr.org ) > Softlayer (softlayer.com ) > Linode (Linode.com ) > > All have full dual-stack support. >> At the risk of feeding the troll... >> >> This isn't just an AWS problem. So... ok. What does it mean, for a customer of a cloud service, to be ipv6 enabled? What really matters for a cloud service user? What information could be surfaced to the cloud providers in order to get the most important ipv6 'stuff' done 'now'? o Is it most important to be able to address ever VM you create with an ipv6 address? o Is it most important to be able to talk to backend services (perhaps at your prem) over ipv6? o Is it most important that administrative interfaces to the VM systems (either REST/etc interfaces for managing vms or 'ssh'/etc) be ipv6 reachable? o Is it most important to be able to terminate ipv6 connections (or datagrams) on a VM service for the public to use? I don't see, especially if the vm networking is unique to each customer, that 'ipv6 address on vm' is hugely important as a first/important goal. I DO see that landing publicly available services on an ipv6 endpoint is super helpful. Would AWS (or any other cloud provider that's not currently up on the v6 bandwagon) enabling a loadbalanced ipv6 vip for your public service (perhaps not just http/s services even?) be enough to relieve some of the pressure on other parties and move the ball forward meaningfully enough for the cloud providers and their customers? -chris From mpalmer at hezmatt.org Mon Jun 1 05:19:00 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Mon, 1 Jun 2015 15:19:00 +1000 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> Message-ID: <20150601051900.GV724@hezmatt.org> On Sun, May 31, 2015 at 10:46:02PM -0400, Christopher Morrow wrote: > So... ok. What does it mean, for a customer of a cloud service, to be > ipv6 enabled? IPv6 feature-parity with IPv4. My must-haves, sorted in order of importance (most to least): > o Is it most important to be able to terminate ipv6 connections (or > datagrams) on a VM service for the public to use? > > o Is it most important to be able to address ever VM you create with > an ipv6 address? > > o Is it most important to be able to talk to backend services (perhaps > at your prem) over ipv6? If, by "backend services", you mean things like RDS, S3, etc, this is in the right place. > o Is it most important that administrative interfaces to the VM > systems (either REST/etc interfaces for managing vms or 'ssh'/etc) be > ipv6 reachable? > > I don't see, especially if the vm networking is unique to each > customer, that 'ipv6 address on vm' is hugely important as a > first/important goal. I DO see that landing publicly available > services on an ipv6 endpoint is super helpful. Being able to address VMs over IPv6 (and have VMs talk to the outside world over IPv6) is *really* useful. Takes away the need to NAT anything. > Would AWS (or any other cloud provider that's not currently up on the > v6 bandwagon) enabling a loadbalanced ipv6 vip for your public service > (perhaps not just http/s services even?) be enough to relieve some of > the pressure on other parties and move the ball forward meaningfully > enough for the cloud providers and their customers? No. I'm currently building an infrastructure which is entirely v6-native internally; the only parts which are IPv4 are public-facing incoming service endpoints, and outgoing connections to other parts of the Internet, which are proxied. Everything else is talking amongst themselves entirely over IPv6. - Matt -- "After years of studying math and encountering surprising and counterintuitive results, I came to accept that math is always reasonable, by my intuition of what is reasonably is not always reasonable." -- Steve VanDevender, ASR From nogs at border6.com Mon Jun 1 06:44:07 2015 From: nogs at border6.com (Pawel Rybczyk) Date: Mon, 01 Jun 2015 08:44:07 +0200 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: <7867-b6.nogs.nanog-31052015205002-96@news.border6.com> References: <7867-b6.nogs.nanog-31052015205002-96@news.border6.com> Message-ID: <556BFF37.7010908@border6.com> Hi, We've have recently published new version of our BGP routing optimization platform where we included new feature called: vRouter. That might be interesting for you. The vRouter provides route summarization support to BGP routers whose TCAM is unable to hold the entire actual feed of Internet prefixes. In this case BGP edge routers work in 'Selective Route Download' mode and transmit the full routing table to the vRouter. The NSI vRouter selects a number of prefixes to which the most data is routed and advertises the necessary routes back to the edge router. Thereby the edge router does not have to support the entire routing table, but only the routes it needs to reach. Please contact me off-list if you need more details. Regards, Pawel Rybczyk Product Evangelist Border 6 On 05/31/2015 10:46 PM, Jason Canady wrote: > If your traffic is small, you could setup a VyOS box. You can still get > redundancy by having two switches, each one connected to an upstream > provider receiving a default route. Then hookup your VyOS router to > each switch and receive full routes to that. You will need a /29 subnet > from your providers to pull this off. If your VyOS box goes down for > whatever reason, you will failover to using one or the other switch. > Announce your prefixes using the BGP session on each switch so that your > inbound traffic doesn't hit the VyOS box. > From owen at delong.com Mon Jun 1 07:06:18 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 1 Jun 2015 00:06:18 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> Message-ID: > On May 31, 2015, at 7:46 PM, Christopher Morrow wrote: > > On Sun, May 31, 2015 at 9:07 PM, Owen DeLong wrote: >> As I said before: >> >> Host Virtual (vr.org ) >> Softlayer (softlayer.com ) >> Linode (Linode.com ) >> >> All have full dual-stack support. > > > >>> At the risk of feeding the troll... >>> >>> This isn't just an AWS problem. > > So... ok. What does it mean, for a customer of a cloud service, to be > ipv6 enabled? It means that I should be able to develop my cloud application(s) with full native IPv6 support and expect to be able to serve IPv4-only, IPv6-only, and dual-stack customers using native IP stacks on my virtual machines without requiring external proxies, translators, etc. from the cloud service provider. > What really matters for a cloud service user? What information could > be surfaced to the cloud providers in order to get the most important > ipv6 'stuff' done 'now?? Ideally, simple native routing of IPv6 to provisioned hosts should suffice in most cases. > o Is it most important to be able to address ever VM you create with > an ipv6 address? Yes. > o Is it most important to be able to talk to backend services (perhaps > at your prem) over ipv6? It?s hard to imagine how you could provide the first one above without having this one come along for the ride. > > o Is it most important that administrative interfaces to the VM > systems (either REST/etc interfaces for managing vms or 'ssh'/etc) be > ipv6 reachable? This would be the one where I would most be able to tolerate a delay. > o Is it most important to be able to terminate ipv6 connections (or > datagrams) on a VM service for the public to use? If you can?t get the first one, this might be adequate as a short-term fallback for some applications. However, it?s far from ideal and not all that useful. > I don't see, especially if the vm networking is unique to each > customer, that 'ipv6 address on vm' is hugely important as a > first/important goal. I DO see that landing publicly available > services on an ipv6 endpoint is super helpful. Here?s the thing? In order to land IPv6 services without IPv6 support on the VM, you?re creating an environment where: 1. The services basically have to be supported by some form of proxy/nat/etc. So long as you are using a supported L4 protocol, that might be fine, but not everything fits in TCP/UDP/ICMP. Generally supporting GRE, IKE, and application-specific protocols becomes an issue. 2. The developer has to develop and maintain an IPv4-compatible codebase rather than be able to use the dual stack capabilities of a host with IPV6_V6ONLY=FALSE in the socket options. This delays the ability to produce native IPv6 applications. 3. Proxies and translators add complexity, increase fragility, and reduce performance. > Would AWS (or any other cloud provider that's not currently up on the > v6 bandwagon) enabling a loadbalanced ipv6 vip for your public service > (perhaps not just http/s services even?) be enough to relieve some of > the pressure on other parties and move the ball forward meaningfully > enough for the cloud providers and their customers? For the reasons outlined above, I don?t really think so. Owen From jwbensley at gmail.com Mon Jun 1 08:24:30 2015 From: jwbensley at gmail.com (James Bensley) Date: Mon, 1 Jun 2015 09:24:30 +0100 Subject: WiFi courses/vendors recommendation In-Reply-To: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> References: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> Message-ID: On 31 May 2015 at 23:28, James Laszko wrote: > I don't have a vendor-agnostic answer for you on #1, but as far as a vendor - Ruckus Wireless. +1 for Ruckus, I have worked with a Ruckus partner in the UK I can recommend if anyone needs one. The Ruckus tin is great having seen it to believe it. The roaming AP stuff works great. James. From surfer at mauigateway.com Mon Jun 1 08:36:46 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 1 Jun 2015 01:36:46 -0700 Subject: BGP Multihoming 2 providers full or partial? Message-ID: <20150601013646.7D3120A4@m0048141.ppops.net> --- nogs at border6.com wrote: From: Pawel Rybczyk platform where we included new feature called That might be interesting for you. ------------------------------------------- This might be interesting for you. https://www.nanog.org/list Please read #5 before going further. Product Evangelist -------------------------------------- BLECH! I need a shower. scott From bill at herrin.us Mon Jun 1 13:24:33 2015 From: bill at herrin.us (William Herrin) Date: Mon, 1 Jun 2015 09:24:33 -0400 Subject: BGP in the Washngton Post Message-ID: Interesting story about BGP and security in the Washington Post today: http://www.washingtonpost.com/sf/business/2015/05/31/net-of-insecurity-part-2/ -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From blake at ispn.net Mon Jun 1 13:29:24 2015 From: blake at ispn.net (Blake Hudson) Date: Mon, 01 Jun 2015 08:29:24 -0500 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: Message-ID: <556C5E34.5070309@ispn.net> Baldur Norddahl wrote on 5/31/2015 1:13 PM: > Remember this: > > 1) for inbound traffic there will be no difference at all. > > 2) routers will ignore a static route if the link is down. If you can get > BFD from the providers then even better. > > So you can emulate 99% of what you get with full routes by loading in > static routes. A simple example would be adding a 0.0.0.0/1 route to one > provider and 128.0.0.0/1 route to the other and get approximately 50% load > sharing. > > You will still get redundancy as the route will ignored if the link is down > and traffic will follow the default route to the other transit provider. > Something to point out: Sometimes the device you connect to is up, but has no reachability to the rest of the world. Using static routes is.. well.. static. There are a few cases (such as the one mentioned) where a static route can be somewhat dynamic. Another case is when the static route next hop does not respond to ARP requests or some machines have the ability to perform triggered actions on some sort of event/test. But why bother with BGP if you're just going to override its decisions by using static routes? As another commenter mentioned, using anything less than a full table is a compromise. If one wants the redundancy in the case of an upstream ISP outage, take full routes. If one wants the traffic engineering flexibility, take full routes and use a BGP knob like route maps to modify existing prefixes rather than make up your own. A default route of last resort is fine; Overriding BGP through static routes degrades the utility of BGP. From mansaxel at besserwisser.org Mon Jun 1 13:39:04 2015 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Mon, 1 Jun 2015 15:39:04 +0200 Subject: BGP in the Washngton Post In-Reply-To: References: Message-ID: <20150601133904.GG23822@besserwisser.org> Subject: BGP in the Washngton Post Date: Mon, Jun 01, 2015 at 09:24:33AM -0400 Quoting William Herrin (bill at herrin.us): > Interesting story about BGP and security in the Washington Post today: > > http://www.washingtonpost.com/sf/business/2015/05/31/net-of-insecurity-part-2/ sort of dissappointed they did not quote randy using only lower case. looks weird. once past that, good comment. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Isn't this my STOP?! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nanog at ics-il.net Mon Jun 1 13:39:03 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 1 Jun 2015 08:39:03 -0500 (CDT) Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: <20150601013646.7D3120A4@m0048141.ppops.net> Message-ID: <16362070.2072.1433165918967.JavaMail.mhammett@ThunderFuck> Seems like a perfectly good post to me. Someone made an inquiry as to how to solve a particular problem There were multiple solutions presented. Pawel posted relevant, on-topic information regarding how his product could solve the problem in a unique way. No harm, no foul. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Scott Weeks" To: nanog at nanog.org Sent: Monday, June 1, 2015 3:36:46 AM Subject: Re: BGP Multihoming 2 providers full or partial? --- nogs at border6.com wrote: From: Pawel Rybczyk platform where we included new feature called That might be interesting for you. ------------------------------------------- This might be interesting for you. https://www.nanog.org/list Please read #5 before going further. Product Evangelist -------------------------------------- BLECH! I need a shower. scott From jmasiello at actionet.com Mon Jun 1 13:44:20 2015 From: jmasiello at actionet.com (Jeff Masiello) Date: Mon, 1 Jun 2015 13:44:20 +0000 Subject: BGP in the Washngton Post In-Reply-To: References: Message-ID: <0d4cef03d62949e7b1e1c2be0ab7aa73@ACTPTDWEXCHM01.actionet.com> Excellent find, Thanks! I forwarded this to a bunch of people. Mostly managers. Jeff A. Masiello ???? -----Original Message----- From: NANOG [mailto:nanog-bounces+jmasiello=actionet.com at nanog.org] On Behalf Of William Herrin Sent: Monday, June 01, 2015 9:25 AM To: nanog at nanog.org Subject: BGP in the Washngton Post Interesting story about BGP and security in the Washington Post today: http://www.washingtonpost.com/sf/business/2015/05/31/net-of-insecurity-part-2/ -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From cb.list6 at gmail.com Mon Jun 1 14:08:20 2015 From: cb.list6 at gmail.com (Ca By) Date: Mon, 1 Jun 2015 07:08:20 -0700 Subject: BGP in the Washngton Post In-Reply-To: References: Message-ID: On Mon, Jun 1, 2015 at 6:24 AM, William Herrin wrote: > Interesting story about BGP and security in the Washington Post today: > > > http://www.washingtonpost.com/sf/business/2015/05/31/net-of-insecurity-part-2/ > > -Bill > > The article left me with the feeling that there was a secure version of BGP that is available but network operators are too short-term-focused and foolish to deploy it. I believe the situation is more complicated than that, no? There is no "secure version of BGP". There are a handful of things that help, like RPKI ... but they are far off from hitting the mark of "securing the internet"... not too mention the ARIN RPKI SNAFU with various lawyers that make RPKI impossible for a large part of the internet. CB PS. All my ipv4 and ipv6 routes are RPKI signed, but I can't validate because Cisco does not think validation within a VRF is an IOS-XR worthy features PPS. It does blow my mind that the internet works so well given that its security relies on the good faith and reputation of a few network janitors and plumbers > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From morrowc.lists at gmail.com Mon Jun 1 14:08:32 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Jun 2015 10:08:32 -0400 Subject: BGP in the Washngton Post In-Reply-To: <20150601133904.GG23822@besserwisser.org> References: <20150601133904.GG23822@besserwisser.org> Message-ID: On Mon, Jun 1, 2015 at 9:39 AM, M?ns Nilsson wrote: > Subject: BGP in the Washngton Post Date: Mon, Jun 01, 2015 at 09:24:33AM -0400 Quoting William Herrin (bill at herrin.us): >> Interesting story about BGP and security in the Washington Post today: >> >> http://www.washingtonpost.com/sf/business/2015/05/31/net-of-insecurity-part-2/ > > sort of dissappointed they did not quote randy using only lower case. looks weird. once past that, good comment. and in comic sans you mean? From morrowc.lists at gmail.com Mon Jun 1 14:23:53 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Jun 2015 10:23:53 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <20150601051900.GV724@hezmatt.org> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601051900.GV724@hezmatt.org> Message-ID: On Mon, Jun 1, 2015 at 1:19 AM, Matt Palmer wrote: > On Sun, May 31, 2015 at 10:46:02PM -0400, Christopher Morrow wrote: >> So... ok. What does it mean, for a customer of a cloud service, to be >> ipv6 enabled? > > IPv6 feature-parity with IPv4. > > My must-haves, sorted in order of importance (most to least): > >> o Is it most important to be able to terminate ipv6 connections (or >> datagrams) on a VM service for the public to use? >> and would a headerswapping 'proxy' be ok? there's (today) a 'header swapping proxy' doing 'nat' (sort of?) for you, so I imagine that whether the 'headerswapping' is v4 to v4 or v6 to v4 you get the same end effect: "People can see your kitten gifs". >> o Is it most important to be able to address every VM you create with >> an ipv6 address? why is this bit important though? I see folk, I think, get hung up on this, but I can't figure out WHY this is as important as folk seem to want it to be? all the vms have names, you end up using the names not the ips... and thus the underlying ip protocool isn't really important? Today those names translate to v4 public ips, which get 'headerswapped' into v4 private addresses on the way through the firehedge at AWS. Tomorrow they may get swapped from v6 to v4... or there may be v6 endpoints. >> o Is it most important to be able to talk to backend services (perhaps >> at your prem) over ipv6? > > If, by "backend services", you mean things like RDS, S3, etc, this is in the > right place. > I meant 'your oracle financials installation at $HOMEBASE'. Things like 'internal amazon services' to me are a named endpoint and: 1) the name you use could be resolving to something different than the external view 2) it's a name not an ip version... provided you have the inny and it's an outy, I'm not sure that what ip protocol you use on the RESTful request matters a bunch. >> o Is it most important that administrative interfaces to the VM >> systems (either REST/etc interfaces for managing vms or 'ssh'/etc) be >> ipv6 reachable? >> >> I don't see, especially if the vm networking is unique to each >> customer, that 'ipv6 address on vm' is hugely important as a >> first/important goal. I DO see that landing publicly available >> services on an ipv6 endpoint is super helpful. > > Being able to address VMs over IPv6 (and have VMs talk to the outside world > over IPv6) is *really* useful. Takes away the need to NAT anything. but the nat isn't really your concern right (it all happens magically for you)? presuming you can talk to 'backend services' and $HOMEBASE over ipv6 you'd also be able to make connections to other v6 endpoints as well. there's little difference REALLY between v4 and v6 ... and jabbing a connection through a proxy to get v6 endpoints would work 'just fine'. (albeit protocol limitations at the higher levels could be interesting if the connection wasn't just 'swapping headers') >> Would AWS (or any other cloud provider that's not currently up on the >> v6 bandwagon) enabling a loadbalanced ipv6 vip for your public service >> (perhaps not just http/s services even?) be enough to relieve some of >> the pressure on other parties and move the ball forward meaningfully >> enough for the cloud providers and their customers? > > No. I'm currently building an infrastructure which is entirely v6-native > internally; the only parts which are IPv4 are public-facing incoming service > endpoints, and outgoing connections to other parts of the Internet, which > are proxied. Everything else is talking amongst themselves entirely over > IPv6. that's great, but I'm not sure that 'all v6 internally!' matters a whole bunch? I look at aws/etc as "bunch of goo doing computation/calculation/storage/etc" with some public VIP (v4, v6, etc) that are well defined and which are tailored to your userbase's needs/abilities. You don't actually ssh to 'ipv6 literal' or 'ipv4 literal', you ssh to 'superawesome.vm.mine.com' and provide http/s (or whatever) services via 'external-service-name.com'. Whether the 1200 vms in your private network cloud are ipv4 or ipv6 isn't important (really) since they also talk to eachother via names, not literal ip numbers. There isn't NAT that you care about there either, the name/ip translation does the right thing (or should) such that 'superawesome.vm.availzone1.com' and 'superawesome.vm.availzone2.com' can chat freely by name without concerns for underlying ip version numbers used (and even without caring that 'chrissawesome.vm.availzone1.com' is 10.0.0.1 as well. From jared at puck.nether.net Mon Jun 1 15:00:38 2015 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 1 Jun 2015 11:00:38 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: References: Message-ID: <04FE9EA4-8AB0-4A81-BF87-5DC29DF5EBF0@puck.nether.net> > On Jun 1, 2015, at 10:08 AM, Ca By wrote: > The article left me with the feeling that there was a secure version of BGP > that is available but network operators are too short-term-focused and > foolish to deploy it. > > I believe the situation is more complicated than that, no? There is no > "secure version of BGP". There are a handful of things that help, like > RPKI ... but they are far off from hitting the mark of "securing the > internet"... not too mention the ARIN RPKI SNAFU with various lawyers that > make RPKI impossible for a large part of the internet. > > CB > > PS. All my ipv4 and ipv6 routes are RPKI signed, but I can't validate > because Cisco does not think validation within a VRF is an IOS-XR worthy > features > > PPS. It does blow my mind that the internet works so well given that its > security relies on the good faith and reputation of a few network janitors > and plumbers The issue here is that people treat routing security the same way as the Jennifer Anniston character in "Office Space" and her flair. People do the minimum to make it work and forget about it. This can have catastrophic effects if one does that with your sewers, septic fields, etc but we accept it in the BGP and routing universe for some reason. You even see that with the IRR data, people add and never remove. You can explore your objects here, you might be surprised how old they are or who is injecting garbage today. http://irrexplorer.nlnog.net/ at $dayjob we try to do the right thing and as a result see complaints from customers, prospects and even our vendors that what we do pushes their scale limits and capabilities. Gert asks if you enabled IPv6 on something today, (or did you turn IPv4 off soon I think will be a fair question). What have we (You!) done to improve routing security recently? Do we need a photo or t-shirt of randy bush saying ?only you can prevent route hijackings?? - Jared From nanog at ics-il.net Mon Jun 1 15:04:59 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 1 Jun 2015 10:04:59 -0500 (CDT) Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <04FE9EA4-8AB0-4A81-BF87-5DC29DF5EBF0@puck.nether.net> Message-ID: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> Actually, that's the level of attention given to all kinds of infrastructure just about everywhere. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Jared Mauch" To: "Ca By" Cc: nanog at nanog.org Sent: Monday, June 1, 2015 10:00:38 AM Subject: Routing Insecurity (Re: BGP in the Washington Post) > On Jun 1, 2015, at 10:08 AM, Ca By wrote: > The article left me with the feeling that there was a secure version of BGP > that is available but network operators are too short-term-focused and > foolish to deploy it. > > I believe the situation is more complicated than that, no? There is no > "secure version of BGP". There are a handful of things that help, like > RPKI ... but they are far off from hitting the mark of "securing the > internet"... not too mention the ARIN RPKI SNAFU with various lawyers that > make RPKI impossible for a large part of the internet. > > CB > > PS. All my ipv4 and ipv6 routes are RPKI signed, but I can't validate > because Cisco does not think validation within a VRF is an IOS-XR worthy > features > > PPS. It does blow my mind that the internet works so well given that its > security relies on the good faith and reputation of a few network janitors > and plumbers The issue here is that people treat routing security the same way as the Jennifer Anniston character in "Office Space" and her flair. People do the minimum to make it work and forget about it. This can have catastrophic effects if one does that with your sewers, septic fields, etc but we accept it in the BGP and routing universe for some reason. You even see that with the IRR data, people add and never remove. You can explore your objects here, you might be surprised how old they are or who is injecting garbage today. http://irrexplorer.nlnog.net/ at $dayjob we try to do the right thing and as a result see complaints from customers, prospects and even our vendors that what we do pushes their scale limits and capabilities. Gert asks if you enabled IPv6 on something today, (or did you turn IPv4 off soon I think will be a fair question). What have we (You!) done to improve routing security recently? Do we need a photo or t-shirt of randy bush saying ?only you can prevent route hijackings?? - Jared From mark.tinka at seacom.mu Mon Jun 1 15:17:39 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 1 Jun 2015 17:17:39 +0200 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <04FE9EA4-8AB0-4A81-BF87-5DC29DF5EBF0@puck.nether.net> References: <04FE9EA4-8AB0-4A81-BF87-5DC29DF5EBF0@puck.nether.net> Message-ID: <556C7793.4080806@seacom.mu> On 1/Jun/15 17:00, Jared Mauch wrote: > This can have catastrophic effects if one does that with your sewers, > septic fields, etc but we accept it in the BGP and routing universe > for some reason. Because our industry (for better or worse) is not as regulated as other "life-concerning" things in the world such as health, aviation, education, construction, finance, electricity, e.t.c., are, it is up to us to make sure we do the right thing. But if there is no "official" or "standard" metric against which we can hold one another accountable, we are all bound to do our own things, as you say, that are enough to make it work and forget about it. As the saying goes, "You can't blame a monkey for botching a brain surgery". Our lack of regulation means we can quickly scramble up a global routing protocol on three napkins and get it into production. This is a good thing. The question now is - how important is this Internetnetwork to us that we are willing to accept a moderate to significant amount of inconvenience in order to improve its long term utility the same way we expect the sewer companies to do a decent job keeping the filth out of sight? Mark. From mark.tinka at seacom.mu Mon Jun 1 15:21:00 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 1 Jun 2015 17:21:00 +0200 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> Message-ID: <556C785C.2040807@seacom.mu> On 1/Jun/15 17:04, Mike Hammett wrote: > Actually, that's the level of attention given to all kinds of infrastructure just about everywhere. ;-) The difference is that there are standardized (global) guidelines for those infrastructures within their own industry, that lack of compliance can lead to serious fines, jail time or both. A network operator unmaliciously screwing up their BGP configuration and taking one side of a continent out is unlikely to see any punishment beyond being fired by his employer, or losing his customers if self-employed. Mark. From morrowc.lists at gmail.com Mon Jun 1 15:30:00 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Jun 2015 11:30:00 -0400 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> Message-ID: On Mon, Jun 1, 2015 at 3:06 AM, Owen DeLong wrote: > >> On May 31, 2015, at 7:46 PM, Christopher Morrow wrote: >> >> On Sun, May 31, 2015 at 9:07 PM, Owen DeLong wrote: >>> As I said before: >>> >>> Host Virtual (vr.org ) >>> Softlayer (softlayer.com ) >>> Linode (Linode.com ) >>> >>> All have full dual-stack support. >> >> >> >>>> At the risk of feeding the troll... >>>> >>>> This isn't just an AWS problem. >> >> So... ok. What does it mean, for a customer of a cloud service, to be >> ipv6 enabled? > > It means that I should be able to develop my cloud application(s) with full native IPv6 support and expect to be able to serve IPv4-only, IPv6-only, and dual-stack customers using native IP stacks on my virtual machines without requiring external proxies, translators, etc. from the cloud service provider. > Ok, I suppose as a long term goal that seems fine. I don't get why 'ipv6 address on my vm' matters a whole bunch (*in a world where v4 is still available to you I mean), but as a long term goal, sure fine. In the short term though, that was my question: "What should be prioritized, and then get that information to aws/gce/rackspace/etc product managers" because I suspect their engineers are not silly, they know that v6 should be part of the plan... but the PM folk are saying: "No one is asking for this v6 thing, but lots of people want that other shiney bauble...so build the shiney!!" >> What really matters for a cloud service user? What information could >> be surfaced to the cloud providers in order to get the most important >> ipv6 'stuff' done 'now?? > > Ideally, simple native routing of IPv6 to provisioned hosts should suffice in most cases. > >> o Is it most important to be able to address ever VM you create with >> an ipv6 address? > > Yes. > long term sure, short term though.. really?? isn't it more important to be able to terminate v6 services from 'public' users? (and v4 as well because not everyone has v6 at home/work/mobile) >> o Is it most important to be able to talk to backend services (perhaps >> at your prem) over ipv6? > > It?s hard to imagine how you could provide the first one above without having this one come along for the ride. >> >> o Is it most important that administrative interfaces to the VM >> systems (either REST/etc interfaces for managing vms or 'ssh'/etc) be >> ipv6 reachable? > > This would be the one where I would most be able to tolerate a delay. > >> o Is it most important to be able to terminate ipv6 connections (or >> datagrams) on a VM service for the public to use? > > If you can?t get the first one, this might be adequate as a short-term fallback for some applications. However, it?s far from ideal and not all that useful. > I agree it's not ideal, and I was making a list of 'short term goals' that could be prioritized and get us all to the v6 utopia later. >> I don't see, especially if the vm networking is unique to each >> customer, that 'ipv6 address on vm' is hugely important as a >> first/important goal. I DO see that landing publicly available >> services on an ipv6 endpoint is super helpful. > > Here?s the thing? In order to land IPv6 services without IPv6 support on the VM, you?re creating an environment where: > > 1. The services basically have to be supported by some form of proxy/nat/etc. > So long as you are using a supported L4 protocol, that might be fine, but not everything fits in TCP/UDP/ICMP. > Generally supporting GRE, IKE, and application-specific protocols becomes an issue. > I figured the simplest path from v6 to v4 was: "Rip the header and extension headers off, make a v4 packet, deliver to vm" aside from "yes, your request came from " that should 'just work', you do have to maintain some state to deliver back, depending on the implementation (but even that is probably able to be hidden from the 'user' and provisioned/capacity planned independent of the 'user'). > 2. The developer has to develop and maintain an IPv4-compatible codebase rather than be able to use > the dual stack capabilities of a host with IPV6_V6ONLY=FALSE in the socket options. This delays the > ability to produce native IPv6 applications. > > 3. Proxies and translators add complexity, increase fragility, and reduce performance. > I think this point is cogent, but ... also part of the pie that 'aws' pays for you the user... Or rather they run a 'service' which takes care of this, has slas and slos... "All packets delivered with 99.99% having Xms extra latency!" "Service has 99.999% uptime!" "Throughput comparable (99.99% at peak, 99% of the time) to straight/native v4" >> Would AWS (or any other cloud provider that's not currently up on the >> v6 bandwagon) enabling a loadbalanced ipv6 vip for your public service >> (perhaps not just http/s services even?) be enough to relieve some of >> the pressure on other parties and move the ball forward meaningfully >> enough for the cloud providers and their customers? > > For the reasons outlined above, I don?t really think so. ok, I figured that for short-term while the providers figure out: "Oh yea, this v6 thing is pretty simple in our encap'd world... why didn't we just turn it on originally?" getting v6 endpoints with little hassle for the 'user' (vm user) would help us all a bunch. From cb.list6 at gmail.com Mon Jun 1 15:31:27 2015 From: cb.list6 at gmail.com (Ca By) Date: Mon, 1 Jun 2015 08:31:27 -0700 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <556C785C.2040807@seacom.mu> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> Message-ID: On Mon, Jun 1, 2015 at 8:21 AM, Mark Tinka wrote: > > > On 1/Jun/15 17:04, Mike Hammett wrote: > > Actually, that's the level of attention given to all kinds of > infrastructure just about everywhere. ;-) > > The difference is that there are standardized (global) guidelines for > those infrastructures within their own industry, that lack of compliance > can lead to serious fines, jail time or both. > > A network operator unmaliciously screwing up their BGP configuration and > taking one side of a continent out is unlikely to see any punishment > beyond being fired by his employer, or losing his customers if > self-employed. > > Mark. > Also, the internet usually works pretty good-ish and the janitors clean up the messes pretty quick-ish. That said, i believe the BGP situation is completely hygienic relative to the DDoS issues going on that could be solved by BCP38 and otherwise fixing poorly admin'd DNS, NTP, CHARGEN, and SSDP nodes. The aforementioned janitors are pretty powerless on this front... and... various parties on all side are looking to cash in (booters on one side, web scrubbers on the other)... which is a very dangerous arms race with real money on both sides looking to escalate the harm / fix. CB From rdobbins at arbor.net Mon Jun 1 15:34:46 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 01 Jun 2015 22:34:46 +0700 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <556C785C.2040807@seacom.mu> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> Message-ID: On 1 Jun 2015, at 22:21, Mark Tinka wrote: > The difference is that there are standardized (global) guidelines for > those infrastructures within their own industry, that lack of > compliance > can lead to serious fines, jail time or both. 1. Ensuring insurance underwriters understand the amount of unsecured risk they have, and working with them to develop the *verifiable* checklists they should be going through before they write 'cyber-' policies. 2. Working with ISO to develop relevant outcome-based standards (e.g., not what you type into your config, but rather the desired result, such as source address validation, detection/classification/traceback/mitigation capabilities, et. al.). 3. Working with regulatory bodies in various regulated verticals to require aforementioned ISOs, same with insurance companies serving those industries (this will have an ink-blot effect reaching down into their supply/service chains). 4. Working with governmental bodies to require aforementioned ISOs in the regulated industries. 5. Working with PCI/DSS to add an availability component, as well as all relevant integrity BCPs. 6. Adding outcome-based requirements surrounding all the relevant BCPs to peering/transit agreements, getting regulators and governments to require same. I really think the insurance industry is going to be the best/easiest route to take (pardon the pun); this has the advantage of not requiring further governmental regulation, and does offer a market-based solution. I know Bill Woodcock has some experience in this general arena. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Mon Jun 1 15:39:08 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 01 Jun 2015 22:39:08 +0700 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> Message-ID: <3EB8B809-0170-4FF7-B55C-4BA0B26F8A28@arbor.net> On 1 Jun 2015, at 22:31, Ca By wrote: > scrubbers on the other)... which is a very dangerous arms race with > real money on both sides > looking to escalate the harm / fix. My fondest wish is for there to cease to be a need for DDoS mitigation tools and techniques, and I do my best to try and educate and proselytize to that end, and have done so for many years. I would much rather be working on other problem-sets. But needs must. ----------------------------------- Roland Dobbins From alh-ietf at tndh.net Mon Jun 1 15:41:11 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 1 Jun 2015 08:41:11 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601051900.GV724@hezmatt.org> Message-ID: <07b701d09c81$6508bc90$2f1a35b0$@tndh.net> > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > Christopher Morrow > Sent: Monday, June 01, 2015 7:24 AM > To: Matt Palmer > Cc: nanog list > Subject: Re: AWS Elastic IP architecture > > On Mon, Jun 1, 2015 at 1:19 AM, Matt Palmer > wrote: > > On Sun, May 31, 2015 at 10:46:02PM -0400, Christopher Morrow wrote: > >> So... ok. What does it mean, for a customer of a cloud service, to be > >> ipv6 enabled? > > > > IPv6 feature-parity with IPv4. > > > > My must-haves, sorted in order of importance (most to least): > > > >> o Is it most important to be able to terminate ipv6 connections (or > >> datagrams) on a VM service for the public to use? > >> > > and would a headerswapping 'proxy' be ok? there's (today) a 'header > swapping proxy' doing 'nat' (sort of?) for you, so I imagine that whether the > 'headerswapping' is v4 to v4 or v6 to v4 you get the same end effect: > "People can see your kitten gifs". > > >> o Is it most important to be able to address every VM you create with > >> an ipv6 address? > > why is this bit important though? I see folk, I think, get hung up on this, but I > can't figure out WHY this is as important as folk seem to want it to be? > > all the vms have names, you end up using the names not the ips... and thus > the underlying ip protocool isn't really important? Today those names > translate to v4 public ips, which get 'headerswapped' into v4 private > addresses on the way through the firehedge at AWS. Tomorrow they may > get swapped from v6 to v4... or there may be v6 endpoints. > > >> o Is it most important to be able to talk to backend services > >> (perhaps at your prem) over ipv6? > > > > If, by "backend services", you mean things like RDS, S3, etc, this is > > in the right place. > > > > I meant 'your oracle financials installation at $HOMEBASE'. Things like > 'internal amazon services' to me are a named endpoint and: > 1) the name you use could be resolving to something different than the > external view > 2) it's a name not an ip version... provided you have the inny and it's an > outy, I'm not sure that what ip protocol you use on the RESTful request > matters a bunch. > > >> o Is it most important that administrative interfaces to the VM > >> systems (either REST/etc interfaces for managing vms or 'ssh'/etc) be > >> ipv6 reachable? > >> > >> I don't see, especially if the vm networking is unique to each > >> customer, that 'ipv6 address on vm' is hugely important as a > >> first/important goal. I DO see that landing publicly available > >> services on an ipv6 endpoint is super helpful. > > > > Being able to address VMs over IPv6 (and have VMs talk to the outside > > world over IPv6) is *really* useful. Takes away the need to NAT anything. > > but the nat isn't really your concern right (it all happens magically for you)? > presuming you can talk to 'backend services' and $HOMEBASE over ipv6 > you'd also be able to make connections to other v6 endpoints as well. > there's little difference REALLY between v4 and v6 ... and jabbing a > connection through a proxy to get v6 endpoints would work 'just fine'. > (albeit protocol limitations at the higher levels could be interesting if the > connection wasn't just 'swapping headers') > > >> Would AWS (or any other cloud provider that's not currently up on the > >> v6 bandwagon) enabling a loadbalanced ipv6 vip for your public > >> service (perhaps not just http/s services even?) be enough to relieve > >> some of the pressure on other parties and move the ball forward > >> meaningfully enough for the cloud providers and their customers? > > > > No. I'm currently building an infrastructure which is entirely > > v6-native internally; the only parts which are IPv4 are public-facing > > incoming service endpoints, and outgoing connections to other parts of > > the Internet, which are proxied. Everything else is talking amongst > > themselves entirely over IPv6. > > that's great, but I'm not sure that 'all v6 internally!' matters a whole bunch? I > look at aws/etc as "bunch of goo doing > computation/calculation/storage/etc" with some public VIP (v4, v6, > etc) that are well defined and which are tailored to your userbase's > needs/abilities. > > You don't actually ssh to 'ipv6 literal' or 'ipv4 literal', you ssh to > 'superawesome.vm.mine.com' and provide http/s (or whatever) services via > 'external-service-name.com'. Whether the 1200 vms in your private network > cloud are ipv4 or ipv6 isn't important (really) since they also talk to > eachother via names, not literal ip numbers. There isn't NAT that you care > about there either, the name/ip translation does the right thing (or should) > such that 'superawesome.vm.availzone1.com' and > 'superawesome.vm.availzone2.com' can chat freely by name without > concerns for underlying ip version numbers used (and even without caring > that 'chrissawesome.vm.availzone1.com' is 10.0.0.1 as well. Look at the problem in the other direction, and you will see that addresses often matter. What if you want to deny ssh connections from a particular address range? The source isn't going to tell you the name it is coming from. What if you want to deploy an MTA on your VM and block connections from SPAM-A-LOT data centers? How do you do that when the header-swap function presents useless crap from an external proxy mapping function? That said, if you double nat from the vip to the stack in a way that masks the internal transport of the service (so that a native stack on the VM behaves as if it is directly attached to the outside world), then it doesn't matter what the service internal transport is. What I read in your line of comments to Owen is that the service only does a header swap once and expects the application on the VM to compensate. In that case there is an impact on the cost of deployment and overall utility. Tony From baldur.norddahl at gmail.com Mon Jun 1 15:49:00 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 1 Jun 2015 17:49:00 +0200 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: <556C5E34.5070309@ispn.net> References: <556C5E34.5070309@ispn.net> Message-ID: On 1 June 2015 at 15:29, Blake Hudson wrote: > Something to point out: Sometimes the device you connect to is up, but has > no reachability to the rest of the world. Using static routes is.. well.. > static. There are a few cases (such as the one mentioned) where a static > route can be somewhat dynamic. Another case is when the static route next > hop does not respond to ARP requests or some machines have the ability to > perform triggered actions on some sort of event/test. But why bother with > BGP if you're just going to override its decisions by using static routes? > > As another commenter mentioned, using anything less than a full table is a > compromise. If one wants the redundancy in the case of an upstream ISP > outage, take full routes. If one wants the traffic engineering flexibility, > take full routes and use a BGP knob like route maps to modify existing > prefixes rather than make up your own. A default route of last resort is > fine; Overriding BGP through static routes degrades the utility of BGP. > Thanks for pointing this out. However I would like to argue whether this is a big drawback or not. If the original poster had infinite money and infinite resources there would be no question to ask. Just get the most expensive router out there and get full tables. So given that the money could be spent on other things, that might be more helpful for his company, is it good value to invest in new routers? I believe every company and NOC teams needs to decide this for themselves. I do however feel this is often a rushed decision because people have an idea that anything less than full tables is not good enough and that you are not a real ISP if you do not have full tables etc. It is true that your static routes could end up pointing at a half dead router, that still keeps the link up. But it is also perfectly possible for a router to keep advertising routes, that it really can't forward traffic to or where there are service problems so servere that it amounts to the same (excessive packet loss etc). This is supposed to be rare for a good quality transit provider and the remedy is the same (manually take the link down). We got our big routers and full tables early on. With perfect 20/20 hindsight I am not sure I would spend the money that way if I had to do it over. All I am saying is that you can get most of the value with partial tables. You get 100% of it with ingress traffic and you can move a very large fraction of your egress exactly the same. Your redundancy might not be equal, but it will not be entirely bad. Regards, Baldur From morrowc.lists at gmail.com Mon Jun 1 15:52:15 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Jun 2015 11:52:15 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <07b701d09c81$6508bc90$2f1a35b0$@tndh.net> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601051900.GV724@hezmatt.org> <07b701d09c81$6508bc90$2f1a35b0$@tndh.net> Message-ID: On Mon, Jun 1, 2015 at 11:41 AM, Tony Hain wrote: > > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of >> Christopher Morrow >> Sent: Monday, June 01, 2015 7:24 AM >> To: Matt Palmer >> Cc: nanog list >> Subject: Re: AWS Elastic IP architecture >> >> On Mon, Jun 1, 2015 at 1:19 AM, Matt Palmer >> wrote: >> > On Sun, May 31, 2015 at 10:46:02PM -0400, Christopher Morrow wrote: >> >> So... ok. What does it mean, for a customer of a cloud service, to be >> >> ipv6 enabled? >> > >> > IPv6 feature-parity with IPv4. >> > >> > My must-haves, sorted in order of importance (most to least): >> > >> >> o Is it most important to be able to terminate ipv6 connections (or >> >> datagrams) on a VM service for the public to use? >> >> >> >> and would a headerswapping 'proxy' be ok? there's (today) a 'header >> swapping proxy' doing 'nat' (sort of?) for you, so I imagine that whether the >> 'headerswapping' is v4 to v4 or v6 to v4 you get the same end effect: >> "People can see your kitten gifs". >> >> >> o Is it most important to be able to address every VM you create with >> >> an ipv6 address? >> >> why is this bit important though? I see folk, I think, get hung up on this, but I >> can't figure out WHY this is as important as folk seem to want it to be? >> >> all the vms have names, you end up using the names not the ips... and thus >> the underlying ip protocool isn't really important? Today those names >> translate to v4 public ips, which get 'headerswapped' into v4 private >> addresses on the way through the firehedge at AWS. Tomorrow they may >> get swapped from v6 to v4... or there may be v6 endpoints. >> >> >> o Is it most important to be able to talk to backend services >> >> (perhaps at your prem) over ipv6? >> > >> > If, by "backend services", you mean things like RDS, S3, etc, this is >> > in the right place. >> > >> >> I meant 'your oracle financials installation at $HOMEBASE'. Things like >> 'internal amazon services' to me are a named endpoint and: >> 1) the name you use could be resolving to something different than the >> external view >> 2) it's a name not an ip version... provided you have the inny and it's an >> outy, I'm not sure that what ip protocol you use on the RESTful request >> matters a bunch. >> >> >> o Is it most important that administrative interfaces to the VM >> >> systems (either REST/etc interfaces for managing vms or 'ssh'/etc) be >> >> ipv6 reachable? >> >> >> >> I don't see, especially if the vm networking is unique to each >> >> customer, that 'ipv6 address on vm' is hugely important as a >> >> first/important goal. I DO see that landing publicly available >> >> services on an ipv6 endpoint is super helpful. >> > >> > Being able to address VMs over IPv6 (and have VMs talk to the outside >> > world over IPv6) is *really* useful. Takes away the need to NAT anything. >> >> but the nat isn't really your concern right (it all happens magically for you)? >> presuming you can talk to 'backend services' and $HOMEBASE over ipv6 >> you'd also be able to make connections to other v6 endpoints as well. >> there's little difference REALLY between v4 and v6 ... and jabbing a >> connection through a proxy to get v6 endpoints would work 'just fine'. >> (albeit protocol limitations at the higher levels could be interesting if the >> connection wasn't just 'swapping headers') >> >> >> Would AWS (or any other cloud provider that's not currently up on the >> >> v6 bandwagon) enabling a loadbalanced ipv6 vip for your public >> >> service (perhaps not just http/s services even?) be enough to relieve >> >> some of the pressure on other parties and move the ball forward >> >> meaningfully enough for the cloud providers and their customers? >> > >> > No. I'm currently building an infrastructure which is entirely >> > v6-native internally; the only parts which are IPv4 are public-facing >> > incoming service endpoints, and outgoing connections to other parts of >> > the Internet, which are proxied. Everything else is talking amongst >> > themselves entirely over IPv6. >> >> that's great, but I'm not sure that 'all v6 internally!' matters a whole bunch? I >> look at aws/etc as "bunch of goo doing >> computation/calculation/storage/etc" with some public VIP (v4, v6, >> etc) that are well defined and which are tailored to your userbase's >> needs/abilities. >> >> You don't actually ssh to 'ipv6 literal' or 'ipv4 literal', you ssh to >> 'superawesome.vm.mine.com' and provide http/s (or whatever) services via >> 'external-service-name.com'. Whether the 1200 vms in your private network >> cloud are ipv4 or ipv6 isn't important (really) since they also talk to >> eachother via names, not literal ip numbers. There isn't NAT that you care >> about there either, the name/ip translation does the right thing (or should) >> such that 'superawesome.vm.availzone1.com' and >> 'superawesome.vm.availzone2.com' can chat freely by name without >> concerns for underlying ip version numbers used (and even without caring >> that 'chrissawesome.vm.availzone1.com' is 10.0.0.1 as well. > > Look at the problem in the other direction, and you will see that addresses often matter. What if you want to deny ssh connections from a particular address range? this sounds like a manage-your-vm question... keep that on v4 only until native v6 gets to your vm. (short term vs long term solution space) >The source isn't going to tell you the name it is coming from. What if you want to deploy an MTA on your VM and block connections from SPAM-A-LOT data centers? How do you do that when the header-swap function presents useless crap from an external proxy mapping function? > yup, 'not http' services are harder to deal with in a 'swap headers' world. > That said, if you double nat from the vip to the stack in a way that masks the internal transport of the service (so that a native stack on the VM behaves as if it is directly attached to the outside world), then it doesn't matter what the service internal transport is. > I was mostly envisioning this, but the header-swap seems easy for a bunch of things (to me at least). > What I read in your line of comments to Owen is that the service only does a header swap once and expects the application on the VM to compensate. In that case there is an impact on the cost of deployment and overall utility. 'compensate' ? do you mean 'get some extra information about the real source address for further policy-type questions to be answered' ? I would hope that in the 'header swap' service there's as little overhead applied to the end system as possible... I'd like my apache server to answer v6 requests without having a v6 address-listening-port on my machine. For 'web' stuff 'X-forwarded-for' seems simple, but breaks for https :( Oh, so what if the 'header swap' service simply shoveled the v6 into a gre (or equivalent) tunnel and dropped that on your doorstep? potentially with an 'apt-get install aws-tunnelservice' ? I would bet in the 'vm network' you could solve a bunch of this easily enough, and provide a v6 address inside the tunnel on the vm providing the services. loadbalancing is a bit rougher (more state management) but .. is doable. -chris From hugo at slabnet.com Mon Jun 1 16:21:44 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 1 Jun 2015 09:21:44 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601051900.GV724@hezmatt.org> <07b701d09c81$6508bc90$2f1a35b0$@tndh.net> Message-ID: <20150601162144.GJ4389@bamboo.slabnet.com> >I would hope that in the 'header swap' service there's as little >overhead applied to the end system as possible... I'd like my apache >server to answer v6 requests without having a v6 >address-listening-port on my machine. Why? Honestly: why would you want to abstract v6 up into the application layer rather than just having the network address and address family visible right at the network layer? >For 'web' stuff 'X-forwarded-for' seems simple, but breaks for https :( Which is an example of why people are pushing to just do the network layer stuff in the network layer, rather than pushing it up the stack. >'compensate' ? do you mean 'get some extra information about the real >source address for further policy-type questions to be answered' ? Hopefully without speaking for someone else, but probably yes. It also necessitates having application-/protocol-specific methods for extracting that information (e.g. the X-forwarded-for you cited). So the options are: 1. Go with the header-swap-type setup you describe, which requires protocol-/application-specific means to extract network-layer information out of the application layer, and will also eventually require your application to do this with native v6 addresses down the line as well (i.e. do a bunch of work now only to have it redo it later). or 2. Just do it properly the first time around. I would opt for #2. -- Hugo On Mon 2015-Jun-01 11:52:15 -0400, Christopher Morrow wrote: >On Mon, Jun 1, 2015 at 11:41 AM, Tony Hain wrote: >> >> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of >>> Christopher Morrow >>> Sent: Monday, June 01, 2015 7:24 AM >>> To: Matt Palmer >>> Cc: nanog list >>> Subject: Re: AWS Elastic IP architecture >>> >>> On Mon, Jun 1, 2015 at 1:19 AM, Matt Palmer >>> wrote: >>> > On Sun, May 31, 2015 at 10:46:02PM -0400, Christopher Morrow wrote: >>> >> So... ok. What does it mean, for a customer of a cloud service, to be >>> >> ipv6 enabled? >>> > >>> > IPv6 feature-parity with IPv4. >>> > >>> > My must-haves, sorted in order of importance (most to least): >>> > >>> >> o Is it most important to be able to terminate ipv6 connections (or >>> >> datagrams) on a VM service for the public to use? >>> >> >>> >>> and would a headerswapping 'proxy' be ok? there's (today) a 'header >>> swapping proxy' doing 'nat' (sort of?) for you, so I imagine that whether the >>> 'headerswapping' is v4 to v4 or v6 to v4 you get the same end effect: >>> "People can see your kitten gifs". >>> >>> >> o Is it most important to be able to address every VM you create with >>> >> an ipv6 address? >>> >>> why is this bit important though? I see folk, I think, get hung up on this, but I >>> can't figure out WHY this is as important as folk seem to want it to be? >>> >>> all the vms have names, you end up using the names not the ips... and thus >>> the underlying ip protocool isn't really important? Today those names >>> translate to v4 public ips, which get 'headerswapped' into v4 private >>> addresses on the way through the firehedge at AWS. Tomorrow they may >>> get swapped from v6 to v4... or there may be v6 endpoints. >>> >>> >> o Is it most important to be able to talk to backend services >>> >> (perhaps at your prem) over ipv6? >>> > >>> > If, by "backend services", you mean things like RDS, S3, etc, this is >>> > in the right place. >>> > >>> >>> I meant 'your oracle financials installation at $HOMEBASE'. Things like >>> 'internal amazon services' to me are a named endpoint and: >>> 1) the name you use could be resolving to something different than the >>> external view >>> 2) it's a name not an ip version... provided you have the inny and it's an >>> outy, I'm not sure that what ip protocol you use on the RESTful request >>> matters a bunch. >>> >>> >> o Is it most important that administrative interfaces to the VM >>> >> systems (either REST/etc interfaces for managing vms or 'ssh'/etc) be >>> >> ipv6 reachable? >>> >> >>> >> I don't see, especially if the vm networking is unique to each >>> >> customer, that 'ipv6 address on vm' is hugely important as a >>> >> first/important goal. I DO see that landing publicly available >>> >> services on an ipv6 endpoint is super helpful. >>> > >>> > Being able to address VMs over IPv6 (and have VMs talk to the outside >>> > world over IPv6) is *really* useful. Takes away the need to NAT anything. >>> >>> but the nat isn't really your concern right (it all happens magically for you)? >>> presuming you can talk to 'backend services' and $HOMEBASE over ipv6 >>> you'd also be able to make connections to other v6 endpoints as well. >>> there's little difference REALLY between v4 and v6 ... and jabbing a >>> connection through a proxy to get v6 endpoints would work 'just fine'. >>> (albeit protocol limitations at the higher levels could be interesting if the >>> connection wasn't just 'swapping headers') >>> >>> >> Would AWS (or any other cloud provider that's not currently up on the >>> >> v6 bandwagon) enabling a loadbalanced ipv6 vip for your public >>> >> service (perhaps not just http/s services even?) be enough to relieve >>> >> some of the pressure on other parties and move the ball forward >>> >> meaningfully enough for the cloud providers and their customers? >>> > >>> > No. I'm currently building an infrastructure which is entirely >>> > v6-native internally; the only parts which are IPv4 are public-facing >>> > incoming service endpoints, and outgoing connections to other parts of >>> > the Internet, which are proxied. Everything else is talking amongst >>> > themselves entirely over IPv6. >>> >>> that's great, but I'm not sure that 'all v6 internally!' matters a whole bunch? I >>> look at aws/etc as "bunch of goo doing >>> computation/calculation/storage/etc" with some public VIP (v4, v6, >>> etc) that are well defined and which are tailored to your userbase's >>> needs/abilities. >>> >>> You don't actually ssh to 'ipv6 literal' or 'ipv4 literal', you ssh to >>> 'superawesome.vm.mine.com' and provide http/s (or whatever) services via >>> 'external-service-name.com'. Whether the 1200 vms in your private network >>> cloud are ipv4 or ipv6 isn't important (really) since they also talk to >>> eachother via names, not literal ip numbers. There isn't NAT that you care >>> about there either, the name/ip translation does the right thing (or should) >>> such that 'superawesome.vm.availzone1.com' and >>> 'superawesome.vm.availzone2.com' can chat freely by name without >>> concerns for underlying ip version numbers used (and even without caring >>> that 'chrissawesome.vm.availzone1.com' is 10.0.0.1 as well. >> >> Look at the problem in the other direction, and you will see that addresses often matter. What if you want to deny ssh connections from a particular address range? > >this sounds like a manage-your-vm question... keep that on v4 only >until native v6 gets to your vm. (short term vs long term solution >space) > > >>The source isn't going to tell you the name it is coming from. What if you want to deploy an MTA on your VM and block connections from SPAM-A-LOT data centers? How do you do that when the header-swap function presents useless crap from an external proxy mapping function? >> > >yup, 'not http' services are harder to deal with in a 'swap headers' world. > >> That said, if you double nat from the vip to the stack in a way that masks the internal transport of the service (so that a native stack on the VM behaves as if it is directly attached to the outside world), then it doesn't matter what the service internal transport is. >> > >I was mostly envisioning this, but the header-swap seems easy for a >bunch of things (to me at least). > >> What I read in your line of comments to Owen is that the service only does a header swap once and expects the application on the VM to compensate. In that case there is an impact on the cost of deployment and overall utility. > >'compensate' ? do you mean 'get some extra information about the real >source address for further policy-type questions to be answered' ? > >I would hope that in the 'header swap' service there's as little >overhead applied to the end system as possible... I'd like my apache >server to answer v6 requests without having a v6 >address-listening-port on my machine. For 'web' stuff >'X-forwarded-for' seems simple, but breaks for https :( > >Oh, so what if the 'header swap' service simply shoveled the v6 into a >gre (or equivalent) tunnel and dropped that on your doorstep? >potentially with an 'apt-get install aws-tunnelservice' ? I would bet >in the 'vm network' you could solve a bunch of this easily enough, and >provide a v6 address inside the tunnel on the vm providing the >services. > >loadbalancing is a bit rougher (more state management) but .. is doable. > >-chris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From maqbool at madbull.info Mon Jun 1 16:28:55 2015 From: maqbool at madbull.info (Maqbool Hashim) Date: Mon, 1 Jun 2015 16:28:55 +0000 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: <556C5E34.5070309@ispn.net>, Message-ID: <1433176135256.33520@madbull.info> First off thanks to everyone that responded to my original post, very instructive and informational replies along with a good view of different perspectives. Baldur, you pointed out that for ingress it's exactly the same to take partials, we are only affected on outbound and we can achieve a large part of the redundancy for outbound also. Someone else pointed out that partitions of the Internet view from our two providers are often lasting minutes rather than hours. Given this input I really lean towards Baldur's statement of we can probably spend the money better elsewhere. One point I will try and make internally is "Do we care about all of the Internet all of the time?", note we are not an ISP. Basically if some part of the Internet in is unreachable for a "short" period will we even notice it? Always if it is one of our remote sites, but of course we can mitigate that by making those part of the partials that we take from both of our providers. By taking full routes I can only see us protecting the view of the whole Internet our internal web browsing clients, after all if a partition to a "busy" part of the Internet happens we will notice it straight away (Google etc.), but if it is someone's iTunes server on the end of some small DSL provider- do we care? One thing I would rather not do which is manage static routes on the BGP routers seems counter intuitive on the face of it. ________________________________________ From: NANOG on behalf of Baldur Norddahl Sent: 01 June 2015 16:49 To: nanog at nanog.org Subject: Re: BGP Multihoming 2 providers full or partial? On 1 June 2015 at 15:29, Blake Hudson wrote: > Something to point out: Sometimes the device you connect to is up, but has > no reachability to the rest of the world. Using static routes is.. well.. > static. There are a few cases (such as the one mentioned) where a static > route can be somewhat dynamic. Another case is when the static route next > hop does not respond to ARP requests or some machines have the ability to > perform triggered actions on some sort of event/test. But why bother with > BGP if you're just going to override its decisions by using static routes? > > As another commenter mentioned, using anything less than a full table is a > compromise. If one wants the redundancy in the case of an upstream ISP > outage, take full routes. If one wants the traffic engineering flexibility, > take full routes and use a BGP knob like route maps to modify existing > prefixes rather than make up your own. A default route of last resort is > fine; Overriding BGP through static routes degrades the utility of BGP. > Thanks for pointing this out. However I would like to argue whether this is a big drawback or not. If the original poster had infinite money and infinite resources there would be no question to ask. Just get the most expensive router out there and get full tables. So given that the money could be spent on other things, that might be more helpful for his company, is it good value to invest in new routers? I believe every company and NOC teams needs to decide this for themselves. I do however feel this is often a rushed decision because people have an idea that anything less than full tables is not good enough and that you are not a real ISP if you do not have full tables etc. It is true that your static routes could end up pointing at a half dead router, that still keeps the link up. But it is also perfectly possible for a router to keep advertising routes, that it really can't forward traffic to or where there are service problems so servere that it amounts to the same (excessive packet loss etc). This is supposed to be rare for a good quality transit provider and the remedy is the same (manually take the link down). We got our big routers and full tables early on. With perfect 20/20 hindsight I am not sure I would spend the money that way if I had to do it over. All I am saying is that you can get most of the value with partial tables. You get 100% of it with ingress traffic and you can move a very large fraction of your egress exactly the same. Your redundancy might not be equal, but it will not be entirely bad. Regards, Baldur From JEdwards at sonifi.com Mon Jun 1 16:29:17 2015 From: JEdwards at sonifi.com (Edwards, Jermaine) Date: Mon, 1 Jun 2015 16:29:17 +0000 Subject: WiFi courses/vendors recommendation In-Reply-To: References: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> Message-ID: <0AA634BD14529B41BB3816DC3D8FD768016F88FE3D@SFCOEX06.lodgenet.com> Wi-Fi is a unique space especially outdoors as it is an unlicensed spectrum. I would suggest looking for an engineer with at least 7 years of field experience along with a strong networking background. The training will only show you how to configure gear and teach perfect world theory. We all know real world isn't that way. Jermaine -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Bensley Sent: Monday, June 01, 2015 04:25 To: nanog at nanog.org Subject: Re: WiFi courses/vendors recommendation On 31 May 2015 at 23:28, James Laszko wrote: > I don't have a vendor-agnostic answer for you on #1, but as far as a vendor - Ruckus Wireless. +1 for Ruckus, I have worked with a Ruckus partner in the UK I can recommend if anyone needs one. The Ruckus tin is great having seen it to believe it. The roaming AP stuff works great. James. From maxtul at netassist.ua Mon Jun 1 16:56:28 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 01 Jun 2015 19:56:28 +0300 Subject: BGP in the Washngton Post In-Reply-To: References: Message-ID: <556C8EBC.7080109@netassist.ua> Is there *IN THEIORY* any possibility to make BGP secure enough now? Yes, RPKI protects from fat fingered people, but NOT protects from people doing hijacks knowlingly. The global routing registry really can be the solution, but it automatically gives one authority a power to cut off any network. Imagine how fast it will be used for censorship. On 01.06.15 16:24, William Herrin wrote: > Interesting story about BGP and security in the Washington Post today: > > http://www.washingtonpost.com/sf/business/2015/05/31/net-of-insecurity-part-2/ > > -Bill > From guillaume at ironie.org Mon Jun 1 06:06:00 2015 From: guillaume at ironie.org (Guillaume Tournat) Date: Mon, 1 Jun 2015 08:06:00 +0200 Subject: WiFi courses/vendors recommendation In-Reply-To: References: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> Message-ID: Fortinet has good products for wifi indoor. Not tested outdoor. > Le 1 juin 2015 ? 00:43, Mike Lyon a ?crit : > > Ubiquiti Networks. > > Its cheap and it works great. Support sucks though. > > I use Ubuquiti gear for my wireless ISP and i use their UniFi APs for when > i do events. > > If you need high density wireless, check out Xirrus Wireless access points, > they are awesome. > > -Mike >> On May 31, 2015 3:30 PM, "James Laszko" wrote: >> >> I don't have a vendor-agnostic answer for you on #1, but as far as a >> vendor - Ruckus Wireless. We are a partner who sells and deploys and the >> stuff is quite awesome for what you're looking for. I'd be happy to >> introduce you to relevant people over there for guidance. >> >> >> Regards, >> >> >> James Laszko >> Mythos Technology Inc >> jamesl at mythostech.com >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Abdullah Medhat >> Sent: Sunday, May 31, 2015 3:07 AM >> To: nanog at nanog.org >> Subject: WiFi courses/vendors recommendation >> >> Good day all, >> >> We are looking forward to establish MetroWifi network as a new business >> line in our company, in addition to small/medium events Wifi coverage. >> >> I have two questions: >> 1. What are the required resources/material/training curriculum to let our >> engineers start educating in this? We are looking for the vendor-agnostic >> materials that will give our engineers the WiFi essentials/fundamentals to >> start building a good foundation before evolving to the professional level. >> >> 2. What vendors do you recommend? We need to find a cost-effective yet >> competent option with good pre/post sales service. >> >> Thanks, >> >> -- >> >> Abdullah Medhat >> From alh-ietf at tndh.net Mon Jun 1 17:18:11 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 1 Jun 2015 10:18:11 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601051900.GV724@hezmatt.org> <07b701d09c81$6508bc90$2f1a35b0$@tndh.net> Message-ID: <07c201d09c8e$f0309830$d091c890$@tndh.net> >>> snip > > What I read in your line of comments to Owen is that the service only does > a header swap once and expects the application on the VM to compensate. > In that case there is an impact on the cost of deployment and overall utility. > > 'compensate' ? do you mean 'get some extra information about the real > source address for further policy-type questions to be answered' ? Yes. Since that is not a required step on a native machine, there would be development / extra configuration required. While people that are interested in IPv6 deployment would likely do the extra work, those who "just want it to work" would delay IPv6 services until someone created the magic. Unfortunately that describes most of the people that use hosted services, so external proxy / nat approaches really do nothing to further any use of IPv6. > > I would hope that in the 'header swap' service there's as little overhead > applied to the end system as possible... I'd like my apache server to answer > v6 requests without having a v6 address-listening-port on my machine. For > 'web' stuff 'X-forwarded-for' seems simple, but breaks for https :( So to avoid the exceedingly simple config change of "Listen 80" rather than "Listen x.x.x.x:80" you would rather not open the IPv6 port? If the service internal transport is really transparent, https would work for free. I don't have any data to base it on, but I always thought that scaling an e-commerce site was the primary utility in using a hosted VM service. If that is true, it makes absolutely no sense to do a proxy VIP thingy for IPv6 port 80 to fill the cart, then fail the connection when trying to check-out. As IPv4 becomes more fragile with the additional layering of nats, the likelihood of that situation goes up, causing even more people to want to turn off the IPv6 vip. It is better for the service to appear to be down at the start than to have customers spend time then fail at the point of gratification, because they are much more likely to forget about an apparent service outage than to forgive wasting their time. > > Oh, so what if the 'header swap' service simply shoveled the v6 into a gre > (or equivalent) tunnel and dropped that on your doorstep? > potentially with an 'apt-get install aws-tunnelservice' ? I would bet in the > 'vm network' you could solve a bunch of this easily enough, and provide a v6 > address inside the tunnel on the vm providing the services. > > loadbalancing is a bit rougher (more state management) but .. is doable. I think tunneling would be more efficient and manageable overall. I have not thought through the trade-offs between terminating it on the host vs inside the VM, but gut feel says that for the end-user / application it might be better inside the vm so there is a clean interface, while for service manageability it would be better on the host, even though some information might get lost in the interface translation. As long as the IP header that the VM stack presents to the application is the same as the one presented to the vip (applies outbound as well), the rest is a design detail that is best left to each organization. Tony From morrowc.lists at gmail.com Mon Jun 1 17:20:57 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Jun 2015 13:20:57 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <20150601162144.GJ4389@bamboo.slabnet.com> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601051900.GV724@hezmatt.org> <07b701d09c81$6508bc90$2f1a35b0$@tndh.net> <20150601162144.GJ4389@bamboo.slabnet.com> Message-ID: On Mon, Jun 1, 2015 at 12:21 PM, Hugo Slabbert wrote: > 2. Just do it properly the first time around. > > I would opt for #2. sure, so would everyone... but they didn't so... what gets you enough there to help customers and also doesn't required a forklift of your running operation? From hugo at slabnet.com Mon Jun 1 17:23:47 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 1 Jun 2015 10:23:47 -0700 Subject: WiFi courses/vendors recommendation In-Reply-To: References: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> Message-ID: <20150601172347.GK4389@bamboo.slabnet.com> Doubt how much PoE you'd use for the MetroWifi stuff, but for the "small/medium events Wifi coverage": >> Ubiquiti Networks. >> >> Its cheap and it works great. Support sucks though. Just watch it here if you're expecting to plug UniFi APs into standard 802.3af/at ports and get power. When I last interacted with them (customer equipment; year or two old, I believe) a lot of their WAPs are 24V, not 802.3af/at. -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From josh at spitwspots.com Mon Jun 1 17:25:40 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Mon, 01 Jun 2015 09:25:40 -0800 Subject: WiFi courses/vendors recommendation In-Reply-To: <0AA634BD14529B41BB3816DC3D8FD768016F88FE3D@SFCOEX06.lodgenet.com> References: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> <0AA634BD14529B41BB3816DC3D8FD768016F88FE3D@SFCOEX06.lodgenet.com> Message-ID: <556C9594.1000606@spitwspots.com> That "7 year" requirement is the most off the wall statement. Do you work in HR? :) How about "find somebody with experience, ideally somebody who's done high-level work for a W/ISP". Josh Reynolds CIO, SPITwSPOTS www.spitwspots.com On 06/01/2015 08:29 AM, Edwards, Jermaine wrote: > Wi-Fi is a unique space especially outdoors as it is an unlicensed spectrum. I would suggest looking for an engineer with at least 7 years of field experience along with a strong networking background. The training will only show you how to configure gear and teach perfect world theory. We all know real world isn't that way. > > Jermaine > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of James Bensley > Sent: Monday, June 01, 2015 04:25 > To: nanog at nanog.org > Subject: Re: WiFi courses/vendors recommendation > > On 31 May 2015 at 23:28, James Laszko wrote: >> I don't have a vendor-agnostic answer for you on #1, but as far as a vendor - Ruckus Wireless. > +1 for Ruckus, I have worked with a Ruckus partner in the UK I can > recommend if anyone needs one. The Ruckus tin is great having seen it to believe it. The roaming AP stuff works great. > > James. From josh at spitwspots.com Mon Jun 1 17:31:56 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Mon, 01 Jun 2015 09:31:56 -0800 Subject: WiFi courses/vendors recommendation In-Reply-To: <20150601172347.GK4389@bamboo.slabnet.com> References: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> <20150601172347.GK4389@bamboo.slabnet.com> Message-ID: <556C970C.1050302@spitwspots.com> They come from the outdoor WISP space, so most of their gear is 24v passive POE. However, they have multiple models of 802.3at/af switches now (up to 48 port), two routers with 24v/48v PoE output capability, and several UniFi APs that are either 802.3af or 802.3at. Josh Reynolds CIO, SPITwSPOTS www.spitwspots.com On 06/01/2015 09:23 AM, Hugo Slabbert wrote: > Doubt how much PoE you'd use for the MetroWifi stuff, but for the > "small/medium events Wifi coverage": > >>> Ubiquiti Networks. >>> >>> Its cheap and it works great. Support sucks though. > > Just watch it here if you're expecting to plug UniFi APs into standard > 802.3af/at ports and get power. When I last interacted with them > (customer equipment; year or two old, I believe) a lot of their WAPs > are 24V, not 802.3af/at. > From frnog at shrd.fr Mon Jun 1 17:30:45 2015 From: frnog at shrd.fr (Michel Luczak) Date: Mon, 1 Jun 2015 19:30:45 +0200 Subject: WiFi courses/vendors recommendation In-Reply-To: <20150601172347.GK4389@bamboo.slabnet.com> References: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> <20150601172347.GK4389@bamboo.slabnet.com> Message-ID: > > Just watch it here if you're expecting to plug UniFi APs into standard 802.3af/at ports and get power. When I last interacted with them (customer equipment; year or two old, I believe) a lot of their WAPs are 24V, not 802.3af/at. The Pro and AC models are 802af/at. Only the ?not Pro? (2.4 GHz only) model is passive 24V PoE but anyway it?s sh*t and not usable for any serious application. BR, Michel Luczak From matthew at matthew.at Mon Jun 1 17:49:09 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 01 Jun 2015 10:49:09 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> Message-ID: <556C9B15.7010403@matthew.at> On 6/1/2015 12:06 AM, Owen DeLong wrote: > ... Here?s the thing? In order to land IPv6 services without IPv6 > support on the VM, you?re creating an environment where... Let's hypothetically say that it is much easier for the cloud provider if they provide just a single choice within their network, but allow both v4 and v6 access from the outside via a translator (to whichever one isn't native internally). Would you rather have: 1) An all-IPv6 network inside, so the hosts can all talk to each other over IPv6 without using (potentially overlapping copies of) RFC1918 space... but where very little of the open-source software you build your services on works at all, because it either doesn't support IPv6 or they put some IPv6 support in but it is always lagging behind and the bugs don't get fixed in a timely manner. Or, 2) An all-IPv4 network inside, with the annoying (but well-known) use of RFC1918 IPv4 space and all your software stacks just work as they always have, only now the fraction of users who have IPv6 can reach them over IPv6 if they so choose (despite the connectivity often being worse than the IPv4 path) and the 2 people who are on IPv6-only networks can reach your services too. Until all of the common stacks that people build upon, including distributed databases, cache layers, web accelerators, etc. all work *better* when the native environment is IPv6, everyone will be choosing #2. And both #1 and #2 are cheaper and easier to manage that full dual-stack to every single host (because you pay all the cost of supporting v6 everywhere with none of the savings of not having to deal with the ever-increasing complexity of continuing to use v4) Matthew Kaufman From cb.list6 at gmail.com Mon Jun 1 18:36:47 2015 From: cb.list6 at gmail.com (Ca By) Date: Mon, 1 Jun 2015 11:36:47 -0700 Subject: AWS Elastic IP architecture In-Reply-To: <556C9B15.7010403@matthew.at> References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> Message-ID: On Mon, Jun 1, 2015 at 10:49 AM, Matthew Kaufman wrote: > On 6/1/2015 12:06 AM, Owen DeLong wrote: > >> ... Here?s the thing? In order to land IPv6 services without IPv6 support >> on the VM, you?re creating an environment where... >> > > Let's hypothetically say that it is much easier for the cloud provider if > they provide just a single choice within their network, but allow both v4 > and v6 access from the outside via a translator (to whichever one isn't > native internally). > > Would you rather have: > 1) An all-IPv6 network inside, so the hosts can all talk to each other > over IPv6 without using (potentially overlapping copies of) RFC1918 > space... but where very little of the open-source software you build your > services on works at all, because it either doesn't support IPv6 or they > put some IPv6 support in but it is always lagging behind and the bugs don't > get fixed in a timely manner. Or, > Facebook selected IPv6-only as outlined above http://blog.ipspace.net/2014/03/facebook-is-close-to-having-ipv6-only.html > > 2) An all-IPv4 network inside, with the annoying (but well-known) use of > RFC1918 IPv4 space and all your software stacks just work as they always > have, only now the fraction of users who have IPv6 can reach them over IPv6 > if they so choose (despite the connectivity often being worse than the IPv4 > path) and the 2 people who are on IPv6-only networks can reach your > services too. > > Until all of the common stacks that people build upon, including > distributed databases, cache layers, web accelerators, etc. all work > *better* when the native environment is IPv6, everyone will be choosing #2. > > And both #1 and #2 are cheaper and easier to manage that full dual-stack > to every single host (because you pay all the cost of supporting v6 > everywhere with none of the savings of not having to deal with the > ever-increasing complexity of continuing to use v4) > > Matthew Kaufman > > From blake at ispn.net Mon Jun 1 18:40:56 2015 From: blake at ispn.net (Blake Hudson) Date: Mon, 01 Jun 2015 13:40:56 -0500 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: <1433176135256.33520@madbull.info> References: <556C5E34.5070309@ispn.net>, <1433176135256.33520@madbull.info> Message-ID: <556CA738.5040304@ispn.net> A gateway of last resort, also called a backup default route, will take care of partitions and is, in my opinion, a good idea if you are not providing transit to others. It's a requirement if you're not taking full routes, but even if you do take full routes the management cost is practically nill. The practical problem with with using static routes (or a locally generated default route only BGP feed) for egress route selection is when your upstream providers perform maintenance or have an outages. When this occurs, you'll likely be impacted during the duration of the event. This may be 5 minutes, it may be hours. What are the track records for your upstream ISPs? Is having two ISPs doubling your downtime, and is this the desired outcome? If you can't send traffic out to half of the internet for an hour is that OK? At midnight? At noon? --Blake Maqbool Hashim wrote on 6/1/2015 11:28 AM: > First off thanks to everyone that responded to my original post, very instructive and informational replies along with a good view of different perspectives. > > Baldur, you pointed out that for ingress it's exactly the same to take partials, we are only affected on outbound and we can achieve a large part of the redundancy for outbound also. Someone else pointed out that partitions of the Internet view from our two providers are often lasting minutes rather than hours. Given this input I really lean towards Baldur's statement of we can probably spend the money better elsewhere. > > One point I will try and make internally is "Do we care about all of the Internet all of the time?", note we are not an ISP. Basically if some part of the Internet in is unreachable for a "short" period will we even notice it? Always if it is one of our remote sites, but of course we can mitigate that by making those part of the partials that we take from both of our providers. > > By taking full routes I can only see us protecting the view of the whole Internet our internal web browsing clients, after all if a partition to a "busy" part of the Internet happens we will notice it straight away (Google etc.), but if it is someone's iTunes server on the end of some small DSL provider- do we care? > > One thing I would rather not do which is manage static routes on the BGP routers seems counter intuitive on the face of it. > > ________________________________________ > From: NANOG on behalf of Baldur Norddahl > Sent: 01 June 2015 16:49 > To: nanog at nanog.org > Subject: Re: BGP Multihoming 2 providers full or partial? > > On 1 June 2015 at 15:29, Blake Hudson wrote: > >> Something to point out: Sometimes the device you connect to is up, but has >> no reachability to the rest of the world. Using static routes is.. well.. >> static. There are a few cases (such as the one mentioned) where a static >> route can be somewhat dynamic. Another case is when the static route next >> hop does not respond to ARP requests or some machines have the ability to >> perform triggered actions on some sort of event/test. But why bother with >> BGP if you're just going to override its decisions by using static routes? >> >> As another commenter mentioned, using anything less than a full table is a >> compromise. If one wants the redundancy in the case of an upstream ISP >> outage, take full routes. If one wants the traffic engineering flexibility, >> take full routes and use a BGP knob like route maps to modify existing >> prefixes rather than make up your own. A default route of last resort is >> fine; Overriding BGP through static routes degrades the utility of BGP. >> > Thanks for pointing this out. However I would like to argue whether this is > a big drawback or not. > > If the original poster had infinite money and infinite resources there > would be no question to ask. Just get the most expensive router out there > and get full tables. > > So given that the money could be spent on other things, that might be more > helpful for his company, is it good value to invest in new routers? I > believe every company and NOC teams needs to decide this for themselves. I > do however feel this is often a rushed decision because people have an idea > that anything less than full tables is not good enough and that you are not > a real ISP if you do not have full tables etc. > > It is true that your static routes could end up pointing at a half dead > router, that still keeps the link up. But it is also perfectly possible for > a router to keep advertising routes, that it really can't forward traffic > to or where there are service problems so servere that it amounts to the > same (excessive packet loss etc). This is supposed to be rare for a good > quality transit provider and the remedy is the same (manually take the link > down). > > We got our big routers and full tables early on. With perfect 20/20 > hindsight I am not sure I would spend the money that way if I had to do it > over. > > All I am saying is that you can get most of the value with partial tables. > You get 100% of it with ingress traffic and you can move a very large > fraction of your egress exactly the same. Your redundancy might not be > equal, but it will not be entirely bad. > > Regards, > > Baldur From toddunder at gmail.com Mon Jun 1 18:43:27 2015 From: toddunder at gmail.com (Todd Underwood) Date: Mon, 1 Jun 2015 14:43:27 -0400 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> Message-ID: fb is not a 'cloud provider'. it's orthogonal to the question. t On Mon, Jun 1, 2015 at 2:36 PM, Ca By wrote: > On Mon, Jun 1, 2015 at 10:49 AM, Matthew Kaufman > wrote: > > > On 6/1/2015 12:06 AM, Owen DeLong wrote: > > > >> ... Here?s the thing? In order to land IPv6 services without IPv6 > support > >> on the VM, you?re creating an environment where... > >> > > > > Let's hypothetically say that it is much easier for the cloud provider if > > they provide just a single choice within their network, but allow both v4 > > and v6 access from the outside via a translator (to whichever one isn't > > native internally). > > > > Would you rather have: > > 1) An all-IPv6 network inside, so the hosts can all talk to each other > > over IPv6 without using (potentially overlapping copies of) RFC1918 > > space... but where very little of the open-source software you build your > > services on works at all, because it either doesn't support IPv6 or they > > put some IPv6 support in but it is always lagging behind and the bugs > don't > > get fixed in a timely manner. Or, > > > > > Facebook selected IPv6-only as outlined above > > http://blog.ipspace.net/2014/03/facebook-is-close-to-having-ipv6-only.html > > > > > > 2) An all-IPv4 network inside, with the annoying (but well-known) use of > > RFC1918 IPv4 space and all your software stacks just work as they always > > have, only now the fraction of users who have IPv6 can reach them over > IPv6 > > if they so choose (despite the connectivity often being worse than the > IPv4 > > path) and the 2 people who are on IPv6-only networks can reach your > > services too. > > > > Until all of the common stacks that people build upon, including > > distributed databases, cache layers, web accelerators, etc. all work > > *better* when the native environment is IPv6, everyone will be choosing > #2. > > > > And both #1 and #2 are cheaper and easier to manage that full dual-stack > > to every single host (because you pay all the cost of supporting v6 > > everywhere with none of the savings of not having to deal with the > > ever-increasing complexity of continuing to use v4) > > > > Matthew Kaufman > > > > > From dave.taht at gmail.com Mon Jun 1 18:52:41 2015 From: dave.taht at gmail.com (Dave Taht) Date: Mon, 1 Jun 2015 11:52:41 -0700 Subject: 300+ms of hotel wifi bufferbloat - peaking at 1.5 sec! In-Reply-To: <556A6B19.8090309@gatech.edu> References: <6D5BCABB-AD36-415F-8B8E-D0287F5B0785@gmail.com> <556A6B19.8090309@gatech.edu> Message-ID: I did the dslreports tests on the NANOG wifi while listening to srikanth today: http://www.dslreports.com/speedtest/593926 And my own (flent data also in this dir)... http://snapon.lab.bufferbloat.net/~d/nanog/download_cdf.png pretty good bandwidth. Pretty horrific latency... a couple detours around the moon. On Sat, May 30, 2015 at 6:59 PM, Srikanth Sundaresan wrote: > While I agree that upload speeds aren't great, it doesn't mean that the > buffers aren't big. Buffer sizes of the order of MB's are uncalled for at > the edge, unless we're talking really high speeds. The miniscule performance > increase for single TCP flows doesn't really justify the potential increase > in latency for everyone else. > > > On 5/30/15 6:25 PM, Steven Tardy wrote: >> >> There's a corollary of the bufferbloat phenomenon: buffer drain time. It's >> not the size of the buffer, but how long it takes to empty. And US ISPs >> continue to say "customers don't want upload speed". >> If the ISP upload speed was symmetric you'd likely never notice the 1-2MB >> of buffers. >> >> I guess what I'm getting at is why do you continue to say buffers are too >> big instead of saying ISP upload is too slow? >> >> >>> On May 30, 2015, at 1:50 PM, Dave Taht wrote: >>> >>> http://www.dslreports.com/speedtest/578850 >>> >>> I would get a kick out of it if folk here tried this new speedtest >>> periodically (on the "cable" setting) during the nanog conference. ;) >>> There is a hires option for more detail on the resulting charts... >>> >>> (or fiddled with "flent" (flent.org)) >>> >>> -- >>> Dave T?ht >>> What will it take to vastly improve wifi for everyone? >>> https://plus.google.com/u/0/explore/makewififast -- Dave T?ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From josh at spitwspots.com Mon Jun 1 18:58:26 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Mon, 01 Jun 2015 10:58:26 -0800 Subject: 300+ms of hotel wifi bufferbloat - peaking at 1.5 sec! In-Reply-To: References: <6D5BCABB-AD36-415F-8B8E-D0287F5B0785@gmail.com> <556A6B19.8090309@gatech.edu> Message-ID: <556CAB52.909@spitwspots.com> There's a bit of discussion on the AFMUG list about that speed test Dave. People with 500Mb, 1Gb,10Gb pipes were getting drastically different results depending on what "type" of test they did. Josh Reynolds CIO, SPITwSPOTS www.spitwspots.com On 06/01/2015 10:52 AM, Dave Taht wrote: > I did the dslreports tests on the NANOG wifi while listening to srikanth today: > > http://www.dslreports.com/speedtest/593926 > > And my own (flent data also in this dir)... > > http://snapon.lab.bufferbloat.net/~d/nanog/download_cdf.png > > pretty good bandwidth. Pretty horrific latency... a couple detours > around the moon. > > > On Sat, May 30, 2015 at 6:59 PM, Srikanth Sundaresan > wrote: >> While I agree that upload speeds aren't great, it doesn't mean that the >> buffers aren't big. Buffer sizes of the order of MB's are uncalled for at >> the edge, unless we're talking really high speeds. The miniscule performance >> increase for single TCP flows doesn't really justify the potential increase >> in latency for everyone else. >> >> >> On 5/30/15 6:25 PM, Steven Tardy wrote: >>> There's a corollary of the bufferbloat phenomenon: buffer drain time. It's >>> not the size of the buffer, but how long it takes to empty. And US ISPs >>> continue to say "customers don't want upload speed". >>> If the ISP upload speed was symmetric you'd likely never notice the 1-2MB >>> of buffers. >>> >>> I guess what I'm getting at is why do you continue to say buffers are too >>> big instead of saying ISP upload is too slow? >>> >>> >>>> On May 30, 2015, at 1:50 PM, Dave Taht wrote: >>>> >>>> http://www.dslreports.com/speedtest/578850 >>>> >>>> I would get a kick out of it if folk here tried this new speedtest >>>> periodically (on the "cable" setting) during the nanog conference. ;) >>>> There is a hires option for more detail on the resulting charts... >>>> >>>> (or fiddled with "flent" (flent.org)) >>>> >>>> -- >>>> Dave T?ht >>>> What will it take to vastly improve wifi for everyone? >>>> https://plus.google.com/u/0/explore/makewififast > > From lnguyen at opsource.net Mon Jun 1 19:11:13 2015 From: lnguyen at opsource.net (Luan Nguyen) Date: Mon, 1 Jun 2015 15:11:13 -0400 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com><20150531091820.GQ724@hezmatt.org><8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com><556C9B15.7010403@matthew.at> Message-ID: Original I asked because was in the process of thinking out loud what options are there for disaster recovery. I could do anycast BGP, advertise out say a /24 of "elastic IP" and internally have that block running inside our data center interconnect dmvpn tunnels. We do have WAN OPT so it probably will be faster running inside the tunnel - not sure what impact it might have on some applications though. so if a vm moves, i need to generate 2 host routes - public and private ipv4, so those can be the same - some customers have vpn/direct connect so they also need to get to the private ipv4 as well the public one...it could get to be a pain to manage. Dimension Data Cloud does have dual stack for cloud VM. Personally i like IPv6 since it's so much easier to plan around...Customers can bring their own ipv4 address to the cloud, the ipv6 is unique - so if you don't want to nat your private ipv4, you could just use ipv6. Our orchestration tools are dual stack as well...making a rest api call with python to ipv6 is as easy as ipv4. IPv6 makes a big different for us to monitor customer VMs though...since they can bring their own ipv4 and might overlap. Honestly, I don't think people care much about ipv6 yet, but hey, we just dual stack for the future so hey if you want to load balancing ipv6 to either ipv6 or ipv4 real servers, knock yourself out, and for marketing as well...AWS doesn't do it, but we do and with the intercloud solution from cisco - moving from aws to didata would be just a click away :) On Mon, Jun 1, 2015 at 2:43 PM, Todd Underwood wrote: > fb is not a 'cloud provider'. > > it's orthogonal to the question. > > t > > On Mon, Jun 1, 2015 at 2:36 PM, Ca By wrote: > > > On Mon, Jun 1, 2015 at 10:49 AM, Matthew Kaufman > > wrote: > > > > > On 6/1/2015 12:06 AM, Owen DeLong wrote: > > > > > >> ... Here?s the thing? In order to land IPv6 services without IPv6 > > support > > >> on the VM, you?re creating an environment where... > > >> > > > > > > Let's hypothetically say that it is much easier for the cloud provider > if > > > they provide just a single choice within their network, but allow both > v4 > > > and v6 access from the outside via a translator (to whichever one isn't > > > native internally). > > > > > > Would you rather have: > > > 1) An all-IPv6 network inside, so the hosts can all talk to each other > > > over IPv6 without using (potentially overlapping copies of) RFC1918 > > > space... but where very little of the open-source software you build > your > > > services on works at all, because it either doesn't support IPv6 or > they > > > put some IPv6 support in but it is always lagging behind and the bugs > > don't > > > get fixed in a timely manner. Or, > > > > > > > > > Facebook selected IPv6-only as outlined above > > > > > http://blog.ipspace.net/2014/03/facebook-is-close-to-having-ipv6-only.html > > > > > > > > > > 2) An all-IPv4 network inside, with the annoying (but well-known) use > of > > > RFC1918 IPv4 space and all your software stacks just work as they > always > > > have, only now the fraction of users who have IPv6 can reach them over > > IPv6 > > > if they so choose (despite the connectivity often being worse than the > > IPv4 > > > path) and the 2 people who are on IPv6-only networks can reach your > > > services too. > > > > > > Until all of the common stacks that people build upon, including > > > distributed databases, cache layers, web accelerators, etc. all work > > > *better* when the native environment is IPv6, everyone will be choosing > > #2. > > > > > > And both #1 and #2 are cheaper and easier to manage that full > dual-stack > > > to every single host (because you pay all the cost of supporting v6 > > > everywhere with none of the savings of not having to deal with the > > > ever-increasing complexity of continuing to use v4) > > > > > > Matthew Kaufman > > > > > > > > > From morrowc.lists at gmail.com Mon Jun 1 19:12:03 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Jun 2015 15:12:03 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <556C9B15.7010403@matthew.at> References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> Message-ID: On Mon, Jun 1, 2015 at 1:49 PM, Matthew Kaufman wrote: > 1) An all-IPv6 network inside, so the hosts can all talk to each other over > IPv6 without using (potentially overlapping copies of) RFC1918 space... this point keeps coming up... I don't see that 'overlapping ipv4' matters at all here. it is presented to the customer (vm oeprator) as 'a flat-ish lan' where you poke from machine to machine via names. (so it seems like a rathole/FUD-problem we can just stop talking about now) -chris From matthew at matthew.at Mon Jun 1 19:34:04 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 01 Jun 2015 12:34:04 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> Message-ID: <556CB3AC.8090701@matthew.at> On 6/1/2015 12:12 PM, Christopher Morrow wrote: > On Mon, Jun 1, 2015 at 1:49 PM, Matthew Kaufman wrote: >> 1) An all-IPv6 network inside, so the hosts can all talk to each other over >> IPv6 without using (potentially overlapping copies of) RFC1918 space... > > this point keeps coming up... I don't see that 'overlapping ipv4' > matters at all here. it is presented to the customer (vm oeprator) as > 'a flat-ish lan' where you poke from machine to machine via names. > > (so it seems like a rathole/FUD-problem we can just stop talking about now) > > -chris I have deployed services in clouds where the overlapping RFC1918 space did present challenges to the software stack that was trying to exchange node reachability as IP/port. So yes, there were and still are cases where existing software that is not aware of potential overlapped assignments can break. Matthew Kaufman From dave.taht at gmail.com Mon Jun 1 20:15:23 2015 From: dave.taht at gmail.com (Dave Taht) Date: Mon, 1 Jun 2015 13:15:23 -0700 Subject: 300+ms of hotel wifi bufferbloat - peaking at 1.5 sec! In-Reply-To: <556CAB52.909@spitwspots.com> References: <6D5BCABB-AD36-415F-8B8E-D0287F5B0785@gmail.com> <556A6B19.8090309@gatech.edu> <556CAB52.909@spitwspots.com> Message-ID: On Mon, Jun 1, 2015 at 11:58 AM, Josh Reynolds wrote: > There's a bit of discussion on the AFMUG list about that speed test Dave. > People with 500Mb, 1Gb,10Gb pipes were getting drastically different results > depending on what "type" of test they did. There were also huge discussions of the dslreports testing ideas on the bufferbloat "bloat" list. Along the way we came up with some ideas and recommendations, which we piled into a document here (comments welcomed!) https://docs.google.com/document/d/1z5NN4WRKQKK-RtxtKR__XIwkybvsKEmunek2Ezdw_90/edit I would like it very much if the currently named "fiber,cable,dsl, etc" options in the dslreports test were renamed something like "insane, extreme, medium, low" and let users call out a wifi or wireless test vs A big flaw in it as structured is that it first tests how robust a network is to lots of flows in slow start in the early stages of the test. The median idea = a grade needs work, also. But see above doc and comment, please. Also I have never trusted a browser to be able to drive tests like this sanely, but I was pretty satisfied that the results I was getting on the hardware I had (up to about 120Mbit) matched realities I could also measure with the "flent.org" (formerly netperf-wrapper) tool. thx for the steer to testers at higher rates. Still, I would trust flent a LOT further than a browser at speeds higher than that. It has been tested with reasonable results up to 40gigE. > > Josh Reynolds > CIO, SPITwSPOTS > www.spitwspots.com > > > On 06/01/2015 10:52 AM, Dave Taht wrote: >> >> I did the dslreports tests on the NANOG wifi while listening to srikanth >> today: >> >> http://www.dslreports.com/speedtest/593926 >> >> And my own (flent data also in this dir)... >> >> http://snapon.lab.bufferbloat.net/~d/nanog/download_cdf.png >> >> pretty good bandwidth. Pretty horrific latency... a couple detours >> around the moon. >> >> >> On Sat, May 30, 2015 at 6:59 PM, Srikanth Sundaresan >> wrote: >>> >>> While I agree that upload speeds aren't great, it doesn't mean that the >>> buffers aren't big. Buffer sizes of the order of MB's are uncalled for at >>> the edge, unless we're talking really high speeds. The miniscule >>> performance >>> increase for single TCP flows doesn't really justify the potential >>> increase >>> in latency for everyone else. >>> >>> >>> On 5/30/15 6:25 PM, Steven Tardy wrote: >>>> >>>> There's a corollary of the bufferbloat phenomenon: buffer drain time. >>>> It's >>>> not the size of the buffer, but how long it takes to empty. And US ISPs >>>> continue to say "customers don't want upload speed". >>>> If the ISP upload speed was symmetric you'd likely never notice the >>>> 1-2MB >>>> of buffers. >>>> >>>> I guess what I'm getting at is why do you continue to say buffers are >>>> too >>>> big instead of saying ISP upload is too slow? >>>> >>>> >>>>> On May 30, 2015, at 1:50 PM, Dave Taht wrote: >>>>> >>>>> http://www.dslreports.com/speedtest/578850 >>>>> >>>>> I would get a kick out of it if folk here tried this new speedtest >>>>> periodically (on the "cable" setting) during the nanog conference. ;) >>>>> There is a hires option for more detail on the resulting charts... >>>>> >>>>> (or fiddled with "flent" (flent.org)) >>>>> >>>>> -- >>>>> Dave T?ht >>>>> What will it take to vastly improve wifi for everyone? >>>>> https://plus.google.com/u/0/explore/makewififast >> >> >> > -- Dave T?ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From jeremy at vcn.com Mon Jun 1 20:17:25 2015 From: jeremy at vcn.com (Jeremy Malli) Date: Mon, 01 Jun 2015 13:17:25 -0700 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: <556CA738.5040304@ispn.net> References: <556C5E34.5070309@ispn.net>, <1433176135256.33520@madbull.info> <556CA738.5040304@ispn.net> Message-ID: <556CBDD5.7090405@vcn.com> You could have your transit providers send you a default route in the BGP session instead of nailing it up using a static. That way if the interface does not physically go down but the BGP session does, the default route will be pulled when the BGP session dies. Also, you could go with a less expensive router that will handle full routes such as the Mikrotik CCR's ( http://routerboard.com/CCR1036-8G-2SplusEM ). Get one for each of your transit providers. People have varying experiences with Mikrotik however for basic use they seem to work well. Jeremy Malli jeremy at vcn.com On 6/1/2015 11:40 AM, Blake Hudson wrote: > A gateway of last resort, also called a backup default route, will take > care of partitions and is, in my opinion, a good idea if you are not > providing transit to others. It's a requirement if you're not taking > full routes, but even if you do take full routes the management cost is > practically nill. > > The practical problem with with using static routes (or a locally > generated default route only BGP feed) for egress route selection is > when your upstream providers perform maintenance or have an outages. > When this occurs, you'll likely be impacted during the duration of the > event. This may be 5 minutes, it may be hours. What are the track > records for your upstream ISPs? Is having two ISPs doubling your > downtime, and is this the desired outcome? If you can't send traffic out > to half of the internet for an hour is that OK? At midnight? At noon? > > --Blake > > Maqbool Hashim wrote on 6/1/2015 11:28 AM: >> First off thanks to everyone that responded to my original post, very >> instructive and informational replies along with a good view of >> different perspectives. >> >> Baldur, you pointed out that for ingress it's exactly the same to take >> partials, we are only affected on outbound and we can achieve a large >> part of the redundancy for outbound also. Someone else pointed out >> that partitions of the Internet view from our two providers are often >> lasting minutes rather than hours. Given this input I really lean >> towards Baldur's statement of we can probably spend the money better >> elsewhere. >> >> One point I will try and make internally is "Do we care about all of >> the Internet all of the time?", note we are not an ISP. Basically if >> some part of the Internet in is unreachable for a "short" period will >> we even notice it? Always if it is one of our remote sites, but of >> course we can mitigate that by making those part of the partials that >> we take from both of our providers. >> >> By taking full routes I can only see us protecting the view of the >> whole Internet our internal web browsing clients, after all if a >> partition to a "busy" part of the Internet happens we will notice it >> straight away (Google etc.), but if it is someone's iTunes server on >> the end of some small DSL provider- do we care? >> >> One thing I would rather not do which is manage static routes on the >> BGP routers seems counter intuitive on the face of it. >> >> ________________________________________ >> From: NANOG on behalf of Baldur Norddahl >> >> Sent: 01 June 2015 16:49 >> To: nanog at nanog.org >> Subject: Re: BGP Multihoming 2 providers full or partial? >> >> On 1 June 2015 at 15:29, Blake Hudson wrote: >> >>> Something to point out: Sometimes the device you connect to is up, >>> but has >>> no reachability to the rest of the world. Using static routes is.. >>> well.. >>> static. There are a few cases (such as the one mentioned) where a static >>> route can be somewhat dynamic. Another case is when the static route >>> next >>> hop does not respond to ARP requests or some machines have the >>> ability to >>> perform triggered actions on some sort of event/test. But why bother >>> with >>> BGP if you're just going to override its decisions by using static >>> routes? >>> >>> As another commenter mentioned, using anything less than a full table >>> is a >>> compromise. If one wants the redundancy in the case of an upstream ISP >>> outage, take full routes. If one wants the traffic engineering >>> flexibility, >>> take full routes and use a BGP knob like route maps to modify existing >>> prefixes rather than make up your own. A default route of last resort is >>> fine; Overriding BGP through static routes degrades the utility of BGP. >>> >> Thanks for pointing this out. However I would like to argue whether >> this is >> a big drawback or not. >> >> If the original poster had infinite money and infinite resources there >> would be no question to ask. Just get the most expensive router out there >> and get full tables. >> >> So given that the money could be spent on other things, that might be >> more >> helpful for his company, is it good value to invest in new routers? I >> believe every company and NOC teams needs to decide this for >> themselves. I >> do however feel this is often a rushed decision because people have an >> idea >> that anything less than full tables is not good enough and that you >> are not >> a real ISP if you do not have full tables etc. >> >> It is true that your static routes could end up pointing at a half dead >> router, that still keeps the link up. But it is also perfectly >> possible for >> a router to keep advertising routes, that it really can't forward traffic >> to or where there are service problems so servere that it amounts to the >> same (excessive packet loss etc). This is supposed to be rare for a good >> quality transit provider and the remedy is the same (manually take the >> link >> down). >> >> We got our big routers and full tables early on. With perfect 20/20 >> hindsight I am not sure I would spend the money that way if I had to >> do it >> over. >> >> All I am saying is that you can get most of the value with partial >> tables. >> You get 100% of it with ingress traffic and you can move a very large >> fraction of your egress exactly the same. Your redundancy might not be >> equal, but it will not be entirely bad. >> >> Regards, >> >> Baldur > From blair.trosper at gmail.com Mon Jun 1 20:19:56 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Mon, 1 Jun 2015 15:19:56 -0500 Subject: Suddenlink RWHOIS = down Message-ID: Can someone from Suddenlink contact me offlist (or just handle) for the fact that your rwhois server is offline? Found a referral to rwhois.suddenlink.net:4321. connect: Connection refused From Lee at asgard.org Mon Jun 1 20:25:06 2015 From: Lee at asgard.org (Lee Howard) Date: Mon, 01 Jun 2015 16:25:06 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <556C9B15.7010403@matthew.at> References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> Message-ID: On 6/1/15, 1:49 PM, "Matthew Kaufman" wrote: >On 6/1/2015 12:06 AM, Owen DeLong wrote: >> ... Here?s the thing? In order to land IPv6 services without IPv6 >> support on the VM, you?re creating an environment where... > >Let's hypothetically say that it is much easier for the cloud provider >if they provide just a single choice within their network, but allow >both v4 and v6 access from the outside via a translator (to whichever >one isn't native internally). > >Would you rather have: >1) An all-IPv6 network inside, so the hosts can all talk to each other >over IPv6 without using (potentially overlapping copies of) RFC1918 >space... but where very little of the open-source software you build >your services on works at all, because it either doesn't support IPv6 or >they put some IPv6 support in but it is always lagging behind and the >bugs don't get fixed in a timely manner. Or, > >2) An all-IPv4 network inside, with the annoying (but well-known) use of >RFC1918 IPv4 space and all your software stacks just work as they always >have, only now the fraction of users who have IPv6 can reach them over >IPv6 if they so choose (despite the connectivity often being worse than >the IPv4 path) and the 2 people who are on IPv6-only networks can reach >your services too. ?fraction? is nearly 1/5 in the U.S., and growing fast: https://www.vyncke.org/ipv6status/project.php I don?t know your source for ?often being worse,? but I have several sources saying, ?lower latency.? (see NANOG60, IPv6 Performance Panel, and see Facebook?s numbers from World IPv6 Congress). > >Until all of the common stacks that people build upon, including >distributed databases, cache layers, web accelerators, etc. all work >*better* when the native environment is IPv6, everyone will be choosing >#2. For certain values of ?everyone.? > >And both #1 and #2 are cheaper and easier to manage that full dual-stack >to every single host (because you pay all the cost of supporting v6 >everywhere with none of the savings of not having to deal with the >ever-increasing complexity of continuing to use v4) I agree with that. Lee > >Matthew Kaufman > > From bill at herrin.us Mon Jun 1 20:28:05 2015 From: bill at herrin.us (William Herrin) Date: Mon, 1 Jun 2015 16:28:05 -0400 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: <556CA738.5040304@ispn.net> References: <556C5E34.5070309@ispn.net> <1433176135256.33520@madbull.info> <556CA738.5040304@ispn.net> Message-ID: On Mon, Jun 1, 2015 at 2:40 PM, Blake Hudson wrote: > A gateway of last resort, also called a backup default route, will take care > of partitions No, Blake, it won't. A partition means one of your ISPs has no route to the destination. Route the packet to that ISP via a default route and it gets sent to /dev/null. More, during a partition you don't get to pick which of your ISPs lack the route. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From blake at ispn.net Mon Jun 1 21:05:55 2015 From: blake at ispn.net (Blake Hudson) Date: Mon, 01 Jun 2015 16:05:55 -0500 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: <556C5E34.5070309@ispn.net> <1433176135256.33520@madbull.info> <556CA738.5040304@ispn.net> Message-ID: <556CC933.8080309@ispn.net> William Herrin wrote on 6/1/2015 3:28 PM: > On Mon, Jun 1, 2015 at 2:40 PM, Blake Hudson wrote: >> A gateway of last resort, also called a backup default route, will take care >> of partitions > No, Blake, it won't. A partition means one of your ISPs has no route > to the destination. Route the packet to that ISP via a default route > and it gets sent to /dev/null. More, during a partition you don't get > to pick which of your ISPs lack the route. > > Regards, > Bill Herrin Thanks. I see what you mean. I was coming from the vantage point of taking full routes and assuming that the prefix information existed and simply hadn't filtered down to the op's equipment yet. It was there, just upstream a hop or two. This could be due to a newly advertised route, path changes, or initial BGP convergence. In this case, a backup route provides the necessary bridge while BGP converges. I see what you mean about one ISP having a route and the other not; Taking full routes resolves any question about the best (only) path. After studying failure modes and attempting to optimize BGP using partial routing tables, I am of the opinion that BGP with a full routing table to directly connected devices is by far the best way to gain the availability benefits of BGP. Many attempts to cost save through multi-hop BGP or traffic engineering end up breaking down when a fault occurs. Some faults, like link state, are easy to detect and work around. Other faults, like where a peer is up, but has no outside connectivity, are harder to detect if you're taking anything less than full routes. --Blake From baldur.norddahl at gmail.com Mon Jun 1 21:13:47 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 1 Jun 2015 23:13:47 +0200 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: <556C5E34.5070309@ispn.net> <1433176135256.33520@madbull.info> <556CA738.5040304@ispn.net> Message-ID: This is only a problem if you use so called tier 1 transit providers. The smaller fish in the pond have multiple transits themselves and will there by always have an alternative route available. Regards Baldur Den 01/06/2015 22.32 skrev "William Herrin" : > On Mon, Jun 1, 2015 at 2:40 PM, Blake Hudson wrote: > > A gateway of last resort, also called a backup default route, will take > care > > of partitions > > No, Blake, it won't. A partition means one of your ISPs has no route > to the destination. Route the packet to that ISP via a default route > and it gets sent to /dev/null. More, during a partition you don't get > to pick which of your ISPs lack the route. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From bill at herrin.us Mon Jun 1 21:19:05 2015 From: bill at herrin.us (William Herrin) Date: Mon, 1 Jun 2015 17:19:05 -0400 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: <556CC933.8080309@ispn.net> References: <556C5E34.5070309@ispn.net> <1433176135256.33520@madbull.info> <556CA738.5040304@ispn.net> <556CC933.8080309@ispn.net> Message-ID: On Mon, Jun 1, 2015 at 5:05 PM, Blake Hudson wrote: > After studying failure modes and attempting to optimize BGP using partial > routing tables, I am of the opinion that BGP with a full routing table to > directly connected devices is by far the best way to gain the availability > benefits of BGP. Many attempts to cost save through multi-hop BGP or traffic > engineering end up breaking down when a fault occurs. Some faults, like link > state, are easy to detect and work around. Other faults, like where a peer > is up, but has no outside connectivity, are harder to detect if you're > taking anything less than full routes. Hi Blake, Yes, it's better to take full routes. But taking a default from two ISPs still has a reliability advantage over using a single ISP. And of course if you have two connections to the same ISP there's limited in taking full routes. Between default routes and full routes there is a range of options with increasing reliability. For example, years ago I had routers with a 256k TCAM as the BGP table approached 256k. The organization I worked for was US-centric. We needed world connectivity, but high reliability to Asia or Europe was not essential. And a large cash expenditure that year would have been bad. By slaving the APNIC /8's to a single accepted BGP route, backed by static routes for those /8's should the master BGP route fail, I maintained full connectivity while suppressing the route count to what the hardware could handle. And of course maintained maximum reliability to the destination region I most cared about. Moral of the story: if you can afford it, always take full routes. If you can't afford it, try to. If you really can't afford it, there's some trickery that can last you a year or two until you can afford it, but make sure new hardware makes it into your budget. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From cfriacas at fccn.pt Mon Jun 1 21:21:20 2015 From: cfriacas at fccn.pt (Carlos Friacas) Date: Mon, 1 Jun 2015 22:21:20 +0100 (WEST) Subject: Giganews/AS30094 Contact Message-ID: Hello, Can someone from Giganews/AS30094 please contact me off-list? Thanks & Regards, ----------------------------------------------------------------------------- Carlos Friacas See: Network Services Area www.fccn.pt FCT - Fundacao para a Ciencia e a Tecnologia www.fct.pt FCCN Unit www.geant.net Av. do Brasil, 101, 1700-066 Lisboa, Portugal, Europe www.gigapix.pt Tel:+351 218440100 NOC:+351 218440101 Fax:+351 218472167 www.6deploy.eu ----------------------------------------------------------------------------- "Internet is just routes (550752/22735), naming (billions) & ... people!" From don at bowenvale.co.nz Mon Jun 1 21:30:27 2015 From: don at bowenvale.co.nz (Don Gould) Date: Tue, 02 Jun 2015 09:30:27 +1200 Subject: Colo Capacity quote in Renton, WA 98057, USA needed In-Reply-To: References: <556661C3.2000403@bowenvale.co.nz> Message-ID: <556CCEF3.1080605@bowenvale.co.nz> Hi Sam, Thanks what a great resource! I'm feeling the NOG love here right now!!! I got a bit DDOS'ed with support and now I'm just wading through the replies. I did discover that I'm just paying way to much and have been bitten by not paying proper attention to refreshing service arrangements annually (or even biannually). Thanks guys to everyone who responded and sorry if I haven't got back to you quite yet. D On 28/05/2015 8:31 p.m., Sam Oduor wrote: > Hi Don > > > Check out http://www.quotecolo.com/colocation/ ; you will enter the > requirements inclusive the area you prefer. > > > They will send you referrals and you can choose who to pick. > > > > > > > Regards > > > > > > > On Thu, May 28, 2015 at 3:30 AM, Don Gould > wrote: > > Hi, > > I have half a dozen servers in a DC in Renton, WA 98057, USA. > > I'm looking for quotes 7 RU with 100mbit PIR. I do need A and B > side power. > > The pricing from my current provider has got out of hand and they > have burnt the relationship. As a result I am interested in > hearing from others who might be interested in servicing this > small requirement. > > Cheers Don > > > -- > Don Gould > 31 Acheson Ave > Mairehau > Christchurch, New Zealand > Ph: + 64 3 348 7235 > Mobile: + 64 21 114 0699 > Ph: +61 3 9111 1821 (Melb) > > > > > > -- > Samson Oduor -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 Ph: +61 3 9111 1821 (Melb) I'M COLLECTING COFFEE CUPS FOR PROJECT COFFEE CUP. Deja vue (missing the French accent mark) - literally means already seen, that sense of haven't we been here before. From bill at herrin.us Mon Jun 1 21:46:22 2015 From: bill at herrin.us (William Herrin) Date: Mon, 1 Jun 2015 17:46:22 -0400 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: <556C5E34.5070309@ispn.net> <1433176135256.33520@madbull.info> <556CA738.5040304@ispn.net> Message-ID: On Mon, Jun 1, 2015 at 5:13 PM, Baldur Norddahl wrote: > This is only a problem if you use so called tier 1 transit providers. > > The smaller fish in the pond have multiple transits themselves and will > there by always have an alternative route available. Hi Baldur, Cogent is not a tier 1 (not a "transit-free") provider last I heard. Maybe that's changed, but they weren't back when they had the week-long peering dispute with Sprint. Their business plan included preventing their routes from reaching Sprint via paid transit. If you were a customer of either carrier that week and you weren't multihomed with full routes, you were not a happy camper. "Always" is such a strong. Yes, you're at higher risk if all your upstreams are "transit-free" but using only backbone providers who have paid upstream transit in their mix is no panacea. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jason at rice.edu Mon Jun 1 21:47:49 2015 From: jason at rice.edu (Jason Bothe) Date: Mon, 1 Jun 2015 16:47:49 -0500 Subject: PeeringDB Admin Message-ID: <4786C2DC-E463-4A55-BEE8-F8609CE26D0F@rice.edu> Could I please have a PeeringDB admin contact me off-list ? Thanks! Jason Bothe, Manager of Networking Rice University o +1 713 348 5500 m +1 713 703 3552 jason at rice.edu From patrick at ianai.net Mon Jun 1 21:51:22 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 1 Jun 2015 17:51:22 -0400 Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: References: <556C5E34.5070309@ispn.net> <1433176135256.33520@madbull.info> <556CA738.5040304@ispn.net> Message-ID: <9CC2CECA-5976-4E65-89C5-A7347E39B78B@ianai.net> On Jun 01, 2015, at 17:46 , William Herrin wrote: > On Mon, Jun 1, 2015 at 5:13 PM, Baldur Norddahl > wrote: >> This is only a problem if you use so called tier 1 transit providers. >> >> The smaller fish in the pond have multiple transits themselves and will >> there by always have an alternative route available. > > Hi Baldur, > > Cogent is not a tier 1 (not a "transit-free") provider last I heard. > Maybe that's changed, but they weren't back when they had the > week-long peering dispute with Sprint. Cogent has no transit. Hasn?t for years. During the peering outage, the only ?transit? they had was to a single SFI network. I make no comments about Cogent?s reliability or peering or etc. ? TTFN, patrick > Their business plan included > preventing their routes from reaching Sprint via paid transit. If you > were a customer of either carrier that week and you weren't multihomed > with full routes, you were not a happy camper. > > "Always" is such a strong. Yes, you're at higher risk if all your > upstreams are "transit-free" but using only backbone providers who > have paid upstream transit in their mix is no panacea. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: From niels=nanog at bakker.net Mon Jun 1 21:55:01 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 1 Jun 2015 23:55:01 +0200 Subject: PeeringDB Admin In-Reply-To: <4786C2DC-E463-4A55-BEE8-F8609CE26D0F@rice.edu> References: <4786C2DC-E463-4A55-BEE8-F8609CE26D0F@rice.edu> Message-ID: <20150601215501.GC3166@excession.tpb.net> * jason at rice.edu (Jason Bothe) [Mon 01 Jun 2015, 23:51 CEST]: >Could I please have a PeeringDB admin contact me off-list ? I've mailed their support alias several times and have literally always had quick and to-the-point answers. -- Niels. From job at instituut.net Mon Jun 1 22:00:29 2015 From: job at instituut.net (Job Snijders) Date: Tue, 2 Jun 2015 00:00:29 +0200 Subject: PeeringDB Admin In-Reply-To: <4786C2DC-E463-4A55-BEE8-F8609CE26D0F@rice.edu> References: <4786C2DC-E463-4A55-BEE8-F8609CE26D0F@rice.edu> Message-ID: <20150601220029.GE94733@Vurt.local> On Mon, Jun 01, 2015 at 04:47:49PM -0500, Jason Bothe wrote: > Could I please have a PeeringDB admin contact me off-list ? Done! Kind regards, Job From jason at rice.edu Mon Jun 1 22:09:26 2015 From: jason at rice.edu (Jason Bothe) Date: Mon, 1 Jun 2015 17:09:26 -0500 Subject: PeeringDB Admin In-Reply-To: <20150601220029.GE94733@Vurt.local> References: <4786C2DC-E463-4A55-BEE8-F8609CE26D0F@rice.edu> <20150601220029.GE94733@Vurt.local> Message-ID: It?s working now, thanks!! :D Jason Bothe, Manager of Networking o +1 713 348 5500 m +1 713 703 3552 jason at rice.edu > On 1, Jun 2015, at 5:00 PM, Job Snijders wrote: > > On Mon, Jun 01, 2015 at 04:47:49PM -0500, Jason Bothe wrote: >> Could I please have a PeeringDB admin contact me off-list ? > > Done! > > Kind regards, > > Job > From mpalmer at hezmatt.org Mon Jun 1 22:17:41 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Tue, 2 Jun 2015 08:17:41 +1000 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> Message-ID: <20150601221741.GW724@hezmatt.org> The question that Matthew Kaufman proposed was specifically asking about app architecture deployments, so what Facebook is choosing to do is entirely germane. - Matt On Mon, Jun 01, 2015 at 02:43:27PM -0400, Todd Underwood wrote: > fb is not a 'cloud provider'. > > it's orthogonal to the question. > > t > > On Mon, Jun 1, 2015 at 2:36 PM, Ca By wrote: > > > On Mon, Jun 1, 2015 at 10:49 AM, Matthew Kaufman > > wrote: > > > > > On 6/1/2015 12:06 AM, Owen DeLong wrote: > > > > > >> ... Here?s the thing? In order to land IPv6 services without IPv6 > > support > > >> on the VM, you?re creating an environment where... > > >> > > > > > > Let's hypothetically say that it is much easier for the cloud provider if > > > they provide just a single choice within their network, but allow both v4 > > > and v6 access from the outside via a translator (to whichever one isn't > > > native internally). > > > > > > Would you rather have: > > > 1) An all-IPv6 network inside, so the hosts can all talk to each other > > > over IPv6 without using (potentially overlapping copies of) RFC1918 > > > space... but where very little of the open-source software you build your > > > services on works at all, because it either doesn't support IPv6 or they > > > put some IPv6 support in but it is always lagging behind and the bugs > > don't > > > get fixed in a timely manner. Or, > > > > > > > > > Facebook selected IPv6-only as outlined above > > > > http://blog.ipspace.net/2014/03/facebook-is-close-to-having-ipv6-only.html > > > > > > > > > > 2) An all-IPv4 network inside, with the annoying (but well-known) use of > > > RFC1918 IPv4 space and all your software stacks just work as they always > > > have, only now the fraction of users who have IPv6 can reach them over > > IPv6 > > > if they so choose (despite the connectivity often being worse than the > > IPv4 > > > path) and the 2 people who are on IPv6-only networks can reach your > > > services too. > > > > > > Until all of the common stacks that people build upon, including > > > distributed databases, cache layers, web accelerators, etc. all work > > > *better* when the native environment is IPv6, everyone will be choosing > > #2. > > > > > > And both #1 and #2 are cheaper and easier to manage that full dual-stack > > > to every single host (because you pay all the cost of supporting v6 > > > everywhere with none of the savings of not having to deal with the > > > ever-increasing complexity of continuing to use v4) > > > > > > Matthew Kaufman > > > > > > > > > -- Designing an effective undergrad CS degree is hard. It's no wonder so many ivy-league schools have more or less given up and turned into Java Certification shops. -- Steve Yegge, http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html From mpalmer at hezmatt.org Mon Jun 1 22:25:38 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Tue, 2 Jun 2015 08:25:38 +1000 Subject: AWS Elastic IP architecture In-Reply-To: <556C9B15.7010403@matthew.at> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> Message-ID: <20150601222532.GX724@hezmatt.org> On Mon, Jun 01, 2015 at 10:49:09AM -0700, Matthew Kaufman wrote: > On 6/1/2015 12:06 AM, Owen DeLong wrote: > >... Here?s the thing? In order to land IPv6 services without IPv6 support > >on the VM, you?re creating an environment where... > > Let's hypothetically say that it is much easier for the cloud provider if > they provide just a single choice within their network, but allow both v4 > and v6 access from the outside via a translator (to whichever one isn't > native internally). > > Would you rather have: > 1) An all-IPv6 network inside, so the hosts can all talk to each other over > IPv6 without using (potentially overlapping copies of) RFC1918 space... but > where very little of the open-source software you build your services on > works at all, because it either doesn't support IPv6 or they put some IPv6 > support in but it is always lagging behind and the bugs don't get fixed in a > timely manner. Or, I'd much rather have this. In fact, I'm building this at the moment. It simplifies so many things, like not having to worry about address assignment, choosing appropriately-sized subnets, address re-use, etc. Having direct access to everything from the outside world without having to deal with NAT/VPN/a jump box makes so many things smoother, too. Everything I've deployed (and yes, all the components are OSS) has dealt with IPv6 just fine, and everything I've considered deploying claims IPv6 support. I've had to submit one patch for fixing an IPv6 bug, and because it's OSS, I can do that! - Matt From mpalmer at hezmatt.org Mon Jun 1 22:36:03 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Tue, 2 Jun 2015 08:36:03 +1000 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> Message-ID: <20150601223603.GY724@hezmatt.org> On Mon, Jun 01, 2015 at 11:30:00AM -0400, Christopher Morrow wrote: > I don't get why > 'ipv6 address on my vm' matters a whole bunch (*in a world where v4 is > still available to you I mean), It simplifies infrastructure management considerably. Having to balance between "how many subnets will I ever need?" vs "how many machines could I end up with in a subnet?" is something I never thought would become annoying, until I had the opportunity to not worry about it... then it was frustrating to have to go back to it. Not having to use a VPN/NAT/jump box to hit all my infrastructure seems like a small benefit, but it saves having to maintain a VPN/jump box (and all its attendant annoyances). Oh, yeah, never having to faff around with split-horizon DNS management... "Family Guy Tooth Fairy" on YouTube. In short, there's a whole pile of dodgy hacks we deploy almost without thinking about it, because "that's just how things are done", to work around limitations in IPv4 deployments. Having IPv6 everywhere *within* the infrastructure makes all of those hacks disappear, and like most things we "just do because we have to", you don't realise how much of a PITA they were until they're gone. - Matt -- And Jesus said unto them, "And whom do you say that I am?" They replied, "You are the eschatological manifestation of the ground of our being, the ontological foundation of the context of our very selfhood revealed." And Jesus replied, "What?" -- Seen on the 'net From hugo at slabnet.com Mon Jun 1 22:41:19 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 1 Jun 2015 15:41:19 -0700 Subject: AWS Elastic IP architecture In-Reply-To: <20150601221741.GW724@hezmatt.org> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> <20150601221741.GW724@hezmatt.org> Message-ID: <20150601224119.GA31945@bamboo.slabnet.com> >The question that Matthew Kaufman proposed was specifically asking about >app architecture deployments, so what Facebook is choosing to do is >entirely germane. I'd lean more on the "ipv6 evangelism" side of the discussion, but: Facebook controls the whole stack and can require buy-in from their apps people to push IPv6 first. If that costs them dev time to patch some OSS to handle it gracefully, that's their business decision. In the "cloud host" domain, you're dealing with a much more heterogeneous environment where the provider doesn't control the whole stack up to the apps. Making the platform as frictionless as possible for customers is key; customer X is not going like your platform much if widget Y doesn't run properly "because IPv6". Sure, widget Y should get its excrement together and handle it, but all customer X sees is "widget Y fails on provider A, but runs fine on provider B" where provider A was v6-only internal but provider B is either v4-only or dual stack. Guess where customer X spends their dollars now? I'm on your side, here: I run my own stuff v6-first wherever possible and have filed bug reports, submitted workarounds/patches, etc. We need people doing that to push things forward. On this given point, though: Facebook -ne generic hosting platform -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From alh-ietf at tndh.net Mon Jun 1 23:20:11 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 1 Jun 2015 16:20:11 -0700 Subject: AWS Elastic IP architecture In-Reply-To: <20150601224119.GA31945@bamboo.slabnet.com> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> <20150601221741.GW724@hezmatt.org> <20150601224119.GA31945@bamboo.slabnet.com> Message-ID: <083301d09cc1$82342120$869c6360$@tndh.net> Hugo Slabbert wrote: >>> snip > > On this given point, though: Facebook -ne generic hosting platform True, but it does represent a business decision to choose IPv6. The relevant point here is that the "NEXT" facebook/twitter/snapchat/... is likely being pushed by clueless investors into outsourcing their infrastructure to AWS/Azure/Google-cloud. This will prevent them from making the same business decision about system efficiency and long term growth that Facebook made due to decisions made by the cloud service operator. >From my perspective, most of this conversation has centered on the needs of the service, and tried very hard to ignore the needs of the customer despite Owen and others repeatedly raising the point. While the needs of the service do impact the cost of delivery, a broken service is still broken. Personally I would consider "free" to be overpriced for a broken service, but maybe that is just me. In any case, if the VM interface doesn't present what looks like a native IPv6 service to the application developer, IPv6 usage will be curtailed and IPv4 growing pains will continue to get worse. Tony From hugo at slabnet.com Mon Jun 1 23:25:48 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 1 Jun 2015 16:25:48 -0700 (PDT) Subject: AWS Elastic IP architecture In-Reply-To: <083301d09cc1$82342120$869c6360$@tndh.net> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> <20150601221741.GW724@hezmatt.org> <20150601224119.GA31945@bamboo.slabnet.com> <083301d09cc1$82342120$869c6360$@tndh.net> Message-ID: Agree with everything in your post. -- Hugo ----- Original Message ----- From: Tony Hain Sent: 2015-06-01 - 16:20 To: 'Hugo Slabbert' , 'Matt Palmer' Subject: RE: AWS Elastic IP architecture > Hugo Slabbert wrote: >>>> snip >> >> On this given point, though: Facebook -ne generic hosting platform > > True, but it does represent a business decision to choose IPv6. The relevant > point here is that the "NEXT" facebook/twitter/snapchat/... is likely being > pushed by clueless investors into outsourcing their infrastructure to > AWS/Azure/Google-cloud. This will prevent them from making the same business > decision about system efficiency and long term growth that Facebook made due > to decisions made by the cloud service operator. > > From my perspective, most of this conversation has centered on the needs of > the service, and tried very hard to ignore the needs of the customer despite > Owen and others repeatedly raising the point. While the needs of the service > do impact the cost of delivery, a broken service is still broken. Personally > I would consider "free" to be overpriced for a broken service, but maybe > that is just me. > > In any case, if the VM interface doesn't present what looks like a native > IPv6 service to the application developer, IPv6 usage will be curtailed and > IPv4 growing pains will continue to get worse. > > Tony > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 870 bytes Desc: PGP/MIME digital signature URL: From morrowc.lists at gmail.com Tue Jun 2 00:08:42 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Jun 2015 20:08:42 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <20150601223603.GY724@hezmatt.org> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> Message-ID: On Mon, Jun 1, 2015 at 6:36 PM, Matt Palmer wrote: > On Mon, Jun 01, 2015 at 11:30:00AM -0400, Christopher Morrow wrote: >> I don't get why >> 'ipv6 address on my vm' matters a whole bunch (*in a world where v4 is >> still available to you I mean), > > It simplifies infrastructure management considerably. Having to balance > between "how many subnets will I ever need?" vs "how many machines could I > end up with in a subnet?" is something I never thought would become > annoying, until I had the opportunity to not worry about it... then it was > frustrating to have to go back to it. Not having to use a VPN/NAT/jump box > to hit all my infrastructure seems like a small benefit, but it saves having > to maintain a VPN/jump box (and all its attendant annoyances). Oh, yeah, > never having to faff around with split-horizon DNS management... "Family Guy > Tooth Fairy" on YouTube. sure, most of that you have to worry about if you're building your own cloud thingy... but in that case, why not just do the 'right thing' as you see fit (which you seem to have done, yay!). If you're just using aws/ec2/gce/whatever... all of that is taken care of for you, so there's nothing to setup and what ip address the vm has just isn't relevant. Whether or not they use ipv6 isn't relevant really either, honestly (for the management and even interprocess comms). > In short, there's a whole pile of dodgy hacks we deploy almost without > thinking about it, because "that's just how things are done", to work around > limitations in IPv4 deployments. Having IPv6 everywhere *within* the > infrastructure makes all of those hacks disappear, and like most things we > "just do because we have to", you don't realise how much of a PITA they were > until they're gone. so... the 'dodgy hacks' only really matter if you have to keep them running (keep a nat box and a bastion and ...) if that's all done for you by the chosen provider then, none of these arguments hold. your bit about subnet sizing and numbering also glosses over a slew of 'where did machine X go?' (naming) problems. which, incidentally you avoid with: "dhcp address and name" in the v6 world. So... I don't really see any of the above arguments for v6 in a vm setup to really hold water in the short term at least. I think for sure you'll want v6 for public services 'soon' (arguably like 10 yrs ago so you'd get practice and operational experience and ...) but for the rest sure it's 'nice', and 'cute', but really not required for operations (unless you have v6 only customers) -chris > > -- > And Jesus said unto them, "And whom do you say that I am?" They replied, > "You are the eschatological manifestation of the ground of our being, the > ontological foundation of the context of our very selfhood revealed." And > Jesus replied, "What?" -- Seen on the 'net > From morrowc.lists at gmail.com Tue Jun 2 00:10:12 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Jun 2015 20:10:12 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <083301d09cc1$82342120$869c6360$@tndh.net> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> <20150601221741.GW724@hezmatt.org> <20150601224119.GA31945@bamboo.slabnet.com> <083301d09cc1$82342120$869c6360$@tndh.net> Message-ID: On Mon, Jun 1, 2015 at 7:20 PM, Tony Hain wrote: > True, but it does represent a business decision to choose IPv6. The relevant > point here is that the "NEXT" facebook/twitter/snapchat/... is likely being > pushed by clueless investors into outsourcing their infrastructure to > AWS/Azure/Google-cloud. ;; ANSWER SECTION: www.snapchat.com. 3433 IN CNAME ghs.google.com. ghs.google.com. 21599 IN CNAME ghs.l.google.com. ghs.l.google.com. 299 IN A 64.233.176.121 snapchat seems to be doing just fine on 'google cloud services' though? oh: ;; ANSWER SECTION: www.snapchat.com. 3388 IN CNAME ghs.google.com. ghs.google.com. 21599 IN CNAME ghs.l.google.com. ghs.l.google.com. 299 IN AAAA 2607:f8b0:4002:c06::79 ha! From cb.list6 at gmail.com Tue Jun 2 00:33:55 2015 From: cb.list6 at gmail.com (Ca By) Date: Mon, 1 Jun 2015 17:33:55 -0700 Subject: AWS Elastic IP architecture In-Reply-To: <083301d09cc1$82342120$869c6360$@tndh.net> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> <20150601221741.GW724@hezmatt.org> <20150601224119.GA31945@bamboo.slabnet.com> <083301d09cc1$82342120$869c6360$@tndh.net> Message-ID: On Monday, June 1, 2015, Tony Hain wrote: > Hugo Slabbert wrote: > >>> snip > > > > On this given point, though: Facebook -ne generic hosting platform > > True, but it does represent a business decision to choose IPv6. The > relevant > point here is that the "NEXT" facebook/twitter/snapchat/... is likely being > pushed by clueless investors into outsourcing their infrastructure to > AWS/Azure/Google-cloud. This will prevent them from making the same > business > decision about system efficiency and long term growth that Facebook made > due > to decisions made by the cloud service operator. > > This is the exact case for www.duckduckgo.com. They were ipv6, moved to aws, and lost support , no aaaa today To be honest, $dayjob may be next to lose ipv6 if / when www goes to the cloud > From my perspective, most of this conversation has centered on the needs of > the service, and tried very hard to ignore the needs of the customer > despite > Owen and others repeatedly raising the point. While the needs of the > service > do impact the cost of delivery, a broken service is still broken. > Personally > I would consider "free" to be overpriced for a broken service, but maybe > that is just me. > > In any case, if the VM interface doesn't present what looks like a native > IPv6 service to the application developer, IPv6 usage will be curtailed and > IPv4 growing pains will continue to get worse. > > Tony > > From marka at isc.org Tue Jun 2 00:51:14 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 02 Jun 2015 10:51:14 +1000 Subject: AWS Elastic IP architecture In-Reply-To: Your message of "Mon, 01 Jun 2015 20:08:42 -0400." References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> Message-ID: <20150602005115.884BF2FC9EA2@rock.dv.isc.org> In message , Christopher Morrow writes: > So... I don't really see any of the above arguments for v6 in a vm > setup to really hold water in the short term at least. I think for > sure you'll want v6 for public services 'soon' (arguably like 10 yrs > ago so you'd get practice and operational experience and ...) but for > the rest sure it's 'nice', and 'cute', but really not required for > operations (unless you have v6 only customers) Everyone has effectively IPv6-only customers today. IPv6 native + CGN only works for services. Similarly DS-Lite and 464XLAT. Sometimes you can get away w/o IPv6, sometimes you can't. In all cases IPv4 is getting more and more expensive to support as more customers share public IP addresses even if it is just have to re-tune rate limits to account for the sharing. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cb.list6 at gmail.com Tue Jun 2 01:02:09 2015 From: cb.list6 at gmail.com (Ca By) Date: Mon, 1 Jun 2015 18:02:09 -0700 Subject: AWS Elastic IP architecture In-Reply-To: <20150602005115.884BF2FC9EA2@rock.dv.isc.org> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> Message-ID: On Monday, June 1, 2015, Mark Andrews wrote: > > In message rs4vSx5mFECpfuE8b7VQ+Au2hCXpMQ at mail.gmail.com > > , Christopher Morrow writes: > > So... I don't really see any of the above arguments for v6 in a vm > > setup to really hold water in the short term at least. I think for > > sure you'll want v6 for public services 'soon' (arguably like 10 yrs > > ago so you'd get practice and operational experience and ...) but for > > the rest sure it's 'nice', and 'cute', but really not required for > > operations (unless you have v6 only customers) > > Everyone has effectively IPv6-only customers today. IPv6 native + > CGN only works for services. Similarly DS-Lite and 464XLAT. > Sometimes you can get away w/o IPv6, sometimes you can't. In all > cases IPv4 is getting more and more expensive to support as more > customers share public IP addresses even if it is just have to > re-tune rate limits to account for the sharing. > > Agreed. Here is some data. It's worth noting that the Samsung Galaxy S6 launched with IPv6 on by default at AT&T, Verizon, Sprint, T-Mobile. And the majority of the T-Mobile at Verizon customer base is on IPv6, so IPv4 is the minority right now in mobile. Oh, and when i say ipv4 is the minority i mean NAT44. Proper public ipv4 is not even on the mobile radar, but ipv6 is http://www.worldipv6launch.org/measurements/ CB > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > From jfmezei_nanog at vaxination.ca Tue Jun 2 01:08:15 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 01 Jun 2015 21:08:15 -0400 Subject: Capacity/transit costs vs growth In-Reply-To: References: <556638D7.9020305@vaxination.ca> <547763742.414850.1432768820433.JavaMail.zimbra@snappytelecom.net> <55665951.7070206@vaxination.ca> <723976488.416529.1432782465734.JavaMail.zimbra@snappytelecom.net> <20150528033249.GA10598@puck.nether.net> <5566975E.5010601@vaxination.ca> Message-ID: <556D01FF.1030106@vaxination.ca> On 15-05-28 16:02, James Bensley wrote: > This sort of information is out there for things like transit prices, > since they are more common shared in public... > > http://drpeering.net/white-papers/Internet-Transit-Pricing-Historical-And-Projected.php Mamny thanks. Sorry for delay, was busy writing submission along with other real work. Managed to turn the graphs on that page into convincing arguments that the CRTC rate structures are wrong. (famous last words , of course) From morrowc.lists at gmail.com Tue Jun 2 01:12:58 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Jun 2015 21:12:58 -0400 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> Message-ID: On Mon, Jun 1, 2015 at 9:02 PM, Ca By wrote: > > > On Monday, June 1, 2015, Mark Andrews wrote: >> >> >> In message >> >> , Christopher Morrow writes: >> > So... I don't really see any of the above arguments for v6 in a vm >> > setup to really hold water in the short term at least. I think for >> > sure you'll want v6 for public services 'soon' (arguably like 10 yrs >> > ago so you'd get practice and operational experience and ...) but for >> > the rest sure it's 'nice', and 'cute', but really not required for >> > operations (unless you have v6 only customers) >> >> Everyone has effectively IPv6-only customers today. IPv6 native + >> CGN only works for services. Similarly DS-Lite and 464XLAT. ok, and for the example of 'put my service in the cloud' ... the service is still accessible over ipv4 right? > Agreed. Here is some data. > > It's worth noting that the Samsung Galaxy S6 launched with IPv6 on by > default at AT&T, Verizon, Sprint, T-Mobile. > > And the majority of the T-Mobile at Verizon customer base is on IPv6, so > IPv4 is the minority right now in mobile. Oh, and when i say ipv4 is the > minority i mean NAT44. > > Proper public ipv4 is not even on the mobile radar, but ipv6 is but.. http/s to an ipv4 address works, so... From marka at isc.org Tue Jun 2 01:32:47 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 02 Jun 2015 11:32:47 +1000 Subject: AWS Elastic IP architecture In-Reply-To: Your message of "Mon, 01 Jun 2015 21:12:58 -0400." References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> Message-ID: <20150602013248.9DED42FCA443@rock.dv.isc.org> In message , Christopher Morrow writes: > On Mon, Jun 1, 2015 at 9:02 PM, Ca By wrote: > > > > > > On Monday, June 1, 2015, Mark Andrews wrote: > >> > >> > >> In message > >> > >> , Christopher Morrow writes: > >> > So... I don't really see any of the above arguments for v6 in a vm > >> > setup to really hold water in the short term at least. I think for > >> > sure you'll want v6 for public services 'soon' (arguably like 10 yrs > >> > ago so you'd get practice and operational experience and ...) but for > >> > the rest sure it's 'nice', and 'cute', but really not required for > >> > operations (unless you have v6 only customers) > >> > >> Everyone has effectively IPv6-only customers today. IPv6 native + > >> CGN only works for services. Similarly DS-Lite and 464XLAT. > > ok, and for the example of 'put my service in the cloud' ... the > service is still accessible over ipv4 right? It depends on what you are trying to do. Having something in the cloud manage something at home. You can't reach the home over IPv4 more and more these days as. IPv6 is the escape path for that but you need both ends to be able to speak IPv6. This will happen to business as well. The ability to be able to be able to call out to everyone is lost if the cloud provider doesn't fully support IPv6. There are a whole segment of applications that don't work, or don't work well, or don't work without a whole lot of additional investment when one end is behind a CGN (covers all the above as IPv4 is supplied over a CGN). This attitude of we don't have to invest in IPv6 yet because we have lots of public IPv4 addresses stinks to high heaven these day, whether you are a ISP, cloud provider or someone else. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Tue Jun 2 01:41:30 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Jun 2015 21:41:30 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <20150602013248.9DED42FCA443@rock.dv.isc.org> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> Message-ID: On Mon, Jun 1, 2015 at 9:32 PM, Mark Andrews wrote: > > In message >, Christopher Morrow writes: >> On Mon, Jun 1, 2015 at 9:02 PM, Ca By wrote: >> > >> > >> > On Monday, June 1, 2015, Mark Andrews wrote: >> >> >> >> >> >> In message >> >> >> >> , Christopher Morrow writes: >> >> > So... I don't really see any of the above arguments for v6 in a vm >> >> > setup to really hold water in the short term at least. I think for >> >> > sure you'll want v6 for public services 'soon' (arguably like 10 yrs >> >> > ago so you'd get practice and operational experience and ...) but for >> >> > the rest sure it's 'nice', and 'cute', but really not required for >> >> > operations (unless you have v6 only customers) >> >> >> >> Everyone has effectively IPv6-only customers today. IPv6 native + >> >> CGN only works for services. Similarly DS-Lite and 464XLAT. >> >> ok, and for the example of 'put my service in the cloud' ... the >> service is still accessible over ipv4 right? > > It depends on what you are trying to do. Having something in the > cloud manage something at home. You can't reach the home over IPv4 > more and more these days as. IPv6 is the escape path for that but > you need both ends to be able to speak IPv6. This will happen to > business as well. The ability to be able to be able to call out > to everyone is lost if the cloud provider doesn't fully support > IPv6. > so, I totally agree that long term v6 must also appear in the cloud-spaces... I was (long back in this thread) asking: "sure, v6 is great, what top 1-3 things could a cloud provider prioritize NOW to get the ball rolling" (presuming they have some 'real' reason why v6 'just can not be added to interface configs'). > There are a whole segment of applications that don't work, or don't > work well, or don't work without a whole lot of additional investment > when one end is behind a CGN (covers all the above as IPv4 is > supplied over a CGN). > 'additional investment' == 'client initiates connection to server' right? :) > This attitude of we don't have to invest in IPv6 yet because we > have lots of public IPv4 addresses stinks to high heaven these day, > whether you are a ISP, cloud provider or someone else. yup, agreed. I was (and am still) reacting to the 'everything is horrible and broken because I can't talk the v6's to all my internal machines' when ... that seems (to me at least) to be completely immaterial when 'there is a v6 endpoint for your http/https/xmpp/etc' available 'now'. (or could be in relatively short order). -chris From surfer at mauigateway.com Tue Jun 2 01:44:41 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 1 Jun 2015 18:44:41 -0700 Subject: BGP Multihoming 2 providers full or partial? Message-ID: <20150601184441.7D329D96@m0048141.ppops.net> ----- Original Message ----- From: "Scott Weeks" --- nogs at border6.com wrote: From: Pawel Rybczyk platform where we included new feature called That might be interesting for you. ------------------------------------------- This might be interesting for you. https://www.nanog.org/list Please read #5 before going further. Product Evangelist -------------------------------------- BLECH! I need a shower. ----------------------------------- --- nanog at ics-il.net wrote: From: Mike Hammett Seems like a perfectly good post to me. Someone made an inquiry as to how to solve a particular problem There were multiple solutions presented. Pawel posted relevant, on-topic information regarding how his product could solve the problem in a unique way. No harm, no foul. ------------------------------ You've obviously never been hounded by sales folks scraping this list that believe they should never give up. It's painful to say the least. If every "Product Evangelist" were allowed to do this, NANOG would be a nightmare. The only answer many times is to be sure you don't buy from "Product Evanglists" that post their crap on NANOG. Hit them where it hurts (no sales because they did that) and they stop. Quickly. To others out there thinking of doing the same, again I say Please read #5 https://www.nanog.org/list scott From nanog at ics-il.net Tue Jun 2 02:53:37 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 1 Jun 2015 21:53:37 -0500 (CDT) Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: <20150601184441.7D329D96@m0048141.ppops.net> Message-ID: <26793491.4160.1433213593061.JavaMail.mhammett@ThunderFuck> Probably not NANOG, but I have way more traffic on many other lists over the last 12+ years. I'm no stranger to over-zealous sales guys. I've started blocking the ones that call my support line and talking to the call center, despite the warning that support is only for my customers. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Scott Weeks" To: nanog at nanog.org Sent: Monday, June 1, 2015 8:44:41 PM Subject: Re: BGP Multihoming 2 providers full or partial? ----- Original Message ----- From: "Scott Weeks" --- nogs at border6.com wrote: From: Pawel Rybczyk platform where we included new feature called That might be interesting for you. ------------------------------------------- This might be interesting for you. https://www.nanog.org/list Please read #5 before going further. Product Evangelist -------------------------------------- BLECH! I need a shower. ----------------------------------- --- nanog at ics-il.net wrote: From: Mike Hammett Seems like a perfectly good post to me. Someone made an inquiry as to how to solve a particular problem There were multiple solutions presented. Pawel posted relevant, on-topic information regarding how his product could solve the problem in a unique way. No harm, no foul. ------------------------------ You've obviously never been hounded by sales folks scraping this list that believe they should never give up. It's painful to say the least. If every "Product Evangelist" were allowed to do this, NANOG would be a nightmare. The only answer many times is to be sure you don't buy from "Product Evanglists" that post their crap on NANOG. Hit them where it hurts (no sales because they did that) and they stop. Quickly. To others out there thinking of doing the same, again I say Please read #5 https://www.nanog.org/list scott From marka at isc.org Tue Jun 2 04:07:06 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 02 Jun 2015 14:07:06 +1000 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: Your message of "Mon, 01 Jun 2015 08:31:27 -0700." References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> Message-ID: <20150602040707.382092FCB844@rock.dv.isc.org> In message , Ca By writes: > On Mon, Jun 1, 2015 at 8:21 AM, Mark Tinka wrote: > > > > > > > On 1/Jun/15 17:04, Mike Hammett wrote: > > > Actually, that's the level of attention given to all kinds of > > infrastructure just about everywhere. ;-) > > > > The difference is that there are standardized (global) guidelines for > > those infrastructures within their own industry, that lack of compliance > > can lead to serious fines, jail time or both. > > > > A network operator unmaliciously screwing up their BGP configuration and > > taking one side of a continent out is unlikely to see any punishment > > beyond being fired by his employer, or losing his customers if > > self-employed. > > > > Mark. > > > > > Also, the internet usually works pretty good-ish and the janitors clean up > the messes pretty quick-ish. > > That said, i believe the BGP situation is completely hygienic relative to > the DDoS issues going on that could be solved by BCP38 and otherwise fixing > poorly admin'd DNS, NTP, CHARGEN, and SSDP nodes. The aforementioned > janitors are pretty powerless on this front... and... various parties on > all side are looking to cash in (booters on one side, web scrubbers on the > other)... which is a very dangerous arms race with real money on both sides > looking to escalate the harm / fix. If you have secure BGP deployed then you could extend the authenication to securely authenticate source addresses you emit and automate BCP38 filter generation and then you wouldn't have to worry about DNS, NTP, CHARGEN etc. reflecting spoofed traffic. > CB -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From alh-ietf at tndh.net Tue Jun 2 04:25:52 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 1 Jun 2015 21:25:52 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> <20150601221741.GW724@hezmatt.org> <20150601224119.GA31945@bamboo.slabnet.com> <083301d09cc1$82342120$869c6360$@tndh.net> Message-ID: <086101d09cec$362a2150$a27e63f0$@tndh.net> > -----Original Message----- > From: christopher.morrow at gmail.com > [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow > Sent: Monday, June 01, 2015 5:10 PM > To: Tony Hain > Cc: Hugo Slabbert; Matt Palmer; nanog list > Subject: Re: AWS Elastic IP architecture > > On Mon, Jun 1, 2015 at 7:20 PM, Tony Hain wrote: > > True, but it does represent a business decision to choose IPv6. The > > relevant point here is that the "NEXT" facebook/twitter/snapchat/... > > is likely being pushed by clueless investors into outsourcing their > > infrastructure to AWS/Azure/Google-cloud. > > ;; ANSWER SECTION: > www.snapchat.com. 3433 IN CNAME ghs.google.com. > ghs.google.com. 21599 IN CNAME ghs.l.google.com. > ghs.l.google.com. 299 IN A 64.233.176.121 > > snapchat seems to be doing just fine on 'google cloud services' though? oh: > > ;; ANSWER SECTION: > www.snapchat.com. 3388 IN CNAME ghs.google.com. > ghs.google.com. 21599 IN CNAME ghs.l.google.com. > ghs.l.google.com. 299 IN AAAA 2607:f8b0:4002:c06::79 > > ha! Try https://snapchat.com and see if you ever get an IPv6 connection... Yes an application aware proxy can hack some services into appearing to work, but they really fail the service customer because a site may appear to be up over IPv6 until the user switches to https, then having to switch to IPv4 end up appearing dead because IPv4 routing is having a bad hair day. From hugo at slabnet.com Tue Jun 2 04:44:11 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 1 Jun 2015 21:44:11 -0700 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601051900.GV724@hezmatt.org> <07b701d09c81$6508bc90$2f1a35b0$@tndh.net> <20150601162144.GJ4389@bamboo.slabnet.com> Message-ID: <20150602044411.GD31945@bamboo.slabnet.com> On Mon 2015-Jun-01 13:20:57 -0400, Christopher Morrow wrote: >On Mon, Jun 1, 2015 at 12:21 PM, Hugo Slabbert wrote: >> 2. Just do it properly the first time around. >> >> I would opt for #2. > >sure, so would everyone... but they didn't so... what gets you enough >there to help customers and also doesn't required a forklift of your >running operation? Sorry; I worded this poorly. Obviously they didn't go dual stack right at the outset. Options #1 and #2 I listed were done from the perspective that it's currently a v4-only environment, and some measure of work has to be done to get it to have v6 capability of *some* form. I'm working with the (soon to be not) unspoken assumption of a future state of the platform where we've "v6'd all the things", checking off all of the boxes in your original message on this; paraphrased: - Every VM has a v6 address - VMs can talk to backend services (including on your prem) over v6 - VM/system admin interfaces are reachable over v6 - You can serve up v6-accessible services from your VM(s) If my (previously unspoken) assumption of a fully v6-capable future state of the platform holds, I'm saying that going with a proxy-type solution as an interim stopgap solution carries a whole bunch of additional labor/operational cost. Implementing either option #1 or option #2 carries some combination of cost from hardware, software, and elbow grease, with values of 0 to $bigint in each category. To be fair: some of the additional elbow grease cost from option #1 is externalized from the hoster to either customers and/or the developers of the software stacks used by customers. That notwithstanding: if you're going to need to do #2 at some point anyway, why not just skip #1 and put your energy into #2 to start with? To be honest: I don't think we are diametrically opposed on this. Backing up a bit: >Would AWS (or any other cloud provider that's not currently up on the >v6 bandwagon) enabling a loadbalanced ipv6 vip for your public service >(perhaps not just http/s services even?) be enough to relieve some of >the pressure on other parties and move the ball forward meaningfully >enough for the cloud providers and their customers? Relieve some pressure and possibly generate at least *some* forward momentum? Sure. And AWS is obviously free to do as they see fit. I think a lot of folks in this discussion are just tired of seeing half measures that expend a bunch of resources to delay the inevitable and push us further into CGN hell when those resources could rather have been allocated to a proper dual-stack or v6-only solution. -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From matthew at matthew.at Tue Jun 2 04:49:35 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 01 Jun 2015 21:49:35 -0700 Subject: AWS Elastic IP architecture In-Reply-To: <20150602013248.9DED42FCA443@rock.dv.isc.org> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> Message-ID: <556D35DF.8080901@matthew.at> On 6/1/2015 6:32 PM, Mark Andrews wrote: > In message > , Christopher Morrow writes: >> On Mon, Jun 1, 2015 at 9:02 PM, Ca By wrote: >>> >>> On Monday, June 1, 2015, Mark Andrews wrote: >>>> >>>> In message >>>> >>>> , Christopher Morrow writes: >>>>> So... I don't really see any of the above arguments for v6 in a vm >>>>> setup to really hold water in the short term at least. I think for >>>>> sure you'll want v6 for public services 'soon' (arguably like 10 yrs >>>>> ago so you'd get practice and operational experience and ...) but for >>>>> the rest sure it's 'nice', and 'cute', but really not required for >>>>> operations (unless you have v6 only customers) >>>> Everyone has effectively IPv6-only customers today. IPv6 native + >>>> CGN only works for services. Similarly DS-Lite and 464XLAT. >> ok, and for the example of 'put my service in the cloud' ... the >> service is still accessible over ipv4 right? > It depends on what you are trying to do. Having something in the > cloud manage something at home. You can't reach the home over IPv4 > more and more these days as. IPv6 is the escape path for that but > you need both ends to be able to speak IPv6. ...and for firewalls to not exist. Since they do, absolutely all the techniques required to "reach something at home" over IPv4 are required for IPv6. This is on the "great myths of the advantages of IPv6" list. IPv6 has exactly one benefit... there's more addresses. It comes with a whole lot of new pain points, and probably a bunch of security nightmare still waiting to be discovered. And it for sure isn't free. Matthew Kaufman From morrowc.lists at gmail.com Tue Jun 2 04:52:45 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 2 Jun 2015 00:52:45 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <086101d09cec$362a2150$a27e63f0$@tndh.net> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> <20150601221741.GW724@hezmatt.org> <20150601224119.GA31945@bamboo.slabnet.com> <083301d09cc1$82342120$869c6360$@tndh.net> <086101d09cec$362a2150$a27e63f0$@tndh.net> Message-ID: On Tue, Jun 2, 2015 at 12:25 AM, Tony Hain wrote: > > >> -----Original Message----- >> From: christopher.morrow at gmail.com >> [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow >> Sent: Monday, June 01, 2015 5:10 PM >> To: Tony Hain >> Cc: Hugo Slabbert; Matt Palmer; nanog list >> Subject: Re: AWS Elastic IP architecture >> >> On Mon, Jun 1, 2015 at 7:20 PM, Tony Hain wrote: >> > True, but it does represent a business decision to choose IPv6. The >> > relevant point here is that the "NEXT" facebook/twitter/snapchat/... >> > is likely being pushed by clueless investors into outsourcing their >> > infrastructure to AWS/Azure/Google-cloud. >> >> ;; ANSWER SECTION: >> www.snapchat.com. 3433 IN CNAME ghs.google.com. >> ghs.google.com. 21599 IN CNAME ghs.l.google.com. >> ghs.l.google.com. 299 IN A 64.233.176.121 >> >> snapchat seems to be doing just fine on 'google cloud services' though? oh: >> >> ;; ANSWER SECTION: >> www.snapchat.com. 3388 IN CNAME ghs.google.com. >> ghs.google.com. 21599 IN CNAME ghs.l.google.com. >> ghs.l.google.com. 299 IN AAAA 2607:f8b0:4002:c06::79 >> >> ha! > > Try https://snapchat.com and see if you ever get an IPv6 connection... Yes an ;; QUESTION SECTION: ;snapchat.com. IN AAAA there is no AAAA for the bare domain... and the bare domain appears to be served from amazon space (54.192.48.27) ~$ openssl s_client -connect snapchat.com:443 CONNECTED(00000003) 139892295607968:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:770: aside from that .... no https listener. Your wang shots are not worth encrypting I suppose? application aware proxy can hack some services into appearing to work, but they really fail the service customer because a site may appear to be up over IPv6 until the user switches to https, then having to switch to IPv4 end up appearing dead because IPv4 routing is having a bad hair day. > > > From marka at isc.org Tue Jun 2 05:12:07 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 02 Jun 2015 15:12:07 +1000 Subject: AWS Elastic IP architecture In-Reply-To: Your message of "Mon, 01 Jun 2015 21:49:35 -0700." <556D35DF.8080901@matthew.at> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> Message-ID: <20150602051208.E4F132FCC4B9@rock.dv.isc.org> In message <556D35DF.8080901 at matthew.at>, Matthew Kaufman writes: > On 6/1/2015 6:32 PM, Mark Andrews wrote: > > In message com > >> , Christopher Morrow writes: > >> On Mon, Jun 1, 2015 at 9:02 PM, Ca By wrote: > >>> > >>> On Monday, June 1, 2015, Mark Andrews wrote: > >>>> > >>>> In message > >>>> > >>>> , Christopher Morrow writes: > >>>>> So... I don't really see any of the above arguments for v6 in a vm > >>>>> setup to really hold water in the short term at least. I think for > >>>>> sure you'll want v6 for public services 'soon' (arguably like 10 yrs > >>>>> ago so you'd get practice and operational experience and ...) but for > >>>>> the rest sure it's 'nice', and 'cute', but really not required for > >>>>> operations (unless you have v6 only customers) > >>>> Everyone has effectively IPv6-only customers today. IPv6 native + > >>>> CGN only works for services. Similarly DS-Lite and 464XLAT. > >> ok, and for the example of 'put my service in the cloud' ... the > >> service is still accessible over ipv4 right? > > It depends on what you are trying to do. Having something in the > > cloud manage something at home. You can't reach the home over IPv4 > > more and more these days as. IPv6 is the escape path for that but > > you need both ends to be able to speak IPv6. > > ...and for firewalls to not exist. Since they do, absolutely all the > techniques required to "reach something at home" over IPv4 are required > for IPv6. This is on the "great myths of the advantages of IPv6" list. For IPv4 you port forward in the NAT possibly doing port translation as will as address translation. For IPv6 you open the port inbound in the firewall or just move the firewalling to the host. IPv6 is easier. With modern machines you really can get rid of the firewall in front of the machine. Lots of the equipement that connects to the home nets spends plenty of time fully exposed to the Internet w/o a firewall. If it does that why does it need a firewall at home? There is a myth that you need a firewall at home. > IPv6 has exactly one benefit... there's more addresses. It comes with a > whole lot of new pain points, and probably a bunch of security nightmare > still waiting to be discovered. And it for sure isn't free. It also remove a whole lot of complications. Simplifies the security profile. > Matthew Kaufman -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From surfer at mauigateway.com Tue Jun 2 05:27:36 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 1 Jun 2015 22:27:36 -0700 Subject: BGP in the Washngton Post Message-ID: <20150601222736.7D329471@m0048141.ppops.net> --- bill at herrin.us wrote: From: William Herrin Interesting story about BGP and security in the Washington Post today: http://www.washingtonpost.com/sf/business/2015/05/31/net-of-insecurity-part-2/ ------------------------------------------------ Great article for the WP and they asked good questions from the correct people, but I have to take issue with the lack of network operator's participation comments: : But getting network operators to participate is proving : difficult. : Many network operators also are cool to taking the further : step of adopting a secure new routing protocol called BGPSEC : to replace BGP. : ?Unless [network] operators can see that the benefits will : generally outweigh the costs, they just won?t deploy it.? It's more that the managers who have no idea what is going on are forcing operators to focus their attention elsewhere, rather than the important things until everyone's behind the 8-ball. Then, all of the sudden, the mostly clueless managers are all about it. But, by then it's too late. Farting in a hurricane and hoping it makes a difference... ;-) scott From rdobbins at arbor.net Tue Jun 2 08:05:13 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 02 Jun 2015 15:05:13 +0700 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <20150602040707.382092FCB844@rock.dv.isc.org> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> Message-ID: <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> On 2 Jun 2015, at 11:07, Mark Andrews wrote: > If you have secure BGP deployed then you could extend the > authenication > to securely authenticate source addresses you emit and automate > BCP38 filter generation and then you wouldn't have to worry about > DNS, NTP, CHARGEN etc. reflecting spoofed traffic This can be and is done by networks which originate routes and which practice good network hygiene, no PKI required. But then we get into the customer of my customer (of my customer, of my customer . . .) problem, and this aren't quite so clear. There are also potentially significant drawbacks to incorporating PKI into the routing space, including new potential DoS vectors against PKI-enabled routing elements, the potential for enumeration of routing elements, and the possibility of building a true 'Internet kill switch' with effects far beyond what various governmental bodies have managed to do so far in the DNS space. Once governments figured out what the DNS was, they started to use it as a ban-hammer - what happens in a PKIed routing system once they figure out what BGP is? But nobody seems to be discussing these potential drawbacks, very much. ----------------------------------- Roland Dobbins From xxnog at ledeuns.net Tue Jun 2 08:46:33 2015 From: xxnog at ledeuns.net (Denis Fondras) Date: Tue, 2 Jun 2015 10:46:33 +0200 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> Message-ID: <20150602084632.GB3772@belenos> > the possibility of building a true 'Internet kill switch' with effects far > beyond what various governmental bodies have managed to do so far in the DNS > space. > Could you elaborate ? I don't see how it could be worse. Comparing with DNS is not relevant IMHO. Everyone is managing its own routing policy, not everyone is managing its own DNS root. Denis From rdobbins at arbor.net Tue Jun 2 09:01:40 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 02 Jun 2015 16:01:40 +0700 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <20150602084632.GB3772@belenos> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602084632.GB3772@belenos> Message-ID: <1C33EFCC-C6B5-41CC-B245-548F627EE6D6@arbor.net> On 2 Jun 2015, at 15:46, Denis Fondras wrote: > Everyone is managing its own routing policy, not everyone is managing > its own DNS root. Everyone CAN manage his own DNS root; everyone CAN use /etc/hosts; everyone CAN switch to an altogether different name resolution such as PNRP. Everyone CAN'T switch to an alternate global routing table. So, what happens when the authorities in some locale start pressing for the cancellation of relevant certificates utilized in routing PKI, and/or order operators under their jurisdiction to reject same? ----------------------------------- Roland Dobbins From owen at delong.com Tue Jun 2 09:01:38 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Jun 2015 10:01:38 +0100 Subject: AWS Elastic IP architecture In-Reply-To: References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> Message-ID: <4B0E0E3F-2327-4DF3-95FB-6DA96EE7DE08@delong.com> > On Jun 1, 2015, at 4:30 PM, Christopher Morrow wrote: > > On Mon, Jun 1, 2015 at 3:06 AM, Owen DeLong > wrote: >> >>> On May 31, 2015, at 7:46 PM, Christopher Morrow wrote: >>> >>> On Sun, May 31, 2015 at 9:07 PM, Owen DeLong wrote: >>>> As I said before: >>>> >>>> Host Virtual (vr.org ) >>>> Softlayer (softlayer.com ) >>>> Linode (Linode.com ) >>>> >>>> All have full dual-stack support. >>> >>> >>> >>>>> At the risk of feeding the troll... >>>>> >>>>> This isn't just an AWS problem. >>> >>> So... ok. What does it mean, for a customer of a cloud service, to be >>> ipv6 enabled? >> >> It means that I should be able to develop my cloud application(s) with full native IPv6 support and expect to be able to serve IPv4-only, IPv6-only, and dual-stack customers using native IP stacks on my virtual machines without requiring external proxies, translators, etc. from the cloud service provider. >> > > Ok, I suppose as a long term goal that seems fine. I don't get why > 'ipv6 address on my vm' matters a whole bunch (*in a world where v4 is > still available to you I mean), but as a long term goal, sure fine. Short term, I don?t want to have to pay to develop my application twice. I want to develop once for IPv6 and be done. Using IPV6_V6ONLY=FALSE socket option, I should be able to support both protocols from an application developed for IPv6 on machines which have both protocol capabilities. If you deliver to my native IPv6 or native IPv4 address, then i get real source addresses of the originator of the connection and I can develop my application normally and not have to re-engineer it around a protocol change later. If you don?t, then, if I care about the source of the connection request in my application, I either have to write the application to look elsewhere for it if the connection came in on IPv4, or, I have to get even more creative about it. Worse, it means that I?m having to maintain IPv4-specific cruft in my application some of which may be necessary to support IPv6 connections that arrive over IPv4 because I can?t get native IPv4. No, this is not a long-term goal, it?s a short-term need. Otherwise, my development costs are increased and my development time is extended. Additionally, the extra code creates additional opportunities for errors, security holes, etc. In short, there?s nothing good about not being able to develop a native application and there are many draw-backs. > In the short term though, that was my question: "What should be > prioritized, and then get that information to aws/gce/rackspace/etc > product managers" because I suspect their engineers are not silly, > they know that v6 should be part of the plan... but the PM folk are > saying: "No one is asking for this v6 thing, but lots of people want > that other shiney bauble...so build the shiney!!? I have little doubt that this is true. However, but the time all of their customers start screaming for IPv6, do you think they?re going to be ready/willing/able to wait the 6-18 months it will take to deploy it after that point? I think they?re going to be coming in crisis mode wondering how they can get IPv6 turned on yesterday. > >>> What really matters for a cloud service user? What information could >>> be surfaced to the cloud providers in order to get the most important >>> ipv6 'stuff' done 'now?? >> >> Ideally, simple native routing of IPv6 to provisioned hosts should suffice in most cases. >> >>> o Is it most important to be able to address ever VM you create with >>> an ipv6 address? >> >> Yes. >> > > long term sure, short term though.. really?? isn't it more important > to be able to terminate v6 services from 'public' users? (and v4 as > well because not everyone has v6 at home/work/mobile) Yes, but I need to be able to terminate the v6 services on the v6 socket on my VM, not on some proxy that masks the source address. If you have a 6->4 proxy/nat/whatever that somehow hands me a packet with an IPv6 from address in the IPv4 packet header, that?s a pretty neat trick. If you have operating system stacks that will support this and hand said source address to the application through the standard accept() API, that?s an even better trick. If you don?t have that for every platform supported on AWS (Linux/BSD/Win/etc.), then I think we need the above mentioned native connectivity, no? >>> o Is it most important to be able to talk to backend services (perhaps >>> at your prem) over ipv6? >> >> It?s hard to imagine how you could provide the first one above without having this one come along for the ride. >>> >>> o Is it most important that administrative interfaces to the VM >>> systems (either REST/etc interfaces for managing vms or 'ssh'/etc) be >>> ipv6 reachable? >> >> This would be the one where I would most be able to tolerate a delay. >> >>> o Is it most important to be able to terminate ipv6 connections (or >>> datagrams) on a VM service for the public to use? >> >> If you can?t get the first one, this might be adequate as a short-term fallback for some applications. However, it?s far from ideal and not all that useful. >> > > I agree it's not ideal, and I was making a list of 'short term goals' > that could be prioritized and get us all to the v6 utopia later. The thing is that in most cases, the sum of implementing this and managing it over a 3-6 month period is more effort than simply routing native IPv6 and adding IPv6 to your provisioning systems. As such, it?s hard for me to justify putting this short term goal in place vs. just deploying native IPv6 connectivity. >>> I don't see, especially if the vm networking is unique to each >>> customer, that 'ipv6 address on vm' is hugely important as a >>> first/important goal. I DO see that landing publicly available >>> services on an ipv6 endpoint is super helpful. >> >> Here?s the thing? In order to land IPv6 services without IPv6 support on the VM, you?re creating an environment where: >> >> 1. The services basically have to be supported by some form of proxy/nat/etc. >> So long as you are using a supported L4 protocol, that might be fine, but not everything fits in TCP/UDP/ICMP. >> Generally supporting GRE, IKE, and application-specific protocols becomes an issue. >> > > I figured the simplest path from v6 to v4 was: "Rip the header and > extension headers off, make a v4 packet, deliver to vm? How do you do that without masking the source address of the IPv6 host at the other end of the connection? If you don?t have a good answer to that question? This fails. > aside from "yes, your request came from " that should > 'just work', you do have to maintain some state to deliver back, > depending on the implementation (but even that is probably able to be > hidden from the 'user' and provisioned/capacity planned independent of > the 'user?). Sure, this is all fine and dandy from the user perspective, but it sucks in very big ways from the application developer perspective. Imagine running a service (let?s say not a web-based service for the moment) with 100s of thousands or even millions of users from all over the world. Now, imagine if every connection in your application logs came from 192.9.200.5. How, exactly, do you track where your users are coming from? How do you tell who connected from what network? How do you track down the abuser after you find him in log entries which share the same source address as everything else? > >> 2. The developer has to develop and maintain an IPv4-compatible codebase rather than be able to use >> the dual stack capabilities of a host with IPV6_V6ONLY=FALSE in the socket options. This delays the >> ability to produce native IPv6 applications. >> >> 3. Proxies and translators add complexity, increase fragility, and reduce performance. >> > > I think this point is cogent, but ... also part of the pie that 'aws' > pays for you the user... Or rather they run a 'service' which takes > care of this, has slas and slos... > "All packets delivered with 99.99% having Xms extra latency!" > "Service has 99.999% uptime!" > "Throughput comparable (99.99% at peak, 99% of the time) to > straight/native v4? I have yet to see a proxy/nat implementation that delivers on those numbers. Forgive my skepticism, but until this is demonstrated, I think I?d rather focus efforts on native deployments than miserable bandaids. >>> Would AWS (or any other cloud provider that's not currently up on the >>> v6 bandwagon) enabling a loadbalanced ipv6 vip for your public service >>> (perhaps not just http/s services even?) be enough to relieve some of >>> the pressure on other parties and move the ball forward meaningfully >>> enough for the cloud providers and their customers? >> >> For the reasons outlined above, I don?t really think so. > > ok, I figured that for short-term while the providers figure out: "Oh > yea, this v6 thing is pretty simple in our encap'd world... why didn't > we just turn it on originally?" > > getting v6 endpoints with little hassle for the 'user' (vm user) would > help us all a bunch. It might help some, but given the extent to which it complicates application development and breaks things unless you?re running the simplest case of web server, I don?t think it helps much. Owen From owen at delong.com Tue Jun 2 09:12:27 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Jun 2015 10:12:27 +0100 Subject: AWS Elastic IP architecture In-Reply-To: <556C9B15.7010403@matthew.at> References: <0FBA59E3-5EA1-4605-8418-EAC5D2564DB6@delong.com> <20150531091820.GQ724@hezmatt.org> <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010! 403@matthew.at> Message-ID: > On Jun 1, 2015, at 6:49 PM, Matthew Kaufman wrote: > > On 6/1/2015 12:06 AM, Owen DeLong wrote: >> ... Here?s the thing? In order to land IPv6 services without IPv6 support on the VM, you?re creating an environment where... > > Let's hypothetically say that it is much easier for the cloud provider if they provide just a single choice within their network, but allow both v4 and v6 access from the outside via a translator (to whichever one isn't native internally). > > Would you rather have: > 1) An all-IPv6 network inside, so the hosts can all talk to each other over IPv6 without using (potentially overlapping copies of) RFC1918 space... but where very little of the open-source software you build your services on works at all, because it either doesn't support IPv6 or they put some IPv6 support in but it is always lagging behind and the bugs don't get fixed in a timely manner. Or, Yes. For one thing, if AWS did this, the open source software would very quickly catch up and IPv4 would be the stack no longer getting primary maintenance in that software. Additionally, it?s easy for me to hide an IPv4 address in a translated to IPv6 packet header. Not so much the other way around. > 2) An all-IPv4 network inside, with the annoying (but well-known) use of RFC1918 IPv4 space and all your software stacks just work as they always have, only now the fraction of users who have IPv6 can reach them over IPv6 if they so choose (despite the connectivity often being worse than the IPv4 path) and the 2 people who are on IPv6-only networks can reach your services too. There are a lot more than 2 people on IPv6-only networks at this point. Most T-Mobile Droid users, for example are on an IPv6-only network at this time. True, T-Mo provides 464Xlat services for those users (which is why T-Mo doesn?t work for iOS users), but that?s still an IPv6-only network. > Until all of the common stacks that people build upon, including distributed databases, cache layers, web accelerators, etc. all work *better* when the native environment is IPv6, everyone will be choosing #2. To the best of my knowledge, Postgress, MySQL, Oracle, NoSQL all support IPv6. Squid and several other caches have full IPv6 support. We don?t even need better? We just need at least equal. However, if, instead of taking a proactive approach and deploying IPv6 in a useful way prior to calamity you would rather wait until the layers and layers of hacks that are increasingly necessary to keep IPv4 alive reach such a staggering proportion that no matter how bad the IPv6 environment may be, IPv4 is worse, I suppose that?s one way we can handle the transition. Personally, I?d rather opt for #1 early and use it to drive the necessary improvements to the codebases you mentioned and probably some others you didn?t. > And both #1 and #2 are cheaper and easier to manage that full dual-stack to every single host (because you pay all the cost of supporting v6 everywhere with none of the savings of not having to deal with the ever-increasing complexity of continuing to use v4) Sure, sort of. You actually do get some savings with dual-stack because you reduce the cost and the rate at which the iPv4 complexity continues to increase. You also reduce the time before you?ll be able to fully deprecate IPv4 and the amount of additional capital that has to be expended hacking, cobbling, and otherwise creating cruft for the sole purpose of keeping IPv4 alive and somewhat functional. Owen From george.tasioulis at gmail.com Tue Jun 2 08:18:31 2015 From: george.tasioulis at gmail.com (George Tasioulis) Date: Tue, 2 Jun 2015 11:18:31 +0300 Subject: WiFi courses/vendors recommendation In-Reply-To: <20150601172347.GK4389@bamboo.slabnet.com> References: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> <20150601172347.GK4389@bamboo.slabnet.com> Message-ID: On Mon, Jun 1, 2015 at 8:23 PM, Hugo Slabbert wrote: > Doubt how much PoE you'd use for the MetroWifi stuff, but for the > "small/medium events Wifi coverage": > > Ubiquiti Networks. >>> >>> Its cheap and it works great. Support sucks though. >>> >> > Just watch it here if you're expecting to plug UniFi APs into standard > 802.3af/at ports and get power. When I last interacted with them (customer > equipment; year or two old, I believe) a lot of their WAPs are 24V, not > 802.3af/at. Only their UniFi AP & AP-LR are 24V, all the rest of their product line (AP-PRO, AP-AC as well as the outdoor units) are 802.3af or 802.3at compliant. You can easily overcome this limitation by using their 8-port ToughSwitch were each POE port can be configured to either 24V or 48V. IMHO Ubiquity's UniFi is a very decent solution when you want to keep budget low. - G. From owen at delong.com Tue Jun 2 09:35:39 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Jun 2015 10:35:39 +0100 Subject: AWS Elastic IP architecture In-Reply-To: <556D35DF.8080901@matthew.at> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> Message-ID: <053A3A21-E0D8-4290-8AA1-5EABE5726756@delong.com> > On Jun 2, 2015, at 5:49 AM, Matthew Kaufman wrote: > > On 6/1/2015 6:32 PM, Mark Andrews wrote: >> In message >> , Christopher Morrow writes: >>> On Mon, Jun 1, 2015 at 9:02 PM, Ca By wrote: >>>> >>>> On Monday, June 1, 2015, Mark Andrews wrote: >>>>> >>>>> In message >>>>> >>>>> , Christopher Morrow writes: >>>>>> So... I don't really see any of the above arguments for v6 in a vm >>>>>> setup to really hold water in the short term at least. I think for >>>>>> sure you'll want v6 for public services 'soon' (arguably like 10 yrs >>>>>> ago so you'd get practice and operational experience and ...) but for >>>>>> the rest sure it's 'nice', and 'cute', but really not required for >>>>>> operations (unless you have v6 only customers) >>>>> Everyone has effectively IPv6-only customers today. IPv6 native + >>>>> CGN only works for services. Similarly DS-Lite and 464XLAT. >>> ok, and for the example of 'put my service in the cloud' ... the >>> service is still accessible over ipv4 right? >> It depends on what you are trying to do. Having something in the >> cloud manage something at home. You can't reach the home over IPv4 >> more and more these days as. IPv6 is the escape path for that but >> you need both ends to be able to speak IPv6. > > ...and for firewalls to not exist. Since they do, absolutely all the techniques required to "reach something at home" over IPv4 are required for IPv6. This is on the "great myths of the advantages of IPv6" list. IPv4 with NAT, you can open one host at home to remote access, or, in some cases, you can select different hosts by using the port number in lieu of the host name/address. IPv6 ? I add a permit statement to the firewall to allow the traffic in to each host/group of hosts that I want and I am done. I do not see the above as being equal effort or as yielding equal results. As such, I?d say that your statement gets added to the great myths of Matthew Kauffman rather than there being any myth about this being an IPv6 advantage. I can assure you that it is MUCH easier for me to remote-manage my mother?s machines over their IPv6 addresses than to get to them over IPv4. I live in California and have native dual-stack without NAT. She lives in Texas and has native dual-stack with NAT for her IPv4. > IPv6 has exactly one benefit... there's more addresses. It comes with a whole lot of new pain points, and probably a bunch of security nightmare still waiting to be discovered. And it for sure isn't free. IPv6 comes with at least one design-advantage ? More addresses. However, more addresses, especially on the scale IPv6 delivers them comes with MANY benefits: 1. Simplified addressing 2. Better aggregation 3. Direct access where permitted 4. Elimination of NAT and its security flaws and disadvantages 5. Simplified topologies 6. Better sunbathing 7. Better network planning with sparse allocations 8. Simpler application code 9. Reduced complexity in: Proxies Applications Firewalls Logging Monitoring Audit Intrusion Detection Intrusion Prevention DDoS mitigation 10. The ability to write software with hope of your codebase working for the next 10 years or more. I?m sure there are other benefits as well, but this gives you at least 10. There are those that would argue that other design advantages include: 1. Fixed length simplified header 2. Stateless Address Autoconfiguration 3. Mobile IP 4. A much cleaner implementation of IPSEC I?m sure there are more, but this is a quick list off the top of my head. Owen From matthew at matthew.at Tue Jun 2 15:08:45 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 02 Jun 2015 08:08:45 -0700 Subject: AWS Elastic IP architecture In-Reply-To: <20150602051208.E4F132FCC4B9@rock.dv.isc.org> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <20150602051208.E4F132FCC4B9@rock.dv.isc.org> Message-ID: <556DC6FD.7040801@matthew.at> On 6/1/15 10:12 PM, Mark Andrews wrote: > In message <556D35DF.8080901 at matthew.at>, Matthew Kaufman writes: >> On 6/1/2015 6:32 PM, Mark Andrews wrote: >>> In message > com >>>> , Christopher Morrow writes: >>>> On Mon, Jun 1, 2015 at 9:02 PM, Ca By wrote: >>>>> On Monday, June 1, 2015, Mark Andrews wrote: >>>>>> In message >>>>>> >>>>>> , Christopher Morrow writes: >>>>>>> So... I don't really see any of the above arguments for v6 in a vm >>>>>>> setup to really hold water in the short term at least. I think for >>>>>>> sure you'll want v6 for public services 'soon' (arguably like 10 yrs >>>>>>> ago so you'd get practice and operational experience and ...) but for >>>>>>> the rest sure it's 'nice', and 'cute', but really not required for >>>>>>> operations (unless you have v6 only customers) >>>>>> Everyone has effectively IPv6-only customers today. IPv6 native + >>>>>> CGN only works for services. Similarly DS-Lite and 464XLAT. >>>> ok, and for the example of 'put my service in the cloud' ... the >>>> service is still accessible over ipv4 right? >>> It depends on what you are trying to do. Having something in the >>> cloud manage something at home. You can't reach the home over IPv4 >>> more and more these days as. IPv6 is the escape path for that but >>> you need both ends to be able to speak IPv6. >> ...and for firewalls to not exist. Since they do, absolutely all the >> techniques required to "reach something at home" over IPv4 are required >> for IPv6. This is on the "great myths of the advantages of IPv6" list. > For IPv4 you port forward in the NAT possibly doing port translation > as will as address translation. Takes about 30 seconds in the web interface of your CPE. > > For IPv6 you open the port inbound in the firewall or just move the > firewalling to the host. Takes about 30 seconds in the web interface of your CPE. > > IPv6 is easier. With modern machines you really can get rid of the > firewall in front of the machine. For the good of the botnet operators, I encourage doing this. I can't run my laser printer without a firewall in front of it, and I can't even guess how secure the controller in the septic system pump box might be... so I don't risk it. And I *know* that some of the webcams I have are vulnerable and have no updates available. > Lots of the equipement that > connects to the home nets spends plenty of time fully exposed to > the Internet w/o a firewall. I don't believe that's accurate. > If it does that why does it need a > firewall at home? > > There is a myth that you need a firewall at home. Perpetuated by all the actual cases of poorly designed operating systems and embedded systems getting attacked and making the news as a result (http://www.insecam.org/ among others) > >> IPv6 has exactly one benefit... there's more addresses. It comes with a >> whole lot of new pain points, and probably a bunch of security nightmare >> still waiting to be discovered. And it for sure isn't free. > It also remove a whole lot of complications. Simplifies the security > profile. If you think that the NDP DOS exposure is a "simplification" of security, then I'd love to hear more about the benefits of IPv6. Matthew Kaufman From matthew at matthew.at Tue Jun 2 15:08:53 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 02 Jun 2015 08:08:53 -0700 Subject: AWS Elastic IP architecture In-Reply-To: <053A3A21-E0D8-4290-8AA1-5EABE5726756@delong.com> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <053A3A21-E0D8-4290-8AA1-5EABE5726756@delong.com> Message-ID: <556DC705.2090406@matthew.at> On 6/2/15 2:35 AM, Owen DeLong wrote: >> On Jun 2, 2015, at 5:49 AM, Matthew Kaufman wrote: >> >> On 6/1/2015 6:32 PM, Mark Andrews wrote: >>> In message >>> , Christopher Morrow writes: >>>> On Mon, Jun 1, 2015 at 9:02 PM, Ca By wrote: >>>>> On Monday, June 1, 2015, Mark Andrews wrote: >>>>>> In message >>>>>> >>>>>> , Christopher Morrow writes: >>>>>>> So... I don't really see any of the above arguments for v6 in a vm >>>>>>> setup to really hold water in the short term at least. I think for >>>>>>> sure you'll want v6 for public services 'soon' (arguably like 10 yrs >>>>>>> ago so you'd get practice and operational experience and ...) but for >>>>>>> the rest sure it's 'nice', and 'cute', but really not required for >>>>>>> operations (unless you have v6 only customers) >>>>>> Everyone has effectively IPv6-only customers today. IPv6 native + >>>>>> CGN only works for services. Similarly DS-Lite and 464XLAT. >>>> ok, and for the example of 'put my service in the cloud' ... the >>>> service is still accessible over ipv4 right? >>> It depends on what you are trying to do. Having something in the >>> cloud manage something at home. You can't reach the home over IPv4 >>> more and more these days as. IPv6 is the escape path for that but >>> you need both ends to be able to speak IPv6. >> ...and for firewalls to not exist. Since they do, absolutely all the techniques required to "reach something at home" over IPv4 are required for IPv6. This is on the "great myths of the advantages of IPv6" list. > IPv4 with NAT, you can open one host at home to remote access, or, in some cases, you can select different hosts by using the port number in lieu of the host name/address. IPv4 with NAT, standard NAT/firewall traversal techniques are used so that things inside your house are reachable as necessary. Almost nobody configures their firewall to open up anything. > > IPv6 ? I add a permit statement to the firewall to allow the traffic in to each host/group of hosts that I want and I am done. IPv6, standard NAT?firewall traversal techniques are used so that things inside your house are reachable as necessary. Still almost nobody configures their firewall to open up anything. For those who do, the work needed to open up a few host/port mappings in IPv4 is basically identical to opening up a few hosts and ports for IPv6. > > I do not see the above as being equal effort or as yielding equal results. For the automatic traversal cases, the end-user effort is identical. For the incredibly rare case of manual configuration (which as NANOG participants we often forget, since we're adjusting our routers all the time) there is almost no difference for most use cases. Yes, the results are marginally superior in the IPv6 case. Nobody cares. > > As such, I?d say that your statement gets added to the great myths of Matthew Kauffman rather than there being any myth about this being an IPv6 advantage. > > I can assure you that it is MUCH easier for me to remote-manage my mother?s machines over their IPv6 addresses than to get to them over IPv4. Only because you've insisted on doing it the hard way, instead of using something like teamviewer or logmein which "just works". > I live in California and have native dual-stack without NAT. She lives in Texas and has native dual-stack with NAT for her IPv4. And I assume your mother opened up her IPv6 firewall all on her own? Most people won't have the technical skills to adjust the IPv6 firewall that comes with their CPE and/or "Wireless Router" any more than they have the skills to set up IPv4 port mapping. >> IPv6 has exactly one benefit... there's more addresses. It comes with a whole lot of new pain points, and probably a bunch of security nightmare still waiting to be discovered. And it for sure isn't free. > IPv6 comes with at least one design-advantage ? More addresses. > > However, more addresses, especially on the scale IPv6 delivers them comes with MANY benefits: > > 1. Simplified addressing > 2. Better aggregation > 3. Direct access where permitted > 4. Elimination of NAT and its security flaws and disadvantages > 5. Simplified topologies > 6. Better sunbathing > 7. Better network planning with sparse allocations All of those are benefits for the network operator, not the end user. > 8. Simpler application code Might be true *if* there was only IPv6. If there's also the need to support IPv4 then supporting *both* is harder than supporting just one. > 9. Reduced complexity in: > Proxies > Applications > Firewalls > Logging > Monitoring > Audit > Intrusion Detection > Intrusion Prevention > DDoS mitigation Matters not to most home users. Doesn't help corporate users because they also need all that for IPv4 indefinitely. > 10. The ability to write software with hope of your codebase working for the next 10 years or more. I'll bet that there's IPv4 devices running happily 10 years from now. > > I?m sure there are other benefits as well, but this gives you at least 10. > > There are those that would argue that other design advantages include: > > 1. Fixed length simplified header Maybe. > 2. Stateless Address Autoconfiguration Disaster, given that I'm still stuck needing DHCPv6 to configure everything that SLAAC won't. Or things that SLAAC only picked up recently (like setting your DNS server) and so are still unsupported in all sorts of gear. > 3. Mobile IP Remains to be seen if this matters. > 4. A much cleaner implementation of IPSEC Sure, but the IPv4 IPSEC seems to work just fine everywhere I've deployed it. > > I?m sure there are more, but this is a quick list off the top of my head. There's a bunch of myths too... and "every device will be directly reachable from the entire Internet" is on there. Matthew Kaufman From dwcarder at wisc.edu Tue Jun 2 15:12:33 2015 From: dwcarder at wisc.edu (Dale W. Carder) Date: Tue, 02 Jun 2015 10:12:33 -0500 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> Message-ID: <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> Thus spake Roland Dobbins (rdobbins at arbor.net) on Tue, Jun 02, 2015 at 03:05:13PM +0700: > > On 2 Jun 2015, at 11:07, Mark Andrews wrote: > > >If you have secure BGP deployed then you could extend the authenication > >to securely authenticate source addresses you emit and automate > >BCP38 filter generation and then you wouldn't have to worry about > >DNS, NTP, CHARGEN etc. reflecting spoofed traffic > > This can be and is done by networks which originate routes and which > practice good network hygiene, no PKI required. > > But then we get into the customer of my customer (of my customer, of my > customer . . .) problem, and this aren't quite so clear. > > There are also potentially significant drawbacks to incorporating PKI into > the routing space, including new potential DoS vectors against PKI-enabled > routing elements, the potential for enumeration of routing elements, and the > possibility of building a true 'Internet kill switch' with effects far > beyond what various governmental bodies have managed to do so far in the DNS > space. > > Once governments figured out what the DNS was, they started to use it as a > ban-hammer - what happens in a PKIed routing system once they figure out > what BGP is? > > But nobody seems to be discussing these potential drawbacks, very much. Start here: https://www.cs.bu.edu/~goldbe/papers/hotRPKI_full.pdf Dale From lorell at hathcock.org Tue Jun 2 16:00:44 2015 From: lorell at hathcock.org (Lorell Hathcock) Date: Tue, 2 Jun 2015 11:00:44 -0500 Subject: Password Decryption Methods? Message-ID: <017b01d09d4d$490ac6b0$db205410$@hathcock.org> All: I have a video camera that I need to recover the password. I have a password hash that is stored in a database, but any online decryption sites are not working. Can someone push me in the right direction on where I go from here? Thanks, Lorell From shopik at inblock.ru Tue Jun 2 16:21:12 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Tue, 2 Jun 2015 19:21:12 +0300 Subject: AWS Elastic IP architecture In-Reply-To: <556DC6FD.7040801@matthew.at> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <20150602051208.E4F132FCC4B9@rock.dv.isc.org> <556DC6FD.7040801@matthew.at> Message-ID: <556DD7F8.7090004@inblock.ru> Tell me how do you plan find printer in /64 subnet, scan it? On 02.06.2015 18:08, Matthew Kaufman wrote: > > I can't run my laser printer without a firewall in front of it, and I > can't even guess how secure the controller in the septic system pump box > might be... so I don't risk it. And I *know* that some of the webcams I > have are vulnerable and have no updates available. From michael.holstein at csuohio.edu Tue Jun 2 16:23:26 2015 From: michael.holstein at csuohio.edu (Michael O Holstein) Date: Tue, 2 Jun 2015 16:23:26 +0000 Subject: Password Decryption Methods? In-Reply-To: <017b01d09d4d$490ac6b0$db205410$@hathcock.org> References: <017b01d09d4d$490ac6b0$db205410$@hathcock.org> Message-ID: Need to recover the *actual* password because of forensic reasons? .. if it's just for usability then 100% of the units I've encountered have some reset routine that wipes the defaults and resets to admin:admin (or whatever). If it was forensics it'd probably be faster to just image the flash chip (hopefully leaded and not BGA but rework isn't *that* hard). It's probably salted by the firmware, sometimes the salt is static in the firmware, sometimes it's a derivative of something like the hardware address. If you can share the other details (make, model, firmware revision, processor type, etc.) .. whatever you know and can share) .. it would be more helpful. Also, how'd you get the hash? .. from a config file backup or from another device that used it to access this one? If so, what software, etc. Cheers, Michael Holstein Cleveland State University ________________________________________ From: NANOG on behalf of Lorell Hathcock Sent: Tuesday, June 2, 2015 12:00 PM To: nanog at nanog.org Subject: Password Decryption Methods? All: I have a video camera that I need to recover the password. I have a password hash that is stored in a database, but any online decryption sites are not working. Can someone push me in the right direction on where I go from here? Thanks, Lorell From mikea at mikea.ath.cx Tue Jun 2 16:33:10 2015 From: mikea at mikea.ath.cx (mikea) Date: Tue, 2 Jun 2015 11:33:10 -0500 Subject: AWS Elastic IP architecture In-Reply-To: <556DD7F8.7090004@inblock.ru> References: <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <20150602051208.E4F132FCC4B9@rock.dv.isc.org> <556DC6FD.7040801@matthew.at> <556DD7F8.7090004@inblock.ru> Message-ID: <20150602163309.GA31816@mikea.ath.cx> On Tue, Jun 02, 2015 at 07:21:12PM +0300, Nikolay Shopik wrote: > Tell me how do you plan find printer in /64 subnet, scan it? > > On 02.06.2015 18:08, Matthew Kaufman wrote: > > > > I can't run my laser printer without a firewall in front of it, and I > > can't even guess how secure the controller in the septic system pump box > > might be... so I don't risk it. And I *know* that some of the webcams I > > have are vulnerable and have no updates available. Security by obscurity? Come, now. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From matthew at matthew.at Tue Jun 2 16:35:11 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 2 Jun 2015 09:35:11 -0700 Subject: AWS Elastic IP architecture In-Reply-To: <556DD7F8.7090004@inblock.ru> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <20150602051208.E4F132FCC4B9@rock.dv.isc.org> <556DC6FD.7040801@matthew.at> <556DD7F8.7090004@inblock.r u> Message-ID: Ah, the "IPv6 subnets are so big you can't find the hosts" myth. Let's see... to find which hosts are active in IPv6 I can: - run a popular web service that people connect to, revealing their addresses - run a DNS server that lots of folks directly use (see Google) - use the back door login your router vendor provided and ask - query your unsecured public SNMP and ask - get you to install software that sends back a list of what's on your subnet - make educated guesses about your non-privacy IP addresses based on the MAC address ranges of popular hardware that is available in stores this year to reduce the search space to a manageable size - hack the site where you get automatic updates from and use its logs That's just off the top of my head Matthew Kaufman (Sent from my iPhone) > On Jun 2, 2015, at 9:21 AM, Nikolay Shopik wrote: > > Tell me how do you plan find printer in /64 subnet, scan it? > >> On 02.06.2015 18:08, Matthew Kaufman wrote: >> >> I can't run my laser printer without a firewall in front of it, and I >> can't even guess how secure the controller in the septic system pump box >> might be... so I don't risk it. And I *know* that some of the webcams I >> have are vulnerable and have no updates available. From shopik at inblock.ru Tue Jun 2 17:01:31 2015 From: shopik at inblock.ru (Nikolay Shopik) Date: Tue, 2 Jun 2015 20:01:31 +0300 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <20150602051208.E4F132FCC4B9@rock.dv.isc.org> <556DC6FD.7040801@matthew.at> <556DD7F8.7090004@inblock.r u> Message-ID: <556DE16B.6000106@inblock.ru> Matthew, Good list - Windows doesn't run non-privacy addresses, so it won't work next time. - If you could guess address of router props to you - Before using SNMP you still need device address. - If you can install software on remote PC, when you probably have same result in IPv4 world. - If you able run popular web/DNS server you probably have already enough money from elsewhere unless someone offer you more money to sell that info and this applies both to IPv4 and IPv6 regardless of firewall. So I'm not saying IPv6 doing just fine w/o firewall, just that it doing much better than IPv4 and its NAT with security through obscurity. And especially from simple kind attacks. On 02.06.2015 19:35, Matthew Kaufman wrote: > Ah, the "IPv6 subnets are so big you can't find the hosts" myth. > > Let's see... to find which hosts are active in IPv6 I can: > - run a popular web service that people connect to, revealing their addresses > - run a DNS server that lots of folks directly use (see Google) > - use the back door login your router vendor provided and ask > - query your unsecured public SNMP and ask > - get you to install software that sends back a list of what's on your subnet > - make educated guesses about your non-privacy IP addresses based on the MAC address ranges of popular hardware that is available in stores this year to reduce the search space to a manageable size > - hack the site where you get automatic updates from and use its logs > > That's just off the top of my head > > Matthew Kaufman > > (Sent from my iPhone) > >> On Jun 2, 2015, at 9:21 AM, Nikolay Shopik wrote: >> >> Tell me how do you plan find printer in /64 subnet, scan it? >> >>> On 02.06.2015 18:08, Matthew Kaufman wrote: >>> >>> I can't run my laser printer without a firewall in front of it, and I >>> can't even guess how secure the controller in the septic system pump box >>> might be... so I don't risk it. And I *know* that some of the webcams I >>> have are vulnerable and have no updates available. From arlingtonalbertson at gmail.com Tue Jun 2 18:12:02 2015 From: arlingtonalbertson at gmail.com (Arlington Albertson) Date: Tue, 2 Jun 2015 11:12:02 -0700 Subject: Any routing issues with TWT in Seattle today? Message-ID: Hey folks, Just wondering if anyone is seeing any issues with TWT routing this morning around Seattle. We've seen a few routing problems and connection issues which appear to be related to this. -AA From alejandroacostaalamo at gmail.com Tue Jun 2 19:34:09 2015 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Tue, 02 Jun 2015 15:04:09 -0430 Subject: MaxMind contact Message-ID: <556E0531.1060101@gmail.com> Hi there, Sorry for the noise. Is there anyone from MaxMind on here? I would appreciate it if anyone on, or off-list can provide any contact details Thanks in advance, Alejandro Acosta, From landonstewart at gmail.com Tue Jun 2 20:01:53 2015 From: landonstewart at gmail.com (Landon Stewart) Date: Tue, 2 Jun 2015 13:01:53 -0700 Subject: Password Decryption Methods? In-Reply-To: References: <017b01d09d4d$490ac6b0$db205410$@hathcock.org> Message-ID: <565039F3-0F10-4BF9-B7FA-ECEC757671D8@gmail.com> On Jun 2, 2015, at 9:23 AM, Michael O Holstein wrote: > If you can share the other details (make, model, firmware revision, processor type, etc.) .. whatever you know and can share) .. it would be more helpful. Also, how'd you get the hash? .. from a config file backup or from another device that used it to access this one? If so, what software, etc. Serial # too. :-D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 909 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pavel.odintsov at gmail.com Tue Jun 2 20:16:16 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 2 Jun 2015 23:16:16 +0300 Subject: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation Message-ID: Hello, Nanog! I'm very pleased to present my open source DoS/DDoS attack monitoring toolkit here! We have spent about 10 months for development of FastNetMon and could present huge feature list now! :) Stop! What is FastNetMon? It's really very fast toolkit which could find attacked host in your network and block it (or redirect to filtering appliance) This solution could save your network and your sleep :) Our site located here: https://github.com/FastVPSEestiOu/fastnetmon We support following engines for traffic capture: - Netflow (v5, v9 and IPFIX) - sFLOW v5 - port mirror/SPAN (PF_RING and netmap supported) Also we have deep integration with ExaBGP (huge thanks to Thomas Mangin) for triggering blackhole on the Core Router or upstream. Since 1.0 version we have added support for following features: - Ability to detect most popular attack types: syn_flood, icmp_flood, udp_flood, ip_fragmentation_flood - Add support for Netmap for Linux (we have prepared special driver for ixgbe users: https://github.com/pavel-odintsov/ixgbe-linux-netmap) and FreeBSD. - Add support for PF_RING ZC (very fast but need license from ntop folks) - Add ability to collect netflow v9/IPFIX data from multiple devices with different templates set - Basic support for IPv6 (we could receive netflow data over IPv6) - Add plugin support for capture engines - Add support of L2TP decapsulation (important for DDoS attack detection inside tunnel) - Add ability to store attack details in Redis - Add Graphite/Grafana integration for traffic visualization - Add systemd unit file - Add ability to unblock host after some timeout - Introduce support of moving average for all counters - Add ExaBGP integration. We could announce attacked host with BGP to border router or uplink - Add so much details in attack report - Add ability to store attack fingerprint in file We have complete support for following platforms: - Fedora 21 - Debian 6, 7, 8 - CentOS 6, 7 - FreeBSD 9, 10, 11 - DragonflyBSD 4 - MacOS X 10.10 >From network equipment side we have tested solution with: - Cisco ASR - Juniper MX - Extreme Summit - ipt_NETFLOW Linux We have binary packages for this operation systems: - CentOS 6: https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/CentOS6 - CentOS 7: https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/CentOS7 - Fedora 21: https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/Fedora21 - FreeBSD: https://github.com/FastVPSEestiOu/fastnetmon/tree/master/src/FreeBSD_port For any other operation systems we recommend automatic installer script: https://github.com/FastVPSEestiOu/fastnetmon/blob/master/docs/INSTALL.md Please join to our mail list or ask about anything here https://groups.google.com/forum/#!forum/fastnetmon Thank you for your attention! -- Sincerely yours, Pavel Odintsov From surfer at mauigateway.com Tue Jun 2 23:00:38 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 2 Jun 2015 16:00:38 -0700 Subject: BGP Multihoming 2 providers full or partial? Message-ID: <20150602160038.7D324403@m0048141.ppops.net> but I don't do email like that why is it hard to read? it's really hard to read email this way. because it's out of order umm, ok. I fixed it for you ----------------------------------------- You've obviously never been hounded by sales folks scraping this list that believe they should never give up. It's painful to say the least. If every "Product Evangelist" were allowed to do this, NANOG would be a nightmare. To others out there thinking of doing the same, again I say Please read #5 https://www.nanog.org/list ------------------------------------------ --------- nanog at ics-il.net wrote: ---------- From: Mike Hammett Probably not NANOG, but I have way more traffic on many other lists over the last 12+ years. I'm no stranger to over-zealous sales guys. I've started blocking the ones that call my support line and talking to the call center, despite the warning that support is only for my customers. ------------------------------------------ So, why-oh-why encourage them here? I'm done with this non-thread and fixing out of order postings. Way too much work for me, but I'm sure it's easier for you. No matter what either of us thinks NANOG's AUP specifically states "Product marketing is prohibited." and "Using list as source for private marketing initiatives is prohibited." [FIN, ACK, Seq=2many, Len=0] scott From marka at isc.org Tue Jun 2 23:14:55 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 03 Jun 2015 09:14:55 +1000 Subject: AWS Elastic IP architecture In-Reply-To: Your message of "Tue, 02 Jun 2015 08:08:45 -0700." <556DC6FD.7040801@matthew.at> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <20150602051208.E4F132FCC4B9@rock.dv.isc.org> <556DC6 FD.7040801@matthew.at> Message-ID: <20150602231456.B04842FD0AA7@rock.dv.isc.org> In message <556DC6FD.7040801 at matthew.at>, Matthew Kaufman writes: > > On 6/1/15 10:12 PM, Mark Andrews wrote: > > In message <556D35DF.8080901 at matthew.at>, Matthew Kaufman writes: > >> On 6/1/2015 6:32 PM, Mark Andrews wrote: > >>> In message >> com > >>>> , Christopher Morrow writes: > >>>> On Mon, Jun 1, 2015 at 9:02 PM, Ca By wrote: > >>>>> On Monday, June 1, 2015, Mark Andrews wrote: > >>>>>> In message > >>>>>> > >>>>>> , Christopher Morrow writes: > >>>>>>> So... I don't really see any of the above arguments for v6 in a vm > >>>>>>> setup to really hold water in the short term at least. I think for > >>>>>>> sure you'll want v6 for public services 'soon' (arguably like 10 yrs > >>>>>>> ago so you'd get practice and operational experience and ...) but for > >>>>>>> the rest sure it's 'nice', and 'cute', but really not required for > >>>>>>> operations (unless you have v6 only customers) > >>>>>> Everyone has effectively IPv6-only customers today. IPv6 native + > >>>>>> CGN only works for services. Similarly DS-Lite and 464XLAT. > >>>> ok, and for the example of 'put my service in the cloud' ... the > >>>> service is still accessible over ipv4 right? > >>> It depends on what you are trying to do. Having something in the > >>> cloud manage something at home. You can't reach the home over IPv4 > >>> more and more these days as. IPv6 is the escape path for that but > >>> you need both ends to be able to speak IPv6. > >> ...and for firewalls to not exist. Since they do, absolutely all the > >> techniques required to "reach something at home" over IPv4 are required > >> for IPv6. This is on the "great myths of the advantages of IPv6" list. > > For IPv4 you port forward in the NAT possibly doing port translation > > as will as address translation. > > Takes about 30 seconds in the web interface of your CPE. > > > > > For IPv6 you open the port inbound in the firewall or just move the > > firewalling to the host. > > Takes about 30 seconds in the web interface of your CPE. > > > > > IPv6 is easier. With modern machines you really can get rid of the > > firewall in front of the machine. > > For the good of the botnet operators, I encourage doing this. > > I can't run my laser printer without a firewall in front of it, and I > can't even guess how secure the controller in the septic system pump box > might be... so I don't risk it. And I *know* that some of the webcams I > have are vulnerable and have no updates available. Well send the printer back as defective which it is. As for the controller of the septic system pump box it should be able to be on the net without a firewall in front of it. > > Lots of the equipement that > > connects to the home nets spends plenty of time fully exposed to > > the Internet w/o a firewall. > > I don't believe that's accurate. All the laptops, phones, tablets, e-readers spend some time connect without a firewall in front of them. A Windows box hasn't needed a firewall in front of it Windows XP SP2. Macs don't need firewalls in front of them. Linux boxes don't need firewalls in front of them. About the only thing the border router should be doing is preventing spoofed "internal" packets from coming in and filtering non-locally sourced packets leaving. There really shouldn't be any to filter legitimately addressed packets. If there is then the product is defective. > > If it does that why does it need a > > firewall at home? > > > > There is a myth that you need a firewall at home. > > Perpetuated by all the actual cases of poorly designed operating systems > and embedded systems getting attacked and making the news as a result > (http://www.insecam.org/ among others) So send the cameras back to the manufacture/retailer for a fix/refund. > >> IPv6 has exactly one benefit... there's more addresses. It comes with a > >> whole lot of new pain points, and probably a bunch of security nightmare > >> still waiting to be discovered. And it for sure isn't free. > > It also remove a whole lot of complications. Simplifies the security > > profile. > > If you think that the NDP DOS exposure is a "simplification" of > security, then I'd love to hear more about the benefits of IPv6. Even with that it simplifies security. Routers will get code to work around that. > Matthew Kaufman -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Wed Jun 3 00:05:12 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 03 Jun 2015 10:05:12 +1000 Subject: BGP in the Washngton Post In-Reply-To: Your message of "Mon, 01 Jun 2015 19:56:28 +0300." <556C8EBC.7080109@netassist.ua> References: <556C8EBC.7080109@netassist.ua> Message-ID: <20150603000513.D8EC12FD407E@rock.dv.isc.org> In message <556C8EBC.7080109 at netassist.ua>, Max Tulyev writes: > Is there *IN THEIORY* any possibility to make BGP secure enough now? > > Yes, RPKI protects from fat fingered people, but NOT protects from > people doing hijacks knowlingly. At the moment because not enough of the net is covered. When you get enough coverage then yes it will protect you because there is no way to get a valid CERT to authenticate the hijack. Even before that RPKI will limit the impact of the hijack by isolating the attack to the networks close to the injection points. Think of this as herd immunity. > The global routing registry really can be the solution, but it > automatically gives one authority a power to cut off any network. > Imagine how fast it will be used for censorship. > On 01.06.15 16:24, William Herrin wrote: > > Interesting story about BGP and security in the Washington Post today: > > > > http://www.washingtonpost.com/sf/business/2015/05/31/net-of-insecurity-part-2/ > > > > -Bill > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From labguy at gmail.com Wed Jun 3 01:06:42 2015 From: labguy at gmail.com (labguy at gmail.com) Date: Tue, 2 Jun 2015 19:06:42 -0600 Subject: WiFi courses/vendors recommendation In-Reply-To: References: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> <20150601172347.GK4389@bamboo.slabnet.com> Message-ID: With respect to vendor neutral training I would suggest starting with CWNP @ www.cwnp.com. They specialize in providing vendor-neutral Wi-Fi training and certification. Instructor led training is available via certified training partners. In addition, there are study guides available for purchase. CWTS (lvl 0) - Intro - terms & lingo CWNA (lvl 1) - Wi-Fi 101 CWSP (lvl 2) - Wi-Fi Security CWDP (lvl 2) - Wi-Fi Design CWAP (lvl2) - Wi-Fi Protocol Analysis CWNE (lvl3).... I recommend completing some or all the CWNP training to understand how Wi-Fi works. Once you understand how Wi-Fi works, you'll know how to design and configure a network to meet your design goals. Next, complement your vendor neutral training with applicable vendor specific training to understand their interface and specific nuances. Moving to another vendor is just a matter of learning where the nerd knobs are for configuring their product as you'll already know the fundamentals of Wi-Fi. Kindest regards, Troy -- *Troy Martin* | M 403.966.4370 On Tue, Jun 2, 2015 at 2:18 AM, George Tasioulis wrote: > On Mon, Jun 1, 2015 at 8:23 PM, Hugo Slabbert wrote: > > > Doubt how much PoE you'd use for the MetroWifi stuff, but for the > > "small/medium events Wifi coverage": > > > > Ubiquiti Networks. > >>> > >>> Its cheap and it works great. Support sucks though. > >>> > >> > > Just watch it here if you're expecting to plug UniFi APs into standard > > 802.3af/at ports and get power. When I last interacted with them > (customer > > equipment; year or two old, I believe) a lot of their WAPs are 24V, not > > 802.3af/at. > > > Only their UniFi AP & AP-LR are 24V, all the rest of their product line > (AP-PRO, AP-AC as well as the outdoor units) are 802.3af or 802.3at > compliant. > You can easily overcome this limitation by using their 8-port ToughSwitch > were each POE port can be configured to either 24V or 48V. > IMHO Ubiquity's UniFi is a very decent solution when you want to keep > budget low. > > - G. > From josh at spitwspots.com Wed Jun 3 01:12:38 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Tue, 02 Jun 2015 17:12:38 -0800 Subject: WiFi courses/vendors recommendation In-Reply-To: References: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> <20150601172347.GK4389@bamboo.slabnet.com> Message-ID: <556E5486.9000605@spitwspots.com> If he's wanting to make a "metro/muni/variousterm" "wireless" network though, he's very likely not going to be using "Wi-Fi" at all. Sure, many of the products may have a WiFi PHY layer, but for outdoor PtMP environments you're talking TDMA, not CSMA. He would be better served by some RF Engineering and vendor specific courses, IMO. (Just my $0.02 as having spent quite a bit of time in the WISP industry, who has watched these "metro/muni/variousterm" networks die over and over and over again.) Josh Reynolds CIO, SPITwSPOTS www.spitwspots.com On 06/02/2015 05:06 PM, labguy at gmail.com wrote: > With respect to vendor neutral training I would suggest starting with CWNP > @ www.cwnp.com. > > They specialize in providing vendor-neutral Wi-Fi training and > certification. Instructor led training is available via certified training > partners. In addition, there are study guides available for purchase. > CWTS (lvl 0) - Intro - terms & lingo > CWNA (lvl 1) - Wi-Fi 101 > CWSP (lvl 2) - Wi-Fi Security > CWDP (lvl 2) - Wi-Fi Design > CWAP (lvl2) - Wi-Fi Protocol Analysis > CWNE (lvl3).... > > I recommend completing some or all the CWNP training to understand how > Wi-Fi works. Once you understand how Wi-Fi works, you'll know how to > design and configure a network to meet your design goals. Next, complement > your vendor neutral training with applicable vendor specific training to > understand their interface and specific nuances. Moving to another vendor > is just a matter of learning where the nerd knobs are for configuring their > product as you'll already know the fundamentals of Wi-Fi. > > > Kindest regards, > Troy > > -- > *Troy Martin* | M 403.966.4370 > > On Tue, Jun 2, 2015 at 2:18 AM, George Tasioulis > wrote: >> On Mon, Jun 1, 2015 at 8:23 PM, Hugo Slabbert wrote: >> >>> Doubt how much PoE you'd use for the MetroWifi stuff, but for the >>> "small/medium events Wifi coverage": >>> >>> Ubiquiti Networks. >>>>> Its cheap and it works great. Support sucks though. >>>>> >>> Just watch it here if you're expecting to plug UniFi APs into standard >>> 802.3af/at ports and get power. When I last interacted with them >> (customer >>> equipment; year or two old, I believe) a lot of their WAPs are 24V, not >>> 802.3af/at. >> >> Only their UniFi AP & AP-LR are 24V, all the rest of their product line >> (AP-PRO, AP-AC as well as the outdoor units) are 802.3af or 802.3at >> compliant. >> You can easily overcome this limitation by using their 8-port ToughSwitch >> were each POE port can be configured to either 24V or 48V. >> IMHO Ubiquity's UniFi is a very decent solution when you want to keep >> budget low. >> >> - G. >> From nanog at ics-il.net Wed Jun 3 01:40:24 2015 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 2 Jun 2015 20:40:24 -0500 (CDT) Subject: BGP Multihoming 2 providers full or partial? In-Reply-To: <20150602160038.7D324403@m0048141.ppops.net> Message-ID: <25781823.5834.1433295600900.JavaMail.mhammett@ThunderFuck> I wouldn't call that product marketing. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Scott Weeks" To: nanog at nanog.org Sent: Tuesday, June 2, 2015 6:00:38 PM Subject: Re: BGP Multihoming 2 providers full or partial? but I don't do email like that why is it hard to read? it's really hard to read email this way. because it's out of order umm, ok. I fixed it for you ----------------------------------------- You've obviously never been hounded by sales folks scraping this list that believe they should never give up. It's painful to say the least. If every "Product Evangelist" were allowed to do this, NANOG would be a nightmare. To others out there thinking of doing the same, again I say Please read #5 https://www.nanog.org/list ------------------------------------------ --------- nanog at ics-il.net wrote: ---------- From: Mike Hammett Probably not NANOG, but I have way more traffic on many other lists over the last 12+ years. I'm no stranger to over-zealous sales guys. I've started blocking the ones that call my support line and talking to the call center, despite the warning that support is only for my customers. ------------------------------------------ So, why-oh-why encourage them here? I'm done with this non-thread and fixing out of order postings. Way too much work for me, but I'm sure it's easier for you. No matter what either of us thinks NANOG's AUP specifically states "Product marketing is prohibited." and "Using list as source for private marketing initiatives is prohibited." [FIN, ACK, Seq=2many, Len=0] scott From ethan at cs.washington.edu Wed Jun 3 02:04:31 2015 From: ethan at cs.washington.edu (Ethan Katz-Bassett) Date: Wed, 03 Jun 2015 02:04:31 +0000 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> Message-ID: The same folks also followed up that workshop paper with a longer paper on the topic: https://www.cs.bu.edu/~goldbe/papers/sigRPKI.pdf On Tue, Jun 2, 2015 at 8:16 AM Dale W. Carder wrote: > Thus spake Roland Dobbins (rdobbins at arbor.net) on Tue, Jun 02, 2015 at > 03:05:13PM +0700: > > > > On 2 Jun 2015, at 11:07, Mark Andrews wrote: > > > > >If you have secure BGP deployed then you could extend the authenication > > >to securely authenticate source addresses you emit and automate > > >BCP38 filter generation and then you wouldn't have to worry about > > >DNS, NTP, CHARGEN etc. reflecting spoofed traffic > > > > This can be and is done by networks which originate routes and which > > practice good network hygiene, no PKI required. > > > > But then we get into the customer of my customer (of my customer, of my > > customer . . .) problem, and this aren't quite so clear. > > > > There are also potentially significant drawbacks to incorporating PKI > into > > the routing space, including new potential DoS vectors against > PKI-enabled > > routing elements, the potential for enumeration of routing elements, and > the > > possibility of building a true 'Internet kill switch' with effects far > > beyond what various governmental bodies have managed to do so far in the > DNS > > space. > > > > Once governments figured out what the DNS was, they started to use it as > a > > ban-hammer - what happens in a PKIed routing system once they figure out > > what BGP is? > > > > But nobody seems to be discussing these potential drawbacks, very much. > > Start here: > https://www.cs.bu.edu/~goldbe/papers/hotRPKI_full.pdf > > Dale > From marka at isc.org Wed Jun 3 02:18:07 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 03 Jun 2015 12:18:07 +1000 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: Your message of "Tue, 02 Jun 2015 10:12:33 -0500." <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> Message-ID: <20150603021808.DE5002FD6281@rock.dv.isc.org> In message <20150602151233.GA29050 at DOIT-2NW1MRFY-X.doit.wisc.edu>, "Dale W. Car der" writes: > Thus spake Roland Dobbins (rdobbins at arbor.net) on Tue, Jun 02, 2015 at 03:05: > 13PM +0700: > > > > On 2 Jun 2015, at 11:07, Mark Andrews wrote: > > > > >If you have secure BGP deployed then you could extend the authenication > > >to securely authenticate source addresses you emit and automate > > >BCP38 filter generation and then you wouldn't have to worry about > > >DNS, NTP, CHARGEN etc. reflecting spoofed traffic > > > > This can be and is done by networks which originate routes and which > > practice good network hygiene, no PKI required. But it is a manual process or trust the information added to this database is correct. Automating the process even if it is only at the customer/isp edge were customer == isp is tagged as a exception would be a big win. > > But then we get into the customer of my customer (of my customer, of my > > customer . . .) problem, and this aren't quite so clear. > > > > There are also potentially significant drawbacks to incorporating PKI into > > the routing space, including new potential DoS vectors against PKI-enabled > > routing elements, the potential for enumeration of routing elements, and th > e > > possibility of building a true 'Internet kill switch' with effects far > > beyond what various governmental bodies have managed to do so far in the DN > S > > space. Yes, there are trade offs. As for that "Internet kill switch", ISP could theoretically be ordered to block all traffic to a prefix. I know that this is theoretically possible today with Australian legistation and basically has been since the very begining as it is in the telecomunication acts. > > Once governments figured out what the DNS was, they started to use it as a > > ban-hammer - what happens in a PKIed routing system once they figure out > > what BGP is? > > > > But nobody seems to be discussing these potential drawbacks, very much. > > Start here: > https://www.cs.bu.edu/~goldbe/papers/hotRPKI_full.pdf > > Dale -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From randy at psg.com Wed Jun 3 04:51:46 2015 From: randy at psg.com (Randy Bush) Date: Tue, 02 Jun 2015 21:51:46 -0700 Subject: BGP in the Washngton Post In-Reply-To: <20150603000513.D8EC12FD407E@rock.dv.isc.org> References: <556C8EBC.7080109@netassist.ua> <20150603000513.D8EC12FD407E@rock.dv.isc.org> Message-ID: > Yes, RPKI protects from fat fingered people, but NOT protects from > people doing hijacks knowingly. the rpki protects from fat fingers as well as the telephone white pages protects from wrong number dialing. it doesn't. for the 312th time (i had to make this clear once again from the floor of nanog this week), ... The RPKI is an X.509 based hierarchy [rfc 6481] which is congruent with the internet IP address allocation administration, the IANA, RIRS, ISPs, ... It is just a database, but is the substrate on which the next two mechanisms are based. It is currently deployed in all five administrative regions. RPKI-based Origin Validation [RFC 6811] uses some of the RPKI data to allow a router to verify that the autonomous system originating an IP address prefix is in fact authorized to do so. This is not crypto checked so can be violated. But it should prevent the vast majority of accidental 'hijackings' on the internet today, e.g. the famous Pakistani accidental announcement of YouTube's address space. RPKI-based origin validation is in shipping code from AlcaLu, Cisco, Juniper, and possibly others. RPKI-based Path Validation, a future technology still being designed [draft-ietf-sidr-bgpsec-overview-06.txt], uses the full crypto information of the RPKI to make up for the embarrassing mistake that, like much of the internet BGP was designed with no thought to securing the BGP protocol itself from being gamed/violated. It allows a receiver of a BGP announcement to cryptographically validate that the autonomous systems through which the announcement passed were indeed those which the sender/forwarder at each hop intended. randy From baconzombie at gmail.com Wed Jun 3 06:52:49 2015 From: baconzombie at gmail.com (Bacon Zombie) Date: Wed, 3 Jun 2015 08:52:49 +0200 Subject: Password Decryption Methods? In-Reply-To: References: <017b01d09d4d$490ac6b0$db205410$@hathcock.org> <565039F3-0F10-4BF9-B7FA-ECEC757671D8@gmail.com> Message-ID: Grab the firmware and run it through BinWalk. Your should be able to pull out the firmware and see what it does to the password before storing it. On 2 Jun 2015 22:03, "Landon Stewart" wrote: On Jun 2, 2015, at 9:23 AM, Michael O Holstein wrote: > If you can share the other details (make, model, firmware revision, processor type, etc.) .. whatever you know and can share) .. it would be more helpful. Also, how'd you get the hash? .. from a config file backup or from another device that used it to access this one? If so, what software, etc. Serial # too. :-D From pavel.odintsov at gmail.com Wed Jun 3 06:54:06 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 3 Jun 2015 09:54:06 +0300 Subject: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation In-Reply-To: References: Message-ID: Thank you for interest! Feel free to ask me about anything! Feature requests very appreciate! On Wed, Jun 3, 2015 at 9:31 AM, Johan Kooijman wrote: > Interesting project, Pavel. I'll most certainly give this a trial run. > > On Tue, Jun 2, 2015 at 10:16 PM, Pavel Odintsov > wrote: >> >> Hello, Nanog! >> >> I'm very pleased to present my open source DoS/DDoS attack monitoring >> toolkit here! >> >> We have spent about 10 months for development of FastNetMon and could >> present huge feature list now! :) >> >> Stop! What is FastNetMon? >> >> It's really very fast toolkit which could find attacked host in your >> network and block it (or redirect to filtering appliance) >> >> This solution could save your network and your sleep :) >> >> Our site located here: https://github.com/FastVPSEestiOu/fastnetmon >> >> We support following engines for traffic capture: >> - Netflow (v5, v9 and IPFIX) >> - sFLOW v5 >> - port mirror/SPAN (PF_RING and netmap supported) >> >> Also we have deep integration with ExaBGP (huge thanks to Thomas >> Mangin) for triggering blackhole on the Core Router or upstream. >> >> Since 1.0 version we have added support for following features: >> - Ability to detect most popular attack types: syn_flood, icmp_flood, >> udp_flood, ip_fragmentation_flood >> - Add support for Netmap for Linux (we have prepared special driver >> for ixgbe users: https://github.com/pavel-odintsov/ixgbe-linux-netmap) >> and FreeBSD. >> - Add support for PF_RING ZC (very fast but need license from ntop folks) >> - Add ability to collect netflow v9/IPFIX data from multiple devices >> with different templates set >> - Basic support for IPv6 (we could receive netflow data over IPv6) >> - Add plugin support for capture engines >> - Add support of L2TP decapsulation (important for DDoS attack >> detection inside tunnel) >> - Add ability to store attack details in Redis >> - Add Graphite/Grafana integration for traffic visualization >> - Add systemd unit file >> - Add ability to unblock host after some timeout >> - Introduce support of moving average for all counters >> - Add ExaBGP integration. We could announce attacked host with BGP to >> border router or uplink >> - Add so much details in attack report >> - Add ability to store attack fingerprint in file >> >> We have complete support for following platforms: >> - Fedora 21 >> - Debian 6, 7, 8 >> - CentOS 6, 7 >> - FreeBSD 9, 10, 11 >> - DragonflyBSD 4 >> - MacOS X 10.10 >> >> From network equipment side we have tested solution with: >> - Cisco ASR >> - Juniper MX >> - Extreme Summit >> - ipt_NETFLOW Linux >> >> We have binary packages for this operation systems: >> - CentOS 6: >> https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/CentOS6 >> - CentOS 7: >> https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/CentOS7 >> - Fedora 21: >> https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/Fedora21 >> - FreeBSD: >> https://github.com/FastVPSEestiOu/fastnetmon/tree/master/src/FreeBSD_port >> >> For any other operation systems we recommend automatic installer >> script: >> https://github.com/FastVPSEestiOu/fastnetmon/blob/master/docs/INSTALL.md >> >> Please join to our mail list or ask about anything here >> https://groups.google.com/forum/#!forum/fastnetmon >> >> Thank you for your attention! >> >> -- >> Sincerely yours, Pavel Odintsov > > > > > -- > Met vriendelijke groeten / With kind regards, > Johan Kooijman -- Sincerely yours, Pavel Odintsov From A.L.M.Buxey at lboro.ac.uk Wed Jun 3 06:31:17 2015 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Wed, 3 Jun 2015 07:31:17 +0100 Subject: WiFi courses/vendors recommendation In-Reply-To: References: <8078ED370ADA824281219A7B5BADC39B6C6A70E7@MBX023-W1-CA-4.exch023.domain.local> <20150601172347.GK4389@bamboo.slabnet.com> Message-ID: +1 for CWNP courses. The CWNA and CWDP cover RF quite well too.... you'll pick up most of what's needed. ..imho most of the vendor specific courses only benefit is to tell you how to manage their control plane. Which button to click on the interface etc ;) alan From mail at johankooijman.com Wed Jun 3 06:31:53 2015 From: mail at johankooijman.com (Johan Kooijman) Date: Wed, 3 Jun 2015 08:31:53 +0200 Subject: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation In-Reply-To: References: Message-ID: Interesting project, Pavel. I'll most certainly give this a trial run. On Tue, Jun 2, 2015 at 10:16 PM, Pavel Odintsov wrote: > Hello, Nanog! > > I'm very pleased to present my open source DoS/DDoS attack monitoring > toolkit here! > > We have spent about 10 months for development of FastNetMon and could > present huge feature list now! :) > > Stop! What is FastNetMon? > > It's really very fast toolkit which could find attacked host in your > network and block it (or redirect to filtering appliance) > > This solution could save your network and your sleep :) > > Our site located here: https://github.com/FastVPSEestiOu/fastnetmon > > We support following engines for traffic capture: > - Netflow (v5, v9 and IPFIX) > - sFLOW v5 > - port mirror/SPAN (PF_RING and netmap supported) > > Also we have deep integration with ExaBGP (huge thanks to Thomas > Mangin) for triggering blackhole on the Core Router or upstream. > > Since 1.0 version we have added support for following features: > - Ability to detect most popular attack types: syn_flood, icmp_flood, > udp_flood, ip_fragmentation_flood > - Add support for Netmap for Linux (we have prepared special driver > for ixgbe users: https://github.com/pavel-odintsov/ixgbe-linux-netmap) > and FreeBSD. > - Add support for PF_RING ZC (very fast but need license from ntop folks) > - Add ability to collect netflow v9/IPFIX data from multiple devices > with different templates set > - Basic support for IPv6 (we could receive netflow data over IPv6) > - Add plugin support for capture engines > - Add support of L2TP decapsulation (important for DDoS attack > detection inside tunnel) > - Add ability to store attack details in Redis > - Add Graphite/Grafana integration for traffic visualization > - Add systemd unit file > - Add ability to unblock host after some timeout > - Introduce support of moving average for all counters > - Add ExaBGP integration. We could announce attacked host with BGP to > border router or uplink > - Add so much details in attack report > - Add ability to store attack fingerprint in file > > We have complete support for following platforms: > - Fedora 21 > - Debian 6, 7, 8 > - CentOS 6, 7 > - FreeBSD 9, 10, 11 > - DragonflyBSD 4 > - MacOS X 10.10 > > From network equipment side we have tested solution with: > - Cisco ASR > - Juniper MX > - Extreme Summit > - ipt_NETFLOW Linux > > We have binary packages for this operation systems: > - CentOS 6: > https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/CentOS6 > - CentOS 7: > https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/CentOS7 > - Fedora 21: > https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/Fedora21 > - FreeBSD: > https://github.com/FastVPSEestiOu/fastnetmon/tree/master/src/FreeBSD_port > > For any other operation systems we recommend automatic installer > script: > https://github.com/FastVPSEestiOu/fastnetmon/blob/master/docs/INSTALL.md > > Please join to our mail list or ask about anything here > https://groups.google.com/forum/#!forum/fastnetmon > > Thank you for your attention! > > -- > Sincerely yours, Pavel Odintsov > -- Met vriendelijke groeten / With kind regards, Johan Kooijman From saku at ytti.fi Wed Jun 3 07:44:45 2015 From: saku at ytti.fi (Saku Ytti) Date: Wed, 3 Jun 2015 10:44:45 +0300 Subject: BGP in the Washngton Post In-Reply-To: References: <556C8EBC.7080109@netassist.ua> <20150603000513.D8EC12FD407E@rock.dv.isc.org> Message-ID: <20150603074445.GA8527@pob.ytti.fi> On (2015-06-02 21:51 -0700), Randy Bush wrote: > The RPKI is an X.509 based hierarchy [rfc 6481] which is congruent > with the internet IP address allocation administration, the IANA, Hijacking this thread. I've requested both our main vendors for 'loose rpki' years ago, nothing has happened. SP trying to deploy RPKI may have negative business impact, if far-end fat-fingers and fail RPKI, then my connectivity to them is broken, while competitor who isn't running RPKI still works fine. Essentially suits may view deploying RPKI as spending money to lose money. Comfortable slow-start would be to have 'loose rpki' which essentially has 3 adj-ribs, verified-rpki, missing-rpki, failed-rpki. Then loc-rib is build from each of these, so that no overlapping routes are installed from inferior ribs. That is, if verified-rpki has 192.0.2.0/24, missing/failed-rpki cannot install it or more-specific of it. Net result is, we will always use verified-rpki route if existing, but if no other options exist, we're happy to use any available route. JunOS allows routing-policy to match on verified status, but this cannot obviously override more-specifics. -- ++ytti From rdobbins at arbor.net Wed Jun 3 08:27:51 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 03 Jun 2015 15:27:51 +0700 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> Message-ID: On 3 Jun 2015, at 9:04, Ethan Katz-Bassett wrote: > The same folks also followed up that workshop paper with a longer > paper on > the topic: > https://www.cs.bu.edu/~goldbe/papers/sigRPKI.pdf Thanks to you and to Dale Carter - I was unaware of these papers. Nonetheless, the risk remains of authorities interfering with the BGP as they've interfered with the DNS. I'm very cognizant of the non-trivial effects of route-hijacking, having been involved in helping get a few of them resolved. Nonetheless, my natural skepticism leads me to wonder whether we aren't better off with the problematic, error-prone system we have (not to mention the enumeration and enhanced DDoS impact of packeting routers doing crypto for their BGP sessions and which aren't protected via iACLs/GTSM). ----------------------------------- Roland Dobbins From owen at delong.com Wed Jun 3 11:56:12 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Jun 2015 12:56:12 +0100 Subject: AWS Elastic IP architecture In-Reply-To: <556DC705.2090406@matthew.at> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <053A3A21-E0D8-4290-8AA1-5EABE5726756@delong! .com> <556DC705.2090406@matthew.at> Message-ID: <4316CE97-FC2E-4FDF-BB0D-B20E756AE64D@delong.com> > On Jun 2, 2015, at 4:08 PM, Matthew Kaufman wrote: > > > On 6/2/15 2:35 AM, Owen DeLong wrote: >>> On Jun 2, 2015, at 5:49 AM, Matthew Kaufman wrote: >>> >>> On 6/1/2015 6:32 PM, Mark Andrews wrote: >>>> In message >>>> , Christopher Morrow writes: >>>>> On Mon, Jun 1, 2015 at 9:02 PM, Ca By wrote: >>>>>> On Monday, June 1, 2015, Mark Andrews wrote: >>>>>>> In message >>>>>>> >>>>>>> , Christopher Morrow writes: >>>>>>>> So... I don't really see any of the above arguments for v6 in a vm >>>>>>>> setup to really hold water in the short term at least. I think for >>>>>>>> sure you'll want v6 for public services 'soon' (arguably like 10 yrs >>>>>>>> ago so you'd get practice and operational experience and ...) but for >>>>>>>> the rest sure it's 'nice', and 'cute', but really not required for >>>>>>>> operations (unless you have v6 only customers) >>>>>>> Everyone has effectively IPv6-only customers today. IPv6 native + >>>>>>> CGN only works for services. Similarly DS-Lite and 464XLAT. >>>>> ok, and for the example of 'put my service in the cloud' ... the >>>>> service is still accessible over ipv4 right? >>>> It depends on what you are trying to do. Having something in the >>>> cloud manage something at home. You can't reach the home over IPv4 >>>> more and more these days as. IPv6 is the escape path for that but >>>> you need both ends to be able to speak IPv6. >>> ...and for firewalls to not exist. Since they do, absolutely all the techniques required to "reach something at home" over IPv4 are required for IPv6. This is on the "great myths of the advantages of IPv6" list. >> IPv4 with NAT, you can open one host at home to remote access, or, in some cases, you can select different hosts by using the port number in lieu of the host name/address. > > IPv4 with NAT, standard NAT/firewall traversal techniques are used so that things inside your house are reachable as necessary. Almost nobody configures their firewall to open up anything. HuH? How do I SSH into my host behind my home NAT firewall without configuration of the firewall? You are making no sense here. NAT Traversal techniques provide for outbound connections and/or a way that a pseudo-service can create an inbound connection that looks like an outbound connection to the firewall. It does not in any way provide for generic inbound access to ordinary services without configuration. >> IPv6 ? I add a permit statement to the firewall to allow the traffic in to each host/group of hosts that I want and I am done. > > IPv6, standard NAT?firewall traversal techniques are used so that things inside your house are reachable as necessary. Still almost nobody configures their firewall to open up anything. Why would one use NAT with IPv6? You?re making no sense there. > For those who do, the work needed to open up a few host/port mappings in IPv4 is basically identical to opening up a few hosts and ports for IPv6. Not really? For example, let?s say you have 20 machines for whom you want to allow inbound SSH access. In the IPv4 world, with NAT, you have to configure an individual port mapping for each machine and you have to either configure all of the SSH clients, or, specify the particular port for the machine you want to get to on the command line. On the other hand, with IPv6, let?s say the machines are all on 2001:db8::/64. Further, let?s say that I group machines for which I want to provide SSH access within 2001:db8::22:0:0:0/80. I can add a single firewall entry which covers this /80 and I?m done. I can put many millions of hosts within that range and they all are accessible directly for SSH from the outside world. Takes about 20 seconds to configure my firewall once and then I never really need to worry about it again. Further, in the IPv4 case, I need special client configuration or client invocation effort every time, while with the IPv6 case, I can simply put the hostname in DNS and then use the name thereafter. >> I do not see the above as being equal effort or as yielding equal results. > > For the automatic traversal cases, the end-user effort is identical. Sure, but automatic traversal is the exception not the rule when considering internet services. > For the incredibly rare case of manual configuration (which as NANOG participants we often forget, since we're adjusting our routers all the time) there is almost no difference for most use cases. Not true as noted above. > Yes, the results are marginally superior in the IPv6 case. Nobody cares. I would argue that it?s more than marginal. >> As such, I?d say that your statement gets added to the great myths of Matthew Kauffman rather than there being any myth about this being an IPv6 advantage. >> >> I can assure you that it is MUCH easier for me to remote-manage my mother?s machines over their IPv6 addresses than to get to them over IPv4. > > Only because you've insisted on doing it the hard way, instead of using something like teamviewer or logmein which "just works?. So does vmc://hostname (if I have IPv6 or non-NAT IPv4). >> I live in California and have native dual-stack without NAT. She lives in Texas and has native dual-stack with NAT for her IPv4. > > And I assume your mother opened up her IPv6 firewall all on her own? As a matter of fact, she did open up the first connection which then provided me the necessary access to configure the rest for her. > Most people won't have the technical skills to adjust the IPv6 firewall that comes with their CPE and/or "Wireless Router" any more than they have the skills to set up IPv4 port mapping. My mother is about as non-technical as you would imagine the typical grandmother portrayed in most such examples. Technically, she?s a great grandmother these days. > >>> IPv6 has exactly one benefit... there's more addresses. It comes with a whole lot of new pain points, and probably a bunch of security nightmare still waiting to be discovered. And it for sure isn't free. >> IPv6 comes with at least one design-advantage ? More addresses. >> >> However, more addresses, especially on the scale IPv6 delivers them comes with MANY benefits: >> >> 1. Simplified addressing >> 2. Better aggregation >> 3. Direct access where permitted >> 4. Elimination of NAT and its security flaws and disadvantages >> 5. Simplified topologies >> 6. Better subnetting >> 7. Better network planning with sparse allocations > > All of those are benefits for the network operator, not the end user. I can see that all of those benefit the network operator. However, with the exception of 2 and 7, I would argue that all of them are also of benefit to at least some fraction of end-users. I am an end user and I am seeing benefits from all but 2. I use sparse address allocation to allow me to classify hosts for convenience, for example. Note, the original item 6 (corrected above) was autocorrected from subnetting to sunbathing. I have restored it to subnetting. > >> 8. Simpler application code > > Might be true *if* there was only IPv6. If there's also the need to support IPv4 then supporting *both* is harder than supporting just one. Only because the need to support NAT traversal comes as overhead in supporting IPv4. Otherwise, most applications can be written for IPv6 and set the socket option IPV6_V6ONLY=FALSE (which should be the default) and on a dual-stack host, the application will simply work and deal with both protocols without ever caring about IPv4. (IPv4 connections are presented to the application as an IPv6 connection from a host with address ::ffff:IP:v4 (where IP:v4 is the 32-bit IPv4 address of the source host). > >> 9. Reduced complexity in: >> Proxies >> Applications >> Firewalls >> Logging >> Monitoring >> Audit >> Intrusion Detection >> Intrusion Prevention >> DDoS mitigation > > Matters not to most home users. Until it does. I?ve had lots of complaints from end users where they didn?t know that the issue was a proxy problem, application coding error with NAT traversal, Firewall problem, etc., but upon investigation, these were exactly the source of said end-user?s problem. > Doesn't help corporate users because they also need all that for IPv4 indefinitely. See above. The more traffic that corporate users can get off of IPv4, the less trouble these things will cause for them. As such, your argument falls flat. >> 10. The ability to write software with hope of your codebase working for the next 10 years or more. > I'll bet that there's IPv4 devices running happily 10 years from now. Maybe, but I bet within 10 years, there?s very little, if any, IPv4 running across the backbone of the internet. >> I?m sure there are other benefits as well, but this gives you at least 10. >> >> There are those that would argue that other design advantages include: >> >> 1. Fixed length simplified header > > Maybe. > >> 2. Stateless Address Autoconfiguration > > Disaster, given that I'm still stuck needing DHCPv6 to configure everything that SLAAC won't. Or things that SLAAC only picked up recently (like setting your DNS server) and so are still unsupported in all sorts of gear. Not a disaster, but perhaps slightly less convenient for your particular situation. In my situation, most hosts don?t need anything more than an IP address, default gateway, and Recursive Nameserver. RAs provide all of that and my hosts just work fine with SLAAC out of the box. >> 3. Mobile IP > > Remains to be seen if this matters. I?ve found it quite useful as have several other people I know. >> 4. A much cleaner implementation of IPSEC > > Sure, but the IPv4 IPSEC seems to work just fine everywhere I've deployed it. For some definition of work. The additional overhead, increased complexity of configuring it, incompatible implementations, and other nightmares I have encountered in IPv4 IPSEC vs. the relative ease and convenience of using it in IPv6 strikes me as quite worth while. A treadle sewing machine works if you choose to use one. That doesn?t mean that an electric sewing machine with CNC stitching capabilities for embroidery, etc. is not a better alternative. >> I?m sure there are more, but this is a quick list off the top of my head. > > There's a bunch of myths too... and "every device will be directly reachable from the entire Internet" is on there. That?s not a myth, it?s just an incomplete statement that people like you love to truncate for the sake of claiming it is a myth. The complete statement is ?Every device can be directly reachable from the entire internet to the extent allowed by policy.? The complete statement is quite true. The incomplete statement is false only because it contains a scope which is beyond the ability of what a protocol can deliver, due to the missing words. Owen From pavel.odintsov at gmail.com Wed Jun 3 14:52:25 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 3 Jun 2015 17:52:25 +0300 Subject: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation In-Reply-To: References: Message-ID: Hello! Thank you! Please share your experience after tests! On Wed, Jun 3, 2015 at 5:50 PM, Budiwijaya wrote: > Yep, definitely i'll give this a trial run. > We are developing nullroute application internally. > I'll try to run this in our lab. > > On Wed, Jun 3, 2015 at 3:16 AM, Pavel Odintsov wrote: >> Hello, Nanog! >> >> I'm very pleased to present my open source DoS/DDoS attack monitoring >> toolkit here! >> >> We have spent about 10 months for development of FastNetMon and could >> present huge feature list now! :) >> >> Stop! What is FastNetMon? >> >> It's really very fast toolkit which could find attacked host in your >> network and block it (or redirect to filtering appliance) >> >> This solution could save your network and your sleep :) >> >> Our site located here: https://github.com/FastVPSEestiOu/fastnetmon >> >> We support following engines for traffic capture: >> - Netflow (v5, v9 and IPFIX) >> - sFLOW v5 >> - port mirror/SPAN (PF_RING and netmap supported) >> >> Also we have deep integration with ExaBGP (huge thanks to Thomas >> Mangin) for triggering blackhole on the Core Router or upstream. >> >> Since 1.0 version we have added support for following features: >> - Ability to detect most popular attack types: syn_flood, icmp_flood, >> udp_flood, ip_fragmentation_flood >> - Add support for Netmap for Linux (we have prepared special driver >> for ixgbe users: https://github.com/pavel-odintsov/ixgbe-linux-netmap) >> and FreeBSD. >> - Add support for PF_RING ZC (very fast but need license from ntop folks) >> - Add ability to collect netflow v9/IPFIX data from multiple devices >> with different templates set >> - Basic support for IPv6 (we could receive netflow data over IPv6) >> - Add plugin support for capture engines >> - Add support of L2TP decapsulation (important for DDoS attack >> detection inside tunnel) >> - Add ability to store attack details in Redis >> - Add Graphite/Grafana integration for traffic visualization >> - Add systemd unit file >> - Add ability to unblock host after some timeout >> - Introduce support of moving average for all counters >> - Add ExaBGP integration. We could announce attacked host with BGP to >> border router or uplink >> - Add so much details in attack report >> - Add ability to store attack fingerprint in file >> >> We have complete support for following platforms: >> - Fedora 21 >> - Debian 6, 7, 8 >> - CentOS 6, 7 >> - FreeBSD 9, 10, 11 >> - DragonflyBSD 4 >> - MacOS X 10.10 >> >> From network equipment side we have tested solution with: >> - Cisco ASR >> - Juniper MX >> - Extreme Summit >> - ipt_NETFLOW Linux >> >> We have binary packages for this operation systems: >> - CentOS 6: https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/CentOS6 >> - CentOS 7: https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/CentOS7 >> - Fedora 21: https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/Fedora21 >> - FreeBSD: https://github.com/FastVPSEestiOu/fastnetmon/tree/master/src/FreeBSD_port >> >> For any other operation systems we recommend automatic installer >> script: https://github.com/FastVPSEestiOu/fastnetmon/blob/master/docs/INSTALL.md >> >> Please join to our mail list or ask about anything here >> https://groups.google.com/forum/#!forum/fastnetmon >> >> Thank you for your attention! >> >> -- >> Sincerely yours, Pavel Odintsov -- Sincerely yours, Pavel Odintsov From eric.oosting at gmail.com Wed Jun 3 15:16:19 2015 From: eric.oosting at gmail.com (Eric Oosting) Date: Wed, 3 Jun 2015 11:16:19 -0400 Subject: nanog website down Message-ID: This morning we suffered a hardware failure in our production environment. The outage affected nanog mail and web services. While mail services have recovered, web services are still down. We apologize for the inconvenience. -e From bob at FiberInternetCenter.com Wed Jun 3 13:31:59 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 3 Jun 2015 06:31:59 -0700 Subject: nanog.org Website down ? Message-ID: Not sure what's up - however I see what's down this AM. From the hotel nanog.org was not reachable. Soooo, I tunneled out of the hotel to my office, still not reachable at 6:15 AM nanog.org (50.31.151.73) www.nanog.org (50.31.151.73) Bob Evans CTO Fiber Internet Center From charles at phukish.com Wed Jun 3 15:28:12 2015 From: charles at phukish.com (Charles van Niman) Date: Wed, 3 Jun 2015 10:28:12 -0500 Subject: nanog.org Website down ? In-Reply-To: References: Message-ID: Yeah, looks like this just made it to the list: >This morning we suffered a hardware failure in our production environment. >The outage affected nanog mail and web services. While mail services have >recovered, web services are still down. On Wed, Jun 3, 2015 at 8:31 AM, Bob Evans wrote: > Not sure what's up - however I see what's down this AM. From the hotel > nanog.org was not reachable. Soooo, I tunneled out of the hotel to my > office, still not reachable at 6:15 AM > > nanog.org (50.31.151.73) > www.nanog.org (50.31.151.73) > > Bob Evans > CTO > Fiber Internet Center > > > > > From eric.oosting at gmail.com Wed Jun 3 15:38:22 2015 From: eric.oosting at gmail.com (Eric Oosting) Date: Wed, 3 Jun 2015 11:38:22 -0400 Subject: nanog website down In-Reply-To: References: Message-ID: At this time, we believe all services have been restored. On Wed, Jun 3, 2015 at 11:16 AM, Eric Oosting wrote: > This morning we suffered a hardware failure in our production environment. > The outage affected nanog mail and web services. While mail services have > recovered, web services are still down. > > We apologize for the inconvenience. > > -e > From matthew at matthew.at Wed Jun 3 15:55:46 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 03 Jun 2015 08:55:46 -0700 Subject: AWS Elastic IP architecture In-Reply-To: <4316CE97-FC2E-4FDF-BB0D-B20E756AE64D@delong.com> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <053A3A21-E0D8-4290-8AA1-5EABE5726756@delong! .com> <556DC705.2090406@matthew.at> <4316CE97-FC2E-4FDF-BB0D-B20E756AE64D@delong.com> Message-ID: <556F2382.8010409@matthew.at> On 6/3/2015 4:56 AM, Owen DeLong wrote: > >> On Jun 2, 2015, at 4:08 PM, Matthew Kaufman > > wrote: >> >> >> On 6/2/15 2:35 AM, Owen DeLong wrote: >>>> On Jun 2, 2015, at 5:49 AM, Matthew Kaufman >>> > wrote: >>>> >>>> On 6/1/2015 6:32 PM, Mark Andrews wrote: >>>>> In message >>>>> >>>>>> , Christopher Morrow writes: >>>>>> On Mon, Jun 1, 2015 at 9:02 PM, Ca By >>>>> > wrote: >>>>>>> On Monday, June 1, 2015, Mark Andrews >>>>>> > wrote: >>>>>>>> In message >>>>>>>> >>>>>>> > >>>>>>>> , Christopher Morrow writes: >>>>>>>>> So... I don't really see any of the above arguments for v6 in a vm >>>>>>>>> setup to really hold water in the short term at least. I >>>>>>>>> think for >>>>>>>>> sure you'll want v6 for public services 'soon' (arguably like >>>>>>>>> 10 yrs >>>>>>>>> ago so you'd get practice and operational experience and ...) >>>>>>>>> but for >>>>>>>>> the rest sure it's 'nice', and 'cute', but really not required for >>>>>>>>> operations (unless you have v6 only customers) >>>>>>>> Everyone has effectively IPv6-only customers today. IPv6 native + >>>>>>>> CGN only works for services. Similarly DS-Lite and 464XLAT. >>>>>> ok, and for the example of 'put my service in the cloud' ... the >>>>>> service is still accessible over ipv4 right? >>>>> It depends on what you are trying to do. Having something in the >>>>> cloud manage something at home. You can't reach the home over IPv4 >>>>> more and more these days as. IPv6 is the escape path for that but >>>>> you need both ends to be able to speak IPv6. >>>> ...and for firewalls to not exist. Since they do, absolutely all >>>> the techniques required to "reach something at home" over IPv4 are >>>> required for IPv6. This is on the "great myths of the advantages of >>>> IPv6" list. >>> IPv4 with NAT, you can open one host at home to remote access, or, >>> in some cases, you can select different hosts by using the port >>> number in lieu of the host name/address. >> >> IPv4 with NAT, standard NAT/firewall traversal techniques are used so >> that things inside your house are reachable as necessary. Almost >> nobody configures their firewall to open up anything. > > HuH? > > How do I SSH into my host behind my home NAT firewall without > configuration of the firewall? Nobody but you and a few hundred other people on this mailing list SSH into hosts at your home. Everyone else in the entire world reaches hosts at their house through their firewall just fine because those hosts are their Nest thermostat, or their Dropcam, or their PC running Skype, or maybe (in rare cases) something like LogMeIn. None of those people ever touch the settings of the device they had delivered by their ISP and/or purchased at Best Buy. Not ever. > > You are making no sense here. NAT Traversal techniques provide for > outbound connections and/or a way that a pseudo-service can create an > inbound connection that looks like an outbound connection to the firewall. > > It does not in any way provide for generic inbound access to ordinary > services without configuration. So what? Nobody (to several levels of statistical significance) needs "generic inbound access to ordinary services". Heck, the only "ordinary services" that exist any more are HTTP/HTTPS. > >>> IPv6 ? I add a permit statement to the firewall to allow the traffic >>> in to each host/group of hosts that I want and I am done. >> >> IPv6, standard NAT?firewall traversal techniques are used so that >> things inside your house are reachable as necessary. Still almost >> nobody configures their firewall to open up anything. > > Why would one use NAT with IPv6? You?re making no sense there. I didn't say you would... but you need firewall traversal, and the "standard NAT and firewall traversal techniques" are how you traverse your IPv6 firewall. > >> For those who do, the work needed to open up a few host/port mappings >> in IPv4 is basically identical to opening up a few hosts and ports >> for IPv6. > > Not really? > > For example, let?s say you have 20 machines for whom you want to allow > inbound SSH access. In the IPv4 world, with NAT, you have to configure > an individual port mapping for each machine and you have to either > configure all of the SSH clients, or, specify the particular port for > the machine you want to get to on the command line. Ok, you go find me 1000 households where nobody in the house is on the NANOG list but where there are 20 machines running SSH already installed. > > On the other hand, with IPv6, let?s say the machines are all on > 2001:db8::/64. Further, let?s say that I group machines for which I > want to provide SSH access within 2001:db8::22:0:0:0/80. I can add a > single firewall entry which covers this /80 and I?m done. I can put > many millions of hosts within that range and they all are accessible > directly for SSH from the outside world. > > Takes about 20 seconds to configure my firewall once and then I never > really need to worry about it again. > Yeah, so there you are manually configuring your firewall again. Which isn't surprising, because you also want to have 20 hosts offering SSH to the world... which makes you an outlier. > Further, in the IPv4 case, I need special client configuration or > client invocation effort every time, while with the IPv6 case, I can > simply put the hostname in DNS and then use the name thereafter. Sure... because like most homeowners, you're proficient at editing BIND config files. > >>> I do not see the above as being equal effort or as yielding equal >>> results. >> >> For the automatic traversal cases, the end-user effort is identical. > > Sure, but automatic traversal is the exception not the rule when > considering internet services. > I don't know what world you're living in, but every single person I know is a user of one or more software or hardware devices that work just fine behind a firewall, either because they're just uploading things to a service, or periodically checking in with a service, or using automatic traversal techniques. >> For the incredibly rare case of manual configuration (which as NANOG >> participants we often forget, since we're adjusting our routers all >> the time) there is almost no difference for most use cases. > > Not true as noted above. Most people never configure. Most of the people who do configure need exactly one address and port to work, in which case the work is about the same. You have 20 SSH hosts. You're an outlier, and so yes, in IPv6 there's less typing. I'm an outlier too... my house has a Juniper SRX-240 that I configure from the command line at its border. That's not normal. I'm not normal. And that's ok. > >> Yes, the results are marginally superior in the IPv6 case. Nobody cares. > > I would argue that it?s more than marginal. You are free to argue that. > >>> As such, I?d say that your statement gets added to the great myths >>> of Matthew Kauffman rather than there being any myth about this >>> being an IPv6 advantage. >>> >>> I can assure you that it is MUCH easier for me to remote-manage my >>> mother?s machines over their IPv6 addresses than to get to them over >>> IPv4. >> >> Only because you've insisted on doing it the hard way, instead of >> using something like teamviewer or logmein which "just works?. > > So does vmc://hostname (if I have IPv6 or non-NAT IPv4). With default out-of-the-box firewall settings as your device arrives from Best Buy? > >>> I live in California and have native dual-stack without NAT. She >>> lives in Texas and has native dual-stack with NAT for her IPv4. >> >> And I assume your mother opened up her IPv6 firewall all on her own? > > As a matter of fact, she did open up the first connection which then > provided me the necessary access to configure the rest for her. So it isn't actually that hard. Just like it isn't that hard for one address and port for the user of a Slingbox or whatever other random product you can find that doesn't have full traversal capabilities in it. > >> Most people won't have the technical skills to adjust the IPv6 >> firewall that comes with their CPE and/or "Wireless Router" any more >> than they have the skills to set up IPv4 port mapping. > > My mother is about as non-technical as you would imagine the typical > grandmother portrayed in most such examples. Technically, she?s a > great grandmother these days. > Congratulations to her. >> >>>> IPv6 has exactly one benefit... there's more addresses. It comes >>>> with a whole lot of new pain points, and probably a bunch of >>>> security nightmare still waiting to be discovered. And it for sure >>>> isn't free. >>> IPv6 comes with at least one design-advantage ? More addresses. >>> >>> However, more addresses, especially on the scale IPv6 delivers them >>> comes with MANY benefits: >>> >>> 1.Simplified addressing >>> 2.Better aggregation >>> 3.Direct access where permitted >>> 4.Elimination of NAT and its security flaws and disadvantages >>> 5.Simplified topologies >>> 6.Better subnetting >>> 7.Better network planning with sparse allocations >> >> All of those are benefits for the network operator, not the end user. > > I can see that all of those benefit the network operator. > > However, with the exception of 2 and 7, I would argue that all of them > are also of benefit to at least some fraction of end-users. > Some fraction, sure. But since that fraction is well under 0.1%, I'm sticking with my position. > I am an end user and I am seeing benefits from all but 2. I use sparse > address allocation to allow me to classify hosts for convenience, for > example. Outlier. > > Note, the original item 6 (corrected above) was autocorrected from > subnetting to sunbathing. I have restored it to subnetting. > I preferred sunbathing. >> >>> 8.Simpler application code >> >> Might be true *if* there was only IPv6. If there's also the need to >> support IPv4 then supporting *both* is harder than supporting just one. > > Only because the need to support NAT traversal comes as overhead in > supporting IPv4. The same code is needed to do IPv6 firewall traversal. > > Otherwise, most applications can be written for IPv6 and set the > socket option IPV6_V6ONLY=FALSE (which should be the default) and on a > dual-stack host, the application will simply work and deal with both > protocols without ever caring about IPv4. (IPv4 connections are > presented to the application as an IPv6 connection from a host with > address ::ffff:IP:v4 (where IP:v4 is the 32-bit IPv4 address of the > source host). For an operating system and TCP/IP stack where that is true, sure. When you're trying to squeeze things into a Cortex M4 that you want to hang on someone's wall, dual-stack takes more Flash. > >> >>> 9.Reduced complexity in: >>> Proxies >>> Applications >>> Firewalls >>> Logging >>> Monitoring >>> Audit >>> Intrusion Detection >>> Intrusion Prevention >>> DDoS mitigation >> >> Matters not to most home users. > > Until it does. I?ve had lots of complaints from end users where they > didn?t know that the issue was a proxy problem, application coding > error with NAT traversal, Firewall problem, etc., but upon > investigation, these were exactly the source of said end-user?s problem. Define "lots". Most users are having great luck with their current IPv4-only connection and the devices they're buying to use with it. > >> Doesn't help corporate users because they also need all that for IPv4 >> indefinitely. > > See above. The more traffic that corporate users can get off of IPv4, > the less trouble these things will cause for them. As such, your > argument falls flat. If I'm still getting support tickets due to IPv4 issues, the problems haven't gone away. Again, tell me when I can switch IPv4 off entirely. > >>> 10.The ability to write software with hope of your codebase working >>> for the next 10 years or more. >> I'll bet that there's IPv4 devices running happily 10 years from now. > > Maybe, but I bet within 10 years, there?s very little, if any, IPv4 > running across the backbone of the internet. I'd take that bet. > >>> I?m sure there are other benefits as well, but this gives you at >>> least 10. >>> >>> There are those that would argue that other design advantages include: >>> >>> 1.Fixed length simplified header >> >> Maybe. >> >>> 2.Stateless Address Autoconfiguration >> >> Disaster, given that I'm still stuck needing DHCPv6 to configure >> everything that SLAAC won't. Or things that SLAAC only picked up >> recently (like setting your DNS server) and so are still unsupported >> in all sorts of gear. > > Not a disaster, but perhaps slightly less convenient for your > particular situation. > > In my situation, most hosts don?t need anything more than an IP > address, default gateway, and Recursive Nameserver. RAs provide all of > that and my hosts just work fine with SLAAC out of the box. Not too many WinXP machines at your house I guess. > >>> 3.Mobile IP >> >> Remains to be seen if this matters. > > I?ve found it quite useful as have several other people I know. > Outlier. >>> 4.A much cleaner implementation of IPSEC >> >> Sure, but the IPv4 IPSEC seems to work just fine everywhere I've >> deployed it. > > For some definition of work. The additional overhead, increased > complexity of configuring it, incompatible implementations, and other > nightmares I have encountered in IPv4 IPSEC vs. the relative ease and > convenience of using it in IPv6 strikes me as quite worth while. > > A treadle sewing machine works if you choose to use one. That doesn?t > mean that an electric sewing machine with CNC stitching capabilities > for embroidery, etc. is not a better alternative. > Given that the security provided by both is identical, I'm not sure that's a good example, but it was creative. >>> I?m sure there are more, but this is a quick list off the top of my >>> head. >> >> There's a bunch of myths too... and "every device will be directly >> reachable from the entire Internet" is on there. > > That?s not a myth, it?s just an incomplete statement that people like > you love to truncate for the sake of claiming it is a myth. > > The complete statement is ?Every device can be directly reachable from > the entire internet to the extent allowed by policy.? > > The complete statement is quite true. The incomplete statement is > false only because it contains a scope which is beyond the ability of > what a protocol can deliver, due to the missing words. > Yes. But those extra words mean that I need to carry around exactly the same tricks I use to get through IPv4 NAT/firewall cases. Matthew Kaufman From frederik at kriewitz.eu Wed Jun 3 16:47:08 2015 From: frederik at kriewitz.eu (Frederik Kriewitz) Date: Wed, 3 Jun 2015 18:47:08 +0200 Subject: BGP offloading (fixing legacy router BGP scalability issues) In-Reply-To: <99E1AA1A-E047-4B88-A449-0BA7304C93D8@gmail.com> References: <99E1AA1A-E047-4B88-A449-0BA7304C93D8@gmail.com> Message-ID: On Mon, May 11, 2015 at 8:38 PM, Chaim Rieger wrote: > Freddy, did you get your test up ? Finally had some time to setup a lab environment and do some basic testing regarding the fully transparent approach mentioned in the initial email. My biggest concern was that the cisco wouldn't like packets with it's own MAC source address. But luckily it's dumb enough to just forward them. Hacked together a small scapy program to implement "selective proxy ARP/NDP spoofing". It's working perfectly fine in my lab setup. As it turns out a quick reality check on our peering ports shows that most BGP implementations are correctly setting TTL to 1 for ebgp sessions by default. That of course breaks my initial plan to just route the BGP packets to the server (cisco will drop them due to TTL expiration). Using a vlan access-map it might be possible to redirect the packets to another interface to fix that. The worst case solution for that should be a RSPAN session with corresponding filter. Essentially all the bricks are there, they just need to be assembled. Best Regards, Freddy From Valdis.Kletnieks at vt.edu Wed Jun 3 17:11:34 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 03 Jun 2015 13:11:34 -0400 Subject: AWS Elastic IP architecture In-Reply-To: Your message of "Tue, 02 Jun 2015 09:35:11 -0700." References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <20150602051208.E4F132FCC4B9@rock.dv.isc.org> <556DC6FD.7040801@matthew.at> <556DD7F8.7090004@! inblock.r u> Message-ID: <7677.1433351494@turing-police.cc.vt.edu> On Tue, 02 Jun 2015 09:35:11 -0700, Matthew Kaufman said: > Ah, the "IPv6 subnets are so big you can't find the hosts" myth. > > Let's see... to find which hosts are active in IPv6 I can: > - run a popular web service that people connect to, revealing their addresses If your vulnerable laser printer or webcam is calling out to Hotmail or Google or whatever, you got *bigger* problems, dude.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From hugo at slabnet.com Wed Jun 3 17:17:08 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Wed, 3 Jun 2015 10:17:08 -0700 Subject: AWS Elastic IP architecture In-Reply-To: <7677.1433351494@turing-police.cc.vt.edu> References: <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <20150602051208.E4F132FCC4B9@rock.dv.isc.org> <556DC6FD.7040801@matthew.at> <7677.1433351494@turing-police.cc.vt.edu> Message-ID: <20150603171708.GA22229@bamboo.slabnet.com> On Wed 2015-Jun-03 13:11:34 -0400, Valdis.Kletnieks at vt.edu wrote: >On Tue, 02 Jun 2015 09:35:11 -0700, Matthew Kaufman said: >> Ah, the "IPv6 subnets are so big you can't find the hosts" myth. >> >> Let's see... to find which hosts are active in IPv6 I can: >> - run a popular web service that people connect to, revealing their addresses > >If your vulnerable laser printer or webcam is calling out to Hotmail or >Google or whatever, you got *bigger* problems, dude.... Not to support Mr. Kaufman's line of reasoning, but: https://h30495.www3.hp.com/c/46775/US/en/?jumpid=in_R11549%2Feprintcenter https://www.google.com/cloudprint/#printers :( -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From Valdis.Kletnieks at vt.edu Wed Jun 3 17:19:51 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 03 Jun 2015 13:19:51 -0400 Subject: AWS Elastic IP architecture In-Reply-To: Your message of "Mon, 01 Jun 2015 21:25:52 -0700." <086101d09cec$362a2150$a27e63f0$@tndh.net> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <556C9B15.7010403@matthew.at> <20150601221741.GW724@hezmatt.org> <20150601224119.GA31945@bamboo.slabnet.com> <083301d09cc1$82342120$869c6360$@tndh.net> <086101d09cec$362a2150$a27e63f0$@tndh.net> Message-ID: <8654.1433351991@turing-police.cc.vt.edu> On Mon, 01 Jun 2015 21:25:52 -0700, Tony Hain said: > Try https://snapchat.com and see if you ever get an IPv6 connection... Obviously some gremlins got busy when they got called out on NANOG... % wget https://www.snapchat.com --2015-06-03 13:13:00-- https://www.snapchat.com/ Resolving www.snapchat.com (www.snapchat.com)... 2607:f8b0:400d:c06::79, 74.125.22.121 Connecting to www.snapchat.com (www.snapchat.com)|2607:f8b0:400d:c06::79|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: 'index.html' index.html [ <=> ] 4.35K --.-KB/s in 0s 2015-06-03 13:13:03 (33.5 MB/s) - 'index.html' saved [4458] When I hit it with Firefox, IPFox reports the connection is ipv6 as well (but a bit harder to get a screenshot)... .. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Steve.Mikulasik at civeo.com Wed Jun 3 17:29:04 2015 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Wed, 3 Jun 2015 17:29:04 +0000 Subject: AWS Elastic IP architecture In-Reply-To: <7677.1433351494@turing-police.cc.vt.edu> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <20150602051208.E4F132FCC4B9@rock.dv.isc.org> <556DC6FD.7040801@matthew.at> <556DD7F8.7090004@! inblock.r u> <7677.1433351494@turing-police.cc.vt.edu> Message-ID: IoT says your toaster will be uploading your breakfast to 10 social media accounts and your socks will be connected to the hospital. Your fridge is also a spambot now too! http://www.businessinsider.com/hackers-use-a-refridgerator-to-attack-businesses-2014-1 IoT means everything gets hacked. Maybe someone can make Cryptolocker to lock you out of your fridge until you pay a ransom. We are entering a whole new era of exciting vulnerabilities. Steve Mikulasik -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Valdis.Kletnieks at vt.edu Sent: Wednesday, June 03, 2015 11:12 AM To: Matthew Kaufman Cc: nanog at nanog.org Subject: Re: AWS Elastic IP architecture On Tue, 02 Jun 2015 09:35:11 -0700, Matthew Kaufman said: > Ah, the "IPv6 subnets are so big you can't find the hosts" myth. > > Let's see... to find which hosts are active in IPv6 I can: > - run a popular web service that people connect to, revealing their > addresses If your vulnerable laser printer or webcam is calling out to Hotmail or Google or whatever, you got *bigger* problems, dude.... From danny at tcb.net Wed Jun 3 19:41:17 2015 From: danny at tcb.net (Danny McPherson) Date: Wed, 03 Jun 2015 13:41:17 -0600 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <20150602040707.382092FCB844@rock.dv.isc.org> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> Message-ID: <5ee1d9d86b26482496c29afa7bdf2613@tcb.net> On 2015-06-01 22:07, Mark Andrews wrote: > If you have secure BGP deployed then you could extend the > authenication > to securely authenticate source addresses you emit and automate > BCP38 filter generation and then you wouldn't have to worry about > DNS, NTP, CHARGEN etc. reflecting spoofed traffic. I don't believe this is entirely true, and BGPSEC certainly doesn't solve most of what I'm concerned about from a routing security perspective. See, e.g.: https://tools.ietf.org/html/draft-ietf-grow-simple-leak-attack-bgpsec-no-help-04 That said, a Internet number resource certification infrastructure, be it RPKI or something with s single root and scalable(!), is certainly necessary, and can be used to bootstrap policy databases (e.g., IRRs) that address both the inter-domain routing (e.g., origin "validation") and data plane anti-spoofing security problems, and perhaps not require operators (enterprises and nation states alike) to trade the autonomy and flexibility they have in routing today for what others see as their infrastructure security needs. After all, stability, resiliency, and availability are ALSO factors in the risk management gumbo that need to be considered by organizations, and the tight coupling of RPKI and BGPSEC as designed, are quite possibly not as attractive to some operators as the designers might suggest, particularly in light of new external dependencies, competitive markets, Internet governance, geopolitical climate, etc.. Many that haven't deployed or have lost interest in having the conversation have done so deliberately, and would prefer a routing by rumor paradigm that affords autonomy and flexibility to one where new control points and exorbitant costs and complexity simply scare the heck out of them, the primitives of which surely extend to many of the luminaries quoted in those articles. YMMV, -danny From morrowc.lists at gmail.com Wed Jun 3 20:24:59 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 3 Jun 2015 16:24:59 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <4316CE97-FC2E-4FDF-BB0D-B20E756AE64D@delong.com> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <556DC705.2090406@matthew.at> <4316CE97-FC2E-4FDF-BB0D-B20E756AE64D@delong.com> Message-ID: On Wed, Jun 3, 2015 at 7:56 AM, Owen DeLong wrote: > For example, let?s say you have 20 machines for whom you want to allow inbound SSH access. In the IPv4 world, with NAT, you have to configure an individual port mapping for each machine and you have to either configure all of the SSH clients, or, specify the particular port for the machine you want to get to on the command line. in the original case in question the fact that there's nat happeng isn't material... so all of this discussion of NAT is a red herring, right? the user of AWS services cares not that 'nat is happening', because they can simply RESTful up a VM instance and ssh into it in ~30 seconds, no config required. let's skip all NAT discussions on this topic from here on out, yes? From rafael at gav.ufsc.br Wed Jun 3 20:32:17 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Wed, 3 Jun 2015 15:32:17 -0500 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <556DC705.2090406@matthew.at> <4316CE97-FC2E-4FDF-BB0D-B20E756AE64D@delong.com> Message-ID: we are starting to waste packets arguing over some private intellectual property On Wed, Jun 3, 2015 at 3:24 PM, Christopher Morrow wrote: > On Wed, Jun 3, 2015 at 7:56 AM, Owen DeLong wrote: > > For example, let?s say you have 20 machines for whom you want to allow > inbound SSH access. In the IPv4 world, with NAT, you have to configure an > individual port mapping for each machine and you have to either configure > all of the SSH clients, or, specify the particular port for the machine you > want to get to on the command line. > > in the original case in question the fact that there's nat happeng > isn't material... so all of this discussion of NAT is a red herring, > right? the user of AWS services cares not that 'nat is happening', > because they can simply RESTful up a VM instance and ssh into it in > ~30 seconds, no config required. > > let's skip all NAT discussions on this topic from here on out, yes? > From bbuuddiiww at gmail.com Wed Jun 3 14:50:23 2015 From: bbuuddiiww at gmail.com (Budiwijaya) Date: Wed, 3 Jun 2015 21:50:23 +0700 Subject: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation In-Reply-To: References: Message-ID: Yep, definitely i'll give this a trial run. We are developing nullroute application internally. I'll try to run this in our lab. On Wed, Jun 3, 2015 at 3:16 AM, Pavel Odintsov wrote: > Hello, Nanog! > > I'm very pleased to present my open source DoS/DDoS attack monitoring > toolkit here! > > We have spent about 10 months for development of FastNetMon and could > present huge feature list now! :) > > Stop! What is FastNetMon? > > It's really very fast toolkit which could find attacked host in your > network and block it (or redirect to filtering appliance) > > This solution could save your network and your sleep :) > > Our site located here: https://github.com/FastVPSEestiOu/fastnetmon > > We support following engines for traffic capture: > - Netflow (v5, v9 and IPFIX) > - sFLOW v5 > - port mirror/SPAN (PF_RING and netmap supported) > > Also we have deep integration with ExaBGP (huge thanks to Thomas > Mangin) for triggering blackhole on the Core Router or upstream. > > Since 1.0 version we have added support for following features: > - Ability to detect most popular attack types: syn_flood, icmp_flood, > udp_flood, ip_fragmentation_flood > - Add support for Netmap for Linux (we have prepared special driver > for ixgbe users: https://github.com/pavel-odintsov/ixgbe-linux-netmap) > and FreeBSD. > - Add support for PF_RING ZC (very fast but need license from ntop folks) > - Add ability to collect netflow v9/IPFIX data from multiple devices > with different templates set > - Basic support for IPv6 (we could receive netflow data over IPv6) > - Add plugin support for capture engines > - Add support of L2TP decapsulation (important for DDoS attack > detection inside tunnel) > - Add ability to store attack details in Redis > - Add Graphite/Grafana integration for traffic visualization > - Add systemd unit file > - Add ability to unblock host after some timeout > - Introduce support of moving average for all counters > - Add ExaBGP integration. We could announce attacked host with BGP to > border router or uplink > - Add so much details in attack report > - Add ability to store attack fingerprint in file > > We have complete support for following platforms: > - Fedora 21 > - Debian 6, 7, 8 > - CentOS 6, 7 > - FreeBSD 9, 10, 11 > - DragonflyBSD 4 > - MacOS X 10.10 > > From network equipment side we have tested solution with: > - Cisco ASR > - Juniper MX > - Extreme Summit > - ipt_NETFLOW Linux > > We have binary packages for this operation systems: > - CentOS 6: https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/CentOS6 > - CentOS 7: https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/CentOS7 > - Fedora 21: https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/Fedora21 > - FreeBSD: https://github.com/FastVPSEestiOu/fastnetmon/tree/master/src/FreeBSD_port > > For any other operation systems we recommend automatic installer > script: https://github.com/FastVPSEestiOu/fastnetmon/blob/master/docs/INSTALL.md > > Please join to our mail list or ask about anything here > https://groups.google.com/forum/#!forum/fastnetmon > > Thank you for your attention! > > -- > Sincerely yours, Pavel Odintsov From larrysheldon at cox.net Thu Jun 4 01:28:10 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Wed, 03 Jun 2015 20:28:10 -0500 Subject: BGP in the Washngton Post In-Reply-To: References: Message-ID: <556FA9AA.1030501@cox.net> On 6/2/2015 00:27, Scott Weeks wrote: > Great article for the WP and they asked good questions from > the correct people, but I have to take issue with the lack > of network operator's participation comments: > > : But getting network operators to participate is proving > : difficult. > > : Many network operators also are cool to taking the further > : step of adopting a secure new routing protocol called BGPSEC > : to replace BGP. > > : ?Unless [network] operators can see that the benefits will > : generally outweigh the costs, they just won?t deploy it.? > > It's more that the managers who have no idea what is going on > are forcing operators to focus their attention elsewhere, rather > than the important things until everyone's behind the 8-ball. > Then, all of the sudden, the mostly clueless managers are all > about it. But, by then it's too late. Farting in a hurricane > and hoping it makes a difference... ;-) Pardon me, (and please forgive me if I am wrong), but I think that from the viewpoints of the Washington Post, its readers, and probably all of humanity save the view on this list, the MANAGEMENT of the several ISP firms and organizations IS "the operators". Folks out on the operating floor don't really exist. -- sed quis custodiet ipsos custodes? (Juvenal) From surfer at mauigateway.com Thu Jun 4 02:08:58 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 3 Jun 2015 19:08:58 -0700 Subject: BGP in the Washngton Post Message-ID: <20150603190858.5B2F6EBA@m0005311.ppops.net> --- larrysheldon at cox.net wrote: From: Larry Sheldon On 6/2/2015 00:27, Scott Weeks wrote: > Great article for the WP and they asked good questions from > the correct people, but I have to take issue with the lack > of network operator's participation comments: > > : But getting network operators to participate is proving > : difficult. > > : Many network operators also are cool to taking the further > : step of adopting a secure new routing protocol called BGPSEC > : to replace BGP. > > : ?Unless [network] operators can see that the benefits will > : generally outweigh the costs, they just won?t deploy it.? > > It's more that the managers who have no idea what is going on > are forcing operators to focus their attention elsewhere, rather > than the important things until everyone's behind the 8-ball. > Then, all of the sudden, the mostly clueless managers are all > about it. But, by then it's too late. Farting in a hurricane > and hoping it makes a difference... ;-) Pardon me, (and please forgive me if I am wrong), but I think that from the viewpoints of the Washington Post, its readers, and probably all of humanity save the view on this list, the MANAGEMENT of the several ISP firms and organizations IS "the operators". Folks out on the operating floor don't really exist. -------------------------------------------------- No, looking at it the way you phrase it, you're not wrong. To me, the operators are the folks with the technical know how and the admin password. I guess I have been out on the raggedy edges (likely soon to change...) too long and I am not used to managers that have any understanding of network operations/engineering. But I do understand what you're saying. And I'm on the list. ;-) scott From lists at sadiqs.com Thu Jun 4 03:16:35 2015 From: lists at sadiqs.com (Sadiq Saif) Date: Wed, 03 Jun 2015 23:16:35 -0400 Subject: NANOG 64 recordings Message-ID: <556FC313.6020407@sadiqs.com> Hi all, For those that missed them: https://www.youtube.com/playlist?list=PLO8DR5ZGla8ju3ftZv_S6L12jBkZKEJVZ -- Sadiq Saif (AS393949) https://staticsafe.ca From owen at delong.com Thu Jun 4 09:11:39 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Jun 2015 10:11:39 +0100 Subject: AWS Elastic IP architecture In-Reply-To: <556F2382.8010409@matthew.at> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <053A3A21-E0D8-4290-8AA1-5EABE5726756@delong! .com> <556DC705.2090406@matthew.at> <4316CE97-FC2E-4FDF-BB0D-B20E756AE64D@delong.com> <556F2382.80! 10409@matthew.at> Message-ID: <233AFE07-72FB-4BF8-A8E9-BA9BCB54072C@delong.com> >>> >>> IPv4 with NAT, standard NAT/firewall traversal techniques are used so that things inside your house are reachable as necessary. Almost nobody configures their firewall to open up anything. >> >> HuH? >> >> How do I SSH into my host behind my home NAT firewall without configuration of the firewall? > > Nobody but you and a few hundred other people on this mailing list SSH into hosts at your home. SSH, VNC, HTTP, HTTPs, LPD, whatever? Pick your service. SSH was just an example. > Everyone else in the entire world reaches hosts at their house through their firewall just fine because those hosts are their Nest thermostat, or their Dropcam, or their PC running Skype, or maybe (in rare cases) something like LogMeIn. I?d argue that SSH is several thousand, not a few hundred. In any case, I suppose you can make the argument that only a few people are trying to access their home network resources remotely other than via some sort of proxy/rendezvous service. However, I would argue that such services exist solely to provide a workaround for the deficiencies in the network introduced by NAT. Get rid of the stupid NAT and you no longer need such services. Even if you want to consider all of those services, the reality is that their codebases could be substantially improved and simplified as well as their security posture improved by eliminating NAT. > None of those people ever touch the settings of the device they had delivered by their ISP and/or purchased at Best Buy. Not ever. Sure? They all live like sheeple not even realizing that they?ve been handed a deficient and limited internet incapable of living up to its potential. They remain blissfully ignorant that they are a rat in a digital cage because they are unaware of life outside the cage. What?s your point? Are you claiming this makes cages a good thing? Are you claiming that since the rats are not demanding to be let out of their cages, we shouldn?t seek to create an environment where cages are not needed? >> You are making no sense here. NAT Traversal techniques provide for outbound connections and/or a way that a pseudo-service can create an inbound connection that looks like an outbound connection to the firewall. >> >> It does not in any way provide for generic inbound access to ordinary services without configuration. > > So what? > > Nobody (to several levels of statistical significance) needs "generic inbound access to ordinary services". Heck, the only "ordinary services" that exist any more are HTTP/HTTPS. This simply isn?t true. To the limited extent that it is true, the reality is that it is a consequence of the limitations of IPv4 and NAT rather than a state that anyone other than you ever really considered desirable. >>>> IPv6 ? I add a permit statement to the firewall to allow the traffic in to each host/group of hosts that I want and I am done. >>> >>> IPv6, standard NAT?firewall traversal techniques are used so that things inside your house are reachable as necessary. Still almost nobody configures their firewall to open up anything. >> >> Why would one use NAT with IPv6? You?re making no sense there. > > I didn't say you would... but you need firewall traversal, and the "standard NAT and firewall traversal techniques" are how you traverse your IPv6 firewall. That?s an awful lot of icky overhead vs. the simple clean solution of permitting desired traffic. I suspect that in the IPv6 world, eventually, rather than silly hacks like UPnP, STUN, etc., we will see, instead, standardized APIs for authenticating with the firewall and automated mechanisms for adding permission after authentication. >>> For those who do, the work needed to open up a few host/port mappings in IPv4 is basically identical to opening up a few hosts and ports for IPv6. >> >> Not really? >> >> For example, let?s say you have 20 machines for whom you want to allow inbound SSH access. In the IPv4 world, with NAT, you have to configure an individual port mapping for each machine and you have to either configure all of the SSH clients, or, specify the particular port for the machine you want to get to on the command line. > > Ok, you go find me 1000 households where nobody in the house is on the NANOG list but where there are 20 machines running SSH already installed. OK, half a dozen Video Game consoles or whatever other service you want to imagine. Just because the standard way to do things today is with silly workarounds required by the lack of address transparency created by NAT, that doesn?t mean we have to continue to do things so badly in the future. >> On the other hand, with IPv6, let?s say the machines are all on 2001:db8::/64. Further, let?s say that I group machines for which I want to provide SSH access within 2001:db8::22:0:0:0/80. I can add a single firewall entry which covers this /80 and I?m done. I can put many millions of hosts within that range and they all are accessible directly for SSH from the outside world. >> >> Takes about 20 seconds to configure my firewall once and then I never really need to worry about it again. >> > > Yeah, so there you are manually configuring your firewall again. Which isn't surprising, because you also want to have 20 hosts offering SSH to the world... which makes you an outlier. Right? Once per service or once per host per service worst case. Eventually, there will be APIs for this, but today, it?s manual. It?s manual today because being able to make use of it makes me an outlier. In the future, with address transparency, being able to deploy services will not make you a outlier. >> Further, in the IPv4 case, I need special client configuration or client invocation effort every time, while with the IPv6 case, I can simply put the hostname in DNS and then use the name thereafter. > > Sure... because like most homeowners, you're proficient at editing BIND config files. Who needs to edit BIND config file to put something in DNS? Sure, you can, and I do, but there are at least a dozen web-based DNS providers where you can host a zone file for free and manage it through a web GUI. >>>> I do not see the above as being equal effort or as yielding equal results. >>> >>> For the automatic traversal cases, the end-user effort is identical. >> >> Sure, but automatic traversal is the exception not the rule when considering internet services. >> > > I don't know what world you're living in, but every single person I know is a user of one or more software or hardware devices that work just fine behind a firewall, either because they're just uploading things to a service, or periodically checking in with a service, or using automatic traversal techniques. I?m living in a world where at least some people want to be peers rather than mere consumers. A world where the thought of being able to make phone calls without a phone company has appeal to at least some people. A world where peer to peer information and communication is considered a good and healthy thing. Sure, if you want to live in the ABC/DIsney/Comcast/NBC/Micr0$0ft fantasy world where people are mindless subjects of their corporate overlords, strictly consuming information and only that which has the approval of said corporate overlords, then the path you advocate makes perfect sense. >>> For the incredibly rare case of manual configuration (which as NANOG participants we often forget, since we're adjusting our routers all the time) there is almost no difference for most use cases. >> >> Not true as noted above. > > Most people never configure. > > Most of the people who do configure need exactly one address and port to work, in which case the work is about the same. Try configuring port forwarding for a household where there is an Xbox One and a PS/3. Not all that uncommon a scenario. Common enough that both Micr0$0ft and Sony technical support have stock scripts for telling you which home gateways you can buy that will work and how to configure them. > You have 20 SSH hosts. You're an outlier, and so yes, in IPv6 there's less typing. Picking apart the specifics of a random example doesn?t actually make the general situation less relevant. > I'm an outlier too... my house has a Juniper SRX-240 that I configure from the command line at its border. That's not normal. I'm not normal. And that's ok. On this, we can agree. >>>> As such, I?d say that your statement gets added to the great myths of Matthew Kauffman rather than there being any myth about this being an IPv6 advantage. >>>> >>>> I can assure you that it is MUCH easier for me to remote-manage my mother?s machines over their IPv6 addresses than to get to them over IPv4. >>> >>> Only because you've insisted on doing it the hard way, instead of using something like teamviewer or logmein which "just works?. >> >> So does vmc://hostname (if I have IPv6 or non-NAT IPv4). > > With default out-of-the-box firewall settings as your device arrives from Best Buy? If I were to answer strictly the question as asked, yes. However, no, but let?s compare the costs? Assuming a 3 year life-cycle on that piece of shit you bought at Best Buy... Logmein Pro for Users (cheapest alternative I could find) $99/year One-time configuration of firewall: $PIZZA for local computer whiz kid every 3 years. I?d argue that the need to configure the firewall is a very cost effective alternative with a less than one month break even. Over a 20 year timeframe, you?ve gone from $1980 (Logmein) to $105 (assuming you pay as much as $15 per pizza which is high). >>>> I live in California and have native dual-stack without NAT. She lives in Texas and has native dual-stack with NAT for her IPv4. >>> >>> And I assume your mother opened up her IPv6 firewall all on her own? >> >> As a matter of fact, she did open up the first connection which then provided me the necessary access to configure the rest for her. > > So it isn't actually that hard. Just like it isn't that hard for one address and port for the user of a Slingbox or whatever other random product you can find that doesn't have full traversal capabilities in it. It wasn?t hard because there was address transparency via IPv6 and a simple permit was all that was needed. No port forwarding, no mapping, just a ?Allow inbound packets to port XX TCP?. >>> Most people won't have the technical skills to adjust the IPv6 firewall that comes with their CPE and/or "Wireless Router" any more than they have the skills to set up IPv4 port mapping. >> >> My mother is about as non-technical as you would imagine the typical grandmother portrayed in most such examples. Technically, she?s a great grandmother these days. >> > > Congratulations to her. > >>> >>>>> IPv6 has exactly one benefit... there's more addresses. It comes with a whole lot of new pain points, and probably a bunch of security nightmare still waiting to be discovered. And it for sure isn't free. >>>> IPv6 comes with at least one design-advantage ? More addresses. >>>> >>>> However, more addresses, especially on the scale IPv6 delivers them comes with MANY benefits: >>>> >>>> 1. Simplified addressing >>>> 2. Better aggregation >>>> 3. Direct access where permitted >>>> 4. Elimination of NAT and its security flaws and disadvantages >>>> 5. Simplified topologies >>>> 6. Better subnetting >>>> 7. Better network planning with sparse allocations >>> >>> All of those are benefits for the network operator, not the end user. >> >> I can see that all of those benefit the network operator. >> >> However, with the exception of 2 and 7, I would argue that all of them are also of benefit to at least some fraction of end-users. >> > > Some fraction, sure. But since that fraction is well under 0.1%, I'm sticking with my position. I disagree. I think 3, especially, will be a growing fraction of users as address transparency becomes the norm and developers start to make use of it. >> I am an end user and I am seeing benefits from all but 2. I use sparse address allocation to allow me to classify hosts for convenience, for example. > > Outlier. Today. We?re talking about the future. I?m talking about the advantages of moving forward. You?re making excuses for remaining mired in the past. >> Note, the original item 6 (corrected above) was autocorrected from subnetting to sunbathing. I have restored it to subnetting. >> > > I preferred sunbathing. Please, go make yourself as crispy as you desire. Fortunately, for you, the sun is not behind a NAT firewall. >>>> 8. Simpler application code >>> >>> Might be true *if* there was only IPv6. If there's also the need to support IPv4 then supporting *both* is harder than supporting just one. >> >> Only because the need to support NAT traversal comes as overhead in supporting IPv4. > > The same code is needed to do IPv6 firewall traversal. But IPv6 firewall traversal isn?t necessary. >> Otherwise, most applications can be written for IPv6 and set the socket option IPV6_V6ONLY=FALSE (which should be the default) and on a dual-stack host, the application will simply work and deal with both protocols without ever caring about IPv4. (IPv4 connections are presented to the application as an IPv6 connection from a host with address ::ffff:IP:v4 (where IP:v4 is the 32-bit IPv4 address of the source host). > > For an operating system and TCP/IP stack where that is true, sure. When you're trying to squeeze things into a Cortex M4 that you want to hang on someone's wall, dual-stack takes more Flash. Yes, having two stacks in the box takes marginally more flash than one. According to http://www.ipso-alliance.org/wp-content/media/lightweight_os.pdf , an IPv6 stack shouldn?t require more than about 15k of flash. These days, that ?s not a lot even in a small ARM Cortex M4. >>>> 9. Reduced complexity in: >>>> Proxies >>>> Applications >>>> Firewalls >>>> Logging >>>> Monitoring >>>> Audit >>>> Intrusion Detection >>>> Intrusion Prevention >>>> DDoS mitigation >>> >>> Matters not to most home users. >> >> Until it does. I?ve had lots of complaints from end users where they didn?t know that the issue was a proxy problem, application coding error with NAT traversal, Firewall problem, etc., but upon investigation, these were exactly the source of said end-user?s problem. > > Define "lots". Most users are having great luck with their current IPv4-only connection and the devices they're buying to use with it. No, most users are suffering in silence because they have no idea where to go to get their problems solved. Most users haven?t experienced a working internet, so the current level of dysfunction is normal to them and they tolerate it because they have no idea that there are better alternatives available. >>> Doesn't help corporate users because they also need all that for IPv4 indefinitely. >> >> See above. The more traffic that corporate users can get off of IPv4, the less trouble these things will cause for them. As such, your argument falls flat. > > If I'm still getting support tickets due to IPv4 issues, the problems haven't gone away. Again, tell me when I can switch IPv4 off entirely. Sure? I didn?t say reducing IPv4 utilization would eliminate IPv4 issues. I said it would reduce them. However, i?m confused? If nobody has problems with IPv4 as you describe above, why are you now complaining about the number of IPv4 tickets you get. Seems you want to have your cake and eat it too here. >>>> 10. The ability to write software with hope of your codebase working for the next 10 years or more. >>> I'll bet that there's IPv4 devices running happily 10 years from now. >> >> Maybe, but I bet within 10 years, there?s very little, if any, IPv4 running across the backbone of the internet. > > I'd take that bet. I?ll put $100 on it. >>>> I?m sure there are other benefits as well, but this gives you at least 10. >>>> >>>> There are those that would argue that other design advantages include: >>>> >>>> 1. Fixed length simplified header >>> >>> Maybe. >>> >>>> 2. Stateless Address Autoconfiguration >>> >>> Disaster, given that I'm still stuck needing DHCPv6 to configure everything that SLAAC won't. Or things that SLAAC only picked up recently (like setting your DNS server) and so are still unsupported in all sorts of gear. >> >> Not a disaster, but perhaps slightly less convenient for your particular situation. >> >> In my situation, most hosts don?t need anything more than an IP address, default gateway, and Recursive Nameserver. RAs provide all of that and my hosts just work fine with SLAAC out of the box. > > Not too many WinXP machines at your house I guess. Nope? I?m very proud to say that there are NO Micr0$0ft boxes in my house. >>>> 3. Mobile IP >>> >>> Remains to be seen if this matters. >> >> I?ve found it quite useful as have several other people I know. >> > > Outlier. This seems be your answer to anything that you don?t like. Outlier or not, the protocol is useful. >>>> 4. A much cleaner implementation of IPSEC >>> >>> Sure, but the IPv4 IPSEC seems to work just fine everywhere I've deployed it. >> >> For some definition of work. The additional overhead, increased complexity of configuring it, incompatible implementations, and other nightmares I have encountered in IPv4 IPSEC vs. the relative ease and convenience of using it in IPv6 strikes me as quite worth while. >> >> A treadle sewing machine works if you choose to use one. That doesn?t mean that an electric sewing machine with CNC stitching capabilities for embroidery, etc. is not a better alternative. >> > > Given that the security provided by both is identical, I'm not sure that's a good example, but it was creative. The security provided by IPv4 IPSEC and IPv6 IPSEC is nearly identical as well. The difference is the difficulty of use. >>>> I?m sure there are more, but this is a quick list off the top of my head. >>> >>> There's a bunch of myths too... and "every device will be directly reachable from the entire Internet" is on there. >> >> That?s not a myth, it?s just an incomplete statement that people like you love to truncate for the sake of claiming it is a myth. >> >> The complete statement is ?Every device can be directly reachable from the entire internet to the extent allowed by policy.? >> >> The complete statement is quite true. The incomplete statement is false only because it contains a scope which is beyond the ability of what a protocol can deliver, due to the missing words. >> > > Yes. But those extra words mean that I need to carry around exactly the same tricks I use to get through IPv4 NAT/firewall cases. Not really? If policy permits you to pass the firewall, then you can pass without tricks. If policy doesn?t allow it, you may be able to traverse the firewall with tricks, but then the question becomes should you? True, if you are the one determining the policy, there is that pesky step of expressing the policy to the firewall. In your preferred world, this is done by adding substantial overhead to each and every piece of software and creating profound limitations on how you can use your software. In my preferred world, this is done by configuring the policy in the firewall once and simplifying the application code and increasing the probability that the security policy enforced is the security policy intended. I guess to each their own. Owen From owen at delong.com Thu Jun 4 09:16:14 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Jun 2015 10:16:14 +0100 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <556DC705.2090406@matthew.at> <4316CE97-FC2E! -4FDF-BB0D-B20E756AE64D@delong.com> Message-ID: <1AC48D74-6ACE-494C-B618-52BA1D34D7D0@delong.com> > On Jun 3, 2015, at 9:24 PM, Christopher Morrow wrote: > > On Wed, Jun 3, 2015 at 7:56 AM, Owen DeLong wrote: >> For example, let?s say you have 20 machines for whom you want to allow inbound SSH access. In the IPv4 world, with NAT, you have to configure an individual port mapping for each machine and you have to either configure all of the SSH clients, or, specify the particular port for the machine you want to get to on the command line. > > in the original case in question the fact that there's nat happeng > isn't material... so all of this discussion of NAT is a red herring, > right? the user of AWS services cares not that 'nat is happening', > because they can simply RESTful up a VM instance and ssh into it in > ~30 seconds, no config required. That depends? If they have a public address ON their machine or dedicated to their machine, then, they MAY not care that NAT is occurring. If they want to run SIP or some other protocol which depends on being able to tell the far end where to connect for secondary channels, then they may care anyway. You can reduce the number of things that NAT breaks, but you can?t eliminate them all. > let's skip all NAT discussions on this topic from here on out, yes? Only if you can promise me 100% that the NAT in question will not break anything. Owen From jra at baylink.com Thu Jun 4 16:15:44 2015 From: jra at baylink.com (Jay Ashworth) Date: Thu, 4 Jun 2015 12:15:44 -0400 (EDT) Subject: Verizon FiOS outbound mail TLS problem - Superpages people here? In-Reply-To: <7931766.181.1433434364073.JavaMail.root@benjamin.baylink.com> Message-ID: <22667917.183.1433434544723.JavaMail.root@benjamin.baylink.com> Anyone on the list who does outbound delivery for Verizon (which I think is actually Superpages)? A client has smart-hosted outbounds to *one* of his customers bouncing suddenly with Deferred: 403 4.7.0 TLS handshake failed. *My* inclination is to think that a cert expired somewhere, but his non-tech contact there tells him that the tech people think things are ok. I'm trying to get a mailer log fragment from them. 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 jrjahangir at gmail.com Thu Jun 4 14:24:58 2015 From: jrjahangir at gmail.com (Jahangir Hossain) Date: Thu, 4 Jun 2015 20:24:58 +0600 Subject: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation In-Reply-To: References: Message-ID: Dear Pavel , This is definitely interesting project . I already tested the previous version but due to some feature limitation i could not continue but i think this new version added very important features . Definitely I will trail the new version soon . On Wed, Jun 3, 2015 at 2:16 AM, Pavel Odintsov wrote: > Hello, Nanog! > > I'm very pleased to present my open source DoS/DDoS attack monitoring > toolkit here! > > We have spent about 10 months for development of FastNetMon and could > present huge feature list now! :) > > Stop! What is FastNetMon? > > It's really very fast toolkit which could find attacked host in your > network and block it (or redirect to filtering appliance) > > This solution could save your network and your sleep :) > > Our site located here: https://github.com/FastVPSEestiOu/fastnetmon > > We support following engines for traffic capture: > - Netflow (v5, v9 and IPFIX) > - sFLOW v5 > - port mirror/SPAN (PF_RING and netmap supported) > > Also we have deep integration with ExaBGP (huge thanks to Thomas > Mangin) for triggering blackhole on the Core Router or upstream. > > Since 1.0 version we have added support for following features: > - Ability to detect most popular attack types: syn_flood, icmp_flood, > udp_flood, ip_fragmentation_flood > - Add support for Netmap for Linux (we have prepared special driver > for ixgbe users: https://github.com/pavel-odintsov/ixgbe-linux-netmap) > and FreeBSD. > - Add support for PF_RING ZC (very fast but need license from ntop folks) > - Add ability to collect netflow v9/IPFIX data from multiple devices > with different templates set > - Basic support for IPv6 (we could receive netflow data over IPv6) > - Add plugin support for capture engines > - Add support of L2TP decapsulation (important for DDoS attack > detection inside tunnel) > - Add ability to store attack details in Redis > - Add Graphite/Grafana integration for traffic visualization > - Add systemd unit file > - Add ability to unblock host after some timeout > - Introduce support of moving average for all counters > - Add ExaBGP integration. We could announce attacked host with BGP to > border router or uplink > - Add so much details in attack report > - Add ability to store attack fingerprint in file > > We have complete support for following platforms: > - Fedora 21 > - Debian 6, 7, 8 > - CentOS 6, 7 > - FreeBSD 9, 10, 11 > - DragonflyBSD 4 > - MacOS X 10.10 > > From network equipment side we have tested solution with: > - Cisco ASR > - Juniper MX > - Extreme Summit > - ipt_NETFLOW Linux > > We have binary packages for this operation systems: > - CentOS 6: > https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/CentOS6 > - CentOS 7: > https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/CentOS7 > - Fedora 21: > https://github.com/FastVPSEestiOu/fastnetmon/tree/master/packages/Fedora21 > - FreeBSD: > https://github.com/FastVPSEestiOu/fastnetmon/tree/master/src/FreeBSD_port > > For any other operation systems we recommend automatic installer > script: > https://github.com/FastVPSEestiOu/fastnetmon/blob/master/docs/INSTALL.md > > Please join to our mail list or ask about anything here > https://groups.google.com/forum/#!forum/fastnetmon > > Thank you for your attention! > > -- > Sincerely yours, Pavel Odintsov > -- - Jahangir From blake at ispn.net Thu Jun 4 16:46:35 2015 From: blake at ispn.net (Blake Hudson) Date: Thu, 04 Jun 2015 11:46:35 -0500 Subject: Verizon FiOS outbound mail TLS problem - Superpages people here? In-Reply-To: <22667917.183.1433434544723.JavaMail.root@benjamin.baylink.com> References: <22667917.183.1433434544723.JavaMail.root@benjamin.baylink.com> Message-ID: <557080EB.30001@ispn.net> I have no relation, but as a mail server operator I can say that I wouldn't be surprised if this is actually a TLS version mismatch or intolerance problem. I would suggest ensuring that both ends support TLS 1.0, 1.1, and 1.2 and use version tolerant TLS implementations. Next on the short list would be not having compatible cyphers between the two servers. Either way, since the error was a 403 error, the expected behavior would be to queue and retry in plain text; Sounds like a broken MTA implementation or misconfiguration if the sending servers do not revert to plain text. --Blake Jay Ashworth wrote on 6/4/2015 11:15 AM: > Anyone on the list who does outbound delivery for Verizon (which I think > is actually Superpages)? A client has smart-hosted outbounds to *one* > of his customers bouncing suddenly with > > Deferred: 403 4.7.0 TLS handshake failed. > > *My* inclination is to think that a cert expired somewhere, but his non-tech > contact there tells him that the tech people think things are ok. > > I'm trying to get a mailer log fragment from them. > > Cheers, > -- jra > From jra at baylink.com Thu Jun 4 16:47:00 2015 From: jra at baylink.com (Jay Ashworth) Date: Thu, 4 Jun 2015 12:47:00 -0400 (EDT) Subject: NANOG 64 recordings In-Reply-To: <556FC313.6020407@sadiqs.com> Message-ID: <17711091.185.1433436420032.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Sadiq Saif" > For those that missed them: > https://www.youtube.com/playlist?list=PLO8DR5ZGla8ju3ftZv_S6L12jBkZKEJVZ Oh, outstanding. Thanks. 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 jimpop at gmail.com Thu Jun 4 16:53:33 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 4 Jun 2015 12:53:33 -0400 Subject: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation In-Reply-To: References: Message-ID: There's a surprising amount of GMail (yes, including me) and new-ness in this thread. Should I be impressed with the freshness or concerned about astroturfing? :-) Bah Humbug! -Jim P. From jra at baylink.com Thu Jun 4 16:57:09 2015 From: jra at baylink.com (Jay Ashworth) Date: Thu, 4 Jun 2015 12:57:09 -0400 (EDT) Subject: Should I Reboot, and Why? (was Re: [RDD] No Play out on Cart Wall) In-Reply-To: <201505311603.06311.curt@cwf1.com> Message-ID: <1405179.191.1433437029515.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Cowboy" > On Sunday 31 May 2015 03:49:10 pm Graham Wilman wrote: > > after getting the play out working on clienta terminal for the past > > 6 days > > the decision was taken today to get clientb terminal working which > > it now partially is > > unfortunately once all 3 terminals the server.clienta and clientb > > were rebooted I could > > not get play out to work on clienta again > > Re-booted why ? > I've often said that rebooting a *nix machine is usually a bad idea. And, again, a good to recap some of Good Sysadmin Practice: In the Windows world, it's often recommended that you reboot a machine that is acting -- as we say in support -- hincky. That's because Windows is sufficiently complicated and fragile that things can get corrupt at runtime, and the simple fact you rebooted it can fix a problem. That's traditionally not been true in the *nix world; particularly on purpose-built single function servers, there simply isn't enough code running at once to allow for the sort of complicated, multiplicative complexity failures that you see in many Windows machines. But does that mean you should never reboot a Linux box, just because you usually don't *have* to, to fix your problem? No, it doesn't, and here's why: Some of the things you might change in your configuration can affect how things start *when* you boot up, and if you've adjusted one of them, the time to boot it and find out *is right now, when you've just made the change and it's fresh in your mind*, not 6 months from now at 3 in the morning, when you don't remember what you did. Well, I suppose you could look in your logbook. Or check your ticketing system. :-) 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 morrowc.lists at gmail.com Thu Jun 4 17:10:48 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 4 Jun 2015 13:10:48 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <1AC48D74-6ACE-494C-B618-52BA1D34D7D0@delong.com> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <556DC705.2090406@matthew.at> <1AC48D74-6ACE-494C-B618-52BA1D34D7D0@delong.com> Message-ID: On Thu, Jun 4, 2015 at 5:16 AM, Owen DeLong wrote: > >> On Jun 3, 2015, at 9:24 PM, Christopher Morrow wrote: > >> let's skip all NAT discussions on this topic from here on out, yes? > > Only if you can promise me 100% that the NAT in question will not break anything. :) people don't seem to be bothered today. From victor.zakharyev at gmail.com Thu Jun 4 17:11:02 2015 From: victor.zakharyev at gmail.com (Victor Zakharyev) Date: Thu, 04 Jun 2015 17:11:02 +0000 Subject: NANOG 64 recordings In-Reply-To: <17711091.185.1433436420032.JavaMail.root@benjamin.baylink.com> References: <556FC313.6020407@sadiqs.com> <17711091.185.1433436420032.JavaMail.root@benjamin.baylink.com> Message-ID: Does anyone have videos from Google presentations on Telemetry? Thanks! Victor ??, 4 ???? 2015 ?. ? 9:51, Jay Ashworth : > ----- Original Message ----- > > From: "Sadiq Saif" > > > For those that missed them: > > https://www.youtube.com/playlist?list=PLO8DR5ZGla8ju3ftZv_S6L12jBkZKEJVZ > > Oh, outstanding. Thanks. > > 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 morrowc.lists at gmail.com Thu Jun 4 17:16:03 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 4 Jun 2015 13:16:03 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <233AFE07-72FB-4BF8-A8E9-BA9BCB54072C@delong.com> References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <556DC705.2090406@matthew.at> <4316CE97-FC2E-4FDF-BB0D-B20E756AE64D@delong.com> <556F2382.8010409@matthew.at> <233AFE07-72FB-4BF8-A8E9-BA9BCB54072C@delong.com> Message-ID: On Thu, Jun 4, 2015 at 5:11 AM, Owen DeLong wrote: > I?d argue that SSH is several thousand, not a few hundred. In any case, I suppose you can make the argument that only a few people are trying to access their home network resources remotely other than via some sort of proxy/rendezvous service. However, I would argue that such services exist solely to provide a workaround for the deficiencies in the network introduced by NAT. Get rid of the stupid NAT and you no longer need such services. This is an interesting argument/point, but if you remove the rendevous service then how do you find the thing in your house? now the user has to manage DNS, or the service in question has to manage a dns entry for the customer, right? you'll be moving the (some of the) pain from 'nat' to 'dns' (or more generally naming and identification). I think though that in a better world, a service related to the thing you want to prod from outside would manage this stuff for you. It's important (I think) to not simplify the discussion as: "Oh, with ipv6 magic happens!" because there are still problems and design things to overcome even with unhindered end-to-end connectivity. From pavel.odintsov at gmail.com Thu Jun 4 17:32:30 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Thu, 4 Jun 2015 20:32:30 +0300 Subject: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation In-Reply-To: References: Message-ID: Looks like many folks want hide company emails ;) I'm good guy and will not spam or offer slmething ;))) But I'm impressed about amount of off list requests. Really huge interest in tool. On Thursday, June 4, 2015, Jim Popovitch wrote: > There's a surprising amount of GMail (yes, including me) and new-ness > in this thread. Should I be impressed with the freshness or > concerned about astroturfing? :-) > > Bah Humbug! > > -Jim P. > -- Sincerely yours, Pavel Odintsov From mansaxel at besserwisser.org Thu Jun 4 17:44:29 2015 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 4 Jun 2015 19:44:29 +0200 Subject: AWS Elastic IP architecture In-Reply-To: References: <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <556DC705.2090406@matthew.at> <4316CE97-FC2E-4FDF-BB0D-B20E756AE64D@delong.com> <556F2382.8010409@matthew.at> <233AFE07-72FB-4BF8-A8E9-BA9BCB54072C@delong.com> Message-ID: <20150604174429.GA12432@besserwisser.org> Subject: Re: AWS Elastic IP architecture Date: Thu, Jun 04, 2015 at 01:16:03PM -0400 Quoting Christopher Morrow (morrowc.lists at gmail.com): > On Thu, Jun 4, 2015 at 5:11 AM, Owen DeLong wrote: > > I?d argue that SSH is several thousand, not a few hundred. In any case, I suppose you can make the argument that only a few people are trying to access their home network resources remotely other than via some sort of proxy/rendezvous service. However, I would argue that such services exist solely to provide a workaround for the deficiencies in the network introduced by NAT. Get rid of the stupid NAT and you no longer need such services. > > This is an interesting argument/point, but if you remove the rendevous > service then how do you find the thing in your house? now the user has > to manage DNS, or the service in question has to manage a dns entry > for the customer, right? Or something. > you'll be moving the (some of the) pain from 'nat' to 'dns' (or more > generally naming and identification). I think though that in a better > world, a service related to the thing you want to prod from outside > would manage this stuff for you. Possibly. > It's important (I think) to not simplify the discussion as: "Oh, with > ipv6 magic happens!" because there are still problems and design > things to overcome even with unhindered end-to-end connectivity. You have successfully demonstrated that users will need some locating service. More so with the cure-all IPv6; because remembering hex is hard for People(tm). You have, however, not shown that all the possible ways of building a locating service that become available once the end-points are uniquely reachable (and thus, as long as we're OK with finding just the right host, identifyable) present an equal level of suckage. I believe that while the work indeed can be daunting for a sufficiently pessimal selection of users, the situation so improves (if we look at simplicity of protocol design and resulting fragility) when the end-points can ignore any middleboxes that the net result, measured as inconvenicence imposed on a standard End User, will improve. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Why is everything made of Lycra Spandex? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From outsider at scarynet.org Thu Jun 4 17:47:29 2015 From: outsider at scarynet.org (Alexander Maassen) Date: Thu, 04 Jun 2015 19:47:29 +0200 Subject: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation Message-ID: It's a security tool. So ppl using it want to publicly hide the fact they use it in case you screw up and it contains leaks ;) -------- Oorspronkelijk bericht -------- Van: Pavel Odintsov Datum: Aan: Jim Popovitch Cc: nanog at nanog.org Onderwerp: Re: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation Looks like many folks want hide company emails ;) I'm good guy and will not spam or offer slmething ;))) But I'm impressed about amount of off list requests. Really huge interest in tool. On Thursday, June 4, 2015, Jim Popovitch wrote: > There's a surprising amount of GMail (yes, including me) and new-ness > in this thread.??? Should I be impressed with the freshness or > concerned about astroturfing??? :-) > > Bah Humbug! > > -Jim P. > -- Sincerely yours, Pavel Odintsov From roberto.berto at gmail.com Thu Jun 4 17:51:41 2015 From: roberto.berto at gmail.com (=?UTF-8?Q?Roberto_Bert=C3=B3?=) Date: Thu, 4 Jun 2015 14:51:41 -0300 Subject: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation In-Reply-To: References: Message-ID: What about we build a Docker? 2015-06-04 14:47 GMT-03:00 Alexander Maassen : > It's a security tool. So ppl using it want to publicly hide the fact they > use it in case you screw up and it contains leaks ;) > > -------- Oorspronkelijk bericht -------- > Van: Pavel Odintsov > Datum: > Aan: Jim Popovitch > Cc: nanog at nanog.org > Onderwerp: Re: FastNetMon 1.1.2 - open source solution for DoS/DDoS > mitigation > > Looks like many folks want hide company emails ;) I'm good guy and will not > spam or offer slmething ;))) > > But I'm impressed about amount of off list requests. Really huge interest > in tool. > > On Thursday, June 4, 2015, Jim Popovitch wrote: > > > There's a surprising amount of GMail (yes, including me) and new-ness > > in this thread. Should I be impressed with the freshness or > > concerned about astroturfing? :-) > > > > Bah Humbug! > > > > -Jim P. > > > > > -- > Sincerely yours, Pavel Odintsov > From lists at sadiqs.com Thu Jun 4 17:53:46 2015 From: lists at sadiqs.com (Sadiq Saif) Date: Thu, 04 Jun 2015 13:53:46 -0400 Subject: VPS + BGP session Message-ID: <557090AA.1060308@sadiqs.com> Hi, I am looking for providers that can provide me a VPS with a BGP session so I can announce my PI IP space (v4 + v6). I have looked at other threads on NANOG regarding this and already have sessions up with ARP Networks, Mythic Beasts, and Knightswarm. Host Virtual is unfortunately out of my budget. I am looking for providers in the east coast USA and Asia Pacific regions at this time. Any pointers are appreciated! -- Sadiq Saif (AS393949) https://staticsafe.ca From pavel.odintsov at gmail.com Thu Jun 4 17:55:39 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Thu, 4 Jun 2015 20:55:39 +0300 Subject: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation In-Reply-To: References: Message-ID: Brilliant idea! But in Docker we could offer only sflow and sflow. Port mirror capture need support from the kernel side. Will try shortly! On Thursday, June 4, 2015, Roberto Bert? wrote: > What about we build a Docker? > > 2015-06-04 14:47 GMT-03:00 Alexander Maassen >: > > > It's a security tool. So ppl using it want to publicly hide the fact they > > use it in case you screw up and it contains leaks ;) > > > > -------- Oorspronkelijk bericht -------- > > Van: Pavel Odintsov > > > Datum: > > Aan: Jim Popovitch > > > Cc: nanog at nanog.org > > Onderwerp: Re: FastNetMon 1.1.2 - open source solution for DoS/DDoS > > mitigation > > > > Looks like many folks want hide company emails ;) I'm good guy and will > not > > spam or offer slmething ;))) > > > > But I'm impressed about amount of off list requests. Really huge interest > > in tool. > > > > On Thursday, June 4, 2015, Jim Popovitch > wrote: > > > > > There's a surprising amount of GMail (yes, including me) and new-ness > > > in this thread. Should I be impressed with the freshness or > > > concerned about astroturfing? :-) > > > > > > Bah Humbug! > > > > > > -Jim P. > > > > > > > > > -- > > Sincerely yours, Pavel Odintsov > > > -- Sincerely yours, Pavel Odintsov From morrowc.lists at gmail.com Thu Jun 4 18:18:24 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 4 Jun 2015 14:18:24 -0400 Subject: AWS Elastic IP architecture In-Reply-To: <20150604174429.GA12432@besserwisser.org> References: <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <556DC705.2090406@matthew.at> <4316CE97-FC2E-4FDF-BB0D-B20E756AE64D@delong.com> <556F2382.8010409@matthew.at> <233AFE07-72FB-4BF8-A8E9-BA9BCB54072C@delong.com> <20150604174429.GA12432@besserwisser.org> Message-ID: On Thu, Jun 4, 2015 at 1:44 PM, M?ns Nilsson wrote: > You have successfully demonstrated that users will need some locating > service. More so with the cure-all IPv6; because remembering hex is hard > for People(tm). but it's not just hex. Even today you (if given a bare ipv4 address) would need some naming/locating service I suspect. Folk can barely remember their email address, nevermind the hostname of their printer/etc for remote use. Today we 'win' because there's some third-party aggregating 'your device' and 'you' and connecting them together 'properly'. > You have, however, not shown that all the possible ways of building a > locating service that become available once the end-points are uniquely > reachable (and thus, as long as we're OK with finding just the right host, > identifyable) present an equal level of suckage. > sure, I wasn't really trying to accomplish that, just to point out that: you still have to find me in the haystack! and 'well then put dns records in your domain' isn't an answer for 99.99+% of users. Even if Owen's swag of 'thousands' of users 'use ssh' is on target there are ~100m users in the US on cable/dsl plant... (so with 10 ssh users ~.01%) that will basically never 'get it'. > I believe that while the work indeed can be daunting for a sufficiently > pessimal selection of users, the situation so improves (if we look at > simplicity of protocol design and resulting fragility) when the end-points > can ignore any middleboxes that the net result, measured as inconvenicence > imposed on a standard End User, will improve. I bet we end up with the same rendezvous services though... perhaps we wont have to worry about the 'printer' making a long-term (or even periodic?) connection to that service, but I imagine there'll still be some service complexity. It may be better than the current situation, but that's still to be seen. From rafael at gav.ufsc.br Thu Jun 4 18:24:11 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Thu, 4 Jun 2015 13:24:11 -0500 Subject: Should I Reboot, and Why? (was Re: [RDD] No Play out on Cart Wall) In-Reply-To: <1405179.191.1433437029515.JavaMail.root@benjamin.baylink.com> References: <201505311603.06311.curt@cwf1.com> <1405179.191.1433437029515.JavaMail.root@benjamin.baylink.com> Message-ID: I also reboot for kernel updates! On Thu, Jun 4, 2015 at 11:57 AM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Cowboy" > > > On Sunday 31 May 2015 03:49:10 pm Graham Wilman wrote: > > > > after getting the play out working on clienta terminal for the past > > > 6 days > > > the decision was taken today to get clientb terminal working which > > > it now partially is > > > unfortunately once all 3 terminals the server.clienta and clientb > > > were rebooted I could > > > not get play out to work on clienta again > > > > Re-booted why ? > > I've often said that rebooting a *nix machine is usually a bad idea. > > And, again, a good to recap some of Good Sysadmin Practice: > > In the Windows world, it's often recommended that you reboot a machine that > is acting -- as we say in support -- hincky. That's because Windows is > sufficiently complicated and fragile that things can get corrupt at > runtime, and the simple fact you rebooted it can fix a problem. > > That's traditionally not been true in the *nix world; particularly on > purpose-built single function servers, there simply isn't enough code > running at once to allow for the sort of complicated, multiplicative > complexity failures that you see in many Windows machines. > > But does that mean you should never reboot a Linux box, just because > you usually don't *have* to, to fix your problem? > > No, it doesn't, and here's why: > > Some of the things you might change in your configuration can affect > how things start *when* you boot up, and if you've adjusted one of them, > the time to boot it and find out *is right now, when you've just made the > change and it's fresh in your mind*, not 6 months from now at 3 in the > morning, when you don't remember what you did. > > Well, I suppose you could look in your logbook. Or check your ticketing > system. :-) > > 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 rafael at gav.ufsc.br Thu Jun 4 18:26:45 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Thu, 4 Jun 2015 13:26:45 -0500 Subject: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation In-Reply-To: References: Message-ID: You could look into LXD for that type of deployment. On Thu, Jun 4, 2015 at 12:55 PM, Pavel Odintsov wrote: > Brilliant idea! But in Docker we could offer only sflow and sflow. Port > mirror capture need support from the kernel side. Will try shortly! > > On Thursday, June 4, 2015, Roberto Bert? wrote: > > > What about we build a Docker? > > > > 2015-06-04 14:47 GMT-03:00 Alexander Maassen > >: > > > > > It's a security tool. So ppl using it want to publicly hide the fact > they > > > use it in case you screw up and it contains leaks ;) > > > > > > -------- Oorspronkelijk bericht -------- > > > Van: Pavel Odintsov > > > > Datum: > > > Aan: Jim Popovitch > > > > Cc: nanog at nanog.org > > > Onderwerp: Re: FastNetMon 1.1.2 - open source solution for DoS/DDoS > > > mitigation > > > > > > Looks like many folks want hide company emails ;) I'm good guy and will > > not > > > spam or offer slmething ;))) > > > > > > But I'm impressed about amount of off list requests. Really huge > interest > > > in tool. > > > > > > On Thursday, June 4, 2015, Jim Popovitch > > wrote: > > > > > > > There's a surprising amount of GMail (yes, including me) and new-ness > > > > in this thread. Should I be impressed with the freshness or > > > > concerned about astroturfing? :-) > > > > > > > > Bah Humbug! > > > > > > > > -Jim P. > > > > > > > > > > > > > -- > > > Sincerely yours, Pavel Odintsov > > > > > > > > -- > Sincerely yours, Pavel Odintsov > From tagno25 at gmail.com Thu Jun 4 18:28:39 2015 From: tagno25 at gmail.com (Philip Dorr) Date: Thu, 4 Jun 2015 13:28:39 -0500 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <556DC705.2090406@matthew.at> <4316CE97-FC2E-4FDF-BB0D-B20E756AE64D@delong.com> <556F2382.8010409@matthew.at> <233AFE07-72FB-4BF8-A8E9-BA9BCB54072C@delong.com> Message-ID: On Thu, Jun 4, 2015 at 12:16 PM, Christopher Morrow wrote: > On Thu, Jun 4, 2015 at 5:11 AM, Owen DeLong wrote: >> I?d argue that SSH is several thousand, not a few hundred. In any case, I suppose you can make the argument that only a few people are trying to access their home network resources remotely other than via some sort of proxy/rendezvous service. However, I would argue that such services exist solely to provide a workaround for the deficiencies in the network introduced by NAT. Get rid of the stupid NAT and you no longer need such services. > > This is an interesting argument/point, but if you remove the rendevous > service then how do you find the thing in your house? now the user has > to manage DNS, or the service in question has to manage a dns entry > for the customer, right? You do not remove the locating service, what you remove is the remote proxy service. For example with a webcam on IPv4, you would connect to website to download the video. The camera would also connect to the website to upload the video. On IPv6 the webcam would connect to the website to say that it is alive and what its IP is. You would connect to the website and your computer would get the IP and directly connect to the webcam. If there were multiple people connecting, you may even be able to use multicast. From rs at seastrom.com Thu Jun 4 21:52:16 2015 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 04 Jun 2015 17:52:16 -0400 Subject: stacking pdu In-Reply-To: (William Herrin's message of "Fri, 29 May 2015 17:29:47 -0400") References: Message-ID: <86k2vj16r3.fsf@valhalla.seastrom.com> William Herrin writes: > Isn't it against the NEC and the fire code to stack power strips? We > all do it, but isn't it against code? Sorry to be late to the party (I plead vacation), but no, afaik it is not. About as close as the NEC comes art 400.8 - you can't use flexible cord as a substitute for permanent wiring (think of some of the shenanigans you've seen with extension cords standing in for NM or MC on thereifixed.com or similar sites). Rack wiring is not "permanent", but I would not go so far as to claim it is subject to the "qualified personnel" rules (OSHA subpart S and NFPA 70E). Datacenter workers who could pass a test on LOTO procedures and routinely utilize proper PPE (even gloves, safety glasses, and steel toe shoes) are the exception rather than the rule. As always, when someone asserts that "X is against code" whether in the form of a statement or a question, the proper response is "Citation, please!" -r From marka at isc.org Thu Jun 4 22:28:38 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 05 Jun 2015 08:28:38 +1000 Subject: AWS Elastic IP architecture In-Reply-To: Your message of "Thu, 04 Jun 2015 13:28:39 -0500." References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <556DC705.2090406@matthew.at> <4316CE97-FC2E-4FDF-BB0D-B20E756AE64D@delong.com> <556F2382.8010409@matthew.at> <233AFE07-72FB-4BF8-A8E9-BA9BCB54072C@delon g.com> Message-ID: <20150604222839.683AE3006C37@rock.dv.isc.org> In message , Philip Dorr writes: > On Thu, Jun 4, 2015 at 12:16 PM, Christopher Morrow > wrote: > > On Thu, Jun 4, 2015 at 5:11 AM, Owen DeLong wrote: > >> I=E2=80=99d argue that SSH is several thousand, not a few hundred. In an= > y case, I suppose you can make the argument that only a few people are tryi= > ng to access their home network resources remotely other than via some sort= > of proxy/rendezvous service. However, I would argue that such services exi= > st solely to provide a workaround for the deficiencies in the network intro= > duced by NAT. Get rid of the stupid NAT and you no longer need such service= > s. > > > > This is an interesting argument/point, but if you remove the rendevous > > service then how do you find the thing in your house? now the user has > > to manage DNS, or the service in question has to manage a dns entry > > for the customer, right? > > You do not remove the locating service, what you remove is the remote > proxy service. And the DNS is the simplest location service. Windows boxes and Mac's can register themselves in the DNS today using standardised protocols. This really isn't a hard thing to do. All you need is a fully qualified hostname, addresses and update credentials (username/password (TSIG) or a public key pair SIG(0)) and you can update the addresses records using the DNS and UPDATE. Windows uses GSS-TSIG (Kerberos) to authenticate the UPDATE request. In theory it could also use plain TSIG and/or SIG(0). What is hard is giving them a globally unique address today because it doesn't exist for 99.9% of the devices connected in the world due to the world having run out of IPv4 address about ~20 years ago. At the moment we are at ~1 address per household for IPv4. We are heading into < 1 address per household for most of the households in the world. For a Mac you do System Preference -> Sharing -> Edit and Tick "Use dynamic global hostname" add the hostname and TSIG credentials (User/Password). The Mac will save them. The Mac will then update the address records for itself as they change. What has to happen is making this a regular part of setting up a machine for the first time. This requires other OS vendors adding equivalent functionality to their OS's. > For example with a webcam on IPv4, you would connect to website to > download the video. The camera would also connect to the website to > upload the video. > > On IPv6 the webcam would connect to the website to say that it is > alive and what its IP is. You would connect to the website and your > computer would get the IP and directly connect to the webcam. If > there were multiple people connecting, you may even be able to use > multicast. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joe at nethead.com Thu Jun 4 22:54:00 2015 From: joe at nethead.com (Joe Hamelin) Date: Thu, 4 Jun 2015 15:54:00 -0700 Subject: stacking pdu In-Reply-To: <86k2vj16r3.fsf@valhalla.seastrom.com> References: <86k2vj16r3.fsf@valhalla.seastrom.com> Message-ID: This takes me back to the days of old with bread racks full of modems and the mess of wall-warts and power-strips. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Thu, Jun 4, 2015 at 2:52 PM, Rob Seastrom wrote: > > William Herrin writes: > > > Isn't it against the NEC and the fire code to stack power strips? We > > all do it, but isn't it against code? > > Sorry to be late to the party (I plead vacation), but no, afaik it is > not. About as close as the NEC comes art 400.8 - you can't use > flexible cord as a substitute for permanent wiring (think of some of > the shenanigans you've seen with extension cords standing in for NM or > MC on thereifixed.com or similar sites). > > Rack wiring is not "permanent", but I would not go so far as to claim > it is subject to the "qualified personnel" rules (OSHA subpart S and > NFPA 70E). Datacenter workers who could pass a test on LOTO > procedures and routinely utilize proper PPE (even gloves, safety > glasses, and steel toe shoes) are the exception rather than the rule. > > As always, when someone asserts that "X is against code" whether in > the form of a statement or a question, the proper response is > "Citation, please!" > > -r > > From pete at altadena.net Thu Jun 4 23:24:49 2015 From: pete at altadena.net (Pete Carah) Date: Thu, 04 Jun 2015 19:24:49 -0400 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <556DC705.2090406@matthew.at> <4316CE97-FC2E-4FDF-BB0D-B20E756AE64D@delong.com> <556F2382.8010409@matthew.at> <233AFE07-72FB-4BF8-A8E9-BA9BCB54072C@delong.com> Message-ID: <5570DE41.7000502@altadena.net> On 06/04/2015 01:16 PM, Christopher Morrow wrote: > On Thu, Jun 4, 2015 at 5:11 AM, Owen DeLong wrote: >> I?d argue that SSH is several thousand, not a few hundred. In any case, I suppose you can make the argument that only a few people are trying to access their home network resources remotely other than via some sort of proxy/rendezvous service. However, I would argue that such services exist solely to provide a workaround for the deficiencies in the network introduced by NAT. Get rid of the stupid NAT and you no longer need such services. > This is an interesting argument/point, but if you remove the rendevous > service then how do you find the thing in your house? now the user has > to manage DNS, or the service in question has to manage a dns entry > for the customer, right? A large part of my heartburn with this is the proliferation of unidentified rendezvous services with no hint of SLA or anything that are burned in to things like door locks, thermostats, washing machines, etc etc. (also no hint of where and even what country has the rendezvous in question...) Once I've equipped my house with IoT devices, there will be a bunch (hundred?) outbound connections to different rendezvous services. Nothing in the box or literature identifies the server(s) in question either. (and likely most of them don't even use https.) You want your door lock and thermostat to effectively publish when you are away for a couple of weeks, onto someone else's unidentified server? At least dns rendezvous allow endpoint security if the manufacturer even thinks about that... -- Pete .... From petebaldridge at gmail.com Thu Jun 4 23:31:22 2015 From: petebaldridge at gmail.com (Pete Baldridge) Date: Thu, 04 Jun 2015 16:31:22 -0700 Subject: NANOG 64 recordings In-Reply-To: References: <556FC313.6020407@sadiqs.com> <17711091.185.1433436420032.JavaMail.root@benjamin.baylink.com> Message-ID: On June 4, 2015 10:11:02 AM PDT, Victor Zakharyev wrote: >Does anyone have videos from Google presentations on Telemetry? > >Thanks! > >Victor > >??, 4 ???? 2015 ?. ? 9:51, Jay Ashworth : > >> ----- Original Message ----- >> > From: "Sadiq Saif" >> >> > For those that missed them: >> > >https://www.youtube.com/playlist?list=PLO8DR5ZGla8ju3ftZv_S6L12jBkZKEJVZ >> >> Oh, outstanding. Thanks. >> >> 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 >> Can anyone comment on what was in the video that's been removed? Is there somewhere else that it can be found? -- Pete Sent from mobile. From bzs at world.std.com Fri Jun 5 01:02:33 2015 From: bzs at world.std.com (Barry Shein) Date: Thu, 4 Jun 2015 21:02:33 -0400 (EDT) Subject: Roof space, co-lo... Message-ID: <201506050102.t5512XQZ014745@world.std.com> A company has asked me if I could find anyone who could provide: 1. Roof space for a 1.2m dish 2. About 2U rackspace (i.e., not a whole rack minimum) 3. Modest (5-10mb) bandwith. 4. Cabling between the rackspace and roof dish 5. Power Prefer Boston/Cambridge area but would consider other venues. I don't know a lot more about it but I think the key request here is the roof space for the 1.2m dish and cabling to the boxes. I don't know which way the dish must face or anything like that if you do this for a living I will put you in touch and you can work it out. Respond to me: bzs at TheWorld.com (some of you were Bcc'd on this) -- -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 mpetach at netflight.com Fri Jun 5 01:36:50 2015 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 4 Jun 2015 18:36:50 -0700 Subject: stacking pdu In-Reply-To: <86k2vj16r3.fsf@valhalla.seastrom.com> References: <86k2vj16r3.fsf@valhalla.seastrom.com> Message-ID: On Thu, Jun 4, 2015 at 2:52 PM, Rob Seastrom wrote: > ... > MC on thereifixed.com or similar sites). thereifixedit.com iftfy. ;P Matt From ag4ve.us at gmail.com Fri Jun 5 04:51:25 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 5 Jun 2015 00:51:25 -0400 Subject: stacking pdu In-Reply-To: References: <86k2vj16r3.fsf@valhalla.seastrom.com> Message-ID: Well, I was kinda thinking this would turn out to be a dumb question / have an obvious answer. Apparently not. But it seems I can't go buy a solution either. I guess there isn't much of a market (though I am just talking software - maybe someone could make an update :) ). From bill at herrin.us Fri Jun 5 05:03:30 2015 From: bill at herrin.us (William Herrin) Date: Fri, 5 Jun 2015 01:03:30 -0400 Subject: VPS + BGP session In-Reply-To: <557090AA.1060308@sadiqs.com> References: <557090AA.1060308@sadiqs.com> Message-ID: On Thu, Jun 4, 2015 at 1:53 PM, Sadiq Saif wrote: > I am looking for providers that can provide me a VPS with a BGP session > so I can announce my PI IP space (v4 + v6). I have looked at other > threads on NANOG regarding this and already have sessions up with ARP > Networks, Mythic Beasts, and Knightswarm. Host Virtual is unfortunately > out of my budget. Hi Sadiq, I assume you found this: http://mailman.nanog.org/pipermail/nanog/2015-February/073592.html Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From david at mandelberg.org Fri Jun 5 03:56:01 2015 From: david at mandelberg.org (David Mandelberg) Date: Thu, 04 Jun 2015 23:56:01 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> Message-ID: <55711DD1.8040906@mandelberg.org> On 06/03/2015 04:27 AM, Roland Dobbins wrote: > (not to mention the > enumeration and enhanced DDoS impact of packeting routers doing crypto > for their BGP sessions and which aren't protected via iACLs/GTSM). Could you elaborate on your enumeration and DDoS concerns? If you're concerned about the public finding out exactly how many routers you have because you've published one BGPsec router key per router, you can choose to use the same router key on multiple routers. If you're concerned about all the crypto work overloading a router, the plan (as far as I've heard) is for the routers to do the BGPsec crypto work in the background as a low priority. I.e., incoming signed routes will initially be treated like unsigned routes, and the BGPsec validation will be kicked off in the background. Once the validation is complete, then routing decisions can be made based on the BGPsec validity. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From david at mandelberg.org Fri Jun 5 04:01:48 2015 From: david at mandelberg.org (David Mandelberg) Date: Fri, 05 Jun 2015 00:01:48 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> Message-ID: <55711F2C.5050508@mandelberg.org> On 06/02/2015 10:04 PM, Ethan Katz-Bassett wrote: > The same folks also followed up that workshop paper with a longer paper on > the topic: > https://www.cs.bu.edu/~goldbe/papers/sigRPKI.pdf And a different set of folks (including me) are working on a different mechanism to protect against attacks from on high. Any feedback would be appreciated. https://tools.ietf.org/html/draft-kent-sidr-suspenders-03 -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From rdobbins at arbor.net Fri Jun 5 06:40:49 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 05 Jun 2015 13:40:49 +0700 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <55711DD1.8040906@mandelberg.org> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> Message-ID: <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> On 5 Jun 2015, at 10:56, David Mandelberg wrote: > Could you elaborate on your enumeration and DDoS concerns? Crypto = more overhead. Less priority to crypto plus DDoS = routing update issues. One can infer peering relationships in a way not possible before. What about bogus signatures? ----------------------------------- Roland Dobbins From pavel.odintsov at gmail.com Fri Jun 5 11:09:01 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Fri, 5 Jun 2015 14:09:01 +0300 Subject: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation In-Reply-To: References: Message-ID: Hello, folks! Due to huge interest about VM's I have prepared VyOS based ISO image with FastNetMon: https://github.com/FastVPSEestiOu/fastnetmon/blob/master/docs/VYOS_BINARY_ISO_IMAGE.md You could run it with any virtual machine and just aim your sflow/netflow targets to it! :) On Thu, Jun 4, 2015 at 9:26 PM, Rafael Possamai wrote: > You could look into LXD for that type of deployment. > > On Thu, Jun 4, 2015 at 12:55 PM, Pavel Odintsov > wrote: >> >> Brilliant idea! But in Docker we could offer only sflow and sflow. Port >> mirror capture need support from the kernel side. Will try shortly! >> >> On Thursday, June 4, 2015, Roberto Bert? wrote: >> >> > What about we build a Docker? >> > >> > 2015-06-04 14:47 GMT-03:00 Alexander Maassen > > >: >> > >> > > It's a security tool. So ppl using it want to publicly hide the fact >> > > they >> > > use it in case you screw up and it contains leaks ;) >> > > >> > > -------- Oorspronkelijk bericht -------- >> > > Van: Pavel Odintsov > >> > > Datum: >> > > Aan: Jim Popovitch > >> > > Cc: nanog at nanog.org >> > > Onderwerp: Re: FastNetMon 1.1.2 - open source solution for DoS/DDoS >> > > mitigation >> > > >> > > Looks like many folks want hide company emails ;) I'm good guy and >> > > will >> > not >> > > spam or offer slmething ;))) >> > > >> > > But I'm impressed about amount of off list requests. Really huge >> > > interest >> > > in tool. >> > > >> > > On Thursday, June 4, 2015, Jim Popovitch > > > wrote: >> > > >> > > > There's a surprising amount of GMail (yes, including me) and >> > > > new-ness >> > > > in this thread. Should I be impressed with the freshness or >> > > > concerned about astroturfing? :-) >> > > > >> > > > Bah Humbug! >> > > > >> > > > -Jim P. >> > > > >> > > >> > > >> > > -- >> > > Sincerely yours, Pavel Odintsov >> > > >> > >> >> >> -- >> Sincerely yours, Pavel Odintsov > > -- Sincerely yours, Pavel Odintsov From owen at delong.com Fri Jun 5 11:09:15 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 5 Jun 2015 12:09:15 +0100 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <556DC705.2090406@matthew.at> <1AC48D74-6ACE-494C-B618-52BA1D34D7D0@delong.com> Message-ID: > On Jun 4, 2015, at 6:10 PM, Christopher Morrow wrote: > > On Thu, Jun 4, 2015 at 5:16 AM, Owen DeLong wrote: >> >>> On Jun 3, 2015, at 9:24 PM, Christopher Morrow wrote: >> >>> let's skip all NAT discussions on this topic from here on out, yes? >> >> Only if you can promise me 100% that the NAT in question will not break anything. > > :) people don't seem to be bothered today. People seem to tolerate it today. It is not clear to what extent they are not bothered vs. to what extent they suffer in silence because they do not know of any viable alternative. Owen From owen at delong.com Fri Jun 5 11:11:28 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 5 Jun 2015 12:11:28 +0100 Subject: AWS Elastic IP architecture In-Reply-To: References: <8133E50C-664E-48FE-ACE8-EEFDF6AF3B11@delong.com> <20150601223603.GY724@hezmatt.org> <20150602005115.884BF2FC9EA2@rock.dv.isc.org> <20150602013248.9DED42FCA443@rock.dv.isc.org> <556D35DF.8080901@matthew.at> <556DC705.2090406@matthew.at> <4316CE97-FC2E-4FDF-BB0D-B20E756AE64D@delong.com> <556F2382.8010409@matthew.at> <233AFE07-72FB-4BF8-A8E9-BA9BCB540! 72C@delong.com> Message-ID: <8AAE7E3D-3569-4DF0-AF44-32EECBDD70F0@delong.com> > On Jun 4, 2015, at 6:16 PM, Christopher Morrow wrote: > > On Thu, Jun 4, 2015 at 5:11 AM, Owen DeLong wrote: >> I?d argue that SSH is several thousand, not a few hundred. In any case, I suppose you can make the argument that only a few people are trying to access their home network resources remotely other than via some sort of proxy/rendezvous service. However, I would argue that such services exist solely to provide a workaround for the deficiencies in the network introduced by NAT. Get rid of the stupid NAT and you no longer need such services. > > This is an interesting argument/point, but if you remove the rendevous > service then how do you find the thing in your house? now the user has > to manage DNS, or the service in question has to manage a dns entry > for the customer, right? DNS is pretty easy. There are dozen?s of free web-UI based DNS services out there. Some of them even run by registrars. > you'll be moving the (some of the) pain from 'nat' to 'dns' (or more > generally naming and identification). I think though that in a better > world, a service related to the thing you want to prod from outside > would manage this stuff for you. I?m unconvinced. Perhaps I prefer to create an entry once vs. pay for some other service to do this and charge me on a monthly basis for a one-time action. > It's important (I think) to not simplify the discussion as: "Oh, with > ipv6 magic happens!" because there are still problems and design > things to overcome even with unhindered end-to-end connectivity. I made no attempt to declare that there was any magic with IPv6. Indeed, my claim is that less magic is required. Owen From swmike at swm.pp.se Fri Jun 5 15:53:58 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 5 Jun 2015 17:53:58 +0200 (CEST) Subject: 100G DWDM FEC standard Message-ID: Hi, I just watched the "evolution of ethernet speeds" presentation from NANOG meeting. There was a statement that there was "vendor secret sauce" in the 100G DWDM space. Yes, that is true, but: http://www.stupi.se/Standards/100G-long-haul4.pdf There actually is a standard for 100G DWDM that has support from multiple router vendors. When you buy new gear, make sure your vendors support the above standard, so we can connect our routers over longer distances between vendors, without needing transponders. We in the Deutsche Telecom Terastream project have Huawei, Cisco, Juniper and ALU routers that natively (DWDM colored interfaces in the routers) talk directly to each other over 1500 km amplified DWDM system (no transponders), and we can also talk from these routers interfaces to Cisco and ALU transponders if we want to. https://jeffloughridge.wordpress.com/2013/10/16/peter-lothbergs-terastream-presentation-at-ripe-67/ if you want to know more about the project. Next time you purchase 100G DWDM equipment, make sure you buy equipment that follows this standard to be certain that it interoperates to combat vendor "secret sauce". -- Mikael Abrahamsson email: swmike at swm.pp.se From betty at nanog.org Fri Jun 5 16:07:57 2015 From: betty at nanog.org (Betty Burke ) Date: Fri, 5 Jun 2015 12:07:57 -0400 Subject: NANOG 64 recordings In-Reply-To: References: <556FC313.6020407@sadiqs.com> <17711091.185.1433436420032.JavaMail.root@benjamin.baylink.com> Message-ID: Working to find out and track down missing video. We will keep you posted. All best. Betty On Thu, Jun 4, 2015 at 7:31 PM, Pete Baldridge wrote: > On June 4, 2015 10:11:02 AM PDT, Victor Zakharyev < > victor.zakharyev at gmail.com> wrote: > >Does anyone have videos from Google presentations on Telemetry? > > > >Thanks! > > > >Victor > > > >??, 4 ???? 2015 ?. ? 9:51, Jay Ashworth : > > > >> ----- Original Message ----- > >> > From: "Sadiq Saif" > >> > >> > For those that missed them: > >> > > >https://www.youtube.com/playlist?list=PLO8DR5ZGla8ju3ftZv_S6L12jBkZKEJVZ > >> > >> Oh, outstanding. Thanks. > >> > >> 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 > >> > > Can anyone comment on what was in the video that's been removed? Is there > somewhere else that it can be found? > -- > Pete > Sent from mobile. > From cscora at apnic.net Fri Jun 5 18:12:03 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Jun 2015 04:12:03 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201506051812.t55IC3B5032217@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 06 Jun, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 547692 Prefixes after maximum aggregation (per Origin AS): 207937 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 266421 Total ASes present in the Internet Routing Table: 50534 Prefixes per ASN: 10.84 Origin-only ASes present in the Internet Routing Table: 36693 Origin ASes announcing only one prefix: 16281 Transit ASes present in the Internet Routing Table: 6318 Transit-only ASes present in the Internet Routing Table: 164 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 41 Max AS path prepend of ASN ( 12486) 32 Prefixes from unregistered ASNs in the Routing Table: 1186 Unregistered ASNs in the Routing Table: 419 Number of 32-bit ASNs allocated by the RIRs: 9729 Number of 32-bit ASNs visible in the Routing Table: 7523 Prefixes from 32-bit ASNs in the Routing Table: 27427 Number of bogon 32-bit ASNs visible in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 384 Number of addresses announced to Internet: 2770664672 Equivalent to 165 /8s, 36 /16s and 252 /24s Percentage of available address space announced: 74.8 Percentage of allocated address space announced: 74.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.4 Total number of prefixes smaller than registry allocations: 183256 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 135256 Total APNIC prefixes after maximum aggregation: 39207 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 141679 Unique aggregates announced from the APNIC address blocks: 56816 APNIC Region origin ASes present in the Internet Routing Table: 5059 APNIC Prefixes per ASN: 28.01 APNIC Region origin ASes announcing only one prefix: 1201 APNIC Region transit ASes present in the Internet Routing Table: 876 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1478 Number of APNIC addresses announced to Internet: 749103296 Equivalent to 44 /8s, 166 /16s and 104 /24s Percentage of available APNIC address space announced: 87.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 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: 179934 Total ARIN prefixes after maximum aggregation: 88238 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 182237 Unique aggregates announced from the ARIN address blocks: 85060 ARIN Region origin ASes present in the Internet Routing Table: 16629 ARIN Prefixes per ASN: 10.96 ARIN Region origin ASes announcing only one prefix: 6123 ARIN Region transit ASes present in the Internet Routing Table: 1740 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 469 Number of ARIN addresses announced to Internet: 1092423456 Equivalent to 65 /8s, 29 /16s and 15 /24s Percentage of available ARIN address space announced: 57.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 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: 132826 Total RIPE prefixes after maximum aggregation: 66036 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 139044 Unique aggregates announced from the RIPE address blocks: 86274 RIPE Region origin ASes present in the Internet Routing Table: 17953 RIPE Prefixes per ASN: 7.74 RIPE Region origin ASes announcing only one prefix: 8136 RIPE Region transit ASes present in the Internet Routing Table: 2967 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3754 Number of RIPE addresses announced to Internet: 694885632 Equivalent to 41 /8s, 107 /16s and 29 /24s Percentage of available RIPE address space announced: 101.0 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: 60073 Total LACNIC prefixes after maximum aggregation: 11368 LACNIC Deaggregation factor: 5.28 Prefixes being announced from the LACNIC address blocks: 70461 Unique aggregates announced from the LACNIC address blocks: 32746 LACNIC Region origin ASes present in the Internet Routing Table: 2448 LACNIC Prefixes per ASN: 28.78 LACNIC Region origin ASes announcing only one prefix: 625 LACNIC Region transit ASes present in the Internet Routing Table: 498 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1706 Number of LACNIC addresses announced to Internet: 168343040 Equivalent to 10 /8s, 8 /16s and 182 /24s Percentage of available LACNIC address space announced: 100.3 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: 11950 Total AfriNIC prefixes after maximum aggregation: 3046 AfriNIC Deaggregation factor: 3.92 Prefixes being announced from the AfriNIC address blocks: 13887 Unique aggregates announced from the AfriNIC address blocks: 5185 AfriNIC Region origin ASes present in the Internet Routing Table: 729 AfriNIC Prefixes per ASN: 19.05 AfriNIC Region origin ASes announcing only one prefix: 196 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: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 116 Number of AfriNIC addresses announced to Internet: 65576704 Equivalent to 3 /8s, 232 /16s and 159 /24s Percentage of available AfriNIC address space announced: 65.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 2923 11557 914 Korea Telecom 17974 2688 904 81 PT Telekomunikasi Indonesia 7545 2610 336 130 TPG Telecom Limited 4755 2025 423 219 TATA Communications formerly 4538 1935 4190 72 China Education and Research 9829 1690 1341 90 National Internet Backbone 9808 1584 8717 28 Guangdong Mobile Communicatio 9583 1485 120 584 Sify Limited 4808 1447 2237 466 CNCGROUP IP network China169 9498 1336 335 102 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 3091 2958 141 Cox Communications Inc. 6389 2796 3688 51 BellSouth.net Inc. 3356 2566 10687 496 Level 3 Communications, Inc. 18566 2047 379 189 MegaPath Corporation 20115 1883 1849 425 Charter Communications 6983 1748 850 244 EarthLink, Inc. 4323 1604 1022 409 tw telecom holdings, inc. 30036 1549 314 471 Mediacom Communications Corp 701 1392 11354 680 MCI Communications Services, 22561 1365 414 250 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 2056 305 358 TELLCOM ILETISIM HIZMETLERI A 20940 1930 757 1403 Akamai International B.V. 6849 1213 356 24 JSC "Ukrtelecom" 31148 1049 45 23 Freenet Ltd. 8402 1046 544 15 OJSC "Vimpelcom" 13188 1040 97 70 TOV "Bank-Inform" 12479 946 868 72 France Telecom Espana SA 6830 906 2693 466 Liberty Global Operations B.V 8551 872 376 52 Bezeq International-Ltd 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 3247 532 204 Telmex Colombia S.A. 28573 2230 2167 114 NET Servi?os de Comunica??o S 8151 1693 3257 469 Uninet S.A. de C.V. 7303 1667 1047 237 Telecom Argentina S.A. 6147 1617 374 23 Telefonica del Peru S.A.A. 6503 1246 421 55 Axtel, S.A.B. de C.V. 26615 1072 2325 35 Tim Celular S.A. 7738 999 1882 41 Telemar Norte Leste S.A. 3816 931 424 159 COLOMBIA TELECOMUNICACIONES S 18881 869 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 24863 890 280 37 Link Egypt (Link.NET) 8452 797 958 13 TE-AS 36903 514 259 98 Office National des Postes et 36992 423 1229 32 ETISALAT MISR 37492 312 175 71 Orange Tunisie 24835 304 146 13 Vodafone Data 3741 250 857 208 Internet Solutions 29571 241 21 12 Cote d'Ivoire Telecom 37054 199 19 6 Data Telecom Service 36947 191 807 13 Telecom Algeria Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3247 532 204 Telmex Colombia S.A. 22773 3091 2958 141 Cox Communications Inc. 4766 2923 11557 914 Korea Telecom 6389 2796 3688 51 BellSouth.net Inc. 17974 2688 904 81 PT Telekomunikasi Indonesia 7545 2610 336 130 TPG Telecom Limited 3356 2566 10687 496 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2230 2167 114 NET Servi?os de Comunica??o S 34984 2056 305 358 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3091 2950 Cox Communications Inc. 6389 2796 2745 BellSouth.net Inc. 17974 2688 2607 PT Telekomunikasi Indonesia 7545 2610 2480 TPG Telecom Limited 39891 2472 2466 SaudiNet, Saudi Telecom Compa 28573 2230 2116 NET Servi?os de Comunica??o S 3356 2566 2070 Level 3 Communications, Inc. 4766 2923 2009 Korea Telecom 4538 1935 1863 China Education and Research 18566 2047 1858 MegaPath Corporation 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.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.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:17 /9:13 /10:34 /11:95 /12:264 /13:506 /14:1003 /15:1720 /16:12929 /17:7279 /18:12362 /19:25545 /20:36069 /21:38847 /22:59848 /23:51938 /24:296210 /25:1103 /26:1142 /27:722 /28:14 /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 2289 3091 Cox Communications Inc. 18566 1999 2047 MegaPath Corporation 6389 1639 2796 BellSouth.net Inc. 6983 1396 1748 EarthLink, Inc. 30036 1382 1549 Mediacom Communications Corp 34984 1322 2056 TELLCOM ILETISIM HIZMETLERI A 6147 1169 1617 Telefonica del Peru S.A.A. 10620 1136 3247 Telmex Colombia S.A. 11492 1124 1208 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1483 2:680 4:93 5:1838 6:25 8:1415 11:1 12:1828 13:14 14:1365 15:17 16:2 17:43 18:22 20:48 23:1224 24:1698 27:1910 31:1603 32:38 33:2 34:4 35:3 36:113 37:1932 38:1037 39:5 40:253 41:2649 42:282 43:1300 44:25 45:686 46:2216 47:42 49:898 50:812 52:12 54:77 55:8 56:6 57:41 58:1297 59:715 60:479 61:1750 62:1338 63:1920 64:4413 65:2272 66:4076 67:2078 68:1062 69:3276 70:990 71:449 72:1986 74:2654 75:336 76:423 77:1338 78:1196 79:794 80:1338 81:1308 82:817 83:699 84:718 85:1416 86:394 87:1040 88:524 89:1848 90:152 91:5986 92:856 93:2223 94:2060 95:2177 96:431 97:354 98:1056 99:49 100:70 101:833 103:7520 104:1783 105:62 106:226 107:987 108:629 109:2060 110:1107 111:1494 112:811 113:1080 114:822 115:1280 116:1382 117:1063 118:1811 119:1427 120:449 121:1086 122:2145 123:1835 124:1513 125:1596 128:648 129:386 130:402 131:1202 132:484 133:175 134:407 135:95 136:330 137:314 138:794 139:154 140:232 141:448 142:661 143:511 144:572 145:116 146:732 147:600 148:1215 149:409 150:564 151:608 152:484 153:243 154:625 155:864 156:409 157:468 158:336 159:1010 160:387 161:660 162:1954 163:426 164:666 165:693 166:310 167:831 168:1306 169:172 170:1473 171:246 172:72 173:1543 174:716 175:709 176:1309 177:3676 178:2150 179:932 180:1942 181:1793 182:1795 183:628 184:756 185:3620 186:2653 187:1753 188:2055 189:1566 190:7709 191:1047 192:8401 193:5601 194:4154 195:3680 196:1980 197:947 198:5538 199:5510 200:6670 201:3147 202:9465 203:9143 204:4684 205:2813 206:3081 207:2946 208:3966 209:3973 210:3532 211:1860 212:2555 213:2334 214:863 215:73 216:5709 217:1829 218:712 219:460 220:1452 221:784 222:476 223:717 End of report From blake at ispn.net Fri Jun 5 18:47:47 2015 From: blake at ispn.net (Blake Hudson) Date: Fri, 05 Jun 2015 13:47:47 -0500 Subject: stacking pdu In-Reply-To: <86k2vj16r3.fsf@valhalla.seastrom.com> References: <86k2vj16r3.fsf@valhalla.seastrom.com> Message-ID: <5571EED3.9080404@ispn.net> Rob Seastrom wrote on 6/4/2015 4:52 PM: > William Herrin writes: > >> Isn't it against the NEC and the fire code to stack power strips? We >> all do it, but isn't it against code? > ... > > As always, when someone asserts that "X is against code" whether in > the form of a statement or a question, the proper response is > "Citation, please!" > > -r > The fire marshal that regularly inspects our building will cite us if he sees an extension cord in use - even temporarily - or sees a temporary power tap/surge suppressor connected to another. Meanwhile, in another city, I see government and commercial buildings violating these rules for years. Perhaps there's some amount of interpretation allowed or some inspectors are more aggressive than others. --Blake From bill at herrin.us Fri Jun 5 19:44:29 2015 From: bill at herrin.us (William Herrin) Date: Fri, 5 Jun 2015 15:44:29 -0400 Subject: stacking pdu In-Reply-To: <5571EED3.9080404@ispn.net> References: <86k2vj16r3.fsf@valhalla.seastrom.com> <5571EED3.9080404@ispn.net> Message-ID: On Fri, Jun 5, 2015 at 2:47 PM, Blake Hudson wrote: >> William Herrin writes: >>> Isn't it against the NEC and the fire code to stack power strips? We >>> all do it, but isn't it against code? > > The fire marshal that regularly inspects our building will cite us if he > sees an extension cord in use - even temporarily - or sees a temporary power > tap/surge suppressor connected to another. I was dinged for power strips connected to a cube tap. I don't have the citation handy, but I looked it up at the time and it was definitely against code. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From list at satchell.net Fri Jun 5 20:01:22 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 05 Jun 2015 13:01:22 -0700 Subject: stacking pdu In-Reply-To: <5571EED3.9080404@ispn.net> References: <86k2vj16r3.fsf@valhalla.seastrom.com> <5571EED3.9080404@ispn.net> Message-ID: <55720012.8020000@satchell.net> On 06/05/2015 11:47 AM, Blake Hudson wrote: > The fire marshal that regularly inspects our building will cite us if he > sees an extension cord in use - even temporarily - or sees a temporary > power tap/surge suppressor connected to another. Meanwhile, in another > city, I see government and commercial buildings violating these rules > for years. Perhaps there's some amount of interpretation allowed or some > inspectors are more aggressive than others. Or the local ordinances block daisy-chaining. I've run into this in several parts of the country, while other parts don't have local regulations -- particularly in "commercial" spaces, which include offices. From sean at donelan.com Fri Jun 5 21:19:47 2015 From: sean at donelan.com (Sean Donelan) Date: Fri, 5 Jun 2015 17:19:47 -0400 (EDT) Subject: stacking pdu In-Reply-To: <5571EED3.9080404@ispn.net> References: <86k2vj16r3.fsf@valhalla.seastrom.com> <5571EED3.9080404@ispn.net> Message-ID: On Fri, 5 Jun 2015, Blake Hudson wrote: > The fire marshal that regularly inspects our building will cite us if he sees > an extension cord in use - even temporarily - or sees a temporary power > tap/surge suppressor connected to another. Meanwhile, in another city, I see > government and commercial buildings violating these rules for years. Perhaps > there's some amount of interpretation allowed or some inspectors are more > aggressive than others. Every Authority Having Jurisdiction (AHJ) is their own fiefdom. Although there are a few model national codes, its the locally enacted law and AHJ interpretation that rules. And, yes, the effectiveness and knowledge of AHJs varies greatly. It wouldn't surprise me if there were some places with no building codes or inspectors. From brian at bloveland.com Fri Jun 5 21:20:40 2015 From: brian at bloveland.com (Brian Loveland) Date: Fri, 5 Jun 2015 17:20:40 -0400 Subject: stacking pdu In-Reply-To: References: <86k2vj16r3.fsf@valhalla.seastrom.com> Message-ID: APC does make some 'half rack' PDU's that take a C20 inlet so they could hang off a C19 outlet on another PDU: http://www.apc.com/resource/include/techspec_index.cfm?base_sku=AP8858&displayList=ALL&page_type=displaybasic&printer_friendly=yes http://www.apc.com/resource/include/techspec_index.cfm?base_sku=AP7821&displayList=ALL&page_type=displaybasic&printer_friendly=yes On the software side, just use a "master" PDU with metering. These "sub" ones are also metered but you would want to look at the total utilization on the "master". No comment if its to code... On Fri, Jun 5, 2015 at 12:51 AM, shawn wilson wrote: > Well, I was kinda thinking this would turn out to be a dumb question / have > an obvious answer. Apparently not. But it seems I can't go buy a solution > either. I guess there isn't much of a market (though I am just talking > software - maybe someone could make an update :) ). > From eric-list at truenet.com Fri Jun 5 21:31:15 2015 From: eric-list at truenet.com (Eric Tykwinski) Date: Fri, 5 Jun 2015 17:31:15 -0400 Subject: stacking pdu In-Reply-To: References: <86k2vj16r3.fsf@valhalla.seastrom.com> Message-ID: <6AC259AC-0AAE-42C6-84E5-864CA9F81A2B@truenet.com> I was pretty much thinking the same, get a switched/metered outlet PDU. APC, ServerTech, et al have them, then daisy chain something like a Dell AP6015 off the outlet. No clue about NEC/local laws, but the Dells are pretty much setup for that type of setup. > On Jun 5, 2015, at 5:20 PM, Brian Loveland wrote: > > APC does make some 'half rack' PDU's that take a C20 inlet so they could > hang off a C19 outlet on another PDU: > http://www.apc.com/resource/include/techspec_index.cfm?base_sku=AP8858&displayList=ALL&page_type=displaybasic&printer_friendly=yes > http://www.apc.com/resource/include/techspec_index.cfm?base_sku=AP7821&displayList=ALL&page_type=displaybasic&printer_friendly=yes > > On the software side, just use a "master" PDU with metering. These "sub" > ones are also metered but you would want to look at the total utilization > on the "master". > > No comment if its to code... > > On Fri, Jun 5, 2015 at 12:51 AM, shawn wilson wrote: > >> Well, I was kinda thinking this would turn out to be a dumb question / have >> an obvious answer. Apparently not. But it seems I can't go buy a solution >> either. I guess there isn't much of a market (though I am just talking >> software - maybe someone could make an update :) ). >> From cidr-report at potaroo.net Fri Jun 5 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Jun 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201506052200.t55M006x079044@wattle.apnic.net> This report has been generated at Fri Jun 5 21:14:36 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 29-05-15 554940 306130 30-05-15 555224 305988 31-05-15 555285 303956 01-06-15 555184 304348 02-06-15 555140 304122 03-06-15 555349 304869 04-06-15 555053 304962 05-06-15 555774 304969 AS Summary 50788 Number of ASes in routing system 20205 Number of ASes announcing only one prefix 3247 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120824832 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'). --- 05Jun15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 556726 305104 251622 45.2% All ASes AS22773 3094 172 2922 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2795 99 2696 96.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS9394 2923 316 2607 89.2% CTTNET China TieTong Telecommunications Corporation,CN AS17974 2688 81 2607 97.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 34 2439 98.6% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2256 288 1968 87.2% NET Servi?os de Comunica??o S.A.,BR AS3356 2571 776 1795 69.8% LEVEL3 - Level 3 Communications, Inc.,US AS4755 2021 260 1761 87.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4766 2923 1303 1620 55.4% KIXS-AS-KR Korea Telecom,KR AS9808 1584 67 1517 95.8% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6983 1747 247 1500 85.9% ITCDELTA - Earthlink, Inc.,US AS10620 3247 1828 1419 43.7% Telmex Colombia S.A.,CO AS20115 1883 489 1394 74.0% CHARTER-NET-HKY-NC - Charter Communications,US AS7303 1666 287 1379 82.8% Telecom Argentina S.A.,AR AS6147 1617 281 1336 82.6% Telefonica del Peru S.A.A.,PE AS9498 1336 117 1219 91.2% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1614 411 1203 74.5% TWTC - tw telecom holdings, inc.,US AS18566 2047 895 1152 56.3% MEGAPATH5-US - MegaPath Corporation,US AS7545 2646 1498 1148 43.4% TPG-INTERNET-AP TPG Telecom Limited,AU AS22561 1365 260 1105 81.0% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS7552 1155 59 1096 94.9% VIETEL-AS-AP Viettel Corporation,VN AS8402 1033 26 1007 97.5% CORBINA-AS OJSC "Vimpelcom",RU AS6849 1210 221 989 81.7% UKRTELNET JSC UKRTELECOM,UA AS8151 1696 733 963 56.8% Uninet S.A. de C.V.,MX AS4538 1953 1037 916 46.9% ERX-CERNET-BKB China Education and Research Network Center,CN AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS26615 1072 173 899 83.9% Tim Celular S.A.,BR AS38285 979 126 853 87.1% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS18881 869 33 836 96.2% Global Village Telecom,BR AS4780 1112 299 813 73.1% SEEDNET Digital United Inc.,TW Total 56574 12499 44075 77.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 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 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.67.78.0/24 AS38040 GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited,TH 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,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 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.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.218.36.0/22 AS19714 -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.66.0.0/24 AS5617 TPNET Orange Polska Spolka Akcyjna,PL 100.66.1.0/24 AS5617 TPNET Orange Polska Spolka Akcyjna,PL 102.69.1.0/24 AS59749 CLEANMAT CLEANMAT EOOD,BG 103.7.56.0/22 AS13144 POP-IDC-TH POPIDC powered by CSLoxinfo,TH 103.7.56.0/23 AS13144 POP-IDC-TH POPIDC powered by CSLoxinfo,TH 103.7.58.0/24 AS13144 POP-IDC-TH POPIDC powered by CSLoxinfo,TH 103.7.59.0/24 AS13144 POP-IDC-TH POPIDC powered by CSLoxinfo,TH 103.10.222.0/24 AS13189 103.11.16.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.44.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.45.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.47.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.19.219.0/24 AS58887 103.20.100.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.101.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.227.4.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.227.184.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.228.8.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.228.84.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.228.136.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.228.224.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.230.116.0/22 AS59351 103.232.104.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.232.248.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,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.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 150.107.28.0/24 AS13144 POP-IDC-TH POPIDC powered by CSLoxinfo,TH 150.107.29.0/24 AS13144 POP-IDC-TH POPIDC powered by CSLoxinfo,TH 150.107.30.0/24 AS13144 POP-IDC-TH POPIDC powered by CSLoxinfo,TH 150.107.31.0/24 AS13144 POP-IDC-TH POPIDC powered by CSLoxinfo,TH 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 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 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.93.64.0/20 AS46708 ALLIEDINTVA - Allied International Corp of VA.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 180.222.120.0/21 AS23818 JETINTERNET JETINTERNET Corporation,JP 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.40.183.0/24 AS62300 -Reserved AS-,ZZ 188.190.96.0/19 AS19714 -Reserved AS-,ZZ 188.190.103.0/24 AS19714 -Reserved AS-,ZZ 188.190.112.0/24 AS19714 -Reserved AS-,ZZ 188.190.113.0/24 AS19714 -Reserved AS-,ZZ 188.190.114.0/24 AS19714 -Reserved AS-,ZZ 188.190.117.0/24 AS19714 -Reserved AS-,ZZ 188.190.118.0/24 AS19714 -Reserved AS-,ZZ 188.190.119.0/24 AS19714 -Reserved AS-,ZZ 188.190.120.0/24 AS19714 -Reserved AS-,ZZ 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.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 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.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 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 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,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.8.0/21 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.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.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 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -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.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.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.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.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems 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.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 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.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.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems 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 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 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 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.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.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 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 CENTURYLINK-US-LEGACY-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 CENTURYLINK-US-LEGACY-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.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 Jun 5 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Jun 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201506052200.t55M01r5079051@wattle.apnic.net> BGP Update Report Interval: 28-May-15 -to- 04-Jun-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 303258 5.1% 1849.1 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 211796 3.6% 124.2 -- BSNL-NIB National Internet Backbone,IN 3 - AS22059 118918 2.0% 16988.3 -- APVIO-1 - Apvio, Inc.,US 4 - AS45899 92287 1.6% 141.8 -- VNPT-AS-VN VNPT Corp,VN 5 - AS36947 86629 1.5% 444.3 -- ALGTEL-AS,DZ 6 - AS6057 84636 1.4% 148.7 -- Administracion Nacional de Telecomunicaciones,UY 7 - AS54169 76305 1.3% 25435.0 -- MGH-ION-1 - Marin General Hospital,US 8 - AS7552 68403 1.1% 52.4 -- VIETEL-AS-AP Viettel Corporation,VN 9 - AS3709 63454 1.1% 2350.1 -- NET-CITY-SA - City of San Antonio,US 10 - AS45609 62338 1.1% 98.9 -- BHARTI-MOBILITY-AS-AP Bharti Airtel Ltd. AS for GPRS Service,IN 11 - AS17451 46776 0.8% 113.5 -- BIZNET-AS-AP BIZNET NETWORKS,ID 12 - AS39891 45386 0.8% 18.4 -- ALJAWWALSTC-AS Saudi Telecom Company JSC,SA 13 - AS22368 42626 0.7% 246.4 -- TELEBUCARAMANGA S.A. E.S.P.,CO 14 - AS3816 31516 0.5% 33.0 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 15 - AS8402 31238 0.5% 25.4 -- CORBINA-AS OJSC "Vimpelcom",RU 16 - AS18051 30007 0.5% 535.8 -- JARDIKNAS-AS-AP Pustekkom,ID 17 - AS132220 27786 0.5% 524.3 -- JPRDIGITAL-IN JPR Digital Pvt. Ltd.,IN 18 - AS7643 27258 0.5% 86.5 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT),VN 19 - AS33659 27102 0.5% 934.6 -- CMCS - Comcast Cable Communications, Inc.,US 20 - AS24560 26680 0.5% 21.5 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS54169 76305 1.3% 25435.0 -- MGH-ION-1 - Marin General Hospital,US 2 - AS22059 118918 2.0% 16988.3 -- APVIO-1 - Apvio, Inc.,US 3 - AS33287 22472 0.4% 11236.0 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US 4 - AS393588 9572 0.2% 9572.0 -- MUBEA-FLO - Mubea,US 5 - AS61039 9307 0.2% 9307.0 -- ZMZ OAO ZMZ,RU 6 - AS37515 14872 0.2% 7436.0 -- iCONNECT,ZA 7 - AS55350 26186 0.4% 6546.5 -- VSCGT-HK Virtual Switching Consultancy Limited (C/O VXRoutes Ltd),HK 8 - AS19502 5435 0.1% 5435.0 -- CRANEWAREINSIGHT-AS - Craneware Insight, Inc.,US 9 - AS32005 14462 0.2% 3615.5 -- THE-CHURCH-PENSION-GROUP - CHURCH PENSION GROUP SERVICES CORPORATION,US 10 - AS263730 2432 0.0% 2432.0 -- TELECABLE SABANETA SRL,DO 11 - AS33440 9569 0.2% 2392.2 -- WEBRULON-NETWORK - webRulon, LLC,US 12 - AS3709 63454 1.1% 2350.1 -- NET-CITY-SA - City of San Antonio,US 13 - AS31357 12274 0.2% 2045.7 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 14 - AS23752 303258 5.1% 1849.1 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 15 - AS21073 1712 0.0% 1712.0 -- ZORANET-AS Zoranet Internetdiensten,NL 16 - AS1466 6747 0.1% 1686.8 -- DNIC-AS-01466 - Headquarters, USAISC,US 17 - AS15835 11343 0.2% 1620.4 -- MAP Moscow Network Access Point,RU 18 - AS38000 6408 0.1% 1602.0 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN 19 - AS47680 7834 0.1% 1566.8 -- NHCS EOBO Limited,IE 20 - AS197914 4421 0.1% 1473.7 -- STOCKHO-AS Stockho Hosting SARL,FR TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 150875 2.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 149557 2.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 105.96.0.0/22 84979 1.4% AS36947 -- ALGTEL-AS,DZ 4 - 204.80.242.0/24 76299 1.2% AS54169 -- MGH-ION-1 - Marin General Hospital,US 5 - 64.34.125.0/24 59532 1.0% AS22059 -- APVIO-1 - Apvio, Inc.,US 6 - 76.191.107.0/24 59381 1.0% AS22059 -- APVIO-1 - Apvio, Inc.,US 7 - 199.204.107.0/24 49538 0.8% AS13338 -- HAYGROUP-ASN - HAY GROUP INC,US AS33287 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US AS33659 -- CMCS - Comcast Cable Communications, Inc.,US 8 - 103.4.244.0/22 13178 0.2% AS55350 -- VSCGT-HK Virtual Switching Consultancy Limited (C/O VXRoutes Ltd),HK 9 - 175.100.164.0/22 12969 0.2% AS55350 -- VSCGT-HK Virtual Switching Consultancy Limited (C/O VXRoutes Ltd),HK 10 - 78.140.0.0/18 12266 0.2% AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 11 - 193.232.94.0/24 11330 0.2% AS15835 -- MAP Moscow Network Access Point,RU 12 - 192.58.137.0/24 9572 0.2% AS393588 -- MUBEA-FLO - Mubea,US 13 - 91.235.169.0/24 9307 0.1% AS61039 -- ZMZ OAO ZMZ,RU 14 - 41.77.96.0/21 8876 0.1% AS37515 -- iCONNECT,ZA 15 - 192.58.232.0/24 8407 0.1% AS6629 -- NOAA-AS - NOAA,US 16 - 88.87.160.0/19 7830 0.1% AS47680 -- NHCS EOBO Limited,IE 17 - 94.73.56.0/21 7032 0.1% AS42081 -- SPEEDY-NET-AS Speedy net EAD,BG 18 - 155.29.111.0/24 6744 0.1% AS1466 -- DNIC-AS-01466 - Headquarters, USAISC,US 19 - 203.175.5.0/24 6359 0.1% AS38000 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN 20 - 66.19.194.0/24 6212 0.1% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc.,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 john at op-sec.us Fri Jun 5 23:13:55 2015 From: john at op-sec.us (John Fraizer) Date: Fri, 5 Jun 2015 16:13:55 -0700 Subject: eBay is looking for network heavies... Message-ID: Hello All, eBay is looking for folks to join our Site Network Engineering team. eBay Site Network Engineering is responsible for the eBay SITE network from ToR to Peering Edge. You won't be bored. You will be challenged. You will have fun! This position is located in San Jose, California @ eBay HQ although exception may be made for extremely well qualified candidates. *Qualifications:* - 7+ years of experience in network design and implementation - 7+ years working at the highest level of technical escalation - Expert level multi-vendor experience in routing & switching with Arista, Cisco, Juniper, Nexus platforms - Expert level understanding of IPv4 & IPv6. Bonus points if you can tell me about IPv8. (The old guard will get that joke.) - Expert level BGP and OSPF - Understanding of multicast technologies such as PIM-SM and PIM-BiDir - Understanding of QoS and implementation strategies - Experience with L2 technologies such as MLAG and VPC - Experience with cloud architectures and network automation - Experience with SDN technologies such as VXLAN, NVGRE and Open vSwitch - Expert level troubleshooting skills - Functional knowledge of and comfort working in *nix environments - Ability to script in Bash, Perl, or other relevant languages. (Bonus for Python) - Excellent communications and documentation skills Head of line for CCIE / JNCIE but knowledge and experience trumps a piece of paper every time! BSCS or other 4-year degree desired - may be substituted with relevant work experience Translation of the above: Are you considered an expert by your industry peers? We know your family thinks you're a genius. Do your peers in the networking community agree? Do you want work on the bleeding edge of technology, playing with the biggest, baddest and bestest toys? Are you a team player who can also work alone providing creative solutions to complex problems using your "out of the box" thinking? Are you tired of being the "smartest guy in the room" when you're at work? Well then, I've got the job you're looking for! The above qualifications are the "wish list". That should give you a feel of whether or not you're qualified for this position though. You know your own skill set better than anyone else. Just be advised: Please don't be a "buzzword bandit" on your CV. If you list a skill or experience, its fair game to ask you about these - in depth - during your phone screen and any subsequent in-person interviews. Interested and Qualified candidates, please forward your CVs to jfraizer at ebay dot com. eBay, Inc is an Equal Opportunity Employer -- John Fraizer MTS2 - eBay Site Network Engineering From mehmet at akcin.net Fri Jun 5 23:22:40 2015 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 5 Jun 2015 19:22:40 -0400 Subject: eBay is looking for network heavies... In-Reply-To: References: Message-ID: Please use below mailing list for job posting http://mailman.nanog.org/mailman/listinfo/jobs Mehmet > On Jun 5, 2015, at 19:13, John Fraizer wrote: > > Hello All, > > eBay is looking for folks to join our Site Network Engineering team. eBay > Site Network Engineering is responsible for the eBay SITE network from ToR > to Peering Edge. You won't be bored. You will be challenged. You will > have fun! > This position is located in San Jose, California @ eBay HQ although > exception may be made for extremely well qualified candidates. > > > *Qualifications:* > > - 7+ years of experience in network design and implementation > - 7+ years working at the highest level of technical escalation > - Expert level multi-vendor experience in routing & switching with > Arista, Cisco, Juniper, Nexus platforms > - Expert level understanding of IPv4 & IPv6. Bonus points if you can > tell me about IPv8. (The old guard will get that joke.) > - Expert level BGP and OSPF > - Understanding of multicast technologies such as PIM-SM and PIM-BiDir > - Understanding of QoS and implementation strategies > - Experience with L2 technologies such as MLAG and VPC > - Experience with cloud architectures and network automation > - Experience with SDN technologies such as VXLAN, NVGRE and Open vSwitch > - Expert level troubleshooting skills > - Functional knowledge of and comfort working in *nix environments > - Ability to script in Bash, Perl, or other relevant languages. (Bonus > for Python) > - Excellent communications and documentation skills > > Head of line for CCIE / JNCIE but knowledge and experience trumps a piece > of paper every time! > BSCS or other 4-year degree desired - may be substituted with relevant work > experience > > > Translation of the above: Are you considered an expert by your industry > peers? We know your family thinks you're a genius. Do your peers in the > networking community agree? Do you want work on the bleeding edge of > technology, playing with the biggest, baddest and bestest toys? Are you a > team player who can also work alone providing creative solutions to complex > problems using your "out of the box" thinking? Are you tired of being the > "smartest guy in the room" when you're at work? Well then, I've got the > job you're looking for! The above qualifications are the "wish list". > That should give you a feel of whether or not you're qualified for this > position though. You know your own skill set better than anyone else. > > Just be advised: Please don't be a "buzzword bandit" on your CV. If you > list a skill or experience, its fair game to ask you about these - in depth > - during your phone screen and any subsequent in-person interviews. > > Interested and Qualified candidates, please forward your CVs to jfraizer at > ebay dot com. > > eBay, Inc is an Equal Opportunity Employer > > -- > John Fraizer > MTS2 - eBay Site Network Engineering From surfer at mauigateway.com Sat Jun 6 00:20:42 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 5 Jun 2015 17:20:42 -0700 Subject: eBay is looking for network heavies... Message-ID: <20150605172042.5B2FFF54@m0005311.ppops.net> --- john at op-sec.us wrote: From: John Fraizer Bonus points if you can tell me about IPv8. (The old guard will get that joke.) -------------------------------- Long live Jim! Ummmm...Never mind... :-) scott From jared at puck.nether.net Sat Jun 6 00:26:53 2015 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 5 Jun 2015 20:26:53 -0400 Subject: eBay is looking for network heavies... In-Reply-To: References: Message-ID: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> > On Jun 5, 2015, at 7:13 PM, John Fraizer wrote: > > Head of line for CCIE / JNCIE but knowledge and experience trumps a piece > of paper every time! Can you please put these at the back of the line? My experience is that the cisco certification (at least) is evidence of the absence of actual troubleshooting skills. (or my standards of what defines ?expert? are different than the rest of the world). - Jared From jlewis at lewis.org Sat Jun 6 00:30:17 2015 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 5 Jun 2015 20:30:17 -0400 (EDT) Subject: eBay is looking for network heavies... In-Reply-To: <20150605172042.5B2FFF54@m0005311.ppops.net> References: <20150605172042.5B2FFF54@m0005311.ppops.net> Message-ID: On Fri, 5 Jun 2015, Scott Weeks wrote: > > > --- john at op-sec.us wrote: > From: John Fraizer > > Bonus points if you can > tell me about IPv8. (The old guard will get that joke.) > -------------------------------- > > > Long live Jim! Ummmm...Never mind... Who? Get off my stargate. :) :0 * ^From:.*(jfleming at anet\.com|ipv6nog at gmail\.com|*fleming at unety\.net) /dev/null ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From lukasz at bromirski.net Sat Jun 6 00:45:42 2015 From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=) Date: Sat, 6 Jun 2015 02:45:42 +0200 Subject: eBay is looking for network heavies... In-Reply-To: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> Message-ID: <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> > On 06 Jun 2015, at 02:26, Jared Mauch wrote: > > >> On Jun 5, 2015, at 7:13 PM, John Fraizer wrote: >> >> Head of line for CCIE / JNCIE but knowledge and experience trumps a piece >> of paper every time! > > Can you please put these at the back of the line? My experience is that > the cisco certification (at least) is evidence of the absence of actual > troubleshooting skills. (or my standards of what defines ?expert? are > different than the rest of the world). Jared, don?t generalize. True - there are people that are ?paper? CCIE/JNCIEs - but let?s not start a rant unless you've met tens of CCIEs/JNCIEs and all of them didn?t know a jack. About troubleshooting. ? CCIE #15929 R&S/SP, CCDE #2012::17 (not that I?d know anything about troubleshooting of course) From john at op-sec.us Sat Jun 6 00:55:52 2015 From: john at op-sec.us (John Fraizer) Date: Fri, 5 Jun 2015 17:55:52 -0700 Subject: eBay is looking for network heavies... In-Reply-To: <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> Message-ID: Folks, It's just a piece of paper in my opinion. A person either knows their stuff or they don't. Less than 5min on a phone screen and I will know if they "bought" their certification(s) or earned them. Sadly, I've spoken to far too many who give some validation to Jared's comment. I'm wondering how many proctors have been paid off or if people are buying fake id's for smart people and paying them to sit for the tests posing as them. John Fraizer --Sent from my Android phone. Please excuse any typos. On Jun 5, 2015 5:45 PM, "?ukasz Bromirski" wrote: > > > On 06 Jun 2015, at 02:26, Jared Mauch wrote: > > > > > >> On Jun 5, 2015, at 7:13 PM, John Fraizer wrote: > >> > >> Head of line for CCIE / JNCIE but knowledge and experience trumps a > piece > >> of paper every time! > > > > Can you please put these at the back of the line? My experience is that > > the cisco certification (at least) is evidence of the absence of actual > > troubleshooting skills. (or my standards of what defines ?expert? are > > different than the rest of the world). > > Jared, don?t generalize. > > True - there are people that are ?paper? CCIE/JNCIEs - but let?s not > start a rant unless you've met tens of CCIEs/JNCIEs and all of them > didn?t know a jack. About troubleshooting. > > ? > CCIE #15929 R&S/SP, CCDE #2012::17 > (not that I?d know anything about troubleshooting of course) From ryan.landry at gmail.com Sat Jun 6 01:23:36 2015 From: ryan.landry at gmail.com (ryanL) Date: Sat, 06 Jun 2015 01:23:36 +0000 Subject: eBay is looking for network heavies... In-Reply-To: References: Message-ID: we're allowed to recruit on nanog?... On Fri, Jun 5, 2015 at 4:19 PM John Fraizer wrote: > Hello All, > > eBay is looking for folks to join our Site Network Engineering team. eBay > Site Network Engineering is responsible for the eBay SITE network from ToR > to Peering Edge. You won't be bored. You will be challenged. You will > have fun! > This position is located in San Jose, California @ eBay HQ although > exception may be made for extremely well qualified candidates. > > > *Qualifications:* > > - 7+ years of experience in network design and implementation > - 7+ years working at the highest level of technical escalation > - Expert level multi-vendor experience in routing & switching with > Arista, Cisco, Juniper, Nexus platforms > - Expert level understanding of IPv4 & IPv6. Bonus points if you can > tell me about IPv8. (The old guard will get that joke.) > - Expert level BGP and OSPF > - Understanding of multicast technologies such as PIM-SM and PIM-BiDir > - Understanding of QoS and implementation strategies > - Experience with L2 technologies such as MLAG and VPC > - Experience with cloud architectures and network automation > - Experience with SDN technologies such as VXLAN, NVGRE and Open vSwitch > - Expert level troubleshooting skills > - Functional knowledge of and comfort working in *nix environments > - Ability to script in Bash, Perl, or other relevant languages. (Bonus > for Python) > - Excellent communications and documentation skills > > Head of line for CCIE / JNCIE but knowledge and experience trumps a piece > of paper every time! > BSCS or other 4-year degree desired - may be substituted with relevant work > experience > > > Translation of the above: Are you considered an expert by your industry > peers? We know your family thinks you're a genius. Do your peers in the > networking community agree? Do you want work on the bleeding edge of > technology, playing with the biggest, baddest and bestest toys? Are you a > team player who can also work alone providing creative solutions to complex > problems using your "out of the box" thinking? Are you tired of being the > "smartest guy in the room" when you're at work? Well then, I've got the > job you're looking for! The above qualifications are the "wish list". > That should give you a feel of whether or not you're qualified for this > position though. You know your own skill set better than anyone else. > > Just be advised: Please don't be a "buzzword bandit" on your CV. If you > list a skill or experience, its fair game to ask you about these - in depth > - during your phone screen and any subsequent in-person interviews. > > Interested and Qualified candidates, please forward your CVs to jfraizer at > ebay dot com. > > eBay, Inc is an Equal Opportunity Employer > > -- > John Fraizer > MTS2 - eBay Site Network Engineering > From nanog at cdl.asgaard.org Sat Jun 6 01:25:14 2015 From: nanog at cdl.asgaard.org (nanog at cdl.asgaard.org) Date: Fri, 05 Jun 2015 18:25:14 -0700 Subject: eBay is looking for network heavies... In-Reply-To: <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> Message-ID: <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> On 5 Jun 2015, at 17:45, ?ukasz Bromirski wrote: >> On 06 Jun 2015, at 02:26, Jared Mauch wrote: >> >> >>> On Jun 5, 2015, at 7:13 PM, John Fraizer wrote: >>> >>> Head of line for CCIE / JNCIE but knowledge and experience trumps a >>> piece >>> of paper every time! >> >> Can you please put these at the back of the line? My experience is >> that >> the cisco certification (at least) is evidence of the absence of >> actual >> troubleshooting skills. (or my standards of what defines >> ?expert? are >> different than the rest of the world). > > Jared, don?t generalize. > > True - there are people that are ?paper? CCIE/JNCIEs - but let?s > not > start a rant unless you've met tens of CCIEs/JNCIEs and all of them > didn?t know a jack. About troubleshooting. 't We had one CCIE at a previous job who just didn't "click" no matter how much we tried to train on the architecture. Eventually in one backbone event, he kept saying that the problem couldn't be with a given router because "traceroute worked." When it was pointed out that the potential fault wouldn't cause traceroute to fail, we got a very puzzled look. We then asked him to explain how traceroute worked. He spectacularly failed. It became a tongue-in-cheek interview question. What was boggling was the number of *IE's that failed trying to explain traceroute's mechanics. My test, as crass as it is. If your CV headlines with a JCIE/CCIE, I am pretty certain that you have very little real-world experience. If it's a footnote somewhere, that's ok. Christopher > > ? > CCIE #15929 R&S/SP, CCDE #2012::17 > (not that I?d know anything about troubleshooting of course) -- ??? Avt tace, avt loqvere meliora silentio Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf keybase: https://keybase.io/liljenstolpe From john at op-sec.us Sat Jun 6 01:31:57 2015 From: john at op-sec.us (John Fraizer) Date: Fri, 5 Jun 2015 18:31:57 -0700 Subject: eBay is looking for network heavies... In-Reply-To: References: Message-ID: It's been over a decade since I was an active participant on NANOG. I didn't know that the NANOG-JOBS list existed. Sometimes it's easier to ask for forgiveness than permission though. I guess it's a good thing Susan H. isn't here to throw me in NANOG jail, huh? John Fraizer --Sent from my Android phone. Please excuse any typos. On Jun 5, 2015 6:23 PM, "ryanL" wrote: > we're allowed to recruit on nanog?... > > On Fri, Jun 5, 2015 at 4:19 PM John Fraizer wrote: > >> Hello All, >> >> eBay is looking for folks to join our Site Network Engineering team. eBay >> Site Network Engineering is responsible for the eBay SITE network from ToR >> to Peering Edge. You won't be bored. You will be challenged. You will >> have fun! >> This position is located in San Jose, California @ eBay HQ although >> exception may be made for extremely well qualified candidates. >> >> >> *Qualifications:* >> >> - 7+ years of experience in network design and implementation >> - 7+ years working at the highest level of technical escalation >> - Expert level multi-vendor experience in routing & switching with >> Arista, Cisco, Juniper, Nexus platforms >> - Expert level understanding of IPv4 & IPv6. Bonus points if you can >> tell me about IPv8. (The old guard will get that joke.) >> - Expert level BGP and OSPF >> - Understanding of multicast technologies such as PIM-SM and PIM-BiDir >> - Understanding of QoS and implementation strategies >> - Experience with L2 technologies such as MLAG and VPC >> - Experience with cloud architectures and network automation >> - Experience with SDN technologies such as VXLAN, NVGRE and Open >> vSwitch >> - Expert level troubleshooting skills >> - Functional knowledge of and comfort working in *nix environments >> - Ability to script in Bash, Perl, or other relevant languages. (Bonus >> for Python) >> - Excellent communications and documentation skills >> >> Head of line for CCIE / JNCIE but knowledge and experience trumps a piece >> of paper every time! >> BSCS or other 4-year degree desired - may be substituted with relevant >> work >> experience >> >> >> Translation of the above: Are you considered an expert by your industry >> peers? We know your family thinks you're a genius. Do your peers in the >> networking community agree? Do you want work on the bleeding edge of >> technology, playing with the biggest, baddest and bestest toys? Are you a >> team player who can also work alone providing creative solutions to >> complex >> problems using your "out of the box" thinking? Are you tired of being the >> "smartest guy in the room" when you're at work? Well then, I've got the >> job you're looking for! The above qualifications are the "wish list". >> That should give you a feel of whether or not you're qualified for this >> position though. You know your own skill set better than anyone else. >> >> Just be advised: Please don't be a "buzzword bandit" on your CV. If you >> list a skill or experience, its fair game to ask you about these - in >> depth >> - during your phone screen and any subsequent in-person interviews. >> >> Interested and Qualified candidates, please forward your CVs to jfraizer >> at >> ebay dot com. >> >> eBay, Inc is an Equal Opportunity Employer >> >> -- >> John Fraizer >> MTS2 - eBay Site Network Engineering >> > From eyeronic.design at gmail.com Sat Jun 6 01:38:31 2015 From: eyeronic.design at gmail.com (Mike Hale) Date: Fri, 5 Jun 2015 18:38:31 -0700 Subject: eBay is looking for network heavies... In-Reply-To: <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> Message-ID: We need a pool on what percentage of readers just googled traceroute. On Jun 5, 2015 6:28 PM, wrote: > On 5 Jun 2015, at 17:45, ?ukasz Bromirski wrote: > > On 06 Jun 2015, at 02:26, Jared Mauch wrote: >>> >>> >>> On Jun 5, 2015, at 7:13 PM, John Fraizer wrote: >>>> >>>> Head of line for CCIE / JNCIE but knowledge and experience trumps a >>>> piece >>>> of paper every time! >>>> >>> >>> Can you please put these at the back of the line? My experience is that >>> the cisco certification (at least) is evidence of the absence of actual >>> troubleshooting skills. (or my standards of what defines ?expert? are >>> different than the rest of the world). >>> >> >> Jared, don?t generalize. >> >> True - there are people that are ?paper? CCIE/JNCIEs - but let?s not >> start a rant unless you've met tens of CCIEs/JNCIEs and all of them >> didn?t know a jack. About troubleshooting. >> > > 't > > We had one CCIE at a previous job who just didn't "click" no matter how > much we tried to train on the architecture. Eventually in one backbone > event, he kept saying that the problem couldn't be with a given router > because "traceroute worked." When it was pointed out that the potential > fault wouldn't cause traceroute to fail, we got a very puzzled look. We > then asked him to explain how traceroute worked. He spectacularly failed. > > It became a tongue-in-cheek interview question. What was boggling was the > number of *IE's that failed trying to explain traceroute's mechanics. > > My test, as crass as it is. If your CV headlines with a JCIE/CCIE, I am > pretty certain that you have very little real-world experience. If it's a > footnote somewhere, that's ok. > > Christopher > > > >> ? >> CCIE #15929 R&S/SP, CCDE #2012::17 >> (not that I?d know anything about troubleshooting of course) >> > > > -- > ??? > Avt tace, avt loqvere meliora silentio > Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc > Current vCard here: http://www.asgaard.org/cdl/cdl.vcf > keybase: https://keybase.io/liljenstolpe > From deleskie at gmail.com Sat Jun 6 01:53:10 2015 From: deleskie at gmail.com (jim deleskie) Date: Fri, 5 Jun 2015 22:53:10 -0300 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> Message-ID: Based on the number of "certified" people I've interviewed over the last 20yr, my default view lines up with Jared's 100% On Fri, Jun 5, 2015 at 10:38 PM, Mike Hale wrote: > We need a pool on what percentage of readers just googled traceroute. > On Jun 5, 2015 6:28 PM, wrote: > > > On 5 Jun 2015, at 17:45, ?ukasz Bromirski wrote: > > > > On 06 Jun 2015, at 02:26, Jared Mauch wrote: > >>> > >>> > >>> On Jun 5, 2015, at 7:13 PM, John Fraizer wrote: > >>>> > >>>> Head of line for CCIE / JNCIE but knowledge and experience trumps a > >>>> piece > >>>> of paper every time! > >>>> > >>> > >>> Can you please put these at the back of the line? My experience is > that > >>> the cisco certification (at least) is evidence of the absence of actual > >>> troubleshooting skills. (or my standards of what defines ?expert? are > >>> different than the rest of the world). > >>> > >> > >> Jared, don?t generalize. > >> > >> True - there are people that are ?paper? CCIE/JNCIEs - but let?s not > >> start a rant unless you've met tens of CCIEs/JNCIEs and all of them > >> didn?t know a jack. About troubleshooting. > >> > > > > 't > > > > We had one CCIE at a previous job who just didn't "click" no matter how > > much we tried to train on the architecture. Eventually in one backbone > > event, he kept saying that the problem couldn't be with a given router > > because "traceroute worked." When it was pointed out that the potential > > fault wouldn't cause traceroute to fail, we got a very puzzled look. We > > then asked him to explain how traceroute worked. He spectacularly > failed. > > > > It became a tongue-in-cheek interview question. What was boggling was > the > > number of *IE's that failed trying to explain traceroute's mechanics. > > > > My test, as crass as it is. If your CV headlines with a JCIE/CCIE, I am > > pretty certain that you have very little real-world experience. If it's > a > > footnote somewhere, that's ok. > > > > Christopher > > > > > > > >> ? > >> CCIE #15929 R&S/SP, CCDE #2012::17 > >> (not that I?d know anything about troubleshooting of course) > >> > > > > > > -- > > ??? > > Avt tace, avt loqvere meliora silentio > > Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc > > Current vCard here: http://www.asgaard.org/cdl/cdl.vcf > > keybase: https://keybase.io/liljenstolpe > > > From jamesl at mythostech.com Sat Jun 6 01:57:38 2015 From: jamesl at mythostech.com (James Laszko) Date: Sat, 6 Jun 2015 01:57:38 +0000 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org>, Message-ID: <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> I asked one of my guys to tracert in windows for something and he executed pathping. I have never seen that in 25 years.... Go figure! James Laszko Mythos Technology Inc jamesl at mythostech.com Sent from my iPhone > On Jun 5, 2015, at 18:40, Mike Hale wrote: > > We need a pool on what percentage of readers just googled traceroute. >> On Jun 5, 2015 6:28 PM, wrote: >> >> On 5 Jun 2015, at 17:45, ?ukasz Bromirski wrote: >> >> On 06 Jun 2015, at 02:26, Jared Mauch wrote: >>>> >>>> >>>>> On Jun 5, 2015, at 7:13 PM, John Fraizer wrote: >>>>> >>>>> Head of line for CCIE / JNCIE but knowledge and experience trumps a >>>>> piece >>>>> of paper every time! >>>> >>>> Can you please put these at the back of the line? My experience is that >>>> the cisco certification (at least) is evidence of the absence of actual >>>> troubleshooting skills. (or my standards of what defines ?expert? are >>>> different than the rest of the world). >>> >>> Jared, don?t generalize. >>> >>> True - there are people that are ?paper? CCIE/JNCIEs - but let?s not >>> start a rant unless you've met tens of CCIEs/JNCIEs and all of them >>> didn?t know a jack. About troubleshooting. >> >> 't >> >> We had one CCIE at a previous job who just didn't "click" no matter how >> much we tried to train on the architecture. Eventually in one backbone >> event, he kept saying that the problem couldn't be with a given router >> because "traceroute worked." When it was pointed out that the potential >> fault wouldn't cause traceroute to fail, we got a very puzzled look. We >> then asked him to explain how traceroute worked. He spectacularly failed. >> >> It became a tongue-in-cheek interview question. What was boggling was the >> number of *IE's that failed trying to explain traceroute's mechanics. >> >> My test, as crass as it is. If your CV headlines with a JCIE/CCIE, I am >> pretty certain that you have very little real-world experience. If it's a >> footnote somewhere, that's ok. >> >> Christopher >> >> >> >>> ? >>> CCIE #15929 R&S/SP, CCDE #2012::17 >>> (not that I?d know anything about troubleshooting of course) >> >> >> -- >> ??? >> Avt tace, avt loqvere meliora silentio >> Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc >> Current vCard here: http://www.asgaard.org/cdl/cdl.vcf >> keybase: https://keybase.io/liljenstolpe >> From list at satchell.net Sat Jun 6 02:31:12 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 05 Jun 2015 19:31:12 -0700 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> Message-ID: <55725B70.6080208@satchell.net> On 06/05/2015 06:38 PM, Mike Hale wrote: > We need a pool on what percentage of readers just googled traceroute. I didn't google traceroute. Didn't need to. Instead, I drew on the knowledge I gained when Clifford and I wrote _Linux IP Stacks Commentary_. Unfortunately, the Steven's books are not required reading in CCIE prep. From bmanning at karoshi.com Sat Jun 6 02:41:00 2015 From: bmanning at karoshi.com (manning) Date: Fri, 5 Jun 2015 19:41:00 -0700 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> Message-ID: whois traceroute ? manning On 5June2015Friday, at 18:38, Mike Hale wrote: > We need a pool on what percentage of readers just googled traceroute. > > From surfer at mauigateway.com Sat Jun 6 02:50:46 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 5 Jun 2015 19:50:46 -0700 Subject: interviewing [was] Re: eBay is looking for network heavies... Message-ID: <20150605195046.5B2FF093@m0005311.ppops.net> ------------------------------------- It became a tongue-in-cheek interview question. What was boggling was the number of *IE's that failed trying to explain traceroute's mechanics. ------------------------------------ One thing I have done in the past is encourage the person to succeed at the interview, rather than see how they fail. I do this because some folks don't interview well, but they really know their stuff or have other attributes that make them desirable, such as a great work ethic and a desire to learn. One way to do this is find out how they'd go about solving a problem, rather than what find out what they've memorized. :: We need a pool on what percentage of readers just :: googled traceroute. Exactly. I've read ras' paper several times, but I don't memorize it. If I need to look something about it up for some reason, I know where to go: https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf Ask me in an interview when I'm nervous and I stumble like a nerd asking a girl out on a date. Say something a little silly then try to recover only to say something more dumb finally trying to recover from both only to say something stupid and finally throwing up my hands in disgust knowing I'm not going to get the date/job. :-) This happened to me around 6-8 months ago. scott From faisal at snappytelecom.net Sat Jun 6 04:35:45 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 6 Jun 2015 04:35:45 +0000 (GMT) Subject: eBay is looking for network heavies... In-Reply-To: <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> Message-ID: <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> 'pathping' ..... learned something new today... Did not know such a command existed in windows.. Been working with computers for over 30 years, while I don't care as to what it says about how much I know, but it sure reminds me that that their is always something more that one can learn ! Thank You. :) 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: "James Laszko" > To: "Mike Hale" > Cc: "NANOG Operators' Group" > Sent: Friday, June 5, 2015 9:57:38 PM > Subject: Re: eBay is looking for network heavies... > > I asked one of my guys to tracert in windows for something and he executed > pathping. I have never seen that in 25 years.... Go figure! > > > James Laszko > Mythos Technology Inc > jamesl at mythostech.com > > Sent from my iPhone > > > On Jun 5, 2015, at 18:40, Mike Hale wrote: > > > > We need a pool on what percentage of readers just googled traceroute. > >> On Jun 5, 2015 6:28 PM, wrote: > >> > >> On 5 Jun 2015, at 17:45, ?ukasz Bromirski wrote: > >> > >> On 06 Jun 2015, at 02:26, Jared Mauch wrote: > >>>> > >>>> > >>>>> On Jun 5, 2015, at 7:13 PM, John Fraizer wrote: > >>>>> > >>>>> Head of line for CCIE / JNCIE but knowledge and experience trumps a > >>>>> piece > >>>>> of paper every time! > >>>> > >>>> Can you please put these at the back of the line? My experience is that > >>>> the cisco certification (at least) is evidence of the absence of actual > >>>> troubleshooting skills. (or my standards of what defines ?expert? are > >>>> different than the rest of the world). > >>> > >>> Jared, don?t generalize. > >>> > >>> True - there are people that are ?paper? CCIE/JNCIEs - but let?s not > >>> start a rant unless you've met tens of CCIEs/JNCIEs and all of them > >>> didn?t know a jack. About troubleshooting. > >> > >> 't > >> > >> We had one CCIE at a previous job who just didn't "click" no matter how > >> much we tried to train on the architecture. Eventually in one backbone > >> event, he kept saying that the problem couldn't be with a given router > >> because "traceroute worked." When it was pointed out that the potential > >> fault wouldn't cause traceroute to fail, we got a very puzzled look. We > >> then asked him to explain how traceroute worked. He spectacularly failed. > >> > >> It became a tongue-in-cheek interview question. What was boggling was the > >> number of *IE's that failed trying to explain traceroute's mechanics. > >> > >> My test, as crass as it is. If your CV headlines with a JCIE/CCIE, I am > >> pretty certain that you have very little real-world experience. If it's a > >> footnote somewhere, that's ok. > >> > >> Christopher > >> > >> > >> > >>> ? > >>> CCIE #15929 R&S/SP, CCDE #2012::17 > >>> (not that I?d know anything about troubleshooting of course) > >> > >> > >> -- > >> ??? > >> Avt tace, avt loqvere meliora silentio > >> Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc > >> Current vCard here: http://www.asgaard.org/cdl/cdl.vcf > >> keybase: https://keybase.io/liljenstolpe > >> > From elmi at 4ever.de Sat Jun 6 06:11:51 2015 From: elmi at 4ever.de (Elmar K. Bins) Date: Sat, 6 Jun 2015 08:11:51 +0200 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> Message-ID: <20150606061151.GA22061@Dumbbox.local> eyeronic.design at gmail.com (Mike Hale) wrote: > We need a pool on what percentage of readers just googled traceroute. None of course! From joe at nethead.com Sat Jun 6 06:13:46 2015 From: joe at nethead.com (Joe Hamelin) Date: Fri, 5 Jun 2015 23:13:46 -0700 Subject: eBay is looking for network heavies... In-Reply-To: <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> Message-ID: Back in 2000 at Amazon, HR somehow decided to have me do the phone interviews for neteng. I'd go through questions on routing and what not, then at the end I would ask questions like, "Who was Jon Postel? Who is Larry Wall? Who is Paul Vixie? What are layers 8 & 9? Explain the RTFM protocol. What is NANOG?" Those answers (or long silences) told me more about the candidate than most of the technical questions. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From joe at nethead.com Sat Jun 6 06:15:17 2015 From: joe at nethead.com (Joe Hamelin) Date: Fri, 5 Jun 2015 23:15:17 -0700 Subject: eBay is looking for network heavies... In-Reply-To: <20150606061151.GA22061@Dumbbox.local> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <20150606061151.GA22061@Dumbbox.local> Message-ID: On Fri, Jun 5, 2015 at 11:11 PM, Elmar K. Bins wrote: > eyeronic.design at gmail.com (Mike Hale) wrote: > > > We need a pool on what percentage of readers just googled traceroute. > > None of course! No, they read the man page, of course! -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > From surfer at mauigateway.com Sat Jun 6 08:50:41 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 6 Jun 2015 01:50:41 -0700 Subject: eBay is looking for network heavies... Message-ID: <20150606015041.5B2FF407@m0005311.ppops.net> --- joe at nethead.com wrote: From: Joe Hamelin Back in 2000 at Amazon, HR somehow decided to have me do the phone interviews for neteng. I'd go through questions on routing and what not, then at the end I would ask questions like, "Who was Jon Postel? Who is Larry Wall? Who is Paul Vixie? What are layers 8 & 9? Explain the RTFM protocol. What is NANOG?" Those answers (or long silences) told me more about the candidate than most of the technical questions. --------------------------------------------------- Now that's a good interview question series. It shows that the person cares, rather than just doing a job. scott ps. I never thought of RTFM as a protocol, but I like it. It's a protocol between engineers. The conservative in what you send part... :-) From ag4ve.us at gmail.com Sat Jun 6 09:48:19 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Sat, 6 Jun 2015 05:48:19 -0400 Subject: eBay is looking for network heavies... In-Reply-To: <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> Message-ID: On Fri, Jun 5, 2015 at 9:57 PM, James Laszko wrote: > I asked one of my guys to tracert in windows for something and he executed pathping. I have never seen that in 25 years.... Go figure! > Yep, I learned something new (though IDK I'll ever use it - I'm guessing it's useless trivia, esp since I haven't done much with Windows in ~6 years now). My default traceroute is: nmap -Pn -p0 --traceroute From deleskie at gmail.com Sat Jun 6 10:32:15 2015 From: deleskie at gmail.com (jim deleskie) Date: Sat, 6 Jun 2015 07:32:15 -0300 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> Message-ID: I remember you asking me who Jon was :) I have since added to my list of interview questions... sad but the number of people with clue is declining not increasing. On Sat, Jun 6, 2015 at 3:13 AM, Joe Hamelin wrote: > Back in 2000 at Amazon, HR somehow decided to have me do the phone > interviews for neteng. I'd go through questions on routing and what not, > then at the end I would ask questions like, "Who was Jon Postel? Who is > Larry Wall? Who is Paul Vixie? What are layers 8 & 9? Explain the RTFM > protocol. What is NANOG?" Those answers (or long silences) told me more > about the candidate than most of the technical questions. > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > From ag4ve.us at gmail.com Sat Jun 6 10:43:01 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Sat, 6 Jun 2015 06:43:01 -0400 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> Message-ID: My first thought on reading that was "who the hell cares if a person knows about internet culture". But than I had to reconsider - it's a very apt way of telling if someone read the right books :) I would also add Ritchie, Thompson, and Diffie to that list (since you ask about Larry, it's only appropriate). On Sat, Jun 6, 2015 at 6:32 AM, jim deleskie wrote: > I remember you asking me who Jon was :) I have since added to my list of > interview questions... sad but the number of people with clue is declining > not increasing. > > > On Sat, Jun 6, 2015 at 3:13 AM, Joe Hamelin wrote: > >> Back in 2000 at Amazon, HR somehow decided to have me do the phone >> interviews for neteng. I'd go through questions on routing and what not, >> then at the end I would ask questions like, "Who was Jon Postel? Who is >> Larry Wall? Who is Paul Vixie? What are layers 8 & 9? Explain the RTFM >> protocol. What is NANOG?" Those answers (or long silences) told me more >> about the candidate than most of the technical questions. >> >> -- >> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 >> From dorian at blackrose.org Sat Jun 6 10:53:20 2015 From: dorian at blackrose.org (Dorian Kim) Date: Sat, 6 Jun 2015 06:53:20 -0400 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> Message-ID: "Those who cannot remember the past are condemned to repeat it? -Santayana Quite relevant in our industry that seems be more hell bent on rehashing ideas and plot lines than Hollywood. -dorian > On Jun 6, 2015, at 6:43 AM, shawn wilson wrote: > > My first thought on reading that was "who the hell cares if a person > knows about internet culture". But than I had to reconsider - it's a > very apt way of telling if someone read the right books :) > > I would also add Ritchie, Thompson, and Diffie to that list (since you > ask about Larry, it's only appropriate). > > On Sat, Jun 6, 2015 at 6:32 AM, jim deleskie wrote: >> I remember you asking me who Jon was :) I have since added to my list of >> interview questions... sad but the number of people with clue is declining >> not increasing. >> >> >> On Sat, Jun 6, 2015 at 3:13 AM, Joe Hamelin wrote: >> >>> Back in 2000 at Amazon, HR somehow decided to have me do the phone >>> interviews for neteng. I'd go through questions on routing and what not, >>> then at the end I would ask questions like, "Who was Jon Postel? Who is >>> Larry Wall? Who is Paul Vixie? What are layers 8 & 9? Explain the RTFM >>> protocol. What is NANOG?" Those answers (or long silences) told me more >>> about the candidate than most of the technical questions. >>> >>> -- >>> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 >>> From dave at fluidhosting.com Sat Jun 6 11:55:58 2015 From: dave at fluidhosting.com (dave at fluidhosting.com) Date: Sat, 06 Jun 2015 07:55:58 -0400 Subject: Looking for network administration service Message-ID: <20150606075558.10613o8gira0efv2@204.14.90.11> Dear all, We are looking for a network engineer to help us maintain our network. Devices used: Brocade RX4 router and Force10 switches. Is there any company/individuals that can provide such service on a monthly retainer or project basis? Thank you in advance. Regards, -dave From tvest at eyeconomics.com Sat Jun 6 12:33:21 2015 From: tvest at eyeconomics.com (tvest) Date: Sat, 06 Jun 2015 08:33:21 -0400 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> Message-ID: <22295B6A-4990-47B2-B466-8AAD869926E0@eyeconomics.com> You are such an optimist ;-) Sometimes those who can remember the past get to repeat it anyway. TV On June 6, 2015 6:53:20 AM EDT, Dorian Kim wrote: >"Those who cannot remember the past are condemned to repeat it? > > -Santayana > >Quite relevant in our industry that seems be more hell bent on >rehashing ideas >and plot lines than Hollywood. > >-dorian > > >> On Jun 6, 2015, at 6:43 AM, shawn wilson wrote: >> >> My first thought on reading that was "who the hell cares if a person >> knows about internet culture". But than I had to reconsider - it's a >> very apt way of telling if someone read the right books :) >> >> I would also add Ritchie, Thompson, and Diffie to that list (since >you >> ask about Larry, it's only appropriate). >> >> On Sat, Jun 6, 2015 at 6:32 AM, jim deleskie >wrote: >>> I remember you asking me who Jon was :) I have since added to my >list of >>> interview questions... sad but the number of people with clue is >declining >>> not increasing. >>> >>> >>> On Sat, Jun 6, 2015 at 3:13 AM, Joe Hamelin wrote: >>> >>>> Back in 2000 at Amazon, HR somehow decided to have me do the phone >>>> interviews for neteng. I'd go through questions on routing and >what not, >>>> then at the end I would ask questions like, "Who was Jon Postel? >Who is >>>> Larry Wall? Who is Paul Vixie? What are layers 8 & 9? Explain the >RTFM >>>> protocol. What is NANOG?" Those answers (or long silences) told >me more >>>> about the candidate than most of the technical questions. >>>> >>>> -- >>>> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 >>>> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From list at satchell.net Sat Jun 6 13:14:34 2015 From: list at satchell.net (Stephen Satchell) Date: Sat, 06 Jun 2015 06:14:34 -0700 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> Message-ID: <5572F23A.4090906@satchell.net> On 06/06/2015 03:32 AM, jim deleskie wrote: > I remember you asking me who Jon was:) I have since added to my list of > interview questions... sad but the number of people with clue is declining > not increasing. It's not a question of clue, but of history. How many CS grads are exposed to the details of the development of the Internet and Information Technology? Many of us know of Jon Postel because we experienced and appreciated his work for the Internet when he was alive. Ditto Richard Stevens. Now I ask you: how many students would delve into history that deeply? How many universities/colleges/trade schools would include that information in their curriculum? Moving on...Larry Wall -- I'm finding that the new generation of people don't use Perl any more, instead favoring Python for some reason. Indeed, my current job's management insists I learn Python, even though Perl has much more support for Cisco equipment as part of CPAN. So, given that bias, it wouldn't be surprising that the up-and-coming wouldn't know who invented a tool they don't use. Guido van Rossum, they know, maybe. People exposed only to Windows may or may not know about Paul Vixie's contributions to our world -- again, it's history that would be arcane for those who never dabbled in Unix or Unix-like systems, or didn't follow Internet politics. (Yes, BIND is implemented on Windows systems -- I consult to an ISP who suffers through the pain caused by the decision to do so -- but using a piece of software and knowing the history of that software are two different things, particularly when a person isn't doing DNS admin full-time.) If your goal is to play "Gotcha!", you need to go farther afield. What is "ARPAnet", and what role did it play in the development of the Internet? What is "XNS"? What is "ThickNet"? "ThinNet"? Expand and explain CTS, RTS, CD/DCD, MR, TR, RC, TC. What is V.35? HSSI? ITU? T1 and E1, and what is the difference? And so on through ISO level 1. Who was Thomas Watson? Who was Hollerith...and how did his invention trace its origins to silk tapestry? What problem was Hollerith trying to solve? Who is (were) Ken Olson and Harlan Anderson? Throw in Ada Lovelace and Grace Hopper. What is the significance of a 30 centimeter piece of twisted-pair wire, which Admiral Hopper would hand out at lectures? What is COBOL? (And I'm not referring to the planet Kobol that is part of the Battlestar Galactia universe.) Who were Ken Thompson, Brian Kernighan, Dennis Ritchie, and Phillip Plauger? Bill Joy? And so on, and so on, second star to the right and straight on 'till morning... Here's the topper: who was (is) Al Gore, and what part did he play in the birth of the Internet as we know it today? Try not to howl as some of the answers you will get. From ag4ve.us at gmail.com Sat Jun 6 13:31:25 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Sat, 6 Jun 2015 09:31:25 -0400 Subject: eBay is looking for network heavies... In-Reply-To: <22295B6A-4990-47B2-B466-8AAD869926E0@eyeconomics.com> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> <22295B6A-4990-47B2-B466-8AAD869926E0@eyeconomics.com> Message-ID: On Sat, Jun 6, 2015 at 8:33 AM, tvest wrote: > You are such an optimist ;-) > > Sometimes those who can remember the past get to repeat it anyway. > I remember seeing a slide deck for devs saying all new web apps are recreating mail, write, wall, and finger (the person posted it on FB, so of course I can't find it for ref) From bross at pobox.com Sat Jun 6 13:53:03 2015 From: bross at pobox.com (Brandon Ross) Date: Sat, 6 Jun 2015 09:53:03 -0400 (EDT) Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> Message-ID: I also concur. There is most certainly a negative correlation between certs and clue in my experience, having met 10s of certificate holders. Long ago when the MCSE was more popular, I actually started putting "MCSE need not apply" on job postings because everyone I interviewed that had one was not just clue challenged, but had negative clue. On Fri, 5 Jun 2015, jim deleskie wrote: > Based on the number of "certified" people I've interviewed over the last > 20yr, my default view lines up with Jared's 100% > > On Fri, Jun 5, 2015 at 10:38 PM, Mike Hale > wrote: > >> We need a pool on what percentage of readers just googled traceroute. >> On Jun 5, 2015 6:28 PM, wrote: >> >>> On 5 Jun 2015, at 17:45, ?ukasz Bromirski wrote: >>> >>> On 06 Jun 2015, at 02:26, Jared Mauch wrote: >>>>> >>>>> >>>>> On Jun 5, 2015, at 7:13 PM, John Fraizer wrote: >>>>>> >>>>>> Head of line for CCIE / JNCIE but knowledge and experience trumps a >>>>>> piece >>>>>> of paper every time! >>>>>> >>>>> >>>>> Can you please put these at the back of the line? My experience is >> that >>>>> the cisco certification (at least) is evidence of the absence of actual >>>>> troubleshooting skills. (or my standards of what defines ?expert? are >>>>> different than the rest of the world). >>>>> >>>> >>>> Jared, don?t generalize. >>>> >>>> True - there are people that are ?paper? CCIE/JNCIEs - but let?s not >>>> start a rant unless you've met tens of CCIEs/JNCIEs and all of them >>>> didn?t know a jack. About troubleshooting. >>>> >>> >>> 't >>> >>> We had one CCIE at a previous job who just didn't "click" no matter how >>> much we tried to train on the architecture. Eventually in one backbone >>> event, he kept saying that the problem couldn't be with a given router >>> because "traceroute worked." When it was pointed out that the potential >>> fault wouldn't cause traceroute to fail, we got a very puzzled look. We >>> then asked him to explain how traceroute worked. He spectacularly >> failed. >>> >>> It became a tongue-in-cheek interview question. What was boggling was >> the >>> number of *IE's that failed trying to explain traceroute's mechanics. >>> >>> My test, as crass as it is. If your CV headlines with a JCIE/CCIE, I am >>> pretty certain that you have very little real-world experience. If it's >> a >>> footnote somewhere, that's ok. >>> >>> Christopher >>> >>> >>> >>>> ? >>>> CCIE #15929 R&S/SP, CCDE #2012::17 >>>> (not that I?d know anything about troubleshooting of course) >>>> >>> >>> >>> -- >>> ??? >>> Avt tace, avt loqvere meliora silentio >>> Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc >>> Current vCard here: http://www.asgaard.org/cdl/cdl.vcf >>> keybase: https://keybase.io/liljenstolpe >>> >> > -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From netfortius at gmail.com Sat Jun 6 15:50:00 2015 From: netfortius at gmail.com (Stefan) Date: Sat, 6 Jun 2015 10:50:00 -0500 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> Message-ID: Sort of back-tracking on the OP JD - is one to derive from the posting and requirements for the job(s) that: 1. the need arises because of the eBay - PayPal split? 2. is PayPal leaving with the openstack [need for] expertise and associated IaaS parts (http://www.openstack.org/user-stories/paypal/), while eBay is keeping a more traditional infra setup? ? Stefan On Sat, Jun 6, 2015 at 8:53 AM, Brandon Ross wrote: > I also concur. There is most certainly a negative correlation between > certs and clue in my experience, having met 10s of certificate holders. > > Long ago when the MCSE was more popular, I actually started putting "MCSE > need not apply" on job postings because everyone I interviewed that had one > was not just clue challenged, but had negative clue. > > > On Fri, 5 Jun 2015, jim deleskie wrote: > > Based on the number of "certified" people I've interviewed over the last >> 20yr, my default view lines up with Jared's 100% >> >> On Fri, Jun 5, 2015 at 10:38 PM, Mike Hale >> wrote: >> >> We need a pool on what percentage of readers just googled traceroute. >>> On Jun 5, 2015 6:28 PM, wrote: >>> >>> On 5 Jun 2015, at 17:45, ?ukasz Bromirski wrote: >>>> >>>> On 06 Jun 2015, at 02:26, Jared Mauch wrote: >>>> >>>>> >>>>>> >>>>>> On Jun 5, 2015, at 7:13 PM, John Fraizer wrote: >>>>>> >>>>>>> >>>>>>> Head of line for CCIE / JNCIE but knowledge and experience trumps a >>>>>>> piece >>>>>>> of paper every time! >>>>>>> >>>>>>> >>>>>> Can you please put these at the back of the line? My experience is >>>>>> >>>>> that >>> >>>> the cisco certification (at least) is evidence of the absence of actual >>>>>> troubleshooting skills. (or my standards of what defines ?expert? are >>>>>> different than the rest of the world). >>>>>> >>>>>> >>>>> Jared, don?t generalize. >>>>> >>>>> True - there are people that are ?paper? CCIE/JNCIEs - but let?s not >>>>> start a rant unless you've met tens of CCIEs/JNCIEs and all of them >>>>> didn?t know a jack. About troubleshooting. >>>>> >>>>> >>>> 't >>>> >>>> We had one CCIE at a previous job who just didn't "click" no matter how >>>> much we tried to train on the architecture. Eventually in one backbone >>>> event, he kept saying that the problem couldn't be with a given router >>>> because "traceroute worked." When it was pointed out that the potential >>>> fault wouldn't cause traceroute to fail, we got a very puzzled look. We >>>> then asked him to explain how traceroute worked. He spectacularly >>>> >>> failed. >>> >>>> >>>> It became a tongue-in-cheek interview question. What was boggling was >>>> >>> the >>> >>>> number of *IE's that failed trying to explain traceroute's mechanics. >>>> >>>> My test, as crass as it is. If your CV headlines with a JCIE/CCIE, I am >>>> pretty certain that you have very little real-world experience. If it's >>>> >>> a >>> >>>> footnote somewhere, that's ok. >>>> >>>> Christopher >>>> >>>> >>>> >>>> ? >>>>> CCIE #15929 R&S/SP, CCDE #2012::17 >>>>> (not that I?d know anything about troubleshooting of course) >>>>> >>>>> >>>> >>>> -- >>>> ??? >>>> Avt tace, avt loqvere meliora silentio >>>> Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc >>>> Current vCard here: http://www.asgaard.org/cdl/cdl.vcf >>>> keybase: https://keybase.io/liljenstolpe >>>> >>>> >>> >> > -- > Brandon Ross Yahoo & AIM: > BrandonNRoss > +1-404-635-6667 ICQ: > 2269442 > Skype: > brandonross > Schedule a meeting: http://www.doodle.com/bross > From dave.taht at gmail.com Sat Jun 6 16:27:16 2015 From: dave.taht at gmail.com (Dave Taht) Date: Sat, 6 Jun 2015 09:27:16 -0700 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> Message-ID: On Sat, Jun 6, 2015 at 6:53 AM, Brandon Ross wrote: > I also concur. There is most certainly a negative correlation between certs > and clue in my experience, having met 10s of certificate holders. Oh good. Maybe my total lack of ever pursuing one of these things is actually a qualification of sorts? I keep searching things like dice and monster out of perverse bemusement, trying to find anyone actually looking for my actual skillset. -- Dave T?ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From clayton at MNSi.Net Sat Jun 6 16:32:35 2015 From: clayton at MNSi.Net (Clayton Zekelman) Date: Sat, 06 Jun 2015 12:32:35 -0400 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> Message-ID: <1433608357_65841@surgemail.mnsi.net> Reminds me of: http://dilbert.com/strip/2000-08-31 At 12:27 PM 06/06/2015, Dave Taht wrote: >On Sat, Jun 6, 2015 at 6:53 AM, Brandon Ross wrote: > > I also concur. There is most certainly a > negative correlation between certs > > and clue in my experience, having met 10s of certificate holders. > >Oh good. Maybe my total lack of ever pursuing one of these things is actually >a qualification of sorts? > >I keep searching things like dice and monster out of perverse bemusement, >trying to find anyone actually looking for my actual skillset. > >-- >Dave T??ht >What will it take to vastly improve wifi for everyone? >https://plus.google.com/u/0/explore/makewififast From ag4ve.us at gmail.com Sat Jun 6 16:44:49 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Sat, 6 Jun 2015 12:44:49 -0400 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> Message-ID: On Sat, Jun 6, 2015 at 12:27 PM, Dave Taht wrote: > On Sat, Jun 6, 2015 at 6:53 AM, Brandon Ross wrote: >> I also concur. There is most certainly a negative correlation between certs >> and clue in my experience, having met 10s of certificate holders. > > Oh good. Maybe my total lack of ever pursuing one of these things is actually > a qualification of sorts? > Meh, certs can be fun. I've never taken one and not learned something. I don't think someone should put me in charge of designing a SOC because I have a Security+ or that BestBuy should trust people with (or w/o) and A+ to fix computers. But I'll bet the journey people took to get that cert taught them something. Having gained the cert, does that mean it doesn't belong on a resume? No. If you hire someone with just a cert to manage your network, does that put you among the biggest dumbasses to ever hire someone? Absolutely. Further, HR who look for certs are probably doing themselves a disservice but if it works for them, who am I to tell them otherwise. If you want to work for the company, get the cert or don't. From frnkblk at iname.com Sat Jun 6 17:27:24 2015 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 6 Jun 2015 12:27:24 -0500 Subject: Access to nanog.cluepon.net Message-ID: <001501d0a07e$0e9566a0$2bc033e0$@iname.com> I'd like to update some material on nanog.cluepon.net (not very responsive to HTTP requests right now) and my account doesn't work anymore. I reached out to Richard S. but have not heard back from him - anyone else here who has admin access and can set me up again? Frank From frnkblk at iname.com Sat Jun 6 17:29:38 2015 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 6 Jun 2015 12:29:38 -0500 Subject: Tunable SFP Message-ID: <001601d0a07e$5e38d250$1aaa76f0$@iname.com> Anyone know if tunable SFPs exist? I've googled around on this, but only found fixed wave-length SFPs. Or of a tunable SFP+ that can operate in SFP port as 1G? Frank From josh at imaginenetworksllc.com Sat Jun 6 17:33:17 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sat, 6 Jun 2015 13:33:17 -0400 Subject: Access to nanog.cluepon.net In-Reply-To: <001501d0a07e$0e9566a0$2bc033e0$@iname.com> References: <001501d0a07e$0e9566a0$2bc033e0$@iname.com> Message-ID: Hasn't been working for about 20 minutes or more for me as well. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sat, Jun 6, 2015 at 1:27 PM, Frank Bulk wrote: > I'd like to update some material on nanog.cluepon.net (not very responsive > to HTTP requests right now) and my account doesn't work anymore. I reached > out to Richard S. but have not heard back from him - anyone else here who > has admin access and can set me up again? > > Frank > > From randy at psg.com Sat Jun 6 17:34:50 2015 From: randy at psg.com (Randy Bush) Date: Sat, 06 Jun 2015 10:34:50 -0700 Subject: hiring net engs (was: eBay rudely recruiting on list) In-Reply-To: <22295B6A-4990-47B2-B466-8AAD869926E0@eyeconomics.com> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> <22295B6A-4990-47B2-B466-8AAD869926E0@eyeconomics.com> Message-ID: nanog as dinosaur food From magicsata at gmail.com Sat Jun 6 17:35:57 2015 From: magicsata at gmail.com (Alistair Mackenzie) Date: Sat, 6 Jun 2015 18:35:57 +0100 Subject: Riot Games Message-ID: Hi, Is there anyone on this list from Riot Games that can reach out to me? I'm having some issues with customers reaching your network. Thanks, Alistair From jared at puck.nether.net Sat Jun 6 17:41:02 2015 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 6 Jun 2015 13:41:02 -0400 Subject: Tunable SFP In-Reply-To: <001601d0a07e$5e38d250$1aaa76f0$@iname.com> References: <001601d0a07e$5e38d250$1aaa76f0$@iname.com> Message-ID: <56FAC265-3CE9-4917-9679-C0DD55CECEC6@puck.nether.net> They do exist. They tend to have tighter link budgets as compared to XFP tunable optics. Don't expect to go as far due to the receiver sensitivity. Jared Mauch > On Jun 6, 2015, at 1:29 PM, Frank Bulk wrote: > > Anyone know if tunable SFPs exist? I've googled around on this, but only > found fixed wave-length SFPs. > > Or of a tunable SFP+ that can operate in SFP port as 1G? > > Frank From frnkblk at iname.com Sat Jun 6 17:45:20 2015 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 6 Jun 2015 12:45:20 -0500 Subject: Tunable SFP In-Reply-To: <56FAC265-3CE9-4917-9679-C0DD55CECEC6@puck.nether.net> References: <001601d0a07e$5e38d250$1aaa76f0$@iname.com> <56FAC265-3CE9-4917-9679-C0DD55CECEC6@puck.nether.net> Message-ID: <001c01d0a080$90512740$b0f375c0$@iname.com> Thanks -- can you point me to any suppliers? Frank -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Saturday, June 06, 2015 12:41 PM To: Frank Bulk Cc: Subject: Re: Tunable SFP They do exist. They tend to have tighter link budgets as compared to XFP tunable optics. Don't expect to go as far due to the receiver sensitivity. Jared Mauch > On Jun 6, 2015, at 1:29 PM, Frank Bulk wrote: > > Anyone know if tunable SFPs exist? I've googled around on this, but only > found fixed wave-length SFPs. > > Or of a tunable SFP+ that can operate in SFP port as 1G? > > Frank From mike at mtcc.com Sat Jun 6 17:52:16 2015 From: mike at mtcc.com (Michael Thomas) Date: Sat, 06 Jun 2015 10:52:16 -0700 Subject: hiring net engs In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> <22295B6A-4990-47B2-B466-8AAD869926E0@eyeconomics.com> Message-ID: <55733350.10607@mtcc.com> On 6/6/15 10:34 AM, Randy Bush wrote: > nanog as dinosaur food Don't you mean nanog as dinosaur water cooler? Mike From tfarrell at riotgames.com Sat Jun 6 17:55:52 2015 From: tfarrell at riotgames.com (Trent Farrell) Date: Sat, 6 Jun 2015 10:55:52 -0700 Subject: Riot Games In-Reply-To: References: Message-ID: Hi Alistair (and anyone else interested), the best place to reach our team is via peering at riotgames.com. Thanks! On Sat, Jun 6, 2015 at 10:35 AM, Alistair Mackenzie wrote: > Hi, > > Is there anyone on this list from Riot Games that can reach out to me? > > I'm having some issues with customers reaching your network. > > Thanks, > Alistair > -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarrell at riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro From jared at puck.nether.net Sat Jun 6 17:58:20 2015 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 6 Jun 2015 13:58:20 -0400 Subject: Tunable SFP In-Reply-To: <001c01d0a080$90512740$b0f375c0$@iname.com> References: <001601d0a07e$5e38d250$1aaa76f0$@iname.com> <56FAC265-3CE9-4917-9679-C0DD55CECEC6@puck.nether.net> <001c01d0a080$90512740$b0f375c0$@iname.com> Message-ID: <4E2D6279-D3C8-4FBC-ABD4-F6CEC59F0D97@puck.nether.net> https://www.finisar.com/optical-transceivers/ftlx6872mcc Finisar is now selling direct now. Let me know in private if you need a sales contact there. Jared Mauch > On Jun 6, 2015, at 1:45 PM, Frank Bulk wrote: > > Thanks -- can you point me to any suppliers? > > Frank > > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: Saturday, June 06, 2015 12:41 PM > To: Frank Bulk > Cc: > Subject: Re: Tunable SFP > > They do exist. They tend to have tighter link budgets as compared to XFP > tunable optics. Don't expect to go as far due to the receiver sensitivity. > > Jared Mauch > >> On Jun 6, 2015, at 1:29 PM, Frank Bulk wrote: >> >> Anyone know if tunable SFPs exist? I've googled around on this, but only >> found fixed wave-length SFPs. >> >> Or of a tunable SFP+ that can operate in SFP port as 1G? >> >> Frank > From bmanning at karoshi.com Sat Jun 6 18:00:04 2015 From: bmanning at karoshi.com (manning) Date: Sat, 6 Jun 2015 11:00:04 -0700 Subject: hiring net engs (was: eBay rudely recruiting on list) In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> <22295B6A-4990-47B2-B466-8AAD869926E0@eyeconomics.com> Message-ID: <045B6C0A-2E60-4A57-BC76-8966E4353254@karoshi.com> On 6June2015Saturday, at 10:34, Randy Bush wrote: > nanog as dinosaur food (not top-posting for your reading pleasure) Why do you love Marshal Rose? Why do you hate Jeff Case? Why would you buy Paul Traina a drink? Does Paul Francis deserve sainthood? (must add this to the Cult of Personality quiz) From frnkblk at iname.com Sat Jun 6 19:06:44 2015 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 6 Jun 2015 14:06:44 -0500 Subject: Tunable SFP In-Reply-To: <55733F85.4040000@aptient.com> References: <001601d0a07e$5e38d250$1aaa76f0$@iname.com> <56FAC265-3CE9-4917-9679-C0DD55CECEC6@puck.nether.net> <001c01d0a080$90512740$b0f375c0$@iname.com> <55733F85.4040000@aptient.com> Message-ID: <00b001d0a08b$edd10060$c9730120$@iname.com> Thanks, that's very helpful. They have several models there: https://www.flexoptix.net/en/produkte/transceiver.html?fo_tra_formfactor=sfp #fo_tra_formfactor=sfp&fo_tra_interface=05_dwdm_100ghz&gan_data=true Frank -----Original Message----- Sent: Saturday, June 06, 2015 1:44 PM To: Frank Bulk Subject: Re: Tunable SFP Check out https://www.flexoptix.net/en/ This topic came up last month and a lot of people recommended this vendor. Hope it helps. On 6/6/2015 10:45 AM, Frank Bulk wrote: > Thanks -- can you point me to any suppliers? > > Frank > > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: Saturday, June 06, 2015 12:41 PM > To: Frank Bulk > Cc: > Subject: Re: Tunable SFP > > They do exist. They tend to have tighter link budgets as compared to XFP > tunable optics. Don't expect to go as far due to the receiver sensitivity. > > Jared Mauch > >> On Jun 6, 2015, at 1:29 PM, Frank Bulk wrote: >> >> Anyone know if tunable SFPs exist? I've googled around on this, but only >> found fixed wave-length SFPs. >> >> Or of a tunable SFP+ that can operate in SFP port as 1G? >> >> Frank > > From frnkblk at iname.com Sat Jun 6 19:16:16 2015 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 6 Jun 2015 14:16:16 -0500 Subject: Tunable SFP In-Reply-To: <00b001d0a08b$edd10060$c9730120$@iname.com> References: <001601d0a07e$5e38d250$1aaa76f0$@iname.com> <56FAC265-3CE9-4917-9679-C0DD55CECEC6@puck.nether.net> <001c01d0a080$90512740$b0f375c0$@iname.com> <55733F85.4040000@aptient.com> <00b001d0a08b$edd10060$c9730120$@iname.com> Message-ID: <00b601d0a08d$42ddcf10$c8996d30$@iname.com> Upon second look, these are "reconfigurable". Doesn't appear to be the same as tunable. =( Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Frank Bulk Sent: Saturday, June 06, 2015 2:07 PM To: nanog at nanog.org Subject: RE: Tunable SFP Thanks, that's very helpful. They have several models there: https://www.flexoptix.net/en/produkte/transceiver.html?fo_tra_formfactor=sfp #fo_tra_formfactor=sfp&fo_tra_interface=05_dwdm_100ghz&gan_data=true Frank -----Original Message----- Sent: Saturday, June 06, 2015 1:44 PM To: Frank Bulk Subject: Re: Tunable SFP Check out https://www.flexoptix.net/en/ This topic came up last month and a lot of people recommended this vendor. Hope it helps. On 6/6/2015 10:45 AM, Frank Bulk wrote: > Thanks -- can you point me to any suppliers? > > Frank > > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: Saturday, June 06, 2015 12:41 PM > To: Frank Bulk > Cc: > Subject: Re: Tunable SFP > > They do exist. They tend to have tighter link budgets as compared to XFP > tunable optics. Don't expect to go as far due to the receiver sensitivity. > > Jared Mauch > >> On Jun 6, 2015, at 1:29 PM, Frank Bulk wrote: >> >> Anyone know if tunable SFPs exist? I've googled around on this, but only >> found fixed wave-length SFPs. >> >> Or of a tunable SFP+ that can operate in SFP port as 1G? >> >> Frank > > From eric at lumaoptics.net Sat Jun 6 22:38:41 2015 From: eric at lumaoptics.net (Eric Litvin) Date: Sat, 6 Jun 2015 15:38:41 -0700 Subject: Tunable SFP In-Reply-To: <00b601d0a08d$42ddcf10$c8996d30$@iname.com> References: <001601d0a07e$5e38d250$1aaa76f0$@iname.com> <56FAC265-3CE9-4917-9679-C0DD55CECEC6@puck.nether.net> <001c01d0a080$90512740$b0f375c0$@iname.com> <55733F85.4040000@aptient.com> <00b001d0a08b$edd10060$c9730120$@iname.com> <00b601d0a08d$42ddcf10$c8996d30$@iname.com> Message-ID: <123F81DF-A557-4A5F-A286-EF465829914F@lumaoptics.net> Hi Frank - we have DWDM SFP TUNABLES - stateside. They are both tunable and reconfigurable. Eric Litvin Luma Optics 650 996 7270 Sent from my iPhone > On Jun 6, 2015, at 12:16 PM, Frank Bulk wrote: > > Upon second look, these are "reconfigurable". Doesn't appear to be the same > as tunable. =( > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Frank Bulk > Sent: Saturday, June 06, 2015 2:07 PM > To: nanog at nanog.org > Subject: RE: Tunable SFP > > Thanks, that's very helpful. They have several models there: > https://www.flexoptix.net/en/produkte/transceiver.html?fo_tra_formfactor=sfp > #fo_tra_formfactor=sfp&fo_tra_interface=05_dwdm_100ghz&gan_data=true > > Frank > > -----Original Message----- > Sent: Saturday, June 06, 2015 1:44 PM > To: Frank Bulk > Subject: Re: Tunable SFP > > Check out https://www.flexoptix.net/en/ > > This topic came up last month and a lot of people recommended this > vendor. Hope it helps. > >> On 6/6/2015 10:45 AM, Frank Bulk wrote: >> Thanks -- can you point me to any suppliers? >> >> Frank >> >> -----Original Message----- >> From: Jared Mauch [mailto:jared at puck.nether.net] >> Sent: Saturday, June 06, 2015 12:41 PM >> To: Frank Bulk >> Cc: >> Subject: Re: Tunable SFP >> >> They do exist. They tend to have tighter link budgets as compared to XFP >> tunable optics. Don't expect to go as far due to the receiver sensitivity. >> >> Jared Mauch >> >>> On Jun 6, 2015, at 1:29 PM, Frank Bulk wrote: >>> >>> Anyone know if tunable SFPs exist? I've googled around on this, but only >>> found fixed wave-length SFPs. >>> >>> Or of a tunable SFP+ that can operate in SFP port as 1G? >>> >>> Frank > > > From sixsigma44 at hotmail.com Sat Jun 6 23:13:38 2015 From: sixsigma44 at hotmail.com (Ray) Date: Sat, 6 Jun 2015 19:13:38 -0400 Subject: Verizon FiOS outbound mail TLS problem - Superpages people here? In-Reply-To: <557080EB.30001@ispn.net> References: <22667917.183.1433434544723.JavaMail.root@benjamin.baylink.com>, <557080EB.30001@ispn.net> Message-ID: We had a similar issue around November last year where an upgrade on our PostFix MTA to a current version of OpenSSL, which has Mandatory TLS enabled for certain recipient domains, suddenly started generating the same errors with just one recipient domain. We eventually figured out that the problem was they were running an outdated version of the AsyncOS on their Cisco IronPorts. Firmware versions prior to 8.02 had several problems with TLS and one of them was an inability to interoperate with senders who used a newer version of OpenSSL. Their IronPort logs in fact showed a TLS connection was established when it wasn't. (We had switched them to Opportunistic TLS to be able to send emails but their logs still showed TLS while a PCAP showed clear text SMTP.) As soon as that company updated their IronPorts to a v8.5 variant the problem went away. They would not tell us what version they used to run but did confirm it was prior to v8.02. Interestingly, www.checktls.com said they were OK. The admins at Check TLS confirmed that, at that time (the end of 2014), they were running a version of OpenSSL on their website that was still compatible with the older AsyncOS version. FWIW, Ray > Date: Thu, 4 Jun 2015 11:46:35 -0500 > From: blake at ispn.net > To: nanog at nanog.org > Subject: Re: Verizon FiOS outbound mail TLS problem - Superpages people here? > > I have no relation, but as a mail server operator I can say that I > wouldn't be surprised if this is actually a TLS version mismatch or > intolerance problem. I would suggest ensuring that both ends support TLS > 1.0, 1.1, and 1.2 and use version tolerant TLS implementations. Next on > the short list would be not having compatible cyphers between the two > servers. > > Either way, since the error was a 403 error, the expected behavior would > be to queue and retry in plain text; Sounds like a broken MTA > implementation or misconfiguration if the sending servers do not revert > to plain text. > > --Blake > > Jay Ashworth wrote on 6/4/2015 11:15 AM: > > Anyone on the list who does outbound delivery for Verizon (which I think > > is actually Superpages)? A client has smart-hosted outbounds to *one* > > of his customers bouncing suddenly with > > > > Deferred: 403 4.7.0 TLS handshake failed. > > > > *My* inclination is to think that a cert expired somewhere, but his non-tech > > contact there tells him that the tech people think things are ok. > > > > I'm trying to get a mailer log fragment from them. > > > > Cheers, > > -- jra > > > From sixsigma44 at hotmail.com Sat Jun 6 23:20:20 2015 From: sixsigma44 at hotmail.com (Ray) Date: Sat, 6 Jun 2015 19:20:20 -0400 Subject: Verizon FiOS outbound mail TLS problem - Superpages people here? In-Reply-To: References: <22667917.183.1433434544723.JavaMail.root@benjamin.baylink.com>, , <557080EB.30001@ispn.net>, Message-ID: Oh, and the way we narrowed it down was somewhat oblique. Because their logs said a TLS connection was established we had a hard time convincing them it wasn't. They were convinced it was us who was broke. We had to send them a PCAP and then they ran one and got the same results. We were communicating via their IronPort "secure email" system and I noticed that the Cisco copyright notice on their messages was from 2012. That put me on the path to look at the Cisco release notes. Once I pointed out that they seemed to be a bit behind and there were fixes in later versions, the conversation went in a different direction. :-) > From: sixsigma44 at hotmail.com > To: blake at ispn.net; nanog at nanog.org > Subject: RE: Verizon FiOS outbound mail TLS problem - Superpages people here? > Date: Sat, 6 Jun 2015 19:13:38 -0400 > > We had a similar issue around November last year where an upgrade on our > PostFix MTA to a current version of OpenSSL, which has Mandatory TLS > enabled for certain recipient domains, suddenly started generating the > same errors with just one recipient domain. > > We eventually figured > out that the problem was they were running an outdated version of the > AsyncOS on their Cisco IronPorts. Firmware versions prior to 8.02 had > several problems with TLS and one of them was an inability to > interoperate with senders who used a newer version of OpenSSL. Their > IronPort logs in fact showed a TLS connection was established when it > wasn't. (We had switched them to Opportunistic TLS to be able to send > emails but their logs still showed TLS while a PCAP showed clear text > SMTP.) > > As soon as that company updated their IronPorts to a v8.5 > variant the problem went away. They would not tell us what version they > used to run but did confirm it was prior to v8.02. > > Interestingly, www.checktls.com > said they were OK. The admins at Check TLS confirmed that, at that time > (the end of 2014), they were running a version of OpenSSL on their > website that was still compatible with the older AsyncOS version. > > FWIW, > > Ray > > Date: Thu, 4 Jun 2015 11:46:35 -0500 > > From: blake at ispn.net > > To: nanog at nanog.org > > Subject: Re: Verizon FiOS outbound mail TLS problem - Superpages people here? > > > > I have no relation, but as a mail server operator I can say that I > > wouldn't be surprised if this is actually a TLS version mismatch or > > intolerance problem. I would suggest ensuring that both ends support TLS > > 1.0, 1.1, and 1.2 and use version tolerant TLS implementations. Next on > > the short list would be not having compatible cyphers between the two > > servers. > > > > Either way, since the error was a 403 error, the expected behavior would > > be to queue and retry in plain text; Sounds like a broken MTA > > implementation or misconfiguration if the sending servers do not revert > > to plain text. > > > > --Blake > > > > Jay Ashworth wrote on 6/4/2015 11:15 AM: > > > Anyone on the list who does outbound delivery for Verizon (which I think > > > is actually Superpages)? A client has smart-hosted outbounds to *one* > > > of his customers bouncing suddenly with > > > > > > Deferred: 403 4.7.0 TLS handshake failed. > > > > > > *My* inclination is to think that a cert expired somewhere, but his non-tech > > > contact there tells him that the tech people think things are ok. > > > > > > I'm trying to get a mailer log fragment from them. > > > > > > Cheers, > > > -- jra > > > > > > From randy_94108 at yahoo.com Sun Jun 7 00:47:58 2015 From: randy_94108 at yahoo.com (Randy) Date: Sun, 7 Jun 2015 00:47:58 +0000 (UTC) Subject: eBay is looking for network heavies... In-Reply-To: References: Message-ID: <1666262376.6430683.1433638078343.JavaMail.yahoo@mail.yahoo.com> $employers don't help in this regard either by requiring said certs. Such requirements; IMO, lead to folks preparing/passing such tests just for $day_job only without any real desire to understand how things-actually-work&why. ----- Original Message ----- From: John Fraizer To: ?ukasz Bromirski Cc: nanog at nanog.org Sent: Friday, June 5, 2015 5:55 PM Subject: Re: eBay is looking for network heavies... Folks, It's just a piece of paper in my opinion. A person either knows their stuff or they don't. Less than 5min on a phone screen and I will know if they "bought" their certification(s) or earned them. Sadly, I've spoken to far too many who give some validation to Jared's comment. I'm wondering how many proctors have been paid off or if people are buying fake id's for smart people and paying them to sit for the tests posing as them. John Fraizer --Sent from my Android phone. Please excuse any typos. On Jun 5, 2015 5:45 PM, "?ukasz Bromirski" wrote: > > > On 06 Jun 2015, at 02:26, Jared Mauch wrote: > > > > > >> On Jun 5, 2015, at 7:13 PM, John Fraizer wrote: > >> > >> Head of line for CCIE / JNCIE but knowledge and experience trumps a > piece > >> of paper every time! > > > > Can you please put these at the back of the line? My experience is that > > the cisco certification (at least) is evidence of the absence of actual > > troubleshooting skills. (or my standards of what defines ?expert? are > > different than the rest of the world). > > Jared, don?t generalize. > > True - there are people that are ?paper? CCIE/JNCIEs - but let?s not > start a rant unless you've met tens of CCIEs/JNCIEs and all of them > didn?t know a jack. About troubleshooting. > > ? > CCIE #15929 R&S/SP, CCDE #2012::17 > (not that I?d know anything about troubleshooting of course) From nanog at afxr.net Sun Jun 7 02:01:54 2015 From: nanog at afxr.net (Randy) Date: Sat, 06 Jun 2015 21:01:54 -0500 Subject: Digitalocean and recent issues Message-ID: <5573A612.7060000@afxr.net> Hello. I work with digitalocean "droplets" or virtual machines for my home business. While great for running cheap websites and server applications, I have noticed recently that I keep getting issues with my other VPN droplet I setup. Firstly, I kept getting blocked by google, it claims automated queries. I don't browse google too often.. Also had an issue with outbound mail on another droplet. Now I'm blocked by... Pizzahut.com Can't order a pizza over my VPN. One might think that there is some virus, but I assure you, there is not, Ive ran tcpdum captures and realtime captures for wireshark, I don't notice any other traffic other then the traffic I initiate by browsing, or doing a few search terms. And I've always paid for my pizza order! Is any one else experiencing issues like this? is there something I'm missing, I have no idea but the pizzahut thing has got me very irked. From john at op-sec.us Sun Jun 7 02:17:02 2015 From: john at op-sec.us (John Fraizer) Date: Sat, 6 Jun 2015 22:17:02 -0400 Subject: eBay is looking for network heavies... In-Reply-To: <1666262376.6430683.1433638078343.JavaMail.yahoo@mail.yahoo.com> References: <1666262376.6430683.1433638078343.JavaMail.yahoo@mail.yahoo.com> Message-ID: Just to be clear, CERTS are NOT a requirement for these positions. They will head-of-line someone for a phone screen. THAT IS ALL! And if you've got a cert, you had better know your stuff because if your cert says you're an EXPERT. I'm gonna expect you to be one! John Fraizer --Sent from my Android phone. Please excuse any typos. On Jun 6, 2015 5:50 PM, "Randy" wrote: > $employers don't help in this regard either by requiring said certs. Such > requirements; IMO, lead to folks preparing/passing such tests just for > $day_job only without any real desire to understand how > things-actually-work&why. > > > > ----- Original Message ----- > From: John Fraizer > To: ?ukasz Bromirski > Cc: nanog at nanog.org > Sent: Friday, June 5, 2015 5:55 PM > Subject: Re: eBay is looking for network heavies... > > Folks, > > It's just a piece of paper in my opinion. A person either knows their > stuff or they don't. Less than 5min on a phone screen and I will know if > they "bought" their certification(s) or earned them. Sadly, I've spoken to > far too many who give some validation to Jared's comment. I'm wondering how > many proctors have been paid off or if people are buying fake id's for > smart people and paying them to sit for the tests posing as them. > > John Fraizer > --Sent from my Android phone. > Please excuse any typos. > On Jun 5, 2015 5:45 PM, "?ukasz Bromirski" wrote: > > > > > > On 06 Jun 2015, at 02:26, Jared Mauch wrote: > > > > > > > > >> On Jun 5, 2015, at 7:13 PM, John Fraizer wrote: > > >> > > >> Head of line for CCIE / JNCIE but knowledge and experience trumps a > > piece > > >> of paper every time! > > > > > > Can you please put these at the back of the line? My experience is > that > > > the cisco certification (at least) is evidence of the absence of actual > > > troubleshooting skills. (or my standards of what defines ?expert? are > > > different than the rest of the world). > > > > Jared, don?t generalize. > > > > True - there are people that are ?paper? CCIE/JNCIEs - but let?s not > > start a rant unless you've met tens of CCIEs/JNCIEs and all of them > > didn?t know a jack. About troubleshooting. > > > > ? > > CCIE #15929 R&S/SP, CCDE #2012::17 > > (not that I?d know anything about troubleshooting of course) > From list at satchell.net Sun Jun 7 02:23:57 2015 From: list at satchell.net (Stephen Satchell) Date: Sat, 06 Jun 2015 19:23:57 -0700 Subject: eBay is looking for network heavies... In-Reply-To: References: <1666262376.6430683.1433638078343.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5573AB3D.4080302@satchell.net> On 06/06/2015 07:17 PM, John Fraizer wrote: > And if you've > got a cert, you had better know your stuff because if your cert says you're > an EXPERT. I'm gonna expect you to be one! X -- math quantity denoting the unknown SPURT -- drip of water under pressure X-SPURT -- unknown drip under pressure From larrysheldon at cox.net Sun Jun 7 02:25:22 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Sat, 06 Jun 2015 21:25:22 -0500 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> Message-ID: <5573AB92.2010207@cox.net> On 6/5/2015 23:35, Faisal Imtiaz wrote: > 'pathping' ..... learned something new today... Did not know such a > command existed in windows.. > > Been working with computers for over 30 years, while I don't care as > to what it says about how much I know, but it sure reminds me that > that their is always something more that one can learn ! > > > Thank You. > > :) +1 Amazing. -- sed quis custodiet ipsos custodes? (Juvenal) From techzone at greeleynet.com Sun Jun 7 03:26:18 2015 From: techzone at greeleynet.com (F.L. Whiteley) Date: Sat, 6 Jun 2015 21:26:18 -0600 Subject: eBay is looking for network heavies... In-Reply-To: <5573AB92.2010207@cox.net> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <5573AB92.2010207@cox.net> Message-ID: <006a01d0a0d1$b8484f20$28d8ed60$@greeleynet.com> Kind of a cack-handed way of doing MTR, but surprising to find that it's been around since NT. New option for some of the troubleshooting from client boxen. Guess you had to buy into some of that MS certification stuff. Gee, I'll have to ask Davis and Brian if it was in one of their Windows Secrets books;^) Frank Whiteley -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Larry Sheldon Sent: Saturday, June 06, 2015 8:25 PM To: nanog at nanog.org Subject: Re: eBay is looking for network heavies... On 6/5/2015 23:35, Faisal Imtiaz wrote: > 'pathping' ..... learned something new today... Did not know such a > command existed in windows.. > > Been working with computers for over 30 years, while I don't care as > to what it says about how much I know, but it sure reminds me that > that their is always something more that one can learn ! > > > Thank You. > > :) +1 Amazing. -- sed quis custodiet ipsos custodes? (Juvenal) From akumar at anilkumar.com Sun Jun 7 03:33:33 2015 From: akumar at anilkumar.com (Anil Kumar) Date: Sun, 7 Jun 2015 09:03:33 +0530 Subject: Digitalocean and recent issues In-Reply-To: <5573A612.7060000@afxr.net> References: <5573A612.7060000@afxr.net> Message-ID: <001395B1-3AFB-45A6-A666-448C8C9992C7@anilkumar.com> > On Jun 7, 2015, at 7:31 AM, Randy wrote: > > Firstly, I kept getting blocked by google, it claims automated queries. I don't browse google too often.. > Also had an issue with outbound mail on another droplet. > Now I'm blocked by... Pizzahut.com > > Is any one else experiencing issues like this? is there something I'm missing. > There is probably a lot of abuse of IP addresses at Digital Ocean, $5 per month and an API is a magnet for that to happen. I also see droplets rebooting "due to an issue on the underlying physical node where the Droplet runs?. This happened a few times each on 3 different droplets during the last 45 days (all at NY DC). AK From bmanning at karoshi.com Sun Jun 7 03:57:38 2015 From: bmanning at karoshi.com (manning) Date: Sat, 6 Jun 2015 20:57:38 -0700 Subject: eBay is looking for network heavies... In-Reply-To: References: <1666262376.6430683.1433638078343.JavaMail.yahoo@mail.yahoo.com> Message-ID: <06C1078F-A86C-4C78-9D97-C661CE6DA947@karoshi.com> i?ll never make it past the telephone screen?. manning bmanning at karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 6June2015Saturday, at 19:17, John Fraizer wrote: > Just to be clear, CERTS are NOT a requirement for these positions. They > will head-of-line someone for a phone screen. THAT IS ALL! And if you've > got a cert, you had better know your stuff because if your cert says you're > an EXPERT. I'm gonna expect you to be one! > > John Fraizer > --Sent from my Android phone. > Please excuse any typos. > On Jun 6, 2015 5:50 PM, "Randy" wrote: > >> $employers don't help in this regard either by requiring said certs. Such >> requirements; IMO, lead to folks preparing/passing such tests just for >> $day_job only without any real desire to understand how >> things-actually-work&why. >> >> >> >> ----- Original Message ----- >> From: John Fraizer >> To: ?ukasz Bromirski >> Cc: nanog at nanog.org >> Sent: Friday, June 5, 2015 5:55 PM >> Subject: Re: eBay is looking for network heavies... >> >> Folks, >> >> It's just a piece of paper in my opinion. A person either knows their >> stuff or they don't. Less than 5min on a phone screen and I will know if >> they "bought" their certification(s) or earned them. Sadly, I've spoken to >> far too many who give some validation to Jared's comment. I'm wondering how >> many proctors have been paid off or if people are buying fake id's for >> smart people and paying them to sit for the tests posing as them. >> >> John Fraizer >> --Sent from my Android phone. >> Please excuse any typos. >> On Jun 5, 2015 5:45 PM, "?ukasz Bromirski" wrote: >> >>> >>>> On 06 Jun 2015, at 02:26, Jared Mauch wrote: >>>> >>>> >>>>> On Jun 5, 2015, at 7:13 PM, John Fraizer wrote: >>>>> >>>>> Head of line for CCIE / JNCIE but knowledge and experience trumps a >>> piece >>>>> of paper every time! >>>> >>>> Can you please put these at the back of the line? My experience is >> that >>>> the cisco certification (at least) is evidence of the absence of actual >>>> troubleshooting skills. (or my standards of what defines ?expert? are >>>> different than the rest of the world). >>> >>> Jared, don?t generalize. >>> >>> True - there are people that are ?paper? CCIE/JNCIEs - but let?s not >>> start a rant unless you've met tens of CCIEs/JNCIEs and all of them >>> didn?t know a jack. About troubleshooting. >>> >>> ? >>> CCIE #15929 R&S/SP, CCDE #2012::17 >>> (not that I?d know anything about troubleshooting of course) >> From darqchild at darqchild.com Fri Jun 5 23:49:05 2015 From: darqchild at darqchild.com (Meagan) Date: Fri, 5 Jun 2015 19:49:05 -0400 Subject: stacking pdu In-Reply-To: References: <86k2vj16r3.fsf@valhalla.seastrom.com> Message-ID: Server tech makes some devices that are powered independently but can be managed as a single unit. We have 2pdus per cabinet on separate circuits, which share a management controller and can provide stats for both circuits. > On Jun 5, 2015, at 12:51 AM, shawn wilson wrote: > > Well, I was kinda thinking this would turn out to be a dumb question / have > an obvious answer. Apparently not. But it seems I can't go buy a solution > either. I guess there isn't much of a market (though I am just talking > software - maybe someone could make an update :) ). > > !DSPAM:55712b43141331257586274! > From phil.daws at innovot.com Sat Jun 6 13:41:48 2015 From: phil.daws at innovot.com (Phil Daws) Date: Sat, 6 Jun 2015 14:41:48 +0100 (BST) Subject: Issue with cache @ 198.6.100.25 (UUNET) Message-ID: <1695667056.979058.1433598108557.JavaMail.zimbra@innovot.com> Hello: Hopefully somebody may be able to help us ? Our domain appears to be having issue at 198.6.100.25 and showing the following: innovot.com. 120 IN MX 10 domain.not.configured. Yet when I dig @8.8.8.8 or @8.8.4.4 all works absolutely fine. Our secondaries are all with DNS Made Easy and we did switch from GoDaddy to FastHosts as the registrar. Would somebody be able to flush the cache on the domain please ? Thank you in advance. -- Phil Daws (null) From larrysheldon at cox.net Sun Jun 7 04:47:34 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Sat, 06 Jun 2015 23:47:34 -0500 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> Message-ID: <5573CCE6.10203@cox.net> On 6/6/2015 05:43, shawn wilson wrote: > My first thought on reading that was "who the hell cares if a person > knows about internet culture". But than I had to reconsider - it's a > very apt way of telling if someone read the right books :) > > I would also add Ritchie, Thompson, and Diffie to that list (since you > ask about Larry, it's only appropriate). I find it interesting that I have not note a mention of people like Radia Pearlman and [name advancing years have stolen from me] that wrote a 3 volume set (I think it was) (that I can not find in the post-great-downsizing-bookshelves-disarray at the moment*). *did a little Binging--Not W. Richard Stevens although the subconscious thinks "steven" might have been the first name. NO! Douglas E. Comer "Internetworking with TCP/IP" (Nice try subconscious! Volume 3 is co-authored by David L. Stevens.) -- sed quis custodiet ipsos custodes? (Juvenal) From morrowc.lists at gmail.com Sun Jun 7 05:11:50 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 7 Jun 2015 01:11:50 -0400 Subject: Issue with cache @ 198.6.100.25 (UUNET) In-Reply-To: <1695667056.979058.1433598108557.JavaMail.zimbra@innovot.com> References: <1695667056.979058.1433598108557.JavaMail.zimbra@innovot.com> Message-ID: ;; QUESTION SECTION: ;innovot.com. IN MX ;; ANSWER SECTION: innovot.com. 85061 IN MX 10 zmx01.gos.innovot.com. innovot.com. 85061 IN MX 20 zmx01.mah.innovot.com. ;; Query time: 47 msec ;; SERVER: 198.6.100.25#53(198.6.100.25) seems fixed now though. On Sat, Jun 6, 2015 at 9:41 AM, Phil Daws wrote: > Hello: > > Hopefully somebody may be able to help us ? Our domain appears to be having issue at 198.6.100.25 and showing the following: > > innovot.com. 120 IN MX 10 domain.not.configured. > > Yet when I dig @8.8.8.8 or @8.8.4.4 all works absolutely fine. Our secondaries are all with DNS Made Easy and we did switch from GoDaddy to FastHosts as the registrar. Would somebody be able to flush the cache on the domain please ? > > Thank you in advance. > -- > Phil Daws > > (null) From nasser at rasana.net Sun Jun 7 06:19:40 2015 From: nasser at rasana.net (Nasser Heidari) Date: Sun, 7 Jun 2015 10:49:40 +0430 Subject: PPPoE/IPoE, any recommendations for upgrade? Message-ID: <002a01d0a0e9$f04481b0$d0cd8510$@rasana.net> Hi, We are currently using PPPoE in our network. I have seen some articles regarding migration of so-called legacy PPPoE to IPoE. After reviewing some of them and implementing IPoE in lab environment using Cisco ASR I didn't fine it that much beneficial to migrate whole system as I need to change a lot of things. For example: - I need to add it's support to our radius and obviously BSS system (E.g. using NAS-PORT-ID instead of username). - For the addressing part, as I have already using distributed BNG's, I need to change some of our policies. (For example assigning address blocks is much easier in PPPoE using framed-route) - I need to change our customers CPE configuration to use Ethernet encapsulation. - I haven't used DHCP in large scale environment. - I don't have any clear Idea/understanding regarding its maintainability/troubleshooting and also security. (Please add if I'm missing any other issue which may run into if I migrate to IPoE) Although it has some benefits, I'm not sure if it's that essential to migrate. Would you please kindly? - Share your Ideas/experiences/best practices in this regard? - If you are already using IPoE, tell more why should I upgrade? - Considering a DSL network with more than 800K customers using PPPoE, do you recommend this migration? Kind Regards, Nasser From stefan at fetaste.com Sun Jun 7 07:19:24 2015 From: stefan at fetaste.com (Stefan Larsson) Date: Sun, 7 Jun 2015 09:19:24 +0200 Subject: Digitalocean and recent issues In-Reply-To: <5573A612.7060000@afxr.net> References: <5573A612.7060000@afxr.net> Message-ID: On Sunday, June 7, 2015, Randy wrote: > > Now I'm blocked by... Pizzahut.com > Can't order a pizza over my VPN. thank god for comic relief. - s From mkaipov at outlook.com Sun Jun 7 07:38:23 2015 From: mkaipov at outlook.com (Murat Kaipov) Date: Sun, 7 Jun 2015 10:38:23 +0300 Subject: PPPoE/IPoE, any recommendations for upgrade? Message-ID: Hello Nasser. We use IPoE in our small ISP. But in my case we use DHCP option 82 and IP address as username for authentication and accounting purposes. As BRAS we configure Cisco ISG. ?????????? ? ?????????? Samsung -------- ???????? ????????? -------- ??: Nasser Heidari ????: 07.06.2015 9:46 (GMT+03:00) ????: nanog at nanog.org ????: PPPoE/IPoE, any recommendations for upgrade? Hi, We are currently using PPPoE in our network. I have seen some articles regarding migration of so-called legacy PPPoE to IPoE. After reviewing some of them and implementing IPoE in lab environment using Cisco ASR I didn't fine it that much beneficial to migrate whole system as I need to change a lot of things. For example: - I need to add it's support to our radius and obviously BSS system (E.g. using NAS-PORT-ID instead of username). - For the addressing part, as I have already using distributed BNG's, I need to change some of our policies. (For example assigning address blocks is much easier in PPPoE using framed-route) - I need to change our customers CPE configuration to use Ethernet encapsulation. - I haven't used DHCP in large scale environment. - I don't have any clear Idea/understanding regarding its maintainability/troubleshooting and also security. (Please add if I'm missing any other issue which may run into if I migrate to IPoE) Although it has some benefits, I'm not sure if it's that essential to migrate. Would you please kindly? - Share your Ideas/experiences/best practices in this regard? - If you are already using IPoE, tell more why should I upgrade? - Considering a DSL network with more than 800K customers using PPPoE, do you recommend this migration? Kind Regards, Nasser From joshua.riesenweber at outlook.com Sun Jun 7 08:10:09 2015 From: joshua.riesenweber at outlook.com (Joshua Riesenweber) Date: Sun, 7 Jun 2015 18:10:09 +1000 Subject: eBay is looking for network heavies... In-Reply-To: <5573CCE6.10203@cox.net> References: , <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net>, <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net>, <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org>, , <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com>, <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net>, , , , <5573CCE6.10203@cox.net> Message-ID: As someone studying their first CCIE (RS), I sometimes find these kind of discussions disheartening. They come up every now and again, and the opinions seem vary anywhere between 'a good interview tool' and 'less than worthless'. It took me a long time to get started in certifications once I began working in IT, because I questioned why I needed a piece of paper to prove what I knew.After I've started, I realised that following a certification track isn't perfect, but it gives (at least to me) the structure to cover areas of knowledge that you might not if you were doing 100% on the job training or some other methods. It gives you something to aim for, and helps with motivation and setting goals. Does a certification mean that you are an expert? No. Does it mean you are devoid of skill? No. All it means is that the person has studied the curriculum, and passed the tests.No more, no less. Now from what I understand of the CCIE lab exam (which I haven't attempted yet), it is a practical exam and you need to know your stuff to pass. I'm sure people think up ways to cheat and devalue it, that's bound to happen. I've sat on both sides of the interview table, and I've had plenty of both certified an uncertified people come through that don't know their stuff.I've also had plenty of both certified and uncertified people who have been great. When I see someone who has a certification, and they can follow it up with actual skills, it indicates they have a certain level of dedication to improving themselves and their education. (In my experience it takes more time to study a certification track than to learn just what you need to get a job done.) Just my 2c... Cheers,Josh From Thomas.Weible at flexoptix.net Sun Jun 7 09:20:35 2015 From: Thomas.Weible at flexoptix.net (Thomas Weible - FLEXOPTIX) Date: Sun, 7 Jun 2015 09:20:35 +0000 Subject: Tunable SFP In-Reply-To: <00b601d0a08d$42ddcf10$c8996d30$@iname.com> References: <001601d0a07e$5e38d250$1aaa76f0$@iname.com> <00b601d0a08d$42ddcf10$c8996d30$@iname.com> Message-ID: Hi Frank, > Frank wrote: > Upon second look, these are "reconfigurable". Doesn't appear to be the >same > as tunable. =( These tuneables have three features: 1. Tune 80-DWDM-channels in the 50 / 100 GHz grid -> You can change the wavelength of the SFP+ 2. Reconfigurable -> configure these SFP+ to operate in your used host system today. Reconfigure these SFP+ to operate in a different host tomorrow. 3. Combining 1. + 2. -> You can use these tunable SFP+ also in hosts which do not support wavelength tuning - in this scenario wavelength tuning is done externally via flexbox. The tunable SFP+ acts like a fixed DWDM SFP+ in your host (or even regular SFP+ ZR if there is no support for fixed DWDM SFP+) but the physics is still a full tunable DWDM SFP+ > Jared wrote: > They do exist. They tend to have tighter link budgets as compared to XFP > tunable optics. Don't expect to go as far due to the receiver >sensitivity. One comment regarding the receiver sensitivity. For both (XFP and SFP+ tunable) it is -24dBm because for both formfactors the same APD receiver is used. Thanks Thomas > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Frank Bulk >Sent: Saturday, June 06, 2015 2:07 PM >To: nanog at nanog.org >Subject: RE: Tunable SFP > >Thanks, that's very helpful. They have several models there: >https://www.flexoptix.net/en/produkte/transceiver.html?fo_tra_formfactor=s >fp >#fo_tra_formfactor=sfp&fo_tra_interface=05_dwdm_100ghz&gan_data=true > >Frank > >-----Original Message----- >Sent: Saturday, June 06, 2015 1:44 PM >To: Frank Bulk >Subject: Re: Tunable SFP > >Check out https://www.flexoptix.net/en/ > >This topic came up last month and a lot of people recommended this >vendor. Hope it helps. > >On 6/6/2015 10:45 AM, Frank Bulk wrote: >> Thanks -- can you point me to any suppliers? >> >> Frank >> >> -----Original Message----- >> From: Jared Mauch [mailto:jared at puck.nether.net] >> Sent: Saturday, June 06, 2015 12:41 PM >> To: Frank Bulk >> Cc: >> Subject: Re: Tunable SFP >> >> They do exist. They tend to have tighter link budgets as compared to XFP >> tunable optics. Don't expect to go as far due to the receiver >>sensitivity. >> >> Jared Mauch >> >>> On Jun 6, 2015, at 1:29 PM, Frank Bulk wrote: >>> >>> Anyone know if tunable SFPs exist? I've googled around on this, but >>>only >>> found fixed wave-length SFPs. >>> >>> Or of a tunable SFP+ that can operate in SFP port as 1G? >>> >>> Frank >> >> > > > > > From swmike at swm.pp.se Sun Jun 7 09:33:25 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 7 Jun 2015 11:33:25 +0200 (CEST) Subject: PPPoE/IPoE, any recommendations for upgrade? In-Reply-To: <002a01d0a0e9$f04481b0$d0cd8510$@rasana.net> References: <002a01d0a0e9$f04481b0$d0cd8510$@rasana.net> Message-ID: On Sun, 7 Jun 2015, Nasser Heidari wrote: > - If you are already using IPoE, tell more why should I upgrade? The IPoE and IPoEoADSL I have done didn't need radius, didn't need BNG, didn't need a lot of the complications you're talking about. It could basically be realised in any decent L3 switch as default gateway for the customers instead of needing BNG. So I'd say if you want to get full potential of IPoE you need to do simplification as well, otherwise there is little use in doing the work if he only thing you want to change is from IPoPPPoE to IPoE encapsulation and keep all the other stuff you're doing. IPoPPPoE requires special CPE and router at your end to achieve high speeds, because they need to support encapsulation/decapsulation of packets at whatever speed you provide. The number of devices that do this is a lot smaller than the ones that do decent speeds with just IPoE. So some people will say migrating to IPoE from IPoPPPoE buys them nothing, because they feel they need all the mechanisms they currently use. Greenfield deployments might say "hey, we can do this without a lot of the needed mechanisms for IPoPPPoE" and save a lot of money and complication. -- Mikael Abrahamsson email: swmike at swm.pp.se From baldur.norddahl at gmail.com Sun Jun 7 09:37:41 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 7 Jun 2015 11:37:41 +0200 Subject: Tunable SFP In-Reply-To: References: <001601d0a07e$5e38d250$1aaa76f0$@iname.com> <00b601d0a08d$42ddcf10$c8996d30$@iname.com> Message-ID: Hi, I believe nobody actually answered the original question: is there any tunable SFP module available. Notice the lack of a + in that statement. The datasheets for modules cited in this thread are all 10G modules with minimum speed of 8.5G. Nothing that will work at 1G. But correct me if I am wrong, the real reason this is not available is because tunable optics is so extremely expensive. It is expensive for 10G and would be insane for a 1G link. When will I be able to buy tunable optics with only a modest price premium? I would love to stock tunables... but it is just so expensive that it is much cheaper to have spare parts for many different wavelengths lying around. Only organisations where money is unlimited can afford to use this stuff just for the convenience! Regards, Baldur From ag4ve.us at gmail.com Sun Jun 7 12:06:13 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 7 Jun 2015 08:06:13 -0400 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> <5573CCE6.10203@cox.net> Message-ID: On Jun 7, 2015 4:12 AM, "Joshua Riesenweber" wrote: > > (In my experience it takes more time to study a certification track than to learn just what you need to get a job done.) > Stated different, no job is going to teach you how to pass a cert. And no cert is going to teach a job. One can help with the other, but different skills are involved. From list at satchell.net Sun Jun 7 12:28:18 2015 From: list at satchell.net (Stephen Satchell) Date: Sun, 07 Jun 2015 05:28:18 -0700 Subject: eBay is looking for network heavies... In-Reply-To: References: , <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net>, <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net>, <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org>, , <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com>, <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net>, , , , <5573CCE6.10203@cox.net> Message-ID: <557438E2.7010505@satchell.net> On 06/07/2015 01:10 AM, Joshua Riesenweber wrote: > Now from what I understand of the CCIE lab exam (which I haven't > attempted yet), it is a practical exam and you need to know your > stuff to pass. I'm sure people think up ways to cheat and devalue it, > that's bound to happen. I've sat on both sides of the interview > table, and I've had plenty of both certified an uncertified people > come through that don't know their stuff.I've also had plenty of both > certified and uncertified people who have been great. When I see > someone who has a certification, and they can follow it up with > actual skills, it indicates they have a certain level of dedication > to improving themselves and their education. (In my experience it > takes more time to study a certification track than to learn just > what you need to get a job done.) The R&S CCIE lab exame is a timed practical exam, and as certification tests goes it does a fair job measuring the ability of the candidate to implement routers and switches to obtain certain results, ON CISCO EQUIPMENT. (This is also true of the other Cisco certification tracks.) The companies that sell preparation services coach the customers and provide hands-on instruction on how to streamline the prep for the actual setting up of the equipment -- that pesky time limit. (By the way, don't get me started on CompTIA. I used to belong to that organization. Talk about sausage being made...) One can learn how to do almost anything. The real trick is being able to finish tasks quickly, and that's damn hard to do without practice, practice, practice. Also, how to approach understanding the lab exercises so you *can* finish each task quickly and demonstrability correctly (taking into consideration automated grading of your work, by the way) is a big part of it. That said, certifications show that the candidate can turn a wrench. It shows nothing about the candidate's ability to handle ARIN, to troubleshoot political snafus, how to deal with management that is severely clue-deficient, and most important play nice with colleagues at other network operator centers. Not to mention one's own customers, and even sometimes co-workers. And all the other (arguably) non-technical parts of being a member of a network operations team. From alter3d at alter3d.ca Sun Jun 7 15:57:03 2015 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Sun, 07 Jun 2015 11:57:03 -0400 Subject: eBay is looking for network heavies... In-Reply-To: References: , <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net>, <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net>, <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org>, , <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com>, <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net>, , , , <5573CCE6.10203@cox.net> Message-ID: <557469CF.5080108@alter3d.ca> On 6/7/2015 4:10 AM, Joshua Riesenweber wrote: > As someone studying their first CCIE (RS), I sometimes find these kind of discussions disheartening. They come up every now and again, and the opinions seem vary anywhere between 'a good interview tool' and 'less than worthless'. A certification is like anything else a person puts on their resume -- I assume its value is overstated and follow the "trust, but verify" protocol. I expect candidates to have the same body of knowledge regardless of whether or not they're certified -- I need them to do a job, and that job requires certain skills. If getting that piece of paper taught you those skills -- great, though very unlikely. If you acquired the skills without the paper, also great. Generally I find that candidates with no/few certs are the more well-rounded (real-life experience + practical knowledge) candidates. The School of Hard Knocks is a great institution of learning. > following a certification track isn't perfect, but it gives (at least to me) the structure to cover areas of knowledge that you might not if you were doing 100% on the job training or some other methods. It gives you something to aim for, and helps with motivation and setting goals. In many ways, certification tracks are something like getting a PhD. Completely useless information (and very few skills) to anything you'll do in the "real world", but if it makes your clock tick, go for it. Just don't expect me to be impressed when I'm interviewing you, because it has no direct relationship with your ability to do this job. As a personal growth tool -- great. As a professional growth tool -- meh. > When I see someone who has a certification, and they can follow it up with actual skills, it indicates they have a certain level of dedication to improving themselves and their education. (In my experience it takes more time to study a certification track than to learn just what you need to get a job done.) My favourite question to ask candidates during an interview is "Tell me about a cool technology project you've done outside of work." I don't even really care what the answer is, it's more about "do they get revved up while they're talking about it?" If they fire up to 110% and get super excited to tell you about the super-awesome $THING they built/coded/hacked, it bodes well for their motivation about all things tech, including learning about it. The "geek" type, if you will. If they shrivel up and say "I dunno... Uhh... I installed Exchange once." then I know all I need to know about their dedication to improving their knowledge & skills. They're here for a day job and really aren't passionate about technology. I often ask this question early in the interview process -- I find it helps the really-awesome-but-with-poor-interview-skills geeks to relax and do well with the rest of the interview, and it it provides me with a pretty damned reliable barometer reading of the candidate from the get-go. From swm at emanon.com Sun Jun 7 16:11:44 2015 From: swm at emanon.com (Scott Morris) Date: Sun, 7 Jun 2015 12:11:44 -0400 Subject: eBay is looking for network heavies... In-Reply-To: <557438E2.7010505@satchell.net> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> <5573CCE6.10203@cox.net> <557438E2.7010505@satchell.net> Message-ID: Shop class can also teach you how to turn a wrench. How many people out of that area go on to be the best mechanics you?ve ever seen? Some do, some don?t. Certifications aren?t any different. They are around to establish a benchmark of minimally qualified knowledge. We all should know the difference between hands-on and multiple-choice things. ANY knowledge is useless unless you know how to actually use it. Looking at your previous post about all the Layer1 things actually made me smile. But that was based on my experience, not something an IE exam taught me. (You were the first person I have ever heard refer to the 30cm with ethernet in the almost 30 years I?ve been doing cabling stuff. I loved it!) We all should know the specifics of what is (or more importantly IS NOT) being tested on in the various exams. And ask questions accordingly. While I?m happy that someone could spout off particular names and their functional contributions to the world, it likewise does not have any indication about someone?s ability to actually program Perl or configure/use/whatever to BIND. Quit bitching about the certifications and simply make your interviews appropriate to what you want to know that a candidate can actually DO on the job. Certs or no certs, there are people who know things and people who do not. If you discount people simply because they have a certification, then you are missing out IMHO. But I guess take that as you will since I have several of these certifications. :) Scott -----Original Message----- From: Stephen Satchell Date: Sunday, June 7, 2015 at 8:28 AM To: , "nanog at nanog.org" Subject: Re: eBay is looking for network heavies... >That said, certifications show that the candidate can turn a wrench. It >shows nothing about the candidate's ability to handle ARIN, to >troubleshoot political snafus, how to deal with management that is >severely clue-deficient, and most important play nice with colleagues at >other network operator centers. Not to mention one's own customers, and >even sometimes co-workers. And all the other (arguably) non-technical >parts of being a member of a network operations team. From randy at psg.com Sun Jun 7 16:28:17 2015 From: randy at psg.com (Randy Bush) Date: Sun, 07 Jun 2015 09:28:17 -0700 Subject: certification (was: eBay is looking for network heavies...) In-Reply-To: <557469CF.5080108@alter3d.ca> References: Message-ID: i assume, but have zero actual knowledge/experience, that certification courses/programs actually cover all the corners and minutiae of a subject such as is-is. so you come out knowing all the options and details, 42% of which you will use; or maybe 24% if you are parsimonious. while i no longer have spare room in my head for a lot of stuff i will not use, having some clue about what's outside my current practice zone would be useful. if i was young and had spare brain cells and time, i might read through the course ware and do some playing in the lab. but you can't move packets on pieces of paper. From eugen at imacandi.net Sun Jun 7 16:42:53 2015 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sun, 7 Jun 2015 19:42:53 +0300 Subject: eBay is looking for network heavies... In-Reply-To: <557469CF.5080108@alter3d.ca> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> <5573CCE6.10203@cox.net> <557469CF.5080108@alter3d.ca> Message-ID: On Sun, Jun 7, 2015 at 6:57 PM, Peter Kristolaitis wrote: > In many ways, certification tracks are something like getting a PhD. > Completely useless information (and very few skills) to anything you'll do > in the "real world", but if it makes your clock tick, go for it. Just > don't expect me to be impressed when I'm interviewing you, because it has > no direct relationship with your ability to do this job. > > Certs are a good way to get selected by the HR people and have your CV forwarded to the people that will actually do the interviewing part. Some companies actually put out job listings with required mandatory certifications so from their point of view, you only qualify if you have a piece of paper saying that you know X,Y,Z. > My favourite question to ask candidates during an interview is "Tell me > about a cool technology project you've done outside of work." I don't > even really care what the answer is, it's more about "do they get revved up > while they're talking about it?" > Cool idea, never thought of this type of questions when gauging peoples interest in motivation and the desire to learn. Eugeniu From lathama at gmail.com Sun Jun 7 16:50:11 2015 From: lathama at gmail.com (Andrew Latham) Date: Sun, 7 Jun 2015 11:50:11 -0500 Subject: certification (was: eBay is looking for network heavies...) In-Reply-To: References: <557469CF.5080108@alter3d.ca> Message-ID: On Sun, Jun 7, 2015 at 11:28 AM, Randy Bush wrote: > i assume, but have zero actual knowledge/experience, that certification > courses/programs actually cover all the corners and minutiae of a subject > such as is-is. so you come out knowing all the options and details, 42% > of which you will use; or maybe 24% if you are parsimonious. > > while i no longer have spare room in my head for a lot of stuff i will > not use, having some clue about what's outside my current practice zone > would be useful. if i was young and had spare brain cells and time, i > might read through the course ware and do some playing in the lab. but > you can't move packets on pieces of paper. > Normally a lurker, I agree. I feel that most of us fall into some range below. - New Build-out / Startupish: All that cool stuff and proper tech is the go forward until the money runs out. - ENTERPRISE: PHB demands you use vendor X and solution Y for no technical reason. - Mom-Pop / Third World / NPO: Do what we can with what we have. - Out Sourcing Vendor Manager: juggling so many vendors doing different things. - IXP: What ever can support the legacy and current tech in a safe way. - Add your own. Certificates are a fun topic. I think if a 17 year old wanted to prove their technical knowledge a certificate would be a good method. Certificates are also looked at as "structure" the same way a degree might be by hiring managers (don't really know how I feel on this). I think Randy touched on a good topic of how do the established people take time to pull in some related knowledge that is not part of their normal roll at this time. Learning ahead of time vs implementing on demand. All in all, silly questions like "describe traceroute" show real world knowledge and communication skill. The later may be more useful at times. -- ~ Andrew "lathama" Latham ~ From aaron at heyaaron.com Sun Jun 7 17:14:17 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Sun, 7 Jun 2015 10:14:17 -0700 Subject: Should I Reboot, and Why? (was Re: [RDD] No Play out on Cart Wall) In-Reply-To: References: <201505311603.06311.curt@cwf1.com> <1405179.191.1433437029515.JavaMail.root@benjamin.baylink.com> Message-ID: > I also reboot for kernel updates! Someone needs to make a bumper sticker... -A From list at satchell.net Sun Jun 7 17:32:35 2015 From: list at satchell.net (Stephen Satchell) Date: Sun, 07 Jun 2015 10:32:35 -0700 Subject: certification In-Reply-To: References: Message-ID: <55748033.5010002@satchell.net> On 06/07/2015 09:28 AM, Randy Bush wrote: > i assume, but have zero actual knowledge/experience, that certification > courses/programs actually cover all the corners and minutiae of a subject > such as is-is. so you come out knowing all the options and details, 42% > of which you will use; or maybe 24% if you are parsimonious. > > while i no longer have spare room in my head for a lot of stuff i will > not use, having some clue about what's outside my current practice zone > would be useful. if i was young and had spare brain cells and time, i > might read through the course ware and do some playing in the lab. but > you can't move packets on pieces of paper. Putting on my "professor's kid" hat: Education is *supposed* to be about learning how to find answers when you need them. How to understand what you find. Yes, there are a number of basic things you need to do "by rote" and from memory (especially "muscle memory"), but when you run into the one-percent cases, you need to know where to look and how to apply what your search turns up. "[I do not] carry such information in my mind since it is readily available in books. ...The value of a college education is not the learning of many facts but the training of the mind to think." -- Albert Einstein From tony at wicks.co.nz Sun Jun 7 21:15:23 2015 From: tony at wicks.co.nz (Tony Wicks) Date: Mon, 8 Jun 2015 09:15:23 +1200 Subject: Tunable SFP In-Reply-To: References: <001601d0a07e$5e38d250$1aaa76f0$@iname.com> <00b601d0a08d$42ddcf10$c8996d30$@iname.com> Message-ID: <004101d0a167$11f1d830$35d58890$@wicks.co.nz> I don't quite see why you would want to use a tuneable 1G optic now days. Generally people use coloured optics to either increase the capacity they can push down a Dark Fibre or to interconnect with a DWDM OTN. In days past using different wavelengths for traffic separation would be not unheard of but in today's world there are many better ways of doing that. The use of tuneable optics reduces sparing and complexity but it is a very difficult and expensive manufacturing task and I can understand why no manufacturer would bother with 1G as that seems like a very small market. If you really want 1G there are plenty of CWDM fixed optics available. If you need more capacity, well really 10G is not at all expensive now days. If you want traffic separation then use MPLS. If you have old 1G only switches, well, you know the answer to that. My 2c -----Original Message----- Hi, I believe nobody actually answered the original question: is there any tunable SFP module available. Notice the lack of a + in that statement. The datasheets for modules cited in this thread are all 10G modules with minimum speed of 8.5G. Nothing that will work at 1G. From eric at lumaoptics.net Sun Jun 7 22:21:47 2015 From: eric at lumaoptics.net (Eric Litvin) Date: Sun, 7 Jun 2015 15:21:47 -0700 Subject: Tunable SFP In-Reply-To: <004101d0a167$11f1d830$35d58890$@wicks.co.nz> References: <001601d0a07e$5e38d250$1aaa76f0$@iname.com> <00b601d0a08d$42ddcf10$c8996d30$@iname.com> <004101d0a167$11f1d830$35d58890$@wicks.co.nz> Message-ID: <1C7550E1-92D8-4829-B76F-8DA3BB4E534E@lumaoptics.net> Dwdm tunable 10G can run at 1G with rate select. Sent from my iPhone > On Jun 7, 2015, at 2:15 PM, Tony Wicks wrote: > > I don't quite see why you would want to use a tuneable 1G optic now days. Generally people use coloured optics to either increase the capacity they can push down a Dark Fibre or to interconnect with a DWDM OTN. In days past using different wavelengths for traffic separation would be not unheard of but in today's world there are many better ways of doing that. The use of tuneable optics reduces sparing and complexity but it is a very difficult and expensive manufacturing task and I can understand why no manufacturer would bother with 1G as that seems like a very small market. If you really want 1G there are plenty of CWDM fixed optics available. If you need more capacity, well really 10G is not at all expensive now days. If you want traffic separation then use MPLS. If you have old 1G only switches, well, you know the answer to that. > > My 2c > > > -----Original Message----- > Hi, > > I believe nobody actually answered the original question: is there any tunable SFP module available. Notice the lack of a + in that statement. The datasheets for modules cited in this thread are all 10G modules with minimum speed of 8.5G. Nothing that will work at 1G. > From Thomas.Weible at flexoptix.net Sun Jun 7 23:04:42 2015 From: Thomas.Weible at flexoptix.net (Thomas Weible - FLEXOPTIX) Date: Sun, 7 Jun 2015 23:04:42 +0000 Subject: Tunable SFP In-Reply-To: <1C7550E1-92D8-4829-B76F-8DA3BB4E534E@lumaoptics.net> References: <001601d0a07e$5e38d250$1aaa76f0$@iname.com> <1C7550E1-92D8-4829-B76F-8DA3BB4E534E@lumaoptics.net> Message-ID: Eric wrote: >Dwdm tunable 10G can run at 1G with rate select. +1 already tested and deployed in the field. The configuration/programming of the tunable needs to be modified because pure 1G gear can not handle the 10G configuration of the tunable in most cases. For sure the mayor (economical) case for tunable SFP+ is 10G Ethernet but beside 1G ETH it also works for 4/8G FC datarate. Thomas > > > >> On Jun 7, 2015, at 2:15 PM, Tony Wicks wrote: >> >> I don't quite see why you would want to use a tuneable 1G optic now >>days. Generally people use coloured optics to either increase the >>capacity they can push down a Dark Fibre or to interconnect with a DWDM >>OTN. In days past using different wavelengths for traffic separation >>would be not unheard of but in today's world there are many better ways >>of doing that. The use of tuneable optics reduces sparing and complexity >>but it is a very difficult and expensive manufacturing task and I can >>understand why no manufacturer would bother with 1G as that seems like a >>very small market. If you really want 1G there are plenty of CWDM fixed >>optics available. If you need more capacity, well really 10G is not at >>all expensive now days. If you want traffic separation then use MPLS. If >>you have old 1G only switches, well, you know the answer to that. >> >> My 2c >> >> >> -----Original Message----- >> Hi, >> >> I believe nobody actually answered the original question: is there any >>tunable SFP module available. Notice the lack of a + in that statement. >>The datasheets for modules cited in this thread are all 10G modules with >>minimum speed of 8.5G. Nothing that will work at 1G. >> > > From john at op-sec.us Mon Jun 8 00:14:51 2015 From: john at op-sec.us (John Fraizer) Date: Sun, 7 Jun 2015 20:14:51 -0400 Subject: eBay is looking for network heavies... In-Reply-To: <06C1078F-A86C-4C78-9D97-C661CE6DA947@karoshi.com> References: <1666262376.6430683.1433638078343.JavaMail.yahoo@mail.yahoo.com> <06C1078F-A86C-4C78-9D97-C661CE6DA947@karoshi.com> Message-ID: Bill, Stop now! You just made me spew beer in all directions out my nose! I have no doubt that there is a home for you @ eBay if you ever desire it. John Fraizer --Sent from my Android phone. Please excuse any typos. On Jun 6, 2015 8:57 PM, "manning" wrote: > i?ll never make it past the telephone screen?. > > manning > bmanning at karoshi.com > PO Box 12317 > Marina del Rey, CA 90295 > 310.322.8102 > > > > On 6June2015Saturday, at 19:17, John Fraizer wrote: > > > Just to be clear, CERTS are NOT a requirement for these positions. They > > will head-of-line someone for a phone screen. THAT IS ALL! And if you've > > got a cert, you had better know your stuff because if your cert says > you're > > an EXPERT. I'm gonna expect you to be one! > > > > John Fraizer > > --Sent from my Android phone. > > Please excuse any typos. > > On Jun 6, 2015 5:50 PM, "Randy" wrote: > > > >> $employers don't help in this regard either by requiring said certs. > Such > >> requirements; IMO, lead to folks preparing/passing such tests just for > >> $day_job only without any real desire to understand how > >> things-actually-work&why. > >> > >> > >> > >> ----- Original Message ----- > >> From: John Fraizer > >> To: ?ukasz Bromirski > >> Cc: nanog at nanog.org > >> Sent: Friday, June 5, 2015 5:55 PM > >> Subject: Re: eBay is looking for network heavies... > >> > >> Folks, > >> > >> It's just a piece of paper in my opinion. A person either knows their > >> stuff or they don't. Less than 5min on a phone screen and I will know > if > >> they "bought" their certification(s) or earned them. Sadly, I've > spoken to > >> far too many who give some validation to Jared's comment. I'm wondering > how > >> many proctors have been paid off or if people are buying fake id's for > >> smart people and paying them to sit for the tests posing as them. > >> > >> John Fraizer > >> --Sent from my Android phone. > >> Please excuse any typos. > >> On Jun 5, 2015 5:45 PM, "?ukasz Bromirski" > wrote: > >> > >>> > >>>> On 06 Jun 2015, at 02:26, Jared Mauch wrote: > >>>> > >>>> > >>>>> On Jun 5, 2015, at 7:13 PM, John Fraizer wrote: > >>>>> > >>>>> Head of line for CCIE / JNCIE but knowledge and experience trumps a > >>> piece > >>>>> of paper every time! > >>>> > >>>> Can you please put these at the back of the line? My experience is > >> that > >>>> the cisco certification (at least) is evidence of the absence of > actual > >>>> troubleshooting skills. (or my standards of what defines ?expert? are > >>>> different than the rest of the world). > >>> > >>> Jared, don?t generalize. > >>> > >>> True - there are people that are ?paper? CCIE/JNCIEs - but let?s not > >>> start a rant unless you've met tens of CCIEs/JNCIEs and all of them > >>> didn?t know a jack. About troubleshooting. > >>> > >>> ? > >>> CCIE #15929 R&S/SP, CCDE #2012::17 > >>> (not that I?d know anything about troubleshooting of course) > >> > > From jra at baylink.com Mon Jun 8 02:53:27 2015 From: jra at baylink.com (Jay Ashworth) Date: Sun, 7 Jun 2015 22:53:27 -0400 (EDT) Subject: eBay is looking for network heavies... In-Reply-To: Message-ID: <32690580.4.1433732007021.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Fraizer" > It's been over a decade since I was an active participant on NANOG. I > didn't know that the NANOG-JOBS list existed. Sometimes it's easier to > ask for forgiveness than permission though. I guess it's a good thing > Susan H. isn't here to throw me in NANOG jail, huh? It's horrible. I got thrown in there after Katrina. Just an accident that I discovered later they'd left the door unlocked. And they don't feed you either. Now that the humor's out of the way, I've been on NANOG since the mid-90s and I didn't know we had a -jobs list at all... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Mon Jun 8 02:57:29 2015 From: jra at baylink.com (Jay Ashworth) Date: Sun, 7 Jun 2015 22:57:29 -0400 (EDT) Subject: eBay is looking for network heavies... In-Reply-To: Message-ID: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joe Hamelin" > Back in 2000 at Amazon, HR somehow decided to have me do the phone > interviews for neteng. I'd go through questions on routing and what not, > then at the end I would ask questions like, "Who was Jon Postel? Who > is Larry Wall? Who is Paul Vixie? What are layers 8 & 9? Explain the RTFM > protocol. What is NANOG?" Those answers (or long silences) told me > more about the candidate than most of the technical questions. Original RFC editor. Invented Perl, among other things. Co-designed DNS (did I get that right?) I personally always label layers 8, 9, and 10 as money, management and inside counsel, but I know views differ. I don't RTFM, I google. It's often faster, so many of TFMs are online now. And this... is NANOG! What's my starting rate? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Mon Jun 8 03:00:24 2015 From: jra at baylink.com (Jay Ashworth) Date: Sun, 7 Jun 2015 23:00:24 -0400 (EDT) Subject: eBay is looking for network heavies... In-Reply-To: <5572F23A.4090906@satchell.net> Message-ID: <21442089.8.1433732424324.JavaMail.root@benjamin.baylink.com> > Here's the topper: who was (is) Al Gore, and what part did he play in > the birth of the Internet as we know it today? Try not to howl as some > of the answers you will get. Advocated for the funding of NREN while in Congress; later misquoted as saying he'd "invented the Internet" at some length, no? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Mon Jun 8 03:05:55 2015 From: jra at baylink.com (Jay Ashworth) Date: Sun, 7 Jun 2015 23:05:55 -0400 (EDT) Subject: eBay is looking for network heavies... In-Reply-To: <5573CCE6.10203@cox.net> Message-ID: <22395846.10.1433732755621.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Larry Sheldon" > I find it interesting that I have not note a mention of people like > Radia Pearlman and [name advancing years have stolen from me] that wrote > a 3 volume set (I think it was) (that I can not find in the > post-great-downsizing-bookshelves-disarray at the moment*). > > *did a little Binging--Not W. Richard Stevens although the > subconscious thinks "steven" might have been the first name. > > NO! Douglas E. Comer "Internetworking with TCP/IP" > (Nice try subconscious! Volume 3 is co-authored by David L. Stevens.) No, W Richard was a layer up the stack: http://www.kohala.com/start/ 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 streiner at cluebyfour.org Mon Jun 8 03:07:10 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 7 Jun 2015 23:07:10 -0400 (EDT) Subject: eBay is looking for network heavies... In-Reply-To: References: , <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net>, <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net>, <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org>, , <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com>, <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net>, , , , <5573CCE6.10203@cox.net> Message-ID: On Sun, 7 Jun 2015, Joshua Riesenweber wrote: > As someone studying their first CCIE (RS), I sometimes find these kind > of discussions disheartening. They come up every now and again, and the > opinions seem vary anywhere between 'a good interview tool' and 'less > than worthless'. [snip] > Does a certification mean that you are an expert? No. Does it mean you > are devoid of skill? No. All it means is that the person has studied the > curriculum, and passed the tests.No more, no less. [snip] > When I see someone who has a certification, and they can follow it up > with actual skills, it indicates they have a certain level of dedication > to improving themselves and their education. (In my experience it takes > more time to study a certification track than to learn just what you > need to get a job done.) Agreed. I don't think certs are completely worthless, nor do I make a professional judgment on someone based solely on the alphabet soup they append to their name (or don't). I've been working in the technology world for over 20 years and have had the opportunity to work with people who had the papers and were top-notch, and people who had those same papers and were complete tools in an "*I* have a CCIE... my excrement can't *possibly* stink!" kind of way. Likewise, some of the sharpest people I've ever worked with had no certs at all, but there were lots of tools there, too. Certs are nice, but someone who has them on their resume had better be prepared to walk the walk in a technical interview. As the OP mentioned, the alphabet soup just puts someone at the head of the line for a phone interview. Nothing more. jms From joe at nethead.com Mon Jun 8 03:15:33 2015 From: joe at nethead.com (Joe Hamelin) Date: Sun, 7 Jun 2015 20:15:33 -0700 Subject: eBay is looking for network heavies... In-Reply-To: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> References: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> Message-ID: Jay said: >Original RFC editor. Invented Perl, among other things. Co-designed DNS >(did I get that right?) I personally always label layers 8, 9, and 10 >as money, management and inside counsel, but I know views differ. I don't >RTFM, I google. It's often faster, so many of TFMs are online now. >And this... is NANOG! >What's my starting rate? :-) Close enough but I look for Evi's t-shirt for layers 8&9; financial and political. Back in 2000 your starting rate would have been $90k/yr, $25k signing and 9k of stock options at $21. It's that last one that makes me wish I could have drunk the Kool-Aid for 5 years. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From mysidia at gmail.com Mon Jun 8 03:19:22 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 7 Jun 2015 22:19:22 -0500 Subject: eBay is looking for network heavies... In-Reply-To: <557438E2.7010505@satchell.net> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> <5573CCE6.10203@cox.net> <557438E2.7010505@satchell.net> Message-ID: On Sun, Jun 7, 2015 at 7:28 AM, Stephen Satchell wrote: > On 06/07/2015 01:10 AM, Joshua Riesenweber wrote: [snip] What the industry could probably use most for entry-level certs is a technical reading comprehension requirement on the certs, or a requirement of GRE scores e.g. 145 Verbal, 160 Math, before being able to obtain the certs, to demonstrate an ability to read and understand documentation, including BNF, and the ability to lookup something from a technical manual, read, understand, and apply it properly using qualified background knowledge at the level being certified. Too often, certs concentrate on trivial minutia that is "trivially tested", but also not frequently used, so the population has a bunch of people who just paid copious $$$ for in-person coaching on _just the specifics of the exam_, or people who memorized answers from stolen copies of exams. So even in that, many of the tests lose their ability, due to the intervention of 3rd party "learning providers" who are just making a quick buck training candidates directly to exams, instead of teaching the subject. In short: In regards to the use of certifications when hiring --- they can be used by non-technical reviewers to help filter candidates, where there are more applicants than desired. Consider it a "bulk" filtering criteria that can be done instantly without wasting as much time, and the final filter might be an internal quiz and human interviewers. The certs are no definitive measure, but candidates with Both experience and industry certs to help confirm the quality of that experience are more likely to be applicants worth committing serious time to evaluate, And they can be used to help break ties between otherwise equal applicants in favor of those certified. As to if it matters whether the certification is for Cisco equipment and you use X vendor equipment instead, I would refer to semi-relevant link here: http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa6506e2f35eaac If Carpenters were hired like engineers.... 'I see here, you have experience with cutting timber with "Makita and Milwaukee brand Skillsaws" Unfortunately, we need someone with 25 years experience using the DeWalts.' Certifications can also be used by consultants/contractors to market services, or assure end customers that their services are by people "qualified by the vendor of their equipment". > The R&S CCIE lab exame is a timed practical exam, and as certification tests > goes it does a fair job measuring the ability of the candidate to implement > routers and switches to obtain certain results, ON CISCO EQUIPMENT. (This > is also true of the other Cisco certification tracks.) Correct. However, earning a certification such as CCIE demonstrates that you are not one of those clueless folks who completely lacks understanding and ability to learn basic config and troubleshooting. Earning the cert would require a great deal of practice due to their time limits, therefore the candidate that holds one shows proof of a certain level of dedication to advancement or learning within the field. And sufficient technical aptitude and ability to learn is implied by the certificate to deal with other vendor's equipment, even though Cisco's certifications only address Cisco equipment directly; there are many vendor-neutral concepts which should have been understood for success. The specifics of configuration language and hardware are "implementation details". No certification measures a candidate's ability to quickly learn novel configuration syntax or special rules of arbitrary $new_vendor's equipment. > One can learn how to do almost anything. The real trick is being able to > finish tasks quickly, and that's damn hard to do without practice, practice, Ability to finish tasks *accurately* is what matters. But very simple things should be done quickly. The results of non-repetitive tasks should always be looked at carefully to help validate accuracy,, And the practice required to do any tasks that are frequent and repetitive should be gained by anyone qualified on the job fairly quickly. > That said, certifications show that the candidate can turn a wrench. It > shows nothing about the candidate's ability to handle ARIN, to troubleshoot > political snafus, how to deal with management that is severely All of these are things that can be learned without a large amount of grief, you need reading comprehension; ARIN's policies and tools are fairly well documented in writing. The candidate who can't even learn and pass a cert test might actually be incapable of learning what is required on their own. It's not cost-effective to buy in-person training or certify for *every little thing* that comes up later. > clue-deficient, and most important play nice with colleagues at other -- -JH From alh-ietf at tndh.net Mon Jun 8 04:31:06 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Sun, 7 Jun 2015 21:31:06 -0700 Subject: certification (was: eBay is looking for network heavies...) In-Reply-To: References: Message-ID: <0edc01d0a1a3$efcd6160$cf682420$@tndh.net> Randy Bush wrote: .... > but you can't move packets on pieces of paper. Or can you? RFC's 6214 2549 1149 ;) From mysidia at gmail.com Mon Jun 8 04:41:47 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 7 Jun 2015 23:41:47 -0500 Subject: certification (was: eBay is looking for network heavies...) In-Reply-To: <0edc01d0a1a3$efcd6160$cf682420$@tndh.net> References: <0edc01d0a1a3$efcd6160$cf682420$@tndh.net> Message-ID: On Sun, Jun 7, 2015 at 11:31 PM, Tony Hain wrote: > Randy Bush wrote: >> but you can't move packets on pieces of paper. > Or can you? RFC's 6214 2549 1149 Sure, but rfc1149 needs some work before it could be a viable way of moving packets. For example: the rfc calls for printing a diagram on paper, which is error-prone, and the ink is expensive. Instead they should be using a hole punch to encode the message on the paper tape, bit by bit, with check bits for error correction. Transport of the tapes by truck or car would be more suitable for bandwidth requirements of bulk transfer. Also, the paper can be recycled more easily by reinserting punched and gluing back punched holes from previous message exchanges, than attempting to rewet and bottle ink. > ;) -- -JH From gary.buhrmaster at gmail.com Mon Jun 8 05:02:06 2015 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Mon, 8 Jun 2015 05:02:06 +0000 Subject: certification (was: eBay is looking for network heavies...) In-Reply-To: <0edc01d0a1a3$efcd6160$cf682420$@tndh.net> References: <0edc01d0a1a3$efcd6160$cf682420$@tndh.net> Message-ID: On Mon, Jun 8, 2015 at 4:31 AM, Tony Hain wrote: > Randy Bush wrote: > .... >> but you can't move packets on pieces of paper. > > Or can you? RFC's 6214 2549 1149 But how many avian carriers would you need to move the packets current pushed around per second, and how many Mercedes' would have their paint ruined from that number of carriers, or would the number be large enough to collapse into a star (obligatory what-if xkcd reference: http://what-if.xkcd.com/99/) From ag4ve.us at gmail.com Mon Jun 8 05:42:28 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 8 Jun 2015 01:42:28 -0400 Subject: eBay is looking for network heavies... In-Reply-To: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> References: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 7, 2015 10:59 PM, "Jay Ashworth" wrote: > > I don't > RTFM, I google. It's often faster, so many of TFMs are online now. > Until Google supports regex and some of the duckduckgo module features, I'll be faster getting to reference to you will on Google. Notice I said reference, not an answer - sometimes you care more about the background than the answer (like if you're filing a bug). man /perldoc /rdoc /:help /etc is where it's at (and allows me to answer lots of questions with man foo ? grep bar - which is still bad but doesn't have such a negative feeling that lmgtfy or a Google link does). Also notice I intentionally left out the failed 'info' pages :) Point here is that "Google" is probably the wrong answer here. From ag4ve.us at gmail.com Mon Jun 8 05:47:14 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 8 Jun 2015 01:47:14 -0400 Subject: eBay is looking for network heavies... In-Reply-To: References: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 8, 2015 1:42 AM, "shawn wilson" wrote: > > > On Jun 7, 2015 10:59 PM, "Jay Ashworth" wrote: > > > > > I don't > > RTFM, I google. It's often faster, so many of TFMs are online now. > > > > Until Google supports regex and some of the duckduckgo module features, I'll be faster getting to reference to you will on Google. Notice I said reference, not an answer - sometimes you care more about the background than the answer (like if you're filing a bug). > > man /perldoc /rdoc /:help /etc is where it's at (and allows me to answer lots of questions with man foo ? grep bar - which is still bad but doesn't have such a negative feeling that lmgtfy or a Google link does). Also notice I intentionally left out the failed 'info' pages :) > > Point here is that "Google" is probably the wrong answer here. Oh this NANOG and manufacturers have different levels of documentation, so I guess s/wrong/incomplete/ is more apt. From nasser at rasana.net Mon Jun 8 06:16:32 2015 From: nasser at rasana.net (Nasser Heidari) Date: Mon, 8 Jun 2015 10:46:32 +0430 Subject: PPPoE/IPoE, any recommendations for upgrade? In-Reply-To: References: <002a01d0a0e9$f04481b0$d0cd8510$@rasana.net> Message-ID: <002d01d0a1b2$aa587980$ff096c80$@rasana.net> > On Sun, 7 Jun 2015, Mikael Abrahamsson wrote: > > > - If you are already using IPoE, tell more why should I upgrade? > > The IPoE and IPoEoADSL I have done didn't need radius, didn't need BNG, didn't > need a lot of the complications you're talking about. It could basically be realised in > any decent L3 switch as default gateway for the customers instead of needing BNG. > > So I'd say if you want to get full potential of IPoE you need to do simplification as > well, otherwise there is little use in doing the work if he only thing you want to > change is from IPoPPPoE to IPoE encapsulation and keep all the other stuff you're > doing. > > IPoPPPoE requires special CPE and router at your end to achieve high speeds, > because they need to support encapsulation/decapsulation of packets at whatever > speed you provide. The number of devices that do this is a lot smaller than the > ones that do decent speeds with just IPoE. > > So some people will say migrating to IPoE from IPoPPPoE buys them nothing, > because they feel they need all the mechanisms they currently use. > Greenfield deployments might say "hey, we can do this without a lot of the needed > mechanisms for IPoPPPoE" and save a lot of money and complication. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se Thanks for your reply. I'm would like this simplicity if I could keep same functionalities I have in PPPoE. By functionalities I mean: - AAA - Triple-ply services and classified accounting per service - Possibility to suspend a user service in case of over-quota - applying fair-share policies Do I have any option to have simplicity and same functionality together? Regards, Nasser -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6280 bytes Desc: not available URL: From swmike at swm.pp.se Mon Jun 8 06:43:53 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 8 Jun 2015 08:43:53 +0200 (CEST) Subject: PPPoE/IPoE, any recommendations for upgrade? In-Reply-To: <002d01d0a1b2$aa587980$ff096c80$@rasana.net> References: <002a01d0a0e9$f04481b0$d0cd8510$@rasana.net> <002d01d0a1b2$aa587980$ff096c80$@rasana.net> Message-ID: On Mon, 8 Jun 2015, Nasser Heidari wrote: > Thanks for your reply. I'm would like this simplicity if I could keep same > functionalities I have in PPPoE. By functionalities I mean: > - AAA > - Triple-ply services and classified accounting per service > - Possibility to suspend a user service in case of over-quota > - applying fair-share policies > > Do I have any option to have simplicity and same functionality together? Yes, but you'd have to do things differently than you do today. Well, you don't do AAA in that case. You use DHCP option 82 to identify what port, and use that instead of AAA. So instead of doing everything in the BNG, you have to do it at the access port using SNMP to poll counters and change port policy there. If this is not your liking, then you have to keep the BNG. -- Mikael Abrahamsson email: swmike at swm.pp.se From larrysheldon at cox.net Mon Jun 8 10:01:42 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 08 Jun 2015 05:01:42 -0500 Subject: Regulators now regulating Internet History? Really? Message-ID: <55756806.1000900@cox.net> Looks to me that there are issues of interest here. http://www.aei.org/publication/tom-wheeler-tries-to-rewrite-internet-history/ -- sed quis custodiet ipsos custodes? (Juvenal) From fkittred at gwi.net Mon Jun 8 10:56:46 2015 From: fkittred at gwi.net (Fletcher Kittredge) Date: Mon, 8 Jun 2015 06:56:46 -0400 Subject: Regulators now regulating Internet History? Really? In-Reply-To: <55756806.1000900@cox.net> References: <55756806.1000900@cox.net> Message-ID: On Mon, Jun 8, 2015 at 6:01 AM, Larry Sheldon wrote: > Looks to me that there are issues of interest here. > > > http://www.aei.org/publication/tom-wheeler-tries-to-rewrite-internet-history/ This isn't a very good article. At best, it is a set of unsubstantiated claims regarding events of undefined correlation. "Change in regulation Y led to less investment in [bad sector] and more investment in [good sector]." Really? Details of how much more? How much less? Why was this better? How did you measure that? There are only vague figures without attribution and no establishment of causal link. The assumption is just made that investment decisions are made for regulatory reasons. This is particularly suspect because, as you may recall, there were other things going on in that period. Like the Internet Bubble. The timeline of events is screwed with. He uses the period between 1996 and 2000, when the Internet Bubble popped, and compares it to 1996 to 2005, when Powell/Martin did away with pro-competitive regulation. Yes, during the bubble, which ended in 2000, there was a huge investment in fiber, but it is a difficult argument to make that the investment was because of regulation since the regulatory change happened in 2005. If it was the regulatory change, why didn't investment happen during the missing five years? Since it is a widely held thesis that the fiber bubble popped because of a huge oversupply of dark fiber, why is that not directly addressed. Yes, after 2005 cable companies invested in broadband, but again that market wasn't technologically developed yet in say, 1999. Further, how can you focus only the rate of change in cable investment without considering the rate of change in DSL? Claiming the Internet bubble popped because of a change in telco regulatory regime in the US is ridiculous, as is ignoring the effect of underlying technology on the appearance and disappearance of markets. Regulators, lawyers and politicians need to get over themselves and have a measured perspective on their importance. The argument that killing competition from the CLECs led to more investment and a better network is a difficult one to make. Particularly during a period where the US's network lost is speed/quality advantage compared to other advanced countries. There is a strong set of opinions that killing CLEC competition was retardant on network speed/quality growth. I don't see how articles like this are going to change minds. Disclaimer: I am a computer scientist. In general, I find public policy arguments deeply annoying because they have flaws similar to the above. -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From ramy.ihashish at gmail.com Mon Jun 8 10:57:42 2015 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Mon, 8 Jun 2015 12:57:42 +0200 Subject: GRE performance over the Internet - DDoS cloud mitigation Message-ID: Good day All, I just want to raise the issue that has not been addressed so far by the DDoS cloud mitigation providers, either in the always-ON solution or the on-demand solution, a BGP session has to be established over a GRE tunnel over the internet between the ISP/NSP/DC and the cloud scrubbing center, the BGP/GRE are used for two main purposes; advertising the victim /24 subnet during the attack, and sending the traffic back to from the scrubbing center to the provider. The question is how can we guarantee the GRE/BGP performance (control traffic) during the time between detection and mitigation? Experts from Arbor, Prolexic(AKAMAI), Radware, Incapsula, Defense.net (F5), Verisign, nexus guard, neustar ......etc are most welcomed to give opinions. Thanks, Ramy "Only the best is good enough" From rdobbins at arbor.net Mon Jun 8 11:25:14 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 08 Jun 2015 18:25:14 +0700 Subject: GRE performance over the Internet - DDoS cloud mitigation In-Reply-To: References: Message-ID: On 8 Jun 2015, at 17:57, Ramy Hashish wrote: > a BGP session has to be established over a GRE tunnel over the > internet between the ISP/NSP/DC and the cloud scrubbing center, This is incorrect. In most cloud overlay DDoS mitigation scenarios (e.g., end-customer obtains service from an MSSP which isn't providing them with transit), a) there is no BGP relationship whatsoever between the end-customer and the MSSP, and b) the GRE tunnel is used strictly for re-injection of clean traffic (i.e., post-mitigation) to the end-customer. In some scenarios, DNS is also used in place of/in addition to BGP-based diversion. But GRE is used for re-injection only. ----------------------------------- Roland Dobbins From jayfar at jayfar.com Mon Jun 8 13:46:59 2015 From: jayfar at jayfar.com (Jay Farrell) Date: Mon, 8 Jun 2015 09:46:59 -0400 Subject: Regulators now regulating Internet History? Really? In-Reply-To: References: <55756806.1000900@cox.net> Message-ID: The article is nothing more or less than what you'd expect to read from the American Enterprise Institute. "All regulation totally sucks" is their only message ever. On Mon, Jun 8, 2015 at 6:56 AM, Fletcher Kittredge wrote: > On Mon, Jun 8, 2015 at 6:01 AM, Larry Sheldon > wrote: > > > Looks to me that there are issues of interest here. > > > > > > > http://www.aei.org/publication/tom-wheeler-tries-to-rewrite-internet-history/ > > > This isn't a very good article. > > At best, it is a set of unsubstantiated claims regarding events of > undefined correlation. "Change in regulation Y led to less investment in > [bad sector] and more investment in [good sector]." Really? Details of how > much more? How much less? Why was this better? How did you measure that? > There are only vague figures without attribution and no establishment of > causal link. The assumption is just made that investment decisions are made > for regulatory reasons. This is particularly suspect because, as you may > recall, there were other things going on in that period. Like the Internet > Bubble. > > The timeline of events is screwed with. He uses the period between 1996 and > 2000, when the Internet Bubble popped, and compares it to 1996 to 2005, > when Powell/Martin did away with pro-competitive regulation. Yes, during > the bubble, which ended in 2000, there was a huge investment in fiber, but > it is a difficult argument to make that the investment was because of > regulation since the regulatory change happened in 2005. If it was the > regulatory change, why didn't investment happen during the missing five > years? Since it is a widely held thesis that the fiber bubble popped > because of a huge oversupply of dark fiber, why is that not directly > addressed. > > Yes, after 2005 cable companies invested in broadband, but again that > market wasn't technologically developed yet in say, 1999. Further, how can > you focus only the rate of change in cable investment without considering > the rate of change in DSL? > > Claiming the Internet bubble popped because of a change in telco regulatory > regime in the US is ridiculous, as is ignoring the effect of underlying > technology on the appearance and disappearance of markets. Regulators, > lawyers and politicians need to get over themselves and have a measured > perspective on their importance. > > The argument that killing competition from the CLECs led to more investment > and a better network is a difficult one to make. Particularly during a > period where the US's network lost is speed/quality advantage compared to > other advanced countries. There is a strong set of opinions that killing > CLEC competition was retardant on network speed/quality growth. I don't see > how articles like this are going to change minds. > > Disclaimer: I am a computer scientist. In general, I find public policy > arguments deeply annoying because they have flaws similar to the above. > > -- > Fletcher Kittredge > GWI > 8 Pomerleau Street > Biddeford, ME 04005-9457 > 207-602-1134 > From m4rtntns at gmail.com Mon Jun 8 14:11:15 2015 From: m4rtntns at gmail.com (Martin T) Date: Mon, 8 Jun 2015 17:11:15 +0300 Subject: most accurate geo-IP source to build country-based access lists Message-ID: Hi, let's say that I need to build an ACL where I block all the IPv4 traffic from Sweden. I considered following solutions: 1) RIR statistics files(ftp://ftp.ripe.net/ripe/stats/RIR-Statistics-Exchange-Format.txt) accessible for example at ftp://ftp.apnic.net/pub/stats/. However, those files contain allocations and assignment made by the registry producing the file and not any sub-assignments by other agencies(for example NIR, LIR). This means that this information is not very accurate. Another problem which I found out is that in case of inetnum object has many country fields, the first one is used. In addition, even the RIR statistics exchange format document says that: cc = ISO 3166 2-letter country code, and the enumerated variances of {AP,EU,UK} These values are not defined in ISO 3166 but are widely used. The cc value identifies the country. However, it is not specified if this is the country where the addresses are used. There are no rules defined for this value. It therefore cannot be used in any reliable way to map IP addresses to countries 2) MaxMind products. Those should rely on user input(for example MaxMind purchases user data from ISP's or content providers) and based on personal experience defaults to RIR data if no other more accurate source is available. If anyone has something to specify here, then please do so. 3) Use iptables geoip module, but turned out, that it uses MaxMind database: root at VM-host:~# grep -Hsi maxmind $(dpkg -L xtables-addons-common) /usr/lib/xtables-addons/xt_geoip_build:# Converter for MaxMind CSV database to binary, for xt_geoip /usr/lib/xtables-addons/xt_geoip_dl: http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz \ /usr/lib/xtables-addons/xt_geoip_dl: http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip; root at VM-host:~# 4) In theory geofeeds(http://tools.ietf.org/html/draft-google-self-published-geofeeds-02) would be a nice solution, but as I understand the RFC, it would work for my example only in case all the IP address users would provide their geofeed and there is a centralized database to query. 5) Use prefix AS path. However, there seems to be no reliable way to determine source country based on information in BGP routing tables. Are there any other possibilities to geolocate IPv4 addresses with higher accuracy? regards, Martin From rdobbins at arbor.net Mon Jun 8 14:14:18 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 08 Jun 2015 21:14:18 +0700 Subject: most accurate geo-IP source to build country-based access lists In-Reply-To: References: Message-ID: <26C02A6C-D40F-4C1C-9DA7-C3B13CBFE740@arbor.net> On 8 Jun 2015, at 21:11, Martin T wrote: > Are there any other possibilities to geolocate IPv4 addresses with > higher accuracy? There is no direct relationship between logical network topology and geopolitical boundaries. ----------------------------------- Roland Dobbins From mansaxel at besserwisser.org Mon Jun 8 14:23:04 2015 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Mon, 8 Jun 2015 16:23:04 +0200 Subject: most accurate geo-IP source to build country-based access lists In-Reply-To: References: Message-ID: <20150608142303.GD19546@besserwisser.org> Subject: most accurate geo-IP source to build country-based access lists Date: Mon, Jun 08, 2015 at 05:11:15PM +0300 Quoting Martin T (m4rtntns at gmail.com): > Are there any other possibilities to geolocate IPv4 addresses with > higher accuracy? There are three levels of untruth: (in increasing order of falseness) 1. No, mom, I did not eat the pie. 2. "There are no Russian soldiers in Crimea" 3. IP Geolocation -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 GOOD-NIGHT, everybody ... Now I have to go administer FIRST-AID to my pet LEISURE SUIT!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From Jason_Livingood at cable.comcast.com Mon Jun 8 14:30:20 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Mon, 8 Jun 2015 14:30:20 +0000 Subject: Regulators now regulating Internet History? Really? In-Reply-To: References: <55756806.1000900@cox.net> Message-ID: On 6/8/15, 6:56 AM, "Fletcher Kittredge" > wrote: Yes, after 2005 cable companies invested in broadband... Without respect to the merits of the AEI article, I did want to point out that cable companies have been investing in broadband / Internet services well before 2005. They were in an R&D phase in the early 1990s and by around 1995 - 1996 there were many cable modem trial deployments underway in the U.S. Comcast and several other cable companies launched their cable Internet service in 1996 in partnership with @Home. For some early background, see: https://www.informit.com/library/content.aspx?b=Planet_Broadband&seqNum=17 http://www.businessweek.com/1996/42/b34971.htm http://articles.baltimoresun.com/1996-12-04/business/1996339002_1_cable-modem-cable-companies-modem-service Regards, Jason Livingood From david at mailplus.nl Mon Jun 8 14:36:12 2015 From: david at mailplus.nl (David Hofstee) Date: Mon, 8 Jun 2015 16:36:12 +0200 Subject: most accurate geo-IP source to build country-based access lists In-Reply-To: <20150608142303.GD19546@besserwisser.org> References: <20150608142303.GD19546@besserwisser.org> Message-ID: <78C35D6C1A82D243B830523B4193CF5F9F3DCE833D@SBS1.blinker.local> 4. There are no Russian IPs in Crimea? David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces at nanog.org] Namens M?ns Nilsson Verzonden: Monday, June 8, 2015 4:23 PM Aan: Martin T CC: nanog at nanog.org Onderwerp: Re: most accurate geo-IP source to build country-based access lists Subject: most accurate geo-IP source to build country-based access lists Date: Mon, Jun 08, 2015 at 05:11:15PM +0300 Quoting Martin T (m4rtntns at gmail.com): > Are there any other possibilities to geolocate IPv4 addresses with > higher accuracy? There are three levels of untruth: (in increasing order of falseness) 1. No, mom, I did not eat the pie. 2. "There are no Russian soldiers in Crimea" 3. IP Geolocation -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 GOOD-NIGHT, everybody ... Now I have to go administer FIRST-AID to my pet LEISURE SUIT!! From A.L.M.Buxey at lboro.ac.uk Mon Jun 8 14:37:12 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 8 Jun 2015 14:37:12 +0000 Subject: most accurate geo-IP source to build country-based access lists In-Reply-To: <20150608142303.GD19546@besserwisser.org> References: <20150608142303.GD19546@besserwisser.org> Message-ID: <20150608143712.GA17927@lboro.ac.uk> Hi, > 2. "There are no Russian soldiers in Crimea" eh? we know there are as it got annexed last year. I think you meant "There are no Russian soldiers in Ukraine" ? alan From jmcc at hackwatch.com Mon Jun 8 14:56:32 2015 From: jmcc at hackwatch.com (John McCormac) Date: Mon, 08 Jun 2015 15:56:32 +0100 Subject: most accurate geo-IP source to build country-based access lists In-Reply-To: References: Message-ID: <5575AD20.7020704@hackwatch.com> On 08/06/2015 15:11, Martin T wrote:> Hi, > > let's say that I need to build an ACL where I block all the IPv4 > traffic from Sweden. I considered following solutions: > > 1) RIR statistics > files(ftp://ftp.ripe.net/ripe/stats/RIR-Statistics-Exchange-Format.txt) > accessible for example at ftp://ftp.apnic.net/pub/stats/. However, > those files contain allocations and assignment made by the registry > producing the file and not any sub-assignments by other agencies(for > example NIR, LIR). This means that this information is not very > accurate. Another problem which I found out is that in case of inetnum > object has many country fields, the first one is used. In addition, > even the RIR statistics exchange format document says that: > It is a very difficult problem because IP ranges change and are split or redelegated. This means that even a reasonably current database will have data that is either out of date or not current. I mapped all websites in com/net/org/biz/info/mobi and the new gTLDs last year. While these are simply websites, the rise of VPN services and TOR have made blocking at a country level somewhat problematic. You may get many of the IPs associated with the country but you will not get them all. At a brute force country level it is possible to use the Delegated ranges lists but that runs into the problem where IP ranges are subnetted and allocated to other countries. This happens more with hosting service providers more than ISPs. There is also the Adjacent Markets effect where a provider will be operating in geographically close markets and the provider's largest IP range will encompass all the country level allocations. This problem typically reoccurs every time a large transnational cable TV/ISP acquires a new range of IPs and the online services such as Netflix are waiting for the IP range lists to update. The cable ISP's users generally appear, to the online services, as being in another country. > 4) In theory geofeeds(http://tools.ietf.org/html/draft-google-self-published-geofeeds-02) > would be a nice solution, but as I understand the RFC, it would work > for my example only in case all the IP address users would provide > their geofeed and there is a centralized database to query. The idea of all IP address users submitting their data is nice in theory but it runs into much the same problem as submission based web directories. Most users are either unaware of the existence of such projects or have no interest in doing so. > Are there any other possibilities to geolocate IPv4 addresses with > higher accuracy? There is but it is seriously labour and resource intensive as it would require a working model of a country's network infrastructure. Basically it uses a combination of IP data and IP mapping using route tracing. There were some US patents published on it a few years ago (I think that Google may have been one of the patentees. Regards...jmcc -- ********************************************************** John McCormac * e-mail: jmcc at hosterstats.com MC2 * web: http://www.hosterstats.com/ 22 Viewmount * Domain Registrations Statistics Waterford * And Historical DNS Database. Ireland * Over 396 Million Domains Tracked. IE * web: http://newgtldnews.com ********************************************************** From ramy.ihashish at gmail.com Mon Jun 8 15:18:21 2015 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Mon, 8 Jun 2015 17:18:21 +0200 Subject: NANOG Digest, Vol 89, Issue 8 In-Reply-To: References: Message-ID: > > > On 8 Jun 2015, at 17:57, Ramy Hashish wrote: > > > a BGP session has to be established over a GRE tunnel over the > > internet between the ISP/NSP/DC and the cloud scrubbing center, > > This is incorrect. > > In most cloud overlay DDoS mitigation scenarios (e.g., end-customer > obtains service from an MSSP which isn't providing them with transit), > a) there is no BGP relationship whatsoever between the end-customer and > the MSSP, and b) the GRE tunnel is used strictly for re-injection of > clean traffic (i.e., post-mitigation) to the end-customer. > > In some scenarios, DNS is also used in place of/in addition to BGP-based > diversion. > > But GRE is used for re-injection only. > > > Roland, I am talking about the case where the ISP/NSP is having their own DDoS mitigation solution -to protect their NW infrastructure- and then providing the service to their end customers. However I have some concerns on your comments: Even if the transit provider won't be involved in the mitigation process and the GRE tunnel is used only for injecting the traffic back to the end customer, the customer's dirty traffic will pass through some congestion points (most likely near the IGWs) throughout the transit provider network. And concerning point b) as per Arbor representatives in my region, Arbor's system takes up to five minutes to mitigate the attack (starting from the hit of the first dirty packet), so there will be a period of time where the dirty traffic (or at least some of it) will be coming down all the way to the end customer until you completely mitigate the attack. I hope now it become more clear. Ramy From nanogml at ddos-mitigator.net Sun Jun 7 16:24:23 2015 From: nanogml at ddos-mitigator.net (nanogml at ddos-mitigator.net) Date: Sun, 07 Jun 2015 09:24:23 -0700 Subject: PoC for shortlisted DDoS Vendors Message-ID: <55747037.kYCVUMGwnhLdkOSM%nanogml@ddos-mitigator.net> hi nanog, back in april, Mohamed was reviewing the shortlist of DDoS appliances, would you mind posting a summary of your findings # partial list of DDoS appliances DDoS-Mitigator.net/Competitors ----- ? does anybody know which DDoS appliances uses IPtables to do its mitigation ?? iptables is good because it supports tarpit which can be used to counter attack the incoming TCP-based DDoS attackers ? Does any colo/datacenter ( in silicon valley or Las Vegas ) allow the customers to put a firewall at the ISP end of the pipe to prevent these ICMP/UDP floods from going down the pipe to the customer thanx alvin DDoS-Simulator.net === Simulate DDoS attacks DDoS-Mitigator.net === Defend against incoming DDoS attacks From rdobbins at arbor.net Mon Jun 8 16:07:46 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 08 Jun 2015 23:07:46 +0700 Subject: NANOG Digest, Vol 89, Issue 8 In-Reply-To: References: Message-ID: <294BA692-AD7B-480B-988A-9984273BDC24@arbor.net> On 8 Jun 2015, at 22:18, Ramy Hashish wrote: > Even if the transit provider won't be involved in the mitigation > process > and the GRE tunnel is used only for injecting the traffic back to the > end > customer, the customer's dirty traffic will pass through some > congestion > points (most likely near the IGWs) throughout the transit provider > network. The Internet is a best-effort network (of networks). People with operational experience understand this and don't find it remarkable, nor do they make unfounded general assertions. > And concerning point b) as per Arbor representatives in my region, > Arbor's > system takes up to five minutes to mitigate the attack (starting from > the > hit of the first dirty packet), so there will be a period of time > where the > dirty traffic (or at least some of it) will be coming down all the way > to > the end customer until you completely mitigate the attack. All the commercial IDMS systems from various vendors of which I'm aware have operator-configured latency values for both detection/classification/traceback and for mitigation activation; these functions are intended to allow the operator to find the right balance between rapidity in responding to operationally-significant events and not being deluged with alerts/mitigations regarding events with little or no operational significance. Different operators with different customer bases in different situations tend to tune them differently, depending upon their situationally-specific priorities, operational practices, etc. It isn't appropriate for a vendor employee like me to get into a vendor-specific discussion on the NANOG list; if you'd like to understand how a) the above assertion about '5 minutes' is incorrect and b) how DDoS mitigation in general focused on minimizing both underblocking and overblocking, rather than on the failed 'IPS' model, contact those Arbor representatives of whom you speak and have them engage me in joint discussions. ----------------------------------- Roland Dobbins From amitchell at isipp.com Mon Jun 8 17:20:03 2015 From: amitchell at isipp.com (Anne Mitchell) Date: Mon, 8 Jun 2015 11:20:03 -0600 Subject: T-mobile contact? Message-ID: <0D0121F7-2D74-4DDC-A720-B94479C0A59A@isipp.com> Is there anyone from T-mobile here, or does anybody have a T-mobile contact with whom they can put me in touch? Anne Anne P. Mitchell, Esq. CEO/President ISIPP SuretyMail Email Reputation, Accreditation & Certification http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Member, California Bar Cyberspace Law Committee Member, Colorado Cybersecurity Consortium Ret. Professor of Law, Lincoln Law School of San Jose 303-731-2121 | amitchell at isipp.com | @AnnePMitchell | Facebook/AnnePMitchell From blake at ispn.net Mon Jun 8 17:43:18 2015 From: blake at ispn.net (Blake Hudson) Date: Mon, 08 Jun 2015 12:43:18 -0500 Subject: most accurate geo-IP source to build country-based access lists In-Reply-To: <26C02A6C-D40F-4C1C-9DA7-C3B13CBFE740@arbor.net> References: <26C02A6C-D40F-4C1C-9DA7-C3B13CBFE740@arbor.net> Message-ID: <5575D436.60501@ispn.net> Roland Dobbins wrote on 6/8/2015 9:14 AM: > > On 8 Jun 2015, at 21:11, Martin T wrote: > >> Are there any other possibilities to geolocate IPv4 addresses with >> higher accuracy? > > There is no direct relationship between logical network topology and > geopolitical boundaries. > > ----------------------------------- > Roland Dobbins Have you thought about application layer tests - e.g. is the client's character set/language set to Swedish? Has the user identified himself/herself/henself as living in or being from Sweeden? --Blake From nanog at ics-il.net Mon Jun 8 18:46:31 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 8 Jun 2015 13:46:31 -0500 (CDT) Subject: Access to nanog.cluepon.net In-Reply-To: Message-ID: <13830863.2876.1433789222012.JavaMail.mhammett@ThunderFuck> Still down here (and apparently elsewhere as a request on another list was about it being down as well). ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Josh Luthman" To: "Frank Bulk" Cc: "NANOG list" Sent: Saturday, June 6, 2015 12:33:17 PM Subject: Re: Access to nanog.cluepon.net Hasn't been working for about 20 minutes or more for me as well. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sat, Jun 6, 2015 at 1:27 PM, Frank Bulk wrote: > I'd like to update some material on nanog.cluepon.net (not very responsive > to HTTP requests right now) and my account doesn't work anymore. I reached > out to Richard S. but have not heard back from him - anyone else here who > has admin access and can set me up again? > > Frank > > From A.L.M.Buxey at lboro.ac.uk Mon Jun 8 21:10:28 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 8 Jun 2015 21:10:28 +0000 Subject: most accurate geo-IP source to build country-based access lists In-Reply-To: <5575D436.60501@ispn.net> References: <26C02A6C-D40F-4C1C-9DA7-C3B13CBFE740@arbor.net> <5575D436.60501@ispn.net> Message-ID: <20150608211028.GA18596@lboro.ac.uk> Hi, > Have you thought about application layer tests - e.g. is the > client's character set/language set to Swedish? Has the user > identified himself/herself/henself as living in or being from > Sweeden? ...just waiting for someone to suggest checking their web cookies to see what area they've got defined in adultfriendfinder or whatever... ;-) alan From colton.conor at gmail.com Mon Jun 8 21:33:15 2015 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 8 Jun 2015 16:33:15 -0500 Subject: PPPoE/IPoE, any recommendations for upgrade? In-Reply-To: <002d01d0a1b2$aa587980$ff096c80$@rasana.net> References: <002a01d0a0e9$f04481b0$d0cd8510$@rasana.net> <002d01d0a1b2$aa587980$ff096c80$@rasana.net> Message-ID: Suspend or shut down a user is easy, just disable their port on the DSLAM or change their port to a VLAN that only allows them to access/pay their bill. Going to PPPoE to IPoE increases the net throughput right? On Mon, Jun 8, 2015 at 1:16 AM, Nasser Heidari wrote: > > On Sun, 7 Jun 2015, Mikael Abrahamsson wrote: > > > > > - If you are already using IPoE, tell more why should I upgrade? > > > > The IPoE and IPoEoADSL I have done didn't need radius, didn't need BNG, > didn't > > need a lot of the complications you're talking about. It could basically > be realised in > > any decent L3 switch as default gateway for the customers instead of > needing BNG. > > > > So I'd say if you want to get full potential of IPoE you need to do > simplification as > > well, otherwise there is little use in doing the work if he only thing > you > want to > > change is from IPoPPPoE to IPoE encapsulation and keep all the other > stuff > you're > > doing. > > > > IPoPPPoE requires special CPE and router at your end to achieve high > speeds, > > because they need to support encapsulation/decapsulation of packets at > whatever > > speed you provide. The number of devices that do this is a lot smaller > than the > > ones that do decent speeds with just IPoE. > > > > So some people will say migrating to IPoE from IPoPPPoE buys them > nothing, > > because they feel they need all the mechanisms they currently use. > > Greenfield deployments might say "hey, we can do this without a lot of > the > needed > > mechanisms for IPoPPPoE" and save a lot of money and complication. > > > > -- > > Mikael Abrahamsson email: swmike at swm.pp.se > > Thanks for your reply. I'm would like this simplicity if I could keep same > functionalities I have in PPPoE. By functionalities I mean: > - AAA > - Triple-ply services and classified accounting per service > - Possibility to suspend a user service in case of over-quota > - applying fair-share policies > > Do I have any option to have simplicity and same functionality together? > > Regards, > Nasser > From baconzombie at gmail.com Mon Jun 8 22:21:17 2015 From: baconzombie at gmail.com (Bacon Zombie) Date: Tue, 9 Jun 2015 00:21:17 +0200 Subject: most accurate geo-IP source to build country-based access lists In-Reply-To: <20150608211028.GA18596@lboro.ac.uk> References: <26C02A6C-D40F-4C1C-9DA7-C3B13CBFE740@arbor.net> <5575D436.60501@ispn.net> <20150608211028.GA18596@lboro.ac.uk> Message-ID: Tinder would be more accurate since it uses the phones GPS. You could also cross check what subreddits they are subscribed to. On 8 Jun 2015 23:12, wrote: > Hi, > > > Have you thought about application layer tests - e.g. is the > > client's character set/language set to Swedish? Has the user > > identified himself/herself/henself as living in or being from > > Sweeden? > > ...just waiting for someone to suggest checking their web cookies > to see what area they've got defined in adultfriendfinder or whatever... > ;-) > > alan > From jeroen at mompl.net Tue Jun 9 00:10:25 2015 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 08 Jun 2015 17:10:25 -0700 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> Message-ID: <55762EF1.80509@mompl.net> On 06/05/2015 06:38 PM, Mike Hale wrote: > We need a pool on what percentage of readers just googled traceroute. You sort of nailed it though. I think ready knowledge about the internals of utilities such as traceroute or ping is nice to have, however if you don't know it it is not something that should disqualify you as an expert or someone with advanced knowledge in the field. Don't learn by heart that which you can look up. In this day and age where knowledge about every subject imaginable is a 5 second (to a minute for those less versed in researching) internet search away there is no need to hold all that knowledge iny our memory. What is far more important (above and beyond the basic skills) is the ability to research quickly, find out the answers you are looking for and apply them in a timely manner. It is actually not easy, because much to my dismay I have found out that so many people, whether they have a phd, or are the airco repair person, have such inability to even use the most basic research tools. It makes you feel like a search engine by proxy. :-( Greetings, Jeroen -- Earthquake Magnitude: 4.7 Date: 2015-06-08 22:20:42.040 UTC Date Local: 2015-06-08 15:20:42 PDT Location: 97km SSE of Makry Gialos, Greece Latitude: 34.1882; Longitude: 26.2303 Depth: 15.48 km | e-quake.org From streiner at cluebyfour.org Tue Jun 9 00:26:39 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 8 Jun 2015 20:26:39 -0400 (EDT) Subject: eBay is looking for network heavies... In-Reply-To: <55762EF1.80509@mompl.net> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <55762EF1.80509@mompl.net> Message-ID: On Mon, 8 Jun 2015, Jeroen van Aart wrote: > On 06/05/2015 06:38 PM, Mike Hale wrote: >> We need a pool on what percentage of readers just googled traceroute. > > Don't learn by heart that which you can look up. In this day and age where > knowledge about every subject imaginable is a 5 second (to a minute for those > less versed in researching) internet search away there is no need to hold all > that knowledge iny our memory. Reminds me of a job interview I had many years ago, where the interviewer was looking for me to quote chapter and verse of several RFCs for different routing protocols. Uh... yeah. jms From davidbass570 at gmail.com Tue Jun 9 00:36:58 2015 From: davidbass570 at gmail.com (David Bass) Date: Mon, 8 Jun 2015 17:36:58 -0700 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <55762EF1.80509@mompl.net> Message-ID: Yeah, I think that's more about them stroking their own ego than anything to do with you or the job. I've unfortunately seen a few of those types before as well. > On Jun 8, 2015, at 5:26 PM, Justin M. Streiner wrote: > >> On Mon, 8 Jun 2015, Jeroen van Aart wrote: >> >>> On 06/05/2015 06:38 PM, Mike Hale wrote: >>> We need a pool on what percentage of readers just googled traceroute. >> >> Don't learn by heart that which you can look up. In this day and age where knowledge about every subject imaginable is a 5 second (to a minute for those less versed in researching) internet search away there is no need to hold all that knowledge iny our memory. > > Reminds me of a job interview I had many years ago, where the interviewer was looking for me to quote chapter and verse of several RFCs for different routing protocols. Uh... yeah. > > jms From Valdis.Kletnieks at vt.edu Tue Jun 9 00:45:29 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 08 Jun 2015 20:45:29 -0400 Subject: eBay is looking for network heavies... In-Reply-To: Your message of "Mon, 08 Jun 2015 17:10:25 -0700." <55762EF1.80509@mompl.net> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <55762EF1.80509@mompl.net> Message-ID: <4262.1433810729@turing-police.cc.vt.edu> On Mon, 08 Jun 2015 17:10:25 -0700, Jeroen van Aart said: > You sort of nailed it though. I think ready knowledge about the > internals of utilities such as traceroute or ping is nice to have, > however if you don't know Describe the top 3 gotchas of using traceroute to diagnose network problems. :) That's something you're not likely to look up if you're in the middle of a connectivity event.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From surfer at mauigateway.com Tue Jun 9 01:22:13 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 8 Jun 2015 18:22:13 -0700 Subject: eBay is looking for network heavies... Message-ID: <20150608182213.D46FF985@m0005311.ppops.net> --- Valdis.Kletnieks at vt.edu wrote: On Mon, 08 Jun 2015 17:10:25 -0700, Jeroen van Aart said: > You sort of nailed it though. I think ready knowledge > about the internals of utilities such as traceroute > or ping is nice to have, however if you don't know Describe the top 3 gotchas of using traceroute to diagnose network problems. :) That's something you're not likely to look up if you're in the middle of a connectivity event.... ------------------------------------------------ It's these types of questions that're hard for some in an interview even though they know their stuff. One might get nervous wondering if (s)he gave the interviewer the three that they're looking for and stumble on the next question even though the next question seems easy to the interviewer. I'd ask the question a little differently: I have a network problem between 2 sites and there is a firewall between them that is blocking ICMP and nothing else. How would you complete a traceroute to troubleshoot? (Use BSD or tcptraceroute, for example) Then, it turns the questioning into operational. scott From yardiel at gmail.com Tue Jun 9 01:26:25 2015 From: yardiel at gmail.com (Yardiel Fuentes) Date: Mon, 8 Jun 2015 21:26:25 -0400 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <55762EF1.80509@mompl.net> Message-ID: This discussion is always reminisced of questions such as: Why would I want to learn Algebra or Calculus in college ? or why would I want to go to college at all ? .. the student argues that calculus or college is hardly ever used, if at all, in a job ? the most sensible perspective has always been: It is not only about the knowledge itself, but how learning those subjects train your mind to tackle technical problems?same in networking? Some of the best interview questions are those that pose a problem and ask you to tackle it by explaining your train of thought?It requires both: knowledge and how to apply it... A simple example can be: What does the n*n or (n^2) problem represent in BGP ? ? Where does the n*n formula come from ? ?. these questions can trigger a technical interview conversation or Q&A?covering BGP-RR?s, BGP confeds, etc etc?maybe H-VPLS ? By the time the conversation is over, there is a better grasp of someone?s understanding on networks ? Yardiel On Mon, Jun 8, 2015 at 8:26 PM, Justin M. Streiner wrote: > On Mon, 8 Jun 2015, Jeroen van Aart wrote: > > On 06/05/2015 06:38 PM, Mike Hale wrote: >> >>> We need a pool on what percentage of readers just googled traceroute. >>> >> >> Don't learn by heart that which you can look up. In this day and age >> where knowledge about every subject imaginable is a 5 second (to a minute >> for those less versed in researching) internet search away there is no need >> to hold all that knowledge iny our memory. >> > > Reminds me of a job interview I had many years ago, where the interviewer > was looking for me to quote chapter and verse of several RFCs for different > routing protocols. Uh... yeah. > > jms > -- Yardiel Fuentes From jeroen at mompl.net Tue Jun 9 01:31:25 2015 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 08 Jun 2015 18:31:25 -0700 Subject: eBay is looking for network heavies... In-Reply-To: <20150608182213.D46FF985@m0005311.ppops.net> References: <20150608182213.D46FF985@m0005311.ppops.net> Message-ID: <557641ED.7080600@mompl.net> On 06/08/2015 06:22 PM, Scott Weeks wrote: > > > --- Valdis.Kletnieks at vt.edu wrote: > On Mon, 08 Jun 2015 17:10:25 -0700, Jeroen van Aart said: > >> You sort of nailed it though. I think ready knowledge >> about the internals of utilities such as traceroute >> or ping is nice to have, however if you don't know > > Describe the top 3 gotchas of using traceroute to > diagnose network problems. :) > > That's something you're not likely to look up if you're > in the middle of a connectivity event.... Yes, but it's different to knowing stuff by heart that you can just research. Note that I do not mention any specific search tool, I barely even use the largest search engines. The "top 3 gotchas of using traceroute" is something I would expect to be part of basic skills that someone with at least mid level knowledge in the field would possess. But how exactly traceroute does its thing is something I personally like to read about but not remember word for word. Greetings, Jeroen -- Earthquake Magnitude: 5.2 Date: 2015-06-09 01:09:02.910 UTC Date Local: 2015-06-08 17:09:02 PDT Location: 11km ENE of Malesina, Greece Latitude: 38.6699; Longitude: 23.3453 Depth: 5.76 km | e-quake.org From shane at ronan-online.com Mon Jun 8 16:09:24 2015 From: shane at ronan-online.com (Shane Ronan) Date: Mon, 8 Jun 2015 12:09:24 -0400 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> <5573CCE6.10203@cox.net> <557438E2.7010505@satchell.net> Message-ID: When I was asked the default BGP timers across three different vendor platforms as measure of my networking ability during an interview, I replied saying I'd look them up if needed them. I was told I didn't understand BGP in enough detail, despite being able to describe all the steps of BGP session establishment and route exchange. Certs have ruined the industry. On Jun 7, 2015 11:20 PM, "Jimmy Hess" wrote: > On Sun, Jun 7, 2015 at 7:28 AM, Stephen Satchell > wrote: > > On 06/07/2015 01:10 AM, Joshua Riesenweber wrote: [snip] > > What the industry could probably use most for entry-level certs is > a technical reading comprehension requirement on the certs, or a > requirement > of GRE scores e.g. 145 Verbal, 160 Math, before being able to obtain > the certs, to demonstrate an ability to read and understand documentation, > including BNF, and the ability to lookup something from a technical > manual, > read, understand, and apply it properly using qualified background > knowledge > at the level being certified. > > Too often, certs concentrate on trivial minutia that is "trivially > tested", but also not > frequently used, so the population has a bunch of people who just paid > copious $$$ for in-person coaching on _just the specifics of the exam_, > or people who memorized answers from stolen copies of exams. > > So even in that, many of the tests lose their ability, due to the > intervention of > 3rd party "learning providers" who are just making a quick buck training > candidates directly to exams, instead of teaching the subject. > > In short: In regards to the use of certifications when hiring --- they > can be used by > non-technical reviewers to help filter candidates, where there are > more applicants than > desired. Consider it a "bulk" filtering criteria that can be done > instantly without wasting > as much time, and the final filter might be an internal quiz and > human interviewers. > > > The certs are no definitive measure, but candidates with Both > experience and industry > certs to help confirm the quality of that experience are more likely > to be applicants worth > committing serious time to evaluate, And they can be used to help break > ties > between otherwise equal applicants in favor of those certified. > > > As to if it matters whether the certification is for Cisco equipment and > you > use X vendor equipment instead, I would refer to > semi-relevant link here: > http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa6506e2f35eaac > > > If Carpenters were hired like engineers.... > 'I see here, you have experience with cutting timber with "Makita and > Milwaukee brand Skillsaws" > Unfortunately, we need someone with 25 years experience using the > DeWalts.' > > Certifications can also be used by consultants/contractors to market > services, > or assure end customers that their services are by people "qualified > by the vendor > of their equipment". > > > > > The R&S CCIE lab exame is a timed practical exam, and as certification > tests > > goes it does a fair job measuring the ability of the candidate to > implement > > routers and switches to obtain certain results, ON CISCO EQUIPMENT. > (This > > is also true of the other Cisco certification tracks.) > > Correct. However, earning a certification such as CCIE demonstrates > that you are not > one of those clueless folks who completely lacks understanding and > ability to learn > basic config and troubleshooting. Earning the cert would require a > great deal of practice > due to their time limits, therefore the candidate that holds one > shows proof of > a certain level of dedication to advancement or learning within the field. > > And sufficient technical aptitude and ability to learn is implied by > the certificate to deal > with other vendor's equipment, even though Cisco's certifications only > address Cisco > equipment directly; there are many vendor-neutral concepts which should > have > been understood for success. > > > The specifics of configuration language and hardware are > "implementation details". > No certification measures a candidate's ability to quickly learn novel > configuration syntax > or special rules of arbitrary $new_vendor's equipment. > > > One can learn how to do almost anything. The real trick is being able to > > finish tasks quickly, and that's damn hard to do without practice, > practice, > > Ability to finish tasks *accurately* is what matters. > But very simple things should be done quickly. > > The results of non-repetitive tasks should always be looked at carefully > to help > validate accuracy,, > > And the practice required to do any tasks that are frequent and repetitive > should be gained by anyone qualified on the job fairly quickly. > > > That said, certifications show that the candidate can turn a wrench. It > > shows nothing about the candidate's ability to handle ARIN, to > troubleshoot > > political snafus, how to deal with management that is severely > > All of these are things that can be learned without a large amount of > grief, > you need reading comprehension; > ARIN's policies and tools are fairly well documented in writing. > > The candidate who can't even learn and pass a cert test might actually > be incapable of learning what is required on their own. > > It's not cost-effective to buy in-person training or certify for > *every little thing* that > comes up later. > > > clue-deficient, and most important play nice with colleagues at other > > -- > -JH > From ag4ve.us at gmail.com Tue Jun 9 02:34:09 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 8 Jun 2015 22:34:09 -0400 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> <5573CCE6.10203@cox.net> <557438E2.7010505@satchell.net> Message-ID: On Jun 8, 2015 10:11 PM, "Shane Ronan" wrote: > > Certs have ruined the industry. Certs have made the industry more interesting. After all, without certs, we'd have less stupid to point at and laugh (or scream). And HR screeners would need to know something about the position they're screening. From ryan.landry at gmail.com Tue Jun 9 02:40:58 2015 From: ryan.landry at gmail.com (ryanL) Date: Tue, 09 Jun 2015 02:40:58 +0000 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> <5573CCE6.10203@cox.net> <557438E2.7010505@satchell.net> Message-ID: i don't think certs have ruined the industry. bad interviewing and recruiting, maybe... asking encyclopedia-type "gotcha" questions are the most inane test of someone's ability to perform well at the job. i promise you - you didn't want to work for this person anyways. got a cert? great. but let's whiteboard a real-world problem and see how you do. i won't play you into a trap. On Mon, Jun 8, 2015 at 7:11 PM Shane Ronan wrote: > When I was asked the default BGP timers across three different vendor > platforms as measure of my networking ability during an interview, I > replied saying I'd look them up if needed them. > > I was told I didn't understand BGP in enough detail, despite being able to > describe all the steps of BGP session establishment and route exchange. > > Certs have ruined the industry. > From henson at acm.org Tue Jun 9 03:14:54 2015 From: henson at acm.org (Paul B. Henson) Date: Mon, 8 Jun 2015 20:14:54 -0700 Subject: Android (lack of) support for DHCPv6 Message-ID: <20150609031454.GD3716@bender.unx.cpp.edu> We're in the beginning steps of bringing up IPv6 at the fairly large university where I work. We plan to use DHCPv6 rather than SLAAC for a variety of reasons. One of our guys recently noticed that Android has no support for DHCPv6, and a rather odd issue thread discussing it: https://code.google.com/p/android/issues/detail?id=32621 It looks like one developer simply refuses to implement it because if he did there might be a scenario where somebody might not be able to tether 8-/? His attitude is that you have to use SLAAC and RDNSS, which we're just not going to do. At this point I guess Android devices just won't work with IPv6 on our network, and we'll suggest they complain to their vendor and/or get a different phone. I was just curious what this forum might think of that design decision and the discussion on the issue thread. Thanks... From randy at psg.com Tue Jun 9 03:19:08 2015 From: randy at psg.com (Randy Bush) Date: Mon, 08 Jun 2015 20:19:08 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150609031454.GD3716@bender.unx.cpp.edu> References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: > We're in the beginning steps of bringing up IPv6 at the fairly large > university where I work. We plan to use DHCPv6 rather than SLAAC for a > variety of reasons. One of our guys recently noticed that Android has no > support for DHCPv6, and a rather odd issue thread discussing it: > > https://code.google.com/p/android/issues/detail?id=32621 > > It looks like one developer simply refuses to implement it because if he > did there might be a scenario where somebody might not be able to tether > 8-/? His attitude is that you have to use SLAAC and RDNSS, which we're > just not going to do. At this point I guess Android devices just won't > work with IPv6 on our network, and we'll suggest they complain to their > vendor and/or get a different phone. > > I was just curious what this forum might think of that design decision > and the discussion on the issue thread. LC still has true religion. dump android. From sabri at cluecentral.net Tue Jun 9 03:56:15 2015 From: sabri at cluecentral.net (Sabri Berisha) Date: Mon, 8 Jun 2015 20:56:15 -0700 (PDT) Subject: eBay is looking for network heavies... In-Reply-To: References: <5573CCE6.10203@cox.net> <557438E2.7010505@satchell.net> Message-ID: <144489502.8448.1433822175180.JavaMail.zimbra@cluecentral.net> Hi, > Certs have ruined the industry. Certifications are great keywords for recruiters. If you're a hiring manager, why create a huge list of all routing protocols you'd like the ideal candidate to understand? Saying "I need a JNCIE with 5 years experience" is a lot easier than "the ideal candidate has an expert-level understanding of OSPF/ISIS, MPLS signaling protocols such as LDP and RSVP, BGP, IPv4/IPv6 and $vendor equipment. You get a bunch of resumes where you look for the experience needed for the position and off you go to do your phone screening. Those who are really experts will be able to pass the certification exams without too much trouble, and those who made it through 20 bootcamps prior to taking their 6th attempt at CCIE R&S before passing are easily weed out by a quick chat on the phone. That said, there is a constant devaluation when it comes to certifications. They start off as being very difficult and only achievable for the real experts, and then the makers get directed by the company to make them easier as too few people pass them. I was part of the development team for the IP certification track of a major telecommunications vendor. The entire team was actually surprised that people passed the professional level exams (2 required) and some even passed the expert level lab exam. They have since made it easier, after I left that company. The same happened with JNCIE. Initially it was a two day exam. Then one had to pass the one day JNCIP-M and the one day JNCIE-M exam. And now even the JNCIP is a written exam, with the JNCIE-SP being a lot easier (so I've been told). Anyway, out of experience I can recommend all of you looking for good network engineers to hire out of your extended network. Someone who comes recommended by someone that I respect will be on top of my list to get in for an interview. Thanks, Sabri JNCIE-M/SP #261 JNCSP-SP JNCIS-ER ECE-IPN #2 ECE-FB #2 (sorry, had to ;) From khelms at zcorum.com Tue Jun 9 04:57:43 2015 From: khelms at zcorum.com (Scott Helms) Date: Tue, 9 Jun 2015 00:57:43 -0400 Subject: PPPoE/IPoE, any recommendations for upgrade? In-Reply-To: References: <002a01d0a0e9$f04481b0$d0cd8510$@rasana.net> <002d01d0a1b2$aa587980$ff096c80$@rasana.net> Message-ID: There are alternative solutions. We're looking at using one from ABN for a customer that perseveres all of the AAA functionality and supports IPoE with the same integrationhooks as PPPoE and handles both at the same time to make transition easier. The project is being staged right now but anyone who wants to be kept in the loop in how it goes can contact me off list. On Jun 8, 2015 11:34 PM, "Colton Conor" wrote: > Suspend or shut down a user is easy, just disable their port on the DSLAM > or change their port to a VLAN that only allows them to access/pay their > bill. > > Going to PPPoE to IPoE increases the net throughput right? > > On Mon, Jun 8, 2015 at 1:16 AM, Nasser Heidari wrote: > > > > On Sun, 7 Jun 2015, Mikael Abrahamsson wrote: > > > > > > > - If you are already using IPoE, tell more why should I upgrade? > > > > > > The IPoE and IPoEoADSL I have done didn't need radius, didn't need BNG, > > didn't > > > need a lot of the complications you're talking about. It could > basically > > be realised in > > > any decent L3 switch as default gateway for the customers instead of > > needing BNG. > > > > > > So I'd say if you want to get full potential of IPoE you need to do > > simplification as > > > well, otherwise there is little use in doing the work if he only thing > > you > > want to > > > change is from IPoPPPoE to IPoE encapsulation and keep all the other > > stuff > > you're > > > doing. > > > > > > IPoPPPoE requires special CPE and router at your end to achieve high > > speeds, > > > because they need to support encapsulation/decapsulation of packets at > > whatever > > > speed you provide. The number of devices that do this is a lot smaller > > than the > > > ones that do decent speeds with just IPoE. > > > > > > So some people will say migrating to IPoE from IPoPPPoE buys them > > nothing, > > > because they feel they need all the mechanisms they currently use. > > > Greenfield deployments might say "hey, we can do this without a lot of > > the > > needed > > > mechanisms for IPoPPPoE" and save a lot of money and complication. > > > > > > -- > > > Mikael Abrahamsson email: swmike at swm.pp.se > > > > Thanks for your reply. I'm would like this simplicity if I could keep > same > > functionalities I have in PPPoE. By functionalities I mean: > > - AAA > > - Triple-ply services and classified accounting per service > > - Possibility to suspend a user service in case of over-quota > > - applying fair-share policies > > > > Do I have any option to have simplicity and same functionality together? > > > > Regards, > > Nasser > > > From list at satchell.net Tue Jun 9 05:34:56 2015 From: list at satchell.net (Stephen Satchell) Date: Mon, 08 Jun 2015 22:34:56 -0700 Subject: eBay is looking for network heavies... In-Reply-To: References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <969661F9-BB1D-4379-950D-B306AFC90033@mythostech.com> <861742673.531014.1433565345403.JavaMail.zimbra@snappytelecom.net> <5573CCE6.10203@cox.net> <557438E2.7010505@satchell.net> Message-ID: <55767B00.1070308@satchell.net> On 06/08/2015 07:34 PM, shawn wilson wrote: > On Jun 8, 2015 10:11 PM, "Shane Ronan" wrote: > >> >> Certs have ruined the industry. > > Certs have made the industry more interesting. After all, without certs, > we'd have less stupid to point at and laugh (or scream). And HR screeners > would need to know something about the position they're screening. > I think that some people here don't realize just who benefits from vendor-specific certifications. It's the *vendors*. It's why companies like Microsoft, Red Hat, Cisco, Juniper, &c spend the money to develop certification programs: to ensure there are a pool of people who can effectively use [some of] their products without having to call technical support all the time. Certification programs are expensive, time- and resource-intensive, and a pain to keep up to date as products mature and grow. The job is even more of a pain when large companies like Cisco end up buying other companies to add their products to the Cisco line to allow customers to solve particular problems and "stay in the family". It's like a tech business wanting to locate in places like San Jose, Cambridge, or Autin...because that's where they can find workers ready to slot into their game. Vendors like to have a large enough certified people so that management can feel comfortable buying vendor hardware and software -- it reduces risk for both customer *and* vendor. Reduced risks means more profits. For everyone. From A.L.M.Buxey at lboro.ac.uk Tue Jun 9 06:30:48 2015 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Tue, 9 Jun 2015 07:30:48 +0100 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150609031454.GD3716@bender.unx.cpp.edu> References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> 'We plan to use DHCPv6 rather than SLAAC for a variety of reasons' Care to elaborate on the reasons? Due to client support we have both. In fact we had SLAAC for many years and just 2 years ago we added DHCPv6 ..that was to ensure fuller client support (since windows and OSX amongst others started to support it) but also because of the ongoing slowness of our kit supporting the growing list of SLAAC extensions to provide DNS/NTP etc values :/ dual-stack since 2001. HE 'sage' ;) alan From morrowc.lists at gmail.com Tue Jun 9 06:35:50 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 9 Jun 2015 02:35:50 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: On Mon, Jun 8, 2015 at 11:19 PM, Randy Bush wrote: >> We're in the beginning steps of bringing up IPv6 at the fairly large >> university where I work. We plan to use DHCPv6 rather than SLAAC for a >> variety of reasons. One of our guys recently noticed that Android has no >> support for DHCPv6, and a rather odd issue thread discussing it: curious about the reasoning, for what is probably singular devices on a LAN ? From A.L.M.Buxey at lboro.ac.uk Tue Jun 9 06:59:52 2015 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Tue, 9 Jun 2015 07:59:52 +0100 Subject: eBay is looking for network heavies... In-Reply-To: <55762EF1.80509@mompl.net> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <55762EF1.80509@mompl.net> Message-ID: <44CF8D7A-91AA-4DB1-ABEB-927A6E20A9E4@lboro.ac.uk> 'Don't learn by heart that which you can look up.'.... apart from enough basics to get you up and connected so that you CAN look things up! ;) There's a whole debate about the education system and learning things by rote that can be looked up. In many sectors you have reference tomes. ..some MUST be reviewed before doing any work. I think there are some key advantages to knowing things when in the field BEFORE you then see the rest of the day go by while troubleshooting. You have to know eg the basics of OSPF to know what to look up when an adjacency doesn't come up. ..to be in 'the right ballpark' as they say :) alan From henson at acm.org Tue Jun 9 07:09:20 2015 From: henson at acm.org (Paul B. Henson) Date: Tue, 9 Jun 2015 00:09:20 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> Message-ID: <20150609070920.GE3716@bender.unx.cpp.edu> On Tue, Jun 09, 2015 at 07:30:48AM +0100, Alan Buxey wrote: > Care to elaborate on the reasons? Heh, there's a reason I said "variety" ;). Honestly, I'm like 90% systems and 10% network, our network guys could probably better explain all of the underlying thought process. My primary task on the deployment is standing up the DHCPv6 servers and IPv6-enabling our operating systems and applications. If you look at comment #101 on the issue thread, that's actually from one of of network admins briefly discussing some of the underlying rationale. From larrysheldon at cox.net Tue Jun 9 08:36:14 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 09 Jun 2015 03:36:14 -0500 Subject: Regulators now regulating Internet History? Really? In-Reply-To: References: <55756806.1000900@cox.net> Message-ID: <5576A57E.9080107@cox.net> On 6/8/2015 08:46, Jay Farrell via NANOG wrote: > The article is nothing more or less than what you'd expect to read from the > American Enterprise Institute. "All regulation totally sucks" is their only > message ever. Unaddressed so far, is the appearance that the regulator quoted (without apparent bias from the AEI author) has "tinkered" with the history. -- sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Tue Jun 9 08:50:26 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 09 Jun 2015 03:50:26 -0500 Subject: eBay is looking for network heavies... In-Reply-To: References: Message-ID: <5576A8D2.5060205@cox.net> I (sortakinda related to the as-drifted thread) was reminded today of another flag I watched for back in the day by something I saw on Facebook? today--people using words (especially big words) that do not mean what they think they do. http://www.sbnation.com/lookit/2015/6/8/8748933/pat-venditte-switch-pitcher-newspaper-headline-amphibious-pitcher I also think the biggest hurdle I faced was that HR did all the early interviewing from lists of questions and answers (sometimes) that we had to produce without regard to a specific opening. Towards the end of my days we were told that the candidate visit with us was not and interview, it was an opportunity for the candidate to see if she (or he) liked us. -- sed quis custodiet ipsos custodes? (Juvenal) From m4rtntns at gmail.com Tue Jun 9 09:11:25 2015 From: m4rtntns at gmail.com (Martin T) Date: Tue, 9 Jun 2015 12:11:25 +0300 Subject: most accurate geo-IP source to build country-based access lists In-Reply-To: <5575D436.60501@ispn.net> References: <26C02A6C-D40F-4C1C-9DA7-C3B13CBFE740@arbor.net> <5575D436.60501@ispn.net> Message-ID: John, > At a brute force country level it is possible to use the Delegated > ranges lists but that runs into the problem where IP ranges are > subnetted and allocated to other countries. Yeah. In addition, to illustrate the point in my initial post, sometimes inetnum objects contain more than one "country" attribute and only the first country code is inserted into RIR delegated list. For example: $ for deleg in $(wget -qO - ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-latest | grep ipv4 | cut -d '|' -f 4 | tail -10000); do > [[ $(whois -rh whois.ripe.net -T inetnum "$deleg") = *country:*country:* ]] && echo "$deleg" > done 193.104.217.0 193.110.48.0 193.111.228.0 193.218.114.0 194.33.109.0 194.34.64.0 194.42.56.0 194.150.168.0 194.153.74.0 195.14.23.0 195.39.208.0 195.85.254.0 195.95.150.0 195.158.230.0 $ Blake, > Have you thought about application layer tests - e.g. is the client's > character set/language set to Swedish? Has the user identified > himself/herself/henself as living in or being from Sweeden? Unfortunately I need this on network layer, i.e. it should work for other traffic besides HTTP/HTTPS. Anyway, thanks for all the replies! Martin From streiner at cluebyfour.org Tue Jun 9 12:01:28 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 9 Jun 2015 08:01:28 -0400 (EDT) Subject: eBay is looking for network heavies... In-Reply-To: <14A285AC-771D-4203-9661-EEC1B740F281@gmail.com> References: <1B4A7DD5-2325-4F12-BB15-353A862A7042@puck.nether.net> <4D6DA9E5-59C6-43C0-8EC1-C7E5B00EC26B@bromirski.net> <68F6B0FB-6064-4F18-A793-B6CEBCDCDD51@cdl.asgaard.org> <55762EF1.80509@mompl.net> <14A285AC-771D-4203-9661-EEC1B740F281@gmail.com> Message-ID: On Mon, 8 Jun 2015, Yardiel D. Fuentes wrote: > This discussion is always reminisced of questions such as: Why would I > want to learn Algebra or Calculus in college ? or why would I want to go > to college at all ? .. the student argues that calculus or college is > hardly ever used, if at all, in a job ? the most sensible perspective > has always been: It is not only about the knowledge itself, but how > learning those subjects train your mind to tackle technical > problems?same in networking? Some of the best interview questions > are those that pose a problem and ask you to tackle it by explaining > your train of thought?It requires both: knowledge and how to apply > it... Your point is well taken, but being asked to recite section 4.2.1 of RFC XXXX is: 1. little more than rote memorization 2. says nothing about a candidate's skills or critical thinking abilities. For the record, there are times in my professional career where I've made some use of algebra and calculus :) jms From ramy.ihashish at gmail.com Tue Jun 9 13:32:59 2015 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Tue, 9 Jun 2015 15:32:59 +0200 Subject: NANOG Digest, Vol 89, Issue 2 In-Reply-To: References: Message-ID: Does anybody knows anything about "AirTight networks" and "Meru"? From dwcarder at wisc.edu Tue Jun 9 13:58:55 2015 From: dwcarder at wisc.edu (Dale W. Carder) Date: Tue, 09 Jun 2015 08:58:55 -0500 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150609031454.GD3716@bender.unx.cpp.edu> References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: <20150609135855.GB14863@DOIT-2NW1MRFY-X.doit.wisc.edu> Thus spake Paul B. Henson (henson at acm.org) on Mon, Jun 08, 2015 at 08:14:54PM -0700: > We're in the beginning steps of bringing up IPv6 at the fairly large > university where I work. Ditto. > We plan to use DHCPv6 rather than SLAAC for a variety of reasons. Those reasons should probably be reviewed. The reality is that you will probably need to support slaac, dhcpv6, and rfc6106. "The nice thing about standards is that there are so many to choose from." Dale From morrowc.lists at gmail.com Tue Jun 9 14:14:08 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 9 Jun 2015 10:14:08 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150609070920.GE3716@bender.unx.cpp.edu> References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> Message-ID: On Tue, Jun 9, 2015 at 3:09 AM, Paul B. Henson wrote: > On Tue, Jun 09, 2015 at 07:30:48AM +0100, Alan Buxey wrote: > >> Care to elaborate on the reasons? > > Heh, there's a reason I said "variety" ;). Honestly, I'm like 90% systems > and 10% network, our network guys could probably better explain all of > the underlying thought process. My primary task on the deployment is > standing up the DHCPv6 servers and IPv6-enabling our operating systems > and applications. If you look at comment #101 on the issue thread, > that's actually from one of of network admins briefly discussing some of > the underlying rationale. it seems as though the large concern is: "network gear wont' hand out resolver data" you'll have v6 and v4 right? dual-stack would let you still get dns services over v4 while providing v6 transport as necessary/available. there seem to be some other largely un-numbered concerns about 'router management' ... but I'd submit that there are quite a few dual-stack networks out there (campus and wide-area and consumer) and we're not seeing this sort of problems supposed. -chris From listas at esds.com.br Tue Jun 9 14:23:24 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Tue, 9 Jun 2015 11:23:24 -0300 Subject: PPPoE/IPoE, any recommendations for upgrade? In-Reply-To: <002a01d0a0e9$f04481b0$d0cd8510$@rasana.net> References: <002a01d0a0e9$f04481b0$d0cd8510$@rasana.net> Message-ID: Junos OS Subscriber Management? http://www.juniper.net/documentation/en_US/junos13.1/information-products/pathway-pages/subscriber-access/index.html -- Eduardo Schoedler 2015-06-07 3:19 GMT-03:00 Nasser Heidari : > Hi, > > We are currently using PPPoE in our network. I have seen some articles > regarding migration of so-called legacy PPPoE to IPoE. After reviewing some > of them and implementing IPoE in lab environment using Cisco ASR I didn't > fine it that much beneficial to migrate whole system as I need to change a > lot of things. For example: > - I need to add it's support to our radius and obviously BSS system (E.g. > using NAS-PORT-ID instead of username). > - For the addressing part, as I have already using distributed BNG's, I > need to change some of our policies. (For example assigning address blocks > is much easier in PPPoE using framed-route) > - I need to change our customers CPE configuration to use Ethernet > encapsulation. > - I haven't used DHCP in large scale environment. > - I don't have any clear Idea/understanding regarding its > maintainability/troubleshooting and also security. > (Please add if I'm missing any other issue which may run into if I migrate > to IPoE) > > Although it has some benefits, I'm not sure if it's that essential to > migrate. > Would you please kindly? > - Share your Ideas/experiences/best practices in this regard? > - If you are already using IPoE, tell more why should I upgrade? > - Considering a DSL network with more than 800K customers using PPPoE, do > you recommend this migration? > > > Kind Regards, > Nasser > > -- Eduardo Schoedler From dhastings at crucialwebhost.com Tue Jun 9 03:17:22 2015 From: dhastings at crucialwebhost.com (Drew Hastings) Date: Mon, 8 Jun 2015 20:17:22 -0700 Subject: Assistance troubleshooting a route between my network and Comcast in Georgia Message-ID: I'm new to this list, and I apologize in advance if this is an inappropriate submission. I'm having an issue with my traffic routing between my network and Comcast in the Georgia region. Aside from this specific ISP and that geographic region, I haven't seen any issues with traffic. My network is 198.91.24.0/21 ASN 32647 Is there a particular contact to get in touch with someone at Comcast for assistance? What can I do, if anything, to resolve this from my end? Here is a successful traceroute, which doesn't originate from my network, going to a router I'd like to reach from my network. This network shares our upstream providers, which is why I've used it to compare. 4 te0-0-0-0.nr11.b023003-0.phx02.atlas.cogentco.com (38.88.34.21) 0.973 ms 1.013 ms te0-0-0-1.nr11.b023003-0.phx02.atlas.cogentco.com (38.104.116.73) 1.052 ms 5 154.24.18.197 (154.24.18.197) 2.200 ms 154.24.18.201 (154.24.18.201) 2.229 ms 154.24.18.205 (154.24.18.205) 0.926 ms 6 be2124.ccr21.phx02.atlas.cogentco.com (66.28.4.193) 2.360 ms 2.737 ms 2.809 ms 7 be2331.ccr22.lax01.atlas.cogentco.com (154.54.30.193) 12.796 ms be2330.ccr21.lax01.atlas.cogentco.com (154.54.30.189) 14.156 ms 14.120 ms 8 be2019.ccr21.lax04.atlas.cogentco.com (154.54.88.10) 14.109 ms 13.642 ms be2017.ccr21.lax04.atlas.cogentco.com (154.54.0.237) 13.916 ms 9 be-201-pe01.losangeles.ca.ibone.comcast.net (50.248.118.249) 15.341 ms 15.304 ms 15.290 ms 10 he-0-4-0-1-cr02.losangeles.ca.ibone.comcast.net (68.86.85.29) 13.283 ms he-0-4-0-0-cr02.losangeles.ca.ibone.comcast.net (68.86.85.13) 13.119 ms he-0-4-0-1-cr02.losangeles.ca.ibone.comcast.net (68.86.85.29) 13.238 ms 11 be-11315-cr01.dallas.tx.ibone.comcast.net (68.86.85.141) 38.441 ms 38.433 ms 38.354 ms 12 be-11314-cr02.56marietta.ga.ibone.comcast.net (68.86.85.22) 55.604 ms 56.516 ms 57.727 ms 13 et-2-0-0-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.89.66) 55.706 ms 54.596 ms 54.688 ms 14 xe-10-3-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.86.106.58) 54.073 ms 54.066 ms xe-11-3-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.86.106.90) 54.607 ms 15 xe-9-3-0-sur02.a2atlanta.ga.atlanta.comcast.net (68.86.110.233) 54.793 ms 55.331 ms 55.320 ms The traceroute reaches 68.86.110.233 successfully without issue. That same traceroute, from my network takes a similar route, but ultimately fails: 6 te0-0-1-1.nr11.b023003-0.phx02.atlas.cogentco.com (38.104.116.185) 0.789 ms 0.720 ms te0-0-0-0.nr11.b023003-0.phx02.atlas.cogentco.com (38.88.34.21) 0.688 ms 7 154.24.18.201 (154.24.18.201) 2.295 ms 2.288 ms 154.24.18.205 (154.24.18.205) 1.062 ms 8 be2125.ccr22.phx02.atlas.cogentco.com (154.54.1.101) 1.248 ms 1.618 ms be2124.ccr21.phx02.atlas.cogentco.com (66.28.4.193) 2.601 ms 9 be2331.ccr22.lax01.atlas.cogentco.com (154.54.30.193) 13.444 ms be2330.ccr21.lax01.atlas.cogentco.com (154.54.30.189) 14.857 ms 13.868 ms 10 be2017.ccr21.lax04.atlas.cogentco.com (154.54.0.237) 13.942 ms be2019.ccr21.lax04.atlas.cogentco.com (154.54.88.10) 15.295 ms be2017.ccr21.lax04.atlas.cogentco.com (154.54.0.237) 13.176 ms 11 be-201-pe01.losangeles.ca.ibone.comcast.net (50.248.118.249) 14.048 ms 11.872 ms 11.864 ms 12 he-0-4-0-2-cr02.losangeles.ca.ibone.comcast.net (68.86.85.93) 14.454 ms he-0-4-0-1-cr02.losangeles.ca.ibone.comcast.net (68.86.85.29) 14.267 ms he-0-4-0-2-cr02.losangeles.ca.ibone.comcast.net (68.86.85.93) 12.086 ms 13 be-11315-cr01.dallas.tx.ibone.comcast.net (68.86.85.141) 35.729 ms 35.723 ms 39.375 ms 14 * * * 15 * * * 16 * * * A traceroute back to my network on Comcast in that region fails in a similar fashion: 1 <1 ms 1 ms 1 ms 192.168.10.1 2 29 ms 8 ms 10 ms 96.120.4.213 3 10 ms 7 ms 9 ms xe-5-1-0-sur01.b2marietta.ga.atlanta.comcast.net [68.85.173.93] 4 11 ms 13 ms 12 ms xe-4-1-18-0-ar01.b0atlanta.ga.atlanta.comcast.ne t [68.86.106.190] 5 16 ms 19 ms 17 ms he-0-4-0-6-cr02.56marietta.ga.ibone.comcast.net [68.86.90.81] 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. It seems like xe-5-1-0-sur01.b2marietta.ga.atlanta.comcast.net is not routing this traffic. I appreciate any assistance that can be provided. Thank you for taking the time to read this. From ggrammel at juniper.net Tue Jun 9 14:24:32 2015 From: ggrammel at juniper.net (Gert Grammel) Date: Tue, 9 Jun 2015 14:24:32 +0000 Subject: 100G DWDM FEC standard Message-ID: Hi Mikael, >From a standards perspective keep in mind that http://www.stupi.se/Standards/100G-long-haul4.pdf is not approved - but we are working hard on it. OTOH having a reference implementation at hand, is an accelerator that helps a lot. Let me also add some color to your email as the current interoperability situation in WDM is quite funny. Sometimes transceivers of the same vendor can't talk to each other, as they are based on a different generation of ASICs and therefore FEC implementations. In other words, vendors typically have more than only one secret sauce they cook with, and different sauces do not blend well :-) . Perhaps transport folks are already too used to deal with such kind of issues that no one laments anymore. On the other hand perhaps, the networking industry is already so used to Ethernet where interoperability is a no-brainer, that it is difficult to imagine what it means to deal with a technology that prevents multi-vendor interop. To confirm your final point: Interoperability is on the top of the shopping lists for the networking industry. Gert email : ggrammel at juniper.net --------------------------------------- Date: Fri, 5 Jun 2015 17:53:58 +0200 (CEST) From: Mikael Abrahamsson To: nanog at nanog.org Subject: 100G DWDM FEC standard Message-ID: Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Hi, I just watched the "evolution of ethernet speeds" presentation from NANOG meeting. There was a statement that there was "vendor secret sauce" in the 100G DWDM space. Yes, that is true, but: http://www.stupi.se/Standards/100G-long-haul4.pdf There actually is a standard for 100G DWDM that has support from multiple router vendors. When you buy new gear, make sure your vendors support the above standard, so we can connect our routers over longer distances between vendors, without needing transponders. We in the Deutsche Telecom Terastream project have Huawei, Cisco, Juniper and ALU routers that natively (DWDM colored interfaces in the routers) talk directly to each other over 1500 km amplified DWDM system (no transponders), and we can also talk from these routers interfaces to Cisco and ALU transponders if we want to. https://jeffloughridge.wordpress.com/2013/10/16/peter-lothbergs-terastream-presentation-at-ripe-67/ if you want to know more about the project. Next time you purchase 100G DWDM equipment, make sure you buy equipment that follows this standard to be certain that it interoperates to combat vendor "secret sauce". -- Mikael Abrahamsson email: swmike at swm.pp.se From roll at Stupi.SE Tue Jun 9 16:46:45 2015 From: roll at Stupi.SE (Peter Lothberg) Date: Tue, 9 Jun 2015 16:46:45 CEST Subject: 100G DWDM FEC standard In-Reply-To: Message-ID: > From a standards perspective keep in mind that > http://www.stupi.se/Standards/100G-long-haul4.pdf is not approved - > but we are working hard on it. OTOH having a reference > implementation at hand, is an accelerator that helps a lot. There is a whole industry that do not want it to be plug and play... (The ones that do not make routers or switches..) > Let me also add some color to your email as the current > interoperability situation in WDM is quite funny. Sometimes > transceivers of the same vendor can't talk to each other, as they > are based on a different generation of ASICs and therefore FEC > implementations. In other words, vendors typically have more than > only one secret sauce they cook with, and different sauces do not > blend well :-) . Perhaps transport folks are already too used to > deal with such kind of issues that no one laments anymore. On the > other hand perhaps, the networking industry is already so used to > Ethernet where interopera bility is a no-brainer, that it is > difficult to imagine what it means to deal with a technology that > prevents multi-vendor interop. All vendors have secret souce for 100G SD-FEC, and just the fact that you can wire the wire the differential encoding eight ways.. That;s why we settled on a HD-FEC that can be inside the DSP-Asic or inline after it. All to us known DSP implementations supports this with more, less or no extra logic. And the logic is free and fully documented. > To confirm your final point: > Interoperability is on the top of the shopping lists for the > networking industry. Amen! -P From jabley at hopcount.ca Tue Jun 9 15:13:56 2015 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 09 Jun 2015 11:13:56 -0400 Subject: most accurate geo-IP source to build country-based access lists In-Reply-To: References: <26C02A6C-D40F-4C1C-9DA7-C3B13CBFE740@arbor.net> <5575D436.60501@ispn.net> Message-ID: <182A7A20-1BB8-4349-A5DE-88E83DB34E1E@hopcount.ca> On 9 Jun 2015, at 5:11, Martin T wrote: >> At a brute force country level it is possible to use the Delegated >> ranges lists but that runs into the problem where IP ranges are >> subnetted and allocated to other countries. > > Yeah. I would say that a perfectly accurate mapping of address to anything geographical (with more accuracy than "it's within the observed universe, somewhere") is unlikely ever to exist, except by accident and for short periods of time. Accuracy and lack of authoritative sources of data is one reason, constant uncoordinated reconfiguration is another. You need to decide how accurate your mapping needs to be (and figure out how to measure that, if accuracy is important). Another part of the problem is framing the question in a useful way: a universal solution seems intractable when the following questions are answered differently (but accurately) by different people who have different needs. Is a device in Uganda connected via satphone to a router in France in Uganda, or France? Is a network in Fiji that can't talk to any other networks in Fiji without leaving the island but is one layer-3 hop away from Australia in Fiji, or Australia? Does the source address of a packet always identify the device that sent the packet? If I'm in region A and you're in region A, and you route within region to me but my replies leave the region on the way back, are we in the same region from my perspective? How about yours? Even: if I'm in region A but I'm using a DNS resolver in region B, am I in region A or region B? Joe From victor at jvknet.com Tue Jun 9 15:14:02 2015 From: victor at jvknet.com (Victor Kuarsingh) Date: Tue, 09 Jun 2015 11:14:02 -0400 Subject: Looking for information on IGP choices in dual-stack networks Message-ID: <557702BA.2070004@jvknet.com> Nanog Folks: Philip Matthews and I are co-authors on an active draft within the IETF related to IPv6 routing design choices. To ensure we are gathering sufficient data we are looking for an expanded set of input from operator forums as well (vs. just the v6ops IETF list). The draft is found here -(https://tools.ietf.org/html/draft-ietf-v6ops-design-choices). We are looking for information on the IGP combinations people are running in their dual-stack networks. We are gathering this information so we can document in our draft which IGP choices are known to work well (i.e., people actually run this combination in production networks without issues). The draft will not name names, but just discuss things in aggregate: for example, "there are 3 large and 2 small production networks that run OSPF for IPv4 and IS-IS for IPv6, thus that combination is judged to work well". If you have a production dual-stack network, then we would like to know which IGP you use to route IPv4 and which you use to route IPv6. We would also like to know roughly how many routers are running this combination. Feel free to share any successes or concerns with the combination as well. We are looking particularly at combinations of the following IGPs: IS-IS, OSPFv2, OSPFv3, EIGRP. If you run something else (RIP?) then we would also like to hear about this, though we will likely document these differently. [We suspect you run RIP/RIPng only at the edge for special situations, but feel free to correct us]. And if you have one of those modern networks that carries dual-stack customer traffic in a L3VPN or similar and thus don?t need a dual-stacked core, then please email us and brag ... If you are on multiple lists at RIPE, NANOG or the IETF, we appologize for any redundant emails you may get (we are just attempting to reach the widest audience possible). Philip Matthews Victor Kuarsingh From matthew at matthew.at Tue Jun 9 16:22:49 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 09 Jun 2015 09:22:49 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: <557712D9.4080605@matthew.at> On 6/8/2015 11:35 PM, Christopher Morrow wrote: > On Mon, Jun 8, 2015 at 11:19 PM, Randy Bush wrote: >>> We're in the beginning steps of bringing up IPv6 at the fairly large >>> university where I work. We plan to use DHCPv6 rather than SLAAC for a >>> variety of reasons. One of our guys recently noticed that Android has no >>> support for DHCPv6, and a rather odd issue thread discussing it: > curious about the reasoning, for what is probably singular devices on a LAN ? Lack of RDNSS support in Windows? That's the complication on my IPv6-only network. Matthew Kaufman From jcurran at arin.net Tue Jun 9 16:23:02 2015 From: jcurran at arin.net (John Curran) Date: Tue, 9 Jun 2015 16:23:02 +0000 Subject: =?Windows-1252?Q?RFP_for_Internet_Transit_for_ARIN_ASN_394018_(1GB_Wowrac?= =?Windows-1252?Q?k=92s_datacenter_located_in_Tukwila,_Seattle)?= References: <55770D4B.4000406@arin.net> Message-ID: Hello NANOG Folks - Apologies for the distraction, but ARIN needs some transit providers and I thought there may be one or two on this list... We need 1 GB via standard multi-mode fiber in Wowrack/Seattle - ISP must provide native IPv4 and IPv6 connectivity, provide full view of the IPv4 and IPv6 routing table, support 32-bit ASNs, etc. If interested, please review the full RFP for details and response information. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] RFP for Internet Transit for ARIN ASN 394018 Date: June 9, 2015 at 8:59:07 AM PDT To: > ARIN is soliciting proposals from Internet Service Providers (ISPs) to bid on the delivery of Internet transit to ARIN's network, ASN 394018. This network is part of ARIN's provisioning network and is a part of critical Internet infrastructure. ARIN is looking for qualified providers that are able to provide service to its rack within Wowrack's datacenter located in Tukwila, Seattle. All contractual terms and conditions related to the work performed, nondisclosure of information, or liability issues must be detailed. ARIN will require that the vendor performing this service sign a nondisclosure agreement due to the proprietary nature of the information ARIN retains for its subscribers. All proposals must be submitted no later than 5:00 p.m. EDT on 22 June 2015. ARIN will evaluate the properly submitted proposals and will select a winning bidder or bidders no later than 30 June 2015. Full text of the RFP is available at: http://www.arin.net/about_us/contracts/201506-westcoast-transit-rfp-sea.pdf Send proposals to rfp-transit-sea at arin.net or by mail to: Matt Rowley Infrastructure Manager ARIN 3635 Concorde Parkway, Suite 200 Chantilly, VA. 20151 ATTN: Proposal for Internet Transit Services Technical questions may be directed to: rfp-transit-sea at arin.net ARIN is operated as a nonprofit 501(c)(6) corporation which is chartered for educational, charitable, and scientific purposes. It is a membership organization with an official IRS designation as a business league. ___________ From johnl at iecc.com Tue Jun 9 16:27:11 2015 From: johnl at iecc.com (John Levine) Date: 9 Jun 2015 16:27:11 -0000 Subject: grepcidr 2.99 Message-ID: <20150609162711.1759.qmail@ary.lan> I've updated grepcidr again, adding some code contributed by a user. (This open source thing may actually have a future.) grepcidr is what it sounds like, you give it a bunch of CIDR ranges, and files to read, and it prints out the lines in the files that contain addresses that match any of the CIDR ranges. The new feature lets it match CIDR ranges in the input files as well as IP addresses. It handles both IPv4 and IPv6. It maps each file into memory and runs a state machine over the file in one pass so it's quite fast. There should be no limits on line length, file size, or number of patterns other than running out of memory. Find it here: http://www.taugh.com/grepcidr-2/ Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From owen at delong.com Tue Jun 9 16:40:10 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 9 Jun 2015 09:40:10 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <557712D9.4080605@matthew.at> References: <20150609031454.GD3716@bender.unx.cpp.edu> <557712D9.4080605@matthew.at> Message-ID: <8A9BCCF3-7381-4C4C-B87A-ABDC64678C96@delong.com> > On Jun 9, 2015, at 09:22 , Matthew Kaufman wrote: > > On 6/8/2015 11:35 PM, Christopher Morrow wrote: >> On Mon, Jun 8, 2015 at 11:19 PM, Randy Bush wrote: >>>> We're in the beginning steps of bringing up IPv6 at the fairly large >>>> university where I work. We plan to use DHCPv6 rather than SLAAC for a >>>> variety of reasons. One of our guys recently noticed that Android has no >>>> support for DHCPv6, and a rather odd issue thread discussing it: >> curious about the reasoning, for what is probably singular devices on a LAN ? > > Lack of RDNSS support in Windows? That's the complication on my IPv6-only network. > > Matthew Kaufman As a general rule, Windows is a significant complication on any network forced to deal with its users. This is not limited to IPv6. Owen From rps at maine.edu Tue Jun 9 18:20:56 2015 From: rps at maine.edu (Ray Soucy) Date: Tue, 9 Jun 2015 14:20:56 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150609031454.GD3716@bender.unx.cpp.edu> References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: It really is too bad. They're literally the only major player not on board but claim to champion IPv6. There is a big difference between saying that something isn't supported and the Android position that they will NOT support DHCPv6. To me, that's something that shouldn't be a decision they get to make, especially when other operating systems have already come around with DHCPv6 support. Very frustrating, and quite frankly an embarrassment to Google. I really didn't expect that kind of dismissive response out of Lorenzo but maybe I just haven't been paying attention. Clients should support a verity of methods and let network operators choose the solution that fits the environment. The whole premise for not supporting DHCPv6 seems to be that mobile networks don't need it, but that totally ignores 802.11 which is equally important. Not to single out Google, on the opposite side It's equally disappointing that Windows 10 will not support RDNSS (at least I haven't been able to find any information on it, has anyone been able to confirm?). I would hope we're past the religious arguments of SLAAC vs DHCPv6 but it seems like every time the topic comes up the entire conversation turns into a holy war on what method is the best. They're both valid, and both useful. On Mon, Jun 8, 2015 at 11:14 PM, Paul B. Henson wrote: > We're in the beginning steps of bringing up IPv6 at the fairly large > university where I work. We plan to use DHCPv6 rather than SLAAC for a > variety of reasons. One of our guys recently noticed that Android has no > support for DHCPv6, and a rather odd issue thread discussing it: > > https://code.google.com/p/android/issues/detail?id=32621 > > It looks like one developer simply refuses to implement it because if he > did there might be a scenario where somebody might not be able to tether > 8-/? His attitude is that you have to use SLAAC and RDNSS, which we're > just not going to do. At this point I guess Android devices just won't > work with IPv6 on our network, and we'll suggest they complain to their > vendor and/or get a different phone. > > I was just curious what this forum might think of that design decision > and the discussion on the issue thread. > > Thanks... > > -- 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 A.L.M.Buxey at lboro.ac.uk Tue Jun 9 18:53:28 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Tue, 9 Jun 2015 18:53:28 +0000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: <20150609185328.GA21078@lboro.ac.uk> Hi, > supporting DHCPv6 seems to be that mobile networks don't need it, but that > totally ignores 802.11 which is equally important. ...and what about 802.3 for those Android boxes/systems on the wired? :-) > I would hope we're past the religious arguments of SLAAC vs DHCPv6 but it > seems like every time the topic comes up the entire conversation turns into > a holy war on what method is the best. They're both valid, and both useful. agreed....too many times I find out that DHCPv6 is chosen as a stateful method because they want to record/track MAC addresses like they do for DHCP.... a little bit of explaining the protocol differences and they soon take up the SLAAC ;-) alan From randy at psg.com Tue Jun 9 19:17:15 2015 From: randy at psg.com (Randy Bush) Date: Tue, 09 Jun 2015 12:17:15 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150609070920.GE3716@bender.unx.cpp.edu> References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> Message-ID: i love this discussion. another enterprise wants to use ipv4 with minimal change from ipv4, has problems, and the usual suspects tell them to drink koolaid. and we wonder at the pitiful ipv6 deployment. randy From randy at psg.com Tue Jun 9 19:21:46 2015 From: randy at psg.com (Randy Bush) Date: Tue, 09 Jun 2015 12:21:46 -0700 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: <557702BA.2070004@jvknet.com> References: <557702BA.2070004@jvknet.com> Message-ID: > If you have a production dual-stack network, then we would like to know > which IGP you use to route IPv4 and which you use to route IPv6. in one network, both ospfs. in another is-is. i recommend the latter. > We would also like to know roughly how many routers are running this > combination. lots randy From job at instituut.net Tue Jun 9 20:18:07 2015 From: job at instituut.net (Job Snijders) Date: Tue, 9 Jun 2015 22:18:07 +0200 Subject: Fwd: PeeringDB 2.0 Rollout And Governance Announcement Message-ID: <20150609201807.GZ94733@Vurt.local> [ Forwarding today's announcement, apologies for duplicates ] --------------- Hi Everyone! PeeringDB is rolling our the first major revision since its inception, PeeringDB 2.0. This email will explain the basics, and how you can learn more information if you are interested. Future Communication ------------------------------------------------------------ Before we begin, we should note one of the major changes is the way in which PeeringDB will be announcing future enhancements, changes, maintenance windows, and other information. In the future, if you would like to be notified of certain events, or participate in discussions, please subscribe to one of the following email lists. The URL will be added to the main PeeringDB page in case you lose this email. * PeeringDB Announce (http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce) All PeeringDB administrative information, such as upgrades, maintenances, outages, etc. * PeeringDB Governance (http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-gov) Discussion list for PeeringDB governance issues. This is a community-based effort, the community?s input will help guide the future of the PeeringDB (as it has always done). * PeeringDB Technical (http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech) Discussion of the back end of PeeringDB & other technical topics. * PeeringDB User-Discuss (http://lists.peeringdb.com/cgi-bin/mailman/listinfo/user-discuss) All other list traffic. Our goal is to give you all the information you want, and no more. Please subscribe to any of these lists you feel are appropriate, or none. You will still be able to use the database even if you are not subscribed to any lists. PeeringDB 2.0 Beta! ------------------------------------------------------------ If you would like to try PeeringDB 2.0 now, please visit beta.peeringdb.com (https://beta.peeringdb.com/) . Documentation is available at beta.peeringdb.com/docs/ to assist with the transition and introduce you to the new API. Should you find bugs please report them on Github (https://github.com/peeringdb/1to2/issues) . PeeringDB Governance Announcement ------------------------------------------------------------ It has been suggested that the PeeringDB be moved under one of the existing community organizations currently in place. After some internal soul searching, discussion with some of those organizations, and discussion with PeeringDB users in person, at conferences, and over email, PeeringDB has decided to remain an independent entity. To ensure the DB?s continued operation with the community?s best interests squarely in mind and shepherd the future development of the DB, the PeeringDB is choosing a board of directors. The initial, interim board was announced during the Peering Track of NANOG 64, June 3, 2015. An election by the PeeringDB community to replace the initial board will be held prior to August 1st, 2016. If you are interested in governance, including running for the board, please join the PeeringDB Governance email list. The times and method of voting for the board as well as other governance topics will be announced on that list, and only on that list. PeeringDB 2.0 Rollout Timeline ------------------------------------------------------------ August 1, 2015: PeeringDB 2.0 will be brought online. The https://www.peeringdb.com/ URL will direct users to the new instance, and access to the old UI will be discontinued. The old SQL access and nightly dumps will continue for a month to ensure transition time for those using the old schema. September 1, 2015: SQL Access to the old PeeringDB 1.0 database will be discontinued. If you would like to be notified of each step as it is happening, as well as future changes to the DB, please subscribe to the PeeringDB Announce list. Questions & Comments ------------------------------------------------------------ If you have any questions, please email admin at PeeringDB.com Kind regards, The PeeringDB Admins From morrowc.lists at gmail.com Tue Jun 9 20:23:01 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 9 Jun 2015 16:23:01 -0400 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: References: <557702BA.2070004@jvknet.com> Message-ID: On Tue, Jun 9, 2015 at 3:21 PM, Randy Bush wrote: >> If you have a production dual-stack network, then we would like to know >> which IGP you use to route IPv4 and which you use to route IPv6. > > in one network, both ospfs. in another is-is. i recommend the latter. > >> We would also like to know roughly how many routers are running this >> combination. why is the question /routers/ and not /networks/ ? (which is still sort of nutty since your reasonable choices for 'dual stack capable' are: ospf/ospf3 || isis) > lots > > randy From A.L.M.Buxey at lboro.ac.uk Tue Jun 9 20:24:58 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Tue, 9 Jun 2015 20:24:58 +0000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> Message-ID: <20150609202458.GA21839@lboro.ac.uk> Hi, > and we wonder at the pitiful ipv6 deployment. if more network admins actually did network stuff then IPv6 deployment would be plentiful and we could even start the discussion about turning off IPv4.... ;-) alan From jmaslak at antelope.net Tue Jun 9 20:27:31 2015 From: jmaslak at antelope.net (Joel Maslak) Date: Tue, 9 Jun 2015 14:27:31 -0600 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> Message-ID: Agreed - apparently the solution is to implement SLAAC + DNS advertisements *AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and you need DHCPv6 for Windows. Am I the only one that thinks this situation is stupid? On Tue, Jun 9, 2015 at 1:17 PM, Randy Bush wrote: > i love this discussion. another enterprise wants to use ipv4 with > minimal change from ipv4, has problems, and the usual suspects tell > them to drink koolaid. > > and we wonder at the pitiful ipv6 deployment. > > randy > From jabley at hopcount.ca Tue Jun 9 20:36:56 2015 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 09 Jun 2015 16:36:56 -0400 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: References: <557702BA.2070004@jvknet.com> Message-ID: On 9 Jun 2015, at 16:23, Christopher Morrow wrote: > On Tue, Jun 9, 2015 at 3:21 PM, Randy Bush wrote: >>> If you have a production dual-stack network, then we would like to know >>> which IGP you use to route IPv4 and which you use to route IPv6. >> >> in one network, both ospfs. in another is-is. i recommend the latter. >> >>> We would also like to know roughly how many routers are running this >>> combination. > > why is the question /routers/ and not /networks/ ? Routers makes more sense to me than networks (IGP, so one network, right?) Joe From A.L.M.Buxey at lboro.ac.uk Tue Jun 9 20:38:37 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Tue, 9 Jun 2015 20:38:37 +0000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> Message-ID: <20150609203837.GC21839@lboro.ac.uk> Hi, > Agreed - apparently the solution is to implement SLAAC + DNS advertisements > *AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and > you need DHCPv6 for Windows. Windows has been dealing with SLAAC for ages...and OSX... DHCPv6 is relatively new in that arena... however in IPv6 your routers are sending RAs and can easily do prefix annoucements etc anyway so SLAAC makes quite a bit of sense...allowing the network to be more dynamic...no more having a gateway address stuck in a DHCP config and all those statically addressed clients needing to be changed etc. i think we're looking at the wrong place...the issue isnt handing out addresses.....its the large gaps in IPv6 functionality at the edge versus whats in IPv4 space.... DHCP snooping, DAI, ARP flood protection etc are getting pretty standard and solid... FHS (first hop security) for IPv6 at the edge is often left wanting (RA guard, ND/DAD protection etc)... but hey, we could get quite active about the lack of multicast adoption across the internet too! ;-) alan From dclements at gmail.com Tue Jun 9 20:40:13 2015 From: dclements at gmail.com (Doug Clements) Date: Tue, 9 Jun 2015 16:40:13 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> Message-ID: On Tue, Jun 9, 2015 at 4:27 PM, Joel Maslak wrote: > Agreed - apparently the solution is to implement SLAAC + DNS advertisements > *AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and > you need DHCPv6 for Windows. > > Am I the only one that thinks this situation is stupid? > If you think this is stupid, look in to the situation for modern WiFi and Android. https://code.google.com/p/android/issues/detail?id=17972 https://code.google.com/p/android/issues/detail?id=59502 https://code.google.com/p/android/issues/detail?id=62076 Summary: - No 802.11k (though 802.11r in barely new devices) - No DFS Channel support in Nexus-branded units, due to Google's resistance to certification. - Most WPA2-Enterprise schemes are sullied with warnings about traffic being monitored as a response to private CAs being installed. Windows support for enterprise features is downright stellar in comparison. --Doug From swmike at swm.pp.se Tue Jun 9 20:43:27 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 9 Jun 2015 22:43:27 +0200 (CEST) Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> Message-ID: On Tue, 9 Jun 2015, Joel Maslak wrote: > Agreed - apparently the solution is to implement SLAAC + DNS advertisements > *AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and > you need DHCPv6 for Windows. > > Am I the only one that thinks this situation is stupid? You don't need to hand out addresses by means of DHCPv6 IA_NA to windows, it does A=1 mode for SLAAC just fine. There is a big difference between handing out resolver, ntp-server, dns search domains etc by means of DHCPv6, and handing out addresses based on DHCPv6 (stateless vs stateful). >From what I have understood Android has made design decisions that means some things will break if you would only give is a single IPv6 address. This is most likely what some operators want to achieve when they say they want to use DHCPv6 IA_NA. In order to actually solve the problem they're trying to solve, you need SAVI (https://tools.ietf.org/wg/savi/) and 802.1x (or similar mechanism) in order to actually gain the control these people are looking for. My question, do they implement this on IPv4? -- Mikael Abrahamsson email: swmike at swm.pp.se From jared at puck.nether.net Tue Jun 9 20:46:11 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 9 Jun 2015 16:46:11 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> Message-ID: <9549F6DE-77F4-45B2-B3A6-14754748F871@puck.nether.net> > On Jun 9, 2015, at 4:40 PM, Doug Clements wrote: > > - Most WPA2-Enterprise schemes are sullied with warnings about traffic > being monitored as a response to private CAs being installed. I had this issue at the last NANOG meeting, I sometimes share my wifi with an embedded platform connected off my ethernet port, but I would get a message about how the Enterprise had disabled it. It wasn?t that important as in theory I could have the device join the local wifi directly but it would have been nice to not get that message from the network or the OS. - Jared From Valdis.Kletnieks at vt.edu Tue Jun 9 20:49:33 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 09 Jun 2015 16:49:33 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: Your message of "Tue, 09 Jun 2015 14:27:31 -0600." References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> Message-ID: <19330.1433882973@turing-police.cc.vt.edu> On Tue, 09 Jun 2015 14:27:31 -0600, Joel Maslak said: > Agreed - apparently the solution is to implement SLAAC + DNS advertisements > *AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and > you need DHCPv6 for Windows. > > Am I the only one that thinks this situation is stupid? It's indeed sub-optimal. But that situation is far from the stupidest thing we've inflicted on ourselves, and we've more or less survived them. (I'm sure that we all have our diverging lists of "3 things stupider than SLACC/DHCPv6" - this industry is old enough now to have quite the closet full of stupidity skeletons....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jared at puck.nether.net Tue Jun 9 20:51:51 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 9 Jun 2015 16:51:51 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> Message-ID: > On Jun 9, 2015, at 4:43 PM, Mikael Abrahamsson wrote: > > On Tue, 9 Jun 2015, Joel Maslak wrote: > >> Agreed - apparently the solution is to implement SLAAC + DNS advertisements >> *AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and >> you need DHCPv6 for Windows. >> >> Am I the only one that thinks this situation is stupid? > > You don't need to hand out addresses by means of DHCPv6 IA_NA to windows, it does A=1 mode for SLAAC just fine. > > There is a big difference between handing out resolver, ntp-server, dns search domains etc by means of DHCPv6, and handing out addresses based on DHCPv6 (stateless vs stateful). > >> From what I have understood Android has made design decisions that means > some things will break if you would only give is a single IPv6 address. This is most likely what some operators want to achieve when they say they want to use DHCPv6 IA_NA. > > In order to actually solve the problem they're trying to solve, you need SAVI (https://tools.ietf.org/wg/savi/) and 802.1x (or similar mechanism) in order to actually gain the control these people are looking for. My question, do they implement this on IPv4? It?s way more fun to fight about it when NDP and DHCPv4 were coming of age at the same time, and DHCP was seen as only a minor upgrade to BootP at the time. The IPv6 purists seem to think that DHCP == NAT == EVIL at times which is frustrating. The result is we have both M=0, M=1, etc.. options and something can be sent via NDP or DHCP, including possible DHCP-PD in conjunction. The reality is I need things to ?just work?. It was interesting to inherit someones half-done IPv6 implementation on our VPN platform, they didn?t understand that proxy-arp didn?t really exist in IPv6 land and the block had to be routed to the VPN box. There are many minor and subtle differences in these technologies which become obvious when some time is spent digging through them. - Jared From morrowc.lists at gmail.com Tue Jun 9 21:00:49 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 9 Jun 2015 17:00:49 -0400 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: References: <557702BA.2070004@jvknet.com> Message-ID: On Tue, Jun 9, 2015 at 4:36 PM, Joe Abley wrote: > > > On 9 Jun 2015, at 16:23, Christopher Morrow wrote: > >> On Tue, Jun 9, 2015 at 3:21 PM, Randy Bush wrote: >>>> If you have a production dual-stack network, then we would like to know >>>> which IGP you use to route IPv4 and which you use to route IPv6. >>> >>> in one network, both ospfs. in another is-is. i recommend the latter. >>> >>>> We would also like to know roughly how many routers are running this >>>> combination. >> >> why is the question /routers/ and not /networks/ ? > > Routers makes more sense to me than networks (IGP, so one network, right?) that confuses me, the logic I mean... I suppose in a single network I'd expect to see one igp for an address family (ospf or ospfv3). Not "eastcoast devices do ospf (stodgy bastards!) and westcoast goes isis!" From cma at cmadams.net Tue Jun 9 21:32:23 2015 From: cma at cmadams.net (Chris Adams) Date: Tue, 9 Jun 2015 16:32:23 -0500 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> Message-ID: <20150609213223.GF999@cmadams.net> Once upon a time, Doug Clements said: > If you think this is stupid, look in to the situation for modern WiFi and > Android. Haven't bothered to see if there's a bug (since my experience with Android and Google bug reports was a waste of time), but since my Android devices (Samsung and LG) upgraded to Lollipop, I no longer have functioning IPv6 on wifi. They connect and get an address (with privacy extensions even), but do not install an IPv6 default route. They can talk to local IPv6 devices, but not the Internet. The phone handles IPv6 over the cell network fine. This used to work; now we have progress! -- Chris Adams From skhosla at neutraldata.com Tue Jun 9 21:55:31 2015 From: skhosla at neutraldata.com (Sameer Khosla) Date: Tue, 9 Jun 2015 21:55:31 +0000 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: References: <557702BA.2070004@jvknet.com> Message-ID: <49A81EB09F493442B6D259E36251192C01719F1F6A@ndcc-exch1.neutraldata.com> Think of scenarios where you have mergers/acquisitions where different portions of the now amalgamated network were designed differently and there may be too much pain or require too much time to redesign rather than bolt together and redistribute. Sk. -----Original Message----- that confuses me, the logic I mean... I suppose in a single network I'd expect to see one igp for an address family (ospf or ospfv3). Not "eastcoast devices do ospf (stodgy bastards!) and westcoast goes isis!" From owen at delong.com Tue Jun 9 21:56:26 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 9 Jun 2015 14:56:26 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150609213223.GF999@cmadams.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> <20150609213223.GF999@cmadams.net> Message-ID: At the end of the day, I see Androids refusal to implement DHCPv6 as about the same level of stupidity as Apple?s refusal to implement 464XLAT in iOS. Both companies need to pull their heads out of their asses. Further, the cellular companies would do well to be more adaptive to the capabilities that exist in the hardware rather than insisting that they choose the solution and the hardware makers must adapt. Owen From Valdis.Kletnieks at vt.edu Tue Jun 9 22:00:45 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 09 Jun 2015 18:00:45 -0400 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: Your message of "Tue, 09 Jun 2015 21:55:31 -0000." <49A81EB09F493442B6D259E36251192C01719F1F6A@ndcc-exch1.neutraldata.com> References: <557702BA.2070004@jvknet.com> <49A81EB09F493442B6D259E36251192C01719F1F6A@ndcc-exch1.neutraldata.com> Message-ID: <24422.1433887245@turing-police.cc.vt.edu> On Tue, 09 Jun 2015 21:55:31 -0000, Sameer Khosla said: > Think of scenarios where you have mergers/acquisitions where different > portions of the now amalgamated network were designed differently and there may > be too much pain or require too much time to redesign rather than bolt together > and redistribute. But in that case, don't they usually say "The heck with it" and continue using 2 separate ASN numbers? -------------- 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 Tue Jun 9 22:08:29 2015 From: randy at psg.com (Randy Bush) Date: Tue, 09 Jun 2015 15:08:29 -0700 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: References: <557702BA.2070004@jvknet.com> Message-ID: > Routers makes more sense to me than networks (IGP, so one network, > right?) so you are thinking of a network where half the routers run is-is one quarter ospf/ospfv2 and one quarter ospf/ripv3. right. there was a very large provider that had one is-is leven-2 across many bgp confederations. there was a .... From randy at psg.com Tue Jun 9 22:10:36 2015 From: randy at psg.com (Randy Bush) Date: Tue, 09 Jun 2015 15:10:36 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150609202458.GA21839@lboro.ac.uk> References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> <20150609202458.GA21839@lboro.ac.uk> Message-ID: >> and we wonder at the pitiful ipv6 deployment. > > if more network admins actually did network stuff then IPv6 > deployment would be plentiful and we could even start the > discussion about turning off IPv4.... ;-) and cash would fall from the sky we are currently in the cycle where net ops are discovering computer programming (we call it net dev). i do not expect easily reconfigured and restructured global networks in this decade. randy From joelja at bogus.com Tue Jun 9 23:04:00 2015 From: joelja at bogus.com (joel jaeggli) Date: Tue, 9 Jun 2015 16:04:00 -0700 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: References: <557702BA.2070004@jvknet.com> Message-ID: <557770E0.7060105@bogus.com> On 6/9/15 2:00 PM, Christopher Morrow wrote: > On Tue, Jun 9, 2015 at 4:36 PM, Joe Abley wrote: >> >> >> On 9 Jun 2015, at 16:23, Christopher Morrow wrote: >> >>> On Tue, Jun 9, 2015 at 3:21 PM, Randy Bush wrote: >>>>> If you have a production dual-stack network, then we would like to know >>>>> which IGP you use to route IPv4 and which you use to route IPv6. >>>> >>>> in one network, both ospfs. in another is-is. i recommend the latter. >>>> >>>>> We would also like to know roughly how many routers are running this >>>>> combination. >>> >>> why is the question /routers/ and not /networks/ ? >> >> Routers makes more sense to me than networks (IGP, so one network, right?) > > that confuses me, the logic I mean... > > I suppose in a single network I'd expect to see one igp for an address > family (ospf or ospfv3). Not "eastcoast devices do ospf (stodgy > bastards!) and westcoast goes isis!" At one time I had datacenter interiors that had no isis support. they ran ospfv2 and to the extent that it was necessary in limited application ospfv3. the datacenter border and the backbone used ISIS for both adress families. routes were in general not redistributed between IGPs. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Tue Jun 9 23:09:08 2015 From: randy at psg.com (Randy Bush) Date: Tue, 09 Jun 2015 16:09:08 -0700 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: <24422.1433887245@turing-police.cc.vt.edu> References: <557702BA.2070004@jvknet.com> <49A81EB09F493442B6D259E36251192C01719F1F6A@ndcc-exch1.neutraldata.com> <24422.1433887245@turing-police.cc.vt.edu> Message-ID: >> Think of scenarios where you have mergers/acquisitions where >> different portions of the now amalgamated network were designed >> differently and there may be too much pain or require too much time >> to redesign rather than bolt together and redistribute. > But in that case, don't they usually say "The heck with it" and > continue using 2 separate ASN numbers? we didn't take that path. we used separated igps (did not want to share blood with yet to be trusted acquired engineers), and bgp confederation so there was one external asn. a useful transition strategy. but in that configuration, bgp at the confed border is ebgp, not ibgp. this has interesting consequences on timing of routing propagation, even with timers turned down. see http://archive.psg.com/030226.apnic-flap.pdf randy From david at mandelberg.org Tue Jun 9 23:09:45 2015 From: david at mandelberg.org (David Mandelberg) Date: Tue, 09 Jun 2015 19:09:45 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> Message-ID: <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> On 2015-06-05 02:40, Roland Dobbins wrote: > On 5 Jun 2015, at 10:56, David Mandelberg wrote: > >> Could you elaborate on your enumeration and DDoS concerns? > > Crypto = more overhead. Less priority to crypto plus DDoS = routing > update issues. I don't think there's an update issue here. The crypto verification is probably going to be deferred in addition to being low priority. If I understand it correctly, this means that a route can be passed along right away without waiting for the crypto checks. > One can infer peering relationships in a way not possible before. How? > What about bogus signatures? If I understand correctly, these routes (and all newly received routes) will initially be treated similarly to unsigned routes. Once BGPsec validation completes, then local policy determines what to do with the validation results. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From jabley at hopcount.ca Tue Jun 9 23:41:23 2015 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 9 Jun 2015 19:41:23 -0400 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: References: <557702BA.2070004@jvknet.com> Message-ID: <4007870726252415245@unknownmsgid> Hi Randy, On Jun 9, 2015, at 18:08, Randy Bush wrote: >> Routers makes more sense to me than networks (IGP, so one network, >> right?) > > so you are thinking of a network where half the routers run is-is one > quarter ospf/ospfv2 and one quarter ospf/ripv3. right. No, not at all. I thought Victor was asking "what IGP" and "how many routers use it in your network". I assumed he was interested in whether the size of the network influenced the IGP choice. Perhaps I misunderstood, because apparently I was the only one who read it that way. Joe From jhellenthal at dataix.net Wed Jun 10 00:23:42 2015 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Tue, 9 Jun 2015 19:23:42 -0500 Subject: grepcidr 2.99 In-Reply-To: <20150609162711.1759.qmail@ary.lan> References: <20150609162711.1759.qmail@ary.lan> Message-ID: <6DFDC9F9-EE28-4263-8E5B-EB751B35B2B4@dataix.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi John, Great contribution. Thanks Might I make a suggestion? with the following command it gives Invalid CIDR. In my usage it would seem logically convenient to throw any quad octet at it and have it translate to the proper CIDR range that isn?t reported as invalid since it does this anyway. For instance 127.0.0.1/8 would just become 127.0.0.0/8. Then add a (-d) flag for debugging or verbose messages. My first impression of the output was that it was only going to grep for valid CIDR ranges which was not true. $ cidr 127.0.0.1/8 Invalid cidr: 127.0.0.1/8 $ grepcidr -q 192.0.0.1/24 Invalid cidr: 192.0.0.1/24 All-in-all great tool and putting it to use right away! Thank you John On Jun 9, 2015, at 11:27, John Levine wrote: I've updated grepcidr again, adding some code contributed by a user. (This open source thing may actually have a future.) grepcidr is what it sounds like, you give it a bunch of CIDR ranges, and files to read, and it prints out the lines in the files that contain addresses that match any of the CIDR ranges. The new feature lets it match CIDR ranges in the input files as well as IP addresses. It handles both IPv4 and IPv6. It maps each file into memory and runs a state machine over the file in one pass so it's quite fast. There should be no limits on line length, file size, or number of patterns other than running out of memory. Find it here: http://www.taugh.com/grepcidr-2/ Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly - -- Jason Hellenthal JJH48-ARIN -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVd4OPAAoJEDLu+wRc4KcIKNYH/15qbVxyPhtcR3HnIXxEWzY+ hwLL0650Dr3cCxFAYkvNqcATgF8e3ZJTxDSKKs3jOlYTzGqQvMfbfI1AAMZyVuWD uyYDHP3SdQfzLlNclDAKZYHVdGNLVn76kew9k1R3uV8qdxfxtuRIhrko2bM60IxM dokeftVUafApnVU40O3mnHaDwAuoqWhKXZhMntNNrPRQqpwNoGfdiGMUtqTsDF6f XjTfY6Xtn3L6lzWK48PGqU6Tvj8/yKVR4BTMlfAp5UNqozYFl8nxfbfRBFEJDfDw JrlHpI52Z2n4d8zy/XKByWhiOskpPnm5QIxZHYXIfcvFA6nJSfl4J7ZiQvkkajE= =GuNx -----END PGP SIGNATURE----- From victor at jvknet.com Wed Jun 10 00:59:19 2015 From: victor at jvknet.com (Victor Kuarsingh) Date: Tue, 09 Jun 2015 20:59:19 -0400 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: <4007870726252415245@unknownmsgid> References: <557702BA.2070004@jvknet.com> <4007870726252415245@unknownmsgid> Message-ID: <55778BE7.4010207@jvknet.com> I/we (Philip and I) attempted to keep the question as generic as possible, allowing folks to state the IGPs they use, in whichever combination or in some cases (as we can see), more complex deployments. I would agree with statements form Joel earlier with respect to cases where early vendor support may have influenced some network zones (inside a given AS) to support a different IGP (his case of OSPFv3 for devices which lacked IS-IS support is one I did face a few years back as well in the DC with respect to Load balancing and Firewall devices). The merger one was a new one for me, but it seems to reflect some peoples reality. regards, Victor K On 2015-06-09 7:41 PM, Joe Abley wrote: > Hi Randy, > > On Jun 9, 2015, at 18:08, Randy Bush wrote: > >>> Routers makes more sense to me than networks (IGP, so one network, >>> right?) >> so you are thinking of a network where half the routers run is-is one >> quarter ospf/ospfv2 and one quarter ospf/ripv3. right. > No, not at all. I thought Victor was asking "what IGP" and "how many > routers use it in your network". I assumed he was interested in > whether the size of the network influenced the IGP choice. > > Perhaps I misunderstood, because apparently I was the only one who > read it that way. > > > Joe From randy at psg.com Wed Jun 10 01:10:58 2015 From: randy at psg.com (Randy Bush) Date: Tue, 09 Jun 2015 18:10:58 -0700 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: <55778BE7.4010207@jvknet.com> References: <557702BA.2070004@jvknet.com> <4007870726252415245@unknownmsgid> <55778BE7.4010207@jvknet.com> Message-ID: a researcher i know and respect asked a bunch of ops what features that used. the researcher finally said something similar to "operators seem to actually use all those kinky knobs and protocols." for any kink you can imagine, someone does it. there are operators who have even deployed ipv6 :) randy From Valdis.Kletnieks at vt.edu Wed Jun 10 01:19:23 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 09 Jun 2015 21:19:23 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: Your message of "Tue, 09 Jun 2015 19:09:45 -0400." <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> Message-ID: <39758.1433899163@turing-police.cc.vt.edu> On Tue, 09 Jun 2015 19:09:45 -0400, David Mandelberg said: > I don't think there's an update issue here. The crypto verification is > probably going to be deferred in addition to being low priority. If I > understand it correctly, this means that a route can be passed along > right away without waiting for the crypto checks. Forward the route and then check it? Didn't we have a very amusing afternoon a number of years ago when $VENDOR did exactly that with some invalid routing data? Or am I mis-remembering history, and therefor doomed to mis-repeat it? -------------- 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 Wed Jun 10 01:29:05 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 09 Jun 2015 21:29:05 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: Your message of "Tue, 09 Jun 2015 21:19:23 -0400." <39758.1433899163@turing-police.cc.vt.edu> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> <39758.1433899163@turing-police.cc.vt.edu> Message-ID: <40518.1433899745@turing-police.cc.vt.edu> On Tue, 09 Jun 2015 21:19:23 -0400, Valdis.Kletnieks at vt.edu said: > Didn't we have a very amusing afternoon a number of years ago when $VENDOR > did exactly that with some invalid routing data? Or am I mis-remembering > history, and therefor doomed to mis-repeat it? Actually, it was collusion. $VENDOR-A forwarded the bad data all over, and every $VENDOR-B router that saw it went walkies... It's the memory that goes first. I can't remember what goes second.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From morrowc.lists at gmail.com Wed Jun 10 01:50:46 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 9 Jun 2015 21:50:46 -0400 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: References: <557702BA.2070004@jvknet.com> <4007870726252415245@unknownmsgid> <55778BE7.4010207@jvknet.com> Message-ID: On Tue, Jun 9, 2015 at 9:10 PM, Randy Bush wrote: > a researcher i know and respect asked a bunch of ops what features that > used. the researcher finally said something similar to "operators seem > to actually use all those kinky knobs and protocols." > > for any kink you can imagine, someone does it. there are operators who > have even deployed ipv6 :) see the other thread of the week, you are wrong sir! wrong! :) At AS701/2/3 there were nominally 2k devices (way back when) using ISIS for their igp for both v4 and v6 data... though the igp split on as-boundaries. hope that helps! From lorenzo at colitti.com Wed Jun 10 02:48:38 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Wed, 10 Jun 2015 11:48:38 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150609031454.GD3716@bender.unx.cpp.edu> References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: On Tue, Jun 9, 2015 at 12:14 PM, Paul B. Henson wrote: > https://code.google.com/p/android/issues/detail?id=32621 > > It looks like one developer simply refuses to implement it because if he > did there might be a scenario where somebody might not be able to tether > 8-/? That sounds pretty stupid even for me, so probably something got lost in translation. I think what I said is that supporting DHCPv6-only networks will eventually force OS manufacturers to implement IPv6 NAT. This is because there are many features inside a mobile OS that require multiple IP addresses. One example is 464xlat. Another example is tethering (and no, much as network admins would like that, users and product management will *not* accept that tethering is "disabled because the network "does not provide enough IP addresses" - they will just want the feature to work, even if it breaks apps some of the time). Another example is any function that mostly lives on a mobile device's baseband processor and needs to access networks that are connected through the application processor (e.g., wifi calling, ePDG access, etc.) In IPv4 we use NAT for all that, and that's unavoidable due to lack of IPv4 space. That reason does not apply in IPv6 though. With SLAAC or DHCPv6 PD, these functions can use their own IPv6 addresses. With stateful DHCPv6 addressing, we're back to using NAT again. That means application flakiness, battery impact due to NAT keepalives, and so on. It also means that things that don't work behind NAT (e.g., 464xlat, which requires its own IPv6 address) cannot be made to work at all. His attitude is that you have to use SLAAC and RDNSS, which we're > just not going to do. You don't "have to do" SLAAC and RDNSS. For as long as the network provides IPv4, there won't be a problem for anyone. And I assume you're not planning on turning off IPv4 tomorrow, because a whole lot of things will stop working if you do that From kauer at biplane.com.au Wed Jun 10 02:59:47 2015 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 10 Jun 2015 12:59:47 +1000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: <1433905187.11511.25.camel@karl> On Wed, 2015-06-10 at 11:48 +0900, Lorenzo Colitti wrote: > With stateful DHCPv6 addressing, we're back to using NAT again. Hope the question doesn't make me look like an idiot, but why does using stateful DHCPv6 mean having to go back to NAT? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From lorenzo at colitti.com Wed Jun 10 03:01:52 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Wed, 10 Jun 2015 12:01:52 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: On Wed, Jun 10, 2015 at 3:20 AM, Ray Soucy wrote: > Clients should support a verity of methods and let network operators choose > the solution that fits the environment. The whole premise for not > supporting DHCPv6 seems to be that mobile networks don't need it, but that > totally ignores 802.11 which is equally important. > No, the premise is that from a user's point of view, DHCPv6-only networks cause regressions in functionality compared to IPv4-only or dual-stack networks. For example: IPv4 apps cannot be supported at all due because 464xlat cannot be made to work, and functions such as tethering cannot be implemented because there are no IP addresses to assign to downstream devices. Implementing IPv6 NAT can resolve some but not all of these regressions (for example, IPv4 apps still cannot be supported). Thus, attempting to operate on DHCPv6-only networks a) will create pressure to implement IPv6 NAT, which causes lots of issues like application complexity, battery life issues due to keepalives, etc. b) impose user-visible regressions even if we do implement IPv6 NAT. >From a user's point of view, that's just a bad deal, especially since IPv4-only networks, dual-stack networks, and IPv6-only networks using SLAAC do not have any of those issues. Stateless DHCP and stateful DHCPv6 PD have none of those issues, either. If we really need stateful addressing, then we should statefully assign prefixes, not single addresses. I understand that "stateful-one-address-per-device-DHCPv6-only" is easier for network operators, but SLAAC really isn't that much harder, and in the long run, we'll get more robust apps, better battery life, more innovation, and happier users. From lorenzo at colitti.com Wed Jun 10 03:06:40 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Wed, 10 Jun 2015 12:06:40 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> <20150609213223.GF999@cmadams.net> Message-ID: On Wed, Jun 10, 2015 at 6:56 AM, Owen DeLong wrote: > At the end of the day, I see Androids refusal to implement DHCPv6 as about > the same level of stupidity as Apple?s refusal to implement 464XLAT in iOS. > Based on the facts, you could could just as well say that Apple is trying to advance the state of the art by refusing to provide suboptimal 464xlat and insisting instead that developers support IPv6-only networks as first-class citizens: https://twitter.com/dteam69/status/608036976990797824 By the same token, you could argue that not supporting statful DHCPv6 address assignment advances the state of the art by trying to avoid slipping back into a "one-address-per-device-NAT-required" world. From Valdis.Kletnieks at vt.edu Wed Jun 10 03:09:34 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 09 Jun 2015 23:09:34 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: Your message of "Wed, 10 Jun 2015 12:59:47 +1000." <1433905187.11511.25.camel@karl> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> Message-ID: <7511.1433905774@turing-police.cc.vt.edu> On Wed, 10 Jun 2015 12:59:47 +1000, Karl Auer said: > On Wed, 2015-06-10 at 11:48 +0900, Lorenzo Colitti wrote: > > With stateful DHCPv6 addressing, we're back to using NAT again. > > Hope the question doesn't make me look like an idiot, but why does using > stateful DHCPv6 mean having to go back to NAT? How does the device ask for a *second* DHCPv6'ed address for tethering or whatever? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From cma at cmadams.net Wed Jun 10 03:14:54 2015 From: cma at cmadams.net (Chris Adams) Date: Tue, 9 Jun 2015 22:14:54 -0500 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <7511.1433905774@turing-police.cc.vt.edu> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> Message-ID: <20150610031454.GH999@cmadams.net> Once upon a time, Valdis.Kletnieks at vt.edu said: > On Wed, 10 Jun 2015 12:59:47 +1000, Karl Auer said: > > Hope the question doesn't make me look like an idiot, but why does using > > stateful DHCPv6 mean having to go back to NAT? > > How does the device ask for a *second* DHCPv6'ed address for tethering or > whatever? It's called "bridging". Let whatever is being tethered ask directly for its own address. -- Chris Adams From jon at nnbfn.net Wed Jun 10 03:26:01 2015 From: jon at nnbfn.net (Jon Bane) Date: Tue, 9 Jun 2015 20:26:01 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150610031454.GH999@cmadams.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <20150610031454.GH999@cmadams.net> Message-ID: On Tue, Jun 9, 2015 at 8:14 PM, Chris Adams wrote: > Once upon a time, Valdis.Kletnieks at vt.edu said: > > On Wed, 10 Jun 2015 12:59:47 +1000, Karl Auer said: > > > Hope the question doesn't make me look like an idiot, but why does > using > > > stateful DHCPv6 mean having to go back to NAT? > > > > How does the device ask for a *second* DHCPv6'ed address for tethering or > > whatever? > > It's called "bridging". Let whatever is being tethered ask directly for > its own address. > -- > Chris Adams > Bridging, DHCP-PD, virtual Interfaces,DHCPv6 first and then when tethering is turned on, enable SLAAC for the additional interfaces or go to the extremes and modify DHCP. Lots of ways to supply multiple addresses to an interface that don't involve ignoring 1/2 of the addressing standard. DHCPv6 - RFC3315 - Category: Standards Track 464XLAT - RFC6877 - Category: Informational Just for perspective on what the which should be a priority. From kauer at biplane.com.au Wed Jun 10 03:37:02 2015 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 10 Jun 2015 13:37:02 +1000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <7511.1433905774@turing-police.cc.vt.edu> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> Message-ID: <1433907422.11511.30.camel@karl> On Tue, 2015-06-09 at 23:09 -0400, Valdis.Kletnieks at vt.edu wrote: > How does the device ask for a *second* DHCPv6'ed address for tethering or > whatever? RFC 3315 says you just chuck in multiple IA_NA (or IA_TA) options. The server will respond with multiple addresses. And if a device makes a second (, third, fourth, ..) request with a different DUID, it'll get a second (,third, fourth,...) address oo, I guess. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From morrowc.lists at gmail.com Wed Jun 10 03:37:11 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 9 Jun 2015 23:37:11 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150610031454.GH999@cmadams.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <20150610031454.GH999@cmadams.net> Message-ID: On Tue, Jun 9, 2015 at 11:14 PM, Chris Adams wrote: > Once upon a time, Valdis.Kletnieks at vt.edu said: >> On Wed, 10 Jun 2015 12:59:47 +1000, Karl Auer said: >> > Hope the question doesn't make me look like an idiot, but why does using >> > stateful DHCPv6 mean having to go back to NAT? >> >> How does the device ask for a *second* DHCPv6'ed address for tethering or >> whatever? > > It's called "bridging". Let whatever is being tethered ask directly for > its own address. it remains to be seen if that would actually work, and it's probably network-dependent, right? If your notional network implemented SAVI restrictions then a single dhcpv6 assigned address might be all you get. A bunch of this discussion (on both sides) seems (to me) get get back to: "I designed something, took a left turn and kept on driving.... and I just don't want to revisit assumptions." Example: "I do not want to support SLAAC because I don't want to do RDNSS, I will provide dns servers/etc via dhcpv6" Example: "We will not support DHCPv6 because people might assign one address only." Both of those have a way to a solution, neither has to be a hard/fast rule, right? From jmaslak at antelope.net Wed Jun 10 03:37:38 2015 From: jmaslak at antelope.net (Joel Maslak) Date: Tue, 9 Jun 2015 21:37:38 -0600 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150610031454.GH999@cmadams.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <20150610031454.GH999@cmadams.net> Message-ID: Most APs don't support bridging, not enough addresses in the protocol (without enabling WDS or whatever modern versions of that are). On Tue, Jun 9, 2015 at 9:14 PM, Chris Adams wrote: > Once upon a time, Valdis.Kletnieks at vt.edu said: > > On Wed, 10 Jun 2015 12:59:47 +1000, Karl Auer said: > > > Hope the question doesn't make me look like an idiot, but why does > using > > > stateful DHCPv6 mean having to go back to NAT? > > > > How does the device ask for a *second* DHCPv6'ed address for tethering or > > whatever? > > It's called "bridging". Let whatever is being tethered ask directly for > its own address. > -- > Chris Adams > From Valdis.Kletnieks at vt.edu Wed Jun 10 03:40:50 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 09 Jun 2015 23:40:50 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: Your message of "Tue, 09 Jun 2015 22:14:54 -0500." <20150610031454.GH999@cmadams.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <20150610031454.GH999@cmadams.net> Message-ID: <18884.1433907650@turing-police.cc.vt.edu> On Tue, 09 Jun 2015 22:14:54 -0500, Chris Adams said: > Once upon a time, Valdis.Kletnieks at vt.edu said: > > On Wed, 10 Jun 2015 12:59:47 +1000, Karl Auer said: > > > Hope the question doesn't make me look like an idiot, but why does using > > > stateful DHCPv6 mean having to go back to NAT? > > > > How does the device ask for a *second* DHCPv6'ed address for tethering or > > whatever? > > It's called "bridging". Let whatever is being tethered ask directly for > its own address. And the router knows to send to the "front" address to reach the "back" address, how, exactly? Seems like somebody should invent a way to assign a prefix to the front address that it can delegate to things behind it. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jmaslak at antelope.net Wed Jun 10 03:45:38 2015 From: jmaslak at antelope.net (Joel Maslak) Date: Tue, 9 Jun 2015 21:45:38 -0600 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <20150610031454.GH999@cmadams.net> Message-ID: Of course I've been up too long, ignore the idiot (me). :) On Tue, Jun 9, 2015 at 9:37 PM, Joel Maslak wrote: > Most APs don't support bridging, not enough addresses in the protocol > (without enabling WDS or whatever modern versions of that are). > > On Tue, Jun 9, 2015 at 9:14 PM, Chris Adams wrote: > >> Once upon a time, Valdis.Kletnieks at vt.edu said: >> > On Wed, 10 Jun 2015 12:59:47 +1000, Karl Auer said: >> > > Hope the question doesn't make me look like an idiot, but why does >> using >> > > stateful DHCPv6 mean having to go back to NAT? >> > >> > How does the device ask for a *second* DHCPv6'ed address for tethering >> or >> > whatever? >> >> It's called "bridging". Let whatever is being tethered ask directly for >> its own address. >> -- >> Chris Adams >> > > From lorenzo at colitti.com Wed Jun 10 04:58:06 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Wed, 10 Jun 2015 13:58:06 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <20150610031454.GH999@cmadams.net> Message-ID: On Wed, Jun 10, 2015 at 12:26 PM, Jon Bane wrote: > > DHCPv6 - RFC3315 - Category: Standards Track > 464XLAT - RFC6877 - Category: Informational > Ooo, that's fun, can I play too? BGP - RFC 4271 - DRAFT STANDARD USM for SNMPv3 - RFC 3414 - INTERNET STANDARD From mike at mtcc.com Wed Jun 10 05:10:22 2015 From: mike at mtcc.com (Michael Thomas) Date: Tue, 09 Jun 2015 22:10:22 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <1433907422.11511.30.camel@karl> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> Message-ID: <5577C6BE.6020905@mtcc.com> On 06/09/2015 08:37 PM, Karl Auer wrote: > On Tue, 2015-06-09 at 23:09 -0400, Valdis.Kletnieks at vt.edu wrote: >> How does the device ask for a *second* DHCPv6'ed address for tethering or >> whatever? > RFC 3315 says you just chuck in multiple IA_NA (or IA_TA) options. The > server will respond with multiple addresses. > > And if a device makes a second (, third, fourth, ..) request with a > different DUID, it'll get a second (,third, fourth,...) address oo, I > guess. > > Wouldn't the right thing to do is have the provider support dhcp prefix delegation, and the tether can run dhcp for its clients? (or even slaac?) Mike From swmike at swm.pp.se Wed Jun 10 05:25:07 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Jun 2015 07:25:07 +0200 (CEST) Subject: Android (lack of) support for DHCPv6 In-Reply-To: <5577C6BE.6020905@mtcc.com> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <5577C6BE.6020905@mtcc.com> Message-ID: On Tue, 9 Jun 2015, Michael Thomas wrote: > Wouldn't the right thing to do is have the provider support dhcp prefix > delegation, and the tether can run dhcp for its clients? (or even > slaac?) Do you think the people who insist on wanting to use DHCPv6 IA_NA will instead be fine with DHCPv6 IA_PD /64 per device instead? The device doesn't *have* to have IA_NA on the "wan" interface, it could assign this /64 to itself and use it for tethering and its own use, so with A=0, M=1, O=1 DHCPv6 could give (minimum, preferrably larger like /62 or /60) /64 PD and this would solve Lorenzos stated problem (albeit with added code). -- Mikael Abrahamsson email: swmike at swm.pp.se From jon at nnbfn.net Wed Jun 10 05:24:43 2015 From: jon at nnbfn.net (Jon Bane) Date: Tue, 9 Jun 2015 22:24:43 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <20150610031454.GH999@cmadams.net> Message-ID: On Tue, Jun 9, 2015 at 9:58 PM, Lorenzo Colitti wrote: > Ooo, that's fun, can I play too? > > BGP - RFC 4271 - DRAFT STANDARD > USM for SNMPv3 - RFC 3414 - INTERNET STANDARD > The difference being, my references were actually relevant to the discussion and a direct response to your arguments. Something something, two rights and wrongs. More importantly however, you have completely ignored, again, the solutions that people are presenting and continuing to hold that DHCPv6 == NAT. You are effectively saying that because YOU believe that DHCPv6 will lead to NAT (slippery-slope falacy), that the rest of us have to accept and design around it. That you are more right than the rest of us about what is appropriate for our networks and what meets our requirements. You build a client, not an architecture. If features are incompatible, try to innovate in the spirit of your employer. I want to believe that you are capable given the position you are in, but your steadfast hold on this equation is making that hard. When I build something I want people to use, I tend to put in the features they need and want so they continue to use it. It is crystal clear here and in the bug post, that people need DHCPv6 on WiFi. We don't need your guiding hand to protect us from ourselves. We need the tools to manage our environments to meet our requirements, not yours. From cb.list6 at gmail.com Wed Jun 10 05:28:19 2015 From: cb.list6 at gmail.com (Ca By) Date: Tue, 9 Jun 2015 22:28:19 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <5577C6BE.6020905@mtcc.com> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <5577C6BE.6020905@mtcc.com> Message-ID: On Tuesday, June 9, 2015, Michael Thomas wrote: > On 06/09/2015 08:37 PM, Karl Auer wrote: > >> On Tue, 2015-06-09 at 23:09 -0400, Valdis.Kletnieks at vt.edu wrote: >> >>> How does the device ask for a *second* DHCPv6'ed address for tethering or >>> whatever? >>> >> RFC 3315 says you just chuck in multiple IA_NA (or IA_TA) options. The >> server will respond with multiple addresses. >> >> And if a device makes a second (, third, fourth, ..) request with a >> different DUID, it'll get a second (,third, fourth,...) address oo, I >> guess. >> >> >> > Wouldn't the right thing to do is have the provider support dhcp prefix > delegation, and the tether can run > dhcp for its clients? (or even slaac?) > > Mike > Well, the OP seems to be interested in campus wifi ... So perhaps we should stick to that first On the other thread, Randy said network operators use a lot of kinky knobs, thats just how it is. If these guys want to run without SLAAC, they can do that and know the outcome . It is just their kink. I dont think andoid will change, and even if they did you will need to wait 5 yeara for theupgrade cycle to push out old clients CB From swmike at swm.pp.se Wed Jun 10 05:35:00 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Jun 2015 07:35:00 +0200 (CEST) Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <20150610031454.GH999@cmadams.net> Message-ID: On Tue, 9 Jun 2015, Jon Bane wrote: > When I build something I want people to use, I tend to put in the > features they need and want so they continue to use it. It is crystal > clear here and in the bug post, that people need DHCPv6 on WiFi. We > don't need your guiding hand to protect us from ourselves. We need the > tools to manage our environments to meet our requirements, not yours. What would you find acceptable behaviour from a device that finds itself on a wifi network that only gives it a single DHCPv6 IA_NA ? That some apps silently stop working because 464XLAT doesn't work, that it throws up a splash screen for the user to say that the network its connected to doesn't work, or that it just doesn't use this network and continues to use cellular (basically like it would one where the connection manager can't verify connectivity), and also that tethering won't work. -- Mikael Abrahamsson email: swmike at swm.pp.se From hugo at slabnet.com Wed Jun 10 05:36:03 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 9 Jun 2015 22:36:03 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: <20150610053603.GD2530@bamboo.slabnet.com> On Wed 2015-Jun-10 12:01:52 +0900, Lorenzo Colitti wrote: >On Wed, Jun 10, 2015 at 3:20 AM, Ray Soucy wrote: > >> Clients should support a verity of methods and let network operators choose >> the solution that fits the environment. The whole premise for not >> supporting DHCPv6 seems to be that mobile networks don't need it, but that >> totally ignores 802.11 which is equally important. >> > >No, the premise is that from a user's point of view, DHCPv6-only networks >cause regressions in functionality compared to IPv4-only or dual-stack >networks. For example: IPv4 apps cannot be supported at all due because >464xlat cannot be made to work... Pardon my ignorance as I don't currently have field experience with 464xlat, but my understanding of the technique is that it is (for the most part) dependent on the network cooperating (by providing a DNS64 and NAT64) for it to work properly. If we take the example of an Android handset on a campus/enterprise, single stack v6 WLAN, is there any way that 464xlat would work without the network operator intentionally providing the necessary infrastructure for 464xlat? E.g. the v6-only network uses SLAAC with RDNSS. The network operator provides resolver addresses to the Android handset via RDNSS, and those resolvers aren't DNS64. The handset queries for ipv4only.arpa, and since the resolvers provided by the operator via RDNSS are not DNS64, it gets NOERROR rather than a Prefix64-synthesized AAAA. Result: the handset determines there is no DNS64 in the path, and hence 464xlat is not possible. Assume we tweak this to say the handset is very independent-minded and queries its own set of DNS64 resolvers. Further assume that the network operator doesn't block DNS queries out to random DNS servers on the internet from client devices. For that to work, the DNS64 has to answer recursive queries from this handset from a v6 address within the random v6-only network the client device currently finds itself on, so you're either looking at needing to provide an open resolver or have some other magic to auth the handset to the DNS64 before answering its queries. Assuming we get this far, the NAT64 indicated in the Prefix64 stuffed into the synthesized AAAAs provided by the DNS64 now also needs to provide NAT64 services to the client device coming from the random v6-only network, again by either simply providing free services to whomever comes calling or authenticating the handset in some way if it's off-net, originating on the random v6-only network in question. Owing to my ignorange in this space, I'm not aware of too many publicly available DNS64/NAT64 services, though some quick searching reveals a handful of such sites. They appear to be mostly research networks, so not really anything that I would be comfortable pointing to as a long term viable solution at which to point my clients/handsets. If I'm misinformed and e.g. T-Mo plans on making their DNS64/NAT64 infra publicly available and hard-coding client devices to point at it, I stand to be corrected. That is an *awful* lot of assumptions we have to break through to get to a working 464xlat service working on a random v6-only WLAN if the 464xlat infra is not provided by that WLAN's operator. So, we either need to fulfill a checklist of *several* longshot assumptions/configurations, or we're looking at an environment where 464xlat is being provided by the network operator for it to have a snowball's chance of working. If the network operator is providing the 464xlat and they *want* that 464xlat to be available on this v6-only WLAN, then it is *their* responsibility to ensure that their chosen v6 address assignment solution (SLAAC or DHCPv6) works with 464xlat and is e.g. capable of PD or multiple v6 addresses per client. If they *choose* to run a v6-only network without a v4 access solution and hence with the regressions you listed, is it your job to tell them they shouldn't do that or to tell your users they can't participate in that network? >...and functions such as tethering cannot be implemented because there are >no IP addresses to assign to downstream devices. You had noted on the bug/request: "It's a fair assumption that many (or at least some) networks that support DHCPv6 will limit the number of IP addresses assigned by DHCPv6 to one per MAC address." Your whole argument of DHCPv6 breaking tethering, 464xlat, and other technologies that require multiple addresses per interfaces hinges on this assumption. It does not hold true in all cases (multiple posters have pointed to solutions such as multiple DUIDs), and in some cases operators may be *intentionally choosing* to design the network with such limitations in place (research nets; pilot networks; things neither of us have thought of yet). Is it really your assertion that your users would be better served *not* being able to connect to these networks *at all* than to connect to them on the terms dictated by the network operator? On a bit of a side note: Multiple posters on the bug/request are coming from enterprise/campus networks that have existing AUPs and enforcement techniques prohibiting certain network functions (e.g. content filtering, restricted outbound access, etc.), and would be making an *active choice* as to whether they do or do not want to support functions such as tethering, 464xlat, etc. If I find myself on such a WLAN, restricting what I'm trying to do, TBH I write it off as something being done intentionally or broken in the network, drop off the WLAN and just do it on the cell network. Does the average user do something different? >Implementing IPv6 NAT can resolve some but not all of these regressions >(for example, IPv4 apps still cannot be supported). Thus, attempting to >operate on DHCPv6-only networks a) will create pressure to implement IPv6 >NAT, which causes lots of issues like application complexity, battery life >issues due to keepalives, etc. b) impose user-visible regressions even if >we do implement IPv6 NAT. > >From a user's point of view, that's just a bad deal, especially since >IPv4-only networks, dual-stack networks, and IPv6-only networks using SLAAC >do not have any of those issues. Stateless DHCP and stateful DHCPv6 PD have >none of those issues, either. If we really need stateful addressing, then >we should statefully assign prefixes, not single addresses. > >I understand that "stateful-one-address-per-device-DHCPv6-only" is easier >for network operators, but SLAAC really isn't that much harder, and in the >long run, we'll get more robust apps, better battery life, more innovation, >and happier users. And there it is: "SLAAC is better and it isn't that hard; use it instead." It is up to the network operator to make the design choices that best fit their network, including if their design goals are to *restrict* certain network functions. You are saying that you know better. -- Hugo [1] https://www.nanog.org/sites/default/files/wednesday_general_byrne_breakingfree_11.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From swmike at swm.pp.se Wed Jun 10 05:38:42 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Jun 2015 07:38:42 +0200 (CEST) Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150609213223.GF999@cmadams.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> <20150609213223.GF999@cmadams.net> Message-ID: On Tue, 9 Jun 2015, Chris Adams wrote: > Android devices (Samsung and LG) upgraded to Lollipop, I no longer have > functioning IPv6 on wifi. They connect and get an address (with privacy > extensions even), but do not install an IPv6 default route. They can > talk to local IPv6 devices, but not the Internet. My Nexus4 with Android 5.1.1 works just fine with IPv6 on wifi. So talk to your handset manufacturer, they must have broke something. -- Mikael Abrahamsson email: swmike at swm.pp.se From marka at isc.org Wed Jun 10 05:42:14 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 10 Jun 2015 15:42:14 +1000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: Your message of "Tue, 09 Jun 2015 22:10:22 -0700." <5577C6BE.6020905@mtcc.com> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <5577C6BE.6020905@mtcc.com> Message-ID: <20150610054215.4A1593054F49@rock.dv.isc.org> In message <5577C6BE.6020905 at mtcc.com>, Michael Thomas writes: > On 06/09/2015 08:37 PM, Karl Auer wrote: > > On Tue, 2015-06-09 at 23:09 -0400, Valdis.Kletnieks at vt.edu wrote: > >> How does the device ask for a *second* DHCPv6'ed address for tethering or > >> whatever? > > RFC 3315 says you just chuck in multiple IA_NA (or IA_TA) options. The > > server will respond with multiple addresses. > > > > And if a device makes a second (, third, fourth, ..) request with a > > different DUID, it'll get a second (,third, fourth,...) address oo, I > > guess. > > Wouldn't the right thing to do is have the provider support dhcp prefix > delegation, and the tether can run > dhcp for its clients? (or even slaac?) Yes. Providers should support both IA_NA and PD. Tethering could have been done properly with PD at the time but it was decided to leave PD to the next round of the phone spec. as as a result there was all the prefix sharing kludges. > Mike -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jon at nnbfn.net Wed Jun 10 05:52:48 2015 From: jon at nnbfn.net (Jon Bane) Date: Tue, 9 Jun 2015 22:52:48 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <20150610031454.GH999@cmadams.net> Message-ID: On Tue, Jun 9, 2015 at 10:35 PM, Mikael Abrahamsson wrote: > What would you find acceptable behaviour from a device that finds itself > on a wifi network that only gives it a single DHCPv6 IA_NA ? That some apps > silently stop working because 464XLAT doesn't work, that it throws up a > splash screen for the user to say that the network its connected to doesn't > work, or that it just doesn't use this network and continues to use > cellular (basically like it would one where the connection manager can't > verify connectivity), and also that tethering won't work. Isn't that the problem of the network operator? To know and accept the tradeoffs for how they operate their network? If this theory that DHCPv6 is going to break the world comes true, then the operators will adjust their methods. Personally, I find operating a dual-stack network far simpler than futzing with XLAT or NAT64. It is a known configuration vs. a complete list of unknown gotchas in translation solutions. Not to mention the added complexity on the client and the network edge. From swmike at swm.pp.se Wed Jun 10 06:20:15 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Jun 2015 08:20:15 +0200 (CEST) Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <20150610031454.GH999@cmadams.net> Message-ID: On Tue, 9 Jun 2015, Jon Bane wrote: > Isn't that the problem of the network operator? To know and accept the > tradeoffs for how they operate their network? If this theory that > DHCPv6 is going to break the world comes true, then the operators will > adjust their methods. Personally, I find operating a dual-stack network > far simpler than futzing with XLAT or NAT64. It is a known configuration > vs. a complete list of unknown gotchas in translation solutions. Not to > mention the added complexity on the client and the network edge. Ok, so lets see a scenario going forward: Android starts to support IA_NA and IA_PD. If it only gets a single IA_NA, 464XLAT and tethering (and potentially even more functionality in the future) doesn't work. How long do you think it'll take before we have a similar discussion here about why Android doesn't support NAT66 to workaround those problems? -- Mikael Abrahamsson email: swmike at swm.pp.se From lorenzo at colitti.com Wed Jun 10 06:32:30 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Wed, 10 Jun 2015 15:32:30 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <1433907422.11511.30.camel@karl> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> Message-ID: On Wed, Jun 10, 2015 at 12:37 PM, Karl Auer wrote: > RFC 3315 says you just chuck in multiple IA_NA (or IA_TA) options. The > server will respond with multiple addresses. > > And if a device makes a second (, third, fourth, ..) request with a > different DUID, it'll get a second (,third, fourth,...) address oo, I > guess. It's certainly possible to make Android request N IPv6 addresses via DHCPv6, and not accept the offer if it is offered fewer than N addresses. But that only really makes sense if there's a generally-agreed upon minimum value of N. I'd be happy to work with people on an Internet draft or other standard to define a minimum value for N, but I fear that it may not possible to gain consensus on that. It's also possible for Android to support DHCPv6 PD. Again I'd be happy to work with people on a document that says that mobile devices should do DHCPv6 PD and not DHCP NA, and then implement DHCPv6 PD. But I fear similar arguments will be had there. Asking for more addresses when the user tries to enable features such as tethering, waiting for the network to reply, and disabling the features if the network does not provide the necessary addresses does not seem like it would provide a good user experience. From alh-ietf at tndh.net Wed Jun 10 06:38:26 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 9 Jun 2015 23:38:26 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> <20150609213223.GF999@cmadams.net> Message-ID: <10cd01d0a348$0e494500$2adbcf00$@tndh.net> > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mikael > Abrahamsson > Sent: Tuesday, June 09, 2015 10:39 PM > To: Chris Adams > Cc: nanog at nanog.org > Subject: Re: Android (lack of) support for DHCPv6 > > On Tue, 9 Jun 2015, Chris Adams wrote: > > > Android devices (Samsung and LG) upgraded to Lollipop, I no longer > > have functioning IPv6 on wifi. They connect and get an address (with > > privacy extensions even), but do not install an IPv6 default route. > > They can talk to local IPv6 devices, but not the Internet. > > My Nexus4 with Android 5.1.1 works just fine with IPv6 on wifi. > > So talk to your handset manufacturer, they must have broke something. I filed a platform bug on this back in the ICS timeframe, and it still persists. As I recall, there are 2 flags provided by the OS related to RA handling. Rather than using the one that sets a preference between the Cell vs. Wifi interface, at least Samsung (possibly others) have chosen to use the other flag that says to completely ignore the WiFi RA if an RA on the Cell interface has ever occurred. This means devices that have no IPv6 on their Cell interface will appear to work fine on WiFi. I claim that there is a platform bug, because there is never a reason to ignore the WiFi RA. Use the other flag to set a preference if that is needed, but ignoring the RA just breaks things in unexpected ways. LC has did a hand-wave that the "ignore RA" flag is needed for battery life, but beyond that we appear to be stuck in a world where Clueless OEMs believe in breaking one network when another might exist. As a general comment about this thread; people need to treat the handset as a "ROUTER" and get over it. Just do a PD and treat it like any other router. Ignore routing protocol announcements from it if when it is run by a customer, but that is no different than any other CPE router. Most handsets now days are more capable than most consumer CPE routers, so moving past the 'it is just a voice endpoint' mindset is appropriate. Tony > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From lorenzo at colitti.com Wed Jun 10 06:43:32 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Wed, 10 Jun 2015 15:43:32 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150610053603.GD2530@bamboo.slabnet.com> References: <20150609031454.GD3716@bender.unx.cpp.edu> <20150610053603.GD2530@bamboo.slabnet.com> Message-ID: On Wed, Jun 10, 2015 at 2:36 PM, Hugo Slabbert wrote: > Pardon my ignorance as I don't currently have field experience with >> 464xlat, but my understanding of the technique is that it is (for the most >> part) dependent on the network cooperating (by providing a DNS64 and NAT64) >> for it to work properly. >> > My point was not "on a SLAAC network, it's possible to implement 464xlat". It was, "on a one-address-per-device network, it's impossible to support 464xlat". Here, 464xlat is just an example of a new technology that needs a separate IP address in order to function. There are other current examples, and unless we get stuck in a one-address-per-device word, there will be future examples too. Multiple posters on the bug/request are coming from enterprise/campus > networks that have existing AUPs and enforcement techniques prohibiting > certain network functions (e.g. content filtering, restricted outbound > access, etc.), and would be making an *active choice* as to whether they do > or do not want to support functions such as tethering, 464xlat, etc. Sure, but today, it is not common practice for networks to prohibit a device from tethering or from using IPv4-only applications on user-managed devices. From a user's point of view, going to a world where such things are prohibited is a regression. And there it is: "SLAAC is better and it isn't that hard; use it > instead." It is up to the network operator to make the design choices that > best fit their network, including if their design goals are to *restrict* > certain network functions. You are saying that you know better. > I don't think that's a useful argument to make, since you are also saying that you know better. From lorenzo at colitti.com Wed Jun 10 06:46:44 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Wed, 10 Jun 2015 15:46:44 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <10cd01d0a348$0e494500$2adbcf00$@tndh.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> <20150609213223.GF999@cmadams.net> <10cd01d0a348$0e494500$2adbcf00$@tndh.net> Message-ID: On Wed, Jun 10, 2015 at 3:38 PM, Tony Hain wrote:I claim that there is a platform bug, because there is never a reason to > > ignore the WiFi RA. Use the other flag to set a preference if that is > needed, but ignoring the RA just breaks things in unexpected ways. LC has > did a hand-wave that the "ignore RA" flag is needed for battery life, but > beyond that we appear to be stuck in a world where Clueless OEMs believe in > breaking one network when another might exist. > This is not how current Android works. Each network can run IPv4, IPv6 or both independently of any other network. If you can reproduce this on a device running current Android (preferably a Nexus device), please file a bug. There is indeed an issue with OEMs dropping RAs when the screen is off. Because it is the OEM that provides the wifi firmware and not Android, it's not really fair to say it's an Android bug. FWIW, recent Nexus devices do not have that bug. From jon at nnbfn.net Wed Jun 10 06:49:51 2015 From: jon at nnbfn.net (Jon Bane) Date: Tue, 9 Jun 2015 23:49:51 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <20150610053603.GD2530@bamboo.slabnet.com> Message-ID: On Tue, Jun 9, 2015 at 11:43 PM, Lorenzo Colitti wrote: > I don't think that's a useful argument to make, since you are also saying > that you know better. > Seriously, this is how you are going to respond? You are claiming you know what is best for everyone and I am telling you that I know is best for MY network. Who are you to even begin to understand my requirement or presume to know them better? seriously? From lorenzo at colitti.com Wed Jun 10 06:59:22 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Wed, 10 Jun 2015 15:59:22 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <20150610053603.GD2530@bamboo.slabnet.com> Message-ID: On Wed, Jun 10, 2015 at 3:49 PM, Jon Bane wrote: > Seriously, this is how you are going to respond? You are claiming you > know what is best for everyone and I am telling you that I know is best for > MY network. Who are you to even begin to understand my requirement or > presume to know them better? > Forgive me, I thought you were saying that you know what operating systems need to do. If that's not what you were saying, then please ignore that part of my reply. From swmike at swm.pp.se Wed Jun 10 06:59:56 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Jun 2015 08:59:56 +0200 (CEST) Subject: Android (lack of) support for DHCPv6 In-Reply-To: <10cd01d0a348$0e494500$2adbcf00$@tndh.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> <20150609213223.GF999@cmadams.net> <10cd01d0a348$0e494500$2adbcf00$@tndh.net> Message-ID: On Tue, 9 Jun 2015, Tony Hain wrote: > I filed a platform bug on this back in the ICS timeframe, and it still > persists. As I recall, there are 2 flags provided by the OS related to RA > handling. Rather than using the one that sets a preference between the Cell > vs. Wifi interface, at least Samsung (possibly others) have chosen to use > the other flag that says to completely ignore the WiFi RA if an RA on the > Cell interface has ever occurred. This means devices that have no IPv6 on > their Cell interface will appear to work fine on WiFi. I just re-verified (same Nexus4 using 5.1.1 on swedish mobile provider Tele2): I disable wifi. I have dual stack on my mobile bearer (PDP context). Verified with 10/10 for both ipv4 and ipv6 on test-ipv4.com (no 464xlat though, this is NAT44:ed IPv4 and native IPv6 on the mobile side). I enable wifi. After a few seconds the Nexus4 connects to my home wifi and starts using it, I get 10/10 for IPv4 on test-ipv4.com and 9/10 for IPv6 because my provider DNS resolver doesn't support native IPv6 lookups. > I claim that there is a platform bug, because there is never a reason to > ignore the WiFi RA. Use the other flag to set a preference if that is > needed, but ignoring the RA just breaks things in unexpected ways. LC > has did a hand-wave that the "ignore RA" flag is needed for battery > life, but beyond that we appear to be stuck in a world where Clueless > OEMs believe in breaking one network when another might exist. Well, it's not present on my Google device anyhow. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Wed Jun 10 07:05:14 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Jun 2015 09:05:14 +0200 (CEST) Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <20150610053603.GD2530@bamboo.slabnet.com> Message-ID: On Tue, 9 Jun 2015, Jon Bane wrote: > Seriously, this is how you are going to respond? You are claiming you > know what is best for everyone and I am telling you that I know is best > for MY network. Who are you to even begin to understand my requirement > or presume to know them better? > > seriously? You seem to fail to realise that you are not Lorenzos customer, his customer is the OEMs that build mobile phones, and their customers who buy Android phones. So while you are doing what you think is best for your network, Lorenzo is doing what he thinks is best for his platform and the hundreds of millions of Android users that are out there. So I happen to agree with Lorenzo that a single IA_NA per device world is a crippled world. Lorenzo said he was willing to work on a document that creates a recommendation for certain minimum amount of IPv6 addresses per device and/or PD, so let's get that happening then? -- Mikael Abrahamsson email: swmike at swm.pp.se From kauer at biplane.com.au Wed Jun 10 07:13:13 2015 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 10 Jun 2015 17:13:13 +1000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> Message-ID: <1433920393.11511.52.camel@karl> On Wed, 2015-06-10 at 15:32 +0900, Lorenzo Colitti wrote: > It's certainly possible to make Android request N IPv6 addresses via > DHCPv6, and not accept the offer if it is offered fewer than N addresses. > But that only really makes sense if there's a generally-agreed upon minimum > value of N. I'd be happy to work with people on an Internet draft or other > standard to define a minimum value for N, but I fear that it may not > possible to gain consensus on that. You need as many as you need. Request them. Worry about it if you don't get them. This is exactly what happens when N=1, BTW. A DHCPv6 server is almost certainly not going to have an upper limit that significantly crimps your style... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From alh-ietf at tndh.net Wed Jun 10 07:14:12 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 10 Jun 2015 00:14:12 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> <20150609213223.GF999@cmadams.net> <10cd01d0a348$0e494500$2adbcf00$@tndh.net> Message-ID: <10d101d0a34d$0dc8b110$295a1330$@tndh.net> From: Lorenzo Colitti [mailto:lorenzo at colitti.com] Sent: Tuesday, June 09, 2015 11:47 PM To: Tony Hain Cc: Mikael Abrahamsson; Chris Adams; NANOG Subject: Re: Android (lack of) support for DHCPv6 On Wed, Jun 10, 2015 at 3:38 PM, Tony Hain wrote:I claim that there is a platform bug, because there is never a reason to ignore the WiFi RA. Use the other flag to set a preference if that is needed, but ignoring the RA just breaks things in unexpected ways. LC has did a hand-wave that the "ignore RA" flag is needed for battery life, but beyond that we appear to be stuck in a world where Clueless OEMs believe in breaking one network when another might exist. This is not how current Android works. Each network can run IPv4, IPv6 or both independently of any other network. If you can reproduce this on a device running current Android (preferably a Nexus device), please file a bug. There is indeed an issue with OEMs dropping RAs when the screen is off. Because it is the OEM that provides the wifi firmware and not Android, it's not really fair to say it's an Android bug. FWIW, recent Nexus devices do not have that bug. My Nexus tablet does not have a Cell interface, and T-Mobile has stopped releasing updates for my phone, so I can't test that. For the issue I saw in the past, there was no screen-off event. All I had to do was enable the IPv6 APN, and given that I live on the edge of the service area the link would drop at some point shortly after. At that point the expected behavior is that IPv6 would still work via wifi, but no. While it still has an address, and can talk to anything on the wire, it has no router because that was removed and the RA is being ignored. I agree the OEM's are likely the problem here, but the platform should not allow them to create an invalid network state. Doing so only insures that they will pick the wrong options and break the network unnecessarily. Tony From A.L.M.Buxey at lboro.ac.uk Wed Jun 10 07:53:44 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Wed, 10 Jun 2015 07:53:44 +0000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: <20150610075344.GA23892@lboro.ac.uk> Hi, > No, the premise is that from a user's point of view, DHCPv6-only networks what about DHCPv6 for IPv6 and DHCP for IPv4 - the client should still be able to pick up an IPv6 address....instead of forcing the only option to be SLAAC ? alan From mpalmer at hezmatt.org Wed Jun 10 01:10:31 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 10 Jun 2015 11:10:31 +1000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> <20150609213223.GF999@cmadams.net> Message-ID: <20150610011031.GH17756@hezmatt.org> On Tue, Jun 09, 2015 at 02:56:26PM -0700, Owen DeLong wrote: > Further, the cellular companies would do well to be more adaptive to the > capabilities that exist in the hardware rather than insisting that they > choose the solution and the hardware makers must adapt. Hahahahahaha! Fun fill in the blanks game: "We're the phone company, __ ___'_ ____ __ ____." - Matt -- The most secure computer in the world is one not connected to the internet. Thats why I recommend Telstra ADSL. -- bash.org/?168859 From johnl at iecc.com Wed Jun 10 08:12:32 2015 From: johnl at iecc.com (John Levine) Date: 10 Jun 2015 08:12:32 -0000 Subject: grepcidr 2.99 In-Reply-To: <6DFDC9F9-EE28-4263-8E5B-EB751B35B2B4@dataix.net> Message-ID: <20150610081232.3178.qmail@ary.lan> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In article <6DFDC9F9-EE28-4263-8E5B-EB751B35B2B4 at dataix.net> you write: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >Hi John, > >Great contribution. Thanks > >Might I make a suggestion? with the following command it gives Invalid CIDR. In >my usage it would seem logically convenient to throw any quad octet at it and >have it translate to the proper CIDR range that isn?t reported as invalid since >it does this anyway. For instance 127.0.0.1/8 would just become 127.0.0.0/8. Already does that with the -s for sloppy flag. >Find it here: > >http://www.taugh.com/grepcidr-2/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlV38XsACgkQkEiFRdeC/kVMHQCfcy7D6fIrhIozpm2rwQ3C10g5 EOYAoKgARRkgkBy/+BRbMSKWd+fWWuaP =9isH -----END PGP SIGNATURE----- From sander at steffann.nl Wed Jun 10 08:31:25 2015 From: sander at steffann.nl (Sander Steffann) Date: Wed, 10 Jun 2015 10:31:25 +0200 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> Message-ID: <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Hi Lorenzo, > It's certainly possible to make Android request N IPv6 addresses via > DHCPv6, and not accept the offer if it is offered fewer than N addresses. > But that only really makes sense if there's a generally-agreed upon minimum > value of N. I'd be happy to work with people on an Internet draft or other > standard to define a minimum value for N, but I fear that it may not > possible to gain consensus on that. I definitely think we should start pushing for N>1 because that will really hurt IPv6 in the future. However any fixed N is a potential danger as requirements will change in the future. But maybe we can do something smarter here. > It's also possible for Android to support DHCPv6 PD. Again I'd be happy to > work with people on a document that says that mobile devices should do > DHCPv6 PD and not DHCP NA, and then implement DHCPv6 PD. But I fear similar > arguments will be had there. I think this will be more difficult to get consensus on, and I can also see more deployment issues (much more state in the routers for all those PDs, needing huge amounts of /64s (or larger) to be able to deal with a few hundred/thousand clients) but it would be very nice if this was possible :) > Asking for more addresses when the user tries to enable features such as > tethering, waiting for the network to reply, and disabling the features if > the network does not provide the necessary addresses does not seem like it > would provide a good user experience. I don't think it is unreasonable. If the network doesn't support the features you need then let the user know (grey out the feature and add a note that says "broken network"). It will put pressure on the network department to fix their DHCPv6 implementation. I have read Lorenzo's arguments and while I don't agree with all of them I do see the risk of creating a situation where N=1 is the default. That would be bad. But instead of not supporting DHCPv6 I think we should work on making sure N>>1. Cheers, Sander From A.L.M.Buxey at lboro.ac.uk Wed Jun 10 08:33:56 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Wed, 10 Jun 2015 08:33:56 +0000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> Message-ID: <20150610083356.GB23892@lboro.ac.uk> Hi, > Asking for more addresses when the user tries to enable features such as > tethering, waiting for the network to reply, and disabling the features if > the network does not provide the necessary addresses does not seem like it > would provide a good user experience. talking of the user experience - any update on when Android will let the user acknowledge a private CA and thus stop the 'your network may be monitored' alert on each restart? :/ alan From baldur.norddahl at gmail.com Wed Jun 10 09:52:10 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 10 Jun 2015 11:52:10 +0200 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <20150610053603.GD2530@bamboo.slabnet.com> Message-ID: We use DHCPv6 to assign just one IP address to the CPE. This is because otherwise our routers do not know where to route the /48 that is also passed along with DHCPv6-PD. The routers are stupid I know, but it is what we got. So we simply implemented a variant of static routes for 2001:db8:x::/48 to 2001:db8::x/128. The DHCP server knows to give you matching /48 and /128. Apart from operational simplicity, we also do not want our routers to keep track of a million ND cache entries. Our system pushes that down to the CPE. In the network we only have one ND cache entry per customer. The Android tethering guy seems to think that tethering should be a bridge. But it should of course be routed. The phone in tethering mode should be getting exactly what we do - one /128 on the uplink interface and a ton of address space it can use internally and sub delegate to tethering clients. What exactly is the argument against supporting a sane environment like that? As a side note, NAT is not the only solution if someone should try to block tethering. I would propose a VPN tunnel. You can then have as much address space you want from the VPN. This is extra easy if you are not locked into the belief that tethering should be a bridge instead of routed. Regards, Baldur From mpalmer at hezmatt.org Wed Jun 10 10:16:02 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 10 Jun 2015 20:16:02 +1000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: <20150610101602.GS17756@hezmatt.org> On Wed, Jun 10, 2015 at 10:31:25AM +0200, Sander Steffann wrote: > I don't think it is unreasonable. If the network doesn't support the > features you need then let the user know (grey out the feature and add a > note that says "broken network"). It will put pressure on the network > department to fix their DHCPv6 implementation. Because that has worked sooooo well in the past, as opposed to the helpdesk person who receives the complaint shrugging their shoulders and saying, "I dunno, that's just the way it is". - Matt From lorenzo at colitti.com Wed Jun 10 10:49:24 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Wed, 10 Jun 2015 19:49:24 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <1433920393.11511.52.camel@karl> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> Message-ID: On Wed, Jun 10, 2015 at 4:13 PM, Karl Auer wrote: > You need as many as you need. Request them. Worry about it if you don't > get them. This is exactly what happens when N=1, BTW. A DHCPv6 server is > almost certainly not going to have an upper limit that significantly > crimps your style... Ok, let's see how that goes, even among the few people on this thread. Question for everyone on this thread that has said that DHCPv6 NA is a requirement: suppose that Android supported stateful DHCPv6 addressing, requested a number of addresses, and did not use any of them if the number of addresses received was less than N. What does N need to be? From lorenzo at colitti.com Wed Jun 10 11:16:25 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Wed, 10 Jun 2015 20:16:25 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: On Wed, Jun 10, 2015 at 5:31 PM, Sander Steffann wrote: > I can also see more deployment issues (much more state in the routers for > all those PDs, needing huge amounts of /64s (or larger) to be able to deal > with a few hundred/thousand clients) but it would be very nice if this was > possible :) > Well, in IPv4 you can do 16M devices in 10/8. You can divide IPv6 space in exactly the same way and give every client a /64. A /24 becomes a /56, and your 10/8 becomes a /40. A /40 is really not hard to get. From dsparro at gmail.com Wed Jun 10 11:29:45 2015 From: dsparro at gmail.com (Dave Sparro) Date: Wed, 10 Jun 2015 07:29:45 -0400 Subject: most accurate geo-IP source to build country-based access lists In-Reply-To: <182A7A20-1BB8-4349-A5DE-88E83DB34E1E@hopcount.ca> References: <26C02A6C-D40F-4C1C-9DA7-C3B13CBFE740@arbor.net> <5575D436.60501@ispn.net> <182A7A20-1BB8-4349-A5DE-88E83DB34E1E@hopcount.ca> Message-ID: Years ago when meeting with the lawyers to talk about the need to block access to a list of websites I was coming from the technical side and talking about how all of our possible solutions were incomplete and easily circumvented by our users. The lawyers' response was to explain the concept of good faith effort. The main point was that we needed to "do something." We'd be in pretty good shape liability-wise as long as we made an attempt. Getting back to the point of the question. I'd find the cheapest/easiest way to implement a somewhat effective GeoIP block, and say that you've done something. On Tue, Jun 9, 2015 at 11:13 AM, Joe Abley wrote: > On 9 Jun 2015, at 5:11, Martin T wrote: > > At a brute force country level it is possible to use the Delegated >>> ranges lists but that runs into the problem where IP ranges are >>> subnetted and allocated to other countries. >>> >> >> Yeah. >> > > I would say that a perfectly accurate mapping of address to anything > geographical (with more accuracy than "it's within the observed universe, > somewhere") is unlikely ever to exist, except by accident and for short > periods of time. Accuracy and lack of authoritative sources of data is one > reason, constant uncoordinated reconfiguration is another. You need to > decide how accurate your mapping needs to be (and figure out how to measure > that, if accuracy is important). > > Another part of the problem is framing the question in a useful way: a > universal solution seems intractable when the following questions are > answered differently (but accurately) by different people who have > different needs. > > Is a device in Uganda connected via satphone to a router in France in > Uganda, or France? > > Is a network in Fiji that can't talk to any other networks in Fiji without > leaving the island but is one layer-3 hop away from Australia in Fiji, or > Australia? > > Does the source address of a packet always identify the device that sent > the packet? > > If I'm in region A and you're in region A, and you route within region to > me but my replies leave the region on the way back, are we in the same > region from my perspective? How about yours? > > Even: if I'm in region A but I'm using a DNS resolver in region B, am I in > region A or region B? > > > Joe > From kauer at biplane.com.au Wed Jun 10 11:30:40 2015 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 10 Jun 2015 21:30:40 +1000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> Message-ID: <1433935840.11511.123.camel@karl> On Wed, 2015-06-10 at 19:49 +0900, Lorenzo Colitti wrote: > Question for everyone on this thread that has said that DHCPv6 NA is a > requirement: suppose that Android supported stateful DHCPv6 addressing, > requested a number of addresses, and did not use any of them if the number > of addresses received was less than N. > What does N need to be? I think that's a wrong question, or maybe I am completely missing your point. Seems to me that N will vary depending on what you are trying to do. And you could well be trying to do several things at once, each with a different requirement. And these things may happen over time, so that at one time you need N, while later you need ten times that many - or half as many, or none. With DHCP you just ask for more when you need more, or release ones you don't need. You don't have to arrange everything up front and then be stuck with it. You know how many addresses you need to provide a given service; you know how to degrade the service gracefully, or whether a graceful degrade is even possible. In other words, you the requester know how many addresses you want and how many you have to have - which are two possibly quite different numbers. Addresses are just a resource, and like any other resource, if the environment can't supply them, you either degrade the service, fail to provide it, or possibly keep trying and provide it later when the resource becomes available. At their most basic, standard DHCPv4 and DHCPv6 clients do exactly that - they keep trying until they get addresses. Not being able to get enough addresses is pretty much like not being able to get enough RAM or disk space, but you make it sound like running out of power! It is not an all-or-nothing proposition at a platform level, and demanding to know "what is N?" implies that it is. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From rps at maine.edu Wed Jun 10 11:35:32 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 10 Jun 2015 07:35:32 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: So here is the thing. You can try to use enhanced functionality which depends on multiple addresses as justification for saying DHCPv6 is not supported. In practice, your device will just not be supported. As you pointed out, there isn't anything that forces adoption of IPv6 right now. If your client is broken because of an incomplete implementation, I just won't give it an IPv6 address at all. I think a lot of others feel the same way. At least on our network, the number of Apple devices dwarf Android by several times. With Android being a minority and not implementing DHCPv6 support you force us to make Android a second class citizen. I'm perfectly find NATing Android, and don't see us giving up the operational benefits to DHCPv6 anytime soon. Also, in terms of hotspot functionality being the major driver ... I already provide ubiquitous wireless coverage. I don't want users enabling a hotspot (rogue AP) on campus because it has a negative impact on service for others, so the whole argument is really meaningless in the context of higher education and campus networking. A phone makes a terrible AP when the laptop supports full 802.11ac. I really don't know anyone who connects through their phone when WiFi is available and the phone is also connected to the same WiFi network. It's not even a use case I think most people would consider common or valid but we're using it a justification to not support something that IS very common and widely deployed. On Wed, Jun 10, 2015 at 7:16 AM, Lorenzo Colitti wrote: > On Wed, Jun 10, 2015 at 5:31 PM, Sander Steffann > wrote: > > > I can also see more deployment issues (much more state in the routers for > > all those PDs, needing huge amounts of /64s (or larger) to be able to > deal > > with a few hundred/thousand clients) but it would be very nice if this > was > > possible :) > > > > Well, in IPv4 you can do 16M devices in 10/8. You can divide IPv6 space in > exactly the same way and give every client a /64. A /24 becomes a /56, and > your 10/8 becomes a /40. A /40 is really not hard to get. > -- 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 A.L.M.Buxey at lboro.ac.uk Wed Jun 10 11:39:16 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Wed, 10 Jun 2015 11:39:16 +0000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> Message-ID: <20150610113916.GA24478@lboro.ac.uk> Hi, > Ok, let's see how that goes, even among the few people on this thread. > > Question for everyone on this thread that has said that DHCPv6 NA is a > requirement: suppose that Android supported stateful DHCPv6 addressing, > requested a number of addresses, and did not use any of them if the number > of addresses received was less than N. > > What does N need to be? well, from memory and a quick discussion with a colleague, our cisco wireless kit is only happy with devices having 8 IPv6 addresses at most - otherwise the older addresses get removed from the neighbour cache. is that a good starting point? :-) alan From russw at riw.us Wed Jun 10 11:51:17 2015 From: russw at riw.us (Russ White) Date: Wed, 10 Jun 2015 07:51:17 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> Message-ID: <049501d0a373$c3611370$4a233a50$@riw.us> > > Crypto = more overhead. Less priority to crypto plus DDoS = routing > > update issues. > > I don't think there's an update issue here. The crypto verification is probably > going to be deferred in addition to being low priority. If I understand it > correctly, this means that a route can be passed along right away without > waiting for the crypto checks. I don't think this quite fits with Postel's law... There's also the size of the table and the ability to pack (compress) the information to consider. > > One can infer peering relationships in a way not possible before. > > How? The keys are per router, not per AS. You could use a single private/public key pair across the entire AS -- but that's not good security hygiene. There's no way to sign an update without exposing the signer; if you sign at anything below the AS level, you're exposing new information. What about the per NLRI timer? The timer is essentially the amount of time you'd like someone to be able to advertise a route once the peering session is broken. How long are you comfortable with someone advertising your routes after you've taken down your peering with them? What's the performance impact of forcing every route in the table to expire, say, every 24 hours? Given your cost of setting your timers to a few minutes or hours is nil (you're transferring the cost of your increased security onto "everyone else"), why not set it lower? Tragedy of the commons? I'm not saying BGPSEC a bad solution for the questions asked -- I'm saying it's is too heavyweight given the tradeoffs, and that we probably started with the wrong questions in the first place. What's needed is to spend some time thinking about what questions really need to be answered, the lowest cost way to answer those questions, and a complete examination of the tradeoffs involved. Is "what path did this update travel," or "are the BGP semantics being properly followed," really questions that want asking? Or are there other, more pertinent questions available? :-) Russ From johnl at iecc.com Wed Jun 10 11:56:46 2015 From: johnl at iecc.com (John Levine) Date: 10 Jun 2015 11:56:46 -0000 Subject: Lists of VPN exit addresses? Message-ID: <20150610115646.3900.qmail@ary.lan> Does anyone keep lists of the exit addresses of public VPN services? I presume there is no need to explain why this would be of interest. R's, John From swmike at swm.pp.se Wed Jun 10 12:03:47 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Jun 2015 14:03:47 +0200 (CEST) Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <20150610053603.GD2530@bamboo.slabnet.com> Message-ID: On Wed, 10 Jun 2015, Baldur Norddahl wrote: > We use DHCPv6 to assign just one IP address to the CPE. This is because > otherwise our routers do not know where to route the /48 that is also > passed along with DHCPv6-PD. If you use DHCPv6-PD you only need a LL address, you do not need a GUA address. Yes, a GUA WAN address is nice for fault finding, shows up in traceroute etc, but it's not needed. If your routers require a GUA WAN address in order for DHCPv6-PD to work, then they're not standards compliant. > Apart from operational simplicity, we also do not want our routers to > keep track of a million ND cache entries. Our system pushes that down to > the CPE. In the network we only have one ND cache entry per customer. Well, if you have a GUA /128, then you have two per customer (because you'll have the LL one as well). If you didn't use the GUA address, you'd only have one. -- Mikael Abrahamsson email: swmike at swm.pp.se From lorenzo at colitti.com Wed Jun 10 12:06:51 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Wed, 10 Jun 2015 21:06:51 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <1433935840.11511.123.camel@karl> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> <1433935840.11511.123.camel@karl> Message-ID: On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer wrote: > Seems to me that N will vary depending on what you are trying to do. Remember, what I'm trying to do is avoid user-visible regressions while getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no buts, no requests to the network. The user turns it on, and it works. IPv4-only apps always work. A model where the device has to request resources from the network before enabling tethering, or before supporting IPv4-only apps, provides a much worse user experience. The user might have to wait a long time, or the operation might even fail. From rdobbins at arbor.net Wed Jun 10 12:08:08 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 10 Jun 2015 19:08:08 +0700 Subject: Lists of VPN exit addresses? In-Reply-To: <20150610115646.3900.qmail@ary.lan> References: <20150610115646.3900.qmail@ary.lan> Message-ID: On 10 Jun 2015, at 18:56, John Levine wrote: > I presume there is no need to explain why this would be of interest. To keep consumers who've legitimately purchased/rented/subscribed to content from accessing same when they travel internationally? Because as a regular international traveler, that's what springs to mind when I see requests like this. Another thought is governmentally-driven censorship, something else I encounter a lot in my travels. ----------------------------------- Roland Dobbins From randy at psg.com Wed Jun 10 12:10:44 2015 From: randy at psg.com (Randy Bush) Date: Wed, 10 Jun 2015 05:10:44 -0700 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <049501d0a373$c3611370$4a233a50$@riw.us> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> <049501d0a373$c3611370$4a233a50$@riw.us> Message-ID: > The keys are per router, not per AS. rtfm. bgpsec key aggregation is at the descretion of the operator. they could use one key to cover 42 ASs. randy From ggm at algebras.org Wed Jun 10 12:12:52 2015 From: ggm at algebras.org (George Michaelson) Date: Wed, 10 Jun 2015 14:12:52 +0200 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> <1433935840.11511.123.camel@karl> Message-ID: On Wed, Jun 10, 2015 at 2:06 PM, Lorenzo Colitti wrote: > On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer wrote: > > > Seems to me that N will vary depending on what you are trying to do. > > > Remember, what I'm trying to do is avoid user-visible regressions while > getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no > buts, no requests to the network. The user turns it on, and it works. > IPv4-only apps always work. > > A model where the device has to request resources from the network before > enabling tethering, or before supporting IPv4-only apps, provides a much > worse user experience. The user might have to wait a long time, or the > operation might even fail. > Laudible goal. I think with mifi devices typically limiting to 8/16 I have a sense that a /56 (which btw, was the unit we expected to use for mass-customer deployment edge numbering) is going to be ok. Its inevitable that in some other N+ years, we're going to be astonished by how many IPs are needed behind the connecting device, but a /56->/64 gap is going to work for now. So pragmatism drives me to say 'we probably have enough in the model we're working on' I say this, because whilst I personally don't like the HD ratio model, its what we adopted as a global measure of density of use, and I think respecting allocation practice which reflects the HD ratio model is good, and drives us to /56 for mass-customer deployments. (I know there are policy people who may believe /48 is where we're going to go. I can only say thats not how I understand address allocation modelling works in many regions, right now. I also know there are people who think a single customer can be a /128. I don't agree with that either) -G From jared at puck.nether.net Wed Jun 10 12:15:54 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 10 Jun 2015 08:15:54 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> <1433935840.11511.123.camel@karl> Message-ID: > On Jun 10, 2015, at 8:06 AM, Lorenzo Colitti wrote: > > On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer wrote: > >> Seems to me that N will vary depending on what you are trying to do. > > > Remember, what I'm trying to do is avoid user-visible regressions while > getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no > buts, no requests to the network. The user turns it on, and it works. > IPv4-only apps always work. > > A model where the device has to request resources from the network before > enabling tethering, or before supporting IPv4-only apps, provides a much > worse user experience. The user might have to wait a long time, or the > operation might even fail. Sure, but when you take a NAT and replace it with no-NAT there will be no-NAT regressions as a result. Perhaps doing 66 w/ ULA would provide a comparable experience? IPv4 and IPv6 are enough alike that 99% of things ?just work? but it?s in the 1% of ARP v NDP, is what we?re talking about here. - Jared From kauer at biplane.com.au Wed Jun 10 12:21:00 2015 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 10 Jun 2015 22:21:00 +1000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> <1433935840.11511.123.camel@karl> Message-ID: <1433938860.11511.146.camel@karl> On Wed, 2015-06-10 at 21:06 +0900, Lorenzo Colitti wrote: > On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer wrote: > > Seems to me that N will vary depending on what you are trying to do. > A model where the device has to request resources from the network before > enabling tethering, or before supporting IPv4-only apps, provides a much > worse user experience. The user might have to wait a long time, or the > operation might even fail. I understand. I took issue only with the idea that any value of N could be "right". Don't forget though that IPv4 phones also need resources from the network - their public IPv4 addresses. Why isn't that a showstopper too? Hm... The essential difference with IPv6 compared to IPv4 is that (due to address abundance) all addresses are (or at least can be) globally routable. There can be a direct bidirectional relationship between a connected device and the world; of necessity, that relationship brings with it a higher degree of interdependence. It's a pretty simple thing really: You can have all that that IPv6 offers (both now and potentially), or you can cripple it so that the user experience is "just like IPv4". I get where you are coming from. It's just a bit sad, is all. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From jared at puck.nether.net Wed Jun 10 12:21:43 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 10 Jun 2015 08:21:43 -0400 Subject: Lists of VPN exit addresses? In-Reply-To: References: <20150610115646.3900.qmail@ary.lan> Message-ID: <4A200C79-18FA-4498-9014-07F429F1A666@puck.nether.net> > On Jun 10, 2015, at 8:08 AM, Roland Dobbins wrote: > > > On 10 Jun 2015, at 18:56, John Levine wrote: > >> I presume there is no need to explain why this would be of interest. > > To keep consumers who've legitimately purchased/rented/subscribed to content from accessing same when they travel internationally? > > Because as a regular international traveler, that's what springs to mind when I see requests like this. > > Another thought is governmentally-driven censorship, something else I encounter a lot in my travels. I?ll just simplify this and say that the Tor Project publishes a list of its exit nodes so you can block these if your abuse/fraud requirements necessitate this. https://check.torproject.org/cgi-bin/TorBulkExitList.py If it?s for geolocation blocking, I?m in favor of these political limitations to go away. It doesn?t take a genius to bypass these if that?s your intent. - Jared From lorenzo at colitti.com Wed Jun 10 12:21:38 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Wed, 10 Jun 2015 21:21:38 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: On Wed, Jun 10, 2015 at 8:35 PM, Ray Soucy wrote: > In practice, your device will just not be supported. > > As you pointed out, there isn't anything that forces adoption of IPv6 > right now. > It's certainly a possibility for both sides in this debate to say "my way or the highway", and wait and see what happens when operators start removing support for IPv4. > I'm perfectly find NATing Android, and don't see us giving up the > operational benefits to DHCPv6 anytime soon. > Oh, I definitely see that DHCPv6 is easier for network operators. But even if you're dead set on using DHCPv6, what I don't see is why don't you support DHCPv6 PD instead of IA_NA? It's the same amount of state. Same accountability. Same transaction model. But unlike NA, the device gets as many addresses as it needs. Nothing breaks, and you get future flexibility. Mobile devices don't have to implement NAT, and application developers don't have to work around it. You size your IPv6 pools based on the size of your IPv4 pools, and don't run out of addresses. Technically, that sort of arrangement is superior to IA_NA in basically every way. So... why use IA_NA? Even if the answers are "that's what we do in IPv4, and we want to do it the same way", or "we're worried that this is strange and will tickle vendor bugs", "it's not supported by the IPAM we use today", or "this is what we've decided, our network our rules", I would hope that we as an industry can think a little longer term than that. Also, in terms of hotspot functionality being the major driver > Don't think about yesterday, think about tomorrow. Tethering and 464xlat are just two examples of what can be done when you have the ability to use more than one IPv6 address and cannot be done without that. We know these will break today; tomorrow, we can use multiple addresses to do things we haven't thought of yet. From tore at fud.no Wed Jun 10 12:31:03 2015 From: tore at fud.no (Tore Anderson) Date: Wed, 10 Jun 2015 14:31:03 +0200 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> <1433935840.11511.123.camel@karl> Message-ID: <20150610143103.4700248d@envy.fud.no> * Lorenzo Colitti > Remember, what I'm trying to do is avoid user-visible regressions > while getting rid of NAT. Today in IPv4, tethering just works, > period. No ifs, no buts, no requests to the network. The user turns > it on, and it works. *cough* https://code.google.com/p/android/issues/detail?id=38563 In particular comment 105 is illuminating. Android is apparently fully on-board with mobile carriers' desire to break tethering, even going so far as to implement a feature whose *sole purpose* is to break thethering. Yet, at the same time, you refuse to implement DHCPv6 on WiFi because it *might*, as a *side effect*, break tethering. This does not strike me as very consistent. If Android had instead simply refused to establish a mobile data connection to the mobile carriers that breaks tethering, then the refusal to implement DHCPv6 would make much more sense. Tore From lorenzo at colitti.com Wed Jun 10 12:44:52 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Wed, 10 Jun 2015 21:44:52 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150610143103.4700248d@envy.fud.no> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> <1433935840.11511.123.camel@karl> <20150610143103.4700248d@envy.fud.no> Message-ID: On Wed, Jun 10, 2015 at 9:31 PM, Tore Anderson wrote: > In particular comment 105 is illuminating. Android is apparently fully > on-board with mobile carriers' desire to break tethering, even going so > far as to implement a feature whose *sole purpose* is to break > thethering. > > Yet, at the same time, you refuse to implement DHCPv6 on WiFi because it > *might*, as a *side effect*, break tethering. This does not strike me > as very consistent. > Tethering is just one example that we know about today. Another example is 464xlat. And that's not counting future applications that can take advantage of multiple IP addresses that we haven't thought of yet, and that we will have if we get stuck with there-are-more-IPv6-addresses-in-this-subnet-than-grains-of-sand-but-you-only-get-one-because-that's-how-we-did-it-in-IPv4 networks. From cma at cmadams.net Wed Jun 10 12:48:36 2015 From: cma at cmadams.net (Chris Adams) Date: Wed, 10 Jun 2015 07:48:36 -0500 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> <1433935840.11511.123.camel@karl> Message-ID: <20150610124836.GA9759@cmadams.net> Once upon a time, Lorenzo Colitti said: > Remember, what I'm trying to do is avoid user-visible regressions while > getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no > buts, no requests to the network. The user turns it on, and it works. > IPv4-only apps always work. Except for the ones that don't. Tethering is far from "just works, period." VPNs, VOIP, and games are things that don't always just work (behind any kind of NAT). -- Chris Adams From jared at puck.nether.net Wed Jun 10 13:04:09 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 10 Jun 2015 09:04:09 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150610124836.GA9759@cmadams.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> <1433935840.11511.123.camel@karl> <20150610124836.GA9759@cmadams.net> Message-ID: <6ABB819D-E884-4B12-95D2-D7733962E9BB@puck.nether.net> > On Jun 10, 2015, at 8:48 AM, Chris Adams wrote: > > Except for the ones that don't. Tethering is far from "just works, > period." VPNs, VOIP, and games are things that don't always just work > (behind any kind of NAT). Please don?t bring facts into a discussion about ideologies of IPv6. I think this is the problem that many of us face when dealing with the day-to-date operational challenges of pitching IPv6 at others, many things break for all sorts of reasons. Those of us fighting to enable this technology everywhere face a number of challenges from vendors (8 IPv6 address limits, passive-aggressive bug-fixing, etc) My favorite vendor bug fix for IPv6 up to this point was this one: This is a point fix for a forwarding issue in ipv6 over bundle area. It does not enable/claim support of ipv6 over bundle So you fix a bug but don?t claim support for the bug you just fixed. Hmm. Either way, we need to continue to push on these sensitive areas to make things happen. I?m waiting for folks like Apple to turn on IPv6 on their CDN, or even deliver software updates over IPv6 to mobile devices. I suspect that would be a watershed moment as most people see huge traffic jumps on iOS release day. (Next one is June 30th apparently). Should be exciting. - Jared From rps at maine.edu Wed Jun 10 13:06:18 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 10 Jun 2015 09:06:18 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: Actually we do support DHCPv6-PD, but Android doesn't even support DHCPv6 let alone PD, so that's the discussion here, isn't it? As for thinking "long term" and "the future", we need devices to work within current models of IPv6 to accelerate _adoption_ of IPv6 _today_ before we can get to that future you're talking about. Not supporting DHCPv6 ultimately holds back adoption, which makes people see IPv6 as optional for longer, and discourages deployment because vendor support is all over the place and seen as "not ready". This isn't theory, we've been _living_ with this as a reality for years now. The networks are ready; the clients are not. Universities see a constant stream of DMCA violation notices that need to be dealt with and not being able to associate a specific IPv6 address to a specific user is a big enough liability that the only option is to not use IPv6. As I said, Android becomes a second class citizen on the network under your model. On Wed, Jun 10, 2015 at 8:21 AM, Lorenzo Colitti wrote: > On Wed, Jun 10, 2015 at 8:35 PM, Ray Soucy wrote: > >> In practice, your device will just not be supported. >> >> As you pointed out, there isn't anything that forces adoption of IPv6 >> right now. >> > > It's certainly a possibility for both sides in this debate to say "my way > or the highway", and wait and see what happens when operators start > removing support for IPv4. > > >> I'm perfectly find NATing Android, and don't see us giving up the >> operational benefits to DHCPv6 anytime soon. >> > > Oh, I definitely see that DHCPv6 is easier for network operators. > > But even if you're dead set on using DHCPv6, what I don't see is why don't > you support DHCPv6 PD instead of IA_NA? It's the same amount of state. Same > accountability. Same transaction model. But unlike NA, the device gets as > many addresses as it needs. Nothing breaks, and you get future flexibility. > Mobile devices don't have to implement NAT, and application developers > don't have to work around it. You size your IPv6 pools based on the size of > your IPv4 pools, and don't run out of addresses. Technically, that sort of > arrangement is superior to IA_NA in basically every way. So... why use > IA_NA? > > Even if the answers are "that's what we do in IPv4, and we want to do it > the same way", or "we're worried that this is strange and will tickle > vendor bugs", "it's not supported by the IPAM we use today", or "this is > what we've decided, our network our rules", I would hope that we as an > industry can think a little longer term than that. > > Also, in terms of hotspot functionality being the major driver >> > > Don't think about yesterday, think about tomorrow. Tethering and 464xlat > are just two examples of what can be done when you have the ability to use > more than one IPv6 address and cannot be done without that. We know these > will break today; tomorrow, we can use multiple addresses to do things we > haven't thought of yet. > -- 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 baldur.norddahl at gmail.com Wed Jun 10 13:13:10 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 10 Jun 2015 15:13:10 +0200 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <20150610053603.GD2530@bamboo.slabnet.com> Message-ID: On 10 June 2015 at 14:03, Mikael Abrahamsson wrote: > On Wed, 10 Jun 2015, Baldur Norddahl wrote: > > We use DHCPv6 to assign just one IP address to the CPE. This is because >> otherwise our routers do not know where to route the /48 that is also >> passed along with DHCPv6-PD. >> > > If you use DHCPv6-PD you only need a LL address, you do not need a GUA > address. Yes, a GUA WAN address is nice for fault finding, shows up in > traceroute etc, but it's not needed. If your routers require a GUA WAN > address in order for DHCPv6-PD to work, then they're not standards > compliant. > I need the GUA to have a stable and predictable next hop for my static route of the /48 prefix delegation. What standard exactly requires my router to be able to snoop a DHCP-PD to create routes dynamically? That was left out and one solution is the one we use. Note that the /48 static routes are configured on the routers well in advantage of the customer even signing up for the service. It is just there waiting for a customer to be assigned the corresponding /128. > > Apart from operational simplicity, we also do not want our routers to >> keep track of a million ND cache entries. Our system pushes that down to >> the CPE. In the network we only have one ND cache entry per customer. >> > > Well, if you have a GUA /128, then you have two per customer (because > you'll have the LL one as well). If you didn't use the GUA address, you'd > only have one. Yes my bad, we will have exactly two cache entries per customer. That is still better than SLAAC with unbounded caches and all the possibility of getting DoS attacks on NDP, extra CPU use etc on my network. Why would I want that, when I can deliver perfect service to the customer with a fixed cache of 2 entries? I have nothing against SLAAC it just does not belong in the carrier network. Regards, Baldur From jra at baylink.com Wed Jun 10 03:49:03 2015 From: jra at baylink.com (Jay Ashworth) Date: Tue, 9 Jun 2015 23:49:03 -0400 (EDT) Subject: eBay is looking for network heavies... In-Reply-To: Message-ID: <12616019.0.1433908143109.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Shane Ronan" > When I was asked the default BGP timers across three different vendor > platforms as measure of my networking ability during an interview, I > replied saying I'd look them up if needed them. > > I was told I didn't understand BGP in enough detail, despite being able to > describe all the steps of BGP session establishment and route > exchange. > > Certs have ruined the industry. Maybe. But they certainly saved you from having to work for an asshole with misplaced priorities... 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 russw at riw.us Wed Jun 10 13:17:36 2015 From: russw at riw.us (Russ White) Date: Wed, 10 Jun 2015 09:17:36 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> <049501d0a373$c3611370$4a233a50$@riw.us> Message-ID: <061c01d0a37f$d24844b0$76d8ce10$@riw.us> > rtfm. bgpsec key aggregation is at the descretion of the operator. > they could use one key to cover 42 ASs. I've been reading the presentations and the mailing lists, both of which imply you should use one key per router for security reasons. I would tend to agree with that assessment, BTW. Russ From wesley.george at twcable.com Wed Jun 10 13:25:20 2015 From: wesley.george at twcable.com (George, Wes) Date: Wed, 10 Jun 2015 09:25:20 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: On 6/9/15, 11:01 PM, "Lorenzo Colitti" wrote: >No, the premise is that from a user's point of view, DHCPv6-only networks >cause regressions in functionality compared to IPv4-only or dual-stack >networks. For example: IPv4 apps cannot be supported at all due because >464xlat cannot be made to work, and functions such as tethering cannot be >implemented because there are no IP addresses to assign to downstream >devices. > >Implementing IPv6 NAT can resolve some but not all of these regressions >(for example, IPv4 apps still cannot be supported). Thus, attempting to >operate on DHCPv6-only networks a) will create pressure to implement IPv6 >NAT, which causes lots of issues like application complexity, battery life >issues due to keepalives, etc. b) impose user-visible regressions even if >we do implement IPv6 NAT. > >From a user's point of view, that's just a bad deal, especially since >IPv4-only networks, dual-stack networks, and IPv6-only networks using >SLAAC >do not have any of those issues. Stateless DHCP and stateful DHCPv6 PD >have >none of those issues, either. If we really need stateful addressing, then >we should statefully assign prefixes, not single addresses. WG] ok, I *finally* understand the distinction you're making here, despite the weird way you're making the argument. You're equating DHCPv6-only with "single stack IPv6", which is odd, because you're simultaneously waving away concerns about android not working on IPv6-only networks because it won't be able to get addresses by saying that you assume that no one is turning off IPv4 on their network tomorrow since that'll break lots of other things. The reality is that this whole argument is needlessly conflating multiple things in a way that isn't helpful, so I'm going to try to break this into pieces in order to make forward progress and try to get us away from what is devolving into a debate that is equal parts religion and kool-aid drinking contest among IPv6 ?bernerds. 1) there are *dual stack* networks out there that happen to support IPv4 and IPv6 via DHCP only (I.e. No SLAAC). This is a fact, and you may not like it, but there's simply no way that you're going to be able to change it in 100% of the situations. Most of the folks involved in this discussion are asserting that Android needs to support those so that the things that can work over IPv6, even with just a single address, will. 2) on a dual stack network, when the device gets fewer IPv6 addresses than it wants/needs, it can continue using the same solution it uses on an IPv4 network, even if it's a sub-optimal NAT-based solution. Having a single IPv6 address is still a net improvement over where we are today, where 100% of the traffic has to be on IPv4 and probably behind multiple layers of NAT. 3) 464xlat being broken is a non-issue on a dual-stack network, since it is expressly designed to act as a shim for IPv4-dependent apps on an IPv6-only network. 4) At some point in the future, there will be IPv6-only networks. At that time, Android will no longer be able to rely on IPv4 as a fallback mechanism, and if it can only get one address, that will break things. Definitely a problem, but not necessarily one that has to be solved immediately, since anyone doing an IPv6-only network today already knows that they need to make a lot of allowances for transition mechanisms and other things to prevent breakage, or are using IPv6-only in tightly controlled situations where there is no breakage because they can ensure 100% IPv6 support among the things using the network. 5) there are multiple possible ways for a device to get multiple IPv6 addresses if it needs them, including DHCPv6 with multiple IA_NA requests, a DCHPv6-PD request, SLAAC, or some sort of bridging that allows multiple virtual interfaces to use the same physical interface, such as the simple type of hypervisor networking that allows multiple VMs to get DHCP addresses assigned from the same network. So what this means is that there is a draft to be written about the need for multiple address support on IPv6 networks for mobile devices, enumerating the ways that they use those multiple addresses, and how it differs from today's IPv4-only or dual-stack implementations, along with a big discussion on the breakage that can happen on IPv6-only networks if a device can't get the addresses it needs. It is a fool's errand to assume that we can dictate one and only one solution to #5 (regardless of one's perceived influence and market power), so the best we can do is to document the preferred one(s) and hope that we've made a good enough case or made them easy enough to use that the majority of network operators do support them. Sunset4 is the right place for that draft, so let's discuss it at the next IETF. However, the spectre of #4 does NOT mean that DHCPv6 is unusable because it would break things today on a dual-stack network, so you need to stop trying to imply that, and stop trying to optimize for use cases that you yourself admit basically don't exist today by blocking support for something that we could use today to have more devices using IPv6, were it available. Thanks, Wes George Anything below this line has been added by my company?s mail server, I have no control over it. ----------- 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 wesley.george at twcable.com Wed Jun 10 13:28:58 2015 From: wesley.george at twcable.com (George, Wes) Date: Wed, 10 Jun 2015 09:28:58 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> <20150609213223.GF999@cmadams.net> Message-ID: On 6/9/15, 11:06 PM, "Lorenzo Colitti" wrote: >Based on the facts, you could could just as well say that Apple is trying >to advance the state of the art by refusing to provide suboptimal 464xlat >and insisting instead that developers support IPv6-only networks as >first-class citizens: > >https://twitter.com/dteam69/status/608036976990797824 WG] I have suggested before that google needs to do the same thing with their app developers. Since you believe that your market power makes you able to influence the way that people deploy IPv6 (i.e. Not using DHCPv6 because you refuse to support it), perhaps it's time to wield that power to move the needle on IPv6 use in the app community instead of telling network operators that are deploying IPv6 that they're "doing it wrong"? >By the same token, you could argue that not supporting statful DHCPv6 >address assignment advances the state of the art by trying to avoid >slipping back into a "one-address-per-device-NAT-required" world. WG] or you could argue that not supporting stateful DHCPv6 blocks IPv6 deployment by preventing it from being used on networks where it is otherwise available on applications that are perfectly happy to have one IPv6 address. That's a lot of traffic that ends up going to the NAT for no good reason. Thanks, Wes Anything below this line has been added by my company?s mail server, I have no control over it. ----------- 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 randy at psg.com Wed Jun 10 13:31:07 2015 From: randy at psg.com (Randy Bush) Date: Wed, 10 Jun 2015 06:31:07 -0700 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <061c01d0a37f$d24844b0$76d8ce10$@riw.us> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> <049501d0a373$c3611370$4a233a50$@riw.us> <061c01d0a37f$d24844b0$76d8ce10$@riw.us> Message-ID: >> rtfm. bgpsec key aggregation is at the descretion of the operator. >> they could use one key to cover 42 ASs. > > I've been reading the presentations and the mailing lists, both of > which imply you should use one key per router for security reasons. > I would tend to agree with that assessment, BTW. folk have different threat models. yours (and mine) may be propagation of router compromise. for others, it might be a subtle increase in disclosure of router links. contrary to your original assertion, the protocol supports both. randy From russw at riw.us Wed Jun 10 13:44:14 2015 From: russw at riw.us (Russ White) Date: Wed, 10 Jun 2015 09:44:14 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> <049501d0a373$c3611370$4a233a50$@riw.us> <061c01d0a37f$d24844b0$76d8ce10$@riw.us> Message-ID: <066701d0a383$8b7aaba0$a27002e0$@riw.us> > folk have different threat models. yours (and mine) may be propagation of > router compromise. for others, it might be a subtle increase in disclosure of > router links. contrary to your original assertion, the protocol supports both. The increased disclosure is not "subtle." The alternate -- deploying a new key to every eBGP speaker in your network while the security of all your routes is compromised, isn't so "subtle" either. It's a bad tradeoff in either direction -- typical of solutions that ask the wrong questions in the first place. Russ From jra at baylink.com Wed Jun 10 13:45:14 2015 From: jra at baylink.com (Jay Ashworth) Date: Wed, 10 Jun 2015 09:45:14 -0400 (EDT) Subject: OT Fiber contractors? Message-ID: <28065428.2.1433943914755.JavaMail.root@benjamin.baylink.com> I have a client needs a couple outside under-parkinglot runs installed*, and I'm so long out of that market I have no idea where to go. Offlist recs for Tampa metro cheerfully accepted. :-) Cheers, -- jra [ * Pulled and terminated; we'll supply the switches and do the interconnect ] -- 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 wesley.george at twcable.com Wed Jun 10 13:50:28 2015 From: wesley.george at twcable.com (George, Wes) Date: Wed, 10 Jun 2015 09:50:28 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> Message-ID: On 6/10/15, 2:32 AM, "Lorenzo Colitti" wrote: >I'd be happy to work with people on an Internet draft or other >standard to define a minimum value for N, but I fear that it may not >possible to gain consensus on that. WG] No, I think that the document you need to write is the one that explains why a mobile device needs multiple addresses, and make some suggestions about the best way to support that. Your earlier response detailing those vs how they do it in IPv4 today was the first a lot of us have heard of that, because we're not in mobile device development and don't necessarily understand the secret sauce involved. This is especially true for your mention of things like WiFi calling, and all of the other things that aren't tethering or 464xlat, since neither of those are as universally agreed-upon as "must have" on things like enterprise networks. I'm sure there are also use cases we haven't thought of yet, so I'm not trying to turn this into a debate about which use cases are valid, just observing that you might get more traction with the others. >Asking for more addresses when the user tries to enable features such as >tethering, waiting for the network to reply, and disabling the features if >the network does not provide the necessary addresses does not seem like it >would provide a good user experience. WG] Nor does not having IPv6 at all, and being stuck behind multiple layers of NAT, but for some reason you seem ok with that, which confuses me greatly. The amount of collective time wasted arguing this is likely more than enough to come up with cool ways to optimize the ask/wait/enable function so that it doesn't translate to a bad user experience, and few things on a mobile device are instantaneous anyway, so let's stop acting like it's an unsolvable problem. Thanks, Wes Anything below this line has been added by my company?s mail server, I have no control over it. ---------- 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 swmike at swm.pp.se Wed Jun 10 13:53:35 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Jun 2015 15:53:35 +0200 (CEST) Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <20150610053603.GD2530@bamboo.slabnet.com> Message-ID: On Wed, 10 Jun 2015, Baldur Norddahl wrote: > I need the GUA to have a stable and predictable next hop for my static > route of the /48 prefix delegation. > > What standard exactly requires my router to be able to snoop a DHCP-PD to > create routes dynamically? That was left out and one solution is the one we > use. > > Note that the /48 static routes are configured on the routers well in > advantage of the customer even signing up for the service. It is just there > waiting for a customer to be assigned the corresponding /128. Well, then you're not doing what most people do when they do DHCPv6-PD, you're using something else. This is the first time I have heard of anyone doing what you describe. Normally it's done by the router acting on DHCPv6 packets and installing a route if need be. http://www.cisco.com/c/en/us/support/docs/ip/ip-version-6-ipv6/113141-DHCPv6-00.html As soon as the PD is handed out, a corresponding route will be installed for that PD to the address (potentially LL address) that requested that PD. > getting DoS attacks on NDP, extra CPU use etc on my network. Why would I > want that, when I can deliver perfect service to the customer with a fixed > cache of 2 entries? If you did PD the way it's normally done, you would need 1 entry, not 2. I do agree that you do not want your equipment sitting in the same broadcast domain as all the customers devices, but do use PD. I'm just baffled by the way you have implemented "PD". -- Mikael Abrahamsson email: swmike at swm.pp.se From rps at maine.edu Wed Jun 10 13:54:03 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 10 Jun 2015 09:54:03 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> Message-ID: The whole conversation is around 464XLAT on IPv6-only networks right? We're going to be dual-stack for a while IMHO, and by the time we can get away with IPv6 only for WiFi, 464 should no longer be relevant because we'll have widespread IPv6 adoption by then. Carriers can do IPv6 only because they tightly control the clients, for WiFi clients are and will always be all over the place, so dual stack will be pretty much a given for a long time. On Wed, Jun 10, 2015 at 9:50 AM, George, Wes wrote: > > On 6/10/15, 2:32 AM, "Lorenzo Colitti" wrote: > > >I'd be happy to work with people on an Internet draft or other > >standard to define a minimum value for N, but I fear that it may not > >possible to gain consensus on that. > > WG] No, I think that the document you need to write is the one that > explains why a mobile device needs multiple addresses, and make some > suggestions about the best way to support that. Your earlier response > detailing those vs how they do it in IPv4 today was the first a lot of us > have heard of that, because we're not in mobile device development and > don't necessarily understand the secret sauce involved. This is especially > true for your mention of things like WiFi calling, and all of the other > things that aren't tethering or 464xlat, since neither of those are as > universally agreed-upon as "must have" on things like enterprise networks. > I'm sure there are also use cases we haven't thought of yet, so I'm not > trying to turn this into a debate about which use cases are valid, just > observing that you might get more traction with the others. > > > >Asking for more addresses when the user tries to enable features such as > >tethering, waiting for the network to reply, and disabling the features if > >the network does not provide the necessary addresses does not seem like it > >would provide a good user experience. > > WG] Nor does not having IPv6 at all, and being stuck behind multiple > layers of NAT, but for some reason you seem ok with that, which confuses > me greatly. The amount of collective time wasted arguing this is likely > more than enough to come up with cool ways to optimize the ask/wait/enable > function so that it doesn't translate to a bad user experience, and few > things on a mobile device are instantaneous anyway, so let's stop acting > like it's an unsolvable problem. > > Thanks, > > Wes > > > Anything below this line has been added by my company?s mail server, I > have no control over it. > ---------- > > > 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. > -- 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 wesley.george at twcable.com Wed Jun 10 13:54:18 2015 From: wesley.george at twcable.com (George, Wes) Date: Wed, 10 Jun 2015 09:54:18 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <20150610053603.GD2530@bamboo.slabnet.com> Message-ID: On 6/10/15, 9:13 AM, "Baldur Norddahl" wrote: >What standard exactly requires my router to be able to snoop a DHCP-PD to >create routes dynamically? That was left out and one solution is the one >we >use. WG] We use this in cable-land, so it's definitely documented in the DOCSIS standards. Not sure it exists anywhere in the IETF standards, and so YMMV on which platforms do and do not support it. Thanks, Wes 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 frnkblk at iname.com Wed Jun 10 14:15:53 2015 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 10 Jun 2015 09:15:53 -0500 Subject: Access to nanog.cluepon.net In-Reply-To: <13830863.2876.1433789222012.JavaMail.mhammett@ThunderFuck> References: <13830863.2876.1433789222012.JavaMail.mhammett@ThunderFuck> Message-ID: <00e001d0a387$f5b09fd0$e111df70$@iname.com> I see that nanog.cluepon.net is still down ? is Richard S. *the* person for this? Frank From: Mike Hammett [mailto:nanog at ics-il.net] Sent: Monday, June 08, 2015 1:47 PM To: Josh Luthman Cc: NANOG list; Frank Bulk Subject: Re: Access to nanog.cluepon.net Still down here (and apparently elsewhere as a request on another list was about it being down as well). ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com _____ From: "Josh Luthman" > To: "Frank Bulk" > Cc: "NANOG list" > Sent: Saturday, June 6, 2015 12:33:17 PM Subject: Re: Access to nanog.cluepon.net Hasn't been working for about 20 minutes or more for me as well. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Sat, Jun 6, 2015 at 1:27 PM, Frank Bulk > wrote: > I'd like to update some material on nanog.cluepon.net (not very responsive > to HTTP requests right now) and my account doesn't work anymore. I reached > out to Richard S. but have not heard back from him - anyone else here who > has admin access and can set me up again? > > Frank > > From swmike at swm.pp.se Wed Jun 10 14:27:23 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Jun 2015 16:27:23 +0200 (CEST) Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <20150610053603.GD2530@bamboo.slabnet.com> Message-ID: On Wed, 10 Jun 2015, George, Wes wrote: > > On 6/10/15, 9:13 AM, "Baldur Norddahl" wrote: > >> What standard exactly requires my router to be able to snoop a DHCP-PD to >> create routes dynamically? That was left out and one solution is the one >> we >> use. > > WG] We use this in cable-land, so it's definitely documented in the DOCSIS > standards. Not sure it exists anywhere in the IETF standards, and so YMMV > on which platforms do and do not support it. http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/15-sy/dhcp-15-sy-book/ip6-dhcp-rel-agent.html#GUID-52D23F09-6829-4950-9431-92D9B7A255C0 "DHCPv6 Relay Agent Notification for Prefix Delegation The DHCPv6 relay agent notification for prefix delegation allows the device working as a DHCPv6 relay agent to find prefix delegation options by reviewing the contents of a DHCPv6 RELAY-REPLY packet that is relayed by the relay agent to the client. When a prefix delegation option is found by the relay agent, the relay agent extracts the information about the prefix that is being delegated and inserts an IPv6 static route matching the prefix delegation information onto the relay agent. Future packets destined to that prefix via relay will be forwarded based on the information contained in the prefix delegation. The IPv6 static route is then left in the routing table until the prefix delegation lease time expires or the relay agent receives a release packet from the client releasing the prefix delegation." I can't find IETF standards language apart from this: "14. Relay agent behavior A relay agent forwards messages containing Prefix Delegation options in the same way as described in section 20, "Relay Agent Behavior" of RFC 3315. If a delegating router communicates with a requesting router through a relay agent, the delegating router may need a protocol or other out-of-band communication to add routing information for delegated prefixes into the provider edge router." >From what I can find, a lot of vendors seem to have functionality implemented to look at the relayed messages and install static routes without any OOO-communication. -- Mikael Abrahamsson email: swmike at swm.pp.se From lorenzo at colitti.com Wed Jun 10 14:58:23 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Wed, 10 Jun 2015 23:58:23 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy wrote: > Actually we do support DHCPv6-PD, but Android doesn't even support DHCPv6 > let alone PD, so that's the discussion here, isn't it? > It is possible to implement DHCPv6 without implementing stateful address assignment. If there were consensus that delegating a prefix of sufficient size via DHCPv6 PD of a sufficient size is an acceptable substitute for stateful IPv6 addressing in the environments that currently insist on stateful DHCPv6 addressing, then it would make sense to implement it. In that scenario, Android would still not implement DHCPv6 NA, but it would implement DHCPv6 PD. What needs to be gauged about that course of action is how much consensus would be achieved, whether network operators would actually use it (IPv6 has a long and distinguished history of people claiming "I can't support IPv6 until I get feature X", feature X appearing, and people changing their claim to "I can't support IPv6 until I get feature Y"), and how much of this discussion would be put to bed. That course of action would seem most feasible if it were accompanied by an IETF document that explained the deployment model and clarified what "sufficient size" is. > Universities see a constant stream of DMCA violation notices that need to > be dealt with and not being able to associate a specific IPv6 address to a > specific user is a big enough liability that the only option is to not use > IPv6. > It's not the *only* option. There are large networks - O(100k) IPv6 nodes - that do ND monitoring for accountability, and it does work for them. Many devices support this via syslog, even. As you can imagine, my Android device gets IPv6 at work, even though it doesn't support DHCPv6. Other universities, too. It's obviously not your chosen or preferred mechanism, but it does work. From rps at maine.edu Wed Jun 10 15:15:54 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 10 Jun 2015 11:15:54 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: Respectfully disagree on all points. The statement that "Android would still not implement DHCPv6 NA, but it would implement DHCPv6 PD." is troubling because you're not even willing to entertain the idea for reasons that are rooted in idealism rather than pragmatism. Very disappointing to see that this is the position of Google. On Wed, Jun 10, 2015 at 10:58 AM, Lorenzo Colitti wrote: > On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy wrote: > >> Actually we do support DHCPv6-PD, but Android doesn't even support DHCPv6 >> let alone PD, so that's the discussion here, isn't it? >> > > It is possible to implement DHCPv6 without implementing stateful address > assignment. > > If there were consensus that delegating a prefix of sufficient size via > DHCPv6 PD of a sufficient size is an acceptable substitute for stateful > IPv6 addressing in the environments that currently insist on stateful > DHCPv6 addressing, then it would make sense to implement it. In that > scenario, Android would still not implement DHCPv6 NA, but it would > implement DHCPv6 PD. > > What needs to be gauged about that course of action is how much consensus > would be achieved, whether network operators would actually use it (IPv6 > has a long and distinguished history of people claiming "I can't support > IPv6 until I get feature X", feature X appearing, and people changing their > claim to "I can't support IPv6 until I get feature Y"), and how much of > this discussion would be put to bed. > > That course of action would seem most feasible if it were accompanied by > an IETF document that explained the deployment model and clarified what > "sufficient size" is. > > >> Universities see a constant stream of DMCA violation notices that need to >> be dealt with and not being able to associate a specific IPv6 address to a >> specific user is a big enough liability that the only option is to not use >> IPv6. >> > > It's not the *only* option. There are large networks - O(100k) IPv6 nodes > - that do ND monitoring for accountability, and it does work for them. Many > devices support this via syslog, even. As you can imagine, my Android > device gets IPv6 at work, even though it doesn't support DHCPv6. Other > universities, too. It's obviously not your chosen or preferred mechanism, > but it does work. > -- 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 lorenzo at colitti.com Wed Jun 10 15:21:34 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Thu, 11 Jun 2015 00:21:34 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: On Wed, Jun 10, 2015 at 10:25 PM, George, Wes wrote: > The reality is that this whole argument is needlessly conflating multiple > things in a way that isn't helpful, so I'm going to try to break this into > pieces in order to make forward progress and try to get us away from what > is devolving into a debate that is equal parts religion and kool-aid > drinking contest among IPv6 ?bernerds. > Thank you for trying to reword what I tried to express. Your assessment pretty much matches mine, except for the conclusion (see below). > So what this means is that there is a draft to be written about the need > for multiple address support on IPv6 networks for mobile devices, > enumerating the ways that they use those multiple addresses, and how it > differs from today's IPv4-only or dual-stack implementations, along with a > big discussion on the breakage that can happen on IPv6-only networks if a > device can't get the addresses it needs. It is a fool's errand to assume > that we can dictate one and only one solution to #5 (regardless of one's > perceived influence and market power), so the best we can do is to > document the preferred one(s) and hope that we've made a good enough case > or made them easy enough to use that the majority of network operators do > support them. > Sunset4 is the right place for that draft, so let's discuss it at the next > IETF. > Yep (but perhaps in v6ops instead of sunset4, see below). > However, the spectre of #4 does NOT mean that DHCPv6 is unusable because > it would break things today on a dual-stack network, so you need to stop > trying to imply that, and stop trying to optimize for use cases that you > yourself admit basically don't exist today by blocking support for > something that we could use today to have more devices using IPv6, were it > available. > I disagree with this part of the conclusion. I don't think it's a good plan to implement stateful DHCPv6 now and postpone the solution of the problem until IPv4 goes away many years from now. By then, a lot of water will have flowed under the bridge by then, and a lot of one-address-only networks will have been deployed and have moulded industry thinking. So, much as it pains me to stand in the way of IPv6 adoption - and you should how much I've tried to do on that front - I think that that wide deployment of one-address-per-device IPv6 might actually do more harm than good, and I expect that many operators who are going to require stateful DHCPv6 addressing are going to use it for one-address-per-device IPv6. I really think it's better if we get this right now, not kick the can down the road. That means we as an industry need to find a solution for IPv6 deployment in university/enterprise networks that does not devolve into one-address-per-device IPv6, *before* one-address-per-device IPv6 becomes universally implemented and usable. From lorenzo at colitti.com Wed Jun 10 15:26:45 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Thu, 11 Jun 2015 00:26:45 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: Ray, please do not construe my words on this thread as being Google's position on anything. These messages were sent from my personal email address, and I do not speak for my employer. Regards, Lorenzo On Thu, Jun 11, 2015 at 12:15 AM, Ray Soucy wrote: > Respectfully disagree on all points. > > The statement that "Android would still not implement DHCPv6 NA, but it > would implement DHCPv6 PD." is troubling because you're not even willing to > entertain the idea for reasons that are rooted in idealism rather > than pragmatism. > > Very disappointing to see that this is the position of Google. > > > On Wed, Jun 10, 2015 at 10:58 AM, Lorenzo Colitti > wrote: > >> On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy wrote: >> >>> Actually we do support DHCPv6-PD, but Android doesn't even support >>> DHCPv6 let alone PD, so that's the discussion here, isn't it? >>> >> >> It is possible to implement DHCPv6 without implementing stateful address >> assignment. >> >> If there were consensus that delegating a prefix of sufficient size via >> DHCPv6 PD of a sufficient size is an acceptable substitute for stateful >> IPv6 addressing in the environments that currently insist on stateful >> DHCPv6 addressing, then it would make sense to implement it. In that >> scenario, Android would still not implement DHCPv6 NA, but it would >> implement DHCPv6 PD. >> >> What needs to be gauged about that course of action is how much consensus >> would be achieved, whether network operators would actually use it (IPv6 >> has a long and distinguished history of people claiming "I can't support >> IPv6 until I get feature X", feature X appearing, and people changing their >> claim to "I can't support IPv6 until I get feature Y"), and how much of >> this discussion would be put to bed. >> >> That course of action would seem most feasible if it were accompanied by >> an IETF document that explained the deployment model and clarified what >> "sufficient size" is. >> >> >>> Universities see a constant stream of DMCA violation notices that need >>> to be dealt with and not being able to associate a specific IPv6 address to >>> a specific user is a big enough liability that the only option is to not >>> use IPv6. >>> >> >> It's not the *only* option. There are large networks - O(100k) IPv6 nodes >> - that do ND monitoring for accountability, and it does work for them. Many >> devices support this via syslog, even. As you can imagine, my Android >> device gets IPv6 at work, even though it doesn't support DHCPv6. Other >> universities, too. It's obviously not your chosen or preferred mechanism, >> but it does work. >> > > > > -- > 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 mohta at necom830.hpcl.titech.ac.jp Wed Jun 10 15:30:07 2015 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 11 Jun 2015 00:30:07 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: <557857FF.5070208@necom830.hpcl.titech.ac.jp> Lorenzo Colitti wrote: > It's not the *only* option. There are large networks - O(100k) IPv6 nodes - > that do ND monitoring for accountability, and it does work for them. Many > devices support this via syslog, even. As you can imagine, my Android > device gets IPv6 at work, even though it doesn't support DHCPv6. Other > universities, too. It's obviously not your chosen or preferred mechanism, > but it does work. Considering that a DOS attack from a node using a lot of addresses to effectively disable logging, SLAAC must not be used, unless maximum N, the maximum number of addresses for a node to have, is standardized ( assuming a node is securely identified through the first hop security, which is necessary to enforce the number of addresses used by each node). Masataka Ohta From tore at fud.no Wed Jun 10 15:35:18 2015 From: tore at fud.no (Tore Anderson) Date: Wed, 10 Jun 2015 17:35:18 +0200 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> <1433935840.11511.123.camel@karl> <20150610143103.4700248d@envy.fud.no> Message-ID: <20150610173518.4ccfcdd3@envy.fud.no> * Lorenzo Colitti > Tethering is just one example that we know about today. Another example is > 464xlat. You can't do 464XLAT without the network operator's help anyway (unless you/Google is planning on hosting a public NAT64 service?). If the network operator actively wants 464XLAT to be used, by providing DNS64/NAT64 service, then it seems fairly reasonable to assume that they're not going to deploy an IPv6/DHCPv6-only network that limits the number of IA_NA per attached node to 1. > And that's not counting future applications that can take > advantage of multiple IP addresses that we haven't thought of yet, and that > we will have if we get stuck with > there-are-more-IPv6-addresses-in-this-subnet-than-grains-of-sand-but-you-only-get-one-because-that's-how-we-did-it-in-IPv4 > networks. Of course. Hard to argue against imaginary things. :-) On the other hand, there exist applications *today* that do require DHCPv6. One such example would be MAP, which IMHO is superior to 464XLAT both for the network operator (statlessness ftw) as well as for the end user (unsolicited inbound packets work, no NAT traversal required). MAP is provisioned with DHCPv6 (I-D.ietf-softwire-map-dhcp), so without DHCPv6 support in Android, MAP support in Android is a non-starter. Tore From baldur.norddahl at gmail.com Wed Jun 10 15:45:48 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 10 Jun 2015 17:45:48 +0200 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <20150610053603.GD2530@bamboo.slabnet.com> Message-ID: On 10 June 2015 at 15:53, Mikael Abrahamsson wrote: > > Well, then you're not doing what most people do when they do DHCPv6-PD, > you're using something else. This is the first time I have heard of anyone > doing what you describe. > I mentioned because the Android guy seems to be guilty of knowing how everyone does or want to run their network. There are always more ways to do this than you thought of. Normally it's done by the router acting on DHCPv6 packets and installing a > route if need be. > I would probably do it like that if my equipment had support. But it does not. And I can not point at any RFCs to tell my vendor that their stuff is broken, because the requirement simply is not in any RFCs. Also consider this: 1) The DHCP relay might not be the same router that needs to do the forwarding. 2) There might be more than one router that can forward. 3) There might not even be a DHCP relay, the DHCP server could be attached directly. In our case we have GPON access switches that do DHCP(v6) snooping. These things can block illegal traffic, but other than that, they are purely layer 2 devices. There is no relay there and no layer 3 forwarding, so no routes can be installed by anything. Upstream from the access switches there are many ways you can structure your network. You might want to have two routers for redundancy. You may attach the DHCP server directly here if it is a small network (although we use relays). Static routes with a fixed GUA next hop for the /48 prefix delegations means you can have some pretty dumb (=cheap) stuff in your network. All you need is an intelligent DHCP server and that is just open source software on a Linux. I considered having the DHCP server add the routes via a script that is triggered by lease handout. But the fixed static routes is much simpler and robust. > I do agree that you do not want your equipment sitting in the same > broadcast domain as all the customers devices, but do use PD. I'm just > baffled by the way you have implemented "PD". > > We all work with the equipment we got and the quirks in there. Just do not go around and assume everyone has the same requirements as you. Saying there is no use case for DHCPv6 except for PD is dumb and that was why I put forward a use case to illustrate how this is used in the real world. At least by us. Regards, Baldur From sandy at tislabs.com Wed Jun 10 15:46:15 2015 From: sandy at tislabs.com (Sandra Murphy) Date: Wed, 10 Jun 2015 11:46:15 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <049501d0a373$c3611370$4a233a50$@riw.us> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> <049501d0a373$c3611370$4a233a50$@riw.us> Message-ID: On Jun 10, 2015, at 7:51 AM, "Russ White" wrote: > > I'm not saying BGPSEC a bad solution for the questions asked -- I'm saying it's is too heavyweight given the tradeoffs, and that we probably started with the wrong questions in the first place. > > What's needed is to spend some time thinking about what questions really need to be answered, the lowest cost way to answer those questions, and a complete examination of the tradeoffs involved. Is "what path did this update travel," or "are the BGP semantics being properly followed," really questions that want asking? Or are there other, more pertinent questions available? > Not liking the solution is not a reason to abandon the problem. This sounds like "I don't like eating right and exercising, so keeping my weight under control is the wrong question" All protocols rely on certain assumptions of what the fields mean - when you send them and when you receive them. Analyzing a protocol for vulnerabilities starts with identifying what happens if those assumptions are broken. (Like the assumption in IP that the source address is the node that sent the packet - spoofing breaks that assumption.) Breaking the semantics creates attacks. --Sandy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sandy at tislabs.com Wed Jun 10 15:54:08 2015 From: sandy at tislabs.com (Sandra Murphy) Date: Wed, 10 Jun 2015 11:54:08 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <061c01d0a37f$d24844b0$76d8ce10$@riw.us> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> <049501d0a373$c3611370$4a233a50$@riw.us> <061c01d0a37f$d24844b0$76d8ce10$@riw.us> Message-ID: <63A98784-80C5-4A76-976E-47E480294C03@tislabs.com> There have been suggestions that a key-per-AS is easier to manage than a key-per-router, like in provisioning. Key-per-router was brought up as providing the means to excise one misbehaving router that is in some risky sort of environment, which is a different management pain. In terms of security, from outside the AS, you are basing your decisions on your trust in the AS in the key-per-AS case, and you are basing your decisions on your trust in the AS that certified the router in the key-per-router case. The local operator's environment and policy rule in choosing the technique. The draft draft-ietf-sidr-bgpsec-ops-05 says: A site/operator MAY use a single certificate/key in all their routers, one certificate/key per router, or any granularity in between. --Sandy On Jun 10, 2015, at 9:17 AM, "Russ White" wrote: > >> rtfm. bgpsec key aggregation is at the descretion of the operator. >> they could use one key to cover 42 ASs. > > I've been reading the presentations and the mailing lists, both of which > imply you should use one key per router for security reasons. I would tend > to agree with that assessment, BTW. > > Russ -------------- 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 alh-ietf at tndh.net Wed Jun 10 16:13:18 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 10 Jun 2015 09:13:18 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: <117e01d0a398$5d4eb4a0$17ec1de0$@tndh.net> Ray Soucy wrote: > > Respectfully disagree on all points. > > The statement that "Android would still not implement DHCPv6 NA, but it would > implement DHCPv6 PD." is troubling because you're not even willing to > entertain the idea for reasons that are rooted in idealism rather than > pragmatism. In Lorenzo's defense, I believe he is taking the long term pragmatic position, while you appear to be taking the short term idealistic position. For argument's sake... let's assume that a shiny new browser comes along the is designed to limit third party cross site correlation and tracking. It does this by using a different source address for every destination. This browser works fine on any network that allows N>1, but is stuck in the myopic historical world of older browsers on networks where N=1. To the pragmatism point, would you rather have a device like that do N NA requests (creating N ND state entries), or have it do PD (creating 1 ND + 1 Routing entry)? Tony > > Very disappointing to see that this is the position of Google. > > > On Wed, Jun 10, 2015 at 10:58 AM, Lorenzo Colitti > wrote: > > > On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy wrote: > > > >> Actually we do support DHCPv6-PD, but Android doesn't even support > >> DHCPv6 let alone PD, so that's the discussion here, isn't it? > >> > > > > It is possible to implement DHCPv6 without implementing stateful > > address assignment. > > > > If there were consensus that delegating a prefix of sufficient size > > via > > DHCPv6 PD of a sufficient size is an acceptable substitute for > > stateful > > IPv6 addressing in the environments that currently insist on stateful > > DHCPv6 addressing, then it would make sense to implement it. In that > > scenario, Android would still not implement DHCPv6 NA, but it would > > implement DHCPv6 PD. > > > > What needs to be gauged about that course of action is how much > > consensus would be achieved, whether network operators would actually > > use it (IPv6 has a long and distinguished history of people claiming > > "I can't support > > IPv6 until I get feature X", feature X appearing, and people changing > > their claim to "I can't support IPv6 until I get feature Y"), and how > > much of this discussion would be put to bed. > > > > That course of action would seem most feasible if it were accompanied > > by an IETF document that explained the deployment model and clarified > > what "sufficient size" is. > > > > > >> Universities see a constant stream of DMCA violation notices that > >> need to be dealt with and not being able to associate a specific IPv6 > >> address to a specific user is a big enough liability that the only > >> option is to not use IPv6. > >> > > > > It's not the *only* option. There are large networks - O(100k) IPv6 > > nodes > > - that do ND monitoring for accountability, and it does work for them. > > Many devices support this via syslog, even. As you can imagine, my > > Android device gets IPv6 at work, even though it doesn't support > > DHCPv6. Other universities, too. It's obviously not your chosen or > > preferred mechanism, but it does work. > > > > > > -- > 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 lorenzo at colitti.com Wed Jun 10 16:17:47 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Thu, 11 Jun 2015 01:17:47 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150610173518.4ccfcdd3@envy.fud.no> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> <1433935840.11511.123.camel@karl> <20150610143103.4700248d@envy.fud.no> <20150610173518.4ccfcdd3@envy.fud.no> Message-ID: On Thu, Jun 11, 2015 at 12:35 AM, Tore Anderson wrote: > > And that's not counting future applications that can take > > advantage of multiple IP addresses that we haven't thought of yet, and > that > > we will have if we get stuck with > > > there-are-more-IPv6-addresses-in-this-subnet-than-grains-of-sand-but-you-only-get-one-because-that's-how-we-did-it-in-IPv4 > > networks. > > Of course. Hard to argue against imaginary things. :-) > I think "imaginary" is the wrong word here. There's a difference between imaginary things and leaving room for for future innovation. Phone network model vs. Internet model is the usual example that comes to mind. > On the other hand, there exist applications *today* that do require > DHCPv6. One such example would be MAP, which IMHO is superior to > 464XLAT both for the network operator (statlessness ftw) as well as for > the end user (unsolicited inbound packets work, no NAT traversal > required). MAP is provisioned with DHCPv6 (I-D.ietf-softwire-map-dhcp), > so without DHCPv6 support in Android, MAP support in Android is a > non-starter. > Support for the DHCPv6 protocol, or support for assigning addresses from IA_NA? From jeffm at iglou.com Wed Jun 10 15:36:22 2015 From: jeffm at iglou.com (Jeff McAdams) Date: Wed, 10 Jun 2015 10:36:22 -0500 Subject: Android (lack of) support for DHCPv6 In-Reply-To: Message-ID: Then you need to be far more careful about what you say. When you said "Android would still not support..." you, very clearly, made a statement of product direction for a Google product. There is no other rational way to interpret your statement than to be a statement of Google's position. -- Jeff On Jun 10, 2015 10:26 AM, Lorenzo Colitti wrote: > > Ray, > > please do not construe my words on this thread as being Google's position > on anything. These messages were sent from my personal email address, and I > do not speak for my employer. > > Regards, > Lorenzo > > On Thu, Jun 11, 2015 at 12:15 AM, Ray Soucy wrote: > > > Respectfully disagree on all points. > > > > The statement that "Android would still not implement DHCPv6 NA, but it > > would implement DHCPv6 PD." is troubling because you're not even willing to > > entertain the idea for reasons that are rooted in idealism rather > > than pragmatism. > > > > Very disappointing to see that this is the position of Google. > > > > > > On Wed, Jun 10, 2015 at 10:58 AM, Lorenzo Colitti > > wrote: > > > >> On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy wrote: > >> > >>> Actually we do support DHCPv6-PD, but Android doesn't even support > >>> DHCPv6 let alone PD, so that's the discussion here, isn't it? > >>> > >> > >> It is possible to implement DHCPv6 without implementing stateful address > >> assignment. > >> > >> If there were consensus that delegating a prefix of sufficient size via > >> DHCPv6 PD of a sufficient size is an acceptable substitute for stateful > >> IPv6 addressing in the environments that currently insist on stateful > >> DHCPv6 addressing, then it would make sense to implement it. In that > >> scenario, Android would still not implement DHCPv6 NA, but it would > >> implement DHCPv6 PD. > >> > >> What needs to be gauged about that course of action is how much consensus > >> would be achieved, whether network operators would actually use it (IPv6 > >> has a long and distinguished history of people claiming "I can't support > >> IPv6 until I get feature X", feature X appearing, and people changing their > >> claim to "I can't support IPv6 until I get feature Y"), and how much of > >> this discussion would be put to bed. > >> > >> That course of action would seem most feasible if it were accompanied by > >> an IETF document that explained the deployment model and clarified what > >> "sufficient size" is. > >> > >> > >>> Universities see a constant stream of DMCA violation notices that need > >>> to be dealt with and not being able to associate a specific IPv6 address to > >>> a specific user is a big enough liability that the only option is to not > >>> use IPv6. > >>> > >> > >> It's not the *only* option. There are large networks - O(100k) IPv6 nodes > >> - that do ND monitoring for accountability, and it does work for them. Many > >> devices support this via syslog, even. As you can imagine, my Android > >> device gets IPv6 at work, even though it doesn't support DHCPv6. Other > >> universities, too. It's obviously? not your chosen or preferred mechanism, > >> but it does work. > >> > > > > > > > > -- > > 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 lorenzo at colitti.com Wed Jun 10 16:29:34 2015 From: lorenzo at colitti.com (Lorenzo Colitti) Date: Thu, 11 Jun 2015 01:29:34 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: Message-ID: On Thu, Jun 11, 2015 at 12:36 AM, Jeff McAdams wrote: > Then you need to be far more careful about what you say. When you said > "Android would still not support..." you, very clearly, made a statement of > product direction for a Google product. Did you intentionally leave the "in that scenario," words that came right before the ones you quoted? How does a sentence that says "in that scenario, android would " constitute a statement of direction? From baconzombie at gmail.com Wed Jun 10 16:38:18 2015 From: baconzombie at gmail.com (Bacon Zombie) Date: Wed, 10 Jun 2015 18:38:18 +0200 Subject: Lists of VPN exit addresses? In-Reply-To: <4A200C79-18FA-4498-9014-07F429F1A666@puck.nether.net> References: <20150610115646.3900.qmail@ary.lan> <4A200C79-18FA-4498-9014-07F429F1A666@puck.nether.net> Message-ID: Well if they are using Hola then EVERY person with it installed is an exit-node. http://adios-hola.org https://m.reddit.com/r/netsec/comments/37rit3/adios_hola_why_you_should_immediately_uninstall/ On 10 Jun 2015 14:28, "Jared Mauch" wrote: > > > On Jun 10, 2015, at 8:08 AM, Roland Dobbins wrote: > > > > > > On 10 Jun 2015, at 18:56, John Levine wrote: > > > >> I presume there is no need to explain why this would be of interest. > > > > To keep consumers who've legitimately purchased/rented/subscribed to > content from accessing same when they travel internationally? > > > > Because as a regular international traveler, that's what springs to mind > when I see requests like this. > > > > Another thought is governmentally-driven censorship, something else I > encounter a lot in my travels. > > I?ll just simplify this and say that the Tor Project publishes a list of > its exit nodes so you can block these if your abuse/fraud requirements > necessitate this. > > https://check.torproject.org/cgi-bin/TorBulkExitList.py > > If it?s for geolocation blocking, I?m in favor of these political > limitations to go away. It doesn?t take a genius to bypass these if that?s > your intent. > > - Jared From dave.taht at gmail.com Wed Jun 10 16:39:24 2015 From: dave.taht at gmail.com (Dave Taht) Date: Wed, 10 Jun 2015 09:39:24 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <20150610173518.4ccfcdd3@envy.fud.no> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> <1433935840.11511.123.camel@karl> <20150610143103.4700248d@envy.fud.no> <20150610173518.4ccfcdd3@envy.fud.no> Message-ID: On Wed, Jun 10, 2015 at 8:35 AM, Tore Anderson wrote: > * Lorenzo Colitti > >> Tethering is just one example that we know about today. In android's case I am perpetually bemused by the fact they use dnsmasq for tethered dhcp, and dnsmasq long ago added support for doing smarter things with slaac, and dhcpv6. Merely upgrading that package in the android distro would get everything needed except dhcp-pd support into android (for which openwrt has got some decent daemons for). dnsmasq is not used in android for dns (which is too bad as dnssec support was also added to it and I hope most of the bugs ironed out, in the last 3 years), as their dns resolver is in java and is admittedly mildly more secure if less featureful. I am told that well over 50% of all android development comes from volunteer developers so rather than kvetching about this it seems plausible for an outside effort to get the needed features for tethering and using dhcpv6-pd into it. If someone wanted to do the work. >> Another example is >> 464xlat. > > You can't do 464XLAT without the network operator's help anyway (unless > you/Google is planning on hosting a public NAT64 service?). If the > network operator actively wants 464XLAT to be used, by providing > DNS64/NAT64 service, then it seems fairly reasonable to assume that > they're not going to deploy an IPv6/DHCPv6-only network that limits the > number of IA_NA per attached node to 1. > >> And that's not counting future applications that can take >> advantage of multiple IP addresses that we haven't thought of yet, and that >> we will have if we get stuck with >> there-are-more-IPv6-addresses-in-this-subnet-than-grains-of-sand-but-you-only-get-one-because-that's-how-we-did-it-in-IPv4 >> networks. > > Of course. Hard to argue against imaginary things. :-) > > On the other hand, there exist applications *today* that do require > DHCPv6. One such example would be MAP, which IMHO is superior to > 464XLAT both for the network operator (statlessness ftw) as well as for > the end user (unsolicited inbound packets work, no NAT traversal > required). MAP is provisioned with DHCPv6 (I-D.ietf-softwire-map-dhcp), > so without DHCPv6 support in Android, MAP support in Android is a > non-starter. > > Tore -- Dave T?ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From swhyte at gmail.com Wed Jun 10 16:49:22 2015 From: swhyte at gmail.com (Scott Whyte) Date: Wed, 10 Jun 2015 09:49:22 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: Message-ID: <55786A92.8070809@gmail.com> On 6/10/15 08:36, Jeff McAdams wrote: > There is no > other rational way to interpret your statement than to be a statement > of Google's position. > False dichotomies suck. From jared at puck.nether.net Wed Jun 10 17:06:01 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 10 Jun 2015 13:06:01 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: Message-ID: > On Jun 10, 2015, at 11:36 AM, Jeff McAdams wrote: > > There is no other rational way to interpret your statement than to be a statement of Google's position. As someone who posts from a personal email but my management has told me that I?m well identifiable as who I work for, I?m sympathetic to the way one can suffer a bit of personality split when certain business realities come into play. I?m sure people might mock me for it, but lots of people have mocked me for years so why should I care about this one so much? When a business reality or necessity hits you in the face, sometimes you can?t do anything about it. Would I have preferred if Apple and AT&T let me tether on my grandfathered unlimited plan? Sure. Could I do this before on my unlimited GPRS/Edge plan with my Nokia? Of course, but the reality is I can just carry another device/SIM and use a tablet to tether. As google is in a business of selling ads on the internet, I can see why they might not want to pick a fight with a carrier at every stage in the process. The ROI just isn?t there is my guess. IPv6 is mature enough to be widely deployed, but some of these cases need to have some give/take on both sides to work out. I?m reminded of the adage of if both sides are unhappy you cut the baby properly in half. - jared From jeffm at iglou.com Wed Jun 10 17:08:02 2015 From: jeffm at iglou.com (Jeff McAdams) Date: Wed, 10 Jun 2015 12:08:02 -0500 Subject: Android (lack of) support for DHCPv6 In-Reply-To: Message-ID: From kauer at biplane.com.au Wed Jun 10 17:13:34 2015 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 11 Jun 2015 03:13:34 +1000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <55786A92.8070809@gmail.com> References: <55786A92.8070809@gmail.com> Message-ID: <1433956414.11511.165.camel@karl> On Wed, 2015-06-10 at 09:49 -0700, Scott Whyte wrote: > False dichotomies suck. There are only two kinds of dichotomy... those that suck and those that do not. This one sucks. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From rps at maine.edu Wed Jun 10 17:18:04 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 10 Jun 2015 13:18:04 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: Message-ID: I don't really feel I was trying to take things out of context, but the full quote would be: "If there were consensus that delegating a prefix of sufficient size via DHCPv6 PD of a sufficient size is an acceptable substitute for stateful IPv6 addressing in the environments that currently insist on stateful DHCPv6 addressing, then it would make sense to implement it. In that scenario, Android would still not implement DHCPv6 NA, but it would implement DHCPv6 PD." To me, that's essentially saying: "EVEN IF we decided to support DHCPv6-PD, and that's a big IF, we will never support stateful address assignment via DHCPv6." This rings especially true when compared against the context of everything else you've written on the subject. I think that's how most others on this list would read it as well. If that isn't what you meant to say, then I'm sorry. I'm certainly not trying to put words in your mouth. I still feel that it's a very poor position to take. Given that you don't speak for Google on the subject, if you're not the decision maker for this issue on Android, could you pull in the people at Google who are, or at least point us to them? A lot of us would like the chance to make our case and expose the harm that Android is doing by not supporting DHCPv6. I think the Android team is very overconfident in their ability to shape the direction of IPv6 adoption, especially with years old Android releases being still in production and it taking incredibly long for changes to trickle down through the Android ecosystem. That delay is also why we have a hard time accepting the mindset that IF you see a need for it in the future you'll add it. That will be 4 to 8 years too late. On Wed, Jun 10, 2015 at 12:29 PM, Lorenzo Colitti wrote: > On Thu, Jun 11, 2015 at 12:36 AM, Jeff McAdams wrote: > >> Then you need to be far more careful about what you say. When you said >> "Android would still not support..." you, very clearly, made a statement of >> product direction for a Google product. > > > Did you intentionally leave the "in that scenario," words that came right > before the ones you quoted? > > How does a sentence that says "in that scenario, android would " > constitute a statement of direction? > -- 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 sander at steffann.nl Wed Jun 10 17:42:31 2015 From: sander at steffann.nl (Sander Steffann) Date: Wed, 10 Jun 2015 19:42:31 +0200 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: <79EC58CC-1AB1-4BDE-96E4-1D25ED893C70@steffann.nl> > > It's not the *only* option. There are large networks - O(100k) IPv6 nodes - that do ND monitoring for accountability, and it does work for them. Many devices support this via syslog, even. As you can imagine, my Android device gets IPv6 at work, even though it doesn't support DHCPv6. Other universities, too. It's obviously not your chosen or preferred mechanism, but it does work. /me starts to write that whitepaper that educates people on how to do this Cheers, Sander From wesley.george at twcable.com Wed Jun 10 17:54:30 2015 From: wesley.george at twcable.com (George, Wes) Date: Wed, 10 Jun 2015 13:54:30 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: From: Lorenzo Colitti > Date: Wednesday, June 10, 2015 at 11:21 AM To: "George, Wes" > Cc: NANOG > Subject: Re: Android (lack of) support for DHCPv6 "I don't think it's a good plan to implement stateful DHCPv6 now and postpone the solution of the problem until IPv4 goes away many years from now. By then, a lot of water will have flowed under the bridge by then, and a lot of one-address-only networks will have been deployed and have moulded industry thinking. So, much as it pains me to stand in the way of IPv6 adoption - and you should how much I've tried to do on that front - I think that that wide deployment of one-address-per-device IPv6 might actually do more harm than good, and I expect that many operators who are going to require stateful DHCPv6 addressing are going to use it for one-address-per-device IPv6. I really think it's better if we get this right now, not kick the can down the road. That means we as an industry need to find a solution for IPv6 deployment in university/enterprise networks that does not devolve into one-address-per-device IPv6, *before* one-address-per-device IPv6 becomes universally implemented and usable." WG] I wasn't suggesting kicking the can. I agree that we need a solution, and getting started on it now so that the guidance and potential solutions are available as soon as possible is the right plan, because it reduces our potential reliance on IPv4 as a fallback for those things that need multiple addresses today. However, I think you're going to have a lot of trouble building consensus for your view that the right response is to try to completely block one-address-per-device IPv6 deployment by any means possible, and I think you're going to have even less success actually doing it, given that most other devices have already built support for it. Turning off IPv4 on a dual-stack network is a major change, as complex (or more) than deploying IPv6 to start with, especially if you haven't been focused on getting everything using IPv6 so that it's not dependent on IPv4, not to mention those unpredictable users. So I don't think it's unreasonable to expect that some changes to the existing IPv6 deployment will be necessary to support such a thing, and therefore I disagree with your assertion that allowing one-address-per-device in the short term will lead to unsolvable problems later, due to inertia or otherwise. It's also not guaranteed that everyone doing stateful DHCPv6 will limit devices to one address, so we need to be a bit careful with the prognostications of universal doom. Rhetorical question: given the growing evidence that IPv6 is often lower latency than IPv4, and Google's heavy focus on improving performance for user experience (page load times, SPDY, etc) especially in the mobile space, how long do you think you'll really be able to justify not supporting IPv6 on a subset of deployments to avoid the risk of future tragedy before you're overruled by the potential to shave off a few more ms of latency? Thanks, Wes Anything below this line has been added by my company?s mail server, I have no control over it. ---------- ________________________________ 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 rps at maine.edu Wed Jun 10 18:11:38 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 10 Jun 2015 14:11:38 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <79EC58CC-1AB1-4BDE-96E4-1D25ED893C70@steffann.nl> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <79EC58CC-1AB1-4BDE-96E4-1D25ED893C70@steffann.nl> Message-ID: I've already written systems to do this kind of thing, but the logging requirements quickly go through the roof for a non-trivial network; especially in the case of temporary addressing now default on many systems. That isn't so much the issue as operational consistency and supportability. The requirement for hosts to be dual stack will exist for some time. For the sanity of IT workers and users alike (most of which don't really know the details of IPv6 and barely understand address scopes let alone multiple addresses) there needs to be some level of consistency between how hosts are addressed and communicate between the two protocols. Saying we'll develop one system for IPv4 and one for IPv6 ultimate results in "Let's not deploy IPv6 just yet". This rings especially true when security concerns come up. Consistency between IPv4 and IPv6 needs to be possible in this transition period, or people simply decide to not deploy. Consistency in addressing and maintaining a one host one address model has major implications for policy construction, flow analysis and incident response, denial of service mitigation, etc. If the consistency isn't there, you need to "re-invent the wheel" for every aspect, then maintain different systems for IPv4 and IPv6 along side one another. Even worse, if we keep seeing adoption held up by inconsistent client implementations I fear we'll start seeing commercial products which NAT or proxy IPv4 to IPv6 to avoid using IPv6 internally. It's very ugly and requires some DNS magic to work, but it's not impossible. We're already seeing this in terms of cloud computing and virtualization. Servers have IPv4 addresses and only a load balancer with an external IPv6 address. We absolutely need to make it possible for people to adopt IPv6 before we can reach a point where IPv4 can go away, and for some organizations the answer of "Just use SLAAC" is simply not acceptable. They just won't do it. Preventing IPv6 adoption hurts us all. And Android not supporting a MAJOR part of IPv6 like DHCPv6 is preventing adoption. On Wed, Jun 10, 2015 at 1:42 PM, Sander Steffann wrote: > > > > It's not the *only* option. There are large networks - O(100k) IPv6 > nodes - that do ND monitoring for accountability, and it does work for > them. Many devices support this via syslog, even. As you can imagine, my > Android device gets IPv6 at work, even though it doesn't support DHCPv6. > Other universities, too. It's obviously not your chosen or preferred > mechanism, but it does work. > > /me starts to write that whitepaper that educates people on how to do this > > Cheers, > Sander > > -- 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 goemon at anime.net Wed Jun 10 18:18:06 2015 From: goemon at anime.net (goemon at anime.net) Date: Wed, 10 Jun 2015 11:18:06 -0700 (PDT) Subject: eBay is looking for network heavies... In-Reply-To: <12616019.0.1433908143109.JavaMail.root@benjamin.baylink.com> References: <12616019.0.1433908143109.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, 9 Jun 2015, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Shane Ronan" >> When I was asked the default BGP timers across three different vendor >> platforms as measure of my networking ability during an interview, I >> replied saying I'd look them up if needed them. >> >> I was told I didn't understand BGP in enough detail, despite being able to >> describe all the steps of BGP session establishment and route >> exchange. >> Certs have ruined the industry. > Maybe. But they certainly saved you from having to work for an asshole > with misplaced priorities... Indeed, the interview process is a two way street. Lets you evaluate who you would be working for -- or if you really would want to. -Dan From alh-ietf at tndh.net Wed Jun 10 18:36:05 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 10 Jun 2015 11:36:05 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: Message-ID: <119401d0a3ac$4f6fbe10$ee4f3a30$@tndh.net> Ray Soucy wrote: > I don't really feel I was trying to take things out of context, but the full quote > would be: > > "If there were consensus that delegating a prefix of sufficient size via > DHCPv6 PD of a sufficient size is an acceptable substitute for stateful > IPv6 addressing in the environments that currently insist on stateful > DHCPv6 addressing, then it would make sense to implement it. In that scenario, > Android would still not implement DHCPv6 NA, but it would implement DHCPv6 > PD." > > To me, that's essentially saying: > > "EVEN IF we decided to support DHCPv6-PD, and that's a big IF, we will never > support stateful address assignment via DHCPv6." > > This rings especially true when compared against the context of everything else > you've written on the subject. > > I think that's how most others on this list would read it as well. > > If that isn't what you meant to say, then I'm sorry. I'm certainly not trying to put > words in your mouth. > > I still feel that it's a very poor position to take. > > Given that you don't speak for Google on the subject, if you're not the decision > maker for this issue on Android, could you pull in the people at Google who are, > or at least point us to them? > > A lot of us would like the chance to make our case and expose the harm that > Android is doing by not supporting DHCPv6. > > I think the Android team is very overconfident in their ability to shape the > direction of IPv6 adoption, especially with years old Android releases being still > in production and it taking incredibly long for changes to trickle down through > the Android ecosystem. > > That delay is also why we have a hard time accepting the mindset that IF you > see a need for it in the future you'll add it. That will be 4 to 8 years too late. > > > So the flip side of that point is; how many decades does it take to trickle things through the operational networks? Having seen this first hand at the operator, infrastructure vendor and OS vendor perspectives, the general network operations community considers anything that makes Application Development harder to be "their problem". Persistent messages like "don't waste time on IPv6 development because we are only going to deploy IPv4 and I need shiny feature X NOW" caused at least one decade of delay in infrastructure products doing anything. Now we appear to be stuck in another decade of delay based on "it is not exactly the same as IPv4". Like it or not, the OS vendors actually cater to the Application Developers, as they are the ones that produce something useful to the end user. Their job is to be the intermediary between the needs of the apps, and the availability (or lack) of network resources. (FWIW: as much as people on this list don?t like them this is exactly why I made sure XP did automated IPv6 over IPv4 tunneling) Fault the OS vendors if you want to, but they are often trying to make the networks appear more capable and consistent than they really are. To a first order this is the primary "innovation" of the iPhone, in telling the carriers "no you don't get to fragment the OS or application functionality". At the end of the day though, N = 1 is the most likely result of an NA deployment today. Once that engrained in the next generation of network operators, they will do everything they can to resist change, because their security architecture and all their tools assume N = 1 (or are we already there?). Taking the opportunity of change to also change the mindset toward PD allows N > 1. Enforcing an NA model where N > 1 eventually fails as N blows out the ND cache. Tony > > > On Wed, Jun 10, 2015 at 12:29 PM, Lorenzo Colitti > wrote: > > > On Thu, Jun 11, 2015 at 12:36 AM, Jeff McAdams wrote: > > > >> Then you need to be far more careful about what you say. When you > >> said "Android would still not support..." you, very clearly, made a > >> statement of product direction for a Google product. > > > > > > Did you intentionally leave the "in that scenario," words that came > > right before the ones you quoted? > > > > How does a sentence that says "in that scenario, android would " > > constitute a statement of direction? > > > > > > -- > 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 mhuff at ox.com Wed Jun 10 18:51:30 2015 From: mhuff at ox.com (Matthew Huff) Date: Wed, 10 Jun 2015 18:51:30 +0000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <79EC58CC-1AB1-4BDE-96E4-1D25ED893C70@steffann.nl> Message-ID: <151D5F75-10C7-48D7-855F-6D8666E6DB72@ox.com> +1 One IP per device will almost most likely be the preference and implementation in corporate/enterprise deployments. Too much procedure, regulation and other roadblocks prevent any other solution. Authentication, Authorization, Accounting, ACLS, NMS, IDS, IP management, custom software, and other roadblocks will certainly stall if not stop IPv6 deployments in enterprises if there isn?t at least the choice of static, single IPv6 addresses per device. SLAAC will probably be a complete non-starter in many corporate environments. It is in ours. The more ideologues preach about restoring peer-to-peer connectivity, dynamic IPs, privacy addresses, etc? the less penetration IPv6 will happen in corporate networks. > On Jun 10, 2015, at 2:11 PM, Ray Soucy wrote: > > I've already written systems to do this kind of thing, but the logging > requirements quickly go through the roof for a non-trivial network; > especially in the case of temporary addressing now default on many > systems. That isn't so much the issue as operational consistency and > supportability. > > The requirement for hosts to be dual stack will exist for some time. > > For the sanity of IT workers and users alike (most of which don't really > know the details of IPv6 and barely understand address scopes let alone > multiple addresses) there needs to be some level of consistency between how > hosts are addressed and communicate between the two protocols. Saying > we'll develop one system for IPv4 and one for IPv6 ultimate results in > "Let's not deploy IPv6 just yet". > > This rings especially true when security concerns come up. Consistency > between IPv4 and IPv6 needs to be possible in this transition period, or > people simply decide to not deploy. Consistency in addressing and > maintaining a one host one address model has major implications for policy > construction, flow analysis and incident response, denial of service > mitigation, etc. If the consistency isn't there, you need to "re-invent > the wheel" for every aspect, then maintain different systems for IPv4 and > IPv6 along side one another. > > Even worse, if we keep seeing adoption held up by inconsistent client > implementations I fear we'll start seeing commercial products which NAT or > proxy IPv4 to IPv6 to avoid using IPv6 internally. It's very ugly and > requires some DNS magic to work, but it's not impossible. We're already > seeing this in terms of cloud computing and virtualization. Servers have > IPv4 addresses and only a load balancer with an external IPv6 address. > > We absolutely need to make it possible for people to adopt IPv6 before we > can reach a point where IPv4 can go away, and for some organizations the > answer of "Just use SLAAC" is simply not acceptable. > > They just won't do it. > > Preventing IPv6 adoption hurts us all. And Android not supporting a MAJOR > part of IPv6 like DHCPv6 is preventing adoption. > > > > > > On Wed, Jun 10, 2015 at 1:42 PM, Sander Steffann wrote: > >>> >>> It's not the *only* option. There are large networks - O(100k) IPv6 >> nodes - that do ND monitoring for accountability, and it does work for >> them. Many devices support this via syslog, even. As you can imagine, my >> Android device gets IPv6 at work, even though it doesn't support DHCPv6. >> Other universities, too. It's obviously not your chosen or preferred >> mechanism, but it does work. >> >> /me starts to write that whitepaper that educates people on how to do this >> >> Cheers, >> Sander >> >> > > > -- > 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 rdrake at direcpath.com Wed Jun 10 19:56:40 2015 From: rdrake at direcpath.com (Robert Drake) Date: Wed, 10 Jun 2015 15:56:40 -0400 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: <557702BA.2070004@jvknet.com> References: <557702BA.2070004@jvknet.com> Message-ID: <55789678.3010501@direcpath.com> On 6/9/2015 11:14 AM, Victor Kuarsingh wrote: > We are looking particularly at combinations of the following IGPs: > IS-IS, OSPFv2, OSPFv3, EIGRP. > If you run something else (RIP?) then we would also like to hear about > this, though we will likely document these differently. [We suspect > you run RIP/RIPng only at the edge for special situations, but feel > free to correct us]. When we first were moving to IPv6 in the core network we evaluated IS-IS because it was what we were using for IPv4 and we would have preferred to run a single protocol for both. We had problems with running a mix of routers where some supported IPv6 and others did not. From what I recall, if any router did not support IPv6 then it wouldn't connect to a router running v6 and v4. It's possible these were bugs and they were worked out later or just a messed up design in the lab, but we also like the idea of keeping IPv4 and IPv6 away from each other so if one is broken the other one might still work. So we use OSPFv3 for IPv6 routing and IS-IS for IPv4 routing. From tore at fud.no Wed Jun 10 20:14:25 2015 From: tore at fud.no (Tore Anderson) Date: Wed, 10 Jun 2015 22:14:25 +0200 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> <1433935840.11511.123.camel@karl> <20150610143103.4700248d@envy.fud.no> <20150610173518.4ccfcdd3@envy.fud.no> Message-ID: <20150610221425.3aea4202@envy.fud.no> * Lorenzo Colitti > > On the other hand, there exist applications *today* that do require > > DHCPv6. One such example would be MAP, which IMHO is superior to > > 464XLAT both for the network operator (statlessness ftw) as well as > > for the end user (unsolicited inbound packets work, no NAT traversal > > required). MAP is provisioned with DHCPv6 > > (I-D.ietf-softwire-map-dhcp), so without DHCPv6 support in Android, > > MAP support in Android is a non-starter. > > > > Support for the DHCPv6 protocol, or support for assigning addresses > from IA_NA? I'm not 100% certain, but you can possibly run MAP without IA_NA. But I think you'll need the CE to be configured with a predictable IPv6 address so that the BR knows where to send the IPv6-encapsulated or -translated IPv4 packets. I don't see how that would work with SLAAC. But I'm not a MAP expert, so I'm open to be educated otherwise. Anyway, here's a (hopefully constructive) suggestion on a way forward: * Implement DHCPv6 client support (IA_NA, IA_TA, IA_PD .. the works) * Upon network connection, request 2x IA_NA and 1x IA_PD (in addition to SLAAC): ** If you get addressing from SLAAC and/or IA_PD, accept the configuration and connect to the network. *** If apps/services require additional addresses, self-assign them from the on-link/delegated prefix as needed. ** If you get 2x IA_NA, accept the configuration and connect to the network. *** If apps/services requires additional addresses, request additional IA_NA as needed. **** If additional IA_NAs are declined either warn user or trigger Android's already existing ?avoided bad network? functionality. ** If you get no SLAAC or IA_PD, and IA_NA <= 1, then refuse to connect to the network (or, for a dual-stack network, connect IPv4-only). (I.e., same behaviour as on a DHCPv6-only network today.) Why N=2? Because it's >1, and what you seem to be worried about is operators using N=1 without thought ("because that's what we did in IPv4"). N=2 will confirm that's not the case for the given network, so I think confirming N=2 gives a much stronger indication that the network allows N= than confirming N=1. That said, I doubt that you can rely on the network accepting N=, neither for DHCPv6 IA_NA *nor* SLAAC, due to neighbour table limitations and DAD overhead (both delay and packets). If the future applications we're imagining needs IPv6 addresses in that ballpark (which isn't *that* far-fetched - say a new address per connection, process, app, whatever), IA_PD is the only mechanism we have today that will work. If you start supporting IA_PD, my bet networks are going to start offering it - just like when you added 464XLAT. Tore From tore at fud.no Wed Jun 10 20:15:45 2015 From: tore at fud.no (Tore Anderson) Date: Wed, 10 Jun 2015 22:15:45 +0200 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> <1433935840.11511.123.camel@karl> <20150610143103.4700248d@envy.fud.no> <20150610173518.4ccfcdd3@envy.fud.no> Message-ID: <20150610221545.48e5d68b@envy.fud.no> * Dave Taht > I am told that well over 50% of all android development comes from > volunteer developers so rather than kvetching about this it seems > plausible for an outside effort to get the needed features for > tethering and using dhcpv6-pd into it. If someone wanted to do the > work. https://android-review.googlesource.com/#/c/78857/ Tore From tylermills at gmail.com Wed Jun 10 20:22:45 2015 From: tylermills at gmail.com (Tyler Mills) Date: Wed, 10 Jun 2015 20:22:45 +0000 Subject: Lists of VPN exit addresses? In-Reply-To: References: <20150610115646.3900.qmail@ary.lan> <4A200C79-18FA-4498-9014-07F429F1A666@puck.nether.net> Message-ID: I'd imagine it is quite easy for a lot of these providers to have a pre-configured virtual machine template or cd image that they can deploy across the board amongst a plethora of different VPS solutions as well. Being able to bring up exit points on the fly would be very helpful in bypassing censorship. On Wed, Jun 10, 2015 at 12:39 PM Bacon Zombie wrote: > Well if they are using Hola then EVERY person with it installed is an > exit-node. > > http://adios-hola.org > > > https://m.reddit.com/r/netsec/comments/37rit3/adios_hola_why_you_should_immediately_uninstall/ > On 10 Jun 2015 14:28, "Jared Mauch" wrote: > > > > > > On Jun 10, 2015, at 8:08 AM, Roland Dobbins > wrote: > > > > > > > > > On 10 Jun 2015, at 18:56, John Levine wrote: > > > > > >> I presume there is no need to explain why this would be of interest. > > > > > > To keep consumers who've legitimately purchased/rented/subscribed to > > content from accessing same when they travel internationally? > > > > > > Because as a regular international traveler, that's what springs to > mind > > when I see requests like this. > > > > > > Another thought is governmentally-driven censorship, something else I > > encounter a lot in my travels. > > > > I?ll just simplify this and say that the Tor Project publishes a list of > > its exit nodes so you can block these if your abuse/fraud requirements > > necessitate this. > > > > https://check.torproject.org/cgi-bin/TorBulkExitList.py > > > > If it?s for geolocation blocking, I?m in favor of these political > > limitations to go away. It doesn?t take a genius to bypass these if > that?s > > your intent. > > > > - Jared > From fw at deneb.enyo.de Wed Jun 10 20:42:36 2015 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 10 Jun 2015 22:42:36 +0200 Subject: Android (lack of) support for DHCPv6 In-Reply-To: (Lorenzo Colitti's message of "Wed, 10 Jun 2015 11:48:38 +0900") References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: <87mw07pa6b.fsf@mid.deneb.enyo.de> * Lorenzo Colitti: > I think what I said is that supporting DHCPv6-only networks will eventually > force OS manufacturers to implement IPv6 NAT. This is because there are > many features inside a mobile OS that require multiple IP addresses. On many networks, there will be fairly tight limits on the number of usable addresses per ?port? even with SLAAC, similar to the evolution of Ethernet switching, which led to configurable limits of MAC addresses per port. So you'll likely need IPv6 NAT in the future anyway. From josh at spitwspots.com Wed Jun 10 20:46:49 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Wed, 10 Jun 2015 12:46:49 -0800 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <87mw07pa6b.fsf@mid.deneb.enyo.de> References: <20150609031454.GD3716@bender.unx.cpp.edu> <87mw07pa6b.fsf@mid.deneb.enyo.de> Message-ID: <5578A239.6050101@spitwspots.com> Memory is cheap, ASICs and FPGAs are getting better all the time. It might be a problem a few years from now for older hardware, but I can't see it causing real issues long term. Josh Reynolds CIO, SPITwSPOTS www.spitwspots.com On 06/10/2015 12:42 PM, Florian Weimer wrote: > * Lorenzo Colitti: > >> I think what I said is that supporting DHCPv6-only networks will eventually >> force OS manufacturers to implement IPv6 NAT. This is because there are >> many features inside a mobile OS that require multiple IP addresses. > On many networks, there will be fairly tight limits on the number of > usable addresses per ?port? even with SLAAC, similar to the evolution > of Ethernet switching, which led to configurable limits of MAC > addresses per port. So you'll likely need IPv6 NAT in the future > anyway. From nwarren at barryelectric.com Wed Jun 10 20:22:28 2015 From: nwarren at barryelectric.com (Nicholas Warren) Date: Wed, 10 Jun 2015 20:22:28 +0000 Subject: Greenfield 464XLAT (In January) Message-ID: Sincere apologies if this e-mail is inappropriate for this audience, We are (going to be) a startup ISP building a new network from the ground up. I was hoping I could get an opinion, or two, on how everyone feels about 464XLAT. I saw what everyone was saying about it in the 'Android doesn't support DHCPv6' discussion, but what about in the wireline side of things? The main reason we are even considering 464XLAT as opposed to dual-stack (the latter is, in my ignorant opinion, the better option.) is the fear of IPv4 depletion that we think might hit ARIN between now and the start of next year; causing us to pay a premium for IPv4 in the gray market. So I guess the real question here would be: is our fear real, or is it just bug on the wall? If our fear is real, what should we implement so that our users can still get to the v4 internet, are we even thinking soberly by suggesting 464XLAT? Thanks, - Nich From ted.ietf at gmail.com Wed Jun 10 21:00:26 2015 From: ted.ietf at gmail.com (Ted Hardie) Date: Wed, 10 Jun 2015 14:00:26 -0700 Subject: Android (lack of) support for DHCPv6 Message-ID: On Wed, Jun 10, 2015 at 11:51 AM, Matthew Huff wrote: > +1 > > One IP per device will almost most likely be the preference and > implementation in corporate/enterprise deployments. Too much procedure, > regulation and other roadblocks prevent any other solution. > > Authentication, Authorization, Accounting, ACLS, NMS, IDS, IP management, > custom software, and other roadblocks will certainly stall if not stop IPv6 > deployments in enterprises if there isn?t at least the choice of static, > single IPv6 addresses per device. SLAAC will probably be a complete > non-starter in many corporate environments. It is in ours. The more > ideologues preach about restoring peer-to-peer connectivity, dynamic IPs, > privacy addresses, etc? the less penetration IPv6 will happen in corporate > networks. > > > So, the critical piece of what you assert above appears to be "static", not "single". If a local address management system is always configured to hand out the same /N to the same device, there doesn't seem to be a requirement in the above that N=1. Lorenzo has detailed why N=1 doesn't work for devices that need to use xlat or which might want to tether other devices; he's volunteered to work with folks on a document and to write code for the case where a device successfully gets a useful value of N>1. Can you help me understand why that doesn't work for you? On the related topic of privacy addresses, I believe we should all be ready for increasing variability in MAC address emitted by devices, and that if you are intending to use MAC auth to assign that /N, you may now be or will soon be surprised. In addition to the work Apple has done and which can be done with Android, see the IEEE work here: http://www.ieee802.org/PrivRecsg/ regards, Ted From jfbeam at gmail.com Wed Jun 10 21:08:12 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 10 Jun 2015 17:08:12 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <20150610031454.GH999@cmadams.net> Message-ID: On Wed, 10 Jun 2015 00:58:06 -0400, Lorenzo Colitti wrote: > On Wed, Jun 10, 2015 at 12:26 PM, Jon Bane wrote: >> DHCPv6 - RFC3315 - Category: Standards Track >> 464XLAT - RFC6877 - Category: Informational > > Ooo, that's fun, can I play too? We aren't asking you to support BGP, or SNMP. We're DEMANDING you support a FUNDAMENTAL COMPONENT of IPv6. DHCPv6 is not *optional*. And every reason you've given to date sounds like a whiny I-Don't-Like-It political agenda. The fact that others have made it work is proof of your asshattery. This has been going around for **YEARS**. You've spent orders of magnitude more time defending your "no" position than it would take to actually include DHCPv6 support. In *two days* of bitching on NANOG, every one of your positions has been shot down, and solutions to every corner case has been presented -- sure, the network policy could still render things non-workable (no PD, only one address, etc.) Will IPv4 only apps work with only one v6 address, no. (or "not easily") But then, IPv4 isn't IPv6; any kludge to get one to work within the other is 100% BS hackery (because no one thought about migration or interoperability. dual-stack was declared the answer, and the WG patted themselves on the back.) Given the choice of ZERO network access, or ("legacy" ???) IPv4 only apps not working, I'll take the later. The people in charge of those lacking apps need to fix their shit. From dougb at dougbarton.us Wed Jun 10 21:16:35 2015 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 10 Jun 2015 14:16:35 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: Message-ID: <5578A933.8090504@dougbarton.us> On 6/10/15 2:00 PM, Ted Hardie wrote: > Lorenzo has detailed why N=1 doesn't work for devices that need to use xlat ... and it's been well demonstrated that this is a red herring argument since the provider has to configure xlat for it to have any chance of working. > or which might want to tether other devices; ... and this argument has been refuted by the word "bridging." I'm not a fan of N=1 for IPv6, but none of Lorenzo's arguments hold water. -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From henson at acm.org Wed Jun 10 21:19:55 2015 From: henson at acm.org (Paul B. Henson) Date: Wed, 10 Jun 2015 14:19:55 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> Message-ID: <2b0001d0a3c3$32a21e60$97e65b20$@acm.org> > From: Lorenzo Colitti > Sent: Tuesday, June 09, 2015 7:49 PM > > That sounds pretty stupid even for me, so probably something got lost in > translation. "Implementing stateful DHCPv6 would break planned use cases such as IPv6 tethering" "And it's not possible to enable tethering" "tethering cannot be made to work well" "what do you expect Android to do if given only one IPv6 address and the user turns on tethering" 'Saying "tethering is not available" is not going to fly' Yes, while you have mentioned a few other things, based on your postings on the issue thread tethering seems to be one of your hot topics. > I think what I said is that supporting DHCPv6-only networks will eventually force > OS manufacturers to implement IPv6 NAT. As opposed to not supporting DHCPv6 operation forcing users to adopt phones based on operating systems other than android? > You don't "have to do" SLAAC and RDNSS. For as long as the network provides > IPv4, there won't be a problem for anyone. Thank you very much for being the guy in charge of determining what my problems are. As I already mentioned in the issue thread, one of our motivations for moving forward with IPv6 deployment is that some grants our faculty want to apply for require native IPv6 communication. So an android device that is incapable of connecting to our IPv6 network due to deficiencies in its implementation of IPv6 standards will not be usable for that grant work. But I will be sure to tell the faculty that the android developer responsible for that breakage assures them it is not a problem. After which I will encourage them to switch to another platform which provides for its users' needs rather than its developers' crusades. From dougb at dougbarton.us Wed Jun 10 21:19:56 2015 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 10 Jun 2015 14:19:56 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: <5578A9FC.2060102@dougbarton.us> On 6/10/15 8:15 AM, Ray Soucy wrote: > The statement that "Android would still not implement DHCPv6 NA, but it > would implement DHCPv6 PD." is troubling because you're not even willing to > entertain the idea for reasons that are rooted in idealism rather > than pragmatism. I was going to respond on this issue in more depth, but others have already gotten there ahead of me. I think Ray's paragraph above sums it up best. Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From dougb at dougbarton.us Wed Jun 10 21:23:37 2015 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 10 Jun 2015 14:23:37 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> Message-ID: <5578AAD9.4030105@dougbarton.us> On 6/9/15 1:27 PM, Joel Maslak wrote: > Agreed - apparently the solution is to implement SLAAC + DNS advertisements > *AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and > you need DHCPv6 for Windows. > > Am I the only one that thinks this situation is stupid? No, you're not. Some of us have been saying that requiring RA is a bad idea, and that adding features to it is a bad idea, for over 15 years now. Unfortunately the anti-DHCP crowd hasn't budged, no matter how many operators have told them that they cannot manage an IPv6 network with the current state of the protocol. Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From henson at acm.org Wed Jun 10 21:23:47 2015 From: henson at acm.org (Paul B. Henson) Date: Wed, 10 Jun 2015 14:23:47 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> Message-ID: <2b0801d0a3c3$bd0f2160$372d6420$@acm.org> > From: Lorenzo Colitti > Sent: Tuesday, June 09, 2015 11:33 PM > > value of N. I'd be happy to work with people on an Internet draft or other [...] > It's also possible for Android to support DHCPv6 PD. Again I'd be happy to > work with people on a document that says that mobile devices should do It would be nice if you were happy to work with people on actually implementing what they are asking for and what their users need as opposed to just methods to try and twist the world to your personal viewpoint. Or maybe even just merging work somebody already did well over a year ago? https://android-review.googlesource.com/#/c/78857/ > Asking for more addresses when the user tries to enable features such as > tethering, waiting for the network to reply, and disabling the features if > the network does not provide the necessary addresses does not seem like it > would provide a good user experience. Absolutely; having a device incapable of connecting at all is a *much* better user experience. Have you ever met a user 8-/? From ted.ietf at gmail.com Wed Jun 10 21:27:12 2015 From: ted.ietf at gmail.com (Ted Hardie) Date: Wed, 10 Jun 2015 14:27:12 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <5578A933.8090504@dougbarton.us> References: <5578A933.8090504@dougbarton.us> Message-ID: On Wed, Jun 10, 2015 at 2:16 PM, Doug Barton wrote: > On 6/10/15 2:00 PM, Ted Hardie wrote: > >> Lorenzo has detailed why N=1 doesn't work for devices that need to use >> xlat >> > > ... and it's been well demonstrated that this is a red herring argument > since the provider has to configure xlat for it to have any chance of > working. > > or which might want to tether other devices; >> > > ... and this argument has been refuted by the word "bridging." > > ?To repeat Valdis' question:? ?And the router knows to send to the "front" address to reach the "back" > address, how, exactly? Seems like somebody should invent a way to assign a > prefix to the front address that it can delegate to things behind it. :)? > ?The other option would, of course, be "bridging" plus IPv6 "NAT", and I assume you see the issues there.? ?Back to the question I asked before: does "static" solve the stated problems without "single"? regards, Ted? From henson at acm.org Wed Jun 10 21:28:43 2015 From: henson at acm.org (Paul B. Henson) Date: Wed, 10 Jun 2015 14:28:43 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <20150610053603.GD2530@bamboo.slabnet.com> Message-ID: <2b0a01d0a3c4$6d4e4d30$47eae790$@acm.org> > From: Mikael Abrahamsson > Sent: Wednesday, June 10, 2015 12:05 AM > > You seem to fail to realise that you are not Lorenzos customer, his > customer is the OEMs that build mobile phones, and their customers who buy > Android phones. And he fails to realize that the people who buy android phones actually want them to work. And the companies manufacturing android phones want their users to be satisfied. And when every single mobile phone other than an android phone does seem to work, who do you think they're going to blame? I can already tell you our helpdesk response "Unfortunately, the android operating system does not fully implement IPv6 standards and as such is not capable of interoperating with our network. Consider switching to an iPhone, or a Windows Phone, or a [every other phone that works]." > So while you are doing what you think is best for your network, Lorenzo is > doing what he thinks is best for his platform and the hundreds of millions > of Android users that are out there. I am sure all of those millions of users sleep better at night knowing that omniscient and caring Lorenzo is looking out for their long-term interests while denying them short-term usability. > So I happen to agree with Lorenzo that a single IA_NA per device world is > a crippled world. Lorenzo said he was willing to work on a document that > creates a recommendation for certain minimum amount of IPv6 addresses per > device and/or PD, so let's get that happening then? How about we support existing already widely deployed Internet standards so they can be used while future standards are being developed? From henson at acm.org Wed Jun 10 21:31:09 2015 From: henson at acm.org (Paul B. Henson) Date: Wed, 10 Jun 2015 14:31:09 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: <2b0b01d0a3c4$c4529b90$4cf7d2b0$@acm.org> > From: Ray Soucy > Sent: Wednesday, June 10, 2015 4:36 AM > > In practice, your device will just not be supported. [..] > If your client is broken because of an incomplete implementation, I just > won't give it an IPv6 address at all. I think a lot of others feel the > same way. [...] > already provide ubiquitous wireless coverage. I don't want users enabling > a hotspot (rogue AP) on campus because it has a negative impact on service > for others, so the whole argument is really meaningless in the context of > higher education and campus networking. Yes. That. All of that. I think you'll find a lot of higher education institutions will agree with this viewpoint. From henson at acm.org Wed Jun 10 21:34:46 2015 From: henson at acm.org (Paul B. Henson) Date: Wed, 10 Jun 2015 14:34:46 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <1433920393.11511.52.camel@karl> <1433935840.11511.123.camel@karl> Message-ID: <2b0c01d0a3c5$460100a0$d20301e0$@acm.org> > From: Lorenzo Colitti > Sent: Wednesday, June 10, 2015 5:07 AM > > getting rid of NAT. Today in IPv4, tethering just works, period. [...] > IPv4-only apps always work. Wow. If your phone just "always works", you certainly lead a charmed life. > A model where the device has to request resources from the network before > enabling tethering, or before supporting IPv4-only apps, provides a much > worse user experience. The user might have to wait a long time, or the > operation might even fail. Far better that the user stare at the useless android brick in their hand that is incapable of connecting to the network at all. Maybe you should try taking a poll of actual users? Dear user, would you rather: A) have a phone that connects to the network and the most part works barring some side cases B) have a phone that is incapable of connecting, but saves you from being unable to use certain functionality that otherwise would have been unavailable. By preventing you from using any functionality at all. From dougb at dougbarton.us Wed Jun 10 21:36:46 2015 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 10 Jun 2015 14:36:46 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <5578A933.8090504@dougbarton.us> Message-ID: <5578ADEE.2080807@dougbarton.us> On 6/10/15 2:27 PM, Ted Hardie wrote: > > > On Wed, Jun 10, 2015 at 2:16 PM, Doug Barton > wrote: > > On 6/10/15 2:00 PM, Ted Hardie wrote: > > Lorenzo has detailed why N=1 doesn't work for devices that need > to use xlat > > > ... and it's been well demonstrated that this is a red herring > argument since the provider has to configure xlat for it to have any > chance of working. > > or which might want to tether other devices; > > > ... and this argument has been refuted by the word "bridging." > > > ?To repeat Valdis' question:? > > ?And the router knows to send to the "front" address to reach the > "back" address, how, exactly? Seems like somebody should invent a > way to assign a prefix to the front address that it can delegate to > things behind it. :)? I saw that, he was refuted by others, most notably by the simple fact that bridging works now in IPv4, so obviously there is a way to make it work. I think PD is the right answer here of course, but that doesn't mean that bridging is the wrong answer. > ?The other option would, of course, be "bridging" plus IPv6 "NAT", and I > assume you see the issues there.? No, actually I don't. I realize that you and Lorenzo are part of the rabid NAT-hating crowd, but I'm not. I don't think it's the right answer here, but I don't think it's automatically a problem either. > ?Back to the question I asked before: does "static" solve the stated > problems without "single"? It *could*, but Lorenzo actually does have a point when he talks about not wanting to cripple future application development. I'd also like to see a rough outline of an implementation before commenting further. Meanwhile, DHCPv6 + PD solves all of Lorenzo's stated problems, but he won't implement it because "DHCP." That's not something you can engineer around. Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From marka at isc.org Wed Jun 10 21:38:15 2015 From: marka at isc.org (Mark Andrews) Date: Thu, 11 Jun 2015 07:38:15 +1000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: Your message of "Wed, 10 Jun 2015 09:54:03 -0400." References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> Message-ID: <20150610213816.DC3793059DA0@rock.dv.isc.org> In message , Ray Soucy writes: > The whole conversation is around 464XLAT on IPv6-only networks right? > We're going to be dual-stack for a while IMHO, and by the time we can get > away with IPv6 only for WiFi, 464 should no longer be relevant because > we'll have widespread IPv6 adoption by then. Or just support DS-Lite along with DHCPv6. DS-Lite does not require its own IPv6 address. 464XLAT and DS-Lite both limit IPv4 packet sizes to less than native. DS-Lite works with DNSSEC. DNS64 doesn't. DS-Lite doesn't require mucking with packet contents. DS-Lite doesn't result in sites being unreachable just because the IPv6 instance is down which is a side effect of DNS64. > Carriers can do IPv6 only because they tightly control the clients, for > WiFi clients are and will always be all over the place, so dual stack will > be pretty much a given for a long time. > > > On Wed, Jun 10, 2015 at 9:50 AM, George, Wes > wrote: > > > > > On 6/10/15, 2:32 AM, "Lorenzo Colitti" wrote: > > > > >I'd be happy to work with people on an Internet draft or other > > >standard to define a minimum value for N, but I fear that it may not > > >possible to gain consensus on that. > > > > WG] No, I think that the document you need to write is the one that > > explains why a mobile device needs multiple addresses, and make some > > suggestions about the best way to support that. Your earlier response > > detailing those vs how they do it in IPv4 today was the first a lot of us > > have heard of that, because we're not in mobile device development and > > don't necessarily understand the secret sauce involved. This is especiall= > y > > true for your mention of things like WiFi calling, and all of the other > > things that aren't tethering or 464xlat, since neither of those are as > > universally agreed-upon as "must have" on things like enterprise networks= > . > > I'm sure there are also use cases we haven't thought of yet, so I'm not > > trying to turn this into a debate about which use cases are valid, just > > observing that you might get more traction with the others. > > > > > > >Asking for more addresses when the user tries to enable features such as > > >tethering, waiting for the network to reply, and disabling the features = > if > > >the network does not provide the necessary addresses does not seem like = > it > > >would provide a good user experience. > > > > WG] Nor does not having IPv6 at all, and being stuck behind multiple > > layers of NAT, but for some reason you seem ok with that, which confuses > > me greatly. The amount of collective time wasted arguing this is likely > > more than enough to come up with cool ways to optimize the ask/wait/enabl= > e > > function so that it doesn't translate to a bad user experience, and few > > things on a mobile device are instantaneous anyway, so let's stop acting > > like it's an unsolvable problem. > > > > Thanks, > > > > Wes > > > > > > Anything below this line has been added by my company=E2=80=99s mail serv= > er, I > > have no control over it. > > ---------- > > > > > > 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 th= > at > > 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 o= > f > > this E-mail and any printout. > > > > > > --=20 > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From henson at acm.org Wed Jun 10 21:43:00 2015 From: henson at acm.org (Paul B. Henson) Date: Wed, 10 Jun 2015 14:43:00 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: <2b0e01d0a3c6$6c69ceb0$453d6c10$@acm.org> > From: Lorenzo Colitti > Sent: Wednesday, June 10, 2015 5:22 AM > > It's certainly a possibility for both sides in this debate to say "my way > or the highway", and wait and see what happens when operators start > removing support for IPv4. You are rather confused. Only one side of this debate is saying "my way or the highway" ? yours. On my side, I am saying that it is my network, and it is not only my right but my responsibility to define policies as to how it should be used. That could be by blocking port 25 outbound to prevent spam abuse, or by forbidding unauthenticated wireless access points, or by requiring WPA2-enterprise authentication to connect, or any other technical configuration determined to be needed or desired by our policy. Can anyone reasonably say that a provider of a network is not allowed to determine the policies by which that network must be used 8-/? On the other hand, *you* are providing infrastructure. You are refusing to implement agreed-upon Internet standards that are already widely supported. You are trying to determine what policy we should use on our network. It is completely different. I'm sorry you cannot see that. > But even if you're dead set on using DHCPv6, what I don't see is why don't > you support DHCPv6 PD instead of IA_NA? Perhaps we will support it in addition to. Or perhaps we will not support it at all as that use pattern might not be desirable on our network. However, I am quite certain all of the equipment we purchase and recommend to purchase will support both standards, as well as SLACC and all other standards that have been defined as a base part of IPv6 support. As providers of infrastructure should. And then we will choose which of them to deploy. As managers of networks should. > more than one IPv6 address and cannot be done without that. We know these > will break today; tomorrow, we can use multiple addresses to do things we > haven't thought of yet. Who knows, maybe IPv12 will solve all of these issues? Maybe we shouldn't bother trying to deploy IPv6 while we're waiting for somebody to design and implement IPv12. From ted.ietf at gmail.com Wed Jun 10 21:46:11 2015 From: ted.ietf at gmail.com (Ted Hardie) Date: Wed, 10 Jun 2015 14:46:11 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <5578ADEE.2080807@dougbarton.us> References: <5578A933.8090504@dougbarton.us> <5578ADEE.2080807@dougbarton.us> Message-ID: On Wed, Jun 10, 2015 at 2:36 PM, Doug Barton wrote: > > >> > > ?The other option would, of course, be "bridging" plus IPv6 "NAT", and I >> assume you see the issues there.? >> > > No, actually I don't. I realize that you and Lorenzo are part of the rabid > NAT-hating crowd, but I'm not. I don't think it's the right answer here, > but I don't think it's automatically a problem either. > ?So, I don't think I'm particularly rabid about this, but I have dealt for a long time on the application side with the side effects. Anyone who has had to engineer a system that requires STUN/TURN/ICE can tell you that it is pretty much a dancing bear. The wonder is how sweetly the bear dances, but that it dances at all. If one of the things I'm tethering wants to do RTCWEB, it's going to be painful if it doesn't have its own address, because it will need to hairpin out to do STUN at the very least.? > ?Back to the question I asked before: does "static" solve the stated >> problems without "single"? >> > > It *could*, but Lorenzo actually does have a point when he talks about not > wanting to cripple future application development. I'd also like to see a > rough outline of an implementation before commenting further. > ?That's fair enough, and some variability in what N is depending on device is as a well. But understanding whether what we're actually looking for is "static" or "single" is a pretty key piece of the requirements scoping, and it sounds like "static" is it, at least from your perspective. Is that a fair assessment? regards, Ted? > > -- > I am conducting an experiment in the efficacy of PGP/MIME signatures. This > message should be signed. If it is not, or the signature does not validate, > please let me know how you received this message (direct, or to a list) and > the mail software you use. Thanks! > > From cb.list6 at gmail.com Wed Jun 10 21:47:23 2015 From: cb.list6 at gmail.com (Ca By) Date: Wed, 10 Jun 2015 14:47:23 -0700 Subject: Greenfield 464XLAT (In January) In-Reply-To: References: Message-ID: On Wed, Jun 10, 2015 at 1:22 PM, Nicholas Warren wrote: > Sincere apologies if this e-mail is inappropriate for this audience, > We are (going to be) a startup ISP building a new network from the ground > up. I was hoping I could get an opinion, or two, on how everyone feels > about 464XLAT. I saw what everyone was saying about it in the 'Android > doesn't support DHCPv6' discussion, but what about in the wireline side of > things? The main reason we are even considering 464XLAT as opposed to > dual-stack (the latter is, in my ignorant opinion, the better option.) is > the fear of IPv4 depletion that we think might hit ARIN between now and the > start of next year; causing us to pay a premium for IPv4 in the gray > market. So I guess the real question here would be: is our fear real, or is > it just bug on the wall? If our fear is real, what should we implement so > that our users can still get to the v4 internet, are we even thinking > soberly by suggesting 464XLAT? > Thanks, > - Nich > > Yes, your fears about IPv4 are correct. If you have a look at ARIN PPML lately, you can see some pretty intense "discussion" about companies exporting ARIN addresses to CCNIC and so on. As a greenfield, you should definitely be focused on IPv6-only to the edge solutions. DS-lite, MAP-E, and 464XLAT come to mind. DS-lite is the oldest and most common in wireline. 464XLAT is more common in mobile. MAP-E and MAP-T have not yet been deployed at the same scale as DS-lite and 464XLAT yet AFAIK, not sure if they will be. You could also simply do dual-stack with private space and CGN to the end user using RFC1918 (10.0.0.0/8, 100.64.0.0/10) Regards, CB From henson at acm.org Wed Jun 10 21:47:41 2015 From: henson at acm.org (Paul B. Henson) Date: Wed, 10 Jun 2015 14:47:41 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: <2b1001d0a3c7$14016700$3c043500$@acm.org> > From: Ray Soucy > Sent: Wednesday, June 10, 2015 6:06 AM > > As for thinking "long term" and "the future", we need devices to work > within current models of IPv6 to accelerate _adoption_ of IPv6 _today_ > before we can get to that future you're talking about. > > Not supporting DHCPv6 ultimately holds back adoption, which makes people > see IPv6 as optional for longer, and discourages deployment because vendor > support is all over the place and seen as "not ready". > > This isn't theory, we've been _living_ with this as a reality for years > now. The networks are ready; the clients are not. > > Universities see a constant stream of DMCA violation notices that need to > be dealt with and not being able to associate a specific IPv6 address to a > specific user is a big enough liability that the only option is to not use > IPv6. As I said, Android becomes a second class citizen on the network > under your model. Your ideas are intriguing to me and I wish to subscribe to your newsletter ;). When someone shows up with a device that only supports WEP, or doesn't support WPA2-Enterprise, we tell them they need to replace it with a device supporting current standards that provide the minimum level of security we have decided upon for our network policy. When someone shows up with an android device that can't connect to our IPv6 network, we will tell them to replace it with a device that fully supports current standards. I still find it hard to believe that Google as a corporate entity thinks it is more important to try and force network operators to conform to their ideals for configuration than it is to make android feature equivalent with its competitors. From jcurran at arin.net Wed Jun 10 21:51:05 2015 From: jcurran at arin.net (John Curran) Date: Wed, 10 Jun 2015 21:51:05 +0000 Subject: Also seeking transit in Equinix SV2/Santa Clara (was: Re: RFP for Internet Transit for ARIN ASN 394018) In-Reply-To: References: <55770D4B.4000406@arin.net> Message-ID: Folks - I forgot to mention the second west coast Internet transit RFP for delivery at Equinix SV2 - Thanks! /John On Jun 9, 2015, at 9:23 AM, John Curran > wrote: Hello NANOG Folks - Apologies for the distraction, but ARIN needs some transit providers and I thought there may be one or two on this list... We need 1 GB via standard multi-mode fiber in Wowrack/Seattle - ISP must provide native IPv4 and IPv6 connectivity, provide full view of the IPv4 and IPv6 routing table, support 32-bit ASNs, etc. If interested, please review the full RFP for details and response information. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] RFP for Internet Transit for ARIN ASN 394018 Date: June 9, 2015 at 8:59:07 AM PDT To: > ARIN is soliciting proposals from Internet Service Providers (ISPs) to bid on the delivery of Internet transit to ARIN's network, ASN 394018. This network is part of ARIN's provisioning network and is a part of critical Internet infrastructure. ARIN is looking for qualified providers that are able to provide service to its rack within Wowrack's datacenter located in Tukwila, Seattle. All contractual terms and conditions related to the work performed, nondisclosure of information, or liability issues must be detailed. ARIN will require that the vendor performing this service sign a nondisclosure agreement due to the proprietary nature of the information ARIN retains for its subscribers. All proposals must be submitted no later than 5:00 p.m. EDT on 22 June 2015. ARIN will evaluate the properly submitted proposals and will select a winning bidder or bidders no later than 30 June 2015. Full text of the RFP is available at: http://www.arin.net/about_us/contracts/201506-westcoast-transit-rfp-sea.pdf Send proposals to rfp-transit-sea at arin.net or by mail to: Matt Rowley Infrastructure Manager ARIN 3635 Concorde Parkway, Suite 200 Chantilly, VA. 20151 ATTN: Proposal for Internet Transit Services Technical questions may be directed to: rfp-transit-sea at arin.net ARIN is operated as a nonprofit 501(c)(6) corporation which is chartered for educational, charitable, and scientific purposes. It is a membership organization with an official IRS designation as a business league. ___________ From henson at acm.org Wed Jun 10 21:51:34 2015 From: henson at acm.org (Paul B. Henson) Date: Wed, 10 Jun 2015 14:51:34 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> > From: Lorenzo Colitti > Sent: Wednesday, June 10, 2015 8:27 AM > > please do not construe my words on this thread as being Google's position > on anything. These messages were sent from my personal email address, and I > do not speak for my employer. Can we construe your postings on the issue thread as being Google and/or Androids official position? They are posted by lorenzo at google.com with a tag of "Project Member", and I believe you also declined the request in the issue under that mantle. If your postings on the issue thread are not authoritative for Google, could you possibly put us in contact with who as Google could make an official statement as to why they are refusing to implement an accepted Internet standard already deployed by their competitors, the lack of which will directly harm their users? From egon at egon.cc Wed Jun 10 21:52:07 2015 From: egon at egon.cc (James Downs) Date: Wed, 10 Jun 2015 14:52:07 -0700 Subject: Lists of VPN exit addresses? In-Reply-To: References: <20150610115646.3900.qmail@ary.lan> Message-ID: <1657A2C7-A23B-4075-B7C9-C43C48F580A9@egon.cc> > On Jun 10, 2015, at 05:08, Roland Dobbins wrote: > Another thought is governmentally-driven censorship, something else I encounter a lot in my travels. I was talking a few weeks ago with a developer type from China who said something to the effect of ?Hosted X is a problem because while developer types have experience getting around firewalls, [manager types] do not?? From wesley.george at twcable.com Wed Jun 10 21:56:10 2015 From: wesley.george at twcable.com (George, Wes) Date: Wed, 10 Jun 2015 17:56:10 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <5578A933.8090504@dougbarton.us> Message-ID: On 6/10/15, 5:27 PM, "Ted Hardie" wrote: >>... and this argument has been refuted by the word "bridging." >> >> >?To repeat Valdis' question:? > >?And the router knows to send to the "front" address to reach the "back" >> address, how, exactly? Seems like somebody should invent a way to >>assign a >> prefix to the front address that it can delegate to things behind it. >>:)? WG] I made reference to it in a previous message, but since the question was repeated, I'll assume that was missed and repeat the answer. The hypervisor folks seem to have figured this out so that it "just works" without NAT, using virtual interfaces that have their own unique MAC addresses so that they look like unique hosts to the network/DHCP server. I'm using it on my FreeNAS (BSD) box at home with jails, and KVM supports it, so chances are it wouldn't even be that hard to incorporate into Android. Thanks Wes 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 mike at mtcc.com Wed Jun 10 22:07:59 2015 From: mike at mtcc.com (Michael Thomas) Date: Wed, 10 Jun 2015 15:07:59 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <5578ADEE.2080807@dougbarton.us> References: <5578A933.8090504@dougbarton.us> <5578ADEE.2080807@dougbarton.us> Message-ID: <5578B53F.7050609@mtcc.com> On 06/10/2015 02:36 PM, Doug Barton wrote: > > It *could*, but Lorenzo actually does have a point when he talks about > not wanting to cripple future application development. I'd also like > to see a rough outline of an implementation before commenting further. > > Meanwhile, DHCPv6 + PD solves all of Lorenzo's stated problems, but he > won't implement it because "DHCP." That's not something you can > engineer around. ??? I thought Lorenzo was fine with DHCPv6 so long as it was with PD? Mike From ted.ietf at gmail.com Wed Jun 10 22:09:56 2015 From: ted.ietf at gmail.com (Ted Hardie) Date: Wed, 10 Jun 2015 15:09:56 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <5578A933.8090504@dougbarton.us> Message-ID: On Wed, Jun 10, 2015 at 2:56 PM, George, Wes wrote: > > On 6/10/15, 5:27 PM, "Ted Hardie" wrote: > > >>... and this argument has been refuted by the word "bridging." > >> > >> > >?To repeat Valdis' question:? > > > >?And the router knows to send to the "front" address to reach the "back" > >> address, how, exactly? Seems like somebody should invent a way to > >>assign a > >> prefix to the front address that it can delegate to things behind it. > >>:)? > > WG] I made reference to it in a previous message, but since the question > was repeated, I'll assume that was missed and repeat the answer. The > hypervisor folks seem to have figured this out so that it "just works" > without NAT, using virtual interfaces that have their own unique MAC > addresses so that they look like unique hosts to the network/DHCP server. > I'm using it on my FreeNAS (BSD) box at home with jails, and KVM supports > it, so chances are it wouldn't even be that hard to incorporate into > Android. > > Thanks > Wes > > > ?Hi Wes, I saw your response, but creating a hypervisor-equivalent network stack inside Android didn't seem particularly easy to me. This may be, however, because I've mostly dealt with OVS-style approaches in the past few years and my calibration is off. If you have pointers to implementations that are for mobile devices, I'd be happy to be educated. regards, Ted > 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 dougb at dougbarton.us Wed Jun 10 22:10:39 2015 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 10 Jun 2015 15:10:39 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <5578A933.8090504@dougbarton.us> <5578ADEE.2080807@dougbarton.us> Message-ID: <5578B5DF.4060005@dougbarton.us> On 6/10/15 2:46 PM, Ted Hardie wrote: > ?That's fair enough, and some variability in what N is depending on > device is as a well. But understanding whether what we're actually > looking for is "static" or "single" is a pretty key piece of the > requirements scoping, and it sounds like "static" is it, at least from > your perspective. Is that a fair assessment? Ted, I honestly can't tell if you're deliberately misrepresenting my argument, or if you're just being dense. You snipped the several places in my previous message where I stated what I think the best way forward is. But just in case it's the latter, not the former: "I think PD is the right answer here of course ..." "Meanwhile, DHCPv6 + PD solves all of Lorenzo's stated problems, but he won't implement it because "DHCP." That's not something you can engineer around." Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mike at mtcc.com Wed Jun 10 22:24:11 2015 From: mike at mtcc.com (Michael Thomas) Date: Wed, 10 Jun 2015 15:24:11 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> Message-ID: <5578B90B.2000409@mtcc.com> On 06/10/2015 02:51 PM, Paul B. Henson wrote: >> From: Lorenzo Colitti >> Sent: Wednesday, June 10, 2015 8:27 AM >> >> please do not construe my words on this thread as being Google's position >> on anything. These messages were sent from my personal email address, and I >> do not speak for my employer. > Can we construe your postings on the issue thread as being Google and/or Androids official position? They are posted by lorenzo at google.com with a tag of "Project Member", and I believe you also declined the request in the issue under that mantle. > > Oh, stop this. The only thing this will accomplish is a giant black hole of silence from anybody at Google and any other $MEGACORP in a similar situation. Mike From ted.ietf at gmail.com Wed Jun 10 22:24:14 2015 From: ted.ietf at gmail.com (Ted Hardie) Date: Wed, 10 Jun 2015 15:24:14 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <5578B5DF.4060005@dougbarton.us> References: <5578A933.8090504@dougbarton.us> <5578ADEE.2080807@dougbarton.us> <5578B5DF.4060005@dougbarton.us> Message-ID: ?In-line. ? On Wed, Jun 10, 2015 at 3:10 PM, Doug Barton wrote: > On 6/10/15 2:46 PM, Ted Hardie wrote: > >> ?But understanding whether what we're actually >> looking for is "static" or "single" is a pretty key piece of the >> requirements scoping, and it sounds like "static" is it, at least from >> your perspective. Is that a fair assessment? >> > > Ted, > > I honestly can't tell if you're deliberately misrepresenting my argument, > or if you're just being dense. You snipped the several places in my > previous message where I stated what I think the best way forward is. But > just in case it's the latter, not the former: > > "I think PD is the right answer here of course ..." > > "Meanwhile, DHCPv6 + PD solves all of Lorenzo's stated problems, but he > won't implement it because "DHCP." That's not something you can engineer > around." > > Doug > > ?I think we lost context here. I started out asking a question in response to this statement by Matthew Huff: Authentication, Authorization, Accounting, ACLS, NMS, IDS, IP management, > custom software, and other roadblocks will certainly stall if not stop IPv6 > deployments in enterprises if there isn?t at least the choice of static, > single IPv6 addresses per device? ?My question was whether a mechanism that could provide a consistent mapping from prefix to user (or device) met the requirements above, whatever size the prefix provided happened to be. I wasn't trying to probe for which mechanism in that part of the question. I understand from your comments that you prefer DHCPv6 +PD. regards, Ted -- > I am conducting an experiment in the efficacy of PGP/MIME signatures. This > message should be signed. If it is not, or the signature does not validate, > please let me know how you received this message (direct, or to a list) and > the mail software you use. Thanks! > > From wesley.george at twcable.com Wed Jun 10 22:32:20 2015 From: wesley.george at twcable.com (George, Wes) Date: Wed, 10 Jun 2015 18:32:20 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <5578A933.8090504@dougbarton.us> Message-ID: From: Ted Hardie > Date: Wednesday, June 10, 2015 at 6:09 PM To: "George, Wes" > Cc: Doug Barton >, "nanog at nanog.org" > Subject: Re: Android (lack of) support for DHCPv6 I saw your response, but creating a hypervisor-equivalent network stack inside Android didn't seem particularly easy to me. This may be, however, because I've mostly dealt with OVS-style approaches in the past few years and my calibration is off. If you have pointers to implementations that are for mobile devices, I'd be happy to be educated. WG] I was merely observing that bridging so that multiple virtual interfaces/devices can share the same interface and get their own addresses is a solved problem generically. From what I can see with KVM, it involves creating a bridge interface or group, and bridging both the physical interface and any virtual interfaces into it, and then standing back. Doesn't seem obvious to me that it requires an entire hypervisor-equivalent network stack to get this one fairly limited feature, and I'm not aware of any mobile implementations, but it does seem to me that its presence in Linux makes it something we shouldn't dismiss out of hand when exploring solutions to this problem given Android's Linux roots - At it's core, it's still a general?purpose computer with a set of network interfaces. I'm not an expert on either Android's networking stack nor Linux's, nor hypervisors, but I have a hunch if this was allowed to move through the existing Android feature development process, we might find some folks that are and can tell us whether this is doable as an alternative to DHCP?PD or SLAAC on networks that generally adhere to the one address per device rule. Thanks Wes ________________________________ 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 marka at isc.org Wed Jun 10 22:37:38 2015 From: marka at isc.org (Mark Andrews) Date: Thu, 11 Jun 2015 08:37:38 +1000 Subject: Greenfield 464XLAT (In January) In-Reply-To: Your message of "Wed, 10 Jun 2015 14:47:23 -0700." References: Message-ID: <20150610223739.8201C3064838@rock.dv.isc.org> In message , Ca By writes: > On Wed, Jun 10, 2015 at 1:22 PM, Nicholas Warren > wrote: > > > Sincere apologies if this e-mail is inappropriate for this audience, > > We are (going to be) a startup ISP building a new network from the ground > > up. I was hoping I could get an opinion, or two, on how everyone feels > > about 464XLAT. I saw what everyone was saying about it in the 'Android > > doesn't support DHCPv6' discussion, but what about in the wireline side of > > things? The main reason we are even considering 464XLAT as opposed to > > dual-stack (the latter is, in my ignorant opinion, the better option.) is > > the fear of IPv4 depletion that we think might hit ARIN between now and the > > start of next year; causing us to pay a premium for IPv4 in the gray > > market. So I guess the real question here would be: is our fear real, or is > > it just bug on the wall? If our fear is real, what should we implement so > > that our users can still get to the v4 internet, are we even thinking > > soberly by suggesting 464XLAT? > > Thanks, > > - Nich > > > > > Yes, your fears about IPv4 are correct. > > If you have a look at ARIN PPML lately, you can see some pretty intense > "discussion" about companies exporting ARIN addresses to CCNIC and so on. > > As a greenfield, you should definitely be focused on IPv6-only to the edge > solutions. DS-lite, MAP-E, and 464XLAT come to mind. > > DS-lite is the oldest and most common in wireline. 464XLAT is more common > in mobile. MAP-E and MAP-T have not yet been deployed at the same scale as > DS-lite and 464XLAT yet AFAIK, not sure if they will be. > > You could also simply do dual-stack with private space and CGN to the end > user using RFC1918 (10.0.0.0/8, 100.64.0.0/10) > > Regards, > CB 464XLAT is a abomination that grew from NAT64/DNS64 despite DNS64 not working with DNSSEC. NAT64/DNS64 was pushed as a "short term solution" as DNS64 cuts off IPv4 access if there is a IPv6 address for the remote site as the client only asks for AAAA addresses. In practice the address selection rules move most traffic from IPv4 to IPv6 anyway so there is no need to have DNS64. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cb.list6 at gmail.com Wed Jun 10 22:38:02 2015 From: cb.list6 at gmail.com (Ca By) Date: Wed, 10 Jun 2015 15:38:02 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> Message-ID: Let's call off the witch hunt. Please. I get it, you want a DHCPv6 client. "Star" the project or whatever you think the right intake process is for an Android feature. On Wed, Jun 10, 2015 at 2:51 PM, Paul B. Henson wrote: > > From: Lorenzo Colitti > > Sent: Wednesday, June 10, 2015 8:27 AM > > > > please do not construe my words on this thread as being Google's position > > on anything. These messages were sent from my personal email address, > and I > > do not speak for my employer. > > Can we construe your postings on the issue thread as being Google and/or > Androids official position? They are posted by lorenzo at google.com with a > tag of "Project Member", and I believe you also declined the request in the > issue under that mantle. > > If your postings on the issue thread are not authoritative for Google, > could you possibly put us in contact with who as Google could make an > official statement as to why they are refusing to implement an accepted > Internet standard already deployed by their competitors, the lack of which > will directly harm their users? > > > From mike at mtcc.com Wed Jun 10 22:50:33 2015 From: mike at mtcc.com (Michael Thomas) Date: Wed, 10 Jun 2015 15:50:33 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <5578A933.8090504@dougbarton.us> Message-ID: <5578BF39.6070804@mtcc.com> On 06/10/2015 03:32 PM, George, Wes wrote: > From: Ted Hardie > > Date: Wednesday, June 10, 2015 at 6:09 PM > To: "George, Wes" > > Cc: Doug Barton >, "nanog at nanog.org" > > Subject: Re: Android (lack of) support for DHCPv6 > > > I saw your response, but creating a hypervisor-equivalent network stack inside Android didn't seem particularly easy to me. This may be, however, because I've mostly dealt with OVS-style approaches in the past few years and my calibration is off. If you have pointers to implementations that are for mobile devices, I'd be happy to be educated. > > WG] I was merely observing that bridging so that multiple virtual interfaces/devices can share the same interface and get their own addresses is a solved problem generically. From what I can see with KVM, it involves creating a bridge interface or group, and bridging both the physical interface and any virtual interfaces into it, and then standing back. Doesn't seem obvious to me that it requires an entire hypervisor-equivalent network stack to get this one fairly limited feature, and I'm not aware of any mobile implementations, but it does seem to me that its presence in Linux makes it something we shouldn't dismiss out of hand when exploring solutions to this problem given Android's Linux roots - At it's core, it's still a general?purpose computer with a set of network interfaces. I'm not an expert on either Android's networking stack nor Linux's, nor hypervisors, but I have a hunch if this was allowed to move through the existing Android feature development process, we might find some folks that are and can tell us whether this is doable as an alternative to DHCP?PD or SLAAC on networks that generally adhere to the one address per device rule. > > Besides, virtualizing the os environment on a phone would be a very interesting thing in its own right. I thought that was gaining momentum at one point as a way to deal with the friction between corpro-IT demands of control, and end user desire to keep nannyware crap off their phone -- just have two vm's with each environment. Mike From Valdis.Kletnieks at vt.edu Wed Jun 10 22:58:59 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 10 Jun 2015 18:58:59 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: Your message of "Wed, 10 Jun 2015 17:56:10 -0400." References: <5578A933.8090504@dougbarton.us> Message-ID: <99685.1433977139@turing-police.cc.vt.edu> On Wed, 10 Jun 2015 17:56:10 -0400, "George, Wes" said: > WG] I made reference to it in a previous message, but since the question > was repeated, I'll assume that was missed and repeat the answer. The > hypervisor folks seem to have figured this out so that it "just works" > without NAT, using virtual interfaces that have their own unique MAC > addresses so that they look like unique hosts to the network/DHCP server. > I'm using it on my FreeNAS (BSD) box at home with jails, and KVM supports > it, so chances are it wouldn't even be that hard to incorporate into > Android. It only "just works" if your upstream device doesn't check/care that you're emitting multiple MAC addresses from the same device. Also, it assumes that some moral equivalent of proxy arp is available. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jeffm at iglou.com Wed Jun 10 23:00:32 2015 From: jeffm at iglou.com (Jeff McAdams) Date: Wed, 10 Jun 2015 18:00:32 -0500 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <5578B90B.2000409@mtcc.com> Message-ID: <255945e5-3e9e-4993-9780-499f463f26a7@email.android.com> No. Given that Lorenzo was posting with absolute statements about Google's approach, and with what they would do in the future in response to hypothetical standards developments, these questions are completely valid. On Jun 10, 2015 5:24 PM, Michael Thomas wrote: > > On 06/10/2015 02:51 PM, Paul B. Henson wrote: > >> From: Lorenzo Colitti > >> Sent: Wednesday, June 10, 2015 8:27 AM > >> > >> please do not construe my words on this thread as being Google's position > >> on anything. These messages were sent from my personal email address, and I > >> do not speak for my employer. > > Can we construe your postings on the issue thread as being Google and/or Androids official position? They are posted by lorenzo at google.com with a tag of "Project Member", and I believe you also declined the request in the issue under that mantle. > > > > > Oh, stop this. The only thing this will accomplish is a giant black hole > of silence from anybody at Google and any other $MEGACORP > in a similar situation. > > Mike From rdobbins at arbor.net Thu Jun 11 00:25:54 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 11 Jun 2015 07:25:54 +0700 Subject: Lists of VPN exit addresses? In-Reply-To: <1657A2C7-A23B-4075-B7C9-C43C48F580A9@egon.cc> References: <20150610115646.3900.qmail@ary.lan> <1657A2C7-A23B-4075-B7C9-C43C48F580A9@egon.cc> Message-ID: <47232CD4-1051-4618-A72F-D7CC1D6A3947@arbor.net> On 11 Jun 2015, at 4:52, James Downs wrote: > I was talking a few weeks ago with a developer type from China who > said something to the effect of ?Hosted X is a problem because while > developer types have experience getting around firewalls, [manager > types] do not?? Yes, we all know that technical people can generally get around these sorts of blocks, and non-technical people all too often can't. The majority of people aren't technical (using Facebook and Instagram all day <> technical). ----------------------------------- Roland Dobbins From sabri at cluecentral.net Thu Jun 11 00:58:58 2015 From: sabri at cluecentral.net (Sabri Berisha) Date: Wed, 10 Jun 2015 17:58:58 -0700 (PDT) Subject: PPPoE/IPoE, any recommendations for upgrade? In-Reply-To: <002a01d0a0e9$f04481b0$d0cd8510$@rasana.net> References: <002a01d0a0e9$f04481b0$d0cd8510$@rasana.net> Message-ID: <531808769.10125.1433984338329.JavaMail.zimbra@cluecentral.net> Hi, I used to work for Redback (who were acquired by Ericsson), and their SmartEdge BNG supports a feature called CLIPS. CLIPS is basically IPoE towards the clients (DHCP based), but with BRAS features. The mac address of the client will be authenticated against your RADIUS and you can pretty much use the same policies as you're used to on PPPoE (with the exception of multicast-related policies of course). I'm not sure, but I think other vendors have similar features nowadays. This might help your migration. Thanks, Sabri ----- Original Message ----- > From: "Nasser Heidari" > To: nanog at nanog.org > Sent: Saturday, June 6, 2015 11:19:40 PM > Subject: PPPoE/IPoE, any recommendations for upgrade? > > Hi, > > We are currently using PPPoE in our network. I have seen some articles > regarding migration of so-called legacy PPPoE to IPoE. After reviewing some > of them and implementing IPoE in lab environment using Cisco ASR I didn't > fine it that much beneficial to migrate whole system as I need to change a > lot of things. For example: > - I need to add it's support to our radius and obviously BSS system (E.g. > using NAS-PORT-ID instead of username). > - For the addressing part, as I have already using distributed BNG's, I > need to change some of our policies. (For example assigning address blocks > is much easier in PPPoE using framed-route) > - I need to change our customers CPE configuration to use Ethernet > encapsulation. > - I haven't used DHCP in large scale environment. > - I don't have any clear Idea/understanding regarding its > maintainability/troubleshooting and also security. > (Please add if I'm missing any other issue which may run into if I migrate > to IPoE) > > Although it has some benefits, I'm not sure if it's that essential to > migrate. > Would you please kindly? > - Share your Ideas/experiences/best practices in this regard? > - If you are already using IPoE, tell more why should I upgrade? > - Considering a DSL network with more than 800K customers using PPPoE, do > you recommend this migration? > > > Kind Regards, > Nasser > > From rps at maine.edu Thu Jun 11 01:27:59 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 10 Jun 2015 21:27:59 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <255945e5-3e9e-4993-9780-499f463f26a7@email.android.com> References: <5578B90B.2000409@mtcc.com> <255945e5-3e9e-4993-9780-499f463f26a7@email.android.com> Message-ID: I agree that some of the rhetoric should be toned down (go out for a beer or something, guys ... I did). There is a difference between fiery debate with Lorenzo and a witch hunt, and some of this is starting to sound a bit personal. I shouldn't have worded things the way I did, I went for the cheap shot in one of those last notes and that isn't really constructive. I'm sorry. I think for many this thread represents years of frustration, though, and LC making the statements in the way he did made him a focal point for that frustration. The problem is there are many of us on the "front lines" trying to push for IPv6 adoption outside the bubble of idealism and when people of great influence like LC take positions like DHCPv6 isn't required it's like a slap in the face to all that effort. We really need to see Google and Android come on board with DHCPv6 support and I'm interested in how we can help make that happen. On Wed, Jun 10, 2015 at 7:00 PM, Jeff McAdams wrote: > No. > > Given that Lorenzo was posting with absolute statements about Google's > approach, and with what they would do in the future in response to > hypothetical standards developments, these questions are completely valid. > > On Jun 10, 2015 5:24 PM, Michael Thomas wrote: > > > > On 06/10/2015 02:51 PM, Paul B. Henson wrote: > > >> From: Lorenzo Colitti > > >> Sent: Wednesday, June 10, 2015 8:27 AM > > >> > > >> please do not construe my words on this thread as being Google's > position > > >> on anything. These messages were sent from my personal email address, > and I > > >> do not speak for my employer. > > > Can we construe your postings on the issue thread as being Google > and/or Androids official position? They are posted by lorenzo at google.com > with a tag of "Project Member", and I believe you also declined the request > in the issue under that mantle. > > > > > > > > Oh, stop this. The only thing this will accomplish is a giant black hole > > of silence from anybody at Google and any other $MEGACORP > > in a similar situation. > > > > Mike > -- 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 mpetach at netflight.com Thu Jun 11 01:39:36 2015 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 10 Jun 2015 18:39:36 -0700 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: <55778BE7.4010207@jvknet.com> References: <557702BA.2070004@jvknet.com> <4007870726252415245@unknownmsgid> <55778BE7.4010207@jvknet.com> Message-ID: We use IS-IS dual-stack in the core, and OSPFv2+OSPFv3 in the datacenters. Roughly 100 routers in the IS-IS core, and less than 2000 routers in the OSPFv2+OSPFv3 datacenters. Matt On Tue, Jun 9, 2015 at 5:59 PM, Victor Kuarsingh wrote: > > I/we (Philip and I) attempted to keep the question as generic as possible, > allowing folks to state the IGPs they use, in whichever combination or in > some cases (as we can see), more complex deployments. > > I would agree with statements form Joel earlier with respect to cases where > early vendor support may have influenced some network zones (inside a given > AS) to support a different IGP (his case of OSPFv3 for devices which lacked > IS-IS support is one I did face a few years back as well in the DC with > respect to Load balancing and Firewall devices). > > The merger one was a new one for me, but it seems to reflect some peoples > reality. > > > regards, > > Victor K > > > > > On 2015-06-09 7:41 PM, Joe Abley wrote: >> >> Hi Randy, >> >> On Jun 9, 2015, at 18:08, Randy Bush wrote: >> >>>> Routers makes more sense to me than networks (IGP, so one network, >>>> right?) >>> >>> so you are thinking of a network where half the routers run is-is one >>> quarter ospf/ospfv2 and one quarter ospf/ripv3. right. >> >> No, not at all. I thought Victor was asking "what IGP" and "how many >> routers use it in your network". I assumed he was interested in >> whether the size of the network influenced the IGP choice. >> >> Perhaps I misunderstood, because apparently I was the only one who >> read it that way. >> >> >> Joe > > From toddunder at gmail.com Thu Jun 11 01:40:40 2015 From: toddunder at gmail.com (Todd Underwood) Date: Thu, 11 Jun 2015 01:40:40 +0000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <5578B90B.2000409@mtcc.com> <255945e5-3e9e-4993-9780-499f463f26a7@email.android.com> Message-ID: Anyone who thinks Lorenzo hasn't been on the front lines of pushing for IPv6 adoption is pretty late to the party or confused about the state of affairs. T On Wed, Jun 10, 2015, 21:30 Ray Soucy wrote: > I agree that some of the rhetoric should be toned down (go out for a beer > or something, guys ... I did). > > There is a difference between fiery debate with Lorenzo and a witch hunt, > and some of this is starting to sound a bit personal. I shouldn't have > worded things the way I did, I went for the cheap shot in one of those last > notes and that isn't really constructive. I'm sorry. > > I think for many this thread represents years of frustration, though, and > LC making the statements in the way he did made him a focal point for that > frustration. > > The problem is there are many of us on the "front lines" trying to push for > IPv6 adoption outside the bubble of idealism and when people of great > influence like LC take positions like DHCPv6 isn't required it's like a > slap in the face to all that effort. > > We really need to see Google and Android come on board with DHCPv6 support > and I'm interested in how we can help make that happen. > > > > > > On Wed, Jun 10, 2015 at 7:00 PM, Jeff McAdams wrote: > > > No. > > > > Given that Lorenzo was posting with absolute statements about Google's > > approach, and with what they would do in the future in response to > > hypothetical standards developments, these questions are completely > valid. > > > > On Jun 10, 2015 5:24 PM, Michael Thomas wrote: > > > > > > On 06/10/2015 02:51 PM, Paul B. Henson wrote: > > > >> From: Lorenzo Colitti > > > >> Sent: Wednesday, June 10, 2015 8:27 AM > > > >> > > > >> please do not construe my words on this thread as being Google's > > position > > > >> on anything. These messages were sent from my personal email > address, > > and I > > > >> do not speak for my employer. > > > > Can we construe your postings on the issue thread as being Google > > and/or Androids official position? They are posted by lorenzo at google.com > > with a tag of "Project Member", and I believe you also declined the > request > > in the issue under that mantle. > > > > > > > > > > > Oh, stop this. The only thing this will accomplish is a giant black > hole > > > of silence from anybody at Google and any other $MEGACORP > > > in a similar situation. > > > > > > Mike > > > > > > -- > 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 Thu Jun 11 01:42:57 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 10 Jun 2015 21:42:57 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <5578B90B.2000409@mtcc.com> <255945e5-3e9e-4993-9780-499f463f26a7@email.android.com> Message-ID: I like to think of it more like the command tent ;-) On Wed, Jun 10, 2015 at 9:40 PM, Todd Underwood wrote: > Anyone who thinks Lorenzo hasn't been on the front lines of pushing for > IPv6 adoption is pretty late to the party or confused about the state of > affairs. > > T > > On Wed, Jun 10, 2015, 21:30 Ray Soucy wrote: > >> I agree that some of the rhetoric should be toned down (go out for a beer >> or something, guys ... I did). >> >> There is a difference between fiery debate with Lorenzo and a witch hunt, >> and some of this is starting to sound a bit personal. I shouldn't have >> worded things the way I did, I went for the cheap shot in one of those >> last >> notes and that isn't really constructive. I'm sorry. >> >> I think for many this thread represents years of frustration, though, and >> LC making the statements in the way he did made him a focal point for that >> frustration. >> >> The problem is there are many of us on the "front lines" trying to push >> for >> IPv6 adoption outside the bubble of idealism and when people of great >> influence like LC take positions like DHCPv6 isn't required it's like a >> slap in the face to all that effort. >> >> We really need to see Google and Android come on board with DHCPv6 support >> and I'm interested in how we can help make that happen. >> >> >> >> >> >> On Wed, Jun 10, 2015 at 7:00 PM, Jeff McAdams wrote: >> >> > No. >> > >> > Given that Lorenzo was posting with absolute statements about Google's >> > approach, and with what they would do in the future in response to >> > hypothetical standards developments, these questions are completely >> valid. >> > >> > On Jun 10, 2015 5:24 PM, Michael Thomas wrote: >> > > >> > > On 06/10/2015 02:51 PM, Paul B. Henson wrote: >> > > >> From: Lorenzo Colitti >> > > >> Sent: Wednesday, June 10, 2015 8:27 AM >> > > >> >> > > >> please do not construe my words on this thread as being Google's >> > position >> > > >> on anything. These messages were sent from my personal email >> address, >> > and I >> > > >> do not speak for my employer. >> > > > Can we construe your postings on the issue thread as being Google >> > and/or Androids official position? They are posted by >> lorenzo at google.com >> > with a tag of "Project Member", and I believe you also declined the >> request >> > in the issue under that mantle. >> > > > >> > > > >> > > Oh, stop this. The only thing this will accomplish is a giant black >> hole >> > > of silence from anybody at Google and any other $MEGACORP >> > > in a similar situation. >> > > >> > > Mike >> > >> >> >> >> -- >> 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 mpetach at netflight.com Thu Jun 11 02:01:29 2015 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 10 Jun 2015 19:01:29 -0700 Subject: eBay is looking for network heavies... In-Reply-To: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> References: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> Message-ID: On Sun, Jun 7, 2015 at 7:57 PM, Jay Ashworth wrote: [...] > > And this... is NANOG! Needs more ellipses and capitalization...more like This...IS...NANOG!!! building up to a nice crescendo roar as you kick the hapless interviewee backwards down the deep, dark well On a slightly different note, however--while it's good to have an appreciation of the past and how we got here, I think it's wise to also recognize we as an industry have some challenges bringing new blood in--and treating it too much like a sacred priesthood with cabalistic knowledge and initiation rites isn't going to help us bring new engineers into the field to take over for us crusty old farts when our eyes give out and we can't type into our 9600 baud serial consoles anymore. Matt CCOF #1999322002 [0] [0] Certified Crufty Old Fart From lyndon at orthanc.ca Thu Jun 11 02:10:15 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Wed, 10 Jun 2015 19:10:15 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <5578A933.8090504@dougbarton.us> Message-ID: <638A6E91-8A9C-4422-A26C-2254B5FDF134@orthanc.ca> Where is Mr. Protocol? When we need him most?! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lyndon at orthanc.ca Thu Jun 11 02:47:21 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Wed, 10 Jun 2015 19:47:21 -0700 Subject: eBay is looking for network heavies... In-Reply-To: References: <12616019.0.1433908143109.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 10, 2015, at 11:18 AM, goemon at anime.net wrote: > Indeed, the interview process is a two way street. Lets you evaluate who you would be working for -- or if you really would want to. I wrote most of a very long follow-up to this. But what it boils down to is: +10,000 For all of you sitting across the table, consider that you are being interviewed even more intensely than you think you are interviewing us. (By anyone who has been in the game for a while, at least. Which means the people you have short-listed, right?) Over the past 25 years or so, I can think of a half-dozen offers I've turned down because the employer failed the interview. (Which doesn't make me a geeenious ... just someone who values low blood pressure, and prefers an interesting work environment over $$$) --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From egon at egon.cc Thu Jun 11 03:16:45 2015 From: egon at egon.cc (James Downs) Date: Wed, 10 Jun 2015 20:16:45 -0700 Subject: Lists of VPN exit addresses? In-Reply-To: <47232CD4-1051-4618-A72F-D7CC1D6A3947@arbor.net> References: <20150610115646.3900.qmail@ary.lan> <1657A2C7-A23B-4075-B7C9-C43C48F580A9@egon.cc> <47232CD4-1051-4618-A72F-D7CC1D6A3947@arbor.net> Message-ID: > On Jun 10, 2015, at 17:25, Roland Dobbins wrote: > > Yes, we all know that technical people can generally get around these sorts of blocks, and non-technical people all too often can't. > > The majority of people aren't technical (using Facebook and Instagram all day <> technical). I thought your point was that you encounter governmentally-driven censorship frequently in your travels, and you were in favor of making it easier to get around it. The need for this was what my anecdote was meant to illustrate. From list at satchell.net Thu Jun 11 03:39:41 2015 From: list at satchell.net (Stephen Satchell) Date: Wed, 10 Jun 2015 20:39:41 -0700 Subject: eBay is looking for network heavies... In-Reply-To: References: <12616019.0.1433908143109.JavaMail.root@benjamin.baylink.com> Message-ID: <557902FD.7090107@satchell.net> On 06/10/2015 07:47 PM, Lyndon Nerenberg wrote: > Over the past 25 years or so, I can think of a half-dozen offers I've > turned down because the employer failed the interview. (Which > doesn't make me a geeenious ... just someone who values low blood > pressure, and prefers an interesting work environment over $$$) OK, can't ignore a straight line like that... When I was living in Chicago, a head-hunter steered me to a consulting firm that had a hot project. They were looking for young hot programmers for a top-secret project. After the phone screen, the company called me in for the face-to-face "interview". I put the word "interview" in quotes because, for 25 minutes, the chief programmer of the place played a video game he wrote. That was the extent of the interview! The company? A game studio (back when game studios were new) who had a contract to develop games for the to-be-introduced Coleco Adam. Um, that was a surprise, and not my thing. I ran out of there... From mohta at necom830.hpcl.titech.ac.jp Thu Jun 11 03:44:36 2015 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 11 Jun 2015 12:44:36 +0900 Subject: DHCPv6 route option (was Re: Android (lack of) support for DHCPv6) In-Reply-To: <5578AAD9.4030105@dougbarton.us> References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> <5578AAD9.4030105@dougbarton.us> Message-ID: <55790424.9090801@necom830.hpcl.titech.ac.jp> Doug Barton wrote: > No, you're not. Some of us have been saying that requiring RA is a bad > idea, and that adding features to it is a bad idea, for over 15 years now. Need a DHCPv6 route option? > Unfortunately the anti-DHCP crowd hasn't budged, no matter how many > operators have told them that they cannot manage an IPv6 network with > the current state of the protocol. FYI, the operators suffering from a lack of feature of some standard are free to have an agreement on how to use the private use part of a number range in the standard controlled by someone else. It is legal, harmless and IETF did so, for example, to map IPv6 multicast addresses to local (that is, not assigned by IEEE and for private use) Ethernet group MAC addresses in section 7 of rfc2464. Thus, interested operators can have an agreement to use some private use option values (224-254) of DHCPv6 for the route option. Moreover, the agreement can be published as a NANOG/RIPE/APRICOT/... recommendation or a some (newly formed) forum standard. Then, some implementers are happily follow the recommendation/standard in addition to IETF standards. At least, ISC has done so, already. https://www.isc.org/blogs/routing-configuration-over-dhcpv6-2/ The presented examples use values 242 for NEXT_HOP and 243 for RTPREFIX option codes. Don't you want to increase the number of operators endorsing the private assignments? Masataka Ohta From rdobbins at arbor.net Thu Jun 11 03:50:21 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 11 Jun 2015 10:50:21 +0700 Subject: Lists of VPN exit addresses? In-Reply-To: References: <20150610115646.3900.qmail@ary.lan> <1657A2C7-A23B-4075-B7C9-C43C48F580A9@egon.cc> <47232CD4-1051-4618-A72F-D7CC1D6A3947@arbor.net> Message-ID: <5285AF56-19B6-4ADA-8380-5DF9FD7DBA6C@arbor.net> On 11 Jun 2015, at 10:16, James Downs wrote: > I thought your point was that you encounter governmentally-driven > censorship frequently in your travels, and you were in favor of making > it easier to get around it. Yes, absolutely. We're in violent agreement. ;> ----------------------------------- Roland Dobbins From lyndon at orthanc.ca Thu Jun 11 04:31:39 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Wed, 10 Jun 2015 21:31:39 -0700 Subject: Nobody is looking for serious candidates In-Reply-To: <557902FD.7090107@satchell.net> References: <12616019.0.1433908143109.JavaMail.root@benjamin.baylink.com> <557902FD.7090107@satchell.net> Message-ID: On Jun 10, 2015, at 8:39 PM, Stephen Satchell wrote: > After the phone screen, the company called me in for the face-to-face "interview". I put the word "interview" in quotes because, for 25 minutes, the chief programmer of the place played a video game he wrote. That was the extent of the interview! Mmm hmm. E.g. I spent half+ an hour being grilled on the internals and efficiencies of various regular expression library implementations. '[a-z]' vs. '[:islower:]' or something equally irrelevant to the interview at hand, for a position creating/managing the kernel - not apps - for an email spam filtering appliance. The second half hour devolved into a rant by the interviewer about 'volatile' in whatever was the latest version of the ANSI C standard. You can have a lot of fun, though, by playing the interviewers. When you discover your interest in the company is a noop, steering things into the Brazil regime can generate endless entertainment ;-) In fact, fishing for silliness can produce plenty of results. --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alexwr at gmail.com Thu Jun 11 04:46:24 2015 From: alexwr at gmail.com (Alex White-Robinson) Date: Thu, 11 Jun 2015 16:46:24 +1200 Subject: eBay is looking for network heavies... In-Reply-To: References: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> Message-ID: Matthew Petach wrote: > On a slightly different note, however--while it's good to > have an appreciation of the past and how we got here, > I think it's wise to also recognize we as an industry > have some challenges bringing new blood in--and > treating it too much like a sacred priesthood with > cabalistic knowledge and initiation rites isn't going > to help us bring new engineers into the field to > take over for us crusty old farts when our eyes > give out and we can't type into our 9600 baud > serial consoles anymore. > > Matt > CCOF #1999322002 [0] I've seen very little attention paid to junior talent in the last few years, and know a few people who would have been talented engineers that never got a chance to show it. They moved into other industries because of the lack of junior roles. I know very few people in network engineering that are under thirty, and not that many under thirty five. On Thu, Jun 11, 2015 at 2:01 PM, Matthew Petach wrote: > On Sun, Jun 7, 2015 at 7:57 PM, Jay Ashworth wrote: > [...] > > > > And this... is NANOG! > > Needs more ellipses and capitalization...more like > > > This...IS...NANOG!!! > > building up to a nice crescendo roar as you kick the > hapless interviewee backwards down the deep, dark well > > > On a slightly different note, however--while it's good to > have an appreciation of the past and how we got here, > I think it's wise to also recognize we as an industry > have some challenges bringing new blood in--and > treating it too much like a sacred priesthood with > cabalistic knowledge and initiation rites isn't going > to help us bring new engineers into the field to > take over for us crusty old farts when our eyes > give out and we can't type into our 9600 baud > serial consoles anymore. > > Matt > CCOF #1999322002 [0] > > > > > [0] Certified Crufty Old Fart > From blakjak at blakjak.net Thu Jun 11 04:59:19 2015 From: blakjak at blakjak.net (Mark Foster) Date: Thu, 11 Jun 2015 16:59:19 +1200 Subject: eBay is looking for network heavies... In-Reply-To: References: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> Message-ID: <557915A7.6010106@blakjak.net> On 11/06/2015 4:46 p.m., Alex White-Robinson wrote: > Matthew Petach wrote: > >> On a slightly different note, however--while it's good to >> have an appreciation of the past and how we got here, >> I think it's wise to also recognize we as an industry >> have some challenges bringing new blood in--and >> treating it too much like a sacred priesthood with >> cabalistic knowledge and initiation rites isn't going >> to help us bring new engineers into the field to >> take over for us crusty old farts when our eyes >> give out and we can't type into our 9600 baud >> serial consoles anymore. >> >> Matt >> CCOF #1999322002 [0] > I've seen very little attention paid to junior talent in the last few > years, and know a few people who would have been talented engineers that > never got a chance to show it. > They moved into other industries because of the lack of junior roles. > > I know very few people in network engineering that are under thirty, and > not that many under thirty five. An interesting statement; both my current network engineering team members are under 35 (and one is under 30) - i'm actually on the hunt for a slightly more senior resource at the moment to take up a vacant Team Leader role, and the candidates i've had apply are generally in their 30's. But perhaps New Zealand is a different audience to the North American continent. Fair enough. My career started as a Network Junior and i'm keen to facilitiate opportunities to move upward for others who're in similar circumstances to that which I was in ~10 years ago, surely i'm not that unusual...?? Mark. From pete at fiberphone.co.nz Thu Jun 11 05:59:28 2015 From: pete at fiberphone.co.nz (Pete Mundy) Date: Thu, 11 Jun 2015 17:59:28 +1200 Subject: Lists of VPN exit addresses? In-Reply-To: <20150610115646.3900.qmail@ary.lan> References: <20150610115646.3900.qmail@ary.lan> Message-ID: <135C54FA-67F5-401B-893A-9980A7974CCF@fiberphone.co.nz> On 10/06/2015 11:59 PM, "John Levine" wrote: > > Does anyone keep lists of the exit addresses of public VPN services? You can get all known commercial v4 VPN endpoints with one declaration: 0.0.0.0/0 That'll guarantee you catch em! Good luck :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4145 bytes Desc: not available URL: From mark.tinka at seacom.mu Thu Jun 11 06:50:38 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 11 Jun 2015 08:50:38 +0200 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: <49A81EB09F493442B6D259E36251192C01719F1F6A@ndcc-exch1.neutraldata.com> References: <557702BA.2070004@jvknet.com> <49A81EB09F493442B6D259E36251192C01719F1F6A@ndcc-exch1.neutraldata.com> Message-ID: <55792FBE.6070002@seacom.mu> On 9/Jun/15 23:55, Sameer Khosla wrote: > Think of scenarios where you have mergers/acquisitions where different portions of the now amalgamated network were designed differently and there may be too much pain or require too much time to redesign rather than bolt together and redistribute. In such cases, BGP-LS may be a better approach, as that encourages more sane filtering in the IGP than an IGP generally would. Mark. From mark.tinka at seacom.mu Thu Jun 11 06:51:42 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 11 Jun 2015 08:51:42 +0200 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <30B29C1F-F92E-4607-952A-B0E230D1A26B@lboro.ac.uk> <20150609070920.GE3716@bender.unx.cpp.edu> <20150609213223.GF999@cmadams.net> Message-ID: <55792FFE.6050807@seacom.mu> On 9/Jun/15 23:56, Owen DeLong wrote: > At the end of the day, I see Androids refusal to implement DHCPv6 as about the same level of stupidity as Apple?s refusal to implement 464XLAT in iOS. > > Both companies need to pull their heads out of their asses. Much like the router vendors fought, for years, over whether LDP or BGP signaling was best for VPLS. In the end, they came to their senses and support them both (largely driven by customers voting with their wallets). Mark. From mark.tinka at seacom.mu Thu Jun 11 06:54:18 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 11 Jun 2015 08:54:18 +0200 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: <557770E0.7060105@bogus.com> References: <557702BA.2070004@jvknet.com> <557770E0.7060105@bogus.com> Message-ID: <5579309A.9000500@seacom.mu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/Jun/15 01:04, joel jaeggli wrote: > > At one time I had datacenter interiors that had no isis support. they > ran ospfv2 and to the extent that it was necessary in limited > application ospfv3. the datacenter border and the backbone used ISIS for > both adress families. routes were in general not redistributed between IGPs. We run Quagga on Anycast servers (DNS, NTP, TACACS+, e.t.c.) using OSPFv2|v3, largely because Quagga's IS-IS support is terrible. We have (restrictively) redistribute that into our IS-IS backbone, which works great. Wish we didn't have to do that, but it works well, and OSPF is stable in Quagga. Mark. -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJVeTCaAAoJEGcZuYTeKm+GZEkP/iPyXNsOkCFwBIbYU4Q8SyDN qjW0oZR8MY126nLqgikvwJed4PdMwZh/Qoyz2C76e2LLVl03/Ru8gN0I8fUl6ueH +B8dKUuTiY8Q4eXyR5GzY451GafY+O/ggJDruDi7t24XCWl14w32pfqdiCTwE10Q Ch+S5mbd8MavLOK2Rbh8bS5AFztRBol7U34UZhUeyH/3/I9xwaMojV0u637Id6b1 veuILlLohxdqUF8r04HRBdr9AZVGADorV1/4C2T4kgCJXrbGpN+QBOMvbjkdBQBU cufppx5hnSSb9tSrkX0cGYFD8ouZXRGK9oC+6Uuouj1R9/Uxfvml4DxJJq75ZEON XZMUEX8NPUJOlX65a94WDdI/7IBp+zTRS5CO2ZXcWYqbXWxFOajjslj7L4LbVADq PZq4HVtGFCeEiyftPXv8r3mmBw/5CJSst255BaYLk6EF8tU0TZbgoeYJspqQXMYx I3HI3GYMhDalHtoMGFNedl+atpVHtlMtOXY+hPuIdpDXXnIw8UrRL1s21qmtSpJD p/5enXrPW5opBdQYQ+dar7LedbanupqhTV0Zp2TZ/n7yaqakalvWk1bCAkwzVrOk 1d0cPNXlomyithOFXSnp1cUqtnsyxixtgcQcY2DgXUKGqnaB2GcHskTu/2gYCmV2 Zcud3k0zJDrCFkve+im6 =osk1 -----END PGP SIGNATURE----- From mark.tinka at seacom.mu Thu Jun 11 06:56:01 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 11 Jun 2015 08:56:01 +0200 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: <24422.1433887245@turing-police.cc.vt.edu> References: <557702BA.2070004@jvknet.com> <49A81EB09F493442B6D259E36251192C01719F1F6A@ndcc-exch1.neutraldata.com> <24422.1433887245@turing-police.cc.vt.edu> Message-ID: <55793101.3090807@seacom.mu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/Jun/15 00:00, Valdis.Kletnieks at vt.edu wrote: > > But in that case, don't they usually say "The heck with it" and continue > using 2 separate ASN numbers? We tried the multiple AS thing once, many years ago at $previous_job. It's cool on paper. We collapsed back into a single AS. Will never touch that sauce again. Mark. -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJVeTEBAAoJEGcZuYTeKm+GG/4P/j/FwIeCM1juYK4JmbOOtEJw Sx9YK6/W3seDN0xeTuhqAwEkJhTtd+gEvumpOWau7UiYqhoctuIAK5p4RDZJXm+e 9rGZFl4dIbMCTyIiXxPLEwPMqNx04P3nXsQPRqY7znzYnVUa+v/pVxvaJsq1+eE6 pgrp88upePZHzFhlWqAZSkFOASBLU8ggrngKSEt5OU0av5bd+oUoBztETaFl0RjK m3XjwglWa9oHC9ll63YT5NmaMf84BMYOFRmDXijNlpXDbmF8CJO2WpPgWu/ZYDqp g8GJomFi+T/A/v2Iq5Dn+SWQP3UQrpMFK7HevMUrad4hFJ0CVbZCxGUccmGsUEBK 0LbwtvNBXdIGjupp3ArjYSbv48HuZKa6wv5aC6QBhAGxkIY15jvR2g4KuLQMLDZG CiNqPMx5Oc+bXN7eSphVDuo2wOPZ+GeA/wIvw3x0EGlBpA9bjZuAGufIollgYeU8 5rgLJkk/u09Nicuql3SU1KUtZ+9afYnnR3MBqfy24ZZpzTgOaDQFXu+yB0ImF490 vkjVEG7gIVlwsF2WKl20rA4a4b5iTN9yWX+CLtAc+2eOU1qjNVhN4IVKrVLr+fQc ZF8owfyf3IfBh3VK8OmtYd+SMbWkmlv55nVI6Wl1oAiv0DKmXrArkDUPjHCKXvhJ bIjz/evtVHH2S9lRJLNq =HlQJ -----END PGP SIGNATURE----- From mark.tinka at seacom.mu Thu Jun 11 07:00:23 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 11 Jun 2015 09:00:23 +0200 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: <4007870726252415245@unknownmsgid> References: <557702BA.2070004@jvknet.com> <4007870726252415245@unknownmsgid> Message-ID: <55793207.8040803@seacom.mu> On 10/Jun/15 01:41, Joe Abley wrote: > No, not at all. I thought Victor was asking "what IGP" and "how many > routers use it in your network". I assumed he was interested in > whether the size of the network influenced the IGP choice. It did for us - IS-IS here with a couple hundred routers (and growing), as I mentioned to Victor and Philip when they posted this in another forum. Single level (L2). Mark. From mark.tinka at seacom.mu Thu Jun 11 07:02:29 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 11 Jun 2015 09:02:29 +0200 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: <55778BE7.4010207@jvknet.com> References: <557702BA.2070004@jvknet.com> <4007870726252415245@unknownmsgid> <55778BE7.4010207@jvknet.com> Message-ID: <55793285.3000107@seacom.mu> On 10/Jun/15 02:59, Victor Kuarsingh wrote: > > > I would agree with statements form Joel earlier with respect to cases > where early vendor support may have influenced some network zones > (inside a given AS) to support a different IGP (his case of OSPFv3 for > devices which lacked IS-IS support is one I did face a few years back > as well in the DC with respect to Load balancing and Firewall devices). Also, router CPU's were much slower then than they are now. The IGP's have gotten a little more complex also, but by-and-large, are still the same if you don't do "fancy things". So there would be a certain amount of increase in scale that an IGP domain would support, perhaps, regardless of which IGP is chosen. Mark. From notify.sina at gmail.com Thu Jun 11 07:24:46 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Thu, 11 Jun 2015 07:24:46 +0000 Subject: eBay is looking for network heavies... In-Reply-To: <557915A7.6010106@blakjak.net> References: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> <557915A7.6010106@blakjak.net> Message-ID: I'm curious. What reading and comprehension level does one need to be considered a network heavy? No snark, I really would like to know. On Thu, Jun 11, 2015, 6:01 AM Mark Foster wrote: > > > On 11/06/2015 4:46 p.m., Alex White-Robinson wrote: > > Matthew Petach wrote: > > > >> On a slightly different note, however--while it's good to > >> have an appreciation of the past and how we got here, > >> I think it's wise to also recognize we as an industry > >> have some challenges bringing new blood in--and > >> treating it too much like a sacred priesthood with > >> cabalistic knowledge and initiation rites isn't going > >> to help us bring new engineers into the field to > >> take over for us crusty old farts when our eyes > >> give out and we can't type into our 9600 baud > >> serial consoles anymore. > >> > >> Matt > >> CCOF #1999322002 [0] > > I've seen very little attention paid to junior talent in the last few > > years, and know a few people who would have been talented engineers that > > never got a chance to show it. > > They moved into other industries because of the lack of junior roles. > > > > I know very few people in network engineering that are under thirty, and > > not that many under thirty five. > > An interesting statement; both my current network engineering team > members are under 35 (and one is under 30) - i'm actually on the hunt > for a slightly more senior resource at the moment to take up a vacant > Team Leader role, and the candidates i've had apply are generally in > their 30's. > > But perhaps New Zealand is a different audience to the North American > continent. Fair enough. > > My career started as a Network Junior and i'm keen to facilitiate > opportunities to move upward for others who're in similar circumstances > to that which I was in ~10 years ago, surely i'm not that unusual...?? > > Mark. > > > From dave.taht at gmail.com Thu Jun 11 07:48:54 2015 From: dave.taht at gmail.com (Dave Taht) Date: Thu, 11 Jun 2015 00:48:54 -0700 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: <557702BA.2070004@jvknet.com> References: <557702BA.2070004@jvknet.com> Message-ID: On Tue, Jun 9, 2015 at 8:14 AM, Victor Kuarsingh wrote: > Nanog Folks: > > Philip Matthews and I are co-authors on an active draft within the IETF > related to IPv6 routing design choices. To ensure we are gathering > sufficient data we are looking for an expanded set of input from operator > forums as well (vs. just the v6ops IETF list). The draft is found here > -(https://tools.ietf.org/html/draft-ietf-v6ops-design-choices). > > We are looking for information on the IGP combinations people are running in > their dual-stack networks. We are gathering this information so we can > document in our draft which IGP choices are known to work well (i.e., people > actually run this combination in production networks without issues). The > draft will not name names, but just discuss things in aggregate: for > example, "there are 3 large and 2 small production networks that run OSPF > for IPv4 and IS-IS for IPv6, thus that combination is judged to work well". > If you have a production dual-stack network, then we would like to know > which IGP you use to route IPv4 and which you use to route IPv6. Babel, for both. (carries both protocols in the same packet, same daemon) > We would > also like to know roughly how many routers are running this combination. In production: 28. In test (and still shared with production) anywhere from 8 to 68. Couple other smaller sites. a few thousand cerowrt boxes "out there", with some percentage having 2-3 participating nodes at least. ietf Homenet prototypes, also. > Feel free to share any successes or concerns with the combination as well. Gave up on bridging, and tried olsr, batman, ospfv3, before settling on babel. Source specific routing now a big help on 110 acre campus with multiple egress nodes. mixed (and mostly) wifi and ethernet, also, which ruled out ospf big time. multi-channel interference, which ruled out olsr (at the time). batman was layer 2 and hard to segment, and bridging 7 wifi hops did not scale at all over 802.11s nor WDS. > We are looking particularly at combinations of the following IGPs: IS-IS, > OSPFv2, OSPFv3, EIGRP. Babel config is crazy easy compared to any of these. So are packet loads. Filtering out natted addrs while still preserving e2e ipv6 connectivity, easy also. a flaw of DV is not seeing the whole picture of the network without traceroute or alternate monitoring means than the protocol itself. Still, see: https://tools.ietf.org/html/draft-chroboczek-babel-doesnt-care-00 Worst case, it's good for a laugh. > If you run something else (RIP?) then we would also like to hear about this, > though we will likely document these differently. [We suspect you run > RIP/RIPng only at the edge for special situations, but feel free to correct > us]. > > And if you have one of those modern networks that carries dual-stack > customer traffic in a L3VPN or similar and thus don?t need a dual-stacked > core, then please email us and brag ... > > If you are on multiple lists at RIPE, NANOG or the IETF, we appologize for > any redundant emails you may get (we are just attempting to reach the widest > audience possible). > > Philip Matthews > Victor Kuarsingh -- Dave T?ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From mohta at necom830.hpcl.titech.ac.jp Thu Jun 11 07:51:22 2015 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 11 Jun 2015 16:51:22 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <99685.1433977139@turing-police.cc.vt.edu> References: <5578A933.8090504@dougbarton.us> <99685.1433977139@turing-police.cc.vt.edu> Message-ID: <55793DFA.2060502@necom830.hpcl.titech.ac.jp> Valdis.Kletnieks at vt.edu wrote: > It only "just works" if your upstream device doesn't check/care that > you're emitting multiple MAC addresses from the same device. What if a Wifi router checks that a device authenticated by a student's account uses only one IPv4, one IPv6 and one MAC addresses? Can tethering still work? Masataka Ohta From johnl at iecc.com Thu Jun 11 07:51:54 2015 From: johnl at iecc.com (John Levine) Date: 11 Jun 2015 07:51:54 -0000 Subject: Lists of VPN exit addresses? In-Reply-To: Message-ID: <20150611075154.9104.qmail@ary.lan> In article you write: > >On 10 Jun 2015, at 18:56, John Levine wrote: > >> I presume there is no need to explain why this would be of interest. Gee, I appear to have presumed wrong. My concrete application is vetting updates to the abuse.net contact database, to recognize people who are trying to hide their actual location. >To keep consumers ... R's, John From mark.tinka at seacom.mu Thu Jun 11 07:53:18 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 11 Jun 2015 09:53:18 +0200 Subject: Looking for information on IGP choices in dual-stack networks In-Reply-To: <55789678.3010501@direcpath.com> References: <557702BA.2070004@jvknet.com> <55789678.3010501@direcpath.com> Message-ID: <55793E6E.2050006@seacom.mu> On 10/Jun/15 21:56, Robert Drake wrote: > > > When we first were moving to IPv6 in the core network we evaluated > IS-IS because it was what we were using for IPv4 and we would have > preferred to run a single protocol for both. We had problems with > running a mix of routers where some supported IPv6 and others did > not. From what I recall, if any router did not support IPv6 then it > wouldn't connect to a router running v6 and v4. > > It's possible these were bugs and they were worked out later or just a > messed up design in the lab, but we also like the idea of keeping IPv4 > and IPv6 away from each other so if one is broken the other one might > still work. Someone may have already mentioned this, but you hit that issue because you were probably running ST (Single Topology) IS-IS. IS-IS supports MT (Multi Topology) which allows you to have incongruent IP stacks on a link, i.e., IPv4 on one end + IPv4/IPv6 on another. As the majority of strategies to implement IPv6 will be in this manner, always recommended to run IS-IS in MT mode. Unless you were implementing IS-IS before MT was supported in code. Mark. From lou at metron.com Thu Jun 11 07:53:59 2015 From: lou at metron.com (Lou Katz) Date: Thu, 11 Jun 2015 00:53:59 -0700 Subject: Good contact at Megapath wanted Message-ID: <20150611075358.GA88048@metron.com> regarding DDoS. Please contact me off-list. -- -=[L]=- Reassembled from random thought waves "We have a saying here on Jupiter -- everybody talks about the Great Red Spot but nobody does anything about it." - Lauren Weinstein From swmike at swm.pp.se Thu Jun 11 08:33:58 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 11 Jun 2015 10:33:58 +0200 (CEST) Subject: Quagga IS-IS (Re: Looking for information on IGP choices in dual-stack networks) In-Reply-To: <5579309A.9000500@seacom.mu> References: <557702BA.2070004@jvknet.com> <557770E0.7060105@bogus.com> <5579309A.9000500@seacom.mu> Message-ID: On Thu, 11 Jun 2015, Mark Tinka wrote: > We run Quagga on Anycast servers (DNS, NTP, TACACS+, e.t.c.) using > OSPFv2|v3, largely because Quagga's IS-IS support is terrible. Quagga's IS-IS will get a lot better in the fall because funding has been provided to fix things important to IETF HOMENET working group requirements for IGP. This will not fix things across the entire Quagga IS-IS code base, but things should be substantially improved. If you're interested in improving it further than that, do send some money to people capable of doing the work, and have them do it. Contact me off-list if you want more information. -- Mikael Abrahamsson email: swmike at swm.pp.se From rdobbins at arbor.net Thu Jun 11 09:38:41 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 11 Jun 2015 16:38:41 +0700 Subject: Lists of VPN exit addresses? In-Reply-To: <20150611075154.9104.qmail@ary.lan> References: <20150611075154.9104.qmail@ary.lan> Message-ID: <19EBD1E0-4CFA-4BA5-AA40-2F8247942BCF@arbor.net> On 11 Jun 2015, at 14:51, John Levine wrote: > to recognize people who are trying to hide their actual location. Precisely. ----------------------------------- Roland Dobbins From deleskie at gmail.com Thu Jun 11 11:05:00 2015 From: deleskie at gmail.com (jim deleskie) Date: Thu, 11 Jun 2015 08:05:00 -0300 Subject: eBay is looking for network heavies... In-Reply-To: References: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> Message-ID: There is a good reason there aren't LOTS of "good" neteng in the 30-35 or under 30 range with lots of experience. Its call the hell we went though for a while after 2000 working in this industry. Many of us lost jobs and couldn't find new ones. I know talented folks that had to go to delivering pizzas ( not to slag pizza delivery folks) to support themselves and their families. Some folks ended up leaving the industry because of it and I'm "sure" lots of people choose to no get into the field seeing no jobs. This type of event causes a whole that takes a long time correct. On Thu, Jun 11, 2015 at 1:46 AM, Alex White-Robinson wrote: > Matthew Petach wrote: > > > On a slightly different note, however--while it's good to > > have an appreciation of the past and how we got here, > > I think it's wise to also recognize we as an industry > > have some challenges bringing new blood in--and > > treating it too much like a sacred priesthood with > > cabalistic knowledge and initiation rites isn't going > > to help us bring new engineers into the field to > > take over for us crusty old farts when our eyes > > give out and we can't type into our 9600 baud > > serial consoles anymore. > > > > Matt > > CCOF #1999322002 [0] > > I've seen very little attention paid to junior talent in the last few > years, and know a few people who would have been talented engineers that > never got a chance to show it. > They moved into other industries because of the lack of junior roles. > > I know very few people in network engineering that are under thirty, and > not that many under thirty five. > > > On Thu, Jun 11, 2015 at 2:01 PM, Matthew Petach > wrote: > > > On Sun, Jun 7, 2015 at 7:57 PM, Jay Ashworth wrote: > > [...] > > > > > > And this... is NANOG! > > > > Needs more ellipses and capitalization...more like > > > > > > This...IS...NANOG!!! > > > > building up to a nice crescendo roar as you kick the > > hapless interviewee backwards down the deep, dark well > > > > > > On a slightly different note, however--while it's good to > > have an appreciation of the past and how we got here, > > I think it's wise to also recognize we as an industry > > have some challenges bringing new blood in--and > > treating it too much like a sacred priesthood with > > cabalistic knowledge and initiation rites isn't going > > to help us bring new engineers into the field to > > take over for us crusty old farts when our eyes > > give out and we can't type into our 9600 baud > > serial consoles anymore. > > > > Matt > > CCOF #1999322002 [0] > > > > > > > > > > [0] Certified Crufty Old Fart > > > From russw at riw.us Thu Jun 11 11:18:24 2015 From: russw at riw.us (Russ White) Date: Thu, 11 Jun 2015 07:18:24 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> <049501d0a373$c3611370$4a233a50$@riw.us> Message-ID: <02a001d0a438$5603fc50$020bf4f0$@riw.us> > Not liking the solution is not a reason to abandon the problem. This sounds > like "I don't like eating right and exercising, so keeping my weight under > control is the wrong question" Two points. First, I did NOT say, "I don't like this." What I did say was technically precise, and, I think, perfectly clear. It's telling that the folks defending BGPSEC must immediately redirect the discussion into the side alleys of who "likes" what, and "rtfm," and "you can do this only it will cost you, so don't do that even though it's probably the right thing to do," straw man arguments, etc. Second, if you said, "If I eat one carrot a day, and I still can't keep my weight under control," you have some other problem than not being able to control your eating, and you might want to check into it a bit with a doctor. BGPSEC can eat one carrot a day and it's still too fat, IMHO -- it has a very high cost for some gain, counterbalanced by a slate of new risks and problems that must be solved. Again -- the ROI just isn't there. > All protocols rely on certain assumptions of what the fields mean - when you > send them and when you receive them. Analyzing a protocol for > vulnerabilities starts with identifying what happens if those assumptions are > broken. (Like the assumption in IP that the source address is the node that > sent the packet - spoofing breaks that assumption.) Breaking the semantics > creates attacks. Sorry, Sandy, but this is a narrow view of security. The question is -- "what information is being transmitted, and how can it be validated (once you've actually defined validated?" One possible answer is, "by making certain the protocol's semantics are being followed." There are other possible answers to that questions, however. When your first attempt doesn't meet ROI, you don't ask the same questions -- you go back to the original requirements to see if you asked the right questions in the first place. To do anything else will quickly resolve to the insanity pattern. Russ From russw at riw.us Thu Jun 11 11:30:01 2015 From: russw at riw.us (Russ White) Date: Thu, 11 Jun 2015 07:30:01 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <63A98784-80C5-4A76-976E-47E480294C03@tislabs.com> References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> <049501d0a373$c3611370$4a233a50$@riw.us> <061c01d0a37f$d24844b0$76d8ce10$@riw.us> <63A98784-80C5-4A76-976E-47E480294C03@tislabs.com> Message-ID: <02ac01d0a439$f5689f70$e039de50$@riw.us> > There have been suggestions that a key-per-AS is easier to manage than a > key-per-router, like in provisioning. Two points -- First, if a single person with console access leaves the company, I must roll the key for all my BGP routes, with the attendant churn, etc. I can't imagine anyone deploying such a thing. Second, a secret only remains secret if two people know it, and one of them is dead -- a basic rule of security is prevent the spread of knowledge. If every person in the organization with console access knows the private key for every router in the network, it's no longer secret. So you can have one key pair per AS, and risk your security. Or you can add more key pairs, either per router, per POP, per region, or at some other level of granularity, and advertise more information about your network as well as make the key pair database larger. Either you weaken your security in one way, or you weaken your security in another. Doesn't sound like much of a "tradeoff" to me. What astounds me is the quietness on this list about this stuff... :-) Russ From mark.tinka at seacom.mu Thu Jun 11 12:24:13 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 11 Jun 2015 14:24:13 +0200 Subject: Quagga IS-IS (Re: Looking for information on IGP choices in dual-stack networks) In-Reply-To: References: <557702BA.2070004@jvknet.com> <557770E0.7060105@bogus.com> <5579309A.9000500@seacom.mu> Message-ID: <55797DED.2020903@seacom.mu> On 11/Jun/15 10:33, Mikael Abrahamsson wrote: > > > Quagga's IS-IS will get a lot better in the fall because funding has > been provided to fix things important to IETF HOMENET working group > requirements for IGP. > > This will not fix things across the entire Quagga IS-IS code base, but > things should be substantially improved. If you're interested in > improving it further than that, do send some money to people capable > of doing the work, and have them do it. > > Contact me off-list if you want more information. Thanks, Mikael. Happy to support the development of IS-IS in Quagga. Will unicast you for more details. Mark. From ruairi.carroll at gmail.com Thu Jun 11 12:24:31 2015 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Thu, 11 Jun 2015 14:24:31 +0200 Subject: eBay is looking for network heavies... In-Reply-To: References: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> Message-ID: On 11 June 2015 at 06:46, Alex White-Robinson wrote: > Matthew Petach wrote: > > > On a slightly different note, however--while it's good to > > have an appreciation of the past and how we got here, > > I think it's wise to also recognize we as an industry > > have some challenges bringing new blood in--and > > treating it too much like a sacred priesthood with > > cabalistic knowledge and initiation rites isn't going > > to help us bring new engineers into the field to > > take over for us crusty old farts when our eyes > > give out and we can't type into our 9600 baud > > serial consoles anymore. > > > > Matt > > CCOF #1999322002 [0] > > I've seen very little attention paid to junior talent in the last few > years, and know a few people who would have been talented engineers that > never got a chance to show it. > They moved into other industries because of the lack of junior roles. > > I know very few people in network engineering that are under thirty, and > not that many under thirty five. > > As someone who is under 35, this comment strikes a chord with me. I started self-studying networking when I was 15ish, yet I had to wait until I was 26 before I could get a full time job in the industry. I even had to move out of my home country. Getting a solid start in the industry was exceptionally hard, and I see no difference now. What I found is that back in early-mid 00's, the industry was a black box. Unless you knew someone inside of the industry, it was quite impossible to get clear career advice on how to a) get an entry level (support) job and b) how to move out of the entry level into an engineering position. We still suffer this lack of clarity, and it's *hurting* us. We should ask ourselves when is the last time we provided career advice to someone who was under 20, and strive to help more teenagers onto the networking path. Someone once suggested that we go back to our high schools and talk to the kids about a career in IT to help give them insight into what we do, and hopefully win over more mind share. /me goes back to being a hip youngster > > On Thu, Jun 11, 2015 at 2:01 PM, Matthew Petach > wrote: > > > On Sun, Jun 7, 2015 at 7:57 PM, Jay Ashworth wrote: > > [...] > > > > > > And this... is NANOG! > > > > Needs more ellipses and capitalization...more like > > > > > > This...IS...NANOG!!! > > > > building up to a nice crescendo roar as you kick the > > hapless interviewee backwards down the deep, dark well > > > > > > On a slightly different note, however--while it's good to > > have an appreciation of the past and how we got here, > > I think it's wise to also recognize we as an industry > > have some challenges bringing new blood in--and > > treating it too much like a sacred priesthood with > > cabalistic knowledge and initiation rites isn't going > > to help us bring new engineers into the field to > > take over for us crusty old farts when our eyes > > give out and we can't type into our 9600 baud > > serial consoles anymore. > > > > Matt > > CCOF #1999322002 [0] > > > > > > > > > > [0] Certified Crufty Old Fart > > > > From wwaites at tardis.ed.ac.uk Thu Jun 11 12:53:26 2015 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Thu, 11 Jun 2015 13:53:26 +0100 (BST) Subject: eBay is looking for network heavies... In-Reply-To: References: Message-ID: <20150611.135326.42345739368595744.wwaites@tardis.ed.ac.uk> On Thu, 11 Jun 2015 14:24:31 +0200, Ruairi Carroll said: > What I found is that back in early-mid 00's, the industry was a > black box. Unless you knew someone inside of the industry... I suspect this is partly a result of the consolidation that went on. In the mid 1990s when I started, there were tons of small mom and pop ISPs with 28.8 modems stacked on Ikea shelving. The way that I got my first job as a student was literally by hanging around one of them and pestering them until they hired me part time. These small ISPs grew and most were eventually were acquired and people who stuck around through that -- especially the often quite complicated network integration that happens after acquisitions -- learned quite a lot about how the Internet operates at a variety of scales and saw a variety of different architectures and technical strategies. The scale and stability of today's Internet means that path is mostly closed now I think, particularly if what you want to do is get a job at a big company. But not entirely, there are still lots of rich field-learning opportunities on the periphery, in places where large carriers fear to tread... -w -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From rps at maine.edu Thu Jun 11 13:37:08 2015 From: rps at maine.edu (Ray Soucy) Date: Thu, 11 Jun 2015 09:37:08 -0400 Subject: eBay is looking for network heavies... In-Reply-To: <20150611.135326.42345739368595744.wwaites@tardis.ed.ac.uk> References: <20150611.135326.42345739368595744.wwaites@tardis.ed.ac.uk> Message-ID: I really wonder how people get into this field today. It has gotten incredibly complex and I've been learning since before I was a teenager (back when it was much more simple). I'm 31 now, but I started getting into computers and specifically networking at a very young age (elementary school). We had a pair of teachers that were enthusiasts and built up a computer lab with everything on token ring running Novell. I thought the fact that I could change to a different PC by driver letter in DOS was the most amazing thing I had ever seen in the 3rd grade. From there I was really hooked, got really into BBSing, and when the first dial-up ISPs started popping up I made it a point to get a job with them. My school district didn't offer a technical program for Internetworking but they had a technical school that competed in the SkillsUSA competitions and approached me about competing in the Internetworking event, without any education or mentor I won the gold medal at the State level both years I competed and went on to the nationals (where that lack of guidance and access to equipment to train on meant I got my slice of humble pie). I held my own, but the guys who won at the national level were just so much more prepared. Despite the stigma of SkillsUSA being trades focused, the Internetworking competition was a really great experience that mixed physical networking and basically a CCNA level of theory (they actually used an old copy of the CCNA as the exam). During this same time I got a paid internship for the local hospital and rebuilt their entire network after seeing the nightmare it was (they had the AS400 with all their healthcare data sitting on a public IP address with no firewall and default QSECOFR credentials sitting there for the taking with 5020 over IP enabled). It was pretty crazy for a high school student to be doing a full redesign of a network for a healthcare provider, even building frame-relay links between facilities and convincing the local cable company to provide dark fiber between a few. When I went to university I made it a point to get student employment with the NOC they ran to provide all of the public schools and libraries in the state with their Internet access, and that evolved into a full time job for them within a few years. Looking back, it's been like a perfect storm of opportunity that I just don't think exists today. I'm really happy I was born when I was and able to have a front row seat to see the explosion of the Internet. I don't know if I'm just getting "old" but I feel like technology has gotten so easy for young people that most of them have no idea how it works, and no desire to know. When we interview for new people, especially fresh out of school, its really disappointing when I hear them start to talk about a /24 as a "class C" and go on to find out the extent of their understanding ends at a textbook that is 20 years out of date. When I ask if they use Linux and they respond yes, I start getting into the details and learn they don't even know the basics on the CLI like being able to find and kill a process (thanks, Ubuntu). I think it's a big part of why the industry finds so little value in a degree vs. experience. That said, there are schools with dedicated networking programs that have really impressed me. RIT is the first that comes to mind. On Thu, Jun 11, 2015 at 8:53 AM, William Waites wrote: > On Thu, 11 Jun 2015 14:24:31 +0200, Ruairi Carroll < > ruairi.carroll at gmail.com> said: > > > What I found is that back in early-mid 00's, the industry was a > > black box. Unless you knew someone inside of the industry... > > I suspect this is partly a result of the consolidation that went > on. In the mid 1990s when I started, there were tons of small mom and > pop ISPs with 28.8 modems stacked on Ikea shelving. The way that I got > my first job as a student was literally by hanging around one of them > and pestering them until they hired me part time. These small ISPs > grew and most were eventually were acquired and people who stuck > around through that -- especially the often quite complicated network > integration that happens after acquisitions -- learned quite a lot > about how the Internet operates at a variety of scales and saw a > variety of different architectures and technical strategies. > > The scale and stability of today's Internet means that path is mostly > closed now I think, particularly if what you want to do is get a job > at a big company. But not entirely, there are still lots of rich > field-learning opportunities on the periphery, in places where large > carriers fear to tread... > > -w > -- 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 cb.list6 at gmail.com Thu Jun 11 13:45:00 2015 From: cb.list6 at gmail.com (Ca By) Date: Thu, 11 Jun 2015 06:45:00 -0700 Subject: eBay is looking for network heavies... In-Reply-To: References: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> Message-ID: On Wednesday, June 10, 2015, Alex White-Robinson wrote: > Matthew Petach > wrote: > > > On a slightly different note, however--while it's good to > > have an appreciation of the past and how we got here, > > I think it's wise to also recognize we as an industry > > have some challenges bringing new blood in--and > > treating it too much like a sacred priesthood with > > cabalistic knowledge and initiation rites isn't going > > to help us bring new engineers into the field to > > take over for us crusty old farts when our eyes > > give out and we can't type into our 9600 baud > > serial consoles anymore. > > > > Matt > > CCOF #1999322002 [0] > > I've seen very little attention paid to junior talent in the last few > years, and know a few people who would have been talented engineers that > never got a chance to show it. > They moved into other industries because of the lack of junior roles. > > I know very few people in network engineering that are under thirty, and > not that many under thirty five. > > My unscientific impression is that 90% of the neteng jobs are for senior engineers on indeed.com with north of 5 years experience. Going back to the OP, looking for network heavies..... How do you get heavies if you don't grow a bench? My $dayjob open reqs are definately all sr eng or above. We have a decent internship program, but far from sufficient to grow a bench > On Thu, Jun 11, 2015 at 2:01 PM, Matthew Petach > > wrote: > > > On Sun, Jun 7, 2015 at 7:57 PM, Jay Ashworth > wrote: > > [...] > > > > > > And this... is NANOG! > > > > Needs more ellipses and capitalization...more like > > > > > > This...IS...NANOG!!! > > > > building up to a nice crescendo roar as you kick the > > hapless interviewee backwards down the deep, dark well > > > > > > On a slightly different note, however--while it's good to > > have an appreciation of the past and how we got here, > > I think it's wise to also recognize we as an industry > > have some challenges bringing new blood in--and > > treating it too much like a sacred priesthood with > > cabalistic knowledge and initiation rites isn't going > > to help us bring new engineers into the field to > > take over for us crusty old farts when our eyes > > give out and we can't type into our 9600 baud > > serial consoles anymore. > > > > Matt > > CCOF #1999322002 [0] > > > > > > > > > > [0] Certified Crufty Old Fart > > > From bob at FiberInternetCenter.com Thu Jun 11 14:19:45 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Thu, 11 Jun 2015 07:19:45 -0700 Subject: Greenfield 464XLAT (In January) In-Reply-To: References: Message-ID: Actually , there is no better audience that I know of to ask this question. And my information might be more marketing related and hardware skeptical. My IPv6 direction choice was much easier than yours. You need to figure out how to build an IPv4 network today from scratch in a world where the IPv4 bus ride seats have largely assigned. When we setup our IPv6 ability, I chose to build a native IPv6 network. Tunneling and translation devices left me wondering about packet flow at those gateway points. Aside from verbal sales assurances, I still had the feeling that under loads these devices would break momentarily or cause latency issues. For web and email services it's not a big issue. Sure everyone could show me a twitch game playing well or a video conference call, but what happens when the device is under load or attacked ? Will service latency be detected by a cleaver well known gamer ? One that points to the issue as a flaw that makes others think our network is unusable for all kinds of services ? Overcome issues like "this ISP forces you to use IPv6" ? The hardware costs can be small compared to consumer perceptions marketing dollars. So you might position to pitch upfront your new world Internet service from day one. European and Comcast has been implementing NAT 6 related things for years. My son made me move his connection to the smallest bandwidth DSL on ATT for his games. However, our Comcast has been fine perfectly for watching Amazon and Netflix streaming (most of the time). Thank You Bob Evans CTO > Sincere apologies if this e-mail is inappropriate for this audience, > We are (going to be) a startup ISP building a new network from the ground > up. I was hoping I could get an opinion, or two, on how everyone feels > about 464XLAT. I saw what everyone was saying about it in the 'Android > doesn't support DHCPv6' discussion, but what about in the wireline side of > things? The main reason we are even considering 464XLAT as opposed to > dual-stack (the latter is, in my ignorant opinion, the better option.) is > the fear of IPv4 depletion that we think might hit ARIN between now and > the start of next year; causing us to pay a premium for IPv4 in the gray > market. So I guess the real question here would be: is our fear real, or > is it just bug on the wall? If our fear is real, what should we implement > so that our users can still get to the v4 internet, are we even thinking > soberly by suggesting 464XLAT? > Thanks, > - Nich > > From Steve.Mikulasik at civeo.com Thu Jun 11 14:27:57 2015 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Thu, 11 Jun 2015 14:27:57 +0000 Subject: eBay is looking for network heavies... In-Reply-To: References: <20150611.135326.42345739368595744.wwaites@tardis.ed.ac.uk> Message-ID: 25 year old neteng reporting in. I got into networking when I wanted to play Quake against my brother and trying to share a single dial-up connection between all the computers in the house. Well I still have a long way to go (employed full time in IT for just over 6 years), I think I am ahead of most IT pros in my age group. At the end of the day us young kids learned the same way most of you did, bit of education, and the vast majority from experience. I am at the point know where my self-education skills are effective enough that I can learn whatever I don't know and solve most any problem I come across. From what others have said, I think this is the key to success in this field, although I think this is a skill you develop early in life or you never get it. I am now trying to learn the things I didn't know I needed to know to solve problems I didn't know existed. I do agree there isn't a big interest from youth in this field. A lot of people get introduced to networking through education and never develop a passion for it. When they graduate they choose IT areas more interesting to themselves. Most schools are teaching recycled CCNA curriculum and/or thinking from the early 90s. Can't blame anyone who hasn't developed a passion for networking outside of education for not entering the field. Memorizing what an Ethernet frame looks like doesn't build an appreciation for networking, unless you can see the bigger picture. Steve Mikulasik -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ray Soucy Sent: Thursday, June 11, 2015 7:37 AM To: William Waites Cc: NANOG Subject: Re: eBay is looking for network heavies... I really wonder how people get into this field today. It has gotten incredibly complex and I've been learning since before I was a teenager (back when it was much more simple). I'm 31 now, but I started getting into computers and specifically networking at a very young age (elementary school). We had a pair of teachers that were enthusiasts and built up a computer lab with everything on token ring running Novell. I thought the fact that I could change to a different PC by driver letter in DOS was the most amazing thing I had ever seen in the 3rd grade. From there I was really hooked, got really into BBSing, and when the first dial-up ISPs started popping up I made it a point to get a job with them. My school district didn't offer a technical program for Internetworking but they had a technical school that competed in the SkillsUSA competitions and approached me about competing in the Internetworking event, without any education or mentor I won the gold medal at the State level both years I competed and went on to the nationals (where that lack of guidance and access to equipment to train on meant I got my slice of humble pie). I held my own, but the guys who won at the national level were just so much more prepared. Despite the stigma of SkillsUSA being trades focused, the Internetworking competition was a really great experience that mixed physical networking and basically a CCNA level of theory (they actually used an old copy of the CCNA as the exam). During this same time I got a paid internship for the local hospital and rebuilt their entire network after seeing the nightmare it was (they had the AS400 with all their healthcare data sitting on a public IP address with no firewall and default QSECOFR credentials sitting there for the taking with 5020 over IP enabled). It was pretty crazy for a high school student to be doing a full redesign of a network for a healthcare provider, even building frame-relay links between facilities and convincing the local cable company to provide dark fiber between a few. When I went to university I made it a point to get student employment with the NOC they ran to provide all of the public schools and libraries in the state with their Internet access, and that evolved into a full time job for them within a few years. Looking back, it's been like a perfect storm of opportunity that I just don't think exists today. I'm really happy I was born when I was and able to have a front row seat to see the explosion of the Internet. I don't know if I'm just getting "old" but I feel like technology has gotten so easy for young people that most of them have no idea how it works, and no desire to know. When we interview for new people, especially fresh out of school, its really disappointing when I hear them start to talk about a /24 as a "class C" and go on to find out the extent of their understanding ends at a textbook that is 20 years out of date. When I ask if they use Linux and they respond yes, I start getting into the details and learn they don't even know the basics on the CLI like being able to find and kill a process (thanks, Ubuntu). I think it's a big part of why the industry finds so little value in a degree vs. experience. That said, there are schools with dedicated networking programs that have really impressed me. RIT is the first that comes to mind. On Thu, Jun 11, 2015 at 8:53 AM, William Waites wrote: > On Thu, 11 Jun 2015 14:24:31 +0200, Ruairi Carroll < > ruairi.carroll at gmail.com> said: > > > What I found is that back in early-mid 00's, the industry was a > > black box. Unless you knew someone inside of the industry... > > I suspect this is partly a result of the consolidation that went on. > In the mid 1990s when I started, there were tons of small mom and pop > ISPs with 28.8 modems stacked on Ikea shelving. The way that I got my > first job as a student was literally by hanging around one of them and > pestering them until they hired me part time. These small ISPs grew > and most were eventually were acquired and people who stuck around > through that -- especially the often quite complicated network > integration that happens after acquisitions -- learned quite a lot > about how the Internet operates at a variety of scales and saw a > variety of different architectures and technical strategies. > > The scale and stability of today's Internet means that path is mostly > closed now I think, particularly if what you want to do is get a job > at a big company. But not entirely, there are still lots of rich > field-learning opportunities on the periphery, in places where large > carriers fear to tread... > > -w > -- 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 mohta at necom830.hpcl.titech.ac.jp Thu Jun 11 14:31:15 2015 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 11 Jun 2015 23:31:15 +0900 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <55793DFA.2060502@necom830.hpcl.titech.ac.jp> References: <5578A933.8090504@dougbarton.us> <99685.1433977139@turing-police.cc.vt.edu> <55793DFA.2060502@necom830.hpcl.titech.ac.jp> Message-ID: <55799BB3.4040605@necom830.hpcl.titech.ac.jp> I wrote: > Valdis.Kletnieks at vt.edu wrote: > >> It only "just works" if your upstream device doesn't check/care that >> you're emitting multiple MAC addresses from the same device. > > What if a Wifi router checks that a device authenticated by a > student's account uses only one IPv4, one IPv6 and one MAC > addresses? > > Can tethering still work? I missed another condition. That is, the student's account can be used to authenticate Wifi access for his/her device (not multiple devices) but nothing else. Is it a so unrealistic restriction? Masataka Ohta From ag4ve.us at gmail.com Thu Jun 11 14:47:16 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 11 Jun 2015 10:47:16 -0400 Subject: eBay is looking for network heavies... In-Reply-To: References: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 11, 2015 7:07 AM, "jim deleskie" wrote: > > There is a good reason there aren't LOTS of "good" neteng in the 30-35 or > under 30 range with lots of experience. Its call the hell we went though > for a while after 2000 working in this industry. Many of us lost jobs and > couldn't find new ones. I know talented folks that had to go to delivering > pizzas ( not to slag pizza delivery folks) to support themselves and their > families. Some folks ended up leaving the industry because of it and I'm > "sure" lots of people choose to no get into the field seeing no jobs. This > type of event causes a whole that takes a long time correct. > So I'm at your early 30s mark too. I've read all y'all on getting in by helping grow the internet and not thinking these things still exist. Two thoughts: 1. Heard of IPv6? Wasn't made just to keep us employed. 2. I'd give anything to have replaced my Encarda (sp?) cd with Wikipedia in middle school. I'd have killed to replace my Motorola with an android or iPhone in high school. To not have a heavy ass bag of books hurting my hand and just grip my kindle. And to have had the ability to hook up a phone line to the 8088 or apple // in elementary school would've been awesome. I'm sure if you look you'll find similar conversations years earlier about "I got in by helping lay the groundwork for Unix/C/DARPANet. IDK what future generations will do to get a job at my level." You aren't the smartest person on the net and not the only person with luck to be in the right place. I hear about teachers using Wikipedia and podcasts as teaching aids and I think "they wouldn't even let me cite Wikipedia in college". Feel sorry for people if you want - I'll help people if I can but never do I think I had it better. From rafael at gav.ufsc.br Thu Jun 11 14:55:41 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Thu, 11 Jun 2015 09:55:41 -0500 Subject: eBay is looking for network heavies... In-Reply-To: References: <20150611.135326.42345739368595744.wwaites@tardis.ed.ac.uk> Message-ID: +1 for experience.. being able to teach yourself just about anything drops you into the top 20% of any industry (with maybe a few exceptions). one thing I noticed is that the best professionals I met out there are just as good with people as they are with routers and console screens. IT is usually just a cost center (unless you work for a tech company), so if you learn how to navigate office politics and push change, then you will have a spot with the packet wrangling Gods. On Thu, Jun 11, 2015 at 9:27 AM, Steve Mikulasik wrote: > 25 year old neteng reporting in. I got into networking when I wanted to > play Quake against my brother and trying to share a single dial-up > connection between all the computers in the house. > > Well I still have a long way to go (employed full time in IT for just over > 6 years), I think I am ahead of most IT pros in my age group. At the end of > the day us young kids learned the same way most of you did, bit of > education, and the vast majority from experience. > > I am at the point know where my self-education skills are effective enough > that I can learn whatever I don't know and solve most any problem I come > across. From what others have said, I think this is the key to success in > this field, although I think this is a skill you develop early in life or > you never get it. I am now trying to learn the things I didn't know I > needed to know to solve problems I didn't know existed. > > I do agree there isn't a big interest from youth in this field. A lot of > people get introduced to networking through education and never develop a > passion for it. When they graduate they choose IT areas more interesting to > themselves. Most schools are teaching recycled CCNA curriculum and/or > thinking from the early 90s. Can't blame anyone who hasn't developed a > passion for networking outside of education for not entering the field. > Memorizing what an Ethernet frame looks like doesn't build an appreciation > for networking, unless you can see the bigger picture. > > Steve Mikulasik > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ray Soucy > Sent: Thursday, June 11, 2015 7:37 AM > To: William Waites > Cc: NANOG > Subject: Re: eBay is looking for network heavies... > > I really wonder how people get into this field today. It has gotten > incredibly complex and I've been learning since before I was a teenager > (back when it was much more simple). > > I'm 31 now, but I started getting into computers and specifically > networking at a very young age (elementary school). We had a pair of > teachers that were enthusiasts and built up a computer lab with everything > on token ring running Novell. I thought the fact that I could change to a > different PC by driver letter in DOS was the most amazing thing I had ever > seen in the 3rd grade. From there I was really hooked, got really into > BBSing, and when the first dial-up ISPs started popping up I made it a > point to get a job with them. > > My school district didn't offer a technical program for Internetworking > but they had a technical school that competed in the SkillsUSA competitions > and approached me about competing in the Internetworking event, without any > education or mentor I won the gold medal at the State level both years I > competed and went on to the nationals (where that lack of guidance and > access to equipment to train on meant I got my slice of humble pie). I > held my own, but the guys who won at the national level were just so much > more prepared. Despite the stigma of SkillsUSA being trades focused, the > Internetworking competition was a really great experience that mixed > physical networking and basically a CCNA level of theory (they actually > used an old copy of the CCNA as the exam). > > During this same time I got a paid internship for the local hospital and > rebuilt their entire network after seeing the nightmare it was (they had > the AS400 with all their healthcare data sitting on a public IP address > with no firewall and default QSECOFR credentials sitting there for the > taking with 5020 over IP enabled). It was pretty crazy for a high school > student to be doing a full redesign of a network for a healthcare provider, > even building frame-relay links between facilities and convincing the local > cable company to provide dark fiber between a few. > > When I went to university I made it a point to get student employment with > the NOC they ran to provide all of the public schools and libraries in the > state with their Internet access, and that evolved into a full time job for > them within a few years. > > Looking back, it's been like a perfect storm of opportunity that I just > don't think exists today. I'm really happy I was born when I was and able > to have a front row seat to see the explosion of the Internet. I don't > know if I'm just getting "old" but I feel like technology has gotten so > easy for young people that most of them have no idea how it works, and no > desire to know. > > When we interview for new people, especially fresh out of school, its > really disappointing when I hear them start to talk about a /24 as a "class > C" and go on to find out the extent of their understanding ends at a > textbook that is 20 years out of date. When I ask if they use Linux and > they respond yes, I start getting into the details and learn they don't > even know the basics on the CLI like being able to find and kill a process > (thanks, Ubuntu). I think it's a big part of why the industry finds so > little value in a degree vs. experience. > > That said, there are schools with dedicated networking programs that have > really impressed me. RIT is the first that comes to mind. > > > > > > On Thu, Jun 11, 2015 at 8:53 AM, William Waites > wrote: > > > On Thu, 11 Jun 2015 14:24:31 +0200, Ruairi Carroll < > > ruairi.carroll at gmail.com> said: > > > > > What I found is that back in early-mid 00's, the industry was a > > > black box. Unless you knew someone inside of the industry... > > > > I suspect this is partly a result of the consolidation that went on. > > In the mid 1990s when I started, there were tons of small mom and pop > > ISPs with 28.8 modems stacked on Ikea shelving. The way that I got my > > first job as a student was literally by hanging around one of them and > > pestering them until they hired me part time. These small ISPs grew > > and most were eventually were acquired and people who stuck around > > through that -- especially the often quite complicated network > > integration that happens after acquisitions -- learned quite a lot > > about how the Internet operates at a variety of scales and saw a > > variety of different architectures and technical strategies. > > > > The scale and stability of today's Internet means that path is mostly > > closed now I think, particularly if what you want to do is get a job > > at a big company. But not entirely, there are still lots of rich > > field-learning opportunities on the periphery, in places where large > > carriers fear to tread... > > > > -w > > > > > > -- > 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 nwarren at barryelectric.com Thu Jun 11 15:06:40 2015 From: nwarren at barryelectric.com (Nicholas Warren) Date: Thu, 11 Jun 2015 15:06:40 +0000 Subject: Greenfield 464XLAT (In January) In-Reply-To: References: Message-ID: A network needs users or it is useless. I am curious as to how your native IPv6 network communicated with (if at all) the v4 world. Has anyone confronted you about your network being IPv6? I might have problems with reading comprehension, but in your statement " So you might position to pitch upfront your new world Internet service from day one.", do you mean pitch as in, setup; or pitch as, into the trash. Thank you, - Nich Warren -----Original Message----- From: Bob Evans [mailto:bob at FiberInternetCenter.com] Sent: Thursday, June 11, 2015 9:20 AM To: Nicholas Warren Cc: nanog at nanog.org Subject: Re: Greenfield 464XLAT (In January) Actually , there is no better audience that I know of to ask this question. And my information might be more marketing related and hardware skeptical. My IPv6 direction choice was much easier than yours. You need to figure out how to build an IPv4 network today from scratch in a world where the IPv4 bus ride seats have largely assigned. When we setup our IPv6 ability, I chose to build a native IPv6 network. Tunneling and translation devices left me wondering about packet flow at those gateway points. Aside from verbal sales assurances, I still had the feeling that under loads these devices would break momentarily or cause latency issues. For web and email services it's not a big issue. Sure everyone could show me a twitch game playing well or a video conference call, but what happens when the device is under load or attacked ? Will service latency be detected by a cleaver well known gamer ? One that points to the issue as a flaw that makes others think our network is unusable for all kinds of services ? Overcome issues like "this ISP forces you to use IPv6" ? The hardware costs can be small compared to consumer perceptions marketing dollars. So you might position to pitch upfront your new world Internet service from day one. European and Comcast has been implementing NAT 6 related things for years. My son made me move his connection to the smallest bandwidth DSL on ATT for his games. However, our Comcast has been fine perfectly for watching Amazon and Netflix streaming (most of the time). Thank You Bob Evans CTO > Sincere apologies if this e-mail is inappropriate for this audience, > We are (going to be) a startup ISP building a new network from the ground > up. I was hoping I could get an opinion, or two, on how everyone feels > about 464XLAT. I saw what everyone was saying about it in the 'Android > doesn't support DHCPv6' discussion, but what about in the wireline side of > things? The main reason we are even considering 464XLAT as opposed to > dual-stack (the latter is, in my ignorant opinion, the better option.) is > the fear of IPv4 depletion that we think might hit ARIN between now and > the start of next year; causing us to pay a premium for IPv4 in the gray > market. So I guess the real question here would be: is our fear real, or > is it just bug on the wall? If our fear is real, what should we implement > so that our users can still get to the v4 internet, are we even thinking > soberly by suggesting 464XLAT? > Thanks, > - Nich > > From charles at thefnf.org Thu Jun 11 15:17:12 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Thu, 11 Jun 2015 10:17:12 -0500 Subject: eBay is looking for network heavies... In-Reply-To: References: <3741358.6.1433732249350.JavaMail.root@benjamin.baylink.com> Message-ID: >> > As someone who is under 35, this comment strikes a chord with me. I > started > self-studying networking when I was 15ish, yet I had to wait until I > was 26 > before I could get a full time job in the industry. I even had to move > out > of my home country. Getting a solid start in the industry was > exceptionally > hard, and I see no difference now. > > What I found is that back in early-mid 00's, the industry was a black > box. > Unless you knew someone inside of the industry, it was quite impossible > to > get clear career advice on how to a) get an entry level (support) job > and > b) how to move out of the entry level into an engineering position. We > still suffer this lack of clarity, and it's *hurting* us. We should ask > ourselves when is the last time we provided career advice to someone > who > was under 20, and strive to help more teenagers onto the networking > path. > Someone once suggested that we go back to our high schools and talk to > the > kids about a career in IT to help give them insight into what we do, > and > hopefully win over more mind share. Yes. This. Absolutely. I roped my wifes 9 year old nephew off his iPAD last night and had him help me cable up my home lab (which is currently at 3 racks, started at as an 1841/2924 in 2008.) He loved it. I was able to teach him all about layer 1. That's how I started (at the bottom as a gopher, pulling cables, racking gear and very hands on building out systems and networks). It helps to have passion/great attitude. That's key. I've been in the industry 15 years and am still bright eyed/bushy tailed every day (sure we all have bad days). So much to learn, to experience, to play with, to say "hey, what's this do?". The fundamentals haven't really changed, it's important to keep that in mind. To quote the magic school bus "make mistakes, get messy". (and occasionally, I knew I should of stayed home today, when the pager goes off. ) I've worked for Fox,Disney,IAC , consulted for various defense contractors, mom/pop shops. Every day at those jobs, it could span from helping a "newb" with something basic, to scaling up some of the worlds most recognized brands or defending (or crafting) highly advanced attacks. It's been fun. Now days, I do.... security. Lots and lots of security. > > /me goes back to being a hip youngster > > > >> >> On Thu, Jun 11, 2015 at 2:01 PM, Matthew Petach >> >> wrote: >> >> > On Sun, Jun 7, 2015 at 7:57 PM, Jay Ashworth wrote: >> > [...] >> > > >> > > And this... is NANOG! >> > >> > Needs more ellipses and capitalization...more like >> > >> > >> > This...IS...NANOG!!! >> > >> > building up to a nice crescendo roar as you kick the >> > hapless interviewee backwards down the deep, dark well >> > >> > >> > On a slightly different note, however--while it's good to >> > have an appreciation of the past and how we got here, >> > I think it's wise to also recognize we as an industry >> > have some challenges bringing new blood in--and >> > treating it too much like a sacred priesthood with >> > cabalistic knowledge and initiation rites isn't going >> > to help us bring new engineers into the field to >> > take over for us crusty old farts when our eyes >> > give out and we can't type into our 9600 baud >> > serial consoles anymore. >> > >> > Matt >> > CCOF #1999322002 [0] >> > >> > >> > >> > >> > [0] Certified Crufty Old Fart >> > >> >> > > !DSPAM:55797f9d282985036917588! From dave.taht at gmail.com Thu Jun 11 15:46:28 2015 From: dave.taht at gmail.com (Dave Taht) Date: Thu, 11 Jun 2015 08:46:28 -0700 Subject: Greenfield 464XLAT (In January) In-Reply-To: References: Message-ID: On Thu, Jun 11, 2015 at 7:19 AM, Bob Evans wrote: > Actually , there is no better audience that I know of to ask this > question. And my information might be more marketing related and hardware > skeptical. > > My IPv6 direction choice was much easier than yours. You need to figure > out how to build an IPv4 network today from scratch in a world where the > IPv4 bus ride seats have largely assigned. > > When we setup our IPv6 ability, I chose to build a native IPv6 network. > Tunneling and translation devices left me wondering about packet flow at > those gateway points. Aside from verbal sales assurances, I still had the > feeling that under loads these devices would break momentarily or cause > latency issues. For web and email services it's not a big issue. Sure > everyone could show me a twitch game playing well or a video conference > call, but what happens when the device is under load or attacked ? Will > service latency be detected by a cleaver well known gamer ? One that > points to the issue as a flaw that makes others think our network is > unusable for all kinds of services ? Overcome issues like "this ISP forces > you to use IPv6" ? The hardware costs can be small compared to consumer > perceptions marketing dollars. So you might position to pitch upfront your > new world Internet service from day one. > > European and Comcast has been implementing NAT 6 related things for years. > My son made me move his connection to the smallest bandwidth DSL on ATT > for his games. However, our Comcast has been fine perfectly for watching > Amazon and Netflix streaming (most of the time). I have been running across more and more and more people that are actually doing that - using two isps - one for games and voice, and the other for streaming and web. I had no idea how prevalent it was. Still don't, all my evidence is anecdotal (and it all points at bufferbloat related problems). > Thank You > Bob Evans > CTO > > > > >> Sincere apologies if this e-mail is inappropriate for this audience, >> We are (going to be) a startup ISP building a new network from the ground >> up. I was hoping I could get an opinion, or two, on how everyone feels >> about 464XLAT. I saw what everyone was saying about it in the 'Android >> doesn't support DHCPv6' discussion, but what about in the wireline side of >> things? The main reason we are even considering 464XLAT as opposed to >> dual-stack (the latter is, in my ignorant opinion, the better option.) is >> the fear of IPv4 depletion that we think might hit ARIN between now and >> the start of next year; causing us to pay a premium for IPv4 in the gray >> market. So I guess the real question here would be: is our fear real, or >> is it just bug on the wall? If our fear is real, what should we implement >> so that our users can still get to the v4 internet, are we even thinking >> soberly by suggesting 464XLAT? >> Thanks, >> - Nich I so would not want to be a new entrant in this market. When last I tried various ipv4 over ipv6 tunnelling methods (in nicaragua 2009) it was very hard to get devices that could do it at all. I think common tools I use now (like openwrt) are really far along on every possible encapsulation method, but the state of other gear still lagging. >> > > -- Dave T?ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From bruce.curtis at ndsu.edu Thu Jun 11 15:56:28 2015 From: bruce.curtis at ndsu.edu (Bruce Curtis) Date: Thu, 11 Jun 2015 15:56:28 +0000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <55799BB3.4040605@necom830.hpcl.titech.ac.jp> References: <5578A933.8090504@dougbarton.us> <99685.1433977139@turing-police.cc.vt.edu> <55793DFA.2060502@necom830.hpcl.titech.ac.jp> <55799BB3.4040605@necom830.hpcl.titech.ac.jp> Message-ID: <0812D922-DC22-4122-80A4-DD10AFB48BB1@ndsu.edu> We have had IPv6 enabled on our campus network since 2008 (including wireless). We started with SLAAC and did some experimenting with DHCPv6 PD over wireless but haven?t implemented DHCPv6 as a production service yet. I thought that one thing that might push us towards DHCPv6 was desk VoIP phones since current desk IP phones depend on learning lots of special or extra info via DHCP. Assuming that desk IP phones don?t become extinct (not a certainty) and assuming that many desk IP phones will continue to be based on Android it seems that my assumption that desk IP phones will want DHCPv6 might not be correct. So what do the prognosticators think? Will the desk IP phone vendors just add DHCPv6 to their version of Android or will they switch to other means to learn the info they now learn via DHCPv4? --- Bruce Curtis bruce.curtis at ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University From bob at FiberInternetCenter.com Thu Jun 11 16:23:22 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Thu, 11 Jun 2015 09:23:22 -0700 Subject: Greenfield 464XLAT (In January) In-Reply-To: References: Message-ID: <88aff3bf5bbec109d710ab8a81ab6a16.squirrel@66.201.44.180> I mean marketing/salesman like pitch. When you have something so new and familiarity is always the desire of the day by IT managers (hence, all the cisco only fans), it's better to be upfront and pitch it as new and improved before others decide to call it something else and choose a different network. We began with IPv4. Then many of us members at both ARIN and NANOG all agreed to push IPv6. I looked at all the methods available and decided we would build native IPv6 network and give the customer both. Soooo, the networks are separate from each other and provided to customers on via separate ports. There is no place in our network where you can hop from IPv6 to IPv4 and visa versa. The customer can install such gear in their LAN and make routing those decisions at their end. (Now years later, a very tiny percentage of customers have link on their IPv6 port.) If anyone complains, it's the customers choice of gear or routing issues at their end, as nothing in our network is NATed. Thereby, reducing our potential service labor costs of dealing with a customers understanding of trace routes in NAT space - and other similar issues that they try to make your staff's problem. Thank You Bob Evans CTO > A network needs users or it is useless. I am curious as to how your native > IPv6 network communicated with (if at all) the v4 world. Has anyone > confronted you about your network being IPv6? I might have problems with > reading comprehension, but in your statement " So you might position to > pitch upfront your new world Internet service from day one.", do you mean > pitch as in, setup; or pitch as, into the trash. > > Thank you, > - Nich Warren > > > -----Original Message----- > From: Bob Evans [mailto:bob at FiberInternetCenter.com] > Sent: Thursday, June 11, 2015 9:20 AM > To: Nicholas Warren > Cc: nanog at nanog.org > Subject: Re: Greenfield 464XLAT (In January) > > Actually , there is no better audience that I know of to ask this > question. And my information might be more marketing related and hardware > skeptical. > > My IPv6 direction choice was much easier than yours. You need to figure > out how to build an IPv4 network today from scratch in a world where the > IPv4 bus ride seats have largely assigned. > > When we setup our IPv6 ability, I chose to build a native IPv6 network. > Tunneling and translation devices left me wondering about packet flow at > those gateway points. Aside from verbal sales assurances, I still had the > feeling that under loads these devices would break momentarily or cause > latency issues. For web and email services it's not a big issue. Sure > everyone could show me a twitch game playing well or a video conference > call, but what happens when the device is under load or attacked ? Will > service latency be detected by a cleaver well known gamer ? One that > points to the issue as a flaw that makes others think our network is > unusable for all kinds of services ? Overcome issues like "this ISP forces > you to use IPv6" ? The hardware costs can be small compared to consumer > perceptions marketing dollars. So you might position to pitch upfront your > new world Internet service from day one. > > European and Comcast has been implementing NAT 6 related things for years. > My son made me move his connection to the smallest bandwidth DSL on ATT > for his games. However, our Comcast has been fine perfectly for watching > Amazon and Netflix streaming (most of the time). > > Thank You > Bob Evans > CTO > > > > >> Sincere apologies if this e-mail is inappropriate for this audience, >> We are (going to be) a startup ISP building a new network from the >> ground >> up. I was hoping I could get an opinion, or two, on how everyone feels >> about 464XLAT. I saw what everyone was saying about it in the 'Android >> doesn't support DHCPv6' discussion, but what about in the wireline side >> of >> things? The main reason we are even considering 464XLAT as opposed to >> dual-stack (the latter is, in my ignorant opinion, the better option.) >> is >> the fear of IPv4 depletion that we think might hit ARIN between now and >> the start of next year; causing us to pay a premium for IPv4 in the gray >> market. So I guess the real question here would be: is our fear real, or >> is it just bug on the wall? If our fear is real, what should we >> implement >> so that our users can still get to the v4 internet, are we even thinking >> soberly by suggesting 464XLAT? >> Thanks, >> - Nich >> >> > > > From bill at herrin.us Thu Jun 11 17:12:30 2015 From: bill at herrin.us (William Herrin) Date: Thu, 11 Jun 2015 13:12:30 -0400 Subject: Greenfield 464XLAT (In January) In-Reply-To: References: Message-ID: On Wed, Jun 10, 2015 at 4:22 PM, Nicholas Warren wrote: > Sincere apologies if this e-mail is inappropriate for this audience, Hi Nich, Looks like the correct audience to me. > We are (going to be) a startup ISP building a new network from the > ground up. [...] The main reason we are even considering 464XLAT > as opposed to dual-stack (the latter is, in my ignorant opinion, the > better option.) is the fear of IPv4 depletion that we think might hit > ARIN between now and the start of next year; causing us to pay a > premium for IPv4 in the gray market. Your customers will require end-to-end IPv4 for the foreseeable future. 464XLAT can provide natted IPv4 using an internal IPv6 infrastructure in special circumstances. Specifically: you must have sufficient control of the customer equipment to compel it to employ 464XLAT to provide IPv4 services to the customer. If your customers lease phones from you and your phone vendors build in 464XLAT support, T-Mobile has demonstrated that this is practical. If your customers bring generic Macs and PCs with the odd Linux user in the mix (their equipment, not yours), you may be asking for extensive support headaches with 464XLAT. Dual stack with carrier NAT would also handle your IPv4 needs. You'll have an additional expense maintaining both protocols within your infrastructure. Nevertheless, this approach alleviates the need to control the customer premises equipment. Regardless of your approach, DS+NAT or 464XLAT, you will require a comparable number of global IPv4 addresses. Neither technology eliminates your need for IPv4 addresses facing the public Internet. Regardless of your approach, you will need to make provisions to support customers who require a global and/or static IPv4 address without NAT. It need not be part of your basic package, but if it's unavailable at any price you can be sure of getting a PR black eye at some point. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From nwarren at barryelectric.com Thu Jun 11 17:40:59 2015 From: nwarren at barryelectric.com (Nicholas Warren) Date: Thu, 11 Jun 2015 17:40:59 +0000 Subject: Greenfield 464XLAT (In January) In-Reply-To: References: Message-ID: I figured that duel-stack would be the way to go, but I worry that ARIN might not give us space for duel stack out of their reserved pool (https://www.arin.net/policy/nrpm.html#four10), and that this .13 of a /8 won't make it to next year. I suppose that would be a question for the ARIN mailing list? Thank you, - Nich Warren -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Thursday, June 11, 2015 12:13 PM To: Nicholas Warren Cc: nanog at nanog.org Subject: Re: Greenfield 464XLAT (In January) On Wed, Jun 10, 2015 at 4:22 PM, Nicholas Warren wrote: > Sincere apologies if this e-mail is inappropriate for this audience, Hi Nich, Looks like the correct audience to me. > We are (going to be) a startup ISP building a new network from the > ground up. [...] The main reason we are even considering 464XLAT as > opposed to dual-stack (the latter is, in my ignorant opinion, the > better option.) is the fear of IPv4 depletion that we think might hit > ARIN between now and the start of next year; causing us to pay a > premium for IPv4 in the gray market. Your customers will require end-to-end IPv4 for the foreseeable future. 464XLAT can provide natted IPv4 using an internal IPv6 infrastructure in special circumstances. Specifically: you must have sufficient control of the customer equipment to compel it to employ 464XLAT to provide IPv4 services to the customer. If your customers lease phones from you and your phone vendors build in 464XLAT support, T-Mobile has demonstrated that this is practical. If your customers bring generic Macs and PCs with the odd Linux user in the mix (their equipment, not yours), you may be asking for extensive support headaches with 464XLAT. Dual stack with carrier NAT would also handle your IPv4 needs. You'll have an additional expense maintaining both protocols within your infrastructure. Nevertheless, this approach alleviates the need to control the customer premises equipment. Regardless of your approach, DS+NAT or 464XLAT, you will require a comparable number of global IPv4 addresses. Neither technology eliminates your need for IPv4 addresses facing the public Internet. Regardless of your approach, you will need to make provisions to support customers who require a global and/or static IPv4 address without NAT. It need not be part of your basic package, but if it's unavailable at any price you can be sure of getting a PR black eye at some point. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bill at herrin.us Thu Jun 11 18:16:30 2015 From: bill at herrin.us (William Herrin) Date: Thu, 11 Jun 2015 14:16:30 -0400 Subject: Greenfield 464XLAT (In January) In-Reply-To: References: Message-ID: On Thu, Jun 11, 2015 at 1:40 PM, Nicholas Warren wrote: > I figured that duel-stack would be the way to go, but I worry that ARIN might not give us space for duel stack out of their reserved pool (https://www.arin.net/policy/nrpm.html#four10), and that this .13 of a /8 won't make it to next year. Hi Nich, The absolute most you can get out of that pool is a /24. The same amount as a regular allocation at current gray market prices would only cost $2500-$5000 (see e.g. http://www.ipv4auctions.com/). There have been enough directed transfers at this point to expect the process to go smoothly, though you might want to contract someone to help walk you through it if you haven't extensively worked with ARIN in the past. There are some fiddly bits with needs assessments and the like where you want to make sure the words you're saying are the ones ARIN staff expects to hear. It can be tough to walk it back if you say the wrong thing the first time. >From reading the ARIN PPML, I understand that the 4.10 pool is largely untouched due to confusion (staff and registrant) on what does and doesn't qualify. The regular free pool (not the 4.10 pool) is on its last dregs and will not likely have any addresses come January. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From david at mandelberg.org Thu Jun 11 19:10:22 2015 From: david at mandelberg.org (David Mandelberg) Date: Thu, 11 Jun 2015 15:10:22 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: <02ac01d0a439$f5689f70$e039de50$@riw.us> References: "\"<17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net>" <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org>" <049501d0a373$c3611370$4a233a50$@riw.us> <061c01d0a37f$d24844b0$76d8ce10$@riw.us> <63A98784-80C5-4A76-976E-47E480294C03@tislabs.com> <02ac01d0a439$f5689f70$e039de50$@riw.us> Message-ID: On 2015-06-11 07:30, Russ White wrote: >> There have been suggestions that a key-per-AS is easier to manage >> than a >> key-per-router, like in provisioning. > > Two points -- > > First, if a single person with console access leaves the company, I > must > roll the key for all my BGP routes, with the attendant churn, etc. I > can't > imagine anyone deploying such a thing. I assume the vast majority of these cases are when the person leaves with no indication of malicious intent. In those cases, it might be possible to perform the key rollover with a relatively long grace period in which both keys are valid. Wouldn't that help reduce churn? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From morrowc.lists at gmail.com Thu Jun 11 19:19:09 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 11 Jun 2015 15:19:09 -0400 Subject: Routing Insecurity (Re: BGP in the Washington Post) In-Reply-To: References: <17689457.2434.1433171075960.JavaMail.mhammett@ThunderFuck> <556C785C.2040807@seacom.mu> <20150602040707.382092FCB844@rock.dv.isc.org> <7B872CEF-2A5C-4DCD-A384-17AA8EE9BBEC@arbor.net> <20150602151233.GA29050@DOIT-2NW1MRFY-X.doit.wisc.edu> <55711DD1.8040906@mandelberg.org> <9188268B-59C4-4FA8-9CA4-3C514CF2625B@arbor.net> <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org> <049501d0a373$c3611370$4a233a50$@riw.us> <061c01d0a37f$d24844b0$76d8ce10$@riw.us> <63A98784-80C5-4A76-976E-47E480294C03@tislabs.com> <02ac01d0a439$f5689f70$e039de50$@riw.us> Message-ID: On Thu, Jun 11, 2015 at 3:10 PM, David Mandelberg wrote: > On 2015-06-11 07:30, Russ White wrote: >>> >>> There have been suggestions that a key-per-AS is easier to manage than a >>> key-per-router, like in provisioning. >> >> >> Two points -- >> >> First, if a single person with console access leaves the company, I must >> roll the key for all my BGP routes, with the attendant churn, etc. I can't >> imagine anyone deploying such a thing. > > > I assume the vast majority of these cases are when the person leaves with no > indication of malicious intent. In those cases, it might be possible to it's actually nearly impossible to tell this... so the 'best' option is to do the changes required as quickly as is safe for your network. yes, it sucks... you know what sucks more? when 2 people leave on adjacent days. From nwarren at barryelectric.com Thu Jun 11 19:32:37 2015 From: nwarren at barryelectric.com (Nicholas Warren) Date: Thu, 11 Jun 2015 19:32:37 +0000 Subject: Greenfield 464XLAT (In January) In-Reply-To: References: Message-ID: I am thinking now that our best option would be to go duel-stack lite (RFC6333), after reading what you fellows have to say about 464XLAT. I feel as though I should add that our peer networks (one was started at the end of 2013) are implementing IPv4 only networks; they are pressuring management into thinking that IPv6 is too experimental to deploy, and that IPv4 (only) is the only way to go. Thank you, - Nich Warren -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Thursday, June 11, 2015 12:13 PM To: Nicholas Warren Cc: nanog at nanog.org Subject: Re: Greenfield 464XLAT (In January) On Wed, Jun 10, 2015 at 4:22 PM, Nicholas Warren wrote: > Sincere apologies if this e-mail is inappropriate for this audience, Hi Nich, Looks like the correct audience to me. > We are (going to be) a startup ISP building a new network from the > ground up. [...] The main reason we are even considering 464XLAT as > opposed to dual-stack (the latter is, in my ignorant opinion, the > better option.) is the fear of IPv4 depletion that we think might hit > ARIN between now and the start of next year; causing us to pay a > premium for IPv4 in the gray market. Your customers will require end-to-end IPv4 for the foreseeable future. 464XLAT can provide natted IPv4 using an internal IPv6 infrastructure in special circumstances. Specifically: you must have sufficient control of the customer equipment to compel it to employ 464XLAT to provide IPv4 services to the customer. If your customers lease phones from you and your phone vendors build in 464XLAT support, T-Mobile has demonstrated that this is practical. If your customers bring generic Macs and PCs with the odd Linux user in the mix (their equipment, not yours), you may be asking for extensive support headaches with 464XLAT. Dual stack with carrier NAT would also handle your IPv4 needs. You'll have an additional expense maintaining both protocols within your infrastructure. Nevertheless, this approach alleviates the need to control the customer premises equipment. Regardless of your approach, DS+NAT or 464XLAT, you will require a comparable number of global IPv4 addresses. Neither technology eliminates your need for IPv4 addresses facing the public Internet. Regardless of your approach, you will need to make provisions to support customers who require a global and/or static IPv4 address without NAT. It need not be part of your basic package, but if it's unavailable at any price you can be sure of getting a PR black eye at some point. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From baldur.norddahl at gmail.com Thu Jun 11 19:43:54 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 11 Jun 2015 21:43:54 +0200 Subject: Greenfield 464XLAT (In January) In-Reply-To: References: Message-ID: Hi, The price for IPv4 is about $10 per address. I do not expect that to become much more expensive in the short term, especially not in the Arin region where there is such abundance of allocated address space that could be freed for a quick dime. So is $10 one time fee for new users too much? We are a young network in the RIPE region and we have had to buy most of our address space. We had the first 1024 for free as that is the RIPE policy. Our strategy is to buy what we need, but use the space as efficient as possible. Users are on a shared subnet (a /32 per user) instead of a /30 per user etc. I believe the other sane option is dual stack with carrier nat. You can sell non-NAT access at a premium. We decided against the NAT option because it is seen as inferior by the users and because it is not free either. Instead of spending money on buying address space, you will spend it on NAT servers. You will also have more fun with denial of service attacks killing your NAT server etc. The high tech solution is stuff like MAP where you move the cost out to the CPE. But then you need to control the CPE - if you have that then great. You would still want to sell a non-NAT (and MAP is NAT) to users that require a public IPv4 address, so you still need to go dual stack or use some tunnelling for that. That's my 2c. Regards, Baldur From laszlo at heliacal.net Thu Jun 11 23:42:07 2015 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Thu, 11 Jun 2015 23:42:07 +0000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <5578B90B.2000409@mtcc.com> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> Message-ID: <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> Lorzenzo is probably not going to post anymore because of this. It looks to me like Lorenzo wants the same thing as most everyone here, aside from the university net nazis, and he's got some balls to come defend his position against the angry old men of NANOG. Perhaps the approach of attacking DHCP is not the right one, but it sounds like his goal is to make IPv6 better than how IPv4 turned out. Things like privacy extensions, multiple addresses and PD are great because they make it harder for people to do address based tracking, which is generally regarded as a desirable feature except by the people who want to do the tracking. DHCPv6 is a crutch that allows operators to simply implement IPv6 with all the same hacks as IPv4 and continue to do address based access control, tracking, etc. It's like a 'goto' statement - it can be used to do clever things, but it can also be used to hack stuff and create very hard to fix problems down the road. I think what Lorenzo is trying to do is to use his influence/position to forcefully prevent people from doing this, and while that may not be the most diplomatic way, I admire his courage in posting here and trying to reason with the mob. -Laszlo On Jun 10, 2015, at 10:24 PM, Michael Thomas wrote: > On 06/10/2015 02:51 PM, Paul B. Henson wrote: >>> From: Lorenzo Colitti >>> Sent: Wednesday, June 10, 2015 8:27 AM >>> >>> please do not construe my words on this thread as being Google's position >>> on anything. These messages were sent from my personal email address, and I >>> do not speak for my employer. >> Can we construe your postings on the issue thread as being Google and/or Androids official position? They are posted by lorenzo at google.com with a tag of "Project Member", and I believe you also declined the request in the issue under that mantle. >> >> > Oh, stop this. The only thing this will accomplish is a giant black hole of silence from anybody at Google and any other $MEGACORP > in a similar situation. > > Mike From marka at isc.org Fri Jun 12 00:16:40 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 12 Jun 2015 10:16:40 +1000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: Your message of "Thu, 11 Jun 2015 23:42:07 +0000." <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> Message-ID: <20150612001641.743B9307F52A@rock.dv.isc.org> In message <9DA9C5B8-E60C-4462-873A-EA5052128067 at heliacal.net>, Laszlo Hanyecz writes: > Lorzenzo is probably not going to post anymore because of this. > > It looks to me like Lorenzo wants the same thing as most everyone here, > aside from the university net nazis, and he's got some balls to come > defend his position against the angry old men of NANOG. Perhaps the > approach of attacking DHCP is not the right one, but it sounds like his > goal is to make IPv6 better than how IPv4 turned out. > > Things like privacy extensions, multiple addresses and PD are great > because they make it harder for people to do address based tracking, > which is generally regarded as a desirable feature except by the people > who want to do the tracking. DHCPv6 is a crutch that allows operators to > simply implement IPv6 with all the same hacks as IPv4 and continue to do > address based access control, tracking, etc. It's like a 'goto' > statement - it can be used to do clever things, but it can also be used > to hack stuff and create very hard to fix problems down the road. I > think what Lorenzo is trying to do is to use his influence/position to > forcefully prevent people from doing this, and while that may not be the > most diplomatic way, I admire his courage in posting here and trying to > reason with the mob. > > -Laszlo There is a difference between arguing that additional addesses should be supported and saying stuff consensus and stuff what you want from the product, I am not going to give you DHCPv6 support because it may be used to only hand out only one address. The better long term strategy is to support DHCPv6 and then complain that you can't get a address for 464XLAT and/or a privacy address. Having a brower come up and say "Unable to obtain privacy address. Do you still want to post this request" for every request will have much more impact and is actually solvable with a couple of tweaks to the DHCPv6 configuration than getting policy changed to support SLACC. Recording N addresss against a user (where N is small) is not any harder than recording 1 address and gives the traceback needed. A RFC compliant DHCPv6 server will hand out multiple address by default. I haven't checked ISC's DHCPv6 server and if it doesn't do multiple addresses by default please open a bug ticket (dhcp-bugs at isc.org) as it should. 464XLAT isn't even needed to do IPv4 over a IPv6-only WiFi. There are other ways to do it, e.g. DS-Lite, which work better than 464XLAT. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rps at maine.edu Fri Jun 12 00:51:21 2015 From: rps at maine.edu (Ray Soucy) Date: Thu, 11 Jun 2015 20:51:21 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> Message-ID: That's really not the case at all. You're just projecting your own views about not thinking DHCPv6 is valid and making yourself and Lorenzo out to be the some sort of victims of NANOG and the ... > university net nazis Did you really just write that? What we're arguing for here is choice, the exact opposite of the association you're trying to make here. It's incredibly poor taste to throw that term around in this context, and adds nothing to the discussion. People are not logical. They adopt a position and then look for information to support it rather than counter it; they even go as far as to ignore or dismiss relevant information in the face of logic. That's religion. And this entire discussion continues to be rooted in religion rather than pragmatism. DHCPv6 is a tool, just as SLAAC is a tool. IPv6 was designed to support both options because they both have valid use cases. Please allow network operators to use the best tool for the job instead of telling us all we're required to do it your way (can you even see how ridiculous this whole "nazi" name calling is given the position you're taking) You don't get to just say "I'm not going to implement this because I don't agree with it," which is what Google is doing in the case of Android. The reason Lorenzo has triggered such a backlash on NANOG is that is fundamental argument on why he doesn't see DHCPv6 as valid for the Android is quite frankly a very weak argument at best. If you're going to stand up and say you're not going to do what everyone else has already done, especially when it comes to implementation of fundamental standards that everything depends upon, you need to have a better reason for it than the one Lorenzo provided. I honestly hope he collects himself and takes the time to respond, because it really is a problem. As much as you may not want DHCPv6 to be a thing, it's already a thing. On Thu, Jun 11, 2015 at 7:42 PM, Laszlo Hanyecz wrote: > Lorzenzo is probably not going to post anymore because of this. > > It looks to me like Lorenzo wants the same thing as most everyone here, > aside from the university net nazis, and he's got some balls to come defend > his position against the angry old men of NANOG. Perhaps the approach of > attacking DHCP is not the right one, but it sounds like his goal is to make > IPv6 better than how IPv4 turned out. > > Things like privacy extensions, multiple addresses and PD are great > because they make it harder for people to do address based tracking, which > is generally regarded as a desirable feature except by the people who want > to do the tracking. DHCPv6 is a crutch that allows operators to simply > implement IPv6 with all the same hacks as IPv4 and continue to do address > based access control, tracking, etc. It's like a 'goto' statement - it can > be used to do clever things, but it can also be used to hack stuff and > create very hard to fix problems down the road. I think what Lorenzo is > trying to do is to use his influence/position to forcefully prevent people > from doing this, and while that may not be the most diplomatic way, I > admire his courage in posting here and trying to reason with the mob. > > -Laszlo > > > On Jun 10, 2015, at 10:24 PM, Michael Thomas wrote: > > > On 06/10/2015 02:51 PM, Paul B. Henson wrote: > >>> From: Lorenzo Colitti > >>> Sent: Wednesday, June 10, 2015 8:27 AM > >>> > >>> please do not construe my words on this thread as being Google's > position > >>> on anything. These messages were sent from my personal email address, > and I > >>> do not speak for my employer. > >> Can we construe your postings on the issue thread as being Google > and/or Androids official position? They are posted by lorenzo at google.com > with a tag of "Project Member", and I believe you also declined the request > in the issue under that mantle. > >> > >> > > Oh, stop this. The only thing this will accomplish is a giant black hole > of silence from anybody at Google and any other $MEGACORP > > in a similar situation. > > > > Mike > > -- 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 henson at acm.org Fri Jun 12 00:54:42 2015 From: henson at acm.org (Paul B. Henson) Date: Thu, 11 Jun 2015 17:54:42 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> Message-ID: <2f1701d0a4aa$617b98f0$2472cad0$@acm.org> > From: Laszlo Hanyecz > Sent: Thursday, June 11, 2015 4:42 PM > > from the university net Nazis Wow, it must be nice to live in a fairyland utopia where there is no DMCA, no federal laws such as HEOA, and a wide variety of other things you clearly know nothing about that require universities to be able to track their users and manage their networks. > attacking DHCP is not the right one, but it sounds like his goal is to make IPv6 > better than how IPv4 turned out. I don't think a single person here has a goal of making IPv6 worse, nor necessarily has any objection to the improvements he has suggested. OTOH, I think the number of people who think he is making a good decision in refusing to implement DHCPv6 is practically nil. > diplomatic way, I admire his courage in posting here and trying to reason with > the mob. If he really wants to validate his position on not implementing DHCPv6, maybe he should approach all of the other vendors who already did and get them to remove it. Being the one and only holdout on implementing a widely deployed Internet standard looks more like lunatic fringe than visionary leader 8-/. From cb.list6 at gmail.com Fri Jun 12 01:03:11 2015 From: cb.list6 at gmail.com (Ca By) Date: Thu, 11 Jun 2015 18:03:11 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <2f1701d0a4aa$617b98f0$2472cad0$@acm.org> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <2f1701d0a4aa$617b98f0$2472cad0$@acm.org> Message-ID: Yeh, we get it. Repeating yourself is not helpful. The horse is dead .... Please move your android feature request to a forum more fit for your request. On Thursday, June 11, 2015, Paul B. Henson wrote: > > From: Laszlo Hanyecz > > Sent: Thursday, June 11, 2015 4:42 PM > > > > from the university net Nazis > > Wow, it must be nice to live in a fairyland utopia where there is no DMCA, > no federal laws such as HEOA, and a wide variety of other things you > clearly > know nothing about that require universities to be able to track their > users > and manage their networks. > > > attacking DHCP is not the right one, but it sounds like his goal is to > make IPv6 > > better than how IPv4 turned out. > > I don't think a single person here has a goal of making IPv6 worse, nor > necessarily has any objection to the improvements he has suggested. OTOH, I > think the number of people who think he is making a good decision in > refusing to implement DHCPv6 is practically nil. > > > diplomatic way, I admire his courage in posting here and trying to reason > with > > the mob. > > If he really wants to validate his position on not implementing DHCPv6, > maybe he should approach all of the other vendors who already did and get > them to remove it. Being the one and only holdout on implementing a widely > deployed Internet standard looks more like lunatic fringe than visionary > leader 8-/. > > > From rps at maine.edu Fri Jun 12 01:10:35 2015 From: rps at maine.edu (Ray Soucy) Date: Thu, 11 Jun 2015 21:10:35 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <2f1701d0a4aa$617b98f0$2472cad0$@acm.org> Message-ID: Well, most systems implemented DHCPv6 support a long time ago. Despite other efforts to have Google support DHCPv6 for Android, nothing has happened. There is nothing wrong with using NANOG to call out a major vendor for this, even if they are a significant sponsor. Just because you don't agree with the direction of the discussion doesn't mean it has no value. On Thu, Jun 11, 2015 at 9:03 PM, Ca By wrote: > Yeh, we get it. Repeating yourself is not helpful. The horse is dead .... > > Please move your android feature request to a forum more fit for your > request. > > On Thursday, June 11, 2015, Paul B. Henson wrote: > > > > From: Laszlo Hanyecz > > > Sent: Thursday, June 11, 2015 4:42 PM > > > > > > from the university net Nazis > > > > Wow, it must be nice to live in a fairyland utopia where there is no > DMCA, > > no federal laws such as HEOA, and a wide variety of other things you > > clearly > > know nothing about that require universities to be able to track their > > users > > and manage their networks. > > > > > attacking DHCP is not the right one, but it sounds like his goal is to > > make IPv6 > > > better than how IPv4 turned out. > > > > I don't think a single person here has a goal of making IPv6 worse, nor > > necessarily has any objection to the improvements he has suggested. > OTOH, I > > think the number of people who think he is making a good decision in > > refusing to implement DHCPv6 is practically nil. > > > > > diplomatic way, I admire his courage in posting here and trying to > reason > > with > > > the mob. > > > > If he really wants to validate his position on not implementing DHCPv6, > > maybe he should approach all of the other vendors who already did and get > > them to remove it. Being the one and only holdout on implementing a > widely > > deployed Internet standard looks more like lunatic fringe than visionary > > leader 8-/. > > > > > > > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From marka at isc.org Fri Jun 12 01:13:12 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 12 Jun 2015 11:13:12 +1000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: Your message of "Thu, 11 Jun 2015 17:54:42 -0700." <2f1701d0a4aa$617b98f0$2472cad0$@acm.org> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <2f1701d0a4aa$617b98f0$2472cad0$@acm.org> Message-ID: <20150612011313.9473B30800E1@rock.dv.isc.org> In message <2f1701d0a4aa$617b98f0$2472cad0$@acm.org>, "Paul B. Henson" writes: > > From: Laszlo Hanyecz > > Sent: Thursday, June 11, 2015 4:42 PM > > > > from the university net Nazis > > Wow, it must be nice to live in a fairyland utopia where there is no DMCA, > no federal laws such as HEOA, and a wide variety of other things you clearly > know nothing about that require universities to be able to track their users > and manage their networks. Both "fairyland utopia" and "net Nazis" are extreme positions. And DHCPv6 is not the only solution to tracking users. There are solutions that work with SLAAC. Same as 464XLAT is not the only way to provide IPv4 service over IPv6. Same as withholding a DHCPv6 client is not the only way to encourage multiple addresses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From laszlo at heliacal.net Fri Jun 12 02:07:22 2015 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Fri, 12 Jun 2015 02:07:22 +0000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> Message-ID: On Jun 12, 2015, at 12:51 AM, Ray Soucy wrote: > That's really not the case at all. > > You're just projecting your own views about not thinking DHCPv6 is valid and making yourself and Lorenzo out to be the some sort of victims of NANOG and the ... > DHCPv6 and Android are just collateral damage here but I think the argument is about steering what the generally accepted form of "end user IPv6 on WiFi" will be. It would be great if we could agree on that so we don't all have to write support for many different ways and provide complicated user interfaces for configuring it, right? Plug and play? > > university net nazis > > Did you really just write that? > As far as "net nazi", I meant it in the same sense as a BOFH. Someone who is intentionally degrading a user's experience by using technical means to block specifically targeted applications or behaviors. And "angry old men" is also not a literal meaning, but an observation of how this has turned into a flame war where it's a lot of seemingly angry people mobbing the Android developer. > What we're arguing for here is choice, the exact opposite of the association you're trying to make here. It's incredibly poor taste to throw that term around in this context, and adds nothing to the discussion. > > People are not logical. They adopt a position and then look for information to support it rather than counter it; they even go as far as to ignore or dismiss relevant information in the face of logic. That's religion. And this entire discussion continues to be rooted in religion rather than pragmatism. > > DHCPv6 is a tool, just as SLAAC is a tool. IPv6 was designed to support both options because they both have valid use cases. Please allow network operators to use the best tool for the job instead of telling us all we're required to do it your way (can you even see how ridiculous this whole "nazi" name calling is given the position you're taking) Without getting into all the "actually there is edge case X" discussions, when you connect to a WiFi network at an office, home or public place today, it's pretty 'standard' to find a DHCP server handing out rfc1918 IPv4 addresses, recursive name servers, and the network doing some form of NAT or proxying. This is pretty much what we expect when we open up a laptop and connect to a network, and if it doesn't work we call the help desk and ask why it doesn't do what we expect. Every user application that wants to do peer to peer networking has to come up with some complicated workaround to communicate through the various forms of NAT and proxies. What do we expect to happen with regard to IPv6? I think it would be great if end to end connectivity was common enough that application developers could assume it will be there, and avoid having to do those workarounds. On the other hand, if it becomes common and acceptable to use DHCPv6 to provide a single address only, then applications will just circumvent it once again with things like NAT, VPNs and reflector servers, which actually makes it worse for everyone involved. > > You don't get to just say "I'm not going to implement this because I don't agree with it," which is what Google is doing in the case of Android. > > The reason Lorenzo has triggered such a backlash on NANOG is that is fundamental argument on why he doesn't see DHCPv6 as valid for the Android is quite frankly a very weak argument at best. If you're going to stand up and say you're not going to do what everyone else has already done, especially when it comes to implementation of fundamental standards that everything depends upon, you need to have a better reason for it than the one Lorenzo provided. > It seems like several people have taken the position that they will use their influence to steer others away from Android because it doesn't work with their chosen network configuration. This to me sounds very much like Android taking the position that the network should support their chosen address configuration protocol instead of that other one. I think in the end we're going to find that both the network side and the client side end up having to support the whole matrix of possible configurations, if the end goal is to provide a good user experience, but this is not a good OS developer and network operator experience because it creates more work for everyone and more trouble for users when the complicated workarounds don't work. -Laszlo > I honestly hope he collects himself and takes the time to respond, because it really is a problem. > > As much as you may not want DHCPv6 to be a thing, it's already a thing. > > > > > > On Thu, Jun 11, 2015 at 7:42 PM, Laszlo Hanyecz wrote: > Lorzenzo is probably not going to post anymore because of this. > > It looks to me like Lorenzo wants the same thing as most everyone here, aside from the university net nazis, and he's got some balls to come defend his position against the angry old men of NANOG. Perhaps the approach of attacking DHCP is not the right one, but it sounds like his goal is to make IPv6 better than how IPv4 turned out. > > Things like privacy extensions, multiple addresses and PD are great because they make it harder for people to do address based tracking, which is generally regarded as a desirable feature except by the people who want to do the tracking. DHCPv6 is a crutch that allows operators to simply implement IPv6 with all the same hacks as IPv4 and continue to do address based access control, tracking, etc. It's like a 'goto' statement - it can be used to do clever things, but it can also be used to hack stuff and create very hard to fix problems down the road. I think what Lorenzo is trying to do is to use his influence/position to forcefully prevent people from doing this, and while that may not be the most diplomatic way, I admire his courage in posting here and trying to reason with the mob. > > -Laszlo > > > On Jun 10, 2015, at 10:24 PM, Michael Thomas wrote: > > > On 06/10/2015 02:51 PM, Paul B. Henson wrote: > >>> From: Lorenzo Colitti > >>> Sent: Wednesday, June 10, 2015 8:27 AM > >>> > >>> please do not construe my words on this thread as being Google's position > >>> on anything. These messages were sent from my personal email address, and I > >>> do not speak for my employer. > >> Can we construe your postings on the issue thread as being Google and/or Androids official position? They are posted by lorenzo at google.com with a tag of "Project Member", and I believe you also declined the request in the issue under that mantle. > >> > >> > > Oh, stop this. The only thing this will accomplish is a giant black hole of silence from anybody at Google and any other $MEGACORP > > in a similar situation. > > > > Mike > > > > > -- > 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 mpetach at netflight.com Fri Jun 12 02:18:49 2015 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 11 Jun 2015 19:18:49 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: On Wed, Jun 10, 2015 at 8:26 AM, Lorenzo Colitti wrote: > Ray, > > please do not construe my words on this thread as being Google's position > on anything. These messages were sent from my personal email address, and I > do not speak for my employer. > > Regards, > Lorenzo Ah, Lorenzo, Lorenzo... I was going to just let the thread go quietly by until you pulled out the "I'm not speaking for my employer" card. :( Can we take what you posted here https://code.google.com/p/android/issues/detail?id=32621#c53 from your google.com account to be official Google position, when you closed the issue requesting DHCPv6 support as "Declined?" Again, in comment #109 https://code.google.com/p/android/issues/detail?id=32621#c109 you speak from your Google.com account when you repeat *twice* the position that you won't support stateful DHCPv6: "and not via stateful DHCPv6 address assignment" followed by "while continuing not to support DHCPv6 address assignment." It's hard to not see _that_ as being Google's position, when you post it from your google.com account in response to an issue raised about broken functionality on the Android platform. So perhaps you're right, and the words you use on _this_ thread are your personal opinion; unfortunately, they seem to be the same words and opinions you use from your google.com account when denying input from Android users who don't seem to want their devices to be crippled by incomplete DHCPv6 support. I wonder at what point large enterprises will simply say "sorry, without working DHCPv6 support, Android devices will not be supported on this network"--at which point this will stop being a religious issue, and will shift to being a business issue, as Google will have to decide whether being stubbornly dogmatic while losing large customers is worth it or not. Thanks! Matt PS--just because some poor unfortunate soul found a way to scrape neighbor tables to work around the lack of DHCPv6 lease logs does *not* make it a practical or wise alternative. A certain network has been trying to test out that workaround, and every time they scrape the neighbor table, the CPU on the routers pegs at 100%. PPS--I am likewise posting this from my personal account (which is still running an old enough Cisco image that it pre-dates IPv6 support entirely, making most of this a moot point for me personally). The opinions expressed here are purely my own, and should in no way be construed to apply to anyone but myself, and possibly the mice living in the garage. From laszlo at heliacal.net Fri Jun 12 02:31:37 2015 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Fri, 12 Jun 2015 02:31:37 +0000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> Message-ID: "Your phone doesn't work with our network, so you should buy one that does" vs "Hey we can't connect, fix your network" Kind of similar to the streaming video vs eyeball network thing.. blaming the bad user experience on the other guy. -Laszlo On Jun 12, 2015, at 2:18 AM, Matthew Petach wrote: > On Wed, Jun 10, 2015 at 8:26 AM, Lorenzo Colitti wrote: >> Ray, >> >> please do not construe my words on this thread as being Google's position >> on anything. These messages were sent from my personal email address, and I >> do not speak for my employer. >> >> Regards, >> Lorenzo > > > Ah, Lorenzo, Lorenzo... > > I was going to just let the thread go quietly by until you pulled > out the "I'm not speaking for my employer" card. :( > > Can we take what you posted here > https://code.google.com/p/android/issues/detail?id=32621#c53 > from your google.com account to be official Google > position, when you closed the issue requesting DHCPv6 > support as "Declined?" > > Again, in comment #109 > https://code.google.com/p/android/issues/detail?id=32621#c109 > you speak from your Google.com account when you repeat > *twice* the position that you won't support stateful DHCPv6: > "and not via stateful DHCPv6 address assignment" followed by > "while continuing not to support DHCPv6 address assignment." > > It's hard to not see _that_ as being Google's position, when you > post it from your google.com account in response to an issue raised > about broken functionality on the Android platform. So perhaps > you're right, and the words you use on _this_ thread are your > personal opinion; unfortunately, they seem to be the same > words and opinions you use from your google.com account when > denying input from Android users who don't seem to want > their devices to be crippled by incomplete DHCPv6 support. > > I wonder at what point large enterprises will simply say > "sorry, without working DHCPv6 support, Android devices > will not be supported on this network"--at which point this > will stop being a religious issue, and will shift to being a > business issue, as Google will have to decide whether > being stubbornly dogmatic while losing large customers > is worth it or not. > > Thanks! > > Matt > > PS--just because some poor unfortunate soul found a > way to scrape neighbor tables to work around the lack > of DHCPv6 lease logs does *not* make it a practical > or wise alternative. A certain network has been trying > to test out that workaround, and every time they scrape > the neighbor table, the CPU on the routers pegs at 100%. > > PPS--I am likewise posting this from my personal > account (which is still running an old enough Cisco > image that it pre-dates IPv6 support entirely, making > most of this a moot point for me personally). The > opinions expressed here are purely my own, and > should in no way be construed to apply to anyone > but myself, and possibly the mice living in the garage. From mpetach at netflight.com Fri Jun 12 02:48:19 2015 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 11 Jun 2015 19:48:19 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> Message-ID: On Thu, Jun 11, 2015 at 4:42 PM, Laszlo Hanyecz wrote: > Lorzenzo is probably not going to post anymore because of this. Oh, I imagine we'll all need to take a time-out after this thread; I know it's got my back fur all riled up, too. :( > It looks to me like Lorenzo wants the same thing as most everyone here, aside from the university net nazis, and he's got some balls to come defend his position against the angry old men of NANOG. Perhaps the approach of attacking DHCP is not the right one, but it sounds like his goal is to make IPv6 better than how IPv4 turned out. If we had the choice of waiting to make IPv6 better, that might be a more laudable position; if we were having this discussion ten years ago, when v4 addresses were still plentiful, pushing for the best future of IPv6 would have been great. Unfortunately, with v4 exhaustion, companies face the decision of "is v6 easy enough to deploy so that I can just do that, or do I stick with v4 and more layers of NAT to stretch my meagre v4 resources out as long as I can." Dogmatic positions like this swing the pendulum firmly towards the latter, unfortunately. He's got balls, I'll definitely say that much. I just feel like his balls are coming to the party ten years too late. :( > Things like privacy extensions, multiple addresses and PD are great because they make it harder for people to do address based tracking, which is generally regarded as a desirable feature except by the people who want to do the tracking. DHCPv6 is a crutch that allows operators to simply implement IPv6 with all the same hacks as IPv4 and continue to do address based access control, tracking, etc. It's like a 'goto' statement - it can be used to do clever things, but it can also be used to hack stuff and create very hard to fix problems down the road. I think what Lorenzo is trying to do is to use his influence/position to forcefully prevent people from doing this, and while that may not be the most diplomatic way, I admire his courage in posting here and trying to reason with the mob. Without address tracking, devices aren't going to be allowed onto corporate networks. You may hate that, but legal liability makes that an absolute necessity. Like it or not, regardless of whatever privacy extensions, multiple addresses, and PD you push for, in order to use those devices on corporate networks, there must be a way to track which devices had those addresses. > -Laszlo Matt PS--any discussion of Lorenzo's balls on my part is purely my personal opinion, and is not undertaken on behalf of any employer. In other words, nobody pays me to talk about Lorenzo's balls. From kauer at biplane.com.au Fri Jun 12 04:06:43 2015 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 12 Jun 2015 14:06:43 +1000 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> Message-ID: <1434082003.3003.98.camel@karl> On Thu, 2015-06-11 at 20:51 -0400, Ray Soucy wrote: > DHCPv6 is a tool, just as SLAAC is a tool. IPv6 was designed to support > both options because they both have valid use cases. Yes, a thousand times yes. > You don't get to just say "I'm not going to implement this because I don't > agree with it," which is what Google is doing in the case of Android. Actually, you DO get to just say that. Anyone can, but especially something as big as Google. And if DHCPv6 turns out to be important enough to enough people, Android will lose market share and either fork, die or change its mind. It wouldn't be the first mobile platform to disappear into the sludge of history. > I honestly hope he collects himself and takes the time to respond, because > it really is a problem. Not for him, and apparently not for Google. It's only a problem for people that want to do DHCPv6 with Android clients. Whether that becomes a problem for Google is another matter. I certainly hope Google sees the light early. Their current stance is very disappointing. And it's odd to see someone at that level so comprehensively missing the point. For someone with the breadth of experience and jacked into the mother lode like Lorenzo - very unusual. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From lyndon at orthanc.ca Fri Jun 12 04:45:18 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 11 Jun 2015 21:45:18 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <1434082003.3003.98.camel@karl> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <1434082003.3003.98.camel@karl> Message-ID: On Jun 11, 2015, at 9:06 PM, Karl Auer wrote: >> You don't get to just say "I'm not going to implement this because I don't >> agree with it," which is what Google is doing in the case of Android. > > Actually, you DO get to just say that. Anyone can, but especially > something as big as Google. And if DHCPv6 turns out to be important > enough to enough people, Android will lose market share and either fork, > die or change its mind. It wouldn't be the first mobile platform to > disappear into the sludge of history. Sadly, there is another side to this. Witness how the DMARC crew are destroying the functionality of email as we have known it for decades. Sometimes the 800 pound gorillas DO have the ability to fsck things over for everyone. --lyndon P.S. But it is the mindless-sheep-like behaviour that lets them. So instead I should be complaining to the masses who are incapable of thinking for themselves? We know how well *that* works ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tore at fud.no Fri Jun 12 05:14:33 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 12 Jun 2015 07:14:33 +0200 Subject: Greenfield 464XLAT (In January) In-Reply-To: References: Message-ID: <20150612071433.75cbf6a5@echo.ms.redpill-linpro.com> * Baldur Norddahl > The high tech solution is stuff like MAP where you move the cost out > to the CPE. But then you need to control the CPE - if you have that > then great. You would still want to sell a non-NAT (and MAP is NAT) > to users that require a public IPv4 address, so you still need to go > dual stack or use some tunnelling for that. Hi Baldur, MAP is *not* NAT; that's what's so neat about it. The users do get a public IPv4 address (or prefix!) routed to their CPE's WAN interface, towards which they can accept inbound unsolicited connections. The public IPv4 address could be port-restricted if the operator wants address sharing, but it does not have to be. You could do both at the same time, e.g., giving your "premium" users a /32 or /28, while the standard subscription includes a /32 with 4k ports. I will grant you that MAP-T performs NAT (i.e., protocol translation) internally, but the translations that happens when a packet enters the MAP domain are reversed when it exits. So the IPv4 addresses are transparent end-to-end. MAP-E (and lw4o6 for that matter), on the other hand, has no form of NAT anywhere. (Unless you count the NAPT44 that sits between the subscriber's RFC1918 LAN segment and the CPE's WAN interface, but that's not exactly something that's unique to MAP.) Nicholas: If I were you, before going down the 464XLAT route, I'd first look closely at these technologies, in the order given: 1) MAP (because it is fully stateless) 2) lw4o6 (because it is mostly stateless, i.e., no session tracking) 3) DS-Lite (which, like 464XLAT, is stateful, but you'll have way more CPEs to choose from than with 464XLAT, which is mostly for mobile) Tore From jfbeam at gmail.com Fri Jun 12 05:18:15 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 12 Jun 2015 01:18:15 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> Message-ID: On Thu, 11 Jun 2015 19:42:07 -0400, Laszlo Hanyecz wrote: > It looks to me like Lorenzo wants the same thing as most everyone here, It doesn't look like that from my chair. He doesn't want to implement DHCPv6 (and has REFUSED to do so for YEARS now) because he cannot find solutions for every possible permutation. In fact, he's hung up on **ONE** configuration: a network where DHCPv6 allows exactly one address to an endpoint. > Things like privacy extensions, multiple addresses and PD are great > because they make it harder for people to do address based tracking, > which is generally regarded as a desirable feature except by the people > who want to do the tracking. Addresses are *always* trackable. It's just a matter of who is in the best position to do it. My ISPs know what prefixes are assigned to me (both static and dynamic.) If I keep track of it, I know everything that's using an address in my networks -- by DHCP logs, and in theory, MAC table logs. (btw, I don't know of any solutions for MAC level logging.) > DHCPv6 is a crutch that allows operators to simply implement IPv6 with > all the same hacks as IPv4 and continue to do address based access > control, tracking, etc. It allows them to have the level of accountability and control they desire and/or REQUIRE. With DHCPv6, one doesn't have to pin a device to a single, solitary address. ISPs already handle that with PD (a single /64, a /60, or larger.) And there's nothing in the specs blocking a node from asking for multiple addresses. Again, because of the specter of one-address, Lorenzo REFUSED to support DHCPv6, IN. ANY. WAY. From Valdis.Kletnieks at vt.edu Fri Jun 12 07:05:57 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 12 Jun 2015 03:05:57 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: Your message of "Fri, 12 Jun 2015 02:07:22 -0000." References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> Message-ID: <38976.1434092757@turing-police.cc.vt.edu> On Fri, 12 Jun 2015 02:07:22 -0000, Laszlo Hanyecz said: > > > university net nazis > > > > Did you really just write that? > > > > As far as "net nazi", I meant it in the same sense as a BOFH. Someone who is > intentionally degrading a user's experience by using technical means to block > specifically targeted applications or behaviors. Well, which is more BOFH-ish: 1) We insist that you connect in a way that allows us to identify and track you for DMCA and other legal requirements that, quite frankly, we'd really rather not have to do, but it's a cost of doing business. 2) We don't let you connect at all because we can't do so without exposing ourselves to more legal liability than we want. Besides which, that's a total red herring. If you actually go back and *read*, I don't think anybody's "intentionally degrading by blocking targeted applications" - except those who are refusing to provide features to allow the applications to work on more network configs. The vast majority of us would *prefer* that Android got fixed so it can ask for more addresses and do more stuff. Most of us don't *care* if a user sucks up 13 adresses across 4 devices at the same time - IPv6 addresses are *cheap*. On the other hand, covering your ass when a subpoena shows up and you realize you don't have the data needed to point at the user they're *really* looking for is incredibly expensive. OK? Let me say that again: We're all asking Google to quit being stubborn and add a feature to Android so we can make the user experience *better*. Now who you calling a BOFH? > On the other hand, if it becomes common and acceptable to use DHCPv6 to > provide a single address only I encourage my competitor universities to design their networks that way. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From brandon at rd.bbc.co.uk Fri Jun 12 07:33:04 2015 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 12 Jun 2015 08:33:04 +0100 (BST) Subject: Android (lack of) support for DHCPv6 Message-ID: <201506120733.IAA21181@sunf10.rd.bbc.co.uk> > > On the other hand, if it becomes common and acceptable to use DHCPv6 to > > provide a single address only > > I encourage my competitor universities to design their networks that way. :) I'd be fine with android doing DHCPv6 plus refusing to use v6 if only one address is available. Covers the stated objective and lets those that will do the claimed right thing go ahead with v6 roll out. brandon From tore at fud.no Fri Jun 12 09:09:34 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 12 Jun 2015 11:09:34 +0200 Subject: AS4788 Telecom Malaysia major route leak? Message-ID: <20150612110934.55621a42@echo.ms.redpill-linpro.com> I see tons of bogus routes show up with AS4788 in the path, and at least AS3549 is acceping them. E.g. for the RIPE NCC (193.0.0.0/21): [BGP/170] 00:20:29, MED 1000, localpref 150 AS path: 3549 4788 12859 3333 I, validation-state: valid > to 64.210.69.85 via xe-1/1/0.0 Tore From baldur.norddahl at gmail.com Fri Jun 12 09:13:08 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 12 Jun 2015 11:13:08 +0200 Subject: Greenfield 464XLAT (In January) In-Reply-To: <20150612071433.75cbf6a5@echo.ms.redpill-linpro.com> References: <20150612071433.75cbf6a5@echo.ms.redpill-linpro.com> Message-ID: On 12 June 2015 at 07:14, Tore Anderson wrote: > > Hi Baldur, > > MAP is *not* NAT; that's what's so neat about it. The users do get a > public IPv4 address (or prefix!) routed to their CPE's WAN interface, > towards which they can accept inbound unsolicited connections. > True if you are only doing MAP because you do not like pesky IPv4 packets in your backbone (ie. do not like dual stack backbone). But for us that are in the "have to buy IPv4 addresses" boat, the interesting thing about MAP is that it can be used instead of carrier NAT. You will have multiple users sharing the same IP address. Each user has a port range routed to him. While he does get the public IP directly on his CPE, he is restricted from using it freely. He will not be able to run ssh on port 22 or a webserver on port 80/443. In this sense it is carrier NAT implemented on the CPEs. And with it comes some of the evil of carrier NAT. If I ever go down the carrier NAT route I would like a MAP solution. It is clever. The only problem is that I do not know of any equipment that will actually do MAP (besides possible Cisco which is outside my price range). The RFC is not even done yet. Regards, Baldur From job at instituut.net Fri Jun 12 09:16:07 2015 From: job at instituut.net (Job Snijders) Date: Fri, 12 Jun 2015 11:16:07 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <20150612110934.55621a42@echo.ms.redpill-linpro.com> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> Message-ID: <20150612091607.GH94733@Vurt.local> On Fri, Jun 12, 2015 at 11:09:34AM +0200, Tore Anderson wrote: > I see tons of bogus routes show up with AS4788 in the path, and at > least AS3549 is acceping them. > > E.g. for the RIPE NCC (193.0.0.0/21): > > [BGP/170] 00:20:29, MED 1000, localpref 150 > AS path: 3549 4788 12859 3333 I, validation-state: valid > > to 64.210.69.85 via xe-1/1/0.0 It appears that AS3549 propagated the (almost?) full routing table leak to its peers, where in lots of instances max prefix kicked in. This has global impact, lots of alerts on the SQA collector page http://sqa.ring.nlnog.net/ Kind regards, Job From sebastian at karotte.org Fri Jun 12 09:16:29 2015 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Fri, 12 Jun 2015 11:16:29 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <20150612110934.55621a42@echo.ms.redpill-linpro.com> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> Message-ID: <20150612091629.GA24543@danton.fire-world.de> * Tore Anderson [2015-06-12 11:12]: > I see tons of bogus routes show up with AS4788 in the path, and at > least AS3549 is acceping them. > > E.g. for the RIPE NCC (193.0.0.0/21): > > [BGP/170] 00:20:29, MED 1000, localpref 150 > AS path: 3549 4788 12859 3333 I, validation-state: valid > > to 64.210.69.85 via xe-1/1/0.0 I confirm, something is going on: http://www.karotte.org/pics/bgp-stability.png Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From ingrid at ripe.net Fri Jun 12 09:18:23 2015 From: ingrid at ripe.net (Ingrid Wijte) Date: Fri, 12 Jun 2015 11:18:23 +0200 Subject: New AS Number Blocks allocated to the RIPE NCC In-Reply-To: <557A9E36.9030604@ripe.net> References: <557A9E36.9030604@ripe.net> Message-ID: <557AA3DF.7080805@ripe.net> -------- Forwarded Message -------- Subject: New AS Number Blocks allocated to the RIPE NCC Date: Fri, 12 Jun 2015 10:54:14 +0200 From: Ingrid Wijte To: address-policy-wg at ripe.net, routing-wg at ripe.net, Menog at menog.net, afnog at afnog.org, sanog at sanog.org, nanog at nanog.org, uknof at lists.uknof.org.uk, lacnog at lacnic.net, discuss at enog.org Dear Colleagues, The RIPE NCC has received the following AS Number Blocks from the IANA on 11 June 2015. 202240-203263 203264-204287 You may want to update your records accordingly. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC From rdobbins at arbor.net Fri Jun 12 09:27:25 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 12 Jun 2015 16:27:25 +0700 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <20150612091607.GH94733@Vurt.local> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> Message-ID: <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> On 12 Jun 2015, at 16:16, Job Snijders wrote: > This has global impact, lots of alerts on the SQA collector page > http://sqa.ring.nlnog.net/ I'm reaching out to them now. ----------------------------------- Roland Dobbins From bortzmeyer at nic.fr Fri Jun 12 09:41:30 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 12 Jun 2015 11:41:30 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <20150612110934.55621a42@echo.ms.redpill-linpro.com> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> Message-ID: <20150612094130.GA24974@nic.fr> On Fri, Jun 12, 2015 at 11:09:34AM +0200, Tore Anderson wrote a message of 10 lines which said: > I see tons of bogus routes show up with AS4788 in the path, and at > least AS3549 is acceping them. > > E.g. for the RIPE NCC (193.0.0.0/21): > > [BGP/170] 00:20:29, MED 1000, localpref 150 > AS path: 3549 4788 12859 3333 I, validation-state: valid Unlike most BGP leaks, they kept the proper origin, so validation by ROA was useless :-( From marty at cloudflare.com Fri Jun 12 09:43:09 2015 From: marty at cloudflare.com (Marty Strong) Date: Fri, 12 Jun 2015 10:43:09 +0100 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> Message-ID: <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> It *looks* like GBLX stopped accepting the leak. Regards, Marty Strong -------------------------------------- CloudFlare - AS13335 Network Engineer marty at cloudflare.com +44 20 3514 6970 UK (Office) +44 7584 906 055 UK (Mobile) +1 888 993 5273 US (Office) smartflare (Skype) http://www.peeringdb.com/view.php?asn=13335 > On 12 Jun 2015, at 10:27, Roland Dobbins wrote: > > > On 12 Jun 2015, at 16:16, Job Snijders wrote: > >> This has global impact, lots of alerts on the SQA collector page http://sqa.ring.nlnog.net/ > > I'm reaching out to them now. > > ----------------------------------- > Roland Dobbins From dhubbard at dino.hostasaurus.com Fri Jun 12 09:51:50 2015 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Fri, 12 Jun 2015 05:51:50 -0400 Subject: Huge Level 3 ipv4 issues? Message-ID: Experiencing packetloss all over the place (chicago, tampa, atlanta) on Level 3's network; can't even reach them from Brighthouse residential. IPv6 seems to still be working fine, but of course Brighthouse doesn't offer that lol. Anyone seeing the same? David From marty at cloudflare.com Fri Jun 12 10:03:26 2015 From: marty at cloudflare.com (Marty Strong) Date: Fri, 12 Jun 2015 11:03:26 +0100 Subject: Huge Level 3 ipv4 issues? In-Reply-To: References: Message-ID: <66DE816B-1EBC-4355-97ED-CFD06F7C8695@cloudflare.com> There?s another thread about this, titled: "AS4788 Telecom Malaysia major route leak?" Regards, Marty Strong -------------------------------------- CloudFlare - AS13335 Network Engineer marty at cloudflare.com +44 20 3514 6970 UK (Office) +44 7584 906 055 UK (Mobile) +1 888 993 5273 US (Office) smartflare (Skype) http://www.peeringdb.com/view.php?asn=13335 > On 12 Jun 2015, at 10:51, David Hubbard wrote: > > Experiencing packetloss all over the place (chicago, tampa, atlanta) on > Level 3's network; can't even reach them from Brighthouse residential. > IPv6 seems to still be working fine, but of course Brighthouse doesn't > offer that lol. > > Anyone seeing the same? > > David From chris at mxtelecom.com Fri Jun 12 10:03:14 2015 From: chris at mxtelecom.com (Chris Wilson) Date: Fri, 12 Jun 2015 11:03:14 +0100 (BST) Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <20150612094130.GA24974@nic.fr> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612094130.GA24974@nic.fr> Message-ID: These aren't just leaks - they're more specifics of what's normally advertised, but keeping the proper origin. Hard to see how that could be accidental... Chris On Fri, 12 Jun 2015, Stephane Bortzmeyer wrote: > On Fri, Jun 12, 2015 at 11:09:34AM +0200, > Tore Anderson wrote > a message of 10 lines which said: > >> I see tons of bogus routes show up with AS4788 in the path, and at >> least AS3549 is acceping them. >> >> E.g. for the RIPE NCC (193.0.0.0/21): >> >> [BGP/170] 00:20:29, MED 1000, localpref 150 >> AS path: 3549 4788 12859 3333 I, validation-state: valid > > Unlike most BGP leaks, they kept the proper origin, so validation by ROA was > useless :-( > From tore at fud.no Fri Jun 12 10:05:16 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 12 Jun 2015 12:05:16 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> Message-ID: <20150612120516.3ec4ce6a@echo.ms.redpill-linpro.com> * Marty Strong via NANOG > It *looks* like GBLX stopped accepting the leak. If so, it's a partial fix at best, I still see plenty of leaked routes, both via 3356 and 3549, e.g.: tore at cr1-osl3> show route 195.24.168.98 all Jun 12 12:03:54 +0200 inet.0: 544405 destinations, 1591203 routes (543086 active, 3 holddown, 526626 hidden) + = Active Route, - = Last Active, * = Both 195.24.160.0/19 *[BGP/170] 00:03:59, MED 2000, localpref 50, from 87.238.63.5 AS path: 3356 3549 4788 6939 39648 I, validation-state: unverified > to 87.238.63.56 via ae0.0 [BGP/170] 00:05:24, MED 0, localpref 50, from 87.238.63.2 AS path: 3356 3549 4788 6939 39648 I, validation-state: unverified > to 87.238.63.56 via ae0.0 [BGP ] 01:16:00, MED 25245, localpref 100 AS path: 3549 4788 6939 39648 I, validation-state: unverified > to 64.210.69.85 via xe-1/1/0.0 It seems to have started around 08:47 UTC, that's when I got my first alarm from ring-sqa at least. Tore From maxsec at gmail.com Fri Jun 12 10:08:10 2015 From: maxsec at gmail.com (Martin Hepworth) Date: Fri, 12 Jun 2015 11:08:10 +0100 Subject: Huge Level 3 ipv4 issues? In-Reply-To: References: Message-ID: seeing issues across GX in the UK as well... -- Martin Hepworth, CISSP Oxford, UK On 12 June 2015 at 10:51, David Hubbard wrote: > Experiencing packetloss all over the place (chicago, tampa, atlanta) on > Level 3's network; can't even reach them from Brighthouse residential. > IPv6 seems to still be working fine, but of course Brighthouse doesn't > offer that lol. > > Anyone seeing the same? > > David > From raymond at prolocation.net Fri Jun 12 10:07:57 2015 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Fri, 12 Jun 2015 11:07:57 +0100 Subject: Huge Level 3 ipv4 issues? In-Reply-To: References: Message-ID: <92CCD6CC-0CA6-464B-A717-0D2E41F1E0B6@prolocation.net> Hai David, > Op 12 jun. 2015 om 10:51 heeft David Hubbard het volgende geschreven: > > Experiencing packetloss all over the place (chicago, tampa, atlanta) on > Level 3's network; can't even reach them from Brighthouse residential. > IPv6 seems to still be working fine, but of course Brighthouse doesn't > offer that lol. > > Anyone seeing the same? > > David Yes. See also another thread here: http://mailman.nanog.org/pipermail/nanog/2015-June/076189.html Thanks, Raymond Dijkxhoorn - Prolication From fohdeesha at gmail.com Fri Jun 12 10:09:13 2015 From: fohdeesha at gmail.com (Jon Sands) Date: Fri, 12 Jun 2015 06:09:13 -0400 Subject: Huge Level 3 ipv4 issues? In-Reply-To: References: Message-ID: Seeing the same on brighthouse in Indianapolis to most of level 3 (so a lot of the internet it seems, only on mobile phone via WiFi atm so haven't looked much into it). Using level3 DNS here totally failed about an hour ago, switched resolvers and I can now resolve things but still no luck with l3 destined traffic On Jun 12, 2015 6:02 AM, "David Hubbard" wrote: > Experiencing packetloss all over the place (chicago, tampa, atlanta) on > Level 3's network; can't even reach them from Brighthouse residential. > IPv6 seems to still be working fine, but of course Brighthouse doesn't > offer that lol. > > Anyone seeing the same? > > David > From marty at cloudflare.com Fri Jun 12 10:15:25 2015 From: marty at cloudflare.com (Marty Strong) Date: Fri, 12 Jun 2015 11:15:25 +0100 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <20150612094130.GA24974@nic.fr> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612094130.GA24974@nic.fr> Message-ID: <6D3BF23A-006E-48E7-8AB9-8EE04DC6D06F@cloudflare.com> > Hi Marty, > > Noted. We are still checking this issue. > > > > > > Regards, > > LEE BON SHENG | leebonsheng at tm.com.my | ipmc_ipcore at tm.com.my > NOC2 IPCORE, ISP Network Management, Telekom Malaysia, AS4788 > TOLLFREE: 1-800-88-2646 (Opt 4) / International: +603-22466646 (Opt 4) > > > > We're committed to perform. > We strive to excel. > We deliver THE BEST! Regards, Marty Strong -------------------------------------- CloudFlare - AS13335 Network Engineer marty at cloudflare.com +44 20 3514 6970 UK (Office) +44 7584 906 055 UK (Mobile) +1 888 993 5273 US (Office) smartflare (Skype) http://www.peeringdb.com/view.php?asn=13335 > On 12 Jun 2015, at 10:41, Stephane Bortzmeyer wrote: > > On Fri, Jun 12, 2015 at 11:09:34AM +0200, > Tore Anderson wrote > a message of 10 lines which said: > >> I see tons of bogus routes show up with AS4788 in the path, and at >> least AS3549 is acceping them. >> >> E.g. for the RIPE NCC (193.0.0.0/21): >> >> [BGP/170] 00:20:29, MED 1000, localpref 150 >> AS path: 3549 4788 12859 3333 I, validation-state: valid > > Unlike most BGP leaks, they kept the proper origin, so validation by ROA was > useless :-( From db at rrbone.net Fri Jun 12 10:16:45 2015 From: db at rrbone.net (Dominik Bay) Date: Fri, 12 Jun 2015 11:16:45 +0100 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> Message-ID: <557AB18D.904@rrbone.net> On 06/12/2015 10:43 AM, Marty Strong via NANOG wrote: > It *looks* like GBLX stopped accepting the leak I think you just saw it flapping. :-) That's what I've been seeing since ~ 0845 UTC :-( -- rrbone UG (haftungsbeschraenkt) - Leibnizstr. 8a - 44147 Dortmund HR B 23168 Amtsgericht Dortmund - Geschaeftsfuehrer: Dominik Bay From job at instituut.net Fri Jun 12 10:18:38 2015 From: job at instituut.net (Job Snijders) Date: Fri, 12 Jun 2015 12:18:38 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> Message-ID: <20150612101838.GI94733@Vurt.local> On Fri, Jun 12, 2015 at 10:43:09AM +0100, Marty Strong via NANOG wrote: > It *looks* like GBLX stopped accepting the leak. I disagree. Since 08:44 UTC up until now (10:15) the DFZ has been a radio-active wasteland with hordes of unwelcome announcements. Kind regards, Job From marty at cloudflare.com Fri Jun 12 10:22:09 2015 From: marty at cloudflare.com (Marty Strong) Date: Fri, 12 Jun 2015 11:22:09 +0100 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <20150612101838.GI94733@Vurt.local> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> <20150612101838.GI94733@Vurt.local> Message-ID: <111DF8D2-36BF-463A-9CB4-566DE933B74E@cloudflare.com> Yes, you?re right, I was too trigger happy :( Regards, Marty Strong -------------------------------------- CloudFlare - AS13335 Network Engineer marty at cloudflare.com +44 20 3514 6970 UK (Office) +44 7584 906 055 UK (Mobile) +1 888 993 5273 US (Office) smartflare (Skype) http://www.peeringdb.com/view.php?asn=13335 > On 12 Jun 2015, at 11:18, Job Snijders wrote: > > On Fri, Jun 12, 2015 at 10:43:09AM +0100, Marty Strong via NANOG wrote: >> It *looks* like GBLX stopped accepting the leak. > > I disagree. Since 08:44 UTC up until now (10:15) the DFZ has been a > radio-active wasteland with hordes of unwelcome announcements. > > Kind regards, > > Job From millnert at gmail.com Fri Jun 12 10:24:06 2015 From: millnert at gmail.com (Martin Millnert) Date: Fri, 12 Jun 2015 12:24:06 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> Message-ID: <1434104646.6144.139.camel@galileo.millnert.se> On Fri, 2015-06-12 at 10:43 +0100, Marty Strong via NANOG wrote: > It *looks* like GBLX stopped accepting the leak. Nope. Churn is ongoing, nothing has been fixed. Global outage began 08:44 UTC and is still ongoing. It's been so long people have now had time to come up with things like "33.333%". Also, possible explanation for why nobody's fixing it: https://twitter.com/TMCorp/status/609167065300271104 :) /M -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From job at instituut.net Fri Jun 12 10:46:53 2015 From: job at instituut.net (Job Snijders) Date: Fri, 12 Jun 2015 12:46:53 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <20150612101838.GI94733@Vurt.local> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> <20150612101838.GI94733@Vurt.local> Message-ID: <20150612104653.GJ94733@Vurt.local> On Fri, Jun 12, 2015 at 12:18:38PM +0200, Job Snijders wrote: > On Fri, Jun 12, 2015 at 10:43:09AM +0100, Marty Strong via NANOG wrote: > > It *looks* like GBLX stopped accepting the leak. > > I disagree. Since 08:44 UTC up until now (10:15) the DFZ has been a > radio-active wasteland with hordes of unwelcome announcements. OK, as of now (~ 10:40) UTC things look normalised. Kind regards, Job From rdobbins at arbor.net Fri Jun 12 10:47:59 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 12 Jun 2015 17:47:59 +0700 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <20150612104653.GJ94733@Vurt.local> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> <20150612101838.GI94733@Vurt.local> <20150612104653.GJ94733@Vurt.local> Message-ID: <77F7D250-5B0C-46E0-ACFA-B4D2581EA286@arbor.net> On 12 Jun 2015, at 17:46, Job Snijders wrote: > OK, as of now (~ 10:40) UTC things look normalised. Just got off the phone, I think things may be in hand, now. ----------------------------------- Roland Dobbins From chris.burton at speakeasy.net Fri Jun 12 11:18:05 2015 From: chris.burton at speakeasy.net (Chris Burton) Date: Fri, 12 Jun 2015 04:18:05 -0700 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <1434104646.6144.139.camel@galileo.millnert.se> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> <1434104646.6144.139.camel@galileo.millnert.se> Message-ID: <008a01d0a501$75833db0$6089b910$@speakeasy.net> Still on hold with Level3, but some of my sites are clearing up. Chris -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Martin Millnert Sent: Friday, June 12, 2015 3:24 AM To: Marty Strong Cc: NANOG Subject: Re: AS4788 Telecom Malaysia major route leak? On Fri, 2015-06-12 at 10:43 +0100, Marty Strong via NANOG wrote: > It *looks* like GBLX stopped accepting the leak. Nope. Churn is ongoing, nothing has been fixed. Global outage began 08:44 UTC and is still ongoing. It's been so long people have now had time to come up with things like "33.333%". Also, possible explanation for why nobody's fixing it: https://twitter.com/TMCorp/status/609167065300271104 :) /M From sebastian at karotte.org Fri Jun 12 11:21:14 2015 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Fri, 12 Jun 2015 13:21:14 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <77F7D250-5B0C-46E0-ACFA-B4D2581EA286@arbor.net> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> <20150612101838.GI94733@Vurt.local> <20150612104653.GJ94733@Vurt.local> <77F7D250-5B0C-46E0-ACFA-B4D2581EA286@arbor.net> Message-ID: <20150612112114.GA6837@danton.fire-world.de> * Roland Dobbins [2015-06-12 12:57]: > > On 12 Jun 2015, at 17:46, Job Snijders wrote: > > > OK, as of now (~ 10:40) UTC things look normalised. > > Just got off the phone, I think things may be in hand, now. Still seeing a lot more updates than usual: http://www.karotte.org/pics/bgp-stability-2.png Is this just folks turning up their sessions again? Looks a bit much... Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From chris at mxtelecom.com Fri Jun 12 11:24:44 2015 From: chris at mxtelecom.com (Chris Wilson) Date: Fri, 12 Jun 2015 12:24:44 +0100 (BST) Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612094130.GA24974@nic.fr> Message-ID: > These aren't just leaks - they're more specifics of what's normally > advertised, but keeping the proper origin. Hard to see how that could be > accidental... Having looked further - the examples of these I was looking at (advertisements from AS34556 & AS17709) were being advertised before the leak, but only with limited visibility. The leak caused them to be (intermittently) globally visible. Tin foil hat off - can all just be accidental. Chris > On Fri, 12 Jun 2015, Stephane Bortzmeyer wrote: > >> On Fri, Jun 12, 2015 at 11:09:34AM +0200, >> Tore Anderson wrote >> a message of 10 lines which said: >> >>> I see tons of bogus routes show up with AS4788 in the path, and at >>> least AS3549 is acceping them. >>> >>> E.g. for the RIPE NCC (193.0.0.0/21): >>> >>> [BGP/170] 00:20:29, MED 1000, localpref 150 >>> AS path: 3549 4788 12859 3333 I, validation-state: >>> valid >> >> Unlike most BGP leaks, they kept the proper origin, so validation by ROA >> was >> useless :-( >> > From job at instituut.net Fri Jun 12 11:27:07 2015 From: job at instituut.net (Job Snijders) Date: Fri, 12 Jun 2015 13:27:07 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <20150612112114.GA6837@danton.fire-world.de> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> <20150612101838.GI94733@Vurt.local> <20150612104653.GJ94733@Vurt.local> <77F7D250-5B0C-46E0-ACFA-B4D2581EA286@arbor.net> <20150612112114.GA6837@danton.fire-world.de> Message-ID: <20150612112707.GL94733@Vurt.local> On Fri, Jun 12, 2015 at 01:21:14PM +0200, Sebastian Wiesinger wrote: > * Roland Dobbins [2015-06-12 12:57]: > > > > On 12 Jun 2015, at 17:46, Job Snijders wrote: > > > > > OK, as of now (~ 10:40) UTC things look normalised. > > > > Just got off the phone, I think things may be in hand, now. > > Still seeing a lot more updates than usual: > > http://www.karotte.org/pics/bgp-stability-2.png > > Is this just folks turning up their sessions again? Looks a bit > much... Yes, I suspect tons of 3356 / 3549 customers shut down their BGP sessions waiting for the storm to blow over. I expect more churn then usual the next 6 ~ 12 hours, due to customers slowly turning session back on. Kind regards, Job From alessandro.martins at gmail.com Fri Jun 12 11:49:22 2015 From: alessandro.martins at gmail.com (Alessandro Martins) Date: Fri, 12 Jun 2015 08:49:22 -0300 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <20150612112707.GL94733@Vurt.local> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> <20150612101838.GI94733@Vurt.local> <20150612104653.GJ94733@Vurt.local> <77F7D250-5B0C-46E0-ACFA-B4D2581EA286@arbor.net> <20150612112114.GA6837@danton.fire-world.de> <20150612112707.GL94733@Vurt.local> Message-ID: First news: http://www.xgn.nl/nieuws/69593/grote-internetstoring-in-europa-problemen-door-route-leak -- Alessandro Martins +55 11 94715-4700 On Fri, Jun 12, 2015 at 8:27 AM, Job Snijders wrote: > On Fri, Jun 12, 2015 at 01:21:14PM +0200, Sebastian Wiesinger wrote: > > * Roland Dobbins [2015-06-12 12:57]: > > > > > > On 12 Jun 2015, at 17:46, Job Snijders wrote: > > > > > > > OK, as of now (~ 10:40) UTC things look normalised. > > > > > > Just got off the phone, I think things may be in hand, now. > > > > Still seeing a lot more updates than usual: > > > > http://www.karotte.org/pics/bgp-stability-2.png > > > > Is this just folks turning up their sessions again? Looks a bit > > much... > > Yes, I suspect tons of 3356 / 3549 customers shut down their BGP > sessions waiting for the storm to blow over. I expect more churn then > usual the next 6 ~ 12 hours, due to customers slowly turning session > back on. > > Kind regards, > > Job > From lorenzo.rossi at iit.cnr.it Fri Jun 12 12:40:41 2015 From: lorenzo.rossi at iit.cnr.it (Lorenzo Rossi) Date: Fri, 12 Jun 2015 14:40:41 +0200 Subject: Huge Level 3 ipv4 issues? In-Reply-To: <92CCD6CC-0CA6-464B-A717-0D2E41F1E0B6@prolocation.net> References: <92CCD6CC-0CA6-464B-A717-0D2E41F1E0B6@prolocation.net> Message-ID: <557AD349.4070807@iit.cnr.it> Hi David, yes. We are connected to Level3 pop in Milan and we are experiencing the same kind of issues with IPv4. IPv6 seems to be working fine. Regards, Lorenzo On 12/06/15 12:07, Raymond Dijkxhoorn wrote: > Hai David, > >> Op 12 jun. 2015 om 10:51 heeft David Hubbard het volgende geschreven: >> >> Experiencing packetloss all over the place (chicago, tampa, atlanta) on >> Level 3's network; can't even reach them from Brighthouse residential. >> IPv6 seems to still be working fine, but of course Brighthouse doesn't >> offer that lol. >> >> Anyone seeing the same? >> >> David > > Yes. See also another thread here: > > http://mailman.nanog.org/pipermail/nanog/2015-June/076189.html > > Thanks, > Raymond Dijkxhoorn - Prolication > From sebastian at karotte.org Fri Jun 12 12:36:38 2015 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Fri, 12 Jun 2015 14:36:38 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <20150612112707.GL94733@Vurt.local> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> <20150612101838.GI94733@Vurt.local> <20150612104653.GJ94733@Vurt.local> <77F7D250-5B0C-46E0-ACFA-B4D2581EA286@arbor.net> <20150612112114.GA6837@danton.fire-world.de> <20150612112707.GL94733@Vurt.local> Message-ID: <20150612123638.GA18041@danton.fire-world.de> * Job Snijders [2015-06-12 13:30]: > Yes, I suspect tons of 3356 / 3549 customers shut down their BGP > sessions waiting for the storm to blow over. I expect more churn then > usual the next 6 ~ 12 hours, due to customers slowly turning session > back on. Yes. It's nice and stable now. http://www.karotte.org/pics/bgp-stability-3.png So after this interesting morning let's hope for a boring weekend. :) Let's wait and see what explanation will be given for this hiccup. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From jj at anexia.at Fri Jun 12 13:25:40 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Fri, 12 Jun 2015 13:25:40 +0000 Subject: AS4788 Telecom Malaysia major route leak? Message-ID: http://www.bgpmon.net/massive-route-leak-cause-internet-slowdown/ J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 From rps at maine.edu Fri Jun 12 14:07:52 2015 From: rps at maine.edu (Ray Soucy) Date: Fri, 12 Jun 2015 10:07:52 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <38976.1434092757@turing-police.cc.vt.edu> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <38976.1434092757@turing-police.cc.vt.edu> Message-ID: The only thing I would add is that DHCPv6 is not just about "tracking" clients. Yes there are ways to do so using SLAAC, but they are not pretty. Giving too much weight to tracking being the reason for DHCPv6 is just as bad as giving too much weight to tethering as the reason against it. It skews the conversation. For us, DHCPv6 is about *operational consistency*. Universities have been running with the end-to-end model everyone is looking to IPv6 to restore for a very long time. When you connect to our network, wired or wireless, you get a public IP with no filtering in place in most cases. We have been living the end-to-end model, and that has given us operational experience and insight on what it actually takes to support access networks using this model. Almost every peer institution I talk to has implemented custom systems refined over decades to preserve the end-to-end model in a time of increasing security incidents and liability. These include IPAM systems, which feed into vulnerability scanning, or host filtering for incident response, etc. These systems are in place for IPv4, and modifying them to support IPv6 (which most of us have done) is relatively easy in the case of DHCPv6. By maintaining consistency between IPv4 and IPv6 we avoid having to retrain hundreds of IT workers on supporting connectivity. By saying that you won't support DHCPv6, you effectively force us into a choice between investing considerable effort in redesigning systems and training IT personnel, while introducing confusion in the support process because IPv4 and IPv6 are delivered using completely different methods. You have just made it cheaper for us to turn to NAT than to support IPv6. That's unacceptable. You might be thinking "well that's just universities and a small percent of users", but the point here is that we do these things for a reason; we've been living without NAT and our collective operational experience doing so is something that would be wise to take into consideration instead of dismissing it or trying to call us names. Organizations running SLAAC who say everything is fine, think everything is fine because IPv6 has received almost no attention from bad actors in terms of security incidents or denial of service attacks. Even well known servers with IPv6 addresses on our network rarely see SSH attempts over IPv6 today. *This will fundamentally change as IPv6 adoption grows*. Are you prepared to be able to deal with abuse reports of hosts on your network participating on denial of service attacks? Can you associate the identity of a system to an individual when law enforcement demands you to do so? How much longer will it take you to track down a host by its IPv6 address to disable it? How many other users have degraded service while they're waiting for you to do that? For most people that are used to the typical IPv4 model (NAT and open pool DHCP), these events are very infrequent, so of course they don't get it. For those of us running a more liberal network which preserves the end-to-end model, free from aggressive filtering on user traffic, these incidents are literally daily occurrences. The fact is that you never know what service a user might enable on their device only to be exploited and degrade service for their peers. So yes, we are looking to the future in the case of DHCPv6, because we've learned from the past. On Fri, Jun 12, 2015 at 3:05 AM, wrote: > On Fri, 12 Jun 2015 02:07:22 -0000, Laszlo Hanyecz said: > > > > > university net nazis > > > > > > Did you really just write that? > > > > > > > As far as "net nazi", I meant it in the same sense as a BOFH. Someone > who is > > intentionally degrading a user's experience by using technical means to > block > > specifically targeted applications or behaviors. > > Well, which is more BOFH-ish: > > 1) We insist that you connect in a way that allows us to identify and track > you for DMCA and other legal requirements that, quite frankly, we'd really > rather not have to do, but it's a cost of doing business. > > 2) We don't let you connect at all because we can't do so without exposing > ourselves to more legal liability than we want. > > Besides which, that's a total red herring. > > If you actually go back and *read*, I don't think anybody's "intentionally > degrading by blocking targeted applications" - except those who are > refusing > to provide features to allow the applications to work on more network > configs. > The vast majority of us would *prefer* that Android got fixed so it can > ask for > more addresses and do more stuff. Most of us don't *care* if a user sucks > up 13 > adresses across 4 devices at the same time - IPv6 addresses are *cheap*. > On the other hand, covering your ass when a subpoena shows up and you > realize > you don't have the data needed to point at the user they're *really* > looking > for is incredibly expensive. > > OK? Let me say that again: We're all asking Google to quit being stubborn > and add a feature to Android so we can make the user experience *better*. > > Now who you calling a BOFH? > > > On the other hand, if it becomes common and acceptable to use DHCPv6 to > > provide a single address only > > I encourage my competitor universities to design their networks that way. > :) > -- 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 charles at phukish.com Fri Jun 12 14:58:55 2015 From: charles at phukish.com (Charles van Niman) Date: Fri, 12 Jun 2015 09:58:55 -0500 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: Message-ID: Does anyone at Level3 care to comment here about this event, and if there are any plans to push BGP prefix security? 2015-06-12 8:25 GMT-05:00 J?rgen Jaritsch : > http://www.bgpmon.net/massive-route-leak-cause-internet-slowdown/ > > > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > From bortzmeyer at nic.fr Fri Jun 12 15:09:23 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 12 Jun 2015 17:09:23 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: Message-ID: <20150612150923.GA3549@nic.fr> On Fri, Jun 12, 2015 at 09:58:55AM -0500, Charles van Niman wrote a message of 25 lines which said: > Does anyone at Level3 care to comment here about this event, https://twitter.com/Level3/status/609353696787496960 From james.cutler at consultant.com Fri Jun 12 15:18:21 2015 From: james.cutler at consultant.com (James R Cutler) Date: Fri, 12 Jun 2015 11:18:21 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <38976.1434092757@turing-police.cc.vt.edu> Message-ID: Ray Soucy has given us an nice summary. It goes along with ?please let me manage my business and don?t take away my tools just to satisfy your prejudices.? Selection of management policies and implementations is ALWAYS a local issue (assuming consideration of legal necessities). Especially in the end-to-end model, the requirements management of end systems has not changed because the IP layer protocol has changed. This is a good reason for not prohibiting continuing use of DHCP-based solutions. ?Purity of protocols? is not a reason for increasing management costs such as described by Ray. This debate about DHCPv6 has been going on far too long. I want to know how much it will cost the ?SLAAC-only? faction to quit fighting DHCPv6. My conjecture is that it would be minimal, especially as compared to the costs for the activities described by Ray. Putting it differently: What business purpose is served by fighting full-functioned DHCPv6 deployment. Don?t give me any RFC or protocol arguments - just tell me the business reasons for forcing others to change how they manage their business. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu > On Jun 12, 2015, at 10:07 AM, Ray Soucy wrote: > > The only thing I would add is that DHCPv6 is not just about "tracking" > clients. Yes there are ways to do so using SLAAC, but they are not pretty. > > Giving too much weight to tracking being the reason for DHCPv6 is just as > bad as giving too much weight to tethering as the reason against it. It > skews the conversation. > > For us, DHCPv6 is about *operational consistency*. > > Universities have been running with the end-to-end model everyone is > looking to IPv6 to restore for a very long time. > > When you connect to our network, wired or wireless, you get a public IP > with no filtering in place in most cases. > > We have been living the end-to-end model, and that has given us operational > experience and insight on what it actually takes to support access networks > using this model. > > Almost every peer institution I talk to has implemented custom systems > refined over decades to preserve the end-to-end model in a time of > increasing security incidents and liability. These include IPAM systems, > which feed into vulnerability scanning, or host filtering for incident > response, etc. > > These systems are in place for IPv4, and modifying them to support IPv6 > (which most of us have done) is relatively easy in the case of DHCPv6. > > By maintaining consistency between IPv4 and IPv6 we avoid having to retrain > hundreds of IT workers on supporting connectivity. By saying that you > won't support DHCPv6, you effectively force us into a choice between > investing considerable effort in redesigning systems and training IT > personnel, while introducing confusion in the support process because IPv4 > and IPv6 are delivered using completely different methods. > > You have just made it cheaper for us to turn to NAT than to support IPv6. > That's unacceptable. > > You might be thinking "well that's just universities and a small percent of > users", but the point here is that we do these things for a reason; we've > been living without NAT and our collective operational experience doing so > is something that would be wise to take into consideration instead of > dismissing it or trying to call us names. > > Organizations running SLAAC who say everything is fine, think everything is > fine because IPv6 has received almost no attention from bad actors in terms > of security incidents or denial of service attacks. Even well known > servers with IPv6 addresses on our network rarely see SSH attempts over > IPv6 today. > > *This will fundamentally change as IPv6 adoption grows*. > > Are you prepared to be able to deal with abuse reports of hosts on your > network participating on denial of service attacks? Can you associate the > identity of a system to an individual when law enforcement demands you to > do so? How much longer will it take you to track down a host by its IPv6 > address to disable it? How many other users have degraded service while > they're waiting for you to do that? > > For most people that are used to the typical IPv4 model (NAT and open pool > DHCP), these events are very infrequent, so of course they don't get it. > For those of us running a more liberal network which preserves the > end-to-end model, free from aggressive filtering on user traffic, these > incidents are literally daily occurrences. > > The fact is that you never know what service a user might enable on their > device only to be exploited and degrade service for their peers. > > So yes, we are looking to the future in the case of DHCPv6, because we've > learned from the past. > > > > > > On Fri, Jun 12, 2015 at 3:05 AM, wrote: > >> On Fri, 12 Jun 2015 02:07:22 -0000, Laszlo Hanyecz said: >> >>>>> university net nazis >>>> >>>> Did you really just write that? >>>> >>> >>> As far as "net nazi", I meant it in the same sense as a BOFH. Someone >> who is >>> intentionally degrading a user's experience by using technical means to >> block >>> specifically targeted applications or behaviors. >> >> Well, which is more BOFH-ish: >> >> 1) We insist that you connect in a way that allows us to identify and track >> you for DMCA and other legal requirements that, quite frankly, we'd really >> rather not have to do, but it's a cost of doing business. >> >> 2) We don't let you connect at all because we can't do so without exposing >> ourselves to more legal liability than we want. >> >> Besides which, that's a total red herring. >> >> If you actually go back and *read*, I don't think anybody's "intentionally >> degrading by blocking targeted applications" - except those who are >> refusing >> to provide features to allow the applications to work on more network >> configs. >> The vast majority of us would *prefer* that Android got fixed so it can >> ask for >> more addresses and do more stuff. Most of us don't *care* if a user sucks >> up 13 >> adresses across 4 devices at the same time - IPv6 addresses are *cheap*. >> On the other hand, covering your ass when a subpoena shows up and you >> realize >> you don't have the data needed to point at the user they're *really* >> looking >> for is incredibly expensive. >> >> OK? Let me say that again: We're all asking Google to quit being stubborn >> and add a feature to Android so we can make the user experience *better*. >> >> Now who you calling a BOFH? >> >>> On the other hand, if it becomes common and acceptable to use DHCPv6 to >>> provide a single address only >> >> I encourage my competitor universities to design their networks that way. >> :) >> > > > > -- > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 872 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jra at baylink.com Fri Jun 12 15:20:28 2015 From: jra at baylink.com (Jay Ashworth) Date: Fri, 12 Jun 2015 11:20:28 -0400 Subject: DC Circuit denies stay on Neutrality Message-ID: <37DEDE7D-5E38-4928-B1CE-E3DF30C3573C@baylink.com> Here is a delightful wacky weekend starter culture for you: a backgrounder on exactly what it means that the DC Circuit denied Verizon et alia a stay of execution on Title II reclassification. Complete with bonus brony references. http://www.wetmachine.com/tales-of-the-sausage-factory/net-neutrality-litigation-round-1-goes-to-the-fcc/ Cheers, --jra -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From nanog at ics-il.net Fri Jun 12 15:25:25 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 12 Jun 2015 10:25:25 -0500 (CDT) Subject: DC Circuit denies stay on Neutrality In-Reply-To: <37DEDE7D-5E38-4928-B1CE-E3DF30C3573C@baylink.com> Message-ID: <10808022.1505.1434122748828.JavaMail.mhammett@ThunderFuck> It wasn't only the big guys requesting a stay. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Jay Ashworth" To: nanog at nanog.org Sent: Friday, June 12, 2015 10:20:28 AM Subject: DC Circuit denies stay on Neutrality Here is a delightful wacky weekend starter culture for you: a backgrounder on exactly what it means that the DC Circuit denied Verizon et alia a stay of execution on Title II reclassification. Complete with bonus brony references. http://www.wetmachine.com/tales-of-the-sausage-factory/net-neutrality-litigation-round-1-goes-to-the-fcc/ Cheers, --jra -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From jimpop at gmail.com Fri Jun 12 15:28:45 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Fri, 12 Jun 2015 11:28:45 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <38976.1434092757@turing-police.cc.vt.edu> Message-ID: On Fri, Jun 12, 2015 at 11:18 AM, James R Cutler wrote: > ?please let me manage my business and don?t take away my tools just to satisfy your prejudices.? There are probably several ways to interpret that in ways you hadn't considered for this discussion, I can think of a few. They are: - Who is taking away what from who in a University, in order to save who's $$? :-) - Suppression of hate talk/art/literature has historically been used to restrict some businesses for the greater good of mankind. -Jim P. From toddunder at gmail.com Fri Jun 12 15:30:31 2015 From: toddunder at gmail.com (Todd Underwood) Date: Fri, 12 Jun 2015 11:30:31 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <38976.1434092757@turing-police.cc.vt.edu> Message-ID: lorenzo already stated that the cost was in user satisfaction related to tethering and the business reason was the desire to not implement NAT in v6 on android. many people didn't like those reasons or think that they are less important than their own reasons. shockingly, everyone believes that their own priorities are more important than everyone else's priorities. the 'cranky about the lack of DHCPv6' crowd has already made their points and further shut down conversation by demanding that lorenzo speak for Google on this thread. indeed, shouting loudly and shutting down conversation was almost certainly the intent of many of the posts here. so mission accomplished. fists have been pounded. conversation has been halted. well done. can me move on now? t On Fri, Jun 12, 2015 at 11:18 AM, James R Cutler < james.cutler at consultant.com> wrote: > Ray Soucy has given us an nice summary. It goes along with ?please let me > manage my business and don?t take away my tools just to satisfy your > prejudices.? > > Selection of management policies and implementations is ALWAYS a local > issue (assuming consideration of legal necessities). Especially in the > end-to-end model, the requirements management of end systems has not > changed because the IP layer protocol has changed. This is a good reason > for not prohibiting continuing use of DHCP-based solutions. ?Purity of > protocols? is not a reason for increasing management costs such as > described by Ray. > > This debate about DHCPv6 has been going on far too long. I want to know > how much it will cost the ?SLAAC-only? faction to quit fighting DHCPv6. > My conjecture is that it would be minimal, especially as compared to the > costs for the activities described by Ray. > > Putting it differently: What business purpose is served by fighting > full-functioned DHCPv6 deployment. Don?t give me any RFC or protocol > arguments - just tell me the business reasons for forcing others to change > how they manage their business. > > James R. Cutler > James.cutler at consultant.com > PGP keys at http://pgp.mit.edu > > > > > On Jun 12, 2015, at 10:07 AM, Ray Soucy wrote: > > > > The only thing I would add is that DHCPv6 is not just about "tracking" > > clients. Yes there are ways to do so using SLAAC, but they are not > pretty. > > > > Giving too much weight to tracking being the reason for DHCPv6 is just as > > bad as giving too much weight to tethering as the reason against it. It > > skews the conversation. > > > > For us, DHCPv6 is about *operational consistency*. > > > > Universities have been running with the end-to-end model everyone is > > looking to IPv6 to restore for a very long time. > > > > When you connect to our network, wired or wireless, you get a public IP > > with no filtering in place in most cases. > > > > We have been living the end-to-end model, and that has given us > operational > > experience and insight on what it actually takes to support access > networks > > using this model. > > > > Almost every peer institution I talk to has implemented custom systems > > refined over decades to preserve the end-to-end model in a time of > > increasing security incidents and liability. These include IPAM systems, > > which feed into vulnerability scanning, or host filtering for incident > > response, etc. > > > > These systems are in place for IPv4, and modifying them to support IPv6 > > (which most of us have done) is relatively easy in the case of DHCPv6. > > > > By maintaining consistency between IPv4 and IPv6 we avoid having to > retrain > > hundreds of IT workers on supporting connectivity. By saying that you > > won't support DHCPv6, you effectively force us into a choice between > > investing considerable effort in redesigning systems and training IT > > personnel, while introducing confusion in the support process because > IPv4 > > and IPv6 are delivered using completely different methods. > > > > You have just made it cheaper for us to turn to NAT than to support IPv6. > > That's unacceptable. > > > > You might be thinking "well that's just universities and a small percent > of > > users", but the point here is that we do these things for a reason; we've > > been living without NAT and our collective operational experience doing > so > > is something that would be wise to take into consideration instead of > > dismissing it or trying to call us names. > > > > Organizations running SLAAC who say everything is fine, think everything > is > > fine because IPv6 has received almost no attention from bad actors in > terms > > of security incidents or denial of service attacks. Even well known > > servers with IPv6 addresses on our network rarely see SSH attempts over > > IPv6 today. > > > > *This will fundamentally change as IPv6 adoption grows*. > > > > Are you prepared to be able to deal with abuse reports of hosts on your > > network participating on denial of service attacks? Can you associate > the > > identity of a system to an individual when law enforcement demands you to > > do so? How much longer will it take you to track down a host by its IPv6 > > address to disable it? How many other users have degraded service while > > they're waiting for you to do that? > > > > For most people that are used to the typical IPv4 model (NAT and open > pool > > DHCP), these events are very infrequent, so of course they don't get it. > > For those of us running a more liberal network which preserves the > > end-to-end model, free from aggressive filtering on user traffic, these > > incidents are literally daily occurrences. > > > > The fact is that you never know what service a user might enable on their > > device only to be exploited and degrade service for their peers. > > > > So yes, we are looking to the future in the case of DHCPv6, because we've > > learned from the past. > > > > > > > > > > > > On Fri, Jun 12, 2015 at 3:05 AM, wrote: > > > >> On Fri, 12 Jun 2015 02:07:22 -0000, Laszlo Hanyecz said: > >> > >>>>> university net nazis > >>>> > >>>> Did you really just write that? > >>>> > >>> > >>> As far as "net nazi", I meant it in the same sense as a BOFH. Someone > >> who is > >>> intentionally degrading a user's experience by using technical means to > >> block > >>> specifically targeted applications or behaviors. > >> > >> Well, which is more BOFH-ish: > >> > >> 1) We insist that you connect in a way that allows us to identify and > track > >> you for DMCA and other legal requirements that, quite frankly, we'd > really > >> rather not have to do, but it's a cost of doing business. > >> > >> 2) We don't let you connect at all because we can't do so without > exposing > >> ourselves to more legal liability than we want. > >> > >> Besides which, that's a total red herring. > >> > >> If you actually go back and *read*, I don't think anybody's > "intentionally > >> degrading by blocking targeted applications" - except those who are > >> refusing > >> to provide features to allow the applications to work on more network > >> configs. > >> The vast majority of us would *prefer* that Android got fixed so it can > >> ask for > >> more addresses and do more stuff. Most of us don't *care* if a user > sucks > >> up 13 > >> adresses across 4 devices at the same time - IPv6 addresses are *cheap*. > >> On the other hand, covering your ass when a subpoena shows up and you > >> realize > >> you don't have the data needed to point at the user they're *really* > >> looking > >> for is incredibly expensive. > >> > >> OK? Let me say that again: We're all asking Google to quit being > stubborn > >> and add a feature to Android so we can make the user experience > *better*. > >> > >> Now who you calling a BOFH? > >> > >>> On the other hand, if it becomes common and acceptable to use DHCPv6 to > >>> provide a single address only > >> > >> I encourage my competitor universities to design their networks that > way. > >> :) > >> > > > > > > > > -- > > 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 millnert at gmail.com Fri Jun 12 15:32:31 2015 From: millnert at gmail.com (Martin Millnert) Date: Fri, 12 Jun 2015 17:32:31 +0200 Subject: Open letter to Level3 concerning the global routing issues on June 12th Message-ID: <1434123151.30267.12.camel@galileo.millnert.se> Dear Level3, The Internet is a cooperative effort, and it works well only when its participants take constructive actions to address errors and remedy problems. Your position as a major Internet Carrier bestows upon you a certain degree of responsibility for the correct operation of the Internet all across (and beyond) the planet. You have many customers. Customers will always occasionally make mistakes. You as a major Internet Carrier have a responsibility to limit, not amplify, your customers' mistakes. Other major carriers implement technical measures that severely limits the damages from customer mistakes from having global impact. Other major carriers also implement operational procedures in addition to technical measures. In combination, these measures drastically reduce the outage-hours as a result of customer configuration errors. At 08:44 UTC on Friday 12th of June, one of your transit customers, Telekom Malaysia (AS4788) began announcing the full Internet table back to you, which you accepted and propagated to your peers and customers, causing global outages for close to 3 hours. [ https://twitter.com/DynResearch/status/609340592036970496 ] During this 3 hour window, it appears (from your own service outage reports) that you did nothing to stop the global Internet outage, but that Telekom Malaysia themselves eventually resolved it. This lack of action on your end, and your disregard for the correct operation of the global Internet is astonishing. These mistakes do not need to happen. AS4788 under normal circumstances announces ~1900 IPv4 prefixes to the Internet. You accepted multiple hundred thousand prefixes from them - a max prefix setting would have severely limited the damage. We expect that these are your practices as well, but they failed. When they do, it should not take ~3 hours to shut down the session(s). Many operators, in despair, turned down their peering sessions with you once it was clear you were causing the outages and no immediate fix was in sight. This improved the situation for some - but not all did. Had you deployed proper IRR-filtering to filter the bad announcements the impact would've been far less critical. As a direct consequence of your ~3 hours of inaction, as a local example, Swedish payment terminals were experiencing problems all over the country. The Swedish economy was directly affected by your inaction. There were queues when I was buying lunch! Imagine the food rage. The situation was probably similar at other places around the globe where people were awake. Operators around the planet are curious: - Did Level3 not detect or understand that it was causing global Internet outages for ~3 hours? - If Level3 did in fact detect or understand it was causing global Internet outages, why did it not properly and immediately remedy the situation? - What is Level3 going to do to address these questions and begin work on restoring its credibility as a carrier? We all understand that mistakes do happen (in applying customer interface templates, etc.). However the Internet is all too pervasive in everyday life today for anything but swift action by carriers to remedy breakage after the fact. It is absolutely not sufficient to let a customer spend 3 hours to detect and fix a situation like this one. It is unacceptable that no swift action was taken on your end to limit the global routing issues you caused. Sincerely, Martin Millnert Member of Internet Community - no carrier / ISP affiliation. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From utkarsh.gosain at tatacommunications.com Fri Jun 12 15:43:04 2015 From: utkarsh.gosain at tatacommunications.com (Utkarsh Gosain) Date: Fri, 12 Jun 2015 15:43:04 +0000 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: <1434123151.30267.12.camel@galileo.millnert.se> References: <1434123151.30267.12.camel@galileo.millnert.se> Message-ID: <0681034898E36F448ACAA0EF289BAB7A0186A7AF2A@inp44vdag03.vsnl.co.in> Hi Martin I am not a spokesperson on behalf of L3 but I have worked for big telcos my whole career and my recommendation is to raise a trouble ticket if any one on the forum is their customer and is affected. I don?t think Engineers at NOC are authorized to reply to forums at any of the major telcos especially regarding outages unless someone raise a trouble ticket and seeks an RCA of the issue one on one with them. Utkarsh Gosain Global Acc Director Tata Communications -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Martin Millnert Sent: Friday, June 12, 2015 11:33 AM To: NANOG Subject: Open letter to Level3 concerning the global routing issues on June 12th Dear Level3, The Internet is a cooperative effort, and it works well only when its participants take constructive actions to address errors and remedy problems. Your position as a major Internet Carrier bestows upon you a certain degree of responsibility for the correct operation of the Internet all across (and beyond) the planet. You have many customers. Customers will always occasionally make mistakes. You as a major Internet Carrier have a responsibility to limit, not amplify, your customers' mistakes. Other major carriers implement technical measures that severely limits the damages from customer mistakes from having global impact. Other major carriers also implement operational procedures in addition to technical measures. In combination, these measures drastically reduce the outage-hours as a result of customer configuration errors. At 08:44 UTC on Friday 12th of June, one of your transit customers, Telekom Malaysia (AS4788) began announcing the full Internet table back to you, which you accepted and propagated to your peers and customers, causing global outages for close to 3 hours. [ https://twitter.com/DynResearch/status/609340592036970496 ] During this 3 hour window, it appears (from your own service outage reports) that you did nothing to stop the global Internet outage, but that Telekom Malaysia themselves eventually resolved it. This lack of action on your end, and your disregard for the correct operation of the global Internet is astonishing. These mistakes do not need to happen. AS4788 under normal circumstances announces ~1900 IPv4 prefixes to the Internet. You accepted multiple hundred thousand prefixes from them - a max prefix setting would have severely limited the damage. We expect that these are your practices as well, but they failed. When they do, it should not take ~3 hours to shut down the session(s). Many operators, in despair, turned down their peering sessions with you once it was clear you were causing the outages and no immediate fix was in sight. This improved the situation for some - but not all did. Had you deployed proper IRR-filtering to filter the bad announcements the impact would've been far less critical. As a direct consequence of your ~3 hours of inaction, as a local example, Swedish payment terminals were experiencing problems all over the country. The Swedish economy was directly affected by your inaction. There were queues when I was buying lunch! Imagine the food rage. The situation was probably similar at other places around the globe where people were awake. Operators around the planet are curious: - Did Level3 not detect or understand that it was causing global Internet outages for ~3 hours? - If Level3 did in fact detect or understand it was causing global Internet outages, why did it not properly and immediately remedy the situation? - What is Level3 going to do to address these questions and begin work on restoring its credibility as a carrier? We all understand that mistakes do happen (in applying customer interface templates, etc.). However the Internet is all too pervasive in everyday life today for anything but swift action by carriers to remedy breakage after the fact. It is absolutely not sufficient to let a customer spend 3 hours to detect and fix a situation like this one. It is unacceptable that no swift action was taken on your end to limit the global routing issues you caused. Sincerely, Martin Millnert Member of Internet Community - no carrier / ISP affiliation. From cma at cmadams.net Fri Jun 12 15:47:46 2015 From: cma at cmadams.net (Chris Adams) Date: Fri, 12 Jun 2015 10:47:46 -0500 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <38976.1434092757@turing-police.cc.vt.edu> Message-ID: <20150612154746.GA28917@cmadams.net> Once upon a time, Todd Underwood said: > lorenzo already stated that the cost was in user satisfaction related to > tethering and the business reason was the desire to not implement NAT in v6 > on android. So, just to roll back for a second, I hadn't really thought about what was being discussed exactly. This is about connecting an Android device to wifi, right? I didn't think you could have an Android device connect to wifi _and_ tether at the same time; when I turn on the hotspot on my phone, it disables wifi client mode (automatically disconnects from any wifi AP) to enable AP mode. I'm pretty sure that's the way all my Android phones have worked. Why is this an issue (i.e. what am I missing)? -- Chris Adams From deleskie at gmail.com Fri Jun 12 15:53:13 2015 From: deleskie at gmail.com (jim deleskie) Date: Fri, 12 Jun 2015 12:53:13 -0300 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: <0681034898E36F448ACAA0EF289BAB7A0186A7AF2A@inp44vdag03.vsnl.co.in> References: <1434123151.30267.12.camel@galileo.millnert.se> <0681034898E36F448ACAA0EF289BAB7A0186A7AF2A@inp44vdag03.vsnl.co.in> Message-ID: People from Big telcom should never reply to mailing lists from work addresses unless specifically allowed, which I suspect TATA doesn't either, based on some direct, buy old knowledge :) Filtering has been a community issue since my days @ MCI being AS3561, often discussed not often enough acted one, I suspect the topic has come up at every "large" NSP I've worked at. Frequently someone complains its "hard" to fix, or router X makes it hard to fix, or customer Y won;t agree, and not enough people stand up to force fix the issues. I've did a preso on it ( while working at TATA) with some other "smart folks" but for all the usual reasons it died on the vine. I don't blame (3) for this but our community as a whole. Many "people/networks" have to not do the "right thing(tm)" for a failure like this to happen. -jim On Fri, Jun 12, 2015 at 12:43 PM, Utkarsh Gosain < utkarsh.gosain at tatacommunications.com> wrote: > Hi Martin > I am not a spokesperson on behalf of L3 but I have worked for big telcos > my whole career and my recommendation is to raise a trouble ticket if any > one on the forum is their customer and is affected. > I don?t think Engineers at NOC are authorized to reply to forums at any of > the major telcos especially regarding outages unless someone raise a > trouble ticket and seeks an RCA of the issue one on one with them. > > > Utkarsh Gosain > Global Acc Director > Tata Communications > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Martin Millnert > Sent: Friday, June 12, 2015 11:33 AM > To: NANOG > Subject: Open letter to Level3 concerning the global routing issues on > June 12th > > Dear Level3, > > The Internet is a cooperative effort, and it works well only when its > participants take constructive actions to address errors and remedy > problems. > Your position as a major Internet Carrier bestows upon you a certain > degree of responsibility for the correct operation of the Internet all > across (and beyond) the planet. You have many customers. Customers will > always occasionally make mistakes. You as a major Internet Carrier have a > responsibility to limit, not amplify, your customers' mistakes. > Other major carriers implement technical measures that severely limits the > damages from customer mistakes from having global impact. > Other major carriers also implement operational procedures in addition to > technical measures. > In combination, these measures drastically reduce the outage-hours as a > result of customer configuration errors. > > At 08:44 UTC on Friday 12th of June, one of your transit customers, > Telekom Malaysia (AS4788) began announcing the full Internet table back to > you, which you accepted and propagated to your peers and customers, causing > global outages for close to 3 hours. > [ https://twitter.com/DynResearch/status/609340592036970496 ] During this > 3 hour window, it appears (from your own service outage > reports) that you did nothing to stop the global Internet outage, but that > Telekom Malaysia themselves eventually resolved it. This lack of action on > your end, and your disregard for the correct operation of the global > Internet is astonishing. These mistakes do not need to happen. > AS4788 under normal circumstances announces ~1900 IPv4 prefixes to the > Internet. You accepted multiple hundred thousand prefixes from them - a max > prefix setting would have severely limited the damage. We expect that these > are your practices as well, but they failed. When they do, it should not > take ~3 hours to shut down the session(s). > > Many operators, in despair, turned down their peering sessions with you > once it was clear you were causing the outages and no immediate fix was in > sight. This improved the situation for some - but not all did. Had you > deployed proper IRR-filtering to filter the bad announcements the impact > would've been far less critical. > > As a direct consequence of your ~3 hours of inaction, as a local example, > Swedish payment terminals were experiencing problems all over the country. > The Swedish economy was directly affected by your inaction. > There were queues when I was buying lunch! Imagine the food rage. The > situation was probably similar at other places around the globe where > people were awake. > > Operators around the planet are curious: > - Did Level3 not detect or understand that it was causing global > Internet outages for ~3 hours? > - If Level3 did in fact detect or understand it was causing global > Internet outages, why did it not properly and immediately remedy the > situation? > - What is Level3 going to do to address these questions and begin work > on restoring its credibility as a carrier? > > We all understand that mistakes do happen (in applying customer interface > templates, etc.). However the Internet is all too pervasive in everyday > life today for anything but swift action by carriers to remedy breakage > after the fact. It is absolutely not sufficient to let a customer spend 3 > hours to detect and fix a situation like this one. It is unacceptable that > no swift action was taken on your end to limit the global routing issues > you caused. > > Sincerely, > Martin Millnert > Member of Internet Community - no carrier / ISP affiliation. > From baldur.norddahl at gmail.com Fri Jun 12 15:53:33 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 12 Jun 2015 17:53:33 +0200 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <38976.1434092757@turing-police.cc.vt.edu> Message-ID: Can someone explain to me how Android uses SLAAC to implement tethering? SLAAC allows the Android device to have as many addresses it wants. But how does that allow it to reshare those address to a tethered device? A tethering device that might itself be running SLAAC or DHCPv6. If the tethering client device was running DHCPv6 the Android phone could proxy that. But with SLAAC the Android has no idea which addresses are in play - unless it implements NAT! We also have the option that the Android is simply doing a layer 2 bridge. In that case, the Android would not care what the tethering client device is doing. Just move the packets. If Google are truly worried about tethering, they would implement something like LISP. It is then possible to provision the tethered device with address space that is totally unrelated to the host network. They gave you only 1 address? Does not matter, we will use that only for the LISP endpoint. Put a /64 on a loopback interface inside the device, so applications can get unlimited addresses as needed. Regards, Baldur From rps at maine.edu Fri Jun 12 15:58:24 2015 From: rps at maine.edu (Ray Soucy) Date: Fri, 12 Jun 2015 11:58:24 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <38976.1434092757@turing-police.cc.vt.edu> Message-ID: Personally my view is that DHCPv6-PD support would be much better for tethering, but I don't get to tell Google how to do that just like they don't get to tell me how to give out addresses. My only request would be if you do implement DHCPv6-PD for tethering, please make it only request a prefix when you actually enable tethering, not as the default. That would be bad for different reasons. Wouldn't the simple play here be for Android to just throw up a message saying "This network does not support tethering" if SLAAC isn't enabled, and to let users complain to local operators if that's something they want? Google doesn't get blamed, operators are happy, and ultimately users have a better experience because the expectations of the network are clear rather than trying something that will likely not work consistently across networks. If the concern is that you don't want to carriers to use DHCPv6 then you could just limit it to 802.11. The point is that there are several options here to address peoples concerns and make IPv6 adoption that much easier, but the position of Google on DHCPv6 support for Android is just another barrier to widespread adoption of IPv6. I honestly appreciate the work Google has been doing for years to promote IPv6 adoption, but they're wrong here. On Fri, Jun 12, 2015 at 11:30 AM, Todd Underwood wrote: > lorenzo already stated that the cost was in user satisfaction related to > tethering and the business reason was the desire to not implement NAT in v6 > on android. > > many people didn't like those reasons or think that they are less > important than their own reasons. > > shockingly, everyone believes that their own priorities are more important > than everyone else's priorities. > > the 'cranky about the lack of DHCPv6' crowd has already made their points > and further shut down conversation by demanding that lorenzo speak for > Google on this thread. indeed, shouting loudly and shutting down > conversation was almost certainly the intent of many of the posts here. so > mission accomplished. > > fists have been pounded. conversation has been halted. well done. > > can me move on now? > > t > > On Fri, Jun 12, 2015 at 11:18 AM, James R Cutler < > james.cutler at consultant.com> wrote: > >> Ray Soucy has given us an nice summary. It goes along with ?please let me >> manage my business and don?t take away my tools just to satisfy your >> prejudices.? >> >> Selection of management policies and implementations is ALWAYS a local >> issue (assuming consideration of legal necessities). Especially in the >> end-to-end model, the requirements management of end systems has not >> changed because the IP layer protocol has changed. This is a good reason >> for not prohibiting continuing use of DHCP-based solutions. ?Purity of >> protocols? is not a reason for increasing management costs such as >> described by Ray. >> >> This debate about DHCPv6 has been going on far too long. I want to know >> how much it will cost the ?SLAAC-only? faction to quit fighting DHCPv6. >> My conjecture is that it would be minimal, especially as compared to the >> costs for the activities described by Ray. >> >> Putting it differently: What business purpose is served by fighting >> full-functioned DHCPv6 deployment. Don?t give me any RFC or protocol >> arguments - just tell me the business reasons for forcing others to change >> how they manage their business. >> >> James R. Cutler >> James.cutler at consultant.com >> PGP keys at http://pgp.mit.edu >> >> >> >> > On Jun 12, 2015, at 10:07 AM, Ray Soucy wrote: >> > >> > The only thing I would add is that DHCPv6 is not just about "tracking" >> > clients. Yes there are ways to do so using SLAAC, but they are not >> pretty. >> > >> > Giving too much weight to tracking being the reason for DHCPv6 is just >> as >> > bad as giving too much weight to tethering as the reason against it. It >> > skews the conversation. >> > >> > For us, DHCPv6 is about *operational consistency*. >> > >> > Universities have been running with the end-to-end model everyone is >> > looking to IPv6 to restore for a very long time. >> > >> > When you connect to our network, wired or wireless, you get a public IP >> > with no filtering in place in most cases. >> > >> > We have been living the end-to-end model, and that has given us >> operational >> > experience and insight on what it actually takes to support access >> networks >> > using this model. >> > >> > Almost every peer institution I talk to has implemented custom systems >> > refined over decades to preserve the end-to-end model in a time of >> > increasing security incidents and liability. These include IPAM >> systems, >> > which feed into vulnerability scanning, or host filtering for incident >> > response, etc. >> > >> > These systems are in place for IPv4, and modifying them to support IPv6 >> > (which most of us have done) is relatively easy in the case of DHCPv6. >> > >> > By maintaining consistency between IPv4 and IPv6 we avoid having to >> retrain >> > hundreds of IT workers on supporting connectivity. By saying that you >> > won't support DHCPv6, you effectively force us into a choice between >> > investing considerable effort in redesigning systems and training IT >> > personnel, while introducing confusion in the support process because >> IPv4 >> > and IPv6 are delivered using completely different methods. >> > >> > You have just made it cheaper for us to turn to NAT than to support >> IPv6. >> > That's unacceptable. >> > >> > You might be thinking "well that's just universities and a small >> percent of >> > users", but the point here is that we do these things for a reason; >> we've >> > been living without NAT and our collective operational experience doing >> so >> > is something that would be wise to take into consideration instead of >> > dismissing it or trying to call us names. >> > >> > Organizations running SLAAC who say everything is fine, think >> everything is >> > fine because IPv6 has received almost no attention from bad actors in >> terms >> > of security incidents or denial of service attacks. Even well known >> > servers with IPv6 addresses on our network rarely see SSH attempts over >> > IPv6 today. >> > >> > *This will fundamentally change as IPv6 adoption grows*. >> > >> > Are you prepared to be able to deal with abuse reports of hosts on your >> > network participating on denial of service attacks? Can you associate >> the >> > identity of a system to an individual when law enforcement demands you >> to >> > do so? How much longer will it take you to track down a host by its >> IPv6 >> > address to disable it? How many other users have degraded service while >> > they're waiting for you to do that? >> > >> > For most people that are used to the typical IPv4 model (NAT and open >> pool >> > DHCP), these events are very infrequent, so of course they don't get it. >> > For those of us running a more liberal network which preserves the >> > end-to-end model, free from aggressive filtering on user traffic, these >> > incidents are literally daily occurrences. >> > >> > The fact is that you never know what service a user might enable on >> their >> > device only to be exploited and degrade service for their peers. >> > >> > So yes, we are looking to the future in the case of DHCPv6, because >> we've >> > learned from the past. >> > >> > >> > >> > >> > >> > On Fri, Jun 12, 2015 at 3:05 AM, wrote: >> > >> >> On Fri, 12 Jun 2015 02:07:22 -0000, Laszlo Hanyecz said: >> >> >> >>>>> university net nazis >> >>>> >> >>>> Did you really just write that? >> >>>> >> >>> >> >>> As far as "net nazi", I meant it in the same sense as a BOFH. Someone >> >> who is >> >>> intentionally degrading a user's experience by using technical means >> to >> >> block >> >>> specifically targeted applications or behaviors. >> >> >> >> Well, which is more BOFH-ish: >> >> >> >> 1) We insist that you connect in a way that allows us to identify and >> track >> >> you for DMCA and other legal requirements that, quite frankly, we'd >> really >> >> rather not have to do, but it's a cost of doing business. >> >> >> >> 2) We don't let you connect at all because we can't do so without >> exposing >> >> ourselves to more legal liability than we want. >> >> >> >> Besides which, that's a total red herring. >> >> >> >> If you actually go back and *read*, I don't think anybody's >> "intentionally >> >> degrading by blocking targeted applications" - except those who are >> >> refusing >> >> to provide features to allow the applications to work on more network >> >> configs. >> >> The vast majority of us would *prefer* that Android got fixed so it can >> >> ask for >> >> more addresses and do more stuff. Most of us don't *care* if a user >> sucks >> >> up 13 >> >> adresses across 4 devices at the same time - IPv6 addresses are >> *cheap*. >> >> On the other hand, covering your ass when a subpoena shows up and you >> >> realize >> >> you don't have the data needed to point at the user they're *really* >> >> looking >> >> for is incredibly expensive. >> >> >> >> OK? Let me say that again: We're all asking Google to quit being >> stubborn >> >> and add a feature to Android so we can make the user experience >> *better*. >> >> >> >> Now who you calling a BOFH? >> >> >> >>> On the other hand, if it becomes common and acceptable to use DHCPv6 >> to >> >>> provide a single address only >> >> >> >> I encourage my competitor universities to design their networks that >> way. >> >> :) >> >> >> > >> > >> > >> > -- >> > 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 niels=nanog at bakker.net Fri Jun 12 16:07:17 2015 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Fri, 12 Jun 2015 18:07:17 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <1434104646.6144.139.camel@galileo.millnert.se> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> <1434104646.6144.139.camel@galileo.millnert.se> Message-ID: <20150612160717.GD3166@excession.tpb.net> * millnert at gmail.com (Martin Millnert) [Fri 12 Jun 2015, 12:54 CEST]: >Also, possible explanation for why nobody's fixing it: >https://twitter.com/TMCorp/status/609167065300271104 :) https://scontent-sea1-1.xx.fbcdn.net/hphotos-xat1/t31.0-8/10914977_10152809997716851_748171875526832420_o.jpg Is that tweet for real? How is that company (not TM) still in business? -- Niels. From bill at herrin.us Fri Jun 12 16:53:45 2015 From: bill at herrin.us (William Herrin) Date: Fri, 12 Jun 2015 12:53:45 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> Message-ID: On Thu, Jun 11, 2015 at 7:42 PM, Laszlo Hanyecz wrote: > DHCPv6 is a crutch that allows operators to simply implement IPv6 > with all the same hacks as IPv4 and continue to do address based > access control, tracking, etc. Hi Lazlo, Who are you to tell me how I must or must not use this new technology? I will use it if I please and as I please. Your (and Lorenzo's) arguments that I must not do stateful address assignment do not please me and do not engender me to implement or support your variant of the new technology. You are, of course, welcome to tell me I'm not important enough for you to care. Should you do so, don't expect more than disdain the next time you express frustration with the technology's rate of uptake. > I think what Lorenzo is trying to do is to use his > influence/position to forcefully prevent people from doing this, > and while that may not be the most diplomatic way, I admire his > courage in posting here and trying to reason with the mob. Hopefully he learned in this escapade that no one, NO ONE, has sufficient position nor influence nor, ultimately, sufficient wisdom to dictate how a technology is to be used. Having offered our respective suggestions, we can but listen as prospective users tell us what additional capabilities they require. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From twh at megagroup.ru Fri Jun 12 17:08:29 2015 From: twh at megagroup.ru (Stepan Kucherenko) Date: Fri, 12 Jun 2015 20:08:29 +0300 Subject: Enterprise network as an ISP with a single huge customer Message-ID: <557B120D.9000904@megagroup.ru> Hello, I'm sure lots of you work for big enterprises, and some of you work for biggest of them. How many of you architect your network as an ISP, with that enterprise as the biggest customer ? Office networks in l3vpn, VPLS/EVPN on top of your own network for DCI, etc ? Or is it usually just a single IGP domain with no unnecessary bells and whistles ? Do you think one approach is better than the other ? If so, why ? I understand that it usually comes down to specific circumstances and most likely scale but I'd still love to hear about your experience. From job at instituut.net Fri Jun 12 17:12:47 2015 From: job at instituut.net (Job Snijders) Date: Fri, 12 Jun 2015 19:12:47 +0200 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: References: <1434123151.30267.12.camel@galileo.millnert.se> <0681034898E36F448ACAA0EF289BAB7A0186A7AF2A@inp44vdag03.vsnl.co.in> Message-ID: <20150612171247.GO94733@Vurt.local> On Fri, Jun 12, 2015 at 12:53:13PM -0300, jim deleskie wrote: > Filtering has been a community issue since my days @ MCI being AS3561, > often discussed not often enough acted one, I suspect the topic has come up > at every "large" NSP I've worked at. Frequently someone complains its > "hard" to fix, or router X makes it hard to fix, or customer Y won;t agree, > and not enough people stand up to force fix the issues. I've did a preso > on it ( while working at TATA) with some other "smart folks" but for all > the usual reasons it died on the vine. Next time around put up more of a fight? :-) In all seriousness not all hope is lost: Even on the crappiest platforms, an operator can do better then nothing with little effort. The simplest protection mechanism of all: maximum prefix limits. If you turn up a peer or customer, confirm with them how many routes you should expect, add 15% and configure that. In this day and age AS_PATH filters are still underutilized, if you apply them on egress they are a very easy way to prevent sending routes from your upstream to your peers, or accepting your upstreams routes from peers/customers. Vote with your wallet, talk to your vendors how to make your life easier. Once example: ask Cisco to implement https://tools.cisco.com/bugsearch/bug/CSCuq14541 ("Add "bgp enforce ebgp-outbound-policy" knob to prevent route leaks" - this is a PR asking that if a new neighbor is configured you don't immediatly send all routes & accept everything). There are actively maintained open source tools such as bgpq3 which can help you generate filters to apply on your customer sessions: it takes 2 seconds to generate an effective IOS prefix-list for 4788: Vurt:~ job$ time bgpq3 -h rr.ntt.net -A AS-TMNET-CUSTOMERS | wc -l 6884 real 0m1.947s (source: https://github.com/snar/bgpq3 - can output in BIRD, XR, IOS, JunOS or JSON syntax) Today there are plenty of networks which use the above techniques successfully on a variety of devices. Kind regards, Job From tom at cloudflare.com Fri Jun 12 17:30:06 2015 From: tom at cloudflare.com (Tom Paseka) Date: Fri, 12 Jun 2015 10:30:06 -0700 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <20150612160717.GD3166@excession.tpb.net> References: <20150612110934.55621a42@echo.ms.redpill-linpro.com> <20150612091607.GH94733@Vurt.local> <6BADE016-C54E-47BD-9102-6BC3484D0D4A@arbor.net> <86EB4BB4-B589-4278-B4B9-456DB7D01662@cloudflare.com> <1434104646.6144.139.camel@galileo.millnert.se> <20150612160717.GD3166@excession.tpb.net> Message-ID: Looks to be edited from their original tweet. On Fri, Jun 12, 2015 at 9:07 AM, wrote: > * millnert at gmail.com (Martin Millnert) [Fri 12 Jun 2015, 12:54 CEST]: >> >> Also, possible explanation for why nobody's fixing it: >> https://twitter.com/TMCorp/status/609167065300271104 :) > > https://scontent-sea1-1.xx.fbcdn.net/hphotos-xat1/t31.0-8/10914977_10152809997716851_748171875526832420_o.jpg > > Is that tweet for real? How is that company (not TM) still in business? > > > -- Niels. From dave.taht at gmail.com Fri Jun 12 17:33:55 2015 From: dave.taht at gmail.com (Dave Taht) Date: Fri, 12 Jun 2015 10:33:55 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> Message-ID: I have completely lost track of the technical issues on this thread. I would like DHCP-PD support for acquiring a prefix for tethering, from both cellular, and from wifi, in android. A mobile (android is also used in settop boxes and devices like that) and pretty standard platform that I could put anywhere in the home to "boost the signal" to devices elsewhere would be a goodness, much like I now use wifi range extenders, bluetooth, powerline, and one day 802.11ad. I also would not mind ahcpd, and hnetd support, and support for one or more sane routing protocols. Is the debate here conflating dhcpv6 (for getting addresses), and dhcp-pd (for obtaining prefixes?) It is certainly possible to do one without the other and vice versa. The core bits of what I don't understand about the flamage is how hard would it be for an end-user - or corporate client - to just add any of these functionalities to this, cyanogenmod, etc. From mike at mtcc.com Fri Jun 12 17:34:21 2015 From: mike at mtcc.com (Michael Thomas) Date: Fri, 12 Jun 2015 10:34:21 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> Message-ID: <557B181D.2080802@mtcc.com> The thing about this is that I get the impression that there was violent agreement that DHCPv6 with PD would be Good Thing. I think that the disagreement is about single address assignments being a Bad Thing or Good Thing. For Android, it seems that if operators implemented the ability to fetch a prefix that would be great for Android. For operators, if you do DHCPv6-PD and Android implements it... the camel's nose is under the tent... Mike On 06/12/2015 09:53 AM, William Herrin wrote: > On Thu, Jun 11, 2015 at 7:42 PM, Laszlo Hanyecz wrote: >> DHCPv6 is a crutch that allows operators to simply implement IPv6 >> with all the same hacks as IPv4 and continue to do address based >> access control, tracking, etc. > Hi Lazlo, > > Who are you to tell me how I must or must not use this new technology? > I will use it if I please and as I please. Your (and Lorenzo's) > arguments that I must not do stateful address assignment do not please > me and do not engender me to implement or support your variant of the > new technology. > > You are, of course, welcome to tell me I'm not important enough for > you to care. Should you do so, don't expect more than disdain the next > time you express frustration with the technology's rate of uptake. > > >> I think what Lorenzo is trying to do is to use his >> influence/position to forcefully prevent people from doing this, >> and while that may not be the most diplomatic way, I admire his >> courage in posting here and trying to reason with the mob. > Hopefully he learned in this escapade that no one, NO ONE, has > sufficient position nor influence nor, ultimately, sufficient wisdom > to dictate how a technology is to be used. Having offered our > respective suggestions, we can but listen as prospective users tell us > what additional capabilities they require. > > Regards, > Bill Herrin > > From toddunder at gmail.com Fri Jun 12 17:36:06 2015 From: toddunder at gmail.com (Todd Underwood) Date: Fri, 12 Jun 2015 13:36:06 -0400 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: References: <1434123151.30267.12.camel@galileo.millnert.se> <0681034898E36F448ACAA0EF289BAB7A0186A7AF2A@inp44vdag03.vsnl.co.in> Message-ID: i remember that presentation! https://www.nanog.org/meetings/abstract?id=459 :-) On Fri, Jun 12, 2015 at 11:53 AM, jim deleskie wrote: > People from Big telcom should never reply to mailing lists from work > addresses unless specifically allowed, which I suspect TATA doesn't either, > based on some direct, buy old knowledge :) > indeed, people from big companies who post on mailing lists at all will be called out as official representatives of their company no matter what address they use, from recent experience. it's probably far better for everyone in such a situation to simply never post anything. :-/ t From deleskie at gmail.com Fri Jun 12 17:40:56 2015 From: deleskie at gmail.com (jim deleskie) Date: Fri, 12 Jun 2015 14:40:56 -0300 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: References: <1434123151.30267.12.camel@galileo.millnert.se> <0681034898E36F448ACAA0EF289BAB7A0186A7AF2A@inp44vdag03.vsnl.co.in> Message-ID: Todd, One of my few work "regrets" is we where not able to move this forward. There was/is lots of value in it. Agree'd on the posting. -jim On Fri, Jun 12, 2015 at 2:36 PM, Todd Underwood wrote: > i remember that presentation! > > https://www.nanog.org/meetings/abstract?id=459 > > :-) > > On Fri, Jun 12, 2015 at 11:53 AM, jim deleskie wrote: > >> People from Big telcom should never reply to mailing lists from work >> addresses unless specifically allowed, which I suspect TATA doesn't >> either, >> based on some direct, buy old knowledge :) >> > > indeed, people from big companies who post on mailing lists at all will be > called out as official representatives of their company no matter what > address they use, from recent experience. > > it's probably far better for everyone in such a situation to simply never > post anything. :-/ > > t > From Valdis.Kletnieks at vt.edu Fri Jun 12 17:43:08 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 12 Jun 2015 13:43:08 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: Your message of "Fri, 12 Jun 2015 10:33:55 -0700." References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> Message-ID: <13012.1434130988@turing-police.cc.vt.edu> On Fri, 12 Jun 2015 10:33:55 -0700, Dave Taht said: > The core bits of what I don't understand about the flamage is how hard > would it be for an end-user - or corporate client - to just add any of > these functionalities to this, cyanogenmod, etc. What percent of Android users have even *heard* of cyanogenmod? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From toddunder at gmail.com Fri Jun 12 17:51:41 2015 From: toddunder at gmail.com (Todd Underwood) Date: Fri, 12 Jun 2015 13:51:41 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: <13012.1434130988@turing-police.cc.vt.edu> References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <13012.1434130988@turing-police.cc.vt.edu> Message-ID: On Fri, Jun 12, 2015 at 1:43 PM, wrote: > On Fri, 12 Jun 2015 10:33:55 -0700, Dave Taht said: > > The core bits of what I don't understand about the flamage is how hard > > would it be for an end-user - or corporate client - to just add any of > > these functionalities to this, cyanogenmod, etc. > > What percent of Android users have even *heard* of cyanogenmod? > a larger percentage than have ever *heard* of IPv6. :-) game. set. match. t From jared at puck.nether.net Fri Jun 12 17:53:28 2015 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 12 Jun 2015 13:53:28 -0400 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: References: <1434123151.30267.12.camel@galileo.millnert.se> <0681034898E36F448ACAA0EF289BAB7A0186A7AF2A@inp44vdag03.vsnl.co.in> Message-ID: > On Jun 12, 2015, at 1:36 PM, Todd Underwood wrote: > > it's probably far better for everyone in such a situation to simply never > post anything. :-/ Yeah it was a bad move trying to equate those two and causes the exact impact you expect. :( - Jared From dave.taht at gmail.com Fri Jun 12 17:55:54 2015 From: dave.taht at gmail.com (Dave Taht) Date: Fri, 12 Jun 2015 10:55:54 -0700 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <13012.1434130988@turing-police.cc.vt.edu> Message-ID: On Fri, Jun 12, 2015 at 10:51 AM, Todd Underwood wrote: > > On Fri, Jun 12, 2015 at 1:43 PM, wrote: >> >> On Fri, 12 Jun 2015 10:33:55 -0700, Dave Taht said: >> > The core bits of what I don't understand about the flamage is how hard >> > would it be for an end-user - or corporate client - to just add any of >> > these functionalities to this, cyanogenmod, etc. >> >> What percent of Android users have even *heard* of cyanogenmod? > > > a larger percentage than have ever *heard* of IPv6. :-) > > game. set. match. Change and innovation have to start somewhere, and usually occur on the edges of the ecosystem. Good ideas (and bad) get filtered up (or out) that way. Cyanogen is one of several android derivatives innovating (or at least, was, last I looked). > t > > -- Dave T?ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From jared at puck.nether.net Fri Jun 12 18:01:35 2015 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 12 Jun 2015 14:01:35 -0400 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: References: <1434123151.30267.12.camel@galileo.millnert.se> <0681034898E36F448ACAA0EF289BAB7A0186A7AF2A@inp44vdag03.vsnl.co.in> Message-ID: > On Jun 12, 2015, at 1:40 PM, jim deleskie wrote: > > Todd, > > One of my few work "regrets" is we where not able to move this forward. > There was/is lots of value in it. There are many of us trying to tilt at these topics in various ways. I know that at $dayjob we try to keep things clean, monitor what?s going on etc.. I?m happy to dump any ASN into my leak detector stuff here that wants it: http://puck.nether.net/bgp/leakinfo.cgi it only looks for one type of thing, but with ?the cloud? it?s much easier to toss feeds and compute at these things than 10-20 years ago. I?m always disappointed to find that people just ?give up? at a certain scale in trying to filter things. I blame many of the vendors for not having the will to fix their BGP implementations to advertise no routes to a new peer without policy. I blame vendors for failing to train/test people on filtering routes as part of their *IE certification. If you?re an internet expert you don?t make these errors, or don?t have them occur for such a long duration. I blame vendors for selling devices route optimization that translate a regular BGP feed into a garbage feed that can cause global pollution. Many people don?t understand their IP routing ?supply chain? so lines of people waiting to pay because you can?t swipe your card is the fault of many people, including the people without cash to cover their food bills. I can rant all day about this amongst other things. What have you done today to improve your routing security? - Jared From cscora at apnic.net Fri Jun 12 18:13:20 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Jun 2015 04:13:20 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201506121813.t5CIDKho005951@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 13 Jun, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 548716 Prefixes after maximum aggregation (per Origin AS): 208073 Deaggregation factor: 2.64 Unique aggregates announced (without unneeded subnets): 267312 Total ASes present in the Internet Routing Table: 50570 Prefixes per ASN: 10.85 Origin-only ASes present in the Internet Routing Table: 36708 Origin ASes announcing only one prefix: 16273 Transit ASes present in the Internet Routing Table: 6303 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: 41 Max AS path prepend of ASN ( 12486) 32 Prefixes from unregistered ASNs in the Routing Table: 1211 Unregistered ASNs in the Routing Table: 421 Number of 32-bit ASNs allocated by the RIRs: 9820 Number of 32-bit ASNs visible in the Routing Table: 7559 Prefixes from 32-bit ASNs in the Routing Table: 27636 Number of bogon 32-bit ASNs visible in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 390 Number of addresses announced to Internet: 2772462112 Equivalent to 165 /8s, 64 /16s and 106 /24s Percentage of available address space announced: 74.9 Percentage of allocated address space announced: 74.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.4 Total number of prefixes smaller than registry allocations: 183677 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 135550 Total APNIC prefixes after maximum aggregation: 39231 APNIC Deaggregation factor: 3.46 Prefixes being announced from the APNIC address blocks: 142059 Unique aggregates announced from the APNIC address blocks: 56921 APNIC Region origin ASes present in the Internet Routing Table: 5060 APNIC Prefixes per ASN: 28.07 APNIC Region origin ASes announcing only one prefix: 1200 APNIC Region transit ASes present in the Internet Routing Table: 868 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 38 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1483 Number of APNIC addresses announced to Internet: 750442176 Equivalent to 44 /8s, 186 /16s and 214 /24s Percentage of available APNIC address space announced: 87.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: 179968 Total ARIN prefixes after maximum aggregation: 88286 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 182248 Unique aggregates announced from the ARIN address blocks: 85212 ARIN Region origin ASes present in the Internet Routing Table: 16612 ARIN Prefixes per ASN: 10.97 ARIN Region origin ASes announcing only one prefix: 6119 ARIN Region transit ASes present in the Internet Routing Table: 1719 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 479 Number of ARIN addresses announced to Internet: 1092631072 Equivalent to 65 /8s, 32 /16s and 58 /24s Percentage of available ARIN address space announced: 57.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 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: 133114 Total RIPE prefixes after maximum aggregation: 66057 RIPE Deaggregation factor: 2.02 Prefixes being announced from the RIPE address blocks: 139142 Unique aggregates announced from the RIPE address blocks: 86249 RIPE Region origin ASes present in the Internet Routing Table: 17961 RIPE Prefixes per ASN: 7.75 RIPE Region origin ASes announcing only one prefix: 8134 RIPE Region transit ASes present in the Internet Routing Table: 2974 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3757 Number of RIPE addresses announced to Internet: 695024896 Equivalent to 41 /8s, 109 /16s and 61 /24s Percentage of available RIPE address space announced: 101.0 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: 60165 Total LACNIC prefixes after maximum aggregation: 11392 LACNIC Deaggregation factor: 5.28 Prefixes being announced from the LACNIC address blocks: 70910 Unique aggregates announced from the LACNIC address blocks: 33217 LACNIC Region origin ASes present in the Internet Routing Table: 2444 LACNIC Prefixes per ASN: 29.01 LACNIC Region origin ASes announcing only one prefix: 623 LACNIC Region transit ASes present in the Internet Routing Table: 506 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: 1721 Number of LACNIC addresses announced to Internet: 168168512 Equivalent to 10 /8s, 6 /16s and 12 /24s Percentage of available LACNIC address space announced: 100.2 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: 12033 Total AfriNIC prefixes after maximum aggregation: 3059 AfriNIC Deaggregation factor: 3.93 Prefixes being announced from the AfriNIC address blocks: 13967 Unique aggregates announced from the AfriNIC address blocks: 5363 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 19.00 AfriNIC Region origin ASes announcing only one prefix: 197 AfriNIC Region transit ASes present in the Internet Routing Table: 156 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 119 Number of AfriNIC addresses announced to Internet: 65774080 Equivalent to 3 /8s, 235 /16s and 162 /24s Percentage of available AfriNIC address space announced: 65.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 2927 11558 917 Korea Telecom 17974 2692 904 78 PT Telekomunikasi Indonesia 7545 2611 336 129 TPG Telecom Limited 4755 2026 423 219 TATA Communications formerly 4538 1897 4190 71 China Education and Research 9829 1703 1343 94 National Internet Backbone 9808 1588 8717 28 Guangdong Mobile Communicatio 9583 1468 117 569 Sify Limited 4808 1448 2235 464 CNCGROUP IP network China169 9498 1339 336 103 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 3093 2958 141 Cox Communications Inc. 6389 2792 3688 51 BellSouth.net Inc. 3356 2571 10687 499 Level 3 Communications, Inc. 18566 2050 380 192 MegaPath Corporation 20115 1885 1851 422 Charter Communications 6983 1748 850 244 EarthLink, Inc. 4323 1605 1022 411 tw telecom holdings, inc. 30036 1562 315 453 Mediacom Communications Corp 701 1395 11354 679 MCI Communications Services, 22561 1353 414 250 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 2088 305 361 TELLCOM ILETISIM HIZMETLERI A 20940 1925 751 1404 Akamai International B.V. 6849 1211 355 22 JSC "Ukrtelecom" 31148 1048 45 23 Freenet Ltd. 13188 1040 97 70 TOV "Bank-Inform" 8402 1012 544 15 OJSC "Vimpelcom" 12479 947 869 72 France Telecom Espana SA 6830 909 2693 467 Liberty Global Operations B.V 8551 871 376 52 Bezeq International-Ltd 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 3239 531 236 Telmex Colombia S.A. 28573 2263 2168 116 NET Servi?os de Comunica??o S 8151 1696 3257 470 Uninet S.A. de C.V. 7303 1637 1017 237 Telecom Argentina S.A. 6147 1620 374 23 Telefonica del Peru S.A.A. 6503 1246 421 55 Axtel, S.A.B. de C.V. 26615 1079 2325 35 Tim Celular S.A. 7738 999 1882 41 Telemar Norte Leste S.A. 3816 945 425 159 COLOMBIA TELECOMUNICACIONES S 18881 870 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 24863 896 280 26 Link Egypt (Link.NET) 8452 802 958 13 TE-AS 36903 514 259 98 Office National des Postes et 36992 423 1229 32 ETISALAT MISR 37492 312 175 71 Orange Tunisie 24835 304 146 13 Vodafone Data 3741 250 857 208 Internet Solutions 29571 241 21 12 Cote d'Ivoire Telecom 37054 225 19 6 Data Telecom Service 36947 178 807 13 Telecom Algeria Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3239 531 236 Telmex Colombia S.A. 22773 3093 2958 141 Cox Communications Inc. 4766 2927 11558 917 Korea Telecom 6389 2792 3688 51 BellSouth.net Inc. 17974 2692 904 78 PT Telekomunikasi Indonesia 7545 2611 336 129 TPG Telecom Limited 3356 2571 10687 499 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2263 2168 116 NET Servi?os de Comunica??o S 34984 2088 305 361 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3093 2952 Cox Communications Inc. 6389 2792 2741 BellSouth.net Inc. 17974 2692 2614 PT Telekomunikasi Indonesia 7545 2611 2482 TPG Telecom Limited 39891 2472 2466 SaudiNet, Saudi Telecom Compa 28573 2263 2147 NET Servi?os de Comunica??o S 3356 2571 2072 Level 3 Communications, Inc. 4766 2927 2010 Korea Telecom 18566 2050 1858 MegaPath Corporation 4538 1897 1826 China Education and Research 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.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.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:17 /9:13 /10:34 /11:95 /12:264 /13:507 /14:1004 /15:1721 /16:12935 /17:7263 /18:12362 /19:25552 /20:36037 /21:38842 /22:59938 /23:51948 /24:297136 /25:1097 /26:1135 /27:724 /28:25 /29:25 /30:11 /31:0 /32:31 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2290 3093 Cox Communications Inc. 18566 2000 2050 MegaPath Corporation 6389 1640 2792 BellSouth.net Inc. 6983 1396 1748 EarthLink, Inc. 30036 1390 1562 Mediacom Communications Corp 34984 1344 2088 TELLCOM ILETISIM HIZMETLERI A 6147 1172 1620 Telefonica del Peru S.A.A. 10620 1137 3239 Telmex Colombia S.A. 11492 1109 1193 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1483 2:670 4:93 5:1849 6:25 8:1417 11:1 12:1828 13:14 14:1385 15:17 16:2 17:44 18:22 20:48 23:1237 24:1684 27:1896 31:1606 32:38 33:2 34:4 35:3 36:117 37:1944 38:1038 39:6 40:253 41:2678 42:280 43:1333 44:29 45:714 46:2211 47:42 49:899 50:811 52:12 54:77 55:5 56:6 57:41 58:1304 59:717 60:478 61:1750 62:1358 63:1921 64:4430 65:2266 66:4069 67:2080 68:1063 69:3251 70:988 71:443 72:1984 74:2648 75:337 76:423 77:1292 78:1190 79:800 80:1340 81:1294 82:828 83:702 84:723 85:1417 86:400 87:1039 88:525 89:1850 90:152 91:5983 92:856 93:2232 94:2063 95:2177 96:429 97:354 98:1056 99:50 100:72 101:825 103:7598 104:1804 105:58 106:231 107:987 108:630 109:2059 110:1120 111:1479 112:823 113:1208 114:823 115:1281 116:1386 117:1065 118:1823 119:1435 120:449 121:1093 122:2147 123:1838 124:1523 125:1605 128:629 129:384 130:404 131:1201 132:505 133:176 134:407 135:95 136:330 137:314 138:835 139:154 140:234 141:447 142:662 143:513 144:572 145:120 146:734 147:587 148:1219 149:410 150:564 151:635 152:484 153:244 154:637 155:861 156:413 157:409 158:337 159:1002 160:392 161:662 162:1959 163:424 164:684 165:692 166:311 167:832 168:1312 169:174 170:1466 171:246 172:91 173:1553 174:719 175:690 176:1260 177:3723 178:2143 179:919 180:1939 181:2006 182:1800 183:628 184:754 185:3678 186:2659 187:1800 188:2051 189:1552 190:7729 191:1104 192:8448 193:5612 194:4163 195:3690 196:2011 197:946 198:5544 199:5484 200:6686 201:3163 202:9436 203:9157 204:4675 205:2799 206:3081 207:2942 208:3977 209:3967 210:3530 211:1857 212:2553 213:2341 214:860 215:72 216:5750 217:1821 218:709 219:465 220:1456 221:784 222:479 223:720 End of report From mpetach at netflight.com Fri Jun 12 18:21:46 2015 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 12 Jun 2015 11:21:46 -0700 Subject: A Public Apology to Lorenzo Message-ID: (resending as I sent it incorrectly the first time; apology for the duplicate for those that see it twice) Dear Lorenzo, I'd like to publicly apologize for my behaviour last night. It has been rightly pointed out to me in private that I crossed several lines in my response to the debate yesterday, and for that I am truly sorry. I crossed the streams, by bringing material from an unrelated forum into the NANOG thread--material that was posted from a different account for a different purpose. That had no place on NANOG, and I do apologize for dredging it up. I engaged in an ad-glandulum attack as part of the debate, which was a low blow. I have absolutely *nothing* against your genitals whatsoever, I promise. I will leave them out of any future discussions. The level of mud-slinging I sank to was more appropriate for an IETF mailing list, not for NANOG; the people here deserve better, and I apologize to everyone for that shameless outburst. It has been pointed out that your desire here was to gather operational input and engage in an open dialogue on a personal basis. I failed to recognize that, and attacked you instead of listening. That was wrong of me, and if you do still have an interest in discussing the needs of network operators, I will do so in an open and respectful mode, and will leave any mention of specific companies out of the discussion. Again, I am truly sorry for my inappropriate outburst last night, and hope it did not prevent a truly open discussion about the needs of network operators. Sincerely, Matthew Petach From jj at anexia.at Fri Jun 12 20:25:40 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Fri, 12 Jun 2015 20:25:40 +0000 Subject: AS4788 Telecom Malaysia major route leak? Message-ID: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> This is the official feedback: Level 3's network, alongside some other ISP's, experienced service disruptions affecting customers in Europe, Asia and multiple other markets. IP, Voice and Content Delivery Network (CDN) services were affected for Level 3. The root cause of the issue was isolated to a third party Internet Service Provider in Asia that leaked internet routes resulting in traffic being sent to a destination that could not route them, which affected IP, Voice and CDN services in multiple markets. The issue has been resolved, but the provider continues working to determine the specific root cause of the incident. At this time, customer services are restored with the exception of any that pose any possible risk to the Level 3 network. Maintaining a reliable, high-performing network for our customers is our top priority. Level 3 will continue to work with the provider to prevent a recurrence. J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 From robert at mckay.com Fri Jun 12 21:28:21 2015 From: robert at mckay.com (Robert McKay) Date: Fri, 12 Jun 2015 22:28:21 +0100 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <38976.1434092757@turing-police.cc.vt.edu> Message-ID: On 2015-06-12 16:58, Ray Soucy wrote: > Wouldn't the simple play here be for Android to just throw up a > message > saying "This network does not support tethering" if SLAAC isn't > enabled, > and to let users complain to local operators if that's something they > want? Google doesn't get blamed, operators are happy, and ultimately > users > have a better experience because the expectations of the network are > clear > rather than trying something that will likely not work consistently > across > networks. No.. there's one more step in the arms race.. if it's impossible to get more than one IPv6 address the user doesn't just give up and say 'oh well', or break down and pay the operator for tethering access - they enable NAT. If NAT isn't supported they will find a way to make it happen anyway. IMO possibly the reason for leaving SLAAC as the only option is to try and force operators to have a configuration that allows some form of tethering.. perhaps not dhcp-pd which might be nicer but at least not NAT. Operators could combat this by coming up with an implementation of SLAAC that tries to force the client to only use one or perhaps a very limited number of IPs. I'm imagining a sort of timeout system where only one IP is really allowed to work at once.. perhaps you could allow more addrs to continue their existing TCP sessions but everything else gets reset except for the one currently active primary outbound IP. This could be combined with other anti-tethering features such as ttl monitoring and deep packet inspection / user agent sniffing. It's probably inevitable that operators will do this and the users will be forced to implement a NAT and proxy based tethering system to evade the anti- tether features anyway.. but forcing the use of SLAAC might delay it for a little while. Rob From bill at herrin.us Fri Jun 12 21:59:23 2015 From: bill at herrin.us (William Herrin) Date: Fri, 12 Jun 2015 17:59:23 -0400 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <1433905187.11511.25.camel@karl> <7511.1433905774@turing-police.cc.vt.edu> <1433907422.11511.30.camel@karl> <0030FD4E-A46A-4630-9A79-896573718C63@steffann.nl> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> Message-ID: On Fri, Jun 12, 2015 at 1:33 PM, Dave Taht wrote: > The core bits of what I don't understand about the flamage is how hard > would it be for an end-user - or corporate client - to just add any of > these functionalities to this, cyanogenmod, etc. Hi Dave, Tough to say. The Feat implementation of OpenVPN claims to work on android without root. OpenVPN would have to hook in to most of the same places in the network stack that a DHCPv6 implementation would. On the other hand, they seem to have trouble with it breaking for each new version of android, and other implementations of OpenVPN do require root. Certainly having to root or flash your android device to get DHCPv6 would reasonably be considered "hard." Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From cidr-report at potaroo.net Fri Jun 12 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Jun 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201506122200.t5CM000A094641@wattle.apnic.net> This report has been generated at Fri Jun 12 21:14:37 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 05-06-15 555774 305130 06-06-15 556811 305075 07-06-15 556467 305437 08-06-15 557208 305685 09-06-15 557034 305924 10-06-15 557385 305621 11-06-15 556779 303990 12-06-15 557587 304127 AS Summary 50831 Number of ASes in routing system 20206 Number of ASes announcing only one prefix 3246 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120824832 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'). --- 12Jun15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 557249 304232 253017 45.4% All ASes AS22773 3096 172 2924 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2791 70 2721 97.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2692 78 2614 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS9394 2921 315 2606 89.2% CTTNET China TieTong Telecommunications Corporation,CN AS39891 2473 34 2439 98.6% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2267 304 1963 86.6% NET Servi?os de Comunica??o S.A.,BR AS4755 2023 261 1762 87.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4766 2927 1339 1588 54.3% KIXS-AS-KR Korea Telecom,KR AS9808 1588 67 1521 95.8% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6983 1747 247 1500 85.9% ITCDELTA - Earthlink, Inc.,US AS7545 2648 1175 1473 55.6% TPG-INTERNET-AP TPG Telecom Limited,AU AS10620 3246 1773 1473 45.4% Telmex Colombia S.A.,CO AS20115 1885 486 1399 74.2% CHARTER-NET-HKY-NC - Charter Communications,US AS7303 1637 286 1351 82.5% Telecom Argentina S.A.,AR AS6147 1621 282 1339 82.6% Telefonica del Peru S.A.A.,PE AS9498 1339 118 1221 91.2% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1616 413 1203 74.4% TWTC - tw telecom holdings, inc.,US AS18566 2050 898 1152 56.2% MEGAPATH5-US - MegaPath Corporation,US AS22561 1353 261 1092 80.7% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS7552 1145 56 1089 95.1% VIETEL-AS-AP Viettel Corporation,VN AS3356 2576 1519 1057 41.0% LEVEL3 - Level 3 Communications, Inc.,US AS6849 1208 217 991 82.0% UKRTELNET JSC UKRTELECOM,UA AS8402 1005 28 977 97.2% CORBINA-AS OJSC "Vimpelcom",RU AS8151 1699 725 974 57.3% Uninet S.A. de C.V.,MX AS4538 1952 1036 916 46.9% ERX-CERNET-BKB China Education and Research Network Center,CN AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS26615 1079 178 901 83.5% Tim Celular S.A.,BR AS18881 869 33 836 96.2% Global Village Telecom,BR AS4780 1075 264 811 75.4% SEEDNET Digital United Inc.,TW AS24560 1239 459 780 63.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN Total 56766 13177 43589 76.8% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 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.67.78.0/24 AS38040 GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited,TH 64.28.145.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.28.146.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 66.11.224.0/21 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.234.0/24 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.236.0/22 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.59.192.0/19 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,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 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.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.218.36.0/22 AS19714 -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.69.1.0/24 AS59749 CLEANMAT CLEANMAT EOOD,BG 103.10.222.0/24 AS13189 103.11.16.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.44.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.45.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.47.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.19.219.0/24 AS58887 103.20.100.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.101.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.37.188.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.227.4.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.227.184.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.228.8.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.228.84.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.228.136.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.228.224.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.230.116.0/22 AS59351 103.232.104.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.232.248.0/22 AS4725 ODN SoftBank Mobile Corp.,JP 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,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.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 144.1.0.0/16 AS20055 RUCLICK-AS RU-CLICK LLC,RU 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 165.101.32.0/19 AS20055 RUCLICK-AS RU-CLICK LLC,RU 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.97.32.0/20 AS23089 HOTWIRE-COMMUNICATIONS - Hotwire Communications,US 172.97.64.0/24 AS8100 ASN-QUADRANET-GLOBAL - QuadraNet, Inc,US 172.97.128.0/17 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD.,CA 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 180.222.120.0/21 AS23818 JETINTERNET JETINTERNET Corporation,JP 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.40.183.0/24 AS62300 -Reserved AS-,ZZ 185.104.144.0/24 AS15544 DATAWAYS Dataways Hellas A.E.,GR 188.190.96.0/19 AS19714 -Reserved AS-,ZZ 188.190.103.0/24 AS19714 -Reserved AS-,ZZ 188.190.112.0/24 AS19714 -Reserved AS-,ZZ 188.190.113.0/24 AS19714 -Reserved AS-,ZZ 188.190.114.0/24 AS19714 -Reserved AS-,ZZ 188.190.117.0/24 AS19714 -Reserved AS-,ZZ 188.190.118.0/24 AS19714 -Reserved AS-,ZZ 188.190.119.0/24 AS19714 -Reserved AS-,ZZ 188.190.120.0/24 AS19714 -Reserved AS-,ZZ 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.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.206.140.0/24 AS54926 -Reserved AS-,ZZ 192.206.141.0/24 AS54926 -Reserved AS-,ZZ 192.206.142.0/24 AS54926 -Reserved AS-,ZZ 192.206.143.0/24 AS54926 -Reserved AS-,ZZ 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 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.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 193.105.154.0/24 AS34023 -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.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 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,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.8.0/21 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.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.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 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -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.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.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.103.89.0/24 AS19523 -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.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems 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.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 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.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.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems 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 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 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 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.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.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.74.12.0/23 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,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 CENTURYLINK-US-LEGACY-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 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,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.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 Jun 12 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Jun 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201506122200.t5CM019G094662@wattle.apnic.net> BGP Update Report Interval: 04-Jun-15 -to- 11-Jun-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 321362 4.8% 166.7 -- BSNL-NIB National Internet Backbone,IN 2 - AS23752 282524 4.2% 2062.2 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS45899 130614 1.9% 75.5 -- VNPT-AS-VN VNPT Corp,VN 4 - AS22059 122035 1.8% 17433.6 -- -Reserved AS-,ZZ 5 - AS36947 85280 1.3% 458.5 -- ALGTEL-AS,DZ 6 - AS54169 83616 1.2% 27872.0 -- MGH-ION-1 - Marin General Hospital,US 7 - AS33659 71069 1.1% 1974.1 -- CMCS - Comcast Cable Communications, Inc.,US 8 - AS3709 64295 1.0% 2381.3 -- NET-CITY-SA - City of San Antonio,US 9 - AS9498 49177 0.7% 36.6 -- BBIL-AP BHARTI Airtel Ltd.,IN 10 - AS39891 46821 0.7% 18.9 -- ALJAWWALSTC-AS Saudi Telecom Company JSC,SA 11 - AS45609 44745 0.7% 71.1 -- BHARTI-MOBILITY-AS-AP Bharti Airtel Ltd. AS for GPRS Service,IN 12 - AS33287 38572 0.6% 6428.7 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US 13 - AS55350 33242 0.5% 8310.5 -- VSCGT-HK Virtual Switching Consultancy Limited (C/O VXRoutes Ltd),HK 14 - AS56041 33190 0.5% 63.0 -- CMNET-ZHEJIANG-AP China Mobile communications corporation,CN 15 - AS8402 31222 0.5% 25.9 -- CORBINA-AS OJSC "Vimpelcom",RU 16 - AS17451 30522 0.5% 86.5 -- BIZNET-AS-AP BIZNET NETWORKS,ID 17 - AS24560 29311 0.4% 23.6 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN 18 - AS132220 28357 0.4% 556.0 -- JPRDIGITAL-IN JPR Digital Pvt. Ltd.,IN 19 - AS10620 27879 0.4% 9.4 -- Telmex Colombia S.A.,CO 20 - AS28024 27789 0.4% 18.2 -- Nuevatel PCS de Bolivia S.A.,BO TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS54169 83616 1.2% 27872.0 -- MGH-ION-1 - Marin General Hospital,US 2 - AS22059 122035 1.8% 17433.6 -- -Reserved AS-,ZZ 3 - AS393588 9562 0.1% 9562.0 -- MUBEA-FLO - Mubea,US 4 - AS55350 33242 0.5% 8310.5 -- VSCGT-HK Virtual Switching Consultancy Limited (C/O VXRoutes Ltd),HK 5 - AS33287 38572 0.6% 6428.7 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US 6 - AS37515 11340 0.2% 5670.0 -- iCONNECT,ZA 7 - AS32005 19332 0.3% 4833.0 -- THE-CHURCH-PENSION-GROUP - CHURCH PENSION GROUP SERVICES CORPORATION,US 8 - AS63485 4294 0.1% 4294.0 -- PATRIOT-ASN - Patriot Web Solutions,US 9 - AS50197 4287 0.1% 4287.0 -- EDROS-AS Political Party "Edinaya Russia",RU 10 - AS25563 14833 0.2% 3708.2 -- WEBLAND-AS Webland AG,CH 11 - AS200939 6732 0.1% 3366.0 -- LME-IRAQ Lukoil Overseas Service B.V.,IQ 12 - AS8283 16762 0.2% 3352.4 -- COLOCLUE-AS Netwerkvereniging Coloclue, Amsterdam, Netherlands,NL 13 - AS131763 6155 0.1% 3077.5 -- IDNIC-TADULAKO-AS-ID Universitas Tadulako,ID 14 - AS55741 2786 0.0% 2786.0 -- WBSDC-NET-IN West Bengal Electronics Industry Development,IN 15 - AS3709 64295 1.0% 2381.3 -- NET-CITY-SA - City of San Antonio,US 16 - AS36913 22043 0.3% 2204.3 -- BROADBAND-MALAWI,MW 17 - AS23752 282524 4.2% 2062.2 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 18 - AS33440 7900 0.1% 1975.0 -- WEBRULON-NETWORK - webRulon, LLC,US 19 - AS33659 71069 1.1% 1974.1 -- CMCS - Comcast Cable Communications, Inc.,US 20 - AS61039 1902 0.0% 1902.0 -- ZMZ OAO ZMZ,RU TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 140438 2.0% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 139882 2.0% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 199.204.107.0/24 109541 1.6% AS33287 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US AS33659 -- CMCS - Comcast Cable Communications, Inc.,US 4 - 105.96.0.0/22 83734 1.2% AS36947 -- ALGTEL-AS,DZ 5 - 204.80.242.0/24 83603 1.2% AS54169 -- MGH-ION-1 - Marin General Hospital,US 6 - 64.34.125.0/24 61480 0.9% AS22059 -- -Reserved AS-,ZZ 7 - 76.191.107.0/24 60535 0.9% AS22059 -- -Reserved AS-,ZZ 8 - 175.100.164.0/22 16612 0.2% AS55350 -- VSCGT-HK Virtual Switching Consultancy Limited (C/O VXRoutes Ltd),HK 9 - 103.4.244.0/22 16611 0.2% AS55350 -- VSCGT-HK Virtual Switching Consultancy Limited (C/O VXRoutes Ltd),HK 10 - 78.140.0.0/18 10593 0.1% AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 11 - 203.192.255.0/24 9828 0.1% AS17665 -- IN2CABLE-AP AS Number of In2cable.com (India) Ltd.,IN 12 - 194.1.163.0/24 9738 0.1% AS8283 -- COLOCLUE-AS Netwerkvereniging Coloclue, Amsterdam, Netherlands,NL 13 - 192.58.137.0/24 9562 0.1% AS393588 -- MUBEA-FLO - Mubea,US 14 - 192.58.232.0/24 8361 0.1% AS6629 -- NOAA-AS - NOAA,US 15 - 41.216.207.0/24 8227 0.1% AS37105 -- NEOLOGY-AS,ZA 16 - 154.66.120.0/24 7882 0.1% AS37098 -- globe-as,MW 17 - 154.66.121.0/24 7826 0.1% AS37098 -- globe-as,MW 18 - 31.171.190.0/24 7703 0.1% AS60411 -- KAZINTERCOM-AS KazInterCom LLC,KZ 19 - 94.73.56.0/21 7696 0.1% AS42081 -- SPEEDY-NET-AS Speedy net EAD,BG 20 - 208.81.26.0/24 7107 0.1% AS32005 -- THE-CHURCH-PENSION-GROUP - CHURCH PENSION GROUP SERVICES CORPORATION,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 pavel.odintsov at gmail.com Fri Jun 12 22:12:51 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Sat, 13 Jun 2015 01:12:51 +0300 Subject: FastNetMon 1.1.2 - open source solution for DoS/DDoS mitigation In-Reply-To: References: Message-ID: Hello, Nanog! I have speech at ENOG 9 and would like to share my slides there: http://www.enog.org/presentations/enog-9/17-FastNetMon_ENOG_pdf.pdf Thank you for attention! On Thursday, June 4, 2015, Rafael Possamai wrote: > You could look into LXD for that type of deployment. > > On Thu, Jun 4, 2015 at 12:55 PM, Pavel Odintsov > wrote: > >> Brilliant idea! But in Docker we could offer only sflow and sflow. Port >> mirror capture need support from the kernel side. Will try shortly! >> >> On Thursday, June 4, 2015, Roberto Bert? > > wrote: >> >> > What about we build a Docker? >> > >> > 2015-06-04 14:47 GMT-03:00 Alexander Maassen > >> > >: >> > >> > > It's a security tool. So ppl using it want to publicly hide the fact >> they >> > > use it in case you screw up and it contains leaks ;) >> > > >> > > -------- Oorspronkelijk bericht -------- >> > > Van: Pavel Odintsov > >> > >> > > Datum: >> > > Aan: Jim Popovitch > > >> > > Cc: nanog at nanog.org >> >> > > Onderwerp: Re: FastNetMon 1.1.2 - open source solution for DoS/DDoS >> > > mitigation >> > > >> > > Looks like many folks want hide company emails ;) I'm good guy and >> will >> > not >> > > spam or offer slmething ;))) >> > > >> > > But I'm impressed about amount of off list requests. Really huge >> interest >> > > in tool. >> > > >> > > On Thursday, June 4, 2015, Jim Popovitch > >> > > wrote: >> > > >> > > > There's a surprising amount of GMail (yes, including me) and >> new-ness >> > > > in this thread. Should I be impressed with the freshness or >> > > > concerned about astroturfing? :-) >> > > > >> > > > Bah Humbug! >> > > > >> > > > -Jim P. >> > > > >> > > >> > > >> > > -- >> > > Sincerely yours, Pavel Odintsov >> > > >> > >> >> >> -- >> Sincerely yours, Pavel Odintsov >> > > -- Sincerely yours, Pavel Odintsov From morrowc.lists at gmail.com Sat Jun 13 01:57:59 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 12 Jun 2015 21:57:59 -0400 Subject: Enterprise network as an ISP with a single huge customer In-Reply-To: <557B120D.9000904@megagroup.ru> References: <557B120D.9000904@megagroup.ru> Message-ID: On Fri, Jun 12, 2015 at 1:08 PM, Stepan Kucherenko wrote: > Hello, > > I'm sure lots of you work for big enterprises, and some of you work for > biggest of them. > > How many of you architect your network as an ISP, with that enterprise as > the biggest customer ? Office networks in l3vpn, VPLS/EVPN on top of your > own network for DCI, etc ? Or is it usually just a single IGP domain with no > unnecessary bells and whistles ? it's nice to have the tools to segregate traffic/users/things... mpls/etc is one method to do that... I don't know that many enterprises pursue this path though :( which is sad (I think). From randy at psg.com Sat Jun 13 02:04:20 2015 From: randy at psg.com (Randy Bush) Date: Sat, 13 Jun 2015 11:04:20 +0900 Subject: Enterprise network as an ISP with a single huge customer In-Reply-To: References: <557B120D.9000904@megagroup.ru> Message-ID: > it's nice to have the tools to segregate traffic/users/things... > mpls/etc is one method to do that... I don't know that many > enterprises pursue this path though :( which is sad (I think). i have seen a lot of this done with firewall devices and vlans. with vlans or mpls, you can make spaghetti without wires, one wheat and one semolina. randy From morrowc.lists at gmail.com Sat Jun 13 02:23:53 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 12 Jun 2015 22:23:53 -0400 Subject: Enterprise network as an ISP with a single huge customer In-Reply-To: References: <557B120D.9000904@megagroup.ru> Message-ID: On Fri, Jun 12, 2015 at 10:04 PM, Randy Bush wrote: >> it's nice to have the tools to segregate traffic/users/things... >> mpls/etc is one method to do that... I don't know that many >> enterprises pursue this path though :( which is sad (I think). > > i have seen a lot of this done with firewall devices and vlans. with > vlans or mpls, you can make spaghetti without wires, one wheat and one > semolina. oh absolutely. you can use many tools to lop off your fingers, my point was that things like mpls (or vlans) provide a nice other tool to use along with your firewalls and such. of course you ought not willy-nilly go crazy with this, but... imagine if the 'hr department' were in one contiguous 'VRF' which had a defined set of 2-3 exit points to control access through... while those willy 'engineers' could be stuck in their own ghetto/VRF and have a different set of 2-3 exit points to control. Expand your network over many locations and in large buildings and ... it can be attractive to run a 2547 network that the company is a 'customer' of, or so I was thinking :) From randy at psg.com Sat Jun 13 02:35:22 2015 From: randy at psg.com (Randy Bush) Date: Sat, 13 Jun 2015 11:35:22 +0900 Subject: Enterprise network as an ISP with a single huge customer In-Reply-To: References: <557B120D.9000904@megagroup.ru> Message-ID: >> i have seen a lot of this done with firewall devices and vlans. with >> vlans or mpls, you can make spaghetti without wires, one wheat and one >> semolina. > > oh absolutely. you can use many tools to lop off your fingers, my > point was that things like mpls (or vlans) provide a nice other tool > to use along with your firewalls and such. > > of course you ought not willy-nilly go crazy with this, but... imagine > if the 'hr department' were in one contiguous 'VRF' which had a > defined set of 2-3 exit points to control access through... while > those willy 'engineers' could be stuck in their own ghetto/VRF and > have a different set of 2-3 exit points to control. > > Expand your network over many locations and in large buildings and ... > it can be attractive to run a 2547 network that the company is a > 'customer' of, or so I was thinking :) i have seen people successful with this with mpls and with vlans with non-mpls tunnel tech (e.g. ipsec for the paranoid). i have seen them screw the pooch with both. randy From twh at megagroup.ru Sat Jun 13 02:48:24 2015 From: twh at megagroup.ru (Stepan Kucherenko) Date: Sat, 13 Jun 2015 05:48:24 +0300 Subject: Enterprise network as an ISP with a single huge customer In-Reply-To: References: <557B120D.9000904@megagroup.ru> Message-ID: <557B99F8.5090605@megagroup.ru> 13.06.2015 05:35, Randy Bush wrote: >>> i have seen a lot of this done with firewall devices and vlans. with >>> vlans or mpls, you can make spaghetti without wires, one wheat and one >>> semolina. >> >> oh absolutely. you can use many tools to lop off your fingers, my >> point was that things like mpls (or vlans) provide a nice other tool >> to use along with your firewalls and such. >> >> of course you ought not willy-nilly go crazy with this, but... imagine >> if the 'hr department' were in one contiguous 'VRF' which had a >> defined set of 2-3 exit points to control access through... while >> those willy 'engineers' could be stuck in their own ghetto/VRF and >> have a different set of 2-3 exit points to control. >> >> Expand your network over many locations and in large buildings and ... >> it can be attractive to run a 2547 network that the company is a >> 'customer' of, or so I was thinking :) > > i have seen people successful with this with mpls and with vlans with > non-mpls tunnel tech (e.g. ipsec for the paranoid). i have seen them > screw the pooch with both. > > randy > You can compartmentalize your network in lots of ways. What I'd like to know is what ways failed harder in other peoples experience (or at least faster). I'm not sure doing it ISP style is better, but I think it has some benefits. Then again, the opposite is true as well, less complexity means more stability. Usually. From georgeb at gmail.com Sat Jun 13 02:54:36 2015 From: georgeb at gmail.com (G B) Date: Fri, 12 Jun 2015 19:54:36 -0700 Subject: Enterprise network as an ISP with a single huge customer In-Reply-To: References: <557B120D.9000904@megagroup.ru> Message-ID: What I have done is leverage the production data center redundancy to provide connectivity services to any nearby offices in the same region, basically using our colo as the office ISP for internet connectivity but as far as doing vpls services and the like, it has been so far cheaper to contract that out as the places where I have worked have had many more offices than production internet sites with one might call "hardened" internet services. It's just cheaper in most cases to go with a third party vendor to provide a VPLS mesh of all of the offices globally than it is for us to do it. Offices move, close, colos change locations. I can call a vendor, tell them we are moving an office to a different building, they worry about moving the circuit. Trying to mesh everything from Sydney to Bangalore to London to San Francisco and all the branch offices in between is great if you have a bunch of people sitting around who are otherwise unoccupied but if you run a lean headcount anyway, farming this out pays in the long run for the shops where I have worked. Not saying this holds true for every scenario, though. If we had production PoPs in the cities where we had offices, yeah, it might make some sense. On Fri, Jun 12, 2015 at 7:35 PM, Randy Bush wrote: > >> i have seen a lot of this done with firewall devices and vlans. with > >> vlans or mpls, you can make spaghetti without wires, one wheat and one > >> semolina. > > > > oh absolutely. you can use many tools to lop off your fingers, my > > point was that things like mpls (or vlans) provide a nice other tool > > to use along with your firewalls and such. > > > > of course you ought not willy-nilly go crazy with this, but... imagine > > if the 'hr department' were in one contiguous 'VRF' which had a > > defined set of 2-3 exit points to control access through... while > > those willy 'engineers' could be stuck in their own ghetto/VRF and > > have a different set of 2-3 exit points to control. > > > > Expand your network over many locations and in large buildings and ... > > it can be attractive to run a 2547 network that the company is a > > 'customer' of, or so I was thinking :) > > i have seen people successful with this with mpls and with vlans with > non-mpls tunnel tech (e.g. ipsec for the paranoid). i have seen them > screw the pooch with both. > > randy > From raphael.timothy at gmail.com Sat Jun 13 03:00:19 2015 From: raphael.timothy at gmail.com (Tim Raphael) Date: Sat, 13 Jun 2015 11:00:19 +0800 Subject: Enterprise network as an ISP with a single huge customer In-Reply-To: <557B99F8.5090605@megagroup.ru> References: <557B120D.9000904@megagroup.ru> <557B99F8.5090605@megagroup.ru> Message-ID: <707C3FA4-55AC-448A-B5FB-0A8D3246BFC9@gmail.com> It will also depend greatly on the knowledge of the design team / person and the operations team. If the designer is ex-SP or has a strong knowledge of both SP and Enterprise then yes, a good design may result. There are plenty of people out there that will use MPLS / multiple tables for the wrong reasons just so they can say that's what they're doing. Regards, Tim Raphael > On 13 Jun 2015, at 10:48 am, Stepan Kucherenko wrote: > > 13.06.2015 05:35, Randy Bush wrote: >>>> i have seen a lot of this done with firewall devices and vlans. with >>>> vlans or mpls, you can make spaghetti without wires, one wheat and one >>>> semolina. >>> >>> oh absolutely. you can use many tools to lop off your fingers, my >>> point was that things like mpls (or vlans) provide a nice other tool >>> to use along with your firewalls and such. >>> >>> of course you ought not willy-nilly go crazy with this, but... imagine >>> if the 'hr department' were in one contiguous 'VRF' which had a >>> defined set of 2-3 exit points to control access through... while >>> those willy 'engineers' could be stuck in their own ghetto/VRF and >>> have a different set of 2-3 exit points to control. >>> >>> Expand your network over many locations and in large buildings and ... >>> it can be attractive to run a 2547 network that the company is a >>> 'customer' of, or so I was thinking :) >> >> i have seen people successful with this with mpls and with vlans with >> non-mpls tunnel tech (e.g. ipsec for the paranoid). i have seen them >> screw the pooch with both. >> >> randy > > You can compartmentalize your network in lots of ways. What I'd like to know is what ways failed harder in other peoples experience (or at least faster). > > I'm not sure doing it ISP style is better, but I think it has some benefits. Then again, the opposite is true as well, less complexity means more stability. Usually. From rdobbins at arbor.net Sat Jun 13 05:44:44 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 13 Jun 2015 12:44:44 +0700 Subject: Enterprise network as an ISP with a single huge customer In-Reply-To: <707C3FA4-55AC-448A-B5FB-0A8D3246BFC9@gmail.com> References: <557B120D.9000904@megagroup.ru> <557B99F8.5090605@megagroup.ru> <707C3FA4-55AC-448A-B5FB-0A8D3246BFC9@gmail.com> Message-ID: On 13 Jun 2015, at 10:00, Tim Raphael wrote: > There are plenty of people out there that will use MPLS / multiple > tables for the wrong reasons just so they can say that's what they're > doing. Concur 100%. I also agree with both Chris and with Randy with regards to pros and cons of this general approach. In my subjective experience, relatively few enterprises have the technical and operational savvy to design, deploy, operate, and troubleshoot a network designed in such a manner, or even understand the appropriate usage of these technologies, much less reap the benefits thereof. Unless they've invested in hiring people with the right skillsets and breadth/depth of actual operational experience, this can be a path fraught with significant risk. ----------------------------------- Roland Dobbins From swmike at swm.pp.se Sat Jun 13 07:11:34 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 13 Jun 2015 09:11:34 +0200 (CEST) Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <38976.1434092757@turing-police.cc.vt.edu> Message-ID: On Fri, 12 Jun 2015, Baldur Norddahl wrote: > Can someone explain to me how Android uses SLAAC to implement tethering? https://tools.ietf.org/html/rfc7278 -- Mikael Abrahamsson email: swmike at swm.pp.se From baldur.norddahl at gmail.com Sat Jun 13 10:30:29 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 13 Jun 2015 12:30:29 +0200 Subject: Android (lack of) support for DHCPv6 In-Reply-To: References: <20150609031454.GD3716@bender.unx.cpp.edu> <2b1101d0a3c7$a4823340$ed8699c0$@acm.org> <5578B90B.2000409@mtcc.com> <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net> <38976.1434092757@turing-police.cc.vt.edu> Message-ID: On 13 June 2015 at 09:11, Mikael Abrahamsson wrote: > On Fri, 12 Jun 2015, Baldur Norddahl wrote: > > Can someone explain to me how Android uses SLAAC to implement tethering? >> > > https://tools.ietf.org/html/rfc7278 > > -- I have not read it in detail, but correct me if I am wrong, that stuff will NOT work while the phone is on wifi. Quote: " As [RFC6459 ] describes, the 3GPP-network-assigned /64 is completely dedicated to the UE and the gateway does not consume any of the /64 addresses. The gateway routes the entire /64 to the UE and does not perform ND or Neighbor Unreachability Detection (NUD) [RFC4861 ]. Communication between the UE and the gateway is only done using link-local addresses and the link is point-to-point. " It is like a DHCP-PD of a /64 to the phone. I fail to see what relevance that has to a phone supporting DHCP on a Wifi or LAN link. Except of course that it should make it trivial for Android to support DHCP-PD. They already have a system that can consume a /64 from a prefix delegation and use that for both applications on the phone and for tethering (does tethering while on Wifi make sense? - it is possible using bluetooth to a laptop). Regards, Baldur From patrick at ianai.net Sat Jun 13 10:30:47 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 13 Jun 2015 06:30:47 -0400 Subject: DC Circuit denies stay on Neutrality In-Reply-To: <10808022.1505.1434122748828.JavaMail.mhammett@ThunderFuck> References: <10808022.1505.1434122748828.JavaMail.mhammett@ThunderFuck> Message-ID: <21BAB2C4-0D05-436E-BEBD-55255639418D@ianai.net> Hundreds of people / companies on both sides. The point of the article is not "Verizon lost", but that the FCC was not "crazy power-usurping unlawful" (direct quote from article). I.e. The FFC has at least a moderate chance of prevailing. Whether they should or not is actually not the point and only slightly related to the decision. Legal decisions are often misinterpreted by the press and lay people, and I'm sure this one will be to a great extent. I think the article did a good job of explaining it to anyone who reads it with an open mind. -- TTFN, patrick Composed on a virtual keyboard, please forgive typos. > On Jun 12, 2015, at 11:25, Mike Hammett wrote: > > It wasn't only the big guys requesting a stay. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Jay Ashworth" > To: nanog at nanog.org > Sent: Friday, June 12, 2015 10:20:28 AM > Subject: DC Circuit denies stay on Neutrality > > Here is a delightful wacky weekend starter culture for you: a backgrounder on exactly what it means that the DC Circuit denied Verizon et alia a stay of execution on Title II reclassification. > > Complete with bonus brony references. > > http://www.wetmachine.com/tales-of-the-sausage-factory/net-neutrality-litigation-round-1-goes-to-the-fcc/ > > Cheers, > --jra > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From mark.tinka at seacom.mu Sat Jun 13 10:34:35 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 13 Jun 2015 12:34:35 +0200 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: <20150612171247.GO94733@Vurt.local> References: <1434123151.30267.12.camel@galileo.millnert.se> <0681034898E36F448ACAA0EF289BAB7A0186A7AF2A@inp44vdag03.vsnl.co.in> <20150612171247.GO94733@Vurt.local> Message-ID: <557C073B.1050108@seacom.mu> On 12/Jun/15 19:12, Job Snijders wrote: > > > The simplest protection mechanism of all: maximum prefix limits. If you > turn up a peer or customer, confirm with them how many routes you should > expect, add 15% and configure that. For peering and customers, we set a default prefix limit value for IPv4 and IPv6. We only change this if the peer/customer informs us that they will announce a lot more than what we've configured. We add some % to cover for "sudden" growth, but not too much to impact the network. For customers, we add prefix lists and AS_PATH filters as mandatory. I'm sure others do the same. It would be good if we all did. I know the largest transit providers tend to be more relaxed for various reasons. Some rely on filters generated by IRR entries, others don't. A lot more work is needed, indeed. It's not 2008 anymore... Mark. From mark.tinka at seacom.mu Sat Jun 13 10:39:45 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 13 Jun 2015 12:39:45 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> Message-ID: <557C0871.6030800@seacom.mu> On 12/Jun/15 22:25, J?rgen Jaritsch wrote: > This is the official feedback: > > > > Level 3's network, alongside some other ISP's, experienced service disruptions affecting customers in Europe, Asia and multiple other markets. IP, Voice and Content Delivery Network (CDN) services were affected for Level 3. The root cause of the issue was isolated to a third party Internet Service Provider in Asia that leaked internet routes resulting in traffic being sent to a destination that could not route them, which affected IP, Voice and CDN services in multiple markets. The issue has been resolved, but the provider continues working to determine the specific root cause of the incident. At this time, customer services are restored with the exception of any that pose any possible risk to the Level 3 network. Maintaining a reliable, high-performing network for our customers is our top priority. Level 3 will continue to work with the provider to prevent a recurrence. While I agree that TM needs to look into its operational procedures, I think Level(3) needs to shoulder more of the blame, and not simply pass the buck to TM. TM has several more upstreams other than Level(3). Assuming their issue affected all their border routers, we did not see an issue via their other upstreams other than Level(3) - although this is conjecture on my part. Level(3) should have filtered at the time they were turning up TM. Simple as that. We all know we should never trust customers. So... Mark. From mark.tinka at seacom.mu Sat Jun 13 10:43:02 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 13 Jun 2015 12:43:02 +0200 Subject: Enterprise network as an ISP with a single huge customer In-Reply-To: <557B120D.9000904@megagroup.ru> References: <557B120D.9000904@megagroup.ru> Message-ID: <557C0936.5040208@seacom.mu> On 12/Jun/15 19:08, Stepan Kucherenko wrote: > > > How many of you architect your network as an ISP, with that enterprise > as the biggest customer ? Office networks in l3vpn, VPLS/EVPN on top > of your own network for DCI, etc ? Or is it usually just a single IGP > domain with no unnecessary bells and whistles ? We run a commercial ISP network that provides IP and other non-IP services to our customers. On top of that, our corporate/enterprise network is a customer. Implementation is l3vpn with firewalls at each office sitting between the l3vpn and public Internet. Enterprise and Internet traffic is routed accordingly. DCN network is a combination of l2vpn and l3vpn, depending on what part of the network the DCN needs to touch. Mark. From rdobbins at arbor.net Sat Jun 13 10:43:32 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 13 Jun 2015 17:43:32 +0700 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: <557C073B.1050108@seacom.mu> References: <1434123151.30267.12.camel@galileo.millnert.se> <0681034898E36F448ACAA0EF289BAB7A0186A7AF2A@inp44vdag03.vsnl.co.in> <20150612171247.GO94733@Vurt.local> <557C073B.1050108@seacom.mu> Message-ID: On 13 Jun 2015, at 17:34, Mark Tinka wrote: > A lot more work is needed, indeed. It's not 2008 anymore... Nor 1997: ;> ----------------------------------- Roland Dobbins From randy at psg.com Sat Jun 13 10:49:36 2015 From: randy at psg.com (Randy Bush) Date: Sat, 13 Jun 2015 19:49:36 +0900 Subject: Enterprise network as an ISP with a single huge customer In-Reply-To: References: <557B120D.9000904@megagroup.ru> <557B99F8.5090605@megagroup.ru> <707C3FA4-55AC-448A-B5FB-0A8D3246BFC9@gmail.com> Message-ID: > In my subjective experience, relatively few enterprises have the > technical and operational savvy to design, deploy, operate, and > troubleshoot a network designed in such a manner, or even understand > the appropriate usage of these technologies, much less reap the > benefits thereof. i have seen many universities and large enterprises with as much clue as your serious isp. where they fall behind your avaerage nanogger is testosterone poisoning. randy From rdobbins at arbor.net Sat Jun 13 10:57:16 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 13 Jun 2015 17:57:16 +0700 Subject: Enterprise network as an ISP with a single huge customer In-Reply-To: References: <557B120D.9000904@megagroup.ru> <557B99F8.5090605@megagroup.ru> <707C3FA4-55AC-448A-B5FB-0A8D3246BFC9@gmail.com> Message-ID: On 13 Jun 2015, at 17:49, Randy Bush wrote: > i have seen many universities and large enterprises with as much clue > as your serious isp. I've seen a few, but not many. All of the ones I've seen who fall into that category operate significant public-facing infrastructure, so they have personnel with the necessary skillsets and experience. > where they fall behind your avaerage nanogger is testosterone > poisoning. I couldn't agree more. ----------------------------------- Roland Dobbins From Grzegorz at Janoszka.pl Sat Jun 13 11:48:33 2015 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Sat, 13 Jun 2015 13:48:33 +0200 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: <557C073B.1050108@seacom.mu> References: <1434123151.30267.12.camel@galileo.millnert.se> <0681034898E36F448ACAA0EF289BAB7A0186A7AF2A@inp44vdag03.vsnl.co.in> <20150612171247.GO94733@Vurt.local> <557C073B.1050108@seacom.mu> Message-ID: <557C1891.1060702@Janoszka.pl> On 2015-06-13 12:34, Mark Tinka wrote: > I know the largest transit providers tend to be more relaxed for various > reasons. Some rely on filters generated by IRR entries, others don't. Actually I had pretty good experiences with Level3 as it has been years as they could use IRR filters to update automatically your prefix list. I remember that Level3 was one of the first carriers to enable that feature and several years afterwards there were still global networks (tier1) that could only do static prefix-lists. -- Grzegorz Janoszka From jj at anexia.at Sat Jun 13 13:06:21 2015 From: jj at anexia.at (=?Windows-1252?Q?J=FCrgen_Jaritsch?=) Date: Sat, 13 Jun 2015 13:06:21 +0000 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: <557C1891.1060702@Janoszka.pl> References: <1434123151.30267.12.camel@galileo.millnert.se> <0681034898E36F448ACAA0EF289BAB7A0186A7AF2A@inp44vdag03.vsnl.co.in> <20150612171247.GO94733@Vurt.local> <557C073B.1050108@seacom.mu>,<557C1891.1060702@Janoszka.pl> Message-ID: The Level3 automatic prefix update feature is broken since 8-10 months and they are unable to fix it. I can provide ~10 ticket IDs with several discussions about the broken feature. We have to open a ticket with them for every new prefix we want to announce ... J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Original Message----- From: Grzegorz Janoszka [Grzegorz at Janoszka.pl] Received: Samstag, 13 Juni 2015, 13:51 To: nanog at nanog.org [nanog at nanog.org] Subject: Re: Open letter to Level3 concerning the global routing issues on June 12th On 2015-06-13 12:34, Mark Tinka wrote: > I know the largest transit providers tend to be more relaxed for various > reasons. Some rely on filters generated by IRR entries, others don't. Actually I had pretty good experiences with Level3 as it has been years as they could use IRR filters to update automatically your prefix list. I remember that Level3 was one of the first carriers to enable that feature and several years afterwards there were still global networks (tier1) that could only do static prefix-lists. -- Grzegorz Janoszka From rafael at gav.ufsc.br Sat Jun 13 13:31:01 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sat, 13 Jun 2015 08:31:01 -0500 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: <1434123151.30267.12.camel@galileo.millnert.se> References: <1434123151.30267.12.camel@galileo.millnert.se> Message-ID: Something about Malaysia, first the airplanes... now BGP leaks? On Fri, Jun 12, 2015 at 10:32 AM, Martin Millnert wrote: > Dear Level3, > > The Internet is a cooperative effort, and it works well only when its > participants take constructive actions to address errors and remedy > problems. > Your position as a major Internet Carrier bestows upon you a certain > degree of responsibility for the correct operation of the Internet all > across (and beyond) the planet. You have many customers. Customers will > always occasionally make mistakes. You as a major Internet Carrier have > a responsibility to limit, not amplify, your customers' mistakes. > Other major carriers implement technical measures that severely limits > the damages from customer mistakes from having global impact. > Other major carriers also implement operational procedures in addition > to technical measures. > In combination, these measures drastically reduce the outage-hours as a > result of customer configuration errors. > > At 08:44 UTC on Friday 12th of June, one of your transit customers, > Telekom Malaysia (AS4788) began announcing the full Internet table back > to you, which you accepted and propagated to your peers and customers, > causing global outages for close to 3 hours. > [ https://twitter.com/DynResearch/status/609340592036970496 ] > During this 3 hour window, it appears (from your own service outage > reports) that you did nothing to stop the global Internet outage, but > that Telekom Malaysia themselves eventually resolved it. This lack of > action on your end, and your disregard for the correct operation of the > global Internet is astonishing. These mistakes do not need to happen. > AS4788 under normal circumstances announces ~1900 IPv4 prefixes to the > Internet. You accepted multiple hundred thousand prefixes from them - a > max prefix setting would have severely limited the damage. We expect > that these are your practices as well, but they failed. When they do, it > should not take ~3 hours to shut down the session(s). > > Many operators, in despair, turned down their peering sessions with you > once it was clear you were causing the outages and no immediate fix was > in sight. This improved the situation for some - but not all did. Had > you deployed proper IRR-filtering to filter the bad announcements the > impact would've been far less critical. > > As a direct consequence of your ~3 hours of inaction, as a local > example, Swedish payment terminals were experiencing problems all over > the country. The Swedish economy was directly affected by your inaction. > There were queues when I was buying lunch! Imagine the food rage. The > situation was probably similar at other places around the globe where > people were awake. > > Operators around the planet are curious: > - Did Level3 not detect or understand that it was causing global > Internet outages for ~3 hours? > - If Level3 did in fact detect or understand it was causing global > Internet outages, why did it not properly and immediately remedy the > situation? > - What is Level3 going to do to address these questions and begin work > on restoring its credibility as a carrier? > > We all understand that mistakes do happen (in applying customer > interface templates, etc.). However the Internet is all too pervasive in > everyday life today for anything but swift action by carriers to remedy > breakage after the fact. It is absolutely not sufficient to let a > customer spend 3 hours to detect and fix a situation like this one. It > is unacceptable that no swift action was taken on your end to limit the > global routing issues you caused. > > Sincerely, > Martin Millnert > Member of Internet Community - no carrier / ISP affiliation. > From streiner at cluebyfour.org Sat Jun 13 14:16:18 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 13 Jun 2015 10:16:18 -0400 (EDT) Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: <557C073B.1050108@seacom.mu> References: <1434123151.30267.12.camel@galileo.millnert.se> <0681034898E36F448ACAA0EF289BAB7A0186A7AF2A@inp44vdag03.vsnl.co.in> <20150612171247.GO94733@Vurt.local> <557C073B.1050108@seacom.mu> Message-ID: On Sat, 13 Jun 2015, Mark Tinka wrote: > For peering and customers, we set a default prefix limit value for IPv4 > and IPv6. We only change this if the peer/customer informs us that they > will announce a lot more than what we've configured. We add some % to > cover for "sudden" growth, but not too much to impact the network. > > For customers, we add prefix lists and AS_PATH filters as mandatory. > > I'm sure others do the same. It would be good if we all did. > > I know the largest transit providers tend to be more relaxed for various > reasons. Some rely on filters generated by IRR entries, others don't. > > A lot more work is needed, indeed. It's not 2008 anymore... At my previous job (regional ISP with a decent amount of BGP-speaking downstream customers), we did prefix and AS-PATH filtering on all customer sessions. The only thing lacking at that time (1997-2004) was a decent way to automate changes - everything was pretty manual. That said, it kept issues caused by customers leaking routes back to us down to pretty much nil. jms From ghenry at suretec.co.uk Sat Jun 13 12:04:16 2015 From: ghenry at suretec.co.uk (Gavin Henry) Date: Sat, 13 Jun 2015 13:04:16 +0100 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: <557C1891.1060702@Janoszka.pl> References: <1434123151.30267.12.camel@galileo.millnert.se> <0681034898E36F448ACAA0EF289BAB7A0186A7AF2A@inp44vdag03.vsnl.co.in> <20150612171247.GO94733@Vurt.local> <557C073B.1050108@seacom.mu> <557C1891.1060702@Janoszka.pl> Message-ID: > Actually I had pretty good experiences with Level3 as it has been years as they could use IRR filters to update automatically your prefix list. I remember that Level3 was one of the first carriers to enable that feature and several years afterwards there were still global networks (tier1) that could only do static prefix-lists. > It is weird, as they don't take new announcements without their being an inetnum object entry in an IRR. Maybe that's just for us small guys? http://www.surevoip.co.uk (AS199659) From rubensk at gmail.com Sat Jun 13 15:00:08 2015 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 13 Jun 2015 12:00:08 -0300 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: <1434123151.30267.12.camel@galileo.millnert.se> References: <1434123151.30267.12.camel@galileo.millnert.se> Message-ID: > > At 08:44 UTC on Friday 12th of June, one of your transit customers, > Telekom Malaysia (AS4788) began announcing the full Internet table back > to you, which you accepted and propagated to your peers and customers, > causing global outages for close to 3 hours. > One thing of notice is that AS Paths were really not short, so some kind of local preference has to be in place. Although it's usual to apply local preference to transit customers, it's probably wise to only do it for prefixes belonging to customer or registered at IRRs. So, if someone does not want to filter prefixes from customers, at least could not apply larger preference to all such prefixes. Focus on the know prefixes and let AS Path sort out those weird paths. Rubens From swmike at swm.pp.se Sat Jun 13 16:20:31 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 13 Jun 2015 18:20:31 +0200 (CEST) Subject: Apple ECN, Bufferbloat, CoDel (fwd) Message-ID: Hi, I just want to bring to your attention the below talk (I am too lazy to re-write the whole email for this slightly different audience). Takeaway: We'll see a lot of ECN enabled traffic in a few months. This shouldn't be a problem. I've been doing it to all my machines for 3-5 years without ill effects. More people will become interested in how TCP works, from application, through the host stack, to the AQM (or lack thereof) in the router etc. If you don't do AQM towards your customers, be prepared that they're going to start complaining in a more informed manner in the not so distant future. IPv6 only with NAT64+DNS64 will become a lot more feasible going forward. I am not a fan of breaking DNSSEC, but perhaps if we can do the DNS64 in the host (as it seems Apple is doing, at least for IPv4 literals), then that might be possible to work around. ---------- Forwarded message ---------- Date: Sat, 13 Jun 2015 18:07:57 +0200 (CEST) From: Mikael Abrahamsson To: bloat at lists.bufferbloat.net Subject: Apple ECN, Bufferbloat, CoDel I highly encourage people to take a look at: https://developer.apple.com/videos/wwdc/2015/?id=719 (you might have to reigster as an apple developer to watch it, I don't know) "Your App and Next Generation Networks IPv6 is growing exponentially and carriers worldwide are moving to pure IPv6 APNs. Learn about new tools to test your apps for compatibility and get expert advice on making sure your apps work in all network environments. iOS 9 and OS X 10.11 now support the latest TCP standards. Hear from the experts on TCP Fast Open and Explicit Congestion Notification, and find out how it benefits your apps." Being on this list you might not learn much from the talk, but I really appreciate a talk aimed at a wider (developer) audience which so clearly outlines the benefits of ECN, CoDel and TCP host opimization to reduce end-to-end experienced application communication latency. One of the major takeaways is that Apple is planning to by default enable ECN in iOS9 and OSX 10.11. This would mean hundreds of millions of devices will be using ECN in a few months. You can skip to 16 minutes into the talk if you're not interested in the new requirement for applications to support an environment where it's Internet access is IPv6 only behind NAT64+DNS64 (I'm myself super excited about this). Let's hope this brings a lot of buzz and requests towards device manufacturers to start supporting ECN marking and AQM. Apple is usually a good megaphone to bring attention to these kinds of issues... -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at ics-il.net Sat Jun 13 16:29:12 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 13 Jun 2015 11:29:12 -0500 (CDT) Subject: Setting Up a Looking Glass In-Reply-To: <29124575.1241.1434212866266.JavaMail.mhammett@ThunderFuck> Message-ID: <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> What's out there for setting up your own looking glass? I saw lots of lists of dead projects or projects that hadn't received any love in years. Being as most the people I work with don't run Cisco, Juniper, etc. for routers, likely having those capabilities with the LG would be nice. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From jimpop at gmail.com Sat Jun 13 16:38:44 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Sat, 13 Jun 2015 12:38:44 -0400 Subject: Setting Up a Looking Glass In-Reply-To: <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> References: <29124575.1241.1434212866266.JavaMail.mhammett@ThunderFuck> <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> Message-ID: On Sat, Jun 13, 2015 at 12:29 PM, Mike Hammett wrote: > What's out there for setting up your own looking glass? I saw lots of lists of dead projects or projects that hadn't received any love in years. Being as most the people I work with don't run Cisco, Juniper, etc. for routers, likely having those capabilities with the LG would be nice. > Here's a relatively new and fresh perspective on it: https://github.com/ramnode/LookingGlass You can see it in action here: http://lg.nyc.ramnode.com/ -Jim P. From shane at ronan-online.com Sat Jun 13 16:53:58 2015 From: shane at ronan-online.com (Shane Ronan) Date: Sat, 13 Jun 2015 12:53:58 -0400 Subject: Setting Up a Looking Glass In-Reply-To: References: <29124575.1241.1434212866266.JavaMail.mhammett@ThunderFuck> <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> Message-ID: <557C6026.2040400@ronan-online.com> This would be even more AWESOME if you added routing table lookup. On 6/13/15 12:38 PM, Jim Popovitch wrote: > On Sat, Jun 13, 2015 at 12:29 PM, Mike Hammett wrote: >> What's out there for setting up your own looking glass? I saw lots of lists of dead projects or projects that hadn't received any love in years. Being as most the people I work with don't run Cisco, Juniper, etc. for routers, likely having those capabilities with the LG would be nice. >> > Here's a relatively new and fresh perspective on it: > > https://github.com/ramnode/LookingGlass > > You can see it in action here: > http://lg.nyc.ramnode.com/ > > -Jim P. From nanog at ics-il.net Sat Jun 13 16:58:00 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 13 Jun 2015 11:58:00 -0500 (CDT) Subject: Setting Up a Looking Glass In-Reply-To: Message-ID: <3285337.1285.1434214703497.JavaMail.mhammett@ThunderFuck> Since posting, I did stumble upon another one (that actually a friend of mine was involved with creating). I'm not likely to find another implementation that works with Mikrotik. ;-) https://github.com/TomHetmer/MikroGlass/wiki I do like the one you linked to. What's holding it back is a lack of BGP information. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Jim Popovitch" To: "NANOG list" Sent: Saturday, June 13, 2015 11:38:44 AM Subject: Re: Setting Up a Looking Glass On Sat, Jun 13, 2015 at 12:29 PM, Mike Hammett wrote: > What's out there for setting up your own looking glass? I saw lots of lists of dead projects or projects that hadn't received any love in years. Being as most the people I work with don't run Cisco, Juniper, etc. for routers, likely having those capabilities with the LG would be nice. > Here's a relatively new and fresh perspective on it: https://github.com/ramnode/LookingGlass You can see it in action here: http://lg.nyc.ramnode.com/ -Jim P. From jason at unlimitednet.us Sat Jun 13 17:00:36 2015 From: jason at unlimitednet.us (Jason Canady) Date: Sat, 13 Jun 2015 13:00:36 -0400 Subject: Setting Up a Looking Glass In-Reply-To: <557C6026.2040400@ronan-online.com> References: <29124575.1241.1434212866266.JavaMail.mhammett@ThunderFuck> <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> <557C6026.2040400@ronan-online.com> Message-ID: <557C61B4.2090808@unlimitednet.us> I totally agree, it would be awesome if it had routing table lookups / BGP queries. We also have a LG running the original system, https://github.com/telephone/LookingGlass. It would probably be pretty simple to add in BGP options. There's a nice system called bgplg that is part of OpenBSD. A quick Internet search will bring up many providers that utilize it so that you can check it out. -- Jason Canady Unlimited Net, LLC Responsive, Reliable, Secure On 6/13/15 12:53 PM, Shane Ronan wrote: > This would be even more AWESOME if you added routing table lookup. > > > On 6/13/15 12:38 PM, Jim Popovitch wrote: >> On Sat, Jun 13, 2015 at 12:29 PM, Mike Hammett wrote: >>> What's out there for setting up your own looking glass? I saw lots >>> of lists of dead projects or projects that hadn't received any love >>> in years. Being as most the people I work with don't run Cisco, >>> Juniper, etc. for routers, likely having those capabilities with the >>> LG would be nice. >>> >> Here's a relatively new and fresh perspective on it: >> >> https://github.com/ramnode/LookingGlass >> >> You can see it in action here: >> http://lg.nyc.ramnode.com/ >> >> -Jim P. > From jimpop at gmail.com Sat Jun 13 17:02:24 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Sat, 13 Jun 2015 13:02:24 -0400 Subject: Setting Up a Looking Glass In-Reply-To: <557C6026.2040400@ronan-online.com> References: <29124575.1241.1434212866266.JavaMail.mhammett@ThunderFuck> <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> <557C6026.2040400@ronan-online.com> Message-ID: On Sat, Jun 13, 2015 at 12:53 PM, Shane Ronan wrote: > This would be even more AWESOME if you added routing table lookup. I'll suggest that to the author. -Jim P. From joelja at bogus.com Sat Jun 13 18:07:18 2015 From: joelja at bogus.com (joel jaeggli) Date: Sat, 13 Jun 2015 11:07:18 -0700 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <557C0871.6030800@seacom.mu> References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <557C0871.6030800@seacom.mu> Message-ID: <557C7156.8000008@bogus.com> On 6/13/15 3:39 AM, Mark Tinka wrote: > > > On 12/Jun/15 22:25, J?rgen Jaritsch wrote: >> This is the official feedback: >> >> >> >> Level 3's network, alongside some other ISP's, experienced service disruptions affecting customers in Europe, Asia and multiple other markets. IP, Voice and Content Delivery Network (CDN) services were affected for Level 3. The root cause of the issue was isolated to a third party Internet Service Provider in Asia that leaked internet routes resulting in traffic being sent to a destination that could not route them, which affected IP, Voice and CDN services in multiple markets. The issue has been resolved, but the provider continues working to determine the specific root cause of the incident. At this time, customer services are restored with the exception of any that pose any possible risk to the Level 3 network. Maintaining a reliable, high-performing network for our customers is our top priority. Level 3 will continue to work with the provider to prevent a recurrence. > > While I agree that TM needs to look into its operational procedures, I > think Level(3) needs to shoulder more of the blame, and not simply pass > the buck to TM. if you localpref your customer up, you should probably not be willing to accept the whole internet from them. > TM has several more upstreams other than Level(3). Assuming their issue > affected all their border routers, we did not see an issue via their > other upstreams other than Level(3) - although this is conjecture on my > part. they also have ~ 180 ASNs in their downstream cone who presumably get a full table have the export policy that did the business in this case applied all the time. > Level(3) should have filtered at the time they were turning up TM. > Simple as that. > > We all know we should never trust customers. So... > > Mark. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From hank at efes.iucc.ac.il Sat Jun 13 18:54:54 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 13 Jun 2015 21:54:54 +0300 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: <1434123151.30267.12.camel@galileo.millnert.se> Message-ID: <5.1.1.6.2.20150613215121.01f39398@efes.iucc.ac.il> At 17:32 12/06/2015 +0200, Martin Millnert wrote: Interesting that Level3 is a member of http://www.routingmanifesto.org/ or see http://www.internetsociety.org/news/network-operators-around-world-demonstrate-their-commitment-secure-and-resilient-internet to quote Level3 "As one of the most connected Internet providers in the world, security of the Internet is top-of-mind at Level 3 Communications. We are dedicated to supporting and protecting the Internet ecosystem and work each day to safeguard customers' critical communications. The Internet is a shared responsibility, and only through these important collaborative efforts can we continue to ensure the protection of this collective infrastructure." -Hank >Dear Level3, > >The Internet is a cooperative effort, and it works well only when its >participants take constructive actions to address errors and remedy >problems. >Your position as a major Internet Carrier bestows upon you a certain >degree of responsibility for the correct operation of the Internet all >across (and beyond) the planet. You have many customers. Customers will >always occasionally make mistakes. You as a major Internet Carrier have >a responsibility to limit, not amplify, your customers' mistakes. >Other major carriers implement technical measures that severely limits >the damages from customer mistakes from having global impact. >Other major carriers also implement operational procedures in addition >to technical measures. >In combination, these measures drastically reduce the outage-hours as a >result of customer configuration errors. > >At 08:44 UTC on Friday 12th of June, one of your transit customers, >Telekom Malaysia (AS4788) began announcing the full Internet table back >to you, which you accepted and propagated to your peers and customers, >causing global outages for close to 3 hours. >[ https://twitter.com/DynResearch/status/609340592036970496 ] >During this 3 hour window, it appears (from your own service outage >reports) that you did nothing to stop the global Internet outage, but >that Telekom Malaysia themselves eventually resolved it. This lack of >action on your end, and your disregard for the correct operation of the >global Internet is astonishing. These mistakes do not need to happen. >AS4788 under normal circumstances announces ~1900 IPv4 prefixes to the >Internet. You accepted multiple hundred thousand prefixes from them - a >max prefix setting would have severely limited the damage. We expect >that these are your practices as well, but they failed. When they do, it >should not take ~3 hours to shut down the session(s). > >Many operators, in despair, turned down their peering sessions with you >once it was clear you were causing the outages and no immediate fix was >in sight. This improved the situation for some - but not all did. Had >you deployed proper IRR-filtering to filter the bad announcements the >impact would've been far less critical. > >As a direct consequence of your ~3 hours of inaction, as a local >example, Swedish payment terminals were experiencing problems all over >the country. The Swedish economy was directly affected by your inaction. >There were queues when I was buying lunch! Imagine the food rage. The >situation was probably similar at other places around the globe where >people were awake. > >Operators around the planet are curious: > - Did Level3 not detect or understand that it was causing global >Internet outages for ~3 hours? > - If Level3 did in fact detect or understand it was causing global >Internet outages, why did it not properly and immediately remedy the >situation? > - What is Level3 going to do to address these questions and begin work >on restoring its credibility as a carrier? > >We all understand that mistakes do happen (in applying customer >interface templates, etc.). However the Internet is all too pervasive in >everyday life today for anything but swift action by carriers to remedy >breakage after the fact. It is absolutely not sufficient to let a >customer spend 3 hours to detect and fix a situation like this one. It >is unacceptable that no swift action was taken on your end to limit the >global routing issues you caused. > >Sincerely, >Martin Millnert >Member of Internet Community - no carrier / ISP affiliation. From me at anuragbhatia.com Sat Jun 13 19:39:44 2015 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sun, 14 Jun 2015 01:09:44 +0530 Subject: Question about EX - SRX redundancy In-Reply-To: <20150402222234.GH9851@bamboo.slabnet.com> References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> <20150402222234.GH9851@bamboo.slabnet.com> Message-ID: Hello everyone Just thought to update over here that I was able to get it done as needed. Some quick points across the same on building redundancy between Juniper EX and SRX devices: 1. Virtual chassis in EX is very different from clustering in SRX and I did not realized the same initially. 2. Key difference is that in virtual chassis both devices run in stacked config and act as single device while routing engine of primary/master EX is used. 3. In case of SRX only one device runs at a time and ports of other SRX (slave) do not access traffic at all as long as it see the master is up via heartbeat. So keeping above points in mind, I did 6 cables connection between EX and SRX. On SRX side all 6 ports belong to same reth bundle (3 on SRX-0 and 3 on SRX-1). On Ex side configuration is in a way to use two ae bundles. If we use same ae bundle for all 6 ports then problem comes up as a % of traffic will hit SRX-1 (slave/secondary) and would be trashed which is not desired. Hence we need to make two ae bundles as say ae1 and ae2. One bundle goes towards one SRX (say master SRX-0) and other bundle goes towards other SRX-1. Ports in ae1 and ae2 can be distributed across multiple Ex to ensure redundancy. So setup can work as: EX-0 >> 2 patches >> SRX-0 EX-1 >> 2 patches >> SRX-1 Ex-0 >> 1 patch >> SRX-1 Ex-1 >> 1 patch >> SRX-0 Now all ports on Ex towards SRX0 go in ae1 and SRX1 go in ae2. Thanks everyone for help and inputs. Have a good weekend ahead! On Fri, Apr 3, 2015 at 3:52 AM, Hugo Slabbert wrote: > I just want to confirm your setup. > > The "criss-cross" setup you were describing is different from what I > described. > > You listed: > > > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>>>>>> > EX0 (ae1) >> One patch to SRX1 (reth1) >>>>>>> > >>>>>>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>>>>>> > EX1 (ae2) >> One patch to SRX0 (reth1) >>>>>>> >>>>>> > ...meaning that your AEs cannot survive losing either one of the EX VC > members, and you're splitting each AE's connectivity across the two SRX > chassis cluster members. You need to dedicate an AE to an SRX chassis > cluster member. > > IOW: ae18 should have one LAG member on EX0 and one member on EX1, and > both of those physical ports go to SRX0. Likewise, ae20 should have one > LAG member on EX0 and one member on EX1, and both of those physical ports > go to SRX1. > > When you shut one of the AEs (e.g. ae18) in the setup I describe, you > *will* lose connectivity to its corresponding SRX, as those are > fate-sharing. You would need to configure interface monitoring on the > chassis cluster to flip over the primary to 2nd SRX in order to survive > that, since the second AE (ae20) that is tied to the 2nd SRX is still up. > > Your failure modes are: > > e.g. 1: lose an EX, you lose the throughput that's being contributed to > the AE by that VC member's ports, but both SRXs remain available and the > primary shouldn't flip (provided your node priorities and > interface-monitoring weights are set accordingly). > > e.g. 2: shut an AE (which spans both EX VC members), one SRX goes dark > since you've killed the AE that's dedicated to it, and the primary will > need to flip (either through interface monitoring or manually) in order for > the setup to remain online. > > -- > Hugo > > > On Fri 2015-Apr-03 02:41:35 +0530, Anurag Bhatia > wrote: > > Hi >> >> >> Tried exactly same. Note: it's ae18 and ae20 on EX side and reth4 on SRX >> side. >> >> >> Initially worked but when I took down ae18, i.e ae18 is disabled, now on >> ae20 I am getting: >> >> show interfaces ae20 >> Physical interface: ae20, Enabled, Physical link is Up >> Interface index: 533, SNMP ifIndex: 924 >> Link-level type: Ethernet, MTU: 1514, Speed: 2Gbps, BPDU Error: None, >> MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, >> Flow control: Disabled, Minimum links needed: 1, Minimum bandwidth >> needed: 0 >> >> >> >> on reth4 on SRX I am getting: >> >> show interfaces reth4 >> Physical interface: reth4, Enabled, Physical link is Down >> Interface index: 132, SNMP ifIndex: 696 >> >> >> >> Any idea why so? All physical ports are up (none is shut) and only thing >> which I shut is one of ae bundles. Also rather then disabling ae18 if I >> disabled associated physical ports behavior is just the same i.e reth4 >> goes >> down. >> >> >> >> >> Thanks for your time and help! >> >> >> >> On Fri, Apr 3, 2015 at 12:25 AM, Hugo Slabbert wrote: >> >> Putting the EXs in a VC and splitting your AEs across the 2x VC members >>> takes care of that. >>> >>> EXVC (ae1) >> Two Patches to SRX0 (reth1) >>> EXVC (ae2) >> Two Patches to SRX1 (reth1) >>> >>> ...where EXVC is a VC composed of EX0 and EX1, and ae1 and ae2 both have >>> one member interface from each VC member. >>> >>> In a failure of EX0 or EX1, your throughput on ae1 and ae2 halves as they >>> each lose a LAG member, but both SRX0 and SRX1 are still reachable. >>> >>> -- >>> Hugo >>> >>> >>> On Thu 2015-Apr-02 23:50:46 +0530, Anurag Bhatia >>> wrote: >>> >>> Hi >>> >>>> >>>> >>>> >>>> Yes, >>>> >>>> >>>> Since SRX0 connected to EX0 and SRX1 connected to EX1 (only). Thus >>>> either >>>> pair - 0 will work or pair - 1 will work. I wish if criss crossing >>>> worked >>>> then failure of one EX would have still made both SRX available. >>>> >>>> >>>> In current worst case scenario - failure of EX0 and SRX1 can cause full >>>> outage. >>>> >>>> >>>> >>>> Thanks. >>>> >>>> On Thu, Apr 2, 2015 at 9:21 PM, Hugo Slabbert wrote: >>>> >>>> In: >>>> >>>>> >>>>> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>>>> >>>>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>>>>> >>>>>>> >>>>>>> >>>>>>> with: >>>>>> >>>>> >>>>> > that if one EX goes down then I cannot make use of other >>>>> corresponding >>>>> >>>>> SRX. >>>>>> >>>>>>> >>>>>>> >>>>>>> Do you mean that e.g. if SRX0 is the chassis cluster primary and >>>>>> EX0 >>>>>> >>>>> goes >>>>> down, then you can't use SRX0, but you would like to be able to survive >>>>> EX0 >>>>> going down *without* failing over the SRX chassis cluster to SRX1? >>>>> >>>>> -- >>>>> Hugo >>>>> >>>>> >>>>> On Thu 2015-Apr-02 20:47:03 +0530, Anurag Bhatia >>>>> wrote: >>>>> >>>>> Hi >>>>> >>>>> >>>>>> >>>>>> I thought cross chassis lag is supposed by the use of reth bundled at >>>>>> SRX >>>>>> end. I read this is basically the major difference in reth Vs ae >>>>>> bundle >>>>>> in >>>>>> SRX. >>>>>> >>>>>> >>>>>> Interesting factor here is that ae bundles can spread across multiple >>>>>> EX >>>>>> chassis in a virtual chassis environment but this cannot be the case >>>>>> with >>>>>> ae bundles in SRX. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks. >>>>>> >>>>>> On Thu, Apr 2, 2015 at 7:59 PM, Bill Blackford >>>>>> wrote: >>>>>> >>>>>> It's my understanding that a cross chassis LAG is not supported. If >>>>>> there >>>>>> >>>>>> is a way, I'm not aware of it. I'm running the same set up as your >>>>>>> working >>>>>>> example in my locations and for now, this suits my requirements. >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>> > On Apr 2, 2015, at 07:12, Anurag Bhatia >>>>>>> wrote: >>>>>>> > >>>>>>> > Hello everyone! >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > I have got two Juniper EX series switches (on virtual chassis) and >>>>>>> two >>>>>>> SRX >>>>>>> > devices on native clustering. >>>>>>> > >>>>>>> > >>>>>>> > I am trying to have a highly available redundancy between them with >>>>>>> atleast >>>>>>> > 2Gbps capacity all the time but kind of failing. I followed >>>>>>> Juniper's >>>>>>> > official page here >>>>>>> > >>>>>>> as >>>>>>> well as >>>>>>> > this detailed forum link here >>>>>>> > < >>>>>>> http://forums.juniper.net/t5/SRX-Services-Gateway/Best-way- >>>>>>> of-redundancy-between-SRX-and-EX/td-p/181365 >>>>>>> > >>>>>>> > . >>>>>>> > >>>>>>> > >>>>>>> > I wish to have a case where devices are connected criss cross and >>>>>>> following >>>>>>> > the documentation I get two ae bundles in EX side and one single >>>>>>> reth >>>>>>> > bundle on SRX side. Both ae bundles on EX side have identical >>>>>>> configuration >>>>>>> > and VLAN has both ae interfaces called up. >>>>>>> > >>>>>>> > >>>>>>> > If I do not go for criss cross connectivity like this: >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>>>>>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>>>>>> > >>>>>>> > >>>>>>> > Then it works all well and redundancy works fine. In this case as >>>>>>> long >>>>>>> as 1 >>>>>>> > out of 4 patch is connected connectivity stays live but this has >>>>>>> trade >>>>>>> off >>>>>>> > that if one EX goes down then I cannot make use of other >>>>>>> corresponding >>>>>>> SRX. >>>>>>> > >>>>>>> > If I do criss connectivity, something like: >>>>>>> > >>>>>>> > >>>>>>> > EX0 (ae1) >> Two Patches to SRX0 (reth1) >>>>>>> > EX0 (ae1) >> One patch to SRX1 (reth1) >>>>>>> > >>>>>>> > EX1 (ae2) >> Two Patches to SRX1 (reth1) >>>>>>> > EX1 (ae2) >> One patch to SRX0 (reth1) >>>>>>> > >>>>>>> > >>>>>>> > In this config system behaves very oddly with one ae pair (and it's >>>>>>> > corresponding physical ports) working well while failover to other >>>>>>> ae >>>>>>> > bundle fails completely. >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > I was wondering if someone can point me out here. >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > Appreciate your time and help! >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > >>>>>>> > >>>>>>> > Anurag Bhatia >>>>>>> > anuragbhatia.com >>>>>>> > >>>>>>> > Linkedin | Twitter >>>>>>> > >>>>>>> > Skype: anuragbhatia.com >>>>>>> > >>>>>>> > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E >>>>>>> 58E2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> Anurag Bhatia >>>>>> anuragbhatia.com >>>>>> >>>>>> Linkedin | Twitter >>>>>> >>>>>> Skype: anuragbhatia.com >>>>>> >>>>>> PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 >>>>>> >>>>>> >>>>>> >>>>> >>>> -- >>>> >>>> >>>> Anurag Bhatia >>>> anuragbhatia.com >>>> >>>> Linkedin | Twitter >>>> >>>> Skype: anuragbhatia.com >>>> >>>> PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 >>>> >>>> >>> >> >> -- >> >> >> Anurag Bhatia >> anuragbhatia.com >> >> Linkedin | Twitter >> >> Skype: anuragbhatia.com >> >> PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 >> > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From randy at psg.com Sat Jun 13 20:28:10 2015 From: randy at psg.com (Randy Bush) Date: Sun, 14 Jun 2015 05:28:10 +0900 Subject: Setting Up a Looking Glass In-Reply-To: References: <29124575.1241.1434212866266.JavaMail.mhammett@ThunderFuck> <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> Message-ID: > Here's a relatively new and fresh perspective on it: > https://github.com/ramnode/LookingGlass > You can see it in action here: > http://lg.nyc.ramnode.com/ looking glass without routing, indeed a new perspective :( randy From jimpop at gmail.com Sat Jun 13 20:36:06 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Sat, 13 Jun 2015 16:36:06 -0400 Subject: Setting Up a Looking Glass In-Reply-To: References: <29124575.1241.1434212866266.JavaMail.mhammett@ThunderFuck> <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> Message-ID: On Sat, Jun 13, 2015 at 4:28 PM, Randy Bush wrote: >> Here's a relatively new and fresh perspective on it: >> https://github.com/ramnode/LookingGlass >> You can see it in action here: >> http://lg.nyc.ramnode.com/ > > looking glass without routing, indeed a new perspective :( But routing is so perfect these days... For those curious, the devs like the idea of adding BGP queries, and are considering adding it (and I'm fairly certain that they probably will). -Jim P. From theodore at ciscodude.net Sat Jun 13 20:39:13 2015 From: theodore at ciscodude.net (Theodore Baschak) Date: Sat, 13 Jun 2015 15:39:13 -0500 Subject: Setting Up a Looking Glass In-Reply-To: <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> References: <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> Message-ID: > On Jun 13, 2015, at 11:29 AM, Mike Hammett wrote: > > What's out there for setting up your own looking glass? I saw lots of lists of dead projects or projects that hadn't received any love in years. Being as most the people I work with don't run Cisco, Juniper, etc. for routers, likely having those capabilities with the LG would be nice. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > If you want/need BGP, OpenBSD + OpenBGPD (with their bgplg cgi/restricted shell) is fairly easy to set up. You mesh the looking glass in like any other router in your system, and it gives you full visibility. I wrote a how-to that you can basically copy and paste into a new 1vCPU/1GB vRAM OpenBSD VM which a lot of people have found helpful in setting this type of thing up: https://ciscodude.net/2014/05/14/openbsd-5-dot-5-bgplg/ This was written for 5.5 but also works on 5.6. I will be checking what changes with 5.7 in the coming weeks as time permits, and will write a followup article if need be. bgplg also is brandable, there is a template file you can edit to change the logos, and add additional information about your network if desired. Similar to what I?ve written about with OpenBSD, you could also peer a system running BIRD (not announcing anything) into your network, and run ulg.py (https://github.com/tmshlvck/ulg ). Theo Baschak From job at instituut.net Sat Jun 13 20:55:32 2015 From: job at instituut.net (Job Snijders) Date: Sat, 13 Jun 2015 22:55:32 +0200 Subject: Setting Up a Looking Glass In-Reply-To: References: <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> Message-ID: <20150613205532.GT94733@Vurt.local> On Sat, Jun 13, 2015 at 03:39:13PM -0500, Theodore Baschak wrote: > If you want/need BGP, OpenBSD + OpenBGPD (with their bgplg > cgi/restricted shell) is fairly easy to set up. You mesh the looking > glass in like any other router in your system, and it gives you full > visibility. I wrote a how-to that you can basically copy and paste > into a new 1vCPU/1GB vRAM OpenBSD VM which a lot of people have found > helpful in setting this type of thing up: > https://ciscodude.net/2014/05/14/openbsd-5-dot-5-bgplg/ Cool, thanks. > Similar to what I?ve written about with OpenBSD, you could also peer a > system running BIRD (not announcing anything) into your network, and > run ulg.py (https://github.com/tmshlvck/ulg Another BIRD based looking glass which is nice is "bird-lg" https://github.com/sileht/bird-lg/ - bird-lg makes it easy to deal with multiple routers and do lookups in parallel. I have an instance running here for the AS199036 NLNOG RING route collector: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=www.nanog.org (or the nice bgp_map view: http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv6?q=www.nanog.org ) In the past I've set up a VM w/ BIRD next to each important router, have the router send a full table to the BIRD instance, and use bird-lg to aggregate lookup access to all those views. This way we didn't need to expose direct access to the PEs themselves. Kind regards, Job From randy at psg.com Sat Jun 13 22:10:58 2015 From: randy at psg.com (Randy Bush) Date: Sun, 14 Jun 2015 07:10:58 +0900 Subject: Setting Up a Looking Glass In-Reply-To: References: <29124575.1241.1434212866266.JavaMail.mhammett@ThunderFuck> <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> Message-ID: >> Here's a relatively new and fresh perspective on it: >> https://github.com/ramnode/LookingGlass >> You can see it in action here: >> http://lg.nyc.ramnode.com/ > looking glass without routing, indeed a new perspective :( with a bit more coffee, perhaps i can expand a bit. for widely distributed data plane probes (ping/traceroute/...), we have good alternatives, nlring, ripe atlas, traceroute.org, etc. as an op, nlring is my fave of the month as i can go from question to result in minimal typing and a matter of seconds. 'looking glass' has traditionally meant a control plane (routing) view. this is a rarer beast, and setting one up is often a bit crude. randy From jimpop at gmail.com Sat Jun 13 22:21:15 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Sat, 13 Jun 2015 18:21:15 -0400 Subject: Setting Up a Looking Glass In-Reply-To: References: <29124575.1241.1434212866266.JavaMail.mhammett@ThunderFuck> <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> Message-ID: On Sat, Jun 13, 2015 at 6:10 PM, Randy Bush wrote: >>> Here's a relatively new and fresh perspective on it: >>> https://github.com/ramnode/LookingGlass >>> You can see it in action here: >>> http://lg.nyc.ramnode.com/ >> looking glass without routing, indeed a new perspective :( > > with a bit more coffee, perhaps i can expand a bit. > > for widely distributed data plane probes (ping/traceroute/...), we have > good alternatives, nlring, ripe atlas, traceroute.org, etc. as an op, > nlring is my fave of the month as i can go from question to result in > minimal typing and a matter of seconds. > > 'looking glass' has traditionally meant a control plane (routing) view. > this is a rarer beast, and setting one up is often a bit crude. Indeed. As with most things there are always more than one meaning, and of course even those change with time. I read into the OP's words that he was looking for a locally hosted capability that he could easily give out to his people in order to trouble shoot connectivity. -Jim P. From mansaxel at besserwisser.org Sat Jun 13 23:17:58 2015 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 14 Jun 2015 01:17:58 +0200 Subject: Enterprise network as an ISP with a single huge customer In-Reply-To: <557B120D.9000904@megagroup.ru> References: <557B120D.9000904@megagroup.ru> Message-ID: <20150613231758.GK2816@besserwisser.org> Subject: Enterprise network as an ISP with a single huge customer Date: Fri, Jun 12, 2015 at 08:08:29PM +0300 Quoting Stepan Kucherenko (twh at megagroup.ru): > Hello, > > I'm sure lots of you work for big enterprises, and some of you work > for biggest of them. > > How many of you architect your network as an ISP, with that > enterprise as the biggest customer ? Office networks in l3vpn, > VPLS/EVPN on top of your own network for DCI, etc ? Or is it usually > just a single IGP domain with no unnecessary bells and whistles ? We do at $dayjob (public service radio station network). We try to stay away from the TE side of MPLS, but the other knobs are in pretty much use. A lot of our newer uses for the network are realtime audio in hi-fi quality. Latency is our enemy, and so we don't do TCP, we skip retransmits, buffers to be able to wait for a late packet are so short it rarely matters, etc. That means a lot of prioritisation being done. It is easier in our "isp-type" network. As a very distributed company (in meatspace, but at the same time very unified in infrastructure) we sure need the flexibility. Doing this on usual VLAN/routing would not fly very well. A lot of the devices we run aren't really fit for living with other networked devices, especially those devices fondled by Users. We usually just push them in another VRF. > Do you think one approach is better than the other ? If so, why ? I'd love to have a single flat routing domain. But I do not think it works with the kind of legacy stuff (some of it brand new...) we run. > I understand that it usually comes down to specific circumstances > and most likely scale but I'd still love to hear about your > experience. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Concentrate on th'cute, li'l CARTOON GUYS! Remember the SERIAL NUMBERS!! Follow the WHIPPLE AVE. EXIT!! Have a FREE PEPSI!! Turn LEFT at th'HOLIDAY INN!! JOIN the CREDIT WORLD!! MAKE me an OFFER!!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From rafael at gav.ufsc.br Sat Jun 13 16:54:51 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sat, 13 Jun 2015 11:54:51 -0500 Subject: Hardware monitoring Message-ID: Hi everyone, I know this is slightly off-topic, but since it's still related to the list, I thought I'd give it a try. I am wondering what systems are out there (open source, preferably) for data collection and processing of hardware health data (temperature, CPU clock, fan speeds, etc). Ideally brand agnostic and location agnostic as well. I know of Cacti, but it would require SNMP enabled devices AFAIK, so room/generator/misc monitors wouldn't necessarily be included. Thanks in advance. Rafael From rafael at gav.ufsc.br Sat Jun 13 19:06:33 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sat, 13 Jun 2015 14:06:33 -0500 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: <5.1.1.6.2.20150613215121.01f39398@efes.iucc.ac.il> References: <1434123151.30267.12.camel@galileo.millnert.se> <5.1.1.6.2.20150613215121.01f39398@efes.iucc.ac.il> Message-ID: A lot of these things are for show only.. Like a big corporation donating to non-profits and sponsoring "feel good" events. You can see that a lot of these same businesses also lobby Washington like crazy, so there you go... This was either an isolated incident or they really don't care much. On Sat, Jun 13, 2015 at 1:54 PM, Hank Nussbacher wrote: > At 17:32 12/06/2015 +0200, Martin Millnert wrote: > > Interesting that Level3 is a member of http://www.routingmanifesto.org/ > > or see > > > http://www.internetsociety.org/news/network-operators-around-world-demonstrate-their-commitment-secure-and-resilient-internet > > to quote Level3 > "As one of the most connected Internet providers in the world, security of > the Internet is top-of-mind at Level 3 Communications. We are dedicated to > supporting and protecting the Internet ecosystem and work each day to > safeguard customers' critical communications. The Internet is a shared > responsibility, and only through these important collaborative efforts can > we continue to ensure the protection of this collective infrastructure." > > -Hank > > > Dear Level3, >> >> The Internet is a cooperative effort, and it works well only when its >> participants take constructive actions to address errors and remedy >> problems. >> Your position as a major Internet Carrier bestows upon you a certain >> degree of responsibility for the correct operation of the Internet all >> across (and beyond) the planet. You have many customers. Customers will >> always occasionally make mistakes. You as a major Internet Carrier have >> a responsibility to limit, not amplify, your customers' mistakes. >> Other major carriers implement technical measures that severely limits >> the damages from customer mistakes from having global impact. >> Other major carriers also implement operational procedures in addition >> to technical measures. >> In combination, these measures drastically reduce the outage-hours as a >> result of customer configuration errors. >> >> At 08:44 UTC on Friday 12th of June, one of your transit customers, >> Telekom Malaysia (AS4788) began announcing the full Internet table back >> to you, which you accepted and propagated to your peers and customers, >> causing global outages for close to 3 hours. >> [ https://twitter.com/DynResearch/status/609340592036970496 ] >> During this 3 hour window, it appears (from your own service outage >> reports) that you did nothing to stop the global Internet outage, but >> that Telekom Malaysia themselves eventually resolved it. This lack of >> action on your end, and your disregard for the correct operation of the >> global Internet is astonishing. These mistakes do not need to happen. >> AS4788 under normal circumstances announces ~1900 IPv4 prefixes to the >> Internet. You accepted multiple hundred thousand prefixes from them - a >> max prefix setting would have severely limited the damage. We expect >> that these are your practices as well, but they failed. When they do, it >> should not take ~3 hours to shut down the session(s). >> >> Many operators, in despair, turned down their peering sessions with you >> once it was clear you were causing the outages and no immediate fix was >> in sight. This improved the situation for some - but not all did. Had >> you deployed proper IRR-filtering to filter the bad announcements the >> impact would've been far less critical. >> >> As a direct consequence of your ~3 hours of inaction, as a local >> example, Swedish payment terminals were experiencing problems all over >> the country. The Swedish economy was directly affected by your inaction. >> There were queues when I was buying lunch! Imagine the food rage. The >> situation was probably similar at other places around the globe where >> people were awake. >> >> Operators around the planet are curious: >> - Did Level3 not detect or understand that it was causing global >> Internet outages for ~3 hours? >> - If Level3 did in fact detect or understand it was causing global >> Internet outages, why did it not properly and immediately remedy the >> situation? >> - What is Level3 going to do to address these questions and begin work >> on restoring its credibility as a carrier? >> >> We all understand that mistakes do happen (in applying customer >> interface templates, etc.). However the Internet is all too pervasive in >> everyday life today for anything but swift action by carriers to remedy >> breakage after the fact. It is absolutely not sufficient to let a >> customer spend 3 hours to detect and fix a situation like this one. It >> is unacceptable that no swift action was taken on your end to limit the >> global routing issues you caused. >> >> Sincerely, >> Martin Millnert >> Member of Internet Community - no carrier / ISP affiliation. >> > > From bilco105 at gmail.com Sat Jun 13 22:12:28 2015 From: bilco105 at gmail.com (Rob Greenwood) Date: Sat, 13 Jun 2015 23:12:28 +0100 Subject: Question about EX - SRX redundancy In-Reply-To: References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> <20150402222234.GH9851@bamboo.slabnet.com> Message-ID: <33C0B3C9-AB2D-4AB1-AA94-010E97FA432F@gmail.com> > 3. In case of SRX only one device runs at a time and ports of other SRX > (slave) do not access traffic at all as long as it see the master is up via > heartbeat. Not entirely accurate. The control plane (routing engine) is only active on one SRX at a time, however, the data plane is active on both. This means in your configuration, both ae1 and ae2 on the EX will be passing traffic to both SRXs. It?s also worth noting you can create multiple redundancy groups and split them between both SRXs. If a device fails, all redundancy groups on the failed device will be migrated to the remaining one. -Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From byron.hicks at tx-learn.net Sun Jun 14 02:40:22 2015 From: byron.hicks at tx-learn.net (Hicks, Byron) Date: Sun, 14 Jun 2015 02:40:22 +0000 Subject: Setting Up a Looking Glass In-Reply-To: References: <29124575.1241.1434212866266.JavaMail.mhammett@ThunderFuck> <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> Message-ID: http://sourceforge.net/projects/routerproxy/ Is my looking glass/router proxy of choice. > On Jun 13, 2015, at 5:21 PM, Jim Popovitch wrote: > > On Sat, Jun 13, 2015 at 6:10 PM, Randy Bush wrote: >>>> Here's a relatively new and fresh perspective on it: >>>> https://github.com/ramnode/LookingGlass >>>> You can see it in action here: >>>> http://lg.nyc.ramnode.com/ >>> looking glass without routing, indeed a new perspective :( >> >> with a bit more coffee, perhaps i can expand a bit. >> >> for widely distributed data plane probes (ping/traceroute/...), we have >> good alternatives, nlring, ripe atlas, traceroute.org, etc. as an op, >> nlring is my fave of the month as i can go from question to result in >> minimal typing and a matter of seconds. >> >> 'looking glass' has traditionally meant a control plane (routing) view. >> this is a rarer beast, and setting one up is often a bit crude. > > Indeed. As with most things there are always more than one meaning, > and of course even those change with time. I read into the OP's > words that he was looking for a locally hosted capability that he > could easily give out to his people in order to trouble shoot > connectivity. > > -Jim P. ? Byron Hicks Lonestar Education and Research Network 972-746-2549 aim/skype: byronhicks -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3648 bytes Desc: not available URL: From josh at imaginenetworksllc.com Sun Jun 14 02:53:08 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sat, 13 Jun 2015 22:53:08 -0400 Subject: Hardware monitoring In-Reply-To: References: Message-ID: Xymon Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Jun 13, 2015 10:51 PM, "Rafael Possamai" wrote: > Hi everyone, > > I know this is slightly off-topic, but since it's still related to the > list, I thought I'd give it a try. I am wondering what systems are out > there (open source, preferably) for data collection and processing of > hardware health data (temperature, CPU clock, fan speeds, etc). Ideally > brand agnostic and location agnostic as well. > > I know of Cacti, but it would require SNMP enabled devices AFAIK, so > room/generator/misc monitors wouldn't necessarily be included. > > > Thanks in advance. > > Rafael > From dovid at telecurve.com Sun Jun 14 03:03:46 2015 From: dovid at telecurve.com (Dovid Bender) Date: Sun, 14 Jun 2015 03:03:46 +0000 Subject: Hardware monitoring Message-ID: <39599996-1434251026-cardhu_decombobulator_blackberry.rim.net-142354771-@b25.c3.bise6.blackberry> Anything on a linux box can have a bash script that snmpd can call. You can always wire up your own contraption and connect it to a Pi. ------Original Message------ From: Rafael Possamai Sender: NANOG To: nanog at nanog.org Subject: Hardware monitoring Sent: Jun 13, 2015 12:54 Hi everyone, I know this is slightly off-topic, but since it's still related to the list, I thought I'd give it a try. I am wondering what systems are out there (open source, preferably) for data collection and processing of hardware health data (temperature, CPU clock, fan speeds, etc). Ideally brand agnostic and location agnostic as well. I know of Cacti, but it would require SNMP enabled devices AFAIK, so room/generator/misc monitors wouldn't necessarily be included. Thanks in advance. Rafael Regards, Dovid From b-nanog at grmbl.net Sun Jun 14 08:22:35 2015 From: b-nanog at grmbl.net (b-nanog at grmbl.net) Date: Sun, 14 Jun 2015 10:22:35 +0200 Subject: Hardware monitoring In-Reply-To: References: Message-ID: <20150614082234.GA42890@mx.grmbl.net> librenms, a fork of observium, originally designed to do network monitoring but over the last years, expanded into servers/devices. http://www.librenms.org/ On Sat, Jun 13, 2015 at 11:54:51AM -0500, Rafael Possamai wrote: > Hi everyone, > > I know this is slightly off-topic, but since it's still related to the > list, I thought I'd give it a try. I am wondering what systems are out > there (open source, preferably) for data collection and processing of > hardware health data (temperature, CPU clock, fan speeds, etc). Ideally > brand agnostic and location agnostic as well. > > I know of Cacti, but it would require SNMP enabled devices AFAIK, so > room/generator/misc monitors wouldn't necessarily be included. > > > Thanks in advance. > > Rafael B From blakjak at blakjak.net Sun Jun 14 08:43:32 2015 From: blakjak at blakjak.net (Mark Foster) Date: Sun, 14 Jun 2015 20:43:32 +1200 Subject: Setting Up a Looking Glass In-Reply-To: References: <29124575.1241.1434212866266.JavaMail.mhammett@ThunderFuck> <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> Message-ID: <58ac0d5bfd7ce742056353375622c71e.squirrel@secure.blakjak.net> If only it wasn't on sourceforge? http://ow.ly/OhNcR (or the original link, http://www.howtogeek.com/218764/warning-don?t-download-software-from-sourceforge-if-you-can-help-it/) On Sun, June 14, 2015 2:40 pm, Hicks, Byron wrote: > http://sourceforge.net/projects/routerproxy/ > > Is my looking glass/router proxy of choice. > > >> On Jun 13, 2015, at 5:21 PM, Jim Popovitch wrote: >> >> On Sat, Jun 13, 2015 at 6:10 PM, Randy Bush wrote: >>>>> Here's a relatively new and fresh perspective on it: >>>>> https://github.com/ramnode/LookingGlass >>>>> You can see it in action here: >>>>> http://lg.nyc.ramnode.com/ >>>> looking glass without routing, indeed a new perspective :( >>> >>> with a bit more coffee, perhaps i can expand a bit. >>> >>> for widely distributed data plane probes (ping/traceroute/...), we have >>> good alternatives, nlring, ripe atlas, traceroute.org, etc. as an op, >>> nlring is my fave of the month as i can go from question to result in >>> minimal typing and a matter of seconds. >>> >>> 'looking glass' has traditionally meant a control plane (routing) view. >>> this is a rarer beast, and setting one up is often a bit crude. >> >> Indeed. As with most things there are always more than one meaning, >> and of course even those change with time. I read into the OP's >> words that he was looking for a locally hosted capability that he >> could easily give out to his people in order to trouble shoot >> connectivity. >> >> -Jim P. > > ??? > Byron Hicks > Lonestar Education and Research Network > 972-746-2549 > aim/skype: byronhicks > > > > > From niels=nanog at bakker.net Sun Jun 14 14:06:13 2015 From: niels=nanog at bakker.net (Niels Bakker) Date: Sun, 14 Jun 2015 16:06:13 +0200 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: References: <1434123151.30267.12.camel@galileo.millnert.se> <5.1.1.6.2.20150613215121.01f39398@efes.iucc.ac.il> Message-ID: <20150614140613.GA81337@excession.tpb.net> * rafael at gav.ufsc.br (Rafael Possamai) [Sun 14 Jun 2015, 04:54 CEST]: >A lot of these things are for show only.. Like a big corporation >donating to non-profits and sponsoring "feel good" events. Donating costs actual money, unlike putting a statement on a webpage >This was either an isolated incident or they really don't care much. Have you considered the third option? -- Niels. From list at satchell.net Sun Jun 14 14:33:09 2015 From: list at satchell.net (Stephen Satchell) Date: Sun, 14 Jun 2015 07:33:09 -0700 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: <20150614140613.GA81337@excession.tpb.net> References: <1434123151.30267.12.camel@galileo.millnert.se> <5.1.1.6.2.20150613215121.01f39398@efes.iucc.ac.il> <20150614140613.GA81337@excession.tpb.net> Message-ID: <557D90A5.3040709@satchell.net> On 06/14/2015 07:06 AM, Niels Bakker wrote: > * rafael at gav.ufsc.br (Rafael Possamai) [Sun 14 Jun 2015, 04:54 CEST]: >> This was either an isolated incident or they really don't care much. > > Have you considered the third option? Third option? From jared at puck.nether.net Sun Jun 14 14:37:45 2015 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 14 Jun 2015 10:37:45 -0400 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: <557D90A5.3040709@satchell.net> References: <1434123151.30267.12.camel@galileo.millnert.se> <5.1.1.6.2.20150613215121.01f39398@efes.iucc.ac.il> <20150614140613.GA81337@excession.tpb.net> <557D90A5.3040709@satchell.net> Message-ID: There are lots of options from failure to follow procedure to software defect amongst others. We are all human, except for my coworker the Troy-bot-3000. Even well intentioned and motivated people have bad things happen to them. What I look for in these incidents is what can be learned and improved upon. If you are motivated about the routing manifesto please join the mailing list. Thanks, Jared Mauch > On Jun 14, 2015, at 10:33 AM, Stephen Satchell wrote: > >> On 06/14/2015 07:06 AM, Niels Bakker wrote: >> * rafael at gav.ufsc.br (Rafael Possamai) [Sun 14 Jun 2015, 04:54 CEST]: >>> This was either an isolated incident or they really don't care much. >> >> Have you considered the third option? > > Third option? From emoore at sover.net Sun Jun 14 15:29:00 2015 From: emoore at sover.net (Evan Moore) Date: Sun, 14 Jun 2015 11:29:00 -0400 Subject: Open letter to Level3 concerning the global routing issues on June 12th In-Reply-To: References: <1434123151.30267.12.camel@galileo.millnert.se> <5.1.1.6.2.20150613215121.01f39398@efes.iucc.ac.il> <20150614140613.GA81337@excession.tpb.net> <557D90A5.3040709@satchell.net> Message-ID: <695C938D41839C4BA32590DDCF9AD21501F2E389B603@Exchange-01.office.sover.net> While this is all true, and I'm always willing to forgive honest errors accompanied by sincere admissions, my recent Level 3 experience (beginning prior to the 12th) has strongly biased me toward the third option Niels meant: serious lack of clue. I've had multiple tickets open over several weeks inquiring why Level 3 is announcing several /24s out of 8/8 to peers, and I keep getting told it's my fault. Supposedly my tickets have gone upstream to higher levels, but nothing changes and the answers I get are wrong. If anyone with clue at Level 3 would like to redeem my faith, please get in touch. ERM Evan R Moore Network Engineer and Bitwrangler Sovernet Communications emoore at sover.net -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jared Mauch Sent: Sunday, June 14, 2015 10:38 AM To: Stephen Satchell Cc: nanog at nanog.org Subject: Re: Open letter to Level3 concerning the global routing issues on June 12th There are lots of options from failure to follow procedure to software defect amongst others. We are all human, except for my coworker the Troy-bot-3000. Even well intentioned and motivated people have bad things happen to them. What I look for in these incidents is what can be learned and improved upon. If you are motivated about the routing manifesto please join the mailing list. Thanks, Jared Mauch > On Jun 14, 2015, at 10:33 AM, Stephen Satchell wrote: > >> On 06/14/2015 07:06 AM, Niels Bakker wrote: >> * rafael at gav.ufsc.br (Rafael Possamai) [Sun 14 Jun 2015, 04:54 CEST]: >>> This was either an isolated incident or they really don't care much. >> >> Have you considered the third option? > > Third option? From ryan.dirocco at totalserversolutions.com Sun Jun 14 15:43:59 2015 From: ryan.dirocco at totalserversolutions.com (Ryan DiRocco) Date: Sun, 14 Jun 2015 15:43:59 +0000 Subject: Hardware monitoring In-Reply-To: References: Message-ID: Just for getting your feet wet and doing so on a (tiny) budget..... If you want to monitor non-SNMP devices such as things like room temp probes, water leak detection, generator/ats/ups alarm outputs, etc . You could look into something like the APC AP9340 units These support APC's own temp/humidity probes, various user input, modbus rs-485 port, etc. They are very cheap (~$100) or so in ebay land and are quite easy to monitor via SNMP. User Guide: http://www.apcmedia.com/salestools/ASTE-6Z5QDH/ASTE-6Z5QDH_R1_EN.pdf -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rafael Possamai Sent: Saturday, June 13, 2015 12:55 PM To: nanog at nanog.org Subject: Hardware monitoring Hi everyone, I know this is slightly off-topic, but since it's still related to the list, I thought I'd give it a try. I am wondering what systems are out there (open source, preferably) for data collection and processing of hardware health data (temperature, CPU clock, fan speeds, etc). Ideally brand agnostic and location agnostic as well. I know of Cacti, but it would require SNMP enabled devices AFAIK, so room/generator/misc monitors wouldn't necessarily be included. Thanks in advance. Rafael From list at satchell.net Sun Jun 14 15:55:13 2015 From: list at satchell.net (Stephen Satchell) Date: Sun, 14 Jun 2015 08:55:13 -0700 Subject: Hardware monitoring In-Reply-To: References: Message-ID: <557DA3E1.4000406@satchell.net> Even cheaper, but a little more DYI, you can look into building a small Linux box, load MRTG (which you should be running anyway), and crafting small probe scripts that would feed the "traffic" grapher. For switch closures like on water-sensors, you will need an I/O board, but they are readily available and pretty easy to script. For temperature/voltage alarms, those same scripts can send alarm e-mail when particular values fall outside of the range. Ditto switch sensing. Also, there are SNMP-based solutions you may not have thought of. Have Cisco routers? The environmental sensors are available via SNMP. On 06/14/2015 08:43 AM, Ryan DiRocco wrote: > Just for getting your feet wet and doing so on a (tiny) budget..... If you want to monitor non-SNMP devices such as things like room temp probes, water leak detection, generator/ats/ups alarm outputs, etc . You could look into something like the APC AP9340 units > > These support APC's own temp/humidity probes, various user input, modbus rs-485 port, etc. > > They are very cheap (~$100) or so in ebay land and are quite easy to monitor via SNMP. > User Guide: http://www.apcmedia.com/salestools/ASTE-6Z5QDH/ASTE-6Z5QDH_R1_EN.pdf > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rafael Possamai > Sent: Saturday, June 13, 2015 12:55 PM > To: nanog at nanog.org > Subject: Hardware monitoring > > Hi everyone, > > I know this is slightly off-topic, but since it's still related to the list, I thought I'd give it a try. I am wondering what systems are out there (open source, preferably) for data collection and processing of hardware health data (temperature, CPU clock, fan speeds, etc). Ideally brand agnostic and location agnostic as well. > > I know of Cacti, but it would require SNMP enabled devices AFAIK, so room/generator/misc monitors wouldn't necessarily be included. > > > Thanks in advance. > > Rafael > From kareem.ali at centralnic.com Sun Jun 14 12:28:02 2015 From: kareem.ali at centralnic.com (Abdulkareem H. Ali) Date: Sun, 14 Jun 2015 13:28:02 +0100 Subject: NANOG Digest, Vol 89, Issue 15 In-Reply-To: References: Message-ID: <557D7352.3010703@centralnic.com> Hi, >Message: 15 >Date: Sun, 14 Jun 2015 01:09:44 +0530 >From: Anurag Bhatia >To: NANOG Mailing List >Subject: Re: Question about EX - SRX redundancy >Message-ID: > >Content-Type: text/plain; charset=UTF-8 > 3. In case of SRX only one device runs at a time and ports of other SRX > (slave) do not access traffic at all as long as it see the master is up via > heartbeat. This is true with regards to RETH interfaces, but any interface that is not part of a reth group on the slave SRX will function all the time. The SRX HA works with RE being up only on the master, while the PFE (which is what all interfaces use) is live on both systems all the time. In fact, you can make a reth group to have it's master interface on the slave SRX, depending on your redundancy group priorities. Also, I'd recommend assigning more than one interface for FAB links, providing your SRXes have the spares to use. Kareem. -- Abdulkareem H. Ali Network Operations Engineer CentralNic Group PLC London Stock Exchange Symbol: CNIC +44 20 3388 0600 www.CentralNic.com CentralNic Group PLC is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From jj at anexia.at Sun Jun 14 17:23:09 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Sun, 14 Jun 2015 17:23:09 +0000 Subject: Hardware monitoring In-Reply-To: <557DA3E1.4000406@satchell.net> References: , <557DA3E1.4000406@satchell.net> Message-ID: Hi, We're using PRTG from Paessler (http://www.paessler.com). We're monitoring > 50k sensors (storage, network, hardware, applications, a/c, generators, door locks, liquid detection system in datacentres, etc) ... Best decision ever! Best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Original Message----- From: Stephen Satchell [list at satchell.net] Received: Sonntag, 14 Juni 2015, 17:57 To: nanog at nanog.org [nanog at nanog.org] Subject: Re: Hardware monitoring Even cheaper, but a little more DYI, you can look into building a small Linux box, load MRTG (which you should be running anyway), and crafting small probe scripts that would feed the "traffic" grapher. For switch closures like on water-sensors, you will need an I/O board, but they are readily available and pretty easy to script. For temperature/voltage alarms, those same scripts can send alarm e-mail when particular values fall outside of the range. Ditto switch sensing. Also, there are SNMP-based solutions you may not have thought of. Have Cisco routers? The environmental sensors are available via SNMP. On 06/14/2015 08:43 AM, Ryan DiRocco wrote: > Just for getting your feet wet and doing so on a (tiny) budget..... If you want to monitor non-SNMP devices such as things like room temp probes, water leak detection, generator/ats/ups alarm outputs, etc . You could look into something like the APC AP9340 units > > These support APC's own temp/humidity probes, various user input, modbus rs-485 port, etc. > > They are very cheap (~$100) or so in ebay land and are quite easy to monitor via SNMP. > User Guide: http://www.apcmedia.com/salestools/ASTE-6Z5QDH/ASTE-6Z5QDH_R1_EN.pdf > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rafael Possamai > Sent: Saturday, June 13, 2015 12:55 PM > To: nanog at nanog.org > Subject: Hardware monitoring > > Hi everyone, > > I know this is slightly off-topic, but since it's still related to the list, I thought I'd give it a try. I am wondering what systems are out there (open source, preferably) for data collection and processing of hardware health data (temperature, CPU clock, fan speeds, etc). Ideally brand agnostic and location agnostic as well. > > I know of Cacti, but it would require SNMP enabled devices AFAIK, so room/generator/misc monitors wouldn't necessarily be included. > > > Thanks in advance. > > Rafael > From list at satchell.net Sun Jun 14 17:35:30 2015 From: list at satchell.net (Stephen Satchell) Date: Sun, 14 Jun 2015 10:35:30 -0700 Subject: Hardware monitoring In-Reply-To: References: , <557DA3E1.4000406@satchell.net> Message-ID: <557DBB62.9040900@satchell.net> On 06/14/2015 10:23 AM, J?rgen Jaritsch wrote: > We're using PRTG from Paessler (http://www.paessler.com). This is a product designed for use on Windows only, no mention of ports to other operating systems. For some people, this is fine. For others, who don't want to mess with Windows at all, it's a concern. Looking at some of the product sheets, it looks boss at what it does. In particular, the "David Letterman" view is an interesting quick snapshot look at what is going on. From jj at anexia.at Sun Jun 14 17:46:05 2015 From: jj at anexia.at (=?Windows-1252?Q?J=FCrgen_Jaritsch?=) Date: Sun, 14 Jun 2015 17:46:05 +0000 Subject: Hardware monitoring In-Reply-To: <557DBB62.9040900@satchell.net> References: , <557DA3E1.4000406@satchell.net> , <557DBB62.9040900@satchell.net> Message-ID: <7db8d08a13d345beb67ce7ed33a52595@anx-i-dag02.anx.local> > This is a product designed for use on Windows only, No. The monitoring itself requires windows as OS but only for the Mgmt service, DB service, etc. You do not need a client (like for Nagios/etc) to monitor other systems. You simply monitor devices via http (e.g. APIs, etc) or SNMP, etc. You can also integrate other coding languages (Perl, PHP, C++, etc) if you need something unsupported. J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Original Message----- From: Stephen Satchell [list at satchell.net] Received: Sonntag, 14 Juni 2015, 19:37 To: nanog at nanog.org [nanog at nanog.org] Subject: Re: Hardware monitoring On 06/14/2015 10:23 AM, J?rgen Jaritsch wrote: > We're using PRTG from Paessler (http://www.paessler.com). This is a product designed for use on Windows only, no mention of ports to other operating systems. For some people, this is fine. For others, who don't want to mess with Windows at all, it's a concern. Looking at some of the product sheets, it looks boss at what it does. In particular, the "David Letterman" view is an interesting quick snapshot look at what is going on. From list at satchell.net Sun Jun 14 18:01:47 2015 From: list at satchell.net (Stephen Satchell) Date: Sun, 14 Jun 2015 11:01:47 -0700 Subject: Hardware monitoring In-Reply-To: <7db8d08a13d345beb67ce7ed33a52595@anx-i-dag02.anx.local> References: , <557DA3E1.4000406@satchell.net> , <557DBB62.9040900@satchell.net> <7db8d08a13d345beb67ce7ed33a52595@anx-i-dag02.anx.local> Message-ID: <557DC18B.5030803@satchell.net> Appreciate the amplification. Cunningham's Law: "The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." On 06/14/2015 10:46 AM, J?rgen Jaritsch wrote: >> This is a product designed for use on Windows only, > > No. The monitoring itself requires windows as OS but only for the Mgmt service, DB service, etc. You do not need a client (like for Nagios/etc) to monitor other systems. You simply monitor devices via http (e.g. APIs, etc) or SNMP, etc. You can also integrate other coding languages (Perl, PHP, C++, etc) if you need something unsupported. > > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > > > -----Original Message----- > From: Stephen Satchell [list at satchell.net] > Received: Sonntag, 14 Juni 2015, 19:37 > To: nanog at nanog.org [nanog at nanog.org] > Subject: Re: Hardware monitoring > > On 06/14/2015 10:23 AM, J?rgen Jaritsch wrote: >> We're using PRTG from Paessler (http://www.paessler.com). > > This is a product designed for use on Windows only, no mention of ports > to other operating systems. For some people, this is fine. For others, > who don't want to mess with Windows at all, it's a concern. > > Looking at some of the product sheets, it looks boss at what it does. > In particular, the "David Letterman" view is an interesting quick > snapshot look at what is going on. > From jj at anexia.at Sun Jun 14 18:10:05 2015 From: jj at anexia.at (=?Windows-1252?Q?J=FCrgen_Jaritsch?=) Date: Sun, 14 Jun 2015 18:10:05 +0000 Subject: Hardware monitoring In-Reply-To: <557DC18B.5030803@satchell.net> References: , <557DA3E1.4000406@satchell.net> , <557DBB62.9040900@satchell.net> <7db8d08a13d345beb67ce7ed33a52595@anx-i-dag02.anx.local>, <557DC18B.5030803@satchell.net> Message-ID: No worries cause your answer wasn't totally wrong :) >From my POV PRTG is nearly a 100% solution and you do not need much more tools to get an good view of your running inventory. Beside PRTG we're only running some tools for flow analysis, NetApp storage analysis, etc. In sum we're running <5 tools to monitor EVERYTHING (hardware, software, datacentre infra, etc). J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Original Message----- From: Stephen Satchell [list at satchell.net] Received: Sonntag, 14 Juni 2015, 20:03 To: nanog at nanog.org [nanog at nanog.org] Subject: Re: Hardware monitoring Appreciate the amplification. Cunningham's Law: "The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." On 06/14/2015 10:46 AM, J?rgen Jaritsch wrote: >> This is a product designed for use on Windows only, > > No. The monitoring itself requires windows as OS but only for the Mgmt service, DB service, etc. You do not need a client (like for Nagios/etc) to monitor other systems. You simply monitor devices via http (e.g. APIs, etc) or SNMP, etc. You can also integrate other coding languages (Perl, PHP, C++, etc) if you need something unsupported. > > > J?rgen Jaritsch > Head of Network & Infrastructure > > ANEXIA Internetdienstleistungs GmbH > > Telefon: +43-5-0556-300 > Telefax: +43-5-0556-500 > > E-Mail: jj at anexia.at > Web: http://www.anexia.at > > Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt > Gesch?ftsf?hrer: Alexander Windbichler > Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 > > > -----Original Message----- > From: Stephen Satchell [list at satchell.net] > Received: Sonntag, 14 Juni 2015, 19:37 > To: nanog at nanog.org [nanog at nanog.org] > Subject: Re: Hardware monitoring > > On 06/14/2015 10:23 AM, J?rgen Jaritsch wrote: >> We're using PRTG from Paessler (http://www.paessler.com). > > This is a product designed for use on Windows only, no mention of ports > to other operating systems. For some people, this is fine. For others, > who don't want to mess with Windows at all, it's a concern. > > Looking at some of the product sheets, it looks boss at what it does. > In particular, the "David Letterman" view is an interesting quick > snapshot look at what is going on. > From job at instituut.net Sun Jun 14 18:27:46 2015 From: job at instituut.net (Job Snijders) Date: Sun, 14 Jun 2015 20:27:46 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> Message-ID: <20150614182746.GX94733@Vurt.local> On Fri, Jun 12, 2015 at 08:25:40PM +0000, J?rgen Jaritsch wrote: > This is the official [level3] feedback: > > [ ... ] For completeness sake: here is what Telekom Malaysia published about the issue: Telekom Malaysia Berhad (TM) wishes to update on the service related issue detected yesterday, 12 June 2015 affecting a number of our Internet services customers that caused a deterioration in connection performance. We identified the root cause and our network team immediately took steps to optimise traffic flows, while we worked to restore connectivity to its expected level of performance. The services were restored at 6.30pm on the same day. We would like to clarify that during a network reconfiguration exercise, we had unintentionally updated traffic routing information which caused congestion and packet loss to our international connectivity. This had affected the internet traffic flow for some of our customers and some international traffic routes. We apologise for any inconvenience caused by the service disruption and would like to assure customers that we are undertaking all the necessary measures to ensure customers continue to experience uninterrupted services. Meanwhile, customers who have any enquiry or require further assistance can email us at help at tm.com.my or tweet to us via @tmconnects on Twitter. source: https://www.tm.com.my/OnlineHelp/Announcement/Pages/INTERNET-SERVICES-DISRUPTION-12-June-2015.aspx Kind regards, Job From me at anuragbhatia.com Sun Jun 14 18:33:41 2015 From: me at anuragbhatia.com (Anurag Bhatia) Date: Mon, 15 Jun 2015 00:03:41 +0530 Subject: 2.4Ghz 40Mhz 802.11n wifi and Apple Macbook Message-ID: Hello everyone, I am running a TP Link TL-WR1043N which (as TP Link says is a) 802.11n router working on 2.4Ghz (no support for 5Ghz). I am running it with flashed OpenWRT. While using option to pick 40Mhz, I see my Mac only gets 20Mhz to use and speed is always 130Mbps. There's no other SSID nearby and I am sitting next to router for testing. This brings me to question - Has anyone successfully used 40Mhz with 2.4Ghz on 802.11n standard with Apple Macbook? I wonder if it's limitation on the chipset or something else. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From bruns at 2mbit.com Sun Jun 14 18:42:14 2015 From: bruns at 2mbit.com (Brielle Bruns) Date: Sun, 14 Jun 2015 12:42:14 -0600 Subject: 2.4Ghz 40Mhz 802.11n wifi and Apple Macbook In-Reply-To: References: Message-ID: <557DCB06.6040606@2mbit.com> On 6/14/15 12:33 PM, Anurag Bhatia wrote: > Hello everyone, > > > > I am running a TP Link TL-WR1043N which (as TP Link says is a) 802.11n > router working on 2.4Ghz (no support for 5Ghz). I am running it with > flashed OpenWRT. > > > > While using option to pick 40Mhz, I see my Mac only gets 20Mhz to use and > speed is always 130Mbps. There's no other SSID nearby and I am sitting next > to router for testing. > > > This brings me to question - Has anyone successfully used 40Mhz with 2.4Ghz > on 802.11n standard with Apple Macbook? I wonder if it's limitation on the > chipset or something else. > > > Everything that I've seen/experienced says that Apple devices won't use 40mhz channels with 2.4 due to the overlapping bands/lack of good separation between channels. However, I'm not sure if this specifically applies to just the Airport APs like the Extreme, or to the laptops as well, as I use AE's at home, and the Unifi APs I do have in service all have 20mhz channels only set on them to avoid issues. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From me at anuragbhatia.com Sun Jun 14 20:37:53 2015 From: me at anuragbhatia.com (Anurag Bhatia) Date: Mon, 15 Jun 2015 02:07:53 +0530 Subject: Question about EX - SRX redundancy In-Reply-To: <33C0B3C9-AB2D-4AB1-AA94-010E97FA432F@gmail.com> References: <75EA7CE7-FB8D-49BE-8F6B-0CC706AAEAA8@gmail.com> <20150402155105.GF9851@bamboo.slabnet.com> <20150402185507.GG9851@bamboo.slabnet.com> <20150402222234.GH9851@bamboo.slabnet.com> <33C0B3C9-AB2D-4AB1-AA94-010E97FA432F@gmail.com> Message-ID: Hi Rob I couldn't get the ports working on SRX with low priority on the cluster. They always showed as down by protocol and never picked traffic. Can you put some light on the reason for that? Thanks On Sun, Jun 14, 2015 at 3:42 AM, Rob Greenwood wrote: > > 3. In case of SRX only one device runs at a time and ports of other SRX > > (slave) do not access traffic at all as long as it see the master is > up via > > heartbeat. > Not entirely accurate. The control plane (routing engine) is only active > on one SRX at a time, however, the data plane is active on both. This means > in your configuration, both ae1 and ae2 on the EX will be passing traffic > to both SRXs. > > It?s also worth noting you can create multiple redundancy groups and split > them between both SRXs. If a device fails, all redundancy groups on the > failed device will be migrated to the remaining one. > > -Rob > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From raymond at prolocation.net Sun Jun 14 20:55:10 2015 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Sun, 14 Jun 2015 22:55:10 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <20150614182746.GX94733@Vurt.local> References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> Message-ID: Hai! Wouw! This is what they came up with?! Hopefully Level3 will take appropriate measures. Its amazing. Really. 'Some internationally routes' Have they any idea what they did at all? Its amazing that with parties like that the internet still works as is ... Thanks, Raymond Dijkxhoorn > Op 14 jun. 2015 om 20:27 heeft Job Snijders het volgende geschreven: > >> On Fri, Jun 12, 2015 at 08:25:40PM +0000, J?rgen Jaritsch wrote: >> This is the official [level3] feedback: >> >> [ ... ] > > For completeness sake: here is what Telekom Malaysia published about the > issue: > > Telekom Malaysia Berhad (TM) wishes to update on the service related > issue detected yesterday, 12 June 2015 affecting a number of our > Internet services customers that caused a deterioration in > connection performance. > > We identified the root cause and our network team immediately took > steps to optimise traffic flows, while we worked to restore > connectivity to its expected level of performance. The services were > restored at 6.30pm on the same day. > > We would like to clarify that during a network reconfiguration > exercise, we had unintentionally updated traffic routing information > which caused congestion and packet loss to our international > connectivity. This had affected the internet traffic flow for some > of our customers and some international traffic routes. > > We apologise for any inconvenience caused by the service disruption > and would like to assure customers that we are undertaking all the > necessary measures to ensure customers continue to experience > uninterrupted services. > > Meanwhile, customers who have any enquiry or require further > assistance can email us at help at tm.com.my or tweet to us via > @tmconnects on Twitter. > > source: https://www.tm.com.my/OnlineHelp/Announcement/Pages/INTERNET-SERVICES-DISRUPTION-12-June-2015.aspx > > Kind regards, > > Job From mark.tinka at seacom.mu Sun Jun 14 21:04:23 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 14 Jun 2015 23:04:23 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> Message-ID: <557DEC57.7020808@seacom.mu> On 14/Jun/15 22:55, Raymond Dijkxhoorn wrote: > Hai! > > Wouw! This is what they came up with?! > > Hopefully Level3 will take appropriate measures. Its amazing. Really. > > 'Some internationally routes' > > Have they any idea what they did at all? > > Its amazing that with parties like that the internet still works as is ... I wouldn't be as hard. Stuff happens - and as they said, during a maintenance activity, they boo-boo'ed. Are Level(3) going to own up and say they should have had filters in place? I certainly hope they do. But more importantly, are Level(3) going to implement the filters against TM's circuit? Are they going to run around the network looking for any additional customer circuits that need plugging? That's my concern... Mark. From jj at anexia.at Sun Jun 14 21:14:20 2015 From: jj at anexia.at (=?utf-8?B?SsO8cmdlbiBKYXJpdHNjaA==?=) Date: Sun, 14 Jun 2015 21:14:20 +0000 Subject: AS4788 Telecom Malaysia major route leak? Message-ID: <357d281c2ffb4f9f904a7f2c39f08d54@anx-i-dag02.anx.local> They should verify the GBLX customer ports as well ... J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 From raymond at prolocation.net Sun Jun 14 21:20:59 2015 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Sun, 14 Jun 2015 23:20:59 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <557DEC57.7020808@seacom.mu> References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> Message-ID: <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> Hai! Mark, mistakes and oopses happen. No problem at all. I understand that completely. There is human faillure and this happenes. A simple 'sorry' would have done. Yet their whole message tells 'they did ok' In my very limited view they did NOT ok. Did i misread? I am also very much looking how level3 is going to prevent things like this. But out of own experience they will not. We have seen before that they implemented filtering based on customer lists. But not a per customer filter. They did this globally. So any l3 customer can announce routes of another l3 customer. While this can be changed this outage tells there is certainly room for improvements. I hope people will learn from what happened and implement proper filtering. Thats even more important then a message from a operator that didnt even understand fully what they caused to the internet globally. Thanks, Raymond Dijkxhoorn > Op 14 jun. 2015 om 23:04 heeft Mark Tinka het volgende geschreven: > > > >> On 14/Jun/15 22:55, Raymond Dijkxhoorn wrote: >> Hai! >> >> Wouw! This is what they came up with?! >> >> Hopefully Level3 will take appropriate measures. Its amazing. Really. >> >> 'Some internationally routes' >> >> Have they any idea what they did at all? >> >> Its amazing that with parties like that the internet still works as is ... > > I wouldn't be as hard. Stuff happens - and as they said, during a > maintenance activity, they boo-boo'ed. > > Are Level(3) going to own up and say they should have had filters in > place? I certainly hope they do. > > But more importantly, are Level(3) going to implement the filters > against TM's circuit? Are they going to run around the network looking > for any additional customer circuits that need plugging? That's my > concern... > > Mark. From mel at beckman.org Sun Jun 14 21:27:35 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 14 Jun 2015 21:27:35 +0000 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu>, <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> Message-ID: Raymond, They provided a "simple sorry": "We apologise for any inconvenience caused by the service disruption." It doesn't get much more simple than that. -mel beckman > On Jun 14, 2015, at 2:21 PM, Raymond Dijkxhoorn wrote: > > Hai! > > Mark, mistakes and oopses happen. No problem at all. I understand that completely. There is human faillure and this happenes. > > A simple 'sorry' would have done. Yet their whole message tells 'they did ok' In my very limited view they did NOT ok. Did i misread? > > I am also very much looking how level3 is going to prevent things like this. But out of own experience they will not. We have seen before that they implemented filtering based on customer lists. But not a per customer filter. They did this globally. So any l3 customer can announce routes of another l3 customer. While this can be changed this outage tells there is certainly room for improvements. > > I hope people will learn from what happened and implement proper filtering. Thats even more important then a message from a operator that didnt even understand fully what they caused to the internet globally. > > Thanks, > Raymond Dijkxhoorn > >> Op 14 jun. 2015 om 23:04 heeft Mark Tinka het volgende geschreven: >> >> >> >>> On 14/Jun/15 22:55, Raymond Dijkxhoorn wrote: >>> Hai! >>> >>> Wouw! This is what they came up with?! >>> >>> Hopefully Level3 will take appropriate measures. Its amazing. Really. >>> >>> 'Some internationally routes' >>> >>> Have they any idea what they did at all? >>> >>> Its amazing that with parties like that the internet still works as is ... >> >> I wouldn't be as hard. Stuff happens - and as they said, during a >> maintenance activity, they boo-boo'ed. >> >> Are Level(3) going to own up and say they should have had filters in >> place? I certainly hope they do. >> >> But more importantly, are Level(3) going to implement the filters >> against TM's circuit? Are they going to run around the network looking >> for any additional customer circuits that need plugging? That's my >> concern... >> >> Mark. From raymond at prolocation.net Sun Jun 14 21:32:42 2015 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Sun, 14 Jun 2015 23:32:42 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> Message-ID: Hello Mel, Must just be me then. I was most likely expecting a more in depth report. Strange things happened. Perhaps they could post a 'what exactly happened' since this wasnt a average route leak. Thanks, Raymond Dijkxhoorn > Op 14 jun. 2015 om 23:27 heeft Mel Beckman het volgende geschreven: > > Raymond, > > They provided a "simple sorry": > > "We apologise for any inconvenience caused by the service disruption." > > It doesn't get much more simple than that. > > -mel beckman > >> On Jun 14, 2015, at 2:21 PM, Raymond Dijkxhoorn wrote: >> >> Hai! >> >> Mark, mistakes and oopses happen. No problem at all. I understand that completely. There is human faillure and this happenes. >> >> A simple 'sorry' would have done. Yet their whole message tells 'they did ok' In my very limited view they did NOT ok. Did i misread? >> >> I am also very much looking how level3 is going to prevent things like this. But out of own experience they will not. We have seen before that they implemented filtering based on customer lists. But not a per customer filter. They did this globally. So any l3 customer can announce routes of another l3 customer. While this can be changed this outage tells there is certainly room for improvements. >> >> I hope people will learn from what happened and implement proper filtering. Thats even more important then a message from a operator that didnt even understand fully what they caused to the internet globally. >> >> Thanks, >> Raymond Dijkxhoorn >> >>> Op 14 jun. 2015 om 23:04 heeft Mark Tinka het volgende geschreven: >>> >>> >>> >>>> On 14/Jun/15 22:55, Raymond Dijkxhoorn wrote: >>>> Hai! >>>> >>>> Wouw! This is what they came up with?! >>>> >>>> Hopefully Level3 will take appropriate measures. Its amazing. Really. >>>> >>>> 'Some internationally routes' >>>> >>>> Have they any idea what they did at all? >>>> >>>> Its amazing that with parties like that the internet still works as is ... >>> >>> I wouldn't be as hard. Stuff happens - and as they said, during a >>> maintenance activity, they boo-boo'ed. >>> >>> Are Level(3) going to own up and say they should have had filters in >>> place? I certainly hope they do. >>> >>> But more importantly, are Level(3) going to implement the filters >>> against TM's circuit? Are they going to run around the network looking >>> for any additional customer circuits that need plugging? That's my >>> concern... >>> >>> Mark. From mel at beckman.org Sun Jun 14 22:56:06 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 14 Jun 2015 22:56:06 +0000 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> , Message-ID: Raymond, But you said "A simple 'sorry' would have done." Now you're asking for lots more detail. Why the change? -mel beckman > On Jun 14, 2015, at 2:32 PM, Raymond Dijkxhoorn wrote: > > Hello Mel, > > Must just be me then. > > I was most likely expecting a more in depth report. Strange things happened. Perhaps they could post a 'what exactly happened' since this wasnt a average route leak. > > Thanks, > Raymond Dijkxhoorn > >> Op 14 jun. 2015 om 23:27 heeft Mel Beckman het volgende geschreven: >> >> Raymond, >> >> They provided a "simple sorry": >> >> "We apologise for any inconvenience caused by the service disruption." >> >> It doesn't get much more simple than that. >> >> -mel beckman >> >>> On Jun 14, 2015, at 2:21 PM, Raymond Dijkxhoorn wrote: >>> >>> Hai! >>> >>> Mark, mistakes and oopses happen. No problem at all. I understand that completely. There is human faillure and this happenes. >>> >>> A simple 'sorry' would have done. Yet their whole message tells 'they did ok' In my very limited view they did NOT ok. Did i misread? >>> >>> I am also very much looking how level3 is going to prevent things like this. But out of own experience they will not. We have seen before that they implemented filtering based on customer lists. But not a per customer filter. They did this globally. So any l3 customer can announce routes of another l3 customer. While this can be changed this outage tells there is certainly room for improvements. >>> >>> I hope people will learn from what happened and implement proper filtering. Thats even more important then a message from a operator that didnt even understand fully what they caused to the internet globally. >>> >>> Thanks, >>> Raymond Dijkxhoorn >>> >>>> Op 14 jun. 2015 om 23:04 heeft Mark Tinka het volgende geschreven: >>>> >>>> >>>> >>>>> On 14/Jun/15 22:55, Raymond Dijkxhoorn wrote: >>>>> Hai! >>>>> >>>>> Wouw! This is what they came up with?! >>>>> >>>>> Hopefully Level3 will take appropriate measures. Its amazing. Really. >>>>> >>>>> 'Some internationally routes' >>>>> >>>>> Have they any idea what they did at all? >>>>> >>>>> Its amazing that with parties like that the internet still works as is ... >>>> >>>> I wouldn't be as hard. Stuff happens - and as they said, during a >>>> maintenance activity, they boo-boo'ed. >>>> >>>> Are Level(3) going to own up and say they should have had filters in >>>> place? I certainly hope they do. >>>> >>>> But more importantly, are Level(3) going to implement the filters >>>> against TM's circuit? Are they going to run around the network looking >>>> for any additional customer circuits that need plugging? That's my >>>> concern... >>>> >>>> Mark. From mel at beckman.org Mon Jun 15 00:07:17 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 15 Jun 2015 00:07:17 +0000 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> , Message-ID: <0E7CF624-AC04-4973-99BF-F41E8BB3B002@beckman.org> SLAs are part of a contract, and thus only apply to the parties of the contract. There are no payments due to other parties. The Internet is a "best effort" network, with zero guarantees. -mel beckman On Jun 14, 2015, at 4:06 PM, Rafael Possamai > wrote: Does anyone know if there's an official "ruling" as to who gets to pay for the SLA breaches? On Sun, Jun 14, 2015 at 5:56 PM, Mel Beckman > wrote: Raymond, But you said "A simple 'sorry' would have done." Now you're asking for lots more detail. Why the change? -mel beckman > On Jun 14, 2015, at 2:32 PM, Raymond Dijkxhoorn > wrote: > > Hello Mel, > > Must just be me then. > > I was most likely expecting a more in depth report. Strange things happened. Perhaps they could post a 'what exactly happened' since this wasnt a average route leak. > > Thanks, > Raymond Dijkxhoorn > >> Op 14 jun. 2015 om 23:27 heeft Mel Beckman > het volgende geschreven: >> >> Raymond, >> >> They provided a "simple sorry": >> >> "We apologise for any inconvenience caused by the service disruption." >> >> It doesn't get much more simple than that. >> >> -mel beckman >> >>> On Jun 14, 2015, at 2:21 PM, Raymond Dijkxhoorn > wrote: >>> >>> Hai! >>> >>> Mark, mistakes and oopses happen. No problem at all. I understand that completely. There is human faillure and this happenes. >>> >>> A simple 'sorry' would have done. Yet their whole message tells 'they did ok' In my very limited view they did NOT ok. Did i misread? >>> >>> I am also very much looking how level3 is going to prevent things like this. But out of own experience they will not. We have seen before that they implemented filtering based on customer lists. But not a per customer filter. They did this globally. So any l3 customer can announce routes of another l3 customer. While this can be changed this outage tells there is certainly room for improvements. >>> >>> I hope people will learn from what happened and implement proper filtering. Thats even more important then a message from a operator that didnt even understand fully what they caused to the internet globally. >>> >>> Thanks, >>> Raymond Dijkxhoorn >>> >>>> Op 14 jun. 2015 om 23:04 heeft Mark Tinka > het volgende geschreven: >>>> >>>> >>>> >>>>> On 14/Jun/15 22:55, Raymond Dijkxhoorn wrote: >>>>> Hai! >>>>> >>>>> Wouw! This is what they came up with?! >>>>> >>>>> Hopefully Level3 will take appropriate measures. Its amazing. Really. >>>>> >>>>> 'Some internationally routes' >>>>> >>>>> Have they any idea what they did at all? >>>>> >>>>> Its amazing that with parties like that the internet still works as is ... >>>> >>>> I wouldn't be as hard. Stuff happens - and as they said, during a >>>> maintenance activity, they boo-boo'ed. >>>> >>>> Are Level(3) going to own up and say they should have had filters in >>>> place? I certainly hope they do. >>>> >>>> But more importantly, are Level(3) going to implement the filters >>>> against TM's circuit? Are they going to run around the network looking >>>> for any additional customer circuits that need plugging? That's my >>>> concern... >>>> >>>> Mark. From rubensk at gmail.com Mon Jun 15 00:13:36 2015 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 14 Jun 2015 21:13:36 -0300 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <0E7CF624-AC04-4973-99BF-F41E8BB3B002@beckman.org> References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> <0E7CF624-AC04-4973-99BF-F41E8BB3B002@beckman.org> Message-ID: On Sun, Jun 14, 2015 at 9:07 PM, Mel Beckman wrote: > SLAs are part of a contract, and thus only apply to the parties of the > contract. There are no payments due to other parties. The Internet is a > "best effort" network, with zero guarantees. > > -mel beckman > Ok, I'll bite: my $dayjob is a Level 3 client that was directly affected by lack of availability due to recovery attempt Level 3 tried in our region. Where $dayjob can collect $ for this incident ? Rubens From ryan.landry at gmail.com Mon Jun 15 00:14:43 2015 From: ryan.landry at gmail.com (ryanL) Date: Mon, 15 Jun 2015 00:14:43 +0000 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <0E7CF624-AC04-4973-99BF-F41E8BB3B002@beckman.org> References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> <0E7CF624-AC04-4973-99BF-F41E8BB3B002@beckman.org> Message-ID: keep in mind their target audience with that message is probably local malaysian customers, not the world. On Sun, Jun 14, 2015 at 5:09 PM Mel Beckman wrote: > SLAs are part of a contract, and thus only apply to the parties of the > contract. There are no payments due to other parties. The Internet is a > "best effort" network, with zero guarantees. > > -mel beckman > > On Jun 14, 2015, at 4:06 PM, Rafael Possamai rafael at gav.ufsc.br>> wrote: > > Does anyone know if there's an official "ruling" as to who gets to pay for > the SLA breaches? > > On Sun, Jun 14, 2015 at 5:56 PM, Mel Beckman mel at beckman.org>> wrote: > Raymond, > > But you said "A simple 'sorry' would have done." Now you're asking for > lots more detail. Why the change? > > -mel beckman > > > On Jun 14, 2015, at 2:32 PM, Raymond Dijkxhoorn > wrote: > > > > Hello Mel, > > > > Must just be me then. > > > > I was most likely expecting a more in depth report. Strange things > happened. Perhaps they could post a 'what exactly happened' since this > wasnt a average route leak. > > > > Thanks, > > Raymond Dijkxhoorn > > > >> Op 14 jun. 2015 om 23:27 heeft Mel Beckman mel at beckman.org>> het volgende geschreven: > >> > >> Raymond, > >> > >> They provided a "simple sorry": > >> > >> "We apologise for any inconvenience caused by the service disruption." > >> > >> It doesn't get much more simple than that. > >> > >> -mel beckman > >> > >>> On Jun 14, 2015, at 2:21 PM, Raymond Dijkxhoorn < > raymond at prolocation.net> wrote: > >>> > >>> Hai! > >>> > >>> Mark, mistakes and oopses happen. No problem at all. I understand that > completely. There is human faillure and this happenes. > >>> > >>> A simple 'sorry' would have done. Yet their whole message tells 'they > did ok' In my very limited view they did NOT ok. Did i misread? > >>> > >>> I am also very much looking how level3 is going to prevent things like > this. But out of own experience they will not. We have seen before that > they implemented filtering based on customer lists. But not a per customer > filter. They did this globally. So any l3 customer can announce routes of > another l3 customer. While this can be changed this outage tells there is > certainly room for improvements. > >>> > >>> I hope people will learn from what happened and implement proper > filtering. Thats even more important then a message from a operator that > didnt even understand fully what they caused to the internet globally. > >>> > >>> Thanks, > >>> Raymond Dijkxhoorn > >>> > >>>> Op 14 jun. 2015 om 23:04 heeft Mark Tinka > het volgende geschreven: > >>>> > >>>> > >>>> > >>>>> On 14/Jun/15 22:55, Raymond Dijkxhoorn wrote: > >>>>> Hai! > >>>>> > >>>>> Wouw! This is what they came up with?! > >>>>> > >>>>> Hopefully Level3 will take appropriate measures. Its amazing. Really. > >>>>> > >>>>> 'Some internationally routes' > >>>>> > >>>>> Have they any idea what they did at all? > >>>>> > >>>>> Its amazing that with parties like that the internet still works as > is ... > >>>> > >>>> I wouldn't be as hard. Stuff happens - and as they said, during a > >>>> maintenance activity, they boo-boo'ed. > >>>> > >>>> Are Level(3) going to own up and say they should have had filters in > >>>> place? I certainly hope they do. > >>>> > >>>> But more importantly, are Level(3) going to implement the filters > >>>> against TM's circuit? Are they going to run around the network looking > >>>> for any additional customer circuits that need plugging? That's my > >>>> concern... > >>>> > >>>> Mark. > > From b-nanog at grmbl.net Mon Jun 15 00:26:25 2015 From: b-nanog at grmbl.net (B) Date: Mon, 15 Jun 2015 02:26:25 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> <0E7CF624-AC04-4973-99BF-F41E8BB3B002@beckman.org> Message-ID: <20150615002625.GB34405@mx.grmbl.net> In addition to that, losing face in SE Asia is "not done". On Mon, Jun 15, 2015 at 12:14:43AM +0000, ryanL wrote: > keep in mind their target audience with that message is probably local > malaysian customers, not the world. > > On Sun, Jun 14, 2015 at 5:09 PM Mel Beckman wrote: > > > SLAs are part of a contract, and thus only apply to the parties of the > > contract. There are no payments due to other parties. The Internet is a > > "best effort" network, with zero guarantees. > > > > -mel beckman > > > > On Jun 14, 2015, at 4:06 PM, Rafael Possamai > rafael at gav.ufsc.br>> wrote: > > > > Does anyone know if there's an official "ruling" as to who gets to pay for > > the SLA breaches? > > > > On Sun, Jun 14, 2015 at 5:56 PM, Mel Beckman > mel at beckman.org>> wrote: > > Raymond, > > > > But you said "A simple 'sorry' would have done." Now you're asking for > > lots more detail. Why the change? > > > > -mel beckman From jra at baylink.com Mon Jun 15 00:36:53 2015 From: jra at baylink.com (Jay Ashworth) Date: Sun, 14 Jun 2015 20:36:53 -0400 (EDT) Subject: Hardware monitoring In-Reply-To: Message-ID: <19782501.86.1434328613772.JavaMail.root@benjamin.baylink.com> > I know this is slightly off-topic, but since it's still related to the > list, I thought I'd give it a try. I am wondering what systems are out > there (open source, preferably) for data collection and processing of > hardware health data (temperature, CPU clock, fan speeds, etc). > Ideally brand agnostic and location agnostic as well. > > I know of Cacti, but it would require SNMP enabled devices AFAIK, so > room/generator/misc monitors wouldn't necessarily be included. You're going to find that the most commonly recommended solution, I think, will be proxy SNMP, and let your SNMP monitor log it; there are *lots* of reasons not to want to run two infrastructures for that. 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 rafael at gav.ufsc.br Sun Jun 14 23:06:22 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sun, 14 Jun 2015 18:06:22 -0500 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> Message-ID: Does anyone know if there's an official "ruling" as to who gets to pay for the SLA breaches? On Sun, Jun 14, 2015 at 5:56 PM, Mel Beckman wrote: > Raymond, > > But you said "A simple 'sorry' would have done." Now you're asking for > lots more detail. Why the change? > > -mel beckman > > > On Jun 14, 2015, at 2:32 PM, Raymond Dijkxhoorn > wrote: > > > > Hello Mel, > > > > Must just be me then. > > > > I was most likely expecting a more in depth report. Strange things > happened. Perhaps they could post a 'what exactly happened' since this > wasnt a average route leak. > > > > Thanks, > > Raymond Dijkxhoorn > > > >> Op 14 jun. 2015 om 23:27 heeft Mel Beckman het > volgende geschreven: > >> > >> Raymond, > >> > >> They provided a "simple sorry": > >> > >> "We apologise for any inconvenience caused by the service disruption." > >> > >> It doesn't get much more simple than that. > >> > >> -mel beckman > >> > >>> On Jun 14, 2015, at 2:21 PM, Raymond Dijkxhoorn < > raymond at prolocation.net> wrote: > >>> > >>> Hai! > >>> > >>> Mark, mistakes and oopses happen. No problem at all. I understand that > completely. There is human faillure and this happenes. > >>> > >>> A simple 'sorry' would have done. Yet their whole message tells 'they > did ok' In my very limited view they did NOT ok. Did i misread? > >>> > >>> I am also very much looking how level3 is going to prevent things like > this. But out of own experience they will not. We have seen before that > they implemented filtering based on customer lists. But not a per customer > filter. They did this globally. So any l3 customer can announce routes of > another l3 customer. While this can be changed this outage tells there is > certainly room for improvements. > >>> > >>> I hope people will learn from what happened and implement proper > filtering. Thats even more important then a message from a operator that > didnt even understand fully what they caused to the internet globally. > >>> > >>> Thanks, > >>> Raymond Dijkxhoorn > >>> > >>>> Op 14 jun. 2015 om 23:04 heeft Mark Tinka het > volgende geschreven: > >>>> > >>>> > >>>> > >>>>> On 14/Jun/15 22:55, Raymond Dijkxhoorn wrote: > >>>>> Hai! > >>>>> > >>>>> Wouw! This is what they came up with?! > >>>>> > >>>>> Hopefully Level3 will take appropriate measures. Its amazing. Really. > >>>>> > >>>>> 'Some internationally routes' > >>>>> > >>>>> Have they any idea what they did at all? > >>>>> > >>>>> Its amazing that with parties like that the internet still works as > is ... > >>>> > >>>> I wouldn't be as hard. Stuff happens - and as they said, during a > >>>> maintenance activity, they boo-boo'ed. > >>>> > >>>> Are Level(3) going to own up and say they should have had filters in > >>>> place? I certainly hope they do. > >>>> > >>>> But more importantly, are Level(3) going to implement the filters > >>>> against TM's circuit? Are they going to run around the network looking > >>>> for any additional customer circuits that need plugging? That's my > >>>> concern... > >>>> > >>>> Mark. > From rafael at gav.ufsc.br Mon Jun 15 00:24:29 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sun, 14 Jun 2015 19:24:29 -0500 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: <0E7CF624-AC04-4973-99BF-F41E8BB3B002@beckman.org> References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> <0E7CF624-AC04-4973-99BF-F41E8BB3B002@beckman.org> Message-ID: I get that much, just wondering if Level3 would have to pay an SLA breach to its customers given the mess started with TM (even though it could have been avoided). And I am guessing if they do, they wouldn't be able to recover anything from TM. On Sun, Jun 14, 2015 at 7:07 PM, Mel Beckman wrote: > SLAs are part of a contract, and thus only apply to the parties of the > contract. There are no payments due to other parties. The Internet is a > "best effort" network, with zero guarantees. > > -mel beckman > > On Jun 14, 2015, at 4:06 PM, Rafael Possamai wrote: > > Does anyone know if there's an official "ruling" as to who gets to pay > for the SLA breaches? > > On Sun, Jun 14, 2015 at 5:56 PM, Mel Beckman wrote: > >> Raymond, >> >> But you said "A simple 'sorry' would have done." Now you're asking for >> lots more detail. Why the change? >> >> -mel beckman >> >> > On Jun 14, 2015, at 2:32 PM, Raymond Dijkxhoorn < >> raymond at prolocation.net> wrote: >> > >> > Hello Mel, >> > >> > Must just be me then. >> > >> > I was most likely expecting a more in depth report. Strange things >> happened. Perhaps they could post a 'what exactly happened' since this >> wasnt a average route leak. >> > >> > Thanks, >> > Raymond Dijkxhoorn >> > >> >> Op 14 jun. 2015 om 23:27 heeft Mel Beckman het >> volgende geschreven: >> >> >> >> Raymond, >> >> >> >> They provided a "simple sorry": >> >> >> >> "We apologise for any inconvenience caused by the service >> disruption." >> >> >> >> It doesn't get much more simple than that. >> >> >> >> -mel beckman >> >> >> >>> On Jun 14, 2015, at 2:21 PM, Raymond Dijkxhoorn < >> raymond at prolocation.net> wrote: >> >>> >> >>> Hai! >> >>> >> >>> Mark, mistakes and oopses happen. No problem at all. I understand >> that completely. There is human faillure and this happenes. >> >>> >> >>> A simple 'sorry' would have done. Yet their whole message tells 'they >> did ok' In my very limited view they did NOT ok. Did i misread? >> >>> >> >>> I am also very much looking how level3 is going to prevent things >> like this. But out of own experience they will not. We have seen before >> that they implemented filtering based on customer lists. But not a per >> customer filter. They did this globally. So any l3 customer can announce >> routes of another l3 customer. While this can be changed this outage tells >> there is certainly room for improvements. >> >>> >> >>> I hope people will learn from what happened and implement proper >> filtering. Thats even more important then a message from a operator that >> didnt even understand fully what they caused to the internet globally. >> >>> >> >>> Thanks, >> >>> Raymond Dijkxhoorn >> >>> >> >>>> Op 14 jun. 2015 om 23:04 heeft Mark Tinka >> het volgende geschreven: >> >>>> >> >>>> >> >>>> >> >>>>> On 14/Jun/15 22:55, Raymond Dijkxhoorn wrote: >> >>>>> Hai! >> >>>>> >> >>>>> Wouw! This is what they came up with?! >> >>>>> >> >>>>> Hopefully Level3 will take appropriate measures. Its amazing. >> Really. >> >>>>> >> >>>>> 'Some internationally routes' >> >>>>> >> >>>>> Have they any idea what they did at all? >> >>>>> >> >>>>> Its amazing that with parties like that the internet still works as >> is ... >> >>>> >> >>>> I wouldn't be as hard. Stuff happens - and as they said, during a >> >>>> maintenance activity, they boo-boo'ed. >> >>>> >> >>>> Are Level(3) going to own up and say they should have had filters in >> >>>> place? I certainly hope they do. >> >>>> >> >>>> But more importantly, are Level(3) going to implement the filters >> >>>> against TM's circuit? Are they going to run around the network >> looking >> >>>> for any additional customer circuits that need plugging? That's my >> >>>> concern... >> >>>> >> >>>> Mark. >> > > From randy at psg.com Mon Jun 15 01:01:44 2015 From: randy at psg.com (Randy Bush) Date: Mon, 15 Jun 2015 10:01:44 +0900 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> <0E7CF624-AC04-4973-99BF-F41E8BB3B002@beckman.org> Message-ID: what i have yet to understand (probably my fault) is how L(3) propagated the disease or, more correctly, what has happened over there that they did not stop the propagation? the crew that went there from mci ran a very tight ship and L(3) has always had pretty rigid filters. what happened? and i mean that in the sense of how can i not make a similar mistake? randy From aftab.siddiqui at gmail.com Mon Jun 15 01:07:53 2015 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Mon, 15 Jun 2015 01:07:53 +0000 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> <0E7CF624-AC04-4973-99BF-F41E8BB3B002@beckman.org> Message-ID: Hi Rafael, I get that much, just wondering if Level3 would have to pay an SLA breach > to its customers given the mess started with TM (even though it could have > been avoided). And I am guessing if they do, they wouldn't be able to > recover anything from TM. I doubt if L3 has to pay anything to its customers in terms of SLA breach, its best effort. Are you aware of any such agreement which suggest otherwise? that would be interesting. From rafael at gav.ufsc.br Mon Jun 15 01:20:23 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sun, 14 Jun 2015 20:20:23 -0500 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> <0E7CF624-AC04-4973-99BF-F41E8BB3B002@beckman.org> Message-ID: Well, I was wondering the same. I am guessing it depends on the SLA contract since they are all very unique and specific. I assume they would have to, granted the issue lasted for a couple hours. Now, it depends on how they define the outage. A fiber cut that yields a customer's service unusable would be an easy SLA breach. Their legal team most likely removed any liability due to someone else's negligence, although you could argue they were negligent as well. So in this case they can claim the whole "best effort" thing and get away with it. I am not a L3 customer, so was just wondering out of curiosity. On Sun, Jun 14, 2015 at 8:07 PM, Aftab Siddiqui wrote: > Hi Rafael, > > I get that much, just wondering if Level3 would have to pay an SLA breach >> to its customers given the mess started with TM (even though it could have >> been avoided). And I am guessing if they do, they wouldn't be able to >> recover anything from TM. > > > I doubt if L3 has to pay anything to its customers in terms of SLA breach, > its best effort. Are you aware of any such agreement which suggest > otherwise? that would be interesting. > From morrowc.lists at gmail.com Mon Jun 15 02:41:32 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 14 Jun 2015 22:41:32 -0400 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> <0E7CF624-AC04-4973-99BF-F41E8BB3B002@beckman.org> Message-ID: On Sun, Jun 14, 2015 at 9:20 PM, Rafael Possamai wrote: > Well, I was wondering the same. I am guessing it depends on the SLA > contract since they are all very unique and specific. I'm going to bet that aside from a few one-off cases the SLA in question talks about maintaining reachability inside L3's network, or maybe even 'is your link up and can you ping the L3 gateway router you connect to?' SLA's aren't meant to actually get paid out... From outsider at scarynet.org Mon Jun 15 03:56:41 2015 From: outsider at scarynet.org (Alexander Maassen) Date: Mon, 15 Jun 2015 05:56:41 +0200 Subject: 2.4Ghz 40Mhz 802.11n wifi and Apple Macbook In-Reply-To: <557DCB06.6040606@2mbit.com> References: <557DCB06.6040606@2mbit.com> Message-ID: <014afcc2287b3a5d4dd0e19db49c3be8.squirrel@mail.scarynet.org> Shoot me if i'm wrong, but doesn't a mac prefer MIMO in order to work correctly? On Sun, June 14, 2015 8:42 pm, Brielle Bruns wrote: > On 6/14/15 12:33 PM, Anurag Bhatia wrote: >> Hello everyone, >> >> >> >> I am running a TP Link TL-WR1043N which (as TP Link says is a) 802.11n >> router working on 2.4Ghz (no support for 5Ghz). I am running it with >> flashed OpenWRT. >> >> >> >> While using option to pick 40Mhz, I see my Mac only gets 20Mhz to use >> and >> speed is always 130Mbps. There's no other SSID nearby and I am sitting >> next >> to router for testing. >> >> >> This brings me to question - Has anyone successfully used 40Mhz with >> 2.4Ghz >> on 802.11n standard with Apple Macbook? I wonder if it's limitation on >> the >> chipset or something else. >> >> >> > > Everything that I've seen/experienced says that Apple devices won't use > 40mhz channels with 2.4 due to the overlapping bands/lack of good > separation between channels. > > However, I'm not sure if this specifically applies to just the Airport > APs like the Extreme, or to the laptops as well, as I use AE's at home, > and the Unifi APs I do have in service all have 20mhz channels only set > on them to avoid issues. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From josh at spitwspots.com Mon Jun 15 04:06:12 2015 From: josh at spitwspots.com (Josh Reynolds) Date: Sun, 14 Jun 2015 20:06:12 -0800 Subject: 2.4Ghz 40Mhz 802.11n wifi and Apple Macbook In-Reply-To: <014afcc2287b3a5d4dd0e19db49c3be8.squirrel@mail.scarynet.org> Message-ID: <152b07f1-5f1c-4a9b-993f-aab558bfb53d@email.android.com> 40MHz on 2.4 is note widely supported, and for good reason - it sucks up the entire unlicensed 2.4GHz band (if you include the 802.12 mask). On 5GHz, 20/40 are supported, and 80/160 in current and future versions of 802.11ac. On Jun 14, 2015 7:56 PM, Alexander Maassen wrote: > > Shoot me if i'm wrong, but doesn't a mac prefer MIMO in order to work > correctly? > > On Sun, June 14, 2015 8:42 pm, Brielle Bruns wrote: > > On 6/14/15 12:33 PM, Anurag Bhatia wrote: > >> Hello everyone, > >> > >> > >> > >> I am running a TP Link TL-WR1043N which (as TP Link says is a) 802.11n > >> router working on 2.4Ghz (no support for 5Ghz). I am running it with > >> flashed OpenWRT. > >> > >> > >> > >> While using option to pick 40Mhz, I see my Mac only gets 20Mhz to use > >> and > >> speed is always 130Mbps. There's no other SSID nearby and I am sitting > >> next > >> to router for testing. > >> > >> > >> This brings me to question - Has anyone successfully used 40Mhz with > >> 2.4Ghz > >> on 802.11n standard with Apple Macbook? I wonder if it's limitation on > >> the > >> chipset or something else. > >> > >> > >> > > > > Everything that I've seen/experienced says that Apple devices won't use > > 40mhz channels with 2.4 due to the overlapping bands/lack of good > > separation between channels. > > > > However, I'm not sure if this specifically applies to just the Airport > > APs like the Extreme, or to the laptops as well, as I use AE's at home, > > and the Unifi APs I do have in service all have 20mhz channels only set > > on them to avoid issues. > > > > > > -- > > Brielle Bruns > > The Summit Open Source Development Group > > http://www.sosdg.org??? /???? http://www.ahbl.org > > > > From mark.tinka at seacom.mu Mon Jun 15 07:40:16 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 15 Jun 2015 09:40:16 +0200 Subject: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> <0E7CF624-AC04-4973-99BF-F41E8BB3B002@beckman.org> Message-ID: <557E8160.5000001@seacom.mu> On 15/Jun/15 03:01, Randy Bush wrote: > what i have yet to understand (probably my fault) is how L(3) propagated > the disease or, more correctly, what has happened over there that they > did not stop the propagation? the crew that went there from mci ran a > very tight ship and L(3) has always had pretty rigid filters. what > happened? and i mean that in the sense of how can i not make a similar > mistake? Given that TM were leaking into 3549, one may infer that Level(3)'s tight screws have not yet completely filtered down to the GBLX network of old. Conjecture on my part... It is no secret that Level(3)'s IRR client is broken, and as others have mentioned before, it's reasonably common to give them a call and get the spanner rammed over its head for the thing to work. Whether they are using the same for the GBLX network, or if the GBLX network is the nasty cousin we don't care about until he leaves the house, is an exercise left to all of us. Mark. From hank at efes.iucc.ac.il Mon Jun 15 08:18:35 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 15 Jun 2015 11:18:35 +0300 Subject: Looking for reputable seller of SFPs Message-ID: <5.1.1.6.2.20150615111455.04ff6d90@efes.iucc.ac.il> Looking for a reputable seller of SFPs in the US that ships overseas. Please reply off-list. Thanks, Hank From brandon at rd.bbc.co.uk Mon Jun 15 10:33:18 2015 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Mon, 15 Jun 2015 11:33:18 +0100 (BST) Subject: AS4788 Telecom Malaysia major route leak? Message-ID: <201506151033.LAA18825@sunf10.rd.bbc.co.uk> > From: Rafael Possamai > ... I assume they would have to, granted the issue lasted for a > couple hours. Now, it depends on how they define the outage A L3 outage is something you manage to open a ticket for, if you don't then it didn't happen (been there before, one of their DC lost power, transit down for around 7h, nothing) With the world trying to call them on this you can't get through so no SLA payout for you brandon From emoore at sover.net Mon Jun 15 12:53:27 2015 From: emoore at sover.net (Evan Moore) Date: Mon, 15 Jun 2015 08:53:27 -0400 Subject: [SPAM]Re: AS4788 Telecom Malaysia major route leak? In-Reply-To: References: <28b9bb34dd2543d3a724c9174b5d3d5e@anx-i-dag02.anx.local> <20150614182746.GX94733@Vurt.local> <557DEC57.7020808@seacom.mu> <96FACE93-DA09-48B4-8349-957696B2968F@prolocation.net> <0E7CF624-AC04-4973-99BF-F41E8BB3B002@beckman.org> Message-ID: <695C938D41839C4BA32590DDCF9AD21501F2E389B623@Exchange-01.office.sover.net> Absolutely on point. Let's solve the problem, not the blame. ERM Evan R Moore Network Engineer and Bitwrangler Sovernet Communications -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Bush Sent: Sunday, June 14, 2015 9:02 PM To: North American Network Operators' Group Subject: [SPAM]Re: AS4788 Telecom Malaysia major route leak? what i have yet to understand (probably my fault) is how L(3) propagated the disease or, more correctly, what has happened over there that they did not stop the propagation? the crew that went there from mci ran a very tight ship and L(3) has always had pretty rigid filters. what happened? and i mean that in the sense of how can i not make a similar mistake? randy From nanog at ics-il.net Mon Jun 15 13:15:29 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 15 Jun 2015 08:15:29 -0500 (CDT) Subject: 2.4Ghz 40Mhz 802.11n wifi and Apple Macbook In-Reply-To: <152b07f1-5f1c-4a9b-993f-aab558bfb53d@email.android.com> Message-ID: <17530089.3028.1434374152057.JavaMail.mhammett@ThunderFuck> It'd be nice if IEEE would start supporting smaller channel sizes and a sync method in the 802.11 specifications. make the default channel size 5 MHz and it auto increases as necessary. 20 meg Internet could get by just fine on interference free 5 MHz. Have a 1588-like sync mechanism sent from the ISP for residential (or your controller for public\business use) to have them transit in sync as well to reduce interference. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Josh Reynolds" To: outsider at scarynet.org Cc: nanog at nanog.org Sent: Sunday, June 14, 2015 11:06:12 PM Subject: Re: 2.4Ghz 40Mhz 802.11n wifi and Apple Macbook 40MHz on 2.4 is note widely supported, and for good reason - it sucks up the entire unlicensed 2.4GHz band (if you include the 802.12 mask). On 5GHz, 20/40 are supported, and 80/160 in current and future versions of 802.11ac. On Jun 14, 2015 7:56 PM, Alexander Maassen wrote: > > Shoot me if i'm wrong, but doesn't a mac prefer MIMO in order to work > correctly? > > On Sun, June 14, 2015 8:42 pm, Brielle Bruns wrote: > > On 6/14/15 12:33 PM, Anurag Bhatia wrote: > >> Hello everyone, > >> > >> > >> > >> I am running a TP Link TL-WR1043N which (as TP Link says is a) 802.11n > >> router working on 2.4Ghz (no support for 5Ghz). I am running it with > >> flashed OpenWRT. > >> > >> > >> > >> While using option to pick 40Mhz, I see my Mac only gets 20Mhz to use > >> and > >> speed is always 130Mbps. There's no other SSID nearby and I am sitting > >> next > >> to router for testing. > >> > >> > >> This brings me to question - Has anyone successfully used 40Mhz with > >> 2.4Ghz > >> on 802.11n standard with Apple Macbook? I wonder if it's limitation on > >> the > >> chipset or something else. > >> > >> > >> > > > > Everything that I've seen/experienced says that Apple devices won't use > > 40mhz channels with 2.4 due to the overlapping bands/lack of good > > separation between channels. > > > > However, I'm not sure if this specifically applies to just the Airport > > APs like the Extreme, or to the laptops as well, as I use AE's at home, > > and the Unifi APs I do have in service all have 20mhz channels only set > > on them to avoid issues. > > > > > > -- > > Brielle Bruns > > The Summit Open Source Development Group > > http://www.sosdg.org / http://www.ahbl.org > > > > From jared at puck.Nether.net Mon Jun 15 13:19:36 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Mon, 15 Jun 2015 09:19:36 -0400 Subject: Apple ECN, Bufferbloat, CoDel (fwd) In-Reply-To: References: Message-ID: <20150615131936.GA32565@puck.nether.net> On Sat, Jun 13, 2015 at 06:20:31PM +0200, Mikael Abrahamsson wrote: > > Hi, > > I just want to bring to your attention the below talk (I am too lazy to > re-write the whole email for this slightly different audience). > > Takeaway: > > We'll see a lot of ECN enabled traffic in a few months. This shouldn't be a > problem. I've been doing it to all my machines for 3-5 years without ill > effects. I recall when ECN first came out and firewalls would block it causing me issues on my Linux boxes sending list mail out. It was a small enough percentage that I mostly ignored it, but this will cause trouble for people who still haven't fixed their broken firewalls. I encourage almost everyone on nanog to watch this talk. - Jared > ---------- Forwarded message ---------- > Date: Sat, 13 Jun 2015 18:07:57 +0200 (CEST) > From: Mikael Abrahamsson > To: bloat at lists.bufferbloat.net > Subject: Apple ECN, Bufferbloat, CoDel > > I highly encourage people to take a look at: > > https://developer.apple.com/videos/wwdc/2015/?id=719 > -- > Mikael Abrahamsson email: swmike at swm.pp.se -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From byron.hicks at tx-learn.net Mon Jun 15 14:27:06 2015 From: byron.hicks at tx-learn.net (Hicks, Byron) Date: Mon, 15 Jun 2015 14:27:06 +0000 Subject: Setting Up a Looking Glass In-Reply-To: <58ac0d5bfd7ce742056353375622c71e.squirrel@secure.blakjak.net> References: <29124575.1241.1434212866266.JavaMail.mhammett@ThunderFuck> <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> <58ac0d5bfd7ce742056353375622c71e.squirrel@secure.blakjak.net> Message-ID: <559C583A-9852-4CD8-910E-418E2A73CF62@tx-learn.net> True. However, this is not a Microsoft Windows app, so the installer isn?t in play here. The file is a .tar.gz file that contains the perl scripts necessary to set up the looking glass/router proxy, so it should be reasonably safe. Hopefully, the University of Indiana will move the source to a safer delivery system in the future. > On Jun 14, 2015, at 3:43 AM, Mark Foster wrote: > > If only it wasn't on sourceforge? > > http://ow.ly/OhNcR > > (or the original link, > http://www.howtogeek.com/218764/warning-don't-download-software-from-sourceforge-if-you-can-help-it/) > ? Byron Hicks Lonestar Education and Research Network 972-746-2549 aim/skype: byronhicks -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3648 bytes Desc: not available URL: From mborchers at phonoscope.com Mon Jun 15 15:58:41 2015 From: mborchers at phonoscope.com (Mark Borchers) Date: Mon, 15 Jun 2015 15:58:41 +0000 Subject: Looking for reputable seller of SFPs In-Reply-To: <5.1.1.6.2.20150615111455.04ff6d90@efes.iucc.ac.il> References: <5.1.1.6.2.20150615111455.04ff6d90@efes.iucc.ac.il> Message-ID: <3E25DB3E3BD3604FAB2786D50BFD827E6F01D2@XCHG1.phonoscope.com> Jason (below) told me they were supplying products to South America, so assume shipping overseas is within this company's normal business activity. [Logo][Phonoscope Banner] Mark Borchers Direct: (832) 615-7918 Mobile: (832) 202-5971 Main: (713) 272-4600 Email: mborchers at phonoscope.com Jason Ross Quality Network Components 2734 Loker Avenue West Suite M Carlsbad, CA 92010 Skype: jross-qnc *1-760-600-5777- Office *1-760-600-5774- Direct 1-760-600-5778- Fax 1-714-697-4494- Mobile Jasonr at quality-netcom.com www.quality-netcom.com [cid:image001.png at 01CE1506.5E7906A0] -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hank Nussbacher Sent: Monday, June 15, 2015 3:19 AM To: nanog at nanog.org Subject: Looking for reputable seller of SFPs Looking for a reputable seller of SFPs in the US that ships overseas. Please reply off-list. Thanks, Hank From joelja at bogus.com Mon Jun 15 16:13:47 2015 From: joelja at bogus.com (joel jaeggli) Date: Mon, 15 Jun 2015 09:13:47 -0700 Subject: Apple ECN, Bufferbloat, CoDel (fwd) In-Reply-To: <20150615131936.GA32565@puck.nether.net> References: <20150615131936.GA32565@puck.nether.net> Message-ID: <557EF9BB.3040604@bogus.com> On 6/15/15 6:19 AM, Jared Mauch wrote: > On Sat, Jun 13, 2015 at 06:20:31PM +0200, Mikael Abrahamsson wrote: >> >> Hi, >> >> I just want to bring to your attention the below talk (I am too lazy to >> re-write the whole email for this slightly different audience). >> >> Takeaway: >> >> We'll see a lot of ECN enabled traffic in a few months. This shouldn't be a >> problem. I've been doing it to all my machines for 3-5 years without ill >> effects. you'll also find all the networks that use the entire tos field as part of the hash key... that's not exactly something you notice when you have a 1:1 host to ip correspondence unless it leads to reordering. but with stateless load balancing you can. fortunately those networks are observably rare. > I recall when ECN first came out and firewalls would block it causing me > issues on my Linux boxes sending list mail out. It was a small enough percentage > that I mostly ignored it, but this will cause trouble for people who still > haven't fixed their broken firewalls. > > I encourage almost everyone on nanog to watch this talk. > > - Jared > >> ---------- Forwarded message ---------- >> Date: Sat, 13 Jun 2015 18:07:57 +0200 (CEST) >> From: Mikael Abrahamsson >> To: bloat at lists.bufferbloat.net >> Subject: Apple ECN, Bufferbloat, CoDel >> >> I highly encourage people to take a look at: >> >> https://developer.apple.com/videos/wwdc/2015/?id=719 > >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From dave.taht at gmail.com Mon Jun 15 16:36:40 2015 From: dave.taht at gmail.com (Dave Taht) Date: Mon, 15 Jun 2015 09:36:40 -0700 Subject: Apple ECN, Bufferbloat, CoDel (fwd) In-Reply-To: <557EF9BB.3040604@bogus.com> References: <20150615131936.GA32565@puck.nether.net> <557EF9BB.3040604@bogus.com> Message-ID: On Mon, Jun 15, 2015 at 9:13 AM, joel jaeggli wrote: > On 6/15/15 6:19 AM, Jared Mauch wrote: >> On Sat, Jun 13, 2015 at 06:20:31PM +0200, Mikael Abrahamsson wrote: >>> >>> Hi, >>> >>> I just want to bring to your attention the below talk (I am too lazy to >>> re-write the whole email for this slightly different audience). >>> >>> Takeaway: >>> >>> We'll see a lot of ECN enabled traffic in a few months. This shouldn't be a >>> problem. I've been doing it to all my machines for 3-5 years without ill >>> effects. > > you'll also find all the networks that use the entire tos field as part > of the hash key... that's not exactly something you notice when you have > a 1:1 host to ip correspondence unless it leads to reordering. but with > stateless load balancing you can. fortunately those networks are > observably rare. I am aware of one such (very large) network that did, indeed, (and til recently!) have devices that used the entire tos field in their ECMP implementation. This led to re-ordering every time ECN "CE" was exerted on ECN enabled flows. Testing for the existence of this problem is not terribly hard (example, have a rule that periodically exerts CE on a bunch of test tcp flows, count the reorders in TCP_INFO), but the tools for it are kind of adhoc as yet. I am curious if there is a SNMP mib/cacti/mrtg/other support for reporting "CE" events in addition to loss? Although fq_codel and pie (as deployed in linux - sadly docis-pie has no ECN support in the spec) do do ecn markings (fq_codel *by default*), deployment on bottleneck links is limited as yet. :) My expectation is that this will make a difference first for apple streaming video apps in the home, connecting to other devices in the home (over wifi, ethernet, bluetooth, etc) that will start to make use of this additional signalling information. And a billion new devices with ecn on by default will probably expose all the other problems rather rapidly. ;) >> I recall when ECN first came out and firewalls would block it causing me >> issues on my Linux boxes sending list mail out. It was a small enough percentage >> that I mostly ignored it, but this will cause trouble for people who still >> haven't fixed their broken firewalls. Better fallbacks exist now. >> I encourage almost everyone on nanog to watch this talk. >> >> - Jared >> >>> ---------- Forwarded message ---------- >>> Date: Sat, 13 Jun 2015 18:07:57 +0200 (CEST) >>> From: Mikael Abrahamsson >>> To: bloat at lists.bufferbloat.net >>> Subject: Apple ECN, Bufferbloat, CoDel >>> >>> I highly encourage people to take a look at: >>> >>> https://developer.apple.com/videos/wwdc/2015/?id=719 >> >>> -- >>> Mikael Abrahamsson email: swmike at swm.pp.se >> > > -- Dave T?ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From bruns at 2mbit.com Mon Jun 15 17:39:48 2015 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 15 Jun 2015 11:39:48 -0600 Subject: 2.4Ghz 40Mhz 802.11n wifi and Apple Macbook In-Reply-To: <014afcc2287b3a5d4dd0e19db49c3be8.squirrel@mail.scarynet.org> References: <557DCB06.6040606@2mbit.com> <014afcc2287b3a5d4dd0e19db49c3be8.squirrel@mail.scarynet.org> Message-ID: <557F0DE4.5010308@2mbit.com> On 6/14/15 9:56 PM, Alexander Maassen wrote: > Shoot me if i'm wrong, but doesn't a mac prefer MIMO in order to work > correctly? You still get a nice performance boost with 802.11b/g/n in 2.4 range even at 20mhz, but if you go to 40mhz, you'll be splattering all over the entire 2.4 band. This is why all of the pre-N performance enhancements for G were troublemakers if you had multiple wireless networks in the same area. You turn it on, and one of two things happen - you either wreck performance of everyone else on that band, or everyone else wrecks your performance. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From joe at nethead.com Mon Jun 15 17:50:15 2015 From: joe at nethead.com (Joe Hamelin) Date: Mon, 15 Jun 2015 10:50:15 -0700 Subject: Anycast provider for SMTP? Message-ID: I have a mail system where there are two MX hosts, one in the US and one in Europe. Both have a DNS MX record metric of 10 so a bastardized round-robin takes place. This does not work so well when one site goes down. My solution will be to place a load balancer in a hosting site (virtual, of course) and have it provide HA. But what about HA for the LB? At first glance anycasting would seem to be a great idea but there is a problem of broken sessions when routes change. Have any of you seen something like this work in the wild? -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From jj at anexia.at Mon Jun 15 17:54:31 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Mon, 15 Jun 2015 17:54:31 +0000 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: <86e46e2e7e7c41b397bb4baacc864a30@anx-i-dag02.anx.local> I guess there is no real chance without conntrack ... I'll try to use something like LVS+mysql conntrack (no idea if this even exists ...) .... J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Original Message----- From: Joe Hamelin [joe at nethead.com] Received: Montag, 15 Juni 2015, 19:51 To: NANOG list [nanog at nanog.org] Subject: Anycast provider for SMTP? I have a mail system where there are two MX hosts, one in the US and one in Europe. Both have a DNS MX record metric of 10 so a bastardized round-robin takes place. This does not work so well when one site goes down. My solution will be to place a load balancer in a hosting site (virtual, of course) and have it provide HA. But what about HA for the LB? At first glance anycasting would seem to be a great idea but there is a problem of broken sessions when routes change. Have any of you seen something like this work in the wild? -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From jco at direwolf.com Mon Jun 15 17:55:48 2015 From: jco at direwolf.com (John Orthoefer) Date: Mon, 15 Jun 2015 13:55:48 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: Well we, Genuity, use to use Cisco Distributed Director to do this. Basically it was a DNS server that ran on a Cisco Router, and could use a lot of different metrics to give an answer, which included routing based metrics. Johno > On Jun 15, 2015, at 1:50 PM, Joe Hamelin wrote: > > I have a mail system where there are two MX hosts, one in the US and one in > Europe. Both have a DNS MX record metric of 10 so a bastardized > round-robin takes place. This does not work so well when one site goes > down. My solution will be to place a load balancer in a hosting site > (virtual, of course) and have it provide HA. But what about HA for the > LB? At first glance anycasting would seem to be a great idea but there is > a problem of broken sessions when routes change. > > Have any of you seen something like this work in the wild? > > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From morrowc.lists at gmail.com Mon Jun 15 18:02:48 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 15 Jun 2015 14:02:48 -0400 Subject: Anycast provider for SMTP? In-Reply-To: <86e46e2e7e7c41b397bb4baacc864a30@anx-i-dag02.anx.local> References: <86e46e2e7e7c41b397bb4baacc864a30@anx-i-dag02.anx.local> Message-ID: On Mon, Jun 15, 2015 at 1:54 PM, J?rgen Jaritsch wrote: > I guess there is no real chance without conntrack ... I'll try to use something like LVS+mysql conntrack (no idea if this even exists ...) .... not clear how helpful that is? > -----Original Message----- > From: Joe Hamelin [joe at nethead.com] > Received: Montag, 15 Juni 2015, 19:51 > To: NANOG list [nanog at nanog.org] > Subject: Anycast provider for SMTP? > > I have a mail system where there are two MX hosts, one in the US and one in > Europe. Both have a DNS MX record metric of 10 so a bastardized > round-robin takes place. This does not work so well when one site goes > down. My solution will be to place a load balancer in a hosting site 'when one site goes down' ... then the other works fine, right? smtp is not latency sensitive in the sense that a 30second timeout for a server will mean delivery to the secondary... right? > (virtual, of course) and have it provide HA. But what about HA for the > LB? At first glance anycasting would seem to be a great idea but there is > a problem of broken sessions when routes change. > > Have any of you seen something like this work in the wild? From jwalter at weebly.com Mon Jun 15 18:04:47 2015 From: jwalter at weebly.com (Jeff Walter) Date: Mon, 15 Jun 2015 11:04:47 -0700 Subject: Setting Up a Looking Glass In-Reply-To: <559C583A-9852-4CD8-910E-418E2A73CF62@tx-learn.net> References: <29124575.1241.1434212866266.JavaMail.mhammett@ThunderFuck> <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> <58ac0d5bfd7ce742056353375622c71e.squirrel@secure.blakjak.net> <559C583A-9852-4CD8-910E-418E2A73CF62@tx-learn.net> Message-ID: Having written two looking glasses from scratch (lg.he.net and and internal one for Weebly) I can tell you it's actually pretty simple. If you're interested in writing your own I'm happy to pass along pointers to help you. Jeff On Mon, Jun 15, 2015 at 7:27 AM, Hicks, Byron wrote: > True. > > However, this is not a Microsoft Windows app, so the installer isn?t in > play here. The file is a .tar.gz file that contains the perl scripts > necessary to set up the looking glass/router proxy, so it should be > reasonably safe. Hopefully, the University of Indiana will move the source > to a safer delivery system in the future. > > > > On Jun 14, 2015, at 3:43 AM, Mark Foster wrote: > > > > If only it wasn't on sourceforge? > > > > http://ow.ly/OhNcR > > > > (or the original link, > > > http://www.howtogeek.com/218764/warning-don't-download-software-from-sourceforge-if-you-can-help-it/ > ) > > > > ? > Byron Hicks > Lonestar Education and Research Network > 972-746-2549 > aim/skype: byronhicks > > > > > From bill at herrin.us Mon Jun 15 18:09:11 2015 From: bill at herrin.us (William Herrin) Date: Mon, 15 Jun 2015 14:09:11 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: On Mon, Jun 15, 2015 at 1:50 PM, Joe Hamelin wrote: > My solution will be to place a load balancer in a hosting site > (virtual, of course) and have it provide HA. But what about HA for the > LB? At first glance anycasting would seem to be a great idea but there is > a problem of broken sessions when routes change. > > Have any of you seen something like this work in the wild? Anycast + TCP = much pain, for reasons which should be obvious. It's on the near side of impossible, but the far side of impractical. You'd spend a lot of money with some high-price software developers getting it to work. > I have a mail system where there are two MX hosts, one in the US and one in > Europe. Both have a DNS MX record metric of 10 so a bastardized > round-robin takes place. This does not work so well when one site goes > down. Not sure why you'd have problems with this since it's a primary operating mode that SMTP was explicitly designed for. Can you elaborate on the kinds of trouble you've experienced? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From woody at pch.net Mon Jun 15 18:13:02 2015 From: woody at pch.net (Bill Woodcock) Date: Mon, 15 Jun 2015 11:13:02 -0700 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: > On Jun 15, 2015, at 10:50 AM, Joe Hamelin wrote: > > I have a mail system where there are two MX hosts, one in the US and one in > Europe. Both have a DNS MX record metric of 10 so a bastardized > round-robin takes place. This does not work so well when one site goes > down. My solution will be to place a load balancer in a hosting site > (virtual, of course) and have it provide HA. But what about HA for the > LB? It seems like you may be over-thinking this. You could, in fact, use anycast, in one of two ways: You could anycast the DNS, with servers in the US and Europe, and different MX metrics between the two, so anyone who?s nearby the European DNS server will see the European MX host as the first-choice, and anyone nearer the US DNS server will see the US MX host as first-choice. Or you could skip the MX records, and just put both US and European SMTP servers on the same IP address, which would save a lot of steps and simplify the system, but leave you with the _very_ occasional corner-case of someone equal-path-length load-balancing traffic to you such that half of one TCP session goes to Europe, and half the the US. That?s a bogeyman that scares a lot of people into not using anycast for TCP services, particularly long-lived ones, but it?s a theoretical problem rather than an actually-observed-in-the-wild problem. But since it scares people, it?s probably safer just doing the DNS anycast, rather than SMTP anycast, to avoid startling the easily-upset out there. :-) Either of these is vastly simpler and more reliable than trying to throw a load balancer into the mix. As you note, load balancers aren?t particularly HA. Always replace load balancers with crossconnects. Much more HA. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From joe at nethead.com Mon Jun 15 18:13:37 2015 From: joe at nethead.com (Joe Hamelin) Date: Mon, 15 Jun 2015 11:13:37 -0700 Subject: Anycast provider for SMTP? In-Reply-To: References: <86e46e2e7e7c41b397bb4baacc864a30@anx-i-dag02.anx.local> Message-ID: On Mon, Jun 15, 2015 at 11:02 AM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > > 'when one site goes down' ... then the other works fine, right? smtp > is not latency sensitive in the sense that a 30second timeout for a > server will mean delivery to the secondary... right? The two MX sites are connected via third party MPLS. The problem is when one MX site loses Internet connectivity the sending MTA may take up to 4 hours to resend and hopefully the DNS coin toss gives it the address of the site that is still connected. (Read as: French ISPs don't seem as robust as I'm use to in the US.) Since our mail traffic is international something like anycast would be nice. Now the other problem is we don't have an ASN or do external BGP ourselves. And not that it matters in a network sense, but this is a Domino mail system. I'm just trying to bring it up to year 2000 standards. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > From colton.conor at gmail.com Mon Jun 15 18:17:52 2015 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 15 Jun 2015 13:17:52 -0500 Subject: 2.4Ghz 40Mhz 802.11n wifi and Apple Macbook In-Reply-To: <557F0DE4.5010308@2mbit.com> References: <557DCB06.6040606@2mbit.com> <014afcc2287b3a5d4dd0e19db49c3be8.squirrel@mail.scarynet.org> <557F0DE4.5010308@2mbit.com> Message-ID: So assuming you live in a decent sized house/lot, should you really care about squatting all over the entire band? I mean sure I can see my neighbors wifi signals, but they are too weak for me to connect with them. So wouldn't mine be just as weak at their location, so why should I care about using the entire band? Aren't I really only using 2/3 of the band by going to 40Mhz, leaving an entire 20Mhz wide channel free for my neighbors AP to switch over to? I see substantial improvements in going from 20 to 40 Mhz from smartphone's that have 1X1 fixed antennas which is every smartphone. Going from 20 Mhz with a max theoretical of 72.2Mbps to 40 Mhz with a max theoretical of 150Mbps is a big difference. Especially when you typically only get half of the max theoretical speed. On Mon, Jun 15, 2015 at 12:39 PM, Brielle Bruns wrote: > On 6/14/15 9:56 PM, Alexander Maassen wrote: > >> Shoot me if i'm wrong, but doesn't a mac prefer MIMO in order to work >> correctly? >> > > You still get a nice performance boost with 802.11b/g/n in 2.4 range even > at 20mhz, but if you go to 40mhz, you'll be splattering all over the entire > 2.4 band. > > This is why all of the pre-N performance enhancements for G were > troublemakers if you had multiple wireless networks in the same area. You > turn it on, and one of two things happen - you either wreck performance of > everyone else on that band, or everyone else wrecks your performance. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From nick at foobar.org Mon Jun 15 18:28:24 2015 From: nick at foobar.org (Nick Hilliard) Date: Mon, 15 Jun 2015 19:28:24 +0100 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: <557F1948.6080506@foobar.org> On 15/06/2015 19:09, William Herrin wrote: > Anycast + TCP = much pain, for reasons which should be obvious. This was presented at some conference or other a couple of years ago: > https://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf Nick From guillaume at ironie.org Mon Jun 15 18:40:13 2015 From: guillaume at ironie.org (Guillaume Tournat) Date: Mon, 15 Jun 2015 20:40:13 +0200 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: <90FE7E60-841C-4993-BC8C-9681A5098BEB@ironie.org> Give a look at hosted GSLB service, FortiDirector, which I have set up for a customer (for SMTP, Exchange, ActiveSync world wide services. > Le 15 juin 2015 ? 19:50, Joe Hamelin a ?crit : > > I have a mail system where there are two MX hosts, one in the US and one in > Europe. Both have a DNS MX record metric of 10 so a bastardized > round-robin takes place. This does not work so well when one site goes > down. My solution will be to place a load balancer in a hosting site > (virtual, of course) and have it provide HA. But what about HA for the > LB? At first glance anycasting would seem to be a great idea but there is > a problem of broken sessions when routes change. > > Have any of you seen something like this work in the wild? > > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From bill at herrin.us Mon Jun 15 18:54:40 2015 From: bill at herrin.us (William Herrin) Date: Mon, 15 Jun 2015 14:54:40 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: On Mon, Jun 15, 2015 at 2:13 PM, Bill Woodcock wrote: > Or you could skip the MX records, and just put both US and European > SMTP servers on the same IP address, which would save a lot of > steps and simplify the system, but leave you with the _very_ > occasional corner-case of someone equal-path-length load-balancing > traffic to you such that half of one TCP session goes to Europe, and > half the the US. That?s a bogeyman that scares a lot of people into not > using anycast for TCP services, particularly long-lived ones, but it?s a > theoretical problem rather than an actually-observed-in-the-wild problem. > But since it scares people, it?s probably safer just doing the DNS > anycast, rather than SMTP anycast, to avoid startling the > easily-upset out there. :-) If I had a dollar for every system that's collapsed from a known but previously "theoretical" problem... It's only theoretical until a VIP can't connect. Deploy a system without covering the corner cases and your comeuppance is assured. Okay, granted you can probably cover your corner case here with a priority 20 MX that leads to a unicast address on one of the two servers. SMTP can let the rare fellow with the bisected packet flow gracefully fall back. Nevertheless, I think you've offered some really bad advice here Bill. Hijackers killing the passengers was a bogeyman too. If you just kept calm and cooperated, you lived through it. Until you didn't, and allowed yourself to be an instrument in killing thousands on the ground as a bonus. Sometimes the math offers really bad advice. On Mon, Jun 15, 2015 at 2:28 PM, Nick Hilliard wrote: > On 15/06/2015 19:09, William Herrin wrote: >> Anycast + TCP = much pain, for reasons which should be obvious. > > This was presented at some conference or other a couple of years ago: > https://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf Thought the comment on page 22 was apropos: their plan is to be dead before future change catches up with them. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From morrowc.lists at gmail.com Mon Jun 15 18:57:59 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 15 Jun 2015 14:57:59 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: On Mon, Jun 15, 2015 at 2:54 PM, William Herrin wrote: > Okay, granted you can probably cover your corner case here with a > priority 20 MX that leads to a unicast address on one of the two > servers. SMTP can let the rare fellow with the bisected packet flow > gracefully fall back. but 'well behaved smtp clients' should already be falling back right? From jabley at hopcount.ca Mon Jun 15 18:58:05 2015 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 15 Jun 2015 14:58:05 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: Hi Joe, On 15 Jun 2015, at 13:50, Joe Hamelin wrote: > I have a mail system where there are two MX hosts, one in the US and > one in > Europe. Both have a DNS MX record metric of 10 so a bastardized > round-robin takes place. This does not work so well when one site > goes > down. My solution will be to place a load balancer in a hosting site > (virtual, of course) and have it provide HA. But what about HA for > the > LB? At first glance anycasting would seem to be a great idea but > there is > a problem of broken sessions when routes change. > > Have any of you seen something like this work in the wild? If you can give responses to QTYPE=MX queries that match the location of the client, you can approximate this without deploying your SMTP servers using anycast. This feels like a simpler solution to operate; anycast sometimes pits BGP-fearing, syseng people against neteng people when things break at 3am, and if that rings true for you then a solution that avoids it might be of interest. So, suppose clients in region A could query NETHEAD.COM/IN/MX and get a response that looks like NETHEAD.COM. IN MX 10 REGION-A-MX.NETHEAD.COM. IN MX 20 REGION-B-MX.NETHEAD.COM. IN MX 20 REGION-C-MX.NETHEAD.COM. whereas clients in region B might see a response that looks more sensible to them: NETHEAD.COM. IN MX 10 REGION-B-MX.NETHEAD.COM. IN MX 20 REGION-A-MX.NETHEAD.COM. IN MX 20 REGION-C-MX.NETHEAD.COM. etc, etc. That way you still get a reasonable fallback in the event that one MX target is unreachable for a particular client, but you steer the bulk of your traffic in a way that makes sense (and which your syseng people don't have to understand the details of). You can achieve the above DNS trickery using various load balancers that other people in this thread have already mentioned. You can also install your own geomaps in your own nameservers and handle it yourself, or you can buy managed DNS service from various people that can do this kind of thing. Disclaimer: Dyn, for whom I work, sells such a service. Joe From dave.taht at gmail.com Mon Jun 15 19:05:55 2015 From: dave.taht at gmail.com (Dave Taht) Date: Mon, 15 Jun 2015 12:05:55 -0700 Subject: Anycast provider for SMTP? In-Reply-To: <557F1948.6080506@foobar.org> References: <557F1948.6080506@foobar.org> Message-ID: On Mon, Jun 15, 2015 at 11:28 AM, Nick Hilliard wrote: > On 15/06/2015 19:09, William Herrin wrote: >> Anycast + TCP = much pain, for reasons which should be obvious. > > This was presented at some conference or other a couple of years ago: > >> https://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf >From that otherwise encouraging preso: "What about IPv6? We have a plan! We plan to be dead before customers demand IPv6". I am pretty sure the authors are still alive(?). I have been using anycast at a small scale on mesh networks, for dns, primarily. Works. > Nick > > -- Dave T?ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From bill at herrin.us Mon Jun 15 19:15:51 2015 From: bill at herrin.us (William Herrin) Date: Mon, 15 Jun 2015 15:15:51 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: <86e46e2e7e7c41b397bb4baacc864a30@anx-i-dag02.anx.local> Message-ID: On Mon, Jun 15, 2015 at 2:13 PM, Joe Hamelin wrote: > The two MX sites are connected via third party MPLS. The problem is when > one MX site loses Internet connectivity the sending MTA may take up to 4 > hours to resend and hopefully the DNS coin toss gives it the address of the > site that is still connected. Hi Joe, Have you been able to document which originating MTA software misbehaves this way? Correct SMTP behavior is to attempt TCP connections to all IP addresses at each MX level in turn, and repeat for each MX level. Only upon failure of all of them. defer the message for later delivery. Interrupted connections (as opposed to timeouts) may go straight to deferred, figuring that bulk traffic like email should pause if congestion exhibits itself in the form of a stalled TCP connection. So it would make sense for a handful of messages to be delayed. And of course all bets are off if Internet connectivity is "flapping" instead of hard down. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From maxtul at netassist.ua Mon Jun 15 19:16:46 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Mon, 15 Jun 2015 22:16:46 +0300 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: <557F249E.4040005@netassist.ua> I see no major problems to use anycast for that. The problem will be in rare case when particular routing chain from client to one of your servers will be changed until TCP stream is active. SMTP have short connections. Even if it happens, it will look as just broken connection for client, and it will shortly re-try it. Am I lost something? On 15.06.15 20:50, Joe Hamelin wrote: > I have a mail system where there are two MX hosts, one in the US and one in > Europe. Both have a DNS MX record metric of 10 so a bastardized > round-robin takes place. This does not work so well when one site goes > down. My solution will be to place a load balancer in a hosting site > (virtual, of course) and have it provide HA. But what about HA for the > LB? At first glance anycasting would seem to be a great idea but there is > a problem of broken sessions when routes change. > > Have any of you seen something like this work in the wild? > > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > From johnl at iecc.com Mon Jun 15 19:17:22 2015 From: johnl at iecc.com (John Levine) Date: 15 Jun 2015 19:17:22 -0000 Subject: Anycast provider for SMTP? In-Reply-To: Message-ID: <20150615191722.30789.qmail@ary.lan> >but 'well behaved smtp clients' should already be falling back right? If you have multiple SMTP servers at the same priority, it's a pretty broken client that doesn't try them all until one works. That said, there is a depressing number of pretty broken SMTP clients. R's, John From jabley at hopcount.ca Mon Jun 15 19:34:19 2015 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 15 Jun 2015 15:34:19 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: <557F1948.6080506@foobar.org> Message-ID: <6F808E70-6C13-42BE-A18C-5B54F6069597@hopcount.ca> On 15 Jun 2015, at 15:05, Dave Taht wrote: > I have been using anycast at a small scale on mesh networks, for dns, > primarily. Works. Many of us have been using anycast at Internet scale for DNS for a couple of decades. I would go further than "works" and perhaps say "necessary". There were some wise words written in RFC 4786 about use of anycast with other protocols (well, I think they are wise, but then I wrote some of them): When a service is anycast between two or more nodes, the routing system makes the node selection decision on behalf of a client. Since it is usually a requirement that a single client-server interaction is carried out between a client and the same server node for the duration of the transaction, it follows that the routing system's node selection decision ought to be stable for substantially longer than the expected transaction time, if the service is to be provided reliably. Some services have very short transaction times, and may even be carried out using a single packet request and a single packet reply (e.g., DNS transactions over UDP transport). Other services involve far longer-lived transactions (e.g., bulk file downloads and audio- visual media streaming). Services may be anycast within very predictable routing systems, which can remain stable for long periods of time (e.g., anycast within a well-managed and topologically-simple IGP, where node selection changes only occur as a response to node failures). Other deployments have far less predictable characteristics (see Section 4.4.7). The stability of the routing system, together with the transaction time of the service, should be carefully compared when deciding whether a service is suitable for distribution using anycast. In some cases, for new protocols, it may be practical to split large transactions into an initialisation phase that is handled by anycast servers, and a sustained phase that is provided by non-anycast servers, perhaps chosen during the initialisation phase. This document deliberately avoids prescribing rules as to which protocols or services are suitable for distribution by anycast; to attempt to do so would be presumptuous. Operators should be aware that, especially for long running flows, there are potential failure modes using anycast that are more complex than a simple 'destination unreachable' failure using unicast. Joe From zocalo at gmail.com Mon Jun 15 19:44:30 2015 From: zocalo at gmail.com (Andy Blanchard) Date: Mon, 15 Jun 2015 20:44:30 +0100 Subject: Paging Versaweb! Message-ID: Is there anyone from Versaweb on the list, or anyone in the NOC at all? Firstly, both the contact addresses you have listed in WHOIS (ipadmin@ and abuse-reports@) are bouncing emails - no such user. More urgently, while trialling a new SIEM tool I've identified literally thousands of unique IPs spread across at least nine separate ARIN PI allocations scanning for MS DS / TCP:445 going back several months. 162.255.180.0/24 would be a good place to start looking for the common link - I've logged over 150 unique IPs in that block alone, but the rest are not much better. I hate to think what else might have slipped through the net - inbound or outbound... -- Andy The only person to have all his work done by Friday was Robinson Crusoe From rafael at gav.ufsc.br Mon Jun 15 19:45:03 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Mon, 15 Jun 2015 14:45:03 -0500 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: I could be mistaken, but you might get all of this done with AWS's Route53. I would read this: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-geo The other step would be to setup HA in each SMTP node (US and France) such as LB or Failover. Just an idea. On Mon, Jun 15, 2015 at 12:50 PM, Joe Hamelin wrote: > I have a mail system where there are two MX hosts, one in the US and one in > Europe. Both have a DNS MX record metric of 10 so a bastardized > round-robin takes place. This does not work so well when one site goes > down. My solution will be to place a load balancer in a hosting site > (virtual, of course) and have it provide HA. But what about HA for the > LB? At first glance anycasting would seem to be a great idea but there is > a problem of broken sessions when routes change. > > Have any of you seen something like this work in the wild? > > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > From joe at nethead.com Mon Jun 15 19:52:18 2015 From: joe at nethead.com (Joe Hamelin) Date: Mon, 15 Jun 2015 12:52:18 -0700 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: On Mon, Jun 15, 2015 at 12:45 PM, Rafael Possamai wrote: > > > The other step would be to setup HA in each SMTP node (US and France) such > as LB or Failover. Just an idea. > > I'll look at the AWS doc, thanks. The mailserver is seldom the problem (it's an AS/400) but the ISP pipe experiences prolonged outages. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From dave.taht at gmail.com Mon Jun 15 19:54:44 2015 From: dave.taht at gmail.com (Dave Taht) Date: Mon, 15 Jun 2015 12:54:44 -0700 Subject: Anycast provider for SMTP? In-Reply-To: <6F808E70-6C13-42BE-A18C-5B54F6069597@hopcount.ca> References: <557F1948.6080506@foobar.org> <6F808E70-6C13-42BE-A18C-5B54F6069597@hopcount.ca> Message-ID: On Mon, Jun 15, 2015 at 12:34 PM, Joe Abley wrote: > On 15 Jun 2015, at 15:05, Dave Taht wrote: > >> I have been using anycast at a small scale on mesh networks, for dns, >> primarily. Works. > > > Many of us have been using anycast at Internet scale for DNS for a couple of > decades. I would go further than "works" and perhaps say "necessary". Oh, I agree. My point was that anycast is also potentially of use in smaller (corporate/mesh) networks, not just in DNS, but smtp as being discussed here. Web and other forms of proxy, also. Other cases, like gittorrent? I'm pretty sure it's a bad idea for ntp, and for non-fully mirrored file distribution services. > There were some wise words written in RFC 4786 about use of anycast with > other protocols (well, I think they are wise, but then I wrote some of > them): a good read. > > When a service is anycast between two or more nodes, the routing > system makes the node selection decision on behalf of a client. > Since it is usually a requirement that a single client-server > interaction is carried out between a client and the same server node > for the duration of the transaction, it follows that the routing > system's node selection decision ought to be stable for substantially > longer than the expected transaction time, if the service is to be > provided reliably. > > Some services have very short transaction times, and may even be > carried out using a single packet request and a single packet reply > (e.g., DNS transactions over UDP transport). Other services involve > far longer-lived transactions (e.g., bulk file downloads and audio- > visual media streaming). > > Services may be anycast within very predictable routing systems, > which can remain stable for long periods of time (e.g., anycast > within a well-managed and topologically-simple IGP, where node > selection changes only occur as a response to node failures). Other > deployments have far less predictable characteristics (see > Section 4.4.7). > > The stability of the routing system, together with the transaction > time of the service, should be carefully compared when deciding > whether a service is suitable for distribution using anycast. In > some cases, for new protocols, it may be practical to split large > transactions into an initialisation phase that is handled by anycast > servers, and a sustained phase that is provided by non-anycast > servers, perhaps chosen during the initialisation phase. > > This document deliberately avoids prescribing rules as to which > protocols or services are suitable for distribution by anycast; to > attempt to do so would be presumptuous. > > Operators should be aware that, especially for long running flows, > there are potential failure modes using anycast that are more complex > than a simple 'destination unreachable' failure using unicast. > > > Joe -- Dave T?ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From jfbeam at gmail.com Mon Jun 15 20:58:21 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 15 Jun 2015 16:58:21 -0400 Subject: 2.4Ghz 40Mhz 802.11n wifi and Apple Macbook In-Reply-To: References: <557DCB06.6040606@2mbit.com> <014afcc2287b3a5d4dd0e19db49c3be8.squirrel@mail.scarynet.org> <557F0DE4.5010308@2mbit.com> Message-ID: On Mon, 15 Jun 2015 14:17:52 -0400, Colton Conor wrote: > So assuming you live in a decent sized house/lot, should you really care > about squatting all over the entire band? I mean sure I can see my > neighbors wifi signals... *DING* There's your problem. It doesn't matter if you can link and pass traffic. If **ANY** other signal is detected in the extended channel, the AP is *REQUIRED* to cease operation @ 40MHz. This is why it is nearly impossible (outside a shielded lab) to get 40Mhz mode in the 2.4GHz band. SOMETHING is going to step on it -- neighbors, bluetooth, cordless phone, leaky microwave oven, baby monitor, RC toy, ... From rafael at gav.ufsc.br Mon Jun 15 20:58:34 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Mon, 15 Jun 2015 15:58:34 -0500 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: You're welcome. I hope that helps. On another note, if your internet pipe in Europe isn't as stable as your pipe in the US, then you could also try and have your infrastructure provider blend your uplink with two or more carrier-grade paths. You wouldn't have to worry about signing up for and maintaining an AS, but you could improve your uptime significantly. On Mon, Jun 15, 2015 at 2:52 PM, Joe Hamelin wrote: > On Mon, Jun 15, 2015 at 12:45 PM, Rafael Possamai > wrote: >> >> >> The other step would be to setup HA in each SMTP node (US and France) >> such as LB or Failover. Just an idea. >> >> I'll look at the AWS doc, thanks. > > The mailserver is seldom the problem (it's an AS/400) but the ISP pipe > experiences prolonged outages. > > > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > > From joe at nethead.com Mon Jun 15 21:08:38 2015 From: joe at nethead.com (Joe Hamelin) Date: Mon, 15 Jun 2015 14:08:38 -0700 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: On Mon, Jun 15, 2015 at 1:58 PM, Rafael Possamai wrote: > You're welcome. I hope that helps. > > On another note, if your internet pipe in Europe isn't as stable as your > pipe in the US, then you could also try and have your infrastructure > provider blend your uplink with two or more carrier-grade paths. You > wouldn't have to worry about signing up for and maintaining an AS, but you > could improve your uptime significantly. > It seems to be more of a last-mile backhoe fade issue right now. I'm trying to convince them that a manufacturing facility isn't a good place for a data center. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From Steve.Mikulasik at civeo.com Mon Jun 15 21:09:16 2015 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Mon, 15 Jun 2015 21:09:16 +0000 Subject: 2.4Ghz 40Mhz 802.11n wifi and Apple Macbook In-Reply-To: References: <557DCB06.6040606@2mbit.com> <014afcc2287b3a5d4dd0e19db49c3be8.squirrel@mail.scarynet.org> <557F0DE4.5010308@2mbit.com> Message-ID: Is this one of those requirements that gets ignored? I have seen plenty of 40Mhz SSIDs polluting spectrum in areas with lots of overlapping APs. Steve Mikulasik -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ricky Beam Sent: Monday, June 15, 2015 2:58 PM To: Brielle Bruns; Colton Conor Cc: NANOG Subject: Re: 2.4Ghz 40Mhz 802.11n wifi and Apple Macbook On Mon, 15 Jun 2015 14:17:52 -0400, Colton Conor wrote: > So assuming you live in a decent sized house/lot, should you really > care about squatting all over the entire band? I mean sure I can see > my neighbors wifi signals... *DING* There's your problem. It doesn't matter if you can link and pass traffic. If **ANY** other signal is detected in the extended channel, the AP is *REQUIRED* to cease operation @ 40MHz. This is why it is nearly impossible (outside a shielded lab) to get 40Mhz mode in the 2.4GHz band. SOMETHING is going to step on it -- neighbors, bluetooth, cordless phone, leaky microwave oven, baby monitor, RC toy, ... From john at op-sec.us Mon Jun 15 22:00:53 2015 From: john at op-sec.us (John Fraizer) Date: Mon, 15 Jun 2015 15:00:53 -0700 Subject: Setting Up a Looking Glass In-Reply-To: <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> References: <29124575.1241.1434212866266.JavaMail.mhammett@ThunderFuck> <12916721.1247.1434212979314.JavaMail.mhammett@ThunderFuck> Message-ID: http://mrlg.op-sec.us/ -- John Fraizer LinkedIn profile: http://www.linkedin.com/in/johnfraizer/ On Sat, Jun 13, 2015 at 9:29 AM, Mike Hammett wrote: > What's out there for setting up your own looking glass? I saw lots of > lists of dead projects or projects that hadn't received any love in years. > Being as most the people I work with don't run Cisco, Juniper, etc. for > routers, likely having those capabilities with the LG would be nice. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > From jfbeam at gmail.com Mon Jun 15 23:15:42 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 15 Jun 2015 19:15:42 -0400 Subject: 2.4Ghz 40Mhz 802.11n wifi and Apple Macbook In-Reply-To: References: <557DCB06.6040606@2mbit.com> <014afcc2287b3a5d4dd0e19db49c3be8.squirrel@mail.scarynet.org> <557F0DE4.5010308@2mbit.com> Message-ID: On Mon, 15 Jun 2015 17:09:16 -0400, Steve Mikulasik wrote: > Is this one of those requirements that gets ignored? I have seen plenty > of 40Mhz SSIDs polluting spectrum in areas with lots of overlapping APs. It's not supposed to be. But what is (originally) submitted for testing and what you get off the shelf are very likely to be different. And then there are vendors that don't bother to be certified. For reference: my WRT54G-V6 (non-n, doesn't do 40MHz) has a certificate, but doesn't carry the logo -- it was also made well after the 2006 certified date. The Ubee DDW3611 hanging on the wall has a logo, but no certificate (the 3610 has one, from 2010.) From randy at psg.com Tue Jun 16 00:00:46 2015 From: randy at psg.com (Randy Bush) Date: Tue, 16 Jun 2015 09:00:46 +0900 Subject: Anycast provider for SMTP? In-Reply-To: References: <557F1948.6080506@foobar.org> Message-ID: > "What about IPv6? We have a plan! We plan to be dead before customers > demand IPv6". > I am pretty sure the authors are still alive(?). and customer demand for ipv6 still holds strong, right? > I have been using anycast at a small scale on mesh networks, for dns, > primarily. Works. dns is udp rand From dave.taht at gmail.com Tue Jun 16 00:07:22 2015 From: dave.taht at gmail.com (Dave Taht) Date: Mon, 15 Jun 2015 17:07:22 -0700 Subject: Anycast provider for SMTP? In-Reply-To: References: <557F1948.6080506@foobar.org> Message-ID: On Mon, Jun 15, 2015 at 5:00 PM, Randy Bush wrote: >> "What about IPv6? We have a plan! We plan to be dead before customers >> demand IPv6". >> I am pretty sure the authors are still alive(?). > > and customer demand for ipv6 still holds strong, right? Does seem to be on the uptick! >> I have been using anycast at a small scale on mesh networks, for dns, >> primarily. Works. > > dns is udp No. In my case, at least, I have been exhaustively testing dnsmasq + dnssec, which falls back to tcp a lot more often than it used to given all the headaches edns0 was causing, and cloudflare gleefully coming up with ever more innovative ways to dump weird stuff on the wire, like signing a domain with a control-c (\003.domain.com). Although 2.73 just (finally) shipped, I am still concerned about the tcp fallback in the anycast scenario. So I do kind of expect that there will be more tcp dns, and I think tcp dns is something android falls back to a lot, still. > rand -- Dave T?ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From jco at direwolf.com Tue Jun 16 00:56:26 2015 From: jco at direwolf.com (John Orthoefer) Date: Mon, 15 Jun 2015 20:56:26 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: <557F1948.6080506@foobar.org> Message-ID: <53989F39-FAC7-4BF9-A488-763D7D3E635D@direwolf.com> > On Jun 15, 2015, at 8:00 PM, Randy Bush wrote: > > dns is udp 15 years ago when we set up 4.2.2.1, there was a fair amount of TCP based DNS. We tried for a bit to support it via the anycast address, but ultimately we decided the support issues weren?t worth it. The few customers that asked/required it were given non-anycast addresses to use for TCP based DNS. I really think the OPs best answer is some DNS based load balancer, that can take metrics based on routing. johno From rubensk at gmail.com Tue Jun 16 12:11:26 2015 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 16 Jun 2015 09:11:26 -0300 Subject: Access to nanog.cluepon.net In-Reply-To: <001501d0a07e$0e9566a0$2bc033e0$@iname.com> References: <001501d0a07e$0e9566a0$2bc033e0$@iname.com> Message-ID: On Sat, Jun 6, 2015 at 2:27 PM, Frank Bulk wrote: > I'd like to update some material on nanog.cluepon.net (not very responsive > to HTTP requests right now) and my account doesn't work anymore. I reached > out to Richard S. but have not heard back from him - anyone else here who > has admin access and can set me up again? > *.cluepon.net { nanog, cisco, juniper } still down for me... Rubens From nwarren at barryelectric.com Tue Jun 16 12:51:59 2015 From: nwarren at barryelectric.com (Nicholas Warren) Date: Tue, 16 Jun 2015 12:51:59 +0000 Subject: Greenfield ISP (In January) Message-ID: Does anyone beside Cisco do MAP? Brocade, Juniper, Huawei? Thank you, - Nich Warren -----Original Message----- From: Tore Anderson [mailto:tore at fud.no] Sent: Friday, June 12, 2015 12:15 AM To: Baldur Norddahl Cc: Nicholas Warren; nanog at nanog.org Subject: Re: Greenfield 464XLAT (In January) * Baldur Norddahl > The high tech solution is stuff like MAP where you move the cost out > to the CPE. But then you need to control the CPE - if you have that > then great. You would still want to sell a non-NAT (and MAP is NAT) to > users that require a public IPv4 address, so you still need to go dual > stack or use some tunnelling for that. Hi Baldur, MAP is *not* NAT; that's what's so neat about it. The users do get a public IPv4 address (or prefix!) routed to their CPE's WAN interface, towards which they can accept inbound unsolicited connections. The public IPv4 address could be port-restricted if the operator wants address sharing, but it does not have to be. You could do both at the same time, e.g., giving your "premium" users a /32 or /28, while the standard subscription includes a /32 with 4k ports. I will grant you that MAP-T performs NAT (i.e., protocol translation) internally, but the translations that happens when a packet enters the MAP domain are reversed when it exits. So the IPv4 addresses are transparent end-to-end. MAP-E (and lw4o6 for that matter), on the other hand, has no form of NAT anywhere. (Unless you count the NAPT44 that sits between the subscriber's RFC1918 LAN segment and the CPE's WAN interface, but that's not exactly something that's unique to MAP.) Nicholas: If I were you, before going down the 464XLAT route, I'd first look closely at these technologies, in the order given: 1) MAP (because it is fully stateless) 2) lw4o6 (because it is mostly stateless, i.e., no session tracking) 3) DS-Lite (which, like 464XLAT, is stateful, but you'll have way more CPEs to choose from than with 464XLAT, which is mostly for mobile) Tore From dj at techwebhosting.com Tue Jun 16 12:50:24 2015 From: dj at techwebhosting.com (DJ Anderson) Date: Tue, 16 Jun 2015 04:50:24 -0800 (AKDT) Subject: ZTE GPON Configuration In-Reply-To: <1584632242.907434.1434458961929.JavaMail.zimbra@techwebhosting.com> Message-ID: <494531690.907436.1434459024295.JavaMail.zimbra@techwebhosting.com> Good Morning All, I am not sure if this is the right place to ask this question or not, so here it goes. I am looking for someone that has experience programming a ZTE GPON OLT and setting up some ONU profiles to go with it. I have just about everything figured out except some issues with the sip configuration and updating things like the country code so that it plays the right dial tone. I guess really I am looking for a ZTE GPON expert. I am willing to pay for anyone's time I really just either need some CLI examples or just to pick someone's brain. Any help that could be provided is greatly appreciated. Please contact me off list. Thanks! DJ Anderson Techwebhosting.com dj at techwebhosting.com From woody at pch.net Tue Jun 16 16:43:26 2015 From: woody at pch.net (Bill Woodcock) Date: Tue, 16 Jun 2015 09:43:26 -0700 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: <3A7115BD-548B-4B8F-8AE5-AB9B42145FBB@pch.net> > On Jun 15, 2015, at 11:54 AM, William Herrin wrote: > I think you've offered some really bad advice here Bill. As I said, there are lots of people who _think_ it doesn?t work. And then there are people who?ve actually done it, and know better. Besides, you seem to not have read what I actually posted. In which the advice I gave was _not_ to do anycast TCP, so as to avoid having to deal with people who _think_ they know something, and are excessively verbal about it. Which is tedious. Perhaps better advice would have been to go ahead and do it, solving his problem, but to just not post to NANOG about it, so he doesn?t have to listen to people who think they know better telling him that what he?s doing isn?t possible. Bumblebees, flight, etc. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bill at herrin.us Tue Jun 16 17:12:27 2015 From: bill at herrin.us (William Herrin) Date: Tue, 16 Jun 2015 13:12:27 -0400 Subject: Anycast provider for SMTP? In-Reply-To: <3A7115BD-548B-4B8F-8AE5-AB9B42145FBB@pch.net> References: <3A7115BD-548B-4B8F-8AE5-AB9B42145FBB@pch.net> Message-ID: On Tue, Jun 16, 2015 at 12:43 PM, Bill Woodcock wrote: >> On Jun 15, 2015, at 11:54 AM, William Herrin wrote: >> I think you've offered some really bad advice here Bill. > > As I said, there are lots of people who _think_ it doesn?t work. And then > there are people who?ve actually done it, and know better. Uh huh. The numbers are clear: 99.99% of the time it works. The other 0.01% of the time you're screwed and had better pray the user is one of the ones you can afford to lose. Unicast TCP breaks too, but it has the virtue of being fixable 100% of the time. > Besides, you seem to not have read what I actually posted. In which > the advice I gave was _not_ to do anycast TCP, so as to avoid having > to deal with people who _think_ they know something Just because I rolled my eyes so hard my vision blurred doesn't mean I failed to read your comment. > Perhaps better advice would have been to go ahead and do it, > solving his problem, but to just not post to NANOG about it, > so he doesn?t have to listen to people who think they know > better telling him that what he?s doing isn?t possible. If you read what Joe wrote, he doesn't currently have an AS number or employ BGP with his Internet providers. Extrapolate for his IPv4 assignment situation and the /24 announcement barrier. In an IPv4-depleted world, he won't be doing anycast any time soon, even if it was a sound plan. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From woody at pch.net Tue Jun 16 17:55:51 2015 From: woody at pch.net (Bill Woodcock) Date: Tue, 16 Jun 2015 10:55:51 -0700 Subject: Anycast provider for SMTP? In-Reply-To: References: <3A7115BD-548B-4B8F-8AE5-AB9B42145FBB@pch.net> Message-ID: <82D10008-CB76-42C7-A78C-EE876924DF1E@pch.net> > If you read what Joe wrote, he doesn't currently have an AS number or > employ BGP with his Internet providers. Extrapolate for his IPv4 > assignment situation and the /24 announcement barrier. In an > IPv4-depleted world, he won't be doing anycast any time soon? ?which is one of the reasons why I suggested that he do anycast DNS (presumably using a DNS service provider) rather than anycast SMTP (presumably using himself) anyway. So, regardless of how much you?re rolling your eyes, we?re saying the same thing. We?re just being testy about the details. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From johnl at iecc.com Tue Jun 16 18:28:44 2015 From: johnl at iecc.com (John Levine) Date: 16 Jun 2015 18:28:44 -0000 Subject: Anycast provider for SMTP? In-Reply-To: Message-ID: <20150616182844.36134.qmail@ary.lan> >Uh huh. The numbers are clear: 99.99% of the time it works. The other >0.01% of the time you're screwed and had better pray the user is one >of the ones you can afford to lose. > >Unicast TCP breaks too, but it has the virtue of being fixable 100% of the time. I love the wry humor on the nanog list. R's, John PS: >If you read what Joe wrote, he doesn't currently have an AS number or >employ BGP with his Internet providers. Extrapolate for his IPv4 >assignment situation and the /24 announcement barrier. Assuming he has his own address space, why couldn't he just tell them what the IPs are and ask them to announce it, like any other customer does? From mohta at necom830.hpcl.titech.ac.jp Tue Jun 16 19:49:23 2015 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 17 Jun 2015 04:49:23 +0900 Subject: Anycast provider for SMTP? In-Reply-To: References: <3A7115BD-548B-4B8F-8AE5-AB9B42145FBB@pch.net> Message-ID: <55807DC3.6090702@necom830.hpcl.titech.ac.jp> William Herrin wrote: > If you read what Joe wrote, he doesn't currently have an AS number or > employ BGP with his Internet providers. Extrapolate for his IPv4 > assignment situation and the /24 announcement barrier. In an > IPv4-depleted world, he won't be doing anycast any time soon, even if > it was a sound plan. Anyone having /24 can start hosting business with 255*N anycast servers. Masataka Ohta From vwittkop at nanog.org Tue Jun 16 19:53:35 2015 From: vwittkop at nanog.org (Valerie Wittkop) Date: Tue, 16 Jun 2015 15:53:35 -0400 Subject: [NANOG-announce] NANOG On The Road Comes to Herndon!! Message-ID: <5306DE26-7537-4702-89A6-7E25E73CE720@nanog.org> We are very excited to be holding the next NOTR event in the great city of Herndon, VA next Tuesday, and we invite you to join us! Are you interested in Internet networking/peering? Do you work at a colocation, hosting or data center facility? Are you a provider of hardware/software solutions for the Internet industry? If so, the NANOG On The Road Herndon event is perfect for you! Date: June 23, 2015 Time: Registration Desk opens at 8:30am and Program is from 9:00 AM - 5:00 PM Location: Westin Dulles Airport Hotel - 2520 Wasser Terrace, Herndon, VA 20171 The FREE to attend event is open for registration. Register Now! The agenda is posted - topics to be discussed include: - Recent & Future Developments in DNS Security - International Network Supply, Traffic & Pricing - DNSSEC & RPKI - High fibre-coaxial networks - Optical Networking Tutorial - IPv6 Tutorial - BGP Tutorial If you are, or will be, in the Herndon area, we invite you to attend. And don?t forget to share the invitation with your colleagues or others you feel may benefit from attending. Make NANOG On The Road your first step toward learning how you can take the wheel and steer the future of the Internet. 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 Tel: +1 866 902 1336, ext 103 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From chuckchurch at gmail.com Tue Jun 16 20:04:50 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Tue, 16 Jun 2015 16:04:50 -0400 Subject: Unified Layer contact Message-ID: <03f601d0a86f$b54d1b70$1fe75250$@gmail.com> Anyone on here from Unified Layer? Having an issue with a small ISP I help out occasionally. Some of their IP Space can reach a hosted web server, but their other prefixes cannot reach the destination. Traceroute from working IP space to destination web server (a bank) : 15 162-144-240-55.unifiedlayer.com (162.144.240.55) [AS 46606] 68 msec 162-144-240-43.unifiedlayer.com (162.144.240.43) [AS 46606] 68 msec 68 msec 16 grandsouth.com (162.144.109.184) [AS 46606] 76 msec 76 msec 72 msec >From non-working IP space: 15 162-144-240-51.unifiedlayer.com (162.144.240.51) [AS 46606] 80 msec 162-144-240-43.unifiedlayer.com (162.144.240.43) [AS 46606] 80 msec 162-144-240-47.unifiedlayer.com (162.144.240.47) [AS 46606] 84 msec 16 * * * 17 * * * 18 * * * We're not a customer of Unified Layer whom the bank uses for hosting, not getting much help via normal channels. Thanks, Chuck From owen at delong.com Tue Jun 16 20:45:02 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 16 Jun 2015 13:45:02 -0700 Subject: Anycast provider for SMTP? In-Reply-To: <55807DC3.6090702@necom830.hpcl.titech.ac.jp> References: <3A7115BD-548B-4B8F-8AE5-AB9B42145FBB@pch.net> <55807DC3.6090702@necom830.hpcl.titech.ac.jp> Message-ID: <18C0FD70-FAF4-4305-8CBB-295AD46385C5@delong.com> > On Jun 16, 2015, at 12:49 , Masataka Ohta wrote: > > William Herrin wrote: > >> If you read what Joe wrote, he doesn't currently have an AS number or >> employ BGP with his Internet providers. Extrapolate for his IPv4 >> assignment situation and the /24 announcement barrier. In an >> IPv4-depleted world, he won't be doing anycast any time soon, even if >> it was a sound plan. > > Anyone having /24 can start hosting business with 255*N anycast servers. > > Masataka Ohta I don?t think that?s quite true? I think you will find that 254*N is probably the best theoretical Max with just a /24 and that more likely, you?ll need some hosts on that subnet that don?t necessarily provide anycast services bringing the practical limit somewhat lower. Of course, if you have what you need to do 255, you can probably actually do 256. Owen From jlewis at lewis.org Tue Jun 16 21:06:52 2015 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 16 Jun 2015 17:06:52 -0400 (EDT) Subject: Anycast provider for SMTP? In-Reply-To: <18C0FD70-FAF4-4305-8CBB-295AD46385C5@delong.com> References: <3A7115BD-548B-4B8F-8AE5-AB9B42145FBB@pch.net> <55807DC3.6090702@necom830.hpcl.titech.ac.jp> <18C0FD70-FAF4-4305-8CBB-295AD46385C5@delong.com> Message-ID: On Tue, 16 Jun 2015, Owen DeLong wrote: > >> On Jun 16, 2015, at 12:49 , Masataka Ohta wrote: >> >> William Herrin wrote: >> >>> If you read what Joe wrote, he doesn't currently have an AS number or >>> employ BGP with his Internet providers. Extrapolate for his IPv4 >>> assignment situation and the /24 announcement barrier. In an >>> IPv4-depleted world, he won't be doing anycast any time soon, even if >>> it was a sound plan. >> >> Anyone having /24 can start hosting business with 255*N anycast servers. >> >> Masataka Ohta > > > I don??t think that??s quite true?? I think you will find that 254*N is > probably the best theoretical Max with just a /24 and that more likely, > you??ll need some hosts on that subnet that don??t necessarily provide > anycast services bringing the practical limit somewhat lower. Of course, > if you have what you need to do 255, you can probably actually do 256. Advertise the /24, internally route 256 /32s to the devices that service those IPs on one or more networks numbered out of other IP ranges. The machines all need unique unicast IPs anyway. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rblayzor.bulk at inoc.net Tue Jun 16 23:57:50 2015 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Tue, 16 Jun 2015 19:57:50 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: On Jun 15, 2015, at 1:50 PM, Joe Hamelin wrote: > > I have a mail system where there are two MX hosts, one in the US and one in > Europe. Both have a DNS MX record metric of 10 so a bastardized > round-robin takes place. This does not work so well when one site goes > down. My solution will be to place a load balancer in a hosting site > (virtual, of course) and have it provide HA. But what about HA for the > LB? At first glance anycasting would seem to be a great idea but there is > a problem of broken sessions when routes change. > > Have any of you seen something like this work in the wild? F5 GTM? Depending on what your DNS volume is you could probably get away with a couple of virtual appliances? -- Robert inoc.net!rblayzor Jabber: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu From bill at herrin.us Wed Jun 17 02:12:58 2015 From: bill at herrin.us (William Herrin) Date: Tue, 16 Jun 2015 22:12:58 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: On Mon, Jun 15, 2015 at 5:08 PM, Joe Hamelin wrote: > It seems to be more of a last-mile backhoe fade issue right now. I'm > trying to convince them that a manufacturing facility isn't a good place > for a data center. Backhoes seem to have gotten you for a day or so now. My mail to you is deferred on my server and: nslookup -q=mx nethead.com Server: 192.168.99.1 Address: 192.168.99.1#53 Non-authoritative answer: nethead.com mail exchanger = 10 tulalip.us. nethead.com mail exchanger = 0 hamelin.us. telnet hamelin.us. 25 Trying 208.71.161.175... Connection failed: No route to host traceroute -T -p 25 hamelin.us. traceroute to hamelin.us. (208.71.161.175), 30 hops max, 60 byte packets 1 lo0-100.WASHDC-VFTTP-312.verizon-gni.net (71.246.241.1) 1.091 ms 1.127 ms 1.442 ms 2 T1-3-0-4.WASHDC-LCR-22.verizon-gni.net (130.81.221.218) 3.869 ms T2-9-0-13.WASHDC-LCR-22.verizon-gni.net (100.41.137.158) 5.005 ms T2-9-0-13.WASHDC-LCR-21.verizon-gni.net (100.41.137.88) 5.651 ms 3 * * * 4 0.ae3.BR2.IAD8.ALTER.NET (140.222.227.195) 6.399 ms 6.578 ms 6.668 ms 5 204.255.168.226 (204.255.168.226) 5.324 ms 5.744 ms 6.168 ms 6 207.88.14.162.ptr.us.xo.net (207.88.14.162) 79.304 ms 74.726 ms 75.877 ms 7 vb6.rar3.chicago-il.us.xo.net (207.88.12.33) 72.258 ms 75.141 ms 72.125 ms 8 te-4-1-0.rar3.denver-co.us.xo.net (207.88.12.22) 74.619 ms 74.544 ms 74.475 ms 9 te-3-0-0.rar3.seattle-wa.us.xo.net (207.88.12.81) 78.125 ms 78.264 ms 77.969 ms 10 ae0d0.cir1.seattle7-wa.us.xo.net (207.88.13.141) 74.881 ms 76.052 ms 76.469 ms 11 216.156.100.146.ptr.us.xo.net (216.156.100.146) 89.162 ms 88.563 ms 89.005 ms 12 cr2-sea-b-te-0-0-0-9.bb.spectrumnet.us (174.127.140.158) 85.827 ms cr2-sea-b-te-0-0-0-8.bb.spectrumnet.us (174.127.140.154) 86.021 ms 85.414 ms 13 cr1-bds-te-0-0-0-1.bb.spectrumnet.us (174.127.138.123) 88.308 ms cr1-bds-te-0-0-0-3.bb.spectrumnet.us (174.127.138.127) 86.834 ms cr1-bds-te-0-0-0-1.bb.spectrumnet.us (174.127.138.123) 87.826 ms 14 TulalipTribes-1000M-BDS.demarc.spectrumnet.us (216.243.26.98) 88.101 ms 87.321 ms 88.475 ms 15 * 208.83.58.225 (208.83.58.225) 88.298 ms 88.084 ms 16 74.112.52.200 (74.112.52.200) 87.485 ms 86.812 ms 86.365 ms 17 host-208-71-161-250.tulalipbroadband.com (208.71.161.250) 86.317 ms 86.103 ms 86.366 ms 18 host-208-71-161-175.tulalip.us (208.71.161.175) 108.818 ms 108.118 ms 107.581 ms 19 host-208-71-161-175.tulalip.us (208.71.161.175) 2605.488 ms !H 2617.132 ms !H * -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From marka at isc.org Wed Jun 17 02:50:11 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 17 Jun 2015 12:50:11 +1000 Subject: Anycast provider for SMTP? In-Reply-To: Your message of "Tue, 16 Jun 2015 10:55:51 -0700." <82D10008-CB76-42C7-A78C-EE876924DF1E@pch.net> References: <3A7115BD-548B-4B8F-8AE5-AB9B42145FBB@pch.net> <82D10008-CB76-42C7-A78C-EE876924DF1E@pch.net> Message-ID: <20150617025011.14B5030CC767@rock.dv.isc.org> In message <82D10008-CB76-42C7-A78C-EE876924DF1E at pch.net>, Bill Woodcock writes: > > > If you read what Joe wrote, he doesn't currently have an AS number or > > employ BGP with his Internet providers. Extrapolate for his IPv4 > > assignment situation and the /24 announcement barrier. In an > > IPv4-depleted world, he won't be doing anycast any time soon??? > > ???which is one of the reasons why I suggested that he do anycast DNS > (presumably using a DNS service provider) rather than anycast SMTP > (presumably using himself) anyway. > > So, regardless of how much you???re rolling your eyes, we???re saying the > same thing. We???re just being testy about the details. > > -Bill If you are that worried about a anycast SMTP/TCP session breaking, you will be just as worried about a anycast DNS/TCP session breaking. That said the problem is that a client SMTP server doesn't retry fast enough when a TCP session breaks mid transaction. Anycast TCP will not fix this. I'm not aware of any SMTP client that takes 4 hours to try the next MX when connect fails and it was a 4 hour retry that was the complaint. Anycast will only help if the SMTP client doesn't try all the lowest cost MX's and there are very few broken SMTP clients that do this. The best fix for these is to identify the clients and get them upgraded to something that is RFC compliant. Trying multiple MXs is a 20+ year old requirement. Basically you are wasting your money on anycast SMTP. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rafael at gav.ufsc.br Wed Jun 17 04:02:40 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Tue, 16 Jun 2015 23:02:40 -0500 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: Any luck on a DNS based solution? On Mon, Jun 15, 2015 at 12:50 PM, Joe Hamelin wrote: > I have a mail system where there are two MX hosts, one in the US and one in > Europe. Both have a DNS MX record metric of 10 so a bastardized > round-robin takes place. This does not work so well when one site goes > down. My solution will be to place a load balancer in a hosting site > (virtual, of course) and have it provide HA. But what about HA for the > LB? At first glance anycasting would seem to be a great idea but there is > a problem of broken sessions when routes change. > > Have any of you seen something like this work in the wild? > > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > From joe at nethead.com Wed Jun 17 04:36:43 2015 From: joe at nethead.com (Joe Hamelin) Date: Tue, 16 Jun 2015 21:36:43 -0700 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: On Tue, Jun 16, 2015 at 9:02 PM, Rafael Possamai wrote: > Any luck on a DNS based solution? > I'm looking into a F5 GTM solution based out of a colo we have in Europe to direct SMTP between France and the US hubs. Now I just have to work layers 8 & 9. Remember when users didn't expect sub-minute delivery times? Thanks for everyone's help, you've give me a lot of good ideas to consider and I've learned more than I ever thought I would about anycast. Although I'm not on the BGP end of things anymore I value the minds, personalities and pure history that NANOG brings. Total side note: I remember back at a NANOG in Atlanta, 2000 maybe, at a BOF on ARIN allocations where I was arguing for netblocks less than a /21 because Amazon couldn't justify that much at that time, I mean we only had one public site but still wanted to multi-home. I remember Randy Bush even backed me up on that one. In the end I did get a block for Amazon and brought up BGP. Oh how times have changed (and how I wish I still had those stock options!) Best regards, Joe (ex JH484) -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > From mpalmer at hezmatt.org Tue Jun 16 01:26:27 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Tue, 16 Jun 2015 11:26:27 +1000 Subject: Anycast provider for SMTP? In-Reply-To: References: <557F1948.6080506@foobar.org> Message-ID: <20150616012627.GL16961@hezmatt.org> On Mon, Jun 15, 2015 at 05:07:22PM -0700, Dave Taht wrote: > On Mon, Jun 15, 2015 at 5:00 PM, Randy Bush wrote: > >> "What about IPv6? We have a plan! We plan to be dead before customers > >> demand IPv6". > >> I am pretty sure the authors are still alive(?). > > > > and customer demand for ipv6 still holds strong, right? > > Does seem to be on the uptick! It's certainly stronger than it has *ever* been before. - Matt -- I am cow, hear me moo, I weigh twice as much as you. I'm a cow, eating grass, methane gas comes out my ass. I'm a cow, you are too; join us all! Type apt-get moo. From maqbool at madbull.info Wed Jun 17 08:44:34 2015 From: maqbool at madbull.info (Maqbool Hashim) Date: Wed, 17 Jun 2015 08:44:34 +0000 Subject: Fkiws with destination port 0 and TCP SYN flag set Message-ID: Hi, I am doing some flow analysis within our network primarily for understanding application flows to aid in network segregation activity and mainly understand what is going on inside the network. To do this I have been using netflow where the switches/firewalls support it. In some cases I have used a monitor port and fed full packet capture into the nfdump toolset for conversion into flows. There is a portion of our network where the switches only support sflow which is not ideal, but hopefully will be able to gather enough data over time to be useful. One of the things I was trying to identify was flow initiation, i.e. the client and server in the flow- so filtered for TCP packets with SYN flag set. It was at this point that I saw TCP SYN packets with a destination port of 0. I have seen this discussed before in this thread http://www.gossamer-threads.com/lists/nanog/users/155141 It was stated in that thread that netflow reports source/dest port 0 for non-initial fragments. My question was is this what I am seeing here, so any SYN packet with dest port 0 is a non-initial fragment seen by the tool? Therefore should I always see a corresponding response with Ack and Reset flags set? I do see a set of flows with R and A set with a source port of 0, all the dest port 0 flows have the SYN flag set, but it's hard to find ones that match a SYN packet due to only receiving a sample of flows. Some notes on the setup: Capture is from inside one VLAN Switches are sending sflow back to analysis tools, sampling rate of 1/1024 packets Using nfdump suite of tools for analysis. sfcapd as as the collector Thinking about this, is what I am seeing a symptom of the fact that the tools don't see all packets, i.e. the tools don't see the initial fragment due to sampling. However I still don't quite understand it appearing with the SYN flag set? I am starting to think that for these purposes I might be better abandoning sflow and go with setting up collectors on the switches to get full flow information for my purposes. Any clarification/input much appreciated. Regards MH From rdobbins at arbor.net Wed Jun 17 09:07:58 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 17 Jun 2015 11:07:58 +0200 Subject: Fkiws with destination port 0 and TCP SYN flag set In-Reply-To: References: Message-ID: <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> On 17 Jun 2015, at 10:44, Maqbool Hashim wrote: > It was stated in that thread that netflow reports source/dest port 0 > for non-initial fragments. Fragmentation in this context only applies to UDP packets. If the destination of a TCP SYN is being reported as 0 (what's the source port?), either it's a reporting artifact of some kind or in fact a SYN destined to TCP/0 (we see this with SYN-floods, sometimes, as well as with attacks attempting to bypass ACL/firewall rules and related to compromise). ----------------------------------- Roland Dobbins From maqbool at madbull.info Wed Jun 17 09:23:55 2015 From: maqbool at madbull.info (Maqbool Hashim) Date: Wed, 17 Jun 2015 09:23:55 +0000 Subject: Fkiws with destination port 0 and TCP SYN flag set In-Reply-To: <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> References: , <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> Message-ID: Hi Thanks for the response. There are lots of different source ports all above 10,000 (e.g. 42628,42927,39050). It is always two redhat machines generating the traffic, can't be 100% sure due to the sampling but pretty sure the capture has been running for 24 hours or so. It is always the same destination servers and in normal operations these source and destination hosts do have a bunch of legitimate flows between them. I was leaning towards it being a reporting artifact, but it's interesting that there are a whole set of Ack Reset packets from the destination hosts with a source port of 0 also. Does this not indicate that it probably isn't a reporting artifact? Maybe I need to setup collectors and span ports on all the switches involved to get to the bottom of this. Just feeling like we need to look at *all* the packets not the sample! Regards, MH ________________________________________ From: NANOG on behalf of Roland Dobbins Sent: 17 June 2015 10:07 To: nanog at nanog.org Subject: Re: Fkiws with destination port 0 and TCP SYN flag set On 17 Jun 2015, at 10:44, Maqbool Hashim wrote: > It was stated in that thread that netflow reports source/dest port 0 > for non-initial fragments. Fragmentation in this context only applies to UDP packets. If the destination of a TCP SYN is being reported as 0 (what's the source port?), either it's a reporting artifact of some kind or in fact a SYN destined to TCP/0 (we see this with SYN-floods, sometimes, as well as with attacks attempting to bypass ACL/firewall rules and related to compromise). ----------------------------------- Roland Dobbins From saper at saper.info Wed Jun 17 09:30:47 2015 From: saper at saper.info (Marcin Cieslak) Date: Wed, 17 Jun 2015 09:30:47 +0000 Subject: Fkiws with destination port 0 and TCP SYN flag set In-Reply-To: References: , <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> Message-ID: On Wed, 17 Jun 2015, Maqbool Hashim wrote: > It is always the same destination servers and in normal operations > these source and destination hosts do have a bunch of legitimate flows > between them. I was leaning towards it being a reporting artifact, > but it's interesting that there are a whole set of Ack Reset packets > from the destination hosts with a source port of 0 also. So the destination host is sending ACK+RST with the *source* port set to zero, or the *destination* port? > Does this not indicate that it probably isn't a reporting artifact? I would just tcpdump on one of the source machines to find out. ~Marcin From rdobbins at arbor.net Wed Jun 17 09:33:34 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 17 Jun 2015 11:33:34 +0200 Subject: Fkiws with destination port 0 and TCP SYN flag set In-Reply-To: References: <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> Message-ID: On 17 Jun 2015, at 11:23, Maqbool Hashim wrote: > Maybe I need to setup collectors and span ports on all the switches > involved to get to the bottom of this. Just feeling like we need to > look at *all* the packets not the sample! Concur 100%. ----------------------------------- Roland Dobbins From maqbool at madbull.info Wed Jun 17 09:34:46 2015 From: maqbool at madbull.info (Maqbool Hashim) Date: Wed, 17 Jun 2015 09:34:46 +0000 Subject: Fkiws with destination port 0 and TCP SYN flag set In-Reply-To: References: , <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> , Message-ID: Hi, The destination host is sending an ACK+RST with the source port set to zero. The destination IP is always one of the two hosts that are generating the SYN packets with a destination port of 0. The destination port however is hard to match up to a source port in the original SYN packet due to the fact that we don't have all the packets. It's actually going to be difficult to get the access and procedural sign off etc. to run tcpdump on the machines involved. What might be easier is to set up a span port for the hosts access port on the switch and grab that via the collector laptop I have. Thanks, MH ________________________________________ From: Marcin Cieslak Sent: 17 June 2015 10:30 To: Maqbool Hashim Cc: nanog at nanog.org Subject: Re: Fkiws with destination port 0 and TCP SYN flag set On Wed, 17 Jun 2015, Maqbool Hashim wrote: > It is always the same destination servers and in normal operations > these source and destination hosts do have a bunch of legitimate flows > between them. I was leaning towards it being a reporting artifact, > but it's interesting that there are a whole set of Ack Reset packets > from the destination hosts with a source port of 0 also. So the destination host is sending ACK+RST with the *source* port set to zero, or the *destination* port? > Does this not indicate that it probably isn't a reporting artifact? I would just tcpdump on one of the source machines to find out. ~Marcin From pavel.odintsov at gmail.com Wed Jun 17 09:44:01 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 17 Jun 2015 12:44:01 +0300 Subject: Fkiws with destination port 0 and TCP SYN flag set In-Reply-To: References: <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> Message-ID: Hello! Looks like it's silly hping3 flood: 12:43:08.961024 IP 192.168.0.127.10562 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961031 IP 192.168.0.127.10563 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961039 IP 192.168.0.127.10564 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961046 IP 192.168.0.127.10565 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961054 IP 192.168.0.127.10566 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961062 IP 192.168.0.127.10567 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961070 IP 192.168.0.127.10568 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961077 IP 192.168.0.127.10569 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961085 IP 192.168.0.127.10570 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961093 IP 192.168.0.127.10571 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961101 IP 192.168.0.127.10572 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961108 IP 192.168.0.127.10573 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961116 IP 192.168.0.127.10574 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961123 IP 192.168.0.127.10575 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961131 IP 192.168.0.127.10576 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961139 IP 192.168.0.127.10577 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961146 IP 192.168.0.127.10578 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961154 IP 192.168.0.127.10579 > 216.239.32.21.0: Flags [.], win 512, length 0 Just try: hping3 --flood target_host. On Wed, Jun 17, 2015 at 12:34 PM, Maqbool Hashim wrote: > Hi, > > The destination host is sending an ACK+RST with the source port set to zero. The destination IP is always one of the two hosts that are generating the SYN packets with a destination port of 0. The destination port however is hard to match up to a source port in the original SYN packet due to the fact that we don't have all the packets. > > It's actually going to be difficult to get the access and procedural sign off etc. to run tcpdump on the machines involved. What might be easier is to set up a span port for the hosts access port on the switch and grab that via the collector laptop I have. > > Thanks, > > MH > > ________________________________________ > From: Marcin Cieslak > Sent: 17 June 2015 10:30 > To: Maqbool Hashim > Cc: nanog at nanog.org > Subject: Re: Fkiws with destination port 0 and TCP SYN flag set > > On Wed, 17 Jun 2015, Maqbool Hashim wrote: > >> It is always the same destination servers and in normal operations >> these source and destination hosts do have a bunch of legitimate flows >> between them. I was leaning towards it being a reporting artifact, >> but it's interesting that there are a whole set of Ack Reset packets >> from the destination hosts with a source port of 0 also. > > So the destination host is sending ACK+RST with the *source* port > set to zero, or the *destination* port? > >> Does this not indicate that it probably isn't a reporting artifact? > > I would just tcpdump on one of the source machines to find out. > > ~Marcin -- Sincerely yours, Pavel Odintsov From rdobbins at arbor.net Wed Jun 17 09:44:52 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 17 Jun 2015 11:44:52 +0200 Subject: Fkiws with destination port 0 and TCP SYN flag set In-Reply-To: References: <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> Message-ID: <31EA52D2-44FE-4F51-BCFC-E6BF6E9B36B6@arbor.net> On 17 Jun 2015, at 11:34, Maqbool Hashim wrote: > What might be easier is to set up a span port for the hosts access > port on the switch and grab that via the collector laptop I have. It's better to collect as much information you have without perturbing the systems involved, anyways. ----------------------------------- Roland Dobbins From maqbool at madbull.info Wed Jun 17 09:50:54 2015 From: maqbool at madbull.info (Maqbool Hashim) Date: Wed, 17 Jun 2015 09:50:54 +0000 Subject: Fkiws with destination port 0 and TCP SYN flag set In-Reply-To: References: <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> , Message-ID: Hmm, no flags set in your output though? ________________________________________ From: Pavel Odintsov Sent: 17 June 2015 10:44 To: Maqbool Hashim Cc: Marcin Cieslak; nanog at nanog.org Subject: Re: Fkiws with destination port 0 and TCP SYN flag set Hello! Looks like it's silly hping3 flood: 12:43:08.961024 IP 192.168.0.127.10562 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961031 IP 192.168.0.127.10563 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961039 IP 192.168.0.127.10564 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961046 IP 192.168.0.127.10565 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961054 IP 192.168.0.127.10566 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961062 IP 192.168.0.127.10567 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961070 IP 192.168.0.127.10568 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961077 IP 192.168.0.127.10569 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961085 IP 192.168.0.127.10570 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961093 IP 192.168.0.127.10571 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961101 IP 192.168.0.127.10572 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961108 IP 192.168.0.127.10573 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961116 IP 192.168.0.127.10574 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961123 IP 192.168.0.127.10575 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961131 IP 192.168.0.127.10576 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961139 IP 192.168.0.127.10577 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961146 IP 192.168.0.127.10578 > 216.239.32.21.0: Flags [.], win 512, length 0 12:43:08.961154 IP 192.168.0.127.10579 > 216.239.32.21.0: Flags [.], win 512, length 0 Just try: hping3 --flood target_host. On Wed, Jun 17, 2015 at 12:34 PM, Maqbool Hashim wrote: > Hi, > > The destination host is sending an ACK+RST with the source port set to zero. The destination IP is always one of the two hosts that are generating the SYN packets with a destination port of 0. The destination port however is hard to match up to a source port in the original SYN packet due to the fact that we don't have all the packets. > > It's actually going to be difficult to get the access and procedural sign off etc. to run tcpdump on the machines involved. What might be easier is to set up a span port for the hosts access port on the switch and grab that via the collector laptop I have. > > Thanks, > > MH > > ________________________________________ > From: Marcin Cieslak > Sent: 17 June 2015 10:30 > To: Maqbool Hashim > Cc: nanog at nanog.org > Subject: Re: Fkiws with destination port 0 and TCP SYN flag set > > On Wed, 17 Jun 2015, Maqbool Hashim wrote: > >> It is always the same destination servers and in normal operations >> these source and destination hosts do have a bunch of legitimate flows >> between them. I was leaning towards it being a reporting artifact, >> but it's interesting that there are a whole set of Ack Reset packets >> from the destination hosts with a source port of 0 also. > > So the destination host is sending ACK+RST with the *source* port > set to zero, or the *destination* port? > >> Does this not indicate that it probably isn't a reporting artifact? > > I would just tcpdump on one of the source machines to find out. > > ~Marcin -- Sincerely yours, Pavel Odintsov From pavel.odintsov at gmail.com Wed Jun 17 09:52:24 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 17 Jun 2015 12:52:24 +0300 Subject: Fkiws with destination port 0 and TCP SYN flag set In-Reply-To: References: <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> Message-ID: Hello! Just add --syn flag: 12:51:51.150085 IP 192.168.0.127.14628 > 216.239.34.21.0: Flags [S], seq 680218921, win 512, length 0 12:51:51.150092 IP 192.168.0.127.14629 > 216.239.34.21.0: Flags [S], seq 2073100941, win 512, length 0 12:51:51.150100 IP 192.168.0.127.14630 > 216.239.34.21.0: Flags [S], seq 1003157405, win 512, length 0 12:51:51.150108 IP 192.168.0.127.14631 > 216.239.34.21.0: Flags [S], seq 466773687, win 512, length 0 12:51:51.150115 IP 192.168.0.127.14632 > 216.239.34.21.0: Flags [S], seq 338869897, win 512, length 0 12:51:51.150123 IP 192.168.0.127.14633 > 216.239.34.21.0: Flags [S], seq 1513724122, win 512, length 0 12:51:51.150130 IP 192.168.0.127.14634 > 216.239.34.21.0: Flags [S], seq 1971827612, win 512, length 0 12:51:51.150138 IP 192.168.0.127.14635 > 216.239.34.21.0: Flags [S], seq 168197290, win 512, length 0 12:51:51.150146 IP 192.168.0.127.14636 > 216.239.34.21.0: Flags [S], seq 1079714921, win 512, length 0 12:51:51.150153 IP 192.168.0.127.14637 > 216.239.34.21.0: Flags [S], seq 1634213253, win 512, length 0 12:51:51.150161 IP 192.168.0.127.14638 > 216.239.34.21.0: Flags [S], seq 1220755012, win 512, length 0 12:51:51.150168 IP 192.168.0.127.14639 > 216.239.34.21.0: Flags [S], seq 351031228, win 512, length 0 12:51:51.150176 IP 192.168.0.127.14640 > 216.239.34.21.0: Flags [S], seq 286599236, win 512, length 0 12:51:51.150184 IP 192.168.0.127.14641 > 216.239.34.21.0: Flags [S], seq 125907752, win 512, length 0 hping3 --flood --syn host.com On Wed, Jun 17, 2015 at 12:50 PM, Maqbool Hashim wrote: > Hmm, no flags set in your output though? > > ________________________________________ > From: Pavel Odintsov > Sent: 17 June 2015 10:44 > To: Maqbool Hashim > Cc: Marcin Cieslak; nanog at nanog.org > Subject: Re: Fkiws with destination port 0 and TCP SYN flag set > > Hello! > > Looks like it's silly hping3 flood: > > 12:43:08.961024 IP 192.168.0.127.10562 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961031 IP 192.168.0.127.10563 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961039 IP 192.168.0.127.10564 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961046 IP 192.168.0.127.10565 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961054 IP 192.168.0.127.10566 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961062 IP 192.168.0.127.10567 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961070 IP 192.168.0.127.10568 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961077 IP 192.168.0.127.10569 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961085 IP 192.168.0.127.10570 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961093 IP 192.168.0.127.10571 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961101 IP 192.168.0.127.10572 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961108 IP 192.168.0.127.10573 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961116 IP 192.168.0.127.10574 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961123 IP 192.168.0.127.10575 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961131 IP 192.168.0.127.10576 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961139 IP 192.168.0.127.10577 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961146 IP 192.168.0.127.10578 > 216.239.32.21.0: Flags [.], > win 512, length 0 > 12:43:08.961154 IP 192.168.0.127.10579 > 216.239.32.21.0: Flags [.], > win 512, length 0 > > Just try: > hping3 --flood target_host. > > On Wed, Jun 17, 2015 at 12:34 PM, Maqbool Hashim wrote: >> Hi, >> >> The destination host is sending an ACK+RST with the source port set to zero. The destination IP is always one of the two hosts that are generating the SYN packets with a destination port of 0. The destination port however is hard to match up to a source port in the original SYN packet due to the fact that we don't have all the packets. >> >> It's actually going to be difficult to get the access and procedural sign off etc. to run tcpdump on the machines involved. What might be easier is to set up a span port for the hosts access port on the switch and grab that via the collector laptop I have. >> >> Thanks, >> >> MH >> >> ________________________________________ >> From: Marcin Cieslak >> Sent: 17 June 2015 10:30 >> To: Maqbool Hashim >> Cc: nanog at nanog.org >> Subject: Re: Fkiws with destination port 0 and TCP SYN flag set >> >> On Wed, 17 Jun 2015, Maqbool Hashim wrote: >> >>> It is always the same destination servers and in normal operations >>> these source and destination hosts do have a bunch of legitimate flows >>> between them. I was leaning towards it being a reporting artifact, >>> but it's interesting that there are a whole set of Ack Reset packets >>> from the destination hosts with a source port of 0 also. >> >> So the destination host is sending ACK+RST with the *source* port >> set to zero, or the *destination* port? >> >>> Does this not indicate that it probably isn't a reporting artifact? >> >> I would just tcpdump on one of the source machines to find out. >> >> ~Marcin > > > > -- > Sincerely yours, Pavel Odintsov -- Sincerely yours, Pavel Odintsov From maqbool at madbull.info Wed Jun 17 09:54:21 2015 From: maqbool at madbull.info (Maqbool Hashim) Date: Wed, 17 Jun 2015 09:54:21 +0000 Subject: Fkiws with destination port 0 and TCP SYN flag set In-Reply-To: <31EA52D2-44FE-4F51-BCFC-E6BF6E9B36B6@arbor.net> References: <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> , <31EA52D2-44FE-4F51-BCFC-E6BF6E9B36B6@arbor.net> Message-ID: Agreed. Might see if I can get netstat -antp output from the operators at some point though. I will start with one of the hosts, looks like the whole flow capturing exercise for this LAN will need to be done using multiple laptops connected to the different access ports for the hosts. No RSPAN support on these switches and no netflow :( ________________________________________ From: NANOG on behalf of Roland Dobbins Sent: 17 June 2015 10:44 To: nanog at nanog.org Subject: Re: Fkiws with destination port 0 and TCP SYN flag set On 17 Jun 2015, at 11:34, Maqbool Hashim wrote: > What might be easier is to set up a span port for the hosts access > port on the switch and grab that via the collector laptop I have. It's better to collect as much information you have without perturbing the systems involved, anyways. ----------------------------------- Roland Dobbins From maqbool at madbull.info Wed Jun 17 11:56:04 2015 From: maqbool at madbull.info (Maqbool Hashim) Date: Wed, 17 Jun 2015 11:56:04 +0000 Subject: Fkiws with destination port 0 and TCP SYN flag set In-Reply-To: References: <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> , <31EA52D2-44FE-4F51-BCFC-E6BF6E9B36B6@arbor.net>, Message-ID: So, progressed to grabbing full packet dumps via monitor ports. This confirmed that indeed the two hosts in question are generating traffic to the same four destinations with a destination port of zero. Now that I have a full packet dump I see reset + ack packets coming back from source port 0 for every single one of the initial SYN packets. Also it does look like a "scan" of some sort as the source port numbers are increasing by two or three every time and roughly 3-4 SYN packets per second being sent. I am guessing this would be process binding to the next available TCP port on the source machine. As far as I can tell to progress the analysis I need to move to doing forensics on the host itself. It could be (as Pavel pointed out) be a utility like hping3 that someone has left running and forgotten about. On the other hand it could be something more malicious I just don't know at the moment. Any advice on this aspect would be great, unless considered off topic. Finally I don't see how it could be, but be interested to hear peoples thoughts, no legitimate application could be generating this traffic could it? I mean I don't see what use an application could make of such a TCP conversation. Discarding network analysis etc. This machine runs a whole host of proprietary control system protocols, so haven't discarded the possibility totally- but I just can't see what an application protocol could find useful in a bunch of reset + ack packets being received from the destination hosts. Regards, MH ________________________________________ From: NANOG on behalf of Maqbool Hashim Sent: 17 June 2015 10:54 To: Roland Dobbins; nanog at nanog.org Subject: Re: Fkiws with destination port 0 and TCP SYN flag set Agreed. Might see if I can get netstat -antp output from the operators at some point though. I will start with one of the hosts, looks like the whole flow capturing exercise for this LAN will need to be done using multiple laptops connected to the different access ports for the hosts. No RSPAN support on these switches and no netflow :( ________________________________________ From: NANOG on behalf of Roland Dobbins Sent: 17 June 2015 10:44 To: nanog at nanog.org Subject: Re: Fkiws with destination port 0 and TCP SYN flag set On 17 Jun 2015, at 11:34, Maqbool Hashim wrote: > What might be easier is to set up a span port for the hosts access > port on the switch and grab that via the collector laptop I have. It's better to collect as much information you have without perturbing the systems involved, anyways. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Wed Jun 17 13:21:20 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 17 Jun 2015 15:21:20 +0200 Subject: Fkiws with destination port 0 and TCP SYN flag set In-Reply-To: References: <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> <31EA52D2-44FE-4F51-BCFC-E6BF6E9B36B6@arbor.net> Message-ID: On 17 Jun 2015, at 13:56, Maqbool Hashim wrote: > Any advice on this aspect would be great, unless considered off topic. NANOG isn't really the right alias for this sort of thing. TCP port-scanning on TCP/0 is a common reconnaissance mechanism. Suggest you take this to a more appropriate alias like one of the bugtraq lists. ----------------------------------- Roland Dobbins From rafael at gav.ufsc.br Wed Jun 17 13:23:12 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Wed, 17 Jun 2015 08:23:12 -0500 Subject: Anycast provider for SMTP? In-Reply-To: <20150616012627.GL16961@hezmatt.org> References: <557F1948.6080506@foobar.org> <20150616012627.GL16961@hezmatt.org> Message-ID: https://www.google.com/intl/en/ipv6/statistics.html On Mon, Jun 15, 2015 at 8:26 PM, Matt Palmer wrote: > On Mon, Jun 15, 2015 at 05:07:22PM -0700, Dave Taht wrote: > > On Mon, Jun 15, 2015 at 5:00 PM, Randy Bush wrote: > > >> "What about IPv6? We have a plan! We plan to be dead before customers > > >> demand IPv6". > > >> I am pretty sure the authors are still alive(?). > > > > > > and customer demand for ipv6 still holds strong, right? > > > > Does seem to be on the uptick! > > It's certainly stronger than it has *ever* been before. > > - Matt > > -- > I am cow, hear me moo, I weigh twice as much as you. I'm a cow, eating > grass, methane gas comes out my ass. I'm a cow, you are too; join us all! > Type apt-get moo. > > From mlm at pixelgate.net Wed Jun 17 14:05:17 2015 From: mlm at pixelgate.net (Mark Milhollan) Date: Wed, 17 Jun 2015 07:05:17 -0700 (PDT) Subject: Fkiws with destination port 0 and TCP SYN flag set In-Reply-To: References: <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> , <31EA52D2-44FE-4F51-BCFC-E6BF6E9B36B6@arbor.net>, Message-ID: On Wed, 17 Jun 2015, Maqbool Hashim wrote: >Finally I don't see how it could be, but be interested to hear peoples >thoughts, no legitimate application could be generating this traffic >could it? I mean I don't see what use an application could make of >such a TCP conversation. Discarding network analysis etc. This >machine runs a whole host of proprietary control system protocols, so >haven't discarded the possibility totally- but I just can't see what an >application protocol could find useful in a bunch of reset + ack >packets being received from the destination hosts. Okay, setting aside the malicious possibilities, it may be that someone felt they needed something like ping but without the need for a raw socket. I would worry about such code as there is usually sufficient proof the host is alive due to ongoing or new sessions. Still, in process control it may be reasonable to check aliveness if, for example, there has been no normal activity for a seemingly small period of time, e.g., 50ms. Such a test is only sufficient to prove that the TCP stack will respond, not the programs (which is where aliveness within the protocols is far more useful, classically PING and PONG). Or perhaps a fence-post bug, e.g., a program is doing its own port selection with a max of 65535 where it accidentally uses max+1 which for a 16 bit unsigned value turns out to be 0, i.e., fixing the port number (setting it to the min value) after it is used rather than before. /mark From maqbool at madbull.info Wed Jun 17 14:15:01 2015 From: maqbool at madbull.info (Maqbool Hashim) Date: Wed, 17 Jun 2015 14:15:01 +0000 Subject: Fkiws with destination port 0 and TCP SYN flag set In-Reply-To: References: <93440109-3E24-419F-9110-EF43FDCF418E@arbor.net> , <31EA52D2-44FE-4F51-BCFC-E6BF6E9B36B6@arbor.net>, , Message-ID: Hi, I'm investigating some of the protocols and will start looking at the processes on the machines. Someone else rightly pointed out this getting off topic for NANOG, so thanks to everyone that responded. Regards, MH ________________________________________ From: NANOG on behalf of Mark Milhollan Sent: 17 June 2015 15:05 To: NANOG list Subject: Re: Fkiws with destination port 0 and TCP SYN flag set On Wed, 17 Jun 2015, Maqbool Hashim wrote: >Finally I don't see how it could be, but be interested to hear peoples >thoughts, no legitimate application could be generating this traffic >could it? I mean I don't see what use an application could make of >such a TCP conversation. Discarding network analysis etc. This >machine runs a whole host of proprietary control system protocols, so >haven't discarded the possibility totally- but I just can't see what an >application protocol could find useful in a bunch of reset + ack >packets being received from the destination hosts. Okay, setting aside the malicious possibilities, it may be that someone felt they needed something like ping but without the need for a raw socket. I would worry about such code as there is usually sufficient proof the host is alive due to ongoing or new sessions. Still, in process control it may be reasonable to check aliveness if, for example, there has been no normal activity for a seemingly small period of time, e.g., 50ms. Such a test is only sufficient to prove that the TCP stack will respond, not the programs (which is where aliveness within the protocols is far more useful, classically PING and PONG). Or perhaps a fence-post bug, e.g., a program is doing its own port selection with a max of 65535 where it accidentally uses max+1 which for a 16 bit unsigned value turns out to be 0, i.e., fixing the port number (setting it to the min value) after it is used rather than before. /mark From chris at totalhighspeed.net Wed Jun 17 13:28:52 2015 From: chris at totalhighspeed.net (Christopher Tyler) Date: Wed, 17 Jun 2015 08:28:52 -0500 (CDT) Subject: Google contact? In-Reply-To: <121648252.1268644.1434547394865.JavaMail.zimbra@totalhighspeed.net> Message-ID: <621147107.1268723.1434547732517.JavaMail.zimbra@totalhighspeed.net> Need some help.. Does anyone have an email contact at Google that they are willing to pass along? All of our mowisp.net Apps for ISP accounts were disabled last night at about 8-9PM without notice and we are now getting swamped with calls. Possibly several hundred users affected. -- Christopher Tyler MTCRE/MTCNA/MTCTCE/MTCWE Total Highspeed Internet Services 417.851.1107 From shawnl at up.net Wed Jun 17 15:15:19 2015 From: shawnl at up.net (Shawn L) Date: Wed, 17 Jun 2015 11:15:19 -0400 (EDT) Subject: =?utf-8?Q?RE=3A_Google_contact=3F?= In-Reply-To: <621147107.1268723.1434547732517.JavaMail.zimbra@totalhighspeed.net> References: <621147107.1268723.1434547732517.JavaMail.zimbra@totalhighspeed.net> Message-ID: <1434554119.591826096@upnet.mymailsrvr.com> Google cancelled their ISP program as of the 8th of June. Feel free to contact me off-list for more info. They cancelled ours as well. -----Original Message----- From: "Christopher Tyler" Sent: Wednesday, June 17, 2015 9:28am To: nanog at nanog.org Subject: Google contact? Need some help.. Does anyone have an email contact at Google that they are willing to pass along? All of our mowisp.net Apps for ISP accounts were disabled last night at about 8-9PM without notice and we are now getting swamped with calls. Possibly several hundred users affected. -- Christopher Tyler MTCRE/MTCNA/MTCTCE/MTCWE Total Highspeed Internet Services 417.851.1107 From Matthew.Black at csulb.edu Wed Jun 17 15:51:11 2015 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 17 Jun 2015 15:51:11 +0000 Subject: Google contact? In-Reply-To: <621147107.1268723.1434547732517.JavaMail.zimbra@totalhighspeed.net> References: <121648252.1268644.1434547394865.JavaMail.zimbra@totalhighspeed.net> <621147107.1268723.1434547732517.JavaMail.zimbra@totalhighspeed.net> Message-ID: Hopefully, they sent you advance notice. Google Apps for ISP EOL https://productforums.google.com/forum/#!topic/apps/_zgHXEBjwKU matthew black california state university, long beach -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher Tyler Sent: Wednesday, June 17, 2015 6:29 AM To: nanog at nanog.org Subject: Google contact? Need some help.. Does anyone have an email contact at Google that they are willing to pass along? All of our mowisp.net Apps for ISP accounts were disabled last night at about 8-9PM without notice and we are now getting swamped with calls. Possibly several hundred users affected. -- Christopher Tyler MTCRE/MTCNA/MTCTCE/MTCWE Total Highspeed Internet Services 417.851.1107 From shawnl at up.net Wed Jun 17 16:10:24 2015 From: shawnl at up.net (Shawn L) Date: Wed, 17 Jun 2015 12:10:24 -0400 (EDT) Subject: =?utf-8?Q?Re=3A_Google_contact=3F?= In-Reply-To: References: <621147107.1268723.1434547732517.JavaMail.zimbra@totalhighspeed.net> <1434554119.591826096@upnet.mymailsrvr.com> Message-ID: <1434557424.9332600@upnet.mymailsrvr.com> I'm replying on-list since it seems like a lot of people are in the same boat. Here's a summary of what happened to us. Please feel free to jump in if you had a different experience, or have more information. Google sent us a notice in December that as of June 8 they would be discontinuing the Google for ISPs program and that we had to find a different e-mail provider. Unfortunately, they only sent this notice to the account that initially created the service, which was un-monitored. I have heard the same thing from others. They did not include a notice about the discontinuation in their monthly billing, only in e-mail and only to the account that initiated the google service. We actually found out about it some time in February. I spoke with the Google contact listed in the e-mail and was told that they were indeed cancelling the service, but wasn't given a reason. We also asked if it was possible to move to a different Google service, Google Apps for Business for example, but was told that it would be against their terms or service and would result in a cancellation of the service. After a lot of research in Google's forums, it looked like a lot of other people were in the same boat we were. We ended up talking with another e-mail provider and migrating all of our mail. Several weeks ago we asked Google for an extension because the migration was taking longer than expected. We were given until the 16th of June and told that no further extensions would be given. I have spoken to one person who was given until the end of June. Here is the original notice we received from google. I hope this helps others in the same boat December 10, 2014 [ your-domain,com ]( http://baragatelephone.com ) Subject: Notice of Non-Renewal of The Google Apps - ISP Partner Edition Agreement. Dear Administrator, Thank you for being a Google customer and for using Google Apps Partner Edition (collectively, "Partner Edition"). As part of Google's integration plans, we have elected to discontinue providing the Partner Edition Services going forward. As provided in the Agreement between Google Inc. and [ your-domain.com ]( http://baragatelephone.com ), this letter serves as your formal notice that the Services will not be renewed, and our Agreement with you will terminate on June 8, 2015. Any other Google services you have purchased (or resold, if applicable), in addition the Partner Edition product and services, will not be affected by this change. Please also note that this notice of non-renewal does not relieve you of any payment obligations you may have under the current Agreement and that you remain responsible for remitting any such owed payments in full by the applicable invoice due date for the Services. We have prepared an Administrator transition resource website ([ https://support.google.com/appstransition/go/admin ]( https://support.google.com/appstransition/go/admin )) and an End User resource website ([ https://support.google.com/appstransition ]( https://support.google.com/appstransition )) to assist you through the transition. This resource center presents some of the migration options available to you and provides instructions that you can share with your customers. We regret any inconvenience this may cause, and thank you again for your business. If you have any questions, please contact your Account Manager below. Account Manager: John Coull Phone Number: [ 212- 565-3131 ]( tel:212-%20565-3131 ) Email Address: [ johnbc at google.com ]( mailto:johnbc at google.com ) Sincerely, Omid Kordestani Chief Business Officer -----Original Message----- From: "Marciano Lopes" Sent: Wednesday, June 17, 2015 11:48am To: "Shawn L" Subject: Re: Google contact? Hello Shawn! They cancelled ours as well. What we can do? Thanks! Atenciosamente, Marciano Lopes GSURF Fixo (48) 3254-8700 Ramal 6272 M?vel (48) 9125-5081 Atendimento 24h 0800-644-4833 2015-06-17 12:15 GMT-03:00 Shawn L <[ shawnl at up.net ]( mailto:shawnl at up.net )>: Google cancelled their ISP program as of the 8th of June. Feel free to contact me off-list for more info. They cancelled ours as well. -----Original Message----- From: "Christopher Tyler" <[ chris at totalhighspeed.net ]( mailto:chris at totalhighspeed.net )> Sent: Wednesday, June 17, 2015 9:28am To: [ nanog at nanog.org ]( mailto:nanog at nanog.org ) Subject: Google contact? Need some help.. Does anyone have an email contact at Google that they are willing to pass along? All of our [ mowisp.net ]( http://mowisp.net ) Apps for ISP accounts were disabled last night at about 8-9PM without notice and we are now getting swamped with calls. Possibly several hundred users affected. -- Christopher Tyler MTCRE/MTCNA/MTCTCE/MTCWE Total Highspeed Internet Services [ 417.851.1107 ]( tel:417.851.1107 ) From josh at imaginenetworksllc.com Wed Jun 17 16:17:24 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 17 Jun 2015 12:17:24 -0400 Subject: Google contact? In-Reply-To: <1434557424.9332600@upnet.mymailsrvr.com> References: <621147107.1268723.1434547732517.JavaMail.zimbra@totalhighspeed.net> <1434554119.591826096@upnet.mymailsrvr.com> <1434557424.9332600@upnet.mymailsrvr.com> Message-ID: I was actually told July 6 or 9 in my email (which was delivered to that unmonitored mail box like you). I told customers July 1. We lost it June 9. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 17, 2015 at 12:10 PM, Shawn L wrote: > > I'm replying on-list since it seems like a lot of people are in the same > boat. > > Here's a summary of what happened to us. Please feel free to jump in if > you had a different experience, or have more information. > > Google sent us a notice in December that as of June 8 they would be > discontinuing the Google for ISPs program and that we had to find a > different e-mail provider. Unfortunately, they only sent this notice to > the account that initially created the service, which was un-monitored. > I have heard the same thing from others. They did not include a notice > about the discontinuation in their monthly billing, only in e-mail and only > to the account that initiated the google service. > > We actually found out about it some time in February. I spoke with the > Google contact listed in the e-mail and was told that they were indeed > cancelling the service, but wasn't given a reason. We also asked if it was > possible to move to a different Google service, Google Apps for Business > for example, but was told that it would be against their terms or service > and would result in a cancellation of the service. > > After a lot of research in Google's forums, it looked like a lot of other > people were in the same boat we were. We ended up talking with another > e-mail provider and migrating all of our mail. Several weeks ago we asked > Google for an extension because the migration was taking longer than > expected. We were given until the 16th of June and told that no further > extensions would be given. I have spoken to one person who was given until > the end of June. > > Here is the original notice we received from google. I hope this helps > others in the same boat > > > December 10, 2014 > [ your-domain,com ]( http://baragatelephone.com ) > > Subject: Notice of Non-Renewal of The Google Apps - ISP Partner Edition > Agreement. > > Dear Administrator, > Thank you for being a Google customer and for using Google Apps Partner > Edition (collectively, "Partner Edition"). > As part of Google's integration plans, we have elected to discontinue > providing the Partner Edition Services going forward. As provided in the > Agreement between Google Inc. and [ your-domain.com ]( > http://baragatelephone.com ), this letter serves as your formal notice > that the Services will not be renewed, and our Agreement with you will > terminate on June 8, 2015. > > Any other Google services you have purchased (or resold, if applicable), > in addition the Partner Edition product and services, will not be affected > by this change. Please also note that this notice of non-renewal does not > relieve you of any payment obligations you may have under the current > Agreement and that you remain responsible for remitting any such owed > payments in full by the applicable invoice due date for the Services. > > We have prepared an Administrator transition resource website ([ > https://support.google.com/appstransition/go/admin ]( > https://support.google.com/appstransition/go/admin )) and an End User > resource website ([ https://support.google.com/appstransition ]( > https://support.google.com/appstransition )) to assist you through the > transition. This resource center presents some of the migration options > available to you and provides instructions that you can share with your > customers. > > We regret any inconvenience this may cause, and thank you again for your > business. If you have any questions, please contact your Account Manager > below. > > Account Manager: John Coull > Phone Number: [ 212- 565-3131 ]( tel:212-%20565-3131 ) > Email Address: [ johnbc at google.com ]( mailto:johnbc at google.com ) > > Sincerely, > Omid Kordestani > Chief Business Officer > > > > > > -----Original Message----- > From: "Marciano Lopes" > Sent: Wednesday, June 17, 2015 11:48am > To: "Shawn L" > Subject: Re: Google contact? > > > > > Hello Shawn! > They cancelled ours as well. > > What we can do? > > Thanks! > > > > > > > > Atenciosamente, > Marciano Lopes > GSURF > Fixo (48) 3254-8700 Ramal 6272 > M?vel (48) 9125-5081 > Atendimento 24h 0800-644-4833 > > 2015-06-17 12:15 GMT-03:00 Shawn L <[ shawnl at up.net ]( mailto: > shawnl at up.net )>: > > Google cancelled their ISP program as of the 8th of June. > > Feel free to contact me off-list for more info. They cancelled ours as > well. > > > > > -----Original Message----- > From: "Christopher Tyler" <[ chris at totalhighspeed.net ]( mailto: > chris at totalhighspeed.net )> > Sent: Wednesday, June 17, 2015 9:28am > To: [ nanog at nanog.org ]( mailto:nanog at nanog.org ) > Subject: Google contact? > > > > Need some help.. Does anyone have an email contact at Google that they > are willing to pass along? > All of our [ mowisp.net ]( http://mowisp.net ) Apps for ISP accounts > were disabled last night at about 8-9PM without notice and we are now > getting swamped with calls. Possibly several hundred users affected. > > -- > Christopher Tyler > MTCRE/MTCNA/MTCTCE/MTCWE > Total Highspeed Internet Services > [ 417.851.1107 ]( tel:417.851.1107 ) > > > > From nanog at ics-il.net Wed Jun 17 16:19:53 2015 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 17 Jun 2015 11:19:53 -0500 (CDT) Subject: Google contact? In-Reply-To: <1434557424.9332600@upnet.mymailsrvr.com> Message-ID: <25206032.6020.1434557977751.JavaMail.mhammett@ThunderFuck> This seems to come up about once a month for quite some time on various lists. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Shawn L" To: "marciano lopes" Cc: "nanog" Sent: Wednesday, June 17, 2015 11:10:24 AM Subject: Re: Google contact? I'm replying on-list since it seems like a lot of people are in the same boat. Here's a summary of what happened to us. Please feel free to jump in if you had a different experience, or have more information. Google sent us a notice in December that as of June 8 they would be discontinuing the Google for ISPs program and that we had to find a different e-mail provider. Unfortunately, they only sent this notice to the account that initially created the service, which was un-monitored. I have heard the same thing from others. They did not include a notice about the discontinuation in their monthly billing, only in e-mail and only to the account that initiated the google service. We actually found out about it some time in February. I spoke with the Google contact listed in the e-mail and was told that they were indeed cancelling the service, but wasn't given a reason. We also asked if it was possible to move to a different Google service, Google Apps for Business for example, but was told that it would be against their terms or service and would result in a cancellation of the service. After a lot of research in Google's forums, it looked like a lot of other people were in the same boat we were. We ended up talking with another e-mail provider and migrating all of our mail. Several weeks ago we asked Google for an extension because the migration was taking longer than expected. We were given until the 16th of June and told that no further extensions would be given. I have spoken to one person who was given until the end of June. Here is the original notice we received from google. I hope this helps others in the same boat December 10, 2014 [ your-domain,com ]( http://baragatelephone.com ) Subject: Notice of Non-Renewal of The Google Apps - ISP Partner Edition Agreement. Dear Administrator, Thank you for being a Google customer and for using Google Apps Partner Edition (collectively, "Partner Edition"). As part of Google's integration plans, we have elected to discontinue providing the Partner Edition Services going forward. As provided in the Agreement between Google Inc. and [ your-domain.com ]( http://baragatelephone.com ), this letter serves as your formal notice that the Services will not be renewed, and our Agreement with you will terminate on June 8, 2015. Any other Google services you have purchased (or resold, if applicable), in addition the Partner Edition product and services, will not be affected by this change. Please also note that this notice of non-renewal does not relieve you of any payment obligations you may have under the current Agreement and that you remain responsible for remitting any such owed payments in full by the applicable invoice due date for the Services. We have prepared an Administrator transition resource website ([ https://support.google.com/appstransition/go/admin ]( https://support.google.com/appstransition/go/admin )) and an End User resource website ([ https://support.google.com/appstransition ]( https://support.google.com/appstransition )) to assist you through the transition. This resource center presents some of the migration options available to you and provides instructions that you can share with your customers. We regret any inconvenience this may cause, and thank you again for your business. If you have any questions, please contact your Account Manager below. Account Manager: John Coull Phone Number: [ 212- 565-3131 ]( tel:212-%20565-3131 ) Email Address: [ johnbc at google.com ]( mailto:johnbc at google.com ) Sincerely, Omid Kordestani Chief Business Officer -----Original Message----- From: "Marciano Lopes" Sent: Wednesday, June 17, 2015 11:48am To: "Shawn L" Subject: Re: Google contact? Hello Shawn! They cancelled ours as well. What we can do? Thanks! Atenciosamente, Marciano Lopes GSURF Fixo (48) 3254-8700 Ramal 6272 M?vel (48) 9125-5081 Atendimento 24h 0800-644-4833 2015-06-17 12:15 GMT-03:00 Shawn L <[ shawnl at up.net ]( mailto:shawnl at up.net )>: Google cancelled their ISP program as of the 8th of June. Feel free to contact me off-list for more info. They cancelled ours as well. -----Original Message----- From: "Christopher Tyler" <[ chris at totalhighspeed.net ]( mailto:chris at totalhighspeed.net )> Sent: Wednesday, June 17, 2015 9:28am To: [ nanog at nanog.org ]( mailto:nanog at nanog.org ) Subject: Google contact? Need some help.. Does anyone have an email contact at Google that they are willing to pass along? All of our [ mowisp.net ]( http://mowisp.net ) Apps for ISP accounts were disabled last night at about 8-9PM without notice and we are now getting swamped with calls. Possibly several hundred users affected. -- Christopher Tyler MTCRE/MTCNA/MTCTCE/MTCWE Total Highspeed Internet Services [ 417.851.1107 ]( tel:417.851.1107 ) From rps at maine.edu Wed Jun 17 19:13:38 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 17 Jun 2015 15:13:38 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: Anycast is generally not well-suited for stateful connectivity (e.g. most things TCP). The use case for anycast is restricted to simple challenge-response protocol design. As such, you typically only see it leveraged for simple services (e.g. DNS, NTP). The reason for this, as you suspect, is you can never guarantee that the path and thus the server will remain consistent across client connections. Ideally you can leverage DNS to provide a response to a unicast resource rather than trying to make the service itself anycast. DNS can be anycast, and DNS can provide different responses based on geographical location, but these can happen independently or together. As you still want failover, you might opt to announce the MX record with the priorities reversed but still pointing to each server. For example MX 10 server1, MX 20 server2 on one side, and MX 10 server2, MX 20 server1 on the other. Typically you would use a DNS load balancer rather than simple anycast DNS to achieve this though. On Mon, Jun 15, 2015 at 1:50 PM, Joe Hamelin wrote: > I have a mail system where there are two MX hosts, one in the US and one in > Europe. Both have a DNS MX record metric of 10 so a bastardized > round-robin takes place. This does not work so well when one site goes > down. My solution will be to place a load balancer in a hosting site > (virtual, of course) and have it provide HA. But what about HA for the > LB? At first glance anycasting would seem to be a great idea but there is > a problem of broken sessions when routes change. > > Have any of you seen something like this work in the wild? > > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > -- 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 Matthew.Black at csulb.edu Wed Jun 17 20:46:43 2015 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 17 Jun 2015 20:46:43 +0000 Subject: DMARC in education Message-ID: Looking at implementing DMARC for my institution. We currently have an SPF record and use DKIM to sign a small subset of messages. Rollout recommendations for DMARC suggest initially creating a "p=none" record to gather information on how a domain is being used. The RUA tag specifies a URI of where to send daily reports. Trying to get an idea of how many reports to expect a day or two after the dust settles. Does anyone use an aggregator to process their feedback (RUA tag) and/or forensic reports (RUF tag)? DMARC information. https://dmarc.org/ See slide 38 of 93 at http://www.slideshare.net/kka7/fighting-email-abuse-with-dmarc?qid=5e90be27-3fc0-41ed-9d71-253978cc6a12&v=default&b=&from_search=2 Everyone's first DMARC record V=DMARC1; p=none; rua=mailto:aggregate at example.com; Cheers! matthew black information technology services california state university, long beach From lnguyen at opsource.net Wed Jun 17 21:07:25 2015 From: lnguyen at opsource.net (Luan Nguyen) Date: Wed, 17 Jun 2015 17:07:25 -0400 Subject: Is it safe to use 240.0.0.0/4 Message-ID: Is that safe to use internally? Anyone using it? Just for NATTING on Cisco gears... From cb.list6 at gmail.com Wed Jun 17 21:12:26 2015 From: cb.list6 at gmail.com (Ca By) Date: Wed, 17 Jun 2015 14:12:26 -0700 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: On Wed, Jun 17, 2015 at 2:07 PM, Luan Nguyen wrote: > Is that safe to use internally? Anyone using it? > Just for NATTING on Cisco gears... > most things, including most cisco gear, will not forward those Class E packets or accept Class E as a valid address If you have success, please report it to the list. From chuckchurch at gmail.com Wed Jun 17 21:12:22 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Wed, 17 Jun 2015 17:12:22 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: <00f801d0a942$4fbb6040$ef3220c0$@gmail.com> ----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ray Soucy Sent: Wednesday, June 17, 2015 3:14 PM To: Joe Hamelin Cc: NANOG list Subject: Re: Anycast provider for SMTP? >As such, you typically only see it leveraged for simple services (e.g. DNS, NTP). I've been thinking about this for NTP. Wouldn't you end up with constant corrections with NTP and Anycast? Or is the assumption your anycasted NTP hosts are all peers of each other and extremely close in time to one another? That still wouldn't address the latency differences between the different hosts. Chuck From tony at wicks.co.nz Wed Jun 17 21:13:20 2015 From: tony at wicks.co.nz (Tony Wicks) Date: Thu, 18 Jun 2015 09:13:20 +1200 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: <001701d0a942$70e780a0$52b681e0$@wicks.co.nz> Use 100.64.0.0/10, this is the CGNAT reserved range.I would most definitely not recommend 240.0.0.0 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Luan Nguyen Sent: Thursday, 18 June 2015 9:07 a.m. To: nanog at nanog.org Subject: Is it safe to use 240.0.0.0/4 Is that safe to use internally? Anyone using it? Just for NATTING on Cisco gears... From josh at imaginenetworksllc.com Wed Jun 17 21:13:59 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 17 Jun 2015 17:13:59 -0400 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: Probably fine to NAT it yourself until it is allocated and someone starts using it. Why not just use RFC1918 space? https://www.google.com/fusiontables/DataSource?docid=1JEgabzMOJx1l25zHZK5wv4_Tn9KRsyDGgSq-M4g Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 17, 2015 at 5:07 PM, Luan Nguyen wrote: > Is that safe to use internally? Anyone using it? > Just for NATTING on Cisco gears... > From luan.nguyen at dimensiondata.com Wed Jun 17 21:21:17 2015 From: luan.nguyen at dimensiondata.com (Luan Nguyen) Date: Wed, 17 Jun 2015 17:21:17 -0400 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: Cisco IOS-XE Fails ip add 241.1.1.1 255.255.255.0 Not a valid host address - 241.1.1.1 ip route 241.0.0.0 255.0.0.0 10.10.10.1 %Invalid destination prefix XR-OS : fails Can take the IP on a interface, but cant route it IOS fails we used up all the reserved ip blocks including the 169.254 and the benchmark, and the 100.64/10 and ofcourse the RFC1918. Lots of apps don't do ipv6 so we are finding interim solution...i guess that's karma since doing so sort of anti-facilitating the use of ipv6 :) On Wed, Jun 17, 2015 at 5:12 PM, Ca By wrote: > On Wed, Jun 17, 2015 at 2:07 PM, Luan Nguyen wrote: > > > Is that safe to use internally? Anyone using it? > > Just for NATTING on Cisco gears... > > > > most things, including most cisco gear, will not forward those Class E > packets or accept Class E as a valid address > > If you have success, please report it to the list. > From jabley at hopcount.ca Wed Jun 17 21:27:53 2015 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 17 Jun 2015 17:27:53 -0400 Subject: Anycast provider for SMTP? In-Reply-To: <00f801d0a942$4fbb6040$ef3220c0$@gmail.com> References: <00f801d0a942$4fbb6040$ef3220c0$@gmail.com> Message-ID: <-7718872391839210467@unknownmsgid> On Jun 17, 2015, at 17:15, Chuck Church wrote: >> As such, you typically only see it leveraged for simple services (e.g. DNS, NTP). > > I've been thinking about this for NTP. Wouldn't you end up with constant corrections with NTP and Anycast? I am not a time geek, but the general and consistent advice I have heard from actual such geeks is, as you suspected, not to use anycast to distribute NTP service. I imagine that advice could be modified somewhat if you differentiate between NTP as used within a mesh of well-synchronised clocks and NTP as an occasional service for mobile clients that require only a loose sense of now. The latter seems like availability might be more important than stability over an extended period, so anycast might make sense there. Joe From listas at esds.com.br Wed Jun 17 21:30:04 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Wed, 17 Jun 2015 18:30:04 -0300 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: And what about 0.0.0.0/8? -- Eduardo Schoedler 2015-06-17 18:21 GMT-03:00 Luan Nguyen : > Cisco IOS-XE Fails > ip add 241.1.1.1 255.255.255.0 > Not a valid host address - 241.1.1.1 > ip route 241.0.0.0 255.0.0.0 10.10.10.1 > %Invalid destination prefix > XR-OS : fails > Can take the IP on a interface, but cant route it > IOS fails > > we used up all the reserved ip blocks including the 169.254 and the > benchmark, and the 100.64/10 and ofcourse the RFC1918. > Lots of apps don't do ipv6 so we are finding interim solution...i guess > that's karma since doing so sort of anti-facilitating the use of ipv6 :) > > On Wed, Jun 17, 2015 at 5:12 PM, Ca By wrote: > > > On Wed, Jun 17, 2015 at 2:07 PM, Luan Nguyen > wrote: > > > > > Is that safe to use internally? Anyone using it? > > > Just for NATTING on Cisco gears... > > > > > > > most things, including most cisco gear, will not forward those Class E > > packets or accept Class E as a valid address > > > > If you have success, please report it to the list. > > > -- Eduardo Schoedler From rps at maine.edu Wed Jun 17 21:38:10 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 17 Jun 2015 17:38:10 -0400 Subject: Anycast provider for SMTP? In-Reply-To: <00f801d0a942$4fbb6040$ef3220c0$@gmail.com> References: <00f801d0a942$4fbb6040$ef3220c0$@gmail.com> Message-ID: NTP might have been a bad example for the timing reasons. One thing to keep in mind with anycast is that unless there are problems the routes are fairly stable and depending on how many servers you deploy and what route visibility you have even different providers will often see the same location as the closest path in terms of BGP. I believe pool.ntp.org employs anycast to some extent, but I'm not sure about that. SNTP seems to to have a discovery component designed to work well with anycast. RFC 7094 has a good summary of all this. In general, the consensus seems to be that anycast is better used for discovery services rather than services themselves. On Wed, Jun 17, 2015 at 5:12 PM, Chuck Church wrote: > ----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ray Soucy > Sent: Wednesday, June 17, 2015 3:14 PM > To: Joe Hamelin > Cc: NANOG list > Subject: Re: Anycast provider for SMTP? > > > >As such, you typically only see it leveraged for simple services (e.g. > DNS, NTP). > > I've been thinking about this for NTP. Wouldn't you end up with constant > corrections with NTP and Anycast? Or is the assumption your anycasted NTP > hosts are all peers of each other and extremely close in time to one > another? That still wouldn't address the latency differences between the > different hosts. > > Chuck > > -- 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 jfbeam at gmail.com Wed Jun 17 21:38:23 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 17 Jun 2015 17:38:23 -0400 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: On Wed, 17 Jun 2015 17:07:25 -0400, Luan Nguyen wrote: > Is that safe to use internally? Anyone using it? > Just for NATTING on Cisco gears... As you've already figured out, Class E space is still restricted on Cisco gear. I'll wait for Curran to pop up with various links to reasons why Class E was "abandoned" by ARIN. (short answer: too much broken crap thinks it's multicast!) From baldur.norddahl at gmail.com Wed Jun 17 21:49:11 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 17 Jun 2015 23:49:11 +0200 Subject: DMARC in education In-Reply-To: References: Message-ID: We use dmarcian.com to process the reports. Regards Baldur From rps at maine.edu Wed Jun 17 21:50:50 2015 From: rps at maine.edu (Ray Soucy) Date: Wed, 17 Jun 2015 17:50:50 -0400 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: There is already more than enough address space allocated for NAT, you don't need to start using random prefixes that may or may not be needed for other purposes in the future. For all we know, tomorrow someone could write an RFC requesting an address reserved for local anycast DNS and it could be assigned from this block. On Wed, Jun 17, 2015 at 5:07 PM, Luan Nguyen wrote: > Is that safe to use internally? Anyone using it? > Just for NATTING on Cisco gears... > -- 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 tom at cloudflare.com Wed Jun 17 21:54:47 2015 From: tom at cloudflare.com (Tom Paseka) Date: Wed, 17 Jun 2015 14:54:47 -0700 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: You'll find as well, a lot of hosts (eg, I know at least Windows XP) won't forward to Class E destinations. -Tom On Wed, Jun 17, 2015 at 2:50 PM, Ray Soucy wrote: > There is already more than enough address space allocated for NAT, you > don't need to start using random prefixes that may or may not be needed for > other purposes in the future. > > For all we know, tomorrow someone could write an RFC requesting an address > reserved for local anycast DNS and it could be assigned from this block. > > On Wed, Jun 17, 2015 at 5:07 PM, Luan Nguyen wrote: > >> Is that safe to use internally? Anyone using it? >> Just for NATTING on Cisco gears... >> > > > > -- > 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 job at instituut.net Wed Jun 17 22:00:45 2015 From: job at instituut.net (Job Snijders) Date: Thu, 18 Jun 2015 00:00:45 +0200 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: Message-ID: <20150617220045.GT94733@Vurt.local> On Wed, Jun 17, 2015 at 05:07:25PM -0400, Luan Nguyen wrote: > Is that safe to use [240.0.0.0/4] internally? Anyone using it? Just > for NATTING on Cisco gears... On Wed, Jun 17, 2015 at 06:30:04PM -0300, Eduardo Schoedler wrote: > And what about 0.0.0.0/8? On both counts: NO. I always assume parties strive to deliver the best service to their respective customers, IMHO this means avoiding IP space which was not designated for a global purpose (yet). Kind regards, Job From rafael at gav.ufsc.br Wed Jun 17 22:24:02 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Wed, 17 Jun 2015 17:24:02 -0500 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: <001701d0a942$70e780a0$52b681e0$@wicks.co.nz> References: <001701d0a942$70e780a0$52b681e0$@wicks.co.nz> Message-ID: Using CGNAT doesn't sound right either, although I haven't read the whole thing, but it seems reasonable to use that block for CGNAT only. https://tools.ietf.org/html/rfc1918 On Wed, Jun 17, 2015 at 4:13 PM, Tony Wicks wrote: > Use 100.64.0.0/10, this is the CGNAT reserved range.I would most > definitely not recommend 240.0.0.0 > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Luan Nguyen > Sent: Thursday, 18 June 2015 9:07 a.m. > To: nanog at nanog.org > Subject: Is it safe to use 240.0.0.0/4 > > Is that safe to use internally? Anyone using it? > Just for NATTING on Cisco gears... > > From fmartin at linkedin.com Wed Jun 17 22:27:54 2015 From: fmartin at linkedin.com (Franck Martin) Date: Wed, 17 Jun 2015 15:27:54 -0700 Subject: DMARC in education In-Reply-To: References: Message-ID: You have dmarcian, returnpath and agari to process reports. https://dmarcian.com/dmarc-status/ Will give you an idea who send aggregate reports. To state the obvious, they will send you a report only if you send them email. Allow 24 to 48 hours to get your first reports, if you don't get any, check your anti-spam filters and mail logs. On Wed, Jun 17, 2015 at 2:49 PM, Baldur Norddahl wrote: > We use dmarcian.com to process the reports. > > Regards > > Baldur > From bill at herrin.us Wed Jun 17 22:38:32 2015 From: bill at herrin.us (William Herrin) Date: Wed, 17 Jun 2015 18:38:32 -0400 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: On Wed, Jun 17, 2015 at 5:38 PM, Ricky Beam wrote: > I'll wait for Curran to pop up with various links to reasons why Class E was > "abandoned" by ARIN. (short answer: too much broken crap thinks it's > multicast!) Hi Ricky, You may be confused. ARIN never possessed class E; it's held in reserve by IETF. As much as I enjoy a good ARIN bashing, they and John Curran are quite faultless here. IIRC, the short answer why it wasn't repurposed as additional unicast addresses was that too much deployed gear has it hardcoded as "reserved, future functionality unknown, do not use." Following an instruction to repurpose 240/4 as unicast addresses, such gear would not receive new firmware or obsolete out of use quickly enough to be worth the effort. Given how slowly IPv6 is deploying, this choice may prove to have been shortsighted. Had IETF designated class-E as "reserved, future unicast" in 2008 when the issue was debated and asked vendors to update their software to expect 240/4 to be used as unicast addresses, half the problem equipment would already have aged out and we could all be debating whether to make them more RFC-1918 or hand them off to the RIRs. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From cb.list6 at gmail.com Wed Jun 17 23:01:36 2015 From: cb.list6 at gmail.com (Ca By) Date: Wed, 17 Jun 2015 16:01:36 -0700 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: On Wednesday, June 17, 2015, William Herrin wrote: > On Wed, Jun 17, 2015 at 5:38 PM, Ricky Beam > wrote: > > I'll wait for Curran to pop up with various links to reasons why Class E > was > > "abandoned" by ARIN. (short answer: too much broken crap thinks it's > > multicast!) > > Hi Ricky, > > You may be confused. ARIN never possessed class E; it's held in > reserve by IETF. As much as I enjoy a good ARIN bashing, they and John > Curran are quite faultless here. > > IIRC, the short answer why it wasn't repurposed as additional unicast > addresses was that too much deployed gear has it hardcoded as > "reserved, future functionality unknown, do not use." Following an > instruction to repurpose 240/4 as unicast addresses, such gear would > not receive new firmware or obsolete out of use quickly enough to be > worth the effort. > > Given how slowly IPv6 is deploying, this Pardon me. But Apple has at least suggested y'all should be ready for ipv6-only networks, not class E http://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-service-is-coming-soon-get-your-apps-ready/ http://www.internetsociety.org/deploy360/blog/2015/06/apple-will-require-ipv6-support-for-all-ios-9-apps/ And the source video which is worth watching from start to finish https://developer.apple.com/videos/wwdc/2015/?id=719 choice may prove to have been > shortsighted. Had IETF designated class-E as "reserved, future > unicast" in 2008 when the issue was debated and asked vendors to > update their software to expect 240/4 to be used as unicast addresses, > half the problem equipment would already have aged out and we could > all be debating whether to make them more RFC-1918 or hand them off to > the RIRs. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com > bill at herrin.us > Owner, Dirtside Systems ......... Web: > From marka at isc.org Wed Jun 17 23:25:34 2015 From: marka at isc.org (Mark Andrews) Date: Thu, 18 Jun 2015 09:25:34 +1000 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: Your message of "Wed, 17 Jun 2015 16:01:36 -0700." References: Message-ID: <20150617232534.7E85730DB49B@rock.dv.isc.org> In message , Ca By writes: > On Wednesday, June 17, 2015, William Herrin wrote: > > > On Wed, Jun 17, 2015 at 5:38 PM, Ricky Beam > > wrote: > > > I'll wait for Curran to pop up with various links to reasons why Class E > > was > > > "abandoned" by ARIN. (short answer: too much broken crap thinks it's > > > multicast!) > > > > Hi Ricky, > > > > You may be confused. ARIN never possessed class E; it's held in > > reserve by IETF. As much as I enjoy a good ARIN bashing, they and John > > Curran are quite faultless here. > > > > IIRC, the short answer why it wasn't repurposed as additional unicast > > addresses was that too much deployed gear has it hardcoded as > > "reserved, future functionality unknown, do not use." Following an > > instruction to repurpose 240/4 as unicast addresses, such gear would > > not receive new firmware or obsolete out of use quickly enough to be > > worth the effort. > > > > Given how slowly IPv6 is deploying, this > > > > Pardon me. But Apple has at least suggested y'all should be ready for > ipv6-only networks, not class E > > > http://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-service-is-coming-soon-get-your-apps-ready/ > > http://www.internetsociety.org/deploy360/blog/2015/06/apple-will-require-ipv6-support-for-all-ios-9-apps/ > > And the source video which is worth watching from start to finish > > https://developer.apple.com/videos/wwdc/2015/?id=719 Well the cell carriers are kind of forcing the issue here for iOS. They want to go IPv6-only and Apple doesn't want to do 464XLAT last I heard (haven't watched the video yet). If all the apps can run in a IPv6 only environment then there is only IPv4 literals in web pages and tethered equipement to worry about so there is less presure to implement 464XLAT. Breaking pages with IPv4 literals may actually be a good thing at this stage. We are 20 years into the migration to IPv6. 15 years of production IPv6 behind us. Most tethered equipment can do IPv6. The only hold outs there are servers that they want to connect to are IPv6 only. Forcing the issue here would also be a good thing. Additionally lots of big companies (FaceBook, Microsoft) are trying to go IPv6 only internally as are data centers. A number of wireline ISP are IPv6 only using DS-Lite to transport IPv4. MAP is a future IPv4 as a service on IPv6 contender. > choice may prove to have been > > shortsighted. Had IETF designated class-E as "reserved, future > > unicast" in 2008 when the issue was debated and asked vendors to > > update their software to expect 240/4 to be used as unicast addresses, > > half the problem equipment would already have aged out and we could > > all be debating whether to make them more RFC-1918 or hand them off to > > the RIRs. > > > > Regards, > > Bill Herrin > > > > > > > > -- > > William Herrin ................ herrin at dirtside.com > > bill at herrin.us > > Owner, Dirtside Systems ......... Web: > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From johnl at iecc.com Wed Jun 17 23:54:17 2015 From: johnl at iecc.com (John Levine) Date: 17 Jun 2015 23:54:17 -0000 Subject: DMARC in education In-Reply-To: Message-ID: <20150617235417.75310.qmail@ary.lan> In article you write: >Looking at implementing DMARC for my institution. What problem do you expect this to solve? This is a real question, since you can be 100% sure that any DMARC policy will wreak havoc on any of your users who use mailing lists like this one. Academic institutions tend to have a lot of list users. >Trying to get an idea of how many reports to expect a day or two after the dust settles. Does anyone >use an aggregator to process their feedback (RUA tag) and/or forensic reports (RUF tag)? Aggregate reports, probably no more than 10 per day per domain. Failure reports, depends on how much traffic your users and people pretending to be your users send to China, since Netease in China and Linkedin are the only providers that sends them, with the vast majority from Netease. The aggregate reports are interesting, the failure reports are not. There are some scripts on the dmarc.org site I wrote that parse the reports and put the interesting bits into a mysql database. I doubt you'll need any more than that to see how much trouble a DMARC policy would cause. R's, John From damian at google.com Thu Jun 18 00:07:01 2015 From: damian at google.com (Damian Menscher) Date: Wed, 17 Jun 2015 17:07:01 -0700 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: Not used in the sense you imagine, but I designed a hack where we hash IPv6 addresses into 224/3 (class D and E space) so backends that don't support IPv6 can still be provided a pseudo-IP. This accelerated support of IPv6 across all Google services without needing to wait for each individual backend to provide support. See https://www.nanog.org/meetings/nanog50/presentations/Wednesday/NANOG50.Talk41.colitti-IPv6%20transition%20experiences.pdf slide 4 for a description, or http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/net/InetAddresses.html for open-sourced code. There may be other uses for IPs beyond routing. Damian On Wed, Jun 17, 2015 at 2:07 PM, Luan Nguyen wrote: > Is that safe to use internally? Anyone using it? > Just for NATTING on Cisco gears... > From jfbeam at gmail.com Thu Jun 18 00:18:23 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 17 Jun 2015 20:18:23 -0400 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: On Wed, 17 Jun 2015 18:38:32 -0400, William Herrin wrote: > You may be confused. ARIN never possessed class E; it's held in > reserve by IETF. As much as I enjoy a good ARIN bashing, they and John > Curran are quite faultless here. Quote-unquote, as in they didn't even bother *even proposing* to use Class E space. The reasons were numerous, btw. (hardcoded restrictions, erroneous classification as multicast, not worth the effort, etc.) > Given how slowly IPv6 is deploying, this choice may prove to have been > shortsighted. I doubt it. As you said, there is A LOT of crap out there that would have to be updated. Pulling a number out of the air, I'd guess *most* in-use devices would NEVER see such an update. Even from companies that do still exist. (Sadly, those are also devices that aren't going to see IPv6, either.) From rfg at tristatelogic.com Thu Jun 18 00:54:30 2015 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 17 Jun 2015 17:54:30 -0700 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted Message-ID: <29116.1434588870@server1.tristatelogic.com> My apologies in advance to any here who might feel that this is off topic... I don't personally believe that it is. Frankly, I don't know of that many mailing lists where the subscribers are likely to care as much about network security (and/or the lack thereof) as the membership of this list does. By now, most of you will have read about the massive federal data breach at the U.S. Government's Office of Personnel Management (OPM), and also the fact that (by OPM's own preliminary estimates) this massive data breach affects at least four million federal government employees... but perhaps as many as 14 million current and former employees. However as this story is still evolving, even as we speak, you may perhaps not be familiar with the following additional important facts that have just come out: *) In addition to ordinary government personel records, including the usual kinds of frequently-hacked personal information (e.g. social security numbers), an as-yet undetermined number of highly detailed 127-page government security clearance forms (SF86) containing vast and intimate details of virtually every aspect of the lives of essentially EVERYONE who has applied for or been granted a government security clearance at any time within THE PAST 30 YEARS have also been hacked/leaked. (Experts seem to agree that this security clearance data constitutes and absolute gold mine and treasure trove of information for foreign intelligence services, opening up vast possibilities for phishing, blackmail, and on and on.) *) The Director of the Office of Personnel Management, Ms. Katherine Archueta was warned, repeatedly, and over several years, by her own department's Inspector General (IG) that many of OPM's systems were insecure and should be taken out of service. Nontheless, as reveled during congressional testimony yesterday, she overruled and ignored this advice and kept the systems online. Given the above facts, I've just started a new Whitehouse Petition, asking that the director of OPM, Ms. Archueta, be fired for gross incompetence. I _do_ understand that the likelihood of anyone ever getting fired for incompetence anywhere within the Washington D.C. Beltway is very much of a long shot, based on history, but I nontheless feel that as a U.S. citizen and taxpayer, I at least want to make my opinion of this matter known to The Powers That Be. I *really* would like some help from members of this list on this endeavor. In particular, if you agree, I'd appreciate it if you would sign my petition, and, whether you agree or not, I sure would appreciate it if you would all share the following URL widely: https://petitions.whitehouse.gov//petition/immediately-fire-office-personnel-managements-director-katherine-archueta-gross-incompetence Note that Whitehouse petitions do not even get properly or completely published on the Whitehouse web site until such time as they receive at least 150 signatures. I am hoping that members of this (NANOG) mailing list will help me to get past that threshold. Thanks for your attention. Regards, rfg From cb.list6 at gmail.com Thu Jun 18 01:17:53 2015 From: cb.list6 at gmail.com (Ca By) Date: Wed, 17 Jun 2015 18:17:53 -0700 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: On Wednesday, June 17, 2015, Ricky Beam wrote: > On Wed, 17 Jun 2015 18:38:32 -0400, William Herrin wrote: > >> You may be confused. ARIN never possessed class E; it's held in >> reserve by IETF. As much as I enjoy a good ARIN bashing, they and John >> Curran are quite faultless here. >> > > Quote-unquote, as in they didn't even bother *even proposing* to use Class > E space. The reasons were numerous, btw. (hardcoded restrictions, erroneous > classification as multicast, not worth the effort, etc.) https://tools.ietf.org/html/draft-wilson-class-e-02 Proposed and denied. Please stop this line and spend your efforts on ipv6 > Given how slowly IPv6 is deploying, this choice may prove to have been >> shortsighted. >> > > I doubt it. As you said, there is A LOT of crap out there that would have > to be updated. Pulling a number out of the air, I'd guess *most* in-use > devices would NEVER see such an update. Even from companies that do still > exist. (Sadly, those are also devices that aren't going to see IPv6, > either.) > From hhoffman at ip-solutions.net Thu Jun 18 01:19:37 2015 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Wed, 17 Jun 2015 21:19:37 -0400 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: <29116.1434588870@server1.tristatelogic.com> References: <29116.1434588870@server1.tristatelogic.com> Message-ID: <55821CA9.1080207@ip-solutions.net> I think it would be great if you were to include some source links in your petition/email so that folks unaware of the specifics can educate themselves in a non-partisan and factual manner. Just my $0.02. Cheers, Harry On 6/17/15 8:54 PM, Ronald F. Guilmette wrote: > My apologies in advance to any here who might feel that this is off > topic... I don't personally believe that it is. Frankly, I don't > know of that many mailing lists where the subscribers are likely to > care as much about network security (and/or the lack thereof) as the > membership of this list does. > > By now, most of you will have read about the massive federal data breach > at the U.S. Government's Office of Personnel Management (OPM), and also > the fact that (by OPM's own preliminary estimates) this massive data breach > affects at least four million federal government employees... but perhaps > as many as 14 million current and former employees. However as this > story is still evolving, even as we speak, you may perhaps not be familiar > with the following additional important facts that have just come out: > > *) In addition to ordinary government personel records, including > the usual kinds of frequently-hacked personal information (e.g. > social security numbers), an as-yet undetermined number of highly > detailed 127-page government security clearance forms (SF86) > containing vast and intimate details of virtually every aspect > of the lives of essentially EVERYONE who has applied for or been > granted a government security clearance at any time within THE > PAST 30 YEARS have also been hacked/leaked. > > (Experts seem to agree that this security clearance data constitutes > and absolute gold mine and treasure trove of information for foreign > intelligence services, opening up vast possibilities for phishing, > blackmail, and on and on.) > > *) The Director of the Office of Personnel Management, Ms. Katherine > Archueta was warned, repeatedly, and over several years, by her > own department's Inspector General (IG) that many of OPM's systems > were insecure and should be taken out of service. Nontheless, as > reveled during congressional testimony yesterday, she overruled > and ignored this advice and kept the systems online. > > Given the above facts, I've just started a new Whitehouse Petition, asking > that the director of OPM, Ms. Archueta, be fired for gross incompetence. > I _do_ understand that the likelihood of anyone ever getting fired for > incompetence anywhere within the Washington D.C. Beltway is very much of > a long shot, based on history, but I nontheless feel that as a U.S. > citizen and taxpayer, I at least want to make my opinion of this matter > known to The Powers That Be. > > I *really* would like some help from members of this list on this endeavor. > In particular, if you agree, I'd appreciate it if you would sign my petition, > and, whether you agree or not, I sure would appreciate it if you would all > share the following URL widely: > > https://petitions.whitehouse.gov//petition/immediately-fire-office-personnel-managements-director-katherine-archueta-gross-incompetence > > Note that Whitehouse petitions do not even get properly or completely > published on the Whitehouse web site until such time as they receive at > least 150 signatures. I am hoping that members of this (NANOG) mailing > list will help me to get past that threshold. > > Thanks for your attention. > > > Regards, > rfg From tylermills at gmail.com Thu Jun 18 01:23:29 2015 From: tylermills at gmail.com (Tyler Mills) Date: Thu, 18 Jun 2015 01:23:29 +0000 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: <29116.1434588870@server1.tristatelogic.com> References: <29116.1434588870@server1.tristatelogic.com> Message-ID: This is the government... you have to put on your bizarro-economics and bizarro-ethics glasses for the State to make sense. It does not operate like a market. Failure results in people being shuffled around, and larger budgets. Failure justifies more control and power. People get taken down for political reasons, not based on a lack of ability or lack of virtue. I would hope this measure succeeds and to see something meaningful come out of it, I just don't see it happening. On Wed, Jun 17, 2015 at 8:56 PM Ronald F. Guilmette wrote: > > My apologies in advance to any here who might feel that this is off > topic... I don't personally believe that it is. Frankly, I don't > know of that many mailing lists where the subscribers are likely to > care as much about network security (and/or the lack thereof) as the > membership of this list does. > > By now, most of you will have read about the massive federal data breach > at the U.S. Government's Office of Personnel Management (OPM), and also > the fact that (by OPM's own preliminary estimates) this massive data breach > affects at least four million federal government employees... but perhaps > as many as 14 million current and former employees. However as this > story is still evolving, even as we speak, you may perhaps not be familiar > with the following additional important facts that have just come out: > > *) In addition to ordinary government personel records, including > the usual kinds of frequently-hacked personal information (e.g. > social security numbers), an as-yet undetermined number of highly > detailed 127-page government security clearance forms (SF86) > containing vast and intimate details of virtually every aspect > of the lives of essentially EVERYONE who has applied for or been > granted a government security clearance at any time within THE > PAST 30 YEARS have also been hacked/leaked. > > (Experts seem to agree that this security clearance data > constitutes > and absolute gold mine and treasure trove of information for > foreign > intelligence services, opening up vast possibilities for phishing, > blackmail, and on and on.) > > *) The Director of the Office of Personnel Management, Ms. Katherine > Archueta was warned, repeatedly, and over several years, by her > own department's Inspector General (IG) that many of OPM's systems > were insecure and should be taken out of service. Nontheless, as > reveled during congressional testimony yesterday, she overruled > and ignored this advice and kept the systems online. > > Given the above facts, I've just started a new Whitehouse Petition, asking > that the director of OPM, Ms. Archueta, be fired for gross incompetence. > I _do_ understand that the likelihood of anyone ever getting fired for > incompetence anywhere within the Washington D.C. Beltway is very much of > a long shot, based on history, but I nontheless feel that as a U.S. > citizen and taxpayer, I at least want to make my opinion of this matter > known to The Powers That Be. > > I *really* would like some help from members of this list on this endeavor. > In particular, if you agree, I'd appreciate it if you would sign my > petition, > and, whether you agree or not, I sure would appreciate it if you would all > share the following URL widely: > > > https://petitions.whitehouse.gov//petition/immediately-fire-office-personnel-managements-director-katherine-archueta-gross-incompetence > > Note that Whitehouse petitions do not even get properly or completely > published on the Whitehouse web site until such time as they receive at > least 150 signatures. I am hoping that members of this (NANOG) mailing > list will help me to get past that threshold. > > Thanks for your attention. > > > Regards, > rfg > -- Tyler W. Mills Infrastructure and Network Engineer Atlanta, GA. From mr.jonas.bjork at me.com Thu Jun 18 01:39:29 2015 From: mr.jonas.bjork at me.com (=?utf-8?Q?Jonas_Bj=C3=B6rk?=) Date: Thu, 18 Jun 2015 03:39:29 +0200 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: >> Given how slowly IPv6 is deploying, this choice may prove to have been >> shortsighted. > > I doubt it. As you said, there is A LOT of crap out there that would have to be updated. Pulling a number out of the air, I'd guess *most* in-use devices would NEVER see such an update. Even from companies that do still exist. (Sadly, those are also devices that aren't going to see IPv6, either.) Most stuff out there do only care about that its subnet mask OR's up correctly with its ip and gw. Poof, there did 99.9 per cent of all devices get excluded. Most stuff that do use and/or misuse this freightening block of darkest cyberspace are either high end network equipment (who drop) or some end users/mcast sender which are behind NAT anyway. I believe it's a great idea. Let's at least try it out, like an alpha-test. We choose a temporary /8 (easy to remember) and divide it into /16s or less, depending on how many interested candidates we are able to raise. After being approved by IANA we begin advertising our new prefixes for a finite amount of time. If the world ends, or is about to, we stop. I believe we would bump into minor caveats but ISP's are beginning to NAT their end customers due to the lack of free ips and I wouldn't want to live in a world where that was the norm. This madness has to stop and v6 won't salvate us for yet another total sonar eclipse or three. Let us at least try it out - if it goes well we have bought us some time. If not, revert. Thank you for listening. br /Mr Bjork From lyndon at orthanc.ca Thu Jun 18 01:54:59 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Wed, 17 Jun 2015 18:54:59 -0700 Subject: DMARC in education In-Reply-To: <20150617235417.75310.qmail@ary.lan> References: <20150617235417.75310.qmail@ary.lan> Message-ID: > What problem do you expect this to solve? This is a real question, > since you can be 100% sure that any DMARC policy will wreak havoc on > any of your users who use mailing lists like this one. *Any* mailing list. Please help stamp out this abomination by refusing to capitulate to its insane desire to pretend the last three+ decades of email functionality never existed. --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From surfer at mauigateway.com Thu Jun 18 01:55:52 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 17 Jun 2015 18:55:52 -0700 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted Message-ID: <20150617185552.D9859428@m0005311.ppops.net> --- rfg at tristatelogic.com wrote: From: "Ronald F. Guilmette" *) The Director of the Office of Personnel Management, Ms. Katherine Archueta was warned, repeatedly, and over several years, by her own department's Inspector General (IG) that many of OPM's systems were insecure and should be taken out of service. Nontheless, as reveled during congressional testimony yesterday, she overruled and ignored this advice and kept the systems online. ------------------------------------------- >From personal experience (at a different level) this is SOP, unfortunately. They just don't understand the importance until catastrophic failure. scott From cb.list6 at gmail.com Thu Jun 18 02:00:30 2015 From: cb.list6 at gmail.com (Ca By) Date: Wed, 17 Jun 2015 19:00:30 -0700 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: On Wednesday, June 17, 2015, Jonas Bj?rk wrote: > > >> Given how slowly IPv6 is deploying, this choice may prove to have been > >> shortsighted. > > > > I doubt it. As you said, there is A LOT of crap out there that would > have to be updated. Pulling a number out of the air, I'd guess *most* > in-use devices would NEVER see such an update. Even from companies that do > still exist. (Sadly, those are also devices that aren't going to see IPv6, > either.) > > Most stuff out there do only care about that its subnet mask OR's up > correctly with its ip and gw. Poof, there did 99.9 per cent of all devices > get excluded. Most stuff that Pretty sure this is wrong. > do use and/or misuse this freightening block of darkest cyberspace are > either high end network equipment (who drop) or some end users/mcast sender > which are behind NAT anyway. > > I believe it's a great idea. Let's at least try it out, like an > alpha-test. We choose a temporary /8 (easy to remember) and divide it into > /16s or less, depending on how many interested candidates we are able to > raise. After being approved by IANA we begin advertising our new prefixes > for a finite amount of time. If the world ends, or is about to, we stop. > > I believe we would bump into minor caveats but ISP's are beginning to NAT > their end customers due to the lack of free ips and I wouldn't want to live > in a world where that was the norm. This madness has to stop and v6 won't > salvate us for yet another total sonar eclipse or three. > > Definately wrong. There are many networks larger and smaller than yours that run ipv6-only (ds-lite, 464xlat, whatever facebook does in their dc). You are wasting time and money. Let us at least try it out - if it goes well we have bought us some time. > If not, revert. > Thank you for listening. > > br /Mr Bjork From nanog-post at rsuc.gweep.net Thu Jun 18 02:14:14 2015 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 17 Jun 2015 22:14:14 -0400 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: <20150618021412.GA93112@gweep.net> No, we examined this back in 2007. See your favorite cache site for http://puck.nether.net/mailman/listinfo/240-e -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG From johnl at iecc.com Thu Jun 18 02:13:56 2015 From: johnl at iecc.com (John Levine) Date: 18 Jun 2015 02:13:56 -0000 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: Message-ID: <20150618021356.75689.qmail@ary.lan> >IIRC, the short answer why it wasn't repurposed as additional unicast >addresses was that too much deployed gear has it hardcoded as >"reserved, future functionality unknown, do not use." Following an >instruction to repurpose 240/4 as unicast addresses, such gear would >not receive new firmware or obsolete out of use quickly enough to be >worth the effort. More to the point, the amount of work required to fix all the existing equipment to handle 240/4 would not be a lot less than the work required to get it to handle IPv6, and it would only have pushed the IPv4 exhaustion out a few years. It was entirely reasonable to conclude that it would not have been a good use of anyone's time or money. Look at the bright side: you can use the money you didn't spend on 240/4 upgrades to buy slightly used IPv4 space on the grey market or CGN equipment. R's, John From josh at imaginenetworksllc.com Thu Jun 18 02:34:10 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 17 Jun 2015 22:34:10 -0400 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: <20150618021356.75689.qmail@ary.lan> References: <20150618021356.75689.qmail@ary.lan> Message-ID: How many devices need IPs? Is there a reason ARIN can't be used? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Jun 17, 2015 10:18 PM, "John Levine" wrote: > >IIRC, the short answer why it wasn't repurposed as additional unicast > >addresses was that too much deployed gear has it hardcoded as > >"reserved, future functionality unknown, do not use." Following an > >instruction to repurpose 240/4 as unicast addresses, such gear would > >not receive new firmware or obsolete out of use quickly enough to be > >worth the effort. > > More to the point, the amount of work required to fix all the existing > equipment to handle 240/4 would not be a lot less than the work > required to get it to handle IPv6, and it would only have pushed the > IPv4 exhaustion out a few years. It was entirely reasonable to > conclude that it would not have been a good use of anyone's time or > money. > > Look at the bright side: you can use the money you didn't spend on > 240/4 upgrades to buy slightly used IPv4 space on the grey market > or CGN equipment. > > R's, > John > From rfg at tristatelogic.com Thu Jun 18 02:57:27 2015 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 17 Jun 2015 19:57:27 -0700 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: Message-ID: <29821.1434596247@server1.tristatelogic.com> In message Tyler Mills wrote: >This is the government... you have to put on your bizarro-economics and >bizarro-ethics glasses for the State to make sense. > >It does not operate like a market. Failure results in people being >shuffled around, and larger budgets. Failure justifies more control and >power. People get taken down for political reasons, not based on a lack of >ability or lack of virtue. > >I would hope this measure succeeds and to see something meaningful come out >of it, I just don't see it happening. Thanks for your support. And yes, I agree that most probably nothing will come of this, but it is worth a try. Consider this, if even just one out of every forty (1/40) of the affected 4+ million (now hopefully pissed off) federal workers signs this petition then it will get past the 100,000 signature point and then the Whitehouse will HAVE to respond to it. Of course, even in that case, the WH might very well just put off their response, you know, until that proverbial "cold day in hell"... just as they have done, and continue to do, with the "Pardon Snowden" petition... however as it that case, their mere lack of response... basically ignoring their own rules which they made for themselves relating to these petitions... would itself call more attention to their utter failure, not only to prevent such breaches, but to even deal with them in a sensible way afterwards. (If this utterly unqualified ethnic-checkbox woman had done this in the private sector, there's no doubt that her ass would be out the door already. As far as I have been able to tell in my limited research, she never managed _anything_ in her life before being named as the head of OPM... not even a Denny's... with the only possible exception being that she may have managed some portion of the President's re-election campaign.) Regards, rfg P.S. I just learned that the story on this breach is even worse than I already thought it was when I started the petition. From ArsTechnica: http://arstechnica.com/security/2015/06/encryption-would-not-have-helped-at-opm-says-dhs-official/ ... A consultant who did some work with a company contracted by OPM to manage personnel records for a number of agencies told Ars that he found the Unix systems administrator for the project "was in Argentina and his co-worker was physically located in the [People's Republic of China]. Both had direct access to every row of data in every database: they were root. Another team that worked with these databases had at its head two team members with PRC passports. I know that because I challenged them personally and revoked their privileges. From my perspective, OPM compromised this information more than three years ago and my take on the current breach is 'so what's new?'" Un-bleeping believable! There's nothing else that I can say about the quote above... at least nothing else that I can say in polite company. From jfbeam at gmail.com Thu Jun 18 05:18:24 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 18 Jun 2015 01:18:24 -0400 Subject: Is it safe to use 240.0.0.0/4 In-Reply-To: References: Message-ID: On Wed, 17 Jun 2015 21:17:53 -0400, Ca By wrote: > https://tools.ietf.org/html/draft-wilson-class-e-02 > > Proposed and denied. Please stop this line and spend your efforts on ipv6 By APNIC. Cisco did, too, btw. And they weren't first, either. Nor is this going to be the last time someone suggests it. To paraphrase Curran (since he's not popping by to say it), it's a lot of work that ultimately yields a small amount of space that's STILL going to run out. 16 /8's won't fix the problem. Just deploy IPv6 already. Sure, there's plenty to complain about -- and we do complain! -- but it's what we have. --Ricky From rfg at tristatelogic.com Thu Jun 18 06:14:25 2015 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 17 Jun 2015 23:14:25 -0700 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted Message-ID: <30529.1434608065@server1.tristatelogic.com> Harry Hoffman hhoffman at ip-solutions.net wrote: >I think it would be great if you were to include some source links in >your petition/email so that folks unaware of the specifics can educate >themselves in a non-partisan and factual manner. Well, as regards to the petition itself, I can't because now it is cast in stone and can't be edited, I think, which is too bad, because I slightly misspelled the lady's name. It is Katherine Archuleta, not Katherine Archueta. :-( But more to the point, they only give you a VERY limited number of characters to state what your petition is asking for, so there's really not room for much in the way of links within the petition itself. But elsewise, I'll give a few good links here, but really if you just go to Google News and search for "OPM breach" you will find one hell of a lot of VERY fresh news reports. =============================================================================== Fed Agency blames giant hack on 'neglected' security systems http://www.usnews.com/news/politics/articles/2015/06/16/cybertheft-of-personnel-info-rips-hole-in-espionage-defenses (Executive Summary: 4.2 mellion federal personel records stolen - OPM was warned, repeatedly, FOR YEARS that systems were insecure and didn't do squat.) =============================================================================== Military clearance OPM data breach 'absolute calamity' http://www.navytimes.com/story/military/2015/06/17/sf-86-security-clearance-breach-troops-affected-opm/28866125/ (Executive Summary: Literally MILLIONS of detailed security clearance files were taken... quote: "everyone's".) =============================================================================== OPM Hack Probe Hindered Because Digital Trail Has Been Erased, US Official Says http://abcnews.go.com/US/opm-hack-probe-hindered-digital-trail-erased-us/story?id=31784335 (Executive Summary: They don't know how long this lasted or even what really happened because they over-write their log files every 60 days) =============================================================================== Will anyone at OPM be fired for not preventing this catastrophic mega-hack by China? http://hotair.com/archives/2015/06/16/will-anyone-at-opm-be-fired-for-not-preventing-this-catastrophic-mega-hack-by-china/ Nope! In fact, Whitehouse has already come out expressing confidence in the OPM Director, Katherine Archuleta: http://thehill.com/policy/cybersecurity/245294-obama-has-confidence-in-opm-director-despite-hack =============================================================================== Catching Up on the OPM Breach - Krebs On Security http://krebsonsecurity.com/2015/06/catching-up-on-the-opm-breach/ (Detailed timeline of the MANY screw-ups) =============================================================================== And last but by no means least, we have ArsTechnica's most recent contribution to the news coverage, it which the following UNBELIEVEABLE insanity is revealed: Encryption would not have helped" at OPM, says DHS official http://arstechnica.com/security/2015/06/encryption-would-not-have-helped-at-opm-says-dhs-official/ ... A consultant who did some work with a company contracted by OPM to manage personnel records for a number of agencies told Ars that he found the Unix systems administrator for the project "was in Argentina and his co-worker was physically located in the [People's Republic of China]. Both had direct access to every row of data in every database: they were root. Another team that worked with these databases had at its head two team members with PRC passports. I know that because I challenged them personally and revoked their privileges. From my perspective, OPM compromised this information more than three years ago and my take on the current breach is 'so what's new?'" Yea. Right. If you are trying to keep foreign nationals out of your "secure" system, then encryption quite certainly WILL NOT HELP if you have already given them root. Regards, rfg P.S. Regadless of your politics or what you think of Snowden, THIS INCIDENT is VASTLY WORSE that any leak that Snowden participated in. At least he and the reporters he worked with tried to exercise some discretion, and did not leak any personal details about any specific U.S. government employees. In the case of this massive OPM hack however, the incompetents in charge of OPM gave unknown foreign enemies EVERYTHING... enough data and personal dirt on millions of federal employees... including active service members and intelligence operatives... to allow them, our enemies, to engage in virtually unlimited blackmailing and spear-phishing of our people until the Second Coming. For those who were worriedly waiting for the much-predicted "Digital Pearl Harbor" attack on this country... well... you don't have to fret about THAT anymore, because this is it. It's already happened. And we did it to ourselves. P.P.S. Here is OPM Director Katherine Archuleta's personal biography. Executive Summary: She a long-time Democratic Party political hack with nothing other than a Master's degree in Education. (Still, isn't it comforting to know that "As a long-time public servant, she is a champion of Federal employees" ?) https://www.opm.gov/about-us/our-people-organization/senior-staff-bios/katherine-archuleta/print-bio.pdf P,P.P.S. Here's a nice clear explanation of how/why she got the job as the Director of the Office of Personel Management, overseeing the safety and security of millions of confidential federal government employee files and the people behind them: http://www.nationaljournal.com/decision-makers/government-operations/katherine-archuleta-director-designate-20130718 July 18, 2013 - Even before President Obama nominated Archuleta to be director of OPM in late May, word leaked to the Washington press corps that the White House was intent on choosing a Hispanic. Both Interior Secretary Ken Salazar and Labor Secretary Hilda Solis had resigned from the Obama administration, and groups such as the National Council of La Raza had chided the president for nominating only one Hispanic to a Cabinet-level position in his second term. Enter Archuleta, who helped engineer the president's reelection win as Obama for America's national political director. Not only is she Latina, but Archuleta also hails from the swing state of Colorado, where Democrats have made inroads in recent years. If she is confirmed as OPM director, the 64-year-old will be the first Hispanic to hold that position. ... From listas at kurtkraut.net Thu Jun 18 08:13:19 2015 From: listas at kurtkraut.net (Kurt Kraut) Date: Thu, 18 Jun 2015 05:13:19 -0300 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: Ray, "Anycast is generally not well-suited for stateful connectivity (e.g. most things TCP)." I don't know anything that would support that claim. I have been using for years BGP anycast for audio and video streaming, always in TCP (RTMP, HLS, WMS, and even the good and old ShoutCast) and works like a charm. And this is the 'secret sauce' of the company I work for, the thing we do better than our competitors that make our users happy and never wanting to leave us: anycast. We have customers that are TV stations and stream 24x7x365 their content and they have watchers getting their streaming also 24x7x365 (like waiting rooms, airports) with no complaints or instability. Best regards, Kurt Kraut 2015-06-17 16:13 GMT-03:00 Ray Soucy : > Anycast is generally not well-suited for stateful connectivity (e.g. most > things TCP). The use case for anycast is restricted to simple > challenge-response protocol design. > > As such, you typically only see it leveraged for simple services (e.g. DNS, > NTP). > > The reason for this, as you suspect, is you can never guarantee that the > path and thus the server will remain consistent across client connections. > > Ideally you can leverage DNS to provide a response to a unicast resource > rather than trying to make the service itself anycast. DNS can be anycast, > and DNS can provide different responses based on geographical location, but > these can happen independently or together. > > As you still want failover, you might opt to announce the MX record with > the priorities reversed but still pointing to each server. For example MX > 10 server1, MX 20 server2 on one side, and MX 10 server2, MX 20 server1 on > the other. > > Typically you would use a DNS load balancer rather than simple anycast DNS > to achieve this though. > > > On Mon, Jun 15, 2015 at 1:50 PM, Joe Hamelin wrote: > > > I have a mail system where there are two MX hosts, one in the US and one > in > > Europe. Both have a DNS MX record metric of 10 so a bastardized > > round-robin takes place. This does not work so well when one site goes > > down. My solution will be to place a load balancer in a hosting site > > (virtual, of course) and have it provide HA. But what about HA for the > > LB? At first glance anycasting would seem to be a great idea but there > is > > a problem of broken sessions when routes change. > > > > Have any of you seen something like this work in the wild? > > > > > > -- > > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > > > > > -- > 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 morrowc.lists at gmail.com Thu Jun 18 08:22:51 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 18 Jun 2015 04:22:51 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: On Thu, Jun 18, 2015 at 4:13 AM, Kurt Kraut via NANOG wrote: > Ray, > > > "Anycast is generally not well-suited for stateful connectivity (e.g. most > things TCP)." > > I don't know anything that would support that claim. I have been using for > years BGP anycast for audio and video streaming, always in TCP (RTMP, HLS, > WMS, and even the good and old ShoutCast) and works like a charm. And this > is the 'secret sauce' of the company I work for, the thing we do better > than our competitors that make our users happy and never wanting to leave > us: anycast. > > We have customers that are TV stations and stream 24x7x365 their content > and they have watchers getting their streaming also 24x7x365 (like waiting > rooms, airports) with no complaints or instability. most of this conversation is a distraction from the OP's question though... since his core problem is: "Broken mta behaviour" and won't really be solved with anycast/etc. TCP anycast seems to work just fine, agreed. UDP anycast seems to work just fine, agreed. any anycast deployment has it's warts, understanding that and them will make operations and services smoother. From rps at maine.edu Thu Jun 18 11:51:37 2015 From: rps at maine.edu (Ray Soucy) Date: Thu, 18 Jun 2015 07:51:37 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: I gave a pretty broad answer because the question was about hosting mail servers using anycast. I don't think what I was getting at in regards to stateful vs. stateless was incorrect, but I was talking about the application level not the nature of the protocol and throwing TCP in there confused the issue (I wasn't talking about TCP itself as a stateful protocol; notice I said "most things"). You can certainly do anycast with TCP, and for small stateless services it can be effective. You can't do anycast for a stateful application without taking the split-brain problem into account. The entire CDN model was developed with anycast in mind, so yes, I'm sure it does work quite well. It generally fits the description of a stateless service, and if it does implement a stateful service it's designed such that nodes have a method of sharing information (perhaps using an eventually consistent model). Taking a normal application, like mail or a dynamic website, and just using anycast for load balancing without designing the service with the anycast model in mind is probably not a good idea. You need to expect that the same user could access different systems, and design for that. The real point here is the problem OP is describing should be easily handled by having proper MX records, and getting into anycast for mail is likely not the right choice (unless maybe your goal is to be really efficient at SPAM). I'd like to know more on what problems he's seeing. On Thu, Jun 18, 2015 at 4:13 AM, Kurt Kraut wrote: > Ray, > > > "Anycast is generally not well-suited for stateful connectivity (e.g. most > things TCP)." > > I don't know anything that would support that claim. I have been using for > years BGP anycast for audio and video streaming, always in TCP (RTMP, HLS, > WMS, and even the good and old ShoutCast) and works like a charm. And this > is the 'secret sauce' of the company I work for, the thing we do better > than our competitors that make our users happy and never wanting to leave > us: anycast. > > We have customers that are TV stations and stream 24x7x365 their content > and they have watchers getting their streaming also 24x7x365 (like waiting > rooms, airports) with no complaints or instability. > > > Best regards, > > > Kurt Kraut > > 2015-06-17 16:13 GMT-03:00 Ray Soucy : > >> Anycast is generally not well-suited for stateful connectivity (e.g. most >> things TCP). The use case for anycast is restricted to simple >> challenge-response protocol design. >> >> As such, you typically only see it leveraged for simple services (e.g. >> DNS, >> NTP). >> >> The reason for this, as you suspect, is you can never guarantee that the >> path and thus the server will remain consistent across client connections. >> >> Ideally you can leverage DNS to provide a response to a unicast resource >> rather than trying to make the service itself anycast. DNS can be >> anycast, >> and DNS can provide different responses based on geographical location, >> but >> these can happen independently or together. >> >> As you still want failover, you might opt to announce the MX record with >> the priorities reversed but still pointing to each server. For example MX >> 10 server1, MX 20 server2 on one side, and MX 10 server2, MX 20 server1 on >> the other. >> >> Typically you would use a DNS load balancer rather than simple anycast DNS >> to achieve this though. >> >> >> On Mon, Jun 15, 2015 at 1:50 PM, Joe Hamelin wrote: >> >> > I have a mail system where there are two MX hosts, one in the US and >> one in >> > Europe. Both have a DNS MX record metric of 10 so a bastardized >> > round-robin takes place. This does not work so well when one site goes >> > down. My solution will be to place a load balancer in a hosting site >> > (virtual, of course) and have it provide HA. But what about HA for the >> > LB? At first glance anycasting would seem to be a great idea but there >> is >> > a problem of broken sessions when routes change. >> > >> > Have any of you seen something like this work in the wild? >> > >> > >> > -- >> > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 >> > >> >> >> >> -- >> 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 jabley at hopcount.ca Thu Jun 18 13:08:13 2015 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 18 Jun 2015 09:08:13 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: On 18 Jun 2015, at 7:51, Ray Soucy wrote: > You can certainly do anycast with TCP, and for small stateless > services it > can be effective. You can't do anycast for a stateful application > without > taking the split-brain problem into account. It's really difficult to apply broad "can" or "can't", "works" or "doesn't work" advice here since there really are no absolutes. What works and what doesn't depends on the intersection between theory and practice (including other peoples' networks), and is broader than the architectural decision to use or not use anycast. The text I pasted much earlier from RFC 4786 was a result of a lot of discussion (and more than a handful of objections to our attempts to answer this question, and to the document as a whole existing at all). In the general, mathematical sense, it's never safe to use anycast with TCP; "safe" here means "entirely safe in all circumstances". Since we live on the Internet, we know nowhere is safe, so this answer is unsatisfying and doesn't help us make real-world decisions. In the pragmatic, throw it at the wall and see what sticks sense, it's usually fine to use anycast with TCP; "usually" means things like "pretty sure I remember this working just fine at my last job" and "in our very particular situation the helpdesk phone didn't seem to ring". There's usually very little science attached to this answer, either in terms of comprehensive data about failures or in terms of characterising the precise environment and considering the ways in which it is similar or dissimilar to others. If anycast is being considered as part of a solution to a particular problem, we might consider an answer of the form "anycast, when it works, is expected to solve that problem; anycast might introduce new problems, though, so we also need to think about a fall-back to a situation where the old problems are reintroduced but the new ones are gone". This kind of fudges around the difficulty in confidently enumerating all the new problems with an anticipation that anycast will work enough of the time to make it worth using at all. So, in the example at hand, using an MX RRSet that tries first to deliver to an SMTP service that is distributed using anycast but will fall back to SMTP service that is not might be a reasonable approach, e.g. $ORIGIN QUIRKAFLEEG.ORG. @ MX 10 ANY.MX ; service provided at DEFRA, NLAMS, USIAD, HKHKG MX 20 DEFRA.MX ; service provided just at DEFRA MX 20 NLAMS.MX ; service provided just at NLAMS MX 20 USIAD.MX ; service provided just at USIAD MX 20 HKHKG.MX ; service provided just at HKHKG. so a client will first attempt to deliver to ANY.MX.QUIRKAFLEEG.ORG, and if that fails we'll try one of the others. For this particular question I still think that geoip/dns is a more straightforward approach, since it avoids the possible timeout and retry behaviour of the client that might delay delivery of mail in the event that the anycast MX is unavailable. Joe From ben at meh.net.nz Thu Jun 18 13:59:01 2015 From: ben at meh.net.nz (Ben) Date: Fri, 19 Jun 2015 01:59:01 +1200 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: <20150618135901.GB16760@meh.net.nz> On Thu, Jun 18, 2015 at 09:08:13AM -0400, Joe Abley wrote: > On 18 Jun 2015, at 7:51, Ray Soucy wrote: > > >You can certainly do anycast with TCP, and for small stateless services it > >can be effective. You can't do anycast for a stateful application without > >taking the split-brain problem into account. > > It's really difficult to apply broad "can" or "can't", "works" or "doesn't > work" advice here since there really are no absolutes. What works and what > doesn't depends on the intersection between theory and practice (including > other peoples' networks), and is broader than the architectural decision to > use or not use anycast. > > The text I pasted much earlier from RFC 4786 was a result of a lot of > discussion (and more than a handful of objections to our attempts to answer > this question, and to the document as a whole existing at all). > > In the general, mathematical sense, it's never safe to use anycast with TCP; > "safe" here means "entirely safe in all circumstances". Since we live on the > Internet, we know nowhere is safe, so this answer is unsatisfying and > doesn't help us make real-world decisions. > > In the pragmatic, throw it at the wall and see what sticks sense, it's > usually fine to use anycast with TCP; "usually" means things like "pretty > sure I remember this working just fine at my last job" and "in our very > particular situation the helpdesk phone didn't seem to ring". There's > usually very little science attached to this answer, either in terms of > comprehensive data about failures or in terms of characterising the precise > environment and considering the ways in which it is similar or dissimilar to > others. I think the single greatest issue with anycast is people relying too much on anycast where traffic falls over in a certain location, say with blackholing, and there's no easy/quick fallback. Like two dns servers for a domain both served in the same location on anycast. But that can happen without anycast too.. > If anycast is being considered as part of a solution to a particular > problem, we might consider an answer of the form "anycast, when it works, is > expected to solve that problem; anycast might introduce new problems, > though, so we also need to think about a fall-back to a situation where the > old problems are reintroduced but the new ones are gone". This kind of > fudges around the difficulty in confidently enumerating all the new problems > with an anticipation that anycast will work enough of the time to make it > worth using at all. > > So, in the example at hand, using an MX RRSet that tries first to deliver to > an SMTP service that is distributed using anycast but will fall back to SMTP > service that is not might be a reasonable approach, e.g. > > $ORIGIN QUIRKAFLEEG.ORG. > > @ MX 10 ANY.MX ; service provided at DEFRA, NLAMS, USIAD, HKHKG > MX 20 DEFRA.MX ; service provided just at DEFRA > MX 20 NLAMS.MX ; service provided just at NLAMS > MX 20 USIAD.MX ; service provided just at USIAD > MX 20 HKHKG.MX ; service provided just at HKHKG. > > so a client will first attempt to deliver to ANY.MX.QUIRKAFLEEG.ORG, and if > that fails we'll try one of the others. I think that is the most prudent advice, if using anycast, have a fallback. But following this thread there's something that's been left unsaid, and that no-one seems to have mentioned. If there's two MX hosts that can most likely receive mail for users in either location, and of them is unreliable, then what happens when that unreliable one receives an email and can't pass it onto the relevant place. One solution is to segregate email into location dependent domains, and just have the right email go to the right location. But if wanting to pick and choose what to send on, it might make sense to proxy all the emails to the destination, so that if email is coming in the dodgy location, and being forwarded to the less dodgy location and the connection breaks mid connection the message can be resent and hopefully hit the less dodgy location. And I think in some ways what might make more sense is to get some alternate path connectivity in the dodgy location if it's just backhaul that's failing. > For this particular question I still think that geoip/dns is a more > straightforward approach, since it avoids the possible timeout and retry > behaviour of the client that might delay delivery of mail in the event that > the anycast MX is unavailable. For availability without a high amount of performance necessary I think that geoip/dns is probably a better solution than anycast. But if wanting to sidetrack a little, I think that anycasting, or even moving mail servers closer to the user isn't happening much yet. And in a way terminating close to the input of network, and proxying to a relevant location seems to me a way that could incorporate some smarts without having to hold e-mail close to the edge, and slightly improve mail delivery performance for larger emails. So the proxy would hold mappings of user to location, then open up a connection masquerading as the users original source for any acl's, rate limiting or such. And if the connection from the edge to the mail server breaks, then another connection directly to the relevant location may work. Ben. From ag4ve.us at gmail.com Thu Jun 18 15:00:00 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 18 Jun 2015 11:00:00 -0400 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: <29116.1434588870@server1.tristatelogic.com> References: <29116.1434588870@server1.tristatelogic.com> Message-ID: On Jun 17, 2015 8:56 PM, "Ronald F. Guilmette" wrote: > > > *) The Director of the Office of Personnel Management, Ms. Katherine > Archueta was warned, repeatedly, and over several years, by her > own department's Inspector General (IG) that many of OPM's systems > were insecure and should be taken out of service. Nontheless, as > reveled during congressional testimony yesterday, she overruled > and ignored this advice and kept the systems online. > > Given the above facts, I've just started a new Whitehouse Petition, asking > that the director of OPM, Ms. Archueta, be fired for gross incompetence. > I _do_ understand that the likelihood of anyone ever getting fired for > incompetence anywhere within the Washington D.C. Beltway is very much of > a long shot, based on history, but I nontheless feel that as a U.S. > citizen and taxpayer, I at least want to make my opinion of this matter > known to The Powers That Be. > Idk whether she was wrong or not. They were running "COBOL" systems - I'm guessing AS/400 (maybe even "newer" zSeries) which are probably supporting some db2 apps. They also mention this is on a flat network. So stopping the hack once it was found was probably real interesting (I'm kinda impressed they minimized downtime as much as they did really). I'm ok saying they were incompetent but not too sure you can do *this* much to mess up a network in <2 years (her tenure). I'd actually be interested in a discussion of how much you can possibly improve / degrade on a network that big from a management position. If the argument is that she should've shut down the network or parts of it - I wonder if anyone of you who run Internet providers would even shut down your email or web servers when, say, heartbleed came out - those services aren't even a main part of your business. One could argue that it would've been illegal for her to shut some of that stuff down without an act of Congress. I'm not saying you're dead wrong. Just that I don't have enough information to say you're right (and if you are, she's probably not the only head you should call for). From josh at imaginenetworksllc.com Thu Jun 18 15:58:25 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 18 Jun 2015 11:58:25 -0400 Subject: Google Apps for ISPs Message-ID: If anyone can message me off list it would be great. We were originally told the service would be shut off in July. All of the accounts were disabled June 9. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 From khelms at zcorum.com Thu Jun 18 16:12:36 2015 From: khelms at zcorum.com (Scott Helms) Date: Thu, 18 Jun 2015 12:12:36 -0400 Subject: Google Apps for ISPs In-Reply-To: References: Message-ID: We worked with dozens of service providers to get their email services migrated, AFAIK no one got an extension. I was told directly that it was possible to have an extension because Google was pulling down the entire system. I'd advise: 1) Make sure your domain TTL's are fairly low so you can change your MX record and have the world get that update shortly there after. 2) Find an alternative email provider, preferably someone who has done transitions to and from Google before. 3) Start communicating with your customers, AFAIK their email, address books, and calendars aren't available and won't be. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Jun 18, 2015 at 11:58 AM, Josh Luthman wrote: > If anyone can message me off list it would be great. > > We were originally told the service would be shut off in July. All of the > accounts were disabled June 9. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > From josh at imaginenetworksllc.com Thu Jun 18 16:32:27 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 18 Jun 2015 12:32:27 -0400 Subject: Google Apps for ISPs In-Reply-To: References: Message-ID: That's all we're after, customers' emails. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Jun 18, 2015 12:12 PM, "Scott Helms" wrote: > We worked with dozens of service providers to get their email services > migrated, AFAIK no one got an extension. I was told directly that it was > possible to have an extension because Google was pulling down the entire > system. I'd advise: > > 1) Make sure your domain TTL's are fairly low so you can change your MX > record and have the world get that update shortly there after. > > 2) Find an alternative email provider, preferably someone who has done > transitions to and from Google before. > > 3) Start communicating with your customers, AFAIK their email, address > books, and calendars aren't available and won't be. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Thu, Jun 18, 2015 at 11:58 AM, Josh Luthman < > josh at imaginenetworksllc.com> wrote: > >> If anyone can message me off list it would be great. >> >> We were originally told the service would be shut off in July. All of the >> accounts were disabled June 9. >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> > > From cryptographrix at gmail.com Thu Jun 18 16:34:46 2015 From: cryptographrix at gmail.com (Cryptographrix) Date: Thu, 18 Jun 2015 16:34:46 +0000 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: References: <29116.1434588870@server1.tristatelogic.com> Message-ID: Have to agree with Shawn on this. If you watch her testimony in front of Congress, it is clear that she was completely flustered at the inability to hire competent people, and the lack of her superiors to prioritize the modernization project she had so passionately advocated for. When I've worked for organizations larger than - say - four or five office locations in diverse parts of the U.S., I've started to see how difficult it can become to get all of them to coordinate on *anything*, and I'm not even talking government here. >From the sound of it, she ran into the ceiling of available workers that were willing to work for the pay grade that the government offers for those positions, which is usually much less than private industry offers and - as a consequence - they are not nearly as familiar with migrations of that size. I do not envy her position, and doubt in the ability of anyone in her position to do more than she has attempted. Give her some credit. On Thu, Jun 18, 2015 at 11:02 AM shawn wilson wrote: > On Jun 17, 2015 8:56 PM, "Ronald F. Guilmette" > wrote: > > > > > > > *) The Director of the Office of Personnel Management, Ms. Katherine > > Archueta was warned, repeatedly, and over several years, by her > > own department's Inspector General (IG) that many of OPM's > systems > > were insecure and should be taken out of service. Nontheless, as > > reveled during congressional testimony yesterday, she overruled > > and ignored this advice and kept the systems online. > > > > Given the above facts, I've just started a new Whitehouse Petition, > asking > > that the director of OPM, Ms. Archueta, be fired for gross incompetence. > > I _do_ understand that the likelihood of anyone ever getting fired for > > incompetence anywhere within the Washington D.C. Beltway is very much of > > a long shot, based on history, but I nontheless feel that as a U.S. > > citizen and taxpayer, I at least want to make my opinion of this matter > > known to The Powers That Be. > > > > Idk whether she was wrong or not. They were running "COBOL" systems - I'm > guessing AS/400 (maybe even "newer" zSeries) which are probably supporting > some db2 apps. They also mention this is on a flat network. So stopping the > hack once it was found was probably real interesting (I'm kinda impressed > they minimized downtime as much as they did really). > > I'm ok saying they were incompetent but not too sure you can do *this* much > to mess up a network in <2 years (her tenure). I'd actually be interested > in a discussion of how much you can possibly improve / degrade on a network > that big from a management position. > > If the argument is that she should've shut down the network or parts of it > - I wonder if anyone of you who run Internet providers would even shut down > your email or web servers when, say, heartbleed came out - those services > aren't even a main part of your business. One could argue that it would've > been illegal for her to shut some of that stuff down without an act of > Congress. > > I'm not saying you're dead wrong. Just that I don't have enough information > to say you're right (and if you are, she's probably not the only head you > should call for). > From khelms at zcorum.com Thu Jun 18 16:36:54 2015 From: khelms at zcorum.com (Scott Helms) Date: Thu, 18 Jun 2015 12:36:54 -0400 Subject: Google Apps for ISPs In-Reply-To: References: Message-ID: Josh, >From what I have been able to see from an outsider's point of view, they tore down the virtual machines that held those emails and while I doubt they scrubbed the hard drives, they're not available in "commercially reasonable way". No ISP I've worked with has been able to get access to emails, settings, address books, or anything else since early in June and that's not from lack of trying. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Jun 18, 2015 at 12:32 PM, Josh Luthman wrote: > That's all we're after, customers' emails. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Jun 18, 2015 12:12 PM, "Scott Helms" wrote: > >> We worked with dozens of service providers to get their email services >> migrated, AFAIK no one got an extension. I was told directly that it was >> possible to have an extension because Google was pulling down the entire >> system. I'd advise: >> >> 1) Make sure your domain TTL's are fairly low so you can change your MX >> record and have the world get that update shortly there after. >> >> 2) Find an alternative email provider, preferably someone who has done >> transitions to and from Google before. >> >> 3) Start communicating with your customers, AFAIK their email, address >> books, and calendars aren't available and won't be. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Thu, Jun 18, 2015 at 11:58 AM, Josh Luthman < >> josh at imaginenetworksllc.com> wrote: >> >>> If anyone can message me off list it would be great. >>> >>> We were originally told the service would be shut off in July. All of the >>> accounts were disabled June 9. >>> >>> Josh Luthman >>> Office: 937-552-2340 >>> Direct: 937-552-2343 >>> 1100 Wayne St >>> Suite 1337 >>> Troy, OH 45373 >>> >> >> From bill at herrin.us Thu Jun 18 16:58:44 2015 From: bill at herrin.us (William Herrin) Date: Thu, 18 Jun 2015 12:58:44 -0400 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: <29116.1434588870@server1.tristatelogic.com> References: <29116.1434588870@server1.tristatelogic.com> Message-ID: On Wed, Jun 17, 2015 at 8:54 PM, Ronald F. Guilmette wrote: > My apologies in advance to any here who might feel that this is off > topic... I don't personally believe that it is. Frankly, I don't > know of that many mailing lists where the subscribers are likely to > care as much about network security (and/or the lack thereof) as the > membership of this list does. > By now, most of you will have read about the massive federal data breach > at the U.S. Government's Office of Personnel Management (OPM), and also > the fact that (by OPM's own preliminary estimates) this massive data breach > affects at least four million federal government employees... Hi Ronald, I'm of the opinion that the whole thing is your fault. The security inadequacies of your network are obviously what allowed the Chinese Super Hackers to break in with their false BGP advertisements and source address spoofing. Well, maybe not, but just imagine if that was true: your post would be on-topic for the mailing list! Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From Valdis.Kletnieks at vt.edu Thu Jun 18 17:11:24 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 18 Jun 2015 13:11:24 -0400 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: Your message of "Thu, 18 Jun 2015 16:34:46 -0000." References: <29116.1434588870@server1.tristatelogic.com> Message-ID: <7303.1434647484@turing-police.cc.vt.edu> On Thu, 18 Jun 2015 16:34:46 -0000, Cryptographrix said: > From the sound of it, she ran into the ceiling of available workers that > were willing to work for the pay grade that the government offers for those > positions, which is usually much less than private industry offers and - as > a consequence - they are not nearly as familiar with migrations of that > size. > I do not envy her position, and doubt in the ability of anyone in her > position to do more than she has attempted. > Give her some credit. Look at the average lifespan of heads of cybersecurity in the federal space - they don't seem to last more than 18-24 months before their foreheads are permanently damaged from banging against the wall... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From rs at seastrom.com Thu Jun 18 17:34:54 2015 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 18 Jun 2015 13:34:54 -0400 Subject: Anycast provider for SMTP? In-Reply-To: (Ray Soucy's message of "Thu, 18 Jun 2015 07:51:37 -0400") References: Message-ID: <86oakc7we9.fsf@valhalla.seastrom.com> Ray Soucy writes: > You can certainly do anycast with TCP, and for small stateless services it > can be effective. You can't do anycast for a stateful application without > taking the split-brain problem into account. In my experience, the thing that makes anycast work *well* is having the concept of a Plan B baked into some-layer-above-4. That creates the ability to recovery gracefully in the corner case when a routing change causes your session to blow up. Choice of layer 4 protocol doesn't really enter into it, nor does the length of time that the layer 4 session exists (in the case of UDP, generally 2 packets; in the case of TCP, somewhat longer). Shorter sessions have a lower likelihood of losing, due to shorter exposure time, but even for a single-packet-each-way UDP transaction the time (and the risk) is not 0. People of course use anycast for DNS. Personal experience shows that it also seems to work great for HLS video streaming. I'd imagine it would work fine for email too, since the whole concept of multi-level MX is a "plan-B-at-higher-level" thing. > The entire CDN model was developed with anycast in mind, Not really; practical application of anycast was nascent when US 6,108,703 (the "Akamai patent", which centered around DNS) was filed. A brief history of anycast is at https://tools.ietf.org/html/draft-mcpherson-anycast-arch-implications-00 section 3. > Taking a normal application, like mail or a dynamic website, and just using > anycast for load balancing without designing the service with the anycast > model in mind is probably not a good idea. You need to expect that the > same user could access different systems, and design for that. For anything at scale, wherein one has multiple back end devices, one must already design for that. Designing consistency-synchronized systems that work over continental or global scale latency is left as an exercise to the implementer. > The real point here is the problem OP is describing should be easily > handled by having proper MX records, and getting into anycast for mail is > likely not the right choice (unless maybe your goal is to be really > efficient at SPAM). Probably originating outbound connections to arbitrary locations from an anycast locator is a step away from goodness. -r From nick at pelagiris.org Thu Jun 18 17:15:48 2015 From: nick at pelagiris.org (Nick B) Date: Thu, 18 Jun 2015 13:15:48 -0400 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: References: <29116.1434588870@server1.tristatelogic.com> Message-ID: Having worked for several departments like this, I can assure you her flustsration was not about her "inability to hire competent people" or "the lack of her superiors to prioritize the modernization project". Unless you have worked for the Federal Government it's almost impossible to understand the mindset - Politics is job #1, Office Politics is job #2, "doing your job" is not a priority. The issue here was 100% looking bad - the worst possible offense a political appointee can commit. Firing this one person is pointless, she's one of 1,000,000 clones, not a one should be employed. I wish I had some simple solution, but I don't, it's going to require years, probably decades, of hard work by a motivated and skilled team. Also, a stable of unicorns. Nick On Thu, Jun 18, 2015 at 12:34 PM, Cryptographrix wrote: > Have to agree with Shawn on this. > If you watch her testimony in front of Congress, it is clear that she was > completely flustered at the inability to hire competent people, and the > lack of her superiors to prioritize the modernization project she had so > passionately advocated for. > When I've worked for organizations larger than - say - four or five office > locations in diverse parts of the U.S., I've started to see how difficult > it can become to get all of them to coordinate on *anything*, and I'm not > even talking government here. > From the sound of it, she ran into the ceiling of available workers that > were willing to work for the pay grade that the government offers for those > positions, which is usually much less than private industry offers and - as > a consequence - they are not nearly as familiar with migrations of that > size. > I do not envy her position, and doubt in the ability of anyone in her > position to do more than she has attempted. > Give her some credit. > > On Thu, Jun 18, 2015 at 11:02 AM shawn wilson wrote: > > > On Jun 17, 2015 8:56 PM, "Ronald F. Guilmette" > > wrote: > > > > > > > > > > > *) The Director of the Office of Personnel Management, Ms. > Katherine > > > Archueta was warned, repeatedly, and over several years, by her > > > own department's Inspector General (IG) that many of OPM's > > systems > > > were insecure and should be taken out of service. Nontheless, > as > > > reveled during congressional testimony yesterday, she overruled > > > and ignored this advice and kept the systems online. > > > > > > Given the above facts, I've just started a new Whitehouse Petition, > > asking > > > that the director of OPM, Ms. Archueta, be fired for gross > incompetence. > > > I _do_ understand that the likelihood of anyone ever getting fired for > > > incompetence anywhere within the Washington D.C. Beltway is very much > of > > > a long shot, based on history, but I nontheless feel that as a U.S. > > > citizen and taxpayer, I at least want to make my opinion of this matter > > > known to The Powers That Be. > > > > > > > Idk whether she was wrong or not. They were running "COBOL" systems - I'm > > guessing AS/400 (maybe even "newer" zSeries) which are probably > supporting > > some db2 apps. They also mention this is on a flat network. So stopping > the > > hack once it was found was probably real interesting (I'm kinda impressed > > they minimized downtime as much as they did really). > > > > I'm ok saying they were incompetent but not too sure you can do *this* > much > > to mess up a network in <2 years (her tenure). I'd actually be interested > > in a discussion of how much you can possibly improve / degrade on a > network > > that big from a management position. > > > > If the argument is that she should've shut down the network or parts of > it > > - I wonder if anyone of you who run Internet providers would even shut > down > > your email or web servers when, say, heartbleed came out - those services > > aren't even a main part of your business. One could argue that it > would've > > been illegal for her to shut some of that stuff down without an act of > > Congress. > > > > I'm not saying you're dead wrong. Just that I don't have enough > information > > to say you're right (and if you are, she's probably not the only head you > > should call for). > > > From nanog at ics-il.net Thu Jun 18 17:26:25 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 18 Jun 2015 12:26:25 -0500 (CDT) Subject: Google Apps for ISPs In-Reply-To: Message-ID: <19853087.871.1434648406542.JavaMail.mhammett@ThunderFuck> There was an inquiry about this just the other day. They got theirs turned back on. Check the archives for the Google contact. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Scott Helms" To: "Josh Luthman" Cc: "NANOG list" Sent: Thursday, June 18, 2015 11:36:54 AM Subject: Re: Google Apps for ISPs Josh, >From what I have been able to see from an outsider's point of view, they tore down the virtual machines that held those emails and while I doubt they scrubbed the hard drives, they're not available in "commercially reasonable way". No ISP I've worked with has been able to get access to emails, settings, address books, or anything else since early in June and that's not from lack of trying. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Jun 18, 2015 at 12:32 PM, Josh Luthman wrote: > That's all we're after, customers' emails. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Jun 18, 2015 12:12 PM, "Scott Helms" wrote: > >> We worked with dozens of service providers to get their email services >> migrated, AFAIK no one got an extension. I was told directly that it was >> possible to have an extension because Google was pulling down the entire >> system. I'd advise: >> >> 1) Make sure your domain TTL's are fairly low so you can change your MX >> record and have the world get that update shortly there after. >> >> 2) Find an alternative email provider, preferably someone who has done >> transitions to and from Google before. >> >> 3) Start communicating with your customers, AFAIK their email, address >> books, and calendars aren't available and won't be. >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> On Thu, Jun 18, 2015 at 11:58 AM, Josh Luthman < >> josh at imaginenetworksllc.com> wrote: >> >>> If anyone can message me off list it would be great. >>> >>> We were originally told the service would be shut off in July. All of the >>> accounts were disabled June 9. >>> >>> Josh Luthman >>> Office: 937-552-2340 >>> Direct: 937-552-2343 >>> 1100 Wayne St >>> Suite 1337 >>> Troy, OH 45373 >>> >> >> From bill at herrin.us Thu Jun 18 17:35:34 2015 From: bill at herrin.us (William Herrin) Date: Thu, 18 Jun 2015 13:35:34 -0400 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: <29116.1434588870@server1.tristatelogic.com> References: <29116.1434588870@server1.tristatelogic.com> Message-ID: On Wed, Jun 17, 2015 at 8:54 PM, Ronald F. Guilmette wrote: > I've just started a new Whitehouse Petition, asking > that the director of OPM, Ms. Archueta, be fired for gross incompetence. Hi Ronald, The core problem here is that the Authority To Operate (ATO) process consumes essentially the entire activity of a USG computing project's security staff. The non-sensical compliance requirements, which if taken literally just about prevent you from ever connecting any computer to any other, get in the way of architecting systems around pragmatic and effective security. There's no use blaming the director for a broken system she's compelled to employ, one far out of her control. The next warmer of that seat is constrained to do no better. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From SNaslund at medline.com Thu Jun 18 18:11:32 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 18 Jun 2015 18:11:32 +0000 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: References: <29116.1434588870@server1.tristatelogic.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401C053065D@MUNPRDMBXA1.medline.com> Absolutely Bill, That is always the case with the government (I have worked with them a lot). They build lots and lots of procedure and process and dumb standards (mandatory POSIX compliance?!?!?, that was a good one) when step one would have been to get current firewall technology in place, have current operating systems, and patch known vulnerabilities (which is why you want the current operating systems). Instead, they go out and commission multi-million dollar consulting contract that spend time drawing up blueprints for the be-all end-all systems that no one is going to fund. When you look at the way the government goes about things like simply setting up the Healthcare website, it is miraculous that they even knew they got hacked. I will bet for every documented breech like this there are hundreds of continuous vulnerabilities being exploited that they don't even know about. These are just the weak ones that got caught. They still tend to look at these systems like their old mainframe based systems instead of looking at desktops, servers, and networks as separate independently upgradable parts. This makes all of their planning so massive that it can never be implemented so no one ever starts. Eventually the desktop OS gets too old to support, the servers have to stay compatible with the old desktops, the software application can't be upgraded because it does not run on the old database, etc etc etc... until the whole system collapses and you have to get the forklift. This director has nothing to do with it. I think they might need to eliminate some useless department and create or hire an IT organization that operates like a service provider to all of these agencies. Steve Naslund Chicago IL >Hi Ronald, > >The core problem here is that the Authority To Operate (ATO) process consumes essentially the entire activity of a USG computing project's security staff. The non-sensical compliance requirements, which if taken literally just about >prevent you from ever connecting any computer to any other, get in the way of architecting systems around pragmatic and effective security. > >There's no use blaming the director for a broken system she's compelled to employ, one far out of her control. The next warmer of that seat is constrained to do no better. > >Regards, >Bill Herrin From surfer at mauigateway.com Thu Jun 18 18:12:03 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 18 Jun 2015 11:12:03 -0700 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted Message-ID: <20150618111203.F274534D@m0005298.ppops.net> --- bill at herrin.us wrote: From: William Herrin The core problem here is that the Authority To Operate (ATO) process consumes essentially the entire activity of a USG computing project's security staff. The non-sensical compliance requirements, which if taken literally just about prevent you from ever connecting any computer to any other, get in the way of architecting systems around pragmatic and effective security. -------------------------------------------- "non-sensical compliance" Yeah, that. Pure, unmitigated insanity. scott From rfg at tristatelogic.com Thu Jun 18 18:31:51 2015 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 18 Jun 2015 11:31:51 -0700 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: Message-ID: <34434.1434652311@server1.tristatelogic.com> In message Cryptographrix wrote: >If you watch her testimony in front of Congress,... I did, actually. And it pissed me off so much that I started the petition (to get her fired). I encourage everybody to watch the video of her congressional testimony on Tuseday. She how she tries to stonewall simple questions like "Why wasn't the data encrypted?" >>From the sound of it, she ran into the ceiling of available workers that >were willing to work for the pay grade that the government offers for those >positions, which is usually much less than private industry offers and - as >a consequence - they are not nearly as familiar with migrations of that size. >I do not envy her position, and doubt in the ability of anyone in her >position to do more than she has attempted. >Give her some credit. I _do_ understand the point you are making. But if you are charged with the safekeeping of untold millions of extraordinarily detailed personal data files, and if you don't have the resources to do your job properly, wouldn't the Right Thing To Do be to either (a) resign in protest or else (b) at the very least send a letter to members of Congress telling them just how effed up things really are, so that they will understand what is at risk? This lady did neither, as far as I can tell. She just followed the first rule of government service: To get along, you go along. In most cases, that course of action would not have resulted in any great harm. But in this case the result was provably and absolutely catastrophic. If there were any justice in the world, Mr. Snowden would be back home in the U.S.A. now, and Ms. Archuleta would now be hiding out in Russia. Regards, rfg From jsklein at gmail.com Thu Jun 18 18:37:49 2015 From: jsklein at gmail.com (Joe Klein) Date: Thu, 18 Jun 2015 14:37:49 -0400 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: References: <29116.1434588870@server1.tristatelogic.com> Message-ID: Based on prior work in this space, the problems are as follows: 0. Political appointees don't stick around for long, therefore they can always point to the last guy as the problem. They are also gone, before impact of lack of security focus impact their jobs. 1. Executives and middle managers are not compensated or recognized for have secure systems, there for operations and missions take priority. This includes disabling all security if the operation requires it, and the PM justifies it. 2. Architecture of systems seldom includes a security architect from the beginning, with security added later at a substantial expense. 3. Test plans are inadequate and at times the wrong test plan for the technology being audited. 4. Third party contractor performing audits and assessments, are paid by the IT department to provide a favorable report, as quick as possible. To accomplish this, the testing is minimal, the qualifications of the staff are low, and the contractors PM has the ability to change findings to ensure the customer looks good. 5. System and network admins - they too are not compensated for secure system, only that the system are operating. This forces prioritizing operations over security. 6. Developers are not held accountable for secure code, and their contractors ignore the issues, even in the few instances where a security clause is included in the contract. 7. Many architectures are build around a security product, and not the risk profile. 8. Stovepipes - Many organization have competing political goals, and spend time CYA instead of making this secure by default. 9. Contractor staff training ? contractors promises training to customer facing staff, but instead never budget for that training. Instead the contract companies see this as OJT on the taxpayer dime. >From a game theory standpoint, it turns security always loses. Joe Klein "Inveniam viam aut faciam" On Thu, Jun 18, 2015 at 1:35 PM, William Herrin wrote: > On Wed, Jun 17, 2015 at 8:54 PM, Ronald F. Guilmette > wrote: > > I've just started a new Whitehouse Petition, asking > > that the director of OPM, Ms. Archueta, be fired for gross incompetence. > > Hi Ronald, > > The core problem here is that the Authority To Operate (ATO) process > consumes essentially the entire activity of a USG computing project's > security staff. The non-sensical compliance requirements, which if > taken literally just about prevent you from ever connecting any > computer to any other, get in the way of architecting systems around > pragmatic and effective security. > > There's no use blaming the director for a broken system she's > compelled to employ, one far out of her control. The next warmer of > that seat is constrained to do no better. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From surfer at mauigateway.com Thu Jun 18 18:42:06 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 18 Jun 2015 11:42:06 -0700 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted Message-ID: <20150618114206.F274573E@m0005298.ppops.net> --- rfg at tristatelogic.com wrote: From: "Ronald F. Guilmette" I _do_ understand the point you are making. But if you are charged with the safekeeping of untold millions of extraordinarily detailed personal data files, and if you don't have the resources to do your job properly, wouldn't the Right Thing To Do be to either (a) resign in protest or else (b) at the very least send a letter to members of Congress telling them just how effed up things really are, so that they will understand what is at risk? ----------------------------------------------------- As someone else said, you can't understand unless you've worked around it. From the statements you're making, it can be seen you haven't. The petition will not help and it's not just one person's fault. Try to stop continental drift. You'd have a better chance. scott From mikea at mikea.ath.cx Thu Jun 18 19:01:52 2015 From: mikea at mikea.ath.cx (mikea) Date: Thu, 18 Jun 2015 14:01:52 -0500 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: References: <29116.1434588870@server1.tristatelogic.com> Message-ID: <20150618190152.GC8477@mikea.ath.cx> On Thu, Jun 18, 2015 at 04:34:46PM +0000, Cryptographrix wrote: > Have to agree with Shawn on this. > If you watch her testimony in front of Congress, it is clear that she was > completely flustered at the inability to hire competent people, and the > lack of her superiors to prioritize the modernization project she had so > passionately advocated for. > When I've worked for organizations larger than - say - four or five office > locations in diverse parts of the U.S., I've started to see how difficult > it can become to get all of them to coordinate on *anything*, and I'm not > even talking government here. > >From the sound of it, she ran into the ceiling of available workers that > were willing to work for the pay grade that the government offers for those > positions, which is usually much less than private industry offers and - as > a consequence - they are not nearly as familiar with migrations of that > size. > I do not envy her position, and doubt in the ability of anyone in her > position to do more than she has attempted. > Give her some credit. She will have some large number of Civil Service Rockets "working", or at least on the TO&E below her: "Won't work; can't be fired." -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From ag4ve.us at gmail.com Thu Jun 18 19:06:58 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 18 Jun 2015 15:06:58 -0400 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: References: <29116.1434588870@server1.tristatelogic.com> Message-ID: On Thu, Jun 18, 2015 at 1:15 PM, Nick B wrote: > Having worked for several departments like this, I can assure you her > flustsration was not about her "inability to hire competent people" or "the > lack of her superiors to prioritize the modernization project". Unless you > have worked for the Federal Government it's almost impossible to understand > the mindset - Politics is job #1, Office Politics is job #2, "doing your > job" is not a priority. The issue here was 100% looking bad - the worst > possible offense a political appointee can commit. Firing this one person > is pointless, she's one of 1,000,000 clones, not a one should be employed. > I wish I had some simple solution, but I don't, it's going to require years, > probably decades, of hard work by a motivated and skilled team. Also, a > stable of unicorns. > Mmmm, most people (gov or private) do their jobs - the problem seems to be policy makers and getting money for things that no one is going to see (security). This has been a well documented issue in the private but idk anyone has realy said how bad gov is (I'd suspect worse than public at this point). My point was that idk you can blame someone for not implementing security in a place that big w/in 2 years. I'd've liked to have seen a roadmap, but I don't suppose you want your attackers to know that, so... From mr.jonas.bjork at me.com Thu Jun 18 19:43:25 2015 From: mr.jonas.bjork at me.com (=?utf-8?Q?Jonas_Bj=C3=B6rk?=) Date: Thu, 18 Jun 2015 21:43:25 +0200 Subject: Anycast provider for SMTP? In-Reply-To: <86oakc7we9.fsf@valhalla.seastrom.com> References: <86oakc7we9.fsf@valhalla.seastrom.com> Message-ID: While risking being slightly off topic: Does anyone use anycast dhcp servers? Have you run into any problems considering synching the leases? From jabley at hopcount.ca Thu Jun 18 19:51:31 2015 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 18 Jun 2015 15:51:31 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: <86oakc7we9.fsf@valhalla.seastrom.com> Message-ID: On 18 Jun 2015, at 15:43, Jonas Bj?rk wrote: > While risking being slightly off topic: Does anyone use anycast dhcp > servers? > Have you run into any problems considering synching the leases? Since DHCP uses broadcast and multicast addresses when a client is discovering a server, it's not obvious why you'd have to. You can run redundant sets of isc-dhcpd servers together serving the same broadcast domain and have them assign leases from the same address pools (at least, I've never tried it, but I was within internal mailing list range of the person maintaining that code and heard him shouting fairly often about it, not always in tones of rage and frustration). Was that what you were after? Joe From nick at foobar.org Thu Jun 18 19:54:38 2015 From: nick at foobar.org (Nick Hilliard) Date: Thu, 18 Jun 2015 20:54:38 +0100 Subject: Anycast provider for SMTP? In-Reply-To: References: <86oakc7we9.fsf@valhalla.seastrom.com> Message-ID: <558321FE.7060908@foobar.org> On 18/06/2015 20:51, Joe Abley wrote: > Since DHCP uses broadcast and multicast addresses when a client is > discovering a server, it's not obvious why you'd have to. most non trivial (i.e. routed networks) would use dhcp relay, in which case anycast dns could be argued to make some sense. TBH, the OP would be better off with multiple unicast installations with backup configured. Most decent quality dhcp implementations can operate in active/failover mode. Nick From baldur.norddahl at gmail.com Thu Jun 18 20:01:42 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 18 Jun 2015 22:01:42 +0200 Subject: Anycast provider for SMTP? In-Reply-To: References: <86oakc7we9.fsf@valhalla.seastrom.com> Message-ID: Den 18/06/2015 21.52 skrev "Joe Abley" : > > On 18 Jun 2015, at 15:43, Jonas Bj?rk wrote: > >> While risking being slightly off topic: Does anyone use anycast dhcp servers? >> Have you run into any problems considering synching the leases? > > > Since DHCP uses broadcast and multicast addresses when a client is discovering a server, it's not obvious why you'd have to. Because clients will switch to unicast for renewal. Also clients will stay with the current server forever, so you might have a bad distribution of load between the servers. If one server was down everyone will switch to the other and never go back until forced. Regards Baldur From mr.jonas.bjork at me.com Thu Jun 18 21:25:14 2015 From: mr.jonas.bjork at me.com (=?utf-8?Q?Jonas_Bj=C3=B6rk?=) Date: Thu, 18 Jun 2015 23:25:14 +0200 Subject: Anycast provider for SMTP? In-Reply-To: References: <86oakc7we9.fsf@valhalla.seastrom.com> Message-ID: > Because clients will switch to unicast for renewal. Also clients will stay > with the current server forever, so you might have a bad distribution of > load between the servers. If one server was down everyone will switch to > the other and never go back until forced. Why wouldn't they go back to the nearest server when it comes back online? > Regards > Baldur From larrysheldon at cox.net Thu Jun 18 21:29:28 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 18 Jun 2015 16:29:28 -0500 Subject: Anycast provider for SMTP? In-Reply-To: References: <86oakc7we9.fsf@valhalla.seastrom.com> Message-ID: <55833838.3030300@cox.net> On 6/18/2015 16:25, Jonas Bj?rk wrote: > >> Because clients will switch to unicast for renewal. Also clients will stay >> with the current server forever, so you might have a bad distribution of >> load between the servers. If one server was down everyone will switch to >> the other and never go back until forced. > > Why wouldn't they go back to the nearest server when it comes back online? Been awhile, but it seems like they try to "renew" the lease they have, with the server that holds it. -- sed quis custodiet ipsos custodes? (Juvenal) From mr.jonas.bjork at me.com Thu Jun 18 21:40:29 2015 From: mr.jonas.bjork at me.com (=?utf-8?Q?Jonas_Bj=C3=B6rk?=) Date: Thu, 18 Jun 2015 23:40:29 +0200 Subject: Anycast provider for SMTP? In-Reply-To: <55833838.3030300@cox.net> References: <86oakc7we9.fsf@valhalla.seastrom.com> <55833838.3030300@cox.net> Message-ID: <75897BBC-3A2F-463F-8B6E-AB97A3F67208@me.com> > On Jun 18, 2015, at 11:29 PM, Larry Sheldon wrote: > >> On 6/18/2015 16:25, Jonas Bj?rk wrote: >> >>> Because clients will switch to unicast for renewal. Also clients will stay >>> with the current server forever, so you might have a bad distribution of >>> load between the servers. If one server was down everyone will switch to >>> the other and never go back until forced. >> >> Why wouldn't they go back to the nearest server when it comes back online? > > Been awhile, but it seems like they try to "renew" the lease they have, with the server that holds it. > > -- > sed quis custodiet ipsos custodes? (Juvenal) The clients speak unicast with one single ip-helper which address is shared by all the servers. They can't choose which ever server to talk to. From twh at megagroup.ru Thu Jun 18 22:01:21 2015 From: twh at megagroup.ru (Stepan Kucherenko) Date: Fri, 19 Jun 2015 01:01:21 +0300 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: References: <29116.1434588870@server1.tristatelogic.com> Message-ID: <55833FB1.4070806@megagroup.ru> 18.06.2015 18:00, shawn wilson wrote: > I'd actually be interested in a discussion of how much you can possibly > improve / degrade on a network that big from a management position. That's quite an interesting topic, isn't it ? Dilbert still has his job so it might as well be immutable. :-) From rsk at gsp.org Thu Jun 18 22:40:52 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 18 Jun 2015 18:40:52 -0400 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: References: <29116.1434588870@server1.tristatelogic.com> Message-ID: <20150618224052.GB796@gsp.org> On Thu, Jun 18, 2015 at 11:00:00AM -0400, shawn wilson wrote: > If the argument is that she should've shut down the network or parts of it > - I wonder if anyone of you who run Internet providers would even shut down > your email or web servers when, say, heartbleed came out - those services > aren't even a main part of your business. Yes, I would. We did (at Purdue) one day in November 1988, when we knew that we had a problem and we had very good reason to believe we were a serious hazard to the rest of the 'net. Confronted with a similar situation today, I would do the exact same thing. It is the highest duty of everyone on the 'net, whether they're running one laptop or a 50,000-server cloud, to ensure that their operation isn't an operational menace to everyone else. And it is the failure of many to discharge that duty, above all others, that is directly responsible for many of the issues we face every day. ---rsk From mohta at necom830.hpcl.titech.ac.jp Thu Jun 18 23:51:15 2015 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 19 Jun 2015 08:51:15 +0900 Subject: Anycast provider for SMTP? In-Reply-To: References: <86oakc7we9.fsf@valhalla.seastrom.com> Message-ID: <55835973.4090907@necom830.hpcl.titech.ac.jp> On 2015/06/19 4:43, Jonas Bj?rk wrote: > While risking being slightly off topic: Does anyone use anycast dhcp servers? > Have you run into any problems considering synching the leases? In general, multiple anycast servers on a link, which is the anycast model of IPv6, is a bad idea, because broadcast just works. Of course, IPv6 inhibition of broadcast is another bad idea. Masataka Ohta From larrysheldon at cox.net Fri Jun 19 02:18:07 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 18 Jun 2015 21:18:07 -0500 Subject: Anycast provider for SMTP? In-Reply-To: References: <86oakc7we9.fsf@valhalla.seastrom.com> <55833838.3030300@cox.net> Message-ID: <55837BDF.5010604@cox.net> On 6/18/2015 16:40, Jonas Bj?rk wrote: > >> On Jun 18, 2015, at 11:29 PM, Larry Sheldon wrote: >> >>> On 6/18/2015 16:25, Jonas Bj?rk wrote: >>> >>>> Because clients will switch to unicast for renewal. Also clients will stay >>>> with the current server forever, so you might have a bad distribution of >>>> load between the servers. If one server was down everyone will switch to >>>> the other and never go back until forced. >>> >>> Why wouldn't they go back to the nearest server when it comes back online? >> >> Been awhile, but it seems like they try to "renew" the lease they have, with the server that holds it. > The clients speak unicast with one single ip-helper which address is shared by all the servers. > They can't choose which ever server to talk to. One of us is confused (and it may well be me) but I thought the ip-helper address was only useful in the initial grope-in-the-dark for a server that is not on the local Ethernet broadcast domain. Thereafter the negotiations (I thought) are between the client and the responding server and forever after until a failure-to-renew occurred. -- sed quis custodiet ipsos custodes? (Juvenal) From list at satchell.net Fri Jun 19 02:50:55 2015 From: list at satchell.net (Stephen Satchell) Date: Thu, 18 Jun 2015 19:50:55 -0700 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: References: <29116.1434588870@server1.tristatelogic.com> Message-ID: <5583838F.2060407@satchell.net> On 06/18/2015 10:15 AM, Nick B wrote: > I wish I had some simple solution, but I don't, it's going to require > years, probably decades, of hard work by a motivated and skilled team. > Also, a stable of unicorns. Not to mention an Act of Congress. Oh, wait... From notify.sina at gmail.com Fri Jun 19 05:57:09 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Fri, 19 Jun 2015 05:57:09 +0000 Subject: Whats' a good product for a high-density Wireless network setup? Message-ID: Hi We are profiling equipment and design for an expected high user density network of multiple, close nit, residential/hostel units. Its going to be 8-10 buildings with possibly a over 1000 users at any given time. We are looking at Ruckus and Ubiquiti as options to get over the high number of devices we are definitely going to encounter. How did you do it, and what would you advise for product and layout? Thanks in advance! From tylermills at gmail.com Fri Jun 19 06:24:00 2015 From: tylermills at gmail.com (Tyler Mills) Date: Fri, 19 Jun 2015 06:24:00 +0000 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: Message-ID: With that many users I cannot recommend Ubiquiti, Ruckus would be the way to go. On Fri, Jun 19, 2015 at 1:58 AM Sina Owolabi wrote: > Hi > > We are profiling equipment and design for an expected high user density > network of multiple, close nit, residential/hostel units. Its going to be > 8-10 buildings with possibly a over 1000 users at any given time. > We are looking at Ruckus and Ubiquiti as options to get over the high > number of devices we are definitely going to encounter. > > How did you do it, and what would you advise for product and layout? > > Thanks in advance! > -- Tyler W. Mills Infrastructure and Network Engineer Atlanta, GA. From damian at google.com Fri Jun 19 06:54:09 2015 From: damian at google.com (Damian Menscher) Date: Thu, 18 Jun 2015 23:54:09 -0700 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: <5583838F.2060407@satchell.net> References: <29116.1434588870@server1.tristatelogic.com> <5583838F.2060407@satchell.net> Message-ID: On Thu, Jun 18, 2015 at 7:50 PM, Stephen Satchell wrote: > On 06/18/2015 10:15 AM, Nick B wrote: > >> I wish I had some simple solution, but I don't, it's going to require >> years, probably decades, of hard work by a motivated and skilled team. >> Also, a stable of unicorns. >> > > Not to mention an Act of Congress. Oh, wait... > If anyone cares to fix government tech (and not just whine about it on mailing lists), the US Digital Service is probably the best way to make an impact: https://www.whitehouse.gov/digital/united-states-digital-service Damian From notify.sina at gmail.com Fri Jun 19 07:42:20 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Fri, 19 Jun 2015 07:42:20 +0000 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: Message-ID: Thanks! Everything is still in planning stage, though. Management is leaning toward Ruckus. Can I get suggestions for authentication and billing systems for wireless users too? Thanks for all the wisdom so far On Fri, Jun 19, 2015 at 7:54 AM Bartek Krawczyk wrote: > I've got really great experience with Aruba. Don't know if it fits > your budged, though. > > Rebards, > > On 19 June 2015 at 08:24, Tyler Mills wrote: > > With that many users I cannot recommend Ubiquiti, Ruckus would be the way > > to go. > > > > On Fri, Jun 19, 2015 at 1:58 AM Sina Owolabi > wrote: > > > >> Hi > >> > >> We are profiling equipment and design for an expected high user density > >> network of multiple, close nit, residential/hostel units. Its going to > be > >> 8-10 buildings with possibly a over 1000 users at any given time. > >> We are looking at Ruckus and Ubiquiti as options to get over the high > >> number of devices we are definitely going to encounter. > >> > >> How did you do it, and what would you advise for product and layout? > >> > >> Thanks in advance! > >> > > -- > > Tyler W. Mills > > Infrastructure and Network Engineer > > Atlanta, GA. > > > > -- > Bartek Krawczyk > From faisal at snappytelecom.net Fri Jun 19 09:11:27 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 19 Jun 2015 09:11:27 +0000 (GMT) Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: Message-ID: <2055979798.699163.1434705087011.JavaMail.zimbra@snappytelecom.net> >>> With that many users I cannot recommend Ubiquiti, Ruckus would be the way to go. Really ? Considering you are referring to Company Names, each with a full product line of low end to high end products ? I often remind folks that Chevrolet, makes both the Corvette as well as the Chevette.... :) Actual implementations, and deployments suggest that Companies offer products that can serve such an environment when implemented correctly. While they each have their strengths and nuances, the key is proper implementation... Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Tyler Mills" > To: "Sina Owolabi" , "nanog at nanog.org list" > Sent: Friday, June 19, 2015 2:24:00 AM > Subject: Re: Whats' a good product for a high-density Wireless network setup? > > With that many users I cannot recommend Ubiquiti, Ruckus would be the way > to go. > > On Fri, Jun 19, 2015 at 1:58 AM Sina Owolabi wrote: > > > Hi > > > > We are profiling equipment and design for an expected high user density > > network of multiple, close nit, residential/hostel units. Its going to be > > 8-10 buildings with possibly a over 1000 users at any given time. > > We are looking at Ruckus and Ubiquiti as options to get over the high > > number of devices we are definitely going to encounter. > > > > How did you do it, and what would you advise for product and layout? > > > > Thanks in advance! > > > -- > Tyler W. Mills > Infrastructure and Network Engineer > Atlanta, GA. > From bob at FiberInternetCenter.com Fri Jun 19 10:01:49 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 19 Jun 2015 03:01:49 -0700 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. Message-ID: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> Ubiquiti Networks UniFi UAP-PRO Enterprise WiFi System - hard to recommend at this point. We saw people mention this brand here on the list - people like them. So what could we have set incorrectly ? They drop link and re-provision on their own at odd times day or night. We have completed everything tech support asked of us. (Really, lame emails they respond with as if they didn't read your text - they won't call and you can't call them). We used POE from ciscos - then changed to their POE provided. They didn't recommend it, but we plugged them all into APC UPSes..... no difference. They all re-provision at different times even when no one is connected or in the building at odd hours like 2am. Each one does this 2-3 times per 24 hour period. Has anyone else experienced this? Anyone know what we may have set incorrectly ? Is this normal - do people put up with the 2 mins the APs are unavailable about 3 times a day? (UniFi support acts like it's not a big issues.) We use the UniFi controller on mac os x. We use their EdgeMax Edge Router. All the latest software in everything UniFi. Thank You Bob Evans From baldur.norddahl at gmail.com Fri Jun 19 10:25:19 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 19 Jun 2015 12:25:19 +0200 Subject: Anycast provider for SMTP? In-Reply-To: <55837BDF.5010604@cox.net> References: <86oakc7we9.fsf@valhalla.seastrom.com> <55833838.3030300@cox.net> <55837BDF.5010604@cox.net> Message-ID: On 19 June 2015 at 04:18, Larry Sheldon wrote: > On 6/18/2015 16:40, Jonas Bj?rk wrote: > > The clients speak unicast with one single ip-helper which address is >> shared by all the servers. >> They can't choose which ever server to talk to. >> > > One of us is confused (and it may well be me) but I thought the ip-helper > address was only useful in the initial grope-in-the-dark for a server that > is not on the local Ethernet broadcast domain. > > Thereafter the negotiations (I thought) are between the client and the > responding server and forever after until a failure-to-renew occurred. > The clients will broadcast DISCOVER and this will be picked up by the DHCP relay. The relay will also broadcast replies from DHCP servers. There might be multiple servers and therefore multiple offers for leases. The client will select a server and broadcast a request for lease including the IP-address of the server in a DHCP option. The relay will pick that up and send it to all servers. The server which finds its own IP in the server id option will then send ACK. All other servers will notice they were not selected and withdraw their offer for a lease (sending nothing). But after this initial exchange, the clients will unicast renew requests directly to the DHCP server, bypassing the DHCP relay. So Jonas is wrong here. The client will at no point send unicast to the DHCP relay (although the relay might send unicast to the client). The DHCP relay exists only to transmit broadcast traffic - that is the purpose of the relay. Also it is the clients that select what server they want to use. That said, there exists non standard vendor solutions were the DHCP relay does more. In our routers it is called DHCP Proxy. The proxy will act as a DHCP server towards clients. Therefore all unicast will also be with the proxy. The proxy is itself a client towards the real DHCP server. This means a DHCP Proxy is stateful. A DHCP Relay is stateless. The fact that a DHCP relay is stateless also makes it impossible for a DHCP relay to pass on unicast to clients. The clients will only include the server id in the first request message. All renew messages are without that information, so the relay has no way to know which server to pass the message to. Everything above is for DHCPv4. Things are slightly different for DHCPv6. The most important difference is that the DHCP servers can request that renew is done by multicast instead of unicast and the server id is included in all messages. This way you can force all traffic to go via the relay including renew. Regards, Baldur From mianosm at gmail.com Fri Jun 19 10:28:55 2015 From: mianosm at gmail.com (Steven Miano) Date: Fri, 19 Jun 2015 06:28:55 -0400 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: <2055979798.699163.1434705087011.JavaMail.zimbra@snappytelecom.net> References: <2055979798.699163.1434705087011.JavaMail.zimbra@snappytelecom.net> Message-ID: > 8-10 buildings with possibly a over 1000 users at any given time. Aerohive, easily. AP330s would thrive in a setup such as that. On Fri, Jun 19, 2015 at 5:11 AM, Faisal Imtiaz wrote: > >>> With that many users I cannot recommend Ubiquiti, Ruckus would be the > way to go. > > Really ? > Considering you are referring to Company Names, each with a full product > line of low end to high end products ? > > I often remind folks that Chevrolet, makes both the Corvette as well as > the Chevette.... > > :) > > Actual implementations, and deployments suggest that Companies offer > products that can serve such an environment when implemented correctly. > While they each have their strengths and nuances, the key is proper > implementation... > > > Faisal Imtiaz > Snappy Internet & Telecom > > ----- Original Message ----- > > From: "Tyler Mills" > > To: "Sina Owolabi" , "nanog at nanog.org list" < > nanog at nanog.org> > > Sent: Friday, June 19, 2015 2:24:00 AM > > Subject: Re: Whats' a good product for a high-density Wireless network > setup? > > > > With that many users I cannot recommend Ubiquiti, Ruckus would be the way > > to go. > > > > On Fri, Jun 19, 2015 at 1:58 AM Sina Owolabi > wrote: > > > > > Hi > > > > > > We are profiling equipment and design for an expected high user density > > > network of multiple, close nit, residential/hostel units. Its going to > be > > > 8-10 buildings with possibly a over 1000 users at any given time. > > > We are looking at Ruckus and Ubiquiti as options to get over the high > > > number of devices we are definitely going to encounter. > > > > > > How did you do it, and what would you advise for product and layout? > > > > > > Thanks in advance! > > > > > -- > > Tyler W. Mills > > Infrastructure and Network Engineer > > Atlanta, GA. > > > -- Miano, Steven M. http://stevenmiano.com From jared at puck.nether.net Fri Jun 19 10:44:16 2015 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 19 Jun 2015 06:44:16 -0400 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> Message-ID: I have a variety of their gear and don't have problems like this. Have you run a cable tester on the wiring? This sounds quite odd and is something I haven't seen. They do most of their support in their forums vs email. The email is mainly for RMA support. What version software is on your controller and the UAP-Pros? Jared Mauch > On Jun 19, 2015, at 6:01 AM, Bob Evans wrote: > > Ubiquiti Networks UniFi UAP-PRO Enterprise WiFi System - hard to recommend > at this point. We saw people mention this brand here on the list - people > like them. So what could we have set incorrectly ? They drop link and > re-provision on their own at odd times day or night. > > We have completed everything tech support asked of us. (Really, lame > emails they respond with as if they didn't read your text - they won't > call and you can't call them). We used POE from ciscos - then changed to > their POE provided. They didn't recommend it, but we plugged them all into > APC UPSes..... no difference. They all re-provision at different times > even when no one is connected or in the building at odd hours like 2am. > Each one does this 2-3 times per 24 hour period. > > Has anyone else experienced this? > Anyone know what we may have set incorrectly ? > Is this normal - do people put up with the 2 mins the APs are unavailable > about 3 times a day? (UniFi support acts like it's not a big issues.) > > We use the UniFi controller on mac os x. We use their EdgeMax Edge Router. > All the latest software in everything UniFi. > > Thank You > Bob Evans > > > > > > From nanog at ics-il.net Fri Jun 19 11:12:00 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 19 Jun 2015 06:12:00 -0500 (CDT) Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> Message-ID: <5464113.727.1434712331999.JavaMail.mhammett@ThunderFuck> I've had their gear for a few years now. It's effectively up until I upgrade the software. Might want to ask on their forums or on the WISPA UBNT list. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Bob Evans" To: nanog at nanog.org Sent: Friday, June 19, 2015 5:01:49 AM Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. Ubiquiti Networks UniFi UAP-PRO Enterprise WiFi System - hard to recommend at this point. We saw people mention this brand here on the list - people like them. So what could we have set incorrectly ? They drop link and re-provision on their own at odd times day or night. We have completed everything tech support asked of us. (Really, lame emails they respond with as if they didn't read your text - they won't call and you can't call them). We used POE from ciscos - then changed to their POE provided. They didn't recommend it, but we plugged them all into APC UPSes..... no difference. They all re-provision at different times even when no one is connected or in the building at odd hours like 2am. Each one does this 2-3 times per 24 hour period. Has anyone else experienced this? Anyone know what we may have set incorrectly ? Is this normal - do people put up with the 2 mins the APs are unavailable about 3 times a day? (UniFi support acts like it's not a big issues.) We use the UniFi controller on mac os x. We use their EdgeMax Edge Router. All the latest software in everything UniFi. Thank You Bob Evans From fastest963 at gmail.com Fri Jun 19 05:19:24 2015 From: fastest963 at gmail.com (James Hartig) Date: Fri, 19 Jun 2015 01:19:24 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: > > You can achieve the above DNS trickery using various load balancers that > other people in this thread have already mentioned. You can also install > your own geomaps in your own nameservers and handle it yourself, or you can > buy managed DNS service from various people that can do this kind of thing. > Just curious, how does DNS load balancing work if people are using 8.8.8.8/208.67.222.222 or basically any public resolvers that cache and have a significant (relatively speaking) user-base? Is the actual percent of requests so small that it doesn't matter? -- James From bbartlomiej.mail at gmail.com Fri Jun 19 06:54:58 2015 From: bbartlomiej.mail at gmail.com (Bartek Krawczyk) Date: Fri, 19 Jun 2015 08:54:58 +0200 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: Message-ID: I've got really great experience with Aruba. Don't know if it fits your budged, though. Rebards, On 19 June 2015 at 08:24, Tyler Mills wrote: > With that many users I cannot recommend Ubiquiti, Ruckus would be the way > to go. > > On Fri, Jun 19, 2015 at 1:58 AM Sina Owolabi wrote: > >> Hi >> >> We are profiling equipment and design for an expected high user density >> network of multiple, close nit, residential/hostel units. Its going to be >> 8-10 buildings with possibly a over 1000 users at any given time. >> We are looking at Ruckus and Ubiquiti as options to get over the high >> number of devices we are definitely going to encounter. >> >> How did you do it, and what would you advise for product and layout? >> >> Thanks in advance! >> > -- > Tyler W. Mills > Infrastructure and Network Engineer > Atlanta, GA. -- Bartek Krawczyk From mike.meredith at port.ac.uk Fri Jun 19 08:39:07 2015 From: mike.meredith at port.ac.uk (Mike Meredith) Date: Fri, 19 Jun 2015 09:39:07 +0100 Subject: Anycast provider for SMTP? In-Reply-To: References: <86oakc7we9.fsf@valhalla.seastrom.com> Message-ID: <20150619093907.08b13af8@scrofula.eps.is.port.ac.uk> On Thu, 18 Jun 2015 15:51:31 -0400, "Joe Abley" may have written: > Since DHCP uses broadcast and multicast addresses when a client is > discovering a server, it's not obvious why you'd have to. And broadcast/multicast when renewing a lease (DHCPREQUEST). You will of course see unicast addresses on the server side if the server is seeing requests forwarded by a udp helper. > You can run redundant sets of isc-dhcpd servers together serving the > same broadcast domain and have them assign leases from the same > address pools (at least, I've never tried it, but I was within Indeed. Rock solid in my experience (on a "little" network). -- Mike Meredith, University of Portsmouth Principal Systems Engineer, Hostmaster, Security, and Timelord! From hal at buzcom.net Fri Jun 19 10:45:51 2015 From: hal at buzcom.net (Hal Ponton) Date: Fri, 19 Jun 2015 11:45:51 +0100 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> Message-ID: What version of the controller are you using, we're running 3.something at that works fine. We've turned off auto update on all of the sites on the server, and Nagios monitors them, we certainly don't see reboots 2-3 times a day, the last time ours rebooted was when we lost power at our office. Contact me off list if you want me to take a look. Regards, Hal Ponton Senior Network Engineer Buzcom / FibreWiFi Tel: 07429 979 217 Email: hal at buzcom.net > On 19 Jun 2015, at 11:01, Bob Evans wrote: > > Ubiquiti Networks UniFi UAP-PRO Enterprise WiFi System - hard to recommend > at this point. We saw people mention this brand here on the list - people > like them. So what could we have set incorrectly ? They drop link and > re-provision on their own at odd times day or night. > > We have completed everything tech support asked of us. (Really, lame > emails they respond with as if they didn't read your text - they won't > call and you can't call them). We used POE from ciscos - then changed to > their POE provided. They didn't recommend it, but we plugged them all into > APC UPSes..... no difference. They all re-provision at different times > even when no one is connected or in the building at odd hours like 2am. > Each one does this 2-3 times per 24 hour period. > > Has anyone else experienced this? > Anyone know what we may have set incorrectly ? > Is this normal - do people put up with the 2 mins the APs are unavailable > about 3 times a day? (UniFi support acts like it's not a big issues.) > > We use the UniFi controller on mac os x. We use their EdgeMax Edge Router. > All the latest software in everything UniFi. > > Thank You > Bob Evans > > > > > > > From morrowc.lists at gmail.com Fri Jun 19 12:12:38 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 19 Jun 2015 14:12:38 +0200 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: On Fri, Jun 19, 2015 at 7:19 AM, James Hartig wrote: > > Just curious, how does DNS load balancing work if people are using > 8.8.8.8/208.67.222.222 or basically any public resolvers that cache and don't know exactly, but you might get some interesting clues from the f-root or as112 designs, eh? From dot at dotat.at Fri Jun 19 12:47:58 2015 From: dot at dotat.at (Tony Finch) Date: Fri, 19 Jun 2015 13:47:58 +0100 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: James Hartig wrote: > > Just curious, how does DNS load balancing work if people are using > 8.8.8.8/208.67.222.222 or basically any public resolvers that cache and > have a significant (relatively speaking) user-base? http://www.afasterinternet.com/ietfdraft.htm Tony. -- f.anthony.n.finch http://dotat.at/ Fisher, German Bight: Northwest 4 or 5, increasing 6 at times. Slight or moderate. Showers. Good, occasionally moderate. From SNaslund at medline.com Fri Jun 19 13:30:35 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 19 Jun 2015 13:30:35 +0000 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: <55833FB1.4070806@megagroup.ru> References: <29116.1434588870@server1.tristatelogic.com> <55833FB1.4070806@megagroup.ru> Message-ID: <9578293AE169674F9A048B2BC9A081B401C0530D3B@MUNPRDMBXA1.medline.com> I think one of their major issues is that they look at too much of the network at a time. If they decided they were going to secure a particular data center or building, they might be much better off. If they start with defending the servers from internal as well as external threats and then move toward the perimeter they might make progress. I think they look at the entire comprehensive network and end up with a number or a project that is too big to fathom. First thing would be current IDP/IDS technology so they would at least know where and what the threats are. Steven Naslund Chicago IL 18.06.2015 18:00, shawn wilson wrote: > I'd actually be interested in a discussion of how much you can possibly > improve / degrade on a network that big from a management position. From jabley at hopcount.ca Fri Jun 19 13:42:09 2015 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 19 Jun 2015 09:42:09 -0400 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: <0403F2A2-4C8B-4A41-A80E-585C6E7C5367@hopcount.ca> On 19 Jun 2015, at 8:12, Christopher Morrow wrote: > On Fri, Jun 19, 2015 at 7:19 AM, James Hartig > wrote: > >> Just curious, how does DNS load balancing work if people are using >> 8.8.8.8/208.67.222.222 or basically any public resolvers that cache >> and If the client that performs the upstream query within the 8.8.8.8/whatever infrastructure is close to you for some meaningful interpretation of "close" then you still get an answer that is (effectively) localised for you. If the resolver infrastructure is sufficiently far that what is good for it is not good for you, then the deployed (if not quite standardised) answer is edns-client-subnet: the resolver infrastructure you're using embeds your client address in its upstream query. The authority servers can then localise a response (and scope it) as being suitable for you, not the resolver in general. http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-02 There are privacy concerns, here. But we might posit that you've already in the business of trading privacy for convenience if you're using a public resolver. > don't know exactly, but you might get some interesting clues from the > f-root or as112 designs, eh? Root servers and AS112 servers don't steer clients towards content according to where they are. They give consistent answers for all queries, regardless of where they came from. Joe From baldur.norddahl at gmail.com Fri Jun 19 13:43:09 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 19 Jun 2015 15:43:09 +0200 Subject: Anycast provider for SMTP? In-Reply-To: <20150619093907.08b13af8@scrofula.eps.is.port.ac.uk> References: <86oakc7we9.fsf@valhalla.seastrom.com> <20150619093907.08b13af8@scrofula.eps.is.port.ac.uk> Message-ID: On 19 June 2015 at 10:39, Mike Meredith wrote: > On Thu, 18 Jun 2015 15:51:31 -0400, "Joe Abley" > may have written: > > Since DHCP uses broadcast and multicast addresses when a client is > > discovering a server, it's not obvious why you'd have to. > > And broadcast/multicast when renewing a lease (DHCPREQUEST). You will > of course see unicast addresses on the server side if the server is > seeing requests forwarded by a udp helper. > RFC 2131 section 4.4.5: "At time T1 the client moves to RENEWING state and sends (*via unicast*) a DHCPREQUEST message to the server to extend its lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its current network address. The client records the local time at which the DHCPREQUEST message is sent for computation of the lease expiration time. The client MUST NOT include a 'server identifier' in the DHCPREQUEST message." Also from section 4.3.2: "DHCPREQUEST generated during RENEWING state: 'server identifier' MUST NOT be filled in, 'requested IP address' option MUST NOT be filled in, 'ciaddr' MUST be filled in with client's IP address. In this situation, the client is completely configured, and is trying to extend its lease. This message will be *unicast*, so *no relay agents will be involved in its transmission*. Because 'giaddr' is therefore not filled in, the DHCP server will trust the value in 'ciaddr', and use it when replying to the client." If there is no reply to the unicast, the client should eventually do a fallback to broadcast, but a great number of DHCP clients fail to implement that. They will instead keep unicasting until the lease expire, then start over including deconfiguring the IP stack and then send DISCOVER. Regards, Baldur From morrowc.lists at gmail.com Fri Jun 19 13:46:04 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 19 Jun 2015 15:46:04 +0200 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: On Fri, Jun 19, 2015 at 2:47 PM, Tony Finch wrote: > James Hartig wrote: >> >> Just curious, how does DNS load balancing work if people are using >> 8.8.8.8/208.67.222.222 or basically any public resolvers that cache and >> have a significant (relatively speaking) user-base? > > http://www.afasterinternet.com/ietfdraft.htm that doesn't address how packets get to the address or back though, right? that's about the content in the packet. From morrowc.lists at gmail.com Fri Jun 19 13:47:43 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 19 Jun 2015 15:47:43 +0200 Subject: Anycast provider for SMTP? In-Reply-To: <0403F2A2-4C8B-4A41-A80E-585C6E7C5367@hopcount.ca> References: <0403F2A2-4C8B-4A41-A80E-585C6E7C5367@hopcount.ca> Message-ID: On Fri, Jun 19, 2015 at 3:42 PM, Joe Abley wrote: > On 19 Jun 2015, at 8:12, Christopher Morrow wrote: > >> On Fri, Jun 19, 2015 at 7:19 AM, James Hartig >> wrote: >> >>> Just curious, how does DNS load balancing work if people are using >>> 8.8.8.8/208.67.222.222 or basically any public resolvers that cache and > >> don't know exactly, but you might get some interesting clues from the >> f-root or as112 designs, eh? > > > Root servers and AS112 servers don't steer clients towards content according > to where they are. They give consistent answers for all queries, regardless > of where they came from. dang you jabley! I didn't see the 'if using' part :( my answer(s) are irrelevant! From mel at beckman.org Fri Jun 19 13:51:30 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 19 Jun 2015 13:51:30 +0000 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180>, Message-ID: <3A3B0EA5-81A2-48B9-A34A-021CEFAE128B@beckman.org> Bob, I've deployed tons of Ubiquiti gear, and have seen this problem before. It always turns out to be poor quality cable installation. POE does not tolerate low quality connectors, especially in outdoor environments. There are many aspects to a quality cabling job, so the best thing you can do is seek out a qualified installer with outdoor POE experience. The most common problem I see is people using crimp-on RJ45 connectors directly on the ends of their cable runs. This is not how structured cabling is designed to work, in particular because most crimp-on connectors are intended for stranded copper wire (such as that used in very flexible patch cords, designed to run horizontally over only a few dozens of feet), whereas the "riser" and "plenum" cable used for long-distance runs has solid core wires. The tiny teeth in standard crimp connectors are designed to penetrate stranded wire, to make a solid electrical contact. With solid core wire, they just bend to the side of the copper core, making tenuous contact, which will conduct POE current poorly (resulting in the resets you see) and eventually fail altogether as the improper connection corrodes over time. The correct installation process is to use "punch-down" RJ45 jacks at each end of the cable run, and connect from those jacks to your equipment (radio at one end, POE switch at the other). On the outdoor side, the jack/plug junction needs to be in a NEMA weatherproof enclosure, with weathertight fittings. And, for human and equipment safety, you must use shielded Cat5e/6 cable anytime you go outdoors, grounding only one end (usually the radio end), and protecting the cable with an inline lightning protector between the RJ45 jack and the radio. If you haven't done that, then that's the first thing to fix. BTW, avoid homemade patch cables whenever possible. Quality factory cables are hydraulically pressed and the plug is hermetically fused for a vastly superior connection compared to anything you can do with simple hand crimpers. And all outdoor cables must be UV-grade cabling with weatherproof sheathing and water repellant inside (so-called "flooded" cable). -mel beckman > On Jun 19, 2015, at 4:54 AM, Hal Ponton wrote: > > What version of the controller are you using, we're running 3.something at that works fine. > > We've turned off auto update on all of the sites on the server, and Nagios monitors them, we certainly don't see reboots 2-3 times a day, the last time ours rebooted was when we lost power at our office. > > Contact me off list if you want me to take a look. > > Regards, > > Hal Ponton > > Senior Network Engineer > > Buzcom / FibreWiFi > > Tel: 07429 979 217 > Email: hal at buzcom.net > >> On 19 Jun 2015, at 11:01, Bob Evans wrote: >> >> Ubiquiti Networks UniFi UAP-PRO Enterprise WiFi System - hard to recommend >> at this point. We saw people mention this brand here on the list - people >> like them. So what could we have set incorrectly ? They drop link and >> re-provision on their own at odd times day or night. >> >> We have completed everything tech support asked of us. (Really, lame >> emails they respond with as if they didn't read your text - they won't >> call and you can't call them). We used POE from ciscos - then changed to >> their POE provided. They didn't recommend it, but we plugged them all into >> APC UPSes..... no difference. They all re-provision at different times >> even when no one is connected or in the building at odd hours like 2am. >> Each one does this 2-3 times per 24 hour period. >> >> Has anyone else experienced this? >> Anyone know what we may have set incorrectly ? >> Is this normal - do people put up with the 2 mins the APs are unavailable >> about 3 times a day? (UniFi support acts like it's not a big issues.) >> >> We use the UniFi controller on mac os x. We use their EdgeMax Edge Router. >> All the latest software in everything UniFi. >> >> Thank You >> Bob Evans >> >> >> >> >> >> >> From Patrick.Darden at p66.com Fri Jun 19 13:55:38 2015 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Fri, 19 Jun 2015 13:55:38 +0000 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C0530D3B@MUNPRDMBXA1.medline.com> References: <29116.1434588870@server1.tristatelogic.com> <55833FB1.4070806@megagroup.ru> <9578293AE169674F9A048B2BC9A081B401C0530D3B@MUNPRDMBXA1.medline.com> Message-ID: <03fe5e33930b416c9a1f5ec60d469d34@BRTEXMB02.phillips66.net> Good point. It's a massive job, and sometimes it is best to look at those piecemeal. Start with small goals, and pick low hanging fruit--your example of the server room is good. Set it up with and IDS, a firewall, harden the hosts by turning off/removing unused/unneeded services, setting up tripwire, and encrypt all data on the drives, then look to password policy enforcement. Then start actively securing it (monthly audits, daily log checks, etc.). Doable. Then pick the next lowest hanging fruit and repeat. --patrick darden -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Naslund, Steve Sent: Friday, June 19, 2015 8:31 AM To: Stepan Kucherenko; nanog at nanog.org Subject: [EXTERNAL]RE: OPM Data Breach - Whitehouse Petition - Help Wanted I think one of their major issues is that they look at too much of the network at a time. If they decided they were going to secure a particular data center or building, they might be much better off. If they start with defending the servers from internal as well as external threats and then move toward the perimeter they might make progress. I think they look at the entire comprehensive network and end up with a number or a project that is too big to fathom. First thing would be current IDP/IDS technology so they would at least know where and what the threats are. Steven Naslund Chicago IL 18.06.2015 18:00, shawn wilson wrote: > I'd actually be interested in a discussion of how much you can possibly > improve / degrade on a network that big from a management position. From charles at thefnf.org Fri Jun 19 14:03:31 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Fri, 19 Jun 2015 09:03:31 -0500 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> Message-ID: <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> On 2015-06-19 05:01, Bob Evans wrote: > Ubiquiti Networks UniFi UAP-PRO Enterprise WiFi System - hard to > recommend > at this point. We saw people mention this brand here on the list - > people > like them. So what could we have set incorrectly ? They drop link and > re-provision on their own at odd times day or night. Drop link all the way down to layer 1? What does re-provision mean? Lose/re acquire DHCP lease? \ What is your network topology? What kind of switches are you using? What's the length of the cable runs? Have you had an electrician check your wiring? How many access points are you running? How many fail? Do they fail in any kind of cluster/pattern? That's just the basic questions. Lots more information needed if you want free support from the NANOG hive mind :D They have millions of satisfied customers in deployments from some of the worlds largest shopping malls to multi state ISPs. Different gear across that customer base of course. > > We have completed everything tech support asked of us. (Really, lame > emails they respond with as if they didn't read your text - they won't > call and you can't call them). We used POE from ciscos - then changed > to > their POE provided. POE from ciscos.... mid span injector, or switch port? They didn't recommend it, but we plugged them all into > APC UPSes..... no difference. The midspan injectors you mean? Hmmmm, wonder why they didn't want you to put them in UPS. Did they provide any explanation? They all re-provision at different times > even when no one is connected or in the building at odd hours like 2am. > Each one does this 2-3 times per 24 hour period. Interesting. Any repeated offenders? > > Has anyone else experienced this? > Anyone know what we may have set incorrectly ? > Is this normal - do people put up with the 2 mins the APs are > unavailable > about 3 times a day? (UniFi support acts like it's not a big issues.) > Do they come back on their own? What's the "downtime" time window? > We use the UniFi controller on mac os x. Mac OSX isn't a server platform. Sorry. Use Windows 2k12 or Ubuntu Server (or your favorite debian or Redhat flavor). I've had zero problems on either of those platforms. What's the topology between the access points and your controller "server"? From charles at thefnf.org Fri Jun 19 14:05:31 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Fri, 19 Jun 2015 09:05:31 -0500 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <3A3B0EA5-81A2-48B9-A34A-021CEFAE128B@beckman.org> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180>, <3A3B0EA5-81A2-48B9-A34A-021CEFAE128B@beckman.org> Message-ID: <85ad63b13d469068cf35b0c5c47f00d3@thefnf.org> On 2015-06-19 08:51, Mel Beckman wrote: > Bob, I've deployed tons of Ubiquiti gear, and have seen this problem > before. It always turns out to be poor quality cable installation. POE > does not tolerate low quality connectors, especially in outdoor > environments. There are many aspects to a quality cabling job, so the > best thing you can do is seek out a qualified installer with outdoor > POE experience. > Yep. Networks. Layer 1 before everything else! So many bad cabling jobs for sure. Are people using the tough cable? That has held up really well in the installations I've done. For a few years with zero issues. From SNaslund at medline.com Fri Jun 19 14:06:31 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 19 Jun 2015 14:06:31 +0000 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <3A3B0EA5-81A2-48B9-A34A-021CEFAE128B@beckman.org> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180>, <3A3B0EA5-81A2-48B9-A34A-021CEFAE128B@beckman.org> Message-ID: <9578293AE169674F9A048B2BC9A081B401C0530EB6@MUNPRDMBXA1.medline.com> That's possible but I if they are re-provisioning on a regular schedule I kind of doubt it. It would be easy to test though. Plug an AP directly into your switch with a quality pre-manufactured patch cord and see how it acts. If it exhibits the same symptom it is probably not cabling. Also, have you checked your interface counters for any packet errors? Don't forget to look at your controller because if the controller became unreachable for any length of time that could easily cause your APs to re-provision as they reconnect with the controller. I might set up a ping every second from the site of the access points to the controller and make sure the availability of the controller is 100%. If you are on Cisco switches you should have log messages regarding PoE be granted on particular ports as well as up down messages on the interfaces. Do you see the ports going up and down? It is important to have NTP on the APs and switches so that you can correlate events in time (i.e. did the AP reboot causing the Ethernet link to drop or did the link drop causing the reboot?) Steven Naslund Chicago IL >Bob, I've deployed tons of Ubiquiti gear, and have seen this problem before. It always turns out to be poor quality cable installation. POE does not tolerate low quality connectors, especially in outdoor environments. There are >many aspects to a quality cabling job, so the best thing you can do is seek out a qualified installer with outdoor POE experience. > >The most common problem I see is people using crimp-on RJ45 connectors directly on the ends of their cable runs. This is not how structured cabling is designed to work, in particular because most crimp-on connectors are intended for >stranded copper wire (such as that used in very flexible patch cords, designed to run horizontally over only a few dozens of feet), whereas the "riser" and "plenum" cable used for long-distance runs has solid core wires. The tiny >teeth in standard crimp connectors are designed to penetrate stranded wire, to make a solid electrical contact. With solid core wire, they just bend to the side of the copper core, making tenuous contact, which will conduct POE >current poorly (resulting in the resets you see) and eventually fail altogether as the improper connection corrodes over time. > >The correct installation process is to use "punch-down" RJ45 jacks at each end of the cable run, and connect from those jacks to your equipment (radio at one end, POE switch at the other). On the outdoor side, the jack/plug junction >needs to be in a NEMA weatherproof enclosure, with weathertight fittings. And, for human and equipment safety, you must use shielded Cat5e/6 cable anytime you go outdoors, grounding only one end (usually the radio end), and >protecting the cable with an inline lightning protector between the RJ45 jack and the radio. >If you haven't done that, then that's the first thing to fix. >BTW, avoid homemade patch cables whenever possible. Quality factory cables are hydraulically pressed and the plug is hermetically fused for a vastly superior connection compared to anything you can do with simple hand crimpers. And >all outdoor cables must be UV-grade cabling with weatherproof sheathing and water repellant inside (so-called "flooded" cable). > -mel beckman From SNaslund at medline.com Fri Jun 19 14:09:38 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 19 Jun 2015 14:09:38 +0000 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> Message-ID: <9578293AE169674F9A048B2BC9A081B401C0530ED1@MUNPRDMBXA1.medline.com> Here is another though. If your APs are re-provisioning every eight hours, what is your DHCP lease time? Are you sure the APs are able to renew their leases (if not, could your scope be full)? Do you see the IP addresses on the APs changing when they come back up? These could indicate a DHCP server issue. If the AP gets a new IP address it will likely have to be re-adopted to the controller. You might want to static address one or more APs to test this theory. Steven Naslund Chicago IL From josh at imaginenetworksllc.com Fri Jun 19 14:09:39 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 19 Jun 2015 10:09:39 -0400 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> Message-ID: Do you want to set one of the radios to my Unifi server to confirm it is or isn't a controller problem? If you simply turn off your controller you can confirm as well. The devices will run as provisioned until told otherwise. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Jun 19, 2015 at 10:03 AM, wrote: > On 2015-06-19 05:01, Bob Evans wrote: > >> Ubiquiti Networks UniFi UAP-PRO Enterprise WiFi System - hard to recommend >> at this point. We saw people mention this brand here on the list - people >> like them. So what could we have set incorrectly ? They drop link and >> re-provision on their own at odd times day or night. >> > > Drop link all the way down to layer 1? What does re-provision mean? > Lose/re acquire DHCP lease? \ > > What is your network topology? What kind of switches are you using? What's > the length of the cable runs? Have you had an electrician check your wiring? > How many access points are you running? How many fail? Do they fail in any > kind of cluster/pattern? > > That's just the basic questions. > > Lots more information needed if you want free support from the NANOG hive > mind :D > > They have millions of satisfied customers in deployments from some of the > worlds largest shopping malls to multi state ISPs. Different gear across > that customer base of course. > > > >> We have completed everything tech support asked of us. (Really, lame >> emails they respond with as if they didn't read your text - they won't >> call and you can't call them). We used POE from ciscos - then changed to >> their POE provided. >> > > POE from ciscos.... mid span injector, or switch port? > > > They didn't recommend it, but we plugged them all into > >> APC UPSes..... no difference. >> > > The midspan injectors you mean? Hmmmm, wonder why they didn't want you to > put them in UPS. Did they provide any explanation? > > > They all re-provision at different times > >> even when no one is connected or in the building at odd hours like 2am. >> Each one does this 2-3 times per 24 hour period. >> > > Interesting. Any repeated offenders? > > > > >> Has anyone else experienced this? >> Anyone know what we may have set incorrectly ? >> Is this normal - do people put up with the 2 mins the APs are unavailable >> about 3 times a day? (UniFi support acts like it's not a big issues.) >> >> > Do they come back on their own? What's the "downtime" time window? > > > > We use the UniFi controller on mac os x. >> > > Mac OSX isn't a server platform. Sorry. Use Windows 2k12 or Ubuntu Server > (or your favorite debian or Redhat flavor). I've had zero problems on > either of those platforms. > > What's the topology between the access points and your controller "server"? > From bob at FiberInternetCenter.com Fri Jun 19 14:10:07 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 19 Jun 2015 07:10:07 -0700 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> Message-ID: Thanks Jared Cables are 3 to 6 feet long - swapped them out already. All cables manufacture made purchased. They plug into the switch directly. Each switch is them multi-mode fiber back to a main switch where the edgeMax router and other gear are connected. Bob Evans > I have a variety of their gear and don't have problems like this. Have you > run a cable tester on the wiring? This sounds quite odd and is something I > haven't seen. > > They do most of their support in their forums vs email. The email is > mainly for RMA support. > > What version software is on your controller and the UAP-Pros? > > Jared Mauch > >> On Jun 19, 2015, at 6:01 AM, Bob Evans >> wrote: >> >> Ubiquiti Networks UniFi UAP-PRO Enterprise WiFi System - hard to >> recommend >> at this point. We saw people mention this brand here on the list - >> people >> like them. So what could we have set incorrectly ? They drop link and >> re-provision on their own at odd times day or night. >> >> We have completed everything tech support asked of us. (Really, lame >> emails they respond with as if they didn't read your text - they won't >> call and you can't call them). We used POE from ciscos - then changed to >> their POE provided. They didn't recommend it, but we plugged them all >> into >> APC UPSes..... no difference. They all re-provision at different times >> even when no one is connected or in the building at odd hours like 2am. >> Each one does this 2-3 times per 24 hour period. >> >> Has anyone else experienced this? >> Anyone know what we may have set incorrectly ? >> Is this normal - do people put up with the 2 mins the APs are >> unavailable >> about 3 times a day? (UniFi support acts like it's not a big issues.) >> >> We use the UniFi controller on mac os x. We use their EdgeMax Edge >> Router. >> All the latest software in everything UniFi. >> >> Thank You >> Bob Evans >> >> >> >> >> >> > From josh at imaginenetworksllc.com Fri Jun 19 14:10:36 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 19 Jun 2015 10:10:36 -0400 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <85ad63b13d469068cf35b0c5c47f00d3@thefnf.org> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <3A3B0EA5-81A2-48B9-A34A-021CEFAE128B@beckman.org> <85ad63b13d469068cf35b0c5c47f00d3@thefnf.org> Message-ID: The current ToughCable really is fantastic. I'd only suggest the bigger one ("carrier"). The old green stuff definitely deterred a lot of people, understandably. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Jun 19, 2015 at 10:05 AM, wrote: > On 2015-06-19 08:51, Mel Beckman wrote: > >> Bob, I've deployed tons of Ubiquiti gear, and have seen this problem >> before. It always turns out to be poor quality cable installation. POE >> does not tolerate low quality connectors, especially in outdoor >> environments. There are many aspects to a quality cabling job, so the >> best thing you can do is seek out a qualified installer with outdoor >> POE experience. >> >> > > > Yep. Networks. Layer 1 before everything else! So many bad cabling jobs > for sure. > > > Are people using the tough cable? That has held up really well in the > installations I've done. For a few years with zero issues. > From jimpop at gmail.com Fri Jun 19 14:12:17 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Fri, 19 Jun 2015 10:12:17 -0400 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: <03fe5e33930b416c9a1f5ec60d469d34@BRTEXMB02.phillips66.net> References: <29116.1434588870@server1.tristatelogic.com> <55833FB1.4070806@megagroup.ru> <9578293AE169674F9A048B2BC9A081B401C0530D3B@MUNPRDMBXA1.medline.com> <03fe5e33930b416c9a1f5ec60d469d34@BRTEXMB02.phillips66.net> Message-ID: On Fri, Jun 19, 2015 at 9:55 AM, Darden, Patrick wrote: > Good point. It's a massive job, and sometimes it is best to look at those piecemeal. Start with small goals, and pick low hanging fruit--your example of the server room is good. Set it up with and IDS, a firewall, harden the hosts by turning off/removing unused/unneeded services, setting up tripwire, and encrypt all data on the drives, then look to password policy enforcement. Then start actively securing it (monthly audits, daily log checks, etc.). Doable. Then pick the next lowest hanging fruit and repeat. You left out: Formulate Bid Solicitation team Procure funding for Bid Solicitation team Request Congressional approval for Bid Solicitation team Request funding for team to win Congressional approval of Bid Solicitation team Receive first round funding for team to win Congressional approval..... Director retires, project status in limbo New round of higher funding sought Congressional recess, projects in limbo Bid process begins, 3 of 4 are non-GSA and require further funding for new approval process After 2 years of paperwork, initial funding for 2 year old IDS v1.1 (that's what was approved!) is approved. repeat, ad nauseam -Jim P. From bob at FiberInternetCenter.com Fri Jun 19 14:14:04 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 19 Jun 2015 07:14:04 -0700 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <5464113.727.1434712331999.JavaMail.mhammett@ThunderFuck> References: <5464113.727.1434712331999.JavaMail.mhammett@ThunderFuck> Message-ID: <9a174c7354c6dc9ea506a57176701dcf.squirrel@66.201.44.180> Mike, Good to know they are reliable. It is an odd looking problem. We will try the forums. Thank You Bob Evans > I've had their gear for a few years now. It's effectively up until I > upgrade the software. Might want to ask on their forums or on the WISPA > UBNT list. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Bob Evans" > To: nanog at nanog.org > Sent: Friday, June 19, 2015 5:01:49 AM > Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. > > Ubiquiti Networks UniFi UAP-PRO Enterprise WiFi System - hard to recommend > at this point. We saw people mention this brand here on the list - people > like them. So what could we have set incorrectly ? They drop link and > re-provision on their own at odd times day or night. > > We have completed everything tech support asked of us. (Really, lame > emails they respond with as if they didn't read your text - they won't > call and you can't call them). We used POE from ciscos - then changed to > their POE provided. They didn't recommend it, but we plugged them all into > APC UPSes..... no difference. They all re-provision at different times > even when no one is connected or in the building at odd hours like 2am. > Each one does this 2-3 times per 24 hour period. > > Has anyone else experienced this? > Anyone know what we may have set incorrectly ? > Is this normal - do people put up with the 2 mins the APs are unavailable > about 3 times a day? (UniFi support acts like it's not a big issues.) > > We use the UniFi controller on mac os x. We use their EdgeMax Edge Router. > All the latest software in everything UniFi. > > Thank You > Bob Evans > > > > > > > > > From jared at puck.nether.net Fri Jun 19 14:15:29 2015 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 19 Jun 2015 10:15:29 -0400 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> Message-ID: It sounds like a PoE issue. I'm also happy to take a look. Anything in the controller logs? Are your DHCP leases short? Or are you seeing the edge router reboot? What version on the edge router? The 1.7.0rc2 was posted and compared to 1.5 and 1.6 it fixes a reboot issue I saw unless you disabled vlan offload. Jared Mauch > On Jun 19, 2015, at 10:10 AM, Bob Evans wrote: > > Thanks Jared > Cables are 3 to 6 feet long - swapped them out already. All cables > manufacture made purchased. They plug into the switch directly. Each > switch is them multi-mode fiber back to a main switch where the edgeMax > router and other gear are connected. > > Bob Evans > > > > > >> I have a variety of their gear and don't have problems like this. Have you >> run a cable tester on the wiring? This sounds quite odd and is something I >> haven't seen. >> >> They do most of their support in their forums vs email. The email is >> mainly for RMA support. >> >> What version software is on your controller and the UAP-Pros? >> >> Jared Mauch >> >>> On Jun 19, 2015, at 6:01 AM, Bob Evans >>> wrote: >>> >>> Ubiquiti Networks UniFi UAP-PRO Enterprise WiFi System - hard to >>> recommend >>> at this point. We saw people mention this brand here on the list - >>> people >>> like them. So what could we have set incorrectly ? They drop link and >>> re-provision on their own at odd times day or night. >>> >>> We have completed everything tech support asked of us. (Really, lame >>> emails they respond with as if they didn't read your text - they won't >>> call and you can't call them). We used POE from ciscos - then changed to >>> their POE provided. They didn't recommend it, but we plugged them all >>> into >>> APC UPSes..... no difference. They all re-provision at different times >>> even when no one is connected or in the building at odd hours like 2am. >>> Each one does this 2-3 times per 24 hour period. >>> >>> Has anyone else experienced this? >>> Anyone know what we may have set incorrectly ? >>> Is this normal - do people put up with the 2 mins the APs are >>> unavailable >>> about 3 times a day? (UniFi support acts like it's not a big issues.) >>> >>> We use the UniFi controller on mac os x. We use their EdgeMax Edge >>> Router. >>> All the latest software in everything UniFi. >>> >>> Thank You >>> Bob Evans > From jared at puck.nether.net Fri Jun 19 14:17:14 2015 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 19 Jun 2015 10:17:14 -0400 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C0530EB6@MUNPRDMBXA1.medline.com> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <3A3B0EA5-81A2-48B9-A34A-021CEFAE128B@beckman.org> <9578293AE169674F9A048B2BC9A081B401C0530EB6@MUNPRDMBXA1.medline.com> Message-ID: This isn't the behavior I've seen with UBNT. They only provision on a change, even if disconnected for a long time. You can check this in the UniFi logs directory. Jared Mauch > On Jun 19, 2015, at 10:06 AM, Naslund, Steve wrote: > > Don't forget to look at your controller because if the controller became unreachable for any length of time that could easily cause your APs to re-provision as they reconnect with the controller. From bob at FiberInternetCenter.com Fri Jun 19 14:19:52 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 19 Jun 2015 07:19:52 -0700 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <3A3B0EA5-81A2-48B9-A34A-021CEFAE128B@beckman.org> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180>, <3A3B0EA5-81A2-48B9-A34A-021CEFAE128B@beckman.org> Message-ID: Mel, Thanks, for all the detail. Everything is in doors and directly connected by new 3 to 6 foot manufactured cables on a cisco switches. All cables have been changed - even tired crossover cables - same results. I'm thinking it has something to do with the controller communications...All these APs shouldn't need a controller after configuration and boot up. But we leave it up. Thank You Bob Evans CTO > Bob, I've deployed tons of Ubiquiti gear, and have seen this problem > before. It always turns out to be poor quality cable installation. POE > does not tolerate low quality connectors, especially in outdoor > environments. There are many aspects to a quality cabling job, so the best > thing you can do is seek out a qualified installer with outdoor POE > experience. > > The most common problem I see is people using crimp-on RJ45 connectors > directly on the ends of their cable runs. This is not how structured > cabling is designed to work, in particular because most crimp-on > connectors are intended for stranded copper wire (such as that used in > very flexible patch cords, designed to run horizontally over only a few > dozens of feet), whereas the "riser" and "plenum" cable used for > long-distance runs has solid core wires. The tiny teeth in standard crimp > connectors are designed to penetrate stranded wire, to make a solid > electrical contact. With solid core wire, they just bend to the side of > the copper core, making tenuous contact, which will conduct POE current > poorly (resulting in the resets you see) and eventually fail altogether as > the improper connection corrodes over time. > > The correct installation process is to use "punch-down" RJ45 jacks at each > end of the cable run, and connect from those jacks to your equipment > (radio at one end, POE switch at the other). On the outdoor side, the > jack/plug junction needs to be in a NEMA weatherproof enclosure, with > weathertight fittings. And, for human and equipment safety, you must use > shielded Cat5e/6 cable anytime you go outdoors, grounding only one end > (usually the radio end), and protecting the cable with an inline lightning > protector between the RJ45 jack and the radio. > > If you haven't done that, then that's the first thing to fix. > > BTW, avoid homemade patch cables whenever possible. Quality factory cables > are hydraulically pressed and the plug is hermetically fused for a vastly > superior connection compared to anything you can do with simple hand > crimpers. And all outdoor cables must be UV-grade cabling with > weatherproof sheathing and water repellant inside (so-called "flooded" > cable). > > -mel beckman > >> On Jun 19, 2015, at 4:54 AM, Hal Ponton wrote: >> >> What version of the controller are you using, we're running 3.something >> at that works fine. >> >> We've turned off auto update on all of the sites on the server, and >> Nagios monitors them, we certainly don't see reboots 2-3 times a day, >> the last time ours rebooted was when we lost power at our office. >> >> Contact me off list if you want me to take a look. >> >> Regards, >> >> Hal Ponton >> >> Senior Network Engineer >> >> Buzcom / FibreWiFi >> >> Tel: 07429 979 217 >> Email: hal at buzcom.net >> >>> On 19 Jun 2015, at 11:01, Bob Evans >>> wrote: >>> >>> Ubiquiti Networks UniFi UAP-PRO Enterprise WiFi System - hard to >>> recommend >>> at this point. We saw people mention this brand here on the list - >>> people >>> like them. So what could we have set incorrectly ? They drop link and >>> re-provision on their own at odd times day or night. >>> >>> We have completed everything tech support asked of us. (Really, lame >>> emails they respond with as if they didn't read your text - they won't >>> call and you can't call them). We used POE from ciscos - then changed >>> to >>> their POE provided. They didn't recommend it, but we plugged them all >>> into >>> APC UPSes..... no difference. They all re-provision at different times >>> even when no one is connected or in the building at odd hours like 2am. >>> Each one does this 2-3 times per 24 hour period. >>> >>> Has anyone else experienced this? >>> Anyone know what we may have set incorrectly ? >>> Is this normal - do people put up with the 2 mins the APs are >>> unavailable >>> about 3 times a day? (UniFi support acts like it's not a big issues.) >>> >>> We use the UniFi controller on mac os x. We use their EdgeMax Edge >>> Router. >>> All the latest software in everything UniFi. >>> >>> Thank You >>> Bob Evans >>> >>> >>> >>> >>> >>> >>> > From Steve.Mikulasik at civeo.com Fri Jun 19 14:27:41 2015 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Fri, 19 Jun 2015 14:27:41 +0000 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> Message-ID: I run lots of these. How many APs? Have you reset them to default yet? https://community.ubnt.com/t5/UniFi-Frequently-Asked-Questions/UniFi-How-do-I-reset-the-UAP-to-factory-default-settings/ta-p/412585 Steve Mikulasik -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bob Evans Sent: Friday, June 19, 2015 8:10 AM To: Jared Mauch Cc: nanog at nanog.org Subject: Re: Ghosts in our 6 New Ubiquity Pros - provision issues. Thanks Jared Cables are 3 to 6 feet long - swapped them out already. All cables manufacture made purchased. They plug into the switch directly. Each switch is them multi-mode fiber back to a main switch where the edgeMax router and other gear are connected. Bob Evans > I have a variety of their gear and don't have problems like this. Have > you run a cable tester on the wiring? This sounds quite odd and is > something I haven't seen. > > They do most of their support in their forums vs email. The email is > mainly for RMA support. > > What version software is on your controller and the UAP-Pros? > > Jared Mauch > >> On Jun 19, 2015, at 6:01 AM, Bob Evans >> wrote: >> >> Ubiquiti Networks UniFi UAP-PRO Enterprise WiFi System - hard to >> recommend at this point. We saw people mention this brand here on the >> list - people like them. So what could we have set incorrectly ? They >> drop link and re-provision on their own at odd times day or night. >> >> We have completed everything tech support asked of us. (Really, lame >> emails they respond with as if they didn't read your text - they >> won't call and you can't call them). We used POE from ciscos - then >> changed to their POE provided. They didn't recommend it, but we >> plugged them all into APC UPSes..... no difference. They all >> re-provision at different times even when no one is connected or in >> the building at odd hours like 2am. >> Each one does this 2-3 times per 24 hour period. >> >> Has anyone else experienced this? >> Anyone know what we may have set incorrectly ? >> Is this normal - do people put up with the 2 mins the APs are >> unavailable about 3 times a day? (UniFi support acts like it's not a >> big issues.) >> >> We use the UniFi controller on mac os x. We use their EdgeMax Edge >> Router. >> All the latest software in everything UniFi. >> >> Thank You >> Bob Evans >> >> >> >> >> >> > From SNaslund at medline.com Fri Jun 19 14:43:08 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 19 Jun 2015 14:43:08 +0000 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: References: <29116.1434588870@server1.tristatelogic.com> <55833FB1.4070806@megagroup.ru> <9578293AE169674F9A048B2BC9A081B401C0530D3B@MUNPRDMBXA1.medline.com> <03fe5e33930b416c9a1f5ec60d469d34@BRTEXMB02.phillips66.net> Message-ID: <9578293AE169674F9A048B2BC9A081B401C0530FE8@MUNPRDMBXA1.medline.com> No I intentionally left those out. Here is why. If they would do small incremental work, they don?t get into the areas of congressional approval and GSA. You can just do the small incremental projects under your IT operations budgeting. There is a big misconception that everything requires congressional approval or a lot of red tape to get done, it is all about thresholds. If you wanted to replace an old obsolete switch or router, you don't need to go there. If you propose to replace 10,000 switches and routers, then you would. Steven Naslund Chicago IL >>On Fri, Jun 19, 2015 at 9:55 AM, Darden, Patrick wrote: >> Good point. It's a massive job, and sometimes it is best to look at those piecemeal. Start with small goals, and pick low hanging fruit--your example of the server room is good. Set it up with and IDS, a firewall, harden the >>hosts by turning off/removing unused/unneeded services, setting up tripwire, and encrypt all data on the drives, then look to password policy enforcement. Then start actively securing it (monthly audits, daily log checks, etc.). >>Doable. Then pick the next lowest hanging fruit and repeat. >You left out: > Formulate Bid Solicitation team > Procure funding for Bid Solicitation team > Request Congressional approval for Bid Solicitation team > Request funding for team to win Congressional approval of Bid Solicitation team > Receive first round funding for team to win Congressional approval..... > Director retires, project status in limbo > New round of higher funding sought > Congressional recess, projects in limbo > Bid process begins, 3 of 4 are non-GSA and require further funding for new approval process > After 2 years of paperwork, initial funding for 2 year old IDS >v1.1 (that's what was approved!) is approved. > repeat, ad nauseam >-Jim P. From Patrick.Darden at p66.com Fri Jun 19 14:47:03 2015 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Fri, 19 Jun 2015 14:47:03 +0000 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: References: <29116.1434588870@server1.tristatelogic.com> <55833FB1.4070806@megagroup.ru> <9578293AE169674F9A048B2BC9A081B401C0530D3B@MUNPRDMBXA1.medline.com> <03fe5e33930b416c9a1f5ec60d469d34@BRTEXMB02.phillips66.net> Message-ID: I believe, if the fruit is small enough, you could sneak some of this in through the cracks. Bull it through via sheer determination. But I understand what you mean.... The more official it is, the more visible it is, the more difficult it is.... The same for any bureaucracy, but a quantum leap here. -- patrick darden -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jim Popovitch Sent: Friday, June 19, 2015 9:12 AM To: nanog at nanog.org Subject: [EXTERNAL]Re: OPM Data Breach - Whitehouse Petition - Help Wanted On Fri, Jun 19, 2015 at 9:55 AM, Darden, Patrick wrote: > Good point. It's a massive job, and sometimes it is best to look at those piecemeal. Start with small goals, and pick low hanging fruit--your example of the server room is good. Set it up with and IDS, a firewall, harden the hosts by turning off/removing unused/unneeded services, setting up tripwire, and encrypt all data on the drives, then look to password policy enforcement. Then start actively securing it (monthly audits, daily log checks, etc.). Doable. Then pick the next lowest hanging fruit and repeat. You left out: Formulate Bid Solicitation team Procure funding for Bid Solicitation team Request Congressional approval for Bid Solicitation team Request funding for team to win Congressional approval of Bid Solicitation team Receive first round funding for team to win Congressional approval..... Director retires, project status in limbo New round of higher funding sought Congressional recess, projects in limbo Bid process begins, 3 of 4 are non-GSA and require further funding for new approval process After 2 years of paperwork, initial funding for 2 year old IDS v1.1 (that's what was approved!) is approved. repeat, ad nauseam -Jim P. From tetherow at shwisp.net Fri Jun 19 14:55:12 2015 From: tetherow at shwisp.net (Sam Tetherow) Date: Fri, 19 Jun 2015 09:55:12 -0500 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C0530ED1@MUNPRDMBXA1.medline.com> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> <9578293AE169674F9A048B2BC9A081B401C0530ED1@MUNPRDMBXA1.medline.com> Message-ID: <55842D50.9050204@shwisp.net> The IP can change on the UniFi without having to re-adopt or re-provision. APs are identified by MAC address at the UniFi protocol level (not layer 2). On 06/19/2015 09:09 AM, Naslund, Steve wrote: > Here is another though. If your APs are re-provisioning every eight hours, what is your DHCP lease time? Are you sure the APs are able to renew their leases (if not, could your scope be full)? Do you see the IP addresses on the APs changing when they come back up? These could indicate a DHCP server issue. If the AP gets a new IP address it will likely have to be re-adopted to the controller. You might want to static address one or more APs to test this theory. > > Steven Naslund > Chicago IL From bill at herrin.us Fri Jun 19 15:06:43 2015 From: bill at herrin.us (William Herrin) Date: Fri, 19 Jun 2015 11:06:43 -0400 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C0530FE8@MUNPRDMBXA1.medline.com> References: <29116.1434588870@server1.tristatelogic.com> <55833FB1.4070806@megagroup.ru> <9578293AE169674F9A048B2BC9A081B401C0530D3B@MUNPRDMBXA1.medline.com> <03fe5e33930b416c9a1f5ec60d469d34@BRTEXMB02.phillips66.net> <9578293AE169674F9A048B2BC9A081B401C0530FE8@MUNPRDMBXA1.medline.com> Message-ID: On Fri, Jun 19, 2015 at 10:43 AM, Naslund, Steve wrote: > No I intentionally left those out. Here is why. If they would do small > incremental work, they don?t get into the areas of congressional approval > and GSA. You can just do the small incremental projects under your IT > operations budgeting. This is only possible when you take all the policies developed to comply with both the law and executive orders and chuck them right out the window. At that point you're operating with no authority and all of the responsibility, which is grounds for termination even if what you do actually works. Especially if you're a contractor as the majority of operations folks in the Federal government are. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From SNaslund at medline.com Fri Jun 19 16:12:55 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 19 Jun 2015 16:12:55 +0000 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: References: <29116.1434588870@server1.tristatelogic.com> <55833FB1.4070806@megagroup.ru> <9578293AE169674F9A048B2BC9A081B401C0530D3B@MUNPRDMBXA1.medline.com> <03fe5e33930b416c9a1f5ec60d469d34@BRTEXMB02.phillips66.net> <9578293AE169674F9A048B2BC9A081B401C0530FE8@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401C0531107@MUNPRDMBXA1.medline.com> Wrong. I was a government (US Air Force) network engineer for over 10 years (not a contractor, a full time employee). There is an O&M budget created for the day to day operation and maintenance of IT systems. This is approved along with your department's budget annually. If you classify updating equipment as an O&M function (which it routinely is) then you have no issues. You purchase your equipment off pre-existing purchasing agreements in place with your agency or the GSA. If your purchases exceeds certain threshold or the amount available under your O&M funding, then you need to go out and negotiate a project and contract it out. Trust me I know how this works, I was also a contracting inspector for communications systems during my time with the US Air Force. For example, I want to connect one new building to my infrastructure including the installation of fiber to the building and purchasing network switches and routers. The organization that wants to do this can eat that cost under their IT O&M budget without issue or breaking any rules. It could also be contracted under the buildings construction project if it is new construction. If I want to replace an existing failed or obsolete firewall with something under a current GSA schedule, I can do that as well. The only thing that matters here is that I do not cross certain dollar thresholds (which vary per department) and that I can absorb the cost into my O&M funding. These all comply with existing contracting law. Let me give you another example. The Air Force Pacific Command wanted to unify several disparate TDM Voice/Video/Data networks into a single ATM switched infrastructure on fiber rings. The cost of that project ran to over 50 million dollars and was done with any additional congressional approval. Air Force Pacific Commander absorbed the entire cost under their existing authorization for maintenance of command and control systems. The construction of manholes and duct work was put out for bid to local construction companies under the Air Force Contracting Regulations. If fact, the DoD was told this was being done (since it modified the engineering of some existing systems) and they agreed to commit some of their O&M dollars to it as a prototype for other commands. None of that work required GSA or congressional scrutiny because it was all conducted under pre-existing authorizations. Project went from concept to full production in under two years. If you want new PCs, the Department of Defense negotiates contracts that you can purchase off of agency wide. It is a common misconception that everything has to go out to bid every time. Things that are purchased routinely (PCs, printers, routers, switches, etc.) are negotiated in large multiyear contracts that are already available to the purchaser. You only need to go back to Congress is you are looking for money that is not already appropriated to you. If my budget appropriation includes $10 million for IT security, I can go ahead and spend that money on IT security devices and services without any more approval through the existing procurement system. In my experience it is more about some government wonk that would rather tell you to launch a $100 million project rather than get off his ass and do something small and useful. Rather than work, just make it so hard to start that it never happens. Steven Naslund Chicago IL >>>This is only possible when you take all the policies developed to comply with both the law and executive orders and chuck them right out the window. At that point you're operating with no authority and all of the responsibility, >>>which is grounds for termination even if what you do actually works. Especially if you're a contractor as the majority of operations folks in the Federal government are. >>>Regards, >>>Bill Herrin From jimpop at gmail.com Fri Jun 19 16:23:10 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Fri, 19 Jun 2015 12:23:10 -0400 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C0531107@MUNPRDMBXA1.medline.com> References: <29116.1434588870@server1.tristatelogic.com> <55833FB1.4070806@megagroup.ru> <9578293AE169674F9A048B2BC9A081B401C0530D3B@MUNPRDMBXA1.medline.com> <03fe5e33930b416c9a1f5ec60d469d34@BRTEXMB02.phillips66.net> <9578293AE169674F9A048B2BC9A081B401C0530FE8@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C0531107@MUNPRDMBXA1.medline.com> Message-ID: On Fri, Jun 19, 2015 at 12:12 PM, Naslund, Steve wrote: > There is an O&M budget created for the day to day operation and maintenance of IT systems. This is approved along with your department's budget annually. If you classify updating equipment as an O&M function (which it routinely is) then you have no issues. You purchase your equipment off pre-existing purchasing agreements in place with your agency or the GSA. If your purchases exceeds certain threshold or the amount available under your O&M funding, then you need to go out and negotiate a project and contract it out. Trust me I know how this works, I was also a contracting inspector for communications systems during my time with the US Air Force. I'm fairly certain that new IDS purchases, for an org as large as OPM, which would also include project-term Support contracts, isn't going to fit into any pre-approved O&M day to day budget... other than maybe an AF budget :-) -Jim P. From bob at FiberInternetCenter.com Fri Jun 19 16:26:42 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 19 Jun 2015 09:26:42 -0700 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C0530EB6@MUNPRDMBXA1.medline.com> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180>, <3A3B0EA5-81A2-48B9-A34A-021CEFAE128B@beckman.org> <9578293AE169674F9A048B2BC9A081B401C0530EB6@MUNPRDMBXA1.medline.com> Message-ID: <20c65aea694462177a8a5b5707e0ffa2.squirrel@66.201.44.180> > That's possible but I if they are re-provisioning on a regular schedule I > kind of doubt it. It would be easy to test though. Plug an AP directly > into your switch with a quality pre-manufactured patch cord and see how it > acts. If it exhibits the same symptom it is probably not cabling. Also, > have you checked your interface counters for any packet errors? Yes, no packet errors crcs or frags. > Don't > forget to look at your controller because if the controller became > unreachable for any length of time that could easily cause your APs to > re-provision as they reconnect with the controller. This is did not know - thought the controller was just to provision and monitor. After all why would a manufacturer make one point of failure for a campus setup that uses thier own edgerouter for the dhcp etc. Doesnt seem correct. But will will investigate it. > I might set up a ping > every second from the site of the access points to the controller and make > sure the availability of the controller is 100%. Yes that and what the ciscos report on the port link. > If you are on Cisco > switches you should have log messages regarding PoE be granted on > particular ports as well as up down messages on the interfaces. Yep and we get them. > Do you > see the ports going up and down? It is important to have NTP on the APs > and switches so that you can correlate events in time (i.e. did the AP > reboot causing the Ethernet link to drop or did the link drop causing the > reboot?) I am sure its the APs dropping - as non of the other devices VOIP phones etc drop in the logs. Thanks Steven Bob > > Steven Naslund > Chicago IL > > >>Bob, I've deployed tons of Ubiquiti gear, and have seen this problem >> before. It always turns out to be poor quality cable installation. POE >> does not tolerate low quality connectors, especially in outdoor >> environments. There are >many aspects to a quality cabling job, so the >> best thing you can do is seek out a qualified installer with outdoor POE >> experience. >> >>The most common problem I see is people using crimp-on RJ45 connectors >> directly on the ends of their cable runs. This is not how structured >> cabling is designed to work, in particular because most crimp-on >> connectors are intended for >stranded copper wire (such as that used in >> very flexible patch cords, designed to run horizontally over only a few >> dozens of feet), whereas the "riser" and "plenum" cable used for >> long-distance runs has solid core wires. The tiny >teeth in standard >> crimp connectors are designed to penetrate stranded wire, to make a solid >> electrical contact. With solid core wire, they just bend to the side of >> the copper core, making tenuous contact, which will conduct POE >current >> poorly (resulting in the resets you see) and eventually fail altogether >> as the improper connection corrodes over time. >> >>The correct installation process is to use "punch-down" RJ45 jacks at >> each end of the cable run, and connect from those jacks to your equipment >> (radio at one end, POE switch at the other). On the outdoor side, the >> jack/plug junction >needs to be in a NEMA weatherproof enclosure, with >> weathertight fittings. And, for human and equipment safety, you must use >> shielded Cat5e/6 cable anytime you go outdoors, grounding only one end >> (usually the radio end), and >protecting the cable with an inline >> lightning protector between the RJ45 jack and the radio. > >>If you haven't done that, then that's the first thing to fix. > >>BTW, avoid homemade patch cables whenever possible. Quality factory >> cables are hydraulically pressed and the plug is hermetically fused for a >> vastly superior connection compared to anything you can do with simple >> hand crimpers. And >all outdoor cables must be UV-grade cabling with >> weatherproof sheathing and water repellant inside (so-called "flooded" >> cable). > >> -mel beckman > > From nanog at ics-il.net Fri Jun 19 16:30:08 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 19 Jun 2015 11:30:08 -0500 (CDT) Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <20c65aea694462177a8a5b5707e0ffa2.squirrel@66.201.44.180> Message-ID: <3919110.1554.1434731391255.JavaMail.mhammett@ThunderFuck> The UBNT controller is only required when setting up the APs or for certain guest portal functions. I'd just leave it connected all of the time. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Bob Evans" To: "Steve Naslund" Cc: nanog at nanog.org Sent: Friday, June 19, 2015 11:26:42 AM Subject: RE: Ghosts in our 6 New Ubiquity Pros - provision issues. > That's possible but I if they are re-provisioning on a regular schedule I > kind of doubt it. It would be easy to test though. Plug an AP directly > into your switch with a quality pre-manufactured patch cord and see how it > acts. If it exhibits the same symptom it is probably not cabling. Also, > have you checked your interface counters for any packet errors? Yes, no packet errors crcs or frags. > Don't > forget to look at your controller because if the controller became > unreachable for any length of time that could easily cause your APs to > re-provision as they reconnect with the controller. This is did not know - thought the controller was just to provision and monitor. After all why would a manufacturer make one point of failure for a campus setup that uses thier own edgerouter for the dhcp etc. Doesnt seem correct. But will will investigate it. > I might set up a ping > every second from the site of the access points to the controller and make > sure the availability of the controller is 100%. Yes that and what the ciscos report on the port link. > If you are on Cisco > switches you should have log messages regarding PoE be granted on > particular ports as well as up down messages on the interfaces. Yep and we get them. > Do you > see the ports going up and down? It is important to have NTP on the APs > and switches so that you can correlate events in time (i.e. did the AP > reboot causing the Ethernet link to drop or did the link drop causing the > reboot?) I am sure its the APs dropping - as non of the other devices VOIP phones etc drop in the logs. Thanks Steven Bob > > Steven Naslund > Chicago IL > > >>Bob, I've deployed tons of Ubiquiti gear, and have seen this problem >> before. It always turns out to be poor quality cable installation. POE >> does not tolerate low quality connectors, especially in outdoor >> environments. There are >many aspects to a quality cabling job, so the >> best thing you can do is seek out a qualified installer with outdoor POE >> experience. >> >>The most common problem I see is people using crimp-on RJ45 connectors >> directly on the ends of their cable runs. This is not how structured >> cabling is designed to work, in particular because most crimp-on >> connectors are intended for >stranded copper wire (such as that used in >> very flexible patch cords, designed to run horizontally over only a few >> dozens of feet), whereas the "riser" and "plenum" cable used for >> long-distance runs has solid core wires. The tiny >teeth in standard >> crimp connectors are designed to penetrate stranded wire, to make a solid >> electrical contact. With solid core wire, they just bend to the side of >> the copper core, making tenuous contact, which will conduct POE >current >> poorly (resulting in the resets you see) and eventually fail altogether >> as the improper connection corrodes over time. >> >>The correct installation process is to use "punch-down" RJ45 jacks at >> each end of the cable run, and connect from those jacks to your equipment >> (radio at one end, POE switch at the other). On the outdoor side, the >> jack/plug junction >needs to be in a NEMA weatherproof enclosure, with >> weathertight fittings. And, for human and equipment safety, you must use >> shielded Cat5e/6 cable anytime you go outdoors, grounding only one end >> (usually the radio end), and >protecting the cable with an inline >> lightning protector between the RJ45 jack and the radio. > >>If you haven't done that, then that's the first thing to fix. > >>BTW, avoid homemade patch cables whenever possible. Quality factory >> cables are hydraulically pressed and the plug is hermetically fused for a >> vastly superior connection compared to anything you can do with simple >> hand crimpers. And >all outdoor cables must be UV-grade cabling with >> weatherproof sheathing and water repellant inside (so-called "flooded" >> cable). > >> -mel beckman > > From bob at FiberInternetCenter.com Fri Jun 19 16:45:02 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 19 Jun 2015 09:45:02 -0700 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <55842D50.9050204@shwisp.net> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> <9578293AE169674F9A048B2BC9A081B401C0530ED1@MUNPRDMBXA1.medline.com> <55842D50.9050204@shwisp.net> Message-ID: <0461cca02f3548269bbcf5b71c705b06.squirrel@66.201.44.180> We have all APs set with static addresses. EdgeMax only hands out IPs to clients using the APs. This happens when people are using the APs and when no one is even in the building at 2am when there are no clients connected. It can happen to one then 5 hours later it happens again...then doesn't happen again for 12 hours. Totally random no interval. It is nice to know that others have no issues with these UniFi AP Pros. They seem to be fine except for the 2 mins or so they randomly drop link and reboot themselves. All are on APC UPSes and other devices in the same switch , like voip phones, never drop the ports. They are all new, delivered in various batches over time. We checked and all are the latest versions. Bob Evans > The IP can change on the UniFi without having to re-adopt or > re-provision. APs are identified by MAC address at the UniFi protocol > level (not layer 2). > > On 06/19/2015 09:09 AM, Naslund, Steve wrote: >> Here is another though. If your APs are re-provisioning every eight >> hours, what is your DHCP lease time? Are you sure the APs are able to >> renew their leases (if not, could your scope be full)? Do you see the >> IP addresses on the APs changing when they come back up? These could >> indicate a DHCP server issue. If the AP gets a new IP address it will >> likely have to be re-adopted to the controller. You might want to >> static address one or more APs to test this theory. >> >> Steven Naslund >> Chicago IL > > From bob at FiberInternetCenter.com Fri Jun 19 16:57:29 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 19 Jun 2015 09:57:29 -0700 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> Message-ID: <6bd2a2ff38c562392fd481154f83effc.squirrel@66.201.44.180> Thank You Charles, Been on NANOG a while - all the basic stuff we know well. Like, cables, cluster occurrences etc. Looking for the UniFi specific experience. Its not the switches, power, cables, ports show no CRC issues etc. We even setup another network with just 2 and it happens randomly - so its some code or something. Think I'm going to let one of the guys here login the the controller and see if we missed a setting in the latest code. NANOGs real good at having someone with specific targeted knowledge appear. Thank You Bob Evans CTO > On 2015-06-19 05:01, Bob Evans wrote: >> Ubiquiti Networks UniFi UAP-PRO Enterprise WiFi System - hard to >> recommend >> at this point. We saw people mention this brand here on the list - >> people >> like them. So what could we have set incorrectly ? They drop link and >> re-provision on their own at odd times day or night. > > Drop link all the way down to layer 1? What does re-provision mean? > Lose/re acquire DHCP lease? \ > > What is your network topology? What kind of switches are you using? > What's the length of the cable runs? Have you had an electrician check > your wiring? > How many access points are you running? How many fail? Do they fail in > any kind of cluster/pattern? > > That's just the basic questions. > > Lots more information needed if you want free support from the NANOG > hive mind :D > > They have millions of satisfied customers in deployments from some of > the worlds largest shopping malls to multi state ISPs. Different gear > across that customer base of course. > > >> >> We have completed everything tech support asked of us. (Really, lame >> emails they respond with as if they didn't read your text - they won't >> call and you can't call them). We used POE from ciscos - then changed >> to >> their POE provided. > > POE from ciscos.... mid span injector, or switch port? > > > They didn't recommend it, but we plugged them all into >> APC UPSes..... no difference. > > The midspan injectors you mean? Hmmmm, wonder why they didn't want you > to put them in UPS. Did they provide any explanation? > > > They all re-provision at different times >> even when no one is connected or in the building at odd hours like 2am. >> Each one does this 2-3 times per 24 hour period. > > Interesting. Any repeated offenders? > > > >> >> Has anyone else experienced this? >> Anyone know what we may have set incorrectly ? >> Is this normal - do people put up with the 2 mins the APs are >> unavailable >> about 3 times a day? (UniFi support acts like it's not a big issues.) >> > > Do they come back on their own? What's the "downtime" time window? > > > >> We use the UniFi controller on mac os x. > > Mac OSX isn't a server platform. Sorry. Use Windows 2k12 or Ubuntu > Server (or your favorite debian or Redhat flavor). I've had zero > problems on either of those platforms. > > What's the topology between the access points and your controller > "server"? > From jra at baylink.com Fri Jun 19 17:06:22 2015 From: jra at baylink.com (Jay Ashworth) Date: Fri, 19 Jun 2015 13:06:22 -0400 (EDT) Subject: REMINDER: LEAP SECOND Message-ID: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> The IERS will be adding a second to time again on my birthday; 2015-06-30T23:59:59 2015-06-30T23:59:60 2015-07-01T00:00:00 Have fun, everyone. :-) 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 woody at pch.net Fri Jun 19 17:06:10 2015 From: woody at pch.net (Bill Woodcock) Date: Fri, 19 Jun 2015 10:06:10 -0700 Subject: Anycast provider for SMTP? In-Reply-To: References: Message-ID: <7A2176F0-629D-44C2-92A2-3E8F6558CDB1@pch.net> > On Jun 18, 2015, at 10:19 PM, James Hartig wrote: > Just curious, how does DNS load balancing work if people are using > 8.8.8.8/208.67.222.222 or basically any public resolvers that cache and > have a significant (relatively speaking) user-base? Is the actual percent > of requests so small that it doesn't matter? The percent of requests is significant, but OpenDNS and Google and the other significant open resolvers are, themselves, anycast, so the geographic correlation is preserved. Also, there?s an RFC for passing an origin IP tag along to the authoritative server, but I don?t know if anyone?s actually doing anything with that on any global inter-provider scale. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tetherow at shwisp.net Fri Jun 19 17:08:04 2015 From: tetherow at shwisp.net (Sam Tetherow) Date: Fri, 19 Jun 2015 12:08:04 -0500 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <0461cca02f3548269bbcf5b71c705b06.squirrel@66.201.44.180> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> <9578293AE169674F9A048B2BC9A081B401C0530ED1@MUNPRDMBXA1.medline.com> <55842D50.9050204@shwisp.net> <0461cca02f3548269bbcf5b71c705b06.squirrel@66.201.44.180> Message-ID: <55844C74.2000602@shwisp.net> Only have 1 Pro on my network and it hasn't given me any issues, several of the original AP and AP-LR as well without issues. What is the uptime on the AP? You should be able to ssh into the APs using the controller username and password. It is a linux base so 'uptime' will tell you. You can also check for ethernet errors using 'ip -s link' on the AP side. On 06/19/2015 11:45 AM, Bob Evans wrote: > We have all APs set with static addresses. EdgeMax only hands out IPs to > clients using the APs. > > This happens when people are using the APs and when no one is even in the > building at 2am when there are no clients connected. It can happen to one > then 5 hours later it happens again...then doesn't happen again for 12 > hours. Totally random no interval. > > It is nice to know that others have no issues with these UniFi AP Pros. > They seem to be fine except for the 2 mins or so they randomly drop link > and reboot themselves. All are on APC UPSes and other devices in the same > switch , like voip phones, never drop the ports. > > They are all new, delivered in various batches over time. We checked and > all are the latest versions. > > Bob Evans > > > > >> The IP can change on the UniFi without having to re-adopt or >> re-provision. APs are identified by MAC address at the UniFi protocol >> level (not layer 2). >> >> On 06/19/2015 09:09 AM, Naslund, Steve wrote: >>> Here is another though. If your APs are re-provisioning every eight >>> hours, what is your DHCP lease time? Are you sure the APs are able to >>> renew their leases (if not, could your scope be full)? Do you see the >>> IP addresses on the APs changing when they come back up? These could >>> indicate a DHCP server issue. If the AP gets a new IP address it will >>> likely have to be re-adopted to the controller. You might want to >>> static address one or more APs to test this theory. >>> >>> Steven Naslund >>> Chicago IL >> > From outsider at scarynet.org Fri Jun 19 17:08:47 2015 From: outsider at scarynet.org (Alexander Maassen) Date: Fri, 19 Jun 2015 19:08:47 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> Message-ID: So you need to wait one more second before you may pop the bottle? :) On Fri, June 19, 2015 7:06 pm, Jay Ashworth wrote: > The IERS will be adding a second to time again on my birthday; > > 2015-06-30T23:59:59 > 2015-06-30T23:59:60 > 2015-07-01T00:00:00 > > Have fun, everyone. :-) > > 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 SNaslund at medline.com Fri Jun 19 17:15:33 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 19 Jun 2015 17:15:33 +0000 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: References: <29116.1434588870@server1.tristatelogic.com> <55833FB1.4070806@megagroup.ru> <9578293AE169674F9A048B2BC9A081B401C0530D3B@MUNPRDMBXA1.medline.com> <03fe5e33930b416c9a1f5ec60d469d34@BRTEXMB02.phillips66.net> <9578293AE169674F9A048B2BC9A081B401C0530FE8@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C0531107@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401C05311E5@MUNPRDMBXA1.medline.com> Here is their 2013 budget https://www.opm.gov/about-us/budget-performance/budgets/2013-budget.pdf Glancing through it they had a 2.1B total appropriation with 90.5M dedicated to salaries and expenses where IT would fall. It appears that their CIO also has a multi-year fund around 70M separately allocated to systems modernization. One telling issue is that the budget talks about their priorities and within all of their goals around ensuring diversity, treating their employees well, providing good customer service, etc; there is not one mention of IT security. It is just about setting priorities. I would bet you that there are plenty of IDP contracts out there that they could ride on. This saves them from the entire RFP and evaluation process by simply stating that their needs are equivalent and a usable contract is already in place. Often in government contracts, support for a fixed period of time is rolled into the purchase price. This is done because the government often cannot commit dollars in forward years. So, when you buy your IDP device you pay for five years of support because you know you have the money this year but do not have next year's appropriation yet. Most government contracts have very sweet support and maintenance options because vendors often differentiate themselves that way without laying down on the up front price and hurting cash flow. They can bury the hidden costs of supporting the devices and just claim a huge number for sales in their current quarter. Here is the best analogy I have ever heard about how government contracting really works : ***Paint is peeling on your house. You use your own authority to buy a can of paint and touch it up with no other approval (your O&M budget) ***You let the peeling paint slide too long and now you need to replace all of your siding. You got to your wife and she tells you to wait until next spring when you have the money in the budget (department level O&M money) ***You let the peeling paint slide WAY too long and now you need to rip out entire walls and while we are at it we might as well put in an addition. You got to the bank to get a home improvement loan (congressional line item budgeting). This is where they have let their systems get too. Agency heads like to shift blame by going to congress and saying I can't do this because I need a huge appropriation to even start. The correct question from congress is to ask that agency head why they did not ask for an IT budget that included enough money to support and maintain a secure infrastructure. They should also ask, what small steps have you taken so far within your own IT budget to address security concerns. For example, do you routinely replace desktops over a certain age, is your malware protection software in place and up to date, is your firewall on the latest code release? If you ran a company would you not fire an IT director that came to you and said "we need to replace all of our network, servers, and PCs because they are all obsolete NOW...TODAY? Wouldn't you wonder what he had been doing with the O&M budget you give to him every year? The truth of this is that most agency heads do not care about IT security, they just do not. The only exception might be DoD because they are well aware that they have enemies that are looking to take them out and it is their primary responsibility to fight enemies. Most other agencies don't have the mindset of having a adversary looking at them and don't care because they don't get hurt, the citizen who's data is lost takes the hit. It might not change things immediately to fire the head of this agency but it does let other agency heads know that if you ignore IT you could lose your job. Steven Naslund Chicago IL >>On Fri, Jun 19, 2015 at 12:12 PM, Naslund, Steve wrote: >> There is an O&M budget created for the day to day operation and maintenance of IT systems. This is approved along with your department's budget annually. If you classify updating equipment as an O&M function (which it routinely >>is) then you have no issues. You purchase your equipment off pre-existing purchasing agreements in place with your agency or the GSA. If your purchases exceeds certain threshold or the amount available under your O&M funding, >>then you need to go out and negotiate a project and contract it out. Trust me I know how this works, I was also a contracting inspector for communications systems during my time with the US Air Force. >> >>I'm fairly certain that new IDS purchases, for an org as large as OPM, which would also include project-term Support contracts, isn't going to fit into any pre-approved O&M day to day budget... other than maybe an AF budget :-) >>-Jim P. From SNaslund at medline.com Fri Jun 19 17:30:16 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 19 Jun 2015 17:30:16 +0000 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C05311E5@MUNPRDMBXA1.medline.com> References: <29116.1434588870@server1.tristatelogic.com> <55833FB1.4070806@megagroup.ru> <9578293AE169674F9A048B2BC9A081B401C0530D3B@MUNPRDMBXA1.medline.com> <03fe5e33930b416c9a1f5ec60d469d34@BRTEXMB02.phillips66.net> <9578293AE169674F9A048B2BC9A081B401C0530FE8@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C0531107@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C05311E5@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401C0531251@MUNPRDMBXA1.medline.com> Here is a great quote straight out of the OPM budget of 2013. ----------------------------------------------------------------- Human Resources Line of Business (HR LOB) The Human Resources Line of Business (HR LOB) leads the government-wide transformation of HR Information Technology by focusing on modernization, integration, and performance assessment. The HR LOB is a model for its cross-agency collaboration which achieves HR service delivery improvements and cost savings results. ----------------------------------------------------------------- I guess being the model for cross-agency collaboration means providing all of the employee data any Chinese agency wants :) Steven Naslund Chicago IL >>On Fri, Jun 19, 2015 at 12:12 PM, Naslund, Steve wrote: >> There is an O&M budget created for the day to day operation and maintenance of IT systems. This is approved along with your department's budget annually. If you classify updating equipment as an O&M function (which it routinely >>is) then you have no issues. You purchase your equipment off pre-existing purchasing agreements in place with your agency or the GSA. If your purchases exceeds certain threshold or the amount available under your O&M funding, >>then you need to go out and negotiate a project and contract it out. Trust me I know how this works, I was also a contracting inspector for communications systems during my time with the US Air Force. >> >>I'm fairly certain that new IDS purchases, for an org as large as OPM, which would also include project-term Support contracts, isn't going to fit into any pre-approved O&M day to day budget... other than maybe an AF budget :-) >>-Jim P. From SNaslund at medline.com Fri Jun 19 17:44:41 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 19 Jun 2015 17:44:41 +0000 Subject: OPM Data Breach - Whitehouse Petition - Help Wanted In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C0531251@MUNPRDMBXA1.medline.com> References: <29116.1434588870@server1.tristatelogic.com> <55833FB1.4070806@megagroup.ru> <9578293AE169674F9A048B2BC9A081B401C0530D3B@MUNPRDMBXA1.medline.com> <03fe5e33930b416c9a1f5ec60d469d34@BRTEXMB02.phillips66.net> <9578293AE169674F9A048B2BC9A081B401C0530FE8@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C0531107@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C05311E5@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B401C0531251@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401C0531271@MUNPRDMBXA1.medline.com> Here is another great document, their Strategic IT Plan http://www.opm.gov/about-us/budget-performance/strategic-plans/strategic-it-plan.pdf. I especially like this excerpt from Page 9. ----------------------------------------------------------------------------- Phase 3 ? Assess (December 2014): We will baseline and begin routinely reporting against our performance outcomes: ? Compliance with laws, policies, and successful practices; ? User and stakeholder satisfaction with improved IT capabilities; and ? Cost per IT service or transaction. No additional funding or manpower is required to implement these initiatives. Stronger IT leadership will result in cost avoidance and cost savings that will allow us to shift valuable, scarce resources to high priority programs. ---------------------------------------------------------------------------- I guess money is not the problem according to this. I guess their "Stronger IT Leadership" is not strong enough. Steven Naslund Chicago IL -----Original Message----- From: Naslund, Steve Sent: Friday, June 19, 2015 12:30 PM To: Naslund, Steve; Jim Popovitch; nanog at nanog.org Subject: RE: OPM Data Breach - Whitehouse Petition - Help Wanted Here is a great quote straight out of the OPM budget of 2013. ----------------------------------------------------------------- Human Resources Line of Business (HR LOB) The Human Resources Line of Business (HR LOB) leads the government-wide transformation of HR Information Technology by focusing on modernization, integration, and performance assessment. The HR LOB is a model for its cross-agency collaboration which achieves HR service delivery improvements and cost savings results. ----------------------------------------------------------------- I guess being the model for cross-agency collaboration means providing all of the employee data any Chinese agency wants :) Steven Naslund Chicago IL >>On Fri, Jun 19, 2015 at 12:12 PM, Naslund, Steve wrote: >> There is an O&M budget created for the day to day operation and maintenance of IT systems. This is approved along with your department's budget annually. If you classify updating equipment as an O&M function (which it routinely >>is) then you have no issues. You purchase your equipment off pre-existing purchasing agreements in place with your agency or the GSA. If your purchases exceeds certain threshold or the amount available under your O&M funding, >>then you need to go out and negotiate a project and contract it out. Trust me I know how this works, I was also a contracting inspector for communications systems during my time with the US Air Force. >> >>I'm fairly certain that new IDS purchases, for an org as large as OPM, >>which would also include project-term Support contracts, isn't going >>to fit into any pre-approved O&M day to day budget... other than maybe >>an AF budget :-) >>-Jim P. From saku at ytti.fi Fri Jun 19 18:03:29 2015 From: saku at ytti.fi (Saku Ytti) Date: Fri, 19 Jun 2015 21:03:29 +0300 Subject: REMINDER: LEAP SECOND In-Reply-To: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> Message-ID: <20150619180329.GA26018@pob.ytti.fi> On (2015-06-19 13:06 -0400), Jay Ashworth wrote: Hey, > The IERS will be adding a second to time again on my birthday; > > 2015-06-30T23:59:60 Hopefully this is last leap second we'll ever see. Non-monotonic time is an abomination and very very few programs measuring passage of time are correct. Even those which are, usually are not portable, most languages do not even offer monotonic time in standard libraries. Canada, China, England and Germany, shame on you for opposing leapsecondless UTC. Next year hopefully GPSTIME. TAI and UTC are the same thing, with different static offset. -- ++ytti From mansaxel at besserwisser.org Fri Jun 19 18:08:07 2015 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Fri, 19 Jun 2015 20:08:07 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> Message-ID: <20150619180806.GF8182@besserwisser.org> Subject: REMINDER: LEAP SECOND Date: Fri, Jun 19, 2015 at 01:06:22PM -0400 Quoting Jay Ashworth (jra at baylink.com): > The IERS will be adding a second to time again on my birthday; This time around there are a number of Vendor C devices that will fail in spectacular ways if not upgraded with a pretty new release -- Nexus and ASR1K being the two most "interesting" among those I've reviewed. http://www.cisco.com/web/about/doing_business/leap-second.html#~ProductInformation -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'd like some JUNK FOOD ... and then I want to be ALONE -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mel at beckman.org Fri Jun 19 18:11:18 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 19 Jun 2015 18:11:18 +0000 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <55844C74.2000602@shwisp.net> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> <9578293AE169674F9A048B2BC9A081B401C0530ED1@MUNPRDMBXA1.medline.com> <55842D50.9050204@shwisp.net> <0461cca02f3548269bbcf5b71c705b06.squirrel@66.201.44.180> <55844C74.2000602@shwisp.net> Message-ID: <7ABDE329-8451-4C78-813C-F395892C785B@beckman.org> Have you done a network analysis for viruses or bridge loops? This could be a broadcast storm caused by either of those network faults. -mel > On Jun 19, 2015, at 10:08 AM, Sam Tetherow wrote: > > Only have 1 Pro on my network and it hasn't given me any issues, several of the original AP and AP-LR as well without issues. > > What is the uptime on the AP? You should be able to ssh into the APs using the controller username and password. It is a linux base so 'uptime' will tell you. You can also check for ethernet errors using 'ip -s link' on the AP side. > > On 06/19/2015 11:45 AM, Bob Evans wrote: >> We have all APs set with static addresses. EdgeMax only hands out IPs to >> clients using the APs. >> >> This happens when people are using the APs and when no one is even in the >> building at 2am when there are no clients connected. It can happen to one >> then 5 hours later it happens again...then doesn't happen again for 12 >> hours. Totally random no interval. >> >> It is nice to know that others have no issues with these UniFi AP Pros. >> They seem to be fine except for the 2 mins or so they randomly drop link >> and reboot themselves. All are on APC UPSes and other devices in the same >> switch , like voip phones, never drop the ports. >> >> They are all new, delivered in various batches over time. We checked and >> all are the latest versions. >> >> Bob Evans >> >> >> >> >>> The IP can change on the UniFi without having to re-adopt or >>> re-provision. APs are identified by MAC address at the UniFi protocol >>> level (not layer 2). >>> >>> On 06/19/2015 09:09 AM, Naslund, Steve wrote: >>>> Here is another though. If your APs are re-provisioning every eight >>>> hours, what is your DHCP lease time? Are you sure the APs are able to >>>> renew their leases (if not, could your scope be full)? Do you see the >>>> IP addresses on the APs changing when they come back up? These could >>>> indicate a DHCP server issue. If the AP gets a new IP address it will >>>> likely have to be re-adopted to the controller. You might want to >>>> static address one or more APs to test this theory. >>>> >>>> Steven Naslund >>>> Chicago IL >>> >> > From cscora at apnic.net Fri Jun 19 18:13:14 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 Jun 2015 04:13:14 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201506191813.t5JIDEtv019656@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 20 Jun, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 549882 Prefixes after maximum aggregation (per Origin AS): 208354 Deaggregation factor: 2.64 Unique aggregates announced (without unneeded subnets): 267650 Total ASes present in the Internet Routing Table: 50672 Prefixes per ASN: 10.85 Origin-only ASes present in the Internet Routing Table: 36714 Origin ASes announcing only one prefix: 16279 Transit ASes present in the Internet Routing Table: 6324 Transit-only ASes present in the Internet Routing Table: 165 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 41 Max AS path prepend of ASN ( 12486) 32 Prefixes from unregistered ASNs in the Routing Table: 1225 Unregistered ASNs in the Routing Table: 426 Number of 32-bit ASNs allocated by the RIRs: 9896 Number of 32-bit ASNs visible in the Routing Table: 7634 Prefixes from 32-bit ASNs in the Routing Table: 28027 Number of bogon 32-bit ASNs visible in the Routing Table: 13 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 388 Number of addresses announced to Internet: 2772890656 Equivalent to 165 /8s, 70 /16s and 244 /24s Percentage of available address space announced: 74.9 Percentage of allocated address space announced: 74.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.4 Total number of prefixes smaller than registry allocations: 184389 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 135535 Total APNIC prefixes after maximum aggregation: 39259 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 142125 Unique aggregates announced from the APNIC address blocks: 57084 APNIC Region origin ASes present in the Internet Routing Table: 5072 APNIC Prefixes per ASN: 28.02 APNIC Region origin ASes announcing only one prefix: 1215 APNIC Region transit ASes present in the Internet Routing Table: 878 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 38 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1502 Number of APNIC addresses announced to Internet: 750709184 Equivalent to 44 /8s, 190 /16s and 233 /24s Percentage of available APNIC address space announced: 87.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: 180493 Total ARIN prefixes after maximum aggregation: 88365 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 182879 Unique aggregates announced from the ARIN address blocks: 85354 ARIN Region origin ASes present in the Internet Routing Table: 16611 ARIN Prefixes per ASN: 11.01 ARIN Region origin ASes announcing only one prefix: 6117 ARIN Region transit ASes present in the Internet Routing Table: 1727 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 483 Number of ARIN addresses announced to Internet: 1093015328 Equivalent to 65 /8s, 38 /16s and 23 /24s Percentage of available ARIN address space announced: 57.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 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: 133222 Total RIPE prefixes after maximum aggregation: 66199 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 139731 Unique aggregates announced from the RIPE address blocks: 86551 RIPE Region origin ASes present in the Internet Routing Table: 17970 RIPE Prefixes per ASN: 7.78 RIPE Region origin ASes announcing only one prefix: 8133 RIPE Region transit ASes present in the Internet Routing Table: 2983 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 35 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3790 Number of RIPE addresses announced to Internet: 694897664 Equivalent to 41 /8s, 107 /16s and 76 /24s Percentage of available RIPE address space announced: 101.0 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-204287 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: 60347 Total LACNIC prefixes after maximum aggregation: 11405 LACNIC Deaggregation factor: 5.29 Prefixes being announced from the LACNIC address blocks: 70967 Unique aggregates announced from the LACNIC address blocks: 33075 LACNIC Region origin ASes present in the Internet Routing Table: 2449 LACNIC Prefixes per ASN: 28.98 LACNIC Region origin ASes announcing only one prefix: 618 LACNIC Region transit ASes present in the Internet Routing Table: 506 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 22 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1736 Number of LACNIC addresses announced to Internet: 168145216 Equivalent to 10 /8s, 5 /16s and 177 /24s Percentage of available LACNIC address space announced: 100.2 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: 12002 Total AfriNIC prefixes after maximum aggregation: 3078 AfriNIC Deaggregation factor: 3.90 Prefixes being announced from the AfriNIC address blocks: 13792 Unique aggregates announced from the AfriNIC address blocks: 5236 AfriNIC Region origin ASes present in the Internet Routing Table: 739 AfriNIC Prefixes per ASN: 18.66 AfriNIC Region origin ASes announcing only one prefix: 196 AfriNIC Region transit ASes present in the Internet Routing Table: 157 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 123 Number of AfriNIC addresses announced to Internet: 65706496 Equivalent to 3 /8s, 234 /16s and 154 /24s Percentage of available AfriNIC address space announced: 65.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 2949 11560 938 Korea Telecom 17974 2697 904 78 PT Telekomunikasi Indonesia 7545 2597 336 128 TPG Telecom Limited 4755 2026 423 222 TATA Communications formerly 4538 1936 4190 71 China Education and Research 9829 1717 1345 103 National Internet Backbone 9808 1539 8717 28 Guangdong Mobile Communicatio 9583 1471 117 567 Sify Limited 4808 1453 2247 463 CNCGROUP IP network China169 9498 1350 336 106 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 3172 2958 139 Cox Communications Inc. 6389 2792 3688 51 BellSouth.net Inc. 3356 2557 10687 504 Level 3 Communications, Inc. 18566 2050 380 192 MegaPath Corporation 20115 1887 1853 423 Charter Communications 6983 1749 850 244 EarthLink, Inc. 4323 1607 1022 411 tw telecom holdings, inc. 30036 1570 319 440 Mediacom Communications Corp 701 1394 11353 678 MCI Communications Services, 22561 1355 414 250 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 2146 305 363 TELLCOM ILETISIM HIZMETLERI A 20940 1945 758 1417 Akamai International B.V. 6849 1210 355 22 JSC "Ukrtelecom" 31148 1048 45 23 Freenet Ltd. 13188 1041 97 71 TOV "Bank-Inform" 8402 1031 544 15 OJSC "Vimpelcom" 12479 947 868 72 France Telecom Espana SA 6830 912 2694 468 Liberty Global Operations B.V 8551 872 376 52 Bezeq International-Ltd 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 3250 532 228 Telmex Colombia S.A. 28573 2276 2170 113 NET Servi?os de Comunica??o S 8151 1688 3238 469 Uninet S.A. de C.V. 7303 1639 1019 238 Telecom Argentina S.A. 6147 1621 373 44 Telefonica del Peru S.A.A. 6503 1251 421 55 Axtel, S.A.B. de C.V. 26615 1056 2325 35 Tim Celular S.A. 7738 999 1882 41 Telemar Norte Leste S.A. 3816 947 427 159 COLOMBIA TELECOMUNICACIONES S 11830 893 364 15 Instituto Costarricense de El 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 24863 875 280 26 Link Egypt (Link.NET) 8452 801 958 13 TE-AS 36903 510 257 102 Office National des Postes et 36992 423 1229 32 ETISALAT MISR 37492 312 175 71 Orange Tunisie 24835 306 146 13 Vodafone Data 3741 250 857 208 Internet Solutions 29571 241 21 12 Cote d'Ivoire Telecom 36947 189 807 13 Telecom Algeria 37054 180 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 3250 532 228 Telmex Colombia S.A. 22773 3172 2958 139 Cox Communications Inc. 4766 2949 11560 938 Korea Telecom 6389 2792 3688 51 BellSouth.net Inc. 17974 2697 904 78 PT Telekomunikasi Indonesia 7545 2597 336 128 TPG Telecom Limited 3356 2557 10687 504 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2276 2170 113 NET Servi?os de Comunica??o S 34984 2146 305 363 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3172 3033 Cox Communications Inc. 6389 2792 2741 BellSouth.net Inc. 17974 2697 2619 PT Telekomunikasi Indonesia 7545 2597 2469 TPG Telecom Limited 39891 2472 2466 SaudiNet, Saudi Telecom Compa 28573 2276 2163 NET Servi?os de Comunica??o S 3356 2557 2053 Level 3 Communications, Inc. 4766 2949 2011 Korea Telecom 4538 1936 1865 China Education and Research 18566 2050 1858 MegaPath Corporation 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.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.15.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:17 /9:13 /10:34 /11:95 /12:264 /13:507 /14:1004 /15:1724 /16:12948 /17:7303 /18:12345 /19:25546 /20:36082 /21:38868 /22:60125 /23:52172 /24:297840 /25:1097 /26:1135 /27:715 /28:14 /29:12 /30:7 /31:0 /32:15 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2374 3172 Cox Communications Inc. 18566 2000 2050 MegaPath Corporation 6389 1640 2792 BellSouth.net Inc. 34984 1401 2146 TELLCOM ILETISIM HIZMETLERI A 6983 1397 1749 EarthLink, Inc. 30036 1396 1570 Mediacom Communications Corp 6147 1174 1621 Telefonica del Peru S.A.A. 10620 1144 3250 Telmex Colombia S.A. 11492 1105 1188 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1496 2:681 4:92 5:1867 6:25 8:1409 11:1 12:1818 13:14 14:1374 15:17 16:2 17:44 18:22 20:48 23:1240 24:1762 27:1923 31:1591 32:38 33:2 34:4 35:3 36:133 37:1984 38:1038 39:6 40:253 41:2669 42:276 43:1330 44:28 45:751 46:2294 47:45 49:901 50:812 52:12 54:77 55:5 56:6 57:41 58:1323 59:715 60:480 61:1745 62:1365 63:1923 64:4475 65:2263 66:4070 67:2076 68:1064 69:3254 70:1024 71:445 72:1978 74:2658 75:339 76:424 77:1296 78:1180 79:787 80:1338 81:1297 82:834 83:722 84:726 85:1409 86:411 87:1042 88:524 89:1848 90:152 91:5995 92:856 93:2238 94:2053 95:2180 96:426 97:355 98:1053 99:51 100:72 101:840 103:7660 104:1821 105:61 106:235 107:990 108:630 109:2065 110:1119 111:1442 112:831 113:1088 114:836 115:1278 116:1386 117:1038 118:1821 119:1458 120:447 121:1089 122:2146 123:1843 124:1516 125:1611 128:644 129:394 130:404 131:1200 132:502 133:177 134:407 135:95 136:332 137:314 138:886 139:153 140:235 141:448 142:668 143:522 144:572 145:118 146:736 147:586 148:1207 149:417 150:564 151:667 152:519 153:245 154:460 155:861 156:417 157:417 158:343 159:1006 160:384 161:663 162:1957 163:436 164:685 165:695 166:312 167:836 168:1314 169:177 170:1461 171:246 172:193 173:1554 174:721 175:694 176:1370 177:3786 178:2156 179:948 180:1948 181:1676 182:1810 183:628 184:755 185:3706 186:2740 187:1791 188:2059 189:1581 190:7788 191:1031 192:8468 193:5619 194:4169 195:3688 196:1980 197:966 198:5550 199:5493 200:6656 201:3259 202:9438 203:9155 204:4701 205:2842 206:3051 207:2967 208:3989 209:3966 210:3532 211:1860 212:2562 213:2365 214:850 215:72 216:5759 217:1801 218:715 219:463 220:1454 221:780 222:477 223:725 End of report From bruns at 2mbit.com Fri Jun 19 18:21:17 2015 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 19 Jun 2015 12:21:17 -0600 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <6bd2a2ff38c562392fd481154f83effc.squirrel@66.201.44.180> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> <6bd2a2ff38c562392fd481154f83effc.squirrel@66.201.44.180> Message-ID: <55845D9D.3010206@2mbit.com> On 6/19/15 10:57 AM, Bob Evans wrote: > Thank You Charles, > Been on NANOG a while - all the basic stuff we know well. Like, cables, > cluster occurrences etc. Looking for the UniFi specific experience. Its > not the switches, power, cables, ports show no CRC issues etc. > > We even setup another network with just 2 and it happens randomly - so its > some code or something. Think I'm going to let one of the guys here login > the the controller and see if we missed a setting in the latest code. > NANOGs real good at having someone with specific targeted knowledge > appear. > I've got a bunch of regular UAPs spread out over multiple customers with various network setups including ERLs as routers, CenturyLink POS modems of various generations, Dink routers, etc. My controller is hosted off-site in Tacoma in our data center. Some issues I've run into, particularly on the consumer devices like the older CenturyLink/Qwest modems... 1) Broken MTU clamping/fixing on PPPoE links, causing the UAPs to have problems making a connection to the remote controller. Worked around by messing with the MSS using iptables on specifically the tcp/8080 and tcp/8443 port on the controller end. Other devices, had to make sure to disable the firewall feature on modem, in order to get it to stop eating ICMP packets (and thus breaking pmtu). 2) Faulty DNS server daemons on the routers. The UAPs would have issues randomly resolving the controller's IP address from hostname. Have this problem time to time with anyone using the built in DNS servers on the CenturyLink/Qwest modems. Resolved this issue by statically defining IP and DNS servers on the UAPs (DNS server set to 8.8.8.8). Also had to disable the firewall on one of the routers to get it to not intercept/mangle DNS packets. These two issues alone have caused me major issues with the devices randomly being unable to get new configurations or download firmware updates. On network switches connected to the UAPs, make sure that you've got the port set to whatever the switches' version of cisco 'portfast' is. In the Site Settings under the Unifi controller, disable "Enable connectivity monitor and wireless uplink" and see if the problem eases up. If you need to use the uplink monitor, manually set the IP you want to check with, and make sure the UAPs can actually ping said IP. I'm the head mod for /r/Ubiquiti, so feel free to bounce things off of me privately with your Unifi setup, and I'll be happy to give you a hand. I can also direct you to the unofficial Ubnt IRC channel where you can get a bunch more opinions. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From charles at thefnf.org Fri Jun 19 18:23:20 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Fri, 19 Jun 2015 13:23:20 -0500 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <6bd2a2ff38c562392fd481154f83effc.squirrel@66.201.44.180> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> <6bd2a2ff38c562392fd481154f83effc.squirrel@66.201.44.180> Message-ID: On 2015-06-19 11:57, Bob Evans wrote: > Thank You Charles, > Been on NANOG a while - all the basic stuff we know well. Like, cables, > cluster occurrences etc. Looking for the UniFi specific experience. Its > not the switches, power, cables, ports show no CRC issues etc. > Sure. I've seen you around. Always good to check the basics, start at layer 1 and work up. That doesn't change, no matter how experienced a crew is. :) > We even setup another network with just 2 and it happens randomly - so > its > some code or something. Wait... same controller? Or a different controller? Because if you can replicate across access points and controllers then you've probably found a bug. Well presuming you aren't fate sharing with anything else (like switches). Very weird. Think I'm going to let one of the guys here login > the the controller and see if we missed a setting in the latest code. > NANOGs real good at having someone with specific targeted knowledge > appear. > Yes it sure is. From charles at thefnf.org Fri Jun 19 18:26:22 2015 From: charles at thefnf.org (charles at thefnf.org) Date: Fri, 19 Jun 2015 13:26:22 -0500 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <55845D9D.3010206@2mbit.com> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> <6bd2a2ff38c562392fd481154f83effc.squirrel@66.201.44.180> <55845D9D.3010206@2mbit.com> Message-ID: <36840df8834876d74c9a7c881fc1d2e9@thefnf.org> > These two issues alone have caused me major issues with the devices > randomly being unable to get new configurations or download firmware > updates. > Question. Once they have connected and are "happy", do they drop off (re provision) like Bob is mentioning? I'm still not entirely sure what is meant by "re provision". I've not seen it answered in the thread. > I'm the head mod for /r/Ubiquiti, so feel free to bounce things off of > me privately with your Unifi setup, Didn't know that sub reddit existed. Awesome. From mel at beckman.org Fri Jun 19 18:29:34 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 19 Jun 2015 18:29:34 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150619180806.GF8182@besserwisser.org> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> Message-ID: <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> The universal workaround is to simply disable NTP on your devices sometime on Leap-Second eave. This will let the clocks free-run over the one-second push, an event of which they will be blissfully ignorant. When you re-enable NTP after The Leap, normal, non-destructive, NTP convergence will occur. Better, if you have a master NTP site clock, you need only disable it?s upstream NTP feed to isolate all the subsidiary devices. If you don?t have such a master clock, this is an excellent time to set one up one. I have found the Time Machines TM1000A GPS time server very inexpensive and super reliable: http://www.newegg.com/Product/Product.aspx?Item=0N6-001Y-00007 -mel > On Jun 19, 2015, at 11:08 AM, M?ns Nilsson wrote: > > Subject: REMINDER: LEAP SECOND Date: Fri, Jun 19, 2015 at 01:06:22PM -0400 Quoting Jay Ashworth (jra at baylink.com): >> The IERS will be adding a second to time again on my birthday; > > This time around there are a number of Vendor C devices that will fail > in spectacular ways if not upgraded with a pretty new release -- Nexus > and ASR1K being the two most "interesting" among those I've reviewed. > > http://www.cisco.com/web/about/doing_business/leap-second.html#~ProductInformation > > -- > M?ns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > I'd like some JUNK FOOD ... and then I want to be ALONE -- From bruns at 2mbit.com Fri Jun 19 18:40:36 2015 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 19 Jun 2015 12:40:36 -0600 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <36840df8834876d74c9a7c881fc1d2e9@thefnf.org> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> <6bd2a2ff38c562392fd481154f83effc.squirrel@66.201.44.180> <55845D9D.3010206@2mbit.com> <36840df8834876d74c9a7c881fc1d2e9@thefnf.org> Message-ID: <55846224.9050003@2mbit.com> On 6/19/15 12:26 PM, charles at thefnf.org wrote: > > >> These two issues alone have caused me major issues with the devices >> randomly being unable to get new configurations or download firmware >> updates. >> > > Question. Once they have connected and are "happy", do they drop off (re > provision) like Bob is mentioning? > I'm still not entirely sure what is meant by "re provision". I've not > seen it answered in the thread. > > Reprovisioning with Unifi happens any time you make a configuration change. The next time the device does it's check-in (don't remember how often it checks in, but its at least once a min), the UAP will get a copy of its updated configuration, load it, then activate the changes (and reboot if necessary). If the device never goes out of provisioning state, then it hasn't managed to pull its configuration or firmware properly and will likely keep trying. When the device is having complete connection issues, it will show up as Disconnected rather then Provisioning in the controller. Useful thing I've done - when a device is randomly having issues with provisioning, I'll setup the remote syslog option in the config, and have it remote log to my controller's syslog. Usually, it will dump exactly the reason why its failing the provision to syslog, making it easier to diagnose. >> I'm the head mod for /r/Ubiquiti, so feel free to bounce things off of >> me privately with your Unifi setup, > > Didn't know that sub reddit existed. Awesome. > Its not as busy as the forums, but there's sometimes good info there. There's also the IRC channel as well, which has a mix of users and some Ubnt employees. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From msa at latt.net Fri Jun 19 18:51:44 2015 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 19 Jun 2015 14:51:44 -0400 Subject: REMINDER: LEAP SECOND In-Reply-To: <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> Message-ID: <20150619185144.GA10635@puck.nether.net> On Fri, Jun 19, 2015 at 06:29:34PM +0000, Mel Beckman wrote: > The universal workaround is to simply disable NTP on your devices sometime > on Leap-Second eave. This will let the clocks free-run over the one-second > push, an event of which they will be blissfully ignorant. When you re-enable > NTP after The Leap, normal, non-destructive, NTP convergence will occur. I encourage all my competitors to use this approach. If you're more than 128 ms off when NTP is flipped back on, it will still probably step the clock, then start slewing it. So you've skipped the leap per se, but your clocks will still jump forward quite a bit. This might isolate you from any leap second related failures, but it does not protect you against the system clock being stepped. If the leap pending information data persists, you might not even be isolated from any leap second failures. You could manage to upset the system clock even more. Are your time servers correctly armed for the leap? > Better, if you have a master NTP site clock, you need only disable it?s > upstream NTP feed to isolate all the subsidiary devices. If you don?t > have such a master clock, this is an excellent time to set one up one. > I have found the Time Machines TM1000A GPS time server very inexpensive > and super reliable: > > http://www.newegg.com/Product/Product.aspx?Item=0N6-001Y-00007 $20 says that doesn't leap correctly. A lot of the inexpensive units appear to be using NMEA speaking GPS modules, and there's no real way to get leap information out of them. Many of them may ignore the timestamps and just use the PPS, in which case they may persist a second behind the world for quite some time. --msa From bob at FiberInternetCenter.com Fri Jun 19 19:13:14 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 19 Jun 2015 12:13:14 -0700 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <55846224.9050003@2mbit.com> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> <6bd2a2ff38c562392fd481154f83effc.squirrel@66.201.44.180> <55845D9D.3010206@2mbit.com> <36840df8834876d74c9a7c881fc1d2e9@thefnf.org> <55846224.9050003@2mbit.com> Message-ID: <7ef07ace54b237efb6f7dcb6c7bdecf3.squirrel@66.201.44.180> This is very helpful information. We will be implementing these steps. Thank You Bob Evans CTO > On 6/19/15 12:26 PM, charles at thefnf.org wrote: >> >> >>> These two issues alone have caused me major issues with the devices >>> randomly being unable to get new configurations or download firmware >>> updates. >>> >> >> Question. Once they have connected and are "happy", do they drop off (re >> provision) like Bob is mentioning? >> I'm still not entirely sure what is meant by "re provision". I've not >> seen it answered in the thread. >> >> > > > Reprovisioning with Unifi happens any time you make a configuration > change. The next time the device does it's check-in (don't remember how > often it checks in, but its at least once a min), the UAP will get a > copy of its updated configuration, load it, then activate the changes > (and reboot if necessary). > > If the device never goes out of provisioning state, then it hasn't > managed to pull its configuration or firmware properly and will likely > keep trying. > > When the device is having complete connection issues, it will show up as > Disconnected rather then Provisioning in the controller. > > Useful thing I've done - when a device is randomly having issues with > provisioning, I'll setup the remote syslog option in the config, and > have it remote log to my controller's syslog. Usually, it will dump > exactly the reason why its failing the provision to syslog, making it > easier to diagnose. > > >>> I'm the head mod for /r/Ubiquiti, so feel free to bounce things off of >>> me privately with your Unifi setup, >> >> Didn't know that sub reddit existed. Awesome. >> > > Its not as busy as the forums, but there's sometimes good info there. > There's also the IRC channel as well, which has a mix of users and some > Ubnt employees. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From bob at FiberInternetCenter.com Fri Jun 19 19:14:08 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 19 Jun 2015 12:14:08 -0700 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <36840df8834876d74c9a7c881fc1d2e9@thefnf.org> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> <6bd2a2ff38c562392fd481154f83effc.squirrel@66.201.44.180> <55845D9D.3010206@2mbit.com> <36840df8834876d74c9a7c881fc1d2e9@thefnf.org> Message-ID: re-provisioning is to go to the controller find its config and reboot. Thank You Bob Evans CTO > > >> These two issues alone have caused me major issues with the devices >> randomly being unable to get new configurations or download firmware >> updates. >> > > Question. Once they have connected and are "happy", do they drop off (re > provision) like Bob is mentioning? > I'm still not entirely sure what is meant by "re provision". I've not > seen it answered in the thread. > > >> I'm the head mod for /r/Ubiquiti, so feel free to bounce things off of >> me privately with your Unifi setup, > > Didn't know that sub reddit existed. Awesome. > > From bob at FiberInternetCenter.com Fri Jun 19 19:16:51 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 19 Jun 2015 12:16:51 -0700 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <55845D9D.3010206@2mbit.com> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> <6bd2a2ff38c562392fd481154f83effc.squirrel@66.201.44.180> <55845D9D.3010206@2mbit.com> Message-ID: <33d2f0069cc37f0345b03a54b1c77f41.squirrel@66.201.44.180> Great details ! Going to implement now. Thank You Bob Evans CTO > On 6/19/15 10:57 AM, Bob Evans wrote: >> Thank You Charles, >> Been on NANOG a while - all the basic stuff we know well. Like, cables, >> cluster occurrences etc. Looking for the UniFi specific experience. Its >> not the switches, power, cables, ports show no CRC issues etc. >> >> We even setup another network with just 2 and it happens randomly - so >> its >> some code or something. Think I'm going to let one of the guys here >> login >> the the controller and see if we missed a setting in the latest code. >> NANOGs real good at having someone with specific targeted knowledge >> appear. >> > > I've got a bunch of regular UAPs spread out over multiple customers with > various network setups including ERLs as routers, CenturyLink POS modems > of various generations, Dink routers, etc. > > My controller is hosted off-site in Tacoma in our data center. > > Some issues I've run into, particularly on the consumer devices like the > older CenturyLink/Qwest modems... > > 1) Broken MTU clamping/fixing on PPPoE links, causing the UAPs to have > problems making a connection to the remote controller. > > Worked around by messing with the MSS using iptables on specifically the > tcp/8080 and tcp/8443 port on the controller end. > > Other devices, had to make sure to disable the firewall feature on > modem, in order to get it to stop eating ICMP packets (and thus breaking > pmtu). > > 2) Faulty DNS server daemons on the routers. The UAPs would have issues > randomly resolving the controller's IP address from hostname. Have this > problem time to time with anyone using the built in DNS servers on the > CenturyLink/Qwest modems. > > Resolved this issue by statically defining IP and DNS servers on the > UAPs (DNS server set to 8.8.8.8). Also had to disable the firewall on > one of the routers to get it to not intercept/mangle DNS packets. > > These two issues alone have caused me major issues with the devices > randomly being unable to get new configurations or download firmware > updates. > > > On network switches connected to the UAPs, make sure that you've got the > port set to whatever the switches' version of cisco 'portfast' is. > > In the Site Settings under the Unifi controller, disable "Enable > connectivity monitor and wireless uplink" and see if the problem eases > up. If you need to use the uplink monitor, manually set the IP you want > to check with, and make sure the UAPs can actually ping said IP. > > > I'm the head mod for /r/Ubiquiti, so feel free to bounce things off of > me privately with your Unifi setup, and I'll be happy to give you a > hand. I can also direct you to the unofficial Ubnt IRC channel where > you can get a bunch more opinions. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From bob at FiberInternetCenter.com Fri Jun 19 19:19:11 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 19 Jun 2015 12:19:11 -0700 Subject: Ghosts in our 6 New Ubiquity Pros - provision issues. In-Reply-To: <7ABDE329-8451-4C78-813C-F395892C785B@beckman.org> References: <3d0213009982e0f66f370dac266bc47f.squirrel@66.201.44.180> <8d6f7e6d12e5bcf785749f44f37b35fb@thefnf.org> <9578293AE169674F9A048B2BC9A081B401C0530ED1@MUNPRDMBXA1.medline.com> <55842D50.9050204@shwisp.net> <0461cca02f3548269bbcf5b71c705b06.squirrel@66.201.44.180> <55844C74.2000602@shwisp.net> <7ABDE329-8451-4C78-813C-F395892C785B@beckman.org> Message-ID: <9e12a6e28c1920a7935bd2429d4c7f5e.squirrel@66.201.44.180> Mell, God idea , but , yes we did - no loops all are spokes - we know cabling and setup our switches and routers to syslog those events. Thank You Bob Evans CTO > Have you done a network analysis for viruses or bridge loops? This could > be a broadcast storm caused by either of those network faults. > > -mel > >> On Jun 19, 2015, at 10:08 AM, Sam Tetherow wrote: >> >> Only have 1 Pro on my network and it hasn't given me any issues, several >> of the original AP and AP-LR as well without issues. >> >> What is the uptime on the AP? You should be able to ssh into the APs >> using the controller username and password. It is a linux base so >> 'uptime' will tell you. You can also check for ethernet errors using >> 'ip -s link' on the AP side. >> >> On 06/19/2015 11:45 AM, Bob Evans wrote: >>> We have all APs set with static addresses. EdgeMax only hands out IPs >>> to >>> clients using the APs. >>> >>> This happens when people are using the APs and when no one is even in >>> the >>> building at 2am when there are no clients connected. It can happen to >>> one >>> then 5 hours later it happens again...then doesn't happen again for 12 >>> hours. Totally random no interval. >>> >>> It is nice to know that others have no issues with these UniFi AP Pros. >>> They seem to be fine except for the 2 mins or so they randomly drop >>> link >>> and reboot themselves. All are on APC UPSes and other devices in the >>> same >>> switch , like voip phones, never drop the ports. >>> >>> They are all new, delivered in various batches over time. We checked >>> and >>> all are the latest versions. >>> >>> Bob Evans >>> >>> >>> >>> >>>> The IP can change on the UniFi without having to re-adopt or >>>> re-provision. APs are identified by MAC address at the UniFi protocol >>>> level (not layer 2). >>>> >>>> On 06/19/2015 09:09 AM, Naslund, Steve wrote: >>>>> Here is another though. If your APs are re-provisioning every eight >>>>> hours, what is your DHCP lease time? Are you sure the APs are able >>>>> to >>>>> renew their leases (if not, could your scope be full)? Do you see >>>>> the >>>>> IP addresses on the APs changing when they come back up? These could >>>>> indicate a DHCP server issue. If the AP gets a new IP address it >>>>> will >>>>> likely have to be re-adopted to the controller. You might want to >>>>> static address one or more APs to test this theory. >>>>> >>>>> Steven Naslund >>>>> Chicago IL >>>> >>> >> > > From rafael at gav.ufsc.br Fri Jun 19 21:40:48 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 19 Jun 2015 16:40:48 -0500 Subject: SIP trunking providers Message-ID: Would anyone in the list be able to recommend a SIP trunk provider in the Chicago area? Not a VoIP expert, so just looking for someone with previous experience. Thanks, Rafael From dovid at telecurve.com Fri Jun 19 21:52:38 2015 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 19 Jun 2015 21:52:38 +0000 Subject: SIP trunking providers Message-ID: <1693203758-1434750759-cardhu_decombobulator_blackberry.rim.net-325802904-@b1.c3.bise6.blackberry> Jivetel.com ------Original Message------ From: Rafael Possamai Sender: NANOG To: nanog at nanog.org Subject: SIP trunking providers Sent: Jun 19, 2015 17:40 Would anyone in the list be able to recommend a SIP trunk provider in the Chicago area? Not a VoIP expert, so just looking for someone with previous experience. Thanks, Rafael Regards, Dovid From stenn at ntp.org Fri Jun 19 21:53:38 2015 From: stenn at ntp.org (Harlan Stenn) Date: Fri, 19 Jun 2015 21:53:38 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150619180329.GA26018@pob.ytti.fi> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> Message-ID: Saku Ytti writes: > Hopefully this is last leap second we'll ever see. Non-monotonic time > is an abomination and very very few programs measuring passage of time > are correct. Even those which are, usually are not portable, most > languages do not even offer monotonic time in standard libraries. > Canada, China, England and Germany, shame on you for opposing > leapsecondless UTC. It's a problem with POSIX, not UTC. UTC is monotonic. > Next year hopefully GPSTIME. TAI and UTC are the same thing, with different > static offset. The General Timestamp API that Network Time Foundation is working on can solve this problem. People use different timescales for different reasons. The Agile folks like the "pigs and chickens" analogy: in a bacon and egg breakfast, the chicken is invested while the pig is committed. It's lame for a chicken to dictate to a pig. It's lame to change an existing Standard. Leave that one alone and choose to follow a new/different Standard. If you don't have a system that can properly handle leapseconds, there are several solutions to this, including: - implement DLM's leap second process in the kernel, described over 20 years ago - use the posix-right timezone files - help Network Time Foundation get the General Timestamp API implemented and deployed, which will let folks use whatever timescale they want. -- Harlan Stenn http://networktimefoundation.org - be a member! From stenn at ntp.org Fri Jun 19 21:58:00 2015 From: stenn at ntp.org (Harlan Stenn) Date: Fri, 19 Jun 2015 21:58:00 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> Message-ID: Bad idea. When restarting ntpd your clocks will likely be off by a second, which will cause a backward step, which will force the problem you claim to be avoiding. There are plenty of ways to solve this problem, and you just get to choose what you want to risk/pay. -- Harlan Stenn http://networktimefoundation.org - be a member! From cidr-report at potaroo.net Fri Jun 19 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Jun 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201506192200.t5JM00j2020380@wattle.apnic.net> This report has been generated at Fri Jun 19 21:14:38 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 12-06-15 557587 304085 13-06-15 557180 303970 14-06-15 557174 304305 15-06-15 557480 304564 16-06-15 557299 304777 17-06-15 557521 304842 18-06-15 557736 304985 19-06-15 558465 305020 AS Summary 50936 Number of ASes in routing system 20251 Number of ASes announcing only one prefix 3250 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120759296 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'). --- 19Jun15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 558662 304994 253668 45.4% All ASes AS22773 3175 169 3006 94.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2791 70 2721 97.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2697 78 2619 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS9394 2919 315 2604 89.2% CTTNET China TieTong Telecommunications Corporation,CN AS39891 2473 35 2438 98.6% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2273 293 1980 87.1% NET Servi?os de Comunica??o S.A.,BR AS4755 2023 281 1742 86.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS10620 3250 1632 1618 49.8% Telmex Colombia S.A.,CO AS4766 2949 1359 1590 53.9% KIXS-AS-KR Korea Telecom,KR AS6983 1748 247 1501 85.9% ITCDELTA - Earthlink, Inc.,US AS7545 2642 1165 1477 55.9% TPG-INTERNET-AP TPG Telecom Limited,AU AS9808 1539 67 1472 95.6% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS20115 1887 488 1399 74.1% CHARTER-NET-HKY-NC - Charter Communications,US AS7303 1639 287 1352 82.5% Telecom Argentina S.A.,AR AS6147 1621 301 1320 81.4% Telefonica del Peru S.A.A.,PE AS9498 1350 121 1229 91.0% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1616 413 1203 74.4% TWTC - tw telecom holdings, inc.,US AS22561 1355 261 1094 80.7% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS7552 1146 58 1088 94.9% VIETEL-AS-AP Viettel Corporation,VN AS3356 2560 1510 1050 41.0% LEVEL3 - Level 3 Communications, Inc.,US AS18566 2050 1019 1031 50.3% MEGAPATH5-US - MegaPath Corporation,US AS8402 1024 28 996 97.3% CORBINA-AS OJSC "Vimpelcom",RU AS6849 1207 217 990 82.0% UKRTELNET JSC UKRTELECOM,UA AS8151 1695 716 979 57.8% Uninet S.A. de C.V.,MX AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS4538 1954 1039 915 46.8% ERX-CERNET-BKB China Education and Research Network Center,CN AS26615 1088 178 910 83.6% Tim Celular S.A.,BR AS38285 979 126 853 87.1% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS18881 870 33 837 96.2% Global Village Telecom,BR AS4780 1081 270 811 75.0% SEEDNET Digital United Inc.,TW Total 56600 12859 43741 77.3% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 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/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.67.78.0/24 AS38040 GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited,TH 64.28.145.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.28.146.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 66.11.224.0/21 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.234.0/24 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.236.0/22 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.59.192.0/19 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,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.85.252.0/23 AS63318 INFOTEC-MANITOBA - Infotec Manitoba,CA 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 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.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 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 88.135.64.0/20 AS48347 MTW-AS JSC MediaSoft Ekspert,RU 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.218.36.0/22 AS19714 -Reserved AS-,ZZ 91.229.5.0/24 AS56923 -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.69.1.0/24 AS59749 CLEANMAT CLEANMAT EOOD,BG 103.10.222.0/24 AS13189 103.11.16.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.44.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.45.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.47.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.19.219.0/24 AS58887 103.20.100.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.101.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.37.188.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.227.4.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.227.184.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.228.8.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.228.84.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.228.136.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.228.224.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.230.116.0/22 AS59351 103.232.104.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,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.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 144.1.0.0/16 AS20055 RUCLICK-AS RU-CLICK LLC,RU 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 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 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 180.222.120.0/21 AS23818 JETINTERNET JETINTERNET Corporation,JP 181.225.156.0/22 AS10834 Telefonica de Argentina,AR 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.40.183.0/24 AS62300 -Reserved AS-,ZZ 185.105.76.0/22 AS59554 DATACENTRUMGRONINGEN Datacenter Groningen B.V.,NL 186.148.224.0/21 AS52302 Awknet International, S.A.,PA 188.190.96.0/19 AS19714 -Reserved AS-,ZZ 188.190.103.0/24 AS19714 -Reserved AS-,ZZ 188.190.112.0/24 AS19714 -Reserved AS-,ZZ 188.190.113.0/24 AS19714 -Reserved AS-,ZZ 188.190.114.0/24 AS19714 -Reserved AS-,ZZ 188.190.117.0/24 AS19714 -Reserved AS-,ZZ 188.190.118.0/24 AS19714 -Reserved AS-,ZZ 188.190.119.0/24 AS19714 -Reserved AS-,ZZ 188.190.120.0/24 AS19714 -Reserved AS-,ZZ 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.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.206.140.0/24 AS54926 -Reserved AS-,ZZ 192.206.141.0/24 AS54926 -Reserved AS-,ZZ 192.206.142.0/24 AS54926 -Reserved AS-,ZZ 192.206.143.0/24 AS54926 -Reserved AS-,ZZ 192.232.32.0/19 AS20053 RELAX-LLC-AS LLC Relax,RU 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 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.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 193.105.154.0/24 AS34023 -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.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 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,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.8.0/21 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.9.9.0/24 AS2863 SPRITELINK Centor AB,SE 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.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 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -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.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.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.103.89.0/24 AS19523 -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.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.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.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 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.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.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems 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 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 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 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.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.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.74.12.0/23 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,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 CENTURYLINK-US-LEGACY-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 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,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.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 Jun 19 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Jun 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201506192200.t5JM01bT020394@wattle.apnic.net> BGP Update Report Interval: 11-Jun-15 -to- 18-Jun-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 276928 3.3% 2288.7 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 233909 2.8% 135.3 -- BSNL-NIB National Internet Backbone,IN 3 - AS9198 112457 1.3% 134.0 -- KAZTELECOM-AS JSC Kazakhtelecom,KZ 4 - AS36947 82755 1.0% 472.9 -- ALGTEL-AS,DZ 5 - AS54169 73772 0.9% 24590.7 -- MGH-ION-1 - Marin General Hospital,US 6 - AS29049 71845 0.9% 270.1 -- DELTA-TELECOM-AS Delta Telecom Ltd,AZ 7 - AS3709 63415 0.8% 2348.7 -- NET-CITY-SA - City of San Antonio,US 8 - AS12389 50484 0.6% 223.4 -- ROSTELECOM-AS OJSC Rostelecom,RU 9 - AS45899 47800 0.6% 58.7 -- VNPT-AS-VN VNPT Corp,VN 10 - AS42337 46309 0.6% 254.4 -- RESPINA-AS Respina Networks & Beyond PJSC,IR 11 - AS28573 44194 0.5% 22.1 -- NET Servi?os de Comunica??o S.A.,BR 12 - AS34875 44023 0.5% 282.2 -- YANFES OJSC "Rostelecom",RU 13 - AS22059 42852 0.5% 6121.7 -- -Reserved AS-,ZZ 14 - AS20852 42114 0.5% 307.4 -- ATLANT-TELECOM-AS FE "ALTERNATIVNAYA ZIFROVAYA SET",BY 15 - AS39891 38514 0.5% 26.1 -- ALJAWWALSTC-AS Saudi Telecom Company JSC,SA 16 - AS51074 37789 0.5% 229.0 -- MABNA GOSTARESH-E-ERTEBATAT-E MABNA COMPANY (Private Joint Stock),IR 17 - AS25563 35876 0.4% 8969.0 -- WEBLAND-AS Webland AG,CH 18 - AS6697 35584 0.4% 237.2 -- BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom,BY 19 - AS3816 34837 0.4% 37.3 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 20 - AS9394 34387 0.4% 12.2 -- CTTNET China TieTong Telecommunications Corporation,CN TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS54169 73772 0.9% 24590.7 -- MGH-ION-1 - Marin General Hospital,US 2 - AS63485 15120 0.2% 15120.0 -- PATRIOT-ASN - Patriot Web Solutions,US 3 - AS393588 9500 0.1% 9500.0 -- MUBEA-FLO - Mubea,US 4 - AS25563 35876 0.4% 8969.0 -- WEBLAND-AS Webland AG,CH 5 - AS22059 42852 0.5% 6121.7 -- -Reserved AS-,ZZ 6 - AS33287 10045 0.1% 5022.5 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US 7 - AS32005 15432 0.2% 3858.0 -- THE-CHURCH-PENSION-GROUP - CHURCH PENSION GROUP SERVICES CORPORATION,US 8 - AS8283 16772 0.2% 3354.4 -- COLOCLUE-AS Netwerkvereniging Coloclue, Amsterdam, Netherlands,NL 9 - AS17001 14658 0.2% 2931.6 -- UMANITOBA - University of Manitoba,CA 10 - AS200939 5106 0.1% 2553.0 -- LME-IRAQ Lukoil Overseas Service B.V.,IQ 11 - AS33440 9951 0.1% 2487.8 -- WEBRULON-NETWORK - webRulon, LLC,US 12 - AS3709 63415 0.8% 2348.7 -- NET-CITY-SA - City of San Antonio,US 13 - AS23752 276928 3.3% 2288.7 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 14 - AS45606 10037 0.1% 2007.4 -- 15 - AS56636 1870 0.0% 1870.0 -- ASVEDARU VEDA Ltd.,RU 16 - AS55741 1794 0.0% 1794.0 -- WBSDC-NET-IN West Bengal Electronics Industry Development,IN 17 - AS49426 6991 0.1% 1747.8 -- LINTECSAS1-AS LInTeCS AS,RU 18 - AS31357 11578 0.1% 1654.0 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 19 - AS38000 6438 0.1% 1609.5 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN 20 - AS63874 1524 0.0% 1524.0 -- IDNIC-BOSOWA-AS-ID PT Bosowa Media Utama,ID TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.88.0/21 137622 1.6% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.64.0/21 137064 1.6% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 105.96.0.0/22 81792 0.9% AS36947 -- ALGTEL-AS,DZ 4 - 204.80.242.0/24 73759 0.9% AS54169 -- MGH-ION-1 - Marin General Hospital,US 5 - 199.204.107.0/24 29118 0.3% AS33287 -- COMCAST-33287 - Comcast Cable Communications, Inc.,US AS33659 -- CMCS - Comcast Cable Communications, Inc.,US 6 - 192.245.51.0/24 27241 0.3% AS10965 -- MRNET - MRNet,CA AS17001 -- UMANITOBA - University of Manitoba,CA 7 - 64.34.125.0/24 21840 0.2% AS22059 -- -Reserved AS-,ZZ 8 - 76.191.107.0/24 20992 0.2% AS22059 -- -Reserved AS-,ZZ 9 - 168.151.255.0/24 15964 0.2% AS62519 -- CERTIFIEDHOST-ASN - Certified Host, LLC,US 10 - 170.178.152.0/22 15120 0.2% AS63485 -- PATRIOT-ASN - Patriot Web Solutions,US 11 - 92.43.216.0/21 12273 0.1% AS25563 -- WEBLAND-AS Webland AG,CH 12 - 185.84.192.0/22 11822 0.1% AS25563 -- WEBLAND-AS Webland AG,CH 13 - 178.174.96.0/19 11780 0.1% AS25563 -- WEBLAND-AS Webland AG,CH 14 - 78.140.0.0/18 11332 0.1% AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 15 - 194.1.163.0/24 9741 0.1% AS8283 -- COLOCLUE-AS Netwerkvereniging Coloclue, Amsterdam, Netherlands,NL 16 - 192.58.137.0/24 9500 0.1% AS393588 -- MUBEA-FLO - Mubea,US 17 - 203.192.255.0/24 9386 0.1% AS17665 -- IN2CABLE-AP AS Number of In2cable.com (India) Ltd.,IN 18 - 66.19.194.0/24 9267 0.1% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc.,US 19 - 192.58.232.0/24 8323 0.1% AS6629 -- NOAA-AS - NOAA,US 20 - 94.73.56.0/21 7245 0.1% AS42081 -- SPEEDY-NET-AS Speedy net EAD,BG 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 baldur.norddahl at gmail.com Fri Jun 19 22:30:45 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 20 Jun 2015 00:30:45 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> Message-ID: On 19 June 2015 at 23:58, Harlan Stenn wrote: > Bad idea. > > When restarting ntpd your clocks will likely be off by a second, which > will cause a backward step, which will force the problem you claim to be > avoiding. > If you are afraid that your routers will crash due to the leapsecond, then it would help to disable the thing that you think will crash them. Even if the router crashes when you enable it later on. Because then you can have one router crash at a time and have it happen in a service window where you are ready for it. Instead of having all routers in your whole network crash at exactly the same time. Regards, Baldur From andrew.duey at widerangebroadband.net Fri Jun 19 22:44:07 2015 From: andrew.duey at widerangebroadband.net (Andrew Duey) Date: Fri, 19 Jun 2015 17:44:07 -0500 Subject: Google Apps for ISPs In-Reply-To: <19853087.871.1434648406542.JavaMail.mhammett@ThunderFuck> References: <19853087.871.1434648406542.JavaMail.mhammett@ThunderFuck> Message-ID: Our Google Apps for ISP's is still up and running. We were told end of July for end of service date. I was under the impression though that there were different dates for different customers originally, but I know we're still up and running on it. --Andrew --Andrew Duey WideRange Broadband LLC Direct: 402-327-1101 andrew.duey at widerangebroadband.net http://widerangebroadband.net On Thu, Jun 18, 2015 at 12:26 PM, Mike Hammett wrote: > There was an inquiry about this just the other day. They got theirs turned > back on. Check the archives for the Google contact. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Scott Helms" > To: "Josh Luthman" > Cc: "NANOG list" > Sent: Thursday, June 18, 2015 11:36:54 AM > Subject: Re: Google Apps for ISPs > > Josh, > > From what I have been able to see from an outsider's point of view, they > tore down the virtual machines that held those emails and while I doubt > they scrubbed the hard drives, they're not available in "commercially > reasonable way". > > No ISP I've worked with has been able to get access to emails, settings, > address books, or anything else since early in June and that's not from > lack of trying. > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > On Thu, Jun 18, 2015 at 12:32 PM, Josh Luthman < > josh at imaginenetworksllc.com> > wrote: > > > That's all we're after, customers' emails. > > > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > On Jun 18, 2015 12:12 PM, "Scott Helms" wrote: > > > >> We worked with dozens of service providers to get their email services > >> migrated, AFAIK no one got an extension. I was told directly that it was > >> possible to have an extension because Google was pulling down the entire > >> system. I'd advise: > >> > >> 1) Make sure your domain TTL's are fairly low so you can change your MX > >> record and have the world get that update shortly there after. > >> > >> 2) Find an alternative email provider, preferably someone who has done > >> transitions to and from Google before. > >> > >> 3) Start communicating with your customers, AFAIK their email, address > >> books, and calendars aren't available and won't be. > >> > >> > >> Scott Helms > >> Vice President of Technology > >> ZCorum > >> (678) 507-5000 > >> -------------------------------- > >> http://twitter.com/kscotthelms > >> -------------------------------- > >> > >> On Thu, Jun 18, 2015 at 11:58 AM, Josh Luthman < > >> josh at imaginenetworksllc.com> wrote: > >> > >>> If anyone can message me off list it would be great. > >>> > >>> We were originally told the service would be shut off in July. All of > the > >>> accounts were disabled June 9. > >>> > >>> Josh Luthman > >>> Office: 937-552-2340 > >>> Direct: 937-552-2343 > >>> 1100 Wayne St > >>> Suite 1337 > >>> Troy, OH 45373 > >>> > >> > >> > > From rps at maine.edu Fri Jun 19 23:07:01 2015 From: rps at maine.edu (Ray Soucy) Date: Fri, 19 Jun 2015 19:07:01 -0400 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: Message-ID: I know you don't want to hear this answer because of cost but I've had good luck with Cisco for very high density (about 1,000 clients in a packed auditorium actively using the network as they follow along with the presenter). The thing you need to watch out for with Ubiquiti is that they don't support DFS, so the entire U-NII-2 channel space is off limits for 5 GHz. That's pretty significant because you're limited to 9 x 20 MHz channels or 4 x 40 MHz channels. Keeping the power level down and creating small cells is essential for high density, so with less channels your hands are really tied in that case. Also, avoid the Zero Handoff marketing nonsense they advertise; I'm sure it can work great for a low client residential area but it requires all APs to share a single channel and depends upon coordinating only one active transmitter at a time, so it simply won't scale. I don't have experience with other vendors at large scale or high density. I don't think what you're talking about is really high density anymore though. That's just normal coverage. Wireless is a lot more complicated than selecting a vendor, though. If you know what you're doing even Ubiquiti could work decently, but if you don't even a Cisco solution won't save you. You really need to be on top of surveying correctly and having appropriate AP placement and channel distribution. On Fri, Jun 19, 2015 at 1:57 AM, Sina Owolabi wrote: > Hi > > We are profiling equipment and design for an expected high user density > network of multiple, close nit, residential/hostel units. Its going to be > 8-10 buildings with possibly a over 1000 users at any given time. > We are looking at Ruckus and Ubiquiti as options to get over the high > number of devices we are definitely going to encounter. > > How did you do it, and what would you advise for product and layout? > > Thanks in advance! > -- 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 josh at imaginenetworksllc.com Fri Jun 19 23:09:12 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 19 Jun 2015 19:09:12 -0400 Subject: Google Apps for ISPs In-Reply-To: References: <19853087.871.1434648406542.JavaMail.mhammett@ThunderFuck> Message-ID: Yes, demanding on your annual contract. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Jun 19, 2015 6:44 PM, "Andrew Duey" wrote: > Our Google Apps for ISP's is still up and running. We were told end of > July for end of service date. I was under the impression though that there > were different dates for different customers originally, but I know we're > still up and running on it. > > --Andrew > > --Andrew Duey > > WideRange Broadband LLC > Direct: 402-327-1101 > andrew.duey at widerangebroadband.net > http://widerangebroadband.net > > On Thu, Jun 18, 2015 at 12:26 PM, Mike Hammett wrote: > > > There was an inquiry about this just the other day. They got theirs > turned > > back on. Check the archives for the Google contact. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > ----- Original Message ----- > > > > From: "Scott Helms" > > To: "Josh Luthman" > > Cc: "NANOG list" > > Sent: Thursday, June 18, 2015 11:36:54 AM > > Subject: Re: Google Apps for ISPs > > > > Josh, > > > > From what I have been able to see from an outsider's point of view, they > > tore down the virtual machines that held those emails and while I doubt > > they scrubbed the hard drives, they're not available in "commercially > > reasonable way". > > > > No ISP I've worked with has been able to get access to emails, settings, > > address books, or anything else since early in June and that's not from > > lack of trying. > > > > > > Scott Helms > > Vice President of Technology > > ZCorum > > (678) 507-5000 > > -------------------------------- > > http://twitter.com/kscotthelms > > -------------------------------- > > > > On Thu, Jun 18, 2015 at 12:32 PM, Josh Luthman < > > josh at imaginenetworksllc.com> > > wrote: > > > > > That's all we're after, customers' emails. > > > > > > Josh Luthman > > > Office: 937-552-2340 > > > Direct: 937-552-2343 > > > 1100 Wayne St > > > Suite 1337 > > > Troy, OH 45373 > > > On Jun 18, 2015 12:12 PM, "Scott Helms" wrote: > > > > > >> We worked with dozens of service providers to get their email services > > >> migrated, AFAIK no one got an extension. I was told directly that it > was > > >> possible to have an extension because Google was pulling down the > entire > > >> system. I'd advise: > > >> > > >> 1) Make sure your domain TTL's are fairly low so you can change your > MX > > >> record and have the world get that update shortly there after. > > >> > > >> 2) Find an alternative email provider, preferably someone who has done > > >> transitions to and from Google before. > > >> > > >> 3) Start communicating with your customers, AFAIK their email, address > > >> books, and calendars aren't available and won't be. > > >> > > >> > > >> Scott Helms > > >> Vice President of Technology > > >> ZCorum > > >> (678) 507-5000 > > >> -------------------------------- > > >> http://twitter.com/kscotthelms > > >> -------------------------------- > > >> > > >> On Thu, Jun 18, 2015 at 11:58 AM, Josh Luthman < > > >> josh at imaginenetworksllc.com> wrote: > > >> > > >>> If anyone can message me off list it would be great. > > >>> > > >>> We were originally told the service would be shut off in July. All of > > the > > >>> accounts were disabled June 9. > > >>> > > >>> Josh Luthman > > >>> Office: 937-552-2340 > > >>> Direct: 937-552-2343 > > >>> 1100 Wayne St > > >>> Suite 1337 > > >>> Troy, OH 45373 > > >>> > > >> > > >> > > > > > From stenn at ntp.org Fri Jun 19 23:09:18 2015 From: stenn at ntp.org (Harlan Stenn) Date: Fri, 19 Jun 2015 23:09:18 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> Message-ID: Baldur Norddahl writes: > On 19 June 2015 at 23:58, Harlan Stenn wrote: > > > Bad idea. > > > > When restarting ntpd your clocks will likely be off by a second, which > > will cause a backward step, which will force the problem you claim to be > > avoiding. > > If you are afraid that your routers will crash due to the leapsecond, > then it would help to disable the thing that you think will crash > them. Even if the router crashes when you enable it later on. Because > then you can have one router crash at a time and have it happen in a > service window where you are ready for it. Instead of having all > routers in your whole network crash at exactly the same time. That' seems fair, as long as you turn off the time stuff only on your routers, and I'm assuming this is on routers that don't have supported software. H From randy at psg.com Sat Jun 20 00:40:20 2015 From: randy at psg.com (Randy Bush) Date: Sat, 20 Jun 2015 09:40:20 +0900 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: Message-ID: > I know you don't want to hear this answer because of cost but I've had > good luck with Cisco for very high density (about 1,000 clients in a > packed auditorium actively using the network as they follow along with > the presenter). the ietf is repeatedly successful with cisco kit at well over 1,000 users, and i mean very active users, in the ballroom. thanks chelliott. but it is not simple, you need to know what you're doing and few do. one can also screw up with any kit, as nanog keeps demonstrating. randy From faisal at snappytelecom.net Sat Jun 20 01:11:56 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 20 Jun 2015 01:11:56 +0000 (GMT) Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: Message-ID: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> >>>The thing you need to watch out for with Ubiquiti is that they don't support DFS, so the entire U-NII-2 channel space is off limits for 5 GHz. Huh ???? Please verify your facts before making blanket statements which are not accurate ... Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Ray Soucy" > To: "Sina Owolabi" > Cc: "nanog at nanog.org list" > Sent: Friday, June 19, 2015 7:07:01 PM > Subject: Re: Whats' a good product for a high-density Wireless network setup? > > I know you don't want to hear this answer because of cost but I've had good > luck with Cisco for very high density (about 1,000 clients in a packed > auditorium actively using the network as they follow along with the > presenter). > > The thing you need to watch out for with Ubiquiti is that they don't > support DFS, so the entire U-NII-2 channel space is off limits for 5 GHz. > That's pretty significant because you're limited to 9 x 20 MHz channels or > 4 x 40 MHz channels. Keeping the power level down and creating small cells > is essential for high density, so with less channels your hands are really > tied in that case. Also, avoid the Zero Handoff marketing nonsense they > advertise; I'm sure it can work great for a low client residential area but > it requires all APs to share a single channel and depends upon coordinating > only one active transmitter at a time, so it simply won't scale. > > I don't have experience with other vendors at large scale or high density. > > I don't think what you're talking about is really high density anymore > though. That's just normal coverage. Wireless is a lot more complicated > than selecting a vendor, though. If you know what you're doing even > Ubiquiti could work decently, but if you don't even a Cisco solution won't > save you. You really need to be on top of surveying correctly and having > appropriate AP placement and channel distribution. > > > > > > On Fri, Jun 19, 2015 at 1:57 AM, Sina Owolabi wrote: > > > Hi > > > > We are profiling equipment and design for an expected high user density > > network of multiple, close nit, residential/hostel units. Its going to be > > 8-10 buildings with possibly a over 1000 users at any given time. > > We are looking at Ruckus and Ubiquiti as options to get over the high > > number of devices we are definitely going to encounter. > > > > How did you do it, and what would you advise for product and layout? > > > > Thanks in advance! > > > > > > -- > 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 josh at imaginenetworksllc.com Sat Jun 20 01:16:37 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 19 Jun 2015 21:16:37 -0400 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> Message-ID: Uhm he's not wrong... Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Jun 19, 2015 9:13 PM, "Faisal Imtiaz" wrote: > >>>The thing you need to watch out for with Ubiquiti is that they don't > support DFS, so the entire U-NII-2 channel space is off limits for 5 GHz. > > Huh ???? > > Please verify your facts before making blanket statements which are not > accurate ... > > > > Faisal Imtiaz > Snappy Internet & Telecom > > > ----- Original Message ----- > > From: "Ray Soucy" > > To: "Sina Owolabi" > > Cc: "nanog at nanog.org list" > > Sent: Friday, June 19, 2015 7:07:01 PM > > Subject: Re: Whats' a good product for a high-density Wireless network > setup? > > > > I know you don't want to hear this answer because of cost but I've had > good > > luck with Cisco for very high density (about 1,000 clients in a packed > > auditorium actively using the network as they follow along with the > > presenter). > > > > The thing you need to watch out for with Ubiquiti is that they don't > > support DFS, so the entire U-NII-2 channel space is off limits for 5 GHz. > > That's pretty significant because you're limited to 9 x 20 MHz channels > or > > 4 x 40 MHz channels. Keeping the power level down and creating small > cells > > is essential for high density, so with less channels your hands are > really > > tied in that case. Also, avoid the Zero Handoff marketing nonsense they > > advertise; I'm sure it can work great for a low client residential area > but > > it requires all APs to share a single channel and depends upon > coordinating > > only one active transmitter at a time, so it simply won't scale. > > > > I don't have experience with other vendors at large scale or high > density. > > > > I don't think what you're talking about is really high density anymore > > though. That's just normal coverage. Wireless is a lot more complicated > > than selecting a vendor, though. If you know what you're doing even > > Ubiquiti could work decently, but if you don't even a Cisco solution > won't > > save you. You really need to be on top of surveying correctly and having > > appropriate AP placement and channel distribution. > > > > > > > > > > > > On Fri, Jun 19, 2015 at 1:57 AM, Sina Owolabi > wrote: > > > > > Hi > > > > > > We are profiling equipment and design for an expected high user density > > > network of multiple, close nit, residential/hostel units. Its going to > be > > > 8-10 buildings with possibly a over 1000 users at any given time. > > > We are looking at Ruckus and Ubiquiti as options to get over the high > > > number of devices we are definitely going to encounter. > > > > > > How did you do it, and what would you advise for product and layout? > > > > > > Thanks in advance! > > > > > > > > > > > -- > > 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 bill at herrin.us Sat Jun 20 01:17:46 2015 From: bill at herrin.us (William Herrin) Date: Fri, 19 Jun 2015 21:17:46 -0400 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: Message-ID: On Fri, Jun 19, 2015 at 1:57 AM, Sina Owolabi wrote: > We are profiling equipment and design for an expected high user density > network of multiple, close nit, residential/hostel units. Its going to be > 8-10 buildings with possibly a over 1000 users at any given time. Hi Sina, Quick terminology note: "high density" means you want 500+ users in a conference hall. That's a very different solution space than 1000 users spread across 8 buildings. High density solutions are concerned with many nodes not stomping on each other in a small space as users wander about. Yet cables connecting all the access points together are short and cheap. Your situation is different. With users spread out, you have less of a signal stomping problem and more of a signal reach problem through various construction materials. Cross-building connections are expensive and few enough users wander between buildings to need to maintain their IP address when they do. If you ask your vendors to show you high-density solutions you may not get what you're looking for. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jamesl at mythostech.com Sat Jun 20 01:35:47 2015 From: jamesl at mythostech.com (James Laszko) Date: Sat, 20 Jun 2015 01:35:47 +0000 Subject: SIP trunking providers In-Reply-To: References: Message-ID: We have facilities in Chicago and LAX based on Broadsoft technology that I think is pretty awesome. Would welcome answering any questions for you.... Regards, James Laszko Mythos Technology Inc jamesl at mythostech.com 951-813-2674 direct Sent from my iPhone > On Jun 19, 2015, at 14:43, Rafael Possamai wrote: > > Would anyone in the list be able to recommend a SIP trunk provider in the > Chicago area? Not a VoIP expert, so just looking for someone with previous > experience. > > > Thanks, > Rafael From jamesl at mythostech.com Sat Jun 20 01:40:31 2015 From: jamesl at mythostech.com (James Laszko) Date: Sat, 20 Jun 2015 01:40:31 +0000 Subject: SIP trunking providers In-Reply-To: References: , Message-ID: Sorry, intended for off-list reply. Sorry for noise. James Sent from my iPhone > On Jun 19, 2015, at 18:37, James Laszko wrote: > > We have facilities in Chicago and LAX based on Broadsoft technology that I think is pretty awesome. Would welcome answering any questions for you.... > > > Regards, > > > James Laszko > Mythos Technology Inc > jamesl at mythostech.com > 951-813-2674 direct > > Sent from my iPhone > >> On Jun 19, 2015, at 14:43, Rafael Possamai wrote: >> >> Would anyone in the list be able to recommend a SIP trunk provider in the >> Chicago area? Not a VoIP expert, so just looking for someone with previous >> experience. >> >> >> Thanks, >> Rafael From mel at beckman.org Sat Jun 20 01:42:48 2015 From: mel at beckman.org (Mel Beckman) Date: Sat, 20 Jun 2015 01:42:48 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> , Message-ID: Harlan, This is cisco's recommended workaround, the ultimate conclusion of an exhaustive study of all Cisco firmware and after detailed post mortem analysis of two previous Leap seconds: https://tools.cisco.com/bugsearch/bug/CSCut33302 GSS Leap second update CSCut33302 Description Symptom: There are periodic leap second events which can add or delete a second to global time. When the leap second update occurs the GSS might hang and have to be reload or the kernel could crash and the GSS would reboot. Conditions: The leap second update will be propagated via Network Time Protocol (NTP) or via manually setting the clock. Workaround: Workaround, Turn off NTP prior to leap second and turn it back on afterward. Further Problem Description: None Or, in the immortal words of The IT Crowd: "Turn it off and on again!" If you run non-IOS server software of such fragility that it can't tolerate time slewing, just shut it down and power back up after The Leap. That's what your competitors are doing :) -mel beckman On Jun 19, 2015, at 4:15 PM, Harlan Stenn > wrote: Baldur Norddahl writes: On 19 June 2015 at 23:58, Harlan Stenn > wrote: Bad idea. When restarting ntpd your clocks will likely be off by a second, which will cause a backward step, which will force the problem you claim to be avoiding. If you are afraid that your routers will crash due to the leapsecond, then it would help to disable the thing that you think will crash them. Even if the router crashes when you enable it later on. Because then you can have one router crash at a time and have it happen in a service window where you are ready for it. Instead of having all routers in your whole network crash at exactly the same time. That' seems fair, as long as you turn off the time stuff only on your routers, and I'm assuming this is on routers that don't have supported software. H From mike.lyon at gmail.com Sat Jun 20 02:08:08 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 19 Jun 2015 19:08:08 -0700 Subject: SIP trunking providers In-Reply-To: References: Message-ID: Flowroute.com On Jun 19, 2015 6:42 PM, "James Laszko" wrote: > Sorry, intended for off-list reply. Sorry for noise. > > James > > Sent from my iPhone > > > On Jun 19, 2015, at 18:37, James Laszko wrote: > > > > We have facilities in Chicago and LAX based on Broadsoft technology that > I think is pretty awesome. Would welcome answering any questions for > you.... > > > > > > Regards, > > > > > > James Laszko > > Mythos Technology Inc > > jamesl at mythostech.com > > 951-813-2674 direct > > > > Sent from my iPhone > > > >> On Jun 19, 2015, at 14:43, Rafael Possamai wrote: > >> > >> Would anyone in the list be able to recommend a SIP trunk provider in > the > >> Chicago area? Not a VoIP expert, so just looking for someone with > previous > >> experience. > >> > >> > >> Thanks, > >> Rafael > From faisal at snappytelecom.net Sat Jun 20 03:36:05 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 20 Jun 2015 03:36:05 +0000 (GMT) Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> Message-ID: <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> FCC Cert claims different. :) 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: "Josh Luthman" > To: "Faisal Imtiaz" > Cc: "NANOG list" , "Ray Soucy" > Sent: Friday, June 19, 2015 9:16:37 PM > Subject: Re: Whats' a good product for a high-density Wireless network setup? > Uhm he's not wrong... > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Jun 19, 2015 9:13 PM, "Faisal Imtiaz" < faisal at snappytelecom.net > wrote: > > >>>The thing you need to watch out for with Ubiquiti is that they don't > > >>>support DFS, so the entire U-NII-2 channel space is off limits for 5 > > >>>GHz. > > > Huh ???? > > > Please verify your facts before making blanket statements which are not > > accurate ... > > > Faisal Imtiaz > > > Snappy Internet & Telecom > > > ----- Original Message ----- > > > > From: "Ray Soucy" < rps at maine.edu > > > > > To: "Sina Owolabi" < notify.sina at gmail.com > > > > > Cc: " nanog at nanog.org list" < nanog at nanog.org > > > > > Sent: Friday, June 19, 2015 7:07:01 PM > > > > Subject: Re: Whats' a good product for a high-density Wireless network > > > setup? > > > > > > > > I know you don't want to hear this answer because of cost but I've had > > > good > > > > luck with Cisco for very high density (about 1,000 clients in a packed > > > > auditorium actively using the network as they follow along with the > > > > presenter). > > > > > > > > The thing you need to watch out for with Ubiquiti is that they don't > > > > support DFS, so the entire U-NII-2 channel space is off limits for 5 GHz. > > > > That's pretty significant because you're limited to 9 x 20 MHz channels > > > or > > > > 4 x 40 MHz channels. Keeping the power level down and creating small > > > cells > > > > is essential for high density, so with less channels your hands are > > > really > > > > tied in that case. Also, avoid the Zero Handoff marketing nonsense they > > > > advertise; I'm sure it can work great for a low client residential area > > > but > > > > it requires all APs to share a single channel and depends upon > > > coordinating > > > > only one active transmitter at a time, so it simply won't scale. > > > > > > > > I don't have experience with other vendors at large scale or high > > > density. > > > > > > > > I don't think what you're talking about is really high density anymore > > > > though. That's just normal coverage. Wireless is a lot more complicated > > > > than selecting a vendor, though. If you know what you're doing even > > > > Ubiquiti could work decently, but if you don't even a Cisco solution > > > won't > > > > save you. You really need to be on top of surveying correctly and having > > > > appropriate AP placement and channel distribution. > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 19, 2015 at 1:57 AM, Sina Owolabi < notify.sina at gmail.com > > > > wrote: > > > > > > > > > Hi > > > > > > > > > > We are profiling equipment and design for an expected high user density > > > > > network of multiple, close nit, residential/hostel units. Its going to > > > > be > > > > > 8-10 buildings with possibly a over 1000 users at any given time. > > > > > We are looking at Ruckus and Ubiquiti as options to get over the high > > > > > number of devices we are definitely going to encounter. > > > > > > > > > > How did you do it, and what would you advise for product and layout? > > > > > > > > > > Thanks in advance! > > > > > > > > > > > > > > > > > > > > > -- > > > > 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 josh at imaginenetworksllc.com Sat Jun 20 03:50:10 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 19 Jun 2015 23:50:10 -0400 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: My equipment that can't do 5.4 with the latest stable or beta firmware says you can't. Hopefully we get 5.1 "soon". :) Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Jun 19, 2015 11:36 PM, "Faisal Imtiaz" wrote: > FCC Cert claims different. > > :) > > 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: *"Josh Luthman" > *To: *"Faisal Imtiaz" > *Cc: *"NANOG list" , "Ray Soucy" > *Sent: *Friday, June 19, 2015 9:16:37 PM > *Subject: *Re: Whats' a good product for a high-density Wireless network > setup? > > Uhm he's not wrong... > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Jun 19, 2015 9:13 PM, "Faisal Imtiaz" wrote: > >> >>>The thing you need to watch out for with Ubiquiti is that they don't >> support DFS, so the entire U-NII-2 channel space is off limits for 5 GHz. >> >> Huh ???? >> >> Please verify your facts before making blanket statements which are not >> accurate ... >> >> >> >> Faisal Imtiaz >> Snappy Internet & Telecom >> >> >> ----- Original Message ----- >> > From: "Ray Soucy" >> > To: "Sina Owolabi" >> > Cc: "nanog at nanog.org list" >> > Sent: Friday, June 19, 2015 7:07:01 PM >> > Subject: Re: Whats' a good product for a high-density Wireless network >> setup? >> > >> > I know you don't want to hear this answer because of cost but I've had >> good >> > luck with Cisco for very high density (about 1,000 clients in a packed >> > auditorium actively using the network as they follow along with the >> > presenter). >> > >> > The thing you need to watch out for with Ubiquiti is that they don't >> > support DFS, so the entire U-NII-2 channel space is off limits for 5 >> GHz. >> > That's pretty significant because you're limited to 9 x 20 MHz channels >> or >> > 4 x 40 MHz channels. Keeping the power level down and creating small >> cells >> > is essential for high density, so with less channels your hands are >> really >> > tied in that case. Also, avoid the Zero Handoff marketing nonsense they >> > advertise; I'm sure it can work great for a low client residential area >> but >> > it requires all APs to share a single channel and depends upon >> coordinating >> > only one active transmitter at a time, so it simply won't scale. >> > >> > I don't have experience with other vendors at large scale or high >> density. >> > >> > I don't think what you're talking about is really high density anymore >> > though. That's just normal coverage. Wireless is a lot more >> complicated >> > than selecting a vendor, though. If you know what you're doing even >> > Ubiquiti could work decently, but if you don't even a Cisco solution >> won't >> > save you. You really need to be on top of surveying correctly and >> having >> > appropriate AP placement and channel distribution. >> > >> > >> > >> > >> > >> > On Fri, Jun 19, 2015 at 1:57 AM, Sina Owolabi >> wrote: >> > >> > > Hi >> > > >> > > We are profiling equipment and design for an expected high user >> density >> > > network of multiple, close nit, residential/hostel units. Its going >> to be >> > > 8-10 buildings with possibly a over 1000 users at any given time. >> > > We are looking at Ruckus and Ubiquiti as options to get over the high >> > > number of devices we are definitely going to encounter. >> > > >> > > How did you do it, and what would you advise for product and layout? >> > > >> > > Thanks in advance! >> > > >> > >> > >> > >> > -- >> > 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 tqr2813d376cjozqap1l at tutanota.com Sat Jun 20 03:43:10 2015 From: tqr2813d376cjozqap1l at tutanota.com (tqr2813d376cjozqap1l at tutanota.com) Date: Sat, 20 Jun 2015 03:43:10 +0000 (UTC) Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: Their "airMAX" line recently got UNII approval but not their UniFi line to my knowledge: https://community.ubnt.com/t5/airMAX-Updates-Blog/airMAX-FCC-UNII-Updates-Lower-Band-Activation-Process/ba-p/1265946 20. Jun 2015 03:36 by faisal at snappytelecom.net: > FCC Cert claims different. > > :) > > 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: "Josh Luthman" <>> josh at imaginenetworksllc.com>> > >> To: "Faisal Imtiaz" <>> faisal at snappytelecom.net>> > >> Cc: "NANOG list" <>> nanog at nanog.org>> >, "Ray Soucy" <>> rps at maine.edu>> >> > >> Sent: Friday, June 19, 2015 9:16:37 PM >> Subject: Re: Whats' a good product for a high-density Wireless network >> setup? >> Uhm he's not wrong... >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> On Jun 19, 2015 9:13 PM, "Faisal Imtiaz" < >> faisal at snappytelecom.net>> >> > wrote: >> > >>>The thing you need to watch out for with Ubiquiti is that they don't >> > >>>support DFS, so the entire U-NII-2 channel space is off limits for 5 >> > >>>GHz. >> >> > Huh ???? >> >> > Please verify your facts before making blanket statements which are not >> > accurate ... >> >> > Faisal Imtiaz >> >> > Snappy Internet & Telecom >> >> > ----- Original Message ----- >> >> > > From: "Ray Soucy" < >> rps at maine.edu>> > >> >> > > To: "Sina Owolabi" < >> notify.sina at gmail.com>> > >> >> > > Cc: " >> nanog at nanog.org>> list" < >> nanog at nanog.org>> > >> >> > > Sent: Friday, June 19, 2015 7:07:01 PM >> >> > > Subject: Re: Whats' a good product for a high-density Wireless network >> > > setup? >> >> > > >> >> > > I know you don't want to hear this answer because of cost but I've had >> > > good >> >> > > luck with Cisco for very high density (about 1,000 clients in a packed >> >> > > auditorium actively using the network as they follow along with the >> >> > > presenter). >> >> > > >> >> > > The thing you need to watch out for with Ubiquiti is that they don't >> >> > > support DFS, so the entire U-NII-2 channel space is off limits for 5 >> GHz. >> >> > > That's pretty significant because you're limited to 9 x 20 MHz >> channels >> > > or >> >> > > 4 x 40 MHz channels. Keeping the power level down and creating small >> > > cells >> >> > > is essential for high density, so with less channels your hands are >> > > really >> >> > > tied in that case. Also, avoid the Zero Handoff marketing nonsense >> they >> >> > > advertise; I'm sure it can work great for a low client residential >> area >> > > but >> >> > > it requires all APs to share a single channel and depends upon >> > > coordinating >> >> > > only one active transmitter at a time, so it simply won't scale. >> >> > > >> >> > > I don't have experience with other vendors at large scale or high >> > > density. >> >> > > >> >> > > I don't think what you're talking about is really high density anymore >> >> > > though. That's just normal coverage. Wireless is a lot more >> complicated >> >> > > than selecting a vendor, though. If you know what you're doing even >> >> > > Ubiquiti could work decently, but if you don't even a Cisco solution >> > > won't >> >> > > save you. You really need to be on top of surveying correctly and >> having >> >> > > appropriate AP placement and channel distribution. >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > On Fri, Jun 19, 2015 at 1:57 AM, Sina Owolabi < >> >> notify.sina at gmail.com>> > >> > > wrote: >> >> > > >> >> > > > Hi >> >> > > > >> >> > > > We are profiling equipment and design for an expected high user >> density >> >> > > > network of multiple, close nit, residential/hostel units. Its going >> to >> > > > be >> >> > > > 8-10 buildings with possibly a over 1000 users at any given time. >> >> > > > We are looking at Ruckus and Ubiquiti as options to get over the >> high >> >> > > > number of devices we are definitely going to encounter. >> >> > > > >> >> > > > How did you do it, and what would you advise for product and layout? >> >> > > > >> >> > > > Thanks in advance! >> >> > > > >> >> > > >> >> > > >> >> > > >> >> > > -- >> >> > > Ray Patrick Soucy >> >> > > Network Engineer >> >> > > University of Maine System >> >> > > >> >> > > T: 207-561-3526 >> >> > > F: 207-561-3531 >> >> > > >> >> > > MaineREN, Maine's Research and Education Network >> >> > > >> http://www.maineren.net >> >> > > >> From rps at maine.edu Sat Jun 20 04:31:52 2015 From: rps at maine.edu (Ray Soucy) Date: Sat, 20 Jun 2015 00:31:52 -0400 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: Well, I could certainly be wrong, but it's news to me if UBNT started supporting DFS in the US. Your first screenshot is listing the UAP for 5240 which is channel 48, U-NII-1. The second show 5825 which is the upper limit of U-NNI-3. I don't see any U-NII-2 in what you posted. This forum post may be a bit out of date, but I haven't seen any announcement or information on the forums to indicate the situation has changed, and I'm pretty good at searching: https://community.ubnt.com/t5/UniFi-Wireless/DFS/m-p/700461#M54771 >From this thread it looks like the ability to configure DFS channels in the US was a UI bug and only showing for ZH anyway. IIRC they actually got in a bit of trouble with the FCC over not restricting the use of these channels enough. Regardless of whether or not the FCC has cleared UBNT indoor products for U-NII-2 and U-NII-2-extended (and I haven't seen evidence of that yet), until you can configure APs to use those channels in the controller without violating FCC regulations I don't consider them usable. The UAP-AC doesn't seem to support DFS channels at all even without FCC restrictions, which kind of kills the point of AC, only 4 x 40 MHz or 2 x 80 MHz channels doesn't cut it when we're talking about density. Note we're talking about indoor wireless and there ARE some UBNT products for outdoor WISP use that do support DFS and have been cleared by the FCC, but we would only be looking at the UAP-PRO or UAP-AC in this case so maybe that's the point of confusion here. On Fri, Jun 19, 2015 at 11:36 PM, Faisal Imtiaz wrote: > FCC Cert claims different. > > :) > > 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: *"Josh Luthman" > *To: *"Faisal Imtiaz" > *Cc: *"NANOG list" , "Ray Soucy" > *Sent: *Friday, June 19, 2015 9:16:37 PM > > *Subject: *Re: Whats' a good product for a high-density Wireless network > setup? > > Uhm he's not wrong... > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > On Jun 19, 2015 9:13 PM, "Faisal Imtiaz" wrote: > >> >>>The thing you need to watch out for with Ubiquiti is that they don't >> support DFS, so the entire U-NII-2 channel space is off limits for 5 GHz. >> >> Huh ???? >> >> Please verify your facts before making blanket statements which are not >> accurate ... >> >> >> >> Faisal Imtiaz >> Snappy Internet & Telecom >> >> >> ----- Original Message ----- >> > From: "Ray Soucy" >> > To: "Sina Owolabi" >> > Cc: "nanog at nanog.org list" >> > Sent: Friday, June 19, 2015 7:07:01 PM >> > Subject: Re: Whats' a good product for a high-density Wireless network >> setup? >> > >> > I know you don't want to hear this answer because of cost but I've had >> good >> > luck with Cisco for very high density (about 1,000 clients in a packed >> > auditorium actively using the network as they follow along with the >> > presenter). >> > >> > The thing you need to watch out for with Ubiquiti is that they don't >> > support DFS, so the entire U-NII-2 channel space is off limits for 5 >> GHz. >> > That's pretty significant because you're limited to 9 x 20 MHz channels >> or >> > 4 x 40 MHz channels. Keeping the power level down and creating small >> cells >> > is essential for high density, so with less channels your hands are >> really >> > tied in that case. Also, avoid the Zero Handoff marketing nonsense they >> > advertise; I'm sure it can work great for a low client residential area >> but >> > it requires all APs to share a single channel and depends upon >> coordinating >> > only one active transmitter at a time, so it simply won't scale. >> > >> > I don't have experience with other vendors at large scale or high >> density. >> > >> > I don't think what you're talking about is really high density anymore >> > though. That's just normal coverage. Wireless is a lot more >> complicated >> > than selecting a vendor, though. If you know what you're doing even >> > Ubiquiti could work decently, but if you don't even a Cisco solution >> won't >> > save you. You really need to be on top of surveying correctly and >> having >> > appropriate AP placement and channel distribution. >> > >> > >> > >> > >> > >> > On Fri, Jun 19, 2015 at 1:57 AM, Sina Owolabi >> wrote: >> > >> > > Hi >> > > >> > > We are profiling equipment and design for an expected high user >> density >> > > network of multiple, close nit, residential/hostel units. Its going >> to be >> > > 8-10 buildings with possibly a over 1000 users at any given time. >> > > We are looking at Ruckus and Ubiquiti as options to get over the high >> > > number of devices we are definitely going to encounter. >> > > >> > > How did you do it, and what would you advise for product and layout? >> > > >> > > Thanks in advance! >> > > >> > >> > >> > >> > -- >> > 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 stenn at ntp.org Sat Jun 20 07:07:25 2015 From: stenn at ntp.org (Harlan Stenn) Date: Sat, 20 Jun 2015 07:07:25 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> , Message-ID: Mel Beckman writes: > Harlan, > > This is cisco's recommended workaround, the ultimate conclusion of an exhau= > stive study of all Cisco firmware and after detailed post mortem analysis o= > f two previous Leap seconds: > > https://tools.cisco.com/bugsearch/bug/CSCut33302 Fair enough. And I've been trying to get Cisco to work with us for very many years. They have yet to show any interest. But they'd be paying us for that. We have no leverage with them. But folks who are paying Cisco for support? For the number of years Cisco has been using NTP and for the number of product lines that use it, they could certainly do better. I know they were current when I did the port for the MDS switch line, years ago. -- Harlan Stenn http://networktimefoundation.org - be a member! From saku at ytti.fi Sat Jun 20 07:48:17 2015 From: saku at ytti.fi (Saku Ytti) Date: Sat, 20 Jun 2015 10:48:17 +0300 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> Message-ID: <20150620074817.GA13104@pob.ytti.fi> On (2015-06-19 21:53 +0000), Harlan Stenn wrote: > It's a problem with POSIX, not UTC. > > UTC is monotonic. You're right. Hopefully POSIX will become monotonic next year, by removal of leaps from UTC. -- ++ytti From notify.sina at gmail.com Sat Jun 20 10:41:29 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Sat, 20 Jun 2015 10:41:29 +0000 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: Thanks everybody. I've been corrected on density... I've been informed that it's to be a minimum of 1000 users per building. That's 8,000 users. (8 buildings, not counting walkways and courtyards, admin, etc.) Does this qualify as high-density? On Sat, Jun 20, 2015 at 5:33 AM Ray Soucy wrote: > Well, I could certainly be wrong, but it's news to me if UBNT started > supporting DFS in the US. > > Your first screenshot is listing the UAP for 5240 which is channel 48, > U-NII-1. The second show 5825 which is the upper limit of U-NNI-3. I > don't see any U-NII-2 in what you posted. > > This forum post may be a bit out of date, but I haven't seen any > announcement or information on the forums to indicate the situation has > changed, and I'm pretty good at searching: > > https://community.ubnt.com/t5/UniFi-Wireless/DFS/m-p/700461#M54771 > > From this thread it looks like the ability to configure DFS channels in the > US was a UI bug and only showing for ZH anyway. IIRC they actually got in > a bit of trouble with the FCC over not restricting the use of these > channels enough. > > Regardless of whether or not the FCC has cleared UBNT indoor products for > U-NII-2 and U-NII-2-extended (and I haven't seen evidence of that yet), > until you can configure APs to use those channels in the controller without > violating FCC regulations I don't consider them usable. > > The UAP-AC doesn't seem to support DFS channels at all even without FCC > restrictions, which kind of kills the point of AC, only 4 x 40 MHz or 2 x > 80 MHz channels doesn't cut it when we're talking about density. > > Note we're talking about indoor wireless and there ARE some UBNT products > for outdoor WISP use that do support DFS and have been cleared by the FCC, > but we would only be looking at the UAP-PRO or UAP-AC in this case so maybe > that's the point of confusion here. > > > > > On Fri, Jun 19, 2015 at 11:36 PM, Faisal Imtiaz > wrote: > > > FCC Cert claims different. > > > > :) > > > > 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: *"Josh Luthman" > > *To: *"Faisal Imtiaz" > > *Cc: *"NANOG list" , "Ray Soucy" > > *Sent: *Friday, June 19, 2015 9:16:37 PM > > > > *Subject: *Re: Whats' a good product for a high-density Wireless network > > setup? > > > > Uhm he's not wrong... > > > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > On Jun 19, 2015 9:13 PM, "Faisal Imtiaz" > wrote: > > > >> >>>The thing you need to watch out for with Ubiquiti is that they don't > >> support DFS, so the entire U-NII-2 channel space is off limits for 5 > GHz. > >> > >> Huh ???? > >> > >> Please verify your facts before making blanket statements which are not > >> accurate ... > >> > >> > >> > >> Faisal Imtiaz > >> Snappy Internet & Telecom > >> > >> > >> ----- Original Message ----- > >> > From: "Ray Soucy" > >> > To: "Sina Owolabi" > >> > Cc: "nanog at nanog.org list" > >> > Sent: Friday, June 19, 2015 7:07:01 PM > >> > Subject: Re: Whats' a good product for a high-density Wireless network > >> setup? > >> > > >> > I know you don't want to hear this answer because of cost but I've had > >> good > >> > luck with Cisco for very high density (about 1,000 clients in a packed > >> > auditorium actively using the network as they follow along with the > >> > presenter). > >> > > >> > The thing you need to watch out for with Ubiquiti is that they don't > >> > support DFS, so the entire U-NII-2 channel space is off limits for 5 > >> GHz. > >> > That's pretty significant because you're limited to 9 x 20 MHz > channels > >> or > >> > 4 x 40 MHz channels. Keeping the power level down and creating small > >> cells > >> > is essential for high density, so with less channels your hands are > >> really > >> > tied in that case. Also, avoid the Zero Handoff marketing nonsense > they > >> > advertise; I'm sure it can work great for a low client residential > area > >> but > >> > it requires all APs to share a single channel and depends upon > >> coordinating > >> > only one active transmitter at a time, so it simply won't scale. > >> > > >> > I don't have experience with other vendors at large scale or high > >> density. > >> > > >> > I don't think what you're talking about is really high density anymore > >> > though. That's just normal coverage. Wireless is a lot more > >> complicated > >> > than selecting a vendor, though. If you know what you're doing even > >> > Ubiquiti could work decently, but if you don't even a Cisco solution > >> won't > >> > save you. You really need to be on top of surveying correctly and > >> having > >> > appropriate AP placement and channel distribution. > >> > > >> > > >> > > >> > > >> > > >> > On Fri, Jun 19, 2015 at 1:57 AM, Sina Owolabi > >> wrote: > >> > > >> > > Hi > >> > > > >> > > We are profiling equipment and design for an expected high user > >> density > >> > > network of multiple, close nit, residential/hostel units. Its going > >> to be > >> > > 8-10 buildings with possibly a over 1000 users at any given time. > >> > > We are looking at Ruckus and Ubiquiti as options to get over the > high > >> > > number of devices we are definitely going to encounter. > >> > > > >> > > How did you do it, and what would you advise for product and layout? > >> > > > >> > > Thanks in advance! > >> > > > >> > > >> > > >> > > >> > -- > >> > 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 rafael at gav.ufsc.br Sat Jun 20 11:59:30 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sat, 20 Jun 2015 06:59:30 -0500 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: I don't think there's an actual standard for density, at least I am not aware of one. Independent of the vendor you use, this guide should be valid at 80% of implementations: http://www.cisco.com/c/en/us/products/collateral/wireless/aironet-1250-series/design_guide_c07-693245.html On Meraki's website there's a case study of an entertainment venue that has about 2,000 users per night, so I am assuming 1,000 which is your cause should be doable. On Sat, Jun 20, 2015 at 5:41 AM, Sina Owolabi wrote: > Thanks everybody. I've been corrected on density... I've been informed that > it's to be a minimum of 1000 users per building. > That's 8,000 users. (8 buildings, not counting walkways and courtyards, > admin, etc.) > Does this qualify as high-density? > > On Sat, Jun 20, 2015 at 5:33 AM Ray Soucy wrote: > > > Well, I could certainly be wrong, but it's news to me if UBNT started > > supporting DFS in the US. > > > > Your first screenshot is listing the UAP for 5240 which is channel 48, > > U-NII-1. The second show 5825 which is the upper limit of U-NNI-3. I > > don't see any U-NII-2 in what you posted. > > > > This forum post may be a bit out of date, but I haven't seen any > > announcement or information on the forums to indicate the situation has > > changed, and I'm pretty good at searching: > > > > https://community.ubnt.com/t5/UniFi-Wireless/DFS/m-p/700461#M54771 > > > > From this thread it looks like the ability to configure DFS channels in > the > > US was a UI bug and only showing for ZH anyway. IIRC they actually got > in > > a bit of trouble with the FCC over not restricting the use of these > > channels enough. > > > > Regardless of whether or not the FCC has cleared UBNT indoor products for > > U-NII-2 and U-NII-2-extended (and I haven't seen evidence of that yet), > > until you can configure APs to use those channels in the controller > without > > violating FCC regulations I don't consider them usable. > > > > The UAP-AC doesn't seem to support DFS channels at all even without FCC > > restrictions, which kind of kills the point of AC, only 4 x 40 MHz or 2 x > > 80 MHz channels doesn't cut it when we're talking about density. > > > > Note we're talking about indoor wireless and there ARE some UBNT products > > for outdoor WISP use that do support DFS and have been cleared by the > FCC, > > but we would only be looking at the UAP-PRO or UAP-AC in this case so > maybe > > that's the point of confusion here. > > > > > > > > > > On Fri, Jun 19, 2015 at 11:36 PM, Faisal Imtiaz < > faisal at snappytelecom.net> > > wrote: > > > > > FCC Cert claims different. > > > > > > :) > > > > > > 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: *"Josh Luthman" > > > *To: *"Faisal Imtiaz" > > > *Cc: *"NANOG list" , "Ray Soucy" > > > *Sent: *Friday, June 19, 2015 9:16:37 PM > > > > > > *Subject: *Re: Whats' a good product for a high-density Wireless > network > > > setup? > > > > > > Uhm he's not wrong... > > > > > > Josh Luthman > > > Office: 937-552-2340 > > > Direct: 937-552-2343 > > > 1100 Wayne St > > > Suite 1337 > > > Troy, OH 45373 > > > On Jun 19, 2015 9:13 PM, "Faisal Imtiaz" > > wrote: > > > > > >> >>>The thing you need to watch out for with Ubiquiti is that they > don't > > >> support DFS, so the entire U-NII-2 channel space is off limits for 5 > > GHz. > > >> > > >> Huh ???? > > >> > > >> Please verify your facts before making blanket statements which are > not > > >> accurate ... > > >> > > >> > > >> > > >> Faisal Imtiaz > > >> Snappy Internet & Telecom > > >> > > >> > > >> ----- Original Message ----- > > >> > From: "Ray Soucy" > > >> > To: "Sina Owolabi" > > >> > Cc: "nanog at nanog.org list" > > >> > Sent: Friday, June 19, 2015 7:07:01 PM > > >> > Subject: Re: Whats' a good product for a high-density Wireless > network > > >> setup? > > >> > > > >> > I know you don't want to hear this answer because of cost but I've > had > > >> good > > >> > luck with Cisco for very high density (about 1,000 clients in a > packed > > >> > auditorium actively using the network as they follow along with the > > >> > presenter). > > >> > > > >> > The thing you need to watch out for with Ubiquiti is that they don't > > >> > support DFS, so the entire U-NII-2 channel space is off limits for 5 > > >> GHz. > > >> > That's pretty significant because you're limited to 9 x 20 MHz > > channels > > >> or > > >> > 4 x 40 MHz channels. Keeping the power level down and creating > small > > >> cells > > >> > is essential for high density, so with less channels your hands are > > >> really > > >> > tied in that case. Also, avoid the Zero Handoff marketing nonsense > > they > > >> > advertise; I'm sure it can work great for a low client residential > > area > > >> but > > >> > it requires all APs to share a single channel and depends upon > > >> coordinating > > >> > only one active transmitter at a time, so it simply won't scale. > > >> > > > >> > I don't have experience with other vendors at large scale or high > > >> density. > > >> > > > >> > I don't think what you're talking about is really high density > anymore > > >> > though. That's just normal coverage. Wireless is a lot more > > >> complicated > > >> > than selecting a vendor, though. If you know what you're doing even > > >> > Ubiquiti could work decently, but if you don't even a Cisco solution > > >> won't > > >> > save you. You really need to be on top of surveying correctly and > > >> having > > >> > appropriate AP placement and channel distribution. > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > On Fri, Jun 19, 2015 at 1:57 AM, Sina Owolabi < > notify.sina at gmail.com> > > >> wrote: > > >> > > > >> > > Hi > > >> > > > > >> > > We are profiling equipment and design for an expected high user > > >> density > > >> > > network of multiple, close nit, residential/hostel units. Its > going > > >> to be > > >> > > 8-10 buildings with possibly a over 1000 users at any given time. > > >> > > We are looking at Ruckus and Ubiquiti as options to get over the > > high > > >> > > number of devices we are definitely going to encounter. > > >> > > > > >> > > How did you do it, and what would you advise for product and > layout? > > >> > > > > >> > > Thanks in advance! > > >> > > > > >> > > > >> > > > >> > > > >> > -- > > >> > 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 rafael at gav.ufsc.br Sat Jun 20 12:13:29 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sat, 20 Jun 2015 07:13:29 -0500 Subject: SIP trunking providers In-Reply-To: References: Message-ID: Thanks everyone for your responses. On Fri, Jun 19, 2015 at 4:40 PM, Rafael Possamai wrote: > Would anyone in the list be able to recommend a SIP trunk provider in the > Chicago area? Not a VoIP expert, so just looking for someone with previous > experience. > > > Thanks, > Rafael > From rsk at gsp.org Sat Jun 20 12:29:09 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 20 Jun 2015 08:29:09 -0400 Subject: Paging postmaster at gmx.net/gmx.de et.al. Message-ID: <20150620122908.GA18122@gsp.org> [ Tried this over on mailop; no response, so now trying here. ] I've noticed that one of my servers has been unable to establish port 25 connections to hosts such as mx00.emig.gmx.net for over a week...and I'm entirely puzzled as to why, since it only sends a trickle of traffic to a handful of users @gmx.net/@gmx.de etc. (They're on a couple of small, low-volume Mailman-managed lists, and have been for time periods ranging from "over a year" to "most of a decade" without any issues.) Some help figuring out why this is happening would be entirely welcome. Thanks, ---rsk From admin at marcoteixeira.com Sat Jun 20 12:40:24 2015 From: admin at marcoteixeira.com (Marco Teixeira) Date: Sat, 20 Jun 2015 13:40:24 +0100 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: Rafael, At some scales, the WiFi standard alone will not cut it... Research on MERUNETWORKS virtual cell tecnology. I have done a trial with them. All the others are far behind on density. Check their case studies. Em 20/06/2015 13:02, "Rafael Possamai" escreveu: > I don't think there's an actual standard for density, at least I am not > aware of one. Independent of the vendor you use, this guide should be valid > at 80% of implementations: > > > http://www.cisco.com/c/en/us/products/collateral/wireless/aironet-1250-series/design_guide_c07-693245.html > > On Meraki's website there's a case study of an entertainment venue that has > about 2,000 users per night, so I am assuming 1,000 which is your cause > should be doable. > > On Sat, Jun 20, 2015 at 5:41 AM, Sina Owolabi > wrote: > > > Thanks everybody. I've been corrected on density... I've been informed > that > > it's to be a minimum of 1000 users per building. > > That's 8,000 users. (8 buildings, not counting walkways and courtyards, > > admin, etc.) > > Does this qualify as high-density? > > > > On Sat, Jun 20, 2015 at 5:33 AM Ray Soucy wrote: > > > > > Well, I could certainly be wrong, but it's news to me if UBNT started > > > supporting DFS in the US. > > > > > > Your first screenshot is listing the UAP for 5240 which is channel 48, > > > U-NII-1. The second show 5825 which is the upper limit of U-NNI-3. I > > > don't see any U-NII-2 in what you posted. > > > > > > This forum post may be a bit out of date, but I haven't seen any > > > announcement or information on the forums to indicate the situation has > > > changed, and I'm pretty good at searching: > > > > > > https://community.ubnt.com/t5/UniFi-Wireless/DFS/m-p/700461#M54771 > > > > > > From this thread it looks like the ability to configure DFS channels in > > the > > > US was a UI bug and only showing for ZH anyway. IIRC they actually got > > in > > > a bit of trouble with the FCC over not restricting the use of these > > > channels enough. > > > > > > Regardless of whether or not the FCC has cleared UBNT indoor products > for > > > U-NII-2 and U-NII-2-extended (and I haven't seen evidence of that yet), > > > until you can configure APs to use those channels in the controller > > without > > > violating FCC regulations I don't consider them usable. > > > > > > The UAP-AC doesn't seem to support DFS channels at all even without FCC > > > restrictions, which kind of kills the point of AC, only 4 x 40 MHz or > 2 x > > > 80 MHz channels doesn't cut it when we're talking about density. > > > > > > Note we're talking about indoor wireless and there ARE some UBNT > products > > > for outdoor WISP use that do support DFS and have been cleared by the > > FCC, > > > but we would only be looking at the UAP-PRO or UAP-AC in this case so > > maybe > > > that's the point of confusion here. > > > > > > > > > > > > > > > On Fri, Jun 19, 2015 at 11:36 PM, Faisal Imtiaz < > > faisal at snappytelecom.net> > > > wrote: > > > > > > > FCC Cert claims different. > > > > > > > > :) > > > > > > > > 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: *"Josh Luthman" > > > > *To: *"Faisal Imtiaz" > > > > *Cc: *"NANOG list" , "Ray Soucy" > > > > *Sent: *Friday, June 19, 2015 9:16:37 PM > > > > > > > > *Subject: *Re: Whats' a good product for a high-density Wireless > > network > > > > setup? > > > > > > > > Uhm he's not wrong... > > > > > > > > Josh Luthman > > > > Office: 937-552-2340 > > > > Direct: 937-552-2343 > > > > 1100 Wayne St > > > > Suite 1337 > > > > Troy, OH 45373 > > > > On Jun 19, 2015 9:13 PM, "Faisal Imtiaz" > > > wrote: > > > > > > > >> >>>The thing you need to watch out for with Ubiquiti is that they > > don't > > > >> support DFS, so the entire U-NII-2 channel space is off limits for 5 > > > GHz. > > > >> > > > >> Huh ???? > > > >> > > > >> Please verify your facts before making blanket statements which are > > not > > > >> accurate ... > > > >> > > > >> > > > >> > > > >> Faisal Imtiaz > > > >> Snappy Internet & Telecom > > > >> > > > >> > > > >> ----- Original Message ----- > > > >> > From: "Ray Soucy" > > > >> > To: "Sina Owolabi" > > > >> > Cc: "nanog at nanog.org list" > > > >> > Sent: Friday, June 19, 2015 7:07:01 PM > > > >> > Subject: Re: Whats' a good product for a high-density Wireless > > network > > > >> setup? > > > >> > > > > >> > I know you don't want to hear this answer because of cost but I've > > had > > > >> good > > > >> > luck with Cisco for very high density (about 1,000 clients in a > > packed > > > >> > auditorium actively using the network as they follow along with > the > > > >> > presenter). > > > >> > > > > >> > The thing you need to watch out for with Ubiquiti is that they > don't > > > >> > support DFS, so the entire U-NII-2 channel space is off limits > for 5 > > > >> GHz. > > > >> > That's pretty significant because you're limited to 9 x 20 MHz > > > channels > > > >> or > > > >> > 4 x 40 MHz channels. Keeping the power level down and creating > > small > > > >> cells > > > >> > is essential for high density, so with less channels your hands > are > > > >> really > > > >> > tied in that case. Also, avoid the Zero Handoff marketing > nonsense > > > they > > > >> > advertise; I'm sure it can work great for a low client residential > > > area > > > >> but > > > >> > it requires all APs to share a single channel and depends upon > > > >> coordinating > > > >> > only one active transmitter at a time, so it simply won't scale. > > > >> > > > > >> > I don't have experience with other vendors at large scale or high > > > >> density. > > > >> > > > > >> > I don't think what you're talking about is really high density > > anymore > > > >> > though. That's just normal coverage. Wireless is a lot more > > > >> complicated > > > >> > than selecting a vendor, though. If you know what you're doing > even > > > >> > Ubiquiti could work decently, but if you don't even a Cisco > solution > > > >> won't > > > >> > save you. You really need to be on top of surveying correctly and > > > >> having > > > >> > appropriate AP placement and channel distribution. > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > On Fri, Jun 19, 2015 at 1:57 AM, Sina Owolabi < > > notify.sina at gmail.com> > > > >> wrote: > > > >> > > > > >> > > Hi > > > >> > > > > > >> > > We are profiling equipment and design for an expected high user > > > >> density > > > >> > > network of multiple, close nit, residential/hostel units. Its > > going > > > >> to be > > > >> > > 8-10 buildings with possibly a over 1000 users at any given > time. > > > >> > > We are looking at Ruckus and Ubiquiti as options to get over the > > > high > > > >> > > number of devices we are definitely going to encounter. > > > >> > > > > > >> > > How did you do it, and what would you advise for product and > > layout? > > > >> > > > > > >> > > Thanks in advance! > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > -- > > > >> > 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 sla at ucolick.org Sat Jun 20 12:53:14 2015 From: sla at ucolick.org (Steve Allen) Date: Sat, 20 Jun 2015 05:53:14 -0700 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150620074817.GA13104@pob.ytti.fi> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150620074817.GA13104@pob.ytti.fi> Message-ID: <20150620125314.GA575@ucolick.org> On Sat 2015-06-20T10:48:17 +0300, Saku Ytti hath writ: > You're right. Hopefully POSIX will become monotonic next year, by removal of > leaps from UTC. Probably not. The ITU-R has outlined four methods for this issue, see http://www.acma.gov.au/Industry/Spectrum/Spectrum-planning/International-planning-ITU-and-other-international-planning-bodies/wrc-15-agenda-item-114 where of method A1, A2, B, C1, C2, and D not all of them remove the leap second from UTC. In any case, previous draft proposals have all specified a 5 year interval from deciding to change until the change happens, so we should plan for 5 more years of leap seconds no matter what. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From rps at maine.edu Sat Jun 20 13:01:34 2015 From: rps at maine.edu (Ray Soucy) Date: Sat, 20 Jun 2015 09:01:34 -0400 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: Compared to the old model of just providing coverage, it's definitely higher density. I think the point I was trying to make is that the old high density is the new normal, and what most on list would consider high density is more along the lines of stadium wireless. I wouldn't really focus on the term too much, though. It's just a distraction from the real question. The answer as always is "it depends". Without detailed floor plans, survey information, and information on what kind of demand users will place on the network, there is really no way to tell you what solution will work well. If you need to service residential areas or hostel units you might be better off looking at some of the newer AP designs that have come out in the last year or so targeting that application, like the Cisco 702 or the Xirus 320. The general design of these units is that they're both a low-power AP and a small switch to provide residents with a few ports to plug in if they need to. This allows you to have one cable drop to each room instead of having to run separate jacks for APs and wired connections. The units are wall-mount and if you have a challenging RF environment this design can be really effective. I've never run Xirrus personally, but I think they were used for the last NANOG conference. On Sat, Jun 20, 2015 at 6:41 AM, Sina Owolabi wrote: > Thanks everybody. I've been corrected on density... I've been informed > that it's to be a minimum of 1000 users per building. > That's 8,000 users. (8 buildings, not counting walkways and courtyards, > admin, etc.) > Does this qualify as high-density? > > On Sat, Jun 20, 2015 at 5:33 AM Ray Soucy wrote: > >> Well, I could certainly be wrong, but it's news to me if UBNT started >> supporting DFS in the US. >> >> Your first screenshot is listing the UAP for 5240 which is channel 48, >> U-NII-1. The second show 5825 which is the upper limit of U-NNI-3. I >> don't see any U-NII-2 in what you posted. >> >> This forum post may be a bit out of date, but I haven't seen any >> announcement or information on the forums to indicate the situation has >> changed, and I'm pretty good at searching: >> >> https://community.ubnt.com/t5/UniFi-Wireless/DFS/m-p/700461#M54771 >> >> From this thread it looks like the ability to configure DFS channels in >> the >> US was a UI bug and only showing for ZH anyway. IIRC they actually got in >> a bit of trouble with the FCC over not restricting the use of these >> channels enough. >> >> Regardless of whether or not the FCC has cleared UBNT indoor products for >> U-NII-2 and U-NII-2-extended (and I haven't seen evidence of that yet), >> until you can configure APs to use those channels in the controller >> without >> violating FCC regulations I don't consider them usable. >> >> The UAP-AC doesn't seem to support DFS channels at all even without FCC >> restrictions, which kind of kills the point of AC, only 4 x 40 MHz or 2 x >> 80 MHz channels doesn't cut it when we're talking about density. >> >> Note we're talking about indoor wireless and there ARE some UBNT products >> for outdoor WISP use that do support DFS and have been cleared by the FCC, >> but we would only be looking at the UAP-PRO or UAP-AC in this case so >> maybe >> that's the point of confusion here. >> >> >> >> >> On Fri, Jun 19, 2015 at 11:36 PM, Faisal Imtiaz > > >> wrote: >> >> > FCC Cert claims different. >> > >> > :) >> > >> > 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: *"Josh Luthman" >> > *To: *"Faisal Imtiaz" >> > *Cc: *"NANOG list" , "Ray Soucy" >> > *Sent: *Friday, June 19, 2015 9:16:37 PM >> > >> > *Subject: *Re: Whats' a good product for a high-density Wireless network >> >> > setup? >> > >> > Uhm he's not wrong... >> > >> > Josh Luthman >> > Office: 937-552-2340 >> > Direct: 937-552-2343 >> > 1100 Wayne St >> > Suite 1337 >> > Troy, OH 45373 >> > On Jun 19, 2015 9:13 PM, "Faisal Imtiaz" >> wrote: >> > >> >> >>>The thing you need to watch out for with Ubiquiti is that they don't >> >> support DFS, so the entire U-NII-2 channel space is off limits for 5 >> GHz. >> >> >> >> Huh ???? >> >> >> >> Please verify your facts before making blanket statements which are not >> >> accurate ... >> >> >> >> >> >> >> >> Faisal Imtiaz >> >> Snappy Internet & Telecom >> >> >> >> >> >> ----- Original Message ----- >> >> > From: "Ray Soucy" >> >> > To: "Sina Owolabi" >> >> > Cc: "nanog at nanog.org list" >> >> > Sent: Friday, June 19, 2015 7:07:01 PM >> >> > Subject: Re: Whats' a good product for a high-density Wireless >> network >> >> setup? >> >> > >> >> > I know you don't want to hear this answer because of cost but I've >> had >> >> good >> >> > luck with Cisco for very high density (about 1,000 clients in a >> packed >> >> > auditorium actively using the network as they follow along with the >> >> > presenter). >> >> > >> >> > The thing you need to watch out for with Ubiquiti is that they don't >> >> > support DFS, so the entire U-NII-2 channel space is off limits for 5 >> >> GHz. >> >> > That's pretty significant because you're limited to 9 x 20 MHz >> channels >> >> or >> >> > 4 x 40 MHz channels. Keeping the power level down and creating small >> >> cells >> >> > is essential for high density, so with less channels your hands are >> >> really >> >> > tied in that case. Also, avoid the Zero Handoff marketing nonsense >> they >> >> > advertise; I'm sure it can work great for a low client residential >> area >> >> but >> >> > it requires all APs to share a single channel and depends upon >> >> coordinating >> >> > only one active transmitter at a time, so it simply won't scale. >> >> > >> >> > I don't have experience with other vendors at large scale or high >> >> density. >> >> > >> >> > I don't think what you're talking about is really high density >> anymore >> >> > though. That's just normal coverage. Wireless is a lot more >> >> complicated >> >> > than selecting a vendor, though. If you know what you're doing even >> >> > Ubiquiti could work decently, but if you don't even a Cisco solution >> >> won't >> >> > save you. You really need to be on top of surveying correctly and >> >> having >> >> > appropriate AP placement and channel distribution. >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > On Fri, Jun 19, 2015 at 1:57 AM, Sina Owolabi > > >> >> wrote: >> >> > >> >> > > Hi >> >> > > >> >> > > We are profiling equipment and design for an expected high user >> >> density >> >> > > network of multiple, close nit, residential/hostel units. Its going >> >> to be >> >> > > 8-10 buildings with possibly a over 1000 users at any given time. >> >> > > We are looking at Ruckus and Ubiquiti as options to get over the >> high >> >> > > number of devices we are definitely going to encounter. >> >> > > >> >> > > How did you do it, and what would you advise for product and >> layout? >> >> > > >> >> > > Thanks in advance! >> >> > > >> >> > >> >> > >> >> > >> >> > -- >> >> > 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 rs at seastrom.com Sat Jun 20 13:22:48 2015 From: rs at seastrom.com (Rob Seastrom) Date: Sat, 20 Jun 2015 09:22:48 -0400 Subject: Anycast provider for SMTP? In-Reply-To: <0403F2A2-4C8B-4A41-A80E-585C6E7C5367@hopcount.ca> (Joe Abley's message of "Fri, 19 Jun 2015 09:42:09 -0400") References: <0403F2A2-4C8B-4A41-A80E-585C6E7C5367@hopcount.ca> Message-ID: <86d20qqztj.fsf@valhalla.seastrom.com> "Joe Abley" writes: > http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-02 > > There are privacy concerns, here. But we might posit that you've > already in the business of trading privacy for convenience if you're > using a public resolver. Personally, I've always thought the privacy concerns of draft-vandergaast (not of using public recursive servers) are overwrought. The entity running the recursive nameserver has knowledge of the exact address (not just the subnet) that you're sending the query from, by inspection of the packet. The entity running the authoritative nameserver does not... but unless you're using DNS for some kind of off-label purpose ( http://code.kryo.se/iodine/ comes immediately to mind), the next thing you'll be doing once you have the reply is opening some kind of connection to the address returned... at which point the target entity will be able to tell the exact address that you're coming from. This assessment makes the assumption that the folks running the authoritative DNS servers are either the target entity or its agent. If that's an invalid assumption, one might say you have bigger problems. If someone could explain a privacy concern here that doesn't involve dipping into my meager tinfoil supply (I'm low and not going to the grocery until tomorrow), that would be swell. -r From rafael at gav.ufsc.br Sat Jun 20 13:49:40 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sat, 20 Jun 2015 08:49:40 -0500 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: That's interesting, I will take a look. Thanks! On Sat, Jun 20, 2015 at 7:40 AM, Marco Teixeira wrote: > Rafael, > At some scales, the WiFi standard alone will not cut it... Research on > MERUNETWORKS virtual cell tecnology. I have done a trial with them. All the > others are far behind on density. Check their case studies. > Em 20/06/2015 13:02, "Rafael Possamai" escreveu: > >> I don't think there's an actual standard for density, at least I am not >> aware of one. Independent of the vendor you use, this guide should be >> valid >> at 80% of implementations: >> >> >> http://www.cisco.com/c/en/us/products/collateral/wireless/aironet-1250-series/design_guide_c07-693245.html >> >> On Meraki's website there's a case study of an entertainment venue that >> has >> about 2,000 users per night, so I am assuming 1,000 which is your cause >> should be doable. >> >> On Sat, Jun 20, 2015 at 5:41 AM, Sina Owolabi >> wrote: >> >> > Thanks everybody. I've been corrected on density... I've been informed >> that >> > it's to be a minimum of 1000 users per building. >> > That's 8,000 users. (8 buildings, not counting walkways and courtyards, >> > admin, etc.) >> > Does this qualify as high-density? >> > >> > On Sat, Jun 20, 2015 at 5:33 AM Ray Soucy wrote: >> > >> > > Well, I could certainly be wrong, but it's news to me if UBNT started >> > > supporting DFS in the US. >> > > >> > > Your first screenshot is listing the UAP for 5240 which is channel 48, >> > > U-NII-1. The second show 5825 which is the upper limit of U-NNI-3. I >> > > don't see any U-NII-2 in what you posted. >> > > >> > > This forum post may be a bit out of date, but I haven't seen any >> > > announcement or information on the forums to indicate the situation >> has >> > > changed, and I'm pretty good at searching: >> > > >> > > https://community.ubnt.com/t5/UniFi-Wireless/DFS/m-p/700461#M54771 >> > > >> > > From this thread it looks like the ability to configure DFS channels >> in >> > the >> > > US was a UI bug and only showing for ZH anyway. IIRC they actually >> got >> > in >> > > a bit of trouble with the FCC over not restricting the use of these >> > > channels enough. >> > > >> > > Regardless of whether or not the FCC has cleared UBNT indoor products >> for >> > > U-NII-2 and U-NII-2-extended (and I haven't seen evidence of that >> yet), >> > > until you can configure APs to use those channels in the controller >> > without >> > > violating FCC regulations I don't consider them usable. >> > > >> > > The UAP-AC doesn't seem to support DFS channels at all even without >> FCC >> > > restrictions, which kind of kills the point of AC, only 4 x 40 MHz or >> 2 x >> > > 80 MHz channels doesn't cut it when we're talking about density. >> > > >> > > Note we're talking about indoor wireless and there ARE some UBNT >> products >> > > for outdoor WISP use that do support DFS and have been cleared by the >> > FCC, >> > > but we would only be looking at the UAP-PRO or UAP-AC in this case so >> > maybe >> > > that's the point of confusion here. >> > > >> > > >> > > >> > > >> > > On Fri, Jun 19, 2015 at 11:36 PM, Faisal Imtiaz < >> > faisal at snappytelecom.net> >> > > wrote: >> > > >> > > > FCC Cert claims different. >> > > > >> > > > :) >> > > > >> > > > 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: *"Josh Luthman" >> > > > *To: *"Faisal Imtiaz" >> > > > *Cc: *"NANOG list" , "Ray Soucy" >> > > > *Sent: *Friday, June 19, 2015 9:16:37 PM >> > > > >> > > > *Subject: *Re: Whats' a good product for a high-density Wireless >> > network >> > > > setup? >> > > > >> > > > Uhm he's not wrong... >> > > > >> > > > Josh Luthman >> > > > Office: 937-552-2340 >> > > > Direct: 937-552-2343 >> > > > 1100 Wayne St >> > > > Suite 1337 >> > > > Troy, OH 45373 >> > > > On Jun 19, 2015 9:13 PM, "Faisal Imtiaz" >> > > wrote: >> > > > >> > > >> >>>The thing you need to watch out for with Ubiquiti is that they >> > don't >> > > >> support DFS, so the entire U-NII-2 channel space is off limits for >> 5 >> > > GHz. >> > > >> >> > > >> Huh ???? >> > > >> >> > > >> Please verify your facts before making blanket statements which are >> > not >> > > >> accurate ... >> > > >> >> > > >> >> > > >> >> > > >> Faisal Imtiaz >> > > >> Snappy Internet & Telecom >> > > >> >> > > >> >> > > >> ----- Original Message ----- >> > > >> > From: "Ray Soucy" >> > > >> > To: "Sina Owolabi" >> > > >> > Cc: "nanog at nanog.org list" >> > > >> > Sent: Friday, June 19, 2015 7:07:01 PM >> > > >> > Subject: Re: Whats' a good product for a high-density Wireless >> > network >> > > >> setup? >> > > >> > >> > > >> > I know you don't want to hear this answer because of cost but >> I've >> > had >> > > >> good >> > > >> > luck with Cisco for very high density (about 1,000 clients in a >> > packed >> > > >> > auditorium actively using the network as they follow along with >> the >> > > >> > presenter). >> > > >> > >> > > >> > The thing you need to watch out for with Ubiquiti is that they >> don't >> > > >> > support DFS, so the entire U-NII-2 channel space is off limits >> for 5 >> > > >> GHz. >> > > >> > That's pretty significant because you're limited to 9 x 20 MHz >> > > channels >> > > >> or >> > > >> > 4 x 40 MHz channels. Keeping the power level down and creating >> > small >> > > >> cells >> > > >> > is essential for high density, so with less channels your hands >> are >> > > >> really >> > > >> > tied in that case. Also, avoid the Zero Handoff marketing >> nonsense >> > > they >> > > >> > advertise; I'm sure it can work great for a low client >> residential >> > > area >> > > >> but >> > > >> > it requires all APs to share a single channel and depends upon >> > > >> coordinating >> > > >> > only one active transmitter at a time, so it simply won't scale. >> > > >> > >> > > >> > I don't have experience with other vendors at large scale or high >> > > >> density. >> > > >> > >> > > >> > I don't think what you're talking about is really high density >> > anymore >> > > >> > though. That's just normal coverage. Wireless is a lot more >> > > >> complicated >> > > >> > than selecting a vendor, though. If you know what you're doing >> even >> > > >> > Ubiquiti could work decently, but if you don't even a Cisco >> solution >> > > >> won't >> > > >> > save you. You really need to be on top of surveying correctly >> and >> > > >> having >> > > >> > appropriate AP placement and channel distribution. >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > On Fri, Jun 19, 2015 at 1:57 AM, Sina Owolabi < >> > notify.sina at gmail.com> >> > > >> wrote: >> > > >> > >> > > >> > > Hi >> > > >> > > >> > > >> > > We are profiling equipment and design for an expected high user >> > > >> density >> > > >> > > network of multiple, close nit, residential/hostel units. Its >> > going >> > > >> to be >> > > >> > > 8-10 buildings with possibly a over 1000 users at any given >> time. >> > > >> > > We are looking at Ruckus and Ubiquiti as options to get over >> the >> > > high >> > > >> > > number of devices we are definitely going to encounter. >> > > >> > > >> > > >> > > How did you do it, and what would you advise for product and >> > layout? >> > > >> > > >> > > >> > > Thanks in advance! >> > > >> > > >> > > >> > >> > > >> > >> > > >> > >> > > >> > -- >> > > >> > 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 jra at baylink.com Sat Jun 20 15:32:53 2015 From: jra at baylink.com (Jay Ashworth) Date: Sat, 20 Jun 2015 11:32:53 -0400 (EDT) Subject: REMINDER: LEAP SECOND In-Reply-To: Message-ID: <6135309.141.1434814373239.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > - use the posix-right timezone files What; not posixly-correct? Cheers, -- jr ':-)' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From notify.sina at gmail.com Sat Jun 20 16:37:55 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Sat, 20 Jun 2015 16:37:55 +0000 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: I'd be grateful for any information on how to calculate for large scale wifi deployment On Sat, Jun 20, 2015 at 2:01 PM Ray Soucy wrote: > Compared to the old model of just providing coverage, it's definitely > higher density. I think the point I was trying to make is that the old > high density is the new normal, and what most on list would consider high > density is more along the lines of stadium wireless. I wouldn't really > focus on the term too much, though. It's just a distraction from the real > question. > > The answer as always is "it depends". Without detailed floor plans, > survey information, and information on what kind of demand users will place > on the network, there is really no way to tell you what solution will work > well. > > If you need to service residential areas or hostel units you might be > better off looking at some of the newer AP designs that have come out in > the last year or so targeting that application, like the Cisco 702 or the > Xirus 320. > > The general design of these units is that they're both a low-power AP and > a small switch to provide residents with a few ports to plug in if they > need to. This allows you to have one cable drop to each room instead of > having to run separate jacks for APs and wired connections. The units are > wall-mount and if you have a challenging RF environment this design can be > really effective. > > I've never run Xirrus personally, but I think they were used for the last > NANOG conference. > > > > > > On Sat, Jun 20, 2015 at 6:41 AM, Sina Owolabi > wrote: > >> Thanks everybody. I've been corrected on density... I've been informed >> that it's to be a minimum of 1000 users per building. >> That's 8,000 users. (8 buildings, not counting walkways and courtyards, >> admin, etc.) >> Does this qualify as high-density? >> >> On Sat, Jun 20, 2015 at 5:33 AM Ray Soucy wrote: >> >>> Well, I could certainly be wrong, but it's news to me if UBNT started >>> supporting DFS in the US. >>> >>> Your first screenshot is listing the UAP for 5240 which is channel 48, >>> U-NII-1. The second show 5825 which is the upper limit of U-NNI-3. I >>> don't see any U-NII-2 in what you posted. >>> >>> This forum post may be a bit out of date, but I haven't seen any >>> announcement or information on the forums to indicate the situation has >>> changed, and I'm pretty good at searching: >>> >>> https://community.ubnt.com/t5/UniFi-Wireless/DFS/m-p/700461#M54771 >>> >>> From this thread it looks like the ability to configure DFS channels in >>> the >>> US was a UI bug and only showing for ZH anyway. IIRC they actually got >>> in >>> a bit of trouble with the FCC over not restricting the use of these >>> channels enough. >>> >>> Regardless of whether or not the FCC has cleared UBNT indoor products for >>> U-NII-2 and U-NII-2-extended (and I haven't seen evidence of that yet), >>> until you can configure APs to use those channels in the controller >>> without >>> violating FCC regulations I don't consider them usable. >>> >>> The UAP-AC doesn't seem to support DFS channels at all even without FCC >>> restrictions, which kind of kills the point of AC, only 4 x 40 MHz or 2 x >>> 80 MHz channels doesn't cut it when we're talking about density. >>> >>> Note we're talking about indoor wireless and there ARE some UBNT products >>> for outdoor WISP use that do support DFS and have been cleared by the >>> FCC, >>> but we would only be looking at the UAP-PRO or UAP-AC in this case so >>> maybe >>> that's the point of confusion here. >>> >>> >>> >>> >>> On Fri, Jun 19, 2015 at 11:36 PM, Faisal Imtiaz < >>> faisal at snappytelecom.net> >>> wrote: >>> >>> > FCC Cert claims different. >>> > >>> > :) >>> > >>> > 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: *"Josh Luthman" >>> > *To: *"Faisal Imtiaz" >>> > *Cc: *"NANOG list" , "Ray Soucy" >>> > *Sent: *Friday, June 19, 2015 9:16:37 PM >>> > >>> > *Subject: *Re: Whats' a good product for a high-density Wireless >>> network >>> >>> > setup? >>> > >>> > Uhm he's not wrong... >>> > >>> > Josh Luthman >>> > Office: 937-552-2340 >>> > Direct: 937-552-2343 >>> > 1100 Wayne St >>> > Suite 1337 >>> > Troy, OH 45373 >>> > On Jun 19, 2015 9:13 PM, "Faisal Imtiaz" >>> wrote: >>> > >>> >> >>>The thing you need to watch out for with Ubiquiti is that they >>> don't >>> >> support DFS, so the entire U-NII-2 channel space is off limits for 5 >>> GHz. >>> >> >>> >> Huh ???? >>> >> >>> >> Please verify your facts before making blanket statements which are >>> not >>> >> accurate ... >>> >> >>> >> >>> >> >>> >> Faisal Imtiaz >>> >> Snappy Internet & Telecom >>> >> >>> >> >>> >> ----- Original Message ----- >>> >> > From: "Ray Soucy" >>> >> > To: "Sina Owolabi" >>> >> > Cc: "nanog at nanog.org list" >>> >> > Sent: Friday, June 19, 2015 7:07:01 PM >>> >> > Subject: Re: Whats' a good product for a high-density Wireless >>> network >>> >> setup? >>> >> > >>> >> > I know you don't want to hear this answer because of cost but I've >>> had >>> >> good >>> >> > luck with Cisco for very high density (about 1,000 clients in a >>> packed >>> >> > auditorium actively using the network as they follow along with the >>> >> > presenter). >>> >> > >>> >> > The thing you need to watch out for with Ubiquiti is that they don't >>> >> > support DFS, so the entire U-NII-2 channel space is off limits for 5 >>> >> GHz. >>> >> > That's pretty significant because you're limited to 9 x 20 MHz >>> channels >>> >> or >>> >> > 4 x 40 MHz channels. Keeping the power level down and creating >>> small >>> >> cells >>> >> > is essential for high density, so with less channels your hands are >>> >> really >>> >> > tied in that case. Also, avoid the Zero Handoff marketing nonsense >>> they >>> >> > advertise; I'm sure it can work great for a low client residential >>> area >>> >> but >>> >> > it requires all APs to share a single channel and depends upon >>> >> coordinating >>> >> > only one active transmitter at a time, so it simply won't scale. >>> >> > >>> >> > I don't have experience with other vendors at large scale or high >>> >> density. >>> >> > >>> >> > I don't think what you're talking about is really high density >>> anymore >>> >> > though. That's just normal coverage. Wireless is a lot more >>> >> complicated >>> >> > than selecting a vendor, though. If you know what you're doing even >>> >> > Ubiquiti could work decently, but if you don't even a Cisco solution >>> >> won't >>> >> > save you. You really need to be on top of surveying correctly and >>> >> having >>> >> > appropriate AP placement and channel distribution. >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > On Fri, Jun 19, 2015 at 1:57 AM, Sina Owolabi < >>> notify.sina at gmail.com> >>> >> wrote: >>> >> > >>> >> > > Hi >>> >> > > >>> >> > > We are profiling equipment and design for an expected high user >>> >> density >>> >> > > network of multiple, close nit, residential/hostel units. Its >>> going >>> >> to be >>> >> > > 8-10 buildings with possibly a over 1000 users at any given time. >>> >> > > We are looking at Ruckus and Ubiquiti as options to get over the >>> high >>> >> > > number of devices we are definitely going to encounter. >>> >> > > >>> >> > > How did you do it, and what would you advise for product and >>> layout? >>> >> > > >>> >> > > Thanks in advance! >>> >> > > >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > 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 ag4ve.us at gmail.com Sat Jun 20 18:03:01 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Sat, 20 Jun 2015 14:03:01 -0400 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150619180329.GA26018@pob.ytti.fi> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> Message-ID: On Jun 19, 2015 2:05 PM, "Saku Ytti" wrote: > > On (2015-06-19 13:06 -0400), Jay Ashworth wrote: > > Hey, > > > The IERS will be adding a second to time again on my birthday; > > > > 2015-06-30T23:59:60 > > Hopefully this is last leap second we'll ever see. Non-monotonic time is an > abomination and very very few programs measuring passage of time are correct. > Even those which are, usually are not portable, most languages do not even > offer monotonic time in standard libraries. > Canada, China, England and Germany, shame on you for opposing leapsecondless > UTC. > > Next year hopefully GPSTIME. TAI and UTC are the same thing, with different > static offset. > Unlikely but here's hoping. I mean letting computers figure out slower earth rotation on the fly would seem more accurate than leap seconds anyway. And then all of us who do earthly things and would like simpler libraries could live in peace. From stenn at ntp.org Sat Jun 20 18:15:34 2015 From: stenn at ntp.org (Harlan Stenn) Date: Sat, 20 Jun 2015 18:15:34 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> Message-ID: shawn wilson writes: > ... I mean letting computers figure out slower earth rotation on the > fly would seem more accurate than leap seconds anyway. And then all of > us who do earthly things and would like simpler libraries could live > in peace. Really? Have you looked in to those calculations, and I'm only talking about the allegedly predictable parts of those calculations, not things like the jetstream, the circumpolar currents, or earthquakes. H From ag4ve.us at gmail.com Sat Jun 20 18:58:56 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Sat, 20 Jun 2015 14:58:56 -0400 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> Message-ID: On Sat, Jun 20, 2015, 14:16 Harlan Stenn wrote: > > shawn wilson writes: > > ... I mean letting computers figure out slower earth rotation on the > > fly would seem more accurate than leap seconds anyway. And then all of > > us who do earthly things and would like simpler libraries could live > > in peace. > > Really? Have you looked in to those calculations, and I'm only talking > about the allegedly predictable parts of those calculations, not things > like the jetstream, the circumpolar currents, or earthquakes. > Ok, forget that point - AFAIK, the only things that matter wrt time is agreement on interval/counter and epoch, and stability. Right now we only have agreement on interval. So while I'd prefer a consistent epoch and counter, I'll live with whatever as we have access to board agreement and stability (like this doesn't hit NANOG every time with "uh oh"). From tknchris at gmail.com Sat Jun 20 19:36:39 2015 From: tknchris at gmail.com (chris) Date: Sat, 20 Jun 2015 15:36:39 -0400 Subject: VZW - fixed wireless services? In-Reply-To: References: <1e18db087b5c45f9ab290bb2f74fee41@BY2PR05MB079.namprd05.prod.outlook.com> Message-ID: They also do it on the enterprise side. We have a number of sites with 4G as a backup WAN, we give them the SIM info and they allow us to assign a static v4 IP or they will also give us a 1918 d address and tunnel it back to us. Overall it works good most of the time the only complaint really is that when theres a problem it can sometimes be time consuming to troubleshoot and find out if the issue is actually on the cellular side or not. Alot of times VZW tells you to contact your radio mfr and the mfr tells you to contact verizon. chris On Wed, Jul 16, 2014 at 1:16 AM, Mike Lyon wrote: > I believe they just attach it as a regular data device on whatever data > plan you pick. It's known as Verizon HomeFusion: > > http://www.verizonwireless.com/b2c/homefusion/hf/main.do > > -Mike > > > > > > On Tue, Jul 15, 2014 at 10:13 PM, Ryan Finnesey wrote: > > > Do you happen to know the rates or where I can find more information on > > the offering? > > > > > > > > *From:* Mike Lyon [mailto:mike.lyon at gmail.com] > > *Sent:* Wednesday, July 16, 2014 1:12 AM > > *To:* Ryan Finnesey > > *Cc:* nanog at nanog.org > > *Subject:* Re: VZW - fixed wireless services? > > > > > > > > Yes, they are. At least out here in Silicon Valley they are. > > > > > > > > -Mike > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jul 15, 2014 at 10:06 PM, Ryan Finnesey > wrote: > > > > Does anyone know if Verizon is using its LTE network to offer fixed > > wireless services? I know Sprint was working on WiMAX hardware with > cisco > > but I assume that was canceled when Sprint started moving to LTE. > > > > Cheers > > Ryan > > > > > > > > > > > > -- > > > > Mike Lyon > > > > 408-621-4826 > > > > mike.lyon at gmail.com > > > > > > > > http://www.linkedin.com/in/mlyon > > > > > > > > > > > > > > > > > > -- > Mike Lyon > 408-621-4826 > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon > From hank at efes.iucc.ac.il Sat Jun 20 20:03:01 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 20 Jun 2015 23:03:01 +0300 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: <5.1.1.6.2.20150620230042.0216ffb8@efes.iucc.ac.il> At 10:41 20/06/2015 +0000, Sina Owolabi wrote: http://www.extricom.com/ specializes in hi-density Wifi. See: http://www.extricom.com/category/large-venues http://www.extricom.com/category/Event_Installations -Hank >Thanks everybody. I've been corrected on density... I've been informed that >it's to be a minimum of 1000 users per building. >That's 8,000 users. (8 buildings, not counting walkways and courtyards, >admin, etc.) >Does this qualify as high-density? From randy at psg.com Sat Jun 20 21:31:38 2015 From: randy at psg.com (Randy Bush) Date: Sun, 21 Jun 2015 06:31:38 +0900 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: > I've never run Xirrus personally, but I think they were used for the > last NANOG conference. and how did that work out? [ though i do not know it was the xirrus units ] randy From Valdis.Kletnieks at vt.edu Sat Jun 20 22:44:02 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 20 Jun 2015 18:44:02 -0400 Subject: REMINDER: LEAP SECOND In-Reply-To: Your message of "Sat, 20 Jun 2015 11:32:53 -0400." <6135309.141.1434814373239.JavaMail.root@benjamin.baylink.com> References: <6135309.141.1434814373239.JavaMail.root@benjamin.baylink.com> Message-ID: <63652.1434840242@turing-police.cc.vt.edu> On Sat, 20 Jun 2015 11:32:53 -0400, Jay Ashworth said: > ----- Original Message ----- > > > - use the posix-right timezone files > > What; not posixly-correct? I wonder how many of us are old enough to remember what that environment variable *used* to be called before political correctness became important. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From rps at maine.edu Sat Jun 20 22:53:49 2015 From: rps at maine.edu (Ray Soucy) Date: Sat, 20 Jun 2015 18:53:49 -0400 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: I've actually never made it out to a NANOG conference, so I'm not sure. I was just told this by peers who attended. On Sat, Jun 20, 2015 at 5:31 PM, Randy Bush wrote: > > I've never run Xirrus personally, but I think they were used for the > > last NANOG conference. > > and how did that work out? [ though i do not know it was the xirrus > units ] > > randy > -- 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 mike.lyon at gmail.com Sat Jun 20 23:04:08 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Sat, 20 Jun 2015 16:04:08 -0700 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: Ive used Xirrus for a few festivals and hack-a-thons and they worked great. Ive also used UBNT UniFi with great success at numerous events, mainly at the old SF Mint (completely made out of Granite and concrete) and RF penetration was awesome. Cisco is nothing to write home about and is over priced. Ive never used Ruckus but it looks to be expensive for what it does. I'd stick with UBNT and Xirrus. -Mike On Jun 20, 2015 3:55 PM, "Ray Soucy" wrote: > I've actually never made it out to a NANOG conference, so I'm not sure. I > was just told this by peers who attended. > > On Sat, Jun 20, 2015 at 5:31 PM, Randy Bush wrote: > > > > I've never run Xirrus personally, but I think they were used for the > > > last NANOG conference. > > > > and how did that work out? [ though i do not know it was the xirrus > > units ] > > > > randy > > > > > > -- > 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 jra at baylink.com Sat Jun 20 23:06:29 2015 From: jra at baylink.com (Jay Ashworth) Date: Sat, 20 Jun 2015 19:06:29 -0400 (EDT) Subject: REMINDER: LEAP SECOND In-Reply-To: <63652.1434840242@turing-police.cc.vt.edu> Message-ID: <22608028.149.1434841589188.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Sat, 20 Jun 2015 11:32:53 -0400, Jay Ashworth said: > > ----- Original Message ----- > > > > > - use the posix-right timezone files > > > > What; not posixly-correct? > > I wonder how many of us are old enough to remember what that environment > variable *used* to be called before political correctness became > important. There are so many layers in that observation that I'm lost. Was posixly-correct a purposeful pun on politically correct, and I've missed it all these decades? Or was it named something else earlier than that, which wasn't itself politically correct? 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 randy at psg.com Sat Jun 20 23:12:46 2015 From: randy at psg.com (Randy Bush) Date: Sun, 21 Jun 2015 08:12:46 +0900 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: > Ive also used UBNT UniFi with great success at numerous events, mainly > at the old SF Mint (completely made out of Granite and concrete) and > RF penetration was awesome. 'fess up. it worked because of bluebottle next door randy From randy at psg.com Sat Jun 20 23:20:33 2015 From: randy at psg.com (Randy Bush) Date: Sun, 21 Jun 2015 08:20:33 +0900 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: > Ive used Xirrus for a few festivals and hack-a-thons and they worked great. > > Ive also used UBNT UniFi with great success at numerous events, mainly at > the old SF Mint (completely made out of Granite and concrete) and RF > penetration was awesome. > > Cisco is nothing to write home about and is over priced. Ive never used > Ruckus but it looks to be expensive for what it does. > > I'd stick with UBNT and Xirrus. having been in the back seat for many deployments over the years with all sorts of kit, i have seen great and reliable pretty large deployments of all of the above (well, xirrus only once). i have seen embarrassing messes with all of the above. i have concluded that the critical component is the engineer. randy From jameshartig at gmail.com Sat Jun 20 23:27:32 2015 From: jameshartig at gmail.com (James Hartig) Date: Sat, 20 Jun 2015 19:27:32 -0400 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> Message-ID: > The thing you need to watch out for with Ubiquiti is that they don't > support DFS, so the entire U-NII-2 channel space is off limits for 5 GHz. The UniFi UAP-AC unit has not been cleared for DFS but looks like the UAP Outdoor has. I own a few UAP-AC v2's and I can confirm with the latest firmware (3.2.12) there is no support for DFS channels. Source: https://community.ubnt.com/t5/UniFi-Wireless/DFS/td-p/697319 -- James Hartig From jared at puck.nether.net Sun Jun 21 00:02:27 2015 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 20 Jun 2015 20:02:27 -0400 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> On Jun 20, 2015, at 5:31 PM, Randy Bush wrote: >> I've never run Xirrus personally, but I think they were used for the >> last NANOG conference. > > and how did that work out? [ though i do not know it was the xirrus > units ] My understanding is that the most recent NANOG had issues with clients picking channels sequentially vs by signal strength. There may have been other issues but when all devices use 149 because that's the first they can and they get link that's not good. If people know of tricks to solve this when there are 600-1000 devices per room i am certain the NANOG eng team would love to know about it. -jared From jared at puck.nether.net Sun Jun 21 00:05:51 2015 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 20 Jun 2015 20:05:51 -0400 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> Message-ID: On Jun 20, 2015, at 7:27 PM, James Hartig wrote: >> The thing you need to watch out for with Ubiquiti is that they don't >> support DFS, so the entire U-NII-2 channel space is off limits for 5 GHz. > > The UniFi UAP-AC unit has not been cleared for DFS but looks like the UAP > Outdoor has. I own a few UAP-AC v2's and I can confirm with the latest > firmware (3.2.12) there is no support for DFS channels. > > Source: https://community.ubnt.com/t5/UniFi-Wireless/DFS/td-p/697319 UBNT went through much of 2013-2015 without many devices passing tests outside the ISM band. They seem to have changed who they do testing with, and combined with the rule changes at the FCC and correspondingly IC they were not equipped to handle that until this year it seems. They still have a huge backlog of DFS certifications which seem to be slowly getting approved as they pass testing. - Jared From nanog at ics-il.net Sun Jun 21 01:50:40 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 20 Jun 2015 20:50:40 -0500 (CDT) Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: Message-ID: <21106950.699.1434851413949.JavaMail.mhammett@ThunderFuck> They've been getting 5150 - 5250 approval. DFS, IIRC, has yet to happen. Well, in their AirMax line, of which the UniFi will be similar internally. They didn't have any problem with their airFiber line, which is completely FPGA. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" To: "James Hartig" Cc: "NANOG list" Sent: Saturday, June 20, 2015 7:05:51 PM Subject: Re: Whats' a good product for a high-density Wireless network setup? On Jun 20, 2015, at 7:27 PM, James Hartig wrote: >> The thing you need to watch out for with Ubiquiti is that they don't >> support DFS, so the entire U-NII-2 channel space is off limits for 5 GHz. > > The UniFi UAP-AC unit has not been cleared for DFS but looks like the UAP > Outdoor has. I own a few UAP-AC v2's and I can confirm with the latest > firmware (3.2.12) there is no support for DFS channels. > > Source: https://community.ubnt.com/t5/UniFi-Wireless/DFS/td-p/697319 UBNT went through much of 2013-2015 without many devices passing tests outside the ISM band. They seem to have changed who they do testing with, and combined with the rule changes at the FCC and correspondingly IC they were not equipped to handle that until this year it seems. They still have a huge backlog of DFS certifications which seem to be slowly getting approved as they pass testing. - Jared From randy at psg.com Sun Jun 21 04:32:38 2015 From: randy at psg.com (Randy Bush) Date: Sun, 21 Jun 2015 13:32:38 +0900 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> Message-ID: > My understanding is that the most recent NANOG had issues with clients > picking channels sequentially vs by signal strength. There may have > been other issues but when all devices use 149 because that's the > first they can and they get link that's not good. > > If people know of tricks to solve this when there are 600-1000 devices > per room i am certain the NANOG eng team would love to know about it. not really; they're in denial. why did san antonio work; the only nanog in 4 or more which did? why does ietf work? wireless is ugly. few know how to deploy at scale. it's just not easy. randy From brez at brezworks.com Sun Jun 21 04:53:58 2015 From: brez at brezworks.com (Jeremy Bresley) Date: Sat, 20 Jun 2015 23:53:58 -0500 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> Message-ID: <55864366.3070504@brezworks.com> On 6/20/2015 11:32 PM, Randy Bush wrote: >> My understanding is that the most recent NANOG had issues with clients >> picking channels sequentially vs by signal strength. There may have >> been other issues but when all devices use 149 because that's the >> first they can and they get link that's not good. >> >> If people know of tricks to solve this when there are 600-1000 devices >> per room i am certain the NANOG eng team would love to know about it. > not really; they're in denial. why did san antonio work; the only nanog > in 4 or more which did? why does ietf work? > > wireless is ugly. few know how to deploy at scale. it's just not easy. > > randy If people are curious what Cisco does for their 3x a year Cisco Live events (last week in San Diego there was 35TB of data transferred over that network), there's a panel discussion about how they deploy things and what tools they use for it. https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76483&backBtn=true That's the session from Milan 2014, may require a free account to view the slides and video. The session from San Diego is at https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=83806&backBtn=true Doesn't look like they've finalized the slides and video for that session yet though. In Milan they deployed 325 APs across 6 controllers (3 HA pairs). From experience at the US Live events, there's 10-15K people in the main hall during keynotes, there's probably close to 100 APs in that room alone with the stadium antennas for the density needed. There's a LOT of people trying to tweet during and this year periscope the keynote speeches. If people are interested, I know a couple of the Cisco folks tend to lurk on this and other lists and can probably provide more details if asked nicely. Jeremy "TheBrez" Bresley brez at brezworks.com From randy at psg.com Sun Jun 21 05:28:40 2015 From: randy at psg.com (Randy Bush) Date: Sun, 21 Jun 2015 14:28:40 +0900 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> Message-ID: > My understanding is that the most recent NANOG had issues with clients > picking channels sequentially vs by signal strength. There may have > been other issues but when all devices use 149 because that's the > first they can and they get link that's not good. we're lucky those mean vicious bad clients don't also come to ietf, wwdc, crisco live, ... oh wait ... you are blaming the customer as if you worked for a telco. oh wait ... :) > If people know of tricks to solve this when there are 600-1000 devices > per room i am certain the NANOG eng team would love to know about it. clue: with 600-1000 geeks there are gonna be 2k-4k devices. randy From Valdis.Kletnieks at vt.edu Sun Jun 21 06:06:08 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 21 Jun 2015 02:06:08 -0400 Subject: REMINDER: LEAP SECOND In-Reply-To: Your message of "Sat, 20 Jun 2015 19:06:29 -0400." <22608028.149.1434841589188.JavaMail.root@benjamin.baylink.com> References: <22608028.149.1434841589188.JavaMail.root@benjamin.baylink.com> Message-ID: <92255.1434866768@turing-police.cc.vt.edu> On Sat, 20 Jun 2015 19:06:29 -0400, Jay Ashworth said: > ----- Original Message ----- > > From: "Valdis Kletnieks" > > I wonder how many of us are old enough to remember what that environment > > variable *used* to be called before political correctness became > > important. > > There are so many layers in that observation that I'm lost. > > Was posixly-correct a purposeful pun on politically correct, and I've > missed it all these decades? > > Or was it named something else earlier than that, which wasn't itself > politically correct? I'll let the perpetrator, Richard Stallman, explain. It was a kerfluffle regarding whether /bin/du should use units of 1,000 or 1024. http://karmak.org/archive/2003/01/12-14-99.epl.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From eyeronic.design at gmail.com Sun Jun 21 06:41:12 2015 From: eyeronic.design at gmail.com (Mike Hale) Date: Sat, 20 Jun 2015 23:41:12 -0700 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> Message-ID: So....ultimately, what's the answer? A huge number of low cost, low power WAPs? Eager readers want to know. :) On Jun 20, 2015 10:30 PM, "Randy Bush" wrote: > > My understanding is that the most recent NANOG had issues with clients > > picking channels sequentially vs by signal strength. There may have > > been other issues but when all devices use 149 because that's the > > first they can and they get link that's not good. > > we're lucky those mean vicious bad clients don't also come to ietf, > wwdc, crisco live, ... oh wait ... > > you are blaming the customer as if you worked for a telco. oh wait ... > :) > > > If people know of tricks to solve this when there are 600-1000 devices > > per room i am certain the NANOG eng team would love to know about it. > > clue: with 600-1000 geeks there are gonna be 2k-4k devices. > > randy > From randy at psg.com Sun Jun 21 06:45:27 2015 From: randy at psg.com (Randy Bush) Date: Sun, 21 Jun 2015 15:45:27 +0900 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> Message-ID: > So....ultimately, what's the answer? A huge number of low cost, low > power WAPs? Eager readers want to know. :) what was unclear about the following? Randy Bush wrote: > From: Randy Bush > Subject: Re: Whats' a good product for a high-density Wireless network setup? > To: Mike Lyon > Cc: North American Network Operators' Group > Date: Sun, 21 Jun 2015 08:20:33 +0900 > ... > having been in the back seat for many deployments over the years with > all sorts of kit, i have seen great and reliable pretty large > deployments of all of the above (well, xirrus only once). i have seen > embarrassing messes with all of the above. i have concluded that the > critical component is the engineer. From eyeronic.design at gmail.com Sun Jun 21 06:50:04 2015 From: eyeronic.design at gmail.com (Mike Hale) Date: Sat, 20 Jun 2015 23:50:04 -0700 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> Message-ID: A lot. It's a good point, but not very helpful to those engineers trying to design said infrastructure. On Jun 20, 2015 11:45 PM, "Randy Bush" wrote: > > So....ultimately, what's the answer? A huge number of low cost, low > > power WAPs? Eager readers want to know. :) > > what was unclear about the following? > > Randy Bush wrote: > > From: Randy Bush > > Subject: Re: Whats' a good product for a high-density Wireless network > setup? > > To: Mike Lyon > > Cc: North American Network Operators' Group > > Date: Sun, 21 Jun 2015 08:20:33 +0900 > > ... > > having been in the back seat for many deployments over the years with > > all sorts of kit, i have seen great and reliable pretty large > > deployments of all of the above (well, xirrus only once). i have seen > > embarrassing messes with all of the above. i have concluded that the > > critical component is the engineer. > From mike.lyon at gmail.com Sun Jun 21 06:56:49 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Sat, 20 Jun 2015 23:56:49 -0700 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> Message-ID: Waaay to many variables to answer the question. Each deployment is different and requires proper engineering and experience... -Mike On Sat, Jun 20, 2015 at 11:50 PM, Mike Hale wrote: > A lot. It's a good point, but not very helpful to those engineers trying > to design said infrastructure. > On Jun 20, 2015 11:45 PM, "Randy Bush" wrote: > > > > So....ultimately, what's the answer? A huge number of low cost, low > > > power WAPs? Eager readers want to know. :) > > > > what was unclear about the following? > > > > Randy Bush wrote: > > > From: Randy Bush > > > Subject: Re: Whats' a good product for a high-density Wireless network > > setup? > > > To: Mike Lyon > > > Cc: North American Network Operators' Group > > > Date: Sun, 21 Jun 2015 08:20:33 +0900 > > > ... > > > having been in the back seat for many deployments over the years with > > > all sorts of kit, i have seen great and reliable pretty large > > > deployments of all of the above (well, xirrus only once). i have seen > > > embarrassing messes with all of the above. i have concluded that the > > > critical component is the engineer. > > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From dave.taht at gmail.com Sun Jun 21 07:00:45 2015 From: dave.taht at gmail.com (Dave Taht) Date: Sun, 21 Jun 2015 00:00:45 -0700 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> Message-ID: On Sat, Jun 20, 2015 at 11:45 PM, Randy Bush wrote: >> So....ultimately, what's the answer? A huge number of low cost, low >> power WAPs? Eager readers want to know. :) > > what was unclear about the following? +1 > Randy Bush wrote: >> From: Randy Bush >> Subject: Re: Whats' a good product for a high-density Wireless network setup? >> To: Mike Lyon >> Cc: North American Network Operators' Group >> Date: Sun, 21 Jun 2015 08:20:33 +0900 >> ... >> having been in the back seat for many deployments over the years with >> all sorts of kit, i have seen great and reliable pretty large >> deployments of all of the above (well, xirrus only once). i have seen >> embarrassing messes with all of the above. i have concluded that the >> critical component is the engineer. It is totally possible to build a good wifi setup if you know what you're doing. David Lang regularly builds a good setup out of commodity parts and openwrt at SCALE, and talks to the basic issues here: https://www.usenix.org/system/files/conference/lisa12/lisa12-final-32.pdf I wish we had more clued people working on wifi. And that conference organizers/hotels/corps/institutions realized that having people that knew what they were doing on the wifi was a valuable service for geeky conferences, at least. SCALE2015 went excellently, I'm told. I have some measurements of the nanog network from the SF conference this past month. pretty terrrible... -- Dave T?ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From mysidia at gmail.com Sun Jun 21 07:02:47 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 21 Jun 2015 02:02:47 -0500 Subject: REMINDER: LEAP SECOND In-Reply-To: <92255.1434866768@turing-police.cc.vt.edu> References: <22608028.149.1434841589188.JavaMail.root@benjamin.baylink.com> <92255.1434866768@turing-police.cc.vt.edu> Message-ID: On Sun, Jun 21, 2015 at 1:06 AM, wrote: > On Sat, 20 Jun 2015 19:06:29 -0400, Jay Ashworth said: [snip] > I'll let the perpetrator, Richard Stallman, explain. It was a kerfluffle > regarding whether /bin/du should use units of 1,000 or 1024. > > http://karmak.org/archive/2003/01/12-14-99.epl.html It's not 1024 vs 1000; it's 1024 vs 512. If it's "du" or "df"; the display is supposed to be the number of 512-Byte blocks..... Thankfully, the -k and -g options were added to display in Kilobyte or Gigabyte units which are more human understandable and familiar. Some of the GNU utilities play fast and loose on the spec and default to 1024-byte blocks. If you set POSIXLY_CORRECT in the environment, they will show in 512 byte blocks, or the disk sector size in bytes, instead, like they are "supposed to" -- -JH From mike.lyon at gmail.com Sun Jun 21 07:04:04 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Sun, 21 Jun 2015 00:04:04 -0700 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> Message-ID: What gear was used at the last NANOG in SF? Was it indeed Xirrus? -Mike On Sun, Jun 21, 2015 at 12:00 AM, Dave Taht wrote: > On Sat, Jun 20, 2015 at 11:45 PM, Randy Bush wrote: > >> So....ultimately, what's the answer? A huge number of low cost, low > >> power WAPs? Eager readers want to know. :) > > > > what was unclear about the following? > > +1 > > > Randy Bush wrote: > >> From: Randy Bush > >> Subject: Re: Whats' a good product for a high-density Wireless network > setup? > >> To: Mike Lyon > >> Cc: North American Network Operators' Group > >> Date: Sun, 21 Jun 2015 08:20:33 +0900 > >> ... > >> having been in the back seat for many deployments over the years with > >> all sorts of kit, i have seen great and reliable pretty large > >> deployments of all of the above (well, xirrus only once). i have seen > >> embarrassing messes with all of the above. i have concluded that the > >> critical component is the engineer. > > It is totally possible to build a good wifi setup if you know what > you're doing. > > David Lang regularly builds a good setup out of commodity parts and > openwrt at SCALE, and talks to the basic issues here: > > https://www.usenix.org/system/files/conference/lisa12/lisa12-final-32.pdf > > I wish we had more clued people working on wifi. And that conference > organizers/hotels/corps/institutions realized that having people that > knew what they were doing on the wifi was a valuable service for geeky > conferences, at least. > > SCALE2015 went excellently, I'm told. > > I have some measurements of the nanog network from the SF conference > this past month. pretty terrrible... > > -- > Dave T?ht > worldwide bufferbloat report: > http://www.dslreports.com/speedtest/results/bufferbloat > And: > What will it take to vastly improve wifi for everyone? > https://plus.google.com/u/0/explore/makewififast > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From randy at psg.com Sun Jun 21 07:05:09 2015 From: randy at psg.com (Randy Bush) Date: Sun, 21 Jun 2015 16:05:09 +0900 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> Message-ID: > What gear was used at the last NANOG in SF? Was it indeed Xirrus? yes. but i would not blame the gear From dave.taht at gmail.com Sun Jun 21 07:17:59 2015 From: dave.taht at gmail.com (Dave Taht) Date: Sun, 21 Jun 2015 00:17:59 -0700 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> Message-ID: On Sun, Jun 21, 2015 at 12:05 AM, Randy Bush wrote: >> What gear was used at the last NANOG in SF? Was it indeed Xirrus? > > yes. but i would not blame the gear I would blame some of the gear. Very bad bufferbloat (up to 1.5 sec of latency) on the download direction. http://snapon.lab.bufferbloat.net/~d/nanog/nanog_down.png More flent.org data in that dir for your bemusement. -- Dave T?ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From randy at psg.com Sun Jun 21 08:46:41 2015 From: randy at psg.com (Randy Bush) Date: Sun, 21 Jun 2015 17:46:41 +0900 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> Message-ID: > What you need is more APs running at lower poer levels to cover > smaller areas, spread out around the room. lots of other trix. some of which i have seen are o pull the asians off on to one or more channel 14 aps (but that's old 11b days). o set the aps low so the wetware attenuates but i am not an expert; i just try to work with folk who are and get the hell out of their way and see that they are well supplied with coffee, food, and beer. randy From list at satchell.net Sun Jun 21 09:17:58 2015 From: list at satchell.net (Stephen Satchell) Date: Sun, 21 Jun 2015 02:17:58 -0700 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> Message-ID: <55868146.1080006@satchell.net> On 06/20/2015 11:56 PM, Mike Lyon wrote: > Waaay to many variables to answer the question. Each deployment is > different and requires proper engineering and experience... And a good description of the problem, too, as I learned the hard way trying to work with the IT people for a Ruckus installation at a convention hotel. They just couldn't believe that 300 people could max out their system when congregated into the main meeting room with two (2) access points. They had "Bill Gates Syndrome": no group will ever exceed 1000 devices. (cf: "No one will ever need more than 640KB of DRAM") Last year, the group AVERAGED four devices each. The problem didn't abate when the group spread out throughout the hotel, either. Just the symptoms changed. From jared at puck.nether.net Sun Jun 21 11:40:29 2015 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 21 Jun 2015 07:40:29 -0400 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> Message-ID: <39FDC5FD-224F-4247-86D2-1D640F255014@puck.nether.net> > On Jun 21, 2015, at 1:28 AM, Randy Bush wrote: > >> My understanding is that the most recent NANOG had issues with clients >> picking channels sequentially vs by signal strength. There may have >> been other issues but when all devices use 149 because that's the >> first they can and they get link that's not good. > > we're lucky those mean vicious bad clients don't also come to ietf, > wwdc, crisco live, ... oh wait ? I?ll say the difference about IETF is a lot more planning goes into it. The people are on-site much earlier than for a NANOG and there are few last minute rushes. While there are larger plenary meetings at IETF, most are in smaller rooms but are packed with chairs and laptops/devices. > you are blaming the customer as if you worked for a telco. oh wait ... > :) Duh. Always blame the customer, step 1 success. step2 (vendor/cisco tac): have you tried turning it on and off again? step3 maybe it?s fixed in the latest code >> If people know of tricks to solve this when there are 600-1000 devices >> per room i am certain the NANOG eng team would love to know about it. > > clue: with 600-1000 geeks there are gonna be 2k-4k devices. Yup. This is a given. - Jared From rs at seastrom.com Sun Jun 21 13:32:01 2015 From: rs at seastrom.com (Rob Seastrom) Date: Sun, 21 Jun 2015 09:32:01 -0400 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: <55868146.1080006@satchell.net> (Stephen Satchell's message of "Sun, 21 Jun 2015 02:17:58 -0700") References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> <55868146.1080006@satchell.net> Message-ID: <861th5uqzy.fsf@valhalla.seastrom.com> Stephen Satchell writes: > ... They just couldn't believe that 300 people could max out their system > ... > Last year, the group AVERAGED four devices each. A *camping* event that I go to, that is by and large not a technology-oriented consituency, averaged 2.6 devices per attendee. -r From jra at baylink.com Sun Jun 21 14:21:48 2015 From: jra at baylink.com (Jay Ashworth) Date: Sun, 21 Jun 2015 10:21:48 -0400 (EDT) Subject: REMINDER: LEAP SECOND In-Reply-To: Message-ID: <14339715.159.1434896508513.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > On Sun, Jun 21, 2015 at 1:06 AM, wrote: > > On Sat, 20 Jun 2015 19:06:29 -0400, Jay Ashworth said: > [snip] > > I'll let the perpetrator, Richard Stallman, explain. It was a > > kerfluffle > > regarding whether /bin/du should use units of 1,000 or 1024. > > > > http://karmak.org/archive/2003/01/12-14-99.epl.html > > It's not 1024 vs 1000; it's 1024 vs 512. > > If it's "du" or "df"; the display is supposed to be the number of > 512-Byte blocks..... [ ... ] > If you set POSIXLY_CORRECT in the environment, they will show in 512 > byte blocks, or the disk sector size in bytes, instead, like they > are "supposed to" Yes, but Valdis' "politically correct" reference goes to the original name of the environment variable, which I once knew, but had forgotten, was POSIX_ME_HARDER. 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 rafael at gav.ufsc.br Sun Jun 21 14:37:39 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sun, 21 Jun 2015 09:37:39 -0500 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: <861th5uqzy.fsf@valhalla.seastrom.com> References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <76FFD72B-0295-4CB3-A685-C004315A9273@puck.nether.net> <55868146.1080006@satchell.net> <861th5uqzy.fsf@valhalla.seastrom.com> Message-ID: No wonder IPv4 is depleted. People's shoes have a MAC address nowadays... On Sun, Jun 21, 2015 at 8:32 AM, Rob Seastrom wrote: > > Stephen Satchell writes: > > > ... They just couldn't believe that 300 people could max out their system > > ... > > Last year, the group AVERAGED four devices each. > > A *camping* event that I go to, that is by and large not a > technology-oriented consituency, averaged 2.6 devices per > attendee. > > -r > > From hbf9121 at hotmail.com Sat Jun 20 16:06:04 2015 From: hbf9121 at hotmail.com (Mitch Howards) Date: Sat, 20 Jun 2015 12:06:04 -0400 Subject: Data Center Network Monitoring with TAPs Message-ID: Hello All, Was wondering what folks are using to monitor traffic on their networks. Looking into Ixia and APCON devices for dedup and other filtering features as well as passive fiber TAPs to capture the traffic. How are folks handling TAP'ing large data center networks? TAPs at the "distribution layer" would be the best fit for my network but that would require a ton of passive fiber TAPs for the incoming fibers to the distribution switches. The end goal is to not only capture the north-south traffic on the network but also east-west traffic. It seems more efficient to just use SPANs but there are many limitations using SPANs. Thanks in advance for any suggestions. Mitch From jtodd at loligo.com Sat Jun 20 17:51:19 2015 From: jtodd at loligo.com (John Todd) Date: Sat, 20 Jun 2015 10:51:19 -0700 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> Message-ID: <51838073-F790-46F2-BDC6-EB783501B69F@loligo.com> On 20 Jun 2015, at 9:37, Sina Owolabi wrote: > I'd be grateful for any information on how to calculate for large > scale > wifi deployment [snip] While it is vendor specific (and therefore subject to certain biases) I?ve found the Aruba VRD (Validated Reference Design) documentation fairly clear and applicable to many high-density environments. It covers theory, planning, and engineering. http://community.arubanetworks.com/t5/Validated-Reference-Design/Very-High-Density-802-11ac-Networks-Validated-Reference-Design/ta-p/230891 I?m certain that Cisco, Xirrus, Ruckus, Ubiquiti, Areohive, etc. also have papers on the topic that (hopefully) have the same basic theory concepts applied to their specific configuration syntax and special sauces. I?ve had good experiences with Aruba with high-density auditorium usage on several occasions, though I tend to turn off some of the proprietary features to keep things simple. There are also some less-formal slide decks on the same topic from Aruba that are a bit redundant but more conversational: http://www.wlanpros.com/wp-content/uploads/2014/03/Ultra-High-Density-WLAN-Design-Deployment-Chuck-Lukaszewski.pdf http://community.arubanetworks.com/aruba/attachments/aruba/tkb at tkb/86/3/2012%20AH%20Vegas%20-%20WLAN%20Design%20for%20High%20Density.pdf JT From mike.lyon at gmail.com Mon Jun 22 05:02:37 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Sun, 21 Jun 2015 22:02:37 -0700 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: <51838073-F790-46F2-BDC6-EB783501B69F@loligo.com> References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <51838073-F790-46F2-BDC6-EB783501B69F@loligo.com> Message-ID: And Aruba also did a kick-ass wireless installation at the new Levi's Stadium in Santa Clara. Here is a White Paper on it: http://arubanetworks.com/wp-content/uploads/stadiumRFfund.pdf -Mike On Sat, Jun 20, 2015 at 10:51 AM, John Todd wrote: > > On 20 Jun 2015, at 9:37, Sina Owolabi wrote: > > I'd be grateful for any information on how to calculate for large scale >> wifi deployment >> > [snip] > > > While it is vendor specific (and therefore subject to certain biases) I?ve > found the Aruba VRD (Validated Reference Design) documentation fairly clear > and applicable to many high-density environments. It covers theory, > planning, and engineering. > > > http://community.arubanetworks.com/t5/Validated-Reference-Design/Very-High-Density-802-11ac-Networks-Validated-Reference-Design/ta-p/230891 > > I?m certain that Cisco, Xirrus, Ruckus, Ubiquiti, Areohive, etc. also have > papers on the topic that (hopefully) have the same basic theory concepts > applied to their specific configuration syntax and special sauces. I?ve > had good experiences with Aruba with high-density auditorium usage on > several occasions, though I tend to turn off some of the proprietary > features to keep things simple. > > There are also some less-formal slide decks on the same topic from Aruba > that are a bit redundant but more conversational: > > > http://www.wlanpros.com/wp-content/uploads/2014/03/Ultra-High-Density-WLAN-Design-Deployment-Chuck-Lukaszewski.pdf > > http://community.arubanetworks.com/aruba/attachments/aruba/tkb at tkb/86/3/2012%20AH%20Vegas%20-%20WLAN%20Design%20for%20High%20Density.pdf > > JT > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From mel at beckman.org Mon Jun 22 05:04:19 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 22 Jun 2015 05:04:19 +0000 Subject: Data Center Network Monitoring with TAPs In-Reply-To: References: Message-ID: <62119928-F855-49D0-A370-5A86B59D1E30@beckman.org> Ultimately this is one of the things that SDN schemes such as OpenFlow bring a data center for free. Distributed flow statistics collection through OenFlow's extensible infrastructure gives you a huge range of reporting and analysis capabilities, with no taps needed. Every network port is in essence a tap. Here's an interesting paper on one open source OF tool: https://www.nas.ewi.tudelft.nl/people/Fernando/papers/MonitoringOpenFlow.pdf -mel beckman > On Jun 21, 2015, at 9:50 PM, Mitch Howards wrote: > > Hello All, > > Was wondering what folks are using to monitor traffic > on their networks. Looking into Ixia and APCON devices for dedup and > other filtering features as well as passive fiber TAPs to capture the > traffic. > > How are folks handling TAP'ing large data center > networks? TAPs at the "distribution layer" would be the best fit for my > network but that would require a ton of passive fiber TAPs for the > incoming fibers to the distribution switches. The end goal is to not > only capture the north-south traffic on the network but also east-west > traffic. It seems more efficient to just use SPANs but there are many > limitations using SPANs. > > Thanks in advance for any suggestions. > > Mitch From mel at beckman.org Mon Jun 22 05:08:29 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 22 Jun 2015 05:08:29 +0000 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <51838073-F790-46F2-BDC6-EB783501B69F@loligo.com>, Message-ID: <7BCFCB80-28EB-4F14-AC81-B7A74FA4F54F@beckman.org> I recently visited that installation. It's quite impressive and we are employing the "down-low" AP placement strategy on another high density project. The scheme uses human RF attenuation to enable closer AP spacing, which in turn supports a higher channel re-use ratio. -mel beckman > On Jun 21, 2015, at 10:03 PM, Mike Lyon wrote: > > And Aruba also did a kick-ass wireless installation at the new Levi's > Stadium in Santa Clara. Here is a White Paper on it: > > http://arubanetworks.com/wp-content/uploads/stadiumRFfund.pdf > > -Mike > > >> On Sat, Jun 20, 2015 at 10:51 AM, John Todd wrote: >> >> >> On 20 Jun 2015, at 9:37, Sina Owolabi wrote: >> >> I'd be grateful for any information on how to calculate for large scale >>> wifi deployment >>> >> [snip] >> >> >> While it is vendor specific (and therefore subject to certain biases) I?ve >> found the Aruba VRD (Validated Reference Design) documentation fairly clear >> and applicable to many high-density environments. It covers theory, >> planning, and engineering. >> >> >> http://community.arubanetworks.com/t5/Validated-Reference-Design/Very-High-Density-802-11ac-Networks-Validated-Reference-Design/ta-p/230891 >> >> I?m certain that Cisco, Xirrus, Ruckus, Ubiquiti, Areohive, etc. also have >> papers on the topic that (hopefully) have the same basic theory concepts >> applied to their specific configuration syntax and special sauces. I?ve >> had good experiences with Aruba with high-density auditorium usage on >> several occasions, though I tend to turn off some of the proprietary >> features to keep things simple. >> >> There are also some less-formal slide decks on the same topic from Aruba >> that are a bit redundant but more conversational: >> >> >> http://www.wlanpros.com/wp-content/uploads/2014/03/Ultra-High-Density-WLAN-Design-Deployment-Chuck-Lukaszewski.pdf >> >> http://community.arubanetworks.com/aruba/attachments/aruba/tkb at tkb/86/3/2012%20AH%20Vegas%20-%20WLAN%20Design%20for%20High%20Density.pdf >> >> JT >> > > > > -- > Mike Lyon > 408-621-4826 > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon From mike.lyon at gmail.com Mon Jun 22 05:12:58 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Sun, 21 Jun 2015 22:12:58 -0700 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: <7BCFCB80-28EB-4F14-AC81-B7A74FA4F54F@beckman.org> References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <51838073-F790-46F2-BDC6-EB783501B69F@loligo.com> <7BCFCB80-28EB-4F14-AC81-B7A74FA4F54F@beckman.org> Message-ID: They also have an awesome DAS installation there as well. On Sun, Jun 21, 2015 at 10:08 PM, Mel Beckman wrote: > I recently visited that installation. It's quite impressive and we are > employing the "down-low" AP placement strategy on another high density > project. The scheme uses human RF attenuation to enable closer AP spacing, > which in turn supports a higher channel re-use ratio. > > -mel beckman > > > On Jun 21, 2015, at 10:03 PM, Mike Lyon wrote: > > > > And Aruba also did a kick-ass wireless installation at the new Levi's > > Stadium in Santa Clara. Here is a White Paper on it: > > > > http://arubanetworks.com/wp-content/uploads/stadiumRFfund.pdf > > > > -Mike > > > > > >> On Sat, Jun 20, 2015 at 10:51 AM, John Todd wrote: > >> > >> > >> On 20 Jun 2015, at 9:37, Sina Owolabi wrote: > >> > >> I'd be grateful for any information on how to calculate for large scale > >>> wifi deployment > >>> > >> [snip] > >> > >> > >> While it is vendor specific (and therefore subject to certain biases) > I?ve > >> found the Aruba VRD (Validated Reference Design) documentation fairly > clear > >> and applicable to many high-density environments. It covers theory, > >> planning, and engineering. > >> > >> > >> > http://community.arubanetworks.com/t5/Validated-Reference-Design/Very-High-Density-802-11ac-Networks-Validated-Reference-Design/ta-p/230891 > >> > >> I?m certain that Cisco, Xirrus, Ruckus, Ubiquiti, Areohive, etc. also > have > >> papers on the topic that (hopefully) have the same basic theory concepts > >> applied to their specific configuration syntax and special sauces. I?ve > >> had good experiences with Aruba with high-density auditorium usage on > >> several occasions, though I tend to turn off some of the proprietary > >> features to keep things simple. > >> > >> There are also some less-formal slide decks on the same topic from Aruba > >> that are a bit redundant but more conversational: > >> > >> > >> > http://www.wlanpros.com/wp-content/uploads/2014/03/Ultra-High-Density-WLAN-Design-Deployment-Chuck-Lukaszewski.pdf > >> > >> > http://community.arubanetworks.com/aruba/attachments/aruba/tkb at tkb/86/3/2012%20AH%20Vegas%20-%20WLAN%20Design%20for%20High%20Density.pdf > >> > >> JT > >> > > > > > > > > -- > > Mike Lyon > > 408-621-4826 > > mike.lyon at gmail.com > > > > http://www.linkedin.com/in/mlyon > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From notify.sina at gmail.com Mon Jun 22 05:39:49 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Mon, 22 Jun 2015 05:39:49 +0000 Subject: Help Needed Converting KVM network Non-VLAN network to VLANs, odd Message-ID: Hi! I apologize if this is not something I should have posted here, but I've come to value the insights and experience of the people on this list a lot, and I am hoping my problem isn't unique. I am also sorry for the long read. I have been to the forums of the devices in play in this problem, and while Red Hat has been a huge help, they all hand off when they hear about the other devices in play. Some background: I have a Sophos UTM ASG220 serving as gateway device for a number of networks, with a Cisco 2960 network switch, and a raft of Red Hat 6.6 servers running KVM and hosting multiple guests, with the guests being on different network subnets. The UTM has its LAN interface populated with multiple virtual interfaces (its really a stripped down, optimized RHEL-type Linux machine under the hood) as gateways for all the network subnets except for the primary network it was created with during installation. I have VLANs defined on the switch, and the KVM hosts are having bonded interfaces (mode 1, based on RHN support advice), VLAN sub interfaces and bridges configured for each network, and each guest is attached to its appropriate bridge and 8021q is setup. Without involving the UTM, VLAN traffic transverses beautifully, between swich, KVM hosts and guests, I have no issues there That said, this is what is happening: I am successful in generating new VLAN interfaces on the Sophos UTM (but with a different IP address) to replace the existing gateway virtual IP address (for instance, for test network, virtual interface gateway address is 10.11.0.253, and the VLAN interface to replace it is 10.11.0.253). At first instance the guests and the kvm host are able to ping the switch, the newVLAN gateway interface and the old virtual gateway interface, after the VLAN is in place. But if I try to remove the old virtual interface (eg 10.11.0.253), then networking starts acting weird. The switch VLAN address (say 10.11.0.7) isunable toping or reach the guests (say 10.11.0.36) on the VLAN, but it can reach the kvm host vlan bridge (say 10.11.0.4) address, and it can reach the Sophos gateway (10.11.0.254,VLAN address). Even after bring the gateway virtual interface (10.11.0.253) back up the situation remainsfor a while. The guests can reach each other on the same VLAN, but cannot ping the switch VLAN interface address, and cannot ping their VLAN gateway address, or route traffic to other external networks). But the guests can reach the LAN DNS servers, which are ona different subnet entirely (192.168.2.0)! But theguests also can only reach the DNS servers on the 192.168.2.0 subnet, they cannot reach all the addresses. Arping responds to and from all network machines/devices while all this is going on. This continued for a while even after rebooting the switch, and bringing up and down the gateway network interfaces. Then suddenly things started working again (but with the gateway virtual and VLAN addresses both up).I am successful in generating anew VLAN interface (but with a different IP address) to replace the existing gateway virtual IP address (for instance, for test network, virtual interface gateway address is 10.11.0.253, and the VLAN interface to replace it is 10.11.0.253). At first instance the guests and the kvm host are able to ping the switch, the newVLAN gateway interface and the old virtual gateway interface, after the VLAN is in place. But if I try to remove the old virtual interface (eg 10.11.0.253), then networking starts acting weird. The switch VLAN address (say 10.11.0.7) isunable toping or reach the guests (say 10.11.0.36) on the VLAN, but it can reach the kvm host vlan bridge (say 10.11.0.4) address, and it can reach the gateway (10.11.0.254,VLAN address). Even after bringing the gateway virtual interface (10.11.0.253) back up the situation remains for a while. The guests can reach each other on the same VLAN, but cannot ping the switch VLAN interface address, and cannot ping their VLAN gateway address, or route traffic to other external networks). But the guests can reach the LAN DNS servers, which are on a different subnet entirely (192.168.2.0)! The guests also can only reach the DNS servers on the 192.168.2.0 subnet, they cannot reach all the addresses. Arping responds to and from all network machines/devices while all this is going on. This continued for a while even after clearing the arp-caches, rebooting the switch, and bringing up and down the gateway network interfaces. Then suddenly things started working again (but with the gateway virtual and VLAN addresses both up). I'd love some insight to what's happening and how I can fix this. From notify.sina at gmail.com Mon Jun 22 05:41:05 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Mon, 22 Jun 2015 05:41:05 +0000 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <51838073-F790-46F2-BDC6-EB783501B69F@loligo.com> <7BCFCB80-28EB-4F14-AC81-B7A74FA4F54F@beckman.org> Message-ID: This has all been a very huge help, and I am thankful for all the insights and reading material. I fee expert already! On Mon, Jun 22, 2015 at 6:14 AM Mike Lyon wrote: > They also have an awesome DAS installation there as well. > > On Sun, Jun 21, 2015 at 10:08 PM, Mel Beckman wrote: > > > I recently visited that installation. It's quite impressive and we are > > employing the "down-low" AP placement strategy on another high density > > project. The scheme uses human RF attenuation to enable closer AP > spacing, > > which in turn supports a higher channel re-use ratio. > > > > -mel beckman > > > > > On Jun 21, 2015, at 10:03 PM, Mike Lyon wrote: > > > > > > And Aruba also did a kick-ass wireless installation at the new Levi's > > > Stadium in Santa Clara. Here is a White Paper on it: > > > > > > http://arubanetworks.com/wp-content/uploads/stadiumRFfund.pdf > > > > > > -Mike > > > > > > > > >> On Sat, Jun 20, 2015 at 10:51 AM, John Todd wrote: > > >> > > >> > > >> On 20 Jun 2015, at 9:37, Sina Owolabi wrote: > > >> > > >> I'd be grateful for any information on how to calculate for large > scale > > >>> wifi deployment > > >>> > > >> [snip] > > >> > > >> > > >> While it is vendor specific (and therefore subject to certain biases) > > I?ve > > >> found the Aruba VRD (Validated Reference Design) documentation fairly > > clear > > >> and applicable to many high-density environments. It covers theory, > > >> planning, and engineering. > > >> > > >> > > >> > > > http://community.arubanetworks.com/t5/Validated-Reference-Design/Very-High-Density-802-11ac-Networks-Validated-Reference-Design/ta-p/230891 > > >> > > >> I?m certain that Cisco, Xirrus, Ruckus, Ubiquiti, Areohive, etc. also > > have > > >> papers on the topic that (hopefully) have the same basic theory > concepts > > >> applied to their specific configuration syntax and special sauces. > I?ve > > >> had good experiences with Aruba with high-density auditorium usage on > > >> several occasions, though I tend to turn off some of the proprietary > > >> features to keep things simple. > > >> > > >> There are also some less-formal slide decks on the same topic from > Aruba > > >> that are a bit redundant but more conversational: > > >> > > >> > > >> > > > http://www.wlanpros.com/wp-content/uploads/2014/03/Ultra-High-Density-WLAN-Design-Deployment-Chuck-Lukaszewski.pdf > > >> > > >> > > > http://community.arubanetworks.com/aruba/attachments/aruba/tkb at tkb/86/3/2012%20AH%20Vegas%20-%20WLAN%20Design%20for%20High%20Density.pdf > > >> > > >> JT > > >> > > > > > > > > > > > > -- > > > Mike Lyon > > > 408-621-4826 > > > mike.lyon at gmail.com > > > > > > http://www.linkedin.com/in/mlyon > > > > > > -- > Mike Lyon > 408-621-4826 > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon > From randy at psg.com Mon Jun 22 06:10:45 2015 From: randy at psg.com (Randy Bush) Date: Mon, 22 Jun 2015 15:10:45 +0900 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <51838073-F790-46F2-BDC6-EB783501B69F@loligo.com> <7BCFCB80-28EB-4F14-AC81-B7A74FA4F54F@beckman.org> Message-ID: > This has all been a very huge help, and I am thankful for all the > insights and reading material. I feel expert already! then you should be very scared randy, who has been doing it for years and knows he is a weenie From notify.sina at gmail.com Mon Jun 22 06:27:16 2015 From: notify.sina at gmail.com (Sina Owolabi) Date: Mon, 22 Jun 2015 06:27:16 +0000 Subject: Whats' a good product for a high-density Wireless network setup? In-Reply-To: References: <351960361.706272.1434762716457.JavaMail.zimbra@snappytelecom.net> <1411892749.707305.1434771365197.JavaMail.zimbra@snappytelecom.net> <51838073-F790-46F2-BDC6-EB783501B69F@loligo.com> <7BCFCB80-28EB-4F14-AC81-B7A74FA4F54F@beckman.org> Message-ID: Well now. Being scared is part of the insight :-) And until I see a "No!!! Don't do it!!" post... On Mon, Jun 22, 2015 at 7:10 AM Randy Bush wrote: > > This has all been a very huge help, and I am thankful for all the > > insights and reading material. I feel expert already! > > then you should be very scared > > randy, who has been doing it for years and knows he is a weenie > From rdobbins at arbor.net Mon Jun 22 07:36:34 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 22 Jun 2015 14:36:34 +0700 Subject: Data Center Network Monitoring with TAPs In-Reply-To: References: Message-ID: <03308BAF-884C-432A-B707-AFDE410D6828@arbor.net> On 20 Jun 2015, at 23:06, Mitch Howards wrote: > Was wondering what folks are using to monitor traffic on their > networks. Looking into Ixia and APCON devices for dedup and other > filtering features as well as passive fiber TAPs to capture the > traffic. Take a look at flow telemetry options you have for your IDC hardware - a combination of flow telemetry, plus the ability to divert traffic into an instrumented sinkhole for full packet-capture is something to consider. SPAN sessions count against your frames per-second budget; not recommended for serious, high-traffic applications. ----------------------------------- Roland Dobbins From dot at dotat.at Mon Jun 22 12:15:41 2015 From: dot at dotat.at (Tony Finch) Date: Mon, 22 Jun 2015 13:15:41 +0100 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> Message-ID: Harlan Stenn wrote: > It's a problem with POSIX, not UTC. > > UTC is monotonic. The problems are that UTC is unpredictable, and it breaks the standard labelling of points in time that was used for hundreds (arguably thousands) of years before 1972. Tony. -- f.anthony.n.finch http://dotat.at/ Irish Sea: Northwesterly 4 or 5, occasionally 6 at first, becoming variable 4. Slight or moderate. Mainly fair. Good. From bortzmeyer at nic.fr Mon Jun 22 12:27:18 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 22 Jun 2015 14:27:18 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> Message-ID: <20150622122718.GA10690@nic.fr> On Mon, Jun 22, 2015 at 01:15:41PM +0100, Tony Finch wrote a message of 15 lines which said: > The problems are that UTC is unpredictable, That's because the earth rotation is unpredictable. Any time based on this buggy planet's movements will be unpredictable. Let's patch it now! From bzeeb-lists at lists.zabbadoz.net Mon Jun 22 12:38:28 2015 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon, 22 Jun 2015 12:38:28 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150622122718.GA10690@nic.fr> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150622122718.GA10690@nic.fr> Message-ID: <8C40413B-B22C-4BCE-85D2-B4F93A233628@lists.zabbadoz.net> > On 22 Jun 2015, at 12:27 , Stephane Bortzmeyer wrote: > > On Mon, Jun 22, 2015 at 01:15:41PM +0100, > Tony Finch wrote > a message of 15 lines which said: > >> The problems are that UTC is unpredictable, > > That's because the earth rotation is unpredictable. Any time based on > this buggy planet's movements will be unpredictable. Let's patch it > now! So we need a new center of the universe and switch to stardate and thus solve the 32bit UNIX time problem for real this time? From bortzmeyer at nic.fr Mon Jun 22 12:44:15 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 22 Jun 2015 14:44:15 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: <8C40413B-B22C-4BCE-85D2-B4F93A233628@lists.zabbadoz.net> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150622122718.GA10690@nic.fr> <8C40413B-B22C-4BCE-85D2-B4F93A233628@lists.zabbadoz.net> Message-ID: <20150622124415.GA12276@nic.fr> On Mon, Jun 22, 2015 at 12:38:28PM +0000, Bjoern A. Zeeb wrote a message of 17 lines which said: > So we need a new center of the universe and switch to stardate and > thus solve the 32bit UNIX time problem for real this time? Or simply use TAI which is the obvious time reference for Internet devices. Using UTC in routers is madness. Routers and Internet servers should use TAI internally and use UTC only when communicating with humans (the inferior life form which crawls on the Earth surface and cares about things like whether the sun is high at noon, for outside picnics). From dot at dotat.at Mon Jun 22 12:55:20 2015 From: dot at dotat.at (Tony Finch) Date: Mon, 22 Jun 2015 13:55:20 +0100 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150622122718.GA10690@nic.fr> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150622122718.GA10690@nic.fr> Message-ID: Stephane Bortzmeyer wrote: > > That's because the earth rotation is unpredictable. Any time based on > this buggy planet's movements will be unpredictable. Let's patch it > now! http://mm.icann.org/pipermail/tz/2015-May/022280.html http://mm.icann.org/pipermail/tz/2015-May/022281.html http://mm.icann.org/pipermail/tz/2015-May/022282.html Tony. -- f.anthony.n.finch http://dotat.at/ Northwest Faeroes, Southeast Iceland: Northeasterly 3 or 4. Moderate, becoming mainly slight. Mainly fair. Good, occasionally poor in Southeast Iceland. From A.L.M.Buxey at lboro.ac.uk Mon Jun 22 12:56:44 2015 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Mon, 22 Jun 2015 12:56:44 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: <8C40413B-B22C-4BCE-85D2-B4F93A233628@lists.zabbadoz.net> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150622122718.GA10690@nic.fr>, <8C40413B-B22C-4BCE-85D2-B4F93A233628@lists.zabbadoz.net> Message-ID: I do feel sorry for you unix/linux users having a problem in year 2038.... fortunately I get another ~ 8 years... my Amiga gets its first big problem in 2046 ;-) http://web.archive.org/web/19981203142814/http://www.amiga.com/092098-y2k.html alan PS if i get to see the 2078 issue I'll be old enough to fuss about other things than a 2 digit date display..and I'm sure if I'm around until 7 February, 2114, 06:28:16 I'll have more to worry about than an old Amiga finally reaching the end of its useful life...unless its actually driving my life support system! ;-) From saku at ytti.fi Mon Jun 22 13:23:11 2015 From: saku at ytti.fi (Saku Ytti) Date: Mon, 22 Jun 2015 16:23:11 +0300 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150622124415.GA12276@nic.fr> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150622122718.GA10690@nic.fr> <8C40413B-B22C-4BCE-85D2-B4F93A233628@lists.zabbadoz.net> <20150622124415.GA12276@nic.fr> Message-ID: <20150622132311.GA14699@pob.ytti.fi> On (2015-06-22 14:44 +0200), Stephane Bortzmeyer wrote: > Or simply use TAI which is the obvious time reference for Internet > devices. Using UTC in routers is madness. Routers and Internet servers > should use TAI internally and use UTC only when communicating with > humans (the inferior life form which crawls on the Earth surface and > cares about things like whether the sun is high at noon, for outside > picnics). I couldn't agree more. But out of curiosity does anyone have scoop why TAI exists? I believe GPSTIME predates it, which appears analogous to TAI. -- ++ytti From randy at psg.com Mon Jun 22 14:17:52 2015 From: randy at psg.com (Randy Bush) Date: Mon, 22 Jun 2015 23:17:52 +0900 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150622124415.GA12276@nic.fr> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150622122718.GA10690@nic.fr> <8C40413B-B22C-4BCE-85D2-B4F93A233628@lists.zabbadoz.net> <20150622124415.GA12276@nic.fr> Message-ID: we can just turn the internet off for an hour until the dust settles. From ag4ve.us at gmail.com Mon Jun 22 14:17:53 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 22 Jun 2015 14:17:53 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150622122718.GA10690@nic.fr> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150622122718.GA10690@nic.fr> Message-ID: On Mon, Jun 22, 2015, 08:29 Stephane Bortzmeyer wrote: > On Mon, Jun 22, 2015 at 01:15:41PM +0100, > Tony Finch wrote > a message of 15 lines which said: > > > The problems are that UTC is unpredictable, > > That's because the earth rotation is unpredictable. Any time based on > this buggy planet's movements will be unpredictable. Let's patch it > now! > > So, what we should do is make clocks move. 99999 slower half of the year (and then speed back up) so that we're really in line with earth's rotational time. I mean we've got the computers to do it (I think most RTC only go down to thousandths so it'll still need a little skewing but I'm sure we'll manage). Ps - if anyone actually does this, I'm going postal. From dot at dotat.at Mon Jun 22 14:27:42 2015 From: dot at dotat.at (Tony Finch) Date: Mon, 22 Jun 2015 15:27:42 +0100 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150622122718.GA10690@nic.fr> Message-ID: shawn wilson wrote: > So, what we should do is make clocks move. 99999 slower half of the year > (and then speed back up) so that we're really in line with earth's > rotational time. That's how UTC worked in the 1960s. ftp://maia.usno.navy.mil/ser7/tai-utc.dat It causes problems for systems that have a tight coupling between time and frequency - broadcast, cellular, etc. Tony. -- f.anthony.n.finch http://dotat.at/ Fair Isle, Southeast Faeroes: Northeasterly 5 or 6 backing northerly 4 or 5. Moderate, occasionally rough at first. Mainly fair. Good. From rafael at gav.ufsc.br Mon Jun 22 16:44:41 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Mon, 22 Jun 2015 11:44:41 -0500 Subject: Data Center Network Monitoring with TAPs In-Reply-To: References: Message-ID: Here's a recent forum thread that discussed the same exact topic. You might find some insight: http://www.reddit.com/r/networking/comments/3aip3p/data_center_network_monitoring/ On Sat, Jun 20, 2015 at 11:06 AM, Mitch Howards wrote: > Hello All, > > Was wondering what folks are using to monitor traffic > on their networks. Looking into Ixia and APCON devices for dedup and > other filtering features as well as passive fiber TAPs to capture the > traffic. > > How are folks handling TAP'ing large data center > networks? TAPs at the "distribution layer" would be the best fit for my > network but that would require a ton of passive fiber TAPs for the > incoming fibers to the distribution switches. The end goal is to not > only capture the north-south traffic on the network but also east-west > traffic. It seems more efficient to just use SPANs but there are many > limitations using SPANs. > > Thanks in advance for any suggestions. > > Mitch From stenn at ntp.org Mon Jun 22 17:58:54 2015 From: stenn at ntp.org (Harlan Stenn) Date: Mon, 22 Jun 2015 17:58:54 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> Message-ID: Tony Finch writes: > Harlan Stenn wrote: > > > It's a problem with POSIX, not UTC. > > > > UTC is monotonic. > > The problems are that UTC is unpredictable, and it breaks the standard > labelling of points in time that was used for hundreds (arguably > thousands) of years before 1972. You mean back when seconds were rubbery, and before the earth's rotational speed could be easily and accurately measured, or at least when the wobbles at that level of accuracy became so noticeable that they could no longer be ignored? H From david.sovereen at mercury.net Mon Jun 22 18:54:09 2015 From: david.sovereen at mercury.net (David Sovereen) Date: Mon, 22 Jun 2015 14:54:09 -0400 Subject: Facebook contact, images issues in IL/WI Message-ID: <7FDC076C-51E9-4006-90B6-5991BC33D8DC@mercury.net> Hello, If someone from Facebook is reading, please contact me off-list. Since last Thursday, our customers have been having image loading problems at Facebook.com We know it?s not just us?many users are reporting similar problems at https://downdetector.com/status/facebook/map/ Would like to help get this resolved. Thanks, Dave ====================================================================== MERCURY NETWORK CORPORATION David Sovereen 920-686-4800 x 151 1011 Washington St Ste 3, Manitowoc, WI 54220-5248 http://www.mercury.net From marshall.eubanks at gmail.com Mon Jun 22 19:36:32 2015 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Mon, 22 Jun 2015 15:36:32 -0400 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150622124415.GA12276@nic.fr> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150622122718.GA10690@nic.fr> <8C40413B-B22C-4BCE-85D2-B4F93A233628@lists.zabbadoz.net> <20150622124415.GA12276@nic.fr> Message-ID: On Mon, Jun 22, 2015 at 8:44 AM, Stephane Bortzmeyer wrote: > On Mon, Jun 22, 2015 at 12:38:28PM +0000, > Bjoern A. Zeeb wrote > a message of 17 lines which said: > > > So we need a new center of the universe and switch to stardate and > > thus solve the 32bit UNIX time problem for real this time? > > Or simply use TAI which is the obvious time reference for Internet > devices. Using UTC in routers is madness. Routers and Internet servers > should use TAI internally and use UTC only when communicating with > humans (the inferior life form which crawls on the Earth surface and > cares about things like whether the sun is high at noon, for outside > picnics). > > If the Earth's core ever decides to have some real fun and causes there to be a negative leap second (there is historical precedent for this, albeit before the existence of UTC and atomic time) there would be a minute with only 59 seconds, and I would expect things to break in new and creative ways. We live in a relatively narrow slice of time (a few decades) where this is a possibility, but it is a possibility. (Note that the number of leap seconds per year has _slowed_ recently, corresponding to a speed up in the long term averaged rotation of the Earth. If that speed up of the Earth's rotation were to happen again, negative leap seconds would be inevitable.) The drift between the Earth's time and atomic time will just get worse over longer time frames (see http://www.ucolick.org/~sla/leapsecs/year2100.html ). Even if UTC - TAI is just fixed (i.e., no more leap seconds), that is just pushing the problem down the road, and our grandkids will have to deal with leap minutes, or our remoter descendants with leap hours. >It's a problem with POSIX, not UTC. Yes. I remember this being raised by people at the USNO back in the early 1990's, but there was no interest in changing POSIX. Too much installed base was the reason stated IIRC. My opinion is (and has been since the early 90's) that the computer / Internet world should just adopt IAT as the time system in use. That is the best time we have, and it will never have steps. Yes, that means that you would need something like a time zone file to set your system clock by hand from local (UTC) time, but, then, we already have to have time zone files. Regards Marshall Eubanks From nicholas.oas at gmail.com Mon Jun 22 20:39:27 2015 From: nicholas.oas at gmail.com (Nicholas Oas) Date: Mon, 22 Jun 2015 16:39:27 -0400 Subject: Residential VSAT experiences? Message-ID: Would anyone mind sharing with me their first-hand experiences with residential satellite internet? Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm thinking specifically as a sysadmin who needs to use the uplink for work, not surf. What are your experiences with the following applications? -SSH, (specifically interactive CLI shell access) -RDP -SIP over SSL -IPSec Tunneling (should be a non-starter due to latency) -GRE Tunneling Thank you, -Nicholas From pkranz at unwiredltd.com Mon Jun 22 20:58:21 2015 From: pkranz at unwiredltd.com (Peter Kranz) Date: Mon, 22 Jun 2015 13:58:21 -0700 Subject: Core alignment fusion splicers Message-ID: <20ac01d0ad2e$2c76fa00$8564ee00$@unwiredltd.com> Curious if any of you have favorites when it comes to fusion splicers.. There is a huge range in price for units that appear to be very similar in both specifications and appearance. Currently considering standardizing on the INNO View 5 http://www.innoinstrument.com/new/splicer/view5.php , but we need enough of these units I'd love stories from the field before dropping the order. Peter Kranz www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz at unwiredltd.com From mel at beckman.org Mon Jun 22 21:06:09 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 22 Jun 2015 21:06:09 +0000 Subject: Core alignment fusion splicers In-Reply-To: <20ac01d0ad2e$2c76fa00$8564ee00$@unwiredltd.com> References: <20ac01d0ad2e$2c76fa00$8564ee00$@unwiredltd.com> Message-ID: Don?t buy to start. Instead, rent a few different brands for splicing projects until you know what features you need and want. And don?t scrimp on the cleaver. Get a quality automatic cleaver (these usually come in the rental bundle). -mel > On Jun 22, 2015, at 1:58 PM, Peter Kranz wrote: > > Curious if any of you have favorites when it comes to fusion splicers.. > There is a huge range in price for units that appear to be very similar in > both specifications and appearance. Currently considering standardizing on > the INNO View 5 http://www.innoinstrument.com/new/splicer/view5.php , but we > need enough of these units I'd love stories from the field before dropping > the order. > > > > Peter Kranz > www.UnwiredLtd.com > Desk: 510-868-1614 x100 > Mobile: 510-207-0000 > pkranz at unwiredltd.com > > > From jj at anexia.at Mon Jun 22 21:07:41 2015 From: jj at anexia.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Mon, 22 Jun 2015 21:07:41 +0000 Subject: AW: Core alignment fusion splicers In-Reply-To: <20ac01d0ad2e$2c76fa00$8564ee00$@unwiredltd.com> References: <20ac01d0ad2e$2c76fa00$8564ee00$@unwiredltd.com> Message-ID: <515026f2064b40768f82af92334ba8f4@anx-i-dag02.anx.local> Hi, We do not have the new View-series but we're working with the IFS-10: http://www.innoinstrument.com/new/splicer/ifs10.php Easy to use. Works quite good under rough conditions. Not THAT expensive. Battery lifetime is ok. Best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Peter Kranz Gesendet: Montag, 22. Juni 2015 22:58 An: nanog at nanog.org Betreff: Core alignment fusion splicers Curious if any of you have favorites when it comes to fusion splicers.. There is a huge range in price for units that appear to be very similar in both specifications and appearance. Currently considering standardizing on the INNO View 5 http://www.innoinstrument.com/new/splicer/view5.php , but we need enough of these units I'd love stories from the field before dropping the order. Peter Kranz www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz at unwiredltd.com From bill at herrin.us Mon Jun 22 22:11:38 2015 From: bill at herrin.us (William Herrin) Date: Mon, 22 Jun 2015 18:11:38 -0400 Subject: Residential VSAT experiences? In-Reply-To: References: Message-ID: On Mon, Jun 22, 2015 at 4:39 PM, Nicholas Oas wrote: > Would anyone mind sharing with me their first-hand experiences with > residential satellite internet? Hi Nicholas, Two-way satellite systems based on SV's in geostationary orbit (like the two you're considering) have high latency. 22,000 miles out, another 22,000 miles back and do it again for the return packet. You'll start around 500ms latency and go up from there. Any kind of interactive session (like SSH and RDP) will be excruciating. I'm not aware of any low earth orbit systems providing residential Internet. Iridium tries to but the bandwidth is pathetic (2400bps or so). LEO vehicles are only 500-1000 miles up. Latency is high compared to wireline systems but within usable bounds for interactive sessions. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From dougb at dougbarton.us Mon Jun 22 22:18:14 2015 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 22 Jun 2015 15:18:14 -0700 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> Message-ID: <558889A6.10704@dougbarton.us> On 6/19/15 2:58 PM, Harlan Stenn wrote: > Bad idea. > > When restarting ntpd your clocks will likely be off by a second, which > will cause a backward step, which will force the problem you claim to be > avoiding. > > There are plenty of ways to solve this problem, and you just get to > choose what you want to risk/pay. You misunderstand the problem. :) The problem is not "clock skips backward one second," because most of the time that's not what happens. The problem is that most software does not handle it well when the clock ticks ... :59 :60 :00 instead of ticking directly from :59 to :00. THAT problem is avoided by temporarily turning off NTP and then turning it back on again when "the coast is clear." Most software can handle the "clock skips forward or backwards one second" problem fairly robustly, and as Baldur pointed out by doing the reset in a controlled manner you greatly reduce your overall risk. Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mike.lyon at gmail.com Mon Jun 22 22:33:43 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 22 Jun 2015 15:33:43 -0700 Subject: Residential VSAT experiences? In-Reply-To: References: Message-ID: SIP will suck. VPN will suck. RDP will suck. Have you looked to see if you have any local wireless ISPs in your area? Hit me up offlist if you want me to check for you. -Mike On Mon, Jun 22, 2015 at 1:39 PM, Nicholas Oas wrote: > Would anyone mind sharing with me their first-hand experiences with > residential satellite internet? > > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm thinking > specifically as a sysadmin who needs to use the uplink for work, not surf. > > What are your experiences with the following applications? > -SSH, (specifically interactive CLI shell access) > -RDP > -SIP over SSL > -IPSec Tunneling (should be a non-starter due to latency) > -GRE Tunneling > > Thank you, > > -Nicholas > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From fred at cisco.com Mon Jun 22 22:35:45 2015 From: fred at cisco.com (Fred Baker (fred)) Date: Mon, 22 Jun 2015 22:35:45 +0000 Subject: Residential VSAT experiences? In-Reply-To: References: Message-ID: <8EAA4E3F-C17F-4988-990F-808E4E03FA5F@cisco.com> > On Jun 22, 2015, at 3:11 PM, William Herrin wrote: > > Two-way satellite systems based on SV's in geostationary orbit (like > the two you're considering) have high latency. 22,000 miles out, > another 22,000 miles back and do it again for the return packet. > You'll start around 500ms latency and go up from there. Any kind of > interactive session (like SSH and RDP) will be excruciating. It is indeed. This is first-hand in the sense that I once worked for an earth station manufacturer and did a fair bit of work related to this environment, and second-hand in that my sister, for a while, used VSAT connectivity to her home. The trick in the context is what's called a "performance-enhancing proxy", or PEP. What it does, in concept, is terminate a TCP connection at each earth station and use some form of private protocol over the bird. Cisco RBSCP (which maps TCP connections to SCTP sessions over the bird, http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/interface/configuration/15-sy/ir-15-sy-book/ir-rt-bsd-sat.html) is an example of such a technology. The obvious benefit of a PEP is that it can convince a TCP sender to keep enough data in flight to make good use of the throughput rate of the satellite - you have a start-up issue with the first RTT, but after that it has essentially figured out what the effective window should be and makes that happen. The downside of a PEP is when the application is itself interactive (it's not about rate, it's about responsiveness clocked by end-to-end RTT) or the protocol in question isn't TCP (noting that TCP in IPsec ESP isn't TCP to the PEP - it's IPsec ESP, and can't be goosed along). In my sister's case, her description of the service was somewhat colorful, and included the word "slow". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dovid at telecurve.com Mon Jun 22 22:49:04 2015 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 22 Jun 2015 22:49:04 +0000 Subject: Residential VSAT experiences? In-Reply-To: References: Message-ID: <274163724-1435013345-cardhu_decombobulator_blackberry.rim.net-1126150793-@b1.c3.bise6.blackberry> Interesting that you say that about sip. We had a client that would use it for sip on ships all the time. It wasn't the best but it worked. Ping times were between 500-700ms. Regards, Dovid -----Original Message----- From: Mike Lyon Sender: "NANOG" Date: Mon, 22 Jun 2015 15:33:43 To: Nicholas Oas; NANOG Subject: Re: Residential VSAT experiences? SIP will suck. VPN will suck. RDP will suck. Have you looked to see if you have any local wireless ISPs in your area? Hit me up offlist if you want me to check for you. -Mike On Mon, Jun 22, 2015 at 1:39 PM, Nicholas Oas wrote: > Would anyone mind sharing with me their first-hand experiences with > residential satellite internet? > > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm thinking > specifically as a sysadmin who needs to use the uplink for work, not surf. > > What are your experiences with the following applications? > -SSH, (specifically interactive CLI shell access) > -RDP > -SIP over SSL > -IPSec Tunneling (should be a non-starter due to latency) > -GRE Tunneling > > Thank you, > > -Nicholas > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From mike.lyon at gmail.com Mon Jun 22 22:54:49 2015 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 22 Jun 2015 15:54:49 -0700 Subject: Residential VSAT experiences? In-Reply-To: <274163724-1435013345-cardhu_decombobulator_blackberry.rim.net-1126150793-@b1.c3.bise6.blackberry> References: <274163724-1435013345-cardhu_decombobulator_blackberry.rim.net-1126150793-@b1.c3.bise6.blackberry> Message-ID: I never had good luck with VSAT and SIP. Maybe you had a better kit than I did :) -Mike On Mon, Jun 22, 2015 at 3:49 PM, Dovid Bender wrote: > Interesting that you say that about sip. We had a client that would use it > for sip on ships all the time. It wasn't the best but it worked. Ping times > were between 500-700ms. > > > > Regards, > > Dovid > > -----Original Message----- > From: Mike Lyon > Sender: "NANOG" Date: Mon, 22 Jun 2015 15:33:43 > To: Nicholas Oas; NANOG > Subject: Re: Residential VSAT experiences? > > SIP will suck. VPN will suck. RDP will suck. > > Have you looked to see if you have any local wireless ISPs in your area? > Hit me up offlist if you want me to check for you. > > -Mike > > > On Mon, Jun 22, 2015 at 1:39 PM, Nicholas Oas > wrote: > > > Would anyone mind sharing with me their first-hand experiences with > > residential satellite internet? > > > > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm > thinking > > specifically as a sysadmin who needs to use the uplink for work, not > surf. > > > > What are your experiences with the following applications? > > -SSH, (specifically interactive CLI shell access) > > -RDP > > -SIP over SSL > > -IPSec Tunneling (should be a non-starter due to latency) > > -GRE Tunneling > > > > Thank you, > > > > -Nicholas > > > > > > -- > Mike Lyon > 408-621-4826 > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From hugo at slabnet.com Mon Jun 22 23:04:55 2015 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 22 Jun 2015 16:04:55 -0700 Subject: Residential VSAT experiences? In-Reply-To: References: <274163724-1435013345-cardhu_decombobulator_blackberry.rim.net-1126150793-@b1.c3.bise6.blackberry> Message-ID: <20150622230455.GO28830@bamboo.slabnet.com> Personally, 500-700ms of delay is well within distinguishable range and causes challenges in verbal communication. If the speakers are both expecting and accustomed to delay like that (e.g. sailors that are used to being hundreds/thousands of miles away from anywhere and any other comms solution sucks anyway), it could be workable. For regular consumer/business voice applications, 100ms and lower is decent, but above that starts to get into various degrees of suckage. Just my 2c. -- Hugo On Mon 2015-Jun-22 15:54:49 -0700, Mike Lyon wrote: >I never had good luck with VSAT and SIP. Maybe you had a better kit than I >did :) > >-Mike > > >On Mon, Jun 22, 2015 at 3:49 PM, Dovid Bender wrote: > >> Interesting that you say that about sip. We had a client that would use it >> for sip on ships all the time. It wasn't the best but it worked. Ping times >> were between 500-700ms. >> >> >> >> Regards, >> >> Dovid >> >> -----Original Message----- >> From: Mike Lyon >> Sender: "NANOG" Date: Mon, 22 Jun 2015 15:33:43 >> To: Nicholas Oas; NANOG >> Subject: Re: Residential VSAT experiences? >> >> SIP will suck. VPN will suck. RDP will suck. >> >> Have you looked to see if you have any local wireless ISPs in your area? >> Hit me up offlist if you want me to check for you. >> >> -Mike >> >> >> On Mon, Jun 22, 2015 at 1:39 PM, Nicholas Oas >> wrote: >> >> > Would anyone mind sharing with me their first-hand experiences with >> > residential satellite internet? >> > >> > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm >> thinking >> > specifically as a sysadmin who needs to use the uplink for work, not >> surf. >> > >> > What are your experiences with the following applications? >> > -SSH, (specifically interactive CLI shell access) >> > -RDP >> > -SIP over SSL >> > -IPSec Tunneling (should be a non-starter due to latency) >> > -GRE Tunneling >> > >> > Thank you, >> > >> > -Nicholas >> > >> >> >> >> -- >> Mike Lyon >> 408-621-4826 >> mike.lyon at gmail.com >> >> http://www.linkedin.com/in/mlyon >> > > > >-- >Mike Lyon >408-621-4826 >mike.lyon at gmail.com > >http://www.linkedin.com/in/mlyon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From stenn at ntp.org Mon Jun 22 23:06:54 2015 From: stenn at ntp.org (Harlan Stenn) Date: Mon, 22 Jun 2015 23:06:54 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: <558889A6.10704@dougbarton.us> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> Message-ID: Doug Barton writes: > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > On 6/19/15 2:58 PM, Harlan Stenn wrote: >> Bad idea. >> >> When restarting ntpd your clocks will likely be off by a second, >> which will cause a backward step, which will force the problem you >> claim to be avoiding. >> >> There are plenty of ways to solve this problem, and you just get to >> choose what you want to risk/pay. > > You misunderstand the problem. :) The problem is not "clock skips > backward one second," because most of the time that's not what > happens. The problem is that most software does not handle it well > when the clock ticks ... :59 :60 :00 instead of ticking directly from > :59 to :00. POSIX NEVER shows :60. > THAT problem is avoided by temporarily turning off NTP and then > turning it back on again when "the coast is clear." Most software can > handle the "clock skips forward or backwards one second" problem > fairly robustly,= and as Baldur pointed out by doing the reset in a > controlled manner you greatly reduce your overall risk. Time going backwards is deadly to a number of applications. But apparently not to applications you care about. You're also not doing anything where somebody is going to get sued because a timestamp is off by a second. There are people for whom this is a very real risk. H From eyeronic.design at gmail.com Mon Jun 22 23:12:32 2015 From: eyeronic.design at gmail.com (Mike Hale) Date: Mon, 22 Jun 2015 16:12:32 -0700 Subject: Residential VSAT experiences? In-Reply-To: <20150622230455.GO28830@bamboo.slabnet.com> References: <274163724-1435013345-cardhu_decombobulator_blackberry.rim.net-1126150793-@b1.c3.bise6.blackberry> <20150622230455.GO28830@bamboo.slabnet.com> Message-ID: I too have had customers in a previous life where the 500ms delay really didn't cause any big issue. Same with SSH and even heavier stuff like SMB. Sure, it was slower than expected, but I could still saturate the pipe pretty good. Thing is...the kind of setups where you're getting 500ms delay with little jitter is stupidly expensive. Those are generally going to be an SCPC (single carrier per channel) uplink with hopefully something like IP over DVB providing a large pool of downlink bandwidth. Expect to pay over 4k per Megahertz (roughly translated to 1 Mbps unidirectional depending your link budgets) of bandwidth (sometimes substantially more, depending on what bird and provider you're using). O3B looks really interesting. I'm not aware of what they're current state of deployment is, but they've got a MEO (I think) constellation planned which will help a lot of with that latency. Viasat had something that looked promising too. I mean..if you're looking at doing sysadmin type stuff where you're already going to be pulling out your hair at times, doing so over hughesnet is going to suuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuck. On Mon, Jun 22, 2015 at 4:04 PM, Hugo Slabbert wrote: > Personally, 500-700ms of delay is well within distinguishable range and > causes challenges in verbal communication. If the speakers are both > expecting and accustomed to delay like that (e.g. sailors that are used to > being hundreds/thousands of miles away from anywhere and any other comms > solution sucks anyway), it could be workable. > > For regular consumer/business voice applications, 100ms and lower is decent, > but above that starts to get into various degrees of suckage. > > Just my 2c. > > -- > Hugo > > > On Mon 2015-Jun-22 15:54:49 -0700, Mike Lyon wrote: > >> I never had good luck with VSAT and SIP. Maybe you had a better kit than I >> did :) >> >> -Mike >> >> >> On Mon, Jun 22, 2015 at 3:49 PM, Dovid Bender wrote: >> >>> Interesting that you say that about sip. We had a client that would use >>> it >>> for sip on ships all the time. It wasn't the best but it worked. Ping >>> times >>> were between 500-700ms. >>> >>> >>> >>> Regards, >>> >>> Dovid >>> >>> -----Original Message----- >>> From: Mike Lyon >>> Sender: "NANOG" Date: Mon, 22 Jun 2015 15:33:43 >>> To: Nicholas Oas; NANOG >>> Subject: Re: Residential VSAT experiences? >>> >>> SIP will suck. VPN will suck. RDP will suck. >>> >>> Have you looked to see if you have any local wireless ISPs in your area? >>> Hit me up offlist if you want me to check for you. >>> >>> -Mike >>> >>> >>> On Mon, Jun 22, 2015 at 1:39 PM, Nicholas Oas >>> wrote: >>> >>> > Would anyone mind sharing with me their first-hand experiences with >>> > residential satellite internet? >>> > >>> > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm >>> thinking >>> > specifically as a sysadmin who needs to use the uplink for work, not >>> surf. >>> > >>> > What are your experiences with the following applications? >>> > -SSH, (specifically interactive CLI shell access) >>> > -RDP >>> > -SIP over SSL >>> > -IPSec Tunneling (should be a non-starter due to latency) >>> > -GRE Tunneling >>> > >>> > Thank you, >>> > >>> > -Nicholas >>> > >>> >>> >>> >>> -- >>> Mike Lyon >>> 408-621-4826 >>> mike.lyon at gmail.com >>> >>> http://www.linkedin.com/in/mlyon >>> >> >> >> >> -- >> Mike Lyon >> 408-621-4826 >> mike.lyon at gmail.com >> >> http://www.linkedin.com/in/mlyon -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From mike at conlen.org Tue Jun 23 00:10:12 2015 From: mike at conlen.org (Michael Conlen) Date: Mon, 22 Jun 2015 20:10:12 -0400 Subject: Residential VSAT experiences? In-Reply-To: References: Message-ID: <9AB1D8A3-AA0E-4DAF-92D1-054D5A121EC9@conlen.org> On Jun 22, 2015, at 4:39 PM, Nicholas Oas wrote: > Would anyone mind sharing with me their first-hand experiences with > residential satellite internet? > > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm thinking > specifically as a sysadmin who needs to use the uplink for work, not surf. My experience with geostationary was that latencies were around 720 ms in practice. Telnet was painful and it turns out my brain didn?t like typing things while I wasn?t getting instant feedback, though I understand there?s software for that problem now. Reliability was pretty good unless the satellite I was using happened to lose it?s control processors. I was using Panamsat Galaxy 4 when it failed. I don?t know how many angry phone calls we got about why we weren?t answering our pages about the entire network being down before we got into the office. In our case recovery involved getting access to another satellite and having people re-aim the dishes. My only real recollection besides that was that the signal was bad enough/long enough to induce TCP Silly Window Syndrome; but I can?t imagine anyone?s running an OS that old anymore. ? Mike From surfer at mauigateway.com Tue Jun 23 00:27:09 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 22 Jun 2015 17:27:09 -0700 Subject: Residential VSAT experiences? Message-ID: <20150622172709.1DAC5311@m0005298.ppops.net> --- bill at herrin.us wrote: From: William Herrin Two-way satellite systems based on SV's in geostationary orbit (like the two you're considering) have high latency. 22,000 miles out, another 22,000 miles back and do it again for the return packet. You'll start around 500ms latency and go up from there. Any kind of interactive session (like SSH and RDP) will be excruciating. ----------------------------------------------- I do SSH over geostationary satellite links (C-band) all the time. I'd say it's slow, but not excruciating, unless you type really fast on the network device's CLI. :-) scott From alfredolton at gmail.com Tue Jun 23 00:18:03 2015 From: alfredolton at gmail.com (Alfred Olton) Date: Mon, 22 Jun 2015 17:18:03 -0700 Subject: Fwd: Residential VSAT experiences? In-Reply-To: References: Message-ID: I had Hughes Net a few years back and can confirm that SSH access was pretty much intolerable for me. The delay between what I was typing, and when it would actually show up on the screen in the remote terminal was really annoying for me. As mentioned in previous responses, I think you would want a low orbit satellite internet provider, if you can find one for residential use. In my case, I had a land line, but was too far out for ADSL, so I ended up getting ISDN (*with unlimited local calling on my phone plan*). Of course the SSH usage experience then was much better. Al On 06/22/2015 04:04 PM, Hugo Slabbert wrote:> Personally, 500-700ms of delay is well within distinguishable range and > causes challenges in verbal communication. If the speakers are both > expecting and accustomed to delay like that (e.g. sailors that are used > to being hundreds/thousands of miles away from anywhere and any other > comms solution sucks anyway), it could be workable. > > For regular consumer/business voice applications, 100ms and lower is > decent, but above that starts to get into various degrees of suckage. > > Just my 2c. > > -- > Hugo > > On Mon 2015-Jun-22 15:54:49 -0700, Mike Lyon wrote: > >> I never had good luck with VSAT and SIP. Maybe you had a better kit >> than I >> did :) >> >> -Mike >> >> >> On Mon, Jun 22, 2015 at 3:49 PM, Dovid Bender >> wrote: >> >>> Interesting that you say that about sip. We had a client that would >>> use it >>> for sip on ships all the time. It wasn't the best but it worked. Ping >>> times >>> were between 500-700ms. >>> >>> >>> >>> Regards, >>> >>> Dovid >>> >>> -----Original Message----- >>> From: Mike Lyon >>> Sender: "NANOG" Date: Mon, 22 Jun 2015 15:33:43 >>> To: Nicholas Oas; NANOG >>> Subject: Re: Residential VSAT experiences? >>> >>> SIP will suck. VPN will suck. RDP will suck. >>> >>> Have you looked to see if you have any local wireless ISPs in your area? >>> Hit me up offlist if you want me to check for you. >>> >>> -Mike >>> >>> >>> On Mon, Jun 22, 2015 at 1:39 PM, Nicholas Oas >>> wrote: >>> >>> > Would anyone mind sharing with me their first-hand experiences with >>> > residential satellite internet? >>> > >>> > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm >>> thinking >>> > specifically as a sysadmin who needs to use the uplink for work, not >>> surf. >>> > >>> > What are your experiences with the following applications? >>> > -SSH, (specifically interactive CLI shell access) >>> > -RDP >>> > -SIP over SSL >>> > -IPSec Tunneling (should be a non-starter due to latency) >>> > -GRE Tunneling >>> > >>> > Thank you, >>> > >>> > -Nicholas >>> > >>> >>> >>> >>> -- >>> Mike Lyon >>> 408-621-4826 >>> mike.lyon at gmail.com >>> >>> http://www.linkedin.com/in/mlyon >>> >> >> >> >> -- >> Mike Lyon >> 408-621-4826 >> mike.lyon at gmail.com >> >> http://www.linkedin.com/in/mlyon From lyndon at orthanc.ca Tue Jun 23 01:01:54 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 22 Jun 2015 18:01:54 -0700 Subject: Residential VSAT experiences? In-Reply-To: <20150622172709.1DAC5311@m0005298.ppops.net> References: <20150622172709.1DAC5311@m0005298.ppops.net> Message-ID: <83287994-FBA2-42DD-8006-7C1E5B0F8609@orthanc.ca> On Jun 22, 2015, at 5:27 PM, Scott Weeks wrote: > I do SSH over geostationary satellite links (C-band) all > the time. I'd say it's slow, but not excruciating, unless > you type really fast on the network device's CLI. :-) SSH client/server authors would do well to learn the lessons of telnet line mode. As would authors of 'interactive' command line applications. The NVT concept is still useful in this day and age, far beyond the LA36. (I.e., if the termcap entry says 'dumb', honour it. There is a damn good reason we are saying 'turn off the bling'.) --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tshaw at oitc.com Tue Jun 23 01:11:17 2015 From: tshaw at oitc.com (TR Shaw) Date: Mon, 22 Jun 2015 21:11:17 -0400 Subject: Residential VSAT experiences? In-Reply-To: References: Message-ID: <54EAD60A-0A03-4240-8967-ADE3642C2DF4@oitc.com> I don?t know what your location is but a wireless internet provider using Canopy or Ubiquity or whatever is much more preferable. Also cellular is used in ?remote? locations with good results. I know plenty of people "in the bush? that use these alternatives over VSat. I use the above over VSat when I am out on fishing trips to remote locations. For truly remote where there is no options other than VSat you need to live with the latency problems for now. Iridum is currently too slow and too costly. Maybe LEO or MEO in the future but not now. I have used SSH from a transatlantic flight but the delay can weigh on you ;-) Tom > On Jun 22, 2015, at 8:18 PM, Alfred Olton wrote: > > I had Hughes Net a few years back and can confirm that SSH access was > pretty much intolerable for me. > The delay between what I was typing, and when it would actually show up on > the screen in the remote terminal was really annoying for me. > As mentioned in previous responses, I think you would want a low orbit > satellite internet provider, if you can find one for residential use. > > In my case, I had a land line, but was too far out for ADSL, so I ended up > getting ISDN (*with unlimited local calling on my phone plan*). > Of course the SSH usage experience then was much better. > > Al > > On 06/22/2015 04:04 PM, Hugo Slabbert wrote:> Personally, 500-700ms of > delay is well within distinguishable range and >> causes challenges in verbal communication. If the speakers are both >> expecting and accustomed to delay like that (e.g. sailors that are used >> to being hundreds/thousands of miles away from anywhere and any other >> comms solution sucks anyway), it could be workable. >> >> For regular consumer/business voice applications, 100ms and lower is >> decent, but above that starts to get into various degrees of suckage. >> >> Just my 2c. >> >> -- >> Hugo >> >> On Mon 2015-Jun-22 15:54:49 -0700, Mike Lyon wrote: >> >>> I never had good luck with VSAT and SIP. Maybe you had a better kit >>> than I >>> did :) >>> >>> -Mike >>> >>> >>> On Mon, Jun 22, 2015 at 3:49 PM, Dovid Bender >>> wrote: >>> >>>> Interesting that you say that about sip. We had a client that would >>>> use it >>>> for sip on ships all the time. It wasn't the best but it worked. Ping >>>> times >>>> were between 500-700ms. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Dovid >>>> >>>> -----Original Message----- >>>> From: Mike Lyon >>>> Sender: "NANOG" Date: Mon, 22 Jun 2015 15:33:43 >>>> To: Nicholas Oas; NANOG >>>> Subject: Re: Residential VSAT experiences? >>>> >>>> SIP will suck. VPN will suck. RDP will suck. >>>> >>>> Have you looked to see if you have any local wireless ISPs in your area? >>>> Hit me up offlist if you want me to check for you. >>>> >>>> -Mike >>>> >>>> >>>> On Mon, Jun 22, 2015 at 1:39 PM, Nicholas Oas >>>> wrote: >>>> >>>>> Would anyone mind sharing with me their first-hand experiences with >>>>> residential satellite internet? >>>>> >>>>> Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm >>>> thinking >>>>> specifically as a sysadmin who needs to use the uplink for work, not >>>> surf. >>>>> >>>>> What are your experiences with the following applications? >>>>> -SSH, (specifically interactive CLI shell access) >>>>> -RDP >>>>> -SIP over SSL >>>>> -IPSec Tunneling (should be a non-starter due to latency) >>>>> -GRE Tunneling >>>>> >>>>> Thank you, >>>>> >>>>> -Nicholas >>>>> >>>> >>>> >>>> >>>> -- >>>> Mike Lyon >>>> 408-621-4826 >>>> mike.lyon at gmail.com >>>> >>>> http://www.linkedin.com/in/mlyon >>>> >>> >>> >>> >>> -- >>> Mike Lyon >>> 408-621-4826 >>> mike.lyon at gmail.com >>> >>> http://www.linkedin.com/in/mlyon From dhc2 at dcrocker.net Tue Jun 23 01:35:34 2015 From: dhc2 at dcrocker.net (Dave Crocker) Date: Mon, 22 Jun 2015 18:35:34 -0700 Subject: Residential VSAT experiences? In-Reply-To: <83287994-FBA2-42DD-8006-7C1E5B0F8609@orthanc.ca> References: <20150622172709.1DAC5311@m0005298.ppops.net> <83287994-FBA2-42DD-8006-7C1E5B0F8609@orthanc.ca> Message-ID: <5588B7E6.7090508@dcrocker.net> On 6/22/2015 6:01 PM, Lyndon Nerenberg wrote: > SSH client/server authors would do well to learn the lessons of telnet line mode. Too bad the RCTE Telnet option never got popular... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From swmike at swm.pp.se Tue Jun 23 05:10:16 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 23 Jun 2015 07:10:16 +0200 (CEST) Subject: Residential VSAT experiences? In-Reply-To: <9AB1D8A3-AA0E-4DAF-92D1-054D5A121EC9@conlen.org> References: <9AB1D8A3-AA0E-4DAF-92D1-054D5A121EC9@conlen.org> Message-ID: On Mon, 22 Jun 2015, Michael Conlen wrote: > typing things while I wasn?t getting instant feedback, though I > understand there?s software for that problem now. Yes, https://mosh.mit.edu/ is your friend if you want to do things interactively. Still, satellite is painful, avoid if anything else decent is available. -- Mikael Abrahamsson email: swmike at swm.pp.se From dave.taht at gmail.com Tue Jun 23 05:14:19 2015 From: dave.taht at gmail.com (Dave Taht) Date: Mon, 22 Jun 2015 22:14:19 -0700 Subject: Residential VSAT experiences? In-Reply-To: <9AB1D8A3-AA0E-4DAF-92D1-054D5A121EC9@conlen.org> References: <9AB1D8A3-AA0E-4DAF-92D1-054D5A121EC9@conlen.org> Message-ID: On Mon, Jun 22, 2015 at 5:10 PM, Michael Conlen wrote: > > On Jun 22, 2015, at 4:39 PM, Nicholas Oas wrote: > >> Would anyone mind sharing with me their first-hand experiences with >> residential satellite internet? >> >> Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm thinking >> specifically as a sysadmin who needs to use the uplink for work, not surf. > > My experience with geostationary was that latencies were around 720 ms in practice. Telnet was painful and it turns out my brain didn?t like typing things while I wasn?t getting instant feedback, though I understand there?s software for that problem now. Mosh makes latencies like this a lot less painful. Still painful. > Reliability was pretty good unless the satellite I was using happened to lose it?s control processors. I was using Panamsat Galaxy 4 when it failed. I don?t know how many angry phone calls we got about why we weren?t answering our pages about the entire network being down before we got into the office. In our case recovery involved getting access to another satellite and having people re-aim the dishes. > > My only real recollection besides that was that the signal was bad enough/long enough to induce TCP Silly Window Syndrome; but I can?t imagine anyone?s running an OS that old anymore. > > ? > Mike > -- Dave T?ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast From mel at beckman.org Tue Jun 23 07:07:25 2015 From: mel at beckman.org (Mel Beckman) Date: Tue, 23 Jun 2015 07:07:25 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> Message-ID: Harlan, Help me understand why there is a serious risk of going back in time. I acknowledge that there is a remote chance of a backstep, but the probability seems very low. Suppose I disable my NTP service five minutes before a positive leap second occurs, so that no server in my network can query it. These servers will then run on their own internal clocks. Then, five minutes after the leap second, I re-engage NTP. Assuming a high degree of local oscillator fidelity, imagine the clock drift is zero. The result is that NTP will report one second older than the time currently in my server, i.e. exactly five minutes after the 23:59:60 leap second. Thus even systems, such as Unix, where 23:59:60 does not exist in the UTC implementation, the timestamp the server sees from NTP is not the potentially code-crashing 23:59:60, but a perfectly rational 00:05:01. This is what my server?s NTP client compares with its internal clock of 00:04:59. NTP's target time is in the future, so there is no risk of going back in time. NTP gradually increments the local time to converge on NTP?s time. In the alternative case of a negative leap second, following the NTP clock discipline algorithm, the NTP client amortizes the one-second reverse jump, specifically in order to avoid setting the clock backward: the local time will be gradually adjusted again via the clock discipline algorithm until local and NTP times converge. Although the offset is more than the 125ms step threshold, stepping a full one second backward is still statistically unlikely. It may be that I?ve misread the NTP specification in RPC-5905 and its antecedents, as well as the leap second historical records of problems. But the disabling-NTP-prior-to-leap workaround seems to bypass all the documented leap-second live lock hangs and other bugs.. -mel On Jun 22, 2015, at 4:06 PM, Harlan Stenn > wrote: Doug Barton writes: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) On 6/19/15 2:58 PM, Harlan Stenn wrote: Bad idea. When restarting ntpd your clocks will likely be off by a second, which will cause a backward step, which will force the problem you claim to be avoiding. There are plenty of ways to solve this problem, and you just get to choose what you want to risk/pay. You misunderstand the problem. :) The problem is not "clock skips backward one second," because most of the time that's not what happens. The problem is that most software does not handle it well when the clock ticks ... :59 :60 :00 instead of ticking directly from :59 to :00. POSIX NEVER shows :60. THAT problem is avoided by temporarily turning off NTP and then turning it back on again when "the coast is clear." Most software can handle the "clock skips forward or backwards one second" problem fairly robustly,= and as Baldur pointed out by doing the reset in a controlled manner you greatly reduce your overall risk. Time going backwards is deadly to a number of applications. But apparently not to applications you care about. You're also not doing anything where somebody is going to get sued because a timestamp is off by a second. There are people for whom this is a very real risk. H From stenn at ntp.org Tue Jun 23 07:46:50 2015 From: stenn at ntp.org (Harlan Stenn) Date: Tue, 23 Jun 2015 07:46:50 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> Message-ID: This stuff can make my head explode. When a leap second is added, like on 30 June 2015 at the last second of the day, POSIX insists that the day still have 86400 seconds in it. This makes the day longer by one second, so time has to either slow down or move backwards. The "dumb" way to do this is to step the clock back by 1 second at the instant before the stroke of midnight. The allegedly better way to do this would be to stop the clock a bit before midnight, and hold the time for 1 second. To continue providing monotonic time, every time somebody says "what time is it" during that holding period one would want to bump the time by the smallest amount possible, usually 1 nanosecond (assuming the kernel keeps time in nanoseconds). Ideally you wouldn't want to add enough nanoseconds to cause the clock to roll over into the next day "too early". But apparently nobody has implemented this, even though Prof. Mills described it in RFC-i-forget about 20 years ago. This is mostly because POSIX deals with absolute time and not relative time. In the unlikely event of a leap second deletion, there would be no 23:59:59, so when the clock is about to strike 23:59:59 it's OK to add an extra second to the clock to effectively have the time "jump" from 23:59:58 to 00:00:00. This is still a monotonic increment in time. Whatever you decide to do, I recommend you actually test it out to see if it behaves the way you think it will. You have a whole week still. H From tim at pelican.org Tue Jun 23 08:44:40 2015 From: tim at pelican.org (Tim Franklin) Date: Tue, 23 Jun 2015 09:44:40 +0100 (BST) Subject: Residential VSAT experiences? In-Reply-To: <274163724-1435013345-cardhu_decombobulator_blackberry.rim.net-1126150793-@b1.c3.bise6.blackberry> References: <274163724-1435013345-cardhu_decombobulator_blackberry.rim.net-1126150793-@b1.c3.bise6.blackberry> Message-ID: <1732312919.8922.1435049080582.JavaMail.zimbra@pelican.org> > Interesting that you say that about sip. We had a client that would use it > for sip on ships all the time. It wasn't the best but it worked. Ping times > were between 500-700ms. It really depends on your expectations - or more to the point, your end-users' expectations. I've tested SIP in the lab up to 2000ms RTT. The protocols all hang together and keep working, but it's obviously very much in walkie-talkie mode, you can't hold a normal duplex conversation. 500ms there's more of the talking over each other / "sorry, you go" / "no, you go" dance, but it *is* workable. If your end-user is expecting land-line replacement though... Regards, Tim. From mel at beckman.org Tue Jun 23 09:25:32 2015 From: mel at beckman.org (Mel Beckman) Date: Tue, 23 Jun 2015 09:25:32 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> Message-ID: <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> Harlan, Why should your head explode? Possibly you?re overthinking the problem. And there is no reason (or simple way I can envision) to test my plan, as you advise, in advance. I will just block NTP in my border router temporarily. No need to make a mountain out of this molehill. Cisco, and many other NTP client gear vendors, recommend this approach, and they?ve published extensive research on the matter. -mel > On Jun 23, 2015, at 12:46 AM, Harlan Stenn wrote: > > This stuff can make my head explode. > > When a leap second is added, like on 30 June 2015 at the last second of > the day, POSIX insists that the day still have 86400 seconds in it. > This makes the day longer by one second, so time has to either slow down > or move backwards. > > The "dumb" way to do this is to step the clock back by 1 second at the > instant before the stroke of midnight. > > The allegedly better way to do this would be to stop the clock a bit > before midnight, and hold the time for 1 second. To continue providing > monotonic time, every time somebody says "what time is it" during that > holding period one would want to bump the time by the smallest amount > possible, usually 1 nanosecond (assuming the kernel keeps time in > nanoseconds). > > Ideally you wouldn't want to add enough nanoseconds to cause the clock > to roll over into the next day "too early". > > But apparently nobody has implemented this, even though Prof. Mills > described it in RFC-i-forget about 20 years ago. > > This is mostly because POSIX deals with absolute time and not relative > time. > > In the unlikely event of a leap second deletion, there would be no > 23:59:59, so when the clock is about to strike 23:59:59 it's OK to add > an extra second to the clock to effectively have the time "jump" from > 23:59:58 to 00:00:00. This is still a monotonic increment in time. > > Whatever you decide to do, I recommend you actually test it out to see > if it behaves the way you think it will. You have a whole week still. > > H From nick at foobar.org Tue Jun 23 10:24:43 2015 From: nick at foobar.org (Nick Hilliard) Date: Tue, 23 Jun 2015 11:24:43 +0100 Subject: REMINDER: LEAP SECOND In-Reply-To: <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> Message-ID: <558933EB.6000201@foobar.org> On 23/06/2015 10:25, Mel Beckman wrote: > Why should your head explode? Possibly you?re overthinking the problem. The problems don't relate to Harlan overthinking the problem. They relate to developers underthinking the problem and assuming that all clocks are monotonic and that certain rules apply, e.g. that there are 60 seconds in a minute, 86400 seconds in a day and so forth. Mostly applications are not time sensitive, but sometimes they are. When they are, and when the developer assumes something which isn't true, unexpected things might happen. assert()s can be triggered, time synchronisation lost with third party applications, unexpected and untested code paths could be used, etc. Blocking NTP at the NTP edge will probably work fine for most situations. Bear in mind that your NTP edge is not necessarily the same as your network edge. E.g. you might have internal GPS / radio sources which could unexpectedly inject the leap second. The larger the network, the more likely this is to happen. Most organisations have network fossils and ntp is an excellent source of these. I.e. systems which work away for years without any problems before one day accidentally triggering meltdown because some developer didn't understand the subtleties of clock monotonicity. Nick From frederik at kriewitz.eu Tue Jun 23 12:59:58 2015 From: frederik at kriewitz.eu (Frederik Kriewitz) Date: Tue, 23 Jun 2015 14:59:58 +0200 Subject: Residential VSAT experiences? In-Reply-To: References: Message-ID: On Mon, Jun 22, 2015 at 10:39 PM, Nicholas Oas wrote: > Would anyone mind sharing with me their first-hand experiences with > residential satellite internet? > > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm thinking > specifically as a sysadmin who needs to use the uplink for work, not surf. > > What are your experiences with the following applications? > -SSH, (specifically interactive CLI shell access) > -RDP > -SIP over SSL > -IPSec Tunneling (should be a non-starter due to latency) > -GRE Tunneling Working for an satellite ISP I can give you some technical background. We're only target enterprise/government/military customers with more specific use cases because offering satellite based Internet to residential customers without making them angry while being profitable is hard. So I've no experience with HughesNet Gen4 or ViaSat Exede as products in particular but I know the underling platforms. In general the systems are optimized for fast browsing and VoIP from the own operator. The modems you'll use with the mentioned services will include all kinds of acceleration features. General acceleration of TCP sessions to work around TCP implementation issues in combination the the high RTT (slow start, behavior during packet loss/high jitter, window scaling, ...) are standard for these services. The residential services usually use additional acceleration features like HTTP prefetching/pushing. That's usually done using a transparent HTTP proxy which sits at the teleport analyzing all HTTP requests/responses, download images etc. already before they are actually requested the the end users browser. They are then pushed to the modem which will delivery them as soon as the end user requests them. As a result the end user doesn't have to wait another RTT for the images etc.. Similar sniffing/spoofing acceleration options are available for other protocols. But with end to end encryption becoming more common these days all these transparent higher level acceleration features of the modems, etc. no longer work. Of course you still can do the same but you have to move the acceleration to the client device. That's not very common yet in the satellite industry. Regarding phone conversations our experience is that the high RTT is not that much of an problem in practice. People recognize the delay and wait longer before starting to talk automatically. But the experience might vary extremely depending on the operators config and end devices. You need corresponding QoS settings to keep latency/jitter low and stable. For residential services the return channel will be most likely time division multiplexed. Once the network is congested (=profitable for the operator) you'll see the latency go beyond 1 second more or less often without proper QoS settings. That of course will completely break your VoIP experience. You should expect that the operator only has corresponding QoS settings for their own VoIP service in place. Experience with third party services might suck due to that. Another issue you might run into are some VoIP phones. Some of them only support very small jitter buffers (<10ms) which might cause problems. IPsec tunneling, GRE tunneling etc. should work perfectly fine unless it's intentionally filtered. But as soon as you do tunneling/encryption you should expect that you byepass any acceleration feature or high priority QoS rule. Besides that both products you mentioned AFAIK are using Ka-Band spot beam satellites. There's probably roughly one beam per US state. Assuming 200 MHz per beam that translate to roughly to a maximum of 600-700 Mbit/s downstream capacity shared by all customers in that beam (one state). Upstream is probably designed for half of that. This grouping of customers also makes a simple experience comparison difficult as your experience will heavily depend on the congestion level in your beam. From other similar services we already know that at the launch new customers are happy (always getting the maximum speed) but as the network fills up they get angry due to bad performance during peak times. I really wouldn't recommend a sysadmin to use a geo stationary satellite based connection for your daily work unless there's no other way - simply due to the latency. You'll notice a significant productivity impact. Best Regards, Frederik Kriewitz From cb.list6 at gmail.com Tue Jun 23 13:01:41 2015 From: cb.list6 at gmail.com (Ca By) Date: Tue, 23 Jun 2015 06:01:41 -0700 Subject: Thanks aws / gcc / azure Message-ID: Since you have failed to achieve in the modest task that was your charge You now get this https://www.markshuttleworth.com/archives/1471 Or s/money/addresses/ http://youtu.be/pA8f-Nh5gRs From jared at puck.nether.net Tue Jun 23 13:07:42 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 23 Jun 2015 09:07:42 -0400 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> Message-ID: > On Jun 22, 2015, at 7:06 PM, Harlan Stenn wrote: > > Time going backwards is deadly to a number of applications. > > But apparently not to applications you care about. Oh it is a problem, and most handle it very ungracefully, such as dovecot which just dies: http://wiki.dovecot.org/TimeMovedBackwards The issue is also most people are used to using rc.local or rc.* type scripts to spawn a daemon which leads to the next major sysadmin/developer problem with is handling error cases improperly or not at all. (86401 is perhaps and error case that people should test for). - Jared From jared at puck.nether.net Tue Jun 23 13:16:35 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 23 Jun 2015 09:16:35 -0400 Subject: RES: REMINDER: LEAP SECOND In-Reply-To: <59E8C16E83D82B439E20698AAC790B5F01384981B8@ma45> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> <59E8C16E83D82B439E20698AAC790B5F01384981B8@ma45> Message-ID: <8EA727B0-0A6E-4DF9-B452-C6B856890106@puck.nether.net> If you don?t have NTP enabled your clock may be wrong so it likely won?t impact you. I?ve always had trouble getting NTP to work right over the years for a variety of reasons. Just set something in cron to ntpdate -u your host on july 1st and you should be good. - Jared > On Jun 23, 2015, at 9:14 AM, Leonardo Oliveira Ortiz wrote: > > Guys, if we don't have NTP enable on our Linux we still have problem with leap second ?? > > > > > -----Mensagem original----- > De: NANOG [mailto:nanog-bounces at nanog.org] Em nome de Jared Mauch > Enviada em: ter?a-feira, 23 de junho de 2015 10:08 > Para: Harlan Stenn > Cc: nanog at nanog.org > Assunto: Re: REMINDER: LEAP SECOND > > >> On Jun 22, 2015, at 7:06 PM, Harlan Stenn wrote: >> >> Time going backwards is deadly to a number of applications. >> >> But apparently not to applications you care about. > > Oh it is a problem, and most handle it very ungracefully, such as dovecot which just dies: > > http://wiki.dovecot.org/TimeMovedBackwards > > The issue is also most people are used to using rc.local or rc.* type scripts to spawn a daemon which leads to the next major sysadmin/developer problem with is handling error cases improperly or not at all. (86401 is perhaps and error case that people should test for). > > - Jared From jared at puck.nether.net Tue Jun 23 13:26:44 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 23 Jun 2015 09:26:44 -0400 Subject: Thanks aws / gcc / azure In-Reply-To: References: Message-ID: <947BBFEC-7911-4FED-8AC4-0B3B64D2C493@puck.nether.net> > On Jun 23, 2015, at 9:01 AM, Ca By wrote: > > Since you have failed to achieve in the modest task that was your charge > > You now get this > > https://www.markshuttleworth.com/archives/1471 > > Or s/money/addresses/ > > http://youtu.be/pA8f-Nh5gRs Cameron, I share your disappointment that IPv6 isn?t available and has kept me away from these platforms for my activities. Using the 240/4 net can be useful but misses the point for many cases. I will say what kinky things people do in their own private networks I am less concerned about, but when it prevents proper IPv6 from occurring, that is a problem. - Jared From rafael at gav.ufsc.br Tue Jun 23 13:37:30 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Tue, 23 Jun 2015 08:37:30 -0500 Subject: Residential VSAT experiences? In-Reply-To: <1732312919.8922.1435049080582.JavaMail.zimbra@pelican.org> References: <274163724-1435013345-cardhu_decombobulator_blackberry.rim.net-1126150793-@b1.c3.bise6.blackberry> <1732312919.8922.1435049080582.JavaMail.zimbra@pelican.org> Message-ID: Reading about SIP made it seem like latency alone is not an issue, aside from delays which impact verbal communication as previously mentioned. What is going to be much worse is jitter and packet loss. You can eventually get used to a significant delay, but dropped calls and chopped sound renders the service useless. On Tue, Jun 23, 2015 at 3:44 AM, Tim Franklin wrote: > > Interesting that you say that about sip. We had a client that would use > it > > for sip on ships all the time. It wasn't the best but it worked. Ping > times > > were between 500-700ms. > > It really depends on your expectations - or more to the point, your > end-users' expectations. > > I've tested SIP in the lab up to 2000ms RTT. The protocols all hang > together and keep working, but it's obviously very much in walkie-talkie > mode, you can't hold a normal duplex conversation. 500ms there's more of > the talking over each other / "sorry, you go" / "no, you go" dance, but it > *is* workable. If your end-user is expecting land-line replacement > though... > > Regards, > Tim. > > From jared at puck.Nether.net Tue Jun 23 14:02:51 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Tue, 23 Jun 2015 10:02:51 -0400 Subject: Residential VSAT experiences? In-Reply-To: <54EAD60A-0A03-4240-8967-ADE3642C2DF4@oitc.com> References: <54EAD60A-0A03-4240-8967-ADE3642C2DF4@oitc.com> Message-ID: <20150623140251.GA31669@puck.nether.net> On Mon, Jun 22, 2015 at 09:11:17PM -0400, TR Shaw wrote: > I don?t know what your location is but a wireless internet provider using Canopy or Ubiquity or whatever is much more preferable. Also cellular is used in ?remote? locations with good results. Using the UBNT gear if you can put together a link is really what you want to do. The equipment is cheap as in disposable and if you install it properly you should have almost no issues even with adverse weather. Even using something like the NSM5 back to back and constructing a multi-link path will end up producing nice results. Make sure you have clear line of sight and plan for any tree growth along the route. I've been using a WISP that has the UBNT gear for years now with no outages attributed to the equipment. > I have used SSH from a transatlantic flight but the delay can weigh on you ;-) I did as well this last time on my way to europe and it worked better than I expected. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From bill at herrin.us Tue Jun 23 14:24:58 2015 From: bill at herrin.us (William Herrin) Date: Tue, 23 Jun 2015 10:24:58 -0400 Subject: Residential VSAT experiences? In-Reply-To: References: <274163724-1435013345-cardhu_decombobulator_blackberry.rim.net-1126150793-@b1.c3.bise6.blackberry> <1732312919.8922.1435049080582.JavaMail.zimbra@pelican.org> Message-ID: On Tue, Jun 23, 2015 at 9:37 AM, Rafael Possamai wrote: > Reading about SIP made it seem like latency alone is not an issue, aside > from delays which impact verbal communication as previously mentioned. What > is going to be much worse is jitter and packet loss. You can eventually get > used to a significant delay, but dropped calls and chopped sound renders > the service useless. With modern software implementing a responsive jitter buffer, jitter shouldn't be much of a problem. Practical effect would be a longer delay as the receiver buffers enough packets to deal with the measured variance in receipt times. Perhaps a few chops early in the conversation as the software grows the buffer. Not all SIP implementations are equal. Try yours in a high-jitter environment and see what happens. High packet loss is deadly. That'll depend on the satellite vendor's network implementation, the weather, etc. But then high packet loss is deadly to essentially all IP networking activity. In situations where a high bit error rate (BER) is endemic, the layer-2 vendor is expected to redress that with forward error correction (FEC) and retransmission that trades jitter for loss. I have no idea which satellite vendors are better or worse about this. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From rdobbins at arbor.net Tue Jun 23 15:13:41 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 23 Jun 2015 22:13:41 +0700 Subject: Residential VSAT experiences? In-Reply-To: References: Message-ID: On 23 Jun 2015, at 3:39, Nicholas Oas wrote: > What are your experiences with the following applications? > -SSH, (specifically interactive CLI shell access) > -RDP > -SIP over SSL > -IPSec Tunneling (should be a non-starter due to latency) > -GRE Tunneling Latency, latency, latency, RTTs, RTTs, RTTs. Not an option for anything interactive, very poor for general user-type Internet access. ----------------------------------- Roland Dobbins From leonardo.ortiz at marisolsa.com Tue Jun 23 13:14:42 2015 From: leonardo.ortiz at marisolsa.com (Leonardo Oliveira Ortiz) Date: Tue, 23 Jun 2015 13:14:42 +0000 Subject: RES: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> Message-ID: <59E8C16E83D82B439E20698AAC790B5F01384981B8@ma45> Guys, if we don't have NTP enable on our Linux we still have problem with leap second ?? -----Mensagem original----- De: NANOG [mailto:nanog-bounces at nanog.org] Em nome de Jared Mauch Enviada em: ter?a-feira, 23 de junho de 2015 10:08 Para: Harlan Stenn Cc: nanog at nanog.org Assunto: Re: REMINDER: LEAP SECOND > On Jun 22, 2015, at 7:06 PM, Harlan Stenn wrote: > > Time going backwards is deadly to a number of applications. > > But apparently not to applications you care about. Oh it is a problem, and most handle it very ungracefully, such as dovecot which just dies: http://wiki.dovecot.org/TimeMovedBackwards The issue is also most people are used to using rc.local or rc.* type scripts to spawn a daemon which leads to the next major sysadmin/developer problem with is handling error cases improperly or not at all. (86401 is perhaps and error case that people should test for). - Jared From Alex.Hardie at nominum.com Tue Jun 23 14:31:25 2015 From: Alex.Hardie at nominum.com (Alex Hardie) Date: Tue, 23 Jun 2015 14:31:25 +0000 Subject: NANOG Digest, Vol 89, Issue 24 In-Reply-To: References: Message-ID: <7245D3644B58AE47A4008980D8336EFD25A57AF4@mbx-02> Not to inject more confusion - but GPS and NTP are noted in the thread... but not PTP (IEEE1588)? alex hardie | +1 404 229 7635 | www.nominum.com -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of nanog-request at nanog.org Sent: Tuesday, June 23, 2015 8:00 AM To: nanog at nanog.org Subject: NANOG Digest, Vol 89, Issue 24 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: REMINDER: LEAP SECOND (Tony Finch) 2. Re: REMINDER: LEAP SECOND (Stephane Bortzmeyer) 3. Re: REMINDER: LEAP SECOND (Bjoern A. Zeeb) 4. Re: REMINDER: LEAP SECOND (Stephane Bortzmeyer) 5. Re: REMINDER: LEAP SECOND (Tony Finch) 6. Re: REMINDER: LEAP SECOND (Alan Buxey) 7. Re: REMINDER: LEAP SECOND (Saku Ytti) 8. Re: REMINDER: LEAP SECOND (Randy Bush) 9. Re: REMINDER: LEAP SECOND (shawn wilson) 10. Re: REMINDER: LEAP SECOND (Tony Finch) 11. Re: Data Center Network Monitoring with TAPs (Rafael Possamai) 12. Re: REMINDER: LEAP SECOND (Harlan Stenn) 13. Facebook contact, images issues in IL/WI (David Sovereen) 14. Re: REMINDER: LEAP SECOND (Marshall Eubanks) 15. Residential VSAT experiences? (Nicholas Oas) 16. Core alignment fusion splicers (Peter Kranz) 17. Re: Core alignment fusion splicers (Mel Beckman) 18. AW: Core alignment fusion splicers (J?rgen Jaritsch) 19. Re: Residential VSAT experiences? (William Herrin) 20. Re: REMINDER: LEAP SECOND (Doug Barton) 21. Re: Residential VSAT experiences? (Mike Lyon) 22. Re: Residential VSAT experiences? (Fred Baker (fred)) 23. Re: Residential VSAT experiences? (Dovid Bender) 24. Re: Residential VSAT experiences? (Mike Lyon) 25. Re: Residential VSAT experiences? (Hugo Slabbert) 26. Re: REMINDER: LEAP SECOND (Harlan Stenn) 27. Re: Residential VSAT experiences? (Mike Hale) 28. Re: Residential VSAT experiences? (Michael Conlen) 29. Re: Residential VSAT experiences? (Scott Weeks) 30. Fwd: Residential VSAT experiences? (Alfred Olton) 31. Re: Residential VSAT experiences? (Lyndon Nerenberg) 32. Re: Residential VSAT experiences? (TR Shaw) 33. Re: Residential VSAT experiences? (Dave Crocker) 34. Re: Residential VSAT experiences? (Mikael Abrahamsson) 35. Re: Residential VSAT experiences? (Dave Taht) 36. Re: REMINDER: LEAP SECOND (Mel Beckman) 37. Re: REMINDER: LEAP SECOND (Harlan Stenn) 38. Re: Residential VSAT experiences? (Tim Franklin) 39. Re: REMINDER: LEAP SECOND (Mel Beckman) 40. Re: REMINDER: LEAP SECOND (Nick Hilliard) ---------------------------------------------------------------------- Message: 1 Date: Mon, 22 Jun 2015 13:15:41 +0100 From: Tony Finch To: Harlan Stenn Cc: Saku Ytti , nanog at nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII Harlan Stenn wrote: > It's a problem with POSIX, not UTC. > > UTC is monotonic. The problems are that UTC is unpredictable, and it breaks the standard labelling of points in time that was used for hundreds (arguably thousands) of years before 1972. Tony. -- f.anthony.n.finch http://dotat.at/ Irish Sea: Northwesterly 4 or 5, occasionally 6 at first, becoming variable 4. Slight or moderate. Mainly fair. Good. ------------------------------ Message: 2 Date: Mon, 22 Jun 2015 14:27:18 +0200 From: Stephane Bortzmeyer To: Tony Finch Cc: Harlan Stenn , nanog at nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: <20150622122718.GA10690 at nic.fr> Content-Type: text/plain; charset=us-ascii On Mon, Jun 22, 2015 at 01:15:41PM +0100, Tony Finch wrote a message of 15 lines which said: > The problems are that UTC is unpredictable, That's because the earth rotation is unpredictable. Any time based on this buggy planet's movements will be unpredictable. Let's patch it now! ------------------------------ Message: 3 Date: Mon, 22 Jun 2015 12:38:28 +0000 From: "Bjoern A. Zeeb" To: Stephane Bortzmeyer Cc: Tony Finch , nanog at nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: <8C40413B-B22C-4BCE-85D2-B4F93A233628 at lists.zabbadoz.net> Content-Type: text/plain; charset=us-ascii > On 22 Jun 2015, at 12:27 , Stephane Bortzmeyer wrote: > > On Mon, Jun 22, 2015 at 01:15:41PM +0100, > Tony Finch wrote > a message of 15 lines which said: > >> The problems are that UTC is unpredictable, > > That's because the earth rotation is unpredictable. Any time based on > this buggy planet's movements will be unpredictable. Let's patch it > now! So we need a new center of the universe and switch to stardate and thus solve the 32bit UNIX time problem for real this time? ------------------------------ Message: 4 Date: Mon, 22 Jun 2015 14:44:15 +0200 From: Stephane Bortzmeyer To: "Bjoern A. Zeeb" Cc: Stephane Bortzmeyer , Tony Finch , nanog at nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: <20150622124415.GA12276 at nic.fr> Content-Type: text/plain; charset=us-ascii On Mon, Jun 22, 2015 at 12:38:28PM +0000, Bjoern A. Zeeb wrote a message of 17 lines which said: > So we need a new center of the universe and switch to stardate and > thus solve the 32bit UNIX time problem for real this time? Or simply use TAI which is the obvious time reference for Internet devices. Using UTC in routers is madness. Routers and Internet servers should use TAI internally and use UTC only when communicating with humans (the inferior life form which crawls on the Earth surface and cares about things like whether the sun is high at noon, for outside picnics). ------------------------------ Message: 5 Date: Mon, 22 Jun 2015 13:55:20 +0100 From: Tony Finch To: Stephane Bortzmeyer Cc: nanog at nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII Stephane Bortzmeyer wrote: > > That's because the earth rotation is unpredictable. Any time based on > this buggy planet's movements will be unpredictable. Let's patch it > now! http://mm.icann.org/pipermail/tz/2015-May/022280.html http://mm.icann.org/pipermail/tz/2015-May/022281.html http://mm.icann.org/pipermail/tz/2015-May/022282.html Tony. -- f.anthony.n.finch http://dotat.at/ Northwest Faeroes, Southeast Iceland: Northeasterly 3 or 4. Moderate, becoming mainly slight. Mainly fair. Good, occasionally poor in Southeast Iceland. ------------------------------ Message: 6 Date: Mon, 22 Jun 2015 12:56:44 +0000 From: Alan Buxey To: "Bjoern A. Zeeb" , Stephane Bortzmeyer Cc: "nanog at nanog.org" Subject: Re: REMINDER: LEAP SECOND Message-ID: Content-Type: text/plain; charset="iso-8859-1" I do feel sorry for you unix/linux users having a problem in year 2038.... fortunately I get another ~ 8 years... my Amiga gets its first big problem in 2046 ;-) http://web.archive.org/web/19981203142814/http://www.amiga.com/092098-y2k.html alan PS if i get to see the 2078 issue I'll be old enough to fuss about other things than a 2 digit date display..and I'm sure if I'm around until 7 February, 2114, 06:28:16 I'll have more to worry about than an old Amiga finally reaching the end of its useful life...unless its actually driving my life support system! ;-) ------------------------------ Message: 7 Date: Mon, 22 Jun 2015 16:23:11 +0300 From: Saku Ytti To: nanog at nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: <20150622132311.GA14699 at pob.ytti.fi> Content-Type: text/plain; charset=us-ascii On (2015-06-22 14:44 +0200), Stephane Bortzmeyer wrote: > Or simply use TAI which is the obvious time reference for Internet > devices. Using UTC in routers is madness. Routers and Internet servers > should use TAI internally and use UTC only when communicating with > humans (the inferior life form which crawls on the Earth surface and > cares about things like whether the sun is high at noon, for outside > picnics). I couldn't agree more. But out of curiosity does anyone have scoop why TAI exists? I believe GPSTIME predates it, which appears analogous to TAI. -- ++ytti ------------------------------ Message: 8 Date: Mon, 22 Jun 2015 23:17:52 +0900 From: Randy Bush To: Stephane Bortzmeyer Cc: North American Network Operators' Group Subject: Re: REMINDER: LEAP SECOND Message-ID: Content-Type: text/plain; charset=US-ASCII we can just turn the internet off for an hour until the dust settles. ------------------------------ Message: 9 Date: Mon, 22 Jun 2015 14:17:53 +0000 From: shawn wilson To: Stephane Bortzmeyer , Tony Finch Cc: nanog at nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: Content-Type: text/plain; charset=UTF-8 On Mon, Jun 22, 2015, 08:29 Stephane Bortzmeyer wrote: > On Mon, Jun 22, 2015 at 01:15:41PM +0100, > Tony Finch wrote > a message of 15 lines which said: > > > The problems are that UTC is unpredictable, > > That's because the earth rotation is unpredictable. Any time based on > this buggy planet's movements will be unpredictable. Let's patch it > now! > > So, what we should do is make clocks move. 99999 slower half of the year (and then speed back up) so that we're really in line with earth's rotational time. I mean we've got the computers to do it (I think most RTC only go down to thousandths so it'll still need a little skewing but I'm sure we'll manage). Ps - if anyone actually does this, I'm going postal. ------------------------------ Message: 10 Date: Mon, 22 Jun 2015 15:27:42 +0100 From: Tony Finch To: shawn wilson Cc: Stephane Bortzmeyer , nanog at nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII shawn wilson wrote: > So, what we should do is make clocks move. 99999 slower half of the year > (and then speed back up) so that we're really in line with earth's > rotational time. That's how UTC worked in the 1960s. ftp://maia.usno.navy.mil/ser7/tai-utc.dat It causes problems for systems that have a tight coupling between time and frequency - broadcast, cellular, etc. Tony. -- f.anthony.n.finch http://dotat.at/ Fair Isle, Southeast Faeroes: Northeasterly 5 or 6 backing northerly 4 or 5. Moderate, occasionally rough at first. Mainly fair. Good. ------------------------------ Message: 11 Date: Mon, 22 Jun 2015 11:44:41 -0500 From: Rafael Possamai To: Mitch Howards Cc: "nanog at nanog.org" Subject: Re: Data Center Network Monitoring with TAPs Message-ID: Content-Type: text/plain; charset=UTF-8 Here's a recent forum thread that discussed the same exact topic. You might find some insight: http://www.reddit.com/r/networking/comments/3aip3p/data_center_network_monitoring/ On Sat, Jun 20, 2015 at 11:06 AM, Mitch Howards wrote: > Hello All, > > Was wondering what folks are using to monitor traffic > on their networks. Looking into Ixia and APCON devices for dedup and > other filtering features as well as passive fiber TAPs to capture the > traffic. > > How are folks handling TAP'ing large data center > networks? TAPs at the "distribution layer" would be the best fit for my > network but that would require a ton of passive fiber TAPs for the > incoming fibers to the distribution switches. The end goal is to not > only capture the north-south traffic on the network but also east-west > traffic. It seems more efficient to just use SPANs but there are many > limitations using SPANs. > > Thanks in advance for any suggestions. > > Mitch ------------------------------ Message: 12 Date: Mon, 22 Jun 2015 17:58:54 +0000 From: Harlan Stenn To: Tony Finch Cc: Harlan Stenn , Saku Ytti , nanog at nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: Content-Type: text/plain; charset=US-ASCII Tony Finch writes: > Harlan Stenn wrote: > > > It's a problem with POSIX, not UTC. > > > > UTC is monotonic. > > The problems are that UTC is unpredictable, and it breaks the standard > labelling of points in time that was used for hundreds (arguably > thousands) of years before 1972. You mean back when seconds were rubbery, and before the earth's rotational speed could be easily and accurately measured, or at least when the wobbles at that level of accuracy became so noticeable that they could no longer be ignored? H ------------------------------ Message: 13 Date: Mon, 22 Jun 2015 14:54:09 -0400 From: David Sovereen To: nanog at nanog.org Subject: Facebook contact, images issues in IL/WI Message-ID: <7FDC076C-51E9-4006-90B6-5991BC33D8DC at mercury.net> Content-Type: text/plain; charset=utf-8 Hello, If someone from Facebook is reading, please contact me off-list. Since last Thursday, our customers have been having image loading problems at Facebook.com We know it?s not just us?many users are reporting similar problems at https://downdetector.com/status/facebook/map/ Would like to help get this resolved. Thanks, Dave ====================================================================== MERCURY NETWORK CORPORATION David Sovereen 920-686-4800 x 151 1011 Washington St Ste 3, Manitowoc, WI 54220-5248 http://www.mercury.net ------------------------------ Message: 14 Date: Mon, 22 Jun 2015 15:36:32 -0400 From: Marshall Eubanks To: Stephane Bortzmeyer Cc: "Bjoern A. Zeeb" , "nanog at nanog.org" Subject: Re: REMINDER: LEAP SECOND Message-ID: Content-Type: text/plain; charset=UTF-8 On Mon, Jun 22, 2015 at 8:44 AM, Stephane Bortzmeyer wrote: > On Mon, Jun 22, 2015 at 12:38:28PM +0000, > Bjoern A. Zeeb wrote > a message of 17 lines which said: > > > So we need a new center of the universe and switch to stardate and > > thus solve the 32bit UNIX time problem for real this time? > > Or simply use TAI which is the obvious time reference for Internet > devices. Using UTC in routers is madness. Routers and Internet servers > should use TAI internally and use UTC only when communicating with > humans (the inferior life form which crawls on the Earth surface and > cares about things like whether the sun is high at noon, for outside > picnics). > > If the Earth's core ever decides to have some real fun and causes there to be a negative leap second (there is historical precedent for this, albeit before the existence of UTC and atomic time) there would be a minute with only 59 seconds, and I would expect things to break in new and creative ways. We live in a relatively narrow slice of time (a few decades) where this is a possibility, but it is a possibility. (Note that the number of leap seconds per year has _slowed_ recently, corresponding to a speed up in the long term averaged rotation of the Earth. If that speed up of the Earth's rotation were to happen again, negative leap seconds would be inevitable.) The drift between the Earth's time and atomic time will just get worse over longer time frames (see http://www.ucolick.org/~sla/leapsecs/year2100.html ). Even if UTC - TAI is just fixed (i.e., no more leap seconds), that is just pushing the problem down the road, and our grandkids will have to deal with leap minutes, or our remoter descendants with leap hours. >It's a problem with POSIX, not UTC. Yes. I remember this being raised by people at the USNO back in the early 1990's, but there was no interest in changing POSIX. Too much installed base was the reason stated IIRC. My opinion is (and has been since the early 90's) that the computer / Internet world should just adopt IAT as the time system in use. That is the best time we have, and it will never have steps. Yes, that means that you would need something like a time zone file to set your system clock by hand from local (UTC) time, but, then, we already have to have time zone files. Regards Marshall Eubanks ------------------------------ Message: 15 Date: Mon, 22 Jun 2015 16:39:27 -0400 From: Nicholas Oas To: "nanog at nanog.org" Subject: Residential VSAT experiences? Message-ID: Content-Type: text/plain; charset=UTF-8 Would anyone mind sharing with me their first-hand experiences with residential satellite internet? Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm thinking specifically as a sysadmin who needs to use the uplink for work, not surf. What are your experiences with the following applications? -SSH, (specifically interactive CLI shell access) -RDP -SIP over SSL -IPSec Tunneling (should be a non-starter due to latency) -GRE Tunneling Thank you, -Nicholas ------------------------------ Message: 16 Date: Mon, 22 Jun 2015 13:58:21 -0700 From: "Peter Kranz" To: Subject: Core alignment fusion splicers Message-ID: <20ac01d0ad2e$2c76fa00$8564ee00$@unwiredltd.com> Content-Type: text/plain; charset="us-ascii" Curious if any of you have favorites when it comes to fusion splicers.. There is a huge range in price for units that appear to be very similar in both specifications and appearance. Currently considering standardizing on the INNO View 5 http://www.innoinstrument.com/new/splicer/view5.php , but we need enough of these units I'd love stories from the field before dropping the order. Peter Kranz www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz at unwiredltd.com ------------------------------ Message: 17 Date: Mon, 22 Jun 2015 21:06:09 +0000 From: Mel Beckman To: Peter Kranz Cc: "" Subject: Re: Core alignment fusion splicers Message-ID: Content-Type: text/plain; charset="utf-8" Don?t buy to start. Instead, rent a few different brands for splicing projects until you know what features you need and want. And don?t scrimp on the cleaver. Get a quality automatic cleaver (these usually come in the rental bundle). -mel > On Jun 22, 2015, at 1:58 PM, Peter Kranz wrote: > > Curious if any of you have favorites when it comes to fusion splicers.. > There is a huge range in price for units that appear to be very similar in > both specifications and appearance. Currently considering standardizing on > the INNO View 5 http://www.innoinstrument.com/new/splicer/view5.php , but we > need enough of these units I'd love stories from the field before dropping > the order. > > > > Peter Kranz > www.UnwiredLtd.com > Desk: 510-868-1614 x100 > Mobile: 510-207-0000 > pkranz at unwiredltd.com > > > ------------------------------ Message: 18 Date: Mon, 22 Jun 2015 21:07:41 +0000 From: J?rgen Jaritsch To: Peter Kranz , "nanog at nanog.org" Subject: AW: Core alignment fusion splicers Message-ID: <515026f2064b40768f82af92334ba8f4 at anx-i-dag02.anx.local> Content-Type: text/plain; charset="iso-8859-1" Hi, We do not have the new View-series but we're working with the IFS-10: http://www.innoinstrument.com/new/splicer/ifs10.php Easy to use. Works quite good under rough conditions. Not THAT expensive. Battery lifetime is ok. Best regards J?rgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj at anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstra?e 140, 9020 Klagenfurt Gesch?ftsf?hrer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -----Urspr?ngliche Nachricht----- Von: NANOG [mailto:nanog-bounces at nanog.org] Im Auftrag von Peter Kranz Gesendet: Montag, 22. Juni 2015 22:58 An: nanog at nanog.org Betreff: Core alignment fusion splicers Curious if any of you have favorites when it comes to fusion splicers.. There is a huge range in price for units that appear to be very similar in both specifications and appearance. Currently considering standardizing on the INNO View 5 http://www.innoinstrument.com/new/splicer/view5.php , but we need enough of these units I'd love stories from the field before dropping the order. Peter Kranz www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz at unwiredltd.com ------------------------------ Message: 19 Date: Mon, 22 Jun 2015 18:11:38 -0400 From: William Herrin To: Nicholas Oas Cc: "nanog at nanog.org" Subject: Re: Residential VSAT experiences? Message-ID: Content-Type: text/plain; charset=UTF-8 On Mon, Jun 22, 2015 at 4:39 PM, Nicholas Oas wrote: > Would anyone mind sharing with me their first-hand experiences with > residential satellite internet? Hi Nicholas, Two-way satellite systems based on SV's in geostationary orbit (like the two you're considering) have high latency. 22,000 miles out, another 22,000 miles back and do it again for the return packet. You'll start around 500ms latency and go up from there. Any kind of interactive session (like SSH and RDP) will be excruciating. I'm not aware of any low earth orbit systems providing residential Internet. Iridium tries to but the bandwidth is pathetic (2400bps or so). LEO vehicles are only 500-1000 miles up. Latency is high compared to wireline systems but within usable bounds for interactive sessions. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: ------------------------------ Message: 20 Date: Mon, 22 Jun 2015 15:18:14 -0700 From: Doug Barton To: nanog at nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: <558889A6.10704 at dougbarton.us> Content-Type: text/plain; charset="utf-8"; Format="flowed" On 6/19/15 2:58 PM, Harlan Stenn wrote: > Bad idea. > > When restarting ntpd your clocks will likely be off by a second, which > will cause a backward step, which will force the problem you claim to be > avoiding. > > There are plenty of ways to solve this problem, and you just get to > choose what you want to risk/pay. You misunderstand the problem. :) The problem is not "clock skips backward one second," because most of the time that's not what happens. The problem is that most software does not handle it well when the clock ticks ... :59 :60 :00 instead of ticking directly from :59 to :00. THAT problem is avoided by temporarily turning off NTP and then turning it back on again when "the coast is clear." Most software can handle the "clock skips forward or backwards one second" problem fairly robustly, and as Baldur pointed out by doing the reset in a controlled manner you greatly reduce your overall risk. Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: ------------------------------ Message: 21 Date: Mon, 22 Jun 2015 15:33:43 -0700 From: Mike Lyon To: Nicholas Oas , NANOG Subject: Re: Residential VSAT experiences? Message-ID: Content-Type: text/plain; charset=UTF-8 SIP will suck. VPN will suck. RDP will suck. Have you looked to see if you have any local wireless ISPs in your area? Hit me up offlist if you want me to check for you. -Mike On Mon, Jun 22, 2015 at 1:39 PM, Nicholas Oas wrote: > Would anyone mind sharing with me their first-hand experiences with > residential satellite internet? > > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm thinking > specifically as a sysadmin who needs to use the uplink for work, not surf. > > What are your experiences with the following applications? > -SSH, (specifically interactive CLI shell access) > -RDP > -SIP over SSL > -IPSec Tunneling (should be a non-starter due to latency) > -GRE Tunneling > > Thank you, > > -Nicholas > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon ------------------------------ Message: 22 Date: Mon, 22 Jun 2015 22:35:45 +0000 From: "Fred Baker (fred)" To: William Herrin , Nicholas Oas Cc: "nanog at nanog.org" Subject: Re: Residential VSAT experiences? Message-ID: <8EAA4E3F-C17F-4988-990F-808E4E03FA5F at cisco.com> Content-Type: text/plain; charset="us-ascii" > On Jun 22, 2015, at 3:11 PM, William Herrin wrote: > > Two-way satellite systems based on SV's in geostationary orbit (like > the two you're considering) have high latency. 22,000 miles out, > another 22,000 miles back and do it again for the return packet. > You'll start around 500ms latency and go up from there. Any kind of > interactive session (like SSH and RDP) will be excruciating. It is indeed. This is first-hand in the sense that I once worked for an earth station manufacturer and did a fair bit of work related to this environment, and second-hand in that my sister, for a while, used VSAT connectivity to her home. The trick in the context is what's called a "performance-enhancing proxy", or PEP. What it does, in concept, is terminate a TCP connection at each earth station and use some form of private protocol over the bird. Cisco RBSCP (which maps TCP connections to SCTP sessions over the bird, http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/interface/configuration/15-sy/ir-15-sy-book/ir-rt-bsd-sat.html) is an example of such a technology. The obvious benefit of a PEP is that it can convince a TCP sender to keep enough data in flight to make good use of the throughput rate of the satellite - you have a start-up issue with the first RTT, but after that it has essentially figured out what the effective window should be and makes that happen. The downside of a PEP is when the application is itself interactive (it's not about rate, it's about responsiveness clocked by end-to-end RTT) or the protocol in question isn't TCP (noting that TCP in IPsec ESP isn't TCP to the PEP - it's IPsec ESP, and can 't be goosed along). In my sister's case, her description of the service was somewhat colorful, and included the word "slow". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: Message signed with OpenPGP using GPGMail URL: ------------------------------ Message: 23 Date: Mon, 22 Jun 2015 22:49:04 +0000 From: "Dovid Bender" To: "Mike Lyon" , "NANOG" , "Nicholas Oas" , "NANOG" Subject: Re: Residential VSAT experiences? Message-ID: <274163724-1435013345-cardhu_decombobulator_blackberry.rim.net-1126150793- at b1.c3.bise6.blackberry> Content-Type: text/plain; charset="utf-8" Interesting that you say that about sip. We had a client that would use it for sip on ships all the time. It wasn't the best but it worked. Ping times were between 500-700ms. Regards, Dovid -----Original Message----- From: Mike Lyon Sender: "NANOG" Date: Mon, 22 Jun 2015 15:33:43 To: Nicholas Oas; NANOG Subject: Re: Residential VSAT experiences? SIP will suck. VPN will suck. RDP will suck. Have you looked to see if you have any local wireless ISPs in your area? Hit me up offlist if you want me to check for you. -Mike On Mon, Jun 22, 2015 at 1:39 PM, Nicholas Oas wrote: > Would anyone mind sharing with me their first-hand experiences with > residential satellite internet? > > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm thinking > specifically as a sysadmin who needs to use the uplink for work, not surf. > > What are your experiences with the following applications? > -SSH, (specifically interactive CLI shell access) > -RDP > -SIP over SSL > -IPSec Tunneling (should be a non-starter due to latency) > -GRE Tunneling > > Thank you, > > -Nicholas > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon ------------------------------ Message: 24 Date: Mon, 22 Jun 2015 15:54:49 -0700 From: Mike Lyon To: dovid at telecurve.com Cc: NANOG , Nicholas Oas , NANOG Subject: Re: Residential VSAT experiences? Message-ID: Content-Type: text/plain; charset=UTF-8 I never had good luck with VSAT and SIP. Maybe you had a better kit than I did :) -Mike On Mon, Jun 22, 2015 at 3:49 PM, Dovid Bender wrote: > Interesting that you say that about sip. We had a client that would use it > for sip on ships all the time. It wasn't the best but it worked. Ping times > were between 500-700ms. > > > > Regards, > > Dovid > > -----Original Message----- > From: Mike Lyon > Sender: "NANOG" Date: Mon, 22 Jun 2015 15:33:43 > To: Nicholas Oas; NANOG > Subject: Re: Residential VSAT experiences? > > SIP will suck. VPN will suck. RDP will suck. > > Have you looked to see if you have any local wireless ISPs in your area? > Hit me up offlist if you want me to check for you. > > -Mike > > > On Mon, Jun 22, 2015 at 1:39 PM, Nicholas Oas > wrote: > > > Would anyone mind sharing with me their first-hand experiences with > > residential satellite internet? > > > > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm > thinking > > specifically as a sysadmin who needs to use the uplink for work, not > surf. > > > > What are your experiences with the following applications? > > -SSH, (specifically interactive CLI shell access) > > -RDP > > -SIP over SSL > > -IPSec Tunneling (should be a non-starter due to latency) > > -GRE Tunneling > > > > Thank you, > > > > -Nicholas > > > > > > -- > Mike Lyon > 408-621-4826 > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon ------------------------------ Message: 25 Date: Mon, 22 Jun 2015 16:04:55 -0700 From: Hugo Slabbert To: Mike Lyon Cc: dovid at telecurve.com, NANOG , NANOG Subject: Re: Residential VSAT experiences? Message-ID: <20150622230455.GO28830 at bamboo.slabnet.com> Content-Type: text/plain; charset="us-ascii"; Format="flowed" Personally, 500-700ms of delay is well within distinguishable range and causes challenges in verbal communication. If the speakers are both expecting and accustomed to delay like that (e.g. sailors that are used to being hundreds/thousands of miles away from anywhere and any other comms solution sucks anyway), it could be workable. For regular consumer/business voice applications, 100ms and lower is decent, but above that starts to get into various degrees of suckage. Just my 2c. -- Hugo On Mon 2015-Jun-22 15:54:49 -0700, Mike Lyon wrote: >I never had good luck with VSAT and SIP. Maybe you had a better kit than I >did :) > >-Mike > > >On Mon, Jun 22, 2015 at 3:49 PM, Dovid Bender wrote: > >> Interesting that you say that about sip. We had a client that would use it >> for sip on ships all the time. It wasn't the best but it worked. Ping times >> were between 500-700ms. >> >> >> >> Regards, >> >> Dovid >> >> -----Original Message----- >> From: Mike Lyon >> Sender: "NANOG" Date: Mon, 22 Jun 2015 15:33:43 >> To: Nicholas Oas; NANOG >> Subject: Re: Residential VSAT experiences? >> >> SIP will suck. VPN will suck. RDP will suck. >> >> Have you looked to see if you have any local wireless ISPs in your area? >> Hit me up offlist if you want me to check for you. >> >> -Mike >> >> >> On Mon, Jun 22, 2015 at 1:39 PM, Nicholas Oas >> wrote: >> >> > Would anyone mind sharing with me their first-hand experiences with >> > residential satellite internet? >> > >> > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm >> thinking >> > specifically as a sysadmin who needs to use the uplink for work, not >> surf. >> > >> > What are your experiences with the following applications? >> > -SSH, (specifically interactive CLI shell access) >> > -RDP >> > -SIP over SSL >> > -IPSec Tunneling (should be a non-starter due to latency) >> > -GRE Tunneling >> > >> > Thank you, >> > >> > -Nicholas >> > >> >> >> >> -- >> Mike Lyon >> 408-621-4826 >> mike.lyon at gmail.com >> >> http://www.linkedin.com/in/mlyon >> > > > >-- >Mike Lyon >408-621-4826 >mike.lyon at gmail.com > >http://www.linkedin.com/in/mlyon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: ------------------------------ Message: 26 Date: Mon, 22 Jun 2015 23:06:54 +0000 From: Harlan Stenn To: Doug Barton Cc: nanog at nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: Content-Type: text/plain; charset=US-ASCII Doug Barton writes: > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > On 6/19/15 2:58 PM, Harlan Stenn wrote: >> Bad idea. >> >> When restarting ntpd your clocks will likely be off by a second, >> which will cause a backward step, which will force the problem you >> claim to be avoiding. >> >> There are plenty of ways to solve this problem, and you just get to >> choose what you want to risk/pay. > > You misunderstand the problem. :) The problem is not "clock skips > backward one second," because most of the time that's not what > happens. The problem is that most software does not handle it well > when the clock ticks ... :59 :60 :00 instead of ticking directly from > :59 to :00. POSIX NEVER shows :60. > THAT problem is avoided by temporarily turning off NTP and then > turning it back on again when "the coast is clear." Most software can > handle the "clock skips forward or backwards one second" problem > fairly robustly,= and as Baldur pointed out by doing the reset in a > controlled manner you greatly reduce your overall risk. Time going backwards is deadly to a number of applications. But apparently not to applications you care about. You're also not doing anything where somebody is going to get sued because a timestamp is off by a second. There are people for whom this is a very real risk. H ------------------------------ Message: 27 Date: Mon, 22 Jun 2015 16:12:32 -0700 From: Mike Hale To: Hugo Slabbert Cc: Mike Lyon , NANOG , NANOG Subject: Re: Residential VSAT experiences? Message-ID: Content-Type: text/plain; charset=UTF-8 I too have had customers in a previous life where the 500ms delay really didn't cause any big issue. Same with SSH and even heavier stuff like SMB. Sure, it was slower than expected, but I could still saturate the pipe pretty good. Thing is...the kind of setups where you're getting 500ms delay with little jitter is stupidly expensive. Those are generally going to be an SCPC (single carrier per channel) uplink with hopefully something like IP over DVB providing a large pool of downlink bandwidth. Expect to pay over 4k per Megahertz (roughly translated to 1 Mbps unidirectional depending your link budgets) of bandwidth (sometimes substantially more, depending on what bird and provider you're using). O3B looks really interesting. I'm not aware of what they're current state of deployment is, but they've got a MEO (I think) constellation planned which will help a lot of with that latency. Viasat had something that looked promising too. I mean..if you're looking at doing sysadmin type stuff where you're already going to be pulling out your hair at times, doing so over hughesnet is going to suuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuck. On Mon, Jun 22, 2015 at 4:04 PM, Hugo Slabbert wrote: > Personally, 500-700ms of delay is well within distinguishable range and > causes challenges in verbal communication. If the speakers are both > expecting and accustomed to delay like that (e.g. sailors that are used to > being hundreds/thousands of miles away from anywhere and any other comms > solution sucks anyway), it could be workable. > > For regular consumer/business voice applications, 100ms and lower is decent, > but above that starts to get into various degrees of suckage. > > Just my 2c. > > -- > Hugo > > > On Mon 2015-Jun-22 15:54:49 -0700, Mike Lyon wrote: > >> I never had good luck with VSAT and SIP. Maybe you had a better kit than I >> did :) >> >> -Mike >> >> >> On Mon, Jun 22, 2015 at 3:49 PM, Dovid Bender wrote: >> >>> Interesting that you say that about sip. We had a client that would use >>> it >>> for sip on ships all the time. It wasn't the best but it worked. Ping >>> times >>> were between 500-700ms. >>> >>> >>> >>> Regards, >>> >>> Dovid >>> >>> -----Original Message----- >>> From: Mike Lyon >>> Sender: "NANOG" Date: Mon, 22 Jun 2015 15:33:43 >>> To: Nicholas Oas; NANOG >>> Subject: Re: Residential VSAT experiences? >>> >>> SIP will suck. VPN will suck. RDP will suck. >>> >>> Have you looked to see if you have any local wireless ISPs in your area? >>> Hit me up offlist if you want me to check for you. >>> >>> -Mike >>> >>> >>> On Mon, Jun 22, 2015 at 1:39 PM, Nicholas Oas >>> wrote: >>> >>> > Would anyone mind sharing with me their first-hand experiences with >>> > residential satellite internet? >>> > >>> > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm >>> thinking >>> > specifically as a sysadmin who needs to use the uplink for work, not >>> surf. >>> > >>> > What are your experiences with the following applications? >>> > -SSH, (specifically interactive CLI shell access) >>> > -RDP >>> > -SIP over SSL >>> > -IPSec Tunneling (should be a non-starter due to latency) >>> > -GRE Tunneling >>> > >>> > Thank you, >>> > >>> > -Nicholas >>> > >>> >>> >>> >>> -- >>> Mike Lyon >>> 408-621-4826 >>> mike.lyon at gmail.com >>> >>> http://www.linkedin.com/in/mlyon >>> >> >> >> >> -- >> Mike Lyon >> 408-621-4826 >> mike.lyon at gmail.com >> >> http://www.linkedin.com/in/mlyon -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ------------------------------ Message: 28 Date: Mon, 22 Jun 2015 20:10:12 -0400 From: Michael Conlen To: Nicholas Oas Cc: "nanog at nanog.org" Subject: Re: Residential VSAT experiences? Message-ID: <9AB1D8A3-AA0E-4DAF-92D1-054D5A121EC9 at conlen.org> Content-Type: text/plain; charset=windows-1252 On Jun 22, 2015, at 4:39 PM, Nicholas Oas wrote: > Would anyone mind sharing with me their first-hand experiences with > residential satellite internet? > > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm thinking > specifically as a sysadmin who needs to use the uplink for work, not surf. My experience with geostationary was that latencies were around 720 ms in practice. Telnet was painful and it turns out my brain didn?t like typing things while I wasn?t getting instant feedback, though I understand there?s software for that problem now. Reliability was pretty good unless the satellite I was using happened to lose it?s control processors. I was using Panamsat Galaxy 4 when it failed. I don?t know how many angry phone calls we got about why we weren?t answering our pages about the entire network being down before we got into the office. In our case recovery involved getting access to another satellite and having people re-aim the dishes. My only real recollection besides that was that the signal was bad enough/long enough to induce TCP Silly Window Syndrome; but I can?t imagine anyone?s running an OS that old anymore. ? Mike ------------------------------ Message: 29 Date: Mon, 22 Jun 2015 17:27:09 -0700 From: "Scott Weeks" To: Subject: Re: Residential VSAT experiences? Message-ID: <20150622172709.1DAC5311 at m0005298.ppops.net> Content-Type: text/plain; charset="UTF-8" --- bill at herrin.us wrote: From: William Herrin Two-way satellite systems based on SV's in geostationary orbit (like the two you're considering) have high latency. 22,000 miles out, another 22,000 miles back and do it again for the return packet. You'll start around 500ms latency and go up from there. Any kind of interactive session (like SSH and RDP) will be excruciating. ----------------------------------------------- I do SSH over geostationary satellite links (C-band) all the time. I'd say it's slow, but not excruciating, unless you type really fast on the network device's CLI. :-) scott ------------------------------ Message: 30 Date: Mon, 22 Jun 2015 17:18:03 -0700 From: Alfred Olton To: nicholas.oas at gmail.com, nanog at nanog.org Subject: Fwd: Residential VSAT experiences? Message-ID: Content-Type: text/plain; charset=UTF-8 I had Hughes Net a few years back and can confirm that SSH access was pretty much intolerable for me. The delay between what I was typing, and when it would actually show up on the screen in the remote terminal was really annoying for me. As mentioned in previous responses, I think you would want a low orbit satellite internet provider, if you can find one for residential use. In my case, I had a land line, but was too far out for ADSL, so I ended up getting ISDN (*with unlimited local calling on my phone plan*). Of course the SSH usage experience then was much better. Al On 06/22/2015 04:04 PM, Hugo Slabbert wrote:> Personally, 500-700ms of delay is well within distinguishable range and > causes challenges in verbal communication. If the speakers are both > expecting and accustomed to delay like that (e.g. sailors that are used > to being hundreds/thousands of miles away from anywhere and any other > comms solution sucks anyway), it could be workable. > > For regular consumer/business voice applications, 100ms and lower is > decent, but above that starts to get into various degrees of suckage. > > Just my 2c. > > -- > Hugo > > On Mon 2015-Jun-22 15:54:49 -0700, Mike Lyon wrote: > >> I never had good luck with VSAT and SIP. Maybe you had a better kit >> than I >> did :) >> >> -Mike >> >> >> On Mon, Jun 22, 2015 at 3:49 PM, Dovid Bender >> wrote: >> >>> Interesting that you say that about sip. We had a client that would >>> use it >>> for sip on ships all the time. It wasn't the best but it worked. Ping >>> times >>> were between 500-700ms. >>> >>> >>> >>> Regards, >>> >>> Dovid >>> >>> -----Original Message----- >>> From: Mike Lyon >>> Sender: "NANOG" Date: Mon, 22 Jun 2015 15:33:43 >>> To: Nicholas Oas; NANOG >>> Subject: Re: Residential VSAT experiences? >>> >>> SIP will suck. VPN will suck. RDP will suck. >>> >>> Have you looked to see if you have any local wireless ISPs in your area? >>> Hit me up offlist if you want me to check for you. >>> >>> -Mike >>> >>> >>> On Mon, Jun 22, 2015 at 1:39 PM, Nicholas Oas >>> wrote: >>> >>> > Would anyone mind sharing with me their first-hand experiences with >>> > residential satellite internet? >>> > >>> > Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm >>> thinking >>> > specifically as a sysadmin who needs to use the uplink for work, not >>> surf. >>> > >>> > What are your experiences with the following applications? >>> > -SSH, (specifically interactive CLI shell access) >>> > -RDP >>> > -SIP over SSL >>> > -IPSec Tunneling (should be a non-starter due to latency) >>> > -GRE Tunneling >>> > >>> > Thank you, >>> > >>> > -Nicholas >>> > >>> >>> >>> >>> -- >>> Mike Lyon >>> 408-621-4826 >>> mike.lyon at gmail.com >>> >>> http://www.linkedin.com/in/mlyon >>> >> >> >> >> -- >> Mike Lyon >> 408-621-4826 >> mike.lyon at gmail.com >> >> http://www.linkedin.com/in/mlyon ------------------------------ Message: 31 Date: Mon, 22 Jun 2015 18:01:54 -0700 From: Lyndon Nerenberg To: "North American Network Operators' Group" Subject: Re: Residential VSAT experiences? Message-ID: <83287994-FBA2-42DD-8006-7C1E5B0F8609 at orthanc.ca> Content-Type: text/plain; charset="us-ascii" On Jun 22, 2015, at 5:27 PM, Scott Weeks wrote: > I do SSH over geostationary satellite links (C-band) all > the time. I'd say it's slow, but not excruciating, unless > you type really fast on the network device's CLI. :-) SSH client/server authors would do well to learn the lessons of telnet line mode. As would authors of 'interactive' command line applications. The NVT concept is still useful in this day and age, far beyond the LA36. (I.e., if the termcap entry says 'dumb', honour it. There is a damn good reason we are saying 'turn off the bling'.) --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: ------------------------------ Message: 32 Date: Mon, 22 Jun 2015 21:11:17 -0400 From: TR Shaw To: Alfred Olton Cc: nicholas.oas at gmail.com, nanog at nanog.org Subject: Re: Residential VSAT experiences? Message-ID: <54EAD60A-0A03-4240-8967-ADE3642C2DF4 at oitc.com> Content-Type: text/plain; charset=utf-8 I don?t know what your location is but a wireless internet provider using Canopy or Ubiquity or whatever is much more preferable. Also cellular is used in ?remote? locations with good results. I know plenty of people "in the bush? that use these alternatives over VSat. I use the above over VSat when I am out on fishing trips to remote locations. For truly remote where there is no options other than VSat you need to live with the latency problems for now. Iridum is currently too slow and too costly. Maybe LEO or MEO in the future but not now. I have used SSH from a transatlantic flight but the delay can weigh on you ;-) Tom > On Jun 22, 2015, at 8:18 PM, Alfred Olton wrote: > > I had Hughes Net a few years back and can confirm that SSH access was > pretty much intolerable for me. > The delay between what I was typing, and when it would actually show up on > the screen in the remote terminal was really annoying for me. > As mentioned in previous responses, I think you would want a low orbit > satellite internet provider, if you can find one for residential use. > > In my case, I had a land line, but was too far out for ADSL, so I ended up > getting ISDN (*with unlimited local calling on my phone plan*). > Of course the SSH usage experience then was much better. > > Al > > On 06/22/2015 04:04 PM, Hugo Slabbert wrote:> Personally, 500-700ms of > delay is well within distinguishable range and >> causes challenges in verbal communication. If the speakers are both >> expecting and accustomed to delay like that (e.g. sailors that are used >> to being hundreds/thousands of miles away from anywhere and any other >> comms solution sucks anyway), it could be workable. >> >> For regular consumer/business voice applications, 100ms and lower is >> decent, but above that starts to get into various degrees of suckage. >> >> Just my 2c. >> >> -- >> Hugo >> >> On Mon 2015-Jun-22 15:54:49 -0700, Mike Lyon wrote: >> >>> I never had good luck with VSAT and SIP. Maybe you had a better kit >>> than I >>> did :) >>> >>> -Mike >>> >>> >>> On Mon, Jun 22, 2015 at 3:49 PM, Dovid Bender >>> wrote: >>> >>>> Interesting that you say that about sip. We had a client that would >>>> use it >>>> for sip on ships all the time. It wasn't the best but it worked. Ping >>>> times >>>> were between 500-700ms. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Dovid >>>> >>>> -----Original Message----- >>>> From: Mike Lyon >>>> Sender: "NANOG" Date: Mon, 22 Jun 2015 15:33:43 >>>> To: Nicholas Oas; NANOG >>>> Subject: Re: Residential VSAT experiences? >>>> >>>> SIP will suck. VPN will suck. RDP will suck. >>>> >>>> Have you looked to see if you have any local wireless ISPs in your area? >>>> Hit me up offlist if you want me to check for you. >>>> >>>> -Mike >>>> >>>> >>>> On Mon, Jun 22, 2015 at 1:39 PM, Nicholas Oas >>>> wrote: >>>> >>>>> Would anyone mind sharing with me their first-hand experiences with >>>>> residential satellite internet? >>>>> >>>>> Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm >>>> thinking >>>>> specifically as a sysadmin who needs to use the uplink for work, not >>>> surf. >>>>> >>>>> What are your experiences with the following applications? >>>>> -SSH, (specifically interactive CLI shell access) >>>>> -RDP >>>>> -SIP over SSL >>>>> -IPSec Tunneling (should be a non-starter due to latency) >>>>> -GRE Tunneling >>>>> >>>>> Thank you, >>>>> >>>>> -Nicholas >>>>> >>>> >>>> >>>> >>>> -- >>>> Mike Lyon >>>> 408-621-4826 >>>> mike.lyon at gmail.com >>>> >>>> http://www.linkedin.com/in/mlyon >>>> >>> >>> >>> >>> -- >>> Mike Lyon >>> 408-621-4826 >>> mike.lyon at gmail.com >>> >>> http://www.linkedin.com/in/mlyon ------------------------------ Message: 33 Date: Mon, 22 Jun 2015 18:35:34 -0700 From: Dave Crocker To: Lyndon Nerenberg , "North American Network Operators' Group" Subject: Re: Residential VSAT experiences? Message-ID: <5588B7E6.7090508 at dcrocker.net> Content-Type: text/plain; charset=utf-8 On 6/22/2015 6:01 PM, Lyndon Nerenberg wrote: > SSH client/server authors would do well to learn the lessons of telnet line mode. Too bad the RCTE Telnet option never got popular... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ------------------------------ Message: 34 Date: Tue, 23 Jun 2015 07:10:16 +0200 (CEST) From: Mikael Abrahamsson To: "nanog at nanog.org" Subject: Re: Residential VSAT experiences? Message-ID: Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed On Mon, 22 Jun 2015, Michael Conlen wrote: > typing things while I wasn?t getting instant feedback, though I > understand there?s software for that problem now. Yes, https://mosh.mit.edu/ is your friend if you want to do things interactively. Still, satellite is painful, avoid if anything else decent is available. -- Mikael Abrahamsson email: swmike at swm.pp.se ------------------------------ Message: 35 Date: Mon, 22 Jun 2015 22:14:19 -0700 From: Dave Taht To: Michael Conlen Cc: Nicholas Oas , "nanog at nanog.org" Subject: Re: Residential VSAT experiences? Message-ID: Content-Type: text/plain; charset=UTF-8 On Mon, Jun 22, 2015 at 5:10 PM, Michael Conlen wrote: > > On Jun 22, 2015, at 4:39 PM, Nicholas Oas wrote: > >> Would anyone mind sharing with me their first-hand experiences with >> residential satellite internet? >> >> Right now I am evaluating HughesNet Gen4 and ViaSat Exede and I'm thinking >> specifically as a sysadmin who needs to use the uplink for work, not surf. > > My experience with geostationary was that latencies were around 720 ms in practice. Telnet was painful and it turns out my brain didn?t like typing things while I wasn?t getting instant feedback, though I understand there?s software for that problem now. Mosh makes latencies like this a lot less painful. Still painful. > Reliability was pretty good unless the satellite I was using happened to lose it?s control processors. I was using Panamsat Galaxy 4 when it failed. I don?t know how many angry phone calls we got about why we weren?t answering our pages about the entire network being down before we got into the office. In our case recovery involved getting access to another satellite and having people re-aim the dishes. > > My only real recollection besides that was that the signal was bad enough/long enough to induce TCP Silly Window Syndrome; but I can?t imagine anyone?s running an OS that old anymore. > > ? > Mike > -- Dave T?ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast ------------------------------ Message: 36 Date: Tue, 23 Jun 2015 07:07:25 +0000 From: Mel Beckman To: Harlan Stenn Cc: Doug Barton , "" Subject: Re: REMINDER: LEAP SECOND Message-ID: Content-Type: text/plain; charset="utf-8" Harlan, Help me understand why there is a serious risk of going back in time. I acknowledge that there is a remote chance of a backstep, but the probability seems very low. Suppose I disable my NTP service five minutes before a positive leap second occurs, so that no server in my network can query it. These servers will then run on their own internal clocks. Then, five minutes after the leap second, I re-engage NTP. Assuming a high degree of local oscillator fidelity, imagine the clock drift is zero. The result is that NTP will report one second older than the time currently in my server, i.e. exactly five minutes after the 23:59:60 leap second. Thus even systems, such as Unix, where 23:59:60 does not exist in the UTC implementation, the timestamp the server sees from NTP is not the potentially code-crashing 23:59:60, but a perfectly rational 00:05:01. This is what my server?s NTP client compares with its internal clock of 00:04:59. NTP's target time is in the future, so there is no risk of going back in time. NTP gradually increments the local time to converge on NTP?s time. In the alternative case of a negative leap second, following the NTP clock discipline algorithm, the NTP client amortizes the one-second reverse jump, specifically in order to avoid setting the clock backward: the local time will be gradually adjusted again via the clock discipline algorithm until local and NTP times converge. Although the offset is more than the 125ms step threshold, stepping a full one second backward is still statistically unlikely. It may be that I?ve misread the NTP specification in RPC-5905 and its antecedents, as well as the leap second historical records of problems. But the disabling-NTP-prior-to-leap workaround seems to bypass all the documented leap-second live lock hangs and other bugs.. -mel On Jun 22, 2015, at 4:06 PM, Harlan Stenn > wrote: Doug Barton writes: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) On 6/19/15 2:58 PM, Harlan Stenn wrote: Bad idea. When restarting ntpd your clocks will likely be off by a second, which will cause a backward step, which will force the problem you claim to be avoiding. There are plenty of ways to solve this problem, and you just get to choose what you want to risk/pay. You misunderstand the problem. :) The problem is not "clock skips backward one second," because most of the time that's not what happens. The problem is that most software does not handle it well when the clock ticks ... :59 :60 :00 instead of ticking directly from :59 to :00. POSIX NEVER shows :60. THAT problem is avoided by temporarily turning off NTP and then turning it back on again when "the coast is clear." Most software can handle the "clock skips forward or backwards one second" problem fairly robustly,= and as Baldur pointed out by doing the reset in a controlled manner you greatly reduce your overall risk. Time going backwards is deadly to a number of applications. But apparently not to applications you care about. You're also not doing anything where somebody is going to get sued because a timestamp is off by a second. There are people for whom this is a very real risk. H ------------------------------ Message: 37 Date: Tue, 23 Jun 2015 07:46:50 +0000 From: Harlan Stenn To: Mel Beckman Cc: Harlan Stenn , Doug Barton , "" Subject: Re: REMINDER: LEAP SECOND Message-ID: Content-Type: text/plain; charset=US-ASCII This stuff can make my head explode. When a leap second is added, like on 30 June 2015 at the last second of the day, POSIX insists that the day still have 86400 seconds in it. This makes the day longer by one second, so time has to either slow down or move backwards. The "dumb" way to do this is to step the clock back by 1 second at the instant before the stroke of midnight. The allegedly better way to do this would be to stop the clock a bit before midnight, and hold the time for 1 second. To continue providing monotonic time, every time somebody says "what time is it" during that holding period one would want to bump the time by the smallest amount possible, usually 1 nanosecond (assuming the kernel keeps time in nanoseconds). Ideally you wouldn't want to add enough nanoseconds to cause the clock to roll over into the next day "too early". But apparently nobody has implemented this, even though Prof. Mills described it in RFC-i-forget about 20 years ago. This is mostly because POSIX deals with absolute time and not relative time. In the unlikely event of a leap second deletion, there would be no 23:59:59, so when the clock is about to strike 23:59:59 it's OK to add an extra second to the clock to effectively have the time "jump" from 23:59:58 to 00:00:00. This is still a monotonic increment in time. Whatever you decide to do, I recommend you actually test it out to see if it behaves the way you think it will. You have a whole week still. H ------------------------------ Message: 38 Date: Tue, 23 Jun 2015 09:44:40 +0100 (BST) From: Tim Franklin To: NANOG Subject: Re: Residential VSAT experiences? Message-ID: <1732312919.8922.1435049080582.JavaMail.zimbra at pelican.org> Content-Type: text/plain; charset=utf-8 > Interesting that you say that about sip. We had a client that would use it > for sip on ships all the time. It wasn't the best but it worked. Ping times > were between 500-700ms. It really depends on your expectations - or more to the point, your end-users' expectations. I've tested SIP in the lab up to 2000ms RTT. The protocols all hang together and keep working, but it's obviously very much in walkie-talkie mode, you can't hold a normal duplex conversation. 500ms there's more of the talking over each other / "sorry, you go" / "no, you go" dance, but it *is* workable. If your end-user is expecting land-line replacement though... Regards, Tim. ------------------------------ Message: 39 Date: Tue, 23 Jun 2015 09:25:32 +0000 From: Mel Beckman To: Harlan Stenn Cc: "" Subject: Re: REMINDER: LEAP SECOND Message-ID: <19968E2F-A487-49C1-887B-42C663DB95FB at beckman.org> Content-Type: text/plain; charset="utf-8" Harlan, Why should your head explode? Possibly you?re overthinking the problem. And there is no reason (or simple way I can envision) to test my plan, as you advise, in advance. I will just block NTP in my border router temporarily. No need to make a mountain out of this molehill. Cisco, and many other NTP client gear vendors, recommend this approach, and they?ve published extensive research on the matter. -mel > On Jun 23, 2015, at 12:46 AM, Harlan Stenn wrote: > > This stuff can make my head explode. > > When a leap second is added, like on 30 June 2015 at the last second of > the day, POSIX insists that the day still have 86400 seconds in it. > This makes the day longer by one second, so time has to either slow down > or move backwards. > > The "dumb" way to do this is to step the clock back by 1 second at the > instant before the stroke of midnight. > > The allegedly better way to do this would be to stop the clock a bit > before midnight, and hold the time for 1 second. To continue providing > monotonic time, every time somebody says "what time is it" during that > holding period one would want to bump the time by the smallest amount > possible, usually 1 nanosecond (assuming the kernel keeps time in > nanoseconds). > > Ideally you wouldn't want to add enough nanoseconds to cause the clock > to roll over into the next day "too early". > > But apparently nobody has implemented this, even though Prof. Mills > described it in RFC-i-forget about 20 years ago. > > This is mostly because POSIX deals with absolute time and not relative > time. > > In the unlikely event of a leap second deletion, there would be no > 23:59:59, so when the clock is about to strike 23:59:59 it's OK to add > an extra second to the clock to effectively have the time "jump" from > 23:59:58 to 00:00:00. This is still a monotonic increment in time. > > Whatever you decide to do, I recommend you actually test it out to see > if it behaves the way you think it will. You have a whole week still. > > H ------------------------------ Message: 40 Date: Tue, 23 Jun 2015 11:24:43 +0100 From: Nick Hilliard To: nanog at nanog.org Subject: Re: REMINDER: LEAP SECOND Message-ID: <558933EB.6000201 at foobar.org> Content-Type: text/plain; charset=utf-8 On 23/06/2015 10:25, Mel Beckman wrote: > Why should your head explode? Possibly you?re overthinking the problem. The problems don't relate to Harlan overthinking the problem. They relate to developers underthinking the problem and assuming that all clocks are monotonic and that certain rules apply, e.g. that there are 60 seconds in a minute, 86400 seconds in a day and so forth. Mostly applications are not time sensitive, but sometimes they are. When they are, and when the developer assumes something which isn't true, unexpected things might happen. assert()s can be triggered, time synchronisation lost with third party applications, unexpected and untested code paths could be used, etc. Blocking NTP at the NTP edge will probably work fine for most situations. Bear in mind that your NTP edge is not necessarily the same as your network edge. E.g. you might have internal GPS / radio sources which could unexpectedly inject the leap second. The larger the network, the more likely this is to happen. Most organisations have network fossils and ntp is an excellent source of these. I.e. systems which work away for years without any problems before one day accidentally triggering meltdown because some developer didn't understand the subtleties of clock monotonicity. Nick End of NANOG Digest, Vol 89, Issue 24 ************************************* From ag4ve.us at gmail.com Tue Jun 23 17:23:04 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Tue, 23 Jun 2015 13:23:04 -0400 Subject: REMINDER: LEAP SECOND In-Reply-To: <558933EB.6000201@foobar.org> References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> Message-ID: On Jun 23, 2015 6:26 AM, "Nick Hilliard" wrote: > > > Blocking NTP at the NTP edge will probably work fine for most situations. > Bear in mind that your NTP edge is not necessarily the same as your network > edge. E.g. you might have internal GPS / radio sources which could > unexpectedly inject the leap second. The larger the network, the more > likely this is to happen. Most organisations have network fossils and ntp > is an excellent source of these. I.e. systems which work away for years > without any problems before one day accidentally triggering meltdown > because some developer didn't understand the subtleties of clock monotonicity. > NTP causes jumps - not skews, right? From jared at puck.nether.net Tue Jun 23 17:42:28 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 23 Jun 2015 13:42:28 -0400 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> Message-ID: <4B57A4F7-8F77-4508-873E-3D5E6E98ADF5@puck.nether.net> > On Jun 23, 2015, at 1:23 PM, shawn wilson wrote: > > NTP causes jumps - not skews, right? ntpdate jumps, ntpd will try to make small adjustments within a range unless -x is specified. Many operating systems have -x as a default. - Jared From nick at foobar.org Tue Jun 23 17:54:42 2015 From: nick at foobar.org (Nick Hilliard) Date: Tue, 23 Jun 2015 18:54:42 +0100 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> Message-ID: <55899D62.7020605@foobar.org> On 23/06/2015 18:23, shawn wilson wrote: > NTP causes jumps - not skews, right? this is implementation dependent. For normal clock differences on ntpd, if you start it with the -x parameter, it will always slew and never step. If you start ntpd without the -x parameter, if the calculated correct time after slewing is out by > 128ms relative to other ntp servers, then after 900 seconds, it will step to the correct time. However in the case of leap seconds, if the operating system implements ntp kernel discipline, then the ntp server will immediately step by the leap second (forwards or backwards), as soon as it receives the leap second notification. It does this on the basis that the kernel supports leap seconds, therefore it's probably the right thing to do. Nick From stenn at ntp.org Wed Jun 24 00:33:31 2015 From: stenn at ntp.org (Harlan Stenn) Date: Wed, 24 Jun 2015 00:33:31 +0000 Subject: NANOG Digest, Vol 89, Issue 24 In-Reply-To: <7245D3644B58AE47A4008980D8336EFD25A57AF4@mbx-02> References: <7245D3644B58AE47A4008980D8336EFD25A57AF4@mbx-02> Message-ID: Alex Hardie writes: > Not to inject more confusion - but GPS and NTP are noted in the > thread... but not PTP (IEEE1588)? I don't belive PTP generally uses UTC as a timescale. H From stenn at ntp.org Wed Jun 24 00:37:51 2015 From: stenn at ntp.org (Harlan Stenn) Date: Wed, 24 Jun 2015 00:37:51 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> Message-ID: shawn wilson writes: > On Jun 23, 2015 6:26 AM, "Nick Hilliard" wrote: > > > > > > > Blocking NTP at the NTP edge will probably work fine for most situations. > > Bear in mind that your NTP edge is not necessarily the same as your > network > > edge. E.g. you might have internal GPS / radio sources which could > > unexpectedly inject the leap second. The larger the network, the more > > likely this is to happen. Most organisations have network fossils and ntp > > is an excellent source of these. I.e. systems which work away for years > > without any problems before one day accidentally triggering meltdown > > because some developer didn't understand the subtleties of clock > monotonicity. > > > > NTP causes jumps - not skews, right? Left to its default condition, ntp will step/jump a change in excess of 128msec. If you want to slew the clock instead, a 1 second correction will take a little over 33 minutes' time to apply. I don't understand why people believe that stopping ntpd for a few minutes while the leap second is applied will help. If the system clock keeps good time, it will *still* be about 1 second ahead when ntpd is restarted, and that will trigger a backward step which is fatal to a number of applications. H From mhuff at ox.com Wed Jun 24 01:06:40 2015 From: mhuff at ox.com (Matthew Huff) Date: Wed, 24 Jun 2015 01:06:40 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> Message-ID: A backward step is a known issue and something that people are more comfortable dealing with as it can happen on any machine with a noisy clock crystal. Having 61 seconds in a minute or 86401 seconds in a day is a different story. > On Jun 23, 2015, at 8:37 PM, Harlan Stenn wrote: > > shawn wilson writes: >> On Jun 23, 2015 6:26 AM, "Nick Hilliard" wrote: >>> >> >>> >>> Blocking NTP at the NTP edge will probably work fine for most situations. >>> Bear in mind that your NTP edge is not necessarily the same as your >> network >>> edge. E.g. you might have internal GPS / radio sources which could >>> unexpectedly inject the leap second. The larger the network, the more >>> likely this is to happen. Most organisations have network fossils and ntp >>> is an excellent source of these. I.e. systems which work away for years >>> without any problems before one day accidentally triggering meltdown >>> because some developer didn't understand the subtleties of clock >> monotonicity. >>> >> >> NTP causes jumps - not skews, right? > > Left to its default condition, ntp will step/jump a change in excess of > 128msec. > > If you want to slew the clock instead, a 1 second correction will take a > little over 33 minutes' time to apply. > > I don't understand why people believe that stopping ntpd for a few > minutes while the leap second is applied will help. If the system clock > keeps good time, it will *still* be about 1 second ahead when ntpd is > restarted, and that will trigger a backward step which is fatal to a > number of applications. > > H From jra at baylink.com Wed Jun 24 02:02:50 2015 From: jra at baylink.com (Jay Ashworth) Date: Tue, 23 Jun 2015 22:02:50 -0400 (EDT) Subject: REMINDER: LEAP SECOND In-Reply-To: Message-ID: <8039932.16.1435111370562.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Harlan Stenn" > > You misunderstand the problem. :) The problem is not "clock skips > > backward one second," because most of the time that's not what > > happens. The problem is that most software does not handle it well > > when the clock ticks ... :59 :60 :00 instead of ticking directly > > from > > :59 to :00. > > POSIX NEVER shows :60. Then I hope POSIX does not claim to represent UTC, because UTC does, no? (IE: somewhere between "a bit" and "a lot" more expansion was called for there; most of us don't have ntp.org email addresses. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Wed Jun 24 02:06:28 2015 From: jra at baylink.com (Jay Ashworth) Date: Tue, 23 Jun 2015 22:06:28 -0400 (EDT) Subject: FOLO: Leap Seconds Message-ID: <22552064.20.1435111588601.JavaMail.root@benjamin.baylink.com> Herewith, for your amusement in the copious free time I hope you have from having smoothly humming networks that don't demand your attention: Falsehoods programers believe about time: http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time and More Falsehoods programmers believe about time: http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time If your heads explode, *I* am not wiping up after. 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 gem at rellim.com Wed Jun 24 02:33:44 2015 From: gem at rellim.com (Gary E. Miller) Date: Tue, 23 Jun 2015 19:33:44 -0700 Subject: REMINDER: LEAP SECOND In-Reply-To: <8039932.16.1435111370562.JavaMail.root@benjamin.baylink.com> References: <8039932.16.1435111370562.JavaMail.root@benjamin.baylink.com> Message-ID: <20150623193344.3f5deea6@rellim.com> Yo Jay! On Tue, 23 Jun 2015 22:02:50 -0400 (EDT) Jay Ashworth wrote: > ----- Original Message ----- > > From: "Harlan Stenn" > > > > You misunderstand the problem. :) The problem is not "clock skips > > > backward one second," because most of the time that's not what > > > happens. The problem is that most software does not handle it well > > > when the clock ticks ... :59 :60 :00 instead of ticking directly > > > from > > > :59 to :00. > > > > POSIX NEVER shows :60. > > Then I hope POSIX does not claim to represent UTC, because UTC does, > no? POSIX-1:2001 clearly 61 seeconds in a minute: The POSIX-1:2001 docs are here: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html From the Description: "The header shall declare the structure tm, which shall include at least the following members: int tm_sec Seconds [0,60]. " From the Application Usage: "The range [0,60] for tm_sec allows for the occasional leap second." From the Rationale: "The range [0,60] seconds allows for positive or negative leap seconds." But, from the section on "Seconds Since the Epoch" http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_14 POSIX seconds is defined as: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 Summed up with: "The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified." Which basically says if you are gonna split hairs on leap seconds things will be undefined. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1(541)382-8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From tqr2813d376cjozqap1l at tutanota.com Wed Jun 24 02:35:37 2015 From: tqr2813d376cjozqap1l at tutanota.com (tqr2813d376cjozqap1l at tutanota.com) Date: Wed, 24 Jun 2015 02:35:37 +0000 (UTC) Subject: FOLO: Leap Seconds In-Reply-To: <22552064.20.1435111588601.JavaMail.root@benjamin.baylink.com> References: <22552064.20.1435111588601.JavaMail.root@benjamin.baylink.com> Message-ID: 24. Jun 2015 02:06 by jra at baylink.com: > Falsehoods programers believe about time: > > and More Falsehoods programmers believe about time: > Great links! If only every programmer would take heed... :) From stenn at ntp.org Wed Jun 24 03:33:05 2015 From: stenn at ntp.org (Harlan Stenn) Date: Wed, 24 Jun 2015 03:33:05 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> Message-ID: Matthew Huff writes: > A backward step is a known issue and something that people are more > comfortable dealing with as it can happen on any machine with a noisy > clock crystal. A clock crystal has to be REALLY bad for ntpd to need to step the clock. > Having 61 seconds in a minute or 86401 seconds in a day is a different > story. Yeah, leap years suck too. And those jumps around daylight savings time. H From tore at fud.no Wed Jun 24 06:33:14 2015 From: tore at fud.no (Tore Anderson) Date: Wed, 24 Jun 2015 08:33:14 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> Message-ID: <20150624083314.0492372b@echo.ms.redpill-linpro.com> * Harlan Stenn > Matthew Huff writes: > > A backward step is a known issue and something that people are more > > comfortable dealing with as it can happen on any machine with a > > noisy clock crystal. > > A clock crystal has to be REALLY bad for ntpd to need to step the > clock. > > > Having 61 seconds in a minute or 86401 seconds in a day is a > > different story. > > Yeah, leap years suck too. > > And those jumps around daylight savings time. Hi Harlan, Leap years and DST ladjustments have never caused us any major issues. It seems these code paths are well tested and work fine. The leap second in 2012 however ... total and utter carnage. Application servers, databases, etc. falling over like dominoes. All hands on deck in the middle of the night to clean up. It took days before we stopped finding broken stuff. Maybe all the bugs from 2012 have been fixed. Maybe they haven't. Maybe new ones have been introduced. I'm not terribly optimistic. One example I'm aware of: Cisco Nexus 5010/5020 switches need software that was released as late as 29th of April this year in order to be immune to the crash&burn leap second bug CSCub38654. The official ?Cisco Suggested release based on software quality, stability and longevity? is older. Go figure. In any case, we're certainly not going to risk it. So our plan is to disconnect our local stratum-2s from their upstreams on June 29th so they (and more crucially, their downstream clients) remain oblivious to the leap second. Come July 1st, we'll reconnect them. The clients' clocks will be 1s (plus any drift) off at that point, but as we're running ntpd with the "-x" option, that shouldn't cause backwards stepping. Running with slightly incorrect clocks for a few days is a small price to pay to avoid a repeat of 2012's mayhem. Tore From nick at foobar.org Wed Jun 24 08:50:02 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 24 Jun 2015 09:50:02 +0100 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> Message-ID: <558A6F3A.4030106@foobar.org> On 24/06/2015 04:33, Harlan Stenn wrote: > A clock crystal has to be REALLY bad for ntpd to need to step the clock. or really virtual. Nick From list-nanog2 at dragon.net Wed Jun 24 10:17:51 2015 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Wed, 24 Jun 2015 07:17:51 -0300 Subject: Call for Presentations - DNS-OARC Fall Workshop, Oct 2015 Message-ID: <20150624101751.710F61E66FE0@fafnir.remote.dragon.net> Apologies if you are on multiple lists and see multiple copies of this email. ------------- The next DNS-OARC Fall Workshop will take place in Montreal on Oct 3rd and 4th, the weekend before NANOG65. DNS-OARC is requesting proposals for presentations, with a preference for DNSSEC work. We are looking for the whole spectrum, from measurement work using passive and active techniques, to applications and potential new uses of DNSSEC. This workshop intends to build from previous strong DNS-OARC workshops, where operational content and research is welcome. Presentations from DNS operators are particularly welcome, as well as from DNS researchers. All DNS-related subjects are accepted, introduction to new tools, visualizations, data analysis, DNSSEC and novel uses of the DNS. If you are an DNS-OARC member, and have a sensitive topic you would like to present for members-only, we will accommodate those talks too. Time will be available for lighting talks to fit short presentations (5 to 10 minutes). Workshop Milestones 17 June 2015, Call for Presentations posted 17 June 2015, Open for submissions 30 July 2015, Deadline for submission 20 August 2015, Final Program published 1 October 2015, Final deadline for slideset submission Details for abstract submission will be published here: https://indico.dns-oarc.net/event/24/call-for-abstracts/ The workshop will be organized on different tracks, depending on the topics and the timing of each presentation. If you are interested in a lightning talk, let us know at the time of submission. You can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via if you have questions or concerns. Sebastian Castro, for the DNS-OARC Programme Committee DNS-OARC is also seeking sponsorship for this workshop, please contact if your organization is interested in becoming a sponsor. (Please note that DNS-OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) From leonardo.ortiz at marisolsa.com Wed Jun 24 12:23:38 2015 From: leonardo.ortiz at marisolsa.com (Leonardo Oliveira Ortiz) Date: Wed, 24 Jun 2015 12:23:38 +0000 Subject: RES: RES: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> <59E8C16E83D82B439E20698AAC790B5F01384981B8@ma45> Message-ID: <59E8C16E83D82B439E20698AAC790B5F013849918E@ma45> Red Hat recomend update tzdate, this rpm is just for timezones right ? If i won't update it we will have some problem ? -----Mensagem original----- De: Mark Milhollan [mailto:mlm at pixelgate.net] Enviada em: quarta-feira, 24 de junho de 2015 09:19 Para: Leonardo Oliveira Ortiz Assunto: Re: RES: REMINDER: LEAP SECOND On Tue, 23 Jun 2015, Leonardo Oliveira Ortiz wrote: >Guys, if we don't have NTP enable on our Linux we still have problem with leap second ?? Without NTP there is no leap second -- you won't even notice it. /mark From mhuff at ox.com Wed Jun 24 12:34:05 2015 From: mhuff at ox.com (Matthew Huff) Date: Wed, 24 Jun 2015 12:34:05 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180806.GF8182@besserwisser.org> <709AFB28-CC8F-4E01-929C-50EB21CD27FE@beckman.org> <558889A6.10704@dougbarton.us> <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> Message-ID: Yes, the clock has to be bad. Been there, done that, especially early Sun x86 servers. Leap years and DST are both things people and developers are aware of outside of technology, leap seconds, not so much. > On Jun 23, 2015, at 11:33 PM, Harlan Stenn wrote: > > Matthew Huff writes: >> A backward step is a known issue and something that people are more >> comfortable dealing with as it can happen on any machine with a noisy >> clock crystal. > > A clock crystal has to be REALLY bad for ntpd to need to step the clock. > >> Having 61 seconds in a minute or 86401 seconds in a day is a different >> story. > > Yeah, leap years suck too. > > And those jumps around daylight savings time. > > H From pch-nanog at u-1.phicoh.com Wed Jun 24 12:22:04 2015 From: pch-nanog at u-1.phicoh.com (Philip Homburg) Date: Wed, 24 Jun 2015 14:22:04 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: Your message of "Wed, 24 Jun 2015 08:33:14 +0200 ." <20150624083314.0492372b@echo.ms.redpill-linpro.com> Message-ID: In your letter dated Wed, 24 Jun 2015 08:33:14 +0200 you wrote: >Leap years and DST ladjustments have never caused us any major >issues. It seems these code paths are well tested and work fine. I seem to remember that they were not tested that well on a certain brand of mobile devices a few years back... In any case, we can abstract from time zones and DST by using UTC internally and then converting to local time in the UI. For UTC the analog approach would be to keep time in TAI internally and convert to UTC when required. There is however a big problem with that. UTC as a time scale is not predictable. There is no way of computing the number of seconds between 2000-01-01 00:00 and 2100-01-01 00:00 because that value is undefined. The net results is that representing, say, 2020-01-01 00:00 as a TAI timestamp is impossible until about 6 months before that date. One way forward for people who for some reason feel attached to representing the rotation of the earth in civil time is to have a scheme for leap second just like leap years. For example, insert a leap second every 18 months. And then revise that scheme once a century to cope unexpect changes in the earth's rotation. (Or just get rid of them all together and move to a different time zone every 4000 years). From dot at dotat.at Wed Jun 24 13:05:34 2015 From: dot at dotat.at (Tony Finch) Date: Wed, 24 Jun 2015 14:05:34 +0100 Subject: REMINDER: LEAP SECOND In-Reply-To: References: Message-ID: Philip Homburg wrote: > > For UTC the analog approach would be to keep time in TAI internally and > convert to UTC when required. This is much less of a solution than you might hope, because most APIs, protocols, and data formats require UT. (Usually not UTC but a representation isomorphic to traditional UT which ignores leap seconds.) Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Variable 3 or 4, but northwesterly 4 or 5 in southeast. Slight, occasionally moderate. Mainly fair. Mainly good. From pch-nanog at u-1.phicoh.com Wed Jun 24 13:34:53 2015 From: pch-nanog at u-1.phicoh.com (Philip Homburg) Date: Wed, 24 Jun 2015 15:34:53 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: Your message of "Wed, 24 Jun 2015 14:05:34 +0100 ." References: Message-ID: In your letter dated Wed, 24 Jun 2015 14:05:34 +0100 you wrote: >Philip Homburg wrote: >> >> For UTC the analog approach would be to keep time in TAI internally and >> convert to UTC when required. > >This is much less of a solution than you might hope, because most APIs, >protocols, and data formats require UT. (Usually not UTC but a >representation isomorphic to traditional UT which ignores leap seconds.) Supporting legacy formats can be annoying. In some cases it would be no problem. For example NTP. If there is a defined way to convert between TAI and UTC then converting TAI to NTP timestamps is easy except during an actual leap second. Which is not really a problem. Unix systems would probably need a few new system calls to accept time in TAI. File formats like tar are unlikely to matter much: find a consistent way of encoding time around the leap second and most likely nobody will care. In any case, it would be nice if future formats and systems could have a sensible time keeping system. From msa at latt.net Wed Jun 24 16:05:00 2015 From: msa at latt.net (Majdi S. Abbas) Date: Wed, 24 Jun 2015 12:05:00 -0400 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150624083314.0492372b@echo.ms.redpill-linpro.com> References: <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> <20150624083314.0492372b@echo.ms.redpill-linpro.com> Message-ID: <20150624160500.GC7191@puck.nether.net> On Wed, Jun 24, 2015 at 08:33:14AM +0200, Tore Anderson wrote: > Leap years and DST ladjustments have never caused us any major > issues. It seems these code paths are well tested and work fine. I've seen quite a few people that for whatever reason insist on running systems in local time zones struggle with the DST reverse step. It's not nearly as much of a non-issue as you claim. > The leap second in 2012 however ... total and utter carnage. > Application servers, databases, etc. falling over like dominoes. All > hands on deck in the middle of the night to clean up. It took days > before we stopped finding broken stuff. "Total and utter carnage" is a bit of a stretch. Linux hosts that ran applications dependant on nanosleeps needed reboots. Note that this wasn't an issue in 2009, because the poorly tested change in question hadn't yet been made to the Linux kernel. (Even in 2012, my personal hosts, running a different operating system sailed through it just fine.) At any time, you might have a bad operational day for any number of reasons. Sure, that one was annoying, but to my knowledge nobody died, and a lot of hosts that probably needed one anyway got a reboot. Certainly, lately, I've seen a lot of Linux hosts rebooted more than once for security patching. #opslife? Cheers, --msa From cma at cmadams.net Wed Jun 24 16:33:06 2015 From: cma at cmadams.net (Chris Adams) Date: Wed, 24 Jun 2015 11:33:06 -0500 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150624160500.GC7191@puck.nether.net> References: <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> <20150624083314.0492372b@echo.ms.redpill-linpro.com> <20150624160500.GC7191@puck.nether.net> Message-ID: <20150624163306.GA914@cmadams.net> Once upon a time, Majdi S. Abbas said: > "Total and utter carnage" is a bit of a stretch. Linux hosts > that ran applications dependant on nanosleeps needed reboots. Note > that this wasn't an issue in 2009, because the poorly tested change in > question hadn't yet been made to the Linux kernel. In 2009, there was a different problem. If the system was under sufficient kernel-related load (such as disk I/O), the kernel's attempt to print an informational message that a leap second had been added caused a kernel deadlock, immediately killing the system. I don't remember any widespread Linux-related leap second issues before that though. -- Chris Adams From tore at fud.no Wed Jun 24 18:33:13 2015 From: tore at fud.no (Tore Anderson) Date: Wed, 24 Jun 2015 20:33:13 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150624160500.GC7191@puck.nether.net> References: <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> <20150624083314.0492372b@echo.ms.redpill-linpro.com> <20150624160500.GC7191@puck.nether.net> Message-ID: <20150624203313.431e9267@envy.fud.no> * Majdi S. Abbas > On Wed, Jun 24, 2015 at 08:33:14AM +0200, Tore Anderson wrote: > > Leap years and DST ladjustments have never caused us any major > > issues. It seems these code paths are well tested and work fine. > > I've seen quite a few people that for whatever reason insist > on running systems in local time zones struggle with the DST reverse > step. It's not nearly as much of a non-issue as you claim. Read again, and note the word "us". I am describing my and my employer's experience with past DST changes and leap years, and those have indeed been completely uneventful. YMMV. > > The leap second in 2012 however ... total and utter carnage. > > Application servers, databases, etc. falling over like dominoes. All > > hands on deck in the middle of the night to clean up. It took days > > before we stopped finding broken stuff. > > "Total and utter carnage" is a bit of a stretch. As above, I am speaking only about how the 2012 leap second went down in our infrastructure. I stand by how I described the event. Again, YMMV. If you plan on let your infrastructure deal with the upcoming leap second head-on, I wish you the best of luck. Hopefully all the bugs from 2012 have been fixed. I, however, certainly have no intention of being the one to find out otherwise. Tore From mhuff at ox.com Wed Jun 24 18:47:16 2015 From: mhuff at ox.com (Matthew Huff) Date: Wed, 24 Jun 2015 18:47:16 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150624203313.431e9267@envy.fud.no> References: <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> <20150624083314.0492372b@echo.ms.redpill-linpro.com> <20150624160500.GC7191@puck.nether.net> <20150624203313.431e9267@envy.fud.no> Message-ID: <58D00624-E1E0-4010-9D70-50658B7D31F2@ox.com> Does anyone know what the latest that we can run our NTP servers and not distribute the LEAP_SECOND flag to the NTP clients? > On Jun 24, 2015, at 2:33 PM, Tore Anderson wrote: > > * Majdi S. Abbas > >> On Wed, Jun 24, 2015 at 08:33:14AM +0200, Tore Anderson wrote: >>> Leap years and DST ladjustments have never caused us any major >>> issues. It seems these code paths are well tested and work fine. >> >> I've seen quite a few people that for whatever reason insist >> on running systems in local time zones struggle with the DST reverse >> step. It's not nearly as much of a non-issue as you claim. > > Read again, and note the word "us". I am describing my and my > employer's experience with past DST changes and leap years, and those > have indeed been completely uneventful. > > YMMV. > >>> The leap second in 2012 however ... total and utter carnage. >>> Application servers, databases, etc. falling over like dominoes. All >>> hands on deck in the middle of the night to clean up. It took days >>> before we stopped finding broken stuff. >> >> "Total and utter carnage" is a bit of a stretch. > > As above, I am speaking only about how the 2012 leap second went down > in our infrastructure. I stand by how I described the event. > > Again, YMMV. If you plan on let your infrastructure deal with the > upcoming leap second head-on, I wish you the best of luck. Hopefully > all the bugs from 2012 have been fixed. I, however, certainly have no > intention of being the one to find out otherwise. > > Tore From tore at fud.no Wed Jun 24 19:07:19 2015 From: tore at fud.no (Tore Anderson) Date: Wed, 24 Jun 2015 21:07:19 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: <58D00624-E1E0-4010-9D70-50658B7D31F2@ox.com> References: <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> <20150624083314.0492372b@echo.ms.redpill-linpro.com> <20150624160500.GC7191@puck.nether.net> <20150624203313.431e9267@envy.fud.no> <58D00624-E1E0-4010-9D70-50658B7D31F2@ox.com> Message-ID: <20150624210719.0f237d7c@envy.fud.no> * Matthew Huff > Does anyone know what the latest that we can run our NTP servers and > not distribute the LEAP_SECOND flag to the NTP clients? From http://support.ntp.org/bin/view/Support/NTPRelatedDefinitions: Leap Indicator This is a two-bit code warning of an impending leap second to be inserted in the NTP timescale. The bits are set before 23:59 on the day of insertion and reset after 00:00 on the following day. This causes the number of seconds (rollover interval) in the day of insertion to be increased or decreased by one. So the answer to your question is, AIUI, 2015-06-29 23:59:59. Tore From mhuff at ox.com Wed Jun 24 19:11:33 2015 From: mhuff at ox.com (Matthew Huff) Date: Wed, 24 Jun 2015 19:11:33 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150624210719.0f237d7c@envy.fud.no> References: <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> <20150624083314.0492372b@echo.ms.redpill-linpro.com> <20150624160500.GC7191@puck.nether.net> <20150624203313.431e9267@envy.fud.no> <58D00624-E1E0-4010-9D70-50658B7D31F2@ox.com> <20150624210719.0f237d7c@envy.fud.no> Message-ID: I saw that, but it says the bits are set "before 23:59" on the day of insertion, but I was hoping that I could shut it down later than 23:59:59 of the previous day (8pm EST). The reason is FINRA regulations. We have to have the time synced once per trading day before the open according to the regulations. We could manually run ntpdate on 100+ servers including 50+ windows servers, but that's not a great solution. ---- 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: Tore Anderson [mailto:tore at fud.no] Sent: Wednesday, June 24, 2015 3:07 PM To: Matthew Huff Cc: nanog2 Subject: Re: REMINDER: LEAP SECOND * Matthew Huff > Does anyone know what the latest that we can run our NTP servers and > not distribute the LEAP_SECOND flag to the NTP clients? >From http://support.ntp.org/bin/view/Support/NTPRelatedDefinitions: Leap Indicator This is a two-bit code warning of an impending leap second to be inserted in the NTP timescale. The bits are set before 23:59 on the day of insertion and reset after 00:00 on the following day. This causes the number of seconds (rollover interval) in the day of insertion to be increased or decreased by one. So the answer to your question is, AIUI, 2015-06-29 23:59:59. Tore From tore at fud.no Wed Jun 24 19:25:57 2015 From: tore at fud.no (Tore Anderson) Date: Wed, 24 Jun 2015 21:25:57 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> <20150624083314.0492372b@echo.ms.redpill-linpro.com> <20150624160500.GC7191@puck.nether.net> <20150624203313.431e9267@envy.fud.no> <58D00624-E1E0-4010-9D70-50658B7D31F2@ox.com> <20150624210719.0f237d7c@envy.fud.no> Message-ID: <20150624212557.278409e4@envy.fud.no> * Matthew Huff > I saw that, but it says the bits are set "before 23:59" on the day of > insertion, but I was hoping that I could shut it down later than > 23:59:59 of the previous day (8pm EST). The reason is FINRA > regulations. We have to have the time synced once per trading day > before the open according to the regulations. Again AIUI, and I'm no NTP expert so I hope someone corrects me if I'm wrong: If you don't configure the "leapfile" ntpd option, the Leap Indicator flag will flow down to your servers from the stratum-1s servers you're synchronising from (directly or indirectly). So what I think you could do, is to on the 29th remove all your upstream servers from your NTP server's config, and set "fudge 127.127.1.0 stratum 3" or something like that so that clients will still want to sync to it. At that point, your NTP server's clock chip will be the reference clock, which might be drift-prone. To work around that, you could at 8pm on the 30th stop ntpd, manually sync the system clock with ntpdate, and start ntpd again. That should keep your NTP server's clock reasonably synchronised, that provides your clients with (a Leap Indicator-free) NTP service. I make no guarantees that the above will work the way I think it will, though... Try it at your own risk. Tore From mhuff at ox.com Wed Jun 24 19:44:35 2015 From: mhuff at ox.com (Matthew Huff) Date: Wed, 24 Jun 2015 19:44:35 +0000 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150624212557.278409e4@envy.fud.no> References: <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> <20150624083314.0492372b@echo.ms.redpill-linpro.com> <20150624160500.GC7191@puck.nether.net> <20150624203313.431e9267@envy.fud.no> <58D00624-E1E0-4010-9D70-50658B7D31F2@ox.com> <20150624210719.0f237d7c@envy.fud.no> <20150624212557.278409e4@envy.fud.no> Message-ID: <480ad477c4324b9a92facf12e0d3ede0@pur-vm-exch13n1.ox.com> That won't work. Being internally sync'ed isn't good enough for FINRA. All the machines must be synced to an external accurate source at least once per trading day. Our plan is to disable our two stratum 1 servers, and our 3 stratum 2 servers before the leap second turnover, but to be 100% safe we would need to do that 24 hours before, but that would be a violation of FINRA regulations. It looks like the safest thing for us to do is to keep our NTP servers running and deal with any crashes/issues. That's better than having to deal with FINRA. ---- 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: Tore Anderson [mailto:tore at fud.no] Sent: Wednesday, June 24, 2015 3:26 PM To: Matthew Huff Cc: nanog2 Subject: Re: REMINDER: LEAP SECOND * Matthew Huff > I saw that, but it says the bits are set "before 23:59" on the day of > insertion, but I was hoping that I could shut it down later than > 23:59:59 of the previous day (8pm EST). The reason is FINRA > regulations. We have to have the time synced once per trading day > before the open according to the regulations. Again AIUI, and I'm no NTP expert so I hope someone corrects me if I'm wrong: If you don't configure the "leapfile" ntpd option, the Leap Indicator flag will flow down to your servers from the stratum-1s servers you're synchronising from (directly or indirectly). So what I think you could do, is to on the 29th remove all your upstream servers from your NTP server's config, and set "fudge 127.127.1.0 stratum 3" or something like that so that clients will still want to sync to it. At that point, your NTP server's clock chip will be the reference clock, which might be drift-prone. To work around that, you could at 8pm on the 30th stop ntpd, manually sync the system clock with ntpdate, and start ntpd again. That should keep your NTP server's clock reasonably synchronised, that provides your clients with (a Leap Indicator-free) NTP service. I make no guarantees that the above will work the way I think it will, though... Try it at your own risk. Tore From tore at fud.no Wed Jun 24 19:57:28 2015 From: tore at fud.no (Tore Anderson) Date: Wed, 24 Jun 2015 21:57:28 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: <480ad477c4324b9a92facf12e0d3ede0@pur-vm-exch13n1.ox.com> References: <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> <20150624083314.0492372b@echo.ms.redpill-linpro.com> <20150624160500.GC7191@puck.nether.net> <20150624203313.431e9267@envy.fud.no> <58D00624-E1E0-4010-9D70-50658B7D31F2@ox.com> <20150624210719.0f237d7c@envy.fud.no> <20150624212557.278409e4@envy.fud.no> <480ad477c4324b9a92facf12e0d3ede0@pur-vm-exch13n1.ox.com> Message-ID: <20150624215728.30d61ed3@envy.fud.no> * Matthew Huff > That won't work. Being internally sync'ed isn't good enough for > FINRA. All the machines must be synced to an external accurate source > at least once per trading day. That was why I proposed to ntpdate on your (upstream-free since the 29th) NTP server(s) sometime on the 30th. That would synchronise its local clock with an external accurate source, without learning the Leap Indicator. > Our plan is to disable our two stratum 1 servers, and our 3 stratum 2 > servers before the leap second turnover, but to be 100% safe we would > need to do that 24 hours before, but that would be a violation of > FINRA regulations. If you run your own straum-1 servers, can't you just opt not to configure "leapfile"? Assuming your own organisation is the only user of those servers, that is (certainly don't do that if it's a public server). After the leap second has passed, you can proceed to correct things. Your clients will then be 1s ahead of correct time, and will need to step/slew their clocks to get in sync. But maybe that's OK as far as FINRA's concerned... > It looks like the safest thing for us to do is to keep our NTP > servers running and deal with any crashes/issues. That's better than > having to deal with FINRA. Maybe. I have no experience with FINRA. :-) Tore From gem at rellim.com Wed Jun 24 20:20:46 2015 From: gem at rellim.com (Gary E. Miller) Date: Wed, 24 Jun 2015 13:20:46 -0700 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150624215728.30d61ed3@envy.fud.no> References: <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> <20150624083314.0492372b@echo.ms.redpill-linpro.com> <20150624160500.GC7191@puck.nether.net> <20150624203313.431e9267@envy.fud.no> <58D00624-E1E0-4010-9D70-50658B7D31F2@ox.com> <20150624210719.0f237d7c@envy.fud.no> <20150624212557.278409e4@envy.fud.no> <480ad477c4324b9a92facf12e0d3ede0@pur-vm-exch13n1.ox.com> <20150624215728.30d61ed3@envy.fud.no> Message-ID: <20150624132046.6af0b0a1@rellim.com> Yo Tore! On Wed, 24 Jun 2015 21:57:28 +0200 Tore Anderson wrote: > If you run your own straum-1 servers, can't you just opt not to > configure "leapfile"? Depends on what your Stratum-1 is syncronized to. Some GPS time sources pass on the leap indicator to NTP. For example, the SiRF-3 GPS, connected by way of gpsd, to ntpd will pass on the leap second. At least in theory. :-) RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1(541)382-8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From cma at cmadams.net Wed Jun 24 20:30:35 2015 From: cma at cmadams.net (Chris Adams) Date: Wed, 24 Jun 2015 15:30:35 -0500 Subject: REMINDER: LEAP SECOND In-Reply-To: <20150624132046.6af0b0a1@rellim.com> References: <20150624083314.0492372b@echo.ms.redpill-linpro.com> <20150624160500.GC7191@puck.nether.net> <20150624203313.431e9267@envy.fud.no> <58D00624-E1E0-4010-9D70-50658B7D31F2@ox.com> <20150624210719.0f237d7c@envy.fud.no> <20150624212557.278409e4@envy.fud.no> <480ad477c4324b9a92facf12e0d3ede0@pur-vm-exch13n1.ox.com> <20150624215728.30d61ed3@envy.fud.no> <20150624132046.6af0b0a1@rellim.com> Message-ID: <20150624203035.GC914@cmadams.net> Once upon a time, Gary E. Miller said: > Depends on what your Stratum-1 is syncronized to. Some GPS time > sources pass on the leap indicator to NTP. For example, the SiRF-3 > GPS, connected by way of gpsd, to ntpd will pass on the leap second. Yep, my ancient old SVeeSix has been showing the leap second for several months; the notification it was added to the GPS signal a while back, either at the start of the year or the start of the quarter (in theory, leap seconds can be added/removed quarterly). -- Chris Adams From list at satchell.net Thu Jun 25 01:13:11 2015 From: list at satchell.net (Stephen Satchell) Date: Wed, 24 Jun 2015 18:13:11 -0700 Subject: REMINDER: LEAP SECOND In-Reply-To: <480ad477c4324b9a92facf12e0d3ede0@pur-vm-exch13n1.ox.com> References: <19968E2F-A487-49C1-887B-42C663DB95FB@beckman.org> <558933EB.6000201@foobar.org> <20150624083314.0492372b@echo.ms.redpill-linpro.com> <20150624160500.GC7191@puck.nether.net> <20150624203313.431e9267@envy.fud.no> <58D00624-E1E0-4010-9D70-50658B7D31F2@ox.com> <20150624210719.0f237d7c@envy.fud.no> <20150624212557.278409e4@envy.fud.no> <480ad477c4324b9a92facf12e0d3ede0@pur-vm-exch13n1.ox.com> Message-ID: <558B55A7.5090001@satchell.net> On 06/24/2015 12:44 PM, Matthew Huff wrote: > It looks like the safest thing for us to do is to keep our NTP > servers running and deal with any crashes/issues. That's better than > having to deal with FINRA. For what it's worth, Red Hat pushed updates to NTP and to TZDATA. You might want to check the documentation to see if the updates include sane handling of the leap second. (I run CentOS 7.1 and Fedora 20, which is where I saw the updates during my morning maintenance.) From damian at google.com Thu Jun 25 01:14:14 2015 From: damian at google.com (Damian Menscher) Date: Wed, 24 Jun 2015 18:14:14 -0700 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150622122718.GA10690@nic.fr> Message-ID: On Mon, Jun 22, 2015 at 7:17 AM, shawn wilson wrote: > > > So, what we should do is make clocks move. 99999 slower half of the year > (and then speed back up) so that we're really in line with earth's > rotational time. I mean we've got the computers to do it (I think most RTC > only go down to thousandths so it'll still need a little skewing but I'm > sure we'll manage). > > Ps - if anyone actually does this, I'm going postal. > http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html comes dangerously close to your modest proposal. Damian From dot at dotat.at Thu Jun 25 09:59:24 2015 From: dot at dotat.at (Tony Finch) Date: Thu, 25 Jun 2015 10:59:24 +0100 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150622122718.GA10690@nic.fr> Message-ID: Damian Menscher via NANOG wrote: > > http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html > comes dangerously close to your modest proposal. Also http://developerblog.redhat.com/2015/06/01/five-different-ways-handle-leap-seconds-ntp/ Tony. -- f.anthony.n.finch http://dotat.at/ Southwest Viking: Northwesterly 3 or 4, veering southeasterly 4 or 5 later. Slight or moderate. Fair. Good. From mdavids at forfun.net Thu Jun 25 12:33:30 2015 From: mdavids at forfun.net (Marco Davids) Date: Thu, 25 Jun 2015 14:33:30 +0200 Subject: Youtube / IPv6 / Netherlands Message-ID: <558BF51A.2060508@forfun.net> Hi, Would anyone from Google care to explain to me off-list why certain Youtube-content is blocked in the Netherlands while using IPv6 when it is working fine via IPv4? Geolocation imperfections perhaps? The IPv6-address is within 2a02:a47f:e000::/36 (actually, it is: 2a02:a444:443b:0:xxxx:xxxx:xxxx:xxxx) Thank you. -- Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4239 bytes Desc: S/MIME Cryptographic Signature URL: From morrowc.lists at gmail.com Thu Jun 25 13:32:25 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 25 Jun 2015 09:32:25 -0400 Subject: Youtube / IPv6 / Netherlands In-Reply-To: <558BF51A.2060508@forfun.net> References: <558BF51A.2060508@forfun.net> Message-ID: On Thu, Jun 25, 2015 at 8:33 AM, Marco Davids wrote: > > Geolocation imperfections perhaps? geolocation is hard :( From nanog at stefan-neufeind.de Thu Jun 25 13:41:13 2015 From: nanog at stefan-neufeind.de (Stefan Neufeind) Date: Thu, 25 Jun 2015 15:41:13 +0200 Subject: Youtube / IPv6 / Netherlands In-Reply-To: References: <558BF51A.2060508@forfun.net> Message-ID: <558C04F9.7090907@stefan-neufeind.de> Am 25.06.2015 um 15:32 schrieb Christopher Morrow: > On Thu, Jun 25, 2015 at 8:33 AM, Marco Davids wrote: >> >> Geolocation imperfections perhaps? > > geolocation is hard :( geolocation is a broken concept anyway :-( Similar to like being allowed by law to only offer some downloads of series/movies during the night (starting 10pm afaik) for youth-protection (here in Germany) ... come on ... Kind regards, sn From seth.mos at dds.nl Thu Jun 25 13:51:50 2015 From: seth.mos at dds.nl (Seth Mos) Date: Thu, 25 Jun 2015 15:51:50 +0200 Subject: Youtube / IPv6 / Netherlands In-Reply-To: <558BF51A.2060508@forfun.net> References: <558BF51A.2060508@forfun.net> Message-ID: <558C0776.8030308@dds.nl> Marco Davids schreef op 25-6-2015 om 14:33: > Hi, > > Would anyone from Google care to explain to me off-list why certain > Youtube-content is blocked in the Netherlands while using IPv6 when it > is working fine via IPv4? > > Geolocation imperfections perhaps? > > The IPv6-address is within 2a02:a47f:e000::/36 > (actually, it is: 2a02:a444:443b:0:xxxx:xxxx:xxxx:xxxx) To add to Marco, The entire 2a02:a400::/25 prefix is used by KPN Netherlands for consumer and small business DSL internet. http://bgp.he.net/ip/2A02:A400:C17F:0:: Kind regards, Seth From pr at isprime.com Thu Jun 25 14:08:42 2015 From: pr at isprime.com (Phil Rosenthal) Date: Thu, 25 Jun 2015 10:08:42 -0400 Subject: Youtube / IPv6 / Netherlands In-Reply-To: References: <558BF51A.2060508@forfun.net> Message-ID: <5270C003-15AF-4310-A718-7E74DD5E3833@isprime.com> > On Jun 25, 2015, at 9:32 AM, Christopher Morrow wrote: > > geolocation is hard :( If you would like to see how Google has your geolocation set, check: curl http://redirector.c.youtube.com/report_mapping You might want to force it both IPv4 and IPv6 to see if there is any difference. Best Regards, -Phil From maxtul at netassist.ua Thu Jun 25 14:44:12 2015 From: maxtul at netassist.ua (Max Tulyev) Date: Thu, 25 Jun 2015 17:44:12 +0300 Subject: Youtube / IPv6 / Netherlands In-Reply-To: <558BF51A.2060508@forfun.net> References: <558BF51A.2060508@forfun.net> Message-ID: <558C13BC.8080702@netassist.ua> Hi, +1. Our 2a01:d0::/32 is floating by Google's geo all around the world, it was Iran, now it is Russia... and I can't do anything with it, and have no human contact in Google for complaint. On 25.06.15 15:33, Marco Davids wrote: > Hi, > > Would anyone from Google care to explain to me off-list why certain > Youtube-content is blocked in the Netherlands while using IPv6 when it > is working fine via IPv4? > > Geolocation imperfections perhaps? > > The IPv6-address is within 2a02:a47f:e000::/36 > (actually, it is: 2a02:a444:443b:0:xxxx:xxxx:xxxx:xxxx) > > Thank you. > > From jared at puck.nether.net Thu Jun 25 14:49:51 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 25 Jun 2015 10:49:51 -0400 Subject: Youtube / IPv6 / Netherlands In-Reply-To: <5270C003-15AF-4310-A718-7E74DD5E3833@isprime.com> References: <558BF51A.2060508@forfun.net> <5270C003-15AF-4310-A718-7E74DD5E3833@isprime.com> Message-ID: <5E90C4E7-DB8A-4743-BE0C-97CF5E280657@puck.nether.net> > On Jun 25, 2015, at 10:08 AM, Phil Rosenthal wrote: > > >> On Jun 25, 2015, at 9:32 AM, Christopher Morrow wrote: >> >> geolocation is hard :( > > If you would like to see how Google has your geolocation set, check: > curl http://redirector.c.youtube.com/report_mapping > > You might want to force it both IPv4 and IPv6 to see if there is any difference. And run it a few times, because it may think your IP in asia is in Amsterdam, etc.. [jared at eng0 ~]$ curl -4 http://redirector.c.youtube.com/report_mapping 203.105.73.114 => ams09x03 : superx_isp_number: 8 (203.105.64.0/20) [s] [jared at eng0 ~]$ curl -4 http://redirector.c.youtube.com/report_mapping 203.105.73.114 => sjc07x04 : superx_isp_number: 1 (203.105.64.0/20) [u] - Jared From seth.mos at dds.nl Thu Jun 25 15:26:38 2015 From: seth.mos at dds.nl (Seth Mos) Date: Thu, 25 Jun 2015 17:26:38 +0200 Subject: Youtube / IPv6 / Netherlands In-Reply-To: <558C13BC.8080702@netassist.ua> References: <558BF51A.2060508@forfun.net> <558C13BC.8080702@netassist.ua> Message-ID: > Op 25 jun. 2015, om 16:44 heeft Max Tulyev het volgende geschreven: > > Hi, > > +1. > > Our 2a01:d0::/32 is floating by Google's geo all around the world, it > was Iran, now it is Russia... and I can't do anything with it, and have > no human contact in Google for complaint. That sounds like a software problem where it does not match anything in the database and then proceeds to return the last known value of the variable. :/ That?s even worse then saying ?We don?t know?. Regards, Seth > > On 25.06.15 15:33, Marco Davids wrote: >> Hi, >> >> Would anyone from Google care to explain to me off-list why certain >> Youtube-content is blocked in the Netherlands while using IPv6 when it >> is working fine via IPv4? >> >> Geolocation imperfections perhaps? >> >> The IPv6-address is within 2a02:a47f:e000::/36 >> (actually, it is: 2a02:a444:443b:0:xxxx:xxxx:xxxx:xxxx) >> >> Thank you. >> >> > From swhyte at gmail.com Thu Jun 25 15:33:59 2015 From: swhyte at gmail.com (Scott Whyte) Date: Thu, 25 Jun 2015 08:33:59 -0700 Subject: Youtube / IPv6 / Netherlands In-Reply-To: <5E90C4E7-DB8A-4743-BE0C-97CF5E280657@puck.nether.net> References: <558BF51A.2060508@forfun.net> <5270C003-15AF-4310-A718-7E74DD5E3833@isprime.com> <5E90C4E7-DB8A-4743-BE0C-97CF5E280657@puck.nether.net> Message-ID: <558C1F67.3050307@gmail.com> On 6/25/15 07:49, Jared Mauch wrote: > >> On Jun 25, 2015, at 10:08 AM, Phil Rosenthal wrote: >> >> >>> On Jun 25, 2015, at 9:32 AM, Christopher Morrow wrote: >>> >>> geolocation is hard :( >> >> If you would like to see how Google has your geolocation set, check: >> curl http://redirector.c.youtube.com/report_mapping >> >> You might want to force it both IPv4 and IPv6 to see if there is any difference. > > > And run it a few times, because it may think your IP in asia is in Amsterdam, etc.. > > [jared at eng0 ~]$ curl -4 http://redirector.c.youtube.com/report_mapping > 203.105.73.114 => ams09x03 : superx_isp_number: 8 (203.105.64.0/20) [s] > [jared at eng0 ~]$ curl -4 http://redirector.c.youtube.com/report_mapping > 203.105.73.114 => sjc07x04 : superx_isp_number: 1 (203.105.64.0/20) [u] Maybe its actually telling you where youtube is serving videos from for that IP address, in realtime, based on a large number of variables only one of which is where on the Earth that IP might be located. > > - Jared > From jared at puck.nether.net Thu Jun 25 15:37:16 2015 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 25 Jun 2015 11:37:16 -0400 Subject: Youtube / IPv6 / Netherlands In-Reply-To: <558C1F67.3050307@gmail.com> References: <558BF51A.2060508@forfun.net> <5270C003-15AF-4310-A718-7E74DD5E3833@isprime.com> <5E90C4E7-DB8A-4743-BE0C-97CF5E280657@puck.nether.net> <558C1F67.3050307@gmail.com> Message-ID: > On Jun 25, 2015, at 11:33 AM, Scott Whyte wrote: > > > > On 6/25/15 07:49, Jared Mauch wrote: >> >>> On Jun 25, 2015, at 10:08 AM, Phil Rosenthal wrote: >>> >>> >>>> On Jun 25, 2015, at 9:32 AM, Christopher Morrow wrote: >>>> >>>> geolocation is hard :( >>> >>> If you would like to see how Google has your geolocation set, check: >>> curl http://redirector.c.youtube.com/report_mapping >>> >>> You might want to force it both IPv4 and IPv6 to see if there is any difference. >> >> >> And run it a few times, because it may think your IP in asia is in Amsterdam, etc.. >> >> [jared at eng0 ~]$ curl -4 http://redirector.c.youtube.com/report_mapping >> 203.105.73.114 => ams09x03 : superx_isp_number: 8 (203.105.64.0/20) [s] >> [jared at eng0 ~]$ curl -4 http://redirector.c.youtube.com/report_mapping >> 203.105.73.114 => sjc07x04 : superx_isp_number: 1 (203.105.64.0/20) [u] > > Maybe its actually telling you where youtube is serving videos from for that IP address, in realtime, based on a large number of variables only one of which is where on the Earth that IP might be located. That might be possible, but sending traffic to Europe vs another site smells like some other issue. It?s also interesting to look at the internalized CIDR it?s matching against. Take puck as an example. puck:~$ curl http://redirector.c.youtube.com/report_mapping -4 204.42.254.5 => ord31x04 : superx_isp_number: 1 (204.42.224.0/19) [u] puck:~$ curl http://redirector.c.youtube.com/report_mapping -6 2001:418:3f4::5 => sjc07s17 (2001:418:200::/39) [u] Many interesting results as a consequence. - jared From morrowc.lists at gmail.com Thu Jun 25 20:13:58 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 25 Jun 2015 16:13:58 -0400 Subject: Youtube / IPv6 / Netherlands In-Reply-To: <5270C003-15AF-4310-A718-7E74DD5E3833@isprime.com> References: <558BF51A.2060508@forfun.net> <5270C003-15AF-4310-A718-7E74DD5E3833@isprime.com> Message-ID: https://github.com/morrowc/yt_troubleshooting might even be useful... I have not run it in a bit so it might die horribly :( but it might also tell you something useful :) On Thu, Jun 25, 2015 at 10:08 AM, Phil Rosenthal wrote: > >> On Jun 25, 2015, at 9:32 AM, Christopher Morrow wrote: >> >> geolocation is hard :( > > If you would like to see how Google has your geolocation set, check: > curl http://redirector.c.youtube.com/report_mapping > > You might want to force it both IPv4 and IPv6 to see if there is any difference. > > Best Regards, > -Phil From johnmusbach1 at gmail.com Wed Jun 24 18:46:33 2015 From: johnmusbach1 at gmail.com (John Musbach) Date: Wed, 24 Jun 2015 14:46:33 -0400 Subject: Any Verizon datacenter techs about? Message-ID: Hello, I'm a techie that recently moved to South Jersey for a tech job. To my astonishment, I discovered that there appears to be a Verizon datacenter near my house that has colocation: http://imgur.com/a/PdGno It's in Somers Point, NJ. While I could not find an address on the building, it is on the corner of Bethel Rd and N New Rd. I've tried walking around back to see if I could talk to anyone about colocation but could not find anyone outside. I've also tried calling Verizon but support wasn't very helpful. My question is, what does it take to get some colocation space inside of that building? Me and my roommate both have a 1u we'd like to rack and having it racked in a datacenter walking distance from where we live would be awesome. What we'd need: 2u space 4 power drops for the servers (2 psu per server) 2 100Mbps ethernet drops with static IPs I'm not sure if that's too little to ask for colocation or not, but that really is all we'd need. Is there anyone about that knows what we'd need to acquire such space, cost, badging, etc? If so, can you please reply offlist? Thanks, John M From sts at ono.at Thu Jun 25 04:48:49 2015 From: sts at ono.at (Stefan Schlesinger) Date: Thu, 25 Jun 2015 06:48:49 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150622122718.GA10690@nic.fr> Message-ID: > On 25 Jun 2015, at 03:14, Damian Menscher via NANOG wrote: > > http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html > comes dangerously close to your modest proposal. > > Damian I wonder why Google hasn't published the patch yet. Leap smear sounds like the sane way to do leap seconds, and it would't break software at all, because time adjustments in the sub-second area are proven to work quite well. Btw. there seem to be a couple of public Google timeservers, I wonder whether could just sync time from there to get leap smearing. time[1-4].google.com Also this update looks like it would smoothen the process: https://rhn.redhat.com/errata/RHBA-2015-1159.html https://bugzilla.redhat.com/show_bug.cgi?id=1214752 -Stefan From morrowc.lists at gmail.com Thu Jun 25 21:32:45 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 25 Jun 2015 17:32:45 -0400 Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: On Wed, Jun 24, 2015 at 2:46 PM, John Musbach wrote: > Hello, > > I'm a techie that recently moved to South Jersey for a tech job. To my > astonishment, I discovered that there appears to be a Verizon > datacenter near my house that has colocation: how / why did you think this has colocation? > > http://imgur.com/a/PdGno > > It's in Somers Point, NJ. While I could not find an address on the > building, it is on the corner of Bethel Rd and N New Rd. I've tried > walking around back to see if I could talk to anyone about colocation > but could not find anyone outside. I've also tried calling Verizon but > support wasn't very helpful. My question is, what does it take to get > some colocation space inside of that building? Me and my roommate both > have a 1u we'd like to rack and having it racked in a datacenter > walking distance from where we live would be awesome. What we'd need: > > 2u space > 4 power drops for the servers (2 psu per server) > 2 100Mbps ethernet drops with static IPs > > I'm not sure if that's too little to ask for colocation or not, but > that really is all we'd need. Is there anyone about that knows what > we'd need to acquire such space, cost, badging, etc? If so, can you > please reply offlist? > > Thanks, > > John M From morrowc.lists at gmail.com Thu Jun 25 21:37:32 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 25 Jun 2015 17:37:32 -0400 Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: On Thu, Jun 25, 2015 at 5:32 PM, Christopher Morrow wrote: > On Wed, Jun 24, 2015 at 2:46 PM, John Musbach wrote: >> Hello, >> >> I'm a techie that recently moved to South Jersey for a tech job. To my >> astonishment, I discovered that there appears to be a Verizon >> datacenter near my house that has colocation: > > how / why did you think this has colocation? > https://www22.verizon.com/wholesale/attachments/space-exhaust/Web_UpdateSouth.pdf if you search for somers point in there this looks like a Central office which might offer future physical (future from 2012) colocation, but I bet you'd have to be a CLEC to take advantage of this... >> >> http://imgur.com/a/PdGno >> >> It's in Somers Point, NJ. While I could not find an address on the >> building, it is on the corner of Bethel Rd and N New Rd. I've tried >> walking around back to see if I could talk to anyone about colocation >> but could not find anyone outside. I've also tried calling Verizon but >> support wasn't very helpful. My question is, what does it take to get >> some colocation space inside of that building? Me and my roommate both >> have a 1u we'd like to rack and having it racked in a datacenter >> walking distance from where we live would be awesome. What we'd need: >> >> 2u space >> 4 power drops for the servers (2 psu per server) >> 2 100Mbps ethernet drops with static IPs >> >> I'm not sure if that's too little to ask for colocation or not, but >> that really is all we'd need. Is there anyone about that knows what >> we'd need to acquire such space, cost, badging, etc? If so, can you >> please reply offlist? >> >> Thanks, >> >> John M From lyle at lcrcomputer.net Thu Jun 25 21:47:01 2015 From: lyle at lcrcomputer.net (Lyle Giese) Date: Thu, 25 Jun 2015 16:47:01 -0500 Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: <558C76D5.5080904@lcrcomputer.net> It looks more like a standard telco central office, not a data center. Lyle On 06/24/15 13:46, John Musbach wrote: > Hello, > > I'm a techie that recently moved to South Jersey for a tech job. To my > astonishment, I discovered that there appears to be a Verizon > datacenter near my house that has colocation: > > http://imgur.com/a/PdGno > > It's in Somers Point, NJ. While I could not find an address on the > building, it is on the corner of Bethel Rd and N New Rd. I've tried > walking around back to see if I could talk to anyone about colocation > but could not find anyone outside. I've also tried calling Verizon but > support wasn't very helpful. My question is, what does it take to get > some colocation space inside of that building? Me and my roommate both > have a 1u we'd like to rack and having it racked in a datacenter > walking distance from where we live would be awesome. What we'd need: > > 2u space > 4 power drops for the servers (2 psu per server) > 2 100Mbps ethernet drops with static IPs > > I'm not sure if that's too little to ask for colocation or not, but > that really is all we'd need. Is there anyone about that knows what > we'd need to acquire such space, cost, badging, etc? If so, can you > please reply offlist? > > Thanks, > > John M From rafael at gav.ufsc.br Thu Jun 25 22:04:09 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Thu, 25 Jun 2015 17:04:09 -0500 Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: Be prepared to drop a lot of money for colocation with Verizon. Also, quoting process is rather long and you will have to sign a NDA most likely, which just makes it even more fun. For the size of your project I'd pick a provider that focuses on colocation for small and medium businesses and is easier to work with. On Wed, Jun 24, 2015 at 1:46 PM, John Musbach wrote: > Hello, > > I'm a techie that recently moved to South Jersey for a tech job. To my > astonishment, I discovered that there appears to be a Verizon > datacenter near my house that has colocation: > > http://imgur.com/a/PdGno > > It's in Somers Point, NJ. While I could not find an address on the > building, it is on the corner of Bethel Rd and N New Rd. I've tried > walking around back to see if I could talk to anyone about colocation > but could not find anyone outside. I've also tried calling Verizon but > support wasn't very helpful. My question is, what does it take to get > some colocation space inside of that building? Me and my roommate both > have a 1u we'd like to rack and having it racked in a datacenter > walking distance from where we live would be awesome. What we'd need: > > 2u space > 4 power drops for the servers (2 psu per server) > 2 100Mbps ethernet drops with static IPs > > I'm not sure if that's too little to ask for colocation or not, but > that really is all we'd need. Is there anyone about that knows what > we'd need to acquire such space, cost, badging, etc? If so, can you > please reply offlist? > > Thanks, > > John M > From damian at google.com Thu Jun 25 22:23:29 2015 From: damian at google.com (Damian Menscher) Date: Thu, 25 Jun 2015 15:23:29 -0700 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150622122718.GA10690@nic.fr> Message-ID: On Wed, Jun 24, 2015 at 9:48 PM, Stefan Schlesinger wrote: > > On 25 Jun 2015, at 03:14, Damian Menscher via NANOG > wrote: > > > > > http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html > > comes dangerously close to your modest proposal. > > I wonder why Google hasn't published the patch yet. Leap smear sounds like > the sane way to do leap seconds, and it would't break software at all, > because time adjustments in the sub-second area are proven to work quite > well. > > Btw. there seem to be a couple of public Google timeservers, I wonder > whether could just sync time from there to get leap smearing. > I'd be cautious about that approach. I don't think they've been advertised for public use, so they could go away without notice. Also, definitely don't mix them with normal servers, as that would just confuse your clocks (which might smear *and* leap or something equally insane). Damian From tore at fud.no Fri Jun 26 05:42:29 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 26 Jun 2015 07:42:29 +0200 Subject: REMINDER: LEAP SECOND In-Reply-To: References: <24952930.133.1434733582653.JavaMail.root@benjamin.baylink.com> <20150619180329.GA26018@pob.ytti.fi> <20150622122718.GA10690@nic.fr> Message-ID: <20150626074229.611ef426@echo.ms.redpill-linpro.com> * Stefan Schlesinger > > On 25 Jun 2015, at 03:14, Damian Menscher via NANOG wrote: > > > > http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html > > comes dangerously close to your modest proposal. > > I wonder why Google hasn't published the patch yet. Leap smear sounds > like the sane way to do leap seconds, and it would't break software > at all, because time adjustments in the sub-second area are proven to > work quite well. It's implemented in chronyd versions 2.0 and up, for what it's worth. The required config directive is "leapsecmode slew". There's a nice blog post explaining how this feature, as well as some other approaches on how to deal with the leap second, work here: http://developerblog.redhat.com/2015/06/01/five-different-ways-handle-leap-seconds-ntp/ Tore From Lee at asgard.org Fri Jun 26 13:24:23 2015 From: Lee at asgard.org (Lee Howard) Date: Fri, 26 Jun 2015 09:24:23 -0400 Subject: Thanks aws / gcc / azure In-Reply-To: References: Message-ID: On 6/23/15, 9:01 AM, "NANOG on behalf of Ca By" wrote: >Since you have failed to achieve in the modest task that was your charge > >You now get this > >https://www.markshuttleworth.com/archives/1471 Time to watch this again: https://www.youtube.com/watch?v=v26BAlfWBm8 Lee > >Or s/money/addresses/ > >http://youtu.be/pA8f-Nh5gRs > From jared at puck.nether.net Fri Jun 26 13:33:38 2015 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 26 Jun 2015 09:33:38 -0400 Subject: Thanks aws / gcc / azure In-Reply-To: References: Message-ID: > On Jun 26, 2015, at 9:24 AM, Lee Howard wrote: > > On 6/23/15, 9:01 AM, "NANOG on behalf of Ca By" on behalf of cb.list6 at gmail.com> wrote: > >> Since you have failed to achieve in the modest task that was your charge >> >> You now get this >> >> https://www.markshuttleworth.com/archives/1471 > > Time to watch this again: https://www.youtube.com/watch?v=v26BAlfWBm8 or this https://www.youtube.com/watch?v=_y36fG2Oba0 - Jared From nathanael.cariaga at adec-innovations.com Fri Jun 26 08:29:53 2015 From: nathanael.cariaga at adec-innovations.com (Nathanael C. Cariaga) Date: Fri, 26 Jun 2015 16:29:53 +0800 Subject: Level3 NOC Contact Message-ID: <558D0D81.7090507@adec-innovations.com> Hi, Any Level3 NOC contacts on the list? Our link in Irvine has been on and off for few minutes already. Would appreciate replies offline.. Thanks! -nathan From aftab.siddiqui at gmail.com Fri Jun 26 14:20:29 2015 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Fri, 26 Jun 2015 14:20:29 +0000 Subject: Thanks aws / gcc / azure In-Reply-To: References: Message-ID: As someone rightly pointed out "ARIN now down to 0.00978 /8s in aggregate." > or this > > https://www.youtube.com/watch?v=_y36fG2Oba0 so this is more appropriate "I suppose we'd better give it a try" From merlyn at geeks.org Fri Jun 26 14:26:53 2015 From: merlyn at geeks.org (Doug McIntyre) Date: Fri, 26 Jun 2015 09:26:53 -0500 Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: <20150626142653.GB80937@geeks.org> On Thu, Jun 25, 2015 at 05:04:09PM -0500, Rafael Possamai wrote: >> On Wed, Jun 24, 2015 at 1:46 PM, John Musbach >> wrote: >> I'm a techie that recently moved to South Jersey for a tech job. To my >> astonishment, I discovered that there appears to be a Verizon >> datacenter near my house that has colocation: > Be prepared to drop a lot of money for colocation with Verizon. Also, > quoting process is rather long and you will have to sign a NDA most likely, > which just makes it even more fun. For the size of your project I'd pick a > provider that focuses on colocation for small and medium businesses and is > easier to work with. ... There was once a time we were going to colo in a VZ facility within the same building our primary datacenter was (to receive favorable rates on cross-connects, etc). There was signing of NDAs, it took the better part of half a year for build out. Then it was announced ready to move in, and we asked the procedure to get cross-connects from outside the facility in (really the whole point of even getting colo there). Oh no, you can't have a cross-connect. Umm, the only reason we're doing this is to cross-connect to the colo. The sales people knew this from the start, and was a key provision. But the site manager was adamant, nothing comes in or out. I guess VZ thought the colo was ultimately to stand alone without talking to anybody. And they are a communications company. Boggle. From nicholas.oas at gmail.com Fri Jun 26 14:59:43 2015 From: nicholas.oas at gmail.com (Nicholas Oas) Date: Fri, 26 Jun 2015 10:59:43 -0400 Subject: Residential VSAT experiences? In-Reply-To: References: Message-ID: Thank you all for your responses. This was exactly the kind of information and opinions I was hoping to find- way better than reading tea leaves! From pauldotwall at gmail.com Fri Jun 26 15:07:47 2015 From: pauldotwall at gmail.com (Paul WALL) Date: Fri, 26 Jun 2015 11:07:47 -0400 Subject: Today's Supreme Court ruling Message-ID: I hear the Supreme Court just ruled IPv6 legal in all states... What does this mean for the backward people who have been steadily resisting deploying the current version of the Internet Protocol? Drive Slow, Paul From A.L.M.Buxey at lboro.ac.uk Fri Jun 26 15:15:22 2015 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Fri, 26 Jun 2015 16:15:22 +0100 Subject: Any Verizon datacenter techs about? In-Reply-To: <20150626142653.GB80937@geeks.org> References: <20150626142653.GB80937@geeks.org> Message-ID: <413EB088-891A-4083-A746-9D9AC1CBAEBE@lboro.ac.uk> >There was signing of NDAs Which you obviously read and follow to the letter ;) alan From simon at slimey.org Fri Jun 26 15:26:08 2015 From: simon at slimey.org (Simon Lockhart) Date: Fri, 26 Jun 2015 16:26:08 +0100 Subject: Any Verizon datacenter techs about? In-Reply-To: <20150626142653.GB80937@geeks.org> References: <20150626142653.GB80937@geeks.org> Message-ID: <20150626152606.GJ19643@virtual.bogons.net> On Fri Jun 26, 2015 at 09:26:53AM -0500, Doug McIntyre wrote: > I guess VZ thought the colo was ultimately to stand alone without > talking to anybody. And they are a communications company. And there-in lies the answer to your question. They're a communications company. They want to sell you communications services. They don't want you to buy communications services from other providers. If you want to provide your own communications circuits, don't buy datacentre space from a communications company. Simon From bill at herrin.us Fri Jun 26 15:34:55 2015 From: bill at herrin.us (William Herrin) Date: Fri, 26 Jun 2015 11:34:55 -0400 Subject: Any Verizon datacenter techs about? In-Reply-To: <20150626142653.GB80937@geeks.org> References: <20150626142653.GB80937@geeks.org> Message-ID: On Fri, Jun 26, 2015 at 10:26 AM, Doug McIntyre wrote: > Then it was announced ready to move in, and we asked the procedure to > get cross-connects from outside the facility in (really the whole > point of even getting colo there). > > Oh no, you can't have a cross-connect. > > Umm, the only reason we're doing this is to cross-connect to the colo. > The sales people knew this from the start, and was a key provision. > But the site manager was adamant, nothing comes in or out. I'm told second hand that when MCI/worldcom (now Verizon Business) controlled 8100 Boone Blvd (the early MAE-East) you had to buy a data circuit from them to get between floors. Not a cable or a cross-connect. A data circuit at the 0-mile tariffed price. I know first hand that when I bought a Verizon Business data circuit at a carrier-neutral colo and asked them to move the IP addresses from my Verizon Business colo to the data circuit, they refused. It took me longer but I canceled the colo anyway. And the circuit too. Jerks. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From mloftis at wgops.com Fri Jun 26 16:10:25 2015 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 26 Jun 2015 09:10:25 -0700 Subject: Level3 NOC Contact In-Reply-To: <558D0D81.7090507@adec-innovations.com> References: <558D0D81.7090507@adec-innovations.com> Message-ID: AFAIK theres no longer any way to get their attention unless you're a customer AND have signed up for their online portal system at https://my.level3.com/ - and I wouldn't expect anything stellar then either. You'll likely have to do your own troubleshooting through them as my recent experiences have shown little to no clue or assistance from them. They were happy to do as asked but weren't able, or willing, or whatever to do anything on their own. Make certain you get the problem category right too or you'll be stuck in the wrong team without any of them telling you that. On Friday, June 26, 2015, Nathanael C. Cariaga < nathanael.cariaga at adec-innovations.com> wrote: > Hi, > > Any Level3 NOC contacts on the list? Our link in Irvine has been on and > off for few minutes already. Would appreciate replies offline.. > > > Thanks! > > -nathan > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From ag4ve.us at gmail.com Fri Jun 26 17:19:36 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 26 Jun 2015 13:19:36 -0400 Subject: Residential VSAT experiences? In-Reply-To: References: Message-ID: On Jun 22, 2015 6:14 PM, "William Herrin" wrote: > > > Two-way satellite systems based on SV's in geostationary orbit (like > the two you're considering) have high latency. 22,000 miles out, > another 22,000 miles back and do it again for the return packet. Just a minor nitpick - that's 22,300 miles above the equator at sea level. You're probably closer to 22,500 miles away from the bird (as could your uplink). That's just rough math adding the tangent of 1500 miles from the equator in my head (plus the tangent of the curve distance from that base line and angle of the bird :) ). From bill at herrin.us Fri Jun 26 17:25:57 2015 From: bill at herrin.us (William Herrin) Date: Fri, 26 Jun 2015 13:25:57 -0400 Subject: Residential VSAT experiences? In-Reply-To: References: Message-ID: On Fri, Jun 26, 2015 at 1:19 PM, shawn wilson wrote: > On Jun 22, 2015 6:14 PM, "William Herrin" wrote: >> Two-way satellite systems based on SV's in geostationary orbit (like >> the two you're considering) have high latency. 22,000 miles out, >> another 22,000 miles back and do it again for the return packet. > > Just a minor nitpick - that's 22,300 miles above the equator at sea level. > You're probably closer to 22,500 miles away from the bird (as could your > uplink). That's just rough math adding the tangent of 1500 miles from the > equator in my head (plus the tangent of the curve distance from that base > line and angle of the bird :) ). Typically further than that because you're not only not at the same latitude as the bird, you're not at the same longitude either. If you want to nitpick. ;) -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From rafael at gav.ufsc.br Fri Jun 26 17:33:06 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 26 Jun 2015 12:33:06 -0500 Subject: Level3 NOC Contact In-Reply-To: References: <558D0D81.7090507@adec-innovations.com> Message-ID: The portal should have some stats where you can do basic troubleshooting. It's really easy to get registered on the portal, you just need account number and customer name (which is scary, but go figure...). On Fri, Jun 26, 2015 at 11:10 AM, Michael Loftis wrote: > AFAIK theres no longer any way to get their attention unless you're a > customer AND have signed up for their online portal system at > https://my.level3.com/ - and I wouldn't expect anything stellar > then either. You'll likely have to do your own troubleshooting through them > as my recent experiences have shown little to no clue or assistance from > them. They were happy to do as asked but weren't able, or willing, or > whatever to do anything on their own. Make certain you get the problem > category right too or you'll be stuck in the wrong team without any of them > telling you that. > > > > On Friday, June 26, 2015, Nathanael C. Cariaga < > nathanael.cariaga at adec-innovations.com> wrote: > > > Hi, > > > > Any Level3 NOC contacts on the list? Our link in Irvine has been on and > > off for few minutes already. Would appreciate replies offline.. > > > > > > Thanks! > > > > -nathan > > > > > -- > > "Genius might be described as a supreme capacity for getting its possessors > into trouble of all kinds." > -- Samuel Butler > From gary.buhrmaster at gmail.com Fri Jun 26 17:37:23 2015 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 26 Jun 2015 17:37:23 +0000 Subject: Residential VSAT experiences? In-Reply-To: References: Message-ID: On Fri, Jun 26, 2015 at 5:25 PM, William Herrin wrote: .... > If you want to nitpick. ;) Well, if you are going to nitpick, the earth is modeled more closely (but still not precisely) as an oblate spheroid than a true sphere. From yang.yu.list at gmail.com Fri Jun 26 17:38:08 2015 From: yang.yu.list at gmail.com (Yang Yu) Date: Sat, 27 Jun 2015 02:38:08 +0900 Subject: Youtube / IPv6 / Netherlands In-Reply-To: <5270C003-15AF-4310-A718-7E74DD5E3833@isprime.com> References: <558BF51A.2060508@forfun.net> <5270C003-15AF-4310-A718-7E74DD5E3833@isprime.com> Message-ID: On Thu, Jun 25, 2015 at 11:08 PM, Phil Rosenthal wrote: > If you would like to see how Google has your geolocation set, check: > curl http://redirector.c.youtube.com/report_mapping It looks like HTTPS is broken for redirector.c.youtube.com From gourmetcisco at hotmail.com Fri Jun 26 18:04:29 2015 From: gourmetcisco at hotmail.com (Hank Disuko) Date: Fri, 26 Jun 2015 14:04:29 -0400 Subject: =?Windows-1252?Q?World's_Fa?= =?Windows-1252?Q?stest_Inte?= =?Windows-1252?Q?rnet=99_in_C?= =?Windows-1252?Q?anadaland?= Message-ID: Bell Canada is apparently gearing up to provide the good people of Toronto with the World's Fastest Internet?. http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html From clayton at MNSi.Net Fri Jun 26 18:09:54 2015 From: clayton at MNSi.Net (Clayton Zekelman) Date: Fri, 26 Jun 2015 14:09:54 -0400 Subject: =?iso-8859-1?Q?Re:_World's_Fastest_Inte_rnet=99_in_?= Canadaland In-Reply-To: References: Message-ID: <1435342198_76812@surgemail.mnsi.net> They needed to do this. Rogers is already offering higher speeds. At 02:04 PM 26/06/2015, Hank Disuko wrote: >Bell Canada is apparently gearing up to provide >the good people of Toronto with the World's Fastest Internet?. >http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html > > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From cscora at apnic.net Fri Jun 26 18:12:33 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Jun 2015 04:12:33 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201506261812.t5QICXvh001314@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 27 Jun, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 550382 Prefixes after maximum aggregation (per Origin AS): 208414 Deaggregation factor: 2.64 Unique aggregates announced (without unneeded subnets): 267700 Total ASes present in the Internet Routing Table: 50752 Prefixes per ASN: 10.84 Origin-only ASes present in the Internet Routing Table: 36709 Origin ASes announcing only one prefix: 16258 Transit ASes present in the Internet Routing Table: 6327 Transit-only ASes present in the Internet Routing Table: 166 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 67 Max AS path prepend of ASN (197377) 50 Prefixes from unregistered ASNs in the Routing Table: 1233 Unregistered ASNs in the Routing Table: 424 Number of 32-bit ASNs allocated by the RIRs: 9984 Number of 32-bit ASNs visible in the Routing Table: 7716 Prefixes from 32-bit ASNs in the Routing Table: 28287 Number of bogon 32-bit ASNs visible in the Routing Table: 13 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 407 Number of addresses announced to Internet: 2782158752 Equivalent to 165 /8s, 212 /16s and 95 /24s Percentage of available address space announced: 75.1 Percentage of allocated address space announced: 75.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.4 Total number of prefixes smaller than registry allocations: 184409 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 135761 Total APNIC prefixes after maximum aggregation: 39420 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 142431 Unique aggregates announced from the APNIC address blocks: 57131 APNIC Region origin ASes present in the Internet Routing Table: 5073 APNIC Prefixes per ASN: 28.08 APNIC Region origin ASes announcing only one prefix: 1213 APNIC Region transit ASes present in the Internet Routing Table: 884 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 39 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1519 Number of APNIC addresses announced to Internet: 750638656 Equivalent to 44 /8s, 189 /16s and 214 /24s Percentage of available APNIC address space announced: 87.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: 180171 Total ARIN prefixes after maximum aggregation: 88106 ARIN Deaggregation factor: 2.04 Prefixes being announced from the ARIN address blocks: 182665 Unique aggregates announced from the ARIN address blocks: 85208 ARIN Region origin ASes present in the Internet Routing Table: 16611 ARIN Prefixes per ASN: 11.00 ARIN Region origin ASes announcing only one prefix: 6113 ARIN Region transit ASes present in the Internet Routing Table: 1734 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 507 Number of ARIN addresses announced to Internet: 1101184800 Equivalent to 65 /8s, 162 /16s and 191 /24s Percentage of available ARIN address space announced: 58.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-395164 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: 133456 Total RIPE prefixes after maximum aggregation: 66325 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 139963 Unique aggregates announced from the RIPE address blocks: 86694 RIPE Region origin ASes present in the Internet Routing Table: 17975 RIPE Prefixes per ASN: 7.79 RIPE Region origin ASes announcing only one prefix: 8125 RIPE Region transit ASes present in the Internet Routing Table: 2965 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 35 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3803 Number of RIPE addresses announced to Internet: 695997696 Equivalent to 41 /8s, 124 /16s and 21 /24s Percentage of available RIPE address space announced: 101.2 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-204287 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: 60411 Total LACNIC prefixes after maximum aggregation: 11431 LACNIC Deaggregation factor: 5.28 Prefixes being announced from the LACNIC address blocks: 71086 Unique aggregates announced from the LACNIC address blocks: 33061 LACNIC Region origin ASes present in the Internet Routing Table: 2439 LACNIC Prefixes per ASN: 29.15 LACNIC Region origin ASes announcing only one prefix: 611 LACNIC Region transit ASes present in the Internet Routing Table: 505 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1759 Number of LACNIC addresses announced to Internet: 168135232 Equivalent to 10 /8s, 5 /16s and 138 /24s Percentage of available LACNIC address space announced: 100.2 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: 12036 Total AfriNIC prefixes after maximum aggregation: 3083 AfriNIC Deaggregation factor: 3.90 Prefixes being announced from the AfriNIC address blocks: 13830 Unique aggregates announced from the AfriNIC address blocks: 5237 AfriNIC Region origin ASes present in the Internet Routing Table: 739 AfriNIC Prefixes per ASN: 18.71 AfriNIC Region origin ASes announcing only one prefix: 196 AfriNIC Region transit ASes present in the Internet Routing Table: 158 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 128 Number of AfriNIC addresses announced to Internet: 65711360 Equivalent to 3 /8s, 234 /16s and 173 /24s Percentage of available AfriNIC address space announced: 65.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 2952 11304 938 Korea Telecom 17974 2698 904 78 PT Telekomunikasi Indonesia 7545 2606 336 129 TPG Telecom Limited 4755 2026 423 222 TATA Communications formerly 4538 1936 4190 71 China Education and Research 9829 1764 1353 122 National Internet Backbone 9808 1551 8717 28 Guangdong Mobile Communicatio 9583 1491 118 567 Sify Limited 4808 1453 2239 464 CNCGROUP IP network China169 9498 1355 336 106 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 3182 2960 141 Cox Communications Inc. 6389 2792 3688 51 BellSouth.net Inc. 3356 2584 10688 502 Level 3 Communications, Inc. 18566 2054 380 195 MegaPath Corporation 20115 1865 1855 416 Charter Communications 6983 1750 850 244 EarthLink, Inc. 4323 1605 1022 411 tw telecom holdings, inc. 30036 1565 320 443 Mediacom Communications Corp 701 1393 11371 676 MCI Communications Services, 22561 1383 415 257 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 2138 305 364 TELLCOM ILETISIM HIZMETLERI A 20940 1980 771 1444 Akamai International B.V. 6849 1209 355 21 JSC "Ukrtelecom" 13188 1052 97 73 TOV "Bank-Inform" 31148 1048 45 23 Freenet Ltd. 8402 996 544 15 OJSC "Vimpelcom" 12479 950 869 74 France Telecom Espana SA 6830 912 2694 468 Liberty Global Operations B.V 8551 883 376 53 Bezeq International-Ltd 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 3256 532 238 Telmex Colombia S.A. 28573 2285 2170 113 NET Servi?os de Comunica??o S 8151 1695 3249 471 Uninet S.A. de C.V. 7303 1633 1005 238 Telecom Argentina S.A. 6147 1568 372 43 Telefonica del Peru S.A.A. 6503 1267 421 55 Axtel, S.A.B. de C.V. 26615 1077 2325 35 Tim Celular S.A. 7738 999 1882 41 Telemar Norte Leste S.A. 3816 951 428 161 COLOMBIA TELECOMUNICACIONES S 11830 892 364 15 Instituto Costarricense de El 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 24863 876 280 26 Link Egypt (Link.NET) 8452 816 958 13 TE-AS 36903 511 257 103 Office National des Postes et 36992 423 1229 32 ETISALAT MISR 37492 312 175 71 Orange Tunisie 24835 304 146 12 Vodafone Data 3741 250 857 208 Internet Solutions 29571 242 21 13 Cote d'Ivoire Telecom 37054 199 20 7 Data Telecom Service 36947 191 807 13 Telecom Algeria Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3256 532 238 Telmex Colombia S.A. 22773 3182 2960 141 Cox Communications Inc. 4766 2952 11304 938 Korea Telecom 6389 2792 3688 51 BellSouth.net Inc. 17974 2698 904 78 PT Telekomunikasi Indonesia 7545 2606 336 129 TPG Telecom Limited 3356 2584 10688 502 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2285 2170 113 NET Servi?os de Comunica??o S 34984 2138 305 364 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3182 3041 Cox Communications Inc. 6389 2792 2741 BellSouth.net Inc. 17974 2698 2620 PT Telekomunikasi Indonesia 7545 2606 2477 TPG Telecom Limited 39891 2472 2466 SaudiNet, Saudi Telecom Compa 28573 2285 2172 NET Servi?os de Comunica??o S 3356 2584 2082 Level 3 Communications, Inc. 4766 2952 2014 Korea Telecom 4538 1936 1865 China Education and Research 18566 2054 1859 MegaPath Corporation 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.226.112.0/20 62788 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.3.0/24 37004 >>UNKNOWN<< 41.73.4.0/24 37004 >>UNKNOWN<< 41.73.5.0/24 37004 >>UNKNOWN<< 41.73.6.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:17 /9:13 /10:36 /11:96 /12:263 /13:507 /14:1005 /15:1728 /16:12931 /17:7274 /18:12335 /19:25537 /20:36099 /21:38850 /22:60283 /23:52221 /24:298188 /25:1098 /26:1139 /27:714 /28:14 /29:12 /30:7 /31:0 /32:15 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2382 3182 Cox Communications Inc. 18566 2003 2054 MegaPath Corporation 6389 1640 2792 BellSouth.net Inc. 6983 1397 1750 EarthLink, Inc. 34984 1395 2138 TELLCOM ILETISIM HIZMETLERI A 30036 1389 1565 Mediacom Communications Corp 10620 1146 3256 Telmex Colombia S.A. 6147 1122 1568 Telefonica del Peru S.A.A. 11492 1108 1191 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1498 2:682 4:93 5:1865 6:25 8:1408 11:1 12:1822 13:14 14:1380 15:16 16:2 17:43 18:22 20:48 23:1248 24:1735 27:1936 31:1589 32:38 33:2 34:4 35:3 36:137 37:2000 38:1045 39:6 40:83 41:2705 42:298 43:1343 44:28 45:831 46:2296 47:45 49:905 50:809 52:12 54:77 55:4 56:6 57:42 58:1323 59:715 60:480 61:1745 62:1353 63:1915 64:4474 65:2268 66:4047 67:2076 68:1065 69:3250 70:1024 71:448 72:1964 74:2663 75:336 76:424 77:1260 78:1166 79:788 80:1350 81:1294 82:846 83:723 84:722 85:1398 86:428 87:1045 88:533 89:1870 90:152 91:6008 92:869 93:2245 94:2055 95:2177 96:426 97:349 98:1055 99:53 100:72 101:845 103:7713 104:1843 105:61 106:237 107:991 108:631 109:2080 110:1134 111:1440 112:827 113:1100 114:832 115:1279 116:1393 117:1056 118:1844 119:1454 120:444 121:1091 122:2148 123:1844 124:1524 125:1618 128:624 129:390 130:410 131:1217 132:503 133:177 134:403 135:95 136:331 137:320 138:915 139:152 140:237 141:445 142:666 143:497 144:550 145:124 146:739 147:588 148:1217 149:416 150:559 151:670 152:521 153:247 154:481 155:867 156:433 157:419 158:344 159:1008 160:385 161:661 162:1956 163:438 164:686 165:694 166:314 167:837 168:1319 169:181 170:1466 171:245 172:248 173:1544 174:719 175:700 176:1361 177:3747 178:2155 179:940 180:1934 181:1683 182:1805 183:624 184:760 185:3738 186:2762 187:1770 188:2049 189:1591 190:7827 191:1022 192:8488 193:5624 194:4179 195:3693 196:1980 197:968 198:5539 199:5494 200:6663 201:3250 202:9461 203:9131 204:4706 205:2840 206:3053 207:2970 208:3989 209:3969 210:3546 211:1867 212:2551 213:2369 214:841 215:73 216:5744 217:1815 218:705 219:463 220:1453 221:786 222:477 223:746 End of report From EDugas at zerofail.com Fri Jun 26 18:13:51 2015 From: EDugas at zerofail.com (Eric Dugas) Date: Fri, 26 Jun 2015 18:13:51 +0000 Subject: =?Windows-1252?Q?RE:_World's_Fastest_Internet=99_in_Canadaland?= In-Reply-To: References: Message-ID: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Nice try Bell.. So-Net did it two years ago, 2Gbps FTTH in Japan. Article: http://bgr.com/2013/06/13/so-net-nuro-2gbps-fiber-service/ If you read Japanese: http://www.nuro.jp/hikari/ Eric -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hank Disuko Sent: June 26, 2015 2:04 PM To: NANOG Subject: World's Fastest Internet? in Canadaland Bell Canada is apparently gearing up to provide the good people of Toronto with the World's Fastest Internet?. http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html From rafael at gav.ufsc.br Fri Jun 26 18:39:23 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 26 Jun 2015 13:39:23 -0500 Subject: =?UTF-8?Q?Re=3A_World=27s_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Message-ID: How does one fully utilize a gigabit link for home use? For a single person it is overkill. Similar to the concept of price elasticity in economics, going from 50mbps to 1gbps doesn't necessarily increase your average transfer rate, at least I don't think it would for me. Anyone care to comment? Just really curious, as to me it's more of a marketing push than anything else, even though gigabit to the home sounds really cool. On Fri, Jun 26, 2015 at 1:13 PM, Eric Dugas wrote: > Nice try Bell.. So-Net did it two years ago, 2Gbps FTTH in Japan. > > Article: http://bgr.com/2013/06/13/so-net-nuro-2gbps-fiber-service/ > > If you read Japanese: http://www.nuro.jp/hikari/ > > Eric > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hank Disuko > Sent: June 26, 2015 2:04 PM > To: NANOG > Subject: World's Fastest Internet? in Canadaland > > Bell Canada is apparently gearing up to provide the good people of Toronto > with the World's Fastest Internet?. > > http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html > > > From tshaw at oitc.com Fri Jun 26 18:40:16 2015 From: tshaw at oitc.com (TR Shaw) Date: Fri, 26 Jun 2015 14:40:16 -0400 Subject: =?windows-1252?Q?Re=3A_World=27s_Fastest_Internet=99_in_Canadala?= =?windows-1252?Q?nd?= In-Reply-To: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Message-ID: <05F912AF-7A52-4ABB-AC68-DBD58F7342BE@oitc.com> But what about us in Northwestern Ontario who can only get dialup, if that, from Bell? > On Jun 26, 2015, at 2:13 PM, Eric Dugas wrote: > > Nice try Bell.. So-Net did it two years ago, 2Gbps FTTH in Japan. > > Article: http://bgr.com/2013/06/13/so-net-nuro-2gbps-fiber-service/ > > If you read Japanese: http://www.nuro.jp/hikari/ > > Eric > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hank Disuko > Sent: June 26, 2015 2:04 PM > To: NANOG > Subject: World's Fastest Internet? in Canadaland > > Bell Canada is apparently gearing up to provide the good people of Toronto with the World's Fastest Internet?. > http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html > > From deleskie at gmail.com Fri Jun 26 18:47:06 2015 From: deleskie at gmail.com (jim deleskie) Date: Fri, 26 Jun 2015 15:47:06 -0300 Subject: =?UTF-8?Q?Re=3A_World=27s_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Message-ID: Its mostly marketing, a number of years ago I worked for a cable co, we knew if we increased BW X we'd see a Y speed increase in usage. We also has done the math on several future generations of upgrades, so we'd know if "phone company" increases to A we'd move to B. I know the guy that did the math for us then, he still sits in that job so I assume he still does similar I suspect any cable so worth their salt does the same. On Fri, Jun 26, 2015 at 3:39 PM, Rafael Possamai wrote: > How does one fully utilize a gigabit link for home use? For a single person > it is overkill. Similar to the concept of price elasticity in economics, > going from 50mbps to 1gbps doesn't necessarily increase your average > transfer rate, at least I don't think it would for me. Anyone care to > comment? Just really curious, as to me it's more of a marketing push than > anything else, even though gigabit to the home sounds really cool. > > > > On Fri, Jun 26, 2015 at 1:13 PM, Eric Dugas wrote: > > > Nice try Bell.. So-Net did it two years ago, 2Gbps FTTH in Japan. > > > > Article: http://bgr.com/2013/06/13/so-net-nuro-2gbps-fiber-service/ > > > > If you read Japanese: http://www.nuro.jp/hikari/ > > > > Eric > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hank Disuko > > Sent: June 26, 2015 2:04 PM > > To: NANOG > > Subject: World's Fastest Internet? in Canadaland > > > > Bell Canada is apparently gearing up to provide the good people of > Toronto > > with the World's Fastest Internet?. > > > > > http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html > > > > > > > From swmike at swm.pp.se Fri Jun 26 18:52:44 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 26 Jun 2015 20:52:44 +0200 (CEST) Subject: =?UTF-8?Q?Re=3A_World's_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Message-ID: On Fri, 26 Jun 2015, Rafael Possamai wrote: > How does one fully utilize a gigabit link for home use? For a single person > it is overkill. Similar to the concept of price elasticity in economics, > going from 50mbps to 1gbps doesn't necessarily increase your average > transfer rate, at least I don't think it would for me. Anyone care to I have 250/50 megabit/s. I frequently use the 250 megabit/s download and upload speed when doing larger file transfers, and I actually get the speed advertised. I can get 500/50 but I'd have to pay tens of USD per month more for that, and it's just not worth it. So while my transfer rate when I actually do something increases, it doesn't make me use more data per month, it just means that when I actually have to download something bigger, it takes shorter time. And yes, "fastest Internet in the world" is pure BS, gigabit ethernet access to peoples homes have been around for years in other places. -- Mikael Abrahamsson email: swmike at swm.pp.se From ops.lists at gmail.com Fri Jun 26 18:55:15 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 27 Jun 2015 00:25:15 +0530 Subject: =?utf-8?Q?Re:_World's_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Message-ID: <98B0CFC8-C380-4EB6-842D-33E904D2E9E8@gmail.com> Parkinson's law of sorts? Use expanding to fill the bandwidth available One kid with a torrent downloading random stuff, streaming hd and music off the internet etc and a family of four can make decent inroads into gigabit or so I would have thought Don't even start counting say a gb here and several mb there in software, os etc upgrades across a variety of devices. Exrtrapolating from current usage levels on comparatively lower speed broadband doesn't quite make sense to me --srs > On 27-Jun-2015, at 12:09 am, Rafael Possamai wrote: > > How does one fully utilize a gigabit link for home use? For a single person > it is overkill. Similar to the concept of price elasticity in economics, > going from 50mbps to 1gbps doesn't necessarily increase your average > transfer rate, at least I don't think it would for me. Anyone care to > comment? Just really curious, as to me it's more of a marketing push than > anything else, even though gigabit to the home sounds really cool. > > > >> On Fri, Jun 26, 2015 at 1:13 PM, Eric Dugas wrote: >> >> Nice try Bell.. So-Net did it two years ago, 2Gbps FTTH in Japan. >> >> Article: http://bgr.com/2013/06/13/so-net-nuro-2gbps-fiber-service/ >> >> If you read Japanese: http://www.nuro.jp/hikari/ >> >> Eric >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hank Disuko >> Sent: June 26, 2015 2:04 PM >> To: NANOG >> Subject: World's Fastest Internet? in Canadaland >> >> Bell Canada is apparently gearing up to provide the good people of Toronto >> with the World's Fastest Internet?. >> >> http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html >> >> >> From swmike at swm.pp.se Fri Jun 26 18:55:33 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 26 Jun 2015 20:55:33 +0200 (CEST) Subject: =?UTF-8?Q?Re=3A_World's_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Message-ID: On Fri, 26 Jun 2015, jim deleskie wrote: > Its mostly marketing, a number of years ago I worked for a cable co, we > knew if we increased BW X we'd see a Y speed increase in usage. We also > has done the math on several future generations of upgrades, so we'd > know if "phone company" increases to A we'd move to B. I know the guy > that did the math for us then, he still sits in that job so I assume he > still does similar I suspect any cable so worth their salt does the > same. After you increase the download speed above a certain threshold, it's my experience that total data per month doesn't increase more than marginally with speed increase. As soon as access speed is high enough so youtube, netflix etc automatically goes to the highest resolution immediately, data transfered per month is the same even though the access speed goes up. So when you go from 5 to 10 megabit/s towards the user, yes, data amount increases, but when you go from 100 to 250 megabit/s towards the user, not so much. -- Mikael Abrahamsson email: swmike at swm.pp.se From landonstewart at gmail.com Fri Jun 26 18:58:10 2015 From: landonstewart at gmail.com (Landon Stewart) Date: Fri, 26 Jun 2015 11:58:10 -0700 Subject: =?utf-8?Q?Re=3A_World=27s_Fastest_Internet=E2=84=A2_in_Canadalan?= =?utf-8?Q?d?= In-Reply-To: <05F912AF-7A52-4ABB-AC68-DBD58F7342BE@oitc.com> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> <05F912AF-7A52-4ABB-AC68-DBD58F7342BE@oitc.com> Message-ID: <85DB3674-000A-4B35-8FE1-3572B4DB010A@gmail.com> > On Jun 26, 2015, at 11:40 AM, TR Shaw wrote: > > But what about us in Northwestern Ontario who can only get dialup, if that, from Bell? Seriously - write to your MP and MLA. Landon Stewart landonstewart at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 909 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ops.lists at gmail.com Fri Jun 26 18:58:12 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 27 Jun 2015 00:28:12 +0530 Subject: =?utf-8?Q?Re:_World's_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Message-ID: <667BE024-748F-4D34-84E8-20CE5DBC660F@gmail.com> Like Peter Lothberg's mother's home :) --srs > On 27-Jun-2015, at 12:22 am, Mikael Abrahamsson wrote: > > And yes, "fastest Internet in the world" is pure BS, gigabit ethernet access to peoples homes have been around for years in other places From mureninc at gmail.com Fri Jun 26 18:59:42 2015 From: mureninc at gmail.com (Constantine A. Murenin) Date: Fri, 26 Jun 2015 11:59:42 -0700 Subject: =?UTF-8?Q?Re=3A_World=27s_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: References: Message-ID: On 26 June 2015 at 11:04, Hank Disuko wrote: > Bell Canada is apparently gearing up to provide the good people of Toronto with the World's Fastest Internet?. > http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html Only 1Gbps?! LOL, but US Internet offers 10Gbps! http://fiber.usinternet.com/plans-and-prices/ https://lobste.rs/s/mv7bzs/us_internet_to_offer_higher-speed_10gbps_connections_in_minneapolis_for_400_usd Yes, residential; yes, 10000Mbps; yes, only 399,00 USD/mo, which amounts to 39 bucks per gigabit. Bell's 1Gbps is by no means the world's fastest internet. Not even in Canada: http://www.cbc.ca/news/technology/small-alberta-town-gets-massive-1-000-mbps-broadband-boost-1.1382428 http://montrealgazette.com/technology/canada-can-learn-from-olds-ab-the-city-with-the-fastest-internet-speed >>>> While homes in cities like Vancouver, Montreal, and Toronto are toiling with maximum speeds only up to 100 megabits per second, in Olds Alberta ? 90 kilometres north of Calgary ? they have access to one Gigabit per second connections, and at the bargain basement rate of $57 per month, with no data caps. Also, is Bell any different from AT&T and Verizon in that it doesn't peer with like anyone? Will most Canadian traffic still go through Chicago or New York? C. From bross at pobox.com Fri Jun 26 19:01:01 2015 From: bross at pobox.com (Brandon Ross) Date: Fri, 26 Jun 2015 15:01:01 -0400 (EDT) Subject: =?UTF-8?Q?Re=3A_World's_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Message-ID: On Fri, 26 Jun 2015, Rafael Possamai wrote: > How does one fully utilize a gigabit link for home use? For a single person > it is overkill. Similar to the concept of price elasticity in economics, > going from 50mbps to 1gbps doesn't necessarily increase your average > transfer rate, at least I don't think it would for me. Why would you use average transfer rate as the metric for user experience quality? Most users don't care about their long term bandwidth average, they care about getting that movie playing _right_now_, or HD video calls with all the grandchildren, all at once. Heck, they care more about web pages showing up on the screen nice and fast more than average download speed. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From paul at paulstewart.org Fri Jun 26 19:03:10 2015 From: paul at paulstewart.org (Paul Stewart) Date: Fri, 26 Jun 2015 15:03:10 -0400 Subject: =?UTF-8?Q?RE:_World's_Fastest_Internet=E2=84=A2_in?= =?UTF-8?Q?_Canadaland?= In-Reply-To: References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Message-ID: <008801d0b042$becdc1b0$3c694510$@paulstewart.org> Personally I think it's pure marketing ... something I think we all know... I seen a few years back a FTTH development get completed using GPON - everything in the area got "Full Gig Internet". Speedtest while I was onsite showed about 900Mb/s download so pretty darn close (before they fully deployed). The interesting part was that the development consisted of 4400 active users the last time I heard but the bandwidth to upstream provider was still only a single GigE and was not hitting serious saturation levels most of the time. Paul -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rafael Possamai Sent: Friday, June 26, 2015 2:39 PM To: Eric Dugas Cc: NANOG Subject: Re: World's Fastest Internet? in Canadaland How does one fully utilize a gigabit link for home use? For a single person it is overkill. Similar to the concept of price elasticity in economics, going from 50mbps to 1gbps doesn't necessarily increase your average transfer rate, at least I don't think it would for me. Anyone care to comment? Just really curious, as to me it's more of a marketing push than anything else, even though gigabit to the home sounds really cool. On Fri, Jun 26, 2015 at 1:13 PM, Eric Dugas wrote: > Nice try Bell.. So-Net did it two years ago, 2Gbps FTTH in Japan. > > Article: http://bgr.com/2013/06/13/so-net-nuro-2gbps-fiber-service/ > > If you read Japanese: http://www.nuro.jp/hikari/ > > Eric > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hank Disuko > Sent: June 26, 2015 2:04 PM > To: NANOG > Subject: World's Fastest Internet? in Canadaland > > Bell Canada is apparently gearing up to provide the good people of > Toronto with the World's Fastest Internet?. > > http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-t > oronto-worlds-fastest-internet.html > > > From list at satchell.net Fri Jun 26 19:59:45 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 26 Jun 2015 12:59:45 -0700 Subject: World's Fastest =?UTF-8?B?SW50ZXJuZXTihKIgaW4gQ2FuYWRhbGFuZA==?= In-Reply-To: <008801d0b042$becdc1b0$3c694510$@paulstewart.org> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> <008801d0b042$becdc1b0$3c694510$@paulstewart.org> Message-ID: <558DAF31.2010709@satchell.net> On 06/26/2015 12:03 PM, Paul Stewart wrote: > Personally I think it's pure marketing ... something I think we all > know... > > I seen a few years back a FTTH development get completed using GPON - > everything in the area got "Full Gig Internet". Speedtest while I > was onsite showed about 900Mb/s download so pretty darn close (before > they fully deployed). > > The interesting part was that the development consisted of 4400 > active users the last time I heard but the bandwidth to upstream > provider was still only a single GigE and was not hitting serious > saturation levels most of the time. I have worked on server room networking, and found that it takes quite a bit of tweaking of the interfaces and the TCP stack to get things up to 80 percent usage of a gigabit link. Both ends. So your side can go like the wind, but your data source may not be able to fill the pipe. So I agree that, for most people, this will be pure marketing hype. As for the 4400 users, that's the classical oversubscription model. From kauer at biplane.com.au Fri Jun 26 20:02:08 2015 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 27 Jun 2015 06:02:08 +1000 Subject: World's Fastest =?UTF-8?Q?Internet=E2=84=A2?= in Canadaland In-Reply-To: References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Message-ID: <1435348928.2626.47.camel@karl> On Fri, 2015-06-26 at 13:39 -0500, Rafael Possamai wrote: > How does one fully utilize a gigabit link for home use? For a single person > it is overkill. This sentiment keeps popping up. It's a failure of vision. To suggest that "single people" or "ordinary people" or any other set of presumably average and uninteresting people will never be able to fully utilise the amazing properties of X, and that they can and should be satisfied with some limited version of X or the even more limited alternative Y, is to completely miss the point. And to actually provide no more than that is to build a self-fulfilling prophecy. Look at pretty much any modern technology and you can be sure that when it was first invented someone wearing the then equivalent of a brown cardigan said "yes, that's all very well, but what use will ordinary people ever have for it?". When the first little fire sputtered into life in some Neanderthal cave you can bet that some troglodyte said "no point make bigger, me warm enough, more hot waste of effort", but of course he hadn't thought of bronze, iron, steel, glass, welding or rocketry. Or the steam engine or the internal combustion engine. What luck that his kids ignored him, eh? As William Gibson wrote, "the street finds its uses for things". I can't think of anything I would or could do with a terabit Internet link - but it's not me who needs it. It's the kids now in school who will build it, and their kids will think it commonplace. And they will look back at you and me and think "how did our grandparents ever manage with only a couple of gigabits? How limiting!" And while they are thinking that, some bright young things will report that they think they've got a primitive exabit link working... Regards, K. PS: There are only three real values for network speeds, just as there are only three values for amount of personal fortune, RAM, disk space and CPU speed. The three values are "not enough", "enough" and "I don't know". Always aspire to "I don't know". -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From owen at delong.com Fri Jun 26 20:06:26 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Jun 2015 13:06:26 -0700 Subject: =?utf-8?Q?Re=3A_World=27s_Fastest_Internet=E2=84=A2_in_Canadalan?= =?utf-8?Q?d?= In-Reply-To: <1435348928.2626.47.camel@karl> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> <1435348928.2626.47.camel@karl> Message-ID: <15774063-8F93-4E33-9D0C-878CBFEF2FBF@delong.com> > On Jun 26, 2015, at 13:02 , Karl Auer wrote: > > On Fri, 2015-06-26 at 13:39 -0500, Rafael Possamai wrote: >> How does one fully utilize a gigabit link for home use? For a single person >> it is overkill. > > This sentiment keeps popping up. It's a failure of vision. To suggest > that "single people" or "ordinary people" or any other set of presumably > average and uninteresting people will never be able to fully utilise the > amazing properties of X, and that they can and should be satisfied with > some limited version of X or the even more limited alternative Y, is to > completely miss the point. And to actually provide no more than that is > to build a self-fulfilling prophecy. I see a potential market for perhaps hundreds of aircraft in the coming century. lol Owen From rafael at gav.ufsc.br Fri Jun 26 20:11:22 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 26 Jun 2015 15:11:22 -0500 Subject: =?UTF-8?Q?Re=3A_World=27s_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: <1435348928.2626.47.camel@karl> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> <1435348928.2626.47.camel@karl> Message-ID: That comment was made from a customer perspective (myself) while I wonder if I ever would wanna pay for it, although it seems like it's pretty cheap already. As an entrepreneur, business, etc... then yes, I agree. Shoot for the stars and land on the moon. :) On Fri, Jun 26, 2015 at 3:02 PM, Karl Auer wrote: > On Fri, 2015-06-26 at 13:39 -0500, Rafael Possamai wrote: > > How does one fully utilize a gigabit link for home use? For a single > person > > it is overkill. > > This sentiment keeps popping up. It's a failure of vision. To suggest > that "single people" or "ordinary people" or any other set of presumably > average and uninteresting people will never be able to fully utilise the > amazing properties of X, and that they can and should be satisfied with > some limited version of X or the even more limited alternative Y, is to > completely miss the point. And to actually provide no more than that is > to build a self-fulfilling prophecy. > > Look at pretty much any modern technology and you can be sure that when > it was first invented someone wearing the then equivalent of a brown > cardigan said "yes, that's all very well, but what use will ordinary > people ever have for it?". > > When the first little fire sputtered into life in some Neanderthal cave > you can bet that some troglodyte said "no point make bigger, me warm > enough, more hot waste of effort", but of course he hadn't thought of > bronze, iron, steel, glass, welding or rocketry. Or the steam engine or > the internal combustion engine. What luck that his kids ignored him, eh? > > As William Gibson wrote, "the street finds its uses for things". > > I can't think of anything I would or could do with a terabit Internet > link - but it's not me who needs it. It's the kids now in school who > will build it, and their kids will think it commonplace. And they will > look back at you and me and think "how did our grandparents ever manage > with only a couple of gigabits? How limiting!" And while they are > thinking that, some bright young things will report that they think > they've got a primitive exabit link working... > > Regards, K. > > PS: There are only three real values for network speeds, just as there > are only three values for amount of personal fortune, RAM, disk space > and CPU speed. The three values are "not enough", "enough" and "I don't > know". Always aspire to "I don't know". > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 > Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 > > > From amekkaoui at mektel.ca Fri Jun 26 20:30:05 2015 From: amekkaoui at mektel.ca (A MEKKAOUI) Date: Fri, 26 Jun 2015 16:30:05 -0400 Subject: =?UTF-8?Q?RE:_World's_Fastest_Internet=E2=84=A2_in?= =?UTF-8?Q?_Canadaland?= In-Reply-To: References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Message-ID: <003d01d0b04e$e41ae590$ac50b0b0$@ca> Your right. Actually, Bell knows that home does not need that much BW, Bell size their network for much less than that. However, from a marketing perspective, when Bell says to a client I am offering you 1G at $100 and competition are offering you 30M at $60, some clients likes that because they ignore that 1G will not make a difference compared to 30M. Also Bell is currently using ADSL technology to provide internet service which is a dead technology. So, Bell has no choice but to move to fiber if they want to stay on the market. KARIM M. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rafael Possamai Sent: 26 juin 2015 14:39 To: Eric Dugas Cc: NANOG Subject: Re: World's Fastest Internet? in Canadaland How does one fully utilize a gigabit link for home use? For a single person it is overkill. Similar to the concept of price elasticity in economics, going from 50mbps to 1gbps doesn't necessarily increase your average transfer rate, at least I don't think it would for me. Anyone care to comment? Just really curious, as to me it's more of a marketing push than anything else, even though gigabit to the home sounds really cool. On Fri, Jun 26, 2015 at 1:13 PM, Eric Dugas wrote: > Nice try Bell.. So-Net did it two years ago, 2Gbps FTTH in Japan. > > Article: http://bgr.com/2013/06/13/so-net-nuro-2gbps-fiber-service/ > > If you read Japanese: http://www.nuro.jp/hikari/ > > Eric > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hank Disuko > Sent: June 26, 2015 2:04 PM > To: NANOG > Subject: World's Fastest Internet? in Canadaland > > Bell Canada is apparently gearing up to provide the good people of > Toronto with the World's Fastest Internet?. > > http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-t > oronto-worlds-fastest-internet.html > > > From mikea at mikea.ath.cx Fri Jun 26 20:35:40 2015 From: mikea at mikea.ath.cx (mikea) Date: Fri, 26 Jun 2015 15:35:40 -0500 Subject: World's Fastest =?utf-8?Q?Internet?= =?utf-8?B?4oSi?= in Canadaland In-Reply-To: <15774063-8F93-4E33-9D0C-878CBFEF2FBF@delong.com> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> <1435348928.2626.47.camel@karl> <15774063-8F93-4E33-9D0C-878CBFEF2FBF@delong.com> Message-ID: <20150626203540.GB69606@mikea.ath.cx> On Fri, Jun 26, 2015 at 01:06:26PM -0700, Owen DeLong wrote: > > > On Jun 26, 2015, at 13:02 , Karl Auer wrote: > > > > On Fri, 2015-06-26 at 13:39 -0500, Rafael Possamai wrote: > >> How does one fully utilize a gigabit link for home use? For a single person > >> it is overkill. > > > > This sentiment keeps popping up. It's a failure of vision. To suggest > > that "single people" or "ordinary people" or any other set of presumably > > average and uninteresting people will never be able to fully utilise the > > amazing properties of X, and that they can and should be satisfied with > > some limited version of X or the even more limited alternative Y, is to > > completely miss the point. And to actually provide no more than that is > > to build a self-fulfilling prophecy. > > I see a potential market for perhaps hundreds of aircraft in the coming century. And just possibly for more than seven computers on the continent. *Any* continent. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From mikea at mikea.ath.cx Fri Jun 26 20:39:00 2015 From: mikea at mikea.ath.cx (mikea) Date: Fri, 26 Jun 2015 15:39:00 -0500 Subject: World's Fastest =?utf-8?Q?Internet?= =?utf-8?B?4oSi?= in Canadaland In-Reply-To: <003d01d0b04e$e41ae590$ac50b0b0$@ca> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> <003d01d0b04e$e41ae590$ac50b0b0$@ca> Message-ID: <20150626203900.GC69606@mikea.ath.cx> On Fri, Jun 26, 2015 at 04:30:05PM -0400, A MEKKAOUI wrote: > Your right. Actually, Bell knows that home does not need that much > BW, Bell size their network for much less than that. However, from a > marketing perspective, when Bell says to a client I am offering you > 1G at $100 and competition are offering you 30M at $60, some clients > likes that because they ignore that 1G will not make a difference > compared to 30M. > > Also Bell is currently using ADSL technology to provide internet > service which is a dead technology. So, Bell has no choice but to move > to fiber if they want to stay on the market. > > KARIM M. When I'm downloading an ISO or USB bootable image of, say, FreeBSD 10.x, that speed difference makes a difference to me. I grant that I'm not Joe Typical by any means, but the number of people who aren't Joe Typical isn't zero -- not by a good bit. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From randy at psg.com Fri Jun 26 20:57:29 2015 From: randy at psg.com (Randy Bush) Date: Sat, 27 Jun 2015 05:57:29 +0900 Subject: World's Fastest =?UTF-8?B?SW50ZXJuZXTihKI=?= in Canadaland In-Reply-To: References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Message-ID: > How does one fully utilize a gigabit link for home use? we once asked how a home user would use 56kb, how anyone needed more than 640k in a pee cee, how we would need more than 32 bits in an address. the only thing not rising is water levels. except the ocean, that is. randy From nanog at ics-il.net Fri Jun 26 21:01:38 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 26 Jun 2015 16:01:38 -0500 (CDT) Subject: =?utf-8?Q?Re:_World's_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: Message-ID: <335296361.4899.1435352530416.JavaMail.mhammett@ThunderFuck> Some of those are why would one EVER need more than X, while others are why would one NOW need more than X. Big difference. Simple fact that there is no residential application that needs more than even 50 megabit much less 10,000 megabit. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Randy Bush" To: "Rafael Possamai" Cc: "NANOG" Sent: Friday, June 26, 2015 3:57:29 PM Subject: Re: World's Fastest Internet? in Canadaland > How does one fully utilize a gigabit link for home use? we once asked how a home user would use 56kb, how anyone needed more than 640k in a pee cee, how we would need more than 32 bits in an address. the only thing not rising is water levels. except the ocean, that is. randy From clayton at MNSi.Net Fri Jun 26 21:12:25 2015 From: clayton at MNSi.Net (Clayton Zekelman) Date: Fri, 26 Jun 2015 17:12:25 -0400 Subject: =?iso-8859-1?Q?Re:_World's_Fastest_Internet=99_in_Canadaland?= In-Reply-To: <335296361.4899.1435352530416.JavaMail.mhammett@ThunderFuck > References: <335296361.4899.1435352530416.JavaMail.mhammett@ThunderFuck> Message-ID: <1435353149_77896@surgemail.mnsi.net> We recently had to pull some year over year statistics on consumption for a regulatory filing. In 2009, our average customer used 11G of data. This year it is 85G. In 5 years it could be 400G or more. What's worse is, OTT video means that consumption is more than likely going to be at peak hours, driving capacity issues. The average multi device household streaming HD video and gaming, and whatever else comes along will drive usage. I honestly don't care what people do with their Internet connection. I just know that I need to find ways to deliver more, because they're going to want it - even if they don't need it. At 05:01 PM 26/06/2015, Mike Hammett wrote: >Some of those are why would one EVER need more than X, while others >are why would one NOW need more than X. Big difference. Simple fact >that there is no residential application that needs more than even >50 megabit much less 10,000 megabit. > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > > > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From mikea at mikea.ath.cx Fri Jun 26 21:11:35 2015 From: mikea at mikea.ath.cx (mikea) Date: Fri, 26 Jun 2015 16:11:35 -0500 Subject: World's Fastest =?utf-8?Q?Internet?= =?utf-8?B?4oSi?= in Canadaland In-Reply-To: <335296361.4899.1435352530416.JavaMail.mhammett@ThunderFuck> References: <335296361.4899.1435352530416.JavaMail.mhammett@ThunderFuck> Message-ID: <20150626211135.GD69606@mikea.ath.cx> On Fri, Jun 26, 2015 at 04:01:38PM -0500, Mike Hammett wrote: > Some of those are why would one EVER need more than X, while others are why > would one NOW need more than X. Big difference. Simple fact that there is > no residential application that needs more than even 50 megabit much less > 10,000 megabit. Define "need". On the average, I probably don't need more than 56 KBaud, integrated over all the years I've been linked to the 'Net from home. Would I be willing to put up with it? Hell, no! Would I be willing to put up with 10 Gig to the house for what I'm paying now? Emphatically yes. Ditto 1 Gig. What I'm getting isn't more than 10 megabit down and 2.5 up, so a fatter pipe would be very welcome. At the same price, or even another $50/month. But I don't need it in the sense that I'll lose money or customers if I don't have it. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From bill at herrin.us Fri Jun 26 21:25:23 2015 From: bill at herrin.us (William Herrin) Date: Fri, 26 Jun 2015 17:25:23 -0400 Subject: Any Verizon datacenter techs about? In-Reply-To: <0C637A28-1AE3-4D1C-A9CE-81C3769D7B7D@rs.hmail.seastrom.com> References: <20150626142653.GB80937@geeks.org> <0C637A28-1AE3-4D1C-A9CE-81C3769D7B7D@rs.hmail.seastrom.com> Message-ID: On Fri, Jun 26, 2015 at 4:11 PM, Robert Seastrom wrote: > On Jun 26, 2015, at 11:34 AM, William Herrin wrote: >> I'm told second hand that when MCI/worldcom (now Verizon Business) >> controlled 8100 Boone Blvd (the early MAE-East) you had to buy a data >> circuit from them to get between floors. Not a cable or a >> cross-connect. A data circuit at the 0-mile tariffed price. > > 4) The sole grain of truth to this story is that for inter-cabinet connections inside the colo, MFS and later Worldcom demanded that one pay for a zero mile local loop and that the circuit pass through actual transport kit so that it could be "managed" - and also billed at insanely-high-for-what-it-was "data rate" prices. > > 5) They managed to extend outside-the-building circuits from the node room to the colo room on a very-long-patch-cord basis, but it was like pulling teeth to get them to agree to *not* put a pair of muxes back to back to drive 400 feet of fiber down to B2 where the facility I managed was. Finally, after many escalations sanity prevailed and the fiber that got installed from 5 to B2 was 288-strand SMF-28 to a patch panel... and no muxes. Hah! Well, like I said, I had it second hand. Stories do grow in the telling. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From mark.tinka at seacom.mu Fri Jun 26 21:31:56 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 26 Jun 2015 23:31:56 +0200 Subject: =?UTF-8?Q?Re:_World's_Fastest_Internet=e2=84=a2_in_Canadaland?= In-Reply-To: <20150626211135.GD69606@mikea.ath.cx> References: <335296361.4899.1435352530416.JavaMail.mhammett@ThunderFuck> <20150626211135.GD69606@mikea.ath.cx> Message-ID: <558DC4CC.3080403@seacom.mu> On 26/Jun/15 23:11, mikea wrote: > Define "need". On the average, I probably don't need more than 56 KBaud, > integrated over all the years I've been linked to the 'Net from home. Would I > be willing to put up with it? Hell, no! Would I be willing to put up with 10 > Gig to the house for what I'm paying now? Emphatically yes. > > Ditto 1 Gig. What I'm getting isn't more than 10 megabit down and 2.5 up, so a > fatter pipe would be very welcome. At the same price, or even another $50/month. > > But I don't need it in the sense that I'll lose money or customers if I don't > have it. Assuming a service provider is looking to stay in business by delivering more services on top of your garden variety Net, then considering the quality of the pipe coming into the home is the first thing. If I built an FTTH network (which would be Active-E, in my case), I'd deliver 1Gbps to every home. This does not mean I am going to sell 1Gbps of Internet access bandwidth to that home. It just means I have 1Gbps of bandwidth into the home. And what can I do with that? - I can sell classic Net. - I can sell classic Voice. - I can sell classic Tv. - I can sell Streaming Tv. - I can sell VoD. - e.t.c. When I market to my customers, I don't market "You have 1Gbps in your home. Now go make babies." I market the services I will be able to deliver over that bandwidth. If an ISP can deliver 1Gbps into the home, why limit thinking to conventions around bandwidth? Customers only care about bandwidth if it's getting in the way. Otherwise, all they want to know is how many VoD streams they can enjoy in 1080p, how many concurrent iPads and laptops in the house they can download a full movie on in 5 minutes, how many sports channels come in the Tv package, and whether they get flat-rate for international voice calls. The bandwidth - well, that is a given. You have to deliver all those services somehow... 1Gbps is just a port on a switch; it's not that big a deal. Mark. From andy at newslink.com Fri Jun 26 21:36:34 2015 From: andy at newslink.com (Andy Ringsmuth) Date: Fri, 26 Jun 2015 16:36:34 -0500 Subject: =?utf-8?Q?Re=3A_World=27s_Fastest_Internet=E2=84=A2_in_Canadalan?= =?utf-8?Q?d?= In-Reply-To: <335296361.4899.1435352530416.JavaMail.mhammett@ThunderFuck> References: <335296361.4899.1435352530416.JavaMail.mhammett@ThunderFuck> Message-ID: > On Jun 26, 2015, at 4:01 PM, Mike Hammett wrote: > > Some of those are why would one EVER need more than X, while others are why would one NOW need more than X. Big difference. Simple fact that there is no residential application that needs more than even 50 megabit much less 10,000 megabit. Oh sure there is. What happens when you use Carbonite or one of the other online backup services and needed a full restore? I bet the average home user, considering one to three or four PCs, could easily have a few terabytes of data. A 500G disk dies and you restore a backup. Bingo, you?re pegging the meter for quite a while. Or even routine backups. On my Mac, after an average day at the office, my Time Machine backup runs anywhere from 1 to 10 gigabytes. If I were to run a Carbonite-type backup when I got home, that?s a substantial chunk. -Andy From jared at puck.nether.net Fri Jun 26 21:48:07 2015 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 26 Jun 2015 17:48:07 -0400 Subject: =?utf-8?Q?Re=3A_World=27s_Fastest_Internet=E2=84=A2_in_Canadalan?= =?utf-8?Q?d?= In-Reply-To: References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Message-ID: The issue here is economics. 1G hardware is cheap, as in sub-$100 for a 1G CPE with SMF in one side and RJ45 out the other. Even if you decide to limit yourself at 100m or similar, if you build it at the optics side, it is more expensive than building at 1G. Because of this, 1G is the most sensible speed/solution. I believe that many people won?t get a real quantity of usage from their links because they will be on 2.4ghz wifi regardless. If you have your home wired, you might get something faster but the largest users these days tend to be adaptive streaming video which uses around 16Mb/s for a 4K stream from Netflix, or software updates from Apple. Speaking of which, since 8.4 is launching next week and tends to be one of the larger internet events these days (more so than victoria secret turned out to be by ratio) I?m awaiting a surge of software updates for all the iDevices around the world. - Jared > On Jun 26, 2015, at 2:39 PM, Rafael Possamai wrote: > > How does one fully utilize a gigabit link for home use? For a single person > it is overkill. Similar to the concept of price elasticity in economics, > going from 50mbps to 1gbps doesn't necessarily increase your average > transfer rate, at least I don't think it would for me. Anyone care to > comment? Just really curious, as to me it's more of a marketing push than > anything else, even though gigabit to the home sounds really cool. > > > > On Fri, Jun 26, 2015 at 1:13 PM, Eric Dugas wrote: > >> Nice try Bell.. So-Net did it two years ago, 2Gbps FTTH in Japan. >> >> Article: http://bgr.com/2013/06/13/so-net-nuro-2gbps-fiber-service/ >> >> If you read Japanese: http://www.nuro.jp/hikari/ >> >> Eric >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hank Disuko >> Sent: June 26, 2015 2:04 PM >> To: NANOG >> Subject: World's Fastest Internet? in Canadaland >> >> Bell Canada is apparently gearing up to provide the good people of Toronto >> with the World's Fastest Internet?. >> >> http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html >> >> >> From marka at isc.org Fri Jun 26 21:56:03 2015 From: marka at isc.org (Mark Andrews) Date: Sat, 27 Jun 2015 07:56:03 +1000 Subject: =?UTF-8?Q?Re=3A_World=27s_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: Your message of "Fri, 26 Jun 2015 13:39:23 -0500." References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> Message-ID: <20150626215603.87EE331651DC@rock.dv.isc.org> In message , Rafael Possamai writes: > How does one fully utilize a gigabit link for home use? For a single person > it is overkill. Similar to the concept of price elasticity in economics, > going from 50mbps to 1gbps doesn't necessarily increase your average > transfer rate, at least I don't think it would for me. Anyone care to > comment? Just really curious, as to me it's more of a marketing push than > anything else, even though gigabit to the home sounds really cool. Overkill is good provided it doesn't cost too much more. You want the connection speed to not be a limitation on what you are trying to do. 1G does that at a good price point these days. At some point in the future 1G will seem slow and there will be a new speed that stops the link speed being the limitation. You don't think about the size of power lines coming into a house as they are overkill for just about anything you will do in the house. You don't think about the size of water pipes coming into a house as they are overkill for just about anything you will do in the house. Very occasionally you will want to connect directly to the mains (filling a pool) but otherwise the pipe is more that sufficient. The worry should be over the gigabytes transfered, the kilowatthours and the kilolitres consumed which are the actual resources being delivered. Unfortunately ISP's have made it about link speed rather than what it really is about because link speed was 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 cidr-report at potaroo.net Fri Jun 26 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Jun 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201506262200.t5QM00oE066089@wattle.apnic.net> This report has been generated at Fri Jun 26 21:17:55 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 19-06-15 558465 311797 20-06-15 557822 304583 21-06-15 557973 304716 22-06-15 558238 304106 23-06-15 558195 304707 24-06-15 558651 303797 25-06-15 558676 304034 26-06-15 559284 304723 AS Summary 51017 Number of ASes in routing system 20289 Number of ASes announcing only one prefix 3256 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120759552 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'). --- 26Jun15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 559555 304724 254831 45.5% All ASes AS22773 3185 171 3014 94.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2792 71 2721 97.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2698 78 2620 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS9394 2920 316 2604 89.2% CTTNET China TieTong Telecommunications Corporation,CN AS39891 2473 34 2439 98.6% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2286 119 2167 94.8% NET Servi?os de Comunica??o S.A.,BR AS3356 2588 788 1800 69.6% LEVEL3 - Level 3 Communications, Inc.,US AS10620 3256 1554 1702 52.3% Telmex Colombia S.A.,CO AS4766 2952 1358 1594 54.0% KIXS-AS-KR Korea Telecom,KR AS6983 1749 247 1502 85.9% ITCDELTA - Earthlink, Inc.,US AS7545 2649 1165 1484 56.0% TPG-INTERNET-AP TPG Telecom Limited,AU AS9808 1551 67 1484 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS20115 1863 489 1374 73.8% CHARTER-NET-HKY-NC - Charter Communications,US AS7303 1633 293 1340 82.1% Telecom Argentina S.A.,AR AS4755 2024 709 1315 65.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS6147 1568 302 1266 80.7% Telefonica del Peru S.A.A.,PE AS9498 1355 122 1233 91.0% BBIL-AP BHARTI Airtel Ltd.,IN AS4323 1614 413 1201 74.4% TWTC - tw telecom holdings, inc.,US AS22561 1383 286 1097 79.3% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS7552 1154 60 1094 94.8% VIETEL-AS-AP Viettel Corporation,VN AS4808 1505 502 1003 66.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS6849 1206 216 990 82.1% UKRTELNET JSC UKRTELECOM,UA AS8151 1699 721 978 57.6% Uninet S.A. de C.V.,MX AS8402 988 23 965 97.7% CORBINA-AS OJSC "Vimpelcom",RU AS18566 2054 1137 917 44.6% MEGAPATH5-US - MegaPath Corporation,US AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS4538 1954 1040 914 46.8% ERX-CERNET-BKB China Education and Research Network Center,CN AS26615 1077 177 900 83.6% Tim Celular S.A.,BR AS38285 979 126 853 87.1% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4780 1095 279 816 74.5% SEEDNET Digital United Inc.,TW Total 57249 12946 44303 77.4% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.3.0/24 AS37004 -Reserved AS-,ZZ 41.73.4.0/24 AS37004 -Reserved AS-,ZZ 41.73.5.0/24 AS37004 -Reserved AS-,ZZ 41.73.6.0/24 AS37004 -Reserved AS-,ZZ 41.73.7.0/24 AS37004 -Reserved AS-,ZZ 41.73.8.0/24 AS37004 -Reserved AS-,ZZ 41.73.9.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.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.67.78.0/24 AS38040 GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited,TH 64.28.145.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 64.28.146.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 66.11.224.0/21 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.234.0/24 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.11.236.0/22 AS29873 BIZLAND-SD - The Endurance International Group, Inc.,US 66.59.192.0/19 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,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 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.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 75.98.128.0/20 AS22652 FIBRENOIRE-INTERNET - Fibrenoire Inc.,CA 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 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 88.135.64.0/20 AS48347 MTW-AS JSC MediaSoft Ekspert,RU 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.218.36.0/22 AS19714 -Reserved AS-,ZZ 91.229.5.0/24 AS56923 -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 103.10.222.0/24 AS13189 103.11.16.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.18.44.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.45.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.18.47.0/24 AS18351 MEDIAAKSES-AS PT Media Akses Global Indo, Internet Provider Jakarta,ID 103.19.219.0/24 AS58887 103.20.100.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.101.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.37.188.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.38.152.0/24 AS1828 UNITAS - Unitas Global LLC,US 103.38.154.0/24 AS1828 UNITAS - Unitas Global LLC,US 103.225.116.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.227.4.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.227.184.0/22 AS10021 KVH KVH Co.,Ltd,JP 103.228.8.0/22 AS13145 CPROCOLTD-AS-AP C-PRO CO., LTD.,KH 103.228.84.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.228.224.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.230.116.0/22 AS59351 103.232.104.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.232.142.0/23 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,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.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 140.81.0.0/16 AS20053 RELAX-LLC-AS LLC Relax,RU 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 144.1.0.0/16 AS20055 RUCLICK-AS RU-CLICK LLC,RU 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 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 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.110.208.0/20 AS39414 HYPERVPN - Fairway Network, Inc.,US 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 179.60.128.0/20 AS26317 , 180.222.120.0/21 AS23818 JETINTERNET JETINTERNET Corporation,JP 181.225.156.0/22 AS10834 Telefonica de Argentina,AR 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.40.183.0/24 AS62300 -Reserved AS-,ZZ 185.106.104.0/24 AS50113 SUPERSERVERSDATACENTER MediaServicePlus Ltd.,RU 186.148.224.0/21 AS52302 Awknet International, S.A.,PA 188.190.96.0/19 AS19714 -Reserved AS-,ZZ 188.190.103.0/24 AS19714 -Reserved AS-,ZZ 188.190.112.0/24 AS19714 -Reserved AS-,ZZ 188.190.113.0/24 AS19714 -Reserved AS-,ZZ 188.190.114.0/24 AS19714 -Reserved AS-,ZZ 188.190.117.0/24 AS19714 -Reserved AS-,ZZ 188.190.118.0/24 AS19714 -Reserved AS-,ZZ 188.190.119.0/24 AS19714 -Reserved AS-,ZZ 188.190.120.0/24 AS19714 -Reserved AS-,ZZ 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.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.206.140.0/24 AS54926 -Reserved AS-,ZZ 192.206.141.0/24 AS54926 -Reserved AS-,ZZ 192.206.142.0/24 AS54926 -Reserved AS-,ZZ 192.206.143.0/24 AS54926 -Reserved AS-,ZZ 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 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.56.203.0/24 AS51110 IDOMTECHNOLOGIES-AS IDOM TECHNOLOGIES,FR 193.105.154.0/24 AS34023 -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.151.160.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 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 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 193.200.130.0/24 AS21104 AM-NETSYS-AS Netsys JV LLC,AM 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.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.9.9.0/24 AS2863 SPRITELINK Centor AB,SE 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.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.180.0/24 AS37004 -Reserved AS-,ZZ 196.3.181.0/24 AS37004 -Reserved AS-,ZZ 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.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 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -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.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.38.248.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.249.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.250.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.251.0/24 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.38.252.0/22 AS13951 CENTER-SEVEN - C7 Data Centers, Inc.,US 199.66.15.0/24 AS30169 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.103.89.0/24 AS19523 -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.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.58.248.0/21 AS27849 200.59.208.0/20 AS26317 , 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 201.131.5.0/24 AS28389 -Reserved AS-,ZZ 201.131.88.0/24 AS8151 Uninet S.A. de C.V.,MX 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.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.122.134.0/24 AS38615 202.140.147.0/24 AS9583 SIFY-AS-IN Sify Limited,IN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 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.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.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems 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 204.235.245.0/24 AS22613 -Reserved AS-,ZZ 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 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.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.73.40.0/22 AS19901 -Reserved AS-,ZZ 208.73.41.0/24 AS19901 -Reserved AS-,ZZ 208.74.12.0/23 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,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 CENTURYLINK-US-LEGACY-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 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,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.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 Jun 26 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Jun 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201506262200.t5QM01E8066105@wattle.apnic.net> BGP Update Report Interval: 18-Jun-15 -to- 25-Jun-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 295162 5.8% 293.4 -- BSNL-NIB National Internet Backbone,IN 2 - AS11139 282275 5.5% 1049.3 -- CWDOM - Cable & Wireless Dominica,DM 3 - AS23752 274915 5.4% 2272.0 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - AS36947 86277 1.7% 1513.6 -- ALGTEL-AS,DZ 5 - AS54169 65664 1.3% 32832.0 -- MGH-ION-1 - Marin General Hospital,US 6 - AS3709 63193 1.2% 2340.5 -- NET-CITY-SA - City of San Antonio,US 7 - AS28024 60787 1.2% 39.4 -- Nuevatel PCS de Bolivia S.A.,BO 8 - AS22059 41677 0.8% 20838.5 -- -Reserved AS-,ZZ 9 - AS8402 41576 0.8% 110.6 -- CORBINA-AS OJSC "Vimpelcom",RU 10 - AS25563 35835 0.7% 8958.8 -- WEBLAND-AS Webland AG,CH 11 - AS38197 31134 0.6% 22.6 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 12 - AS391 30965 0.6% 118.2 -- AFCONC-BLOCK1-AS - 754th Electronic Systems Group,US 13 - AS10834 30420 0.6% 166.2 -- Telefonica de Argentina,AR 14 - AS25577 26596 0.5% 397.0 -- C4L-AS Connexions4London Ltd,GB 15 - AS39891 25799 0.5% 16.8 -- ALJAWWALSTC-AS Saudi Telecom Company JSC,SA 16 - AS48159 25566 0.5% 75.0 -- TIC-AS Telecommunication Infrastructure Company,IR 17 - AS3816 25023 0.5% 59.4 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 18 - AS4249 24371 0.5% 15.3 -- LILLY-AS - Eli Lilly and Company,US 19 - AS13036 20344 0.4% 1271.5 -- TMOBILE-CZ T-Mobile Czech Republic a.s.,CZ 20 - AS246 19693 0.4% 44.5 -- ASIFICS-GW-AS - 754th Electronic Systems Group,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS54169 65664 1.3% 32832.0 -- MGH-ION-1 - Marin General Hospital,US 2 - AS22059 41677 0.8% 20838.5 -- -Reserved AS-,ZZ 3 - AS393588 9604 0.2% 9604.0 -- MUBEA-FLO - Mubea,US 4 - AS25563 35835 0.7% 8958.8 -- WEBLAND-AS Webland AG,CH 5 - AS61039 5307 0.1% 5307.0 -- ZMZ OAO ZMZ,RU 6 - AS32005 13093 0.3% 4364.3 -- THE-CHURCH-PENSION-GROUP - CHURCH PENSION GROUP SERVICES CORPORATION,US 7 - AS201522 4002 0.1% 4002.0 -- UB330-NET UB330.net d.o.o.,SI 8 - AS40637 3395 0.1% 3395.0 -- MAILROUTE - MailRoute, Inc.,US 9 - AS38000 6084 0.1% 3042.0 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN 10 - AS20173 9428 0.2% 2357.0 -- Televisa, S.A de C.V.,MX 11 - AS3709 63193 1.2% 2340.5 -- NET-CITY-SA - City of San Antonio,US 12 - AS23752 274915 5.4% 2272.0 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 13 - AS35798 2201 0.0% 2201.0 -- DEVERYWARE DEVERYWARE S.A.,FR 14 - AS10292 16183 0.3% 2022.9 -- CWJ-1 - Cable & Wireless Jamaica,JM 15 - AS13943 7439 0.1% 1859.8 -- YK-COMMUNICATIONS - YK Communications, Inc.,US 16 - AS31357 11768 0.2% 1681.1 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 17 - AS27644 1642 0.0% 1642.0 -- THREATSTOP - ThreatSTOP,US 18 - AS56636 1636 0.0% 1636.0 -- ASVEDARU VEDA Ltd.,RU 19 - AS57233 1630 0.0% 1630.0 -- ASKOMPANON Kompanon LLC.,RU 20 - AS36947 86277 1.7% 1513.6 -- ALGTEL-AS,DZ TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.64.0/21 139889 2.6% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.88.0/21 133259 2.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 105.96.0.0/22 85890 1.6% AS36947 -- ALGTEL-AS,DZ 4 - 204.80.242.0/24 65660 1.2% AS54169 -- MGH-ION-1 - Marin General Hospital,US 5 - 200.0.251.0/24 29629 0.6% AS10834 -- Telefonica de Argentina,AR 6 - 64.34.125.0/24 21241 0.4% AS22059 -- -Reserved AS-,ZZ 7 - 76.191.107.0/24 20436 0.4% AS22059 -- -Reserved AS-,ZZ 8 - 208.163.55.0/24 15511 0.3% AS10292 -- CWJ-1 - Cable & Wireless Jamaica,JM 9 - 41.216.207.0/24 12217 0.2% AS37105 -- NEOLOGY-AS,ZA 10 - 92.43.216.0/21 12183 0.2% AS25563 -- WEBLAND-AS Webland AG,CH 11 - 185.84.192.0/22 11940 0.2% AS25563 -- WEBLAND-AS Webland AG,CH 12 - 78.140.0.0/18 11710 0.2% AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 13 - 178.174.96.0/19 11709 0.2% AS25563 -- WEBLAND-AS Webland AG,CH 14 - 192.58.137.0/24 9604 0.2% AS393588 -- MUBEA-FLO - Mubea,US 15 - 203.192.255.0/24 9597 0.2% AS17665 -- IN2CABLE-AP AS Number of In2cable.com (India) Ltd.,IN 16 - 192.58.232.0/24 8390 0.2% AS6629 -- NOAA-AS - NOAA,US 17 - 94.73.56.0/21 7409 0.1% AS42081 -- SPEEDY-NET-AS Speedy net EAD,BG 18 - 199.66.144.0/21 7294 0.1% AS13943 -- YK-COMMUNICATIONS - YK Communications, Inc.,US 19 - 65.48.215.0/24 7258 0.1% AS11139 -- CWDOM - Cable & Wireless Dominica,DM 20 - 65.48.216.0/24 7244 0.1% AS11139 -- CWDOM - Cable & Wireless Dominica,DM 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 Jun 26 22:15:54 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 27 Jun 2015 00:15:54 +0200 Subject: =?UTF-8?Q?Re:_World's_Fastest_Internet=e2=84=a2_in_Canadaland?= In-Reply-To: <20150626215603.87EE331651DC@rock.dv.isc.org> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> <20150626215603.87EE331651DC@rock.dv.isc.org> Message-ID: <558DCF1A.9050500@seacom.mu> On 26/Jun/15 23:56, Mark Andrews wrote: > > > Unfortunately ISP's have made it about link speed rather than what > it really is about because link speed was the limiting factor. When 1Gbps becomes mainstream to the home, I think it will stop being about link speed (well, for a while anyway, because who knows...). As others have mentioned, a single device pulling 1Gbps in the home is asking a lot, even if it were connected to the home router via copper/fibre. As most devices in the home will be wi-fi-based, 1Gbps is safe (for now). Of course, more devices in the home will put pressure on 1Gbps, but not before they put pressure on the wi-fi network. So again, 1Gbps is safe, for now. The wired devices that could draw on that 1Gbps big time will be the STB's, gaming consoles (even those use wi-fi), home media servers, e.t.c. Depending on what one does with those, they may or may not draw much from the 1Gbps fibre coming into the house. Even if the service provider was dropping a 1080p or 4K IPTv Multicast stream into 3x STB's in the home (one for the living room, one for the man-cave and another random one in the house), and each STB had at least two tuners (watch on one tuner, record from another tuner), you're still looking at less than 120Mbps for all 3x STB's running + recording simultaneously, assuming each tuner is pulling 20Mbps when active. Of course, with 2015 families not glued to their Tv's as much as previous generations did, that is less demand for classic Tv. So all in all, with 1Gbps, there is a reasonable chance that, at the very least, the connection between the home and the nearest service provider switch will be utilitarian. The problem now is, who gets that 1Gbps link to their house, around the world? Mark. From owen at delong.com Fri Jun 26 22:17:28 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Jun 2015 15:17:28 -0700 Subject: =?utf-8?Q?Re=3A_World=27s_Fastest_Internet=E2=84=A2_in_Canadalan?= =?utf-8?Q?d?= In-Reply-To: <335296361.4899.1435352530416.JavaMail.mhammett@ThunderFuck> References: <335296361.4899.1435352530416.JavaMail.mhammett@ThunderFuck> Message-ID: <8838D335-7228-4D02-833E-531956BD6B11@delong.com> It?s not just about the transfer rate, though. As has been noted, response times at peak congestion are definitely faster if you have more bandwidth. So if you?ve got 3 kids all wanting to stream different HD5k content, 50Mbits is going to get interesting. 100Mbps will probably handle it with enough of a jitter buffer. 10G you can probably play instant on and let the jitter buffer build while playing the first few seconds. There are a number of other tactics that can improve user experience with more bandwidth than is needed for the long-term average. Average transfer rate is a silly way to measure anticipated user experience, as has been pointed out by others. Owen > On Jun 26, 2015, at 14:01 , Mike Hammett wrote: > > Some of those are why would one EVER need more than X, while others are why would one NOW need more than X. Big difference. Simple fact that there is no residential application that needs more than even 50 megabit much less 10,000 megabit. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > ----- Original Message ----- > > From: "Randy Bush" > To: "Rafael Possamai" > Cc: "NANOG" > Sent: Friday, June 26, 2015 3:57:29 PM > Subject: Re: World's Fastest Internet? in Canadaland > >> How does one fully utilize a gigabit link for home use? > > we once asked how a home user would use 56kb, how anyone needed more > than 640k in a pee cee, how we would need more than 32 bits in an > address. > > the only thing not rising is water levels. except the ocean, that is. > > randy > From rafael at gav.ufsc.br Fri Jun 26 22:20:43 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Fri, 26 Jun 2015 17:20:43 -0500 Subject: =?UTF-8?Q?Re=3A_Re=3A_World=27s_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: <20150626215603.87EE331651DC@rock.dv.isc.org> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> <20150626215603.87EE331651DC@rock.dv.isc.org> Message-ID: Good points. But just like I won't take more than one shower at a time, I probably won't watch more than one Netflix stream session at a time (assuming that for myself only). Downloading a large ISO image in seconds is definitely a plus, although at the office I never reach a steady 120MB/s from some Linux mirror out there. I've recently created a Debian mirror and the 1500GB or so of data came at an average speed of 270mbps using a 1gbps datacenter link. I think it will still be a while until we can saturate a 1gbps link inside the average home. While there are people working hard to deliver 1gbps FTTH, there are others working equally as hard in developing video compression algorithms to utilize less bandwidth on the content provider side. Not arguing against it, I'm just throwing gas at the fire to see what different perspectives come out. On Fri, Jun 26, 2015 at 4:56 PM, Mark Andrews wrote: > > In message < > CAJB2g-H2cccqUD7_BhpoyDo+BeYSyZpy+js2P+hJ6RUk0QX-hQ at mail.gmail.com> > , Rafael Possamai writes: > > How does one fully utilize a gigabit link for home use? For a single > person > > it is overkill. Similar to the concept of price elasticity in economics, > > going from 50mbps to 1gbps doesn't necessarily increase your average > > transfer rate, at least I don't think it would for me. Anyone care to > > comment? Just really curious, as to me it's more of a marketing push than > > anything else, even though gigabit to the home sounds really cool. > > Overkill is good provided it doesn't cost too much more. You want > the connection speed to not be a limitation on what you are trying > to do. 1G does that at a good price point these days. At some > point in the future 1G will seem slow and there will be a new speed > that stops the link speed being the limitation. > > You don't think about the size of power lines coming into a house > as they are overkill for just about anything you will do in the > house. > > You don't think about the size of water pipes coming into a house > as they are overkill for just about anything you will do in the > house. Very occasionally you will want to connect directly to the > mains (filling a pool) but otherwise the pipe is more that sufficient. > > The worry should be over the gigabytes transfered, the kilowatthours > and the kilolitres consumed which are the actual resources being > delivered. > > Unfortunately ISP's have made it about link speed rather than what > it really is about because link speed was 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 owen at delong.com Fri Jun 26 22:23:00 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Jun 2015 15:23:00 -0700 Subject: =?windows-1252?Q?Re=3A_World=27s_Fastest_Internet=99_in_Canadala?= =?windows-1252?Q?nd?= In-Reply-To: <558DCF1A.9050500@seacom.mu> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> <20150626215603.87EE331651DC@rock.dv.isc.org> <558DCF1A.9050500@seacom.mu> Message-ID: 10Gbps inside the home at an economical price for the phys means IP Multicast can finally be a viable alternative (replacement for) HDMI. No more will you connect one Blu-Ray player to One Amp to One TV. You?ll just connect them all to ethernet. Amps and TVs will have UIs which allow you to subscribe to streams provided by Blu-Rays and other media sources. Want to watch something on two TVs while listening to the audio through a particular amp in the house, no problem. Set up the stream on the provider device and subscribe on the TVs and the Amp. When it?s all set, press play and enjoy. Want to pause it and move to a third TV and change amps? No problem. Pause, reconfigure the subscriptions, and resume. Of course this will require the RIAA and their friends to either come up with new ways to be obnoxious to consumers or to perform an extraction of their crania from their collective rectums about DRM in order to be viable, but I?m sure one or more of those things will happen eventually. Owen > On Jun 26, 2015, at 15:15 , Mark Tinka wrote: > > > > On 26/Jun/15 23:56, Mark Andrews wrote: >> >> >> Unfortunately ISP's have made it about link speed rather than what >> it really is about because link speed was the limiting factor. > > When 1Gbps becomes mainstream to the home, I think it will stop being > about link speed (well, for a while anyway, because who knows...). > > As others have mentioned, a single device pulling 1Gbps in the home is > asking a lot, even if it were connected to the home router via > copper/fibre. As most devices in the home will be wi-fi-based, 1Gbps is > safe (for now). Of course, more devices in the home will put pressure on > 1Gbps, but not before they put pressure on the wi-fi network. So again, > 1Gbps is safe, for now. > > The wired devices that could draw on that 1Gbps big time will be the > STB's, gaming consoles (even those use wi-fi), home media servers, > e.t.c. Depending on what one does with those, they may or may not draw > much from the 1Gbps fibre coming into the house. > > Even if the service provider was dropping a 1080p or 4K IPTv Multicast > stream into 3x STB's in the home (one for the living room, one for the > man-cave and another random one in the house), and each STB had at least > two tuners (watch on one tuner, record from another tuner), you're still > looking at less than 120Mbps for all 3x STB's running + recording > simultaneously, assuming each tuner is pulling 20Mbps when active. Of > course, with 2015 families not glued to their Tv's as much as previous > generations did, that is less demand for classic Tv. > > So all in all, with 1Gbps, there is a reasonable chance that, at the > very least, the connection between the home and the nearest service > provider switch will be utilitarian. The problem now is, who gets that > 1Gbps link to their house, around the world? > > Mark. > From jabley at hopcount.ca Fri Jun 26 23:26:54 2015 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 26 Jun 2015 20:26:54 -0300 Subject: World's Fastest =?utf-8?q?Internet=E2=84=A2?= in Canadaland In-Reply-To: References: Message-ID: <1FA3734A-DF71-444B-8F2A-27B8A5A1C7D2@hopcount.ca> On 26 Jun 2015, at 15:04, Hank Disuko wrote: > Bell Canada is apparently gearing up to provide the good people of > Toronto with the World's Fastest Internet?. > http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html Bell Canada is in the business of defending the current regulatory regime from claims that internet speeds are slow, or that investment by incumbents in the last mile is lacking, or that it ought to be required to share its access network with competitors. Read the press with that context in mind. There's cooperative, rural broadband in the UK [1] that offers 10G access to farms at a lower price than Bell charges for some satellite TV bundles. I don't think anybody need waste any cycles persuading other people here that the "fastest internet" claims are not aligned precisely with the kind reality you find even on this list. Joe [1] http://b4rn.org.uk From johnmusbach1 at gmail.com Sat Jun 27 00:32:58 2015 From: johnmusbach1 at gmail.com (John Musbach) Date: Fri, 26 Jun 2015 20:32:58 -0400 Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: On Thu, Jun 25, 2015 at 5:32 PM, Christopher Morrow wrote: > On Wed, Jun 24, 2015 at 2:46 PM, John Musbach wrote: >> Hello, >> >> I'm a techie that recently moved to South Jersey for a tech job. To my >> astonishment, I discovered that there appears to be a Verizon >> datacenter near my house that has colocation: > > how / why did you think this has colocation? Look at the second picture, the sign on the door more specifically. :) -- John Musbach From johnmusbach1 at gmail.com Sat Jun 27 00:36:36 2015 From: johnmusbach1 at gmail.com (John Musbach) Date: Fri, 26 Jun 2015 20:36:36 -0400 Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: On Thu, Jun 25, 2015 at 5:37 PM, Christopher Morrow wrote: > On Thu, Jun 25, 2015 at 5:32 PM, Christopher Morrow > wrote: >> On Wed, Jun 24, 2015 at 2:46 PM, John Musbach wrote: >>> Hello, >>> >>> I'm a techie that recently moved to South Jersey for a tech job. To my >>> astonishment, I discovered that there appears to be a Verizon >>> datacenter near my house that has colocation: >> >> how / why did you think this has colocation? >> > > https://www22.verizon.com/wholesale/attachments/space-exhaust/Web_UpdateSouth.pdf > > if you search for somers point in there this looks like a Central > office which might offer future physical (future from 2012) > colocation, but I bet you'd have to be a CLEC to take advantage of > this... Ohh ok. I suppose that colo entrance being for CLECs would make sense haha. Too much of a dream for a general population colocation datacenter to be near residential I guess. Was worth a try. -- John Musbach From johnmusbach1 at gmail.com Sat Jun 27 00:40:14 2015 From: johnmusbach1 at gmail.com (John Musbach) Date: Fri, 26 Jun 2015 20:40:14 -0400 Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: On Fri, Jun 26, 2015 at 8:36 PM, John Musbach wrote: > On Thu, Jun 25, 2015 at 5:37 PM, Christopher Morrow > wrote: >> On Thu, Jun 25, 2015 at 5:32 PM, Christopher Morrow >> wrote: >>> On Wed, Jun 24, 2015 at 2:46 PM, John Musbach wrote: >>>> Hello, >>>> >>>> I'm a techie that recently moved to South Jersey for a tech job. To my >>>> astonishment, I discovered that there appears to be a Verizon >>>> datacenter near my house that has colocation: >>> >>> how / why did you think this has colocation? >>> >> >> https://www22.verizon.com/wholesale/attachments/space-exhaust/Web_UpdateSouth.pdf >> >> if you search for somers point in there this looks like a Central >> office which might offer future physical (future from 2012) >> colocation, but I bet you'd have to be a CLEC to take advantage of >> this... > > Ohh ok. I suppose that colo entrance being for CLECs would make sense > haha. Too much of a dream for a general population colocation > datacenter to be near residential I guess. Was worth a try. P.S. If there was any way to get a tour inside of there at least I'd totally sign a NDA for that. :) Never been inside, let alone near, a CO before. -- John Musbach From joe at nethead.com Sat Jun 27 00:44:32 2015 From: joe at nethead.com (Joe Hamelin) Date: Fri, 26 Jun 2015 17:44:32 -0700 Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: On Fri, Jun 26, 2015 at 5:40 PM, John Musbach wrote: > . > > P.S. If there was any way to get a tour inside of there at least I'd > totally sign a NDA for that. :) Never been inside, let alone near, a > CO before. > http://museumofcommunications.org/?page_id=12 -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From larrysheldon at cox.net Sat Jun 27 01:31:26 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 26 Jun 2015 20:31:26 -0500 Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: <558DFCEE.2070602@cox.net> On 6/26/2015 19:44, Joe Hamelin wrote: > On Fri, Jun 26, 2015 at 5:40 PM, John Musbach > wrote: > >> . >> >> P.S. If there was any way to get a tour inside of there at least I'd >> totally sign a NDA for that. :) Never been inside, let alone near, a >> CO before. >> > > http://museumofcommunications.org/?page_id=12 There are three parts of a #5 Crossbar switch for which I have a special fondness: The exerciser routine--late at night in a (sometimes spooky) dark, quiet office you hear a clicking noise that come up from behind you and passes on into the distance in front of you, After a bit, you realize that it is approaching again....and again, each time a little lower down as the exerciser operated EVERY crosspoint in the office, one at a time. The Transverter -- a monument to the Perfect Kludge. The Trouble Recorder -- a card-punch that punches a card every time a call fails, to record all of the equipment (and some other stuff) that was involved in the call. The cards were BIG (4 inches by 16 inches, maybe) and I have no idea what the number of possible hole locations was and had printed on-the card a cryptic notation as to what each hole meant. The most interesting thing was the fact that there were notations on both sides of the card--a given hole had two meanings depending on which side of the card the hole had been punched it. Thye first thing you looked at was two holes (I forget what one of the markings was, bit one hole said "AMA" on one side and "Turn Card Over" on the other side. (I was not a switchman, so the number of errors possible here us huge.) -- sed quis custodiet ipsos custodes? (Juvenal) From larrysheldon at cox.net Sat Jun 27 01:37:34 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 26 Jun 2015 20:37:34 -0500 Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: <558DFE5E.1020202@cox.net> On 6/26/2015 20:31, Larry Sheldon wrote: > On 6/26/2015 19:44, Joe Hamelin wrote: >> On Fri, Jun 26, 2015 at 5:40 PM, John Musbach >> wrote: >> >>> . >>> >>> P.S. If there was any way to get a tour inside of there at least I'd >>> totally sign a NDA for that. :) Never been inside, let alone near, a >>> CO before. >>> >> >> http://museumofcommunications.org/?page_id=12 > > There are three parts of a #5 Crossbar switch for which I have a special > fondness: > > The exerciser routine--late at night in a (sometimes spooky) dark, quiet > office you hear a clicking noise that come up from behind you and > passes on into the distance in front of you, After a bit, you realize > that it is approaching again....and again, each time a little lower down > as the exerciser operated EVERY crosspoint in the office, one at a time. > > The Transverter -- a monument to the Perfect Kludge. > > The Trouble Recorder -- a card-punch that punches a card every time a > call fails, to record all of the equipment (and some other stuff) that > was involved in the call. The cards were BIG (4 inches by 16 inches, > maybe) and I have no idea what the number of possible hole locations was > and had printed on-the card a cryptic notation as to what each hole > meant. The most interesting thing was the fact that there were > notations on both sides of the card--a given hole had two meanings > depending on which side of the card the hole had been punched it. Thye > first thing you looked at was two holes (I forget what one of the > markings was, bit one hole said "AMA" on one side and "Turn Card Over" > on the other side. (I was not a switchman, so the number of errors > possible here us huge.) I didn't realise that there was a relevant picture in the museum set -- http://museumofcommunications.org/wp-content/uploads/2012/06/DSC_7116-1024x680.jpg shows severak of those cards on shelves, and in the near fore-ground is the bins used for sorting cards for further investigation (one of the "investigation" steps was to take a deck of cards for a similar failure and hold the deck up to the light to see if a single piece of equipment had been involved in every failure (hole goes through the deck). > > -- sed quis custodiet ipsos custodes? (Juvenal) From morrowc.lists at gmail.com Sat Jun 27 02:37:57 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 26 Jun 2015 22:37:57 -0400 Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: On Fri, Jun 26, 2015 at 8:32 PM, John Musbach wrote: > On Thu, Jun 25, 2015 at 5:32 PM, Christopher Morrow > wrote: >> On Wed, Jun 24, 2015 at 2:46 PM, John Musbach wrote: >>> Hello, >>> >>> I'm a techie that recently moved to South Jersey for a tech job. To my >>> astonishment, I discovered that there appears to be a Verizon >>> datacenter near my house that has colocation: >> >> how / why did you think this has colocation? > > Look at the second picture, the sign on the door more specifically. :) oriiginal view of the door sign was not readable... had to do some work to see 'co locators entrance'. Bet this means 'clec entrance' (they probably forgot to include the hours of operation: 9-4, lunch 11-3) From swmike at swm.pp.se Sat Jun 27 02:51:16 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 27 Jun 2015 04:51:16 +0200 (CEST) Subject: =?UTF-8?Q?RE=3A_World's_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: <008801d0b042$becdc1b0$3c694510$@paulstewart.org> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> <008801d0b042$becdc1b0$3c694510$@paulstewart.org> Message-ID: On Fri, 26 Jun 2015, Paul Stewart wrote: > The interesting part was that the development consisted of 4400 active > users the last time I heard but the bandwidth to upstream provider was > still only a single GigE and was not hitting serious saturation levels > most of the time. I'd say for any kind of serious FTTH deployment, peak hour average user will be around 0.5 - 2 megabit/s, so if you actually want a user who buys 100/100 to be able to use that at peak hour, you're looking at an oversubscription factor of around 1/10th of the above, ie around 500 users on a gigabit ethernet uplink. -- Mikael Abrahamsson email: swmike at swm.pp.se From jra at baylink.com Sat Jun 27 03:06:34 2015 From: jra at baylink.com (Jay Ashworth) Date: Fri, 26 Jun 2015 23:06:34 -0400 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 Message-ID: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> And that's the ballgame. http://www.reddit.com/r/ipv6/comments/3b5p3i/arin_just_subdivided_their_last_1718192021_and_22/ -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From tqr2813d376cjozqap1l at tutanota.com Sat Jun 27 03:47:53 2015 From: tqr2813d376cjozqap1l at tutanota.com (tqr2813d376cjozqap1l at tutanota.com) Date: Sat, 27 Jun 2015 03:47:53 +0000 (UTC) Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: 27. Jun 2015 03:06 by jra at baylink.com: > And that's the ballgame. > > http://www.reddit.com/r/ipv6/comments/3b5p3i/arin_just_subdivided_their_last_1718192021_and_22 > And here's to another eternity of shitty ISPs not implementing IPv6 because 'they have enough v4 already'. From lost at l-w.ca Sat Jun 27 03:58:27 2015 From: lost at l-w.ca (William Astle) Date: Fri, 26 Jun 2015 21:58:27 -0600 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: <558E1F63.8010806@l-w.ca> On 15-06-26 09:47 PM, tqr2813d376cjozqap1l at tutanota.com wrote: > 27. Jun 2015 03:06 by jra at baylink.com: > >> And that's the ballgame. >> >> http://www.reddit.com/r/ipv6/comments/3b5p3i/arin_just_subdivided_their_last_1718192021_and_22 > > > And here's to another eternity of shitty ISPs not implementing IPv6 because > 'they have enough v4 already'. Not necessarily just shitty ISPs either. Like certain data centers attached to AS701 in Canada. Been getting the runaround from them on that for far too many years. Last answer was "we can but we're not going to because effort". From alter3d at alter3d.ca Sat Jun 27 04:15:59 2015 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Sat, 27 Jun 2015 00:15:59 -0400 Subject: World's Fastest =?UTF-8?B?SW50ZXJuZXTihKIgaW4gQ2FuYWRhbGFuZA==?= In-Reply-To: <1FA3734A-DF71-444B-8F2A-27B8A5A1C7D2@hopcount.ca> References: <1FA3734A-DF71-444B-8F2A-27B8A5A1C7D2@hopcount.ca> Message-ID: <558E237F.1060602@alter3d.ca> On 6/26/2015 7:26 PM, Joe Abley wrote: > > On 26 Jun 2015, at 15:04, Hank Disuko wrote: > >> Bell Canada is apparently gearing up to provide the good people of >> Toronto with the World's Fastest Internet?. >> http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html >> > > Bell Canada is in the business of defending the current regulatory > regime from claims that internet speeds are slow, or that investment > by incumbents in the last mile is lacking, or that it ought to be > required to share its access network with competitors. Read the press > with that context in mind. > > There's cooperative, rural broadband in the UK [1] that offers 10G > access to farms at a lower price than Bell charges for some satellite > TV bundles. I don't think anybody need waste any cycles persuading > other people here that the "fastest internet" claims are not aligned > precisely with the kind reality you find even on this list. > > Joe > > [1] http://b4rn.org.uk And defend the current regulatory regime well they do. I live literally minutes outside of the Ottawa urban area and I have as choices for network connectivity either LoS wireless or satellite. I can, however, stand at the end of my driveway and look in EITHER direction to see houses that can get cable service, yet none of the incumbents are willing to service my little stretch of road (affecting me and ~5 neighbours). I'm told by the neighbours (I just moved here) that they've been bugging the incumbents for YEARS and getting no traction at all. I'm thinking of pricing out a fiber run and running a little local co-op network access provider for me and the neighbours, but I suspect that install costs might nix that idea. (For extra fun, I was told by one of the incumbents that my address was serviceable with up to 150Mbps cable before I purchased the property. Then when I took possession and tried to get service set up -- nope, sorry. But that's a whole other story...) From tony at lavanauts.org Sat Jun 27 09:26:17 2015 From: tony at lavanauts.org (Antonio Querubin) Date: Fri, 26 Jun 2015 23:26:17 -1000 (HST) Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: On Fri, 26 Jun 2015, Jay Ashworth wrote: > And that's the ballgame. > > http://www.reddit.com/r/ipv6/comments/3b5p3i/arin_just_subdivided_their_last_1718192021_and_22/ Nah, probably two more days if you just do a straight line extrapolation based on today's data. So Tuesday or Wednesday is more likely with an ever increasing confidence level of complete runout by Independence Day. I sense a metaphor in there somewhere :) Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From randy at psg.com Sat Jun 27 09:57:37 2015 From: randy at psg.com (Randy Bush) Date: Sat, 27 Jun 2015 18:57:37 +0900 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: the rirs have run out of their free source of short ints to rent to us. i am sure everyone will move to ipv6 in a week. news at eleven. randy From rafael at gav.ufsc.br Sat Jun 27 12:35:34 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sat, 27 Jun 2015 07:35:34 -0500 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: Randy, How long do you think it will take to completely get rid of IPv4? Or is it even going to happen at all? On Sat, Jun 27, 2015 at 4:57 AM, Randy Bush wrote: > the rirs have run out of their free source of short ints to rent to us. > i am sure everyone will move to ipv6 in a week. news at eleven. > > randy > From matthew at matthew.at Sat Jun 27 14:23:07 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 27 Jun 2015 07:23:07 -0700 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: Except for AfriNIC And so we'll get to hear "the sky is falling" one last time Matthew Kaufman (Sent from my iPhone) > On Jun 27, 2015, at 2:57 AM, Randy Bush wrote: > > the rirs have run out of their free source of short ints to rent to us. > i am sure everyone will move to ipv6 in a week. news at eleven. > > randy From bob at FiberInternetCenter.com Sat Jun 27 14:38:43 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Sat, 27 Jun 2015 07:38:43 -0700 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: Our fundamental issue is that an IPv4 address has no real value as networks still give them away, it's pennies in your pocket. Everything of use needs to have a cost to motivate for change. Establishing that now won't create change it will first create greater conservation. There will be a cost that will be reached before change takes place on a scale that matters. Networks set the false perception and customer expectation that address space is free and readily available. Networks with plenty, still land many customers today by handing over a class C to customer with less than 10 servers and 5 people in an office. We have a greater supply for packets to travel than we do for addresses required to move packets. Do you know how many packets a single IP address can generate or utilize, if it was attached too "The World's Fastest Internet" in someplace like Canadaland or Sweden on init7's Fiber7 ? No matter how large the pipe the answer is always, "all of it". It's address space we should now place a price upon. Unlike, My Space's disappearance when Facebook arrived there is no quick jump to IPv6. There is no coordinated effort required that involves millions of people to change browser window content. But to answer your question... Everything that is handed over for free is perceived as having no value. Therefore, IPv4 has to cost much more than the cost to change to IPv6 today. While the IPv6 addresses are free, it is expensive to change. Businesses spend lots of money on a free lunches. It's going to take at least the price of one good lunch per IP address per month to create the consideration for change. That's about $30 for 2 people in California. Offering a /48 of free IPv6 space to everyone on the planet didn't make it happen. There is no financial incentive to move to IPv6. In fact there is more reason "not to change" than "to change". The new gear cost $$$ (lots of it didn't work well and required exploration to learn that), IT people need hours to implement (schedules are full of day-to-day issues), networks keep growing with offerings that drop Internet costs and save everyone money, business as usual is productive on IPv4 (business doesn't have time for distraction), many of us get distracted by something more immediate and interesting than buying a new wi-fi router for the home. What will come first ? A) the earths future core rotation changes altering the ionosphere in such a way that we are all exposed to continuous x-rays that shorten our lifespan OR B) the last IPv4 computer running will be reconfigured to IPv6 Thank You Bob Evans CTO > Randy, > > How long do you think it will take to completely get rid of IPv4? Or is it > even going to happen at all? > > On Sat, Jun 27, 2015 at 4:57 AM, Randy Bush wrote: > >> the rirs have run out of their free source of short ints to rent to us. >> i am sure everyone will move to ipv6 in a week. news at eleven. >> >> randy >> > From swmike at swm.pp.se Sat Jun 27 14:54:17 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 27 Jun 2015 16:54:17 +0200 (CEST) Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: On Sat, 27 Jun 2015, Rafael Possamai wrote: > How long do you think it will take to completely get rid of IPv4? Or is > it even going to happen at all? I believe somewhere around 2018-2025 a lot of ISPs, hosting providers etc will start to treat IPv4 as a second rate citizen and for the people still single-stacked to IPv4 by then, the Internet experience is going to become so bad that they'll beg to get IPv6 and the ones not providing it will feel severe business impact of not doing IPv6. Mobile providers will be the first huge ones to go IPv6 only to the devices, which will mean that from your mobile device, IPv4 will most likely work worse than IPv6. Then it's downhill from there. -- Mikael Abrahamsson email: swmike at swm.pp.se From deleskie at gmail.com Sat Jun 27 15:02:22 2015 From: deleskie at gmail.com (jim deleskie) Date: Sat, 27 Jun 2015 12:02:22 -0300 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: I'd give it another 20 yrs of v4, v6 addressing and all those letters are to hard for us old folk, we'll find ways to make it make it work :) On Sat, Jun 27, 2015 at 11:54 AM, Mikael Abrahamsson wrote: > On Sat, 27 Jun 2015, Rafael Possamai wrote: > > How long do you think it will take to completely get rid of IPv4? Or is >> it even going to happen at all? >> > > I believe somewhere around 2018-2025 a lot of ISPs, hosting providers etc > will start to treat IPv4 as a second rate citizen and for the people still > single-stacked to IPv4 by then, the Internet experience is going to become > so bad that they'll beg to get IPv6 and the ones not providing it will feel > severe business impact of not doing IPv6. > > Mobile providers will be the first huge ones to go IPv6 only to the > devices, which will mean that from your mobile device, IPv4 will most > likely work worse than IPv6. Then it's downhill from there. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From randy at psg.com Sat Jun 27 15:13:25 2015 From: randy at psg.com (Randy Bush) Date: Sun, 28 Jun 2015 00:13:25 +0900 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: > How long do you think it will take to completely get rid of IPv4? not in our lifetimes From tmorizot at gmail.com Sat Jun 27 15:27:01 2015 From: tmorizot at gmail.com (Scott Morizot) Date: Sat, 27 Jun 2015 10:27:01 -0500 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: On Sat, Jun 27, 2015 at 9:38 AM, Bob Evans wrote: > What will come first ? > A) the earths future core rotation changes altering the ionosphere in such > a way that we are all exposed to continuous x-rays that shorten our > lifespan > OR > B) the last IPv4 computer running will be reconfigured to IPv6 > > Thank You > Bob Evans > CTO > At least from a large enterprise perspective, I don't really care when IPv4 is removed from that last computer. Instead, I care about how long it will take us to eliminate IPv4 from most or all of our internal network and confine its continued support to our dual-stacked public resources and legacy support at our perimeter. In particular, our plans right now focus on transitioning to a native IPv6-only wide area network providing legacy protocol support where needed using LISP. (We already have LISP configured and deployed to our largest sites.) We're in the process of ensuring all clients are dual-stacked and deploying IPv6 to internal applications. We are testing and developing a process to create IPv4 "enclaves" in our data centers for applications that cannot timely transition fronted by NAT64 so we can start removing IPv4 from our many smaller access network sites. It's not really our problem or concern how long some people choose to keep IPv4-only systems running, even as those systems increasingly become second-class citizens on the network. Running a large, fully dual-stacked enterprise network is overly-complex, increases costs, and imposes limitations. As time proceeds, I expect most enterprises that haven't already done so will reach a similar conclusion. I've never worked at a carrier or ISP, so I have no particular insight into the drivers pushing those sorts of networks. But the presentation by Comcast on possible plans to provide long term legacy IPv4 support as an overlay service suggest to me that the drivers are not completely dissimilar from their perspective. So it really doesn't matter that much how long IPv4 continues to exist in one sense or another. It's the tipping point where much of the Internet begins to treat it as a second-class citizen that really matters. I would suggest most people will not like ending up on the wrong side of that curve. My perspective, anyway. Scott From Valdis.Kletnieks at vt.edu Sat Jun 27 16:18:58 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 27 Jun 2015 12:18:58 -0400 Subject: World's Fastest Internet™ in Canadaland In-Reply-To: Your message of "Fri, 26 Jun 2015 15:35:40 -0500." <20150626203540.GB69606@mikea.ath.cx> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> <1435348928.2626.47.camel@karl> <15774063-8F93-4E33-9D0C-878CBFEF2FBF@delong.com> <20150626203540.GB69606@mikea.ath.cx> Message-ID: <18126.1435421938@turing-police.cc.vt.edu> On Fri, 26 Jun 2015 15:35:40 -0500, mikea said: > And just possibly for more than seven computers on the continent. Note that there's scant evidence that Thomas Watson actually said it - and more evidence that others said something similar. Also, given that during that timeframe there was already more than 5 or 7 computers in existence, there's reason to think that what was being discussed (no matter who it was) was similar to what we now call a "supercomputer" - take a look at the Top 10 systems in the Top500 list, and there's always just 5-10 beasts that are an order of magnitude faster than the huge pile from slots 11 to 100.... https://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_misquote -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From kuenzler at init7.net Sat Jun 27 16:37:22 2015 From: kuenzler at init7.net (Fredy Kuenzler) Date: Sat, 27 Jun 2015 18:37:22 +0200 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: <558ED142.3010503@init7.net> Am 27.06.2015 um 16:38 schrieb Bob Evans: > We have a greater supply for packets to travel than we do for > addresses required to move packets. Do you know how many packets a > single IP address can generate or utilize, if it was attached too > "The World's Fastest Internet" in someplace like Canadaland or Sweden > on init7's Fiber7 ? Thanks for mentioning Fiber7, which is actually available in Switzerland, not Sweden. And every Fiber7 customer gets a /48, too. -- Fredy Kuenzler --------------------- Fiber7. No Limits. https://www.fiber7.ch --------------------- Init7 (Switzerland) Ltd. AS13030 St.-Georgen-Strasse 70 CH-8400 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 / @kuenzler http://www.init7.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From saku at ytti.fi Sat Jun 27 16:47:35 2015 From: saku at ytti.fi (Saku Ytti) Date: Sat, 27 Jun 2015 19:47:35 +0300 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: <20150627164735.GA12676@pob.ytti.fi> On (2015-06-27 07:38 -0700), Bob Evans wrote: Hey Bob, > What will come first ? > A) the earths future core rotation changes altering the ionosphere in such > a way that we are all exposed to continuous x-rays that shorten our > lifespan As a firm believer of sustainable development I furiously believe that once this solar system becomes uninhabitable we've takenflora and fauna in galactic Noah's Ark to next useful system. Any development prohibiting this outcome is clearly less sustainable. Having said that, both IPv4 and IPv6 will be obsolete before heath death of universe, but I believe IPv4 will out-live IPv6 much like 2G GSM will outlive 3G, due to various legacy applications. None of this will matter much to us, as it'll be deep in the edge taken care by integrators not operators. > B) the last IPv4 computer running will be reconfigured to IPv6 Never. The cost of doing so in some environments will eclipse cost of translating at the edge, for same reason there are IPX, X.25, FrameRelay, ATM, CLNS networks for decades to come. All or nothing proposals are rarely data-driven decisions, but tend to be sentimental decisions 'x is old, thus it must be gone' -- ++ytti From baconzombie at gmail.com Sat Jun 27 16:49:07 2015 From: baconzombie at gmail.com (Bacon Zombie) Date: Sat, 27 Jun 2015 18:49:07 +0200 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: <558ED142.3010503@init7.net> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <558ED142.3010503@init7.net> Message-ID: Is anybody still using IPX or TokenRing? I've heard that TokenRing is over 9000 times better for iSCSI since you are guaranteed that the packets will not get collisions. On 27 Jun 2015 18:39, "Fredy Kuenzler" wrote: > Am 27.06.2015 um 16:38 schrieb Bob Evans: > > We have a greater supply for packets to travel than we do for > > addresses required to move packets. Do you know how many packets a > > single IP address can generate or utilize, if it was attached too > > "The World's Fastest Internet" in someplace like Canadaland or Sweden > > on init7's Fiber7 ? > > Thanks for mentioning Fiber7, which is actually available in > Switzerland, not Sweden. And every Fiber7 customer gets a /48, too. > > -- > Fredy Kuenzler > > --------------------- > Fiber7. No Limits. > https://www.fiber7.ch > --------------------- > > Init7 (Switzerland) Ltd. > AS13030 > St.-Georgen-Strasse 70 > CH-8400 Winterthur > Skype: flyingpotato > Phone: +41 44 315 4400 > Fax: +41 44 315 4401 > Twitter: @init7 / @kuenzler > http://www.init7.net/ > > From lyndon at orthanc.ca Sat Jun 27 17:23:27 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 27 Jun 2015 10:23:27 -0700 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> On Jun 27, 2015, at 5:35 AM, Rafael Possamai wrote: > How long do you think it will take to completely get rid of IPv4? Or is it > even going to happen at all? IPX ruled the roost, very popularly, for a little while. How long did it take to die? Why did it die? What were the triggers that pushed it over the cliff? I think there's a lot to be learned from that piece of recent history. Specifically, as a demonstration of how a "most popular" protocol can find itself ejected from the arena in the blink of an eye. I knew several people who built their career path on the assumptions of IPX. Ouch. --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From d3e3e3 at gmail.com Sat Jun 27 17:35:13 2015 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sat, 27 Jun 2015 13:35:13 -0400 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> Message-ID: On Sat, Jun 27, 2015 at 1:23 PM, Lyndon Nerenberg wrote: > > On Jun 27, 2015, at 5:35 AM, Rafael Possamai wrote: > > > How long do you think it will take to completely get rid of IPv4? Or is it > > even going to happen at all? > > IPX ruled the roost, very popularly, for a little while. How long did it take to die? Why did it die? What were the triggers that pushed it over the cliff? I think there's a lot to be learned from that piece of recent history. Specifically, as a demonstration of how a "most popular" protocol can find itself ejected from the arena in the blink of an eye. I knew several people who built their career path on the assumptions of IPX. Ouch. There are reasonable arguments that IPX was better than IPv4 but IPv4 had all the mind share as the standard and IPX was the proprietary alternative. So everyone switched but more than a few were not happy afterward when the noticed the features they had lost. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com > --lyndon > From outsider at scarynet.org Sat Jun 27 17:58:24 2015 From: outsider at scarynet.org (Alexander Maassen) Date: Sat, 27 Jun 2015 19:58:24 +0200 Subject: =?US-ASCII?Q?Re:_How_long_will_it_take_to_completely_?= =?US-ASCII?Q?get_rid_of_IPv4_or_will_it=0D__happen_at_all=3F?= Message-ID: Before that will happen. Isp's will first try cgnat and the alikes. They rather spend money on hardware supporting that then make the networks dualstack. Why? you may ask. Simple. Most customer service centers have ppl with less then basic skills. Explaining how ipv4 even looks like took them long enough. Abuse ticket systems and logparsers are probably also v4 based. And the one who wrote them, probably got fired and replaced by a younger/cheaper guy who just got out of school with no real field experience. When will the change happen then you might ask. Very simple. If the largest destinations like fb/twitter and others start to drop v4. So what we really would need is not an ipv6 day, but, you might have guessed it, an ipv6 ONLY day.? On such a day, a hell of a lot isps will have their support queue overfilled with people asking why they cannot visit their favourite sites. And all the isp can say is: our network infrastructure is too old. -------- Oorspronkelijk bericht -------- Van: Bob Evans Datum: Aan: Rafael Possamai Cc: North American Network Operators' Group Onderwerp: How long will it take to completely get rid of IPv4 or will it happen at all? Our fundamental issue is that an IPv4 address has no real value as networks still give them away, it's pennies in your pocket. Everything of use needs to have a cost to motivate for change. Establishing that now won't create change it will first create greater conservation. There will be a cost that will be reached before change takes place on a scale that matters. Networks set the false perception and customer expectation that address space is free and readily available. Networks with plenty, still land many customers today by handing over a class C to customer with less than 10 servers and 5 people in an office. We have a greater supply for packets to travel than we do for addresses required to move packets. Do you know how many packets a single IP address can generate or utilize, if it was attached too "The World's Fastest Internet" in someplace like Canadaland or Sweden on init7's Fiber7 ?? No matter how large the pipe the answer is always, "all of it". It's address space we should now place a price upon. Unlike, My Space's disappearance when Facebook arrived there is no quick jump to IPv6. There is no coordinated effort required that involves millions of people to change browser window content. But to answer your question... Everything that is handed over for free is perceived as having no value. Therefore, IPv4 has to cost much more than the cost to change to IPv6 today. While the IPv6 addresses are free, it is expensive to change. Businesses spend lots of money on a free lunches. It's going to take at least the price of one good lunch per IP address per month to create the consideration for change. That's about $30 for 2 people in California. Offering a /48 of free IPv6 space to everyone on the planet didn't make it happen. There is no financial incentive to move to IPv6. In fact there is more reason "not to change" than "to change". The new gear cost $$$ (lots of it didn't work well and required exploration to learn that),? IT people need hours to implement (schedules are full of day-to-day issues), networks keep growing with offerings that drop Internet costs and save everyone money, business as usual is productive on IPv4 (business doesn't have time for distraction), many of us get distracted by something more immediate and interesting than buying a new wi-fi router for the home. What will come first ? A) the earths future core rotation changes altering the ionosphere in such a way that we are all exposed to continuous x-rays that shorten our lifespan ???????????????? OR B) the last IPv4 computer running will be reconfigured to IPv6 Thank You Bob Evans CTO > Randy, > > How long do you think it will take to completely get rid of IPv4? Or is it > even going to happen at all? > > On Sat, Jun 27, 2015 at 4:57 AM, Randy Bush wrote: > >> the rirs have run out of their free source of short ints to rent to us. >> i am sure everyone will move to ipv6 in a week.? news at eleven. >> >> randy >> > From alh-ietf at tndh.net Sat Jun 27 18:02:05 2015 From: alh-ietf at tndh.net (Tony Hain) Date: Sat, 27 Jun 2015 11:02:05 -0700 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: <07dc01d0b103$607c1ff0$21745fd0$@tndh.net> Bob Evans wrote: > > Our fundamental issue is that an IPv4 address has no real value as networks > still give them away, it's pennies in your pocket. Everything of use needs to > have a cost to motivate for change. Establishing that now won't create > change it will first create greater conservation. There will be a cost that will > be reached before change takes place on a scale that matters. > > Networks set the false perception and customer expectation that address > space is free and readily available. Networks with plenty, still land many > customers today by handing over a class C to customer with less than 10 > servers and 5 people in an office. > > We have a greater supply for packets to travel than we do for addresses > required to move packets. Do you know how many packets a single IP > address can generate or utilize, if it was attached too "The World's Fastest > Internet" in someplace like Canadaland or Sweden on init7's Fiber7 ? No > matter how large the pipe the answer is always, "all of it". It's address space > we should now place a price upon. Unlike, My Space's disappearance when > Facebook arrived there is no quick jump to IPv6. There is no coordinated > effort required that involves millions of people to change browser window > content. > > But to answer your question... > > Everything that is handed over for free is perceived as having no value. > Therefore, IPv4 has to cost much more than the cost to change to IPv6 today. > While the IPv6 addresses are free, it is expensive to change. > Businesses spend lots of money on a free lunches. It's going to take at least > the price of one good lunch per IP address per month to create the > consideration for change. That's about $30 for 2 people in California. > Offering a /48 of free IPv6 space to everyone on the planet didn't make it > happen. > > There is no financial incentive to move to IPv6. In fact there is more reason > "not to change" than "to change". The new gear cost $$$ (lots of it didn't > work well and required exploration to learn that), IT people need hours to > implement (schedules are full of day-to-day issues), networks keep growing > with offerings that drop Internet costs and save everyone money, business > as usual is productive on IPv4 (business doesn't have time for distraction), > many of us get distracted by something more immediate and interesting > than buying a new wi-fi router for the home. > > What will come first ? > A) the earths future core rotation changes altering the ionosphere in such a > way that we are all exposed to continuous x-rays that shorten our lifespan > OR > B) the last IPv4 computer running will be reconfigured to IPv6 > > Thank You > Bob Evans > CTO > Rewind the clock 20 years s/ipv4/sna/ s/ipv6/ipv4/ and/or rewind the clock 15 years s/ipv4/tdm/ s/ipv6/voip/ and your rant is exactly what was coming out of enterprises and carriers at those times. The only thing more constant than change in this industry is the intransigence of the luddites that believe they are the masters of the universe and will refuse to move with the tide. Sometimes (like in the case of IPv4) they can build a strong seawall that will hold the tide back for a decade, but rest assured that the tide always wins. I have looked and can't find the references, but I distinctly remember Businessweek or Fortune magazine covers in the late 90's with phrases to the effect of 'SNA Forever' or 'SNA is for real business/IPv4 is an experimental toy'. I have also been in meetings with carriers and been told "No end customer will ever fill a DS-3. Those are inter-city exchange circuits, and there isn't enough data in the world to fill one", having just told them we were connecting CERN to Cal-tech. To the point of the original question, look to history for some indication. While people in the late 90's were busy trying to figure out how to translate web pages to SNA terminals, within ~ 5 years, the noise was gone. I am sure you will still find pockets of legacy SNA in use, but nobody cares. Then look at the education system. Once you retire-out the tenured dinosaurs that are still teaching classfull IPv4, followed by a generation of upstarts that never learned about those tiny 32-bit locators which could only possibly identify <1% of the connected devices they are aware of, it will die off. Until then, it will move to the backwaters where nobody cares. When you ignore the costs of maintaining an ever crumbling foundation, and just look at the cost of replacement, then you can mentally justify staying in the past. If you are honest about the TCO, and include both the wizardry created by the network masters and the difficult to quantify increased cost of all the software that has to work around that, then a cost based analysis is valid. Unfortunately there has been enough myopic focus on network-specific costs on this list that a decade has been lost that could have been used to update software and reduce the future timeframe that IPv4 needs to be supported. While many on this list have bought into the hatred of the automated tunneling in Windows, that was put there specifically to provide a working API for the application developers. Breaking the stalemate between lack-of-apps that might use a network and lack-of-network on which to develop those apps, was possible by having the API mask out the lack of function in the underlying network. Unfortunately rather than enhance that capability, the angry mob took up arms and blocked it. The only thing wrong with 6to4 was the one-liner that said you could only announce a /12 into the IPv6 DFZ. If everyone had ignored that and set up local relays announcing the appropriate /20-48 matching their IPv4 prefix into the DFZ, and the IPv4-anycast only to their own customers, you would have had the functionality of 6rd in deployed code at least 5 years earlier. The fact that it was vilified rather than adapted speaks volumes about the unwillingness of the community to face the inevitable. There was a recent comment on the list that the IETF pushed dual-stack out the door and patted themselves on the back, which is absolutely untrue. I was the one that pushed the dual-stack mantra, and was put in the position of WG chair because I was standing in the back of the room during the BOF for the transition WG mumbling to myself 'been there, done that, doesn't scale' at the proposals being tossed out by the research community. Having just transitioned a collection of protocols to IPv4, the thing that worked best at a SYSTEM level was to deploy the new protocol alongside the old one, and let each app move in its own timeframe. Yes that was duplicate effort at the network level, but there are many more parts to the system, and from my experience those cost an order of magnitude more. While dual-stack does require IPv4, it was over 15 years ago when that statement was made, while it was still possible. In any case, the point of dual-stack was not to solve all problems, just to set a baseline of the long term network that apps could move to. For the cases where it was not economical to move the app, wizardry was appropriate, and the WG was defining additional corner-case tools. In another unfortunate case, one of those escaped over the objection of the chairs and was forced onto the standards track because several AD's insisted we needed a standard translator. That set back the process another 3-5 years, but the bigger failing was that the responsible AD (on this list) decided that 'we had enough tools already, we needed deployment', and shut the WG down. I really don't know what additional tools might have developed or been identified, and I really don't care about the WG closing, but this was not a case of one-size-fits-all and pat yourself on the back. This has been a long-winded way of saying, IPv4 will be replaced EVENTUALLY, and as Randy said, 'news at 11'. Tony > > > > > Randy, > > > > How long do you think it will take to completely get rid of IPv4? Or > > is it even going to happen at all? > > > > On Sat, Jun 27, 2015 at 4:57 AM, Randy Bush wrote: > > > >> the rirs have run out of their free source of short ints to rent to us. > >> i am sure everyone will move to ipv6 in a week. news at eleven. > >> > >> randy > >> > > From blair.trosper at gmail.com Sat Jun 27 18:27:15 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Sat, 27 Jun 2015 13:27:15 -0500 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: <07dc01d0b103$607c1ff0$21745fd0$@tndh.net> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <07dc01d0b103$607c1ff0$21745fd0$@tndh.net> Message-ID: I agree with Tony, but at the same time, I also find myself having a hard time rendering an opinion as to timeframe. It'll probably be surprising, but as someone who joined the Internet in the 1990s when IRC was still the pinnacle of what we could do, it's hard to imagine v4 ever going away completely. Maybe a hold- over for legacy services a bit like AM or shortwave radio? Uncertain, but an intriguing thought experiment. On Sat, Jun 27, 2015 at 1:02 PM, Tony Hain wrote: > Bob Evans wrote: > > > > Our fundamental issue is that an IPv4 address has no real value as > networks > > still give them away, it's pennies in your pocket. Everything of use > needs > to > > have a cost to motivate for change. Establishing that now won't create > > change it will first create greater conservation. There will be a cost > that will > > be reached before change takes place on a scale that matters. > > > > Networks set the false perception and customer expectation that address > > space is free and readily available. Networks with plenty, still land > many > > customers today by handing over a class C to customer with less than 10 > > servers and 5 people in an office. > > > > We have a greater supply for packets to travel than we do for addresses > > required to move packets. Do you know how many packets a single IP > > address can generate or utilize, if it was attached too "The World's > Fastest > > Internet" in someplace like Canadaland or Sweden on init7's Fiber7 ? No > > matter how large the pipe the answer is always, "all of it". It's address > space > > we should now place a price upon. Unlike, My Space's disappearance when > > Facebook arrived there is no quick jump to IPv6. There is no coordinated > > effort required that involves millions of people to change browser window > > content. > > > > But to answer your question... > > > > Everything that is handed over for free is perceived as having no value. > > Therefore, IPv4 has to cost much more than the cost to change to IPv6 > today. > > While the IPv6 addresses are free, it is expensive to change. > > Businesses spend lots of money on a free lunches. It's going to take at > least > > the price of one good lunch per IP address per month to create the > > consideration for change. That's about $30 for 2 people in California. > > Offering a /48 of free IPv6 space to everyone on the planet didn't make > it > > happen. > > > > There is no financial incentive to move to IPv6. In fact there is more > reason > > "not to change" than "to change". The new gear cost $$$ (lots of it > didn't > > work well and required exploration to learn that), IT people need hours > to > > implement (schedules are full of day-to-day issues), networks keep > growing > > with offerings that drop Internet costs and save everyone money, business > > as usual is productive on IPv4 (business doesn't have time for > distraction), > > many of us get distracted by something more immediate and interesting > > than buying a new wi-fi router for the home. > > > > What will come first ? > > A) the earths future core rotation changes altering the ionosphere in > such > a > > way that we are all exposed to continuous x-rays that shorten our > lifespan > > OR > > B) the last IPv4 computer running will be reconfigured to IPv6 > > > > Thank You > > Bob Evans > > CTO > > > > Rewind the clock 20 years s/ipv4/sna/ s/ipv6/ipv4/ and/or > rewind the clock 15 years s/ipv4/tdm/ s/ipv6/voip/ > and your rant is exactly what was coming out of enterprises and carriers at > those times. The only thing more constant than change in this industry is > the intransigence of the luddites that believe they are the masters of the > universe and will refuse to move with the tide. Sometimes (like in the case > of IPv4) they can build a strong seawall that will hold the tide back for a > decade, but rest assured that the tide always wins. > > I have looked and can't find the references, but I distinctly remember > Businessweek or Fortune magazine covers in the late 90's with phrases to > the > effect of 'SNA Forever' or 'SNA is for real business/IPv4 is an > experimental > toy'. I have also been in meetings with carriers and been told "No end > customer will ever fill a DS-3. Those are inter-city exchange circuits, and > there isn't enough data in the world to fill one", having just told them we > were connecting CERN to Cal-tech. > > To the point of the original question, look to history for some indication. > While people in the late 90's were busy trying to figure out how to > translate web pages to SNA terminals, within ~ 5 years, the noise was gone. > I am sure you will still find pockets of legacy SNA in use, but nobody > cares. Then look at the education system. Once you retire-out the tenured > dinosaurs that are still teaching classfull IPv4, followed by a generation > of upstarts that never learned about those tiny 32-bit locators which could > only possibly identify <1% of the connected devices they are aware of, it > will die off. Until then, it will move to the backwaters where nobody > cares. > > When you ignore the costs of maintaining an ever crumbling foundation, and > just look at the cost of replacement, then you can mentally justify staying > in the past. If you are honest about the TCO, and include both the wizardry > created by the network masters and the difficult to quantify increased cost > of all the software that has to work around that, then a cost based > analysis > is valid. Unfortunately there has been enough myopic focus on > network-specific costs on this list that a decade has been lost that could > have been used to update software and reduce the future timeframe that > IPv4 > needs to be supported. > > While many on this list have bought into the hatred of the automated > tunneling in Windows, that was put there specifically to provide a working > API for the application developers. Breaking the stalemate between > lack-of-apps that might use a network and lack-of-network on which to > develop those apps, was possible by having the API mask out the lack of > function in the underlying network. Unfortunately rather than enhance that > capability, the angry mob took up arms and blocked it. The only thing wrong > with 6to4 was the one-liner that said you could only announce a /12 into > the > IPv6 DFZ. If everyone had ignored that and set up local relays announcing > the appropriate /20-48 matching their IPv4 prefix into the DFZ, and the > IPv4-anycast only to their own customers, you would have had the > functionality of 6rd in deployed code at least 5 years earlier. The fact > that it was vilified rather than adapted speaks volumes about the > unwillingness of the community to face the inevitable. > > There was a recent comment on the list that the IETF pushed dual-stack out > the door and patted themselves on the back, which is absolutely untrue. I > was the one that pushed the dual-stack mantra, and was put in the position > of WG chair because I was standing in the back of the room during the BOF > for the transition WG mumbling to myself 'been there, done that, doesn't > scale' at the proposals being tossed out by the research community. Having > just transitioned a collection of protocols to IPv4, the thing that worked > best at a SYSTEM level was to deploy the new protocol alongside the old > one, > and let each app move in its own timeframe. Yes that was duplicate effort > at > the network level, but there are many more parts to the system, and from my > experience those cost an order of magnitude more. While dual-stack does > require IPv4, it was over 15 years ago when that statement was made, while > it was still possible. In any case, the point of dual-stack was not to > solve > all problems, just to set a baseline of the long term network that apps > could move to. For the cases where it was not economical to move the app, > wizardry was appropriate, and the WG was defining additional corner-case > tools. In another unfortunate case, one of those escaped over the objection > of the chairs and was forced onto the standards track because several AD's > insisted we needed a standard translator. That set back the process another > 3-5 years, but the bigger failing was that the responsible AD (on this > list) > decided that 'we had enough tools already, we needed deployment', and shut > the WG down. I really don't know what additional tools might have developed > or been identified, and I really don't care about the WG closing, but this > was not a case of one-size-fits-all and pat yourself on the back. > > This has been a long-winded way of saying, IPv4 will be replaced > EVENTUALLY, > and as Randy said, 'news at 11'. > > Tony > > > > > > > > > > > Randy, > > > > > > How long do you think it will take to completely get rid of IPv4? Or > > > is it even going to happen at all? > > > > > > On Sat, Jun 27, 2015 at 4:57 AM, Randy Bush wrote: > > > > > >> the rirs have run out of their free source of short ints to rent to > us. > > >> i am sure everyone will move to ipv6 in a week. news at eleven. > > >> > > >> randy > > >> > > > > > > From frnkblk at iname.com Sat Jun 27 18:45:54 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Sat, 27 Jun 2015 13:45:54 -0500 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: <001501d0b109$84989ac0$8dc9d040$@iname.com> What's the ratio of mobile (cellular) endpoints to non-mobile devices? And we know that mobile continues to grow faster than fixed endpoints -- at what point will the scales naturally tip to IPv6? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mikael Abrahamsson Sent: Saturday, June 27, 2015 9:54 AM To: Rafael Possamai Cc: North American Network Operators' Group Subject: Re: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 On Sat, 27 Jun 2015, Rafael Possamai wrote: > How long do you think it will take to completely get rid of IPv4? Or is > it even going to happen at all? I believe somewhere around 2018-2025 a lot of ISPs, hosting providers etc will start to treat IPv4 as a second rate citizen and for the people still single-stacked to IPv4 by then, the Internet experience is going to become so bad that they'll beg to get IPv6 and the ones not providing it will feel severe business impact of not doing IPv6. Mobile providers will be the first huge ones to go IPv6 only to the devices, which will mean that from your mobile device, IPv4 will most likely work worse than IPv6. Then it's downhill from there. -- Mikael Abrahamsson email: swmike at swm.pp.se From bmanning at karoshi.com Sat Jun 27 18:48:06 2015 From: bmanning at karoshi.com (manning) Date: Sat, 27 Jun 2015 11:48:06 -0700 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <558ED142.3010503@init7.net> Message-ID: Quite a few folks actually. (the 802.5 & 802.4 specs)?. This is kind of like asking when we will stop using ethernet framing (ethernet was designed for a 3Mbps transmission rate) yet we are deploying 100Gbps networks. Still stuck on that 1500byte limitation. When can we get rid of that? manning bmanning at karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 27June2015Saturday, at 9:49, Bacon Zombie wrote: > Is anybody still using IPX or TokenRing? > > I've heard that TokenRing is over 9000 times better for iSCSI since you are > guaranteed that the packets will not get collisions. > On 27 Jun 2015 18:39, "Fredy Kuenzler" wrote: > >> Am 27.06.2015 um 16:38 schrieb Bob Evans: >>> We have a greater supply for packets to travel than we do for >>> addresses required to move packets. Do you know how many packets a >>> single IP address can generate or utilize, if it was attached too >>> "The World's Fastest Internet" in someplace like Canadaland or Sweden >>> on init7's Fiber7 ? >> >> Thanks for mentioning Fiber7, which is actually available in >> Switzerland, not Sweden. And every Fiber7 customer gets a /48, too. >> >> -- >> Fredy Kuenzler >> >> --------------------- >> Fiber7. No Limits. >> https://www.fiber7.ch >> --------------------- >> >> Init7 (Switzerland) Ltd. >> AS13030 >> St.-Georgen-Strasse 70 >> CH-8400 Winterthur >> Skype: flyingpotato >> Phone: +41 44 315 4400 >> Fax: +41 44 315 4401 >> Twitter: @init7 / @kuenzler >> http://www.init7.net/ >> >> From hank at efes.iucc.ac.il Sat Jun 27 18:56:07 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 27 Jun 2015 21:56:07 +0300 Subject: =?iso-8859-1?Q?Re:_World's_Fastest_Inte_rnet=99_in___?= Canadaland In-Reply-To: <1435342198_76812@surgemail.mnsi.net> References: Message-ID: <5.1.1.6.2.20150627215249.050a8830@efes.iucc.ac.il> At 14:09 26/06/2015 -0400, Clayton Zekelman wrote: Singapore averages 130Mb/sec and has ISPs that average 500Mb/sec: http://www.netindex.com/download/2,17/Singapore/ Rogers currently averages over 60Mb/sec: http://www.netindex.com/download/2,7/Canada/ -Hank >They needed to do this. Rogers is already offering higher speeds. > >At 02:04 PM 26/06/2015, Hank Disuko wrote: >>Bell Canada is apparently gearing up to provide the good people of >>Toronto with the World's Fastest Internet?. >>http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html >> > >--- > >Clayton Zekelman >Managed Network Systems Inc. (MNSi) >3363 Tecumseh Rd. E >Windsor, Ontario >N8W 1H4 > >tel. 519-985-8410 >fax. 519-985-8409 From Valdis.Kletnieks at vt.edu Sat Jun 27 21:54:05 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 27 Jun 2015 17:54:05 -0400 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: Your message of "Sat, 27 Jun 2015 07:38:43 -0700." References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: <92835.1435442045@turing-police.cc.vt.edu> On Sat, 27 Jun 2015 07:38:43 -0700, "Bob Evans" said: > What will come first ? > A) the earths future core rotation changes altering the ionosphere in such > a way that we are all exposed to continuous x-rays that shorten our > lifespan > OR > B) the last IPv4 computer running will be reconfigured to IPv6 Data point: I just ran a tcpdump looking for NTP packets going to 128.173.14.71. In 90 minutes, I got hits from 330 unique IP addresses, including some that were chatty enough to indicate there were dozens of hosts behind a NAT. The biggest offenders: % tcpdump -n -r ~/ntp.dump | cut -f3 -d' ' | cut -f1-4 -d'.' | sort | uniq -c | sort -nr | head -30 reading from file /home/valdis/ntp.dump, link-type EN10MB (Ethernet) 5507 200.195.163.227 3797 74.254.73.226 2989 200.19.200.174 1718 50.129.20.208 1160 200.169.44.45 1119 200.206.35.74 624 201.64.113.34 516 186.215.65.33 352 201.48.247.23 352 187.72.210.97 350 200.171.23.66 281 177.96.208.28 212 187.28.183.82 206 189.22.174.82 200 200.195.127.118 195 187.72.239.145 180 68.213.39.6 180 198.234.129.210 176 201.93.57.129 176 201.90.121.244 176 201.82.103.134 176 201.67.192.74 176 201.59.167.213 176 201.55.163.226 176 201.55.123.98 176 201.48.80.252 176 201.30.191.178 176 201.26.253.187 176 200.250.99.132 176 200.247.208.84 Note that 128.173.14.71 was an IBM RS/6000 taken out of service in June 1999, and we've not re-used the IP address since. So basically, anybody who has tried to get NTP from that address anytime this century has come up empty. The other scary number? % tcpdump -n -r ~/ntp.dump | grep NTP | cut -f6 -d' ' | sort | uniq -c reading from file /home/valdis/ntp.dump, link-type EN10MB (Ethernet) 413 NTPv1, 205 NTPv2, 34900 NTPv3, 2155 NTPv4, I'm not sure which scares me more - that there are boxes on the net *still* running v1 or v2, or boxes that have upgraded to v4 and are blindly using the same ntp.conf without bothering to sanity check if a clock is still usable.... -------------- 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 Sat Jun 27 22:53:22 2015 From: jra at baylink.com (Jay Ashworth) Date: Sat, 27 Jun 2015 18:53:22 -0400 Subject: ICYMI: SSLv3 is now formally dead. MUST NOT. Message-ID: http://www.rfc-editor.org/rfc/rfc7568.txt -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From tqr2813d376cjozqap1l at tutanota.com Sat Jun 27 22:57:44 2015 From: tqr2813d376cjozqap1l at tutanota.com (tqr2813d376cjozqap1l at tutanota.com) Date: Sat, 27 Jun 2015 22:57:44 +0000 (UTC) Subject: ICYMI: SSLv3 is now formally dead. MUST NOT. In-Reply-To: References: Message-ID: 27. Jun 2015 22:53 by jra at baylink.com: > http://www.rfc-editor.org/rfc/rfc7568.txt > Finally. Now for the many years of websites supporting it anyways "because windows xp". From list at satchell.net Sat Jun 27 22:58:43 2015 From: list at satchell.net (Stephen Satchell) Date: Sat, 27 Jun 2015 15:58:43 -0700 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <558ED142.3010503@init7.net> Message-ID: <558F2AA3.1060608@satchell.net> On 06/27/2015 11:48 AM, manning wrote: > This is kind of like asking when we will stop using ethernet framing > (ethernet was designed for a 3Mbps transmission rate) yet we are > deploying 100Gbps networks. Still stuck on that 1500byte limitation. > When can we get rid of that? Speed has nothing to do with frame size. The 1500 byte limitation is more a function of the CRC algorithm. (Oh, the initial frame size was selected for 3-mbit Ethernet so that collision mitigation was reasonable.) Think about jumbo frames (9000 bytes) and their robust error detection. Research is being done in even larger frames, because the rule is that as your transmission rate increases, you should increase the frame size and use a FRC algorithm that detects all one-bit errors and most two-bit errors, at least. From Kevin.Irwin at cinbell.com Sat Jun 27 23:36:45 2015 From: Kevin.Irwin at cinbell.com (Irwin, Kevin) Date: Sat, 27 Jun 2015 23:36:45 +0000 Subject: =?Windows-1252?Q?Re:_World's_Fastest_Internet=99_in_Canadaland?= In-Reply-To: References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local>, Message-ID: <9B8DFFD5-8C39-4572-BB4C-5BA1EF7BACDB@cinbell.com> Based on our 1Gbps residential customers usage, I believe you just sit at home and run speedtest all day. Sent from my iPhone > On Jun 26, 2015, at 2:41 PM, Rafael Possamai wrote: > > How does one fully utilize a gigabit link for home use? For a single person > it is overkill. Similar to the concept of price elasticity in economics, > going from 50mbps to 1gbps doesn't necessarily increase your average > transfer rate, at least I don't think it would for me. Anyone care to > comment? Just really curious, as to me it's more of a marketing push than > anything else, even though gigabit to the home sounds really cool. > > > >> On Fri, Jun 26, 2015 at 1:13 PM, Eric Dugas wrote: >> >> Nice try Bell.. So-Net did it two years ago, 2Gbps FTTH in Japan. >> >> Article: http://bgr.com/2013/06/13/so-net-nuro-2gbps-fiber-service/ >> >> If you read Japanese: http://www.nuro.jp/hikari/ >> >> Eric >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hank Disuko >> Sent: June 26, 2015 2:04 PM >> To: NANOG >> Subject: World's Fastest Internet? in Canadaland >> >> Bell Canada is apparently gearing up to provide the good people of Toronto >> with the World's Fastest Internet?. >> >> http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html >> >> >> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and destroy any copies of this document. From randy at psg.com Sun Jun 28 00:13:51 2015 From: randy at psg.com (Randy Bush) Date: Sun, 28 Jun 2015 09:13:51 +0900 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <558ED142.3010503@init7.net> Message-ID: > Is anybody still using IPX or TokenRing? both great wide-area protocols. oh, wait. randy From chuckchurch at gmail.com Sun Jun 28 01:41:26 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Sat, 27 Jun 2015 21:41:26 -0400 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <558ED142.3010503@init7.net> Message-ID: <006601d0b143$942b5f60$bc821e20$@gmail.com> IPX with EIGRP or NLSP wasn't bad over the WAN. Can't help you with TokenRing though. Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Bush Sent: Saturday, June 27, 2015 8:14 PM To: Bacon Zombie Cc: nanog at nanog.org Subject: Re: How long will it take to completely get rid of IPv4 or will it happen at all? > Is anybody still using IPX or TokenRing? both great wide-area protocols. oh, wait. randy From tony at wicks.co.nz Sun Jun 28 01:49:34 2015 From: tony at wicks.co.nz (Tony Wicks) Date: Sun, 28 Jun 2015 13:49:34 +1200 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: <006601d0b143$942b5f60$bc821e20$@gmail.com> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <558ED142.3010503@init7.net> <006601d0b143$942b5f60$bc821e20$@gmail.com> Message-ID: <001f01d0b144$b23e1550$16ba3ff0$@wicks.co.nz> I see your IPX and raise you Appletalk. Appletalk was king of fill up the WAN (64k or so in those days) with just broadcast traffic. Oh, are playing what sucked more than IPv4 ? ;Subject: RE: How long will it take to completely get rid of IPv4 or will it happen at all? ;IPX with EIGRP or NLSP wasn't bad over the WAN. Can't help you with TokenRing though. From larrysheldon at cox.net Sun Jun 28 02:16:57 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Sat, 27 Jun 2015 21:16:57 -0500 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <558ED142.3010503@init7.net> Message-ID: <558F5919.4000305@cox.net> On 6/27/2015 19:13, Randy Bush wrote: >> Is anybody still using IPX or TokenRing? > > both great wide-area protocols. oh, wait. The university that fired me for being too old some years ago had three Token Rings--one of them Thicknet. And scads and wads of IPX-speaking machines. That HAS been 10 years ago, so maybe..... -- sed quis custodiet ipsos custodes? (Juvenal) From rafael at gav.ufsc.br Sun Jun 28 02:35:29 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Sat, 27 Jun 2015 21:35:29 -0500 Subject: =?UTF-8?Q?Re=3A_World=27s_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: <9B8DFFD5-8C39-4572-BB4C-5BA1EF7BACDB@cinbell.com> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> <9B8DFFD5-8C39-4572-BB4C-5BA1EF7BACDB@cinbell.com> Message-ID: Good for you. On Sat, Jun 27, 2015 at 6:36 PM, Irwin, Kevin wrote: > Based on our 1Gbps residential customers usage, I believe you just sit at > home and run speedtest all day. > > Sent from my iPhone > > > On Jun 26, 2015, at 2:41 PM, Rafael Possamai wrote: > > > > How does one fully utilize a gigabit link for home use? For a single > person > > it is overkill. Similar to the concept of price elasticity in economics, > > going from 50mbps to 1gbps doesn't necessarily increase your average > > transfer rate, at least I don't think it would for me. Anyone care to > > comment? Just really curious, as to me it's more of a marketing push than > > anything else, even though gigabit to the home sounds really cool. > > > > > > > >> On Fri, Jun 26, 2015 at 1:13 PM, Eric Dugas > wrote: > >> > >> Nice try Bell.. So-Net did it two years ago, 2Gbps FTTH in Japan. > >> > >> Article: http://bgr.com/2013/06/13/so-net-nuro-2gbps-fiber-service/ > >> > >> If you read Japanese: http://www.nuro.jp/hikari/ > >> > >> Eric > >> > >> -----Original Message----- > >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Hank Disuko > >> Sent: June 26, 2015 2:04 PM > >> To: NANOG > >> Subject: World's Fastest Internet? in Canadaland > >> > >> Bell Canada is apparently gearing up to provide the good people of > Toronto > >> with the World's Fastest Internet?. > >> > >> > http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html > >> > >> > >> > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you receive > this in error, please contact the sender and destroy any copies of this > document. > From bob at FiberInternetCenter.com Sun Jun 28 02:48:18 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Sat, 27 Jun 2015 19:48:18 -0700 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: References: Message-ID: <2d8460c7271792922523cd08ad5b404d.squirrel@66.201.44.180> > When will the change happen then you might ask. Very simple. If the > largest destinations like fb/twitter and others start to drop v4. Agreed, IPv4 will be here a long time, because, not one company will risk financial loses and stock devaluation over address space. The day that a large company flips to IPv6 only in an IPv4 world will be the day to short as many shares of that stock as possible. This creates the big market for IPv4. Costs price per IP address must get beyond the price of a good lunch once per month. Because, that's an amount that businesses understand and begin to pay attention. IPv4 address space is now a profit center and will cost more to the end user than transit and network costs... Or... how will IPv6 catch on in any other way ? From cb.list6 at gmail.com Sun Jun 28 03:32:06 2015 From: cb.list6 at gmail.com (Ca By) Date: Sat, 27 Jun 2015 20:32:06 -0700 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: <2d8460c7271792922523cd08ad5b404d.squirrel@66.201.44.180> References: <2d8460c7271792922523cd08ad5b404d.squirrel@66.201.44.180> Message-ID: On Saturday, June 27, 2015, Bob Evans wrote: > > > > When will the change happen then you might ask. Very simple. If the > > largest destinations like fb/twitter and others start to drop v4. > > Agreed, IPv4 will be here a long time, because, not one company will risk > financial loses and stock devaluation over address space. The day that a > large company flips to IPv6 only in an IPv4 world will be the day to short > as many shares of that stock as possible. > > T-Mobile US large enough ? http://www.internetsociety.org/deploy360/resources/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/ I hear they have more ipv6-only subscribers than ipv4 CB This creates the big market for IPv4. Costs price per IP address must get > beyond the price of a good lunch once per month. Because, that's an amount > that businesses understand and begin to pay attention. IPv4 address space > is now a profit center and will cost more to the end user than transit and > network costs... Or... how will IPv6 catch on in any other way ? > > > > From swmike at swm.pp.se Sun Jun 28 03:40:28 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 28 Jun 2015 05:40:28 +0200 (CEST) Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: References: <2d8460c7271792922523cd08ad5b404d.squirrel@66.201.44.180> Message-ID: On Sat, 27 Jun 2015, Ca By wrote: > T-Mobile US large enough ? > > http://www.internetsociety.org/deploy360/resources/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/ > > I hear they have more ipv6-only subscribers than ipv4 By "IPv6 only" I believe he meant "stop offering IPv4 reachability to customers". Since you use 464XLAT and NAT64, you still offer IPv4 access even though it's done over IPv6 to the customer. -- Mikael Abrahamsson email: swmike at swm.pp.se From marka at isc.org Sun Jun 28 03:25:16 2015 From: marka at isc.org (Mark Andrews) Date: Sun, 28 Jun 2015 13:25:16 +1000 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: <2d8460c7271792922523cd08ad5b404d.squirrel@66.201.44.180> References: <2d8460c7271792922523cd08ad5b404d.squirrel@66.201.44.180> Message-ID: <57175189-BF78-4041-80CB-3F39DA14D925@isc.org> This is like the switch to using MX only for email rather than MX. and A for mon MX aware systems. It will just happen and no one will notice. Mark On 28/06/2015, at 12:48, "Bob Evans" wrote: > > >> When will the change happen then you might ask. Very simple. If the >> largest destinations like fb/twitter and others start to drop v4. > > Agreed, IPv4 will be here a long time, because, not one company will risk > financial loses and stock devaluation over address space. The day that a > large company flips to IPv6 only in an IPv4 world will be the day to short > as many shares of that stock as possible. > > This creates the big market for IPv4. Costs price per IP address must get > beyond the price of a good lunch once per month. Because, that's an amount > that businesses understand and begin to pay attention. IPv4 address space > is now a profit center and will cost more to the end user than transit and > network costs... Or... how will IPv6 catch on in any other way ? > > > From eugen at imacandi.net Sun Jun 28 12:58:19 2015 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sun, 28 Jun 2015 15:58:19 +0300 Subject: =?UTF-8?Q?Re=3A_World=27s_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: <9B8DFFD5-8C39-4572-BB4C-5BA1EF7BACDB@cinbell.com> References: <39584b8df0bf492b8ca1c0385557f645@ZF-EXCH2013-02.Pre2Post.local> <9B8DFFD5-8C39-4572-BB4C-5BA1EF7BACDB@cinbell.com> Message-ID: > > > On Jun 26, 2015, at 2:41 PM, Rafael Possamai wrote: > > > > How does one fully utilize a gigabit link for home use? For a single > person > > it is overkill. Similar to the concept of price elasticity in economics, > > going from 50mbps to 1gbps doesn't necessarily increase your average > > transfer rate, at least I don't think it would for me. Anyone care to > > comment? Just really curious, as to me it's more of a marketing push than > > anything else, even though gigabit to the home sounds really cool. > You don't run it hot all day long, it's just that you don't wait forever for things to download when you need something from the Internet. From mel at beckman.org Sun Jun 28 13:17:15 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 28 Jun 2015 13:17:15 +0000 Subject: OK, Google. Time to dial back the AI hype. Message-ID: Google has always played fast and loose with its AI claims, but today t has gone too far. In a WSJ story, Google is misleading people into thinking it has achieved emotion, if not outright consciousness, in its AI programming: http://slashdot.org/submission/4569873/wsj-jumps-the-shark-with-ai-gets-testy-story Google claims one of its computer programs using a database of movie scripts to answer questions supposedly "lashed out" at a human researcher who was repeatedly asking it to explain morality. Don't computer scientists have a responsibility to deal forthrightly with the public on the real state of research in such fields as AI? When an Internet provider like Google makes such outlandish claims, one has to wonder what the real agenda is. -mel beckman From tknchris at gmail.com Sun Jun 28 14:57:28 2015 From: tknchris at gmail.com (chris) Date: Sun, 28 Jun 2015 10:57:28 -0400 Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: I cant say much about other incumbents but i have been in alot of vz co's in nj/nyc and Its very rare to see any humans in a CO anymore even in ones in really dense metro areas On Jun 26, 2015 10:40 PM, "Christopher Morrow" wrote: > On Fri, Jun 26, 2015 at 8:32 PM, John Musbach > wrote: > > On Thu, Jun 25, 2015 at 5:32 PM, Christopher Morrow > > wrote: > >> On Wed, Jun 24, 2015 at 2:46 PM, John Musbach > wrote: > >>> Hello, > >>> > >>> I'm a techie that recently moved to South Jersey for a tech job. To my > >>> astonishment, I discovered that there appears to be a Verizon > >>> datacenter near my house that has colocation: > >> > >> how / why did you think this has colocation? > > > > Look at the second picture, the sign on the door more specifically. :) > > oriiginal view of the door sign was not readable... had to do some > work to see 'co locators entrance'. Bet this means 'clec entrance' > (they probably forgot to include the hours of operation: 9-4, lunch > 11-3) > From owen at delong.com Sun Jun 28 15:02:52 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 28 Jun 2015 08:02:52 -0700 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <558ED142.3010503@init7.net> Message-ID: <76B79D10-2C57-403C-897C-3F1E902A17A9@delong.com> > On Jun 27, 2015, at 11:48 , manning wrote: > > Quite a few folks actually. (the 802.5 & 802.4 specs)?. > This is kind of like asking when we will stop using ethernet framing (ethernet was designed for a 3Mbps transmission rate) > yet we are deploying 100Gbps networks. Still stuck on that 1500byte limitation. When can we get rid of that? Many networks have? It?s called ?Jumbo Frames? Owen > > > manning > bmanning at karoshi.com > PO Box 12317 > Marina del Rey, CA 90295 > 310.322.8102 > > > > On 27June2015Saturday, at 9:49, Bacon Zombie wrote: > >> Is anybody still using IPX or TokenRing? >> >> I've heard that TokenRing is over 9000 times better for iSCSI since you are >> guaranteed that the packets will not get collisions. >> On 27 Jun 2015 18:39, "Fredy Kuenzler" wrote: >> >>> Am 27.06.2015 um 16:38 schrieb Bob Evans: >>>> We have a greater supply for packets to travel than we do for >>>> addresses required to move packets. Do you know how many packets a >>>> single IP address can generate or utilize, if it was attached too >>>> "The World's Fastest Internet" in someplace like Canadaland or Sweden >>>> on init7's Fiber7 ? >>> >>> Thanks for mentioning Fiber7, which is actually available in >>> Switzerland, not Sweden. And every Fiber7 customer gets a /48, too. >>> >>> -- >>> Fredy Kuenzler >>> >>> --------------------- >>> Fiber7. No Limits. >>> https://www.fiber7.ch >>> --------------------- >>> >>> Init7 (Switzerland) Ltd. >>> AS13030 >>> St.-Georgen-Strasse 70 >>> CH-8400 Winterthur >>> Skype: flyingpotato >>> Phone: +41 44 315 4400 >>> Fax: +41 44 315 4401 >>> Twitter: @init7 / @kuenzler >>> http://www.init7.net/ >>> >>> > From Valdis.Kletnieks at vt.edu Sun Jun 28 16:34:22 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 28 Jun 2015 12:34:22 -0400 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: Your message of "Sun, 28 Jun 2015 08:02:52 -0700." <76B79D10-2C57-403C-897C-3F1E902A17A9@delong.com> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <558ED142.3010503@init7.net> <76B79D10-2C57-403C-897C-3F1E902A17A9@delong.com> Message-ID: <15453.1435509262@turing-police.cc.vt.edu> On Sun, 28 Jun 2015 08:02:52 -0700, Owen DeLong said: > > > On Jun 27, 2015, at 11:48 , manning wrote: > > > > Quite a few folks actually. (the 802.5 & 802.4 specs) . > > This is kind of like asking when we will stop using ethernet framing (ethernet was designed for a 3Mbps transmission rate) > > yet we are deploying 100Gbps networks. Still stuck on that 1500byte limitation. When can we get rid of that? > > Many networks have It?s called ?Jumbo Frames? Unfortunately, enough people do things to break PMTU Discovery that it's not usually feasible to send jumbograms outside your directly controlled networks. So you may actually have jumbogram support all the way one end to the other, but you can't rely on it and have to throttle back to 1500 (or even smaller) in self-defense.... -------------- 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 Sun Jun 28 18:50:29 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 28 Jun 2015 13:50:29 -0500 (CDT) Subject: Quanta LB4M In-Reply-To: <1538206498.7765.1435517378968.JavaMail.mhammett@ThunderFuck> Message-ID: <1729959674.7770.1435517445740.JavaMail.mhammett@ThunderFuck> Has anyone gotten a "non-factory" firmware to go onto these guys? There are a couple threads on Google that are inconclusive. There are rumors that it's the same as a Dell something or an HP something else, but no one has outright said, "I loaded a Dell XXXX firmware onto it and solved all of the random ass bugs." If I didn't already have a couple of stacked Extreme x400s, I'd consider these at home, but they're somewhat buggy. Quanta told me to contact whomever I bought it from... but I don't think the random guy on eBay is going to have much of anything useful to say. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com From bruns at 2mbit.com Sun Jun 28 19:03:00 2015 From: bruns at 2mbit.com (Brielle Bruns) Date: Sun, 28 Jun 2015 13:03:00 -0600 Subject: Quanta LB4M In-Reply-To: <1729959674.7770.1435517445740.JavaMail.mhammett@ThunderFuck> References: <1729959674.7770.1435517445740.JavaMail.mhammett@ThunderFuck> Message-ID: <559044E4.2040208@2mbit.com> On 6/28/15 12:50 PM, Mike Hammett wrote: > Has anyone gotten a "non-factory" firmware to go onto these guys? There are a couple threads on Google that are inconclusive. There are rumors that it's the same as a Dell something or an HP something else, but no one has outright said, "I loaded a Dell XXXX firmware onto it and solved all of the random ass bugs." > > If I didn't already have a couple of stacked Extreme x400s, I'd consider these at home, but they're somewhat buggy. > > Quanta told me to contact whomever I bought it from... but I don't think the random guy on eBay is going to have much of anything useful to say. > Oh FSM, those things. Urgh. They are like the EIF24G series and 10GCF from Foundry - OEM devices that vendors can just rebrand with their own logos and sell. I've tried swapping the firmware on the EIF24G-As and the Dell equivalent, and its been a miss every time. Got several of them at one point with 'defective ports' that magically got fixed with a firmware upgrade. Even with the firmware upgrades, STP was a hot mess on them causing odd blocking situations. Your better off going with something like the new Ubiquiti EdgeSwitch Lite. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From nanog at ics-il.net Sun Jun 28 19:24:38 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 28 Jun 2015 14:24:38 -0500 (CDT) Subject: Quanta LB4M In-Reply-To: <559044E4.2040208@2mbit.com> Message-ID: <2093955279.7810.1435519488090.JavaMail.mhammett@ThunderFuck> *nods* I'm surprised that I missed that announcement until this morning. Given the love\hate I have with UBNT, I may end up getting them... and then hating myself for it. Those in the WISP business will understand. For those not in the WISP business, case of vendor doesn't listen on a regular enough basis. I have some of their products and love them to death. The others I beat over their heads with the issues. Wait, that gave me an idea for the next time I see them... Last February at the spring WISPA show, I gave several vendors an SFP. I've been requesting SFP cage on many products for many years (sometimes multiple generations of product) only to largely be ignored. I concluded that their engineering teams must not know what SFPs are and thus gave one to each of them to take back to their engineering teams so they could figure out how to make it happen. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Brielle Bruns" To: nanog at nanog.org Sent: Sunday, June 28, 2015 2:03:00 PM Subject: Re: Quanta LB4M On 6/28/15 12:50 PM, Mike Hammett wrote: > Has anyone gotten a "non-factory" firmware to go onto these guys? There are a couple threads on Google that are inconclusive. There are rumors that it's the same as a Dell something or an HP something else, but no one has outright said, "I loaded a Dell XXXX firmware onto it and solved all of the random ass bugs." > > If I didn't already have a couple of stacked Extreme x400s, I'd consider these at home, but they're somewhat buggy. > > Quanta told me to contact whomever I bought it from... but I don't think the random guy on eBay is going to have much of anything useful to say. > Oh FSM, those things. Urgh. They are like the EIF24G series and 10GCF from Foundry - OEM devices that vendors can just rebrand with their own logos and sell. I've tried swapping the firmware on the EIF24G-As and the Dell equivalent, and its been a miss every time. Got several of them at one point with 'defective ports' that magically got fixed with a firmware upgrade. Even with the firmware upgrades, STP was a hot mess on them causing odd blocking situations. Your better off going with something like the new Ubiquiti EdgeSwitch Lite. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jared at puck.nether.net Sun Jun 28 19:56:17 2015 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 28 Jun 2015 15:56:17 -0400 Subject: Quanta LB4M In-Reply-To: <1729959674.7770.1435517445740.JavaMail.mhammett@ThunderFuck> References: <1729959674.7770.1435517445740.JavaMail.mhammett@ThunderFuck> Message-ID: <1457DAD1-A34C-41F5-B02C-6D992819FA2B@puck.nether.net> > On Jun 28, 2015, at 2:50 PM, Mike Hammett wrote: > > Has anyone gotten a "non-factory" firmware to go onto these guys? There are a couple threads on Google that are inconclusive. There are rumors that it's the same as a Dell something or an HP something else, but no one has outright said, "I loaded a Dell XXXX firmware onto it and solved all of the random ass bugs." I managed to brick one of these by loading the wrong firmware, or doing it at the wrong layer. I have gotten a few more and these are great switches for home or environment where you have a spare on hand. You can usually get them for around $100 on eBay. The firmware is *really* not designed for anything fancy but I?ve been able to drop in a variety of optics and have it work without issues in the 10G ports. Check the flash on them as there is a primary/secondary flash once you?re past the boot image. (Don?t try to flash it from that level, that?s how I killed it at least). I tossed a few different firmware versions I extracted here, as well as the flash0/flash1 images and the doc i found for it. http://puck.nether.net/~jared/lb4m/ - Jared From morrowc.lists at gmail.com Mon Jun 29 02:59:45 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 28 Jun 2015 22:59:45 -0400 Subject: OK, Google. Time to dial back the AI hype. In-Reply-To: References: Message-ID: On Sun, Jun 28, 2015 at 9:17 AM, Mel Beckman wrote: > Don't computer scientists have a responsibility to deal forthrightly with the public on the real state of research in such fields as AI? When an Internet provider like Google makes such outlandish claims, one has to wonder what the real agenda is. don't list users have a responsibility to attempt to stay on topic? From streiner at cluebyfour.org Mon Jun 29 03:22:39 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 28 Jun 2015 23:22:39 -0400 (EDT) Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: On Sun, 28 Jun 2015, chris wrote: > I cant say much about other incumbents but i have been in alot of vz co's > in nj/nyc and Its very rare to see any humans in a CO anymore even in ones > in really dense metro areas The majority of ILEC COs I've seen are unstaffed these days, save for the rare occasion where something needs to be physically touched. CLECs are sometimes a different story because they might only have one physical CO in a given LATA. jms > On Jun 26, 2015 10:40 PM, "Christopher Morrow" > wrote: > >> On Fri, Jun 26, 2015 at 8:32 PM, John Musbach >> wrote: >>> On Thu, Jun 25, 2015 at 5:32 PM, Christopher Morrow >>> wrote: >>>> On Wed, Jun 24, 2015 at 2:46 PM, John Musbach >> wrote: >>>>> Hello, >>>>> >>>>> I'm a techie that recently moved to South Jersey for a tech job. To my >>>>> astonishment, I discovered that there appears to be a Verizon >>>>> datacenter near my house that has colocation: >>>> >>>> how / why did you think this has colocation? >>> >>> Look at the second picture, the sign on the door more specifically. :) >> >> oriiginal view of the door sign was not readable... had to do some >> work to see 'co locators entrance'. Bet this means 'clec entrance' >> (they probably forgot to include the hours of operation: 9-4, lunch >> 11-3) >> > From keiths at neilltech.com Sun Jun 28 03:38:20 2015 From: keiths at neilltech.com (Keith Stokes) Date: Sun, 28 Jun 2015 03:38:20 +0000 Subject: =?Windows-1252?Q?Re:_World's_Fastest_Internet=99_in_Canadaland?= In-Reply-To: <558E237F.1060602@alter3d.ca> References: <1FA3734A-DF71-444B-8F2A-27B8A5A1C7D2@hopcount.ca>, <558E237F.1060602@alter3d.ca> Message-ID: <798C8368-5EF3-46FB-A5D1-6B81DD65B56E@neilltech.com> Use wireless. There are reasonably priced point to point bridges available. -- Keith Stokes > On Jun 26, 2015, at 11:18 PM, Peter Kristolaitis wrote: > >> On 6/26/2015 7:26 PM, Joe Abley wrote: >> >>> On 26 Jun 2015, at 15:04, Hank Disuko wrote: >>> >>> Bell Canada is apparently gearing up to provide the good people of Toronto with the World's Fastest Internet?. >>> http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html >> >> Bell Canada is in the business of defending the current regulatory regime from claims that internet speeds are slow, or that investment by incumbents in the last mile is lacking, or that it ought to be required to share its access network with competitors. Read the press with that context in mind. >> >> There's cooperative, rural broadband in the UK [1] that offers 10G access to farms at a lower price than Bell charges for some satellite TV bundles. I don't think anybody need waste any cycles persuading other people here that the "fastest internet" claims are not aligned precisely with the kind reality you find even on this list. >> >> Joe >> >> [1] http://b4rn.org.uk > > And defend the current regulatory regime well they do. I live literally minutes outside of the Ottawa urban area and I have as choices for network connectivity either LoS wireless or satellite. I can, however, stand at the end of my driveway and look in EITHER direction to see houses that can get cable service, yet none of the incumbents are willing to service my little stretch of road (affecting me and ~5 neighbours). > > I'm told by the neighbours (I just moved here) that they've been bugging the incumbents for YEARS and getting no traction at all. I'm thinking of pricing out a fiber run and running a little local co-op network access provider for me and the neighbours, but I suspect that install costs might nix that idea. > > (For extra fun, I was told by one of the incumbents that my address was serviceable with up to 150Mbps cable before I purchased the property. Then when I took possession and tried to get service set up -- nope, sorry. But that's a whole other story...) > From kristian.j.f at gmail.com Sun Jun 28 04:11:40 2015 From: kristian.j.f at gmail.com (Kristian Francisco) Date: Sat, 27 Jun 2015 21:11:40 -0700 Subject: Data Center Network Monitoring with TAPs In-Reply-To: References: Message-ID: I'm designing the first phase of a datacenter network monitoring project for my company. We are starting with SPAN at access layer and plan to control traffic volume using filtering, slicing, de-dupe, etc. There are instances when we need to do capacity/delay analysis on L2 traffic and Ixia, APCON, Emulex etc. are coming out with flow generators for SPAN/TAP traffic. We may decide to go with TAP in the future as we found a vendor that was willing to implement functionality to allow us to offload flow generation from our access/distribution/core devices by creating templates based on the source device/interface. In essence, to our monitoring tools, netflow traffic will seem as if it is coming from the real device. Best Regards, Kristian J. Francisco On Mon, Jun 22, 2015 at 9:44 AM, Rafael Possamai wrote: > Here's a recent forum thread that discussed the same exact topic. You might > find some insight: > > http://www.reddit.com/r/networking/comments/3aip3p/data_center_network_monitoring/ > > > On Sat, Jun 20, 2015 at 11:06 AM, Mitch Howards > wrote: > > > Hello All, > > > > Was wondering what folks are using to monitor traffic > > on their networks. Looking into Ixia and APCON devices for dedup and > > other filtering features as well as passive fiber TAPs to capture the > > traffic. > > > > How are folks handling TAP'ing large data center > > networks? TAPs at the "distribution layer" would be the best fit for my > > network but that would require a ton of passive fiber TAPs for the > > incoming fibers to the distribution switches. The end goal is to not > > only capture the north-south traffic on the network but also east-west > > traffic. It seems more efficient to just use SPANs but there are many > > limitations using SPANs. > > > > Thanks in advance for any suggestions. > > > > Mitch > From mel at beckman.org Mon Jun 29 03:55:47 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 29 Jun 2015 03:55:47 +0000 Subject: OK, Google. Time to dial back the AI hype. In-Reply-To: References: , Message-ID: <8BB74F34-491B-44B2-9698-5F5C6F00C4F0@beckman.org> Because Google is an ISP, it seems to me a legitimate discussion point. Given Google's penchant for crafty customer surveillance, this technology seems like one that Google might try to leverage into a snoopy product. . -mel via cell > On Jun 28, 2015, at 10:59 PM, Christopher Morrow wrote: > >> On Sun, Jun 28, 2015 at 9:17 AM, Mel Beckman wrote: >> Don't computer scientists have a responsibility to deal forthrightly with the public on the real state of research in such fields as AI? When an Internet provider like Google makes such outlandish claims, one has to wonder what the real agenda is. > > don't list users have a responsibility to attempt to stay on topic? From ryan.landry at gmail.com Mon Jun 29 05:34:02 2015 From: ryan.landry at gmail.com (ryanL) Date: Mon, 29 Jun 2015 05:34:02 +0000 Subject: OK, Google. Time to dial back the AI hype. In-Reply-To: <8BB74F34-491B-44B2-9698-5F5C6F00C4F0@beckman.org> References: <8BB74F34-491B-44B2-9698-5F5C6F00C4F0@beckman.org> Message-ID: has nothing to do with network operations. stick to reddit or slashdot. On Sun, Jun 28, 2015, 20:57 Mel Beckman wrote: > Because Google is an ISP, it seems to me a legitimate discussion point. > Given Google's penchant for crafty customer surveillance, this technology > seems like one that Google might try to leverage into a snoopy product. . > > -mel via cell > > > On Jun 28, 2015, at 10:59 PM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > > > >> On Sun, Jun 28, 2015 at 9:17 AM, Mel Beckman wrote: > >> Don't computer scientists have a responsibility to deal forthrightly > with the public on the real state of research in such fields as AI? When an > Internet provider like Google makes such outlandish claims, one has to > wonder what the real agenda is. > > > > don't list users have a responsibility to attempt to stay on topic? > From randy at psg.com Mon Jun 29 07:11:11 2015 From: randy at psg.com (Randy Bush) Date: Mon, 29 Jun 2015 16:11:11 +0900 Subject: OK, Google. Time to dial back the AI hype. In-Reply-To: <8BB74F34-491B-44B2-9698-5F5C6F00C4F0@beckman.org> References: Message-ID: > Because Google is an ISP, it seems to me a legitimate discussion > point. Given Google's penchant for crafty customer surveillance, this > technology seems like one that Google might try to leverage into a > snoopy product. . if we wasted this list discussing things which *might* be leveraged into a snoopy product we would be overwhelmed and the folk who actually manage networks would go elsewhere. try some other list, please. we're just trying to move packets. randy From A.L.M.Buxey at lboro.ac.uk Mon Jun 29 08:14:05 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 29 Jun 2015 08:14:05 +0000 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: <92835.1435442045@turing-police.cc.vt.edu> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <92835.1435442045@turing-police.cc.vt.edu> Message-ID: <20150629081405.GB1191@lboro.ac.uk> Hi, > I just ran a tcpdump looking for NTP packets going to 128.173.14.71. In 90 > minutes, I got hits from 330 unique IP addresses, including some that were > chatty enough to indicate there were dozens of hosts behind a NAT. ah yes. the joy of the usual 2 scenarios 1) your IP got used in some random equipment config/firmware 2) your IP got used in some documentation rather than using one the official IPv4 documentation address space the last scenario is the IP address was used in some long ago post or blog that google helps unearth whenever anyone asks for NTP. we had the same for DNS.....learnt that lesson :/ >without bothering to sanity check if a clock is still usable.... THAT is the scary part.....they're not even checking its working.... (at least their kit wont crash and burn at the leap second if it hasnt got working NTP ;-) !) alan From A.L.M.Buxey at lboro.ac.uk Mon Jun 29 08:16:56 2015 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 29 Jun 2015 08:16:56 +0000 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> Message-ID: <20150629081656.GC1191@lboro.ac.uk> Hi, >I knew several people who built their career path on the assumptions of IPX. Ouch. ....or DECnet ;-) alan From jlewis at lewis.org Mon Jun 29 11:50:48 2015 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 29 Jun 2015 07:50:48 -0400 (EDT) Subject: OK, Google. Time to dial back the AI hype. In-Reply-To: References: Message-ID: On Sun, 28 Jun 2015, Mel Beckman wrote: > Google has always played fast and loose with its AI claims, but today t > has gone too far. In a WSJ story, Google is misleading people into > thinking it has achieved emotion, if not outright consciousness, in its > AI programming: > > http://slashdot.org/submission/4569873/wsj-jumps-the-shark-with-ai-gets-testy-story > > Google claims one of its computer programs using a database of movie > scripts to answer questions supposedly "lashed out" at a human > researcher who was repeatedly asking it to explain morality. Is the WSJ a wholly owned subsidiary of GOOG? It looks to me like a WSJ journalist said that. > Don't computer scientists have a responsibility to deal forthrightly > with the public on the real state of research in such fields as AI? When > an Internet provider like Google makes such outlandish claims, one has > to wonder what the real agenda is. I think you're confusing computer scientist integrity with journalism and a desire to attract readers. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From list at satchell.net Mon Jun 29 12:42:17 2015 From: list at satchell.net (Stephen Satchell) Date: Mon, 29 Jun 2015 05:42:17 -0700 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: <20150629081656.GC1191@lboro.ac.uk> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> <20150629081656.GC1191@lboro.ac.uk> Message-ID: <55913D29.2010908@satchell.net> On 06/29/2015 01:16 AM, A.L.M.Buxey at lboro.ac.uk wrote: > Hi, > >> I knew several people who built their career path on the assumptions of IPX. Ouch. > > ....or DECnet ;-) Or XNS. On the other hand, people did have a nice career with SNA...but they weren't trying to push packets over the From ramy.ihashish at gmail.com Mon Jun 29 12:53:57 2015 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Mon, 29 Jun 2015 14:53:57 +0200 Subject: CDNs for carriers Message-ID: Hello there, Does anybody recommend a CDN to work beside GGC and AKAMAI? and if you have a real life deployment, do you have any figures about how much this recommended CDN save from the Internet BW? (currently both of GGC and AKAMAI saves about 40% of our Internet BW) Thanks, Ramy From jared at puck.nether.net Mon Jun 29 12:56:31 2015 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 29 Jun 2015 08:56:31 -0400 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: <001501d0b109$84989ac0$8dc9d040$@iname.com> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <001501d0b109$84989ac0$8dc9d040$@iname.com> Message-ID: > On Jun 27, 2015, at 2:45 PM, wrote: > > What's the ratio of mobile (cellular) endpoints to non-mobile devices? And > we know that mobile continues to grow faster than fixed endpoints -- at what > point will the scales naturally tip to IPv6? this is why i?m very curious to see if google follows apple on the ipv6 software testing side. While I have some technical nits with the way that apple is enabling some testing as it impacts DNSSEC/DANE to start naming things, it does place us on the right trajectory. My guess is that IPv4 has a long life ahead of itself. - Jared From ramy.ihashish at gmail.com Mon Jun 29 12:57:35 2015 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Mon, 29 Jun 2015 14:57:35 +0200 Subject: Web content categorization Message-ID: Good day all, We are looking forward to filter the broadband traffic based on the category, anybody has any cost effective solution? Thanks, Ramy From patrick at ianai.net Mon Jun 29 12:58:59 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 29 Jun 2015 08:58:59 -0400 Subject: CDNs for carriers In-Reply-To: References: Message-ID: Netflix: Frankly, those three are roughly the same size, and the only ones anywhere near that size. -- TTFN, patrick > On Jun 29, 2015, at 08:53 , Ramy Hashish wrote: > > Hello there, > > Does anybody recommend a CDN to work beside GGC and AKAMAI? and if you have > a real life deployment, do you have any figures about how much this > recommended CDN save from the Internet BW? (currently both of GGC and > AKAMAI saves about 40% of our Internet BW) > > Thanks, > > Ramy From Valdis.Kletnieks at vt.edu Mon Jun 29 13:06:59 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 29 Jun 2015 09:06:59 -0400 Subject: CDNs for carriers In-Reply-To: Your message of "Mon, 29 Jun 2015 14:53:57 +0200." References: Message-ID: <43111.1435583219@turing-police.cc.vt.edu> On Mon, 29 Jun 2015 14:53:57 +0200, Ramy Hashish said: > Does anybody recommend a CDN to work beside GGC and AKAMAI? I would think that talking to Netflix about hosting one of their boxes would be the obvious next step? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From morrowc.lists at gmail.com Mon Jun 29 13:33:58 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 29 Jun 2015 09:33:58 -0400 Subject: CDNs for carriers In-Reply-To: References: Message-ID: On Mon, Jun 29, 2015 at 8:53 AM, Ramy Hashish wrote: > do you have any figures about how much this > recommended CDN save from the Internet BW? isn't that going to wholey depend on your traffic mix/matrix? Wouldn't it be helpful to look at where your users send/receive traffic and then figure out the best next addition? Maybe your best bet isn't another CDN, but better/more/wider peering with folk 2+ AS hops out from your current next-hop-as set? From jared at puck.nether.net Mon Jun 29 13:44:18 2015 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 29 Jun 2015 09:44:18 -0400 Subject: CDNs for carriers In-Reply-To: References: Message-ID: <7A5E6370-9856-422F-90B9-7AAF9D35628B@puck.nether.net> > On Jun 29, 2015, at 9:33 AM, Christopher Morrow wrote: > > On Mon, Jun 29, 2015 at 8:53 AM, Ramy Hashish wrote: >> do you have any figures about how much this >> recommended CDN save from the Internet BW? > > isn't that going to wholey depend on your traffic mix/matrix? > Wouldn't it be helpful to look at where your users send/receive > traffic and then figure out the best next addition? > > Maybe your best bet isn't another CDN, but better/more/wider peering > with folk 2+ AS hops out from your current next-hop-as set? I would say that step 1 is to figure out where your traffic is going. Generically saying ?CDN? isn?t enough to know what the results are. Once you?ve determined where the traffic is going/coming from you can start to make educated decisions vs just ?CDN? guessing. An enterprise profile looks much different than residential for example. I recall some companies calling our NOC ?under attack? because their software update server went down and the machines failed safe and were all fetching software updates from ?the internet? vs the internal caching proxy. If you have money to spend, there are a few vendors out there from cheap to $$$$ that will help you look at the traffic to make these decisions. If you don?t have money to spend, look at NFSen/pmacct. You may be able to spin up a low-cost VM at your local cloud provider (e.g.: digital ocean). Remember to export both your v6 and v4 (ip classic) flows as these can widely differ. Look for common ASNs or IP ranges. I?m sure there?s numerous consultants on the list that would also assist you in this process. Hope this helps. - jared From javier at kjsl.org Mon Jun 29 13:53:45 2015 From: javier at kjsl.org (Javier Henderson) Date: Mon, 29 Jun 2015 09:53:45 -0400 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: <55913D29.2010908@satchell.net> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> <20150629081656.GC1191@lboro.ac.uk> <55913D29.2010908@satchell.net> Message-ID: <353F0284-FC94-4AEB-A81A-01B474465A32@kjsl.org> > On Jun 29, 2015, at 8:42 AM, Stephen Satchell wrote: > > On 06/29/2015 01:16 AM, A.L.M.Buxey at lboro.ac.uk wrote: >> Hi, >> >>> I knew several people who built their career path on the assumptions of IPX. Ouch. >> >> ....or DECnet ;-) > > Or XNS. On the other hand, people did have a nice career with SNA...but they weren't trying to push packets over the ?LAT? -jav From nanog at ics-il.net Mon Jun 29 13:59:22 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 29 Jun 2015 08:59:22 -0500 (CDT) Subject: CDNs for carriers In-Reply-To: <7A5E6370-9856-422F-90B9-7AAF9D35628B@puck.nether.net> Message-ID: <1045686261.870.1435586395880.JavaMail.mhammett@ThunderFuck> Simple flows wouldn't necessarily tell you if you're pulling a bunch from a Netflix caching box on your upstream somewhere. You'd think you had a huge amount going to your current upstream because technically you do, but a local cache or peer could alter that significantly. As we've been starting up our IX, we're finding that we can send lists of ASNs and prefixes and the various CDNs will tell us how much traffic they see going to our customers. Combine that with what flows tell you and I think you've got a good approach. What are some good approaches to determining traffic levels to not only ASNs, but also that ASN's downstream ASNs? You may have ASNs A, B, C, D and E in your flows. Say none of them represent more than 5% of your traffic by themselves. If B, C, D and E all purchase transit from A and you can reasonably peer with A, you actually can move 25% of your traffic over to a peer. Maybe there is no good approach at doing that without a bunch of manual work or paying someone else to do it. Looking at some stats from one of our customers that is also going through Equinix Chicago, for their average inbound ~37% of traffic was Netflix, Google was 34% and the next highest was Apple at 5%. Note that Akamai had left Chicago Equinix by this point, so they wouldn't be reflected in those numbers. Those percentages are percent of all traffic they send to Equinix. I believe about 2/3s of their total transit went to Equinix when that got turned up. Their total traffic went up once joining the Equinix IX, presumably because they were now bypassing some congestion somewhere. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" To: "Christopher Morrow" Cc: "nanog list" , "Ramy Hashish" Sent: Monday, June 29, 2015 8:44:18 AM Subject: Re: CDNs for carriers > On Jun 29, 2015, at 9:33 AM, Christopher Morrow wrote: > > On Mon, Jun 29, 2015 at 8:53 AM, Ramy Hashish wrote: >> do you have any figures about how much this >> recommended CDN save from the Internet BW? > > isn't that going to wholey depend on your traffic mix/matrix? > Wouldn't it be helpful to look at where your users send/receive > traffic and then figure out the best next addition? > > Maybe your best bet isn't another CDN, but better/more/wider peering > with folk 2+ AS hops out from your current next-hop-as set? I would say that step 1 is to figure out where your traffic is going. Generically saying ?CDN? isn?t enough to know what the results are. Once you?ve determined where the traffic is going/coming from you can start to make educated decisions vs just ?CDN? guessing. An enterprise profile looks much different than residential for example. I recall some companies calling our NOC ?under attack? because their software update server went down and the machines failed safe and were all fetching software updates from ?the internet? vs the internal caching proxy. If you have money to spend, there are a few vendors out there from cheap to $$$$ that will help you look at the traffic to make these decisions. If you don?t have money to spend, look at NFSen/pmacct. You may be able to spin up a low-cost VM at your local cloud provider (e.g.: digital ocean). Remember to export both your v6 and v4 (ip classic) flows as these can widely differ. Look for common ASNs or IP ranges. I?m sure there?s numerous consultants on the list that would also assist you in this process. Hope this helps. - jared From morrowc.lists at gmail.com Mon Jun 29 14:16:01 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 29 Jun 2015 10:16:01 -0400 Subject: CDNs for carriers In-Reply-To: <1045686261.870.1435586395880.JavaMail.mhammett@ThunderFuck> References: <7A5E6370-9856-422F-90B9-7AAF9D35628B@puck.nether.net> <1045686261.870.1435586395880.JavaMail.mhammett@ThunderFuck> Message-ID: On Mon, Jun 29, 2015 at 9:59 AM, Mike Hammett wrote: > Simple flows wouldn't necessarily tell you if you're pulling a bunch from a Netflix caching box on your upstream somewhere. You'd think you had a huge amount going to your current upstream because technically you do, but a local cache or peer could alter that significantly. probably dns and flow gets you some more traction, right? meaning: "gosh 1.2.3.0/26 is sending us LOTS of traffic... oh: nslookup 1.2.3.4 == hosta.networkb.netflix.com, ah-ha!" where ptr records are generated I suppose like: $ host 63.88.73.108 108.73.88.63.in-addr.arpa domain name pointer 108.73.88.63.ashburn.google-ggc.verizon.com. Also, often just port/protocol are helpful enough... you won't know without looking (at the OP's traffic I mean), which it sounds like hasn't really been done yet? From jared at puck.nether.net Mon Jun 29 14:21:05 2015 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 29 Jun 2015 10:21:05 -0400 Subject: CDNs for carriers In-Reply-To: <1045686261.870.1435586395880.JavaMail.mhammett@ThunderFuck> References: <1045686261.870.1435586395880.JavaMail.mhammett@ThunderFuck> Message-ID: > On Jun 29, 2015, at 9:59 AM, Mike Hammett wrote: > > Simple flows wouldn't necessarily tell you if you're pulling a bunch from a Netflix caching box on your upstream somewhere. You'd think you had a huge amount going to your current upstream because technically you do, but a local cache or peer could alter that significantly. As we've been starting up our IX, we're finding that we can send lists of ASNs and prefixes and the various CDNs will tell us how much traffic they see going to our customers. Combine that with what flows tell you and I think you've got a good approach. > > What are some good approaches to determining traffic levels to not only ASNs, but also that ASN's downstream ASNs? You may have ASNs A, B, C, D and E in your flows. Say none of them represent more than 5% of your traffic by themselves. If B, C, D and E all purchase transit from A and you can reasonably peer with A, you actually can move 25% of your traffic over to a peer. Maybe there is no good approach at doing that without a bunch of manual work or paying someone else to do it. > > Looking at some stats from one of our customers that is also going through Equinix Chicago, for their average inbound ~37% of traffic was Netflix, Google was 34% and the next highest was Apple at 5%. Note that Akamai had left Chicago Equinix by this point, so they wouldn't be reflected in those numbers. Those percentages are percent of all traffic they send to Equinix. I believe about 2/3s of their total transit went to Equinix when that got turned up. Their total traffic went up once joining the Equinix IX, presumably because they were now bypassing some congestion somewhere. > Sure. There are a lot of dynamics to consider. It?s fairly easy to look at TCP speeds and retransmissions to determine the link speed involved. I?ve seen many CDNs quickly identify congested or paths without congestion and engage in some adaptive behaviors. This being said, there is not a single solution to everything. Chris mentioned using DNS, which is a nice method assuming you see all the queries within your traffic cone. - Jared From bob at FiberInternetCenter.com Mon Jun 29 14:22:16 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 29 Jun 2015 07:22:16 -0700 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: <15453.1435509262@turing-police.cc.vt.edu> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <558ED142.3010503@init7.net> <76B79D10-2C57-403C-897C-3F1E902A17A9@delong.com> <15453.1435509262@turing-police.cc.vt.edu> Message-ID: It is true - you I have had to throttle back for years for optimum transport on many carriers. In fact, if you have an ATT transit in your mix of BGP you wont get a ping response at 1500 MTU from that ATT router. On Sun, 28 Jun 2015 08:02:52 -0700, Owen DeLong said: >> >> > On Jun 27, 2015, at 11:48 , manning wrote: >> > >> > Quite a few folks actually. (the 802.5 & 802.4 specs) . >> > This is kind of like asking when we will stop using ethernet framing >> (ethernet was designed for a 3Mbps transmission rate) >> > yet we are deploying 100Gbps networks. Still stuck on that 1500byte >> limitation. When can we get rid of that? >> >> Many networks have It?s called ?Jumbo Frames? > > Unfortunately, enough people do things to break PMTU Discovery that it's > not > usually feasible to send jumbograms outside your directly controlled > networks. > So you may actually have jumbogram support all the way one end to the > other, > but you can't rely on it and have to throttle back to 1500 (or even > smaller) > in self-defense.... > From morrowc.lists at gmail.com Mon Jun 29 14:25:11 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 29 Jun 2015 10:25:11 -0400 Subject: CDNs for carriers In-Reply-To: References: <1045686261.870.1435586395880.JavaMail.mhammett@ThunderFuck> Message-ID: On Mon, Jun 29, 2015 at 10:21 AM, Jared Mauch wrote: > This being said, there is not a single solution to everything. Chris mentioned using DNS, which is a nice method assuming you see all the queries within your traffic cone. sorry, I meant that you could just look at the reverse dns for some of the higher traffic sources/destinations... you can ALSO look at your recursive dns servers to see what folk are looking up 'often'... which is a third tool to use. (presuming you see all/most/representative-set of your customers, yes) From blake at ispn.net Mon Jun 29 14:46:03 2015 From: blake at ispn.net (Blake Hudson) Date: Mon, 29 Jun 2015 09:46:03 -0500 Subject: CDNs for carriers In-Reply-To: References: <1045686261.870.1435586395880.JavaMail.mhammett@ThunderFuck> Message-ID: <55915A2B.3000508@ispn.net> Christopher Morrow wrote on 6/29/2015 9:25 AM: > On Mon, Jun 29, 2015 at 10:21 AM, Jared Mauch wrote: >> This being said, there is not a single solution to everything. Chris mentioned using DNS, which is a nice method assuming you see all the queries within your traffic cone. > > sorry, I meant that you could just look at the reverse dns for some of > the higher traffic sources/destinations... you can ALSO look at your > recursive dns servers to see what folk are looking up 'often'... which > is a third tool to use. (presuming you see all/most/representative-set > of your customers, yes) For hosts with no (or meaningless) reverse DNS, I've found that browsing to the IP in question via HTTPs will often provide an SSL certificate with lots of useful information. --Blake From bob at FiberInternetCenter.com Mon Jun 29 16:07:00 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 29 Jun 2015 09:07:00 -0700 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: <353F0284-FC94-4AEB-A81A-01B474465A32@kjsl.org> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> <20150629081656.GC1191@lboro.ac.uk> <55913D29.2010908@satchell.net> <353F0284-FC94-4AEB-A81A-01B474465A32@kjsl.org> Message-ID: It would not surprise me to find ARCnet (Datapoint's) still running in some corner somewhere. Thank You Bob Evans CTO >> On Jun 29, 2015, at 8:42 AM, Stephen Satchell wrote: >> >> On 06/29/2015 01:16 AM, A.L.M.Buxey at lboro.ac.uk wrote: >>> Hi, >>> >>>> I knew several people who built their career path on the assumptions >>>> of IPX. Ouch. >>> >>> ....or DECnet ;-) >> >> Or XNS. On the other hand, people did have a nice career with SNA...but >> they weren't trying to push packets over the > > ?LAT? > > -jav > > From gary.buhrmaster at gmail.com Mon Jun 29 16:15:49 2015 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Mon, 29 Jun 2015 16:15:49 +0000 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> <20150629081656.GC1191@lboro.ac.uk> <55913D29.2010908@satchell.net> <353F0284-FC94-4AEB-A81A-01B474465A32@kjsl.org> Message-ID: On Mon, Jun 29, 2015 at 4:07 PM, Bob Evans wrote: > It would not surprise me to find ARCnet (Datapoint's) still running in > some corner somewhere. Possibly next to the system running Banyan VINES. From larrysheldon at cox.net Mon Jun 29 16:20:22 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 29 Jun 2015 11:20:22 -0500 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> <20150629081656.GC1191@lboro.ac.uk> <55913D29.2010908@satchell.net> <353F0284-FC94-4AEB-A81A-01B474465A32@kjsl.org> Message-ID: <55917046.6020703@cox.net> On 6/29/2015 11:07, Bob Evans wrote: > It would not surprise me to find ARCnet (Datapoint's) still running > in some corner somewhere. I would not be surprised to learn that the University that fired me for being too old still has one. -- sed quis custodiet ipsos custodes? (Juvenal) From rodrigo at 1telecom.com.br Mon Jun 29 17:38:16 2015 From: rodrigo at 1telecom.com.br (Rodrigo Augusto) Date: Mon, 29 Jun 2015 14:38:16 -0300 Subject: microwave comba fos200 Message-ID: Hi folks? Does anyone have a telnet user and password for this radio? Rodrigo Augusto Gestor de T.I. Grupo Connectoway http://www.connectoway.com.br http://www.1telecom.com.br * rodrigo at connectoway.com.br ( (81) 3497-6060 ( (81) 8184-3646 ( INOC-DBA 52965*100 From ttauber at 1-4-5.net Mon Jun 29 17:34:13 2015 From: ttauber at 1-4-5.net (Tony Tauber) Date: Mon, 29 Jun 2015 13:34:13 -0400 Subject: [NANOG-announce] =?utf-8?q?NANOG_65_-_Montr=C3=A9al_-_Call_for_Pr?= =?utf-8?q?esentations_is_Open!?= Message-ID: Hello NANOG Folks, Thanks to all those who made NANOG 64 in San Francisco our largest meeting ever (by well over 25% margin)! Our 65th meeting will be held in Montr?al, Quebec on June 5-7th. Our meeting sits between the DNS-OARC workshop (Sat-Sun) and the ARIN 36 meeting (Thu-Fri) so will be ripe for fruitful interaction among these various constituencies. The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG 65 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet, . Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability. Key dates to track if you wish to submit a presentation: Key Dates For NANOG 65 Event/Deadline Date Registration for NANOG 65 Opens Monday, 6/29/2015 CFP Opens for NANOG 65 Monday, 6/29/2015 CFP Deadline #1: Presentation Abstracts Due Monday, 7/27/2015 CFP Topic List and NANOG Highlights Page Posted Friday, 8/14/2015 CFP Deadline #2: Presentation Slides Due Monday, 8/31/2015 Meeting Agenda Published Monday, 9/7/2015 Speaker FINAL presentations to PC Tool Friday, 10/2/2015 On-site Registration Sunday, 10/4/2015 Lightning Talk Submissions Open (Abstracts Only) Saturday, 10/3/2015 NANOG 65 submissions are welcome on the Program Committee Site or email me if you have questions. See the detailed NANOG65 Call for Presentations for more information. Thanks, Tony Tauber Chair, Program Committee North American Network Operator Group (NANOG) -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From ttauber at 1-4-5.net Mon Jun 29 17:44:48 2015 From: ttauber at 1-4-5.net (Tony Tauber) Date: Mon, 29 Jun 2015 13:44:48 -0400 Subject: [NANOG-announce] =?utf-8?q?NANOG_65_-_Montr=C3=A9al_-_Call_for_Pr?= =?utf-8?q?esentations_is_Open!?= In-Reply-To: References: Message-ID: Dang! Yes, correct. It's October 5-7th. Our 65th meeting will be held in Montr?al, Quebec on June 5-7th. > Thanks for the eagle eyes out there. Tony -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jason.sherron at microsoft.com Mon Jun 29 18:02:41 2015 From: jason.sherron at microsoft.com (Jason Sherron) Date: Mon, 29 Jun 2015 18:02:41 +0000 Subject: Data Center Network Monitoring with TAPs In-Reply-To: References: Message-ID: <8ceed28978c54216b7733ccc3f8768e6@DFM-DB3MBX15-07.exchange.corp.microsoft.com> Some colleagues wrote up Microsoft DEMon: https://sharkfest.wireshark.org/sharkfest.12/presentations/A-4_Leveraging_Openflow_to_create_a_Large_Scale_and_Cost_Effective_Packet_Capture_Network.pdf -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kristian Francisco Sent: Saturday, June 27, 2015 9:12 PM To: Rafael Possamai Cc: nanog at nanog.org Subject: Re: Data Center Network Monitoring with TAPs I'm designing the first phase of a datacenter network monitoring project for my company. We are starting with SPAN at access layer and plan to control traffic volume using filtering, slicing, de-dupe, etc. There are instances when we need to do capacity/delay analysis on L2 traffic and Ixia, APCON, Emulex etc. are coming out with flow generators for SPAN/TAP traffic. We may decide to go with TAP in the future as we found a vendor that was willing to implement functionality to allow us to offload flow generation from our access/distribution/core devices by creating templates based on the source device/interface. In essence, to our monitoring tools, netflow traffic will seem as if it is coming from the real device. Best Regards, Kristian J. Francisco On Mon, Jun 22, 2015 at 9:44 AM, Rafael Possamai wrote: > Here's a recent forum thread that discussed the same exact topic. You > might find some insight: > > http://www.reddit.com/r/networking/comments/3aip3p/data_center_network > _monitoring/ > > > On Sat, Jun 20, 2015 at 11:06 AM, Mitch Howards > wrote: > > > Hello All, > > > > Was wondering what folks are using to monitor traffic on their > > networks. Looking into Ixia and APCON devices for dedup and other > > filtering features as well as passive fiber TAPs to capture the > > traffic. > > > > How are folks handling TAP'ing large data center networks? TAPs at > > the "distribution layer" would be the best fit for my network but > > that would require a ton of passive fiber TAPs for the incoming > > fibers to the distribution switches. The end goal is to not only > > capture the north-south traffic on the network but also east-west > > traffic. It seems more efficient to just use SPANs but there are > > many limitations using SPANs. > > > > Thanks in advance for any suggestions. > > > > Mitch > From bygg at cafax.se Mon Jun 29 20:17:37 2015 From: bygg at cafax.se (Johnny Eriksson) Date: Mon, 29 Jun 2015 20:17:37 WET DST Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: Your message of Mon, 29 Jun 2015 09:53:45 -0400 Message-ID: Javier Henderson wrote: > > Or XNS. On the other hand, people did have a nice career with > SNA...but they weren't trying to push packets over the > > LAT .daytime Monday 29-Jun-2015 20:10:46 .pjob Job 3 at ODEN User BYGG [10,335] TTY4 .where tty4 LAT PC78(LATD for FreeBSD) TTY4 Is there anyting wrong with LAT? > -jav --Johnny From swhyte at gmail.com Mon Jun 29 19:04:15 2015 From: swhyte at gmail.com (Scott Whyte) Date: Mon, 29 Jun 2015 12:04:15 -0700 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: Message-ID: <559196AF.8020600@gmail.com> On 6/29/15 20:17, Johnny Eriksson wrote: > Javier Henderson wrote: > >>> Or XNS. On the other hand, people did have a nice career with >> SNA...but they weren't trying to push packets over the >> >> LAT > > .daytime > Monday 29-Jun-2015 20:10:46 > > .pjob > Job 3 at ODEN User BYGG [10,335] TTY4 > > .where tty4 > LAT PC78(LATD for FreeBSD) TTY4 > > Is there anyting wrong with LAT? err, its been awhile. Doesn't LAT have a 1 sec timeout that's not configurable? > >> -jav > > --Johnny > From ggm at algebras.org Mon Jun 29 19:41:44 2015 From: ggm at algebras.org (George Michaelson) Date: Mon, 29 Jun 2015 21:41:44 +0200 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: <559196AF.8020600@gmail.com> References: <559196AF.8020600@gmail.com> Message-ID: Dec gave you the source on Microfiche. If you want to change LAT just read, and find your Bliss32 compiler. On Mon, Jun 29, 2015 at 9:04 PM, Scott Whyte wrote: > > > On 6/29/15 20:17, Johnny Eriksson wrote: > >> Javier Henderson wrote: >> >> Or XNS. On the other hand, people did have a nice career with >>>> >>> SNA...but they weren't trying to push packets over the >>> >>> LAT >>> >> >> .daytime >> Monday 29-Jun-2015 20:10:46 >> >> .pjob >> Job 3 at ODEN User BYGG [10,335] TTY4 >> >> .where tty4 >> LAT PC78(LATD for FreeBSD) TTY4 >> >> Is there anyting wrong with LAT? >> > > err, its been awhile. Doesn't LAT have a 1 sec timeout that's not > configurable? > > >> -jav >>> >> >> --Johnny >> >> From jimpop at gmail.com Mon Jun 29 21:04:12 2015 From: jimpop at gmail.com (Jim Popovitch) Date: Mon, 29 Jun 2015 17:04:12 -0400 Subject: NTT->HE earlier today (~10am EDT) Message-ID: Hello, I haven't seen anything to explain this, so I'm asking a larger audience. Did anyone notice any unusual NTT or HE routing this AM? Here's what I saw: 2.|-- xe-0-1-0-17.r04.atlnga05.us.bb.gin.ntt.net 0.0% 20 0.8 0.7 0.6 0.9 0.1 3.|-- ae-2.r20.atlnga05.us.bb.gin.ntt.net 0.0% 20 4.6 6.2 0.5 13.6 4.8 4.|-- ae-4.r22.asbnva02.us.bb.gin.ntt.net 0.0% 20 15.3 15.0 13.9 15.8 0.7 5.|-- ae-4.r20.frnkge04.de.bb.gin.ntt.net 0.0% 20 127.3 106.7 98.5 127.3 11.1 6.|-- ae-2.r02.frnkge04.de.bb.gin.ntt.net 0.0% 20 126.8 126.0 125.7 126.8 0.2 7.|-- ae-1.r00.sofibu01.bg.bb.gin.ntt.net 0.0% 20 131.1 130.0 128.7 131.4 1.2 8.|-- 83.217.227.42 80.0% 20 148.5 146.0 144.2 148.5 2.0 9.|-- ip-48-93.sofia-connect.net 90.0% 20 184.5 163.8 143.1 184.5 29.3 10.|-- ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 11.|-- 10ge5-4.core1.vie1.he.net 75.0% 20 160.7 150.4 143.9 160.7 6.3 12.|-- 10ge1-4.core1.prg1.he.net 80.0% 20 158.4 159.5 157.9 161.1 1.6 13.|-- 10ge10-12.core1.fra1.he.net 75.0% 20 154.5 159.2 145.9 174.4 10.7 14.|-- 100ge5-2.core1.par2.he.net 75.0% 20 187.9 172.9 157.1 187.9 11.1 15.|-- 100ge7-1.core1.nyc4.he.net 78.9% 19 147.2 146.2 144.6 147.5 1.4 16.|-- 100ge7-2.core1.chi1.he.net 78.9% 19 165.6 172.1 165.6 183.5 8.0 17.|-- 10ge15-2.core1.den1.he.net 89.5% 19 201.3 204.7 201.3 208.1 4.8 -Jim P. From r.engehausen at gmail.com Mon Jun 29 21:15:38 2015 From: r.engehausen at gmail.com (Roy) Date: Mon, 29 Jun 2015 14:15:38 -0700 Subject: Charter and IPV6? Message-ID: <5591B57A.7050900@gmail.com> Has Charter rolled out IPV6 yet? I have both fiber and cable connections to Charter but I stopped asking them months ago. Roy From Curtis.Parish at mtsu.edu Mon Jun 29 21:17:17 2015 From: Curtis.Parish at mtsu.edu (Curtis L. Parish) Date: Mon, 29 Jun 2015 21:17:17 +0000 Subject: Any Verizon datacenter techs about? In-Reply-To: References: Message-ID: If the building is over 30 years old I can guarantee you it is at least 75% empty now. >P.S. If there was any way to get a tour inside of there at least I'd totally sign a NDA for that. :) Never been inside, let alone near, a CO >before. >-- John Musbach From mleber at he.net Mon Jun 29 21:18:24 2015 From: mleber at he.net (Mike Leber) Date: Mon, 29 Jun 2015 14:18:24 -0700 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: References: Message-ID: <5591B620.2000407@he.net> NTT's customer Sofia Connect leaked our routes to NTT. NTT accepted these routes instead of properly filtering their customer announcements. As a network of non-trivial size, announcing over 75,000 customer routes which is nearly 15% of the IPv4 routing table, we'd expect the common courtesy of having our ASN included in their customer facing AS-PATH filters, as we extend this same courtesy to other networks of this size (such as AS2914). Mike. On 6/29/15 2:04 PM, Jim Popovitch wrote: > Hello, > > I haven't seen anything to explain this, so I'm asking a larger > audience. Did anyone notice any unusual NTT or HE routing this AM? > > Here's what I saw: > > > 2.|-- xe-0-1-0-17.r04.atlnga05.us.bb.gin.ntt.net 0.0% 20 0.8 > 0.7 0.6 0.9 0.1 > 3.|-- ae-2.r20.atlnga05.us.bb.gin.ntt.net 0.0% 20 4.6 > 6.2 0.5 13.6 4.8 > 4.|-- ae-4.r22.asbnva02.us.bb.gin.ntt.net 0.0% 20 15.3 > 15.0 13.9 15.8 0.7 > 5.|-- ae-4.r20.frnkge04.de.bb.gin.ntt.net 0.0% 20 127.3 > 106.7 98.5 127.3 11.1 > 6.|-- ae-2.r02.frnkge04.de.bb.gin.ntt.net 0.0% 20 126.8 > 126.0 125.7 126.8 0.2 > 7.|-- ae-1.r00.sofibu01.bg.bb.gin.ntt.net 0.0% 20 131.1 > 130.0 128.7 131.4 1.2 > 8.|-- 83.217.227.42 80.0% 20 148.5 > 146.0 144.2 148.5 2.0 > 9.|-- ip-48-93.sofia-connect.net 90.0% 20 184.5 > 163.8 143.1 184.5 29.3 > 10.|-- ??? 100.0 20 0.0 > 0.0 0.0 0.0 0.0 > 11.|-- 10ge5-4.core1.vie1.he.net 75.0% 20 160.7 > 150.4 143.9 160.7 6.3 > 12.|-- 10ge1-4.core1.prg1.he.net 80.0% 20 158.4 > 159.5 157.9 161.1 1.6 > 13.|-- 10ge10-12.core1.fra1.he.net 75.0% 20 154.5 > 159.2 145.9 174.4 10.7 > 14.|-- 100ge5-2.core1.par2.he.net 75.0% 20 187.9 > 172.9 157.1 187.9 11.1 > 15.|-- 100ge7-1.core1.nyc4.he.net 78.9% 19 147.2 > 146.2 144.6 147.5 1.4 > 16.|-- 100ge7-2.core1.chi1.he.net 78.9% 19 165.6 > 172.1 165.6 183.5 8.0 > 17.|-- 10ge15-2.core1.den1.he.net 89.5% 19 201.3 > 204.7 201.3 208.1 4.8 > > > -Jim P. From lathama at gmail.com Mon Jun 29 21:20:37 2015 From: lathama at gmail.com (Andrew Latham) Date: Mon, 29 Jun 2015 16:20:37 -0500 Subject: Charter and IPV6? In-Reply-To: <5591B57A.7050900@gmail.com> References: <5591B57A.7050900@gmail.com> Message-ID: Google says https://www.myaccount.charter.com/customers/Support.aspx?SupportArticleID=2665 and I use the 6rd. It works. On Mon, Jun 29, 2015 at 4:15 PM, Roy wrote: > > Has Charter rolled out IPV6 yet? I have both fiber and cable connections > to Charter but I stopped asking them months ago. > > Roy > -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From robertg at garlic.com Mon Jun 29 21:23:07 2015 From: robertg at garlic.com (Robert Glover) Date: Mon, 29 Jun 2015 14:23:07 -0700 Subject: Charter and IPV6? Message-ID: As of 3mos ago, no :( -------- Original message -------- From: Roy Date: 06/29/2015 2:15 PM (GMT-08:00) To: nanog Subject: Charter and IPV6? Has Charter rolled out IPV6 yet?? I have both fiber and cable connections to Charter but I stopped asking them months ago. Roy ??????????? From mtt.lov at gmail.com Mon Jun 29 21:38:30 2015 From: mtt.lov at gmail.com (Matt Love) Date: Mon, 29 Jun 2015 17:38:30 -0400 Subject: Charter and IPV6? In-Reply-To: References: Message-ID: I just asked for it about a month ago in my area, they said the beta is just about to be over. On Mon, Jun 29, 2015 at 5:23 PM, Robert Glover wrote: > As of 3mos ago, no :( > > > > -------- Original message -------- > From: Roy > Date: 06/29/2015 2:15 PM (GMT-08:00) > To: nanog > Subject: Charter and IPV6? > > > Has Charter rolled out IPV6 yet? I have both fiber and cable > connections to Charter but I stopped asking them months ago. > > Roy > ??????????? From jared at puck.nether.net Mon Jun 29 21:51:18 2015 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 29 Jun 2015 17:51:18 -0400 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: <5591B620.2000407@he.net> References: <5591B620.2000407@he.net> Message-ID: <4163618F-C434-4B16-9A73-A9918B4A8713@puck.nether.net> Greetings, We are aware of this issue and as is usual we filter customers based on their registered routes. This creates some unique challenges that we have been speaking about publicly and privately with various groups. I have started the process (yay telco-speak) to fix this. It would be helpful if networks would take a look at what routes they have registered in the various IRRs as well as if their AS-SETs expand out to something quite large. We have seen many customers import objects that then import their other upstream networks. We have found the IRR Explorer tool helpful to look at who has registered our IP space and to police these registrations with the various IRRs out there. http://irrexplorer.nlnog.net/ http://irrexplorer.nlnog.net/prefix/184.105.213.86 The stability of the routing ecosystem is something that I personally care a lot about and have privately given Mike and others my cell number to allow them to follow-up. As is often operators end up chasing problems after the fact, and this appears to be no exception. *sigh* - Jared > On Jun 29, 2015, at 5:18 PM, Mike Leber wrote: > > NTT's customer Sofia Connect leaked our routes to NTT. NTT accepted these routes instead of properly filtering their customer announcements. As a network of non-trivial size, announcing over 75,000 customer routes which is nearly 15% of the IPv4 routing table, we'd expect the common courtesy of having our ASN included in their customer facing AS-PATH filters, as we extend this same courtesy to other networks of this size (such as AS2914). > > Mike. > > On 6/29/15 2:04 PM, Jim Popovitch wrote: >> Hello, >> >> I haven't seen anything to explain this, so I'm asking a larger >> audience. Did anyone notice any unusual NTT or HE routing this AM? >> >> Here's what I saw: >> >> >> 2.|-- xe-0-1-0-17.r04.atlnga05.us.bb.gin.ntt.net 0.0% 20 0.8 >> 0.7 0.6 0.9 0.1 >> 3.|-- ae-2.r20.atlnga05.us.bb.gin.ntt.net 0.0% 20 4.6 >> 6.2 0.5 13.6 4.8 >> 4.|-- ae-4.r22.asbnva02.us.bb.gin.ntt.net 0.0% 20 15.3 >> 15.0 13.9 15.8 0.7 >> 5.|-- ae-4.r20.frnkge04.de.bb.gin.ntt.net 0.0% 20 127.3 >> 106.7 98.5 127.3 11.1 >> 6.|-- ae-2.r02.frnkge04.de.bb.gin.ntt.net 0.0% 20 126.8 >> 126.0 125.7 126.8 0.2 >> 7.|-- ae-1.r00.sofibu01.bg.bb.gin.ntt.net 0.0% 20 131.1 >> 130.0 128.7 131.4 1.2 >> 8.|-- 83.217.227.42 80.0% 20 148.5 >> 146.0 144.2 148.5 2.0 >> 9.|-- ip-48-93.sofia-connect.net 90.0% 20 184.5 >> 163.8 143.1 184.5 29.3 >> 10.|-- ??? 100.0 20 0.0 >> 0.0 0.0 0.0 0.0 >> 11.|-- 10ge5-4.core1.vie1.he.net 75.0% 20 160.7 >> 150.4 143.9 160.7 6.3 >> 12.|-- 10ge1-4.core1.prg1.he.net 80.0% 20 158.4 >> 159.5 157.9 161.1 1.6 >> 13.|-- 10ge10-12.core1.fra1.he.net 75.0% 20 154.5 >> 159.2 145.9 174.4 10.7 >> 14.|-- 100ge5-2.core1.par2.he.net 75.0% 20 187.9 >> 172.9 157.1 187.9 11.1 >> 15.|-- 100ge7-1.core1.nyc4.he.net 78.9% 19 147.2 >> 146.2 144.6 147.5 1.4 >> 16.|-- 100ge7-2.core1.chi1.he.net 78.9% 19 165.6 >> 172.1 165.6 183.5 8.0 >> 17.|-- 10ge15-2.core1.den1.he.net 89.5% 19 201.3 >> 204.7 201.3 208.1 4.8 >> >> >> -Jim P. From bmanning at karoshi.com Mon Jun 29 22:18:46 2015 From: bmanning at karoshi.com (manning) Date: Mon, 29 Jun 2015 15:18:46 -0700 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> <18012.1429214983@turing-police.cc.vt.edu> <20150416201356.GN67158@Vurt.local> <19328.1429216247@turing-police.cc.vt.edu> <55301E9B.4010601@bogus.com> <55380E9B.7080908@ripe.net> Message-ID: <5918ED06-83E8-4B66-BC80-34361483AF59@karoshi.com> is this any different than the architecture Rodney Joffe built 20 years ago? manning bmanning at karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 1May2015Friday, at 15:41, Jac Kloots wrote: > > Randy, > > On Thu, 30 Apr 2015, Randy Bush wrote: > >>>>> in any case the idea still seems silly. >>>> not if you need to appear to be DOING SOMETHING!!! >>> Of course there is that. But in order to be appear to be doing something >>> one has to pledge to do BCP38 and various other things I would consider >>> BCP. All little bits help. >> >> except the big logo marketing has the implication that all the rest of >> us unwashed networks are untrustable. this is not the cooperative >> internet. > > You can apply to become a member in the initiative. > > Jac > > -- > Jac Kloots > Network Services > SURFnet bv From rs at seastrom.com Mon Jun 29 23:38:53 2015 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 29 Jun 2015 19:38:53 -0400 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: (George Michaelson's message of "Mon, 29 Jun 2015 21:41:44 +0200") References: <559196AF.8020600@gmail.com> Message-ID: <86vbe6dr02.fsf@valhalla.seastrom.com> Guarantee there's no BLISS-32 on Johnny's machine. The source to the LAT software he's talking to *may* be in BLISS-36. It's more likely in MACRO-10. -r (does this gray hair make me look old?) George Michaelson writes: > Dec gave you the source on Microfiche. If you want to change LAT just read, > and find your Bliss32 compiler. > > On Mon, Jun 29, 2015 at 9:04 PM, Scott Whyte wrote: > >> >> >> On 6/29/15 20:17, Johnny Eriksson wrote: >> >>> Javier Henderson wrote: >>> >>> Or XNS. On the other hand, people did have a nice career with >>>>> >>>> SNA...but they weren't trying to push packets over the >>>> >>>> LAT >>>> >>> >>> .daytime >>> Monday 29-Jun-2015 20:10:46 >>> >>> .pjob >>> Job 3 at ODEN User BYGG [10,335] TTY4 >>> >>> .where tty4 >>> LAT PC78(LATD for FreeBSD) TTY4 >>> >>> Is there anyting wrong with LAT? >>> >> >> err, its been awhile. Doesn't LAT have a 1 sec timeout that's not >> configurable? >> >> >>> -jav >>>> >>> >>> --Johnny >>> >>> From jfbeam at gmail.com Tue Jun 30 00:03:08 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 29 Jun 2015 20:03:08 -0400 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: <558E1F63.8010806@l-w.ca> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <558E1F63.8010806@l-w.ca> Message-ID: On Fri, 26 Jun 2015 23:58:27 -0400, William Astle wrote: > Like certain data centers attached to AS701 in Canada. Or their end customers all over the world. Of course, they're no different than most other carriers. At the time we moved into this office, TWC wasn't available [TWCBC] (but they at least understood IPv6; metro-e has since been installed here), TWTC craftily avoided answering the question (the answer was "no"), AT&T gave a similar "we can't be bothered" answer (supported, but we aren't "big enough" to be connected to that gear), Earthlink (ITC Deltacom) had no idea what it was (I'm sure engineers did, but sales and support didn't.) Not that the company cares. Last reading of the checkpoint config, there wasn't any v6 in it anywhere. Which is a bit surprising as one of those fw's is in Hong Kong! ** TWC (residential) DOES support IPv6 now. I'm an Earthlink subscriber so I get none of that; they've not provided any prefixes. From woody at pch.net Tue Jun 30 00:10:09 2015 From: woody at pch.net (Bill Woodcock) Date: Mon, 29 Jun 2015 17:10:09 -0700 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> Message-ID: <1CEC8A76-457D-4CA2-B0C9-A8D62496DBFD@pch.net> > On Apr 16, 2015, at 3:58 AM, David Hofstee wrote: > > Hi, > > I saw the following and thought it would be interesting to share. In case of a persistent DDoS an ASy can fallback to a small set of (more trustable) AS'es for their routing: > http://www.trustednetworksinitiative.nl/ It is indeed an interesting proposal, though not one that?s perhaps fully informed of the intricacies of commercial routing economics. Two things worthy of note for this audience, I think: First, I don?t know that anyone is expecting networks that do not consider themselves to be principally Dutch in nationality to participate. Second, this is a proposal of the Hague Security Delta, which is, in essence, a group of think-tanks. It is not a proposal of the Dutch government, nor of the Dutch Internet Service Providers. That is not intended to speak to the merit of the proposal, which has both good and bad points. Just to indicate that it is neither a home-grown ISP thing, nor something the Dutch government is mandating or advocating. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lyndon at orthanc.ca Tue Jun 30 00:50:43 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 29 Jun 2015 17:50:43 -0700 Subject: Thoughts On Cheap Chinese xDSL Testers Message-ID: <345FC405-DFFC-4F35-B5EB-74ED3A4966F9@orthanc.ca> I've been poking around looking for an inexpensive xDSL circuit tester to do some measurements on my home DSL line, in opposition to the telco. $2K+ is not in the budget, so I'm curious about the accuracy of the $300 Chinese units kicking around eBay (e.g. the ST332B). Anyone out there have experience with them? Are they even remotely close to accurate? --lyndon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Tue Jun 30 00:55:04 2015 From: randy at psg.com (Randy Bush) Date: Tue, 30 Jun 2015 09:55:04 +0900 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: <5918ED06-83E8-4B66-BC80-34361483AF59@karoshi.com> References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> <18012.1429214983@turing-police.cc.vt.edu> <20150416201356.GN67158@Vurt.local> <19328.1429216247@turing-police.cc.vt.edu> <55301E9B.4010601@bogus.com> <55380E9B.7080908@ripe.net> <5918ED06-83E8-4B66-BC80-34361483AF59@karoshi.com> Message-ID: hi lazarus, >>>>>> in any case the idea still seems silly. >>>>> not if you need to appear to be DOING SOMETHING!!! >>>> Of course there is that. But in order to be appear to be doing >>>> something one has to pledge to do BCP38 and various other things I >>>> would consider BCP. All little bits help. >>> except the big logo marketing has the implication that all the rest >>> of us unwashed networks are untrustable. this is not the >>> cooperative internet. >> You can apply to become a member in the initiative. > is this any different than the architecture Rodney Joffe built 20 > years ago? as the recent L(3)/TM global disaster made quite clear, it is not architecture; it's marketing literature. we can get that stuff printed at a local copy shop. randy From bmanning at karoshi.com Tue Jun 30 00:58:38 2015 From: bmanning at karoshi.com (manning) Date: Mon, 29 Jun 2015 17:58:38 -0700 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: <558F2AA3.1060608@satchell.net> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <558ED142.3010503@init7.net> <558F2AA3.1060608@satchell.net> Message-ID: <317F3D6D-DBF0-41F0-8A82-4A6CA03EEA5A@karoshi.com> actually, 1500 byte frames require a very different buffering technique, since you have so many in flight at a given time. if your old enough, this equates to the 53byte ATM cells when the data rates were in the Megabit range. manning bmanning at karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 27June2015Saturday, at 15:58, Stephen Satchell wrote: > On 06/27/2015 11:48 AM, manning wrote: >> This is kind of like asking when we will stop using ethernet framing >> (ethernet was designed for a 3Mbps transmission rate) yet we are >> deploying 100Gbps networks. Still stuck on that 1500byte limitation. >> When can we get rid of that? > > Speed has nothing to do with frame size. The 1500 byte limitation is more a function of the CRC algorithm. (Oh, the initial frame size was selected for 3-mbit Ethernet so that collision mitigation was reasonable.) > > Think about jumbo frames (9000 bytes) and their robust error detection. Research is being done in even larger frames, because the rule is that as your transmission rate increases, you should increase the frame size and use a FRC algorithm that detects all one-bit errors and most two-bit errors, at least. From robertg at garlic.com Tue Jun 30 01:23:11 2015 From: robertg at garlic.com (Robert Glover) Date: Mon, 29 Jun 2015 18:23:11 -0700 Subject: Thoughts On Cheap Chinese xDSL Testers Message-ID: The local ILEC (Verizon) use Colt 250+. ?They are pretty cool. ?They do not do layer 3 like the meter you referenced. I'm actually looking for a cost-effective meter that does ADSL+ / VDSL2 / e.SHDSL. ?it's easy to find one that does the first two, but not all three. -------- Original message -------- From: Lyndon Nerenberg Date: 06/29/2015 5:50 PM (GMT-08:00) To: North American Network Operators' Group Subject: Thoughts On Cheap Chinese xDSL Testers I've been poking around looking for an inexpensive xDSL circuit tester to do some measurements on my home DSL line, in opposition to the telco. $2K+ is not in the budget, so I'm curious about the accuracy of the $300 Chinese units kicking around eBay (e.g. the ST332B).? Anyone out there have experience with them?? Are they even remotely close to accurate? --lyndon ????? From randy at psg.com Tue Jun 30 01:29:46 2015 From: randy at psg.com (Randy Bush) Date: Tue, 30 Jun 2015 10:29:46 +0900 Subject: Trusted Networks Initiative: DDoS fallback set of AS'es In-Reply-To: References: <78C35D6C1A82D243B830523B4193CF5F9F3651C3E0@SBS1.blinker.local> <18012.1429214983@turing-police.cc.vt.edu> <20150416201356.GN67158@Vurt.local> <19328.1429216247@turing-police.cc.vt.edu> <55301E9B.4010601@bogus.com> <55380E9B.7080908@ripe.net> <5918ED06-83E8-4B66-BC80-34361483AF59@karoshi.com> Message-ID: > as the recent L(3)/TM global disaster made quite clear, it is not > architecture; it's marketing literature. and let's give a shoutout to jared and mike randy From joe at nethead.com Tue Jun 30 02:31:58 2015 From: joe at nethead.com (Joe Hamelin) Date: Mon, 29 Jun 2015 19:31:58 -0700 Subject: Thoughts On Cheap Chinese xDSL Testers In-Reply-To: References: Message-ID: The Westel A90-750045-07 Frontier branded DSL router has some amazing DSL status screens if you dig in the menu deep enough. I always kept one in the truck when I was doing some service work. Check the local Goodwill/Value Village. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Mon, Jun 29, 2015 at 6:23 PM, Robert Glover wrote: > The local ILEC (Verizon) use Colt 250+. They are pretty cool. They do > not do layer 3 like the meter you referenced. > I'm actually looking for a cost-effective meter that does ADSL+ / VDSL2 / > e.SHDSL. it's easy to find one that does the first two, but not all three. > > -------- Original message -------- > From: Lyndon Nerenberg > Date: 06/29/2015 5:50 PM (GMT-08:00) > To: North American Network Operators' Group > Subject: Thoughts On Cheap Chinese xDSL Testers > > I've been poking around looking for an inexpensive xDSL circuit tester to > do some measurements on my home DSL line, in opposition to the telco. $2K+ > is not in the budget, so I'm curious about the accuracy of the $300 Chinese > units kicking around eBay (e.g. the ST332B). Anyone out there have > experience with them? Are they even remotely close to accurate? > > --lyndon > > ????? > From faisal at snappytelecom.net Tue Jun 30 03:17:59 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 30 Jun 2015 03:17:59 +0000 (GMT) Subject: Thoughts On Cheap Chinese xDSL Testers In-Reply-To: <345FC405-DFFC-4F35-B5EB-74ED3A4966F9@orthanc.ca> References: <345FC405-DFFC-4F35-B5EB-74ED3A4966F9@orthanc.ca> Message-ID: <200334742.809871.1435634279894.JavaMail.zimbra@snappytelecom.net> We have some sunrise telecom test set's which we don't use any more. Will be willing the sell them, let me know off list. 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: "Lyndon Nerenberg" > To: "North American Network Operators' Group" > Sent: Monday, June 29, 2015 8:50:43 PM > Subject: Thoughts On Cheap Chinese xDSL Testers > > I've been poking around looking for an inexpensive xDSL circuit tester to do > some measurements on my home DSL line, in opposition to the telco. $2K+ is > not in the budget, so I'm curious about the accuracy of the $300 Chinese > units kicking around eBay (e.g. the ST332B). Anyone out there have > experience with them? Are they even remotely close to accurate? > > --lyndon > > From faisal at snappytelecom.net Tue Jun 30 03:24:02 2015 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 30 Jun 2015 03:24:02 +0000 (GMT) Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: <4163618F-C434-4B16-9A73-A9918B4A8713@puck.nether.net> References: <5591B620.2000407@he.net> <4163618F-C434-4B16-9A73-A9918B4A8713@puck.nether.net> Message-ID: <1961783072.809900.1435634642818.JavaMail.zimbra@snappytelecom.net> Hi Jared, This is neat !, for someone who recently started working the IRR's, I can tell you that it has been very difficult finding all info in one location. What you shared is pretty neat !, and I would like to clean up the records associated with our prefixes. Can you suggest some practical tips on getting older 'stale' records cleaned up from the different registries ? (i.e. records created for us by others, in a former time-frame). Regards Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Jared Mauch" > To: "Mike Leber" > Cc: nanog at nanog.org > Sent: Monday, June 29, 2015 5:51:18 PM > Subject: Re: NTT->HE earlier today (~10am EDT) > > Greetings, > > We are aware of this issue and as is usual we filter customers based on their > registered routes. This creates some unique challenges that we have been > speaking about publicly and privately with various groups. > > I have started the process (yay telco-speak) to fix this. > > It would be helpful if networks would take a look at what routes they have > registered in the various IRRs as well as if their AS-SETs expand out to > something quite large. We have seen many customers import objects that then > import their other upstream networks. > > We have found the IRR Explorer tool helpful to look at who has registered our > IP space and to police these registrations with the various IRRs out there. > http://irrexplorer.nlnog.net/ > > http://irrexplorer.nlnog.net/prefix/184.105.213.86 > > The stability of the routing ecosystem is something that I personally care a > lot about and have privately given Mike and others my cell number to allow > them to follow-up. As is often operators end up chasing problems after the > fact, and this appears to be no exception. *sigh* > > - Jared > > > On Jun 29, 2015, at 5:18 PM, Mike Leber wrote: > > > > NTT's customer Sofia Connect leaked our routes to NTT. NTT accepted these > > routes instead of properly filtering their customer announcements. As a > > network of non-trivial size, announcing over 75,000 customer routes which > > is nearly 15% of the IPv4 routing table, we'd expect the common courtesy > > of having our ASN included in their customer facing AS-PATH filters, as we > > extend this same courtesy to other networks of this size (such as AS2914). > > > > Mike. > > > > On 6/29/15 2:04 PM, Jim Popovitch wrote: > >> Hello, > >> > >> I haven't seen anything to explain this, so I'm asking a larger > >> audience. Did anyone notice any unusual NTT or HE routing this AM? > >> > >> Here's what I saw: > >> > >> > >> 2.|-- xe-0-1-0-17.r04.atlnga05.us.bb.gin.ntt.net 0.0% 20 0.8 > >> 0.7 0.6 0.9 0.1 > >> 3.|-- ae-2.r20.atlnga05.us.bb.gin.ntt.net 0.0% 20 4.6 > >> 6.2 0.5 13.6 4.8 > >> 4.|-- ae-4.r22.asbnva02.us.bb.gin.ntt.net 0.0% 20 15.3 > >> 15.0 13.9 15.8 0.7 > >> 5.|-- ae-4.r20.frnkge04.de.bb.gin.ntt.net 0.0% 20 127.3 > >> 106.7 98.5 127.3 11.1 > >> 6.|-- ae-2.r02.frnkge04.de.bb.gin.ntt.net 0.0% 20 126.8 > >> 126.0 125.7 126.8 0.2 > >> 7.|-- ae-1.r00.sofibu01.bg.bb.gin.ntt.net 0.0% 20 131.1 > >> 130.0 128.7 131.4 1.2 > >> 8.|-- 83.217.227.42 80.0% 20 148.5 > >> 146.0 144.2 148.5 2.0 > >> 9.|-- ip-48-93.sofia-connect.net 90.0% 20 184.5 > >> 163.8 143.1 184.5 29.3 > >> 10.|-- ??? 100.0 20 0.0 > >> 0.0 0.0 0.0 0.0 > >> 11.|-- 10ge5-4.core1.vie1.he.net 75.0% 20 160.7 > >> 150.4 143.9 160.7 6.3 > >> 12.|-- 10ge1-4.core1.prg1.he.net 80.0% 20 158.4 > >> 159.5 157.9 161.1 1.6 > >> 13.|-- 10ge10-12.core1.fra1.he.net 75.0% 20 154.5 > >> 159.2 145.9 174.4 10.7 > >> 14.|-- 100ge5-2.core1.par2.he.net 75.0% 20 187.9 > >> 172.9 157.1 187.9 11.1 > >> 15.|-- 100ge7-1.core1.nyc4.he.net 78.9% 19 147.2 > >> 146.2 144.6 147.5 1.4 > >> 16.|-- 100ge7-2.core1.chi1.he.net 78.9% 19 165.6 > >> 172.1 165.6 183.5 8.0 > >> 17.|-- 10ge15-2.core1.den1.he.net 89.5% 19 201.3 > >> 204.7 201.3 208.1 4.8 > >> > >> > >> -Jim P. > > From damien at supremebytes.com Tue Jun 30 03:33:26 2015 From: damien at supremebytes.com (Damien Burke) Date: Tue, 30 Jun 2015 03:33:26 +0000 Subject: Charter and IPV6? In-Reply-To: References: Message-ID: <2FD50E6D13594B4C93B743BFCF9F52842FCF0C9F@EXCH01.sb.local> Looks like charter just got a /28 of IPv6 http://whois.arin.net/rest/net/NET6-2600-2300-1/pft -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matt Love Sent: Monday, June 29, 2015 2:39 PM To: Robert Glover Cc: nanog Subject: Re: Charter and IPV6? I just asked for it about a month ago in my area, they said the beta is just about to be over. On Mon, Jun 29, 2015 at 5:23 PM, Robert Glover wrote: > As of 3mos ago, no :( > > > > -------- Original message -------- > From: Roy > Date: 06/29/2015 2:15 PM (GMT-08:00) > To: nanog > Subject: Charter and IPV6? > > > Has Charter rolled out IPV6 yet? I have both fiber and cable > connections to Charter but I stopped asking them months ago. > > Roy > ??????????? From jfbeam at gmail.com Tue Jun 30 03:53:09 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 29 Jun 2015 23:53:09 -0400 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> Message-ID: On Sat, 27 Jun 2015 08:35:34 -0400, Rafael Possamai wrote: > How long do you think it will take to completely get rid of IPv4? Or is > it even going to happen at all? Things like IPX and token-ring are still around. IPv4 isn't going anywhere for decades. (if ever) Mostly because there are things that will *never* run IPv6 that aren't going to get replaced just because of IPv6. (it's a given most of those things don't live on the internet.) From hank at efes.iucc.ac.il Tue Jun 30 03:54:46 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 30 Jun 2015 06:54:46 +0300 Subject: NTT->HE earlier today (~10am EDT) Message-ID: Kudos Mike for saying it very clearly! Hank On Jun 30, 2015 12:18 AM, Mike Leber wrote: > > NTT's customer Sofia Connect leaked our routes to NTT.? NTT accepted > these routes instead of properly filtering their customer > announcements.? As a network of non-trivial size, announcing over 75,000 > customer routes which is nearly 15% of the IPv4 routing table, we'd > expect the common courtesy of having our ASN included in their customer > facing AS-PATH filters, as we extend this same courtesy to other > networks of this size (such as AS2914). > > Mike. > > On 6/29/15 2:04 PM, Jim Popovitch wrote: > > Hello, > > > > I haven't seen anything to explain this, so I'm asking a larger > > audience.? Did anyone notice any unusual NTT or HE routing this AM? > > > > Here's what I saw: > > > > > >??? 2.|-- xe-0-1-0-17.r04.atlnga05.us.bb.gin.ntt.net? 0.0%??? 20??? 0.8 > > 0.7?? 0.6?? 0.9?? 0.1 > >??? 3.|-- ae-2.r20.atlnga05.us.bb.gin.ntt.net???????? 0.0%??? 20??? 4.6 > > 6.2?? 0.5? 13.6?? 4.8 > >??? 4.|-- ae-4.r22.asbnva02.us.bb.gin.ntt.net???????? 0.0%??? 20?? 15.3 > > 15.0 13.9 15.8 0.7 > >??? 5.|-- ae-4.r20.frnkge04.de.bb.gin.ntt.net???????? 0.0%??? 20? 127.3 > > 106.7? 98.5 127.3? 11.1 > >??? 6.|-- ae-2.r02.frnkge04.de.bb.gin.ntt.net???????? 0.0%??? 20? 126.8 > > 126.0 125.7 126.8?? 0.2 > >??? 7.|-- ae-1.r00.sofibu01.bg.bb.gin.ntt.net???????? 0.0%??? 20? 131.1 > > 130.0 128.7 131.4?? 1.2 > >??? 8.|-- 83.217.227.42????????????????????????????? 80.0%??? 20? 148.5 > > 146.0 144.2 148.5?? 2.0 > >??? 9.|-- ip-48-93.sofia-connect.net???????????????? 90.0%??? 20? 184.5 > > 163.8 143.1 184.5? 29.3 > >?? 10.|-- ?????????????????????????????????????????? 100.0??? 20??? 0.0 > > 0.0?? 0.0?? 0.0?? 0.0 > >?? 11.|-- 10ge5-4.core1.vie1.he.net????????????????? 75.0%??? 20? 160.7 > > 150.4 143.9 160.7?? 6.3 > >?? 12.|-- 10ge1-4.core1.prg1.he.net????????????????? 80.0%??? 20? 158.4 > > 159.5 157.9 161.1?? 1.6 > >?? 13.|-- 10ge10-12.core1.fra1.he.net??????????????? 75.0%??? 20? 154.5 > > 159.2 145.9 174.4? 10.7 > >?? 14.|-- 100ge5-2.core1.par2.he.net???????????????? 75.0%??? 20? 187.9 > > 172.9 157.1 187.9? 11.1 > >?? 15.|-- 100ge7-1.core1.nyc4.he.net???????????????? 78.9%??? 19? 147.2 > > 146.2 144.6 147.5?? 1.4 > >?? 16.|-- 100ge7-2.core1.chi1.he.net???????????????? 78.9%??? 19? 165.6 > > 172.1 165.6 183.5?? 8.0 > >?? 17.|-- 10ge15-2.core1.den1.he.net???????????????? 89.5%??? 19? 201.3 > > 204.7 201.3 208.1?? 4.8 > > > > > > -Jim P. From jfbeam at gmail.com Tue Jun 30 04:03:09 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 30 Jun 2015 00:03:09 -0400 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> Message-ID: On Sat, 27 Jun 2015 13:23:27 -0400, Lyndon Nerenberg wrote: > IPX ruled the roost, very popularly, for a little while. How long did > it take to die? It isn't dead yet, but it's certainly on the endangered list. > Why did it die? The death of Novell NetWare (and their transitioned to IP) killed it the enterprise. Games adopting IP for network play killed it in the home. Ultimately, it sucks as a WAN protocol, so the internet was built using this new fangled IP thing. From jfbeam at gmail.com Tue Jun 30 04:18:10 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 30 Jun 2015 00:18:10 -0400 Subject: How long will it take to completely get rid of IPv4 or will it happen at all? In-Reply-To: References: Message-ID: On Sat, 27 Jun 2015 13:58:24 -0400, Alexander Maassen wrote: > Before that will happen. Isp's will first try cgnat and the alikes. They already are. And, depending on the network, have for eons. Have you checked the IP used by your cellphone? (the last few times I bothered to look... somewhere in 29/8. I thought that was really funny.) > Why? Simple: Money. It's cheaper to install a $100k NAT appliance (or several) than it is to replace 16mil CPE devices, plus all the engineering, testing, and customer support "training" (read: BS scripts to follow.) AND, your customers aren't having any trouble getting where they need to go. Sure, there will be the forward thinkers pushing for IPv6, but not because there's some IPv6 only place they need to go (or be.) From Grzegorz at Janoszka.pl Tue Jun 30 08:27:21 2015 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Tue, 30 Jun 2015 10:27:21 +0200 Subject: Route leak in Bangladesh Message-ID: <559252E9.6030703@Janoszka.pl> We have just received alert from bgpmon that AS58587 Fiber @ Home Limited has hijacked most of our (AS43996) prefixes and Hurricane Electric gladly accepted them. Anybody see their prefixes hijacked as well? -- Grzegorz Janoszka From hank at efes.iucc.ac.il Tue Jun 30 08:51:23 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 30 Jun 2015 11:51:23 +0300 Subject: Route leak in Bangladesh In-Reply-To: <559252E9.6030703@Janoszka.pl> Message-ID: <5.1.1.6.2.20150630114745.003a2820@efes.iucc.ac.il> At 10:27 30/06/2015 +0200, Grzegorz Janoszka wrote: >We have just received alert from bgpmon that AS58587 Fiber @ Home Limited >has hijacked most of our (AS43996) prefixes and Hurricane Electric gladly >accepted them. > >Anybody see their prefixes hijacked as well? Welcome to the party :-) Not only you. -Hank >-- >Grzegorz Janoszka From randy at psg.com Tue Jun 30 09:03:58 2015 From: randy at psg.com (Randy Bush) Date: Tue, 30 Jun 2015 18:03:58 +0900 Subject: Route leak in Bangladesh In-Reply-To: <5.1.1.6.2.20150630114745.003a2820@efes.iucc.ac.il> References: <559252E9.6030703@Janoszka.pl> <5.1.1.6.2.20150630114745.003a2820@efes.iucc.ac.il> Message-ID: be nice if some technical details were included From ops.lists at gmail.com Tue Jun 30 09:12:20 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 30 Jun 2015 14:42:20 +0530 Subject: Route leak in Bangladesh In-Reply-To: <559252E9.6030703@Janoszka.pl> References: <559252E9.6030703@Janoszka.pl> Message-ID: I have sent this to a contact at another Bangladeshi ISP that should be able to reach the right person for this ASAP. > On 30-Jun-2015, at 1:57 pm, Grzegorz Janoszka wrote: > > We have just received alert from bgpmon that AS58587 Fiber @ Home Limited has hijacked most of our (AS43996) prefixes and Hurricane Electric gladly accepted them. > > Anybody see their prefixes hijacked as well? From hank at efes.iucc.ac.il Tue Jun 30 09:13:27 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 30 Jun 2015 12:13:27 +0300 Subject: Route leak in Bangladesh In-Reply-To: References: <5.1.1.6.2.20150630114745.003a2820@efes.iucc.ac.il> <559252E9.6030703@Janoszka.pl> <5.1.1.6.2.20150630114745.003a2820@efes.iucc.ac.il> Message-ID: <5.1.1.6.2.20150630121021.05060fd0@efes.iucc.ac.il> At 18:03 30/06/2015 +0900, Randy Bush wrote: >be nice if some technical details were included Your prefix: xx.104.150.0/24: Prefix Description: xxxx Update time: 2015-06-30 07:39 (UTC) Detected by #peers: 8 Detected prefix: xx.104.150.0/24 Announced by: AS58587 (FIBERATHOME-BD Fiber @ Home Limited,BD) Upstream AS: AS6939 (HURRICANE - Hurricane Electric, Inc.,US) ASpath: 25152 6939 58587 and another: On Tuesday June 30th 2015 at 7:37 UTC we detected a Origin AS Change event for your prefix (23.44.244.0/22 Akamai) The detected prefix: 23.44.244.0/22, was announced by AS58587 (FIBERATHOME-BD Fiber @ Home Limited,BD) Alert description: Origin AS Change Detected Prefix: 23.44.244.0/22 Detected Origin AS: 58587 Expected Origin AS: 1680 Same Aspath of 6939 58587 -Hank From randy at psg.com Tue Jun 30 09:19:23 2015 From: randy at psg.com (Randy Bush) Date: Tue, 30 Jun 2015 18:19:23 +0900 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: <5591B620.2000407@he.net> <559252E9.6030703@Janoszka.pl> References: <5591B620.2000407@he.net> Message-ID: > NTT's customer Sofia Connect leaked our routes to NTT. NTT accepted > these routes instead of properly filtering their customer > announcements. As a network of non-trivial size, announcing over > 75,000 customer routes which is nearly 15% of the IPv4 routing table, > we'd expect the common courtesy of having our ASN included in their > customer facing AS-PATH filters, as we extend this same courtesy to > other networks of this size (such as AS2914). sometimes the goddesses have a sense of humor At Tue, 30 Jun 2015 10:27:21 +0200, Grzegorz Janoszka wrote: > We have just received alert from bgpmon that AS58587 Fiber @ Home > Limited has hijacked most of our (AS43996) prefixes and Hurricane > Electric gladly accepted them. randy From maz at iij.ad.jp Tue Jun 30 10:26:25 2015 From: maz at iij.ad.jp (Matsuzaki Yoshinobu) Date: Tue, 30 Jun 2015 19:26:25 +0900 (JST) Subject: Route leak in Bangladesh In-Reply-To: <559252E9.6030703@Janoszka.pl> References: <559252E9.6030703@Janoszka.pl> Message-ID: <20150630.192625.498571400847043127.maz@iij.ad.jp> A friend in AS58587 confirmed that this was caused by a configuration error - it seems like related to redistribution, and they already fixed that. ----- Matsuzaki Yoshinobu - IIJ/AS2497 INOC-DBA: 2497*629 In message <559252E9.6030703 at Janoszka.pl> Date: Tue, 30 Jun 2015 10:27:21 +0200 Grzegorz Janoszka wrote > > We have just received alert from bgpmon that AS58587 Fiber @ > Home Limited has hijacked most of our (AS43996) prefixes and > Hurricane Electric gladly accepted them. > > Anybody see their prefixes hijacked as well? > > -- > Grzegorz Janoszka From randy at psg.com Tue Jun 30 10:56:51 2015 From: randy at psg.com (Randy Bush) Date: Tue, 30 Jun 2015 19:56:51 +0900 Subject: Route leak in Bangladesh In-Reply-To: <20150630.192625.498571400847043127.maz@iij.ad.jp> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> Message-ID: > A friend in AS58587 confirmed that this was caused by a configuration > error - it seems like related to redistribution, and they already > fixed that. 7007 all over again. do not redistribute bgp into igp. do not redistribute igp into bgp. randy From jared at puck.Nether.net Tue Jun 30 12:03:30 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Tue, 30 Jun 2015 08:03:30 -0400 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: <1961783072.809900.1435634642818.JavaMail.zimbra@snappytelecom.net> References: <5591B620.2000407@he.net> <4163618F-C434-4B16-9A73-A9918B4A8713@puck.nether.net> <1961783072.809900.1435634642818.JavaMail.zimbra@snappytelecom.net> Message-ID: <20150630120329.GB28600@puck.nether.net> On Tue, Jun 30, 2015 at 03:24:02AM +0000, Faisal Imtiaz wrote: > Hi Jared, > > This is neat !, for someone who recently started working the IRR's, I can tell you that it has been very difficult finding all info in one location. > > What you shared is pretty neat !, and I would like to clean up the records associated with our prefixes. > > Can you suggest some practical tips on getting older 'stale' records cleaned up from the different registries ? > (i.e. records created for us by others, in a former time-frame). I've not found a great method as it usually involves a lot of either happy or grumpy sounding emails to addresses that may bounce quite a lot. We have had good luck getting RADB to clean out older entries. I recently helped someone announce some IP blocks from the NTT network and there are many crusty IRR objects that seem impossible to clean up because the IRR is feels like first-in-never-out input. http://irrexplorer.nlnog.net/prefix/203.10.78.0/24 - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From maz at iij.ad.jp Tue Jun 30 13:22:38 2015 From: maz at iij.ad.jp (Matsuzaki Yoshinobu) Date: Tue, 30 Jun 2015 22:22:38 +0900 (JST) Subject: Route leak in Bangladesh In-Reply-To: References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> Message-ID: <20150630.222238.1512981023241287808.maz@iij.ad.jp> Randy Bush wrote >> A friend in AS58587 confirmed that this was caused by a configuration >> error - it seems like related to redistribution, and they already >> fixed that. > > 7007 all over again. do not redistribute bgp into igp. do not > redistribute igp into bgp. I also suggested them to implement BGP community based route filtering in their outbound policy. Any other suggestions or thoughts to prevent such incidents in general? ----- Matsuzaki Yoshinobu - IIJ/AS2497 INOC-DBA: 2497*629 From mark.tinka at seacom.mu Tue Jun 30 13:29:57 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 30 Jun 2015 15:29:57 +0200 Subject: Route leak in Bangladesh In-Reply-To: <20150630.222238.1512981023241287808.maz@iij.ad.jp> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> Message-ID: <559299D5.4010700@seacom.mu> On 30/Jun/15 15:22, Matsuzaki Yoshinobu wrote: > I also suggested them to implement BGP community based route filtering > in their outbound policy. Any other suggestions or thoughts to > prevent such incidents in general? - Get your downstreams to create route objects before you turn them up. - Get your provisioning teams to validate the prefixes being provided by your downstreams. - Use both prefix- and AS_PATH-based filters for your downstreams. - Use BGP communities (as you've stated). - No exceptions. Mark. From job at instituut.net Tue Jun 30 13:41:18 2015 From: job at instituut.net (Job Snijders) Date: Tue, 30 Jun 2015 15:41:18 +0200 Subject: Route leak in Bangladesh In-Reply-To: <20150630.222238.1512981023241287808.maz@iij.ad.jp> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> Message-ID: <20150630134118.GU95870@Vurt.local> On Tue, Jun 30, 2015 at 10:22:38PM +0900, Matsuzaki Yoshinobu wrote: > Randy Bush wrote > >> A friend in AS58587 confirmed that this was caused by a configuration > >> error - it seems like related to redistribution, and they already > >> fixed that. > > > > 7007 all over again. do not redistribute bgp into igp. do not > > redistribute igp into bgp. > > I also suggested them to implement BGP community based route filtering > in their outbound policy. Any other suggestions or thoughts to > prevent such incidents in general? In addition to the BGP community scheme, outbound as-path filters could help. Most network's list of transit providers is fairly static, it would be easiy with as-path filters to prevent announcing upstream routes to other upstreams or peering partners. Kind regards, Job From jabley at hopcount.ca Tue Jun 30 13:44:12 2015 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 30 Jun 2015 09:44:12 -0400 Subject: Route leak in Bangladesh In-Reply-To: <20150630134118.GU95870@Vurt.local> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630134118.GU95870@Vurt.local> Message-ID: On 30 Jun 2015, at 9:41, Job Snijders wrote: > In addition to the BGP community scheme, outbound as-path filters > could > help. I agree, but possibly not in the case of a redistribution loop. (We don't know that's what happened, exactly, but I thought it was worth mentioning.) Joe From job at instituut.net Tue Jun 30 14:24:43 2015 From: job at instituut.net (Job Snijders) Date: Tue, 30 Jun 2015 16:24:43 +0200 Subject: Route leak in Bangladesh In-Reply-To: References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630134118.GU95870@Vurt.local> Message-ID: <20150630142443.GV95870@Vurt.local> On Tue, Jun 30, 2015 at 09:44:12AM -0400, Joe Abley wrote: > On 30 Jun 2015, at 9:41, Job Snijders wrote: > >In addition to the BGP community scheme, outbound as-path filters could > >help. > > I agree, but possibly not in the case of a redistribution loop. > > (We don't know that's what happened, exactly, but I thought it was worth > mentioning.) Joe, you are right. In this specific situation, for a small to medium sized network, it might be prudent to apply an outbound prefix-filter on all transit & peering sessions and thus only allowing prefixes which actually belong to downstream customers and the network itself. One could generate that prefix-list based on the network's AS-SET. I wouldn't deploy /only/ outbound prefix-filters. This method should be viewed as complementary to other methods such as the already mentioned a BGP community scheme. Kind regards, Job From streiner at cluebyfour.org Tue Jun 30 14:28:13 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 30 Jun 2015 10:28:13 -0400 (EDT) Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> Message-ID: On Tue, 30 Jun 2015, Ricky Beam wrote: > The death of Novell NetWare (and their transitioned to IP) killed it the > enterprise. Games adopting IP for network play killed it in the home. > > Ultimately, it sucks as a WAN protocol, so the internet was built using this > new fangled IP thing. There are still isolated pockets of devices out there speaking IPX, DECnet, Appletalk, etc, but either they're not connected to the 'Internet', or their traffic passes through other devices that encapsulate and de-encapsulate it in IP to allow it to be transported. jms From mark.tinka at seacom.mu Tue Jun 30 14:38:48 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 30 Jun 2015 16:38:48 +0200 Subject: Route leak in Bangladesh In-Reply-To: <20150630142443.GV95870@Vurt.local> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630134118.GU95870@Vurt.local> <20150630142443.GV95870@Vurt.local> Message-ID: <5592A9F8.9090304@seacom.mu> On 30/Jun/15 16:24, Job Snijders wrote: > In this specific situation, for a small to medium sized network, it > might be prudent to apply an outbound prefix-filter on all transit & > peering sessions and thus only allowing prefixes which actually belong > to downstream customers and the network itself. I say that regardless of size, deploy the ultimate solution as the network is only bound to grow. It's harder for folk to undo old habits as they become more entrenched. Mark. From streiner at cluebyfour.org Tue Jun 30 14:39:56 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 30 Jun 2015 10:39:56 -0400 (EDT) Subject: Route leak in Bangladesh In-Reply-To: <20150630.222238.1512981023241287808.maz@iij.ad.jp> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> Message-ID: On Tue, 30 Jun 2015, Matsuzaki Yoshinobu wrote: > Randy Bush wrote >>> A friend in AS58587 confirmed that this was caused by a configuration >>> error - it seems like related to redistribution, and they already >>> fixed that. >> >> 7007 all over again. do not redistribute bgp into igp. do not >> redistribute igp into bgp. > > I also suggested them to implement BGP community based route filtering > in their outbound policy. Any other suggestions or thoughts to > prevent such incidents in general? At a minimum, AS-PATH filtering of outgoing routes to just your ASN(s) and your downstream customer ASNs. Whether this is done manually, built using AS-SETs from your route registry of choice, or through some other automated means is another story. jms From sandy at tislabs.com Tue Jun 30 14:44:00 2015 From: sandy at tislabs.com (Sandra Murphy) Date: Tue, 30 Jun 2015 10:44:00 -0400 Subject: Route leak in Bangladesh In-Reply-To: <20150630134118.GU95870@Vurt.local> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630134118.GU95870@Vurt.local> Message-ID: <77F4C35B-B7BC-43CF-9C62-45B541D2ED26@tislabs.com> On Jun 30, 2015, at 9:41 AM, Job Snijders wrote: > > In addition to the BGP community scheme, outbound as-path filters could > help. Most network's list of transit providers is fairly static, it > would be easiy with as-path filters to prevent announcing upstream > routes to other upstreams or peering partners. Except that this was not a route leak per se. The announced routes AS_PATH shows them as originated by the offending AS, not *propagated* by the offending AS. So the outbound AS_PATH did not retain the upstream portion of the path. --Sandy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From job at instituut.net Tue Jun 30 14:49:10 2015 From: job at instituut.net (Job Snijders) Date: Tue, 30 Jun 2015 16:49:10 +0200 Subject: Route leak in Bangladesh In-Reply-To: <5592A9F8.9090304@seacom.mu> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630134118.GU95870@Vurt.local> <20150630142443.GV95870@Vurt.local> <5592A9F8.9090304@seacom.mu> Message-ID: <20150630144910.GX95870@Vurt.local> On Tue, Jun 30, 2015 at 04:38:48PM +0200, Mark Tinka wrote: > On 30/Jun/15 16:24, Job Snijders wrote: > > In this specific situation, for a small to medium sized network, it > > might be prudent to apply an outbound prefix-filter on all transit & > > peering sessions and thus only allowing prefixes which actually belong > > to downstream customers and the network itself. > > I say that regardless of size, deploy the ultimate solution as the > network is only bound to grow. > > It's harder for folk to undo old habits as they become more > entrenched. Nothing is ever regardless of anything :-) I would forsee issues if i'd try to add an eleven megabyte prefix-list on all devices in the network. Kind regards, Job From sandy at tislabs.com Tue Jun 30 14:53:45 2015 From: sandy at tislabs.com (Sandra Murphy) Date: Tue, 30 Jun 2015 10:53:45 -0400 Subject: Route leak in Bangladesh In-Reply-To: References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> Message-ID: On Jun 30, 2015, at 10:39 AM, "Justin M. Streiner" wrote: > On Tue, 30 Jun 2015, Matsuzaki Yoshinobu wrote: > >> Randy Bush wrote >>>> A friend in AS58587 confirmed that this was caused by a configuration >>>> error - it seems like related to redistribution, and they already >>>> fixed that. >>> >>> 7007 all over again. do not redistribute bgp into igp. do not >>> redistribute igp into bgp. >> >> I also suggested them to implement BGP community based route filtering >> in their outbound policy. Any other suggestions or thoughts to >> prevent such incidents in general? > > At a minimum, AS-PATH filtering of outgoing routes to just your ASN(s) and your downstream customer ASNs. Whether this is done manually, built using AS-SETs from your route registry of choice, or through some other > automated means is another story. > That sort of AS_PATH filtering would not have helped in this case. The AS originated the routes, it did not propagate an upstream route. So an AS_PATH filter to just its own AS would have passed these routes. You would need origin validation on your outbound routes. Job suggested prefix filters on outbound routes. (If you are doing prefix filters on your inbound customer links, it might be excessive caution to also prefix filter customers prefixes on outbound links? Or is it: you can never be too careful, belt-and-suspenders, measure twice, etc?) --Sandy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nick at foobar.org Tue Jun 30 15:04:35 2015 From: nick at foobar.org (Nick Hilliard) Date: Tue, 30 Jun 2015 16:04:35 +0100 Subject: Route leak in Bangladesh In-Reply-To: <559299D5.4010700@seacom.mu> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <559299D5.4010700@seacom.mu> Message-ID: <5592B003.7030706@foobar.org> On 30/06/2015 14:29, Mark Tinka wrote: > - Get your downstreams to create route objects before you turn them up. > - Get your provisioning teams to validate the prefixes being > provided by your downstreams. > - Use both prefix- and AS_PATH-based filters for your downstreams. > - Use BGP communities (as you've stated). > - No exceptions. plus: - fully automate ingress prefix management - use maxprefixes with manual reenable on all ebgp sessions I've been caught with fully automated IRR based per-session prefix filtering where the customer put the IXP AS macro into their AS macro. When the customer did a 7007 on this, we accepted everything that they announced back to us, oy vey. So you need both. Nick From job at instituut.net Tue Jun 30 15:09:29 2015 From: job at instituut.net (Job Snijders) Date: Tue, 30 Jun 2015 17:09:29 +0200 Subject: Route leak in Bangladesh In-Reply-To: References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> Message-ID: <20150630150929.GZ95870@Vurt.local> On Tue, Jun 30, 2015 at 10:53:45AM -0400, Sandra Murphy wrote: > That sort of AS_PATH filtering would not have helped in this case. > The AS originated the routes, it did not propagate an upstream route. > > So an AS_PATH filter to just its own AS would have passed these > routes. > > You would need origin validation on your outbound routes. Job > suggested prefix filters on outbound routes. (If you are doing prefix > filters on your inbound customer links, it might be excessive caution > to also prefix filter customers prefixes on outbound links? Or is it: > you can never be too careful, belt-and-suspenders, measure twice, > etc?) I wouldn't consider it to be excessive caution to bring more safeguards to the game, you never know when diarrhea will strike. If you were the network causing a leak of this type, prefix filters on inbound facing your customers might not have prevented this. If you are a network providing transit to the leak originator mentioned in the above paragraph, I believe a prefix based filter could have made a big difference. Kind regards, Job From streiner at cluebyfour.org Tue Jun 30 15:28:15 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 30 Jun 2015 11:28:15 -0400 (EDT) Subject: Route leak in Bangladesh In-Reply-To: References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> Message-ID: On Tue, 30 Jun 2015, Sandra Murphy wrote: > On Jun 30, 2015, at 10:39 AM, "Justin M. Streiner" wrote: >> At a minimum, AS-PATH filtering of outgoing routes to just your ASN(s) >> and your downstream customer ASNs. Whether this is done manually, >> built using AS-SETs from your route registry of choice, or through some >> other automated means is another story. >> > > That sort of AS_PATH filtering would not have helped in this case. The > AS originated the routes, it did not propagate an upstream route. I didn't realise they offending AS was originating those routes, rather than propagating the existing ones. > So an AS_PATH filter to just its own AS would have passed these routes. That's why I suggested it as a minimum precaution. When I worked in the service provider world, we did prefix + AS-PATH filtering + max-prefix, which was pretty effective in keeping BGP-borne madness down to a dull roar. Would that stop everything? No, but it did help a lot. I still work in a BGP-speaking organization - just not one that has downstream BGP-speaking customers at this point. > You would need origin validation on your outbound routes. Job > suggested prefix filters on outbound routes. (If you are doing prefix > filters on your inbound customer links, it might be excessive caution to > also prefix filter customers prefixes on outbound links? Or is it: you > can never be too careful, belt-and-suspenders, measure twice, etc?) It depends on how much automation can be done to update the necessary filters and AS-PATH ACLs, and how much you trust both the automation method and the data source for those filters. jms From graham at apolix.co.za Tue Jun 30 15:45:32 2015 From: graham at apolix.co.za (Graham Beneke) Date: Tue, 30 Jun 2015 17:45:32 +0200 Subject: Route leak in Bangladesh In-Reply-To: <20150630150929.GZ95870@Vurt.local> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> <20150630.222238.1512981023241287808.maz@iij.ad.jp> <20150630150929.GZ95870@Vurt.local> Message-ID: <5592B99C.90708@apolix.co.za> On 30/06/2015 17:09, Job Snijders wrote: > If you were the network causing a leak of this type, prefix filters on > inbound facing your customers might not have prevented this. > > If you are a network providing transit to the leak originator mentioned > in the above paragraph, I believe a prefix based filter could have made > a big difference. We seem to be assuming that this leak occurred within the context of a customer-provider BGP relationship. But what if this is not the case? What if this was a peering session - perhaps via a route server at an exchange point. max-pref on a session with a route server is an extremely blunt (and potentially ineffective) tool for the job. In some regions the use to route servers and the lack of clue about anything BGP beyond one session to the route server (and one session to transit) is scary. We place our faith in the IXP operator, that they know best, while there may be no evidence that they do... ;-) -- Graham Beneke From andree+nanog at toonk.nl Tue Jun 30 15:46:51 2015 From: andree+nanog at toonk.nl (Andree Toonk) Date: Tue, 30 Jun 2015 08:46:51 -0700 Subject: Route leak in Bangladesh In-Reply-To: <20150630.192625.498571400847043127.maz@iij.ad.jp> References: <559252E9.6030703@Janoszka.pl> <20150630.192625.498571400847043127.maz@iij.ad.jp> Message-ID: <5592B9EB.10902@toonk.nl> Some more data from BGPmon.net: This affected close to 28,000 prefixes from 4,477 unique Autonomous systems. The hijacks were originated by AS58587 and propagated via AS45796 (15,002 prefixes) and AS6939 (25,841). The AS45796 paths were only seen via one of our peers, while the AS6939 path had a more significant visibility. The event started at 07:37 UTC and lasted for a few minutes. Cheers Andree .-- My secret spy satellite informs me that at 2015-06-30 3:26 AM Matsuzaki Yoshinobu wrote: > A friend in AS58587 confirmed that this was caused by a configuration > error - it seems like related to redistribution, and they already > fixed that. > > ----- > Matsuzaki Yoshinobu > - IIJ/AS2497 INOC-DBA: 2497*629 > > In message <559252E9.6030703 at Janoszka.pl> > Date: Tue, 30 Jun 2015 10:27:21 +0200 > Grzegorz Janoszka wrote >> We have just received alert from bgpmon that AS58587 Fiber @ >> Home Limited has hijacked most of our (AS43996) prefixes and >> Hurricane Electric gladly accepted them. >> >> Anybody see their prefixes hijacked as well? >> >> -- >> Grzegorz Janoszka > From list at satchell.net Tue Jun 30 17:03:01 2015 From: list at satchell.net (Stephen Satchell) Date: Tue, 30 Jun 2015 10:03:01 -0700 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> Message-ID: <5592CBC5.6060209@satchell.net> On 06/30/2015 07:28 AM, Justin M. Streiner wrote: > There are still isolated pockets of devices out there speaking IPX, > DECnet, Appletalk, etc, but either they're not connected to the > 'Internet', or their traffic passes through other devices that > encapsulate and de-encapsulate it in IP to allow it to be transported. For the young (and the young at heart) those "other devices" were known as "bridges" back in the day. From owen at delong.com Tue Jun 30 17:24:34 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 30 Jun 2015 10:24:34 -0700 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: <5592CBC5.6060209@satchell.net> References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> <5592CBC5.6060209@satchell.net> Message-ID: <9B2B3003-0749-48A4-B49D-FA46C928BA41@delong.com> > On Jun 30, 2015, at 10:03 , Stephen Satchell wrote: > > On 06/30/2015 07:28 AM, Justin M. Streiner wrote: >> There are still isolated pockets of devices out there speaking IPX, >> DECnet, Appletalk, etc, but either they're not connected to the >> 'Internet', or their traffic passes through other devices that >> encapsulate and de-encapsulate it in IP to allow it to be transported. > > For the young (and the young at heart) those "other devices" were known as "bridges" back in the day. Not all of them? Some of them were ?gateways? and occasionally you?d even encounter a ?proxy?. Owen From infinityape at gmail.com Tue Jun 30 18:37:55 2015 From: infinityape at gmail.com (Dennis B) Date: Tue, 30 Jun 2015 14:37:55 -0400 Subject: GRE performance over the Internet - DDoS cloud mitigation In-Reply-To: References: Message-ID: Depends on what performance considerations you are trying to address, technically. The question is how can we guarantee the GRE/BGP performance (control traffic) during the time between detection and mitigation? GRE decapsulation? IE: Hardware vs Software? Routing of the Protocol over the internet? IE: If the inbound path is saturated, what is the availability of the GRE tunnel? User-experience with GRE packet overhead? IE: TCP Fragmentation causing PMTUD messages for reassembly? I've worked at Prolexic for 7 years and now Akamai for 1.4 yrs, post acquisition. Immediately, I can think of multiple scenarios' (3) that come to mind on how to solve any one of these categories. Would you like to learn more? lol DB On Mon, Jun 8, 2015 at 7:25 AM, Roland Dobbins wrote: > > On 8 Jun 2015, at 17:57, Ramy Hashish wrote: > > a BGP session has to be established over a GRE tunnel over the internet >> between the ISP/NSP/DC and the cloud scrubbing center, >> > > This is incorrect. > > In most cloud overlay DDoS mitigation scenarios (e.g., end-customer > obtains service from an MSSP which isn't providing them with transit), a) > there is no BGP relationship whatsoever between the end-customer and the > MSSP, and b) the GRE tunnel is used strictly for re-injection of clean > traffic (i.e., post-mitigation) to the end-customer. > > In some scenarios, DNS is also used in place of/in addition to BGP-based > diversion. > > But GRE is used for re-injection only. > > ----------------------------------- > Roland Dobbins > From rdobbins at arbor.net Tue Jun 30 18:45:05 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 01 Jul 2015 01:45:05 +0700 Subject: GRE performance over the Internet - DDoS cloud mitigation In-Reply-To: References: Message-ID: On 1 Jul 2015, at 1:37, Dennis B wrote: > Would you like to learn more? lol I'm quite conversant with all these considerations, thanks. OP asserted that BGP sessions for diversion into any cloud DDoS mitigation service ran from the endpoint network through GRE tunnels to the cloud-based mitigation provider. I was explaining that in most cloud mitigation scenarios, GRE tunnels are used for re-injection of 'clean' traffic to the endpoint networks. ----------------------------------- Roland Dobbins From jfmezei_nanog at vaxination.ca Tue Jun 30 20:32:46 2015 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 30 Jun 2015 16:32:46 -0400 Subject: World's Fastest =?UTF-8?B?SW50ZXJuZXTihKIgaW4gQ2FuYWRhbGFuZA==?= In-Reply-To: References: Message-ID: <5592FCEE.4050509@vaxination.ca> On 15-06-26 14:04, Hank Disuko wrote: > Bell Canada is apparently gearing up to provide the good people of Toronto with the World's Fastest Internet?. > http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html BTW, initally, Bell limits it to 940mbps. Likely because the Sagemcom routers it uses don't have the umph to handle higher bandwidth. (these boxes also have the hacked VDSL modem that interfaces with the not-so-compliant and long ago discontinued Stinger DSKAMs that Bell continued to deploy until 2012 despite these being discontinued in 2005 and never getting full compliance with VDSL2.) One new CPE routers are found, Bell intends to raise marketed "up to" speed to 1gnps. Of course, it will br priced so that few people order it so congestion in 32 home sectors won't be too much of a problem. Question: >From the network operator's point of view, is there a huge difference in network planning: 1- user spends 2 hours streaming a Netflix movie at roughly 6mbps. 2- user spends 5 minutes downloadimng that movie at 150mbps and then is idle for 2 hours while watching it ? Does "2" end up requiring less total capacity because on average fewer people use it at the same time ? From infinityape at gmail.com Tue Jun 30 20:32:54 2015 From: infinityape at gmail.com (Dennis B) Date: Tue, 30 Jun 2015 16:32:54 -0400 Subject: GRE performance over the Internet - DDoS cloud mitigation In-Reply-To: References: Message-ID: Roland, Agreed, Ramy's scenario was not truly spot on, but his question still remains. Perf implications when cloud security providers time to detect/mitigate is X minutes. How stable can GRE transports and BGP sessions be when under load? In my technical opinion, this is a valid argument, which deems wide opinion. Specifically, use-cases about how to apply defense in depth logically in the DC vs Hybrid vs Pure Cloud. Good topic, already some back-chatter personal opinions from Nanog lurkers! Regards, Dennis B. On Tue, Jun 30, 2015 at 2:45 PM, Roland Dobbins wrote: > > On 1 Jul 2015, at 1:37, Dennis B wrote: > > Would you like to learn more? lol >> > > I'm quite conversant with all these considerations, thanks. > > OP asserted that BGP sessions for diversion into any cloud DDoS mitigation > service ran from the endpoint network through GRE tunnels to the > cloud-based mitigation provider. I was explaining that in most cloud > mitigation scenarios, GRE tunnels are used for re-injection of 'clean' > traffic to the endpoint networks. > > ----------------------------------- > Roland Dobbins > From benno at NLnetLabs.nl Tue Jun 30 20:39:42 2015 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Tue, 30 Jun 2015 22:39:42 +0200 Subject: Call for presentations RIPE 71 Message-ID: <5592FE8E.6080705@NLnetLabs.nl> Dear colleagues, Please find the CFP for RIPE 71 below or at https://ripe71.ripe.net/submit-topic/cfp/. The deadline for submissions is 13 September 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 RIPE PC Chair https://www.ripe.net/participate/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 71 will take place from 16-20 November 2015 in Bucharest, Romania. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 71. See the full descriptions of the different presentation formats, https://ripe71.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 13 September 2015. Proposals submitted after this date will be considered depending on the remaining available space in the programme. 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. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe71.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe71.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice---in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals 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, presenters/panellists should 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 jfbeam at gmail.com Tue Jun 30 20:43:15 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 30 Jun 2015 16:43:15 -0400 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> Message-ID: On Tue, 30 Jun 2015 10:28:13 -0400, Justin M. Streiner wrote: > There are still isolated pockets of devices out there speaking IPX, > DECnet, Appletalk, etc Indeed. I'm one of them. (rarely) ... IPX managed print server. It speaks IP, but cannot be managed by IP. I'd throw it away, but it functions as a two port serial terminal server as well. (2 parallel, 2 serial) I don't have any true appletalk (or localtalk!) hardware anymore. But I know where there's a palet of them. :-) I still have MCA token-ring cards for an RS/6000 (and the RS/6000.) I'm just waiting for the NCDOT to need one to recoup a wad of tax money. > or their traffic passes through other devices that encapsulate and > de-encapsulate it in IP to allow it to be transported. Ahhhh, the "internet in a box" IPX-IP gateway device. God, how we hated those things. But some companies refused to install an IP stack, 'tho they'd install the IPX "IP app" suite. (late '90s) From baldur.norddahl at gmail.com Tue Jun 30 21:20:53 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 30 Jun 2015 23:20:53 +0200 Subject: =?UTF-8?Q?Re=3A_World=27s_Fastest_Internet=E2=84=A2_in_Canadaland?= In-Reply-To: <5592FCEE.4050509@vaxination.ca> References: <5592FCEE.4050509@vaxination.ca> Message-ID: On 30 June 2015 at 22:32, Jean-Francois Mezei wrote: > BTW, initally, Bell limits it to 940mbps. 940 Mbps is what speedtest.net will give you on a linespeed 1 Gbps connection. That sounds more like marketing people trying to understand "overhead". Regards, Baldur From hvgeekwtrvl at gmail.com Tue Jun 30 21:29:26 2015 From: hvgeekwtrvl at gmail.com (james machado) Date: Tue, 30 Jun 2015 14:29:26 -0700 Subject: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6 In-Reply-To: References: <7E6DE655-14E2-45FB-97C0-F0AA9BF4796F@baylink.com> <056A929F-D576-4897-B260-3EC3EFC8EBB1@orthanc.ca> Message-ID: On Tue, Jun 30, 2015 at 1:43 PM, Ricky Beam wrote: > On Tue, 30 Jun 2015 10:28:13 -0400, Justin M. Streiner > wrote: >> >> There are still isolated pockets of devices out there speaking IPX, >> DECnet, Appletalk, etc > > > Indeed. I'm one of them. (rarely) ... IPX managed print server. It speaks > IP, but cannot be managed by IP. I'd throw it away, but it functions as a > two port serial terminal server as well. (2 parallel, 2 serial) > > I don't have any true appletalk (or localtalk!) hardware anymore. But I know > where there's a palet of them. :-) > > I still have MCA token-ring cards for an RS/6000 (and the RS/6000.) I'm just > waiting for the NCDOT to need one to recoup a wad of tax money. > >> or their traffic passes through other devices that encapsulate and >> de-encapsulate it in IP to allow it to be transported. > > > Ahhhh, the "internet in a box" IPX-IP gateway device. God, how we hated > those things. But some companies refused to install an IP stack, 'tho they'd > install the IPX "IP app" suite. (late '90s) But how much memory you could save if you only ran IPX. Adding the IP stack would take you below 500K and then you would have programs that just wouldn't run. QEMM could only do so much. From mleber at he.net Tue Jun 30 21:44:02 2015 From: mleber at he.net (Mike Leber) Date: Tue, 30 Jun 2015 14:44:02 -0700 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: References: <5591B620.2000407@he.net> Message-ID: <55930DA2.2090201@he.net> I was thinking that when I posted yesterday. These were announcements from a peer, not customer routes. We are lowering our max prefix limits on many peers as a result of this. We are also going towards more prefix filtering on peers beyond bogons and martians. Mike. On 6/30/15 2:19 AM, Randy Bush wrote: >> NTT's customer Sofia Connect leaked our routes to NTT. NTT accepted >> these routes instead of properly filtering their customer >> announcements. As a network of non-trivial size, announcing over >> 75,000 customer routes which is nearly 15% of the IPv4 routing table, >> we'd expect the common courtesy of having our ASN included in their >> customer facing AS-PATH filters, as we extend this same courtesy to >> other networks of this size (such as AS2914). > sometimes the goddesses have a sense of humor > > At Tue, 30 Jun 2015 10:27:21 +0200, Grzegorz Janoszka wrote: >> We have just received alert from bgpmon that AS58587 Fiber @ Home >> Limited has hijacked most of our (AS43996) prefixes and Hurricane >> Electric gladly accepted them. > randy From tore at fud.no Tue Jun 30 22:02:40 2015 From: tore at fud.no (Tore Anderson) Date: Wed, 1 Jul 2015 00:02:40 +0200 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: <55930DA2.2090201@he.net> References: <5591B620.2000407@he.net> <55930DA2.2090201@he.net> Message-ID: <20150701000240.1d2872ed@envy.fud.no> * Mike Leber > I was thinking that when I posted yesterday. > > These were announcements from a peer, not customer routes. > > We are lowering our max prefix limits on many peers as a result of this. > > We are also going towards more prefix filtering on peers beyond bogons > and martians. Hi Mike, You're not mentioning RPKI here. Any particular reason why not? If I understand correctly, in today's leak the origin AS was changed/reset, so RPKI ought to have saved the day. (At least Grzegorz' day, considering that 33 of AS43996's prefixes are covered by ROAs.) Tore > > At Tue, 30 Jun 2015 10:27:21 +0200, Grzegorz Janoszka wrote: > >> We have just received alert from bgpmon that AS58587 Fiber @ Home > >> Limited has hijacked most of our (AS43996) prefixes and Hurricane > >> Electric gladly accepted them. From arnold.nipper at de-cix.net Tue Jun 30 22:23:05 2015 From: arnold.nipper at de-cix.net (Arnold Nipper) Date: Wed, 01 Jul 2015 00:23:05 +0200 Subject: Call for presentations EPF 10 Message-ID: <559316C9.20006@de-cix.net> Call for Presentations European Peering Forum 10 AMS-IX, DE-CIX, LINX, Netnod and guest IXP Equinix, are happy to host the 10th European Peering Forum (EPF) in Madrid, Spain from the 21st till the 23th of September 2015. The event will welcome up to 250 peering managers and coordinators from networks connected to the host Internet exchanges. Besides an interesting topical agenda, the three-day event accommodates room for attendees to meet on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations and lightning talks related to peering and technical topics of interconnection. Your presentation should address * Interconnection Automation * Regional Peering * Interconnection and Peering Internet Governance and Regulatory Topics * Economic and Product Trends * Peering/Interconnection Strategy * Interesting findings about peering * 100GE Submissions =========== Presentations must be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee . Please include: * Author's name and e-mail * Presentation title * Abstract * Slides (if available) * Time requested Deadlines ========= Presentation Abstract Deadline 2015-07-20 12:00 UTC Final Selection of Speakers 2015-07-31 Presentation Slides Submission Deadline 2015-09-04 12:00 UTC -- Arnold Nipper CTO/COO and Co-Founder DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net | Phone +49 69 1730902 22 | Mobile +49 172 2650958 | Fax +49 69 4056 2716 | arnold.nipper at de-cix.net | Geschaeftsfuehrer Harald A. Summa | Registergericht AG Koeln HRB 51135 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From mleber at he.net Tue Jun 30 22:26:46 2015 From: mleber at he.net (Mike Leber) Date: Tue, 30 Jun 2015 15:26:46 -0700 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: <20150701000240.1d2872ed@envy.fud.no> References: <5591B620.2000407@he.net> <55930DA2.2090201@he.net> <20150701000240.1d2872ed@envy.fud.no> Message-ID: <559317A6.2060209@he.net> On 6/30/15 3:02 PM, Tore Anderson wrote: > * Mike Leber > >> I was thinking that when I posted yesterday. >> >> These were announcements from a peer, not customer routes. >> >> We are lowering our max prefix limits on many peers as a result of this. >> >> We are also going towards more prefix filtering on peers beyond bogons >> and martians. > Hi Mike, > > You're not mentioning RPKI here. Any particular reason why not? > > If I understand correctly, in today's leak the origin AS was > changed/reset, so RPKI ought to have saved the day. (At least Grzegorz' > day, considering that 33 of AS43996's prefixes are covered by ROAs.) Yes, we will incorporate RPKI into how we build our prefix filters for peers as we improve our tools. Currently this will involve some amount of prefix list compression due to the limits of current hardware and the need to still have BGP converge. As Job Snijders said, "I would forsee issues if i'd try to add an eleven megabyte prefix-list on all devices in the network.". Mike. From cb.list6 at gmail.com Tue Jun 30 22:32:42 2015 From: cb.list6 at gmail.com (Ca By) Date: Tue, 30 Jun 2015 15:32:42 -0700 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: <559317A6.2060209@he.net> References: <5591B620.2000407@he.net> <55930DA2.2090201@he.net> <20150701000240.1d2872ed@envy.fud.no> <559317A6.2060209@he.net> Message-ID: On Tuesday, June 30, 2015, Mike Leber wrote: > > > On 6/30/15 3:02 PM, Tore Anderson wrote: > >> * Mike Leber >> >> I was thinking that when I posted yesterday. >>> >>> These were announcements from a peer, not customer routes. >>> >>> We are lowering our max prefix limits on many peers as a result of this. >>> >>> We are also going towards more prefix filtering on peers beyond bogons >>> and martians. >>> >> Hi Mike, >> >> You're not mentioning RPKI here. Any particular reason why not? >> >> If I understand correctly, in today's leak the origin AS was >> changed/reset, so RPKI ought to have saved the day. (At least Grzegorz' >> day, considering that 33 of AS43996's prefixes are covered by ROAs.) >> > > Yes, we will incorporate RPKI into how we build our prefix filters for > peers as we improve our tools. > > Currently this will involve some amount of prefix list compression due to > the limits of current hardware and the need to still have BGP converge. > > As Job Snijders said, "I would forsee issues if i'd try to add an eleven > megabyte prefix-list on all devices in the network.". > > Mike. > It is NTT that would have mitigated this issue if they deployed and enforcer rpki, right? From job at instituut.net Tue Jun 30 22:33:19 2015 From: job at instituut.net (Job Snijders) Date: Wed, 1 Jul 2015 00:33:19 +0200 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: <20150701000240.1d2872ed@envy.fud.no> References: <5591B620.2000407@he.net> <55930DA2.2090201@he.net> <20150701000240.1d2872ed@envy.fud.no> Message-ID: <20150630223319.GH95870@Vurt.local> On Wed, Jul 01, 2015 at 12:02:40AM +0200, Tore Anderson wrote: > > I was thinking that when I posted yesterday. > > > > These were announcements from a peer, not customer routes. > > > > We are lowering our max prefix limits on many peers as a result of this. > > > > We are also going towards more prefix filtering on peers beyond bogons > > and martians. > > You're not mentioning RPKI here. Any particular reason why not? > > If I understand correctly, in today's leak the origin AS was > changed/reset, so RPKI ought to have saved the day. (At least > Grzegorz' day, considering that 33 of AS43996's prefixes are covered > by ROAs.) This assessment is correct, however there might be some constraints in play with regard to RPKI, which are not really related to RPKI itself, which prohibit meaningful deployment. I've seen a few obstacles myself: - equipment might not support the RTR protocol to validate announcements against the cache validator - Legal obstacles in obtaining the anchors from all RIRs - when not using the RTR protocol but generating prefix-list filters based on RPKI data, the devices might not support sufficient entries. Would be good if other people share obstacles, and possibly, the methods they used to overcome those. I'll count "not using brocade" as a valid method. Kind regards, Job From johnl at iecc.com Tue Jun 30 22:39:00 2015 From: johnl at iecc.com (John Levine) Date: 30 Jun 2015 22:39:00 -0000 Subject: OK, Google. Time to dial back the AI hype. In-Reply-To: Message-ID: <20150630223900.1509.qmail@ary.lan> >Is the WSJ a wholly owned subsidiary of GOOG? It looks to me like a WSJ >journalist said that. If you read the paper, which is linked from the article and takes about five minutes, you'll find that article is cheap clickbait and has approximately nothing to do with the topic of the paper. As far as I can tell, none of the people in the lengthy slashdot thread bothered to do that. ObNANOG: it's about a text chat app that can be loaded with various text databases. The first couple of examples use a tech support database and the examples are impressively close to the kind of tech support one gets from offshore script readers. The example quoted in the WSJ used a database of movie subtitles, so it's not surprising that it reads like a bad movie script. R's, John From job at instituut.net Tue Jun 30 22:39:35 2015 From: job at instituut.net (Job Snijders) Date: Wed, 1 Jul 2015 00:39:35 +0200 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: References: <5591B620.2000407@he.net> <55930DA2.2090201@he.net> <20150701000240.1d2872ed@envy.fud.no> <559317A6.2060209@he.net> Message-ID: <20150630223935.GI95870@Vurt.local> On Tue, Jun 30, 2015 at 03:32:42PM -0700, Ca By wrote: > It is NTT that would have mitigated this issue if they deployed and > enforcer rpki, right? No, NTT deploying RPKI would not have helped in yesterday's issue. But, RPKI could've made a difference in today's Bangladesh leak, even if RPKI validation was not implemented by the direct upstream with propagated the leak. Kind regards, Job From jared at puck.nether.net Tue Jun 30 22:40:03 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 30 Jun 2015 17:40:03 -0500 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: <559317A6.2060209@he.net> References: <5591B620.2000407@he.net> <55930DA2.2090201@he.net> <20150701000240.1d2872ed@envy.fud.no> <559317A6.2060209@he.net> Message-ID: We have been pushing large configurations to devices. You can check my slides from the London IEPG meeting. When 96% of your config is prefix filters we are sure trying. I ask others to encourage your vendors to make this a priority as we have faced a number of issues in this area and have been waiting quite some time for vendor resolution. Jared Mauch > On Jun 30, 2015, at 5:26 PM, Mike Leber wrote: > > > >> On 6/30/15 3:02 PM, Tore Anderson wrote: >> * Mike Leber >> >>> I was thinking that when I posted yesterday. >>> >>> These were announcements from a peer, not customer routes. >>> >>> We are lowering our max prefix limits on many peers as a result of this. >>> >>> We are also going towards more prefix filtering on peers beyond bogons >>> and martians. >> Hi Mike, >> >> You're not mentioning RPKI here. Any particular reason why not? >> >> If I understand correctly, in today's leak the origin AS was >> changed/reset, so RPKI ought to have saved the day. (At least Grzegorz' >> day, considering that 33 of AS43996's prefixes are covered by ROAs.) > > Yes, we will incorporate RPKI into how we build our prefix filters for peers as we improve our tools. > > Currently this will involve some amount of prefix list compression due to the limits of current hardware and the need to still have BGP converge. > > As Job Snijders said, "I would forsee issues if i'd try to add an eleven megabyte prefix-list on all devices in the network.". > > Mike. From job at instituut.net Tue Jun 30 22:58:30 2015 From: job at instituut.net (Job Snijders) Date: Wed, 1 Jul 2015 00:58:30 +0200 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: References: <5591B620.2000407@he.net> <55930DA2.2090201@he.net> <20150701000240.1d2872ed@envy.fud.no> <559317A6.2060209@he.net> Message-ID: <20150630225830.GK95870@Vurt.local> On Tue, Jun 30, 2015 at 05:40:03PM -0500, Jared Mauch wrote: > We have been pushing large configurations to devices. You can check my > slides from the London IEPG meeting. These are the slides: http://iepg.org/2014-03-02-ietf89/ietf89_iepg_jmauch.pdf > When 96% of your config is prefix filters we are sure trying. > > I ask others to encourage your vendors to make this a priority as we > have faced a number of issues in this area and have been waiting quite > some time for vendor resolution. I'd like to add, that our average router config, since then has grown with an extra 100k lines compared to those 2013 statistics. Kind regards, Job From randy at psg.com Tue Jun 30 23:23:32 2015 From: randy at psg.com (Randy Bush) Date: Wed, 01 Jul 2015 08:23:32 +0900 Subject: NTT->HE earlier today (~10am EDT) In-Reply-To: <559317A6.2060209@he.net> References: <5591B620.2000407@he.net> <55930DA2.2090201@he.net> <20150701000240.1d2872ed@envy.fud.no> <559317A6.2060209@he.net> Message-ID: > As Job Snijders said, "I would forsee issues if i'd try to add an eleven > megabyte prefix-list on all devices in the network.". and that is why i stopped peering with HE. i run origin validation; issue roas please. randy From noc at adam.es Tue Jun 30 08:50:18 2015 From: noc at adam.es (Adam Datacenter - NOC) Date: Tue, 30 Jun 2015 10:50:18 +0200 Subject: Route leak in Bangladesh In-Reply-To: <559252E9.6030703@Janoszka.pl> References: <559252E9.6030703@Janoszka.pl> Message-ID: <00ae01d0b311$cab72300$60256900$@es> Yes, we have seen one of our prefixes hikacked. We contacted to Fiberathome and they told us the issue has been solved. Greetings. Ferran. -----Mensaje original----- De: NANOG [mailto:nanog-bounces at nanog.org] En nombre de Grzegorz Janoszka Enviado el: martes, 30 de junio de 2015 10:27 Para: nanog at nanog.org Asunto: Route leak in Bangladesh We have just received alert from bgpmon that AS58587 Fiber @ Home Limited has hijacked most of our (AS43996) prefixes and Hurricane Electric gladly accepted them. Anybody see their prefixes hijacked as well? -- Grzegorz Janoszka From lists at snowpondtech.com Tue Jun 30 13:57:21 2015 From: lists at snowpondtech.com (Joshua Zukerman) Date: Tue, 30 Jun 2015 09:57:21 -0400 Subject: Thoughts On Cheap Chinese xDSL Testers In-Reply-To: References: Message-ID: There are some downsides with the Colt-250+ units (as I have one almost daily to do installs for a CLEC). 1. The Colts require 4 high amperage AA batteries. I used to purchase Duracell Ultra batteries which worked, but life span was a couple of weeks to maybe a month and now I cannot seem to find them in stores. I now use Lithium batteries and they seem to last a few months now. 2. They will only sync up for 100 Seconds max. Not helpful when you're trying to diagnose a flapping circuit. 3. They won't stay sync'd up on circuits with Occam DSLAMs. They randomly drop after a few seconds. Not a condition of the circuit. Some type of incompatibility with Occams. 4. As others said, not a Layer 3 or 2 (I think). 5. Does not provide any additional details like Far end errors, Near end Errors, FEC/HEC, etc. On the plus side: 1. They boot up really quick, as quick as you can press 2 buttons you can start a test. (my understanding is Sunrise units take a couple of minutes to bootup) 2. Relatively lightweight. 3. Can use regular 6p4c line cords in case you lose the nice Angled-Bed-of-Nails/6p4c test cable it comes with (like I accidentally did). 4. Can be purchased for cheap on eBay. I got mine years ago for less than $150.00 On Mon, Jun 29, 2015 at 9:23 PM, Robert Glover wrote: > The local ILEC (Verizon) use Colt 250+. They are pretty cool. They do > not do layer 3 like the meter you referenced. > I'm actually looking for a cost-effective meter that does ADSL+ / VDSL2 / > e.SHDSL. it's easy to find one that does the first two, but not all three. > > -------- Original message -------- > From: Lyndon Nerenberg > Date: 06/29/2015 5:50 PM (GMT-08:00) > To: North American Network Operators' Group > Subject: Thoughts On Cheap Chinese xDSL Testers > > I've been poking around looking for an inexpensive xDSL circuit tester to > do some measurements on my home DSL line, in opposition to the telco. $2K+ > is not in the budget, so I'm curious about the accuracy of the $300 Chinese > units kicking around eBay (e.g. the ST332B). Anyone out there have > experience with them? Are they even remotely close to accurate? > > --lyndon > > ????? > -- Joshua Zukerman President Snow Pond Technology Group Inc. www.snowpondtech.com