- Test - lists.nanog.org

Re: GTEI/Exodus
by mark＠exodus.net 16 Sep '98

16 Sep '98

Exodus has been carrying the traffic on our backbone since the beginning. -----Original Message----- From: Jon Zeeff <jzeeff(a)verio.net> To: Tim Wolfe <tim(a)clipper.net> Cc: list(a)inet-access.net <list(a)inet-access.net>; nanog(a)merit.edu <nanog(a)merit.edu> Date: Tuesday, September 15, 1998 5:05 PM Subject: Re: GTEI/Exodus | |Or perhaps Exodus is evening out the byte miles between source and destination |ISPs by hauling traffic closer to the destination before it leaves |their network. | |> > GTE Internetworking has joined with Exodus Communications, Inc. to speed up |> > their customers' access to the Internet. |> Hmm.. not to start another massive thread here, but I wonder if this means |> that Exodus is now paying for transit and/or peering? *************************************************************************** Mark Tripod - Senior Network Architect - Exodus Communications http://www.exodus.net - (888) 2-EXODUS - support(a)exodus.net ASN 3967 - NASDAQ (EXDS) - Direct: (408) 346-2389

2 1

Worldcom Fibrecut again in VA
by mwinter＠exodus.net 16 Sep '98

16 Sep '98

Just in case you too see the same old lines from last friday go down again. Worldcom has another nice fibrecut in VA between Fredricksburg and Bowling Green. Same lines as last friday's train derailment for us.... - Martin Winter Exodus Communications

1 0

Re: Hi, I'm from Cable and Wireless and I'm here to help...
by Sean Donelan 16 Sep '98

16 Sep '98

>In the interest of the free flow of useful and correct information >with regard to the divestiture of internetMCI, please do not believe >anything you hear, rather feel free to ask. There are a number of >ex-MCI'ers listening and we'll be happy to debunk rumors from whatever >source. Basic rule, if it came from anything but a 'cw.net' address >please ask before you jump in. Hi. I'm updating my customer service and NOC phone number lists. Will the InternetMCI still be using MCI exchanges and call centers, or will the phone numbers be changing to C&W exchanges? Thanks, sean. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: Marc Slemko: Re: Hi, I'm from Cable and Wireless and I'm here to help...
by Jeffrey S. Young 16 Sep '98

16 Sep '98

and for my next trick.... imagine if tomorrow, someone came to you and told you to change your domain name on every piece of equipment in your network, tease apart years of interconnection with your parent company, etc... in other words, ignore the semantics, it's the thought that counts. Jeff Young wrote: > ------- Forwarded Message > > Return-Path: marcs(a)go2net.com > Received: from ALPHA1.RESTON.MCI.NET (alpha1 [204.70.128.80]) > by postoffice.Reston.mci.net (8.8.5/8.8.5) with ESMTP id OAA15398 > for <young(a)pdp11-bak.reston.mci.net>; Wed, 16 Sep 1998 14:31:23 -0400 (EDT) > Received: from redfish.go2net.com ([207.178.55.5]) > by ALPHA1.RESTON.MCI.NET (PMDF V5.2-29 #27226) > with SMTP id <01J1VLRE3BF00012QB(a)ALPHA1.RESTON.MCI.NET> for > young(a)pdp11-bak.reston.mci.net (ORCPT rfc822;young(a)mci.net) Wed, > 16 Sep 1998 14:31:22 EDT > Received: from marcs by redfish.go2net.com with smtp (Exim 1.82 #2) > id 0zJMLU-0000xc-00; Wed, 16 Sep 1998 11:30:28 -0700 > Date: Wed, 16 Sep 1998 11:30:28 -0700 (PDT) > From: Marc Slemko <marcs(a)znep.com> > Subject: Re: Hi, I'm from Cable and Wireless and I'm here to help... > In-reply-to: <199809161751.NAA25868(a)foghorn.Reston.mci.net> > Sender: Marc Slemko <marcs(a)go2net.com> > X-Sender: marcs@redfish > To: Jeff Young <young(a)mci.net> > Message-id: <Pine.GSO.4.02A.9809161129590.26825-100000@redfish> > MIME-version: 1.0 > Content-transfer-encoding: 7BIT > Content-Type: TEXT/PLAIN; charset=US-ASCII > Content-Length: 634 > > On Wed, 16 Sep 1998, Jeff Young wrote: > > > Folks, > > > > In the interest of the free flow of useful and correct information > > with regard to the divestiture of internetMCI, please do not believe > > anything you hear, rather feel free to ask. There are a number of > > ex-MCI'ers listening and we'll be happy to debunk rumors from whatever > > source. Basic rule, if it came from anything but a 'cw.net' address > ^^^^^^^^^^^^^^^^^ > > Says he posting from a mci.net address. <g> > > Sorry, couldn't help but find that ironical. > > > please ask before you jump in. > > > > Jeff Young > > young(a)cw.net > > > > ------- End of Forwarded Message

1 0

Hi, I'm from Cable and Wireless and I'm here to help...
by Jeff Young 16 Sep '98

16 Sep '98

Folks, In the interest of the free flow of useful and correct information with regard to the divestiture of internetMCI, please do not believe anything you hear, rather feel free to ask. There are a number of ex-MCI'ers listening and we'll be happy to debunk rumors from whatever source. Basic rule, if it came from anything but a 'cw.net' address please ask before you jump in. Jeff Young young(a)cw.net

5 7

RFC 974 - Mail Routing and the Domain System
by Michael J. Maravillo 16 Sep '98

16 Sep '98

Hello, 'Just want to clarify something... is there a difference between: domain.com. MX 10 mx1.domain.com. domain.com. MX 10 mx2.domain.com. domain.com. MX 10 mx3.domain.com. ;... mx1.domain.com. IN A 10.0.0.1 mx2.domain.com. IN A 10.0.0.2 mx3.domain.com. IN A 10.0.0.3 and: domain.com. MX 10 mx.domain.com. ;... mx.domain.com. IN A 10.0.0.1 mx.domain.com. IN A 10.0.0.2 mx.domain.com. IN A 10.0.0.3 >From RFC 974: "...Note that multiple MXs may have the same preference value. In this case, all MXs at with a given value must be tried before any of a higher value are tried..." Is the behaviour the same with the round-robined configuration? Thanks in advance, Mike _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com

5 5

DNS Zone Serial Numbers
by James R. Cutler 16 Sep '98

16 Sep '98

As long as one is interested in DNS zone SOA record serial numbers, it is convenient to use the following script to simplify the user interface and view. Of course, this assumes an operating system with a shell. I would love a translation to perl so I could run it on my MacOS machine. :) JimC <cut to here> #!/bin/sh if test "$1" = "" then echo usage: $0 domain exit 1 fi DOMAIN=$1 # # Use nslookup to discover the nameservers for this domain ($1). # Use awk to grab the name server names from the nameserver lines. # (The names are always in the last field). Use sort -u to weed out # duplicates; we don't actually care about collation. # SERVERS=`nslookup -type=ns $DOMAIN |\ awk '/nameserver/ {print $NF}' | sort -u` if test "$SERVERS" = "" then # # Didn't find any servers. Just quit silently; nslookup will # have detected this error and printed a message. That will # suffice. # exit 1 fi # # Check each server's SOA serial number. The output from # nslookup is saved in two tmp files: nso.$$ (standard output) # and nse.$$ (standard error). These files are rewritten on # every iteration. Turn off defname and search since we # should be dealing with fully qualified names. # # NOTE: this loop is rather long; don't be fooled. # for i in $SERVERS do nslookup >/tmp/nso.$$ 2>/tmp/nse.$$ <<-EOF server $i set nosearch set nodefname set norecurse set q=soa $DOMAIN EOF # # Does this response indicate that the current server ($i) is # authoritative? The server is NOT authoritative if (a) the # response says so, or (b) the response tells you to find # authoritative info elsewhere. # if egrep "Non-authoritative|Authoritative answers can be" \ /tmp/nso.$$ >/dev/null then echo $i is not authoritative for $DOMAIN continue fi # # We know the server is authoritative; extract the serial number. # SERIAL=`cat /tmp/nso.$$ | grep serial | sed -e "s/.*= //"` if test "$SERIAL" = "" then # # We get here if SERIAL is null. In this case, there should # be an error message from nslookup; so cat the "standard # error" file. # cat /tmp/nse.$$ else # # Report the server's name and its serial number. # echo $i has serial number $SERIAL fi done # end of the "for" loop # # Delete the temporary files. # rm -f /tmp/nso.$$ /tmp/nse.$$ - James R. Cutler EDS , 800 Tower Drive, Troy, MI 48098 Phone: +1 248 265 7514 FAX: +1 248 265 7514 EDS Internal Web: <http://www.iscg.eds.com/cutler/> World Wide Web: <http://www.ltu.edu/midecus/dechtm/cutler/cutler.htm>

2 1

got any good documents ?
by kbrown＠teamhuber.com 16 Sep '98

16 Sep '98

I am preparing to give a presentation to end-users about using ATM technologies in their environments. I'm doing well, with the exception of finding a way to "dumb-down" ATM addressing. Might any of you have already dealt with this issue...say perhaps with your managers? :=) If you have a document which might assist me with reducing the overhead required to explain this, and you don't mind me borrowing some of the context... please zap it my way. It will be greatly appreciated. Kevin Brown kevin(a)teamhuber.com

3 2

long delay between circuits..
by jhyang 16 Sep '98

16 Sep '98

Hello, I want to hear advices from gurus,, Our network use transit service from UU.NET in PaloAlto IX. ## the result of traceroute from our network to www.sun.com traceroute to Sun.COM (192.9.49.33), 30 hops max, 40 byte packets --<snip>-- 4 INET-PA-GW.nuri.net (203.235.119.253) 147 ms 145 ms 143 ms 5 911.Hssi5-0.GW1.PAO1.ALTER.NET (157.130.192.145) 170 ms 169 ms 173 ms <-----@@@@ 6 119.ATM3-0.XR1.SCL1.ALTER.NET (146.188.144.78) 486 ms 434 ms 441 ms <-----@@@@ 7 146.188.145.157 (146.188.145.157) 432 ms 440 ms 443 ms 8 core7-hssi5-0.SanFrancisco.mci.net (206.157.77.73) 408 ms 457 ms 425 ms --<snip>-- (INET-PA-GW.nuri.net is our ROUTER.) Between hop 5 and hop 6, it took about 300 ms. It seems the problem of UU.NET as simple analysis.. If the circuit has a problem, the all connections between PAIX and uu.net have problems also. Has anybody the same problem ? Thanks in advacne.. Sincerely,, PS) Was the location of the www.sun.com moved to east coast? I remember that www.sun.com was directly connected with UU.NET, but today the traceroute shows it is connected via MCI and the location is Boston. Is it right ? or the result from routing unstablilty ?

1 0

Re: RFC 974 - Mail Routing and the Domain System
by Andrew Staples 16 Sep '98

16 Sep '98

> BIND will round robin the MX records, how mail agents deal with >multiple MX records of the same priority is less of a known factor (to >me at least). Actually I'd be interested to hear from people who try >both configurations for say a month at a time to see what influence each >configuration has if any. RFC 974 reads: D.EXAMPLE.ORG IN MX 0 D.EXAMPLE.ORG D.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG D.EXAMPLE.ORG IN WKS 10.0.0.4 TCP SMTP In the third example, consider a mailer on A.EXAMPLE.ORG trying to deliver a message to D.EXAMPLE.ORG. In this case there are only two MX RRs, both with the same preference value. Either MX will accept messages for D.EXAMPLE.ORG. The mailer should try one MX first (which one is up to the mailer, though D.EXAMPLE.ORG seems most reasonable), and if that delivery fails should try the other MX (e.g. C.EXAMPLE.ORG)

1 0