RE: Severe Response Degradation

Mailman List Mirror (Read Only)
1

This is what we are currently seeing. Unfortunately @Home does not do
reverse dns for their routers so I am going by their helpdesk's descriptions
of locations. I do know that the router is in SF but could not get an exact
location due to @home claiming it to be a sprint issue. This also brings
back the conversation of RFC1918 addressing and the problems it can cause
when troubleshooting response issues.

Since opening the ticket the response times are starting to get better (less
actual timeouts) but the normal ping of 30-40ms is definitely not there and
does severely suffer when more data intensive packets head that way. I still
am not sure about locations as @home does not publish any connectivity maps
that I have been able to get a hold of. From my traceroutes I would point
directly to @Home's router but do not have the ability hold them to this
fact which then makes it difficult when I go back and ask for allowances for
bad service on my circuits.

Tracing route to www.news.com [204.162.80.176]

over a maximum of 30 hops:

  3 <10 ms 10 ms <10 ms 10.252.25.37

  4 <10 ms 10 ms <10 ms 10.252.32.1

  5 141 ms 170 ms 170 ms 172.16.2.161 @Home locates this router
in SF as a Peer to Sprint

  6 160 ms 180 ms 181 ms mae-west.att.net [198.32.136.124]

  7 190 ms 180 ms 191 ms gr1-h30.sffca.ip.att.net [192.205.31.41]

  8 190 ms 180 ms 171 ms 12.127.1.193

  9 140 ms 151 ms 160 ms ar2-a300s1.sffca.ip.att.net [12.127.1.141]

10 111 ms 120 ms 110 ms 12.127.194.46

11 * 12.127.194.46 reports: Destination net unreachable.

Tracing route to www.yahoo.com [204.71.200.75]

over a maximum of 30 hops:

  3 <10 ms 10 ms <10 ms 10.252.25.37

  4 <10 ms 10 ms <10 ms 10.252.32.1

  5 170 ms 160 ms 140 ms 172.16.3.205 @Home locates this router in
SF as a Peer to Sprint

  6 150 ms 170 ms 160 ms 206.251.7.201

  7 141 ms 150 ms 140 ms 206.251.7.43

  8 90 ms 121 ms 120 ms 204.71.200.75

Trace complete.

Derrick Bennett

Quoted from Stephen:

Not that the problem doesn't exist, but ...

Sprint does not have a router (or any presence whatsoever) at PAIX. If

anyone at PAIX peers with Sprint from a router located at PAIX, they

must be buying a circuit to a Sprint POP to do it. Since Sprint has no

presence at PAIX, what do you mean by "affects many of the Sprint Net

peers in PAIX?"

Do you have a traceroute to support your assertion that the @Home

router in question is located at PAIX? (I don't know whether it is or

no, but none of the traceroutes into @Home that I do from my PAIX

routers show an @Home router numbered in 172.16.6 as a next hop.)

If there is a problem such as you describe, it's not affecting the

two PAIX routers I have that peer with @Home.

Stephen

2

This is what we are currently seeing. Unfortunately @Home does not do
reverse dns for their routers so I am going by their helpdesk's descriptions
of locations. I do know that the router is in SF but could not get an exact
location due to @home claiming it to be a sprint issue. This also brings
back the conversation of RFC1918 addressing and the problems it can cause
when troubleshooting response issues.

I haven't actually tried this, but I have been told that if you actually use @Home's DNS servers and query the RFC1918 addresses for the routers, it will give you back "intelligent" names.

All well and good for average-joe-weenie-@Home-user, but not very good for those of us not slaved to their DNS. :slight_smile:

D

3

Derek Balling wrote:

>This is what we are currently seeing. Unfortunately @Home does not do
>reverse dns for their routers so I am going by their helpdesk's descriptions
>of locations. I do know that the router is in SF but could not get an exact
>location due to @home claiming it to be a sprint issue. This also brings
>back the conversation of RFC1918 addressing and the problems it can cause
>when troubleshooting response issues.

I haven't actually tried this, but I have been told that if you actually
use @Home's DNS servers and query the RFC1918 addresses for the routers, it
will give you back "intelligent" names.

I've tried it, without success. If anyone finds a particular DNS server
in their realm which does resolve these, please let me know. They seem
to treat the info as trade secrets... very annoying.

Considering the large chunk of 24/8 they have, I can't imagine why they
had to use RFC 1918 addresses throughout their infrastructure. When I
raised issues about this (just after getting a T1 to their network),
they had no answers other than that since they chose an MTU of 1500
bytes for all their links, they didn't think path MTU discovery would be
an issue.

4

This one at least seems to work for 172.x.x.x addresses... fails horribly on 10.0.0.0/8 addresses though:

server 24.1.64.33

Default Server: proxy1.frmt1.sfba.home.com
Address: 24.1.64.33

172.16.4.38

Server: proxy1.frmt1.sfba.home.com
Address: 24.1.64.33

Name: bb1-hssi2-0-ds3.paix.home.net
Address: 172.16.4.38

That DNS server is the one I am "supposed" to point my home machine at (except that I find using REAL services as opposed to the ones @home offers gives me something better than "worthless" usability *grin*, so I don't ordinarily use them unless I absolutely have to).

D

Derek Balling wrote:
I've tried it, without success. If anyone finds a particular DNS server
in their realm which does resolve these, please let me know. They seem
to treat the info as trade secrets... very annoying.

Be nice if we could just harken a LITTLE back to the old Fidonet days, find their IP-assignment practice for routers "Excessively annoying" and excommunicate them. :slight_smile:

Considering the large chunk of 24/8 they have, I can't imagine why they
had to use RFC 1918 addresses throughout their infrastructure. When I
raised issues about this (just after getting a T1 to their network),
they had no answers other than that since they chose an MTU of 1500
bytes for all their links, they didn't think path MTU discovery would be
an issue.

That sounds about what I've come to expect. Its interesting since I live in Fremont, CA, where (if you hadn't heard) the City Council decided that "Hey, you provide service over cable... and cable is regulated... you're going to meet QoS standards or you're not going to provide cable service here either".

This coming after the City Council called TCI@Home support during a council meeting and was still on hold without having heard a human voice at the END of the meeting. A group of like 50 residents or so all came to the City Council meeting the same day TCI was getting fined for poor TV QoS (hold times, etc.), and made a loud stink about the Internet offering (hold time, ludicrous performance, etc.)

I think they might be able to get whacked with a very big Clue Stick, and it could be very painful for them.

I should note here that I actually do know at least one person in the @Home NOC (although not terribly well, but I'm at least acquainted with him) and he seemed to possess much clue. From what I can tell though, sadly, he's in the minority.

D

5

I haven't actually tried this, but I have been told that if you actually
use @Home's DNS servers and query the RFC1918 addresses for the routers, it
will give you back "intelligent" names.

I've tried it, without success. If anyone finds a particular DNS server
in their realm which does resolve these, please let me know. They seem
to treat the info as trade secrets... very annoying.

i tried it. it worked fine. dig home.net ns and try those. i just
axfr'ed

   168.192.in-addr.arpa (36 answers)
   10.in-addr.arpa (3770 answers)
   16.172.in-addr.arpa (926 records)
   17.172.in-addr.arpa (158 records)

from their ns2.home.net (24.2.0.27). they're not using the rest of
172.16/12. or, at least, don't have the reverse zones set up.

Considering the large chunk of 24/8 they have, I can't imagine why they
had to use RFC 1918 addresses throughout their infrastructure. When I
raised issues about this (just after getting a T1 to their network),
they had no answers other than that since they chose an MTU of 1500
bytes for all their links, they didn't think path MTU discovery would be
an issue.

well then, they're obviously clueless.

6

I have tried it, and forgotten about it, should have mentioned it. This works. The problem is that you need a node to traceroute to first. But y'all already have that <grin>.