- NANOG - lists.nanog.org

question about traffic eng/ Cisco CEF.
by Jaideep Chandrashekar 09 Aug '00

09 Aug '00

Hi, I seem to be having some problems trying to use Cisco CEF on a 7200. My problem description is as follows. I need some way of sharing load (connections) across multiple links. The routes are all statically configured and have the same distance (though physically of different lengths). When I enable cef and set it to share load on a per destination mode, for some reason, all the traffic to a destination takes a single route .. though the route table shows two equal cost paths. The only point I might be missing is that I am looking at very few connections (2-3) and that load sharing with cef might be engineered to share load in a statistical sense (only kick in with large number of connections). Could anybody throw any light on this. Also ... is there any way to clear the routing table so that when a new link comes up, (and a new route is added to a list of equal cost paths) all the connections are again redistributed across the links. Couldn't seem to be able to make existing connections switch paths. With fast switching ... was able to do this by flushing the routecache .. but cef doesn't use a cache (says the documentation).... Any help is much appreciated. -jaideep

2 1

Open IP Directed Broadcast List...
by dies 09 Aug '00

09 Aug '00

Well, I've rescanned the Internet. I've chosen to scan down to /27 subnets this time. My new list of open broadcasts is available at.... http://www.pulltheplug.com If you are an ISP or work for one, PLEASE VISIT THIS SITE AND CHECK FOR YOUR NETWORKS OR DOWNSTREAMS!! If there are no broadcasts to use, there are no broadcast based attacks! 125102 networks broken...I've posted the top 4000 amp sites this time around... As always I'm looking for help...If you think you can help out, email me. Enjoy

1 0

root-servers.net's nameservers change
by Verd, Brad 08 Aug '00

08 Aug '00

Informational Message: On 8 August, 2000, Network Solutions took actions in compliance with the cooperative agreement with the Department of Commerce to discontinue use of the 'InterNIC' name. One specific aspect of this change involves the server named rs0.internic.net, which had been the primary name server for the root-servers.net domain name along with secondary servers ns.ripe.net, ns.isi.edu and ns-ext.vix.com. All four of these servers were removed from the root-servers.net domain name and replaced with the following servers which were already functioning as root servers: a.root-servers.net f.root-servers.net k.root-servers.net j.root-servers.net At 1730 EDT, the new suite of name servers began acting authoritatively for the root-servers.net domain. The net zone will be updated to reflect the root-servers.net nameserver entries in serial #2000080801. The four hosts rs0.internic.net, ns.isi.edu, ns.ripe.net, and ns-ext.vix.com will continue to serve the root-servers.net zone with the new list of name servers. These hosts will continue to remain active until the time of the new name server suite exceeds the Time To Live (TTL), as defined in the root-servers.net zone. That TTL is currently set to 3,600,000 seconds, or about 42 days. This is an operational change that transferred very smoothly. You will NOT need to make any configuration changes on your machines. You will NOT need a new root.cache file. -------------------------------------- Brad Verd gTLD Operations Manager Network Solutions Registry Email - bverd(a)netsol.com ---------------------------------------

3 2

RE: g.root-servers.net returns NXDOMAIN for com.
by woods＠weird.com 08 Aug '00

08 Aug '00

[ On Saturday, August 5, 2000 at 06:39:41 (+0800), Mathias K�rber wrote: ] > Subject: RE: g.root-servers.net returns NXDOMAIN for com. > > Regardless of whether g.root-servers.net has .com delegation pointing > to it, it is still listed as a root-server (in most users's hints file > and I think even in the current one). > > So people *will* ask it for any- and everything and should get proper answers. No, only really broken resolvers, or people who don't quite know what they're doing, or people who are trying to catch it off guard, will ask it for anything but NS (and maybe SOA) records for the root zone or the top level zones. > A client cannot know that g.root-servers.net is not delegated .com until it has > asked one of the root-servers (assuming it had no cached knowledge), > and it it happened to ask g.root-servers.net, it will be told that the whole > .com hierarchy does not exist... Ah, no, that's not what will happen now; and it is not happening *now*: $ host -r -t ns com. g.root-servers.net com NS F.ROOT-SERVERS.NET com NS J.GTLD-SERVERS.NET com NS K.GTLD-SERVERS.NET com NS A.GTLD-SERVERS.NET com NS M.GTLD-SERVERS.NET com NS G.GTLD-SERVERS.NET com NS C.GTLD-SERVERS.NET com NS I.GTLD-SERVERS.NET com NS B.GTLD-SERVERS.NET com NS A.ROOT-SERVERS.NET com NS E.GTLD-SERVERS.NET com NS F.GTLD-SERVERS.NET $ host -r -t ns weird.com. g.root-servers.net weird.com NS record currently not present at g.root-servers.net (i.e. it knows it is not authoritative for my zone and it is not returning a mistaken authoritative NXDOMAIN) BTW, I think the only way you should get an authoritative NXDOMAIN domain for a top-level zone from a BIND-based nameserver is if that nameserver were authoritiative for the parent zone, *and* the parent (i.e. root) zone itself contained *no* data for the top-level zone in question. While the former is supposed to be true for g.root-servers.net at all times, the latter was only true for a short period of time while they futzed with it trying to make it continue to do something that it apparently did not want to do. This *may* indicate a bug in BIND-8 -- I don't know for sure. > The .com delegation is irrelevant in thiscase. g.root-servers.net is broken > right now and should be fixed or shut down until it is. At the moment it is not broken in any way that I can discern. It has a "lame" delegation of .COM, .ORG, and .NET from the point of view of some nameservers out there in the world. This is indeed the best solution to the problem (and in fact the previous attempts to continue to try and load the zone when there were known problems were what was wrong wrong and that's what ended up causing people problems). Shutting it down completely and abrubtly would cause more delays to a portion of the average DNS queries than is necessary. So long as it can continue to reliably serve the zones that are currently delegated to it, it should stay up and running and simply be left "lame" for COM/ORG/NET. Assuming this isn't a spoofed reply, it may give some indication as to the source of the problems it had though: $ host -t txt -c ch version.bind g.root-servers.net VERSION.BIND TXT "8.1.2-P2" The lesson learned here should be that if you operate *any* authoritiative nameserver, you will pull the public network cable to it immediately if you suspect it is answering incorrectly for domains it should know about (be they delegations from a parent zone or zone it should have loaded itself) and that it not be plugged in again until it is guaranteed to be answering correctly, *and* that it be monitored most closely until it can be shown that it still answers all queries correctly under real-world load. If it cannot answer only for a few of its zones then it should be made lame for those zones such that it can continue to serve queries for other zones with which there are no problems. I thought previous incidents would have taught these lessons to everyone by now, but it seems not. If this kind of thing happens for top level zones with very experienced operators who have most of the world's eyes staring down on them, you can just imagine how often it happens to many piddly second level domains and even more 3rd and so on! Perhaps a good project that would assist in these situations would be to write a sniffer tool that could look for authoritative NXDOMAIN replies and compare them to a list of known zones to see if any incorrect answers are flying by on the wire out to unsuspecting clients. It shouldn't be too hard to munge something like this together from the source of tcpdump in fact.... -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods(a)acm.org> <robohack!woods> Planix, Inc. <woods(a)planix.com>; Secrets of the Weird <woods(a)weird.com>

2 1

Genuity
by Charles Sprickman 08 Aug '00

08 Aug '00

Hi, Sorry to post, but we've exhausted any normal routes through customer service. You can just delete this here and now without scrolling down to the nasty traceroutes... Could someone with some knowledge of ticket 802-107 please contact me off list. This is a long-standing issue and I'm having trouble swallowing the current explanation. Thanks, Charles ------ Nutshell: core-1#ping Protocol [ip]: Target IP address: www.bbn.com Repeat count [5]: 25 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 25, 100-byte ICMP Echos to 128.11.42.31, timeout is 2 seconds: ..!..!!..!!!..!!!.!.!!.!. Success rate is 52 percent (13/25), round-trip min/avg/max = 152/164/176 ms core-1#traceroute www.bbn.com Type escape sequence to abort. Tracing the route to www.bbn.com (128.11.42.31) 1 fa10-0.nyccolo-border1.bbnplanet.net (207.240.48.45) [AS 3847] 0 msec 0 msec 4 msec 2 f6-0.nyccolo-core1.bbnplanet.net (207.240.1.81) [AS 3847] 0 msec 0 msec 0 msec 3 a3-0-916.camcolo-dbe1.bbnplanet.net (128.11.124.130) [AS 3847] 164 msec * * 4 vlan40.camcolo-isw02-rc1.bbnplanet.net (128.11.194.68) [AS 3847] 168 msec * * 5 * bbnbp3.cam-colo.bbnplanet.com (128.11.42.185) [AS 3847] 176 msec * -- Tracing the route to www.uu.net (208.243.117.123) 1 fa10-0.nyccolo-border1.bbnplanet.net (207.240.48.45) [AS 3847] 0 msec 0 msec 4 msec 2 f6-0.nyccolo-core1.bbnplanet.net (207.240.1.81) [AS 3847] 0 msec 0 msec 0 msec 3 a1-0-516.ordcolo-core1.bbnplanet.net (128.11.124.66) [AS 3847] 36 msec 36 msec 32 msec 4 fa5-0-0.ordcolo-peer1.bbnplanet.net (207.240.1.174) [AS 3847] 36 msec 36 msec 36 msec 5 NChicago2-core0.nap.net (207.112.249.129) [AS 5646] 172 msec 176 msec 176 msec 6 * * p5-2.chcgil1-ba1.bbnplanet.net (4.24.6.129) [AS 1] 176 msec 7 * * * 8 * p2-0.nycmny1-br1.bbnplanet.net (4.24.6.90) [AS 1] 236 msec * 9 * p1-0.nycmny1-ba1.bbnplanet.net (4.24.6.230) [AS 1] 172 msec * 10 * * a1-0.xnycmny4-uunet.bbnplanet.net (4.0.6.142) [AS 1] 172 msec 11 160.at-6-0-0.XR1.NYC9.ALTER.NET (152.63.18.222) [AS 701] 172 msec 168 msec 172 msec 12 * * 181.at-1-0-0.TR1.NYC9.ALTER.NET (152.63.20.122) [AS 701] 180 msec 13 125.at-5-0-0.TR1.DCA6.ALTER.NET (152.63.2.125) [AS 701] 184 msec 184 msec 184 msec 14 187.at-4-1-0.XR1.DCA1.ALTER.NET (152.63.33.209) [AS 701] 184 msec * * 15 195.ATM6-0.GW3.DCA1.ALTER.NET (146.188.161.73) [AS 701] 176 msec 192 msec * 16 * 315.GW1.TCO3.customer.ALTER.NET (137.39.128.206) [AS 701] 168 msec * 17 prod-334a.tco3.web.uu.net (208.243.113.236) [AS 11486] 172 msec * * -- This is normally a very quick hop to qwest, which leads me to not believe that this has anything to do with Sprint. Don't ask me why there's a connection to qwest at 33 Whitehall, no one's been able to explain that. Tracing the route to www.qwest.net (208.45.139.41) 1 fa10-0.nyccolo-border1.bbnplanet.net (207.240.48.45) [AS 3847] 0 msec 0 msec 0 msec 2 f6-0.nyccolo-core1.bbnplanet.net (207.240.1.81) [AS 3847] 4 msec 0 msec 0 msec 3 * quasi.artnet.com (207.240.48.38) [AS 3847] 144 msec * 4 jfk-core-03.inet.qwest.net (205.171.30.13) [AS 209] 140 msec 156 msec * 5 * * jfk-core-01.inet.qwest.net (205.171.30.9) [AS 209] 140 msec 6 wdc-core-02.inet.qwest.net (205.171.5.235) [AS 209] 144 msec 156 msec * 7 * wdc-core-01.inet.qwest.net (205.171.24.1) [AS 209] 148 msec 268 msec 8 * wdc-brdr-03.inet.qwest.net (205.171.24.38) [AS 209] 148 msec 144 msec 9 iad-cntr-01.inet.qwest.net (205.171.24.138) [AS 209] 152 msec * 144 msec 10 * * * 11 www.qwest.net (208.45.139.41) [AS 209] 144 msec 160 msec * My guess, the MFS ATM connection to nyccolo is crap... | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork(a)inch.com | access(a)inch.com

1 1

Sonoma Access
by John Fraizer 08 Aug '00

08 Aug '00

Does anyone have any experiences with the Sonoma Access product? Good/Bad opinions? Success/Horror stories? --- John Fraizer EnterZone, Inc

2 1

RE: [OT] Valley of the Boyz
by rdobbins＠netmore.net 08 Aug '00

08 Aug '00

News flash, lady - IT -is- "tape drives and hardware and wires and machines". So, if you have nothing in common with people who are interested in such things, go do something else. Male or female, people with this sort of attitude have no business in the industry. I could care less whether my colleagues are male or female, as long as they know their stuff and do their jobs. All this whining - and that's what it is - about 'gender balance' (whatever -that- is) is absurd. There may well not be as many women who are into this sort of thing as men, just as there may not be as many men who are into interior design or haute couture. So what? -----Original Message----- From: John M . Brown To: nanog(a)merit.edu Sent: 8/7/00 1:15 AM Subject: [OT] Valley of the Boyz http://www.cnn.com/2000/TECH/computing/08/03/it.women/index.html

13 14

more on savvis outtages...
by deeann mikula 08 Aug '00

08 Aug '00

pgh. lost savvis again around 6pm EDT. i called then, and got a "don't really know yet..." response from their noc. after getting the msg below (8pm EDT), i called them back, and the noc tech told me that they are working at it from 2 angles, one group on the possibility of an equiptment failure and another group working with an at&t tech on the possibility that the problem lies with them. he said he "seems like" it might be a re-occurence of y'days problem, but it was too soon to tell and he hadn't gotten an official confirmation that it was ok to say that yet. IMHO, i think their handling of this (emails and prompt call backs, and informed and cheerful phone staff) has been great (from a customer support viewpoint.) now if they could just get us back up again... 3 separate several hour outages of the complete pgh. network is just unacceptable. :( [8am-2pm sunday, 4am-6am monday and 6pm-? monday.] just my update for all those of pgh net-admins, and anyone else who cares. deeann m.m. mikula director of operations telerama public access internet http://www.telerama.com ---------- Forwarded message ---------- Date: Mon, 7 Aug 2000 18:23:15 -0500 (CDT) From: <snipped, from savvis noc> Subject: NOTIFICATION OF EMERGENCY OUTAGE At 8/7/2000 17:28:33 CST, we experienced an outage in our ATM and Frame Relay switches in Pittsburgh. We have escalated this issue to the highest levels in Savvis, and have also opened tickets with carriers. If you have any questions or concerns, please call the NCC at (888) 638-6771 and reference ticket 322411.

2 1

root servers
by Jeff Harper 07 Aug '00

07 Aug '00

Just curious if anyone had noticed any issues with root servers in July>? Thanks, Jeff Harper jharper(a)verizon.com

1 0

Re: g.root-servers.net returns NXDOMAIN for com.
by Michael Shields 07 Aug '00

07 Aug '00

In article <27673.965401287(a)ftel.net>, Mark Milhollan <mlm(a)ftel.net> wrote: > >Hence, if you randomly query the one server that is returning NXDOMAIN > >for com, all com lookups will fail. > > This is why BIND 8 has the bogus characteristic, or why one may need to > edit their root hint file. Too bad both require a reload/restart. As well as manual configuration at every resolver on earth. I don't think that's a scalable solution. The root servers need to work. -- Shields.

2 1