- Test - lists.nanog.org

NTT handing packets to Reliance (Flag Telecom) in California for BSNL block
by Anurag Bhatia 19 Jun '12

19 Jun '12

Hello everyone, I was trying to understand reason for high latency between my BSNL (AS9829) connection and a specific Germany based server on M-Online. I can see forward path is correct but reverse path is: traceroute to 117.200.57.47 (117.200.57.X), 30 hops max, 60 byte packets 1 gw.giga-dns.com (91.194.90.1) [AS51167] 0.929 ms 0.915 ms 1.151 ms 2 host-93-104-204-33.customer.m-online.net (93.104.204.33) [AS8767] 1.144 ms 1.370 ms 1.608 ms 3 xe-1-1-0.rt-decix-2.m-online.net (82.135.16.102) [AS8767] 8.334 ms 8.325 ms 8.559 ms 4 xe-1-1-0.rt-decix-2.m-online.net (82.135.16.102) [AS8767] 8.043 ms 213.198.72.237 (213.198.72.237) [AS2914] 8.289 ms xe-1-1-0.rt-decix-2.m-online.net (82.135.16.102) [AS8767] 8.023 ms 5 ae-2.r20.frnkge04.de.bb.gin.ntt.net (129.250.5.217) [AS2914] 77.508 ms 213.198.72.237 (213.198.72.237) [AS2914] 7.773 ms 7.768 ms 6 ae-1.r23.amstnl02.nl.bb.gin.ntt.net (129.250.3.179) [AS2914] 15.726 ms xe-1-1-3.r20.frnkge04.de.bb.gin.ntt.net (129.250.5.221) [AS2914] 9.195 ms ae-3.r22.londen03.uk.bb.gin.ntt.net (129.250.3.137) [AS2914] 43.581 ms 7 ae-1.r23.amstnl02.nl.bb.gin.ntt.net (129.250.3.179) [AS2914] 15.876 ms xe-1-1-3.r20.frnkge04.de.bb.gin.ntt.net (129.250.5.221) [AS2914] 42.557 ms 42.534 ms 8 ae-7.r21.asbnva02.us.bb.gin.ntt.net (129.250.2.144) [AS2914] 108.990 ms 101.966 ms ae-0.r23.nycmny01.us.bb.gin.ntt.net (129.250.3.73) [AS2914] 90.236 ms 9 ae-2.r21.lsanca03.us.bb.gin.ntt.net (129.250.3.55) [AS2914] 167.662 ms ae-1.r20.asbnva02.us.bb.gin.ntt.net (129.250.2.9) [AS2914] 131.915 ms ae-7.r21.asbnva02.us.bb.gin.ntt.net (129.250.2.144) [AS2914] 99.925 ms 10 ae-0.r20.asbnva02.us.bb.gin.ntt.net (129.250.4.4) [AS2914] 131.452 ms ae-2.r04.lsanca03.us.bb.gin.ntt.net (129.250.5.70) [AS2914] 162.135 ms 171.360 ms 11 ae-2.r21.lsanca03.us.bb.gin.ntt.net (129.250.3.55) [AS2914] 227.815 ms ae-2.r04.lsanca03.us.bb.gin.ntt.net (129.250.5.70) [AS2914] 160.347 ms ae-2.r21.lsanca03.us.bb.gin.ntt.net (129.250.3.55) [AS2914] 167.755 ms 12 ae-2.r04.lsanca03.us.bb.gin.ntt.net (129.250.5.70) [AS2914] 166.245 ms 172.954 ms 162.521 ms 13 xe-0-1-0-10.r04.lsanca03.us.ce.gin.ntt.net (198.172.90.222) [AS2914] 183.765 ms 183.748 ms 185.719 ms 14 115.249.245.201 (115.249.245.201) [AS18101] 322.389 ms 80.77.1.58 (80.77.1.58) [AS15412] 316.879 ms 218.248.255.57 (218.248.255.57) [AS9829] 315.371 ms 15 218.248.255.57 (218.248.255.57) [AS9829] 311.356 ms 311.584 ms 115.249.245.201 (115.249.245.201) [AS18101] 333.586 ms 16 218.248.173.41 (218.248.173.41) [AS9829] 359.339 ms 353.042 ms 354.021 ms 17 218.248.173.41 (218.248.173.41) [AS9829] 348.914 ms 344.156 ms 342.131 ms 18 * 218.248.173.41 (218.248.173.41) [AS9829] 354.091 ms * 19 * * * 20 * * * I can see from Reliance's Looking glass that there direct path from EU to India on their network. I wonder why exactly NTT handling off packets to Reliance in California? The problem seems only for BSNL block - 117.200.48.0/20. If destination is not BSNL and say Reliance itself...say for Monster.co.inweb server which is in Reliance datacenter: *Query Results:* *Router: *Amsterdam - NL *Command:* traceroute 220.226.205.30 *Disclaimer: Traceroute is a useful tool for determining the route a packet takes, but it should not be used as an accurate measure of network performance. For more information please view the Traceroute Disclaimer<https://ssp.pme.gin.ntt.net/lg/trDisclaimer.html> .* traceroute to 220.226.205.30 (220.226.205.30), 30 hops max, 40 byte packets 1 as-0.r22.amstnl02.nl.bb.gin.ntt.net (129.250.2.118) 15.806 ms 0.746 ms 0.718 ms MPLS Label=499040 CoS=0 TTL=1 S=0 MPLS Label=304400 CoS=0 TTL=1 S=1 2 ae-5.r23.londen03.uk.bb.gin.ntt.net (129.250.5.197) 8.180 ms 7.740 ms 8.770 ms MPLS Label=304400 CoS=0 TTL=1 S=1 3 ae-2.r02.londen03.uk.bb.gin.ntt.net (129.250.5.41) 16.229 ms 15.829 ms 16.326 ms 4 flagtelecom-0.r02.londen03.uk.bb.gin.ntt.net (83.231.235.238) 15.059 ms 16.032 ms 7.014 ms 5 62.216.128.106 (62.216.128.106) 8.332 ms 62.216.128.122 (62.216.128.122) 32.306 ms ge-0-0-3.0.cjr02.ldn004.flagtel.com (62.216.128.138) 9.051 ms MPLS Label=412816 CoS=0 TTL=1 S=1 6 so-1-0-0.0.pjr02.ldn001.flagtel.com (85.95.25.9) 8.616 ms so-1-0-0.0.pjr01.ldn001.flagtel.com (85.95.25.13) 19.806 ms ge-0-1-0.0.pjr01.ldn001.flagtel.com (62.216.129.137) 8.059 ms MPLS Label=300480 CoS=0 TTL=1 S=1 7 so-4-0-0.0.pjr01.mmb004.flagtel.com (85.95.25.113) 280.327 ms so-1-0-0.0.pjr02.mmb004.flagtel.com (85.95.25.138) 281.659 ms so-3-1-0.0-pjr02.mmb004-flagtel.com (85.95.26.158) 282.889 ms 8 62.216.147.138 (62.216.147.138) 285.101 ms 695.643 ms 62.216.147.46 (62.216.147.46) 278.537 ms Pretty much direct. I wonder what exactly is different/wrong in case of BSNL block 117.200.48.0/20? Is BSNL selectively announcing it only from Reliance's California based router and not any other router in Europe? Can somehow one can test & confirm the above guess of selective announcement? (*Apologize if I missed some fundamental glitch error. I am new to it.*) Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia>| Google+ <https://plus.google.com/118280168625121532854>

4 4

IPv6 day and tunnels
by Joe Maimon 19 Jun '12

19 Jun '12

Well, IPv6 day isnt here yet, and my first casualty is the browser on the wife's machine, firefox now configured to not query AAAA. Now www.facebook.com loads again. Looks like a tunnel mtu issue. I have not as of yet traced the definitive culprit, who is (not) sending ICMP too big, who is (not) receiving them, etc. www.arin.net works and worked for years. www.facebook.com stopped June 1. So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly? Or was the fix incorporating the breakage into the basic design? In IPv4 I can make tunneling just work nearly all of the time. So I have to munge a tcp mss header, or clear a df-bit, or fragment the encapsulated packet when all else fails, but at least the tools are there. And on the host, /proc/sys/net In IPv6, it seems my options are a total throwback, with the best one turning the sucker off. Nobody (on that station) needs it anyways. Joe

14 94

ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!
by Jay Ashworth 18 Jun '12

18 Jun '12

http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield… <sigh> Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

13 29

Re: Our first inbound email via IPv6 (was spam!)
by Livingood, Jason 18 Jun '12

18 Jun '12

On 6/17/12 1:18 PM, "Jason Roysdon" <nanog.20110127(a)jason.roysdon.net> wrote: >Jason, > >Will all MX get AAAA RRs, or at least all of your MX priority levels >have at least one AAAA RR? Without a failure of mx2 & mx3, Sendmail and >well-behaving mail servers are never going to try mx1. Yes, in the relatively near future. - Jason

1 0

Re: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!
by Roland Perry 18 Jun '12

18 Jun '12

In article <20120617095906.GA32028(a)vacation.karoshi.com.?>, bmanning(a)vacation.karoshi.com top-posts: Why not. Lots of aspects of the Internet are regulated. > Internet Regulator? > >/bill > > >On Sun, Jun 17, 2012 at 10:43:26AM +0100, Roland Perry wrote: >> In article <20120616160738.EEE097C4(a)resin05.mta.everyone.net>, Scott >> Weeks <surfer(a)mauigateway.com> writes >> >> >What is going to make folks change their behavior? >> >> If all else fails, perhaps a regulator fining the ISP $1000 for every >> allocation (I agree that whether it's IPv4 or IPv6 isn't relevant) where >> the WHOIS information is shown to be false or significantly out of date. >> >> They could send compliance teams in to check, just like the IRS does for >> the accounts. >> -- >> Roland Perry -- Roland Perry

1 0

Re: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!
by Scott Weeks 18 Jun '12

18 Jun '12

--- goemon(a)anime.net wrote: or you can fix the problem that has been festering for 10+ years. ----------------------------------- Yeah, that. Why make it seem that v6 is the problem when it isn't. scott

8 9

Re: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!
by Scott Weeks 18 Jun '12

18 Jun '12

--- vinny(a)abellohome.net wrote: From: Vinny Abello <vinny(a)abellohome.net> : It would seem to me if the if law enforcement is concerned about : incentives to make networks do this, then it should be made a law : within their operating jurisdiction to enforce this compliance. : This is a law enforcement problem and I feel it should be properly : solved by a legal solution, ------------------------------------------------------- Worst case solution. Guaranteed. scott

3 2

Re: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!
by Scott Weeks 17 Jun '12

17 Jun '12

--- jcurran(a)arin.net wrote: From: John Curran <jcurran(a)arin.net> With respect to updating Whois, it is true that many ISPs do not update their sub-delegations until applying for their next IPv4 block. Whether this is also the case with IPV6 or not remains to be seen, but given IPv6 allocation size, it would not be good. ---------------------------------------------------- What is going to make folks change their behavior? scott

6 6

Re: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!
by Scott Weeks 15 Jun '12

15 Jun '12

> On Fri, 15 Jun 2012 11:59:26 -0400, Jay Ashworth said: > > http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield… The article sure does have a lot of threatening and smack-down tones toward service providers (us): "We're looking at a problem that's about to occur,""It occurs as service providers start to roll out V6." Our fault, no one else's... ------------------------------------ "This is not a question of willful rejection,""ISPs are happy to do this. They're just lazy...It doesn't have a direct impact on them and their ability to get new address space because they don't need new address space." Yep, we're definitely the lazy ones. No one else. ------------------------------------ "We're hoping through all of this you can come up with some self-regulatory method in which you can do it," "Because otherwise, there will be other things that people are going to consider." That's definitely a threat. ------------------------------------- "We're hoping that people in the community seize the opportunity to work and to have that self-regulation, because, if not, if all of the different governments then get involved, it could get uglier." Yeah, that one, too. ------------------------------------- Yep, that's the kind of attitude that fosters community cooperation. Yep. That's it... scott

4 3

Re: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!
by Scott Weeks 15 Jun '12

15 Jun '12

>>> http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield… > > The article sure does have a lot of threatening and smack-down tones toward service providers (us): > > > > "We're looking at a problem that's about to occur,""It occurs as service providers start to roll out V6." > > Our fault, no one else's... > ------------------------------------ :: Who else would you blame for failing to update whois? -------------------------------------------------------- At the risk of 10k flamethrowers turning my way... It is no difference than in v4. Those that do in v4 will do in v6 and those that don't in v4 won't in v6, so why make v6 the culprit? That isn't helpful. <snip> :: Personally, I think that the article is counter-productive for the FBI in what they are trying to achieve. ---------------------------------------------------------- yes scott

2 1