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

In article <1187541399.746856.4250@k79g2000hse.googlegroups.c om>,
BrianPlummer <bplummer@hotmail.com> 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 ***

On Aug 19, 6:35 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <1187541399.746856.4...@k79g2000hse.googlegroups.c om>,
>
> BrianPlummer <bplum...@hotmail.com> 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

In article <1187616507.892076.103910@w3g2000hsg.googlegroups. com>,
BrianPlummer <bplummer@hotmail.com> wrote:

> On Aug 19, 6:35 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
> > In article <1187541399.746856.4...@k79g2000hse.googlegroups.c om>,
> >> 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 ***

On Aug 20, 7:39 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <1187616507.892076.103...@w3g2000hsg.googlegroups. com>,
>
> BrianPlummer <bplum...@hotmail.com> wrote:
> > On Aug 19, 6:35 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
> > > In article <1187541399.746856.4...@k79g2000hse.googlegroups.c om>,
> > >> 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

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

> On Aug 20, 7:39 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
> > In article <1187616507.892076.103...@w3g2000hsg.googlegroups. com>,
> >
> > BrianPlummer <bplum...@hotmail.com> wrote:
> > > On Aug 19, 6:35 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
> > > > In article <1187541399.746856.4...@k79g2000hse.googlegroups.c om>,
> > > >> 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 ***