February 2009 - Test - lists.nanog.org

Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
by Nuno Vieira - nfsi telecom 10 Feb '09

10 Feb '09

security by obscurity is not the way, everyone knows it. those guys will figure it out sooner or later (where later, might take ages). in the meanwhile, a lot have pseudo-secured networks thru triple-nat, quadruple-nat, multiple ipsec'd layered and so, and others live with the hammer in their suitcase for fixing things around when the clue is gone. often they forgot the neat webserver box that run's some strange software, which no one updates, and... in the end is the cheese hole around their network... but, in the other end, money talks, and bulls**t walks, so, we might be all wrong, and they might be right, who knows ? who cares anyway ? :-) --nvieira ----- "John Osmon" <josmon(a)rigozsaurus.com> wrote: > > It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says: > Implement IP address masquerading to prevent internal addresses > from > being translated and revealed on the Internet. Use technologies > that > implement RFC 1918 address space, such as port address translation > (PAT) > or network address translation (NAT) > > I know that some auditors want to hold people to that standard. > > I stopped working with the credit card people at that point...

1 0

Automatic Switches?
by Seth Mattinen 09 Feb '09

09 Feb '09

I hate to interrupt the IPv6 and RFC 1918 mega-threads... Does anyone know of a company that makes 208v (3-wire line-line ground, no neutral, 208v loads only, single phase) 30-60 amp automatic transfer switches with sub-30ms switching time? APC used to make the SU045X163 30A model, but it seems to have been discontinued and it's hard to find products that support 208v single phase. ~Seth

2 2

Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
by Scott Howard 09 Feb '09

09 Feb '09

On Sat, Feb 7, 2009 at 5:56 PM, Matthew Moyle-Croft <mmc(a)internode.com.au>wrote: > My issue is that customers have indicated that they feel statics are a > given for IPv6 and this would be a problem if I went from tens of thousands > of statics to hundreds of thousands of static routes (ie. from a minority to > all). Even injecting statics into But is this a general requirement, or just one from the types of people that are likely to be early adopters for IPv6? Go and ask those people who "feel statics are a given for IPv6" if they would prefer static or dynamic IPv4 addresses, and I suspect most/all of them will want the static there too. Now ask your average user the same question and see if you get the same answer. I don't see static for IPv6 as any more (or less?) of an operational requirement than for IPv4. Certain users will definitely require static address, just as they do for IPv4, and IMHO these should be handled in exactly the same way - the exact mechanism for which will vary from ISP to ISP. Scott.

3 2

Packet Loss between Qwest and Global Crossing
by Andris Kalnozols 09 Feb '09

09 Feb '09

This post to the NANOG list in the hope that an interested engineer from either Qwest or GBLX will act on the problem I have observed. I've identified a packet loss problem (10-15%) between Qwest and Global Crossing. From one end (HP), the partial traceroute is: traceroute to 68.85.190.221 (68.85.190.221), 30 hops max, 40 byte packets 1 lpagwb01-vlan151-phy.hpl.hp.com (192.6.19.2) 0.622 ms 0.378 ms 0.315 ms 2 * * * 3 * * * 4 65.115.64.25 (65.115.64.25) 1.380 ms 1.297 ms 1.233 ms 5 205.171.14.150 (205.171.14.150) 1.377 ms 1.385 ms 1.277 ms 6 67.14.34.14 (67.14.34.14) 1.955 ms 2.046 ms 1.962 ms 7 205.171.233.18 (205.171.233.18) 2.204 ms 2.204 ms 2.076 ms 8 63.146.26.42 (63.146.26.42) 5.937 ms 4.253 ms 4.574 ms 9 * COMCAST-IP-SERVICES-LLC.TenGigabitEthernet1-3.ar2.snv2.gblx.net (64.211.1.214) 21.942 ms 21.670 ms There's no packet loss until the `gblx.net' (64.211.1.214) is pinged. Coming from the other end (Comcast), the partial traceroute is: Tracing route to gundega.hpl.hp.com [192.6.19.190] over a maximum of 30 hops: 1 * * * Request timed out. 2 9 ms 7 ms 7 ms 68.85.190.221 3 8 ms 6 ms 6 ms 68.87.226.66 4 7 ms 6 ms 7 ms te-9-1-ur06.sanjose.ca.sfba.comcast.net [68.87.192.54] 5 9 ms 9 ms 11 ms te-0-3-0-4-ar01.oakland.ca.sfba.comcast.net [68.87.226.229] 6 11 ms 11 ms 11 ms pos-0-4-0-0-cr01.sacramento.ca.ibone.comcast.net [68.86.90.141] 7 13 ms 12 ms 13 ms pos-0-8-0-0-cr01.sanjose.ca.ibone.comcast.net [68.86.85.78] 8 14 ms 12 ms 12 ms TenGigabitEthernet3-1.ar1.snv2.gblx.net [64.214.174.109] 9 41 ms * 38 ms sjp-brdr-02.inet.qwest.net [63.146.26.41] Pinging from this direction, there no packet loss until the first Qwest router (63.146.26.41) is pinged. So it seems clear that the problem is between Qwest and Global Crossing. ------ Andris

3 3

Re: One /22 Two ISP no BGP
by Charles Regan 09 Feb '09

09 Feb '09

I'll explain. We are a small ISP on a very remote Island. We have a /22 from ARIN. We have a 20mbits pipe from ISP1 and 20mbits from ISP2. They are the only two we can get bandwidth. So we are stuck with ISP1 that doesn't support BGP. On Fri, Feb 6, 2009 at 12:48 PM, Azinger, Marla <marla.azinger(a)frontiercorp.com> wrote: > im curiouse. you probably had a reason for wanting to do that. So cant you find another ISP that will do what you want? > > Cheers > Marla > > -----Original Message----- > From: Charles Regan [mailto:charles.regan@gmail.com] > Sent: Friday, February 06, 2009 8:29 AM > To: nanog(a)nanog.org > Subject: One /22 Two ISP no BGP > > I want to advertise my /22 to two different ISP on different POP. > > I can't use BGP as ISP1 doesn't support it. > > Any suggestions ? > > Thanks, > Charles > >

7 6

FW: IPv6 delivery model to end customers
by Soucy, Ray 09 Feb '09

09 Feb '09

> For IOS, have you tried the command: > > int gi0/1 > ipv6 nd ra suppress I think this only applies to RA originating from the L3 interface in question... not an L2 interface. I could be mistaken. I'll have to poke at it.

2 1

Re: Private use of non-RFC1918 IP space
by Zaid Ali 09 Feb '09

09 Feb '09

I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 1. How do we migrate to a IPv6 stack on all servers and I am talking about the thousands of servers that exist on peoples network that run SaaS, Financial/Banking systems. 2. How do we make old applications speak IPv6? There are some old back-end systems that run core functions for many businesses out there that don't really have any upgrade path and I don't think people are thinking about this. >From a network perspective IPv6 adoption is just about doing it and executing with your fellow AS neighbors. The elephant in the room is the applications that ride on your network. Zaid ----- Original Message ----- From: "Roger Marquis" <marquis(a)roble.com> To: nanog(a)nanog.org Sent: Tuesday, February 3, 2009 9:39:33 AM GMT -08:00 US/Canada Pacific Subject: Re: Private use of non-RFC1918 IP space Stephen Sprunk wrote: > Patrick W. Gilmore wrote: >> Except the RIRs won't give you another /48 when you have only used one >> trillion IP addresses. > > Are you sure? According to ARIN staff, current implementation of policy > is that all requests are approved since there are no defined criteria > that would allow them to deny any. So far, nobody's shown interest in > plugging that hole in the policy because it'd be a major step forward if > IPv6 were popular enough for anyone to bother wasting it... Catch 22? From my experience IPv6 is unlikely to become popular until it fully supports NAT. Much as network providers love the thought of owning all of your address space, and ARIN of billing for it, and RFCs like 4864 of providing rhetorical but technically flawed arguments against it, the lack of NAT only pushes adoption of IPv6 further into the future. Roger Marquis

14 20

L3: Google from DC via the Netherlands?
by Peter Beckman 08 Feb '09

08 Feb '09

Seems strange. Had a partial outage on Verizon network this morning around 9:50am EST, then when it came back around 10:05am, google routed via the Netherlands. My guess is that there's some sort of routing problem making my fastest or least cost route go to the Netherlands, but I wanted to find out if there was an ongoing issue, or if the Netherlands simply now serves the US East Coast for google. Isn't there anything closer? Or is this just indicative of an ongoing L3 outage? I'm guessing it's cheaper/faster to get to Google somewhere in the US, but maybe someone on NANOG knows better than I do. HOST: octal.angryox.com Loss% Snt Last Avg Best Wrst StDev 1. tomato.angryox.com 0.0% 20 0.6 0.6 0.5 0.7 0.0 2. 10.1.41.15 0.0% 20 2.1 4.2 1.9 42.8 9.1 3. p4-2.lcr-02.washdc.verizon-g 0.0% 20 1.5 1.5 1.3 2.3 0.2 4. 130.81.29.218 0.0% 20 2.0 7.3 2.0 45.0 11.9 5. 0.so-1-2-0.xl4.iad8.alter.ne 0.0% 20 2.4 2.4 2.3 3.3 0.2 6. 0.ge-3-3-0.br2.iad8.alter.ne 0.0% 20 2.4 2.4 2.3 2.5 0.1 7. te-11-3-0.edge1.washington4. 0.0% 20 2.4 12.2 2.3 151.2 33.6 8. vlan99.csw4.washington1.leve 0.0% 20 3.1 7.3 3.0 15.0 4.3 9. ae-92-92.ebr2.washington1.le 0.0% 20 3.2 3.3 3.1 3.6 0.1 10. ae-42-42.ebr2.frankfurt1.lev 0.0% 20 94.1 94.4 93.7 104.0 2.3 11. ae-2-2.ebr1.dusseldorf1.leve 0.0% 20 106.1 100.6 95.8 107.0 4.1 12. ae-46-106.ebr2.dusseldorf1.l 0.0% 20 100.4 103.1 98.0 111.0 4.3 13. ae-41.ebr1.amsterdam1.level3 0.0% 20 107.2 99.9 94.4 107.7 5.7 14. ae-11-53.car1.amsterdam1.lev 0.0% 20 94.5 95.0 94.1 102.6 2.0 15. 212.72.42.14 0.0% 20 94.9 98.8 94.5 133.9 12.0 16. 209.85.254.250 0.0% 20 95.4 95.4 94.8 97.0 0.5 17. 72.14.233.114 0.0% 20 100.9 107.2 100.7 140.6 9.7 18. 209.85.255.166 0.0% 20 108.9 109.1 107.5 117.3 2.1 19. 209.85.255.110 5.0% 20 109.5 112.4 106.3 119.9 4.7 20. ew-in-f147.google.com 5.0% 20 107.9 108.0 107.5 108.9 0.3 Fri Feb 6 10:56:09 2009 Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. tomato.angryox.com 0.0% 8 0.6 0.6 0.5 0.6 0.0 2. 10.1.41.15 0.0% 8 2.1 2.4 2.1 3.3 0.4 3. P4-2.LCR-02.WASHDC.verizon-gni.net 0.0% 8 1.4 1.4 1.3 1.5 0.1 4. 130.81.29.218 0.0% 8 2.1 9.1 1.9 59.0 20.2 5. 0.so-1-2-0.XL4.IAD8.ALTER.NET 0.0% 8 2.4 2.4 2.3 2.6 0.1 0.so-6-1-0.XL4.IAD8.ALTER.NET 6. 0.ge-7-1-0.BR2.IAD8.ALTER.NET 0.0% 8 2.5 2.5 2.4 2.6 0.1 0.ge-3-3-0.BR2.IAD8.ALTER.NET 0.ge-5-1-0.BR2.IAD8.ALTER.NET 0.ge-7-0-0.BR2.IAD8.ALTER.NET 7. te-11-3-0.edge1.Washington4.level3.net 0.0% 7 2.4 6.0 2.3 27.2 9.4 8. vlan79.csw2.Washington1.Level3.net 0.0% 7 3.2 8.3 3.2 13.5 4.2 9. ae-72-72.ebr2.Washington1.Level3.net 0.0% 7 3.7 3.5 3.1 4.0 0.3 10. ae-44-44.ebr2.Frankfurt1.Level3.net 0.0% 7 94.5 94.9 94.4 97.2 1.0 11. ae-2-2.ebr1.Dusseldorf1.Level3.net 0.0% 7 106.2 100.7 96.4 106.7 4.6 12. ae-46-106.ebr2.Dusseldorf1.Level3.net 0.0% 7 107.6 106.1 100.1 108.9 3.0 13. ae-41.ebr1.Amsterdam1.Level3.net 0.0% 7 95.5 100.6 95.4 108.3 5.9 14. ae-11-55.car1.Amsterdam1.Level3.net 0.0% 7 95.3 95.8 94.4 98.7 1.5 15. GOOGLE-INC.car1.Amsterdam1.Level3.net 0.0% 7 97.0 96.7 96.5 97.0 0.2 16. 209.85.254.250 0.0% 7 102.0 97.0 95.7 102.0 2.2 17. 72.14.233.114 0.0% 7 107.5 104.8 101.5 107.5 2.7 209.85.248.79 18. 209.85.255.70 0.0% 7 109.8 109.1 107.9 110.3 0.8 72.14.239.123 209.85.255.166 209.85.255.20 19. 209.85.255.98 0.0% 7 118.3 114.9 109.7 120.2 4.6 209.85.255.102 209.85.255.110 20. ew-in-f103.google.com 0.0% 7 110.0 109.4 108.0 110.6 1.1 --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman(a)angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------

9 11

Seeking FIOS tech support with two (or more) brain cells
by Robert E. Seastrom 08 Feb '09

08 Feb '09

Hi folks, Does anyone know any kind of super-secret back door number for Verizon FIOS tech support for people-with-a-clue? I can hear the drool hitting the keyboard on the other end of the line and the confusion in the voice of the support rep when I try to get help with turning up a "business" (ha!) FIOS circuit with five static addresses on it. Things have sure gone downhill since they decided that a MOCA handoff was a good idea; I turned one of these up for another friend a year ago and it was 100% plug and chug... Before you flame me, yes, I tried the database on puck.nether.net to see if I could pull something off via that route, but no joy. -r

1 1

Re: 97.128.0.0/9 allocation to verizon wireless
by Brandon Butterworth 08 Feb '09

08 Feb '09

> 2) If one company is likely to need four more /8's, and there are now > 32 in the free pool man is IPv4 in trouble. It's going to happen soon enough anyway. > At this point it > would only take eight companies the size of verizon wireless to > exhaust the free pool WORLDWIDE. No matter how much effort we put > into reclaiming IPv4 space there's just no way to keep up with new > demand. If they were allowed to. At some point I hope (I've heard the RIRs are making plans) they'll be told "no, you can't roll out something that big as v4, that's enough infrastructure you can afford to build it as v6, the rest of the v4 is now only for smaller necessary v4 use". What is necessary v4 and the v6 only threshold can now be argued over while everyone else gets on with building v6 or big v4 NATs brandon

1 0