August 1999 - Test - lists.nanog.org

Re: Power outage in Vienna, Virginia and other things
by Sean Donelan 24 Aug '99

24 Aug '99

SEAN(a)dra.COM (Sean Donelan) writes: >While checking on Vienna, I also found I had problems reaching sites >in Boston, MA. Both Tufts University and Boston University are off-net. >I haven't heard of anything happening in the Boston area. I know Tufts >switch providers, but I don't know about BU. So the information in the >RADB may not give good information for reaching the correct upstream >provider. The sites have come back up, and it appears the former nearnet lost more customers than I knew about. Because the new provider doesn't include information in an public RADB-like database, I didn't realize all the sites went through the same place. I was looking for and asking the wrong provider. UUNET had announced on their maintenance page they are replacing routers in Boston, MA this morning. The router maintenance affected the sites I was using to check for problems: computerworld.com, tufts.edu, and bu.edu. I guess its time to look for new beacons. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Power outage in Vienna, Virginia and other things
by Sean Donelan 24 Aug '99

24 Aug '99

There is a power outage in the Vienna, VA area which appears to be affecting a few co-location facilities in the area. Some web sites I know hosted in the area are down. MAE-East is currently up. While checking on Vienna, I also found I had problems reaching sites in Boston, MA. Both Tufts University and Boston University are off-net. I haven't heard of anything happening in the Boston area. I know Tufts switch providers, but I don't know about BU. So the information in the RADB may not give good information for reaching the correct upstream provider. And there is a DS3 cable problem in Alameda, CA. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Training the next generation:
by Dana Hudes 24 Aug '99

24 Aug '99

Hi ! I'm teaching networking this year at CUNY Hunter College here in Manhattan. I would like your input as industry members what skills would have value to you in a new graduate computer science major (the students are seniors). Fall course is "Telecomputing"; the syllabus I created for the course uses Tannenbaum's _Computer Networks_ and tries to cover a range of things. Course project will likely be design and implement a bridge, possibly including source-route and certainly including spanning tree. Early on, coverage of WAN include project with PCM and such. A syllabus is posted at http://harmony.hudes.org/Telecomputing.html Students will have a broad base in a variety of networking topics. Focus on Ethernet in the LAN and PPP and ATM in the WAN. Spring is a "special topics" course. I've some flexibility here. I'm weighing two alternatives, and want some feedback. Of all possible things, the acting chair and I narrowed to two possible courses: 1. A course in TCP/IP. Use Comer, _Internetworking with TCP/IP_ and his syllabus from Purdue as a starting point. No time in this course for any physical layer or data link stuff beyond a cursory overview of Ethernet as we move at high speed to the network layer and IP forwarding. Comer's graduate course has students build a router but this is probably too much for undergraduates. Instead an OSPF implementation, including all the options (especially NSSA) . A cursory introduction to sockets programming with the course focus on routing algorithms (i.e. RIP, OSPF, and BGP4). Can this one course (my fall course hasn't sufficient registration to make the 2 semester sequence in networking we'd hoped; maybe next year). 2. Network application programming. Java clients, Perl and Apache server side (or perhaps Java servlets). Hunter students know C++ fairly well by their senior year; Java is an easy transition. The entire class would divide into teams with assignments that comprise various parts of the client and server portions. The project would be a turn-based simulation game (I used to play these and have a number of appropriate games with play-by-mail options, game rule design and/or game theory is not part of the course). While this won't teach them to be router engineers -- or developers, it should have some industry relevance. Most Hunter graduates stay in the Greater NYC metropolitan area. Given this, which of these options is better for the industry? who is in shorter supply? Prompt feedback greatly appreciated. Registrar is asking for the course description ASAP or sooner. Thanks! Dana Hudes CUNY Hunter Computer Science former ISP

2 1

Paul A Vixie: BIND 8.2.2 (T3B; RC0) is available for general testing
by Paul A Vixie 24 Aug '99

24 Aug '99

fyi ------- Forwarded Message To: bind-announce(a)isc.org Subject: BIND 8.2.2 (T3B; RC0) is available for general testing Date: Tue, 24 Aug 1999 00:01:59 -0700 From: Paul A Vixie <vixie(a)bb.rc.vix.com> Confidence: moderate. This is running on part of F.ROOT-SERVERS.NET and on all of our local production servers. The only reasons it's not a full release candidate are that IXFR is still disabled and we're still tinkering with the NT support. Highlights vs. BIND 8.2.1: Preliminary support for Windows/NT (thanks to BayNetworks). More fixes, especially to DNSSEC, TSIG, IXFR, and selective forwarding. More portability improvements and lint removal (A/UX 3.1.1, SCO 5.0). Better NOTIFY behaviour, especially with large update volume. Better UPDATE handling, including SRV RR support and RFC compliance. Fix for "ndc reload ZONENAME" (specific zone reload) problems. Fix for round robin when multiple CNAMEs are in use. New "min-roots" (MINROOTS) and "serial-queries" (MAXQSERIAL) options. Log files are no longer auto-rotated every time the server starts up. New "ndc reconfig" command only finds new/deleted zones, no stat()ing. New global options for "update-source" and "also-notify". $GENERATE now supports more record types, and options. the distribution files are: ftp://ftp.isc.org/isc/bind/src/testing/t3b/bind-src.tar.gz ftp://ftp.isc.org/isc/bind/src/testing/t3b/bind-doc.tar.gz ftp://ftp.isc.org/isc/bind/src/testing/t3b/bind-contrib.tar.gz the pgp signature files are: ftp://ftp.isc.org/isc/bind/src/testing/t3b/bind-src.tar.gz.asc ftp://ftp.isc.org/isc/bind/src/testing/t3b/bind-doc.tar.gz.asc ftp://ftp.isc.org/isc/bind/src/testing/t3b/bind-contrib.tar.gz.asc the md5 checksums are: 0abf1631852beb1d989b4d41759641bf bind-contrib.tar.gz d82f381d0904ee236b5262abb9ac1484 bind-contrib.tar.gz.asc 4e51a75f0dd42327daa6f922b4fd4fab bind-doc.tar.gz c417a461f329abce517ade68c735f154 bind-doc.tar.gz.asc feb88267cd52196fcf0097b2ef6f04c1 bind-src.tar.gz 38446afd2df7b62af88facf35191ca03 bind-src.tar.gz.asc top of CHANGES says: --- 8.2.2-T3B released --- 783. [support] make res_send() more friendly to the java scheduler. 782. [support] dangling cnames aren't errors, stop logging them. 781. [support] add -n option to ndc command, to run nonstandard named. 780. [bug] UPDATE did not support the AAAA RR. 779. [bug] miscellaneous IXFR fixes. 778. [support] don't complain to syslog about negative caching RRs. --- 8.2.2-T2B released --- 777. [bug] getword() didn't increment lineno at EOF. 776. [bug] the NOERROR_NODATA cookie overlapped a valid rcode. 775. [protocol] we weren't sending properly formated FORMERR responses. 774. [bug] UPDATE did not support the SRV RR. 773. [bug] named-xfer was calling inet_ntoa in one printf. 772. [typo] Typo in ns_parser.y on maybe_zero_port: line. 771. [lint] UNLINK performs a INIT_LINK so explicit INIT_LINK's are nolonger needed after UNLINK. 770. [protocol] dynamic update prerequisites were inappropiately matching wildcards, at variance with RFC 2136. 769. [bug] ordering of CNAMES was driven by original query type. 768. [support] MINROOTS is now a configuration option "min-roots". 767. [clarity] adjust XFR log messages to be more clear about cause. 766. [support] add "serial-queries" option to dynamify MAXQSERIAL. 765. [feature] added evInitID() and evTestID() for NOTIFY work. 764. [bug] DNSSEC changed the semantics of match() without changing all the call sites that cared about it. 763. [bug] NOTIFY events caused by dynamic update weren't being deferred, and multiple NOTIFY events weren't being coalesced. 762. [support] don't rotate log file versions on server startup. 761. [port] named-xfer's openlog() was unconditionally using the LOG_CONS option. now it does what named does. --- 8.2.2-T1A released --- 760. [port] preliminary win/nt from baynetworks (thanks!) 759. [support] new compile time option BIND_IXFR, defaults to "off", since our testing has shown up some problems with it. 758. [feature] new "ndc reconfig" command only finds new/gone zones, doesn't stat() master files or qserial() slave SOA's. 757. [support] FORCED_RELOAD is no longer optional. 756. [support] fixed output format of hmac keys; removed DST chaff. 755. [feature] "also-notify" is now a global option. 754. [bug] the control socket was not checked for event lib compatability. 753. [feature] "ndc help" now returns one line command summaries. 752. [feature] "ndc trace" now takes an optional "level" argument. 751. [support] debugging output could segfault in ns_print.c::addstr. 750. [port] A/UX 3.1.1. 749. [port] #9 has now been done for all Makefiles. 748. [feature] "transfer-source" is now a global option. 747. [support] SORT_RESPONSE is no longer a compile time option, since the behaviour can be turned off at runtime with the "rrset_order fixed;" option. 746. [bug] don't bother rescanning the interfaces if setuid!=root. 745. [protocol] IXFR transmission was just plain wrong in some cases. 744. [support] allow the calling location of strings to be recorded. 743. [feature] $GENERATE now supports more record types, and options. 742. [port] port/sco50 was using /usr/local/etc for its ndc socket. 741. [port] HPUX needed __BIND_RES_TEXT. 740. [bug] #634 had the unfortunate side effect of disabling IXFR. 739. [port] probe for IPv6 structures, solaris openbsd freebsd 738. [bug] invalidate pointers back into linked list when element is removed. 737. [port] solaris: expr is sensitive to LC_COLLATE 736. [bug] potential single file descriptor leak opening /dev/random. 735. [bug] memory leak: having rrset-order set and reconfiguring the server results in a memory leak. 734. [port] linux only fills in as many entries as will fill the buffer with SIOCGIFCONF. 733. [bug] RD is not being set on first message to first forwarder resulting in false "Lame Server" reports and degraded service. 732. [bug] errors reading keys from master files could cause the the server to drop core. 731. [bug] highestFD was not reflecting the highest value the library could cope with. 730. [port] rand() does not modify the LSB on BSD based systems. 729. [bug] allow-query responses were dependent upon cache contents. 728. [bug] it wasn't possible to specify the flags of trusted keys in hex, which was inconvenient since dig prints hex. 727. [bug] TSIG keys weren't properly shared with named-xfer if the zone named contained a slash (/). 726. [bug] TSIG keys weren't reloaded correctly with 'ndc reload'. 725. [bug] only the first key in an acl was matched correctly. 724. [bug] "ndc restart" needed a short delay before checking for the health of a newly started name server. 723. [bug] TSIG signed zone transfer failed on especially large zones. 722. [doc] the example named.conf file had invalid TSIG usage. 721. [bug] duplicate records were tripping the cname-and-otherdata test, which wasn't necessary since they'll be ignored. 720. [port] solaris doesn't have gethostid() the way we build. 719. [lint] lots of lint fixed by bob and paul. 718. [bug] multiple CNAME support was not cycling the cnames in an RRset properly. 717. [bug] wrong /bin/ps flags in solaris prand_conf.h. minor tweak to ports/prand_conf/prand_conf.c to ensure proper flags in future ports. 716. [bug] log files are now closed/reopened on a size basis. 715. [clarity] root servers don't need to be primed. 714. [typo] extra "q" in a message in ns_maint.c. --- 8.2.1 released --- ... ------- End of Forwarded Message

1 0

Re: "Engineer" (Was: Tech contact for Qwest?)
by Vadim Antonov 24 Aug '99

24 Aug '99

J.D. Falk <jdfalk(a)cybernothing.org> wrote: > Yeah, but at least they have a code of ethics. Where'd ours > go? Having to have a written code of ethics is usually a very sure sign that there are problems in this respect. Every time i hear about anything like that i'm reminded of the Moral Code of Bulider of Communism (yes, there was a poster with that text in virtually every classroom in the ussr). That one was a lot more comprehensive, too. Well, the early Internet types have unwritten ethics - and it is a hell lot different from the corporate ethics of the Professional Engineers (tm). Clashes between these two often provide spectacular fireworks :) --vadim

3 2

Re: Training the next generation:
by Dana Hudes 24 Aug '99

24 Aug '99

Darin, thanks for the feedback. All the bridging issues you mention are covered in Tannenbaum. Packet captures for examples is a good thought. These students are already familiar with the spanning tree algorithm from a previous course, they just don't know that it is good for bridging. I don't have complete details by section but the book details are at http://www.phptr.com/ptrbooks/ptr_0133499456.html for Tannenbaum and http://www.phptr.com/ptrbooks/esm_0130117021.html for the project book by Grodzinsky IP addressing is covered in Tannenbaum, as are routing algorithms. Obviously Tannenbaum doesn't cover OSPF to the same depth as Comer or John Moy's OSPF book. The URL for my syllabus for CSCI 415 Telecomputing is in my original post. A syllabus for a TCP/IP course is posted by Comer at http://www.cs.purdue.edu/~comer/courses.html . What I'm most concerned for is the special topics course. There is no time for bridging and other L1/L2 stuff (or ATM wherever layer you stick it). That is in Telecomputing. ----- Original Message ----- From: Darin Divinia <ddivinia(a)broadcast.com> To: Dana Hudes <dhudes(a)panix.com> Sent: Monday, August 23, 1999 11:48 PM Subject: Re: Training the next generation: > I would include some basic stuff on IP addressing. > Some fundamentals of routing protocols (what makes ones routable) > Difference between a routing and routable protocol. > Sniffer traces of protocols. > Bridging, specifically how a MAC table works and what a port off a bridge > should see Same for a bridge for that fact. > > Do you have the details of what you are going to teach by section? That > would help me see what is missing. > > D. > > > At 12:12 AM 8/24/99 -0400, you wrote: > >Hi ! > > I'm teaching networking this year at CUNY Hunter College here in Manhattan. > >I would like your input as industry members what skills would have value to > >you in a new graduate computer science major (the students are seniors). > >Fall course is "Telecomputing"; the syllabus I created for the course uses > >Tannenbaum's _Computer Networks_ and tries to cover a range of things. > >Course project will likely be design and implement a bridge, possibly > >including source-route and certainly including spanning tree. Early on, > >coverage of WAN include project with PCM and such. > >A syllabus is posted at http://harmony.hudes.org/Telecomputing.html > >Students will have a broad base in a variety of networking topics. Focus on > >Ethernet in the LAN and PPP and ATM in the WAN. > > > > > >Spring is a "special topics" course. I've some flexibility here. I'm > >weighing two alternatives, and want some feedback. > >Of all possible things, the acting chair and I narrowed to two possible > >courses: > >1. A course in TCP/IP. Use Comer, _Internetworking with TCP/IP_ and his > >syllabus from Purdue as a starting point. > >No time in this course for any physical layer or data link stuff beyond a > >cursory overview of Ethernet as we move at high speed to the network layer > >and IP forwarding. Comer's graduate course has students build a router but > >this is probably too much for undergraduates. Instead an OSPF > >implementation, including all the options (especially NSSA) . A cursory > >introduction to sockets programming with the course focus on routing > >algorithms (i.e. RIP, OSPF, and BGP4). > >Can this one course (my fall course hasn't sufficient registration to make > >the 2 semester sequence in networking we'd hoped; maybe next year). > > > >2. Network application programming. Java clients, Perl and Apache server > >side (or perhaps Java servlets). Hunter students know C++ fairly well by > >their senior year; Java is an easy transition. The entire class would divide > >into teams with assignments that comprise various parts of the client and > >server portions. The project would be a turn-based simulation game (I used > >to play these and have a number of appropriate games with play-by-mail > >options, game rule design and/or game theory is not part of the course). > >While this won't teach them to be router engineers -- or developers, it > >should have some industry relevance. > > > > > >Most Hunter graduates stay in the Greater NYC metropolitan area. Given this, > >which of these options is better for the industry? who is in shorter supply? > > > >Prompt feedback greatly appreciated. Registrar is asking for the course > >description ASAP or sooner. > > > >Thanks! > >Dana Hudes > >CUNY Hunter Computer Science > >former ISP > >

1 0

snmpstat monitor ver. 1.2.e - see http://noc.bn.ru/~alex/MON
by Alex P. Rudnev 24 Aug '99

24 Aug '99

I completed, as promised, the work of collecting distribution pack for the snmpstat monitor (version 1.2.e, where 'e' means _english menu available_). The system was tested for the FreeBSD and Solarys 2.6, but I believe it can work fine on any Unix where CMU SNMP library can be translated. This pack include: - the russion and english dicumentation; - the installation pack (tested for the fixed /p/stat and user: monitor group: monitor configs but theoretically allowing to use any location and user), including snmpstatd daemon, WWW interface to the monitoring system, LINKS data base and WWW interface for it, and (in addition) modems_poll monitor (withouth any WARRANTIES and docs). This (1.2) is SHAREWARE software - we ask you to contact us in case this appear to be usefull for your market or provision work, if you are the commercial company. I can't promise the next (with the object priorities, snmp polling of the modems, service monitoring etc) version should be just as free as this one, but it should not bee 100% commercial anyway. Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

1 0

Re: cheap GPS
by Sean Donelan 23 Aug '99

23 Aug '99

scharf(a)vix.COM (Jerry Scharf) writes: >this is silly. If you compare the number of GPS receivers in the world and >the number of WWVB receivers, there should have been hundreds of thousands >to millions of complaints to have similar ratio. You forgot to compare it >to a MAE-East outage, current solar activity or hurricane Bret. Last time >I looked, nanog still had something to do with network engineering and >little to do with automotive navigation, surveying, or any of the other >GPS applications. > >In the timing world, which is the only thing that WWVB could impact, the >reports of major problems are not showing up. I didn't forget. My question was a bit of a Rorschach test. How would people perceive and compare the relative severity of two very small events. You are correct the number of GPS receivers used in timing applications, especially feeding the Internet, is a very small number compared to all GPS receivers. The number of stratum 1 clocks on the Internet is even smaller number. Most are maintained by people with a near obession for keeping track of the correct time. But I'm a psychologist. I'm interested why so many consumers didn't head the warnings, and take advantage of the the free upgrade offers from manufactures to fix their GPS units before the rollover. I mentioned I didn't find information on Pioneer's web site. Actually I just didn't go back far enough. It turns out Pioneer asked consumers a year ago to bring their units to be repaired. Another person told me about a company which needed to shutdown their operations for a couple of days because their consultant told them the wrong date for the rollover, so they weren't ready when it occured. Although I'm not sure waiting until the last week, even if you consultant did give you the wrong date, to update your equipment was very smart. And the Darwin factor is always an issue. Even after all the publicity, at least one boater who set sail without checking his GPS, needed to be rescued. When asked by reporters in Japan why they didn't upgrade their GPS receivers when the manufactures told them the units wouldn't work, consumers said "I didn't think it would affect my unit." No, I don't think japanese consumers are that different from any other consumers in the world. How does this affect network operators? Could we learn something from how consumers reacted? Do you set up a seperate contact number for consumers who waited too long, so they don't clogged up the queue for consumers with other problems? If you think its hard to reach a "cluefull" person on a normal day, will it be worse? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: "Engineer" (Was: Tech contact for Qwest?)
by smd＠clock.org 23 Aug '99

23 Aug '99

| What's wrong about a good thread lasting long ? I wish Karl Denninger (famous Internet Engineer) was here to inform us that the governments mentioned in this thread are unlawfully supporting a monopoly, and imposing a barrier to entry against perfectly intelligent, competent people, and that the correct remedy now is to sue them, and that Karl's own lawyers are already preparing a case. Sean.

1 0

Re: Tech contact for Qwest?
by Vadim Antonov 23 Aug '99

23 Aug '99

Michael Dillon <michael(a)memra.com> wrote: > That 10% mentor is more important than the percentages would suggest > because it acts as a catalyst for the other 90%. A good mentor will help > a less experienced engineer to make most effective use of their time in > learning the trade. It's not enough to just be available to answer > questions. Absolutely. Unfortunately being a teacher is a completely different profession which requires completely different talents. A lot of very good engineers are poor teachers. Having tried to teach professionally i know that it is much harder than it seems. --vadim PS Actually, i do not see shortage of clueful network engineers. What i see is complete lack of clueful managers. Engineers are often left without any useful managerial support, and all too often are simply screwed up by the bad management. That's why i think the fact that good engineers are getting more expensive is positive. When management if forced to pay through the nose for the professional expertise, they more likely feel compelled to follow the offered advice. It is quite possible to run a large backbone with two-three top-notch engineers - providing they can pick their assistants and don't have to spend most of their time dealing with bureaucratic idiocy.

6 6