May 1998 - Test - lists.nanog.org

different thinking on exchanging traffic
by Jonathan Arneault 27 May '98

27 May '98

A few days ago I posted a proposal for traffic exchange across an ATM backbone specifically designed for that purpose. I am suggesting an NxOC-48 network with peers purchasing DS3 connections at their various geographic locations, and establishing ATM PVCs with specified CBR's to their respective peers. Each DS3 connection would allow up to 5 PVCs, with over-subscription at a 2 to 1 maximum. In this scenario, a flat pricing for a port would be about 5K/month, and CBR's would be set at a maximum of 10K/mo for full DS3 bandwidth. Since the beginning of this thread, I have been in contact with several venture capital firms to feel out the support from the financial world about making this do-able. I have estimated the costs involved with the fiber and switch purchases at about US 691MM for sunk capital costs, and approximately 250K/mo for operating expenses. With strong indications of its fiscal viability, I am now asking you, the potential consumers of such a service, your distinct opinions, and whether or not you would purchase such a service if made available. Specifically, if I build it, will you come. Your response will determine whether or not I will proceed in my discussions with the VCs, and will probably be incorporated into a supporting document in the application for funding. It is understood that no statement you make in regard to this letter will be legally binding, and will in no wise obligate you to purchase this service if and when it becomes available. I'm really asking you all to do me a favor by letting me know if you'd like to see this or not. If so, great. If not, I'd rather spend my energy on something that'll be successful. Please respond to me directly, and include your name, title, your company's name, and a day-time telephone number. Thanks much, Jonathan Arneault jarneault(a)inet-solutions.net

5 4

Suggestion for improved identD
by Ehud Gavron 26 May '98

26 May '98

Suggestion: PPP access devices intercept identD requests and return the authenticated access string. Reasoning: Modern ``stacks'' used by end-users -- especially those on throwaway accounts, fake any identD response. This makes tracking those people tougher. Methods: 1: identD v2, new port, intercepted by access devices which support it. 2: modification to hosts requirement RFCs, making access devices responsible for intercepting identD requests to their PPP clients. 3: a security RFC ``suggesting'' 1 or 2 Thoughts appreciated, as are comments, flames, blames, and anything of some content. Ehud gavron(a)aces.com p.s. new beta traceroute at ftp.aces.com cd pub/software/traceroute/beta

19 30

Draft NANOG Agenda
by Susan Rebecca Harris 26 May '98

26 May '98

Greetings - here's a draft agenda for the June 1998 NANOG. On Monday evening, we'll also feature demos of freely available routing tools and other BOFs - stay tuned for more information. For meeting details, see http://www.nanog.org/mtg-9806/update.html . Looking forward to seeing you! ---------------------------------- SUNDAY, June 7: Evening Tutorials 7:15 p.m. Introduction to Multicast (Dave Meyer, Cisco Systems) 8:45 p.m. Interesting Things You Can Do With OSPF (Howard Berkowitz) MONDAY, June 8 9:00 a.m. Welcome, Introductions, Future Meetings (Bill Norton, Merit) 9:30 a.m. Recommendations on Queue Management and Congestion Avoidance in the Internet (Van Jacobson, Lawrence Berkeley National Laboratory) 10:00 a.m. QoS and Ebone: Issues and Potential Solutions (Sean Doran, Ebone) 10:30 a.m. BREAK 10:45 a.m. Differentiated Services Panel: Working Group Update and Viewpoints From the Community (Kathleen Nichols, Bay Networks, moderator) Priority Service for Internet Traffic (Van Jacobson, Lawrence Berkeley National Laboratory) Differentiated Services Support in Cisco Routers (Fred Baker. Cisco) TBA (Peter Ford, Microsoft) 12:15 p.m. - 1:45 p.m. LUNCH 1:45 p.m. Introduction to the NETPERF.NET Inter-Provider Network Performance Monitoring Project (Avi Freedman, Net Access) 2:00 p.m. Path and Round-Trip Time Measurements: a New Project at CAIDA (Daniel McRobb, CAIDA (Cooperative Association for Internet Data Analysis)) 2:30 p.m. Building Large-Scale Internet Measurement Infrastructure (Vern Paxson, Lawrence Berkeley National Laboratory) 3:00 p.m. Update from the IPMA Project (Craig Labovitz, Merit) 3:30 p.m. BREAK 3:45 p.m. Roadmap to a Distributed Registry: Transition to RPSL (Routing Policy Specification Language) (Cengiz Alaettinoglu, ISI, Curtis Villamizar, ANS) TUESDAY, June 9 9:00 a.m. Overview of FBI Computer Investigations (Scott Larson, FBI) 9:45 a.m. Network-based Denial of Service Attacks: Descriptions and How to Protect Your Network (Craig Heugen, Cisco) 10:15 a.m. What Is a VPN? (Paul Ferguson, Cisco) 10:45 a.m. BREAK 11:00 a.m. Dial-in VPN Using Layer 3 Tunneling (Gary Malkin, Bay Networks) 11:30 a.m. Broadband VPNs - Outsourcing ISP services to Cable TV and XDSL Providers (Bruce Perlmutter, Bay Networks) 12:00 p.m. LUNCH 1:30 p.m. Implementing Simplex IP Bandwidth Augmentation and IP-based News and HTTP Broadcast Services via Geosynchronous Satellite (Avi Freedman, Net Access) 2:00 p.m. Scaling and Other New BGP Features (Mark Turner, Cisco) 2:30 p.m. ARIN Update (Kim Hubbard, ARIN) 2:45 p.m. BREAK 3:00 p.m. InterNIC Update (Mark Kosters, InterNIC) 3:30 p.m. Update on UCAID, Internet2, and the Abiline Project (Guy Almes, UCAID) 4:00 p.m. Closing Remarks (Bill Norton, Merit)

1 0

Re: The questions stand
by John Fraizer - Administrator 26 May '98

26 May '98

At 04:12 PM 5/21/98 -0400, you wrote: >Seems to depend on where you sit. John is only a few hops away (on the >same 'Tier 1' provider?) as Karl, so traffic is dependant on only three >parties maintaining a clean network. Across another backbone (via public >view sage.aspire.net) it's not so clean, probably due to packet loss No webserver active on common ports at sage.aspire.net, so I traced from here to there: [OverKill]:~$ traceroute sage.aspire.net traceroute: Warning: Multiple interfaces found; using 209.41.244.2 @ eth0 traceroute to sage.aspire.net (207.233.170.6), 30 hops max, 40 byte packets 1 eth1-core0.Columbus.EnterZone.Net (209.41.244.1) 0.464 ms 0.402 ms 0.378 ms 2 core1-eth0-ENTERZONE.Columbus.fnsi.net (209.115.127.21) 4.123 ms 2.925 ms 1.905 ms 3 border1-atm6.Vienna.fnsi.net (206.183.239.90) 31.108 ms 28.097 ms 34.240 ms 4 br1.tco1.alter.net (192.41.177.248) 44.899 ms 30.415 ms 31.101 ms 5 335.ATM2-0-0.CR2.TCO1.Alter.Net (137.39.74.73) 44.533 ms 46.970 ms 46.335 ms 6 412.atm11-0-0.gw2.tco1.alter.net (137.39.22.13) 35.126 ms 50.597 ms 29.909 ms 7 diginetusa-gw.customer.ALTER.NET (157.130.34.26) 52.351 ms 51.069 ms 29.571 ms 8 rt1b-ser0-VA001.diginetusa.net (207.233.201.22) 59.098 ms 60.608 ms 57.744 ms 9 sage.aspire.net (207.233.170.6) 42.377 ms 48.387 ms 46.359 ms --- sage.aspire.net ping statistics --- 64 packets transmitted, 64 packets received, 0% packet loss round-trip min/avg/max = 44.1/50.0/67.9 ms Looks clean to me. >across the Tier 1 provider that they use (UUNet) or loss at an exchange >point between UUNet and Napnet to get to Karl's network. Oh, Gawd! I have never, in my most bizzare nightmares contemplated obtaining bandwidth from UUNet. They don't even have a POP in Columbus according to the Worldcomm/UUNet sales puke who approached me at our co-lo facility last week. We obtain our bandwidth from Fiber Network Solutions, Inc. (FNSI.NET) Karl from what I see is getting bandwidth or transit at least from GOOD.NET: [OverKill]:~$ traceroute www.mcs.net traceroute: Warning: Multiple interfaces found; using 209.41.244.2 @ eth0 traceroute to www.mcs.net (205.164.8.12), 30 hops max, 40 byte packets 1 eth1-core0.Columbus.EnterZone.Net (209.41.244.1) 0.478 ms 0.400 ms 0.381 ms 2 core1-eth0-ENTERZONE.Columbus.fnsi.net (209.115.127.21) 1.522 ms 1.454 ms 1.367 ms 3 aads.good.net (198.32.130.49) 13.534 ms 13.805 ms 13.705 ms 4 mcsnet.chicago.good.net (207.98.189.130) 14.305 ms 16.059 ms 14.862 ms 5 www.mcs.net (205.164.8.12) 14.279 ms 13.941 ms 14.021 ms Pings: --- www.mcs.net ping statistics --- 52 packets transmitted, 52 packets received, 0% packet loss round-trip min/avg/max = 13.6/15.2/23.4 ms >From an OAR.NET connected machine, it looks like it transits through NAP.NET: [tvo@noldor tvo]$ traceroute www.mcs.net ...blah blah blah... 7 oeb3-atm6-0.columbus.oar.net (199.18.202.13) 37.002 ms 38.028 ms 37.028 ms 8 tlp3-atm1-0.toledo.oar.net (199.18.202.53) 45.021 ms aads.nap.net (198.32.130.39) 49.466 ms 50.494 ms 9 chi-h0.mcs.net (206.54.225.150) 50.948 ms 57.74 ms 51.727 ms 10 www.mcs.net (205.164.8.12) 50.387 ms 50.473 ms 50.216 ms [tvo@noldor tvo]$ Pings: --- www.mcs.net ping statistics --- 67 packets transmitted, 67 packets received, 0% packet loss round-trip min/avg/max = 58.5/62.2/81.6 ms (Note: The above connection is via ISDN so, I'll be nice and attribute the latency to that VS OAR.NET's architecture.) >Despite our best intentions, packet loss and delay will always exists from >our networks to certain destinations, no matter whether we use 'Tier 1' >providers or companies that are creating private NAPs of their own. And >how it looks from me to you doesn't mean much, in the long run - how it >looks across the board from you to your customer's destinations is what >makes a difference. If that's accomplished with a small backbone >provider, a big player like MCI, or some local 'private nap' company >shouldn't make any difference to anyone but yourself. In all honesty, the only time I have experienced packet loss to any destination, it has been isolated and attributed to (heat/cold/incompetence/emergency, unscheduled maintenance - PICK ONE, seems like the MAE operators do) at one of the MAEs or some idiot with too much backhoe and too little clue. If you are accepting packet loss as "normal and unavoidable", your provider is making excuses vs isolating and eliminating problems in their network or in their interconnect at the MAEs. If, on the other hand, you expect to get what you pay for and deliver it to your customers without having to make excuses for problems in your upstreams network, perhaps I can interest you in a circuit or co-location. If you're one of the folks who is caught up on the Tier issue, I can sell you a circuit from FNSI.NET as well. As for how we look from the "outside": MAE-East Looking Glass Results 1 mae-east.fnsi.net (192.41.177.11) 0 msec 0 msec 4 msec 2 core1-hssi7.Columbus.fnsi.net (206.183.239.89) [AS 6259] 28 msec 28 msec 32 msec 3 ENTERZONE.Columbus.fnsi.net (209.115.127.22) [AS 6259] 28 msec 76 msec 36 msec 4 www.enterzone.net (209.41.244.11) [AS 6259] 28 msec 36 msec 32 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 28/36/48 ms Sprintnap Looking Glass Results 1 phl2-core2-f4-0.atlas.digex.net (165.117.51.37) 0 msec 0 msec 0 msec 2 dca1-cpe2-h10-0-0.atlas.digex.net (165.117.52.121) 8 msec 4 msec 4 msec 3 dca1-cpe1-fa4-0-0.atlas.digex.net (165.117.224.10) 8 msec 8 msec 4 msec 4 iad1-core1-p5-0.atlas.digex.net (165.117.52.230) 8 msec 4 msec 4 msec 5 mae-east.fnsi.net (192.41.177.11) 16 msec 12 msec 4 msec 6 core1-hssi7.Columbus.fnsi.net (206.183.239.89) [AS 6259] 36 msec 40 msec 44 msec 7 ENTERZONE.Columbus.fnsi.net (209.115.127.22) [AS 6259] 36 msec 32 msec 44 msec 8 www.enterzone.net (209.41.244.11) [AS 6259] 48 msec 44 msec 48 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms MAE-West Looking Glass Results 1 mae-west.fnsi.net (198.32.136.111) 0 msec 4 msec 0 msec 2 core1-hssi8.Columbus.fnsi.net (206.183.239.93) [AS 6259] 66 msec 68 msec 66 msec 3 ENTERZONE.Columbus.fnsi.net (209.115.127.22) [AS 6259] 64 msec 60 msec 60 msec 4 www.enterzone.net (209.41.244.11) [AS 6259] 60 msec 60 msec 64 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/60 ms PAIX Looking Glass Results 1 sjc3-core2-fa0-0-0.atlas.digex.net (165.117.53.194) 4 msec 0 msec 0 msec 2 sjc1-core2-h5-0.atlas.digex.net (165.117.50.121) 4 msec 4 msec 0 msec 3 sjc1-core1-fa3-0-0.atlas.digex.net (165.117.50.145) 4 msec 4 msec 4 msec 4 pacbell.fnsi.net (198.32.128.5) 4 msec 8 msec 4 msec 5 core1-hssi8.Columbus.fnsi.net (206.183.239.93) [AS 6259] 72 msec 78 msec 70 msec 6 ENTERZONE.Columbus.fnsi.net (209.115.127.22) [AS 6259] 72 msec 70 msec 74 msec 7 www.enterzone.net (209.41.244.11) [AS 6259] 70 msec 70 msec 70 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/80/84 ms ROUTE-SERVER.CERF.NET Looking Glass Results 1 h1-0.san-hq3.cerf.net (192.215.254.1) [AS 1740] 4 msec 4 msec 4 msec 2 h1-0.san-hq3.cerf.net (192.215.254.1) [AS 1740] 0 msec 0 msec 0 msec 3 h2-0-0.san-bb3.cerf.net (134.24.29.61) [AS 1740] 0 msec 4 msec 4 msec 4 atm1-0-155M.san-bb1.cerf.net (134.24.32.6) [AS 1740] 4 msec atm6-0-1-155M.sjc-bb2.cerf.net (134.24.29.94) [AS 1740] 16 msec 16 msec 5 mae-west.nap.net (198.32.136.13) 20 msec 20 msec 20 msec 6 core0-a0-7.chi1.nap.net (207.112.247.146) [AS 5646] 100 msec 92 msec 92 msec 7 core0-fe8-1.chi1.nap.net (207.112.247.153) [AS 5646] 108 msec 96 msec 108 msec 8 aads.fnsi.net (198.32.130.64) [AS 6196] 208 msec 116 msec 104 msec 9 ENTERZONE.Columbus.fnsi.net (209.115.127.22) [AS 6259] 100 msec 116 msec 116 msec 10 www.enterzone.net (209.41.244.11) [AS 6259] 104 msec 104 msec 120 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 100/105/120 ms And from (http://zeus.lyceum.com/cgi-bin/nph-bgp-routes) 1 Serial0.BR1.ATL2.lyceum.net (206.71.7.18) 8 msec 4 msec 4 msec 2 ge001.rt1.ATL.netrail.net (207.153.92.1) [AS 4006] 8 msec 8 msec 8 msec 3 gs012.rt1.DCA.netrail.net (205.215.63.13) [AS 4006] 44 msec 40 msec 44 msec 4 gf020.rt2.DCA.netrail.net (205.215.4.2) [AS 4006] 44 msec 40 msec 40 msec 5 mae-east.fnsi.net (192.41.177.11) [AS 701] 44 msec 52 msec 48 msec 6 core1-hssi7.Columbus.fnsi.net (206.183.239.89) [AS 6259] 84 msec 80 msec 80 msec 7 ENTERZONE.Columbus.fnsi.net (209.115.127.22) [AS 6259] 72 msec 72 msec 76 msec 8 www.enterzone.net (209.41.244.11) [AS 6259] 72 msec 76 msec 72 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 72/74/76 ms And just for grins and giggles, lets look from a few more countries: CSL GmbH 1 csl.D.net.DTAG.DE (194.245.101.62) 4 msec 4 msec 4 msec 2 D-ag1.D.net.DTAG.DE (194.25.7.77) 4 msec 4 msec 4 msec 3 D-gw1.D.net.DTAG.DE (194.25.122.118) [AS 3320] 8 msec 8 msec 8 msec 4 K-gw1.K.net.DTAG.DE (194.25.120.150) [AS 3320] 8 msec 8 msec 8 msec 5 F-gw3.F.net.DTAG.DE (194.25.120.229) [AS 3320] 12 msec 12 msec 12 msec 6 TysonsC-gw1.USA.net.DTAG.DE (194.25.6.186) [AS 3320] 120 msec 108 msec 112 msec 7 Penns-gw1.USA.net.DTAG.DE (194.25.6.193) [AS 3320] 108 msec 116 msec 108 msec 8 sl-bb1-pen-2-0.sprintlink.net (207.143.32.174) [AS 4999] 116 msec 116 msec 116 msec 9 sl-bb11-pen-0-1.sprintlink.net (144.232.5.9) [AS 1239] 116 msec 116 msec 116 msec 10 sl-bb7-pen-4-0-0.sprintlink.net (144.232.5.58) [AS 1239] 116 msec 116 msec 116 msec 11 sl-bb5-chi-1-0-0.sprintlink.net (144.228.10.38) [AS 1239] 136 msec 136 msec 136 msec 12 sl-bb11-chi-0-2.sprintlink.net (144.232.0.173) [AS 1239] 132 msec 132 msec 132 msec 13 sl-gw14-chi-8-0-0.sprintlink.net (144.232.0.194) [AS 1239] 140 msec 136 msec 136 msec 14 sl-napnet-2--T3.sprintlink.net (144.228.159.18) [AS 1239] 176 msec 176 msec 180 msec 15 aads.fnsi.net (198.32.130.64) [AS 6196] 388 msec 300 msec 336 msec 16 ENTERZONE.Columbus.fnsi.net (209.115.127.22) [AS 6259] 288 msec 184 msec 192 msec 17 www.enterzone.net (209.41.244.11) [AS 6259] 188 msec 188 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 184/190/196 ms AMS-IX Looking Glass Results 1 Amsterdam1.cistron.net (195.64.68.4) 4 msec 4 msec 4 msec 2 jedi-s0-5.amsterdam.wirehub.net (195.86.26.2) 4 msec 4 msec 8 msec 3 ajani-s0.1.washington.wirehub.net (194.165.94.149) 108 msec 92 msec 92 msec 4 mae-east.fnsi.net (192.41.177.11) 108 msec 100 msec 100 msec 5 core1-hssi7.Columbus.fnsi.net (206.183.239.89) 136 msec 124 msec 136 msec 6 ENTERZONE.Columbus.fnsi.net (209.115.127.22) 124 msec 120 msec 124 msec 7 www.enterzone.net (209.41.244.11) 160 msec 124 msec 156 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 124/140/152 ms DTI Japan: DTI NSPIXP-2 Router (http://neptune.dti.ad.jp/routechk-ixp2.html) Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 220/224/228 ms IMNET Japan: IMNET/NSPIXP2 Looking Glass (http://www.inoc.imnet.ad.jp/lg/ix-lg.html) Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 180/194/204 ms LINX London: LINX Looking Glass (http://www.linx.net/cgi-bin/lg.pl) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 120/120/124 ms I guess again, for some reason, things are fast and clean from my network. They always have been since our move to Fiber Network Solutions, Inc (FNSI.NET) for our bandwidth. Then again, I guess not all Tier 1's are alike. ------- John Fraizer (tvo) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:tvo@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

2 1

Wrong /24 Announcement at UU.net / BGP IOS Bug ?
by Winfried Haug 26 May '98

26 May '98

Hello.. one of our customers (germany.net, AS6751) is announcing us 151.189.0.0/16. We announce this to our both upstreams ECRC (AS1273) and Ebone (1755). Since a few days a lot of german ISPs ask us, why 151.189.0.0/24 is routed via UU.net to the USA and then goes back to germany. We checked our cisco-routers an finaly i found a Customer of UU.net with a looking glass: (http://zeus.lyceum.com/cgi-bin/nph-bgp-routes) > QUERY: bgp 151.189.0.0 > FROM: BR1.ATL1.lyceum.net. > > BGP routing table entry for 151.189.0.0/24, version 9891827 > Paths: (1 available, best #1, advertised over IBGP) > 701 1800 1755 1755 1755 5549 5549 6751 > 157.130.64.121 from 157.130.64.121 (137.39.2.42) > Origin IGP, valid, external, best ok lets see bacK: Sprint (1800) doesnt have this /24 but the /16 as it should be: icm-bb4-pen#show ip bgp 151.189.0.0 255.255.255.0 % Network not in table icm-bb4-pen# the same applies to EBONE (AS1755): frankfurt-ebs1>show ip bgp 151.189.0.0 255.255.255.0 % Network not in table frankfurt-ebs1> an we (AS5549) also dont see any /24 out of 151.189.0.0/16 So the question is: why does UU.net announce 151.189.0.0/24 and from where do they get it. The worse thing is, that all uu.net customers get this )(&%&$()& /24 from the hub in Frankfurt. The Space 151.189.1.0 - 151.189.255.255 is visiable at uu.net via 151.189.0.0/16.. So what happens here, could this be an ios bug ? We didnt touch our configuration towards ebone and they dont play with their configuration every day :-) Any ideas ? hints ? Winfried PS: for the german isps, we fixed it by announcing only at de-cix the 151.189.0.0/24 additionally to 151.189.0.0/16 and it works, but i am still looking for an answer to my questions :-) ? -- Winfried Haug | seicom.NET & SCHWABEN.DE | Tel. +49 7121 9770- 0 Laiblinsplatz 12 | Internet+ISDN access & consulting | Fax. +49 7121 9770-19 72793 Pfullingen | Access in STGT + RT + TUE + BB + LB | Rack +49 7127 989-X haug(a)schwaben.net| 150*ISDN (64kb/X.75) / 100 * K56flex | Rack +49 711 9675-X haug(a)seicom.NET |SAP-OSS * FTP * TELNET * NETNEWS * IRC | Rack +49 7121 709-X * 10 MBit DE-CIX * 2 MBit INXS * 5 MBit ecrc/ebone * 2 Mbit Belwue * 2 Mbit WIN

3 5

RE: why isn't nanog moderated?
by Rob Wilson 26 May '98

26 May '98

As in "style" should be followed with a period? or is that grammar? -----Original Message----- From: Patrick W. Gilmore [SMTP:patrick@priori.net] Sent: Friday, May 22, 1998 1:21 PM To: Nanog Subject: Re: why isn't nanog moderated? At 09:11 AM 5/22/98 +0100, Paul Mansfield wrote: > >all postings should be as succinct as possible, in fact almost trunca so people like you can post silly comments about other people's writing styles

1 0

? what a route
by Stephen Schmidt 26 May '98

26 May '98

This doesn't strike me as a "good thing": when looking to see what happend to fnsi.net, I found: bordercore1.chi>sho ip bgp 206.183.224.0 BGP routing table entry for 206.0.0.0/8, version 514950 Paths: (2 available, best #2, advertised over IBGP, EBGP) 4358 5646 7336, (received & used) 199.245.230.197 from 199.245.230.197 (207.98.189.86) Origin incomplete, localpref 100, weight 105, valid, external 4358 5646 7336, (received & used) 198.69.212.90 from 198.69.212.90 (207.227.0.138) Origin incomplete, localpref 100, weight 110, valid, external, best 206/8? Compass Communications (ASN-COMPASS) 2001 Sixth Avenue, Suite 3205 Seattle, WA 98121 US Autonomous System Name: COMPASS Autonomous System Number: 7336 Coordinator: RIOS, TONY (TR143-ARIN) tonester(a)CCOM.NET (206) 777-9999 (FAX) (206) 777-3077 Record last updated on 11-Nov-96. Database last updated on 21-May-98 16:09:46 EDT. Steve -- _/_/ _/ _/_/_/_/ _/ _/ _/ _/ Stephen E. Schmidt _/_/_/_/ _/ _/_/_/_/ Vice President, Access _/ _/ _/ _/ American Information Systems, Inc. _/ _/ _/ _/_/_/_/ E-mail: steve(a)ais.net, http://www.ais.net For my PGP public key, email me with the subject "pgp request" ALL RIGHTS RESERVED

1 0

Re[2]: Wired Q: Embedded NT
by dnewman＠data.com 26 May '98

26 May '98

It was in Data Communications magazine ;-) The switch maker is Berkeley Systems. They licensed NT source and stripped it down (I think the IP stack is one of the things they whacked ;-) to run the switch. With the obvious exception of M$ RRAS, this is AFAIK is the only vendor using NT as a switch or router OS. David Newman Data Communications magazine ______________________________ Reply Separator _________________________________ Subject: Re: Wired Q: Embedded NT Author: "Lehrer Neil" <nlehrer(a)usia.gov> at dcm_smtp Date: 5/14/98 11:04 AM i saw something about a switch maker embedding nt. about layer 4 switches understanding application level info. it was recent, maybe network world, but i can't be sure. ``````` To: nanog(a)merit.edu From: James Glave <> Hi all, James Glave at Wired News again. This time around I am seeking opinions on behalf of a friend up at Wired (the print magazine) -- concerning embedded NT. I couldn't find any discussion in the nanog archive, so I'm wondering if anoyne here has any experience with, or knowledge of, embedding NT in networking hardware - if that even makes any sense....? >From: Jesse Freund <freund(a)wired.com> >i'm working on a piece about nt-embedded and i have a couple of questions. >i'm hoping you might be able to hook me up with a smart network operator or >someone else in the know or perhaps you know. basically, i'm curious why >the hell someone would want a version of nt embedded in a switch or router? >and who provides the custom solutions nt-embedded is meant to replace? Thanks, all! jtg James Glave, Senior Technology Writer Wired News http://www.wired.com (415) 276-8430 Unstoppable Force of the Week: "Gettin' jiggy wit' it!" Regards +++++++++++++++++++++++++++++++++++++++ + Neil Lehrer + U.S. Information Agency + Networks and Systems Support Division + + voice 202 619-0903 + fax 202 619-3883 + internet nlehrer(a)usia.gov + + "oh what a tangled net we weave + when we seek to retrieve." + +++++++++++++++++++++++++++++++++++++++

10 9

Re: Wired Q: Embedded NT
by Roeland M.J. Meyer 25 May '98

25 May '98

At 01:12 PM 5/25/98 +0400, Alex P. Rudnev wrote: >You are wrong a little. The difference is: > >- if you use MS and it don't work, your boss blame to BILL GATES. > >- if you use FreeBSD (or Linux, through FreeBSD is better for the >networking) and it don't work, your boss blame _guess, who? - YOU_ . Nope, buying IBM/M$ to secure your job is a canard. In both cases, if you are an employee you will lose credibility (lose enough of that and your job follows), as an owner of a business you lose customers (lose enough of *that* and you'll have to get a real job). If an employee causes sufficient loss of business through bad decisions, they get canned (back to credibility again). We run Caldera here, with WinNT workstations. This is not simply because we are a Caldera VAR. Linux servers are much more reliable than WinNT, although we have *one* of those also, no choice and it's constantly in Intensive Care (Netscape ES3.51 locks up regularly or NT auto-boots and we have to MANUALLY enter the VeriSign password. We are working on an Linux/Apache-SSL/PostgreSQL/self-certifying solution). BTW, Caldera does not yet have an Enterprise Server solution, but there's one on the way. >That's a matter. > >> >> The reason is simple. While we sit here bitching about this "minor" >> issue and that "minor" issue, like the state of the net, the S&M >> (Sales and Marketing, but sometimes I wonder) people are out there >> from Mickeysoft promoting the "No one ever got fired for buying M$" >> message. NT is a >corporate< product. This, in my view, means that >> you don't care if it works as long as you can hire someone else to >> fix it and your budget is maintained. Hell, if we started using "free" >> products, we wouldn't have license fees to pay and my budget to run >> a 100 node NT network would disappear. Budgets = Power in that sad >> world. > >... > _________________________________________________ Morgan Hill Software Company, Inc. Colorado Springs, CO - Livermore, CA - Morgan Hill, CA Domain Administrator MHSC2-DOM and MHSC3-DOM Administrative and Technical contact ____________________________________________ InterNIC Id: MHSC hostmaster (HM239-ORG) e-mail: <mailto:hostmaster@mhsc.com>mailto:hostmaster@mhsc.com web -pages: <http://www.mhsc.com/>http://www.mhsc.com/

3 2

The questions stand
by Pickett, David 25 May '98

25 May '98

My objectives are far more pedestrian than any effort to confuse or divide the Internet community. I'm working at getting a handle on what about the NAPs does and does not work. I've seen some discussion on frames vs cells in the NAPs, and that's an interesting albeit religiously charged subject. I've heard speakers soap-boxing about the need for a decent policy-free L2 interconnect. Are we there yet? Who's heading in the right direction? Does the current NAP model meet your needs as ISPs? Do we just light more fibre or do we need a better solution? Reply to the list or to me directly. I'm all ears. David R. Pickett Northchurch Communications Inc 5 Corporate Drive Andover, MA 01080 978-691-4649

8 10