- NANOG - lists.nanog.org

"Route control" and routing table size
by Hank Nussbacher 11 Dec '01

11 Dec '01

There are many companies now in the "route control" field such as Route Science, Netvmg, Proficient Networks and many others. A recent one I spotted is Radware: http://www.radware.com/archive/pdfs/whitepapers/PeerDirectorTech.pdf See page 5: "Some peers are still overloaded, configure smaller CIDRs". Are we about to see a growth in the routing table size after seeing a slowing down in 2001: http://www.telstra.net/ops/bgp/bgp-active.html ? -Hank

1 0

Tail Drops and TCP Slow Start
by Murphy, Brennan 11 Dec '01

11 Dec '01

If I have a DS3 or OC3 handling mounds and mounds of FTP download traffic, what is the easiest way to detect if the bandwidth in use is falling into a classic Tail Drop pattern? According to a Cisco book I am reading, the bandwidth utilization should graph in a "sawtooth" pattern of gradual increases in accordance with multiple machines gradually increasing via TCP slow start and then sharp drops. Will this only happen when the utilization approaches 100%. (maybe dumb question) Should I be able to do a show buffers and see misses or is there some better way to detect other than via graphing? Also, suppose in examining my ftp traffic patterns that I noticed that it spikes at 15minutes after the type of the hour, consistently, etc. Could I create a timed access list to only kick in at that time? Anyone have experience with WRED to handle ftp congestion? I usually take these types of questions to Cisco but I thought I'd post it to this list to get any generic real world advice. sh buff Buffer elements: 499 in free list (500 max allowed) 5713661 hits, 0 misses, 0 created Public buffer pools: Small buffers, 104 bytes (total 600, permanent 600): 580 in free list (20 min, 1250 max allowed) 2225528470 hits, 6 misses, 18 trims, 18 created 0 failures (0 no memory) Middle buffers, 600 bytes (total 450, permanent 450): 448 in free list (10 min, 1000 max allowed) 68259213 hits, 7 misses, 21 trims, 21 created 0 failures (0 no memory) Big buffers, 1524 bytes (total 450, permanent 450): 449 in free list (5 min, 1500 max allowed) 6807747 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) VeryBig buffers, 4520 bytes (total 50, permanent 50): 50 in free list (0 min, 1500 max allowed) 46167681 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) Large buffers, 5024 bytes (total 50, permanent 50): 50 in free list (0 min, 150 max allowed) 0 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) Huge buffers, 18024 bytes (total 5, permanent 5): 5 in free list (0 min, 65 max allowed) 34 hits, 6 misses, 12 trims, 12 created 0 failures (0 no memory) Interface buffer pools: IPC buffers, 4096 bytes (total 768, permanent 768): 768 in free list (256 min, 2560 max allowed) 769236774 hits, 0 fallbacks, 0 trims, 0 created 0 failures (0 no memory) Header pools:

4 3

Re: Network Operations Luminaries?
by Brett Frankenberger 11 Dec '01

11 Dec '01

> As for the previous question in this thread, 12.1 that I'm currently > running treats "no red bgp subn route-m <name>" the same as "no red > bgp" No it doesn't. My test case was invalid. Nevermind ... -- Brett

1 0

OSPF LSA filtering
by Rizkalla, Simon 11 Dec '01

11 Dec '01

Does anyone have any idea how to filter out LSA updates between areas? I am using the Cisco 7204 VXR routers as ABRs and Enterasys routers as ASBRs. However, I do not want routes to be propagated from the backbone area to any other area. The limitation is that the Enterasys gear we are using does not support NSSAs. Regards, Simon Rizkalla

4 3

To ask for the impossible......
by Paul Wouters 10 Dec '01

10 Dec '01

This being a very very very long shot. Does anyone know of a way to reach an interactive human being at uhm... *sobs loudly* Network Solutions...... Before anyone tells me I should ditch them and move away, that's exactly what I tried. I moved all our domains away from them, and they seem to have pseudo-randomly chosen to refuse transfers of some of them, and yes even ones that have been paid till 2003. Too tired for this bureaucratic fight.... Paul Wouters Xtended Internet -- Broerdijk 27 Postbus 170 Tel: 31-24-360 39 19 6523 GM Nijmegen 6500 AD Nijmegen Fax: 31-24-360 19 99 The Netherlands The Netherlands info(a)xtdnet.nl

2 2

Re: USGS returns to the Internet
by jloiacon＠csc.com 10 Dec '01

10 Dec '01

The "law of unintended consequences" done struck USGS. I keep performance data on a NASA router at the USGS Eros Data Center (EDC). Large satellite based science data products are transferred continuously between EDC and NASA centers as well as principal investigator's throughout the world. My MRTG graph is flat-lined between Thursday PM and Sunday AM. Joe Valdis.Kletni eks(a)vt.edu To: wb8foz(a)nrk.com Sent by: cc: nanog(a)merit.edu (nanog list) owner-nanog@m Subject: Re: USGS returns to the Internet erit.edu 12/10/2001 12:16 PM On Sun, 09 Dec 2001 21:54:31 EST, David Lesher <wb8foz(a)nrk.com> said: > Unnamed Administration sources reported that Patrick Greenwell said: > > page server" of the DOI had access to the Indian trust data. My > > speculation would be that it does if it's Internet connected... > I can see no reason why a server full of personal data would be. Personally, given the amount and size of holes the court-appointed tiger team found, and the fact that *previous* security audits going back as far as 1989 (it appears) have found problems, I'd be surprised if they had gotten it *right* and segregated that server from the Internet. And of course, given the judge's wording, if the data server is on the Internet, then every DoI host that's on the Internet has access to it - and thus needs to have its plug pulled. Bet somebody's wishing that server had been on a private network with only several other dozen machines.... ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech << Attachment Removed : C.DTF >>

1 0

Re: USGS returns to the Internet
by David Lesher 10 Dec '01

10 Dec '01

Unnamed Administration sources reported that Patrick Greenwell said: > > > > A judge *ordered* the DOI offline. I disagree. Read the order. <http://www.indiantrust.org/rulings/2001.12.05_TRO.pdf> It only talks about systems with Indian Trust data not the home page server. I think it's fair to assume a PHB panicked over [his,her] tail being locked up by His Honor; and ordered ALL servers down. YMMV. -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

5 6

USGS returns to the Internet
by Sean Donelan 10 Dec '01

10 Dec '01

One of the sources I use to keep track of natural hazards (i.e. earthquakes) which may affect the net has been off the net for the last few days. The US Geological Survey (along with the rest of Department of Interior) Internet access was shutdown earlier this week. On December 8, Judge Lamberth modified his order allowing some services to be restored. First @Home and then the Department of the Interior, US Judges have disrupted more Internet users in the last couple of weeks than any other source. What next a judge riding a backhoe?

5 8

AT&T/Alternet outage in Chicago?
by Wes Bachman 08 Dec '01

08 Dec '01

We were noticing some routing problems between AT&T (our provider) and alternet/uunet sites. This seems better now, but AT&T still has a master ticket open. Anyone seeing similar things, or have more information? Thanks, -Wes Bachman -- |=| Wesley A. Bachman / Iowa City, IA / <wbachman(a)leepfrog.com> |=| Developer, System Administrator, Leepfrog Technologies, Inc. PGP Public key available upon request. My opinions are my own. |=| ``...money is like us in time; it lies but can't stand up.'' -VU |=|

4 4

weird whois entries for yahoo.com
by David Ulevitch 08 Dec '01

08 Dec '01

Hello nanog, This morning while troubleshooting some weird dns-poisoning issues I came across this: > [root@scooby parked]# whois yahoo.com(a)whois.crsnic.net > [whois.crsnic.net] > > Whois Server Version 1.3 > > Domain names in the .com, .net, and .org domains can now be registered > with many different competing registrars. Go to http://www.internic.net > for detailed information. > > YAHOO.COM.REALLY.NEEDS.TO.GET.A.CLUE.AT.JIMPHILLIPS.ORG > YAHOO.COM.IS.TRYING.TO.STEAL.YAHOO.VU.HOW.ACIDULOUS.COM > YAHOO.COM.AINT.NOTHIN.COMPARED.TO.SAFESEARCH.COM > YAHOO.COM > > To single out one record, look it up with "xxx", where xxx is one of the > of the records displayed above. If the records are the same, look them up > with "=xxx" to receive a full display for each record. > >>>> Last update of whois database: Sat, 8 Dec 2001 05:13:13 EST <<< > > The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and > Registrars. > > [root@scooby parked]# compared to this: > [root@scooby parked]# whois yahoo.com(a)whois.networksolutions.com > [whois.networksolutions.com] > The Data in Network Solutions' WHOIS database is provided by Network > Solutions for information purposes, and to assist persons in obtaining > information about or related to a domain name registration record. > Network Solutions does not guarantee its accuracy. By submitting a > WHOIS query, you agree that you will use this Data only for lawful > purposes and that, under no circumstances will you use this Data to: > (1) allow, enable, or otherwise support the transmission of mass > unsolicited, commercial advertising or solicitations via e-mail > (spam); or (2) enable high volume, automated, electronic processes > that apply to Network Solutions (or its systems). Network Solutions > reserves the right to modify these terms at any time. By submitting > this query, you agree to abide by this policy. > > > Registrant: > Yahoo (YAHOO-DOM) > 701 First Avenue > Sunnyvale, CA 94089 > US > > Domain Name: YAHOO.COM > > Administrative Contact, Technical Contact: > Administrator, Domain (DA16065) domainadmin(a)YAHOO-INC.COM > Yahoo! Inc. > 701 First Avenue > Sunnyvale, CA 94089 > US > 1-408-530-5062 > Billing Contact: > Billing, Domain (DB28833) domainbilling(a)YAHOO-INC.COM > Yahoo! Inc. > 225 Broadway, 13th Floor > San Diego, CA 92101 > 1-408-731-3300 > > Record last updated on 05-Oct-2001. > Record expires on 20-Jan-2010. > Record created on 18-Jan-1995. > Database last updated on 8-Dec-2001 00:50:00 EST. > > Domain servers in listed order: > > NS1.SNV.YAHOO.COM 216.115.108.33 > NS2.SAN.YAHOO.COM 209.132.1.29 > NS3.EUROPE.YAHOO.COM 217.12.4.71 > NS4.DAL.YAHOO.COM 63.250.206.50 > NS5.DCX.YAHOO.COM 216.32.74.10 > > [root@scooby parked]# Is this just someone at yahoo having fun with whois, or a more serious problem? Thanks, David Ulevitch mailto:davidu@everydns.net EveryDNS.net http://www.everydns.net

3 2