Crossed Routing Tables (cycle in traceroute) - TCP-IP

This is a discussion on Crossed Routing Tables (cycle in traceroute) - TCP-IP ; Hello, I have what I think can be described as 2 routers that have references to each other in their routing tables. I am calling this "Crossed Routing Tables". If there is a better description please correct me. But, I ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Crossed Routing Tables (cycle in traceroute)

  1. Crossed Routing Tables (cycle in traceroute)

    Hello,

    I have what I think can be described as 2 routers that have references
    to each other in their routing tables. I am calling this "Crossed
    Routing Tables". If there is a better description please correct me.
    But, I will say that this is a guess because all I have is the
    evidence of what is happening.

    I am in the USA (New York) at the moment and if I execute a traceroute
    to 61.91.200.175 I get the following output:

    traceroute to 61.91.200.175 (61.91.200.175), 64 hops max, 40 byte
    packets
    1 10.0.1.1 (10.0.1.1) 1.205 ms 1.295 ms 1.080 ms
    2 10.35.128.1 (10.35.128.1) 8.317 ms 9.475 ms 15.200 ms
    3 pos0-2-nycmnyd-rtr1.nyc.rr.com (24.29.100.149) 9.617 ms 8.557
    ms 7.975 ms
    4 pos10-0-nycmnya-rtr2.nyc.rr.com (24.29.97.38) 9.977 ms 7.525 ms
    8.750 ms
    5 * * tenge-3-0-0.nycsnyoo-rtr1.nyc.rr.com (24.29.119.114) 12.325
    ms
    6 so-1-1-0.c0.buf00.twc-core.net (66.109.1.101) 9.402 ms 9.184 ms
    10.693 ms
    7 ae-1-0.p0.nyc90.twc-core.net (66.109.1.26) 10.505 ms 11.112 ms
    13.075 ms
    8 40.ecr1.nyk.cw.net (198.32.118.40) 10.663 ms 11.538 ms 11.543
    ms
    9 so-2-0-0-dcr2.tsd.cw.net (195.2.10.110) 85.138 ms 87.158 ms
    86.946 ms
    10 as0-dcr1.tsd.cw.net (195.2.10.165) 88.999 ms 86.117 ms 85.468
    ms
    11 cattele-gw3.tsd.cw.net (166.63.211.142) 316.757 ms 316.547 ms
    317.225 ms
    12 202.47.253.151 (202.47.253.151) 313.734 ms 324.837 ms 316.351
    ms
    13 61.19.10.6 (61.19.10.6) 335.256 ms 345.008 ms 388.107 ms
    14 203-144-144-26.static.asianet.co.th (203.144.144.26) 812.899 ms
    330.564 ms 360.610 ms
    15 203-144-162-147.static.asianet.co.th (203.144.162.147) 333.649
    ms 511.785 ms 384.283 ms
    16 61-91-251-126.static.asianet.co.th (61.91.251.126) 360.701 ms
    346.998 ms 327.327 ms
    17 61-91-251-121.static.asianet.co.th (61.91.251.121) 348.275 ms
    723.881 ms 328.420 ms
    18 61-91-184-202.static.asianet.co.th (61.91.184.202) 367.926 ms
    800.821 ms 330.691 ms
    19 203-144-254-54.static.asianet.co.th (203.144.254.54) 345.763 ms
    550.358 ms 350.642 ms
    20 210-86-223-41.static.asianet.co.th (210.86.223.41) 351.757 ms
    331.119 ms 372.181 ms
    21 203-144-254-54.static.asianet.co.th (203.144.254.54) 333.365 ms
    353.855 ms 328.997 ms
    22 210-86-223-41.static.asianet.co.th (210.86.223.41) 330.758 ms
    380.594 ms 329.446 ms
    23 203-144-254-54.static.asianet.co.th (203.144.254.54) 327.324 ms
    389.548 ms 349.877 ms
    24 210-86-223-41.static.asianet.co.th (210.86.223.41) 332.757 ms
    350.824 ms 329.011 ms

    The cycling between 203.144.254.54 and 210.86.223.41 continues until
    the "64 max hops" has been reached.

    According to ARIN/APNIC, these 2 machines are owned by True Internet
    Co., Ltd. based in Bangkok Thailand. I have carried on an extensive
    email conversation with True Internet Co and they say basically that
    there is no problem, yet, the traceroute gives a completely different
    story. My friends in Chiang Mai Thailand cannot get many of their
    communications packages to work with people outside of Thailand and I
    told them that I would take a look at the issue and let them know what
    I found (the dest IP of the traceroute is from a machine in Chiang
    Mai). The short story is that I immediately found this apparent cycle
    and I am thinking that this could easily be the source of their
    difficulties.

    Bottomline, the problem persists AND the traceroute continues to show
    the cycle. And I do not know where to turn now. I am not sure that
    the emails that I sent to True Corp ever made it to anyone who would
    see this issue for what it is.

    If you can offer any advice on what the appropriate next steps should
    be to resolve this problem I would greatly appreciate it.

    Thanks!!

    Brian


  2. Re: Crossed Routing Tables (cycle in traceroute)

    In article <1187541399.746856.4250@k79g2000hse.googlegroups.co m>,
    BrianPlummer wrote:

    > Hello,
    >
    > I have what I think can be described as 2 routers that have references
    > to each other in their routing tables. I am calling this "Crossed
    > Routing Tables". If there is a better description please correct me.
    > But, I will say that this is a guess because all I have is the
    > evidence of what is happening.


    It's called a routing loop.

    >
    > I am in the USA (New York) at the moment and if I execute a traceroute
    > to 61.91.200.175 I get the following output:
    >
    > traceroute to 61.91.200.175 (61.91.200.175), 64 hops max, 40 byte
    > packets

    ....
    > 21 203-144-254-54.static.asianet.co.th (203.144.254.54) 333.365 ms
    > 353.855 ms 328.997 ms
    > 22 210-86-223-41.static.asianet.co.th (210.86.223.41) 330.758 ms
    > 380.594 ms 329.446 ms
    > 23 203-144-254-54.static.asianet.co.th (203.144.254.54) 327.324 ms
    > 389.548 ms 349.877 ms
    > 24 210-86-223-41.static.asianet.co.th (210.86.223.41) 332.757 ms
    > 350.824 ms 329.011 ms
    >
    > The cycling between 203.144.254.54 and 210.86.223.41 continues until
    > the "64 max hops" has been reached.


    I see the same thing, coming from Comcast in Massachusetts.

    >
    > According to ARIN/APNIC, these 2 machines are owned by True Internet
    > Co., Ltd. based in Bangkok Thailand. I have carried on an extensive
    > email conversation with True Internet Co and they say basically that
    > there is no problem, yet, the traceroute gives a completely different
    > story. My friends in Chiang Mai Thailand cannot get many of their
    > communications packages to work with people outside of Thailand and I
    > told them that I would take a look at the issue and let them know what
    > I found (the dest IP of the traceroute is from a machine in Chiang
    > Mai). The short story is that I immediately found this apparent cycle
    > and I am thinking that this could easily be the source of their
    > difficulties.


    It's possible that one of the machines is the CPE router for their
    customer. The problem may be that the aggregate network is being routed
    to the customer's network, but the subnet containing this address is
    down. If they don't configure the CPE properly, when this happens it
    will send the traffic back to its default gateway, and then it loops
    back, and so on.

    The CPE router needs a null route for their entire aggregate network to
    prevent this. In any case, there's nothing you or the ISP can do about
    it. And since it only happens when the destination subnet is
    unreachable, it's not really a serious problem for you (if they fix it
    you'll get a "Destination Unreachable" error instead of a timeout, but
    you still won't get to the server).

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  3. Re: Crossed Routing Tables (cycle in traceroute)

    On Aug 19, 6:35 pm, Barry Margolin wrote:
    > In article <1187541399.746856.4...@k79g2000hse.googlegroups.co m>,
    >
    > BrianPlummer wrote:
    > > Hello,

    >
    > > I have what I think can be described as 2 routers that have references
    > > to each other in their routing tables. I am calling this "Crossed
    > > Routing Tables". If there is a better description please correct me.
    > > But, I will say that this is a guess because all I have is the
    > > evidence of what is happening.

    >
    > It's called a routing loop.
    >
    >
    >
    >
    >
    >
    >
    > > I am in the USA (New York) at the moment and if I execute a traceroute
    > > to 61.91.200.175 I get the following output:

    >
    > > traceroute to 61.91.200.175 (61.91.200.175), 64 hops max, 40 byte
    > > packets

    > ...
    > > 21 203-144-254-54.static.asianet.co.th (203.144.254.54) 333.365 ms
    > > 353.855 ms 328.997 ms
    > > 22 210-86-223-41.static.asianet.co.th (210.86.223.41) 330.758 ms
    > > 380.594 ms 329.446 ms
    > > 23 203-144-254-54.static.asianet.co.th (203.144.254.54) 327.324 ms
    > > 389.548 ms 349.877 ms
    > > 24 210-86-223-41.static.asianet.co.th (210.86.223.41) 332.757 ms
    > > 350.824 ms 329.011 ms

    >
    > > The cycling between 203.144.254.54 and 210.86.223.41 continues until
    > > the "64 max hops" has been reached.

    >
    > I see the same thing, coming from Comcast in Massachusetts.
    >
    >
    >
    > > According to ARIN/APNIC, these 2 machines are owned by True Internet
    > > Co., Ltd. based in Bangkok Thailand. I have carried on an extensive
    > > email conversation with True Internet Co and they say basically that
    > > there is no problem, yet, the traceroute gives a completely different
    > > story. My friends in Chiang Mai Thailand cannot get many of their
    > > communications packages to work with people outside of Thailand and I
    > > told them that I would take a look at the issue and let them know what
    > > I found (the dest IP of the traceroute is from a machine in Chiang
    > > Mai). The short story is that I immediately found this apparent cycle
    > > and I am thinking that this could easily be the source of their
    > > difficulties.

    >
    > It's possible that one of the machines is the CPE router for their
    > customer. The problem may be that the aggregate network is being routed
    > to the customer's network, but the subnet containing this address is
    > down. If they don't configure the CPE properly, when this happens it
    > will send the traffic back to its default gateway, and then it loops
    > back, and so on.
    >
    > The CPE router needs a null route for their entire aggregate network to
    > prevent this. In any case, there's nothing you or the ISP can do about
    > it. And since it only happens when the destination subnet is
    > unreachable, it's not really a serious problem for you (if they fix it
    > you'll get a "Destination Unreachable" error instead of a timeout, but
    > you still won't get to the server).
    >
    > --
    > Barry Margolin, bar...@alum.mit.edu
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***



    >> The CPE router needs a null route for their entire aggregate network to
    >> prevent this. In any case, there's nothing you or the ISP can do about
    >> it. And since it only happens when the destination subnet is
    >> unreachable, it's not really a serious problem for you (if they fix it
    >> you'll get a "Destination Unreachable" error instead of a timeout, but
    >> you still won't get to the server).


    This paragraph I don't understand. Someone, somewhere has to be able
    to fix this...no? Additionally, I don't understand the "it's not a
    serious problem for you" comment. If packets are not making it to the
    destination, isn't that a "real" problem.

    Respectfully,
    Confused


  4. Re: Crossed Routing Tables (cycle in traceroute)

    In article <1187616507.892076.103910@w3g2000hsg.googlegroups.c om>,
    BrianPlummer wrote:

    > On Aug 19, 6:35 pm, Barry Margolin wrote:
    > > In article <1187541399.746856.4...@k79g2000hse.googlegroups.co m>,
    > >> The CPE router needs a null route for their entire aggregate network to
    > >> prevent this. In any case, there's nothing you or the ISP can do about
    > >> it. And since it only happens when the destination subnet is
    > >> unreachable, it's not really a serious problem for you (if they fix it
    > >> you'll get a "Destination Unreachable" error instead of a timeout, but
    > >> you still won't get to the server).

    >
    > This paragraph I don't understand. Someone, somewhere has to be able
    > to fix this...no? Additionally, I don't understand the "it's not a


    Yes, the owner of the destination network should be able to fix it.

    > serious problem for you" comment. If packets are not making it to the
    > destination, isn't that a "real" problem.


    If the destination network is down, you're not going to be able to get
    to the destination.

    As an analogy, if someone unplugs their phone and you try calling them,
    does it matter if you get ring-no-answer or an intercept saying "your
    call cannot be connected"? You're not going to be able to talk to them
    no matter what the symptom is.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  5. Re: Crossed Routing Tables (cycle in traceroute)

    On Aug 20, 7:39 pm, Barry Margolin wrote:
    > In article <1187616507.892076.103...@w3g2000hsg.googlegroups.c om>,
    >
    > BrianPlummer wrote:
    > > On Aug 19, 6:35 pm, Barry Margolin wrote:
    > > > In article <1187541399.746856.4...@k79g2000hse.googlegroups.co m>,
    > > >> The CPE router needs a null route for their entire aggregate network to
    > > >> prevent this. In any case, there's nothing you or the ISP can do about
    > > >> it. And since it only happens when the destination subnet is
    > > >> unreachable, it's not really a serious problem for you (if they fix it
    > > >> you'll get a "Destination Unreachable" error instead of a timeout, but
    > > >> you still won't get to the server).

    >
    > > This paragraph I don't understand. Someone, somewhere has to be able
    > > to fix this...no? Additionally, I don't understand the "it's not a

    >
    > Yes, the owner of the destination network should be able to fix it.
    >
    > > serious problem for you" comment. If packets are not making it to the
    > > destination, isn't that a "real" problem.

    >
    > If the destination network is down, you're not going to be able to get
    > to the destination.
    >
    > As an analogy, if someone unplugs their phone and you try calling them,
    > does it matter if you get ring-no-answer or an intercept saying "your
    > call cannot be connected"? You're not going to be able to talk to them
    > no matter what the symptom is.
    >
    > --
    > Barry Margolin, bar...@alum.mit.edu
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***


    Hi Barry,

    Thanks for taking the time to deal with this...I really appreciate
    it!!!

    First I'm clear on the "unplugged phone" analogy...this is simple.

    Now, that said, I'm fuzzy, in this case, on this idea of the
    "destination network being down". I know what it "means" to say this
    of course, but it does not apply here...at least I think it doesn't.
    The IP that I traceroute to is up and running and it would be "on the
    destination network"...no? So, it must be up... every time I have
    conducted this traceroute test I have checked with a friend in Chiang
    Mai to see 1. if his machine (WAP) is up and 2. if his WAP still has
    the same IP (and we actively check the IP each time to make sure that
    we don't 'muddy the waters').

    At present, the symptoms remain the same. The traceroute gives the
    same results and with some network applications the "user experience"
    is "choppy" (my friend's words). The key example he cites is Skype.
    When he contacts his friends outside of Thailand, his voice travels
    through to the "outside of Thailand" destination without a problem,
    but the callee's voice does not make it back to Thailand. Actually,
    it does come through but it is choppy and often "unintelligible" (my
    friend's words again). The only part of this description that I have
    a problem with is that "some" of the traffic bound for Thailand gets
    through at all. I would think, based on what I am seeing in the
    traceroute that none of the traffic should get through. But clearly
    this depends on "where" the friend outside of Thailand actually is
    because a gateway other than the one(s) that I am seeing could be in
    the mix.

    Bottomline, I'm going to be there in a few weeks and I'm going to be
    able to troubleshoot this issue from that end. I'm thinking that I
    should be able to "see" other details. I will let you know what I
    find.

    Thanks,
    Brian




  6. Re: Crossed Routing Tables (cycle in traceroute)

    In article <1187877211.135258.252110@l22g2000prc.googlegroups. com>,
    BrianPlummer wrote:

    > On Aug 20, 7:39 pm, Barry Margolin wrote:
    > > In article <1187616507.892076.103...@w3g2000hsg.googlegroups.c om>,
    > >
    > > BrianPlummer wrote:
    > > > On Aug 19, 6:35 pm, Barry Margolin wrote:
    > > > > In article <1187541399.746856.4...@k79g2000hse.googlegroups.co m>,
    > > > >> The CPE router needs a null route for their entire aggregate network to
    > > > >> prevent this. In any case, there's nothing you or the ISP can do about
    > > > >> it. And since it only happens when the destination subnet is
    > > > >> unreachable, it's not really a serious problem for you (if they fix it
    > > > >> you'll get a "Destination Unreachable" error instead of a timeout, but
    > > > >> you still won't get to the server).

    > >
    > > > This paragraph I don't understand. Someone, somewhere has to be able
    > > > to fix this...no? Additionally, I don't understand the "it's not a

    > >
    > > Yes, the owner of the destination network should be able to fix it.
    > >
    > > > serious problem for you" comment. If packets are not making it to the
    > > > destination, isn't that a "real" problem.

    > >
    > > If the destination network is down, you're not going to be able to get
    > > to the destination.
    > >
    > > As an analogy, if someone unplugs their phone and you try calling them,
    > > does it matter if you get ring-no-answer or an intercept saying "your
    > > call cannot be connected"? You're not going to be able to talk to them
    > > no matter what the symptom is.
    > >
    > > --
    > > Barry Margolin, bar...@alum.mit.edu
    > > Arlington, MA
    > > *** PLEASE post questions in newsgroups, not directly to me ***
    > > *** PLEASE don't copy me on replies, I'll read them in the group ***

    >
    > Hi Barry,
    >
    > Thanks for taking the time to deal with this...I really appreciate
    > it!!!
    >
    > First I'm clear on the "unplugged phone" analogy...this is simple.
    >
    > Now, that said, I'm fuzzy, in this case, on this idea of the
    > "destination network being down". I know what it "means" to say this
    > of course, but it does not apply here...at least I think it doesn't.
    > The IP that I traceroute to is up and running and it would be "on the
    > destination network"...no? So, it must be up... every time I have
    > conducted this traceroute test I have checked with a friend in Chiang
    > Mai to see 1. if his machine (WAP) is up and 2. if his WAP still has
    > the same IP (and we actively check the IP each time to make sure that
    > we don't 'muddy the waters').


    Can he get out to the Internet from that machine?

    >
    > At present, the symptoms remain the same. The traceroute gives the
    > same results and with some network applications the "user experience"
    > is "choppy" (my friend's words). The key example he cites is Skype.
    > When he contacts his friends outside of Thailand, his voice travels
    > through to the "outside of Thailand" destination without a problem,
    > but the callee's voice does not make it back to Thailand. Actually,
    > it does come through but it is choppy and often "unintelligible" (my
    > friend's words again). The only part of this description that I have
    > a problem with is that "some" of the traffic bound for Thailand gets
    > through at all. I would think, based on what I am seeing in the
    > traceroute that none of the traffic should get through. But clearly
    > this depends on "where" the friend outside of Thailand actually is
    > because a gateway other than the one(s) that I am seeing could be in
    > the mix.


    That's a possibility.

    What happens if he tries to traceroute to YOUR address? Can you post
    that?

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

+ Reply to Thread