- Test - lists.nanog.org

summary: gateway failover.
by foo 13 Nov '98

13 Nov '98

first of all, sorry for the duplicate message. i originally sent it without my proper from address to avoid having my primary mailbox spammed, but thought it wouldnt go through because the from address wasnt on nanog-post... second, i incorrectly referred to the rfc for IRDP as 1285, when it is 1256. re: IRDP support. the following os's/routing daemons have support: gated (version ?) Solaris (in.rdisc(1)) Windows NT (with sp3) Windows 95 (with Sockets 2) a couple of useful urls were sent my way, the most interesting being: http://www.eddieware.org which details an Open Source HA project by Ericsson (very cool), which is unfortunately only supported under Linux for the time being, though Solaris/FreeBSD support is slated for December. another from a usenix/lisa presentation with some good info is here: http://dilbert.dcs.it.mtu.edu/failover/ also, many suggestions were given for ways to accomplish this goal with network layer stuff (ospf, rip, interface aliases, proxy arp, etc.), though i was looking for an application layer solution, primarily. if you'd like details on the various suggestions, email me privately. -foo

1 0

Re: Is it time for an disruption analysis working group for the Internet?
by Sean Donelan 12 Nov '98

12 Nov '98

pete(a)kruckenberg.COM (Pete Kruckenberg) writes: >How is this handled in other networked industries? I'm sure that the same >issues of proprietary information and public humliation exist there; how >do they deal with it? Other industries, e.g. electric, airline, nuclear, telephone, railroad, banking, etc, tend to have two different reporting regimes. One for 'major events,' and one for 'near misses.' For major events, the issues of proprietary information and public humiliation tend to be less. Mainly because everyone already knows you had a major event (e.g. three-mile island, at&t nationwide failure) and the company's and industry's goals tends to focus on restoring public confidence. This seems to be true no matter what the root cause of the problem. After a major event, company records tend to get opened either voluntarily or involuntarily anyway. So most companies prefer the P.R. of saying they are cooperating fully with investigators. Although as NASA found out, sometimes you get a Richard P. Feynman on the board, who doesn't always follow the company line. I think, for some definition of major events, it should be possible to get cooperation from a large number of service providers. Once the event has happend, it is usually in their self-interest to participate in the process. Of course, there will be a few service providers who won't participate on principle or because of internal disorganization. But that's what the press is for.... For near-misses, the reporting parties tend to be individuals (a.k.a. whistleblowers) and confidentiality is more important due to the retribution even accurate information receives. And in general, 'near misses' don't attract much attention because by definition, the crisis didn't happen. I think any type of near miss reporting and analysis will be very difficult. I could rant about the U.S. Government's plans in this area are, but that is a different mailing list. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: ARIN?
by Andrea Di Lecce 12 Nov '98

12 Nov '98

At 10:40 11/5/98 -0500, Brandon Ross wrote: >> Looks alot like /14 & change. That would be 256K plus delegated - 210K users >> Hey, your right, not a bad packing ratio. Hows yours? :) > >How's 2 /16's & change, 128k addresses - 455k users. I think I win. (In >an effort to fully disclose, about 20% of those users are on wholesale >dialup providers). Cable modem subscribers normally are not dynamically assigned IPs like dialups. Besides, they are advertised as a constant connection, and a lot of people use it as such. ************************************************** Andrea Di Lecce (416) 935-5700 Rogers@Home Network Operations 1 Mount Pleasant Road, Toronto, M4Y 2Y5 **************************************************

26 39

gtld failure
by Randy Bush 12 Nov '98

12 Nov '98

[ apologies if this message is our of time sync due to my travels making net access sporadic ] i think the net would appreciate (some might say deserves) a technical (not political) post mortem by a neutral party. like could we get sean donelan to sort out what actually happened and report? randy

1 0

gotta love those internic boyz
by Paul A Vixie 12 Nov '98

12 Nov '98

the facts are, internic's own servers (f.gtld-server.net etc) were sending back NOERROR/NOANSWER whereas my server was sending back a lame delegation. that means clients would try other servers to gain the right final answer if they got a bad answer from my server, but they would just report a fatal application error ("host not found") if they contacted an internic gtld server. the other fact of note is that the reason my server was lame had to do with some kind of provisioning problem inside internic or its isp. my own mrtg graphs are clean for this period, and internic was the only site i couldn't reach at high bandwidth. f.root-servers.net was lame for two days because it could not fetch COM from NSI. yet NSI, in its statements to reporters and to users, are of the following form. it is REALLY DAMNED HARD to not get pissed off at this kind of BS. *MY* server was not sending fatally bad answers, *THEIRS* were. i've been in touch with wired news and have been queried about this from CNN and i'll be telling the whole story to every reporter who can reach me. i've seen holtzman's comments about "unreliable volunteer servers" in the WSJ in the past and i'm no longer willing to sit by and be slandered when it was NSI's problem all along. (tcpdump doesn't lie.) (a total of five servers were having trouble, of two different kinds, so this was a complex failure situation.) ------- Forwarded Message Date: Wed, 11 Nov 1998 18:18:45 -0800 (PST) To: Paul A Vixie <paul(a)vix.com> Subject: Re: FYI F.ROOT-SERVERS.NET In-Reply-To: <199811120201.SAA09783(a)bb.rc.vix.com> Oops! Sorry to bug you. When I called them their folks told me "That server isn't run by Internic so you'll have to contact them about the fact that they run an unreliable server..." What a bunch of dweebs. Take care, > network solutions (the current internic contractor) was having connectivity > problems that made it impossible for us to fetch the zone. all is now well. > > > Just an FYI, but I don't think your root server is properly configured. > > Internic thinks it should be authoritative for .com. Maybe they have their > > SOA wrong? ------- End of Forwarded Message

3 2

NANOG 14 thanks
by David Diaz 12 Nov '98

12 Nov '98

I wanted to thank everyone who came and helped with NANOG 14. It was an absolute pleasure to meet everyone who attended. If there is a regret it's that we wish there was time to met with everyone there. Our engineers were universally excited and greatful to have the opportunity to exchange experiences with all those they spoke with. It was an honor as well as a pleasure to host nanog. I highly recommend it to anyone even considering it. It may look like work but it was all Fun. Thanks again to all especially the Merit folks. Next time no oversubscription factor on the power strips. 1 strip per attendee a must!! David PS-Anyone needing power strips or anything else for another NANOG I think we may be able to help. And next time PLEASE dont flood ping Bellsouth, they have no sense of humor! Thank you, David Diaz Chief Technical Officer Netrail, Inc email: davediaz(a)netrail.net pager: 888-576-1018 office: 888-NETRAIL Fax: 404 522-2191 Colo facilities: Atlanta-NAP, Miami, Arlington, Chicago, San Francisco ------------------------------------------------- Hosting NANOG 14 in Atlanta Nov 8-10

1 0

was i asleep when the gtld servers had the worse problem today?
by Paul A Vixie 12 Nov '98

12 Nov '98

http://www.news.com/News/Item/0,4,28664,00.html?st.ne.fd.mdh

4 3

Re: QUICKER FIX Re: [fjk].gtld-servers.net bogus for .com
by Scott Gifford 12 Nov '98

12 Nov '98

>> > Many thanks to my friend & cow-orker Tristan Horn for this >> > idea...in BIND 8 you can define servers as bogus (meaning >> > "don't ever trust these") as follows: >> > >> > // [fjkl].root-servers.net >> > server 192.5.5.241 { bogus yes; }; >> > server 198.41.0.10 { bogus yes; }; >> > server 193.0.14.129 { bogus yes; }; >> > server 198.32.64.12 { bogus yes; }; > >i recommend against that. > Do you recommend against this particular way of telling BIND to temporarily ignore name servers which are known to be a little, errr, funky? Or do you recommend against ignoring broken name servers in general?.. I guess what I really would like to know is how did you handle this problem? :) Just wondering, --------Scott.

2 1

WCCP talk..
by alex＠nac.net 12 Nov '98

12 Nov '98

Unfortunately, stage fright prevents me from asking this question on the NANOG meeting floor. My understanding of WCCP is that the server is responsible to tell the WCCP-enabled Cisco router that, "Hey, I'm alive to recieve port 80 requests!" My question is, what prevents a cache from seding a WCCP frame saying, "Hey, I'm alive" when it really isn't? Is there a way for the router to check the cache in the opposite direction? Seems odd that your would rely on the cache to verify that the cache is OK. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP; we have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

6 14

ANS routing problems?
by Aleksi.Suhonen＠saunalahti.fi 11 Nov '98

11 Nov '98

Hello, We are having routing problems with ANS. They are not accepting our routes from AS3561. They were excepting them just fine about a week ago, but around last week end our routes dissappeared from their AS. Current status, with AT&T as an example of a working routing status: route-views.oregon-ix.net>sh ip b r ^1673_.+_6667 route-views.oregon-ix.net>sh ip b r ^7018_.+_6667 BGP table version is 4987768, local router ID is 198.32.162.100 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 195.74.0.0/19 12.127.0.249 0 7018 3561 5556 6667 i * 195.197.0.0/16 12.127.0.249 0 7018 3561 5556 6667 i * 195.218.64.0/19 12.127.0.249 0 7018 3561 5556 6667 i * 195.238.192.0/19 12.127.0.249 0 7018 3561 5556 6667 i Since all their NS and MX records are within their own network, contacting them is rather impossible, so I turn to the NANO group for helpful hints on how to resolve the problem. -- Aleksi Suhonen Network Development Saunalahden Serveri Oy AXU-RIPE

2 1