[Nanog-futures] NANOG Trademark and Resources transferring to NewNOG
Yesterday, NewNOG and Merit Network signed an agreement to transfer the NANOG trademark and related resources to NewNOG, effective Monday, Feb. 7. This includes the nanog.org domain, the NANOG logo, and the contents and archives of the NANOG mailing lists and web site. NewNOG and Merit are working on a transition plan to migrate the mailing list and web infrastructure by the end of March with minimal downtime. For more information, see our joint press release: http://www.merit.edu/news/newsarchive/article.php?article=20110201_nanog Steve, for the NewNOG board ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: ipv4's last graph
* Geoff Huston http://www.potaroo.net/tools/ipv4/rir.jpg Ohh, very nice, Geoff! Thank you! A few questions, though: 1) The graph shows the most probable APNIC depletion date to be in July. However your site at http://ipv4.potaroo.net says 25-Sep-2011. What's the reason for this discrepancy? 2) Do you intend to update the graph daily? I noticed that it didn't change this morning along with all your other graphs. 3) May I copy it into my own presentations about IPv4 and IPv6? Regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27
Re: quietly....
On 2 feb 2011, at 4:51, Dave Israel wrote: They were features dreamed up by academics, theoreticians, and purists, and opposed by operators. Contrary to popular belief, the IETF listens to operators and wants them to participate. Few do. For instance, I don't seem to remember your name from any IETF mailinglists. (I could be mistaken, though.) There is a fundamental difference between designing something and using something. Both inform the other. But letting users with no design experience create something is a short road to failure. (Letting designers run stuff isn't much better.) I always like to say the internet is an infinite universe. In an infinite universe, everything that's possible exist. Same in the internet. Think of some way to do something, however ill-informed, and someone is doing it that way. Example: if you give administrators the option of putting a router address in a DHCP option, they will do so and some fraction of the time, this will be the wrong address and things don't work. If you let routers announce their presence, then it's virtually impossible that something goes wrong because routers know who they are. A clear win. Of course it does mean that people gasp have to learn something new when adopting IPv6.
Re: Last of ipv4 /8's allocated
On 2 feb 2011, at 0:39, Randy Carpenter wrote: That's how I would do it. With the exception of LACNIC, each one neighbors a block that is already allocated to that RIR. But if they wanted to do that, why give 106/8 to APNIC? I assume you mean 102/8 No, I was talking about monday's allocations: http://www.apnic.net/publications/news/2011/delegation
Re: Verizon acquiring Terremark
Paul, I'm sure everything will be fine in practice as others have indicated, I was merely making a point of the inherent conflict of interest. Best regards, Jeff On Wed, Feb 2, 2011 at 1:38 AM, Paul Vixie vi...@isc.org wrote: Jeffrey Lyon jeffrey.l...@blacklotus.net writes: One cannot be owned by a carrier and remain carrier neutral. My two cents, my experience running PAIX when it was owned by MFN was not like you're saying. -- Paul Vixie KI6YSY -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions
Re: Verizon acquiring Terremark
On Feb 2, 2011, at 3:22 AM, Jeffrey Lyon wrote: One cannot be owned by a carrier and remain carrier neutral. One does NOT have to be carrier neutral to provide good service.. I am sure those who have experienced great Terremark service will stick to them. mehmet
Re: quietly....
Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation. This question probably calls for another picture. Here is a plot of 2009 and 2010 in terms of the average number of IPv4 addresses allocated on a daily basis, across all 5 RIRs. I've used a smoothing function across the allocation data in order to clearly show the trend pattern over the two year period. http://www.potaroo.net/tools/ipv4/daily-allocs.jpg Geoff
Re: DHCP server fail-over and accounting
2011/2/1 Joe sj_h...@hotmail.com: hi, we plan to implement DHCP server farm in our network. Currently , there are there problems burning my head. could anybody You're making this way, way too complicated. Run two DHCP servers. Allocate two different netblocks to each server. For Example, if your network is a /24, allocate a couple of /26's. Both will answer on a request. The client will ack to whatever address it decides to accept. Full redundancy. To our experience, this needs to set up DHCP server on two sites and syncronize their content in real time. Beside this , we hope there should be as less modification as possible on edge router when one DHCP server is down. should anycast architecture helpful ? or should we just set up two dhcp servers on two sites and sync. with ISC DHCPD? Don't even bother with the syncing, and anycast is the wrong protocol here. 2. How to set up accouting and authentication with DHCP? That's the wrong place to do it. 802.1X is better here, or PPPOE/ACLs that need RADIUS auth to get past. 3. Someone said PPPOE is not good for customer looking for long time online , DHCP is an good option. But, to my understanding That's funny, because many major ISPs (like telcos) have done this for years. -j
Re: quietly....
On Wed, Feb 2, 2011 at 1:29 AM, Geoff Huston g...@apnic.net wrote: Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation. This question probably calls for another picture. Here is a plot of 2009 and 2010 in terms of the average number of IPv4 addresses allocated on a daily basis, across all 5 RIRs. I've used a smoothing function across the allocation data in order to clearly show the trend pattern over the two year period. http://www.potaroo.net/tools/ipv4/daily-allocs.jpg Geoff Oh master of the awesome graphingness...can you do a corresponding slide for v6 allocation rates, so we can see if the runout is helping inspire additional interest for networks in perhaps investigating v6 more seriously? Thanks! Matt
Re: DHCP server fail-over and accounting
Hi, On Wed, Feb 2, 2011 at 10:38 AM, John Adams j...@retina.net wrote: 2011/2/1 Joe sj_h...@hotmail.com: hi, we plan to implement DHCP server farm in our network. Currently , there are there problems burning my head. could anybody You're making this way, way too complicated. Run two DHCP servers. Allocate two different netblocks to each server. For Example, if your network is a /24, allocate a couple of /26's. Both will answer on a request. The client will ack to whatever address it decides to accept. Full redundancy. Well, it also depends on the constraints: having such a configuration implies that every scope will have to be declared twice, as well as the DHCP options. Plus, if the server who issued the lease is down, the client will get a new DHCP lease - which maybe an issue for some people. To our experience, this needs to set up DHCP server on two sites and syncronize their content in real time. Beside this , we hope there should be as less modification as possible on edge router when one DHCP server is down. should anycast architecture helpful ? or should we just set up two dhcp servers on two sites and sync. with ISC DHCPD? Don't even bother with the syncing, and anycast is the wrong protocol here. Agree, anycast makes no sense. ISC DHCPd sync works well, provided you know it and configured it correctly.
Re: quietly....
On 2/2/11 10:29 AM, Geoff Huston wrote: Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation. This question probably calls for another picture. Here is a plot of 2009 and 2010 in terms of the average number of IPv4 addresses allocated on a daily basis, across all 5 RIRs. I've used a smoothing function across the allocation data in order to clearly show the trend pattern over the two year period. http://www.potaroo.net/tools/ipv4/daily-allocs.jpg Geoff We published a similar graph on RIPE Labs last friday. It shows the 6 months rolling average allocation rate for each RIR (in units of /8s per month). APNIC's allocation rate has been on a steady rise since 2008. After coming down in 2009/2010, the average rates in ARIN and RIPE have gone up again recently. Could be the first signs of a gold rush, or just a coincidence. https://labs.ripe.net/Members/wilhelm/images/IPv4RatesPerRIR.png -- Rene
Re: quietly....
On Feb 1, 2011, at 8:05 PM, George Herbert wrote: On Tue, Feb 1, 2011 at 7:46 PM, valdis.kletni...@vt.edu wrote: On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said: We had a small ramp up in December (about 25% increase) but that is within reasonable variation. Today was a little different, though, with 4 times the normal request rate... that would be a rush. Any trending on the rate of requests for IPv6 prefixes? More interesting would be re-requests - organizations exhausting an initial allocation and requiring more. People asking for the first one just indicates initial adoption rates. Other than experimental blocks, I am generally under the impression that IPv6 allocations are designed to avoid that being necessary for an extended period of time. If that is not true, then that's a flag. There are definitely policy changes needed in order to make this true. I doubt that there are many network operators that have deployed enough IPv6 to be up against that wall yet. I know of only one. ARIN Policy Proposal 121 is intended to improve that situation significantly and also reduce the probability for human-factors related outages in the future in IPv6. Owen
Re: Connectivity status for Egypt
On Tue, Feb 1, 2011 at 21:30, Marshall Eubanks t...@americafree.tv wrote: On Jan 31, 2011, at 5:14 PM, Marshall Eubanks wrote: As an update, BGP for Noor.net has been withdrawn. Even the Egyptian stock exchange - egyptse.com - now appears to be off the Internet. I have been told that the Egyptian Prime Minister has publicly announced that the Internet would be restored soon, but at present neither my Looks like it's coming back: http://stat.ripe.net/egypt ~2500 prefixes being announced now. -- teo - http://www.teoruiz.com Res publica non dominetur
Re: quietly....
On Feb 1, 2011, at 9:02 PM, Jack Bates wrote: On 2/1/2011 9:51 PM, Dave Israel wrote: They were features dreamed up by academics, theoreticians, and purists, and opposed by operators. You mean like the lack of Default Router in DHCPv6? The whole SLAAC vs. DHCPv6 argument is a complete debacle. What IETF should have done there is provide two complete protocols that operators could make the choice or combination of choices that worked best for them. Instead, the two camps spent so much time and energy disrupting the other protocol that instead, we have two completely incomplete protocols and you need to use a weird combination of the two just to get basic functionality. There is ongoing work to complete them both now that operators have noticed, but, it is unfortunate this was so badly delayed. Don't get me wrong. I love RA. However, it is NOT a universal tool, and there are cases where Default Router via DHCPv6 would be more appropriate and easier to manage. Yep. This is an example of a missing feature. I'm in complete agreement. NAT66 is different. NAT66 breaks things in ways that impact sites outside of the site choosing to deploy NAT. Owen
Re: Connectivity status for Egypt
On Wed, Feb 2, 2011 at 6:17 AM, Teo Ruiz teor...@gmail.com wrote: On Tue, Feb 1, 2011 at 21:30, Marshall Eubanks t...@americafree.tv wrote: On Jan 31, 2011, at 5:14 PM, Marshall Eubanks wrote: As an update, BGP for Noor.net has been withdrawn. Even the Egyptian stock exchange - egyptse.com - now appears to be off the Internet. I have been told that the Egyptian Prime Minister has publicly announced that the Internet would be restored soon, but at present neither my Looks like it's coming back: http://stat.ripe.net/egypt ~2500 prefixes being announced now. -- teo - http://www.teoruiz.com Res publica non dominetur Yes, confirmed from 09:29 UTC. Basically all major providers are back, full status quo ante (modulo reagg), major sites are up. http://www.renesys.com/blog/2011/02/egypt-returns-to-the-internet.shtml Good thoughts go out to the guys in the EG NOCs this morning.Nanog wants to hear your war stories some day over a cup of tea. --jim
Re: Connectivity status for Egypt
On Wed, Feb 02, 2011 at 06:23:39AM -0500, Jim Cowie co...@renesys.com wrote a message of 29 lines which said: Yes, confirmed from 09:29 UTC. Basically all major providers are back, full status quo ante (modulo reagg), major sites are up. EUN (the academic network, which includes the primary name server for .EG) is still unreachable (1130 UTC).
Re: Connectivity status for Egypt
On Wed, Feb 02, 2011 at 12:30:45PM +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 10 lines which said: EUN (the academic network, which includes the primary name server for .EG) is still unreachable (1130 UTC). It works now (1137 UTC). BGP was a bit slow.
Re: quietly....
On Feb 2, 2011, at 12:16 AM, Iljitsch van Beijnum wrote: On 2 feb 2011, at 4:51, Dave Israel wrote: They were features dreamed up by academics, theoreticians, and purists, and opposed by operators. Contrary to popular belief, the IETF listens to operators and wants them to participate. Few do. For instance, I don't seem to remember your name from any IETF mailinglists. (I could be mistaken, though.) There is a fundamental difference between designing something and using something. Both inform the other. But letting users with no design experience create something is a short road to failure. (Letting designers run stuff isn't much better.) I always like to say the internet is an infinite universe. In an infinite universe, everything that's possible exist. Same in the internet. Think of some way to do something, however ill-informed, and someone is doing it that way. Example: if you give administrators the option of putting a router address in a DHCP option, they will do so and some fraction of the time, this will be the wrong address and things don't work. If you let routers announce their presence, then it's virtually impossible that something goes wrong because routers know who they are. A clear win. Of course it does mean that people gasp have to learn something new when adopting IPv6. I would point to 6to4 and the RAs coming from Windows Laptops that think they are routers because someone clicked on an ICS checkbox as a counter example that letting things that think they are routers announce their presence is, in fact, proof that it is not only possible that something goes wrong, but, commonplace. So, your clear win has proven to be a rather large lose in a number of environments. Owen
RE: Connectivity to Brazil
Very interesting. I have had similar issues with connectivity to my Brazil office, and oddly enough it involved GBLX and CTBC (now called Algar Telecom). I also vastly divergent paths to a couple hosts in the same subnet. I ended up communicating with GBLX via email (who were actually really great in corresponding with me)...the engineer pointed to some sort of link capacity issue...i'll dig up the thread... Date: Wed, 2 Feb 2011 01:21:09 -0500 From: vi...@abellohome.net Subject: Re: Connectivity to Brazil To: the76po...@gmail.com CC: nanog@nanog.org We saw similar issues with IKE through Global Crossing (as odd as that sounds) out of the NYC market at the same time. We routed around them and problem solved. Still scratching our heads on that one... In my experiences, GLBX has numerous odd issues to the point where it's become a bad joke anytime something breaks with connectivity... we blame them. It's kind of not funny though because it's almost always true. Taking them out of the equation usually fixes the problem. One of our customers who is frequently affected by GBLX problems jumps to the (often correct) conclusion that they are causing problems. :-/ -Vinny On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote: Thanks for the response. Ike had worked great up until Monday. The provider did a local test and our box saw the Ike packets so it appears to lie somewhere upstream. (GLBX may be a good guess) Also - the paths are stable and we are sourcing from the same ip - very strange behaivor.Hope someone from GLBX or CTBC (or someone who had experienced an issue like this) can assist Thanks to all for their feedback so far. SD On Feb 1, 2011, at 3:19 PM, valdis.kletni...@vt.edu wrote: On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: Some carrier, somewhere between us and the service provider is selectively dropping the IKE packets originating from our VPN gateway and destined for our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming back from Brazil to us. This is effectively preventing us from establishing the IPSEC tunnel between our gateways. Has IKE been known to work to that location before? Or is this something new? My first guess is some chucklehead banana-eater at the service provider either fat-fingered the firewall config, or semi-intentionally blocked it because it was traffic on a protocol/port number they didn't understand so it must be evil. Also something else is awry, for two given hosts on the same subnet (x.y.z.52 and x.y.z.53), they take two wildly divergent paths: Anyone have any insight on to what may be occurring? The paths appear to diverge at 67.16.142.238. I wonder if that's gear trying to do some load-balancing across 2 paths, and it's using the source IP as a major part of the selector function (route to round-robin interface source-IP mod N or similar?). The other possibility is your two traceroutes happened to catch a routing flap in progress (obviously not the case if the two routes are remaining stable). Sorry I can't be more helpful than that...
Re: quietly....
On 02/02/2011 08:16, Iljitsch van Beijnum wrote: Contrary to popular belief, the IETF listens to operators and wants them to participate. Few do. For instance, I don't seem to remember your name from any IETF mailinglists. (I could be mistaken, though.) Regardless of the stated opinion of the IETF and its participants, there is a culture in the IETF of resistance to operational opinion. The DHCPv6 vs RA debacle is a direct consequence of this and a good example of both the problem and the serious consequences which ensue when one side doesn't listen. Nick
Re: quietly....
Regardless of the stated opinion of the IETF and its participants, there is a culture in the IETF of resistance to operational opinion. The DHCPv6 vs RA debacle is a direct consequence of this and a good example of both the problem and the serious consequences which ensue when one side doesn't listen. some ietf ops participants have been fighting this for years, not always successfully. but recently, the ops within the ietf community have been banding together a bit more. the win rate is not a lot higher, but at least we can share the pain. :) your characterization of the dhcpv6 issue as a debacle is understated. it's flat out st00pid and insane, and loses ipv6 non-trivial market share. the religious fools have moved to the mentality that v4 scarcity will force ipv6 deployment and they don't have to compromise their ivory tower zealotry. they are bringing nats of all flavors on themselves. this would be fine if the rest of us did not also get the dren. randy
Re: quietly....
On Feb 1, 2011, at 11:19 PM, John Curran wrote: On Feb 1, 2011, at 11:05 PM, George Herbert wrote: More interesting would be re-requests - organizations exhausting an initial allocation and requiring more. People asking for the first one just indicates initial adoption rates. Other than experimental blocks, I am generally under the impression that IPv6 allocations are designed to avoid that being necessary for an extended period of time. If that is not true, then that's a flag. I don't believe we've had an IPv6 additional request yet (but I look forward to it happening at some point :-). I will check and get back to the list with the definitive answer. It turns out we've had a handful of ISPs come back for additional IPv6 blocks but it was the result of an better understanding of their evolving address allocation requirements pre-deployment. FYI, /John John Curran President and CEO ARIN
Re: quietly....
On 2 feb 2011, at 12:39, Owen DeLong wrote: I would point to 6to4 and the RAs coming from Windows Laptops that think they are routers because someone clicked on an ICS checkbox as a counter example that letting things that think they are routers announce their presence is, in fact, proof that it is not only possible that something goes wrong, but, commonplace. I didn't say they were necessarily good routers. The issue of rogue routers and DHCP servers is a separate one. Obviously if you have rogue RAs but no rogue DHCPv6 then it helps if you can ignore the RAs and put all the info in DHCPv6. But the same bad practices that created rogue RAs can just as easily create rogue DHCPv6 servers so this is not a real solution, just very limited managing of symptoms. But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6.
Re: quietly....
Example: if you give administrators the option of putting a router address in a DHCP option, they will do so and some fraction of the time, this will be the wrong address and things don't work. They cause themselves a problem then they fix it. If you let routers announce their presence, then it's virtually impossible that something goes wrong s/impossible/certain because routers know who they are It doesn't mean they're right. If I choose DHCP I've made the choice to define how this network works. I then want it to carry on like that, not depend on others not screwing up too. A clear win. Of course it does mean that people gasp have to learn something new when adopting IPv6. It means all administrators now have to guard against trivial errors by all end users. Lot larger fail surface It's not about dislike of new, it's dislike of pointless risk brandon
Re: Connectivity to Brazil
That thread detail would be very interesting to me. Thanks for the heads up. Sent from my iPhone On Feb 2, 2011, at 7:14 AM, Matt Disuko gourmetci...@hotmail.com wrote: Very interesting. I have had similar issues with connectivity to my Brazil office, and oddly enough it involved GBLX and CTBC (now called Algar Telecom). I also vastly divergent paths to a couple hosts in the same subnet. I ended up communicating with GBLX via email (who were actually really great in corresponding with me)...the engineer pointed to some sort of link capacity issue...i'll dig up the thread... Date: Wed, 2 Feb 2011 01:21:09 -0500 From: vi...@abellohome.net Subject: Re: Connectivity to Brazil To: the76po...@gmail.com CC: nanog@nanog.org We saw similar issues with IKE through Global Crossing (as odd as that sounds) out of the NYC market at the same time. We routed around them and problem solved. Still scratching our heads on that one... In my experiences, GLBX has numerous odd issues to the point where it's become a bad joke anytime something breaks with connectivity... we blame them. It's kind of not funny though because it's almost always true. Taking them out of the equation usually fixes the problem. One of our customers who is frequently affected by GBLX problems jumps to the (often correct) conclusion that they are causing problems. :-/ -Vinny On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote: Thanks for the response. Ike had worked great up until Monday. The provider did a local test and our box saw the Ike packets so it appears to lie somewhere upstream. (GLBX may be a good guess) Also - the paths are stable and we are sourcing from the same ip - very strange behaivor. Hope someone from GLBX or CTBC (or someone who had experienced an issue like this) can assist Thanks to all for their feedback so far. SD On Feb 1, 2011, at 3:19 PM, valdis.kletni...@vt.edu wrote: On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: Some carrier, somewhere between us and the service provider is selectively dropping the IKE packets originating from our VPN gateway and destined for our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming back from Brazil to us. This is effectively preventing us from establishing the IPSEC tunnel between our gateways. Has IKE been known to work to that location before? Or is this something new? My first guess is some chucklehead banana-eater at the service provider either fat-fingered the firewall config, or semi-intentionally blocked it because it was traffic on a protocol/port number they didn't understand so it must be evil. Also something else is awry, for two given hosts on the same subnet (x.y.z.52 and x.y.z.53), they take two wildly divergent paths: Anyone have any insight on to what may be occurring? The paths appear to diverge at 67.16.142.238. I wonder if that's gear trying to do some load-balancing across 2 paths, and it's using the source IP as a major part of the selector function (route to round-robin interface source-IP mod N or similar?). The other possibility is your two traceroutes happened to catch a routing flap in progress (obviously not the case if the two routes are remaining stable). Sorry I can't be more helpful than that...
Re: quietly....
On 02/02/2011 12:50, Iljitsch van Beijnum wrote: But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6. I rest my case. Nick
Re: Connectivity to Brazil
Thanks Vinny - how did you route around? There seems to be one path from the US to Brazil via GBLX and CTBC.Are you leveraging leased connectivity? Thanks for the info!! SD Sent from my iPhone On Feb 2, 2011, at 1:21 AM, Vinny Abello vi...@abellohome.net wrote: We saw similar issues with IKE through Global Crossing (as odd as that sounds) out of the NYC market at the same time. We routed around them and problem solved. Still scratching our heads on that one... In my experiences, GLBX has numerous odd issues to the point where it's become a bad joke anytime something breaks with connectivity... we blame them. It's kind of not funny though because it's almost always true. Taking them out of the equation usually fixes the problem. One of our customers who is frequently affected by GBLX problems jumps to the (often correct) conclusion that they are causing problems. :-/ -Vinny On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote: Thanks for the response. Ike had worked great up until Monday. The provider did a local test and our box saw the Ike packets so it appears to lie somewhere upstream. (GLBX may be a good guess) Also - the paths are stable and we are sourcing from the same ip - very strange behaivor.Hope someone from GLBX or CTBC (or someone who had experienced an issue like this) can assist Thanks to all for their feedback so far. SD On Feb 1, 2011, at 3:19 PM, valdis.kletni...@vt.edu wrote: On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: Some carrier, somewhere between us and the service provider is selectively dropping the IKE packets originating from our VPN gateway and destined for our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming back from Brazil to us. This is effectively preventing us from establishing the IPSEC tunnel between our gateways. Has IKE been known to work to that location before? Or is this something new? My first guess is some chucklehead banana-eater at the service provider either fat-fingered the firewall config, or semi-intentionally blocked it because it was traffic on a protocol/port number they didn't understand so it must be evil. Also something else is awry, for two given hosts on the same subnet (x.y.z.52 and x.y.z.53), they take two wildly divergent paths: Anyone have any insight on to what may be occurring? The paths appear to diverge at 67.16.142.238. I wonder if that's gear trying to do some load-balancing across 2 paths, and it's using the source IP as a major part of the selector function (route to round-robin interface source-IP mod N or similar?). The other possibility is your two traceroutes happened to catch a routing flap in progress (obviously not the case if the two routes are remaining stable). Sorry I can't be more helpful than that...
RE: Using IPv6 with prefixes shorter than a /64 on a LAN
Our classified networks aren't ever going to be connected to anything but themselves either, and they need sane local addressing. Some of them are a single room with a few machines, some of them are entire facilities with hundreds of machines, but none of them are going to be talking to a router or anything upstream, as neither of those exist on said networks. Jamie -Original Message- From: Chuck Anderson [mailto:c...@wpi.edu] Sent: Tuesday, February 01, 2011 6:39 PM To: nanog@nanog.org Subject: Re: Using IPv6 with prefixes shorter than a /64 on a LAN On Tue, Feb 01, 2011 at 03:14:57PM -0800, Owen DeLong wrote: On Feb 1, 2011, at 2:58 PM, Jack Bates wrote: There are many cases where ULA is a perfect fit, and to work around it seems silly and reduces the full capabilities of IPv6. I fully expect to see protocols and networks within homes which will take full advantage of ULA. I also expect to see hosts which don't talk to the public internet directly and never need a GUA. I guess we can agree to disagree about this. I haven't seen one yet. What would your recommended solution be then for disconnected networks? Every home user and enterprise user requests GUA directly from their RIR/NIR/LIR at a cost of hunderds of dollars per year or more?
Re: quietly....
On Feb 2, 2011, at 4:50 AM, Iljitsch van Beijnum wrote: On 2 feb 2011, at 12:39, Owen DeLong wrote: I would point to 6to4 and the RAs coming from Windows Laptops that think they are routers because someone clicked on an ICS checkbox as a counter example that letting things that think they are routers announce their presence is, in fact, proof that it is not only possible that something goes wrong, but, commonplace. I didn't say they were necessarily good routers. No, you said the router always knows better than the DHCP server. This is an example of a common case where it does not. The issue of rogue routers and DHCP servers is a separate one. Obviously if you have rogue RAs but no rogue DHCPv6 then it helps if you can ignore the RAs and put all the info in DHCPv6. But the same bad practices that created rogue RAs can just as easily create rogue DHCPv6 servers so this is not a real solution, just very limited managing of symptoms. It really isn't. If the DHCP server on a subnet could override the rogue routers RA messages by policy, then, it would actually make it fairly trivial to address this issue. Unfortunately because administrators don't have that option, we're stuck. But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6. This is a clear example of the myopia in the IETF that has operators so frustrated. Owen
Re: Connectivity status for Egypt
On Feb 2, 2011, at 6:23 AM, Jim Cowie wrote: On Wed, Feb 2, 2011 at 6:17 AM, Teo Ruiz teor...@gmail.com wrote: On Tue, Feb 1, 2011 at 21:30, Marshall Eubanks t...@americafree.tv wrote: On Jan 31, 2011, at 5:14 PM, Marshall Eubanks wrote: As an update, BGP for Noor.net has been withdrawn. Even the Egyptian stock exchange - egyptse.com - now appears to be off the Internet. I have been told that the Egyptian Prime Minister has publicly announced that the Internet would be restored soon, but at present neither my Looks like it's coming back: http://stat.ripe.net/egypt ~2500 prefixes being announced now. -- teo - http://www.teoruiz.com Res publica non dominetur Yes, confirmed from 09:29 UTC. Basically all major providers are back, full status quo ante (modulo reagg), major sites are up. http://www.renesys.com/blog/2011/02/egypt-returns-to-the-internet.shtml It's not just BGP - DNS (based on the samples I have been testing) seems to be fully back too. Regards Marshall Good thoughts go out to the guys in the EG NOCs this morning.Nanog wants to hear your war stories some day over a cup of tea. --jim
Re: Bovespa
Where are you connecting from? Sent from my iPhone On Feb 1, 2011, at 11:22 PM, Philip Lavine source_ro...@yahoo.com wrote: 1. Does anyone know where the Bovespa is located and if colocation is a possibility at that datacenter/s. 2. What is a good Internet (DS3? or ethernet) carrier in Sao Paolo thank you Philip
Re: Bovespa
On Wed, Feb 2, 2011 at 2:22 AM, Philip Lavine source_ro...@yahoo.com wrote: 1. Does anyone know where the Bovespa is located and if colocation is a possibility at that datacenter/s. Sao Paulo downtown, although it is unclear at this time if it will stay there or not. They do not provide colocation at their datacenter, but there is one a few steps from it, Alog. (http://www.alog.com.br). Other SP metro area datacenters include Locaweb (http://www.locaweb.com.br), UOL Host (http://www.uolhost.com.br) and Global Crossing. UOL Host newest facility is also at downtown. Bovespa recently chose Diveo (http://www.diveo.com, acquired by UOL Host) for their contingency site, located about 30 km from Bovespa current location. 2. What is a good Internet (DS3? or ethernet) carrier in Sao Paolo Ethernet carriers are prevalent in Sao Paulo. My first pick is AES Atimus (http://www.aesatimus.com.br). Algar (http://www.algartelecom.com.br), Global Crossing coming second; you can also lease Internet capacity from the datacenter you end up colocating at, usually with good prices and quality. Rubens
Re: Connectivity to Brazil
CTBC has capacity from GBLX, TIWS and SEABONE, although not all prefixes are announced to all providers. TIWS usual path in the US is thru Level 3, so steering the traffic to Level 3 might do the trick. Rubens On Wed, Feb 2, 2011 at 11:08 AM, Steve Danelli the76po...@gmail.com wrote: Thanks Vinny - how did you route around? There seems to be one path from the US to Brazil via GBLX and CTBC. Are you leveraging leased connectivity? Thanks for the info!! SD Sent from my iPhone On Feb 2, 2011, at 1:21 AM, Vinny Abello vi...@abellohome.net wrote: We saw similar issues with IKE through Global Crossing (as odd as that sounds) out of the NYC market at the same time. We routed around them and problem solved. Still scratching our heads on that one... In my experiences, GLBX has numerous odd issues to the point where it's become a bad joke anytime something breaks with connectivity... we blame them. It's kind of not funny though because it's almost always true. Taking them out of the equation usually fixes the problem. One of our customers who is frequently affected by GBLX problems jumps to the (often correct) conclusion that they are causing problems. :-/ -Vinny On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote: Thanks for the response. Ike had worked great up until Monday. The provider did a local test and our box saw the Ike packets so it appears to lie somewhere upstream. (GLBX may be a good guess) Also - the paths are stable and we are sourcing from the same ip - very strange behaivor. Hope someone from GLBX or CTBC (or someone who had experienced an issue like this) can assist Thanks to all for their feedback so far. SD On Feb 1, 2011, at 3:19 PM, valdis.kletni...@vt.edu wrote: On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: Some carrier, somewhere between us and the service provider is selectively dropping the IKE packets originating from our VPN gateway and destined for our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming back from Brazil to us. This is effectively preventing us from establishing the IPSEC tunnel between our gateways. Has IKE been known to work to that location before? Or is this something new? My first guess is some chucklehead banana-eater at the service provider either fat-fingered the firewall config, or semi-intentionally blocked it because it was traffic on a protocol/port number they didn't understand so it must be evil. Also something else is awry, for two given hosts on the same subnet (x.y.z.52 and x.y.z.53), they take two wildly divergent paths: Anyone have any insight on to what may be occurring? The paths appear to diverge at 67.16.142.238. I wonder if that's gear trying to do some load-balancing across 2 paths, and it's using the source IP as a major part of the selector function (route to round-robin interface source-IP mod N or similar?). The other possibility is your two traceroutes happened to catch a routing flap in progress (obviously not the case if the two routes are remaining stable). Sorry I can't be more helpful than that...
Re: Strange L2 failure
On 1/29/2011 10:05 PM, Jack Bates wrote: On 1/29/2011 8:47 PM, ML wrote: I just ran into something like this yesterday. A Belkin router with a MAC of 9444.52dc. was properly learned at the IDF switch but the upstream agg switch/router wouldn't learn it. I even tried to static the MAC into the CAM..router refused. That's what really tripped me out, was that the router actually did place an ARP entry and pretended like everything should be working. Scheduling some more direct tests with packet sniffers next week when I get back in the office. I'm curious now if IOS has the issue or the line card, so we'll test off different cards direct and monitor results. Jack Turns out I ran out of space in the CAM..embarrassing. What didn't happen was frame flooding. Since this device was part of the ME34xx product line I'd wager Cisco thought it better to drop frames than leak data. I upgraded the IOS to 12.2(50)SE5 from 12.2(25)SEG. Somehow there is more space in the TCAM for unicast MACs between software versions.
Re: quietly....
On 2 feb 2011, at 14:10, Owen DeLong wrote: I didn't say they were necessarily good routers. No, you said the router always knows better than the DHCP server. This is an example of a common case where it does not. If someone turns their box into a router they can also turn it into a DHCP server. This is what happens with IPv4. The solution is to filter these packets from fake routers in the switches. So ask your switch vendor for that feature in IPv6. It really isn't. If the DHCP server on a subnet could override the rogue routers RA messages by policy, then, it would actually make it fairly trivial to address this issue. And who overrides the rogue DHCPv6 messages? Or is it turtles all the way down? But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6. This is a clear example of the myopia in the IETF that has operators so frustrated. I can assure you that I'm quite alone within the IETF with that view. I'm not talking about the interaction between DHCPv6 and RAs here, just about how bad DHCPv6 is on its own terms. For instance, there's no client identifier or using MAC addresses to identify clients, this is now done with a DUID. Unfortunately, administrators have no way of knowing what DUID a given client is going to use so having a DHCPv6 server set up with information tailored to a specific client is really hard. There's also stateful and stateless DHCPv6, but it's the client that has to choose between them, while the server knows whether it's going to return stateful or stateless information. There's no prefix length in DHCPv6, so this needs to be learned from RAs. (Although it can be argued that because routers need to know this info anyway, having the prefix length there doesn't buy you anything.) The problem with DHCP in general is that there is a continuous influx of new options but they all need to be encoded into a binary format inside a small packet. This info should be in an XML file on a HTTP server instead, rather than be overloaded into the connectivity bootstrapping. The problem with RA / DHCP is that RAs were built with some vague notion of what DHCP would do some day and then when DHCPv6 was developed half a decade later the evolving ideas didn't fit with the shape of the hole left in RAs anymore but that problem wasn't addressed at this time. Fixing that now (hopefully fixing it well, not doing stupid things like making DHCPv6 an IPv4 DHCP clone with all the IPv4 DHCP problems that we all suffer every day) means that we'll end up with three types of systems: - no DHCPv6 - legacy DHCPv6 - new DHCPv6 Good luck trying to come up with a combination of RA and DHCP settings that make all three work well. Even without new DHCPv6, there's already 12 ways to set up RAs and DHCP and only a few combinations produce useful results.
Re: Verizon acquiring Terremark
Date: Wed, 2 Feb 2011 03:22:39 -0500 From: Jeffrey Lyon jeffrey.l...@blacklotus.net I'm sure everything will be fine in practice as others have indicated, I was merely making a point of the inherent conflict of interest. ah. if you mean it's unusual or it's difficult rather than it cannot be then i have no arguments. the reason PAIX got traction at all, coming late to the game (1995-ish) as we did, was because MFS was then able to charge circuit prices for many forms of cross connect down at MAE West. and i did face continuous pressure from MFN to go after a share of PAIX's carrier's circuit revenue. (which i never did and which none of my successors have done either.) noting, the game as moved on. if verizon behaves badly as terremark's owner then the presence of equinix in the market will act as a relief valve. i think the neutral and commercial model is very well established and that verizon will not want to be the only carrier in those facilities nor have their circuit-holders be the only customers for the real estate. it's an awful lot of space to use just as colo, and it's both over- and underbuilt for colo (vs. an IX). re: On Wed, Feb 2, 2011 at 1:38 AM, Paul Vixie vi...@isc.org wrote: Jeffrey Lyon jeffrey.l...@blacklotus.net writes: One cannot be owned by a carrier and remain carrier neutral. My two cents, my experience running PAIX when it was owned by MFN was not like you're saying.
RE: Connectivity to Brazil
Algar looking Glass: http://lg.ctbc.com.br/lg/ I found the response from the GC engineer. It won't mean much cutpasted verbatim and out of context, so I'll just summarize. Basically, I was seeing vastly different response times to given hosts in the same subnet on CTBC's network. My source ip was the same. Traceroute revealed to me the packets taking different paths, after hitting a particular GLBX router. The GC engineer said CTBC is a customer that hangs off of this particular router, and that traffic was hitting an interface and hair-pinning back out to the customer's segment. He pointed to possible congestion on CTBCs switching fabric as the cause for the varied response times (conceivable) and different routes (um...ok maybe some kind of load-balancing at play). I managed to call CTBC (Algar) and confirmed they were experiencing congestion issues and they had a scheduled circuit capacity upgrade with GLBX in a few weeks. As a network admin, i find it sometimes sadly humorous how we can poke and prod at a problem, go through various carrier support channels and scratch our heads for hours/days when all it would normally take is a RO userid on a couple routers in the path to figure things out. that's not too much to ask, right? ;) -matt CC: vi...@abellohome.net; nanog@nanog.org From: the76po...@gmail.com Subject: Re: Connectivity to Brazil Date: Wed, 2 Feb 2011 08:07:14 -0500 To: gourmetci...@hotmail.com That thread detail would be very interesting to me. Thanks for the heads up. Sent from my iPhone On Feb 2, 2011, at 7:14 AM, Matt Disuko gourmetci...@hotmail.com wrote: Very interesting. I have had similar issues with connectivity to my Brazil office, and oddly enough it involved GBLX and CTBC (now called Algar Telecom). I also vastly divergent paths to a couple hosts in the same subnet. I ended up communicating with GBLX via email (who were actually really great in corresponding with me)...the engineer pointed to some sort of link capacity issue...i'll dig up the thread... Date: Wed, 2 Feb 2011 01:21:09 -0500 From: vi...@abellohome.net Subject: Re: Connectivity to Brazil To: the76po...@gmail.com CC: nanog@nanog.org We saw similar issues with IKE through Global Crossing (as odd as that sounds) out of the NYC market at the same time. We routed around them and problem solved. Still scratching our heads on that one... In my experiences, GLBX has numerous odd issues to the point where it's become a bad joke anytime something breaks with connectivity... we blame them. It's kind of not funny though because it's almost always true. Taking them out of the equation usually fixes the problem. One of our customers who is frequently affected by GBLX problems jumps to the (often correct) conclusion that they are causing problems. :-/ -Vinny On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote: Thanks for the response. Ike had worked great up until Monday. The provider did a local test and our box saw the Ike packets so it appears to lie somewhere upstream. (GLBX may be a good guess) Also - the paths are stable and we are sourcing from the same ip - very strange behaivor. Hope someone from GLBX or CTBC (or someone who had experienced an issue like this) can assist Thanks to all for their feedback so far. SD On Feb 1, 2011, at 3:19 PM, valdis.kletni...@vt.edu wrote: On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: Some carrier, somewhere between us and the service provider is selectively dropping the IKE packets originating from our VPN gateway and destined for our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming back from Brazil to us. This is effectively preventing us from establishing the IPSEC tunnel between our gateways. Has IKE been known to work to that location before? Or is this something new? My first guess is some chucklehead banana-eater at the service provider either fat-fingered the firewall config, or semi-intentionally blocked it because it was traffic on a protocol/port number they didn't understand so it must be evil. Also something else is awry, for two given hosts on the same subnet (x.y.z.52 and x.y.z.53), they take two wildly divergent paths: Anyone have any insight on to what may be occurring? The paths appear to diverge at 67.16.142.238. I wonder if that's gear trying to do some load-balancing across 2 paths, and it's using the source IP as a major part of the selector function (route to round-robin interface source-IP mod N or similar?). The other possibility is your two traceroutes happened to catch a routing flap in progress (obviously not the case if the two
Re: Verizon acquiring Terremark
I wonder if the price point will change. Having been in PAIX/SD/Equinix facilities for several years things have certainly changed with regard to contract negotiations and pricing. Equinix is not very flexible. The shuffle of techs has also resulted in a much less helpful group to work with. On 02/02/2011 09:20 AM, Paul Vixie wrote: Date: Wed, 2 Feb 2011 03:22:39 -0500 From: Jeffrey Lyonjeffrey.l...@blacklotus.net I'm sure everything will be fine in practice as others have indicated, I was merely making a point of the inherent conflict of interest. ah. if you mean it's unusual or it's difficult rather than it cannot be then i have no arguments. the reason PAIX got traction at all, coming late to the game (1995-ish) as we did, was because MFS was then able to charge circuit prices for many forms of cross connect down at MAE West. and i did face continuous pressure from MFN to go after a share of PAIX's carrier's circuit revenue. (which i never did and which none of my successors have done either.) noting, the game as moved on. if verizon behaves badly as terremark's owner then the presence of equinix in the market will act as a relief valve. i think the neutral and commercial model is very well established and that verizon will not want to be the only carrier in those facilities nor have their circuit-holders be the only customers for the real estate. it's an awful lot of space to use just as colo, and it's both over- and underbuilt for colo (vs. an IX). re: On Wed, Feb 2, 2011 at 1:38 AM, Paul Vixievi...@isc.org wrote: Jeffrey Lyonjeffrey.l...@blacklotus.net writes: One cannot be owned by a carrier and remain carrier neutral. My two cents, my experience running PAIX when it was owned by MFN was not like you're saying.
Re: quietly....
On Wed, Feb 2, 2011 at 09:49, Chris Adams cmad...@hiwaay.net wrote: The difference is that in the widest-used desktop OS, turn me into a router is a single checkbox, while turn me into a DHCP server requires installing software. Turning on Internet Connection Sharing also (helpfully) enables and configures a DHCP server on the ICS host. ~Matt
Re: quietly....
On Feb 2, 2011, at 6:17 AM, Iljitsch van Beijnum wrote: On 2 feb 2011, at 14:10, Owen DeLong wrote: I didn't say they were necessarily good routers. No, you said the router always knows better than the DHCP server. This is an example of a common case where it does not. If someone turns their box into a router they can also turn it into a DHCP server. This is what happens with IPv4. The solution is to filter these packets from fake routers in the switches. So ask your switch vendor for that feature in IPv6. Turns out that this is A LOT less common and when it does happen, it's easier to find and eliminate. It really isn't. If the DHCP server on a subnet could override the rogue routers RA messages by policy, then, it would actually make it fairly trivial to address this issue. And who overrides the rogue DHCPv6 messages? Or is it turtles all the way down? Turns out to be quite a bit easier to isolate and remove the rogue DHCP server. Also turns out that there isn't a single-checkbox way to accidentally create a DHCP server, unlike a rogue RA. But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6. This is a clear example of the myopia in the IETF that has operators so frustrated. I can assure you that I'm quite alone within the IETF with that view. Then you have had impressive success at blocking useful development for a lone individual. I'm not talking about the interaction between DHCPv6 and RAs here, just about how bad DHCPv6 is on its own terms. For instance, there's no client identifier or using MAC addresses to identify clients, this is now done with a DUID. Unfortunately, administrators have no way of knowing what DUID a given client is going to use so having a DHCPv6 server set up with information tailored to a specific client is really hard. There's also stateful and stateless DHCPv6, but it's the client that has to choose between them, while the server knows whether it's going to return stateful or stateless information. There's no prefix length in DHCPv6, so this needs to be learned from RAs. (Although it can be argued that because routers need to know this info anyway, having the prefix length there doesn't buy you anything.) I agree that there is much that needs to be improved in DHCPv6. The lack of a default router, however, is the broken part that causes the most difficulty in modern operations. The problem with DHCP in general is that there is a continuous influx of new options but they all need to be encoded into a binary format inside a small packet. This info should be in an XML file on a HTTP server instead, rather than be overloaded into the connectivity bootstrapping. The problem with RA / DHCP is that RAs were built with some vague notion of what DHCP would do some day and then when DHCPv6 was developed half a decade later the evolving ideas didn't fit with the shape of the hole left in RAs anymore but that problem wasn't addressed at this time. Fixing that now (hopefully fixing it well, not doing stupid things like making DHCPv6 an IPv4 DHCP clone with all the IPv4 DHCP problems that we all suffer every day) means that we'll end up with three types of systems: We can agree to disagree about that. While it's true that there is a large number of options and the DHCP packet needs to remain relatively small, the reality is that no site uses all of them. They large number of options represents a superset of the differing needs of various sites. XML on HTTP is too much overhead for things a system needs to know at boot time to download its kernel. Operationally, DHCPv4 is just fine and is meeting the needs today. There's no reason we shouldn't have at least equivalent functionality in DHCPv6. - no DHCPv6 - legacy DHCPv6 - new DHCPv6 Good luck trying to come up with a combination of RA and DHCP settings that make all three work well. Even without new DHCPv6, there's already 12 ways to set up RAs and DHCP and only a few combinations produce useful results. Yes... It really would be better if both SLAAC and DHCPv6 provided complete solutions and the operator could pick the single solution that worked best for them. Unfortunately, instead of looking at how things are used in the real world, IETF pursued some sort of theoretical purity exercise and we have two half-protocols that can't possibly provide a complete solution in either one. SLAAC fails because you can't get information about DNS, NTP, or anything other than a list of prefixes and a router that MIGHT actually be able to default-route your packets. DHCP fails because you can't get a default router out of it. Owen
Re: quietly....
On Feb 2, 2011, at 6:43 AM, Jack Bates wrote: On 2/2/2011 8:22 AM, Tony Finch wrote: Counterexample: rogue RAs from Windows boxes running 6to4 or Teredo and Internet Connection Sharing. This is a lot harder to fix than a misconfigured DHCP server. CounterCounterexample: rogue DHCPv6 servers from windows boxes or improperly connected CPEs. Both DHCP(4 or 6) and RA require careful filtering to keep rogues from jacking things up. Though M$ has a nice deployment for authorizing DHCP4 servers in corporate environments. It's a lot easier to find and eliminate a rogue DHCP server than a rogue RA. Owen
Re: quietly....
On Wed, 2011-02-02 at 07:00 -0800, Owen DeLong wrote: SLAAC fails because you can't get information about DNS, NTP, or anything other than a list of prefixes and a router that MIGHT actually be able to default-route your packets. DHCP fails because you can't get a default router out of it. That said, there appear to be efforts under way to add DNS server information to RA and to add a default router option to DHCPv6. Well, last time I looked, anyway... Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 signature.asc Description: This is a digitally signed message part
Re: quietly....
On 2 feb 2011, at 16:00, Owen DeLong wrote: SLAAC fails because you can't get information about DNS, NTP, or anything other than a list of prefixes and a router that MIGHT actually be able to default-route your packets. Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd rather use a known NTP server that keeps correct time. For DNS in RA, see RFC 6106. But all of this could easily have been avoided: why are we _discovering_ DNS addresses in the first place? Simply host them on well known addresses and you can hardcode those addresses, similar to the 6to4 gateway address. But no, no rough consensus on something so simple. DHCP fails because you can't get a default router out of it. If you consider that wrong, I don't want to be right.
Re: quietly....
On Feb 2, 2011, at 10:23 AM, Iljitsch van Beijnum wrote: Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd rather use a known NTP server that keeps correct time. Been there. Done that. Made perfect business sense. The NTP servers were ours and kept excellent time. Oh, we also included the default route. James R. Cutler james.cut...@consultant.com
Re: netflow analysis for jitter and packet loss?
If you're considering actual 'netflow' data, I'm not really sure it will help with your requirements. The smallest unit is the 'flow' which could include many UDP packets and has only *flow* start and end times. Cisco's IP SLA might help. See: http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsjitter.html Joe From: Shacolby Jackson shaco...@bluejeansnet.com To: nanog@nanog.org Date: 02/01/2011 07:21 PM Subject: netflow analysis for jitter and packet loss? What tools are people most happy with? Specifically I'm hoping to mirror a port and later see if I can detect any inbound jitter or possibly even out of order udp datagrams. At first glance it doesn't look like ntop or plixer can provide that level of detail. Any suggestions? -shac
Re: quietly....
Hi, But all of this could easily have been avoided: why are we _discovering_ DNS addresses in the first place? Simply host them on well known addresses and you can hardcode So, when I take my laptop from Home to work, to the airport, to some random cyber cafe I should have to manually alter my DNS servers assuming I can find someone in the location who can tell me what they are ?? Or let me guess, I should hardcode some public DNS servers which I can hopefully reach from where I am, hopefully is not down or having issues and hopefully I don't have poor latency to? And here I always thought the D in DHCP stood for Dynamic.
Re: quietly....
On Wed, Feb 2, 2011 at 10:23, Iljitsch van Beijnum iljit...@muada.comwrote: But all of this could easily have been avoided: why are we _discovering_ DNS addresses in the first place? Simply host them on well known addresses and you can hardcode those addresses, similar to the 6to4 gateway address. But no, no rough consensus on something so simple. I'll admit right now that I don't know nearly enough about the IETF process, but it looks like there have been 2 separate attempts at this: draft-lee-dnsop-resolver-wellknown-ipv6addr - ID, expired draft-ohta-preconfigured-dns - ID, expired Until one of those is revived (or a similar draft is written), and makes it through IETF to reach RFC status, and there are assigned addresses from IANA, there are no well known addresses for anyone hardcode. ~Matt
Re: quietly....
On 2/2/2011 9:23 AM, Iljitsch van Beijnum wrote: Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd rather use a known NTP server that keeps correct time. Most corporate networks do, as it is more critical for the workstations to be in sync with the servers than to actually have the correct time. Though ideally, the servers have their time synced in one form or another. But all of this could easily have been avoided: why are we _discovering_ DNS addresses in the first place? Simply host them on well known addresses and you can hardcode those addresses, similar to the 6to4 gateway address. But no, no rough consensus on something so simple. Administrative control. Utilizing well known addresses and anycasting DNS servers is considered a BAD thing. Anycasting in this way means you always use the nearest DNS server, which may NOT be the correct DNS server for your machine. DHCP fails because you can't get a default router out of it. If you consider that wrong, I don't want to be right. It is wrong in many situations. Case in point. As an ISP, RA does not gain me anything but increases router load and bandwidth utilization as it spits out to 3000+ interfaces periodically. Default Router in DHCPv6 reduces this load and traffic. Another case: What is the authentication model on RAs? M$ is very good at authenticating their DHCP servers to insure rogues don't interfere. Jack
Re: quietly....
On 2 feb 2011, at 16:35, Greg Estabrooks wrote: But all of this could easily have been avoided: why are we _discovering_ DNS addresses in the first place? Simply host them on well known addresses and you can hardcode So, when I take my laptop from Home to work, to the airport, to some random cyber cafe I should have to manually alter my DNS servers assuming I can find someone in the location who can tell me what they are ?? No, the point is that DNS resolvers in different places all use the same addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.) I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done.
Re: quietly....
On 2/2/11 7:23 AM, Iljitsch van Beijnum wrote: On 2 feb 2011, at 16:00, Owen DeLong wrote: SLAAC fails because you can't get information about DNS, NTP, or anything other than a list of prefixes and a router that MIGHT actually be able to default-route your packets. Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd rather use a known NTP server that keeps correct time. Me, because I have better things to do than to manually enter NTP servers (and other various boot settings) into all of my IP phones by hand. Configure DHCP, plug them in, and it just works. ~Seth
Re: quietly....
So, when I take my laptop from Home to work, to the airport, to some random cyber cafe I should have to manually alter my DNS servers assuming I can find someone in the location who can tell me what they are ?? Or let me guess, I should hardcode some public DNS servers which I can hopefully reach from where I am, hopefully is not down or having issues and hopefully I don't have poor latency to? You could always run your own recursive server on your laptop, instead of a stub, and remove your dependancy on anyone but the roots. *ducks* Regards, Tim.
Re: quietly....
On Wed, 2 Feb 2011, Tim Franklin wrote: You could always run your own recursive server on your laptop, instead of a stub, and remove your dependancy on anyone but the roots. *ducks* Especially because this is the only secure way to do DNSSEC validation. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.
Re: quietly....
On 2/2/2011 9:52 AM, Iljitsch van Beijnum wrote: I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done. I don't disagree that an anycast well known address would be nice for say RA + SLAAC. However, DHCP has many uses and requirements. It has versatility that RA + SLAAC doesn't have, especially when dealing with policies for specific devices (which I understand DHCPv6 is missing some of this logic). This includes DNS servers. When I am connected to certain parts of our network, the DNS servers I receive are not the same as everyone around me. This applies to VPN connections as well (though I realize in VPN I could actually setup for the prefix to go via the VPN). DHCP is about giving hosts information based on policies. The simpler use of DHCP could easily be replaced, but the more common corporate uses cannot. Currently, much of the functionality of DHCP is not included in DHCPv6, which is a serious operations issue. Jack
Re: quietly....
On 2/2/2011 10:52 AM, Iljitsch van Beijnum wrote: No, the point is that DNS resolvers in different places all use the same addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.) I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done. So what if I want to assign different people to different resolvers by policy? What if I want to use non-/64 subnets with a resolver on each one? What if I round-robin amongst more or less resolvers than there are well-known addresses assigned to? What if, in 1/2/5/10/20/50 years, we need to do things differently? Why intentionally burden a protocol with something that screams I am going to be a depreciated legacy problem someday! -Dave
Re: quietly....
From: Iljitsch van Beijnum iljit...@muada.com I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done. I don't particularly care whether DHCP is the *best* way to get some particular job done; I care that it is a well-known, well-understood way of *getting* the job done, and lots of operational work, development, and process has gone into making DHCP do this well, reliably, and scalably. The problem with DHCPv6 is that it doesn't do nearly enough when compared to DHCPv4, and there are not in fact any good alternatives. The insistence on RA, along with a handwaving dismissal of all of those folks who have a high reliance on DHCP has done a tremendous disservice to the uptake of IPv6. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: quietly....
Matt Addison matt.addi...@lists.evilgeni.us writes: I'll admit right now that I don't know nearly enough about the IETF process, but it looks like there have been 2 separate attempts at this: draft-lee-dnsop-resolver-wellknown-ipv6addr - ID, expired draft-ohta-preconfigured-dns - ID, expired Until one of those is revived (or a similar draft is written), and makes it through IETF to reach RFC status, and there are assigned addresses from IANA, there are no well known addresses for anyone hardcode. Several microsoft OSes will automatically use fec0:0:0:::1, 2, and 3 if there is a nameserver there.
Egypt
Hi again from Network World... We're now looking into a story on how Egypt may have restored service -- did they bring up all routes at once? Stagger the re-introduction of routes so as not to overwhelm routers? Any specific ISPs brought up before others and why? ie, Noor and the stock exchange brought up before any others, etc. Any thoughts from NANOG on how best -- or worst -- to restore Internet service following, reportedly, the largest government-mandated blackout ever? Also, are any of you in touch with any Egyptian ISPs and sharing this type of information? Or hearing any war stories from over there? Thanks again, and best regards, Jim Duffy Network World
Re: Connectivity to Brazil
Very simply. :) We chose to stop accepting prefixes from and announcing prefixes to them. You could attempt this in more elaborate and less forceful ways if you're in the right position, but we encounter issues like this too much and it affects critical clients that cannot afford any downtime, and we have plenty of other transit connections. We are in a position where we have direct connectivity with them (which based on our track record won't be much longer), so it might be much easier for us. Otherwise you'd have to hope your upstream is the one connected to them and has communities available to tinker with to withdraw your tagged prefixes from being announced to them, and just change the local preference or however you prefer to do it on the inbound routes from your upstream, or better yet filter on as-path. -Vinny On 2/2/2011 8:08 AM, Steve Danelli wrote: Thanks Vinny - how did you route around? There seems to be one path from the US to Brazil via GBLX and CTBC.Are you leveraging leased connectivity? Thanks for the info!! SD Sent from my iPhone On Feb 2, 2011, at 1:21 AM, Vinny Abello vi...@abellohome.net wrote: We saw similar issues with IKE through Global Crossing (as odd as that sounds) out of the NYC market at the same time. We routed around them and problem solved. Still scratching our heads on that one... In my experiences, GLBX has numerous odd issues to the point where it's become a bad joke anytime something breaks with connectivity... we blame them. It's kind of not funny though because it's almost always true. Taking them out of the equation usually fixes the problem. One of our customers who is frequently affected by GBLX problems jumps to the (often correct) conclusion that they are causing problems. :-/ -Vinny On Feb 1, 2011, at 3:57 PM, Steve Danelli wrote: Thanks for the response. Ike had worked great up until Monday. The provider did a local test and our box saw the Ike packets so it appears to lie somewhere upstream. (GLBX may be a good guess) Also - the paths are stable and we are sourcing from the same ip - very strange behaivor.Hope someone from GLBX or CTBC (or someone who had experienced an issue like this) can assist Thanks to all for their feedback so far. SD On Feb 1, 2011, at 3:19 PM, valdis.kletni...@vt.edu wrote: On Tue, 01 Feb 2011 08:54:47 EST, Steve Danelli said: Some carrier, somewhere between us and the service provider is selectively dropping the IKE packets originating from our VPN gateway and destined for our Brazil gateway. Other traffic is able to pass, as are the IKE packets coming back from Brazil to us. This is effectively preventing us from establishing the IPSEC tunnel between our gateways. Has IKE been known to work to that location before? Or is this something new? My first guess is some chucklehead banana-eater at the service provider either fat-fingered the firewall config, or semi-intentionally blocked it because it was traffic on a protocol/port number they didn't understand so it must be evil. Also something else is awry, for two given hosts on the same subnet (x.y.z.52 and x.y.z.53), they take two wildly divergent paths: Anyone have any insight on to what may be occurring? The paths appear to diverge at 67.16.142.238. I wonder if that's gear trying to do some load-balancing across 2 paths, and it's using the source IP as a major part of the selector function (route to round-robin interface source-IP mod N or similar?). The other possibility is your two traceroutes happened to catch a routing flap in progress (obviously not the case if the two routes are remaining stable). Sorry I can't be more helpful than that...
Re: quietly....
On Wednesday, February 02, 2011 10:52:46 am Iljitsch van Beijnum wrote: No, the point is that DNS resolvers in different places all use the same addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.) Hrmph. Shades of 47.0079.00A03E01.00 and all that that implies, here. Well, different syntatic sugar, but, anyway Haven't we withdrawn from this ATM before?
2011.02.02 NANOG51 day 3 morning session notes
Final set of notes for NANOG51 have been posted up at http://kestrel3.netflight.com/2011.02.02-NANOG51-morning-notes.txt (not that many people will see them, as everyone is clearing out of the room and heading for flights at this point. ^_^; ) Thanks again to Josh and Terremark for hosting another successful conference; would have loved to be able to join the party, but alas, lack of budget ruled that out this time around. Thanks also to all the presenters and speakers, and to the technical crew who provide the online streams; in spite of my grumblings about the occasional spottiness this time around, it really is awesome to be able to follow along remotely. :) Thanks! Matt
Re: quietly....
On 2 feb 2011, at 17:14, Dave Israel wrote: I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done. So what if I want to assign different people to different resolvers by policy? For the record: I'm not saying that DHCPv6 is never useful. DHCPv6 is intended as a stateful configuration provisioning tool, i.e., to give different hosts different configurations. If that's what you need then DHCP fits the bill. However, in most small scale environments this is not what's needed so DHCP doesn't fit the bill. Also, the examples mentioned are about enterprise networks with stable systems. Here, DHCP works well. However, with systems that connect to different networks, things don't always work so well. I may want to use the DHCP-provided NTP servers at work, but syncing with a random NTP server when I connect to a wifi hotspot is not such a great idea.
Re: quietly....
On Wednesday, February 02, 2011 10:23:28 am Iljitsch van Beijnum wrote: Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd rather use a known NTP server that keeps correct time. We do, for multiple reasons. And we have some stringent timing requirements.
OT: References for i/o Phoenix Datacenter
My company is considering taking space in the i/o Phoenix One datacenter in Arizona. If anyone has any feedback of this facility in general or any of i/o's facilities, good or bad, I would certainly appreciate an off-list reply. As you would expect, the company you're intending to do business with is never going to give you a negative reference. :) Thanks everyone and my apologies for the quick off-topic distraction. Adam
RE: ipv4's last graph
So in the interest of 'second opinions never hurt', and I just can't get my head around APnic sitting at 3 /8's, burning 2.3 /8's in the last 2 months and the idea of a 50% probability that their exhaustion event occurs Aug. 2011, here are a couple other graphs to consider. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf Tony -Original Message- From: Geoff Huston [mailto:g...@apnic.net] Sent: Tuesday, February 01, 2011 12:12 PM To: Randy Bush Cc: NANOG Operators' Group Subject: Re: ipv4's last graph On 01/02/2011, at 7:02 PM, Randy Bush wrote: with the iana free pool run-out, i guess we won't be getting those nice graphs any more. might we have one last one for the turnstiles? :- )/2 and would you mind doing the curves now for each of the five rirs? gotta give us all something to repeat endlessly on lists and in presos. but of course. http://www.potaroo.net/tools/ipv4/rir.jpg This is a different graph - it is a probabilistic graph that shows the predicted month when the RIR will be down to its last /8 policy (whatever that policy may be), and the relative probability that the event will occur in that particular month. The assumption behind this graph is that the barricades will go up across the regions and each region will work from its local address pools and service only its local client base, and that as each region gets to its last /8 policy the applicants will not transfer their demand to those regions where addresses are still available. Its not possible to quantify how (in)accurate this assumption may be, so beyond the prediction of the first exhaustion point (which is at this stage looking more likely to occur in July 2011 than not) the predictions for the other RIRs are highly uncertain. Geoff
Re: quietly....
On Tue, 1 Feb 2011, Cameron Byrne wrote: Telling people I'm right, you're wrong over and over again leads to them going away and ignoring IPv6. +1 Somebody should probably get a blog instead of sending, *39 and counting*, emails to this list in one day. It's a discussion list. We're having a discussion. Admittedly, Owen hasn't presented any solutions to my actual problems, but.. ;) Owen said: The solution to number 2 depends again on the circumstance. IPv6 offers a variety of tools for this problem, but, I have yet to see an environment where the other tools can't offer a better solution than NAT. Which is a complete non-answer. NAT provides a nice solution - even with it's problems - for small consumers and large enterprises, who have much higher percentages of devices that need (or even -require-) no inbound connectivity. Why should I (or my IT department) have to renumber the 5,000 desktop PCs in this office (a large percentage of which have static IP addresses due to the failings of dynamic DNS and software that won't support DNS (I'm looking at you, Unity.) just because we've changed providers? Why should we have to renumber devices at my mom's house just because she switched from cable to dsl? -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org http://www.expita.com/nomime.html
Re: ipv4's last graph
On Wed, Feb 2, 2011 at 9:01 AM, Tony Hain alh-i...@tndh.net wrote: So in the interest of 'second opinions never hurt', and I just can't get my head around APnic sitting at 3 /8's, burning 2.3 /8's in the last 2 months and the idea of a 50% probability that their exhaustion event occurs Aug. 2011, here are a couple other graphs to consider. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf Tony Two things: 1) you'll get better uptake of your graph if it's visible as a simple image, rather than requiring a PDF download. :/ 2) labelling the Y axis would help; I'm not sure what the scale of 1-8 represents, unless it's perhaps the number of slices of pizza consumed per staff member per address allocation request? But I do agree with what seems to be your driving message, which is that Geoff could potentially be considered optimistic. ^_^; Matt
RE: AS numbers and multiple site best practices
I've had trouble finding any technical reason not to use it. What is important to you about having QA and Corporate use separate AS numbers? Does using the same AS number result in a reduction of separation? For my part it's mostly a desire to make sure that changes to QA or Corp BGP configs could never impact BGP for our Production datacenter. So far it looks like it may just be a fear of the unknown on my part as I can't think of a good example of how one might actually affect one BGP installation by making changes to another BGP installation purely based on sharing an AS number (clearly you could have impact if you are advertising the same space from both locations).
Re: quietly....
On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: No, the point is that DNS resolvers in different places all use the same addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.) Because no one has ever had a need to coexist with other DNS servers on the same subnet, right? After all, there should only ever be 1 authorative source of information, and there's no way we would ever want to have an exception for that. ...david (who manages his own authorative and recursive DNS servers that are used specificly for our group's purposes that have to coexist with IT-managed servers) -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org http://www.expita.com/nomime.html
Re: quietly....
On Wed, Feb 2, 2011 at 12:28, david raistrick dr...@icantclick.org wrote: On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: No, the point is that DNS resolvers in different places all use the same addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.) Because no one has ever had a need to coexist with other DNS servers on the same subnet, right? After all, there should only ever be 1 authorative source of information, and there's no way we would ever want to have an exception for that. Why do they have to be mutually exclusive? What's wrong with having default well known (potentially anycasted) resolver addresses, which can then be overridden by RA/DHCP/static configuration? ~Matt
Re: ipv4's last graph
On 02/02/2011 17:22, Matthew Petach wrote: On Wed, Feb 2, 2011 at 9:01 AM, Tony Hain alh-i...@tndh.net wrote: So in the interest of 'second opinions never hurt', and I just can't get my head around APnic sitting at 3 /8's, burning 2.3 /8's in the last 2 months and the idea of a 50% probability that their exhaustion event occurs Aug. 2011, here are a couple other graphs to consider. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf Tony Two things: 1) you'll get better uptake of your graph if it's visible as a simple image, rather than requiring a PDF download. :/ Not wishing to advertise google but http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf and http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf works for me without needing to download a pdf viewer Vince 2) labelling the Y axis would help; I'm not sure what the scale of 1-8 represents, unless it's perhaps the number of slices of pizza consumed per staff member per address allocation request? But I do agree with what seems to be your driving message, which is that Geoff could potentially be considered optimistic. ^_^; Matt
Re: quietly....
On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: different networks, things don't always work so well. I may want to use the DHCP-provided NTP servers at work, but syncing with a random NTP server when I connect to a wifi hotspot is not such a great idea. It's not random if the network operator is providing it via DHCP is it? Antonio Querubin e-mail/xmpp: t...@lava.net
Re: quietly....
On 02/02/2011 17:43, Matt Addison wrote: Why do they have to be mutually exclusive? What's wrong with having default well known (potentially anycasted) resolver addresses, which can then be overridden by RA/DHCP/static configuration? because that increases the complexity of the system, and complexity leads to more failure modes. If you model how this would work on a state diagram, you'll see that there are several inherent ways that this will cause serious problems when people start doing things like removing the well known addresses (because they don't use them), and so forth. This is a well-examined problem: well known unicast listener addresses are a bad, bad idea. Nick
RE: ipv4's last graph
-Original Message- From: Vincent Hoffman [mailto:jh...@unsane.co.uk] Sent: Wednesday, February 02, 2011 9:44 AM To: nanog@nanog.org Subject: Re: ipv4's last graph On 02/02/2011 17:22, Matthew Petach wrote: On Wed, Feb 2, 2011 at 9:01 AM, Tony Hain alh-i...@tndh.net wrote: So in the interest of 'second opinions never hurt', and I just can't get my head around APnic sitting at 3 /8's, burning 2.3 /8's in the last 2 months and the idea of a 50% probability that their exhaustion event occurs Aug. 2011, here are a couple other graphs to consider. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf Tony Two things: 1) you'll get better uptake of your graph if it's visible as a simple image, rather than requiring a PDF download. :/ Not wishing to advertise google but http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- rir-pools.pdf and http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- rir-pools-zoom.pdf works for me without needing to download a pdf viewer For some reason that viewer didn't work here, so I added jpg's to the site. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.jpg http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.jpg Vince 2) labelling the Y axis would help; I'm not sure what the scale of 1-8 represents, unless it's perhaps the number of slices of pizza consumed per staff member per address allocation request? I thought about leaving it off completely, but figured I would be asked for scale. It is /8's remaining until they drop into their 'last allocation' policy. I will see if I can figure out how to fit that into something readable. But I do agree with what seems to be your driving message, which is that Geoff could potentially be considered optimistic. ^_^; Geoff has always been the optimist ... ;0 Matt
Re: AS numbers and multiple site best practices
It seems to me that the issues (in terms of causing failures) are all related to how the prefixes are announced, and not what ASN they are announced from. However if there ARE issues caused by how the prefixes are announced, it may (or may not) be easier to troubleshoot the problem if the announcements are from different ASNs. I go back to the definition of an Autonomous System - a network or group of networks under a common administrative control. Are the networks at the datacenter and the networks at the corporate office under a common administrative control or not? From a certain purist perspective, if the corp office networks aren't run by the same people who run the datacenter, then the prefixes should be announced from different ASNs with different points of contact. In this case, in theory, if the corp office prefixes are being announced from both that location AND the datacenter, then you should BGP peer the corp office with the datacenter, so that the data center announces them with the same origin ASN that you are using at the corp office location, and the data center ASN is next in the list as a provider. Of course that may have the affect of tending to steer all or most of the corp office traffic away from the datacenter (or not depending on peering), which may or may not be what you intend. Of course in spite of all of that, I have to ask if another ASN is really NEEDED - i.e. do the people who run the data center network and the people who run the corp office network talk to each other? Are the data center network folks smart enough to figure out if a problem might be related to announcements from the corp office, and friendly enough to be able to work together with the other group to resolve the issue (and the other way around)? If you all get along, I have to ask if you need to add another ASN to the routers of everyone in the world... Mickster On Wed, Feb 2, 2011 at 9:24 AM, Andy Litzinger andy.litzin...@theplatform.com wrote: I've had trouble finding any technical reason not to use it. What is important to you about having QA and Corporate use separate AS numbers? Does using the same AS number result in a reduction of separation? For my part it's mostly a desire to make sure that changes to QA or Corp BGP configs could never impact BGP for our Production datacenter. So far it looks like it may just be a fear of the unknown on my part as I can't think of a good example of how one might actually affect one BGP installation by making changes to another BGP installation purely based on sharing an AS number (clearly you could have impact if you are advertising the same space from both locations).
Re: 2011.02.02 NANOG51 day 3 morning session notes
On Feb 2, 2011, at 11:52 AM, Matthew Petach wrote: Thanks again to Josh and Terremark for hosting another successful conference; would have loved to be able to join the party, but alas, lack of budget ruled that out this time around. +1 Josh / Bill , amazing job with hosting nanog. Mehmet
Re: ipv4's last graph
On Wed, Feb 02, 2011 at 10:11:48AM -0800, Tony Hain said: For some reason that viewer didn't work here, so I added jpg's to the site. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.jpg http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.jpg 13:13 dec0de africa is where it's at 13:15 moebius_ Dear Sirs, I am the son of the deposed Prime Minister of Nigeria. We are in possession of 93,208,512 IP addresses and wish to request your assistance... /kc -- Ken Chase - k...@heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.
Re: ipv4's last graph
Note that the ARIN, APNIC, and RIPE lines should all basically level out to asymptotes after they hit 1 /8 left, due to the soft run out policies in place [1][2][3]. Either that, or just consider arriving at 1 /8 left as depletion. Geoff: How are your graphs dealing with these policies? [1] https://www.arin.net/policy/nrpm.html#four10 [2] http://www.apnic.net/policy/add-manage-policy#9.10.1 [3] http://ripe.net/ripe/policies/proposals/2010-02.html On Wed, Feb 2, 2011 at 1:11 PM, Tony Hain alh-i...@tndh.net wrote: -Original Message- From: Vincent Hoffman [mailto:jh...@unsane.co.uk] Sent: Wednesday, February 02, 2011 9:44 AM To: nanog@nanog.org Subject: Re: ipv4's last graph On 02/02/2011 17:22, Matthew Petach wrote: On Wed, Feb 2, 2011 at 9:01 AM, Tony Hain alh-i...@tndh.net wrote: So in the interest of 'second opinions never hurt', and I just can't get my head around APnic sitting at 3 /8's, burning 2.3 /8's in the last 2 months and the idea of a 50% probability that their exhaustion event occurs Aug. 2011, here are a couple other graphs to consider. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf Tony Two things: 1) you'll get better uptake of your graph if it's visible as a simple image, rather than requiring a PDF download. :/ Not wishing to advertise google but http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- rir-pools.pdf and http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- rir-pools-zoom.pdf works for me without needing to download a pdf viewer For some reason that viewer didn't work here, so I added jpg's to the site. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.jpg http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.jpg Vince 2) labelling the Y axis would help; I'm not sure what the scale of 1-8 represents, unless it's perhaps the number of slices of pizza consumed per staff member per address allocation request? I thought about leaving it off completely, but figured I would be asked for scale. It is /8's remaining until they drop into their 'last allocation' policy. I will see if I can figure out how to fit that into something readable. But I do agree with what seems to be your driving message, which is that Geoff could potentially be considered optimistic. ^_^; Geoff has always been the optimist ... ;0 Matt
RE: ipv4's last graph
-Original Message- From: Richard Barnes [mailto:richard.bar...@gmail.com] Sent: Wednesday, February 02, 2011 10:44 AM To: Tony Hain Cc: Vincent Hoffman; nanog@nanog.org Subject: Re: ipv4's last graph Note that the ARIN, APNIC, and RIPE lines should all basically level out to asymptotes after they hit 1 /8 left, due to the soft run out policies in place [1][2][3]. Either that, or just consider arriving at 1 /8 left as depletion. The /8 that applies to those policies has not been allocated yet ... ask again tomorrow. Would it make more sense to mark the graph at 1 with an asterisk, or just leave those out of this graph all together? If you care about how well the policy is managing the end of the pool, then marking 1 is the right thing, while if you only care about when 'old policy' stops then it makes more sense to just leave them off. Tony Geoff: How are your graphs dealing with these policies? [1] https://www.arin.net/policy/nrpm.html#four10 [2] http://www.apnic.net/policy/add-manage-policy#9.10.1 [3] http://ripe.net/ripe/policies/proposals/2010-02.html On Wed, Feb 2, 2011 at 1:11 PM, Tony Hain alh-i...@tndh.net wrote: -Original Message- From: Vincent Hoffman [mailto:jh...@unsane.co.uk] Sent: Wednesday, February 02, 2011 9:44 AM To: nanog@nanog.org Subject: Re: ipv4's last graph On 02/02/2011 17:22, Matthew Petach wrote: On Wed, Feb 2, 2011 at 9:01 AM, Tony Hain alh-i...@tndh.net wrote: So in the interest of 'second opinions never hurt', and I just can't get my head around APnic sitting at 3 /8's, burning 2.3 /8's in the last 2 months and the idea of a 50% probability that their exhaustion event occurs Aug. 2011, here are a couple other graphs to consider. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf Tony Two things: 1) you'll get better uptake of your graph if it's visible as a simple image, rather than requiring a PDF download. :/ Not wishing to advertise google but http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- rir-pools.pdf and http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- rir-pools-zoom.pdf works for me without needing to download a pdf viewer For some reason that viewer didn't work here, so I added jpg's to the site. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.jpg http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.jpg Vince 2) labelling the Y axis would help; I'm not sure what the scale of 1-8 represents, unless it's perhaps the number of slices of pizza consumed per staff member per address allocation request? I thought about leaving it off completely, but figured I would be asked for scale. It is /8's remaining until they drop into their 'last allocation' policy. I will see if I can figure out how to fit that into something readable. But I do agree with what seems to be your driving message, which is that Geoff could potentially be considered optimistic. ^_^; Geoff has always been the optimist ... ;0 Matt
Re: quietly....
the problem is not whether RA is worth a damn, produces more erronious results, is harder to filter bad guys/gals, ... the problem is folk have *large* dhcp deployments. they look at going to ipv6 and say wtf? i have to revamp my operation because of some religious nuts. rfc1918 is my friend. whew! randy
Re: ipv4's last graph
Currently there is no policy in ARIN that would do that short of the last /10, so, the line should change at 1/4 of the last /8. Owen On Feb 2, 2011, at 10:43 AM, Richard Barnes wrote: Note that the ARIN, APNIC, and RIPE lines should all basically level out to asymptotes after they hit 1 /8 left, due to the soft run out policies in place [1][2][3]. Either that, or just consider arriving at 1 /8 left as depletion. Geoff: How are your graphs dealing with these policies? [1] https://www.arin.net/policy/nrpm.html#four10 [2] http://www.apnic.net/policy/add-manage-policy#9.10.1 [3] http://ripe.net/ripe/policies/proposals/2010-02.html On Wed, Feb 2, 2011 at 1:11 PM, Tony Hain alh-i...@tndh.net wrote: -Original Message- From: Vincent Hoffman [mailto:jh...@unsane.co.uk] Sent: Wednesday, February 02, 2011 9:44 AM To: nanog@nanog.org Subject: Re: ipv4's last graph On 02/02/2011 17:22, Matthew Petach wrote: On Wed, Feb 2, 2011 at 9:01 AM, Tony Hain alh-i...@tndh.net wrote: So in the interest of 'second opinions never hurt', and I just can't get my head around APnic sitting at 3 /8's, burning 2.3 /8's in the last 2 months and the idea of a 50% probability that their exhaustion event occurs Aug. 2011, here are a couple other graphs to consider. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.pdf http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf Tony Two things: 1) you'll get better uptake of your graph if it's visible as a simple image, rather than requiring a PDF download. :/ Not wishing to advertise google but http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- rir-pools.pdf and http://docs.google.com/viewer?url=http://www.tndh.net/~tony/ietf/IPv4- rir-pools-zoom.pdf works for me without needing to download a pdf viewer For some reason that viewer didn't work here, so I added jpg's to the site. http://www.tndh.net/~tony/ietf/IPv4-rir-pools.jpg http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.jpg Vince 2) labelling the Y axis would help; I'm not sure what the scale of 1-8 represents, unless it's perhaps the number of slices of pizza consumed per staff member per address allocation request? I thought about leaving it off completely, but figured I would be asked for scale. It is /8's remaining until they drop into their 'last allocation' policy. I will see if I can figure out how to fit that into something readable. But I do agree with what seems to be your driving message, which is that Geoff could potentially be considered optimistic. ^_^; Geoff has always been the optimist ... ;0 Matt
Re: quietly....
On Feb 2, 2011, at 3:16 AM, Iljitsch van Beijnum wrote: On 2 feb 2011, at 4:51, Dave Israel wrote: They were features dreamed up by academics, theoreticians, and purists, and opposed by operators. Contrary to popular belief, the IETF listens to operators and wants them to participate. Few do. For instance, I don't seem to remember your name from any IETF mailinglists. (I could be mistaken, though.) From personal experience, the only reason die-hard IETF folk want operators to participate on IETF lists is so that they can tell them that they're wrong on IETF mailing lists as opposed to operator mailing lists. Example: if you give administrators the option of putting a router address in a DHCP option, they will do so and some fraction of the time, this will be the wrong address and things don't work. If you let routers announce their presence, then it's virtually impossible that something goes wrong because routers know who they are. A clear win. Of course it does mean that people gasp have to learn something new when adopting IPv6. Is anyone else reading this and the word condescending _not_ popping into their heads?
Re: quietly....
On Feb 2, 2011, at 10:23 AM, Iljitsch van Beijnum wrote: On 2 feb 2011, at 16:00, Owen DeLong wrote: SLAAC fails because you can't get information about DNS, NTP, or anything other than a list of prefixes and a router that MIGHT actually be able to default-route your packets. Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd rather use a known NTP server that keeps correct time. For DNS in RA, see RFC 6106. But all of this could easily have been avoided: why are we _discovering_ DNS addresses in the first place? Simply host them on well known addresses and you can hardcode those addresses, similar to the 6to4 gateway address. But no, no rough consensus on something so simple. DHCP fails because you can't get a default router out of it. If you consider that wrong, I don't want to be right. Hey, I thought you wanted ops input... Here you are getting it, and look, here all you are doing is saying that its wrong.
Re: quietly....
On Feb 2, 2011, at 6:18 AM, Owen DeLong wrote: NAT66 is different. NAT66 breaks things in ways that impact sites outside of the site choosing to deploy NAT. Examples?
Re: quietly....
On Wed, 02 Feb 2011 07:45:46 -1000, Antonio Querubin said: On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: different networks, things don't always work so well. I may want to use the DHCP-provided NTP servers at work, but syncing with a random NTP server when I connect to a wifi hotspot is not such a great idea. It's not random if the network operator is providing it via DHCP is it? If you're connecting at a Starbuck's, and you care more than hopefully somebody will tell me the right time within a minute, yes, it *is* essentially random. pgp8E3xDG0iDd.pgp Description: PGP signature
Re: quietly....
On Wed, 02 Feb 2011 14:30:23 EST, John Payne said: On Feb 2, 2011, at 3:16 AM, Iljitsch van Beijnum wrote: Example: if you give administrators the option of putting a router address in a DHCP option, they will do so and some fraction of the time, this will be the wrong address and things don't work. If you let routers announce their presence, then it's virtually impossible that something goes wrong because routers know who they are. A clear win. Of course it does mean that people gasp have to learn something new when adopting IPv6. Is anyone else reading this and the word condescending _not_ popping into their heads? The only other charitable conclusion I can draw is Somebody hasn't spent time chasing down people with misconfigured laptops on the wireless who are squawking RA's for 2002: There's a *big* operational difference between all authorized and properly configured routers know who they are and all nodes that think they're routers (deluded though they may be) know who they are. pgpiKLbv0VvGU.pgp Description: PGP signature
Re: quietly....
On Feb 1, 2011, at 6:15 PM, Owen DeLong wrote: On Feb 1, 2011, at 2:56 PM, John Payne wrote: On Feb 1, 2011, at 4:38 PM, Owen DeLong o...@delong.com wrote: NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. It does not solve any other problem(s). That's a bold statement. Especially as you said NAT and not PAT. NAT, PAT, whatever... I'm willing to back it up. NAT provides a solution to, lets call it, enterprise multihoming. Remote office with a local Internet connection, but failover through the corporate network. In IPv4 this would likely be done with PAT, but I'm looking forward to being able to do something similar with NAT66 (or whatever it ends up being called) without blowing out my internal policies or having to maintain multiple addresses on each end point.
Re: quietly....
On 2/2/2011 2:42 PM, valdis.kletni...@vt.edu wrote: The only other charitable conclusion I can draw is Somebody hasn't spent time chasing down people with misconfigured laptops on the wireless who are squawking RA's for 2002: There's a *big* operational difference between all authorized and properly configured routers know who they are and all nodes that think they're routers (deluded though they may be) know who they are. Amen to that, and add all mischievous nodes that would /*love*/ to be your router / DNS / default gateway / etc Jeff
Re: quietly....
On Feb 2, 2011, at 11:40 AM, John Payne wrote: On Feb 2, 2011, at 6:18 AM, Owen DeLong wrote: NAT66 is different. NAT66 breaks things in ways that impact sites outside of the site choosing to deploy NAT. Examples? SIP Network enabled Video Games Peer to Peer services of various forms etc. Owen
Primus Canada AS 6407 Contact needed
Hi, I'm seeking a contact at AS6407 to help troubleshoot a huge spike in latency I'm seeing to them. Thanks, Jared
Re: quietly....
On 2 feb 2011, at 20:37, John Payne wrote: DHCP fails because you can't get a default router out of it. If you consider that wrong, I don't want to be right. Hey, I thought you wanted ops input... Here you are getting it, and look, here all you are doing is saying that its wrong. I said the IETF wants input. In case you hadn't noticed, I'm not the IETF. I don't represent them in any way. I'm not even a working group chair. I've gone to a bunch of meetings, spent way too much time on IETF mailinglists and co-wrote all of one RFCs. I read some great writing advice once. It applies to much more than just writing. It goes like this: whenever a reader tells you that there's something wrong with your book, there is something wrong with your book. But if they tell you how to fix it, they're pretty much always wrong. I'm not part of the DHC working group and I'm not a big DHCP user myself, so I don't claim to know the issues that exist with DHCPv6 in the operational community. But I'm sure there are some valid issues there. However, I'm equally sure that adding IPv4-DHCP-style router addresses to DHCPv6 is a big mistake that will create a lot of operational problems. Maybe not in the networks of the people that want this feature, but the problems will be there. Coming to the IETF to have your solution rubberstamped invariably leads to disappointment. Go there to tell them about your problem. That works much better. But sending _me_ your input doesn't seem to make either of us happier.
Re: quietly....
On Feb 2, 2011, at 2:54 PM, Owen DeLong wrote: On Feb 2, 2011, at 11:40 AM, John Payne wrote: On Feb 2, 2011, at 6:18 AM, Owen DeLong wrote: NAT66 is different. NAT66 breaks things in ways that impact sites outside of the site choosing to deploy NAT. Examples? SIP Network enabled Video Games Peer to Peer services of various forms etc. I chose NAT66. How does that affect you or any other site? Note that I have already blocked games and peer to peer either technically or via policy and I have no SIP end points that have any business talking outside the enterprise. Just rephrasing you slightly. NAT66 will break applications that many enterprises will already have blocked at their perimeters.
Re: quietly....
On Wed, Feb 2, 2011 at 8:55 AM, Iljitsch van Beijnum iljit...@muada.com wrote: On 2 feb 2011, at 17:14, Dave Israel wrote: I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done. So what if I want to assign different people to different resolvers by policy? For the record: I'm not saying that DHCPv6 is never useful. DHCPv6 is intended as a stateful configuration provisioning tool, i.e., to give different hosts different configurations. If that's what you need then DHCP fits the bill. However, in most small scale environments this is not what's needed so DHCP doesn't fit the bill. There are all sized enivronments. Political battles having partly crippled DHCPv6 in ways that end up significantly limiting IPv6 uptake into large enterprise organizations ... it's hard to describe how frustrating this is without resorting to thrown fragile objects against hard walls. As an active consultant to medium and large enterprises, this is driving me nuts. This single item is in my estimation contributing at least 6, perhaps 12 months to the worldwide average delay in IPv6 uptake. I know several organizations that would have been there six months ago had DHCPv6 not had this flaw. They're currently 6-12 months from getting there. This was predicted. That the right people didn't believe it suggests that perhaps the right people are the wrong people. Also, the examples mentioned are about enterprise networks with stable systems. Here, DHCP works well. However, with systems that connect to different networks, things don't always work so well. I may want to use the DHCP-provided NTP servers at work, but syncing with a random NTP server when I connect to a wifi hotspot is not such a great idea. That's a problem with insufficiently configurable network location profiles on your OS (not having a listen to DHCP NTP here, but not elsewhere button). -- -george william herbert george.herb...@gmail.com
Re: quietly....
On Feb 2, 2011, at 3:12 PM, Iljitsch van Beijnum wrote: On 2 feb 2011, at 20:37, John Payne wrote: DHCP fails because you can't get a default router out of it. If you consider that wrong, I don't want to be right. Hey, I thought you wanted ops input... Here you are getting it, and look, here all you are doing is saying that its wrong. I said the IETF wants input. In case you hadn't noticed, I'm not the IETF. I don't represent them in any way. I'm not even a working group chair. I've gone to a bunch of meetings, spent way too much time on IETF mailinglists and co-wrote all of one RFCs. You may not represent the IETF, but you are representative of the attitude of the IETF. I read some great writing advice once. It applies to much more than just writing. It goes like this: whenever a reader tells you that there's something wrong with your book, there is something wrong with your book. But if they tell you how to fix it, they're pretty much always wrong. There's something wrong with your attitude towards operators. There's a lot wrong with the IETF attitude towards operators, but you're here :) I'm not part of the DHC working group and I'm not a big DHCP user myself, so I don't claim to know the issues that exist with DHCPv6 in the operational community. But I'm sure there are some valid issues there. However, I'm equally sure that adding IPv4-DHCP-style router addresses to DHCPv6 is a big mistake that will create a lot of operational problems. Maybe not in the networks of the people that want this feature, but the problems will be there. Having machines listen to any RA they receive is _today_ a cause of a lot of operational problems. Why do we need mommy-IETF telling us no for default routes in DHCP but letting RAs run wild? Why does the mere mention of NAT cause daddy-IETF to round up the troops and insist that everyone is wrong?
Re: 2011.02.02 NANOG51 day 3 morning session notes
Josh ++ Geek Circus sets the bar. On Feb 2, 2011, at 1:34 PM, Mehmet Akcin meh...@akcin.net wrote: On Feb 2, 2011, at 11:52 AM, Matthew Petach wrote: Thanks again to Josh and Terremark for hosting another successful conference; would have loved to be able to join the party, but alas, lack of budget ruled that out this time around. +1 Josh / Bill , amazing job with hosting nanog. Mehmet
Re: quietly....
On Feb 2, 2011, at 11:42 AM, valdis.kletni...@vt.edu wrote: On Wed, 02 Feb 2011 07:45:46 -1000, Antonio Querubin said: On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: different networks, things don't always work so well. I may want to use the DHCP-provided NTP servers at work, but syncing with a random NTP server when I connect to a wifi hotspot is not such a great idea. It's not random if the network operator is providing it via DHCP is it? If you're connecting at a Starbuck's, and you care more than hopefully somebody will tell me the right time within a minute, yes, it *is* essentially random. While that is true, the people that are asking for the ability to advertise NTP servers in DHCP are not running the networks at Starbucks. Owen
Re: quietly....
On Feb 2, 2011, at 3:15 PM, George Herbert wrote: On Wed, Feb 2, 2011 at 8:55 AM, Iljitsch van Beijnum iljit...@muada.com wrote: On 2 feb 2011, at 17:14, Dave Israel wrote: I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done. So what if I want to assign different people to different resolvers by policy? For the record: I'm not saying that DHCPv6 is never useful. DHCPv6 is intended as a stateful configuration provisioning tool, i.e., to give different hosts different configurations. If that's what you need then DHCP fits the bill. However, in most small scale environments this is not what's needed so DHCP doesn't fit the bill. There are all sized enivronments. Political battles having partly crippled DHCPv6 in ways that end up significantly limiting IPv6 uptake into large enterprise organizations ... it's hard to describe how frustrating this is without resorting to thrown fragile objects against hard walls. As an active consultant to medium and large enterprises, this is driving me nuts. This single item is in my estimation contributing at least 6, perhaps 12 months to the worldwide average delay in IPv6 uptake. I know several organizations that would have been there six months ago had DHCPv6 not had this flaw. They're currently 6-12 months from getting there. Well, to be fair... In my decent sized enterprise, DHCPv6 and the lack of default route is irritating but not the blocker. The second largest OS we have doesn't support DHCPv6 at all, so its not like fixing the default route option is a magic bullet. So, we're going to have DHCP for IPv4 and SLAAC for IPv6 for now. DNS, NTP, etc will be done over IPv4 - no way around that. We have vendor struggles. The current pain is the lack of good support for VRRPv3. RA guard is another. However, IPv6 on the enterprise network will continue to be seen as an after thought until and unless we get parity.
Re: quietly....
On Wednesday, February 02, 2011 03:16:59 am Iljitsch van Beijnum wrote: A clear win. Of course it does mean that people gasp have to learn something new when adopting IPv6. Ever hear of intellectual inertia? The more that has to be learned to go a new path, the less likely that path will be chosen if another path still works, or can be made work with incremental changes. There's already too much new to learn, and not as many available hours or people to learn it. put on op hat What I want is to add an IPv6 subnet or subnets to my already tuned DHCP server config, add IPv6 addresses to the addresses handed out (in the same config clause as the IPv4 addresses are stored, preferably), update the DHCP server software to IPv6-capability, restart the DHCP server, and both IPv4 and IPv6 clients get what they need, through the same already locked down channels, with no other upgrades required. Takes what, thirty minutes per DHCP server if you're slow? Instead, I'll have to completely relearn how dynamic allocation works, learn about and protect against a new attack vector, learn about and deploy new hardware and software more than likely, and in general pull my hair out debugging new code and new platforms and so I'll be inclined to keep what works and bandaid it until it cannot be bandaided any more. Sorry, but those are the operational facts of life. take off op hat IPv6's uptake has been slow because it is too different, IMO, and thus intellectual inertia (in the complete Newtonian physics sense of the word) kicks in. IPv4 is a huge mass moving at a large velocity, and the delta force vector to adjust course is too great for many to swallow. It doesn't seem that different until you add all those pesky little details up. Try that exercise one day, and add up *all* the differences that operators have to know and implement to go IPv6, and balance that against smaller staffs and smaller budgets.
Re: quietly....
On 2 feb 2011, at 21:18, John Payne wrote:
Having machines listen to any RA they receive is _today_ a cause of a lot of
operational problems.
You should have come to the IETF 10 or even 5 years ago. It's too late now, one
day before the global pool of IPv4 addresses runs out. IPv6 is what it is.
There will be more tinkering but if you think there's enough time to wait for
your pet feature to be standardized and implemented widely, you're sorely
mistaken.
Why do we need mommy-IETF telling us no for default routes in DHCP but
letting RAs run wild?
Why does the mere mention of NAT cause daddy-IETF to round up the troops and
insist that everyone is wrong?
Because IPv4-style DHCP often breaks because the DHCP server points to the
wrong router address and because NAT breaks end-to-end connectivity so severe
workaround in applications become necessary. But you knew that.
On 2 feb 2011, at 21:15, George Herbert wrote:
it's hard to describe how
frustrating this is without resorting to thrown fragile objects
against hard walls.
Ok, I know I'm going to regret this, but:
Can you explain what exactly the problems with DHCPv6 are that you're running
into that are inherent to DHCP and/or IPv6 host configuration and won't be
fixed by bringing IPv4 ethernet switch features to IPv6?
On 2 feb 2011, at 21:18, Owen DeLong wrote:
If you're connecting at a Starbuck's, and you care more than hopefully
somebody will tell me the right time within a minute, yes, it *is*
essentially
random.
While that is true, the people that are asking for the ability to advertise
NTP servers in DHCP are not running the networks at Starbucks.
But whatever the IETF comes up with needs to work at Starbucks as well as
enterprise networks, everything else you can think of and then some you can't.
On 2 feb 2011, at 21:36, Lamar Owen wrote:
put on op hat
What I want is to add an IPv6 subnet or subnets to my already tuned DHCP
server config, add IPv6 addresses to the addresses handed out (in the same
config clause as the IPv4 addresses are stored, preferably), update the DHCP
server software to IPv6-capability, restart the DHCP server, and both IPv4
and IPv6 clients get what they need, through the same already locked down
channels, with no other upgrades required.
You can do that today. For instance, this is what I have in a test setup.
(However, the ISC dhcpd can only do either v4 or v6, not both at the same time.)
subnet6 2001:960:7bf:d::/64
{
option dhcp6.name-servers 2001:1af8:2:5::2;
option dhcp6.domain-search bonjour.muada.nl;
range6 2001:960:7bf:d::1000 2001:960:7bf:d::1fff;
}
Of course there are some subtleties such as the fact that some IPv6 systems
don't support DHCPv6 so you also need stateless autoconfig if you want to be
able to use those, and some (all?) routers automatically enable stateless
autoconfig and don't tell hosts to use DHCP. But that can be fixed with two
lines of config.
Instead, I'll have to completely relearn how dynamic allocation works, learn
about and protect against a new attack vector
You also get to stop worrying about a few old ones.
It doesn't seem that different until you add all those pesky little details
up. Try that exercise one day, and add up *all* the differences that
operators have to know and implement to go IPv6, and balance that against
smaller staffs and smaller budgets.
I did this for routing. I can explain everything you need to know about how to
run IPv6 BGP, RIP and OSPF in an hour and a half. Did that at a RIPE meeting
some years ago. Setting up Apache to use IPv6 is one line of config. BIND two
or three (not counting IPv6 reverse zones).
There are some good books on running IPv6, you know. :-)
Re: quietly....
On Wed, 2 Feb 2011 15:18:55 -0500 John Payne j...@sackheads.org wrote: On Feb 2, 2011, at 3:12 PM, Iljitsch van Beijnum wrote: On 2 feb 2011, at 20:37, John Payne wrote: DHCP fails because you can't get a default router out of it. If you consider that wrong, I don't want to be right. Hey, I thought you wanted ops input... Here you are getting it, and look, here all you are doing is saying that its wrong. I said the IETF wants input. In case you hadn't noticed, I'm not the IETF. I don't represent them in any way. I'm not even a working group chair. I've gone to a bunch of meetings, spent way too much time on IETF mailinglists and co-wrote all of one RFCs. You may not represent the IETF, but you are representative of the attitude of the IETF. And I'm afraid you're representative of the IPv4 thinking attitude, that seems to believe that the past IPv4 ways are not just the only ways of solving a problem but are also naturally the best. They also seem assume that the way IPv6 is going to be used is exactly the same as IPv4, so the IPv4 methods will be perfect in all IPv6 applications. It's a bit of a shame that people who've gotten into networking in the last 10 to 15 years haven't studied or worked with anything more than IPv4. They've missed out on seeing a variety of different ways to solve the same types of problems and therefore been exposed to the various benefits and trade-offs of the different methods. With that sort of exposure, people may find out that there are other better ways to solve problems, but IPv4's limitations and constraints prevented them being possible. I read some great writing advice once. It applies to much more than just writing. It goes like this: whenever a reader tells you that there's something wrong with your book, there is something wrong with your book. But if they tell you how to fix it, they're pretty much always wrong. There's something wrong with your attitude towards operators. There's a lot wrong with the IETF attitude towards operators, but you're here :) I'm not part of the DHC working group and I'm not a big DHCP user myself, so I don't claim to know the issues that exist with DHCPv6 in the operational community. But I'm sure there are some valid issues there. However, I'm equally sure that adding IPv4-DHCP-style router addresses to DHCPv6 is a big mistake that will create a lot of operational problems. Maybe not in the networks of the people that want this feature, but the problems will be there. Having machines listen to any RA they receive is _today_ a cause of a lot of operational problems. Why do we need mommy-IETF telling us no for default routes in DHCP but letting RAs run wild? Why does the mere mention of NAT cause daddy-IETF to round up the troops and insist that everyone is wrong?
Re: quietly....
In a message written on Wed, Feb 02, 2011 at 09:55:30PM +0100, Iljitsch van Beijnum wrote: On 2 feb 2011, at 21:18, John Payne wrote: Having machines listen to any RA they receive is _today_ a cause of a lot of operational problems. You should have come to the IETF 10 or even 5 years ago. It's too late now, one day before the global pool of IPv4 addresses runs out. IPv6 is what it is. There will be more tinkering but if you think there's enough time to wait for your pet feature to be standardized and implemented widely, you're sorely mistaken. I went to the IETF ~5 years and argued about the problems with RA's and the lack of things like a default route in DHCP. I had working group chairs tell me You're an operator, you don't know what you're talking about, and clearly don't understand IPv6. After a few months of bashing my head against that abuse I gave up. This problem will now be solved by vendors, when operators put up cash. The solutions will be far uglier than if it was designed properly, and the IETF will fade even further into irrevelance. Because IPv4-style DHCP often breaks because the DHCP server points to the wrong router address and because NAT breaks end-to-end connectivity so severe workaround in applications become necessary. But you knew that. FUD, plain and simple. DHCP does not often break, it's used by probably hundreds of millions of devices every day, mostly without problem. In fact, in my short time with IPv6 I've had several orders of magnitude more breakage with RA's than with DHCP. Actual operational experience. Try telling that to IETF folks though, and they are convinced you're just an idiot rather than trying to understand what happens when the rubber meets the road. Can you explain what exactly the problems with DHCPv6 are that you're running into that are inherent to DHCP and/or IPv6 host configuration and won't be fixed by bringing IPv4 ethernet switch features to IPv6? I love this question, because it basically admits the protocol is broken. To make RA's even remotely palitable, you need RA Guard on the switches. This feature does not exist, but if we bring features like DHCP guard forward into the IPv6 world, it's the logical solution and solves the problem. However, to the IETF people who think this, they just don't understand how many networks are built and run. Let's split the problem space. Ther are folks who say run hotel or dorm networks and need to protect from bad, bad users. For them DHCP guard, RA guard, BotNet guard, and all sorts of other features need to be in the switches. However, there are a lot of corporate network users where there really is no rogue DHCP server. Perhaps they are even using 802.1x on end user ports, so there are no rogue users at all. However, they do need a robust networking configuration. I'll give the simple scenario I've done to myself twice. Went to a remote site. Replaced the router with a new router. Took the old router back to the office and plugged it in so I could upgrade the code. IPv6 stopped working instantly. IPv4 kept working just fine, forever. Why? Well, the router from the other site sends out RA's as soon as it is plugged in, and all the hosts believe it and sink traffic to it. On the IPv4 side it was a DHCP HELPER. Let me repeat that, it's the part the IETF folks always miss. IT WAS A DHCP HELPER. A box on the network goes to do a DHCP request. It goes to the actual router, and to this rogue remote office router. However, being not configured correctly the rogue router's DHCP helper points to a default route out a WAN interface that is down, and the packet is dropped. No response, the host gets a response from the real router and all is well. The mere act of plugging in a old router takes down IPv6, but leaves IPv4 working just fine. I'd say that's a LOT less robust. Rather than give me IPv6 DHCP that works like IPv4, and thus would be just as robust, the IVTF, the vendors making the decisions, want me to deploy RA guard, which ooops, isn't on any of the old switches so you'll have to replace all of them. Basically, as an operator, the vendors got together, developed a broken protocol, figured out a work-around that requires me to replace everything. Or in short, the vendors figured out how to make me replace everything. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpLZ8gEX3naO.pgp Description: PGP signature
