NTT handing packets to Reliance (Flag Telecom) in California for BSNL block
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>
On Tue, Jun 19, 2012 at 4:15 PM, Anurag Bhatia <me@anuragbhatia.com> wrote:
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?
there's a fiber cut in that part of the world, and reliance is ... in the middle of it (smwe-4 I think?) maybe they decided that some of their customer traffic ought to take a less congested path?
Hello Christopher Thanks for pointing out SMW4 cut as reported here - http://www.renesys.com/blog/2012/06/smw4-break-on-south-asia.shtml As far as I see it is likely not linked to issue. I guess it is still some bad routing issue rather then impact of cable cut since I have seen similar issues in past (last few months). Thanks. On Wed, Jun 20, 2012 at 2:32 AM, Christopher Morrow <morrowc.lists@gmail.com
wrote:
On Tue, Jun 19, 2012 at 4:15 PM, Anurag Bhatia <me@anuragbhatia.com> wrote:
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?
there's a fiber cut in that part of the world, and reliance is ... in the middle of it (smwe-4 I think?) maybe they decided that some of their customer traffic ought to take a less congested path?
-- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia>| Google+ <https://plus.google.com/118280168625121532854>
I have also noticed that traffic sourced in NYC destined for Qatar across NTT seems to now go from NYC -> SJC -> SNG and ends up being about 180+ms longer than just going over the atlantic. I've seen this a few times (only with NTT routes). Thanks, -Drew -----Original Message----- From: Anurag Bhatia [mailto:me@anuragbhatia.com] Sent: Tuesday, June 19, 2012 4:15 PM To: NANOG Mailing List Subject: NTT handing packets to Reliance (Flag Telecom) in California for BSNL block 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>
On Tue, Jun 19, 2012 at 06:42:33PM -0400, Drew Weaver wrote:
I have also noticed that traffic sourced in NYC destined for Qatar across NTT seems to now go from NYC -> SJC -> SNG and ends up being about 180+ms longer than just going over the atlantic.
I've seen some people in the middle east/africa purchase services in Asia based on their business needs. In the case of NTT, this is likely the case as they are a decent sized player in Asia.
I've seen this a few times (only with NTT routes).
See below for some further insight....
Thanks, -Drew
-----Original Message----- From: Anurag Bhatia [mailto:me@anuragbhatia.com] Sent: Tuesday, June 19, 2012 4:15 PM To: NANOG Mailing List Subject: NTT handing packets to Reliance (Flag Telecom) in California for BSNL block
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 ... 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
.CE.GIN.NTT.NET is customer equipment. It appears they are preferring their customer route.
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.
It is going to their customer.
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.*)
I've seen cases where the packet goes around the world based on the networks involved. You can usually tell due to increased latency or looking at ping -R output. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
participants (4)
-
Anurag Bhatia -
Christopher Morrow -
Drew Weaver -
Jared Mauch