March 2003 - Test - lists.nanog.org

Re: cw to att? issue?
by Scott Granados 13 Mar '03

13 Mar '03

It actually looked like it was farther in the att network, after cw's peer the next hop after cw's peer. I just tried the trace again and it seems better. Cw seems to be handing off to att at a different point in santaclara now not sanfrancisco which seemed to help. Again though it looked like att was the issue because cw looked fine up tntil one hop after cw ended. On Wed, 12 Mar 2003, IP-GNOC wrote: > No issues to report, probably a return path issue. It'd be easier to > confirm that with a traceroute showing the latency. And you will get a > timely response from noc(a)cw.net, which is where this email belongs. > > Regards, > Mark Kasten > Cable & Wireless > > > Scott Granados wrote: > > >Anyone else seeing an issue between cw and att somewhere near sf it looks > >like. > > > >I go from 4 ms, at the point tagged as the peer between cw and att and > >1400 ms once I land on att. > > > >THanks > > > > > > > > > > > >

6 6

RE: att.net domain expired
by Ejay Hire 13 Mar '03

13 Mar '03

I is/am/was incorrect. It is amazing how the internet empowers one to make a fool of himself in front of an audience of thousands. The domain is not expired, I am unable to count to 2003, and the outage was due to an unknown dns error. (Maybe somebody is moving a server to 69/8? :) ) -Ejay -----Original Message----- From: Ejay Hire [mailto:ejay.hire@isdn.net] Sent: Thursday, March 13, 2003 2:46 AM To: nanog(a)merit.edu Subject: att.net domain expired Hello all. Expect some calls from people who can't reach *.att.net. The att.net domain has expired and is in Verisign's new "not working and not for sale" hold queue. -Ejay Registrant: AT&T Corp. (ATT2-DOM) 55 Corporate Drive null US Domain Name: ATT.NET Administrative Contact, Technical Contact: GNMC (VXGTRUVDOO) rm-hostmaster(a)ems.att.com <mailto:rm-hostmaster@ems.att.com> GNMC 3324 Hollenberg Bridgeton, MO 63044 US 314-264-9672 fax: 281-664-9975 >>>>>>> Record expires on 14-Dec-2003. Record created on 13-Dec-1993. Database last updated on 13-Mar-2003 03:25:00 EST. Domain servers in listed order: ORCU.OR.BR.NP.ELS-GMS.ATT.NET 199.191.129.139 WYCU.WY.BR.NP.ELS-GMS.ATT.NET 199.191.128.43 OHCU.OH.MT.NP.ELS-GMS.ATT.NET 199.191.144.75 MACU.MA.MT.NP.ELS-GMS.ATT.NET 199.191.145.136

1 0

RE: Gender and other protocol issues
by Todd A. Blank 12 Mar '03

12 Mar '03

Speaking of Gender and Protocol, I think this whole gender bias thing can be solved by implementing an LDAP server.... Sorry - wrong thread... -----Original Message----- From: Cutler, James R [mailto:james.cutler@eds.com] Sent: Wednesday, March 12, 2003 10:44 PM To: nanog(a)merit.edu Subject: Gender and other protocol issues A famous Internet personality is alleged to have said, approximately, "Be liberal in what you accept. Be exact in what you emit." 'Seems like this continues to be sound advice. :-) JimC

1 0

Gender and other protocol issues
by Cutler, James R 12 Mar '03

12 Mar '03

A famous Internet personality is alleged to have said, approximately, "Be liberal in what you accept. Be exact in what you emit." 'Seems like this continues to be sound advice. :-) JimC

1 0

Re: 69/8 problem -- Would CNN care?
by Jack Bates 12 Mar '03

12 Mar '03

From: "Avleen Vig" > Let's spin this argument on it's head for a moment and look at it from > another view point: > > What you're facing, is opposition from neglegent and / or lazy network > administrators. > Going up against them is always difficult. Believe me, I know. > I consider this the same view. It is difficult. My objection is to the fact that people complain concerning the increase in posts (which I am obligated to read almost all of them) while I'm trying to pull resources that I don't personally possess, ie. the ideas and abilities of NANOG participators. > So, lets look at a hypothetical situation: > CNN (or someone) reports that someone within 69/8 is generating most of > the spam, or distributing most of the world's viruses, or something > equally stupid that the mass media occassionally spurts out. > Primary blocking of 69/8 is not caused from mass media. It is caused from old router configs. Mass media might be the way out. Having said that, I do block networks in 69/8 for spam and viruses. :) > What do you do then? Get CNN to retract the story? That own't accomplish > anything really and we all know it. > Retractions aren't news. People don't notice them. This is news worthy, as it affects a service that people have grown to depend on in their daily lives. Even if it conflicts with another new story (wouldn't be the first time), it should be put out and with enough force that every day people are aware of it, which will mean some firewalls will get checked. > This is not a technical problem, so technical means (centralised > filtering) won't work. The idea of Centralized filtering isn't to solve the current issue, but to hopefully develop a solution that can help prevent this problem in the future. > Neither is it a policy problem, people are free to filter what they > like. They are allowed to, but most are filtering out of ignorance. They wouldn't be filtering if they had the clue. > There's a very fine line between filtering a network out on purpose, and > neglegently not removing filters when space is allocated. From some view > points, they're one and the same thing. > Yes, I agree. Yet, my personal goal is to have neither where my network is concerned. I work long hours, have my personal time interrupted (including vacations) to maintain my network and make it the best that I can. I work hard to please my users as well as other networks at the same time, even though their desires often conflict. It is this very reason that the 69/8 threads interest me. I am not alone in these things. As a community, we need to be proactive with these issues and not just reactive. Waiting for the customer to complain is not the ideal solution. Perhaps I'm wrong. Perhaps we don't possess the intellect to solve such problems. We can't solve the spam problem, so why should we be able to solve this? -Jack

1 0

Getting a Host Record
by Crist J. Clark 12 Mar '03

12 Mar '03

I'm feeling really dumb asking this, but how does one get host info out of Network Solutions WHOIS these days? I want to look up the contact info on a host. I can get the IP from the hostname and vice-versa along with the registrar, but I can't figure out how to get the full record. "Nameserver" queries don't seem to work on whois.networksolutions.com anymore, and the records for zones that I know use the server no longer include the NIC handle for the nameservers. How do I get the record? Or get the NIC handle to get the record through WHOIS? (And I though netsol _used to_ suck. Thank goodness ICANN is saving us all.) -- Crist J. Clark | cjclark(a)alum.mit.edu | cjclark(a)jhu.edu http://people.freebsd.org/~cjc/ | cjc(a)freebsd.org

3 2

cw to att? issue?
by Scott Granados 12 Mar '03

12 Mar '03

Anyone else seeing an issue between cw and att somewhere near sf it looks like. I go from 4 ms, at the point tagged as the peer between cw and att and 1400 ms once I land on att. THanks

3 2

Re: Route Supression Problem
by Danny McPherson 12 Mar '03

12 Mar '03

> Dampening is done on the eBGP router where the route enters the AS, and, > unless I'm mistaken, per route/path and not per prefix. So the flapping > that ISP A sees from ISP B is a completely seperate thing from the > flapping that ISP A sees from its customer's customer as far as the > dampening algorithm is concerned. Nope. It's per-prefix. Have a look at the pointer Randy provided. I think one of the section of RFC 2439 alludes to this as well. -danny

3 2

Re: Route Supression Problem
by Danny McPherson 12 Mar '03

12 Mar '03

> Thus the application effect being talked about. Sure, I understand that. I was making a different assumption... That the sources of traffic were likely from downstream ASs, not "ISP A", or even B or C, and as such, the multiplication could happen per prefix. However, without knowing the number of "penalizing events", what constitutes a penalizing event, and aggressiveness of your peers suppression policies -- or the source distribution of the traffic, it's tough to tell. -danny

1 0

Route Supression Problem
by Jack Bates 12 Mar '03

12 Mar '03

Unless useful to others, feel free to just reply off-list. Background: Tuesday (yesterday) morning around 1am, I got a phone call from one of my transit customers(which seems more like a dream). I, sadly, didn't have the router they are on logging to a server, so it's impossible for me to see exactly what happened. Here's what I have. They received a minor spike in traffic going to them. My router shows the last BGP peer reset about that time, so this could be me sending the global table. His bandwidth then drops to 0 for almost exactly 30 minutes (MRTG isn't an exactly graph). My guess (authoratative answer) was the customer flapped their routes once too many times and was suppressed by both of my providers, as I seem to recall the penalty heal rate is in 30 minute increments. First issue is, am I right? If I am, then I need to develop ways to limit the damage done to my customer. Is there a way to setup route supression just under what most people use so that I can have client fix the problem and then clear the suppress on my network to allow them to come back up immediately just under the suppress threshold? Another possibility, although I've not seen reference to it, since the customer only transits through my network and depends on my redundancy, is it possible to hold his routes in the tables and keep advertising them out unless they are down for a set time period (ie, ignore flaps, but drop them if he's down 15-30 minutes)? I've never seen this issue. I was aware supression was possible when I first started learning BGP, and so I have never risked bouncing my peers more than three times in a day, and at that point usually quit playing until the next week. When my peers flap due to DDOS attacks, BGP never stabalizes fully or my providers have protected my networks (though I haven't seen how 69.8/18 will react in this scenario which doesn't have a shorter prefix at the peer). My customer is thinking of multi-homing again after this. Of course, it wouldn't have saved the customer. The reason they left multi-homing is that their network is in the same building and they only have one BGP router. I don't think multiple paths would have saved them. Opinions? Suggestions? Options? -Jack ~We now return you to the 69/8 threads

6 8