Question on routing of Tata AS6453 with their other network AS4755
Hello everyone I was looking around and noticed a pretty bad route from DTAG to Tata AS6453 (basically destination was Tata Comm's Indian network on AS4755). I am not able to understand cause for inefficient routing but I am sure I am failing to understand something which is crazy in their IGP. The result is that route from Europe to India is via Europe > US > Singapore > India rather then direct India. There seem to be quite a few prefixes with these problem, but for this mail question, I am picking two prefixes - one which seems to be having good routing. 202.54.82.0/24 has pretty bad routing while 93.183.28.0/24. I see both prefixes have valid route objects and are originated by VSNL AS4755 to Tata AS6453 in India. Now if we compare trace from Tata's own core router say in Paris from their looking glass, I get: Router: gin-pye-core1 Site: FR, Paris, PYE Command: traceroute ip 202.54.82.1 Tracing the route to RAS55.1.ppppun.vsnl.net.in (202.54.82.1) 1 if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 525297 Exp 0] 300 msec if-0-0-0-0.tcore1.PYE-Paris.as6453.net (80.231.154.37) [MPLS: Label 525297 Exp 0] 260 msec if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 525297 Exp 0] 260 msec 2 if-5-2.tcore1.L78-London.as6453.net (80.231.130.1) [MPLS: Label 523604 Exp 0] 264 msec if-3-6.tcore1.L78-London.as6453.net (80.231.130.85) [MPLS: Label 523604 Exp 0] 256 msec if-5-2.tcore1.L78-London.as6453.net (80.231.130.1) [MPLS: Label 523604 Exp 0] 264 msec 3 if-2-2.tcore2.L78-London.as6453.net (80.231.131.1) [MPLS: Label 728466 Exp 0] 264 msec * if-1-2.tcore2.L78-London.as6453.net <http://if-1-2.tcore2.L78-London.as6453.net> (80.231.130.122) [MPLS: Label 728466 Exp 0] 264 msec 268 msec* * 4 if-20-2.tcore2.NYY-NewYork.as6453.net <http://if-20-2.tcore2.NYY-NewYork.as6453.net> (216.6.99.13) [MPLS: Label 354225 Exp 0] 276 msec 260 msec 260 msec* 5 * if-12-6.tcore1.CT8-Chicago.as6453.net (216.6.99.46) [MPLS: Label 365409 Exp 0] 304 msec if-11-2.tcore1.NYY-NewYork.as6453.net (216.6.99.2) [MPLS: Label 782881 Exp 0] 256 msec 6 if-22-2.tcore2.CT8-Chicago.as6453.net (64.86.79.1) [MPLS: Label 361921 Exp 0] 264 msec 264 msec if-1-2.tcore1.PDI-PaloAlto.as6453.net (66.198.127.5) [MPLS: Label 670352 Exp 0] 256 msec 7 if-11-3.tcore2.PDI-PaloAlto.as6453.net (66.198.144.57) [MPLS: Label 321233 Exp 0] 256 msec if-2-2.tcore2.PDI-PaloAlto.as6453.net (66.198.127.2) [MPLS: Label 321233 Exp 0] 260 msec * 8 if-9-2.tcore1.TV2-Tokyo.as6453.net (180.87.180.18) 280 msec 260 msec 260 msec 9 if-2-2.tcore2.TV2-Tokyo.as6453.net (180.87.180.2) [MPLS: Label 581761 Exp 0] 252 msec 252 msec 252 msec 10 if-6-2.tcore1.SVW-Singapore.as6453.net (180.87.12.109) [MPLS: Label 710034 Exp 0] 248 msec 244 msec 248 msec 11 if-5-2.tcore1.CXR-Chennai.as6453.net (180.87.12.54) 244 msec 272 msec 252 msec 12 180.87.36.10 272 msec 256 msec 272 msec 13 172.31.19.94 272 msec 252 msec 256 msec 14 * * 172.25.83.142 288 msec 15 172.25.83.134 !H * * while for other prefix, route is: Router: gin-pye-core1 Site: FR, Paris, PYE Command: traceroute ip 93.183.28.1 Tracing the route to 93.183.28.1 1 if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 519713 Exp 0] 12 msec if-0-0-0-0.tcore1.PYE-Paris.as6453.net (80.231.154.37) [MPLS: Label 519713 Exp 0] 12 msec if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 519713 Exp 0] 12 msec 2 if-8-1600.tcore1.WYN-Marseille.as6453.net (80.231.217.5) [MPLS: Label 302880 Exp 0] 12 msec if-14-2.tcore1.WYN-Marseille.as6453.net (80.231.154.170) [MPLS: Label 302880 Exp 0] 36 msec if-8-1600.tcore1.WYN-Marseille.as6453.net (80.231.217.5) [MPLS: Label 302880 Exp 0] 12 msec *3 if-2-2.tcore2.WYN-Marseille.as6453.net <http://if-2-2.tcore2.WYN-Marseille.as6453.net> (80.231.217.2) 12 msec 12 msec 12 msec* 4 80.231.200.26 140 msec 116 msec 116 msec 5 172.31.16.193 148 msec 140 msec 144 msec * 6 115.114.71.133.static-chennai.vsnl.net.in <http://115.114.71.133.static-chennai.vsnl.net.in> (115.114.71.133) [AS 4755] 140 msec 148 msec 140 msec* 7 172.29.209.82 [MPLS: Labels 301664/7167 Exp 1] 148 msec 144 msec 148 msec 8 172.31.35.138 [MPLS: Labels 4831/7167 Exp 1] 152 msec 152 msec 148 msec 9 121.242.126.205.static-chennai.vsnl.net.in (121.242.126.205) [AS 4755] [MPLS: Label 7167 Exp 1] 148 msec * 140 msec 10 121.242.126.206.static-chennai.vsnl.net.in (121.242.126.206) [AS 4755] 140 msec 148 msec 140 msec 11 * * * 12 * * * Now if I focus on best route entry in router for both prefixes, I see following: Bad Prefix: 4755 tv2-tcore1. (metric 16148) from *hk2-core3.* (hk2-core3.) Origin IGP, valid, internal, best Community: Originator: 66.110.10.113 Good Prefix: 4755 wyn-tcore2. (metric 10050) *from wyn-tcore2.* (66.110.10.109) Origin IGP, valid, internal, best Community: Now as I understand Paris router is getting bad prefix from TV2 which is their Tokyo router while for other prefix with good routing, route is via their other router on cable landing station in France. Can someone explain me what exactly is happening here? Are they missing some iBGP sessions? It's not perfect mesh & missing route reflectors? Probably both prefixes are originated inside India by different routers but as I understand all prefixes get transit from AS6453 and so is it like AS6453 missing some routes (which seem to be direct) to technically downstream AS4755? Curious to hear your thoughts. Note: I am not worried about issue - it's not really impacting me. Just trying to learn what is wrong in the backbone design here. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia> Skype: anuragbhatia.com
We have a ticket open with Tata currently on a similar issue. Traffic from our AS (51088) via Tata to DTAG goes from Amsterdam, NL, to Tata Frankfurth, Germany, to Tata Paris, France, to DTAG In Paris, back to Germany ?? With packetloss... Our Tinet (GT-T) routes go from Amsterdam to DTAG ( Amsterdam) to Germany .. No reply on the ticket yet where the packetloss comes from or why they are routing via Paris which adds about 30 ms ... Check out our Smokeping page for it .. http://smokeping.a2b-internet.com/smokeping/smokeping.cgi?target=LatencyChec... We are currently pref'ing the traffic to DTAG via Tinet/ GT-T. Erik Bais A2B Internet Verstuurd vanaf mijn iPad Op 16 nov. 2013 om 20:49 heeft Anurag Bhatia <me@anuragbhatia.com> het volgende geschreven:
Hello everyone
I was looking around and noticed a pretty bad route from DTAG to Tata AS6453 (basically destination was Tata Comm's Indian network on AS4755). I am not able to understand cause for inefficient routing but I am sure I am failing to understand something which is crazy in their IGP. The result is that route from Europe to India is via Europe > US > Singapore > India rather then direct India.
There seem to be quite a few prefixes with these problem, but for this mail question, I am picking two prefixes - one which seems to be having good routing.
202.54.82.0/24 has pretty bad routing while 93.183.28.0/24. I see both prefixes have valid route objects and are originated by VSNL AS4755 to Tata AS6453 in India. Now if we compare trace from Tata's own core router say in Paris from their looking glass, I get:
Router: gin-pye-core1 Site: FR, Paris, PYE Command: traceroute ip 202.54.82.1
Tracing the route to RAS55.1.ppppun.vsnl.net.in (202.54.82.1)
1 if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 525297 Exp 0] 300 msec if-0-0-0-0.tcore1.PYE-Paris.as6453.net (80.231.154.37) [MPLS: Label 525297 Exp 0] 260 msec if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 525297 Exp 0] 260 msec 2 if-5-2.tcore1.L78-London.as6453.net (80.231.130.1) [MPLS: Label 523604 Exp 0] 264 msec if-3-6.tcore1.L78-London.as6453.net (80.231.130.85) [MPLS: Label 523604 Exp 0] 256 msec if-5-2.tcore1.L78-London.as6453.net (80.231.130.1) [MPLS: Label 523604 Exp 0] 264 msec 3 if-2-2.tcore2.L78-London.as6453.net (80.231.131.1) [MPLS: Label 728466 Exp 0] 264 msec * if-1-2.tcore2.L78-London.as6453.net <http://if-1-2.tcore2.L78-London.as6453.net> (80.231.130.122) [MPLS: Label 728466 Exp 0] 264 msec 268 msec* * 4 if-20-2.tcore2.NYY-NewYork.as6453.net <http://if-20-2.tcore2.NYY-NewYork.as6453.net> (216.6.99.13) [MPLS: Label 354225 Exp 0] 276 msec 260 msec 260 msec* 5 * if-12-6.tcore1.CT8-Chicago.as6453.net (216.6.99.46) [MPLS: Label 365409 Exp 0] 304 msec if-11-2.tcore1.NYY-NewYork.as6453.net (216.6.99.2) [MPLS: Label 782881 Exp 0] 256 msec 6 if-22-2.tcore2.CT8-Chicago.as6453.net (64.86.79.1) [MPLS: Label 361921 Exp 0] 264 msec 264 msec if-1-2.tcore1.PDI-PaloAlto.as6453.net (66.198.127.5) [MPLS: Label 670352 Exp 0] 256 msec 7 if-11-3.tcore2.PDI-PaloAlto.as6453.net (66.198.144.57) [MPLS: Label 321233 Exp 0] 256 msec if-2-2.tcore2.PDI-PaloAlto.as6453.net (66.198.127.2) [MPLS: Label 321233 Exp 0] 260 msec * 8 if-9-2.tcore1.TV2-Tokyo.as6453.net (180.87.180.18) 280 msec 260 msec 260 msec 9 if-2-2.tcore2.TV2-Tokyo.as6453.net (180.87.180.2) [MPLS: Label 581761 Exp 0] 252 msec 252 msec 252 msec 10 if-6-2.tcore1.SVW-Singapore.as6453.net (180.87.12.109) [MPLS: Label 710034 Exp 0] 248 msec 244 msec 248 msec 11 if-5-2.tcore1.CXR-Chennai.as6453.net (180.87.12.54) 244 msec 272 msec 252 msec 12 180.87.36.10 272 msec 256 msec 272 msec 13 172.31.19.94 272 msec 252 msec 256 msec 14 * * 172.25.83.142 288 msec 15 172.25.83.134 !H * *
while for other prefix, route is:
Router: gin-pye-core1 Site: FR, Paris, PYE Command: traceroute ip 93.183.28.1
Tracing the route to 93.183.28.1
1 if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 519713 Exp 0] 12 msec if-0-0-0-0.tcore1.PYE-Paris.as6453.net (80.231.154.37) [MPLS: Label 519713 Exp 0] 12 msec if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 519713 Exp 0] 12 msec 2 if-8-1600.tcore1.WYN-Marseille.as6453.net (80.231.217.5) [MPLS: Label 302880 Exp 0] 12 msec if-14-2.tcore1.WYN-Marseille.as6453.net (80.231.154.170) [MPLS: Label 302880 Exp 0] 36 msec if-8-1600.tcore1.WYN-Marseille.as6453.net (80.231.217.5) [MPLS: Label 302880 Exp 0] 12 msec *3 if-2-2.tcore2.WYN-Marseille.as6453.net <http://if-2-2.tcore2.WYN-Marseille.as6453.net> (80.231.217.2) 12 msec 12 msec 12 msec* 4 80.231.200.26 140 msec 116 msec 116 msec 5 172.31.16.193 148 msec 140 msec 144 msec * 6 115.114.71.133.static-chennai.vsnl.net.in <http://115.114.71.133.static-chennai.vsnl.net.in> (115.114.71.133) [AS 4755] 140 msec 148 msec 140 msec* 7 172.29.209.82 [MPLS: Labels 301664/7167 Exp 1] 148 msec 144 msec 148 msec 8 172.31.35.138 [MPLS: Labels 4831/7167 Exp 1] 152 msec 152 msec 148 msec 9 121.242.126.205.static-chennai.vsnl.net.in (121.242.126.205) [AS 4755] [MPLS: Label 7167 Exp 1] 148 msec * 140 msec 10 121.242.126.206.static-chennai.vsnl.net.in (121.242.126.206) [AS 4755] 140 msec 148 msec 140 msec 11 * * * 12 * * *
Now if I focus on best route entry in router for both prefixes, I see following:
Bad Prefix: 4755 tv2-tcore1. (metric 16148) from *hk2-core3.* (hk2-core3.) Origin IGP, valid, internal, best Community: Originator: 66.110.10.113
Good Prefix: 4755 wyn-tcore2. (metric 10050) *from wyn-tcore2.* (66.110.10.109) Origin IGP, valid, internal, best Community:
Now as I understand Paris router is getting bad prefix from TV2 which is their Tokyo router while for other prefix with good routing, route is via their other router on cable landing station in France.
Can someone explain me what exactly is happening here? Are they missing some iBGP sessions? It's not perfect mesh & missing route reflectors?
Probably both prefixes are originated inside India by different routers but as I understand all prefixes get transit from AS6453 and so is it like AS6453 missing some routes (which seem to be direct) to technically downstream AS4755?
Curious to hear your thoughts.
Note: I am not worried about issue - it's not really impacting me. Just trying to learn what is wrong in the backbone design here.
Thanks. --
Anurag Bhatia anuragbhatia.com
Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia> Skype: anuragbhatia.com
On Nov 16, 2013, at 11:49 AM, Anurag Bhatia <me@anuragbhatia.com> wrote:
Hello everyone
I was looking around and noticed a pretty bad route from DTAG to Tata AS6453 (basically destination was Tata Comm's Indian network on AS4755). I am not able to understand cause for inefficient routing but I am sure I am failing to understand something which is crazy in their IGP. The result is that route from Europe to India is via Europe > US > Singapore > India rather then direct India.
<snip> I think you'll find that these decisions are intentional and driven by the cost of routes headed direct over land from EU to India. Ask Tata for a price quote for transit internet services in the EU and, separately, for transit internet in the EU that go direct from EU to India. They are not the same price. Regards, Mike
Heu Michael But this time AS4755 wasn't their customer. It's their own network in India! I think probably it will be hard for us and in general for technical community to comment on business side of it but I am just curious on technical side on what it is like that? Is it missing iBGP sessions or just intentional filtering of a group of prefixes via a peer group or based on some community tag? Thanks. On Sun, Nov 17, 2013 at 11:16 PM, Michael Smith <mksmith@mac.com> wrote:
On Nov 16, 2013, at 11:49 AM, Anurag Bhatia <me@anuragbhatia.com> wrote:
Hello everyone
I was looking around and noticed a pretty bad route from DTAG to Tata AS6453 (basically destination was Tata Comm's Indian network on AS4755). I am not able to understand cause for inefficient routing but I am sure I am failing to understand something which is crazy in their IGP. The result is that route from Europe to India is via Europe > US > Singapore > India rather then direct India.
<snip>
I think you'll find that these decisions are intentional and driven by the cost of routes headed direct over land from EU to India. Ask Tata for a price quote for transit internet services in the EU and, separately, for transit internet in the EU that go direct from EU to India. They are not the same price.
Regards,
Mike
-- Anurag Bhatia anuragbhatia.com Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia> Skype: anuragbhatia.com
On Nov 18, 2013, at 3:01 AM, Anurag Bhatia <me@anuragbhatia.com> wrote:
Heu Michael
But this time AS4755 wasn't their customer. It's their own network in India!
I think probably it will be hard for us and in general for technical community to comment on business side of it but I am just curious on technical side on what it is like that? Is it missing iBGP sessions or just intentional filtering of a group of prefixes via a peer group or based on some community tag?
It's hard to tell what the right answer is without the prefix and diagnosing the problem from multiple locations. Collecting data from various looking glasses in multiple cities and regions is always helpful to triangulate what is going on. - Jared
participants (4)
-
Anurag Bhatia -
Erik Bais -
Jared Mauch -
Michael Smith