- NANOG - lists.nanog.org

Re: Optical Crossconnects and IP
by Vadim Antonov 08 May '00

08 May '00

> ** Disclaimer; I work for a vendor: PLURIS, but this question concerns a > personal curiosity that I have about OXCs. ** Disclaimer: I do not work for a vendor: PLURIS > I also don't > see much NSP participation in the relevant standards bodies about signaling > in optical networks. Probably because the said standards bodies (and on-demand fiber capacity allocation in general) have little relevance to the NSPs and Internet backbones in general? --vadim PS I keep wondering why people keep reinventing virtual circuits.

2 1

Optical Crossconnects and IP
by Bora Akyol 08 May '00

08 May '00

** Disclaimer; I work for a vendor: PLURIS, but this question concerns a personal curiosity that I have about OXCs. ** ------------------------------------------------ There has been a lot of work going on about how to utilize OXCs in an internetwork at both OIF and ODSI (and some IDs in IETF). A couple of themes have been emerging: 1. Use the OXCs to set up paths akin to MPLS LSPs. This is great for providers that have MPLS, but what about pure IP-based backbones. 2. Decide which routers connect with what other routers (within the same domain) using configuration. Then use signaling to create circuits between the routers to connect them. I would like to hear about what people are thinking about OXCs, how they are intending on utilizing them, what functionality to they expect from their routers. Let me put in my two cents worth: --------------------------------------------- It is hard not to think of the OXC-based circuit model as another overlay network, but it brings distinct provisioning advantages in terms of speed and flexibility. There apparently are some cost advantages as well. On the other hand, the OXC based optical network is a change in some manner from a converged IP over optical network architecture where IP routers plug directly into DWDMs and have enough ports to handle all of the traffic. For NSPs that have already an MPLS or ATM solution, an OXC-based circuit switched model is not a big leap, but for all IP shops it is. I also don't see much NSP participation in the relevant standards bodies about signaling in optical networks. Thanks in advance Bora Akyol

1 0

GTE DNS?
by Zaid Ali 08 May '00

08 May '00

Is there a known outage on GTE DNS? Zaid ------------------------------------------ Zaid Ali Network Architect WebEx 110 Rose Orchard Way San Jose, CA 95134 Tel: 408-435-7251 fax: 408-435-7004 www.webex.com ----------------------------------------

1 0

Australia OPTUS outage investigated (was Re: DACS blamed for MCI / CSX train problems last week)
by Sean Donelan 08 May '00

08 May '00

On Mon, 08 May 2000, Mohamed Hirse wrote: > A start would be if carriers architecture their network to be redundant > and self healing. Some do, compare Worldcom's reliability to Sprint's reliability. Of course, after the merger things may change (FUD, FUD, FUD). But even then you can have more outages than you can handle. For example, Cable&Wireless OPTUS network in Australia experienced dual fiber outages within a couple of hours bringing much of their network down. http://www.newsbytes.com/pubNews/00/148623.html The most reliable network I know about, FEDWIRE, only has 3-5 way diversity. How does the fed assure the carriers actually route the circuits they way they were ordered? I don't know.

1 0

DACS blamed for MCI / CSX train problems last week
by Sean Donelan 08 May '00

08 May '00

According to Computerworld, the MCI outage affecting CSX rail lines last week was caused by DACS problems. http://www.computerworld.com/home/print.nsf/all/000505DCCE This isn't the first DACS problem nor is MCI the only carrier affected by DACS problems. Bell Atlantic had a multi-day DACS problems, I've experienced 18+ hour MCI DACS problems in the past. What is it about DACS systems which seem to lead to such catastrophic problems? How can you put an entire train system out of operation due to a single piece of equipment?

2 1

Re: Alert timeline for Love Bug
by Neil Long 07 May '00

07 May '00

Just to add that I got an alert from Sophos (another anti-virus vendor) with their detection module at 11:24 (UTC+1) here in the UK They had classified it as Name: VBS/LoveLet-A Type: Visual Basic Script worm Neil

1 0

Alert timeline for Love Bug
by Sean Donelan 07 May '00

07 May '00

Senator Bennet from Utah wants to know where the FBI was when the "Love Bug" began circulating through e-mail systems in the USA. I thought I would try to figure out when various different alerts first reached the public from various sources. Although there may be some "private" alerts earlier, I don't have a good way to find out their timestamps. I've tried to normalize all times to UTC. 4-May-2000 10:17 UTC NANOG posting 4-May-2000 12:54 UTC AP (Hong Kong) 4-May-2000 13:17 UTC Reuters(London) 4-May-2000 13:30 UTC ZDNet News 4-May-2000 13:31 UTC F-Secure press release 4-May-2000 14:30 UTC Financial Services Information Sharing Alert 4-May-2000 14:30 UTC CERT/CC Alert 4-May-2000 14:38 UTC Symantec press release 4-May-2000 15:00 UTC FBI/NIPC Alert 4-May-2000 15:05 UTC Computer Associates press release 4-May-2000 16:19 UTC Trend Micro press release I think the FBI did pretty well. In context, the FBI alert came out approximately the same time as most commercial virus vendor press releases. I'm not surprised NANOG beat the FBI or CERT by 4 to 5 hours. But I think I missed some news reports. Does anyone know of any verifiable public alerts or news stories about the "Love Bug" before 1017 UTC?

2 2

Re: tcp port 8311?
by Dean Robb 07 May '00

07 May '00

At 12:06 PM 5/3/00 -0700, K. Graham wrote: > >What is the name of the log file that is generated from this program? >Where is the log file placed in the system? Did you check to see if >there is any residual traces of the programs in the registry? If so >where? Do you know the name(s) of the *.vbs you have encountered? Only one gave me solidly useful clues: All the traces were n.*...the * being various VisualBasic-related extensions. The one that gave me useful info was n.log - showed the modem log and dialout times, etc, but not a list of what was transmitted. The number the modem dialed was XXX'd out; and the transmission stats showed the 10megs. The end user confirmed that, although he was doing some VB6 programming for a class, it wasn't his script and that no one was home at the time the dialout occured. Unfortunately, the system was unstable as hell and I was lucky to get this data before it crashed completely; W98 wouldn't load at all because of (suspected) corrupted files. Before it crashed completely (and the reason the end user called me) was that upon W98 boot, a system error would be displayed saying RPCSS.dll had caused a GP fault in OLE32 and then a VB debug session would start and freeze. The other encounter showed similar symptoms but left no clues that I could find. >Virus_Research(a)NAI.com, samples(a)f-secure.com, and support(a)sophos.com >all are addresses where suspect files can be sent. They prefer them in >a zip format before accepting them. If I'd been able to get samples, I'd surely forward them. Bet these clients keep their McAfee updated and running from now on :). "Microsoft is not a monopoly!" - Bill Gates "HA!" - Judge Jackson Dean Robb Owner, PC-EASY (757) 495-EASY [3279] On-site computer services Member, ICANN @Large

1 0

RE: DomainSiren.com Whois records alert service
by Roeland Meyer (E-mail) 07 May '00

07 May '00

Cute dude. OTOH, this probably has enough operational content to merit posting to NANOG. Now all we need is for some script-kiddee to figure it out <groan>. > Behalf Of domainiac > Sent: Saturday, May 06, 2000 4:08 PM > > I figured out a way to completely hijack a domain in less > than week under > the new shared system. And by hijack I do not mean simply > redirect the DNS, > etc. I mean completely change the whois record to a new > owner. I won't post > specific directions but I am sure others could do the same > trick as it is > not that complicated. I passed the specific directions onto > ICANN but who > knows if they are likely to do anything. The vulnerability > only applies to > NSI domains with MAIL-FROM (or when their CRYPT-PW system screws up). > > I set up an automated system that reads both the registry and > registrar > records, compares it the stored records, and automatically > e-mails contacts > with the changed info. It also can be used to track domains > about to be > released. > > http://DomainSiren.com > > Russ Smith > http://ChangeYourDomain.com

1 0

Re: DACS blamed for MCI / CSX train problems last week
by Joe Abley 06 May '00

06 May '00

[apologies in advanced for the pitiful layout that Outlook Express will no doubt inflict on you after I click send] -----Original Message----- From: Sean Donelan <sean(a)donelan.com> To: nanog(a)merit.edu <nanog(a)merit.edu> Date: Saturday, May 06, 2000 3:04 PM Subject: DACS blamed for MCI / CSX train problems last week >This isn't the first DACS problem nor is MCI the only carrier affected >by DACS problems. Bell Atlantic had a multi-day DACS problems, I've >experienced 18+ hour MCI DACS problems in the past. What is it about >DACS systems which seem to lead to such catastrophic problems? I don't believe there is anything unherently unreliable in a DACS (we call them Digital Cross-Connects, or DCCs, down here). In fact, most DCCs I have seen are extrordinarily redundant and would probably quite happily continue to function at 100% after a good seeing-to with an axe. The problem lies elsewhere. "Modern" telecommunications equipment seems to come equipped with two configuration paradigms: [1] will usually be a vendor-supplied Unix solution, probably running on Sun or HP hardware, which provides a full database back-end and a simple point-and-click interface for end-to-end service management. This is what the engineering planning people see when the system is demonstrated to them, and this obvious money-saving wonder is what will justify the inflated budget required to purchase it. [2] will probably be 9600 bps terminal access to a protracted series of cryptic menus, about sixteen levels deep, through which the only practical way to navigate is to type ahead protracted strings such as "1,4,9,13-17,3,3,1" and then walk away for ten minutes to drink coffee. [1] will usually stop working properly about four weeks after the vendors disappear from site. Various technicians who have either a vague idea of the network technology, or a self-taught-at-home expertise in Linux, will attempt to fix the problem. The IT department will be called in, and will limp through a SunOS 4.1.3 install from QIC tape, and may even get as far as completing a successful reinstallation of the vendor's management system (at which point it will become clear that the back-end is an embedded version of Informix, for which the licence keys are either missing or have mysteriously transformed themselves into one-week demo licences for some completely unrelated product). Hence [1] will quickly cease to be a useful tool for provisioning services. Of course, the business doesn't stop just because one management system is broken; we always have [2]. [2] is extremely vulnerable to radical accidental reprogramming of the network due to caffeine-induced finger-shake, but quickly becomes a preferred tool for programming the network for a certain subset of the network provisioning technicians. Those who discover that they can script routine tasks using shareware terminal packages will also become able to perform radical accidental reprogramming of the network whilst standing on the keyboard, reaching back to tape laser-printed Dilbert cartoons or semi-pornographic calendars to cubicle walls. Any change using [2] will naturally never be reflected in the database of [1]. This fact will be recognised whenever someone manages to get [1] temporarily back on its feet, and will trigger a seemingly endless series of network audit projects, which will never succeed due to the underground popularity of [2] and the fact that anybody competent enough to perform a network audit does their very best to escape from the project at the earliest opportunity, leaving no indication whatsoever of what they have found out so far. The unreliability of any network records means that any troubleshooting is likely to involve far more random guesswork than is healthy, and the probability of a cascade of outages following routine maintenance on a minor issue is much higher than you would expect. On the other hand, it could be simply that marketing departments have observed that customers are happy with the phrase "DACS outage" and therefore use it as a generic term to describe any incident which might otherwise cause a customer to complain :)

1 0