RE: Severe Response Degradation
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
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. :) D
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. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
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 At 09:39 AM 4/28/99 -0400, Daniel Senie wrote:
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. :)
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
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. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."
Andrew Brown writes:
Daniel Senie writes:
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.
Hasn't this come up here before? I'm too lazy to go check the archive, but I seem to remember a discussion of this topic. IIRC, the reason/excuse given (lame or not) was that they use equipment that does not deal well/at all with CIDR or VLSM or somesuch. Or am I thinking of someone else? Not that I recall it being a widely accepted reason here. :-) --Jeff ObRandy: Cynical response regarding people simply complaining about that which they do not fully understand omitted.
Jeff Aitken wrote:
Andrew Brown writes:
Daniel Senie writes:
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.
Hasn't this come up here before? I'm too lazy to go check the archive, but I seem to remember a discussion of this topic. IIRC, the reason/excuse given (lame or not) was that they use equipment that does not deal well/at all with CIDR or VLSM or somesuch. Or am I thinking of someone else?
Well, all of their gear is Cisco. Last I checked, I think Cisco was OK with CIDR and VLSM, and even unnumbered links. As for the cluelessness statements, my take is that they've got some very clueful people, and some very clueless people. They've also got the inertia of a company many times their size. Perhaps that's appropriate, though, as they are now owned, at least in part, by AT&T (via the TCI deal). -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
well then, they're obviously clueless.
Hasn't this come up here before? I'm too lazy to go check the archive, but I seem to remember a discussion of this topic. IIRC, the reason/excuse given (lame or not) was that they use equipment that does not deal well/at all with CIDR or VLSM or somesuch. Or am I thinking of someone else?
Well, all of their gear is Cisco. Last I checked, I think Cisco was OK with CIDR and VLSM, and even unnumbered links.
perhaps they need to be told about "ip classless"?
As for the cluelessness statements, my take is that they've got some very clueful people, and some very clueless people. They've also got the inertia of a company many times their size. Perhaps that's appropriate, though, as they are now owned, at least in part, by AT&T (via the TCI deal).
no offense to the clueful then. the clueless won't notice. :) -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."
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>.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Derek Balling Sent: Wednesday, April 28, 1999 6:18 AM To: Derrick Bennett; 'nanog@merit.edu' Subject: RE: Severe Response Degradation
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. :)
D
participants (7)
-
Andrew Brown -
Daniel Senie -
ddiviniaï¼ broadcast.com -
Derek Balling -
Derrick Bennett -
Jeff Aitken -
Roeland M.J. Meyer