January 1992 - Test - lists.nanog.org

CERFnet Weekly Report for the week of Monday, January 6, 1992.
by Donna Bigley 13 Jan '92

13 Jan '92

############################################################################### This is the CERFnet weekly activity report for the period of Monday, January 6th through Sunday, January 12th, 1992. This report is also available through anonymous FTP from NIC.CERF.NET [192.102.249.3] in the cerfnet/cerfnet_stats subdirectory. The filename is: 12-january-92.txt All times are in Pacific Standard Time, and in the 24-hour format. Please direct any questions or comments to: donnab(a)cerf.net or help(a)cerf.net ****************************************************************************** NETWORK OUTAGES: SITE: SERI/KOREA SITES AFFECTED: SERI/KOREA TIME STARTED: TUE. 1-7-92 03:16 TIME ENDED: TUE. 1-7-92 03:32 TIME ELAPSED: 16 min REASON: Unknown SITE: SWRL (CSUCO) SITES AFFECTED: SWRL (CSUCO) TIME STARTED: TUE. 1-7-91 05:09 TIME ENDED: TUE. 1-7-91 06:05 TIME STARTED: TUE. 1-7-91 06:09 TIME ENDED: TUE. 1-7-91 08:00 TIME ELAPSED: 2 hours 47 min REASON: Unscheduled Site Maintenance SITE: UCI SITES AFFECTED: UCI, UCI Dial n' CERF, CSUCO, HUGHES, EMULEX, UNOCAL, MTI, SPARTA, FULLERTON, and CMD. TIME STARTED: TUE. 1-7-91 20:47 TIME ENDED: TUE. 1-7-91 20:50 TIME ELAPSED: 3 min REASON: Power Outage SITE: SPARTA SITES AFFECTED: SPARTA TIME STARTED: TUE. 1-7-92 20:48 TIME ENDED: WED. 1-8-92 07:14 TIME ELAPSED: 10 hours 26 min REASON: Power Outage SITE: UCI-UCLA T1 SITES AFFECTED: UCI-UCLA T1 TIME STARTED: TUE. 1-7-91 20:48 TIME ENDED: WED. 1-8-91 08:44 TIME ELAPSED: 11 hours 56 min REASON: Link Failure SITE: CISCO SITES AFFECTED: CISCO TIME STARTED: THU. 1-9-92 08:56 TIME ENDED: THU. 1-9-92 09:16 TIME ELAPSED: 20 min REASON: Site Activity SITE: UCI SITES AFFECTED: UCI, UCI Dial n' CERF, CSUCO, HUGHES, EMULEX, UNOCAL, MTI, SPARTA, FULLERTON, and CMD. TIME STARTED: THU. 1-9-92 09:42 TIME ENDED: THU. 1-9-92 09:52 TIME ELAPSED: 10 min REASON: CERFnet Scheduled Maintenance SITE: QUALCOMM SITES AFFECTED: QUALCOMM TIME STARTED: THU. 1-9-92 21:06:56 TIME ENDED: THU. 1-9-92 21:08:03 TIME ELAPSED: 1 min 7 sec. REASON: Site Scheduled Maintenance SITE: GA SITES AFFECTED: GA TIME STARTED: SUN. 1-12-92 20:36 TIME ENDED: SUN. 1-12-92 21:34 TIME ELAPSED: 58 min REASON: Unknown ------------------------------------------------------------------------ CERFNET TRAFFIC CAPACITY USAGE AT EACH CIRCUIT LINK LINK SPEED CAPACITY PEAK HOUR (PDT) SDSC/CALTECH 1.544 mbps 06.3% 09:00 SDSC/UCI 1.544 mbps 04.6% 06:00 SDSC/UCLA 1.544 mbps 06.2% 15:00 SDSC/UCOP 1.544 mbps 03.1% 15:00 SDSC/UCR 1.544 mbps 00.6% 21:00 UCI/UCLA 1.544 mbps 03.5% 06:00 UCLA/UCSB 512 kbps 06.1% 16:00 SDSC/AGI 1.544 mbps 00.2% 15:00 SDSC/BIOSYM 1.544 kbps 00.1% 14:00 SDSC/GA 1.544 mbps 01.3% 22:00 SDSC/GD 1.544 mbps 01.3% 23:00 SDSC/SAIC 1.544 mbps 01.7% 14:00 SDSC/SCAQMD 1.544 mbps 00.02% 13:00 SDSC/SDSU 1.544 mbps 00.9% 10:00 UCI/CSU CO(SWRL) 1.544 mbps 01.6% 15:00 UCOP/APPLE 1.544 mbps 00.8% 09:00 UCOP/CISCO 1.544 mbps 00.1% 06:00 UCR/LLUMC 1.544 mbps 00.04% 15:00 CALTECH/CADAM 56 kbps 00.6% 05:00 CALTECH/CLAREMONT 56 kbps 14.4% 06:00 CALTECH/DISNEY 56 kbps 10.4% 07:00 CALTECH/OXY 56 kbps 04.0% 21:00 SDSC/AJS 56 kbps 02.1% 14:00 SDSC/KOREA 56 kbps 03.6% 20:00 SDSC/QUALCOMM 56 kbps 26.9% 10:00 SDSC/SCIH 56 kbps 03.8% 09:00 SDSC/USD 56 kbps 05.4% 15:00 SDSC/USIU 56 kbps 03.7% 09:00 SDSC/XEROX 56 kbps 00.8% 06:00 UCI/CMD 56 kbps 01.8% 06:00 UCI/EMULEX 56 kbps 07.8% 13:00 UCI/FULLERTON 56 kbps 02.7% 07:00 UCI/HUGHES 56 kbps 04.4% 16:00 UCI/MTI 56 kbps 05.1% 06:00 UCI/SPARTA 56 kbps 02.9% 10:00 UCI/UNOCAL 56 kbps 04.4% 09:00 UCLA/ISX 56 kbps 01.1% 15:00 UCLA/PEPPERDINE 56 kbps 01.0% 06:00 UCLA/QUOTRON 56 kbps 07.3% 06:00 UCLA/SMC 56 kbps 00.9% 16:00 UCOP/FARALLON 56 kbps 03.4% 06:00 UCOP/INTEL 56 kbps 11.2% 13:00 UCOP/LSIL 56 kbps 02.1% 06:00 UCOP/NETLABS 56 kbps 15.8% 19:00 ------------------------------------------------------------------------------ SITE CISCO BOX UPTIME SINCE LAST REBOOT (as of 00:15 PST on Jan. 13, 1992): CERFnet BACKBONE CALTECH [131.215.139.253] Up: 248 days 22 hours 43 minutes SDSC Drzog [132.249.16.13] Up: 29 days 08 hours 25 minutes SDSC Hang10 [132.249.16.15] Up: 25 days 07 hours 11 minutes UCI [128.200.1.101] Up: 03 days 16 hours 07 minutes [CERFnet Scheduled Maintenance] UCLA [128.97.130.10] Up: 16 days 00 hours 45 minutes UCOP [134.24.52.112] Up: 51 days 08 hours 41 minutes UCR [134.24.108.105] Up: 58 days 12 hours 36 minutes CERF 1544 AGI [134.24.202.110] Up: 16 days 17 hours 54 minutes APPLE [134.24.70.200] Up: 77 days 06 hours 15 minutes BIOSYM [134.24.57.200] Up: 35 days 09 hours 14 minutes CISCO Systems [134.24.54.200] Up: 40 days 14 hours 09 minutes CSUCO/SWRL [130.150.102.200] Up: 26 days 18 hours 15 minutes GA [134.24.221.200] Up: 86 days 16 hours 34 minutes GD [134.24.60.200] Up: 11 days 04 hours 14 minutes LLUMC [134.24.208.200] Up: 54 days 12 hours 22 minutes SAIC [134.24.53.208] Up: 08 days 08 hours 34 minutes UCSB [134.24.107.107] Up: 54 days 07 hours 38 minutes CERF 56 AJS [134.24.225.101] Up: 55 days 15 hours 50 minutes CADAM [134.24.229.200] Up: 09 days 13 hours 06 minutes CLAREMONT [134.24.206.109] Up: 14 days 06 hours 49 minutes CMD [134.24.218.200] Up: 05 days 03 hours 28 minutes [Power Outage] DATAPRODUCTS [134.24.211.104] Up: 159 days 10 hours 48 minutes DISNEY [134.24.207.211] Up: 09 days 10 hours 20 minutes EMULEX [134.24.209.212] Up: 29 days 15 hours 48 minutes FARALLON [134.24.56.200] Up: 38 days 11 hours 43 minutes FULLERTON [134.24.214.217] Up: 27 days 15 hours 33 minutes HUGHES [134.24.204.200] Up: 59 days 07 hours 21 minutes INTEL [134.24.55.200] Up: 15 days 03 hours 19 minutes LSIL [134.24.72.200] Up: 15 days 14 hours 14 minutes MTI [134.24.216.100] Up: 09 days 13 hours 39 minutes NETLABS [134.24.71.200] Up: 37 days 15 hours 07 minutes OXY [134.24.205.108] Up: 139 days 12 hours 51 minutes PEPPERDINE [134.24.203.218] Up: 08 days 13 hours 24 minutes QUALCOMM [134.24.200.201] Up: 33 days 18 hours 19 minutes QUOTRON [134.24.230.202] Up: 48 days 13 hours 44 minutes SANTA MONICA [134.24.210.219] Up: 03 days 01 hours 22 minutes [Power Outage] SCAQMD [134.24.234.200] Up: 24 days 14 hours 27 minutes SCI-HOR [134.24.109.205] Up: 45 days 11 hours 15 minutes SDSU [192.77.100.101] Up: 34 days 16 hours 31 minutes SERI/KOREA [134.24.223.200] Up: 111 days 00 hours 00 minutes SPARTA [134.24.215.200] Up: 04 days 17 hours 01 minutes [Power Outage] UNOCAL [134.24.217.200] Up: 21 days 22 hours 45 minutes USD [134.24.201.106] Up: 98 days 10 hours 55 minutes USIU [134.24.222.215] Up: 190 days 17 hours 07 minutes XEROX [134.24.51.207] Up: 74 days 23 hours 22 minutes DIAL n' CERF DNC-SDSC [134.24.1.2] Up: 28 days 14 hours 57 minutes DNC-UCI [134.24.2.2] Up: 05 days 03 hours 24 minutes [Power Outage] DNC-UCLA [134.24.3.2] Up: 16 days 00 hours 46 minutes DNC-CALTECH [134.24.4.2] Up: 74 days 21 hours 02 minutes DNC-UCOP [134.24.5.2] Up: 135 days 15 hours 10 minutes

1 0

Planning the new institutional backbones and interconnections
by Phil Urquiza 11 Jan '92

11 Jan '92

Subject: ------- Planning the new Institutional backbones and their inter-connectivities. Objective: --------- To determine the network backbones requirements for NREN and institutional applications. -------- Premises: -------- All present telecommunication and Local Area networks are not directly compatible with the new fiber based networks that will soon be activated, worldwide. Today's Video, LANS, WANS, POTS, Routers, Packets & Frame relays, etc, will all be carried transparently on the new fiber backbones. They will coexist for a while until all their functions are completely absorbed by Sonet, ATM, B-ISDN and F-CATV. The NREN and institutional backbones can all be build, today, using readily available Sonet fiber equipment and systems, from multiple sources and with full standards compatibility. We do not need to wait for the common carriers to build our applications, we can buy the same compatible equipment from the same sources that they do. The fibers are already installed across the country, between most of the metro area telephone central offices, on the outside plant subscriber loop carriers, on many CATV trunk distributions, and to many of our institutions. We need to lease the backbone fibers from the common carriers, now, before they deploy their Sonet and B-ISDN systems. If we wait then we will only be able to affoard leasing bandwidth from them. The NREN and other backbones need the fiber capabilities more than a conservative bandwidth increment. FDDI-2, Sonet(SMDS, ATM, FDDI-3, MAN, B-ISDN) and F-CATV backbones, they represent compatible technology, at different stages. All these LAN, MAN, WAN, RAN, NAN and GAN fiber based new implementations will be able to provide the same, or compatible, data and multimedia services, on the same telecomm media: single mode fiber media at 1300 and 1500 nm wavelengths. We could all learn how to apply the new fiber technology, from the NREN network backbone deployment and their applications. A full NREN backbone deployment, as described below, could be completed within a year. At that time many of today's backbones, Internet, Milnet, Fednet, Videonet, could be carried within it, and still have most of the large bandwidth left to develop the intended NREN applications. Recommendation: -------------- What should the NREN backbone fast evolution be like ?. Phase I, start national NREN backbone ----- Single mode fiber leased from common carriers, four fibers per node. Fiber shall terminate directly at NREN location nodes Install ED-Optical fiber amplifiers at common carrier locations. OC-48 Sonet transport fiber equipment installed at all NREN locations. All NREN equipment should be owned by NREN and have a distributed management organization, among non-commercial NREN regionals. Phase II, start state NREN backbones ----- Expand fiber NREN backbone between major cities, same as Phase I Phase III, connect regional members to NREN backbones ----- Add, common carrier provided, Sonet access service to NREN backbones nodes, for regional networks access. Phase IV, upgrade NREN backbone. ----- Upgrade existing fibers for dual wavelength multiplex, 1300/1500 nm. Upgrade for higer capacity Sonet transport, OC-96 through OC-256. Phase V, upgrade to ATM and B-ISDN ----- Install small B-ISDN switches with ATM at major NREN nodes. Install Local Sonet and Video distribution fiber, to the Desk/Station, using bidirectional B-ISDN fibers. Phase V, complete backbone for full research use ----- Upgrade inter node fiber for multiple Wavelength Multiplex Add common carrier provided B-ISDN access service, for regionals Phase VI, building the applications for the Future ----- This is the only phase that we can not buy, the research and development, from other vendors. Cost recovery: ------------- All cost could be recovered, if NREN wants, by selling the NREN back to the common carriers, at the end of the research exercise. NREN could even get some profit, by getting a free lease back for some years. ---- The end of the beginning.

1 0

Advanced Topics Seminar - Revised Agenda
by smr 10 Jan '92

10 Jan '92

Here is a revised agenda for the Advanced Topics Seminar, again to be held Jan 23 and 24th in Ann Arbor, MI. As a reminder, if you do plan on attending the seminar please rsvp to seminar(a)merit.edu. Sheri Repucci Merit/Internet Engineering AGENDA ==================================================================== Thursday Jan 23rd ----------------- 9:00-9:15 Opening Remarks 9:15-10:00 Gigabit Testbeds by Dick Binder of CNRI 10:00-10:45 High Speed Switching by Northern Telecommunications Inc/Bell Northern Research 10:45-11:00 Short break 11:00-12:00 Backbone Routing by Jessica Yu of Merit 12:00-1:30 Lunch 1:30-2:15 SMDS & SMDS Network Management by Dave Piscatello of Bellcore 2:15-3:00 SMDS WAN Implementation Plan for ESnet by Tony Hain of ESnet 3:00-3:15 Short break 3:15-3:45 T3 Summary and Overview by Mark Knopper of Merit 3:45-4:30 Future T3 Enhancements on Performance by Mathi Packiam of IBM 4:30-5:00 Open discussion on T3 status Friday Jan 24th --------------- 9:00-9:45 BGP3 by Dennis Ferguson of CA*net 9:45-10:45 NREN Engineering by Peter Ford of Los Alamos National Laboratory 10:45-11:00 short break 11:00-11:30 OSI by Sue Hares of Merit 11:30-1:00 Lunch 1:00-2:30 Informal and Open Discussion with Regional Techs 2:30-5:00 tours, discussions and meetings

1 0

Additions to the NSFNET policy-based routing database
by Belinda Sue Blair 10 Jan '92

10 Jan '92

The following networks have been added to the NSFNET policy-based routing database: T1 Network: Net # Net Name Primary Secondary Location -------- ----------- ------- --------- -------- 192.74.218 LOGANCOLTS 291 293 Logan High School, 1800 H St. Union City CA 94587, USA 156.63 OHIO 266 267 Ohio Data Network, 65 East State Street, Suite 810, Columbus, OH 43215, USA 155.246 STEVENS 97 Stevens Institute of Technology, Castle Point on the Hudson, Hoboken, NJ 07030, USA 192.135.67 TEA 280 114 Texas Education Agency, 1701 North Congress Avenue, Austin, TX 78701-1494, USA 192.133.7 TAINET 93 Tuebner & Associates, Inc., 324 South Husband, Stillwater, OK 74074, USA 155.92 MSOE 267 266 Milwaukee School of Engineering, Academic Computing Services, 1025 N. Milwaukee Street, Milwaukee, WI 53202, USA 144.60 FDDI-CMC 93 SBC Technology Resources, Incorporated, 550 Maryville Centre Drive, Suite 400, St. Louis, MO 63141, USA 138.47 LATECH 279 86 Louisiana Tech University, Nethkin Hall - Room 235, Arizona Avenue, Ruston, LA 71272, USA 134.84 UMN-GWNET 267 266 University of Minnesota, Minnesota Supercomputer Center, 1200 Washington Avenue South, Minneapolis, MN 55415, USA 192.133.2 KSC 209 210 Kaman Sciences Corporation, P.O. Box 7463, Colorado Springs, CO 80933, USA 192.131.107 MEIKO-NET 560 281 Meiko Scientific Corp., 1601 Trapelo Road, Waltham, MA 02154, USA 192.129.66 LWOOD-NET1 184 164 USAISC-FLW, ASQNB-ZTI B-404, Ft. Leonard Wood, MO 65473, USA Total NSFNET T1 announced networks: 4333 T3 Network: Network IP: 192.131.107 Network Name: MEIKO-NET Location: Meiko Scientific Corp., 1601 Trapelo Road, Waltham, MA 02154, USA Country Code: US 1:560 NEARnet Regional Network 2:281 NEARnet Regional Network Total NSFNET T3 announced networks: 962 The configuration reports, map information sheets, and configuration files which reflect these changes are available for anonymous ftp on nis.nsf.net as usual. nsfsites - configuration reports latest report for: - NSFNET T1 has the file extension .now - NSFNET T3 has the file extension 3.now nsfconfg - configuration files for the routing software for each NSS latest report for: - NSFNET T1 has the file format config.nss# - NSFNET T3 has the file extension .t3p Please send all requests for configuration changes to nsfnet-admin(a)merit.edu using the NSFNET configuration forms. The forms are available on-line from the nis.nsf.net machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfsites" and grab the files TEMPLATE.NET, TEMPLATE.GATE, and TEMPLATE.AS. **************************************************************************** -B. Sue Blair Merit Network Operations

1 0

Re: ANS Connectivity Agreement
by Manavendra K. Thakur 10 Jan '92

10 Jan '92

>>>>> On Thu, 09 Jan 92 08:39:30 -0500, jrugo(a)nic.near.net said: > I believe, however, that cost of providing service is not the only > issue to be considered. I believe that a most important parameter > in the equation is the number of connections a network brings. As > we already have access to the NSFnet, what you are offering NEARnet > is access to Dialog. What you want is access to 115 of New > England's premier research and educational institutions. Certainly ANS wants access to those "115 New England premier research and educational institutions." But ANS also intends to find institution #116 and sign them up to directly connect to ANSnet as CO+RE customers! Given that ANS plans to actively compete with NEARnet and other regionals for the same end customers, how long will ANS and NEARnet (in this specific example) be able to maintain an amicable business relationship? Makes you think, doesn't it? I don't know the answer to that question, but I'm very glad that John Rugo posted his message. Not only does his message prove to me that my regional's business manager is actively doing his job by asking the right questions, but maybe his message will help other regionals ask some of the right questions as well. Manavendra K. Thakur Internet: thakur(a)zerkalo.harvard.edu Systems Programmer, High Energy Division BITNET: thakur(a)cfa.BITNET Harvard-Smithsonian Center for DECNET: CFA::thakur Astrophysics UUCP: ...!uunet!mit-eddie!thakur

2 1

Re: ANS Connectivity Agreement
by jrugo＠nic.near.net 09 Jan '92

09 Jan '92

Hello Al, Thank you for responding to my note. > I am responding to your note to Al Weis regarding the exchange of commercial > traffic between ANS and NEARnet. The short answer to your question is no, > ANS will not accept commercial (CO) traffic generated by an attached network > under the Connectivity Agreement. There is a Gateway agreement that can be > signed whereby ANS and the attached network exchange CO traffic. Understood. > The thread of your question implies that the infrastructure of NEARnet and that > of ANSnet are symmetrical. I don't think so. I asked for a fair and equitable arrangement, which does not necessarily imply symmetry. > Providing national backbone services as well as > direct attachments and gateways positions ANSnet within a different economic > and operational structure. The scale of our operational and other commitments > does not allow ANSnet to provide transit services in exchange for the delivery > of CO traffic being accepted by NEARnet. I agree that the cost of leased lines is related to the length of the line. I also understand that the costs of field service, sales and other customer-related activities are greater in a national effort versus a regional effort. However, the costs of these activities are very real for a regional network. The problem I have with your stated position is that the costs a regional incurs in providing its infrastructure are not recognized by the terms of your proposed agreement. To reiterate, I do not consider them to be fair and equitable. I believe, however, that cost of providing service is not the only issue to be considered. I believe that a most important parameter in the equation is the number of connections a network brings. As we already have access to the NSFnet, what you are offering NEARnet is access to Dialog. What you want is access to 115 of New England's premier research and educational institutions. Please do not misinterpret me - some of NEARnet's clients have expressed an interest in access to Dialog. I am actively considering whether ANSnet is the best way to provide that service to them. On another note, ANS now finds itself in a competitive position. As the manager of a regional network, I must consider the value of competing options to determine the best option for NEARnet to offer to its members. Some of the criteria I am considering are: * Quality of service provided by the vendor * Responsiveness of vendor * Cost of service * Richness of connectivity (i.e. # of connections) * Terms of contract Your salesman and I will once again be sitting down tommorrow to discuss ANSnet as an option for NEARnet. I intend to negotiate with him in good faith for the benefit of NEARnet's membership. Now, let me say in closing that the reason that I have brought my thoughts on these topics to this public forum is that I objected to Al Weis' characterization of the connectivity agreement. I have made my objections clear to this audience. Absent of similar grandstanding in the future, I now intend to close this public discussion. Thank you for making your position clear and for answering my question. - John M. Rugo NEARnet Business Manager Bolt Beranek and Newman

1 0

Routing between the T1 and T3 Backbones
by epg 08 Jan '92

08 Jan '92

The T1 and T3 backbones share many potential interconnection points. The current routing plan is designed so that all of the networks known to both backbones are announced to each other at one interconnection point, Ann Arbor. Two additional interconnection points have been established at San Deigo and Houston. Currently traffic between the two backbones traverse the Ann Arbor interconnect. Should the path between the T1 router and T3 router in Ann Arbor fail for whatever reason, the interconnection at Houston becomes the path between the T1 and the T3 backbones. If both the Ann Arbor and Houston sessions should fail, the Merit Network Operations Center can manually enable the third interconnection point at San Diego. There are three categories of networks that are known to both backbones (don't get excited, we're not talking com and edu): a) networks that are only known to the T1 backbone b) networks that are only known to the T3 backbone c) networks that are announced by mid-levels to both backbones To accomodate more and more networks that will fit into category "c", and to eliminate excessive traffic between the two backbones, we have redesigned the way the two backbones will peer with each other. In fact, we have made some changes in the routing configuration files on the T3 backbone to accomplish those goals. The purpose of this note is to describe our plans and some of the actions that we have taken. We plan to install another interconnect point at Princeton. Therefore there will be four established points of interconnection between the T1 and T3 networks. Ann Arbor and Houston will be the active interconection points with San Diego and Princeton providing backup. The primary and backup locations are paired. Princeton will act as backup for Ann Arbor, and San Diego will be the backup for Houston. The T1 routers will announce all of the networks known to the T1 backbone to the T3 routers at both active interconnection points. The T3 backbone routers are configured to assign different BGP metrics to the announcements learned from the T1 routers, thereby preferring one path to the T1 network. As the two backbones are now configured, all traffic from the T3 network to the T1 network prefers the path via the Ann Arbor interconnect. If the Ann Arbor interconnect should fail, the traffic will flow via the Houston interconnect. The largest change is the routing announcements from the T3 to the T1 network. For networks that are known to both the T1 and T3 backbones via mid-level announcements, they are either announced to the T1 at Ann Arbor or at Houston. Traffic to dual homed networks should only use the path between the T1 network and the T3 network if the session between the mid-level and the T1 or T3 router fails. For networks that are known only to the T3, the T3 routers announce these networks at both interconnects with different metrics. If the interconnection with the lowest metric fails, the T3 only networks will still be reachable via the other interconnect. The following diagram may help to clarify the new routing design. C (T3 only) E (T3 only) | | | | +-------------------------+ | | /| T3 backbone |\ / +-------------------------+ \ D Houston | | Ann Arbor B \ +-------------------------+ / \ | |/ | T1 backbone | +-------------------------+ | | A ( T1 only) Network A is known only to the T1 backbone. Networks C and E are known only to the T3 backbone. Networks B and D are known to both backbones. The T3 backbone prefers the Ann Arbor interconnect for traffic to Network A. The T1 backbone prefers the Houston interconnect for traffic to Network C. The T1 backbone prefers the Ann Arbor interconnect for traffic to Network E. Networks C and E will use the T3 network to communicate with Networks B and D. Network A will use the T1 network to communicate with Networks B and D. Traffic between B and D will depend on some local routing decisions. The interesting scenarios are those which represent traffic flows between T1 only and T3 only known networks. Scenario 1 : E is the source and A is the destination. E ---> Ann Arbor Interconnect ---> A ---> Ann Arbor Interconnect ---> E Scenario 2 : C is the source and A is the destination. C ---> Ann Arbor Interconnect ---> A ---> Houston Interconnect ---> C We have taken the first steps to implement this new routing plan. The routing announcements between the T3 routers and T1 routers at Ann Arbor and Houston reflect the split configuration. T3 only networks are announced at both interconnects where one is the primary path and the second is the secondary path. Networks that are known independently to both the T3 and T1 networks are announced at either the Ann Arbor interconnect or the Houston interconnect. If you have any questions concerning the new routing configurations between the T1 and T3 backbones, please feel free to send a message to ie(a)merit.edu. --Elise

1 0

December Backbone Engineering Report
by mak 07 Jan '92

07 Jan '92

ANSNET/NSFNET Backbone Engineering Report December 31, 1991 Jordan Becker Mark Knopper becker(a)ans.net mak(a)merit.edu Advanced Network & Services Inc. Merit Network Inc. Summary ======= The T3 network continued to perform reliably during the month of December. A change freeze and stability test period was observed on the T3 network during December 13-20 in preparation for the cutover of additional traffic from the T1 network which is scheduled to begin in mid-January. During the stability test period, two test outages during off-peak hours were scheduled. Some final software changes are being deployed following the stability period, and a routing migration plan has been developed to support the continued traffic migration from T1->T3. Changes were deployed on the T1 backbone during December to improve the reliability. A new routing daemon was deployed to fix the chronic EGP peer loss problem that had been exhibited most notably on NSS10 in addition to some other nodes. The T1 network continues to experience a low level of congestion, primarily at the ethernet interfaces on some nodes. The December 1991 T1 and T3 traffic statistics are in available for FTP in pub/stats on merit.edu. The total inbound packet count for the T1 network was 9,683,414,659, down 4.4% from November. 529,316,363 of these packets entered from the T3 network. The total inbound packet count for the T3 network was 2,201,976,944, up 38.7% from November. 489,233,191 of these packets entered from the T1 network. The combined total inbound packet count for the T1 and T3 networks (less cross network traffic) was 10,866,842,049, down 3.3% from November. Finally, the plan to deploy the RS/960 technology for Phase III of the T3 backbone is taking shape. Testing on the T3 Research Network will begin in January with the possibility for deployment in late February. T1 Backbone Update ================== NSS Software Problems and Changes We had been experiencing an EGP session loss problem on several T1 backbone NSS systems. This was occuring most frequently on NSS10 at Ithaca. This problem has been fixed by a change to the rcp_routed program running on the RCP nodes in the backbone NSS's. The problem was due to the timing between the creation of routing packets, and the transmission of those packets during transient conditions. This new software prevents the simultaneous loss of EGP sessions across multiple PSPs in an NSS that had been observed at some nodes. Since this problem was corrected, we have experienced a few isolated disconnects with an EGP/BGP peer on NSS10 at Ithaca, which are believed to be unrelated to the earlier problem. This symptom happens less frequently, and involves only one PSP at a time. The latest occurences have been traced to an isolation of the PSP from the RCP. This is due to CPU looping on the PSP during a flood of traffic sourced from the local ethernet interface. We are working to attach a sniffer to the local ethernet to determine the source of these traffic floods on the PSP ethernet interface. Another problem that we have seen roughly three times a month is a crash of a T1 RCP node due to a known virtual memory bug in the RT kernel. We are working on both of these problems now and hope to have them corrected soon. We continue to experience congestion on the T1 backbone. We are collecting 15 minute peak and average traffic measures via SNMP on all interfaces, and we also sample some interfaces at shorter intervals to look at burst traffic. We have occasionally measured sustained T1 backbone link utilization around 50% average, and peaks above 70% on several T1 lines. We also have experienced high burst data streaming on the local EPSP ethernet interface (3500PPS bursts at an average 200 bytes/packet). We have already taken a number of actions to reduce the congestion including the addition of split-EPSP routers and T1 links, and installation of dual-ethernet EPSP systems where we split the routes across each ethernet interface. These have been deployed at Ithaca, College Park, and Champaign. There are a number of things we can still do to improve this, however the greatest reduction in congestion has, and will continue to come from migration of traffic from the T1 to the T3 network. ICMP Network Unreachable Messages The T1 network has exhibited some problematic behavior that was previously addressed on the T3 network where ICMP network unreachable messages are generated and transmitted external to the backbone by core backbone nodes during routing transients. This was addressed in the T3 network by implementing an option to limit the generation of these unreachable messages only to nodes equipped with an external LAN interface rather than allowing the core backbone nodes to generate them. An equivalent implementation of this option is now being tested for deployment on the T1 network. This manifests itself as a problem for host software implementations when routing transients occur in the backbone due to circuit problems or other reasons. T1 Backbone Circuit Problems On the T1 backbone nodes, CSU circuit error reporting data is not made available to the RT router software via SNMP as is the case on the T3 backbone. This makes it more difficult to generate NOC alerts that correspond to circuit performance problems recorded by the CSU equipment. However the PSP nodes are able to detect DCD transitions (known as "DCD waffles") and record them in the router log files. An increase in circuit performance problems on the T1 backbone has been observed on several links lately as evidenced by DCD waffles, and some actions have been taken to resolve the problems. These include work in progress to provide more timely reports on all DCD waffle events, as well as direct integration of carrier monitored T1 ESF data with our SNMP based network monitoring tools. Procedures have been improved for the diagnosis and troubleshooting for T1 backbone circuit problems in cooperation with MCI and the local exchange carriers. We have also worked to improve the procedures and communications between our operators & engineers, and our peer network counterparts. T3 Backbone Update ================== Summary During the week of December 13-20, a change freeze was conducted and stability measurements were performed. No software or hardware changes were administered to the backbone nodes, with the exception of the normal Tuesday and Friday morning routing configuration updates. Prior to the change freeze and stability week, several changes and software enhancements were introduced on the T3 system to address known problems. During stability week, two problems were identified. One problem involves the loss of connectivity to an adjacent IS-IS neighbor. Following stability week, a new rcp_routed program has been installed on the network which has instrumentation developed in order to identify the problem. Unfortunately this problem has not been observed again since the new code has been installed. A new plan for T1-T3 routing and traffic exchanges has been developed. This will support the continued migration of traffic from the T1 to the T3 system which is expected to commence in January 1992. Pre-Stability Period Changes --Safety Net The remaining two links for "Safety Net" were installed and configured. Safety Net is a collection of 12 T1 links connecting the CNSS nodes in a redundant fashion within the core of the T3 network. Safety Net has proven to be useful backup path on a couple of occasions for several minutes in duration where all T3 paths out of a core node become unusable due to a T3 interface or CNSS failure. Safety Net will remain in place until the existing T3 interface hardware is replaced with the newer RS/960 interface hardware, and this is no longer necessary. --Routing Software Changes Three changes were made to the rcp_routed daemon software. A digital signature from MD4 was implemented in the rcp_routed software to ensure the integrity of IBGP messages between systems. An enhancement to increase the level of route aggregation was made in the BGP software that reduces the size of external routing updates to peer routers. This provided a workaround to a problem in some of the regional routers that are supporting external BGP where the peer router would freeze after receiving a BGP update message. The "route loss" problem mentioned in the November 1991 report was identified and fixed prior to the commencement of the stability period. This was identified as a bug involving the exchange of information between the external and internal routing software. --AIX Build 3.0.62 Kernel Installed A new system software build was deployed on all RS/6000 nodes in the T3 backbone to fix several problems. One of these was the T960 "sticky T1" problem, which would cause a delay on packet forwarding across a T1 interface. Another problem that was fixed involved a delay in the download of routes from the RS/6000 system and T960 ethernet and T1 "smart" interface cards. Change Freeze and Stability Week 12/13-12/20 During this period, no hardware configuration or software changes were administered and several reliability and stability tests were performed. Some of these tests included scheduled test outages of selected nodes during off-peak hours. A test outage of the T1/T3 interconnect gateway was performed. The external BGP sessions on the Ann Arbor interconnect gateway were disconnected, forcing the Houston backup interconnect gateway to become operational. This transition occurred automatically over a 15 minute time period. After the switchover, the Ann Arbor primary gateway was put back into production. Another test that was performed was a node outage of the Denver T3 backbone CNSS. This node was chosen since it does not yet support any production ENSS nodes. The routing daemon on this node was taken down and brought back up again. This had no unexpected results, and did not have any noticeable impact on other network traffic during the IS-IS routing convergence which was measured to be on the order of 25 seconds across the T3 network. As a result of these tests and the measurement of improved T3 backbone stability, the change freeze week was concluded successfully on 12/20. Plans are described below to migrate additional traffic from the T1 to the T3 network in January. Post-Stability Week Actions and Plans --New Routing Software The new rcp_routed with instrumentation to debug the IS-IS adjacency loss problem was installed. This problem has not occured since 12/22. --AIX Kernel Build 3.0.63 Targeted for Installation A new software build is being tested at this time to address the T960 ethernet freeze problem, and to support a full CRC-32 link layer error check computed in software. This new software build will be deployed in two phases. Build 63 also includes a version of the NNstat feature which allows the net-to-net traffic statistics matrix to be collected. This is a necessary change targeted for deployment prior to migrating a major portion of the T1 backbone traffic over to T3. --Routing Architecture Plan With the traffic migration from T1 to T3, it will be necessary to split the announcements of routes from the T3 network to the T1 network (for networks that are connected to both T1 and T3) across multiple T1/T3 interconnect gateways in order to load balance, and ensure that the size of the IS-IS packets contained in the announcement does not get excessively large. Routing announcements from the T1 to the T3 networks will be made on all primary interconnect gateways, as will routing announcements for networks which are only connected to the T3 network. The routing configuration database modifications and configuration updates are already underway to support this design. In order to provide improved redundancy for traffic between the T1 and T3 networks, additional T1/T3 interconnect gateways will be established. A fourth T1/T3 gateway is being installed at the Princeton site to act as backup to the Ann Arbor primary gateway. A fifth and sixth gateway are planned for future expansion with the expectation that the IS-IS packet size will increase with additional growth in the total number of networks announced to the T3 and T1 backbones. --T1->T3 Traffic Migration Plan A plan has been drafted that addresses the T1->T3 traffic migration in support of peer networks that are not already using the T3 network. Regional networks maintain a co-located peer router with both a T1 NSS and T3 ENSS are requested to maintain EGP/BGP peer sessions with both the T1 and T3 networks. This will allow them to announce their networks to both the T1 and T3 systems. It is advised that regionals have their peer routers learn default routes from the T1 NSS, and explicit routes for all destinations from the T3 ENSS. This will result in all traffic destined for a site primarily reachable on T3 to take the T3 path, and likewise for T1. The goal here is to minimize traffic on the interconnect gateways. Primary reachability via T3 or T1 will be managed through the adjustment of routing metrics on the T1 and T3 systems. An analysis of the traffic associated with each Autonomous System has been conducted. Migration of traffic will be implemented by choosing AS pairs that account for the largest inter-AS traffic flows. These will be moved over together in a pairwise fashion as part of a scheduled routing configuration update. We are working with some regionals now to schedule this. We will proceede slowly with this migration where no more than one pair of AS's will be moved over in a single week at first. We are working to coordinate this with the regionals and we hope to have a signficant portion of the T1 traffic cut over to T3 by the end of February. Some traffic will likely remain on T1 backbone for several reasons. Since the T3 nodes do not yet support the OSI CLNP protocol, that traffic will remain on the T1 backbone. There are also some other international networks that do not directly peer with the T3 network which will announce themselves only to the T1 backbone. Phase III T3 Network RS/960 T3 Adapter Upgrade ============================================== A phased implementation plan for the new RS/960 T3 adapters is being developed, and testing will begin on the T3 Research Network in mid-January. The testing phase will take over a month and exercize many features and test cases. Redundant backup facilities to be used during the phased upgrade will be supported and tested on the research network. Performance and stress testing will also be conducted. Test outages and adapter swaps will take place to simulate expected maintainance scenarios. The RS/960 T3 adapters do not interoperate across a DS3 serial link with the existing T3 adapters, and so the phased upgrade must be administered on a link-by-link rather than node-by-node basis. Deployment will be coordinated with the peer networks to ensure that adequate advanced notice and backup planning is afforded. The deployment could begin in late-February depending upon the test results from the T3 Research network.

1 0

Re: ANS Connectivity Agreement
by bjp＠sura.net 07 Jan '92

07 Jan '92

<Al Hoover says:> >I am responding to your note to Al Weis regarding the exchange of commercial >traffic between ANS and NEARnet. The short answer to your question is no, >ANS will not accept commercial (CO) traffic generated by an attached network >under the Connectivity Agreement. There is a Gateway agreement that can be >signed whereby ANS and the attached network exchange CO traffic. > >The thread of your question implies that the infrastructure of NEARnet and that >of ANSnet are symmetrical. Providing national backbone services as well as >direct attachments and gateways positions ANSnet within a different economic >and operational structure. The scale of our operational and other commitments >does not allow ANSnet to provide transit services in exchange for the delivery >of CO traffic being accepted by NEARnet. > The implication here is that ALL of ANS operations and backbone should be included in this evaluation. I believe this to be incorrect, the only part of the ANS backbone that is of use to me (in the sense that I want to do commericial traffic) is the commercial part. (IE connections to ANS commmercial customers and to other regionals that permit commercial traffic via ANS. So what matters is commericial connectivity NOT size. If another group can connect me to as much of the commericial world or connect to a reasonable amount at a smaller cost than whats the point in signing the ANS aggreement. In the real world I doubt people will care how much you can get to - they will care if you can get to what they want... OF course getting to more of the commericial world means the odds are in your favor when they ask if you can get to foo.com. >The regional does get something in return for accepting the ANS CO traffic in >the form of added value to the regional's members who presumably may want >access to and benefit from the CO services available. This added value means >more members and more revenue. The agreement as it now stands seems to say that the regionals have more to gain by signing the agreement then ANS does, a number of people seem to be disputing this claim. As I stated before if enough people feel this way and don't sign, ANS will be hurt. More then the agreements themselves people worry about the motivations behind the agreements, claiming special priviliges (most equal among equals) may one the things that worries people. For if ANS claim those priviliges now what other priviliges might they claim in the future. Note: I really have no idea what ANS motivations/intentions are, however I can say that I have read/seen things that have made me uneasy. Brad Passwaters (301)(982-3214) SURAnet Operations bjp(a)sura.net include <std.diclaimer.h> :-)

1 0

Re: ANS Connectivity Agreement
by ahoover＠hoovermac.ans.net 07 Jan '92

07 Jan '92

John, I am responding to your note to Al Weis regarding the exchange of commercial traffic between ANS and NEARnet. The short answer to your question is no, ANS will not accept commercial (CO) traffic generated by an attached network under the Connectivity Agreement. There is a Gateway agreement that can be signed whereby ANS and the attached network exchange CO traffic. The thread of your question implies that the infrastructure of NEARnet and that of ANSnet are symmetrical. Providing national backbone services as well as direct attachments and gateways positions ANSnet within a different economic and operational structure. The scale of our operational and other commitments does not allow ANSnet to provide transit services in exchange for the delivery of CO traffic being accepted by NEARnet. The regional does get something in return for accepting the ANS CO traffic in the form of added value to the regional's members who presumably may want access to and benefit from the CO services available. This added value means more members and more revenue. If you need any additional information, please give me a call. Al Hoover (914) 789-5300 >Here is my question from last week, to which I have not heard a definitive >answer. I think the list has some inquiring minds that want to know its answer >from you. >>> OK, so NEARnet would agree to accept commercial traffic from ANS, does ANS >>> agree to accept commercial traffic from NEARnet under the same terms and >>> conditions? As I read it, a regional agrees to use its infrastructure as a >>> distribution mechanism for ANS and gets nothing in return. >Thanks in advance for your clarification. >Sincerely, >John M. Rugo >NEARnet Business Manager >Bolt Beranek and Newman

2 1