September 2012 - Test - lists.nanog.org

Rogers Contact ? Offlist please?
by Dennis Burgess 25 Sep '12

25 Sep '12

Region, Owen Sound, any technical contact for help with a fiber connection with slow/bursty uploads. ? Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition <http://www.wlan1.com/product_p/mikrotik%20book-2.htm> " Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 <tel:314-735-0270> Website: http://www.linktechs.net <http://www.linktechs.net/> - Skype: linktechs <skype:linktechs?call> -- Create Wireless Coverage's with www.towercoverage.com <http://www.towercoverage.com/> - 900Mhz - LTE - 3G - 3.65 - TV Whitespace 5-Day Advanced RouterOS Workshop - Oct 8th 2012 - St. Louis, MO, USA <http://www.wlan1.com/RouterOS_Training_p/5d-stl-training-oct2012.htm>

1 0

Re: Charter Blackholing AS29889
by Randy McAnally 25 Sep '12

25 Sep '12

On 09/25/2012 9:32 am, Randy McAnally wrote: > Hi guys (and sorry for the noise), Thanks to all those who replied as well as Charter's help we defermined uRPF between Charter and some of their peers were filtering ICMP packets making traceroutes appear dead. Compounded by the fact our test server was blocking certain ICMP packets. The issue appears to have been a non issue from the beginning. Carry on folks :) -- Randy McAnally

1 0

Re: Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
by Rajiv Asati (rajiva) 25 Sep '12

25 Sep '12

Adrian, MAP facilitates both IPv6 deployment and IPv4 address exhaustion without involving any CGN mess in the network. This allows the home networks to stay dual-stack, use IPv6 as possible, and resort to IPv4 if IPv6 is not feasible for the intended destinations. One could promote the intent being that as more and more traffic goes over IPv6, less and less IPv4 will be needed (thereby shrinking the reliance on IPv4 ports sharing). Note that MAP Translation mode (i.e. MAP-T) does not involve any encapsulation, so, any QoS or Security or LI or DPI or Caching needing access to Layer4 info (i.e. UDP/TCP ports) would work just fine anywhere in the network. In case of MAP-E (Encapsulation mode), layer4 info (i.e. UDP/TCP ports) is not available in the network (until at boundary of the network where decapsulation is done). > * The ISP's router to which the user connects being > able to route packets on routes that go beyond the > IP address and into the port number field of TCP/UDP. Nope. The routers still follow the dynamic IPv4 and IPv6 routing for packet forwarding. That is UNCHANGED. The routers (expected to the boundary routers/ASBR, not the PE routers connecting the users) must have to look at the ports for IPv4->IPv6 stateless translation. Once translated, routing lookup as usual. > * A CE router being instructed to constrain itself to > using a limited set of ports on the WAN side in its > NAT44 implementation. Indeed. And it is not much different from how it works today. Almost all CPEs (I.e. Residential routers) work with limited set of ports (typically 2000) for dynamic NAT44 anyway. Of course, when MAP is enabled, the range would no longer be the default (as is the case today), rather something that is assigned using DHCP or TR069. That's in the control plane. Cheers, Rajiv -----Original Message----- From: "nanog-request(a)nanog.org" <nanog-request(a)nanog.org> Reply-To: "nanog(a)nanog.org" <nanog(a)nanog.org> Date: Tuesday, September 25, 2012 12:08 AM To: "nanog(a)nanog.org" <nanog(a)nanog.org> Subject: NANOG Digest, Vol 56, Issue 84 >Date: Mon, 24 Sep 2012 22:42:46 +0100 >From: Mike Jones <mike(a)mikejones.in> >To: Adrian Bool <aid(a)logic.org.uk> >Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> >Subject: Re: Throw me a IPv6 bone (sort of was IPv6 ignorance) >Message-ID: > <CAAAas8H8ERETrcnn0TaFD3cNToAfpdy12G6goNP5e=2cYtH1bQ(a)mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >On 24 September 2012 21:11, Adrian Bool <aid(a)logic.org.uk> wrote: >> >>On 24 Sep 2012, at 17:57, Tore Anderson >><tore.anderson(a)redpill-linpro.com> wrote: >> >>>* Tore Anderson >>> >>>>I would pay very close attention to MAP/4RD. >>> >>>FYI, Mark Townsley had a great presentation about MAP at RIPE65 today, >>>it's 35 minutes you won't regret spending: >>> >>>https://ripe65.ripe.net/archives/video/5 >>>https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24 >>>-2012.pdf >> >>Interesting video; thanks for posting the link. >> >>This does seem a strange proposal though. My understanding from the >>video is that it is a technology to help not with the deployment of IPv6 >>but with the scarcity of IPv4 addresses. In summary; it simply allows a >>number of users (e.g. 1024) to share a single public IPv4 address. >> >>My feeling is therefore, why are the IPv4 packets to/from the end user >>being either encapsulated or translated into IPv6 - why do they not >>simply remain as IPv4 packets? >> >>If the data is kept as IPv4, this seems to come down to just two changes, >> >>* The ISP's router to which the user connects being able to route >>packets on routes that go beyond the IP address and into the port number >>field of TCP/UDP. >>* A CE router being instructed to constrain itself to using a limited >>set of ports on the WAN side in its NAT44 implementation. >> >>Why all the IPv6 shenanigans complicating matters? > >While you could do something similar without the encapsulation this >would require that every router on your network support routing on >port numbers, by using IPv6 packets it can be routed around your >network by existing routers. And it's not like anyone is going to be >deploying such a system without also deploying IPv6, so it's not >adding any additional requirements doing it that way. > >- Mike > > > >------------------------------ > >Message: 3 >Date: Mon, 24 Sep 2012 23:34:30 +0100 >From: Adrian Bool <aid(a)logic.org.uk> >To: "nanog(a)nanog.org" <nanog(a)nanog.org> >Subject: Re: Throw me a IPv6 bone (sort of was IPv6 ignorance) >Message-ID: <8BEEBCDA-B6FA-4407-BF95-E122B26F4916(a)logic.org.uk> >Content-Type: text/plain; charset=us-ascii > > >On 24 Sep 2012, at 22:42, Mike Jones <mike(a)mikejones.in> wrote: > >>While you could do something similar without the encapsulation this >>would require that every router on your network support routing on >>port numbers, > >Well, not really. As the video pointed out, the system was designed to >leverage hierarchy to reduce routing complexity. Using the hierarchy, >port number routing is only required at the level where a routes diverge >on a port basis - which if you're being sensible about such a deployment >would only be at the edge of the access layer. > >aid >

1 0

Charter Blackholing AS29889
by Randy McAnally 25 Sep '12

25 Sep '12

Hi guys (and sorry for the noise), It appears return traffic from Charter to our ASN is blackholed. According to all three of our upstreams they are delivering traffic but it's not coming back. Unfortunately I don't have a reverse traceroute (our emails to charter customers are bouncing) so I have no idea what transit path they are returning traffic on. I tried fiddling with our outbound paths to no avail. If someone on a Charter connection could shoot me a traceroute to 209.9.238.7 that would be great. Ultimately if someone from Charter is willing to help that would be awesome as well. Source IP: 209.9.238.7 (AS29889) Dest IP: 75.140.10.216 Via HE: [root@mon ~]# traceroute 75.140.10.216 traceroute to 75.140.10.216 (75.140.10.216), 30 hops max, 60 byte packets 1 209.9.238.1 (209.9.238.1) 0.551 ms 0.790 ms 0.512 ms 2 gige-g4-13.core1.ash1.he.net (216.66.0.225) 12.029 ms 12.094 ms 12.158 ms 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Via Abovenet: [root@mon ~]# traceroute 75.140.10.216 traceroute to 75.140.10.216 (75.140.10.216), 30 hops max, 60 byte packets 1 209.9.238.1 (209.9.238.1) 0.544 ms 0.540 ms 0.573 ms 2 208.185.24.1 (208.185.24.1) 0.206 ms 0.218 ms 0.200 ms 3 xe-4-2-0.er1.iad10.us.above.net (64.125.29.198) 0.228 ms 0.232 ms 0.215 ms 4 above-telia.iad10.us.above.net (64.125.13.158) 117.943 ms 117.958 ms 117.763 ms 5 las-bb1-link.telia.net (80.91.246.71) 62.157 ms 62.162 ms 62.189 ms 6 cco-ic-151505-las-bb1.c.telia.net (213.248.79.102) 72.780 ms 70.183 ms 70.151 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * -- Randy McAnally

1 0

RE: Google IP Contact
by Anders Hansen - DSV 25 Sep '12

25 Sep '12

Got in contact.. thx! Best regards, Anders Hansen Network Specialist Group IT - ITS, Communication Services DSV A/S Litauen Alle 4 P. O. Box 157 DK-2630 Taastrup +45 43 20 30 40 Tel. +45 43 20 42 59 Direct Tel. +45 25 41 76 73 Mobile anders.hansen(a)dsv.com<mailto:anders.hansen@dsv.com> www.dsv.com<http://www.dsv.com> From: Anders Hansen - DSV Sent: 25. september 2012 13:12 To: 'nanog(a)nanog.org' Subject: Google IP Contact If anyone from Google is reading this list, I would appreciate if you could contact me off-list. We've got some issues with one of our CIDR's being treated as German, and would very much like to have this corrected. Tried to report the problem online, but unfortunately without any effect. Best regards, Anders Hansen Network Specialist Group IT - ITS, Communication Services DSV A/S Litauen Alle 4 P. O. Box 157 DK-2630 Taastrup +45 43 20 30 40 Tel. +45 43 20 42 59 Direct Tel. +45 25 41 76 73 Mobile anders.hansen(a)dsv.com<mailto:anders.hansen@dsv.com> www.dsv.com<http://www.dsv.com>

1 0

Google IP Contact
by Anders Hansen - DSV 25 Sep '12

25 Sep '12

If anyone from Google is reading this list, I would appreciate if you could contact me off-list. We've got some issues with one of our CIDR's being treated as German, and would very much like to have this corrected. Tried to report the problem online, but unfortunately without any effect. Best regards, Anders Hansen Network Specialist Group IT - ITS, Communication Services DSV A/S Litauen Alle 4 P. O. Box 157 DK-2630 Taastrup +45 43 20 30 40 Tel. +45 43 20 42 59 Direct Tel. +45 25 41 76 73 Mobile anders.hansen(a)dsv.com<mailto:anders.hansen@dsv.com> www.dsv.com<http://www.dsv.com>

1 0

IPv6 Address allocation best practises for sites.
by John Mitchell 25 Sep '12

25 Sep '12

Question about what other service/network providers are doing in relation to allocation of addresses for websites. With IPv6 starting to trickle its way in, what is considered the industry best practise now for IP(v6) addresses bonded to websites. In the past the standard practise was to have a single IPv4 address shared between multiple sites using a name based virtual host directive in Apache/IIS, unless of course the site was SSL in which case it normally needed a IP of its own (unless you had a client who was happy to only support SSL on IE7+ browsers with SNI). Does the best practise switch to now using one IPv6 per site, or still the same one IPv6 for multi-sites? - Mitch

6 5

Throw me a IPv6 bone (sort of was IPv6 ignorance)
by Mark Radabaugh 25 Sep '12

25 Sep '12

The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? -- Mark Radabaugh Amplex mark(a)amplex.net 419.837.5015

15 23

Re: IPv6 Address allocation best practises for sites.
by Aleksi Suhonen 25 Sep '12

25 Sep '12

Morning, The way to allocate IPv6 addresses per website depends more on the technologies already in use at the hosting site. An existing hoster will move slowly to any alternative method. I predict a bigger, faster change in the way medium sized sites do load balancing. IPv6 allows hosters to go back to DNS round robin based load balancing, which still works much better than often reported. It became an unfashionable way to do things because there weren't enough IPv4 addresses for everyone to be doing it, but this limitation won't be an issue in IPv6. I had a customer case a couple of years back where the client tried it out and was amazed at the results. In that particular case each server announced 2 /128s to the closest router, one with a better metric and the other with a worse metric. So during failovers, one server got twice the normal traffic until that DNS entry was pulled from the round robin set. Said client went back to "the old ways" tho because they couldn't do the same thing on IPv4 and they didn't want to have two different load balancing methods for two different IP versions. They are very fervent believers in the KISS principle. They are now waiting and hoping for the IPv4 traffic to die down and IPv6 traffic to pick up so that they can start doing things on IPv6's terms instead. :-) Hoping against all odds that they won't have to wait long, -- Aleksi Suhonen / Axu TM Oy Internetworking Consulting Cellular: +358 45 670 2048 World Wide Web: www.axu.tm

1 0

Real world sflow vs netflow?
by David Hubbard 24 Sep '12

24 Sep '12

Can anyone on or off list give me some real world thoughts on sflow vs netflow for border routers? (multi-homed, BGP, straight v4 & v6 only for web hosting, no mpls, vpns, vlans, etc.) Finding it hard to decipher the vendor version of the answer to that question. We use netflow v9 currently but are considering hardware that would be sflow. We don't use it for billing purposes, mostly for spotting malicious remote hosts doing things like scans, spotting traffic such as weird ports in use in either direction that warrant further investigation, watching for ddos/dos destinations to act on mitigation, or investigating the nature of unusual levels of traffic on switch ports that set off alarms. I'm concerned things like port scans, etc. won't be picked up by the NMS if fed by sflow due to the sampling nature, or similar concern if 500 ssh connections by the same remote host are sampled as 1 connection, etc. Of course these concerns were put in my head by someone interested in me continuing to use equipment that happens to output netflow data, hence me wanting some real people answers. :-) Thanks!

15 34