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.

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=LatencyCheckList.Tata_Paris

We are currently pref'ing the traffic to DTAG via Tinet/ GT-T.

Erik Bais
A2B Internet

<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.

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