October 1995 - Test - lists.nanog.org

Re: MCI and SprintLink are partitioned (fwd)
by Sean Doran 04 Oct '95

04 Oct '95

HWB - The problem is really not so much that the routing fell over but that other problems were run into, that are independent of NAPs/MAEs/etc. | . are all three (four?) NAPs really being used (I know they are | there, but despite repeated requests to at least one NAP service | provider I appear to be unable to get an answer). I do know that the | NY NAP is heavily used, including as my traffic to the Bay area | sites I need access to traverses it (modulo all the losses in | Sprintlink for at least weeks (reported to and confirmed by the | regional network that serves SDSC, though from rumors I am hearing | Sprintlink is rather not the exception, and many natives in the | community starting to get restless] SprintLink and MCI exchange traffic at two NAPs, both MAEs, and FIX-WEST. We likely will start exchanging traffic at the PAC*Bell NAP in the very near future. SprintLink and AGIS will be exchanging traffic there even before then. Others at that NAP are either in the queue wrt negotiating a bilateral agreement with Sprint, or have not yet approached Sprint with regards to a peering for various reasons. SprintLink and MCI exchange fairly heavy traffic at the Chicago NAP, very heavy traffic at the Pennsauken NAP, and extraordinarily heavy traffic at MAE-EAST, and we are have already been looking at a very strong and purely technical need to start moving traffic between ourselves directly in several other locations. The reason you see so much use of the Pennsauken NAP is that CERFNET has a DS3 ATM pipe terminated on a router there, and that is where CERFNET and SprintLink exchange a good chunk of traffic, principally because the bandwidth available to do that in New Yorsey has been greater than any other path on the west coast through which CERFNET and SprintLink could have exchanged traffic. I believe that Push could supply you with further details of CERFNET's near-future plans in this and other regards. | . Is there any evidence that the NAPs are really backing each other | up? Did someone test and document it, e.g., with a few "test" networks | in a bunch of regional networks? What are the time delays for a | switch? Does someone have consecutive traceroute outputs where a | switch among the NAPs really happened? What do you mean by backing each other up? There was never a requirement for NAPs to do that; what does fall-overs is the bilateral routing among each pair of peers at each touchdown point. BGP fallover with respect to very large changes (disconnectivity at a NAP, MAE or FIX-WEST) between two very big peers adjusts in various ways; firstly, you could have a fast IGP switching, which means convergence time within one side of a few seconds. Secondly, you could have an eBGP timeout or the like, which means convergence time in a matter of a couple of minutes or less. The key problem here is that convergence eats CPU (lots of routes to be announced or withdrawn or sent to different next-hops), and very very bad transitions can take ten to fifteen minutes, depending on the characteristics of the failures. However, fall-over happens fairly frequently and sometimes as a result of having to make code changes and the like at edge routers (routers colocated at NAPs/MAEs/FIXes etc), and we have long established that done right, it's not very painful. | . do we have some regular examples from *any* site A initiating a | connection from A to B, A to C, and A to D, where the three are | verifiably (via traceroute, I guess) would traverse different NAPs | (and hopefully only one each)? Sure; if I understand the question correctly, anybody on SprintLink or MCI should be able to do this without thinking about it. | . Are there routing stability reports accessible online from the RA | (or whoever else feels responsible for this) that graph fluctuations | at the NAPs, including correlation among them? What are the quality | metrics for routing stability? Not AFAIK. | . Do all the NAPs provide online statistics? The Sprint NAP has a statistics package which is really nifty but not yet widely publically available; you should tap Bilal or one of the other responsible people on the shoulder to show it off to you. | . Are the NAP and RA regular reports to NSF publicly (hopefully via | the Web) available? Not sure. It might be a good idea. | . Is there any way NANOG can be used to exchange status information | about networks, rather than getting comments and rumors second or | third hand. outage-request(a)sprint.net can put you on our (very widely-subscribed) list for announcing SprintLink/ICM outages, innages, root problems and potential solutions. I hope that you'll find that the quality of information there is reasonable and that volume is fairly light, and generally is what you seem to be asking for. | Even better | then posting (e.g, via some mailing list) would be an accessible | distributed data base covering all the service pproviders and | accessible via the network. Is someone already working on that? | Would not NANOG be *the* forum to cooperate on that? I'm certainly open to the idea. The first thing you'll have to realize is that when you can't get to the database because the network is broken, it can't help you... Sean.

1 0

Re: MCI and SprintLink are partitioned (fwd)
by Enke Chen 04 Oct '95

04 Oct '95

Hi, Currently MCI peers with Sprintlink at four places: Mae-East, Mae-West, New York NAP, and Chicago NAP, and these peers do backup each other. I just checked the peer status a few minutes ago. Here is what I found: interconnect up time Mae-East 6:06:45 (sheduled maintainence this morning) Mae-West 3d04 NY NAP 4d20 Chicago NAP 1w6d Clearly this data does not support the remark that a partition (total loss of peers) happened between MCI and Sprint yesterday evening. -- Enke >Anyone willing to say what happened? > >******************************************************************** >Gordon Cook, Editor & Publisher Subscript.: Individ-ascii $85 >The COOK Report on Internet Non Profit. $150 >431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 >(609) 882-2572 Corporate $350 >Internet: cook(a)cookreport.com Corporate. Site Lic $650 >http://www.netaxs.com/~cook <- Subscription Info & COOK Report Index >******************************************************************** >---------- Forwarded message ---------- >To: cook(a)cookreport.com >Subject: MCI and SprintLink are partitioned (fwd) > >Forwarded message: >>From spot.Colorado.EDU!westnet-site-people-request Tue Oct 3 20:48:25 1995 >From: Chris Garner <cgarner(a)westnet.net> >Message-Id: <199510040136.TAA06094(a)dozer.colorado.edu> >Subject: MCI and SprintLink are partitioned >To: westnet-site-people(a)westnet.net >Date: Tue, 3 Oct 1995 19:36:50 -0600 (MDT) >X-Mailer: ELM [version 2.4 PL21] >Content-Type: text >Content-Length: 289 > > > MCI and SprintLink are disconnected at the moment. MCI is >having a BGP problem with SprintLink. Currently the two networks >are partitioned. The problem started just after 7pm (Mountain time) >and is still occuring. > > > -Chris (cgarner(a)westnet.net)

2 2

Re: MCI and SprintLink are partitioned (fwd)
by Curtis Villamizar 04 Oct '95

04 Oct '95

Just a random sampling: I can reach a Sprint and an MCI customer. I can also traceroute -g through Sprint and reach an MCI customer (sorry no DNS on the router, 144.228 is Sprintland and 204.70 is MCIland). Curtis traceroute to connix.com (198.69.10.2), 30 hops max, 40 byte packets 1 en-0.enss470.t3.ans.net (204.148.1.30) 2.253 ms 2.132 ms 2.049 ms 2 t0-0.cnss52.Hartford.t3.ans.net (192.103.65.9) 27.768 ms 27.648 ms 27.434 ms 3 mf-0.cnss48.Hartford.t3.ans.net (140.222.48.222) 27.838 ms 27.521 ms 27.54 ms 4 t3-2.cnss32.New-York.t3.ans.net (140.222.32.3) 30.855 ms 30.531 ms 30.334 ms 5 t3-1.cnss56.Washington-DC.t3.ans.net (140.222.56.2) 36.671 ms 35.944 ms 36.505 ms 6 t3-0.enss147.t3.ans.net (140.222.147.1) 37.055 ms 36.686 ms 36.238 ms 7 sl-mae-e-F0/0.sprintlink.net (192.41.177.241) 40.192 ms 63.829 ms 213.618 ms 8 sl-dc-8-H1/0-T3.sprintlink.net (144.228.10.41) 169.323 ms 56.15 ms 216.765 ms 9 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 226.158 ms 42.494 ms 42.574 ms 10 sl-pen-1-H2/0-T3.sprintlink.net (144.228.10.34) 39.521 ms 53.347 ms 51.931 ms 11 sl-pen-7-F0/0.sprintlink.net (144.228.60.7) 46.35 ms 128.988 ms 206.026 ms 12 sl-caravela-4-s0-T1.sprintlink.net (144.228.67.110) 204.428 ms 55.455 ms 50.509 ms 13 hfd-01.rt.connix.net (204.183.68.65) 57.627 ms 57.497 ms 61.205 ms 14 mfd-hfd.pp.connix.net (204.183.69.130) 54.592 ms 52.971 ms 54.21 ms 15 connix.com (198.69.10.2) 59.009 ms 70.912 ms 68.981 ms traceroute to ns.isi.edu (128.9.128.127), 30 hops max, 40 byte packets 1 en-0.enss470.t3.ans.net (204.148.1.30) 2.273 ms 2.15 ms 2.078 ms 2 t0-0.cnss52.Hartford.t3.ans.net (192.103.65.9) 27.731 ms 27.803 ms 27.686 ms 3 mf-0.cnss48.Hartford.t3.ans.net (140.222.48.222) 28.485 ms 27.492 ms 27.525 ms 4 t3-2.cnss43.Cleveland.t3.ans.net (140.222.43.3) 42.654 ms 42.49 ms 42.396 ms 5 t3-1.cnss27.Chicago.t3.ans.net (140.222.27.3) 50.043 ms 49.993 ms 49.974 ms 6 t3-1.cnss96.Denver.t3.ans.net (140.222.96.2) 74.795 ms 74.753 ms 74.692 ms 7 t3-1.cnss8.San-Francisco.t3.ans.net (140.222.8.2) 97.726 ms 98.407 ms 98.726 ms 8 t3-0.enss144.t3.ans.net (140.222.144.1) 100.66 ms 101.765 ms 101.544 ms 9 fix-west-cpe.SanFrancisco.mci.net (192.203.230.18) 101.413 ms 101.038 ms 103.37 ms 10 borderx2-hssi2-0.SanFrancisco.mci.net (204.70.158.117) 254.546 ms 265.445 ms 214.901 ms 11 core2-fddi-1.SanFrancisco.mci.net (204.70.158.65) 153.304 ms 103.416 ms 104.602 ms 12 core-hssi-2.Bloomington.mci.net (204.70.1.41) 114.067 ms 117.875 ms 115.73 ms 13 border1-fddi-0.Bloomington.mci.net (204.70.2.130) 119.707 ms 113.654 ms 114.491 ms 14 csunet-losnettos.Bloomington.mci.net (204.70.48.6) 121.376 ms 119.585 ms 119.236 ms 15 ISI-SWRL-GW.LN.NET (204.102.78.1) 117.668 ms 118.692 ms 117.416 ms 16 ln-gw.isi.edu (128.9.16.1) 121.521 ms 118.617 ms 119.793 ms 17 cisco2-32.isi.edu (128.9.32.2) 117.898 ms 120.588 ms 120.731 ms 18 darkstar.isi.edu (128.9.128.127) 117.897 ms 120.146 ms 120.439 ms traceroute to 128.9.128.127 (128.9.128.127), 30 hops max, 12 byte packets 1 cnss32-ft2.if (140.222.32.3) 6 ms 6 ms 5 ms 2 enss218-ft0.if (140.222.218.1) 11 ms 11 ms 10 ms 3 192.157.69.9 (192.157.69.9) 12 ms 14 ms 12 ms 4 144.228.60.1 (144.228.60.1) 18 ms 125 ms 119 ms 5 144.228.10.33 (144.228.10.33) 121 ms 112 ms 100 ms 6 144.228.20.8 (144.228.20.8) 77 ms 187 ms 19 ms 7 144.228.10.42 (144.228.10.42) 204 ms 170 ms 217 ms 8 192.41.177.181 (192.41.177.181) 222 ms 143 ms 97 ms 9 204.70.74.101 (204.70.74.101) 81 ms 52 ms 102 ms 10 204.70.74.49 (204.70.74.49) 97 ms 99 ms * 11 204.70.1.129 (204.70.1.129) 284 ms 379 ms 221 ms 12 204.70.1.125 (204.70.1.125) 254 ms * 56 ms 13 204.70.1.114 (204.70.1.114) 250 ms 219 ms 258 ms 14 204.70.1.122 (204.70.1.122) 246 ms 154 ms 235 ms 15 204.70.1.34 (204.70.1.34) 265 ms 555 ms 442 ms 16 204.70.2.130 (204.70.2.130) 137 ms 287 ms 280 ms 17 204.70.48.6 (204.70.48.6) 1179 ms 135 ms 239 ms 18 * 204.102.78.1 (204.102.78.1) 312 ms 178 ms 19 128.9.16.1 (128.9.16.1) 217 ms 170 ms 234 ms 20 128.9.32.2 (128.9.32.2) 216 ms 157 ms 321 ms 21 128.9.128.127 (128.9.128.127) 198 ms 365 ms 234 ms

1 0

Re: MCI and SprintLink are partitioned (fwd)
by craig＠mci.net 04 Oct '95

04 Oct '95

Gordon, You may be interested in checking out this paper by Network Computing relating to your question. http://techweb.cmp.com/techweb/nc/online/netlimit.html -craig At 12:33 AM 10/04/95, Gordon Cook wrote: >Anyone willing to say what happened? > >******************************************************************** >Gordon Cook, Editor & Publisher Subscript.: Individ-ascii $85 >The COOK Report on Internet Non Profit. $150 >431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 >(609) 882-2572 Corporate $350 >Internet: cook(a)cookreport.com Corporate. Site Lic $650 >http://www.netaxs.com/~cook <- Subscription Info & COOK Report Index >******************************************************************** > > >---------- Forwarded message ---------- >To: cook(a)cookreport.com >Subject: MCI and SprintLink are partitioned (fwd) > >Forwarded message: >>From spot.Colorado.EDU!westnet-site-people-request Tue Oct 3 20:48:25 1995 >From: Chris Garner <cgarner(a)westnet.net> >Message-Id: <199510040136.TAA06094(a)dozer.colorado.edu> >Subject: MCI and SprintLink are partitioned >To: westnet-site-people(a)westnet.net >Date: Tue, 3 Oct 1995 19:36:50 -0600 (MDT) >X-Mailer: ELM [version 2.4 PL21] >Content-Type: text >Content-Length: 289 > > > MCI and SprintLink are disconnected at the moment. MCI is >having a BGP problem with SprintLink. Currently the two networks >are partitioned. The problem started just after 7pm (Mountain time) >and is still occuring. > > >-- > > -Chris (cgarner(a)westnet.net)

1 0

Re: number of unaggregated class C's in swamp?
by William Allen Simpson 02 Oct '95

02 Oct '95

> From: Michael Dillon <michael(a)junction.net> > On Fri, 29 Sep 1995, Mark Kent wrote: > > Announce now that by Oct 1, 1996 no individual /24 will be routed. > > This is a reasonable timetable. > > > Filter 204/24 and 205/24 on Oct 31, 1995 > > Filter 202/24 and 203/24 on Nov 30, 1995 > > This is not! > > The great bulk of the world, especially management types, gets their > technical news with a 4 to 6 month time delay from glossy technical > magazines. This delay is due to the time required for writers to I want to thank Mark Kent, and disagree with Michael Dillon. Last April, folks at IETF stood in the front of the room and said they were going to start reducing the prefixes. I heard within a _month_! Now, it has been 6 months. We've already had plenty of time for the news magazines to print and management types to absorb the news. Some competent providers have already informed their customers that they need to renumber, have already started planning, and are actually renumbering! Others are not so competent. Time to announce to them that we're sorry, but unless they pay out lots of money to upgrade their competitors and fund the research, their competitors aren't going to accept their /24 routes anymore. We are all in this together. Now, the pier wg is trying to help put together a list of OS's and pin-pointing "how to" work through renumbering. That should help. But there's no time like the present to get on with doing it! The only difference I'd make is to _START_ with 192, not end there. We get a lot more bang for the buck there, as renumbering will help aggregate both continentally and regionally, and also free up badly managed space for the future. That nice table from Dennis was an eye-opener (just what I was looking for, thanks)! Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

5 6

Re: Comments on Routing and Allocation Policy Wanted
by Sanjay Dani 02 Oct '95

02 Oct '95

>From: patrick(a)Verity.COM (Patrick Horgan) >> From: "Walter O. Haas" <haas(a)xmission.com> >> >> Somehow I'm under the impression that it's possible to have SMTP over a >> PPP dialup by logging into the mail server, is that not correct? > >Not exactly. smtp is just a tcp protocol. You only need to do a tcp [snip] >One easy way to do mail is to nfs mount the directory containing [snip] >The next choice is POP (Post Office Protocol). With pop, your machine [snip] Alternatively, if you want to SMTP over email for a domain over the dialup connection, assign the PPP client a primary MX record and a fully connected server on the PPP server's network a secondary. The PPP reconnect script on the client can be instrumented to flush the outgoing queue and also send email to pseudo alias on the secondary MX server that triggers a flush of its incoming queue for your domain. You have to make sure you dialup at least once every three days or so. This strategy requires the PPP client have a static IP. Sanjay.

2 1

Re: Comments on Routing and Allocation Policy Wanted
by patrick＠Verity.COM 02 Oct '95

02 Oct '95

> From: Sanjay Dani <sanjay(a)professionals.com> > > > Alternatively, if you want to SMTP over email for a domain over the > dialup connection, assign the PPP client a primary MX record and a > fully connected server on the PPP server's network a secondary. The > PPP reconnect script on the client can be instrumented to flush the > outgoing queue and also send email to pseudo alias on the secondary > MX server that triggers a flush of its incoming queue for your domain. > You have to make sure you dialup at least once every three days or so. > > This strategy requires the PPP client have a static IP. > > Sanjay. > Sanjay is quite right:) I missed this because of my own assumptions. I'd like to be able to read mail from home via pop and from work via an NFS mounted spool directory. Sanjays solution is one that works quite well if you want to only read your mail remotely, i.e. you might be in a situation where you have no direct access to read mail on the normal mailhost. Another possibility that neither of us has mentioned is to have the mailhost use uucp delivery for your mail domain. Then it queues in the uucp spool until your machine calls (or until the mailhost calls you if you have it set up that way.) Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

Re: Comments on Routing and Allocation Policy Wanted
by patrick＠Verity.COM 02 Oct '95

02 Oct '95

> From: "Walter O. Haas" <haas(a)xmission.com> > > Somehow I'm under the impression that it's possible to have SMTP over a > PPP dialup by logging into the mail server, is that not correct? Not exactly. smtp is just a tcp protocol. You only need to do a tcp connection to do smtp. That means that no login to the mail server is needed to do smtp. You might have meant something different though. Let me give a brief overview of issues involved in doing mail via a ppp connection. The first assumption is that your remote ppp-connected host doesn't have a full time ppp-connection. If it did you could just make it an smtp host. One easy way to do mail is to nfs mount the directory containing your email on your ppp connected host and do mail just as you always would. This isn't always possible since nfs mounting might not work from your host, (you might not have the appropriate software,) or policy might not allow it. The next choice is POP (Post Office Protocol). With pop, your machine contacts the pop server on the mailhost and is able to access the mail in your spool file. After reading a mail you're able to leave it in the spool file, or delete it. (Note that pop passes your password in the clear:( ) Your MUA (mail user agent, i.e. what you used to read and send mail), talks SMTP via TCP over PPP directly to the mailhost. If this is unclear, please send me mail, I could give you a lot more information. > Assigning > an IP address on the fly gives better utilization of the space if you can > get the functionality you need. Using pop over ppp gets the functionality you need as long as you don't need a "full time connection." All the reasons you would need a full time connection would have implications that you need static IP. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

geeting NANOG listed in Encyclopedia of Associations
by Nigel Allen 02 Oct '95

02 Oct '95

Groups like NANOG may find it useful to be listed in the _Encyclopedia of Associations_, a directory of national non-profit groups in the United States, so that journalists, researchers and potential new members can get in touch with you more easily. I have transcribed the questionnaire that the _Encyclopedia of Associations_ uses to compile its listings, and I would be happy to send a copy to anyone who would like their group listed. The Encyclopedia of Associations is published by Gale Research Inc. of Detroit, a well-known publisher of reference books. Your local library probably has a copy of the _Encyclopedia of Associations_ that you can look through to see how other progressive groups are listed. To request a questionnaire, send me e-mail (ndallen(a)io.org) or contact: Encyclopedia of Associations Gale Research Inc. 835 Penobscot Building Detroit, MI 48226-4094 U.S.A. telephone (313) 961-2242 or 800-877-GALE fax (313) 961-6815 -- Nigel Allen, Toronto, Ontario, Canada ndallen(a)io.org Web page: http://www.io.org/~ndallen

2 1

Re: Peering in the LA region?!?
by Marcos Della 02 Oct '95

02 Oct '95

Well, it sounds like several people are interested in peering somewhere in the LA region. We were just out to the one wilshire building last Monday to look at the layout and the interconnects within the building. There are several people located on various floors there. For those that are in the building, you all probably know about the "cost" of doing business between floors. We just purchased a 4" pipe from P1 to the 18th floor (our location) with drops on each floor (hense the right of way). We also have a thousand spare feet of space that leased to us for the next generation or so :-) With this in mind, this week, we are starting the buildout of both co-location space as well as interconnect racks. We are planning on putting a 7500 in this location as well as a CDDI ring. We can just as easily put up an ethernet hub and interconnect this down to Peter's spot on the 14th floor. Bill, if you want to locate a RADB processor, you are welcome to install one in our location if need be. We will also allow low speed frame or T1 groups to connect in to the PCH router that we will probably be setting up there as well (packet clearing house) for a "star" peering arrangment. This router will back end into our connections also. As for anyone else, let me know since we are flying down to LA Wednesday to begin the rollout. Also, we will have MFS fiber and PacBell fiber on our floor as well if needed. We are talking to TCG for fiber as well for anyone who wants to connect via any of these methods. Marcos -- ''' (o o) --------------------------oOO--(_)--OOo-------------------------- Marcos R. Della Email: mdella(a)InterNex.Net Director, Network Engineering InterNex Information Services Phone: 408/496-5466 http://www.internex.net/~mdella

1 0