- Test - lists.nanog.org

Re: trouble in Sprint land?
by Steven M. Bellovin 17 Jul '00

17 Jul '00

Steve Bellovin writes: >What is going on here? I've seen similar delays -- i.e., over 4 >seconds -- for several days now, though only during the day. It's also >not just the routers being slow about pings; round-trip to the >destination (www.law.cornell.edu, in this case) is over 5 seconds: I managed to delete the traceroute from my note. From other replies, it seems to affect folks who are going through UUnet to Sprint: traceroute to www.law.cornell.edu (128.253.22.200) from sigaba.research.att.com (135.207.23.169), 40 hops max, 40 byte packets 1 oden.research.att.com (135.207.31.1) 0.511 ms 0.545 ms 0.507 ms 2 opsec.research.att.com (135.207.1.2) 1.321 ms 1.178 ms 1.316 ms 3 192.20.225.225 (192.20.225.225) 3.429 ms 2.472 ms 3.297 ms 4 Serial1-1-1.GW1.EWR1.ALTER.NET (157.130.0.177) 9.495 ms 7.279 ms 29.985 ms 5 113.ATM2-0.XR1.EWR1.ALTER.NET (146.188.176.34) 10.142 ms 5.166 ms 3.784 ms 6 193.ATM7-0.XR1.NYC4.ALTER.NET (146.188.178.53) 5.283 ms 6.269 ms 4.283 ms 7 189.ATM11-0-0.BR1.NYC4.ALTER.NET (146.188.177.189) 71.224 ms 10.384 ms 200.119 ms 8 137.39.23.146 (137.39.23.146) 10.799 ms 5.844 ms 5.543 ms 9 sl-bb10-nyc-2-3-155M.sprintlink.net (144.232.8.221) 6.910 ms 6.153 ms 7.388 ms 10 sl-bb22-rly-13-0.sprintlink.net (144.232.9.226) 853.712 ms 861.250 ms 888.238 ms 11 sl-gw9-rly-9-0.sprintlink.net (144.232.7.254) 4891.870 ms 4958.808 ms * --Steve Bellovin

1 0

trouble in Sprint land?
by Steve Bellovin 17 Jul '00

17 Jul '00

What is going on here? I've seen similar delays -- i.e., over 4 seconds -- for several days now, though only during the day. It's also not just the routers being slow about pings; round-trip to the destination (www.law.cornell.edu, in this case) is over 5 seconds: PING www.law.cornell.edu (128.253.22.200): 56 data bytes 64 bytes from 128.253.22.200: icmp_seq=0 ttl=238 time=5116.59 ms 64 bytes from 128.253.22.200: icmp_seq=1 ttl=238 time=5174.68 ms 64 bytes from 128.253.22.200: icmp_seq=2 ttl=238 time=5200.65 ms 64 bytes from 128.253.22.200: icmp_seq=3 ttl=238 time=5163.74 ms 64 bytes from 128.253.22.200: icmp_seq=4 ttl=238 time=5062.49 ms 64 bytes from 128.253.22.200: icmp_seq=5 ttl=238 time=5075.5 ms 64 bytes from 128.253.22.200: icmp_seq=6 ttl=238 time=5112.46 ms 64 bytes from 128.253.22.200: icmp_seq=7 ttl=238 time=5205.24 ms 64 bytes from 128.253.22.200: icmp_seq=8 ttl=238 time=5228.75 ms --Steve Bellovin

1 0

Foot in my mouth
by Chris Cappuccio 17 Jul '00

17 Jul '00

http://www.directmag.com/content/newsline/main.html#81 The beginning of this article... "Yesmail.com, a Chicago-based permission marketer, won a temporary restraining order Thursday against Mail Abuse Prevention System LLC (MAPS) in the first legal challenge to the Redwood, CA-based group. Issued by the Northern District Court of Illinois (Eastern Division), the order blocks MAPS from adding yesmail to its list of alleged spammers. It is good through Aug. 2. A hearing has been scheduled for July 18."

1 0

RE: Wanted: Clueful Individual @ TeleGlobe.net
by Karyn Ulriksen 17 Jul '00

17 Jul '00

Out of curiousity, how does the telco world handle this? When some one signs up for MCI longdistance, I assume that on some calls they will cross off the MCI network (and potentially though several others) that will be piled mile high in static. The customers will complain about their connection to their respective local and long distance companies. But I believe it isn't an option to contact the networks that they may transit mid-stream. However, some QC must be in place to achieve some level of consistancy to get that expected "pin drop" quality we've apparently come to take for granted... Is it cooperation amongst the networks possibly? Cooperation among the NOC's seems in order wherever possible and I rarely run into uncooperative NOCs (unless I find myself in the sad state of being unreasonable). IMHO, it's probably asking too much for every network to answer to every Tom, Dick, & Harry when everyone is fighting for peering b/w, praying for equipment that lives up to expectations, filtering script kiddies, and keeping the typical high b/w access to less than $45.00/month. Of course, I could be wrong and accept that possibility. Karyn > -----Original Message----- > From: Troy Davis [mailto:troy@nack.net] > Sent: Sunday, July 16, 2000 12:44 AM > To: Derek J. Balling > Cc: nanog(a)nanog.org > Subject: Re: Wanted: Clueful Individual @ TeleGlobe.net > > > > On Sat, 15 Jul 2000, Derek J. Balling <dredd(a)megacity.org> wrote: > > > Sample snip from phone call: > > This mirrors my experience with the AT&T NOC on Friday after > seeing latency > between GlobalCenter and AT&T. The GlobalCenter NOC had no > problem opening a > ticket without caring whether I was a customer or not. They > spent a few hours > on it and said it appeared to be an over-loaded AT&T router. > > Not entirely sure of that - and if it was true, wanting to > see what AT&T > was doing about it - I called AT&T, was transferred 3 times > to reach the IP > folks, and was promptly stonewalled. > > The level 1 tech didn't know latency from Adam but wasn't > willing to find > someone who did. He said he couldn't open a ticket for a non-customer > and we argued for 10 minutes about what to do next - hang up > or talk to the > next guy up the chain. I convinced him that it was an actual > issue and that > he should indeed tell his boss - or maybe he just got tired > of talking. > > Anyhow, his boss came on the line and said the same thing, > emphasizing that > they couldn't open tickets for non-customers. Even informing > him that AT&T > customers were calling us to complain and that AT&T users > were affected > didn't help. This guy claimed to be the engineering manager > and said there > was nobody above him to go to. We talked for a while - 10-20 > minutes - and > apparantly he finally got tired too, since he took my name/number. > > A couple minutes later I got a call from a third guy there, > who said that > any issues were between AT&T and GlobalCenter and that I had > no business > calling. I asked if there was an open ticket or even someone > addressing it > and he had no idea. He didn't seem to know any more about > networking than the > first guy. > > The most discouraging part was that the last two people > understood that it was > a service-affecting problem and yet hadn't been given any > procedures to solve > it. It felt like I was asking a secretary - they all stated > that they > understood it was a problem but couldn't do a damn thing. > > I ended up sending a note to noc(a)att.net telling them the > problem, my support > story, and noting that their NOC folks couldn't do any of > these things (all of > which I asked to do): > - open a trouble ticket for a non-customer > - transfer me to someone who could > - transfer me to the IP engineers > - verify/deny that the problem was within AT&T (a > traceroute, perhaps?) > - call GlobalCenter and work on the ticket I had open with them > - provide me with an escalation or complaint path, > either for the original > problem or to complain about the NOC's useless procedures > > .. any of which would have been more useful than hanging up > and sending an > email. I still haven't received a reply or even an automated > ticket #. > > Cheers, > > Troy >

1 0

Re: Wanted: Clueful Individual @ TeleGlobe.net
by Me 17 Jul '00

17 Jul '00

Having worked at a large unnamed backbone provider, I agree with the reasoning behind not opening tickets for non-customers. That having been said however, it is inexcusable to ignore a possible problem on the network you are responisible for. When non-customers would call the NOC, I would listen to them, thank them for the heads up, and investigate the problem, at the same time letting them know I could not open a "customer" ticket on them. If there WAS a problem found(believe it or not, net everyone reporting a problem knew what they were talking about :> ), an internal ticket would be opened and worked as normal. -Sean me(a)mentzer.org

1 0

RE: piracy on parade
by Abrams, Chris 17 Jul '00

17 Jul '00

Agreed. -----Original Message----- From: Dmitri Krioukov [mailto:dima@krioukov.net] Sent: Friday, July 14, 2000 1:25 PM To: nanog(a)merit.edu Subject: RE: piracy on parade wouldn't it to be a right time to get list moderated? thanks, -- dima.

2 1

What Internet Service Providers Need to Know About the Law
by Sean Donelan 17 Jul '00

17 Jul '00

Next week Mark Eckenwiler, a real lawyer in the criminal division at the US Department of Justice, will be discussing "What Internet Service Providers Need to Know About the Law" at the Blackhat Conference in Las Vegas. I've dealt with Mark before. He knows both the legal and technical stuff. ISP or exchange point operators may want to send either a technical or legal person to get a better idea what the DOJ thinks ISPs should know. Its one of those rare opportunities to try to get real answers to those perpetual mailing list topics. I hope his talk doesn't get yanked by DOJ due to the current carnivore flap. http://www.blackhat.com/ for more information.

1 0

slashdot slashdotted?
by Sean Donelan 17 Jul '00

17 Jul '00

Is it only me, or is www.slashdot.org off the air? I've been trying to access it for the last hour or so with no response. I contacted their upstream ISP, but wondered if anyone else had heard anything.

3 3

Re: Path-MTU-discovery
by Richard A. Steenbergen 17 Jul '00

17 Jul '00

On Mon, 17 Jul 2000, Mikael Abrahamsson wrote: > On Mon, 17 Jul 2000, Patrick W. Gilmore wrote: > > > Wow, why would the ICMPs get lost? > > I think it's because of access lists etc. I am not the one who have > set it up so I do not know. We've had this problem from two different > companies (one for our national needs and one for our international > needs). The international one has solved it with what you mention > below. Wouldn't it be unfortunante if the script kiddies decided to do DoS over ICMP Need-Frag... This is a very bad situation we find ourselves in you realize? The quicker we find a way to get rid of this rather bad hack the better. Rate-limits of need-frag can help, but many people are still in a position where their filters leave need-frag wide open and they can't or aren't currently rate limiting. The PMTU-D blackhole detection-type checks help keep this current hack alive a little longer. I'm not currently aware of the extent to which various OS's implement this kind of thing, any ideas? -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: Path-MTU-discovery
by Patrick W. Gilmore 17 Jul '00

17 Jul '00

At 08:26 AM 7/17/00 +0200, Mikael Abrahamsson wrote: >On the other hand, at work we're doing some tunneling using ciscos. Due to >routing etc the ICMP "need-to-frag"-messages get lost and the people >behind those tunnels cannot use 90% of the www sites (so they have to >resort to proxies). Seems to me that PMTUd works better than most people >think. Wow, why would the ICMPs get lost? Also, cisco has a feature on tunnels now where the routers will frag & de-frag making the tunnel MTU effectively 1500 bytes (or whatever you set). >I do believe that NT and Win2k comes default with a registry setting that >makes it send all TCP traffic with the DF flag set (which I can see no >reason for unless M$ IP stack cannot do refragmentation properly). This >setting is changable as far as I know but I cannot seem to find the >information at this time. Anyone? I have no clue if that is really a setting. (Do not run any MS web servers.) However, end stations do not do fragmentation. They do re-assembly, but the receiving station has no control over whether something gets fragmented in transit to it. If the MTU of a path is less than, say, 1500, the end station just sends out smaller packets, not fragments. Since it is likely that you have visited an MS-power site, and you say you can reach all sites, then the MS IP-stack can probably send out packets < 1500 bytes long. If the setting you describe does exist (and it may very well considering MS' history), it is probably just another screw up from the world's black-hole for bad programmers. >Mikael Abrahamsson email: swmike(a)swm.pp.se TTFN, patrick

2 1