- Test - lists.nanog.org

got any good dirt on 12.0.X(S)?
by scott w 03 Jan '00

03 Jan '00

I'm looking for anything on IOS 12.0.X(S). The Good, the Bad, *and* the Ugly. Mostly the Bad and Ugly.... I haven't found too much in the archives. If I missed it let me know, I've got my flameproof panties on... 8-) Most likely, private replies are best. I'll summarize later if there is sufficient interest. Thanks, scott

1 0

BGP session resets
by Sean Donelan 02 Jan '00

02 Jan '00

In the last 48 hours I have received several reports about different providers resetting or reloading ALL of their external BGP sessions due to problems. I have not heard why the ISP reset their sessions, or details of what the problem is/was. At first I just assumed it was normal maintenance activity. ISPs do reload their BGP sessions on a regular basis. But as additional reports are coming in, it doesn't seem to be normal maintenance. The resets are ISP network-wide, and happening outside of typical maintenance windows. I have reports four different ISPs needed to reset their BGP. A small number, and it may just be because people are watching things a bit closer than normal. Does anyone know why ISPs are doing this?

1 0

Re: mail does bounce (was: Customers down?)
by Sean Donelan 02 Jan '00

02 Jan '00

On Sun, 02 January 2000, Owen DeLong wrote: > I'll take a stab at this: > > Attempting to resolve a.b.c.d.e.f.g.h.i > > If you get back a return value from DNS that says > "Authoritative answer, a.b.c.d.e.f.g.h.i does not exist" > Bounce the mail. > > If you get back a return that says > "Resolving a.b.c.d.e.f.g.h.i timed out without a return" > Queue the mail. > > This also works for i, h.i, g.h.i, f.g.h.i, etc. I'm happy to agree this is a very sensible thing to do. However, there is no requirement for any mailer to do it. Some mailers may, but other mailers may not. So it is not very wise to assume all mailers work the same as yours. There is a written recommendation that domains should have DNS servers on seperate networks. There is no such recommendation that mailers retry or queue mail when they can't reach DNS servers.

1 0

Re: mail does bounce (was: Customers down?)
by owen＠dixon.delong.sj.ca.us 02 Jan '00

02 Jan '00

> On Sat, 01 January 2000, "Steven J. Sobol" wrote: > > What I was referring to was a situation where the domain does exist in the > > root nameservers but the authoritative nameservers are unavailable. > > So .COM exists in the root servers? How do you decide to treat second > level domains (i.e. donelan.com) versus third level domains > (i.e. www.donelan.com) versus third level domains under country code > domains. > > > > > > I'll take a stab at this: Attempting to resolve a.b.c.d.e.f.g.h.i If you get back a return value from DNS that says "Authoritative answer, a.b.c.d.e.f.g.h.i does not exist" Bounce the mail. If you get back a return that says "Resolving a.b.c.d.e.f.g.h.i timed out without a return" Queue the mail. This also works for i, h.i, g.h.i, f.g.h.i, etc. Owen

3 2

an anticipated y2k situation
by scott w 02 Jan '00

02 Jan '00

My prediction was the NANOG mailing list would see a large increase in traffic due to y2k. It did. And here's one more... ;-) Happy new year/century/millennium everyone!! scott

1 0

RE: mail does bounce (was: Customers down?)
by owen＠dixon.delong.sj.ca.us 02 Jan '00

02 Jan '00

> > > > I think I like it better that way. Just because both nameservers are > > > temporarily down doesn't mean the domain doesn't exist. :P > > > > Seems to me you're talking past one another. If all nameservers for a > > domain are down there *is* no nameserver which can say that the domain > > is authoritatively non-existent. (OK, you could get a negative caching > > answer from one of the authoritative servers on the level above, but > > that's a different issue...) > > > > I agree with Greg Woods - if a domain is authoritatively non-existent, > > I'd expect a sane mailer to bounce the message. > > I'm glad that you don't write code, especially sendmail code. > > I'm hoping that some clarification of terms will kill this thread... There is a difference between the following terms: Authoritatively Non-existant domain: A domain for which the servers authoritative for the parent zone report that the domain does not exist. Unreachable Authoritative Servers: A domain which exists and posesses a delegation in it's parent servers, but which authoritative servers are currently not reachable. The former is regarded as a permanent error and mail is immediately bounced by every mailer I know of. The latter is a transient error and is treated as such by sendmail. I would hope it would be treated as such by other mailers. Owen

1 0

Re: [shadyron@total-bollo.cx: What happened in the UK]
by michael.dillon＠gtsip.net 02 Jan '00

02 Jan '00

On Sat, 01 January 2000, Joe Abley wrote: > We rolled over 1h35m ago. Rollover saw (locally) two of the four mobile > networks drop the users in the room with me (ie they saw coverage totally > drop). However, the other two networks: Orange & One2One were fine, with > users being able to make and receive calls fine. Attempting to call from > Orange -> {Cellnet | Vodafone} received either line busy or network busy. I was on the Westminster bridge near Big Ben at midnight and it was amazing how many people were pulling out cellphones just before midnight to phone up friends in other places like Sydney or New York. When people commented on being unable to make cellphone calls I asked what network they were on and most were on Vodafone but some were on One2One. Then about ten minutes into the fireworks display I decided to try making a phone call but my Orange mobile no longer had service so they were down too. I suspect this may be a combination of too many people in one small area (3 million in the streets of Central London) and too many simultaneous attempts at making a cellphone call. I think that cellphone use is a lot more common here in Europe than in North America. I sat on a train watching ten year-olds sending SMS messages to each other on their cellphones. As more and more such wireless devices are deployed, the possibility of localized overload becomes much greater. I experienced a similar overload four years ago at a technology conference held at a ski resort on top of a mountain which attracted more cellphone users than the single cell on the mountain could handle. Is this something that wireless TCP/IP can alleviate or is bigger infrastructure the only cure? --- Michael Dillon Phone: +44 (20) 7769 8489 Mobile: +44 (79) 7099 2658 Director of Product Engineering, GTS IP Services 151 Shaftesbury Ave. London WC2H 8AL UK

1 0

TDL .it maybe down???
by Giorgio Lembo 02 Jan '00

02 Jan '00

Hello, Has anyone noticed any strange behaviour in dns.nic.it? Thanks Cheers, Giorgio --- [root 17:15:02:giorgio]# nslookup Default Server: localhost Address: 127.0.0.1 > server 194.185.132.253 Default Server: venere-eth1.inet.it Address: 194.185.132.253 > www.iol.it Server: venere-eth1.inet.it Address: 194.185.132.253 Non-authoritative answer: Name: www.iol.it Address: 195.210.91.83 > www.nic.it Server: venere-eth1.inet.it Address: 194.185.132.253 *** venere-eth1.inet.it can't find www.nic.it: Non-existent host/domain --- Giorgio Lembo INS Ltd - Milano

1 0

ISP Y2K mailing list summary
by Sean Donelan 02 Jan '00

02 Jan '00

This was the final summary post for the NANOG ISP Y2K mailing list. Special thanks to Merit for allowing the ad-hoc group of Internet Service Providers to share the name for the NANOG ISP Y2K event. This post is a couple of hours early, because I want to go to sleep. NANOG ISP Y2K Summary Status 2-JAN-2000 12:30 UTC Y2K Summary Although the "hotlines" got a lot of press, much of the information came via e-mail. It was difficult to dial into the international conference bridges near midnight in various countries due to congestion on the international voice circuits. The Internet is a dynamic place. All numbers may vary depending on where you are on the Internet. But the trends should be the same. The Internet global routing table showed a slow decline in networks from 71,200 on December 25, 1999 to 70,911 on December 30, 1999. On December 31, 1999 the networks steadily declined to 69,812 by 1 hour before Midnight EST. During this hour the routing table quickly dropped to 67,795 routes, and held steady from Midnight until 5am EST. After 5am EST January 1, 2000 the number of networks started increasing steadily to 70,455 on January 2, 2000. The number of unique ASNs in the global route table declined from 6,380 on December 30, 1999 to 6,330 at January 1, 2000 Midnight EST. The number of terminating ASNs showed a similar decline from 5,180 to 5,130. Which leads to the conclusion transit networks did not disconnect during the rollover. Peak traffic levels across MAE-East were lower on Friday December 31, about 1.6Gb versus 1.9Gb for a normal workday. There was a slight but noticable 0.2Gb dip in traffic at Midnight EST. Followed by a slight increase after Midnight EST. All well below peak traffic capacity. Traffic flow followed the normal sine wave pattern, except for the dip at Midnight EST. Summary of ISPs 2 ISPs reported a routing problem, isolated to normal circuit problems. 1 ISP reported voice-call (POTS) congestion in New Zealand shortly after midnight through several voice carriers. Internet backbone connectivity was not affected. This was the pattern through most time zones. Several ISPs reported trouble synchronizing NTP servers. Congestion on the NIST network is believed the cause. NTP servers elsewhere did not show any problems. 1 ISP reported messages sent in elm showed year as 100 instead of 2000. Patch was available prior to Y2K. Several reports of user-written scripts containing poor date handling practices. Report of one web site defacement after close of business. Report of some unauthorized domain name transfers at the beginning of the holiday weekend. Not unusual, seems to happen every holiday weekend. Two ccTLDs were down for part of the rollover. 13 ccTLDs had partial problems. No Y2K faults were found. Circuit problems, administrators turning off servers, and ordinary DNS problems. Exchange points worldwide reported a decrease in traffic immediately before their midnight local time. A sharp increase immediately after midnight local time, but less than peak capacity. Certain "event" web sites saw traffic increase 20 times over normal levels. Some event sites report being overwhelmed. But overall, traffic appears to have been lower than peak business day capacity. The use of many country-specific information sites, and the rolling nature of the Y2K event helped distribute the traffic worldwide. In general public interest waned about 30 minutes after local Midnight in each timezone, leaving more bandwidth for each successive timezone. Midnight US Eastern time did dominate changes in traffic and routing. A few rumors sprung up throughout the night. Most were quickly determined to be unfounded. But overall, not as many as I thought would spread. Issues known/predicted prior to the Y2K rollover Some sites plan to shutdown or disconnect from the Internet over the New Year's weekend Some certificate authority certificates expire on December 31, 1999 Increase in voice and cellular calls immediately around local midnight may cause some congestion on circuits Information from the media (Note: ISP names are from publicly announced information. Names will not be included from non-public sources.) C I Host (www.cihost.com) issued a press release about a name server problem. No client data files were damaged. The data corruption that occurred Dec. 29 is isolated to the [company local] nameservers only and the restoration remains unrelated to any Y2K issues. Keynote Internet Performance Update #2 reports slower access to New Zealand after rollover, 6.2 seconds. No information what the measurement was before the rollover. Appears to be localized to specific web sites (i.e. congestion) France's National Weather Service Internet site had a display problem with a date. The page shows 01/01/19100 instead of 01/01/2000. United States Naval Observatory web time site had a display problem with a date. The page shows 19100 instead of 2000. Hacker target Japan Y2K Center. No intrusion or damage reported. Several stories based on Keynote press releases report the Internet passed through the Y2K rollover unaffected, other than a few spots of congestion around particular web sites. The www.y2k.gov web servers were predicted able to handle 40 million hits. Only 3 million showed on January 1. Many, MANY, ISPs, web hosting, and access providers issued press releases throughout January 1, 2000 announcing they had no Y2K problems (and I think they all sent me a copy). Summary from the Y2KCC/JP The number of reported troubles 25 Troubles with Stratum1 NTP server 4 Trouble with ICQ 1 Troubles with ccTLD 15 small partial troubles 13 others 2 Trouble with router 1 Trouble with Y2KCC/JP system 1 Latency of a particular site 1 Suspect of cracking 1 Trouble with NNTP server 1

1 0

UK GMT roll over
by Neil J. McRae 02 Jan '00

02 Jan '00

GMT and CET rolled over without any major incidents. The cellular networks were busy but thats to be expected. Regards, Neil. -- Neil J. McRae - Alive and Kicking. neil(a)DOMINO.ORG

12 13