- NANOG - lists.nanog.org

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 09 Jan '92

09 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 08 Jan '92

08 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

Re: NCR - a followup note
by Martin Lee Schoffstall 07 Jan '92

07 Jan '92

Milo, I also believe that nothing should be implemented until the new routing coordinator is done under the NSF RFP. At best a recommendation should be put into place to consider. marty Yes. I think with the proper mods, we can support the kind of environment whe re nets can change carriers and such. However, it is vital to note that some amount of hierarchy is required to keep the routing info manageable. There is a trade-off between flexibility and scalability. If every group demands lots of flexibility, then it will not be possible to build the system as large as everyone might want... Thanks, Milo

2 3

Additions to the NSFNET policy-based routing database
by Steven K. Widmayer 07 Jan '92

07 Jan '92

The following networks have been added to the NSFNET policy-based routing database: T1 Network: Net # Net Name Primary Secondary Location -------- ----------- ------- --------- -------- 131.231 LUT-AC-UK 274 60 Loughborough University, University of Technology, Loughborough LE11 3TU, UNITED KINGDOM 151.195 CHP 1206 204 Children's Hospital of Pittsburgh, 3705 Fifth Avenue, Pittsburgh, PA 15213 157.134 OAR 266 267 Ohio Academic Resources Network, 1224 Kinnear Road, Columbus, OH 43212 192.73.228 SILVACO 200 754 Silvaco Data Systems, 4701 Patrick Henry Drive, Building 6, Santa Clara, CA 95054 192.83.245 PORTAL1 200 754 Portal Communications Company, 10385 Cherry Tree Lane, Cupertino, CA 95014 192.132.95 FRANZNET 701 279 Franz Incorporated, 1995 University Ave, Berkeley, Ca 94704 192.135.47 CSISDN 200 754 Connective Strategies International, 465B Fairchild Drive, Suite 207, Mountain View, CA 94043 192.135.237 MPL106 22 Marine Physical Lab/UCSD, Univ of CA at San Diego, La Jolla, CA 92023-0704 192.135.238 MPL4 22 Marine Physical Lab/UCSD, Univ of CA at San Diego, La Jolla, CA 92023-0704 192.138.88 OVL 266 267 Ohio Supercomputer Center, 1224 Kinnear Road, Columbus, OH 43212 Total NSFNET T1 announced networks: 4320 The following T1 gates have also been added: Router Internet Address: 192.12.211.3 Router Internet Name: T3 enss 137 Router AS Number: 756 (T1-T3 Network Interconnect (Princeton, NJ)) NSS number colocated with router: 8 Router type: T3 ENSS RS 6000 T3 Network: Network IP: 128.2 Network Name: CMU-NET Location: Carnegie-Mellon University, Computer Science Department, Schenley Park, Pittsburgh, PA 15213 Country Code: US 1:1206 PSCNET Network IP: 151.195 Network Name: CHP Location: Children's Hospital of Pittsburgh, 3705 Fifth Avenue, Pittsburgh, PA 15213 Country Code: US 1:1206 PSCNET Network IP: 192.73.228 Network Name: SILVACO Location: Silvaco Data Systems, 4701 Patrick Henry Drive, Building 6, Santa Clara, CA 95054 Country Code: US 1:200 BARRNet Network IP: 192.83.245 Network Name: PORTAL1 Location: Portal Communications Company, 10385 Cherry Tree Lane, Cupertino, CA 95014 Country Code: US 1:200 BARRNet Network IP: 192.132.95 Network Name: FRANZNET Location: Franz Incorporated, 1995 University Ave, Berkeley, Ca 94704 Country Code: US 42:701 Alternet Router Network IP: 192.135.47 Network Name: CSISDN Location: Connective Strategies International, 465B Fairchild Drive, Suite 207, Mountain View, CA 94043 Country Code: US 1:200 BARRNet Total NSFNET T3 announced networks: 961 The following T3 gates have also been added: AS Number: 757 AS Notes: T1-T3 Network Interconnect (Princeton, NJ) AS Country Code: US BkBn: 690 NSS: 140.222.137 - ENSS137 Princeton, NJ Gate: 192.12.211.1 - NSS 8 JVNC, Princeton, NJ 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. --Steve Widmayer Merit/NSFNET

1 0

NCR discussion
by Belinda Sue Blair 07 Jan '92

07 Jan '92

Sorry for not replying sooner. I had indeed become imbued with the holiday spirit :).. I will respond to all mail in this one response: >>Folks, >> >>Greetings. On the NCR discussion, I would just like to say that I >>appreciate everyone's input on this, including the non-US people. >>We are all internetworking cohorts affected by these issues and have >>an obligation to work out whatever solution is best for the network >>while giving commercial customers what they require. Everyone should > >To whom do you refer when you say commercial customers (PSI or NCR) Sorry to be unclear. I meant customers of the regionals such as NCR. >>feel free to work with each other on this since anything in the >>database can be changed. Yet again, I state the obvious while >>tip-toeing through the political tulips :-). > >Well its looks like that there needs to be some kind of policy >on how many routes one entity can have propogated, and of course >the requisite appeal proccess :-). This problem will be recoccurring >as larger places join to the net and are unwilling to change how they >do things, wether or not it hurts the rest of the world. The more >money becomes involved in netoworking the less likely it becomes >that everybody will be willing to play nice and share :-) I would agree that some kind of policy needs to be implemented if the equipment used to pass traffic cannot handle levels beyond certain thresholds. On the subject of technical solutions, if a viable one was presented to NCR, they could certainly implement that. In terms of administrative setup, it has been suggested that NCR be put on their own AS, so that regionals could ignore the NCR nets without ignoring all the PSINet traffic. Though no commercial organization has their own AS, I personally don't object to setting a precedent (again!) if it benefits the net. Perhaps others in nsfnet-admin and regional-techs, etc. could respond to this as well. You make a good point, though I would say that PSINet apparently did refuse NCR when first approached. The NIC granted NCR those nets. What does the NIC gain except continued roasting by people saying that they (the NIC, that is) don't know what they're doing? There is also the theory that PSINet gave the NIC some of their NCR $$$$ to get the NCR implementation which smells like musty Air Jordans to me (the theory, that is). Maybe we can get Joan Collins to play me in the made-for-tv version of this sordid little gem :-).. -B. Sue Blair Merit Network Operations

1 0

CERFnet Weekly Report for the week of Monday, December 30, 1991.
by Donna Bigley 06 Jan '92

06 Jan '92

############################################################################### This is the CERFnet weekly activity report for the period of Monday, December 30th through Sunday, January 5th, 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: 05-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: UCI SITES AFFECTED: UCI, UCI Dial n' CERF, CSUCO, HUGHES, EMULEX, UNOCAL, MTI, SPARTA, FULLERTON, and CMD. TIME STARTED: MON. 12-30-91 10:33 TIME ENDED: MON. 12-30-91 12:55 TIME STARTED: MON. 12-30-91 14:33 TIME ENDED: MON. 12-30-91 16:08 TIME ELAPSED: 3 hours 57 min (Intermittant Access) REASON: Link Failure SITE: SAIC SITES AFFECTED: SAIC TIME STARTED: MON. 12-30-91 10:34 TIME ENDED: MON. 12-30-91 13:56 TIME ELAPSED: 3 hours 22 min REASON: Site Activity SITE: GD SITES AFFECTED: GD TIME STARTED: WED. 1-1-92 10:36 TIME ENDED: WED. 1-1-92 20:00 TIME ELAPSED: 9 hours 24 min REASON: Site Scheduled Maintenance SITE: UCI SITES AFFECTED: UCI, UCI Dial n' CERF, CSUCO, HUGHES, EMULEX, UNOCAL, MTI, SPARTA, FULLERTON, and CMD. TIME STARTED: FRI. 1-3-92 07:30 TIME ENDED: FRI. 1-3-92 11:27 TIME ELAPSED: 3 hours 57 min (Intermittant Outages during scheduled upgrade) REASON: CERFnet/Site Scheduled Maintenance SITE: DISNEY SITES AFFECTED: DISNEY TIME STARTED: FRI. 1-3-92 13:20 TIME ENDED: FRI. 1-3-92 13:55 TIME ELAPSED: 35 min REASON: Power Outage SITE: PEPPERDINE SITES AFFECTED: PEPPERDINE TIME STARTED: SAT. 1-4-92 09:17 TIME ENDED: SAT. 1-4-92 09:50 TIME STARTED: SAT. 1-4-92 10:28 TIME ENDED: SAT. 1-4-92 10:51 TIME ELAPSED: 56 min REASON: Site Activity SITE: QUALCOMM SITES AFFECTED: QUALCOMM TIME STARTED: SAT. 1-4-92 12:57 TIME ENDED: SAT. 1-4-92 13:22 TIME ELAPSED: 25 min REASON: Unknown SITE: SAIC SITES AFFECTED: SAIC TIME STARTED: SAT. 1-4-92 14:38 TIME ENDED: SAT. 1-4-92 15:41 TIME ELAPSED: 1 hour 3 min REASON: Site Scheduled Maintenance SITE: EMULEX SITES AFFECTED: EMULEX TIME STARTED: SUN. 1-5-92 22:02 TIME ENDED: SUN. 1-5-92 22:13 TIME ELAPSED: 11 min REASON: Unknown ------------------------------------------------------------------------ CERFNET TRAFFIC CAPACITY USAGE AT EACH CIRCUIT LINK LINK SPEED CAPACITY PEAK HOUR (PDT) SDSC/CALTECH 1.544 mbps 04.3% 10:00 SDSC/UCI 1.544 mbps 03.6% 14:00 SDSC/UCLA 1.544 mbps 05.8% 14:00 SDSC/UCOP 1.544 mbps 02.1% 15:00 SDSC/UCR 1.544 mbps 00.5% 15:00 UCI/UCLA 1.544 mbps 03.1% 14:00 UCLA/UCSB 512 kbps 03.4% 12:00 SDSC/AGI 1.544 mbps 00.2% 16:00 SDSC/BIOSYM 1.544 kbps 00.1% 08:00 SDSC/GA 1.544 mbps 00.5% 16:00 SDSC/GD 1.544 mbps 00.2% 07:00 SDSC/SAIC 1.544 mbps 01.2% 07:00 SDSC/SCAQMD 1.544 mbps 00.02% 10:00 SDSC/SDSU 1.544 mbps 00.5% 17:00 UCI/CSU CO(SWRL) 1.544 mbps 01.2% 14:00 UCOP/APPLE 1.544 mbps 00.6% 17:00 UCOP/CISCO 1.544 mbps 00.5% 17:00 UCR/LLUMC 1.544 mbps 00.2% 15:00 CALTECH/CADAM 56 kbps 00.5% 11:00 CALTECH/CLAREMONT 56 kbps 13.0% 14:00 CALTECH/DISNEY 56 kbps 05.1% 14:00 CALTECH/OXY 56 kbps 02.9% 17:00 SDSC/AJS 56 kbps 01.5% 14:00 SDSC/KOREA 56 kbps 02.0% 18:00 SDSC/QUALCOMM 56 kbps 06.2% 11:00 SDSC/SCIH 56 kbps 03.9% 15:00 SDSC/USD 56 kbps 03.5% 14:00 SDSC/USIU 56 kbps 02.6% 11:00 SDSC/XEROX 56 kbps 00.8% 07:00 UCI/CMD 56 kbps 02.6% 11:00 UCI/EMULEX 56 kbps 03.8% 18:00 UCI/FULLERTON 56 kbps 02.2% 14:00 UCI/HUGHES 56 kbps 02.9% 13:00 UCI/MTI 56 kbps 05.1% 15:00 UCI/SPARTA 56 kbps 02.3% 17:00 UCI/UNOCAL 56 kbps 03.1% 22:00 UCLA/ISX 56 kbps 01.0% 14:00 UCLA/PEPPERDINE 56 kbps 02.4% 10:00 UCLA/QUOTRON 56 kbps 05.2% 10:00 UCLA/SMC 56 kbps 02.6% 21:00 UCOP/FARALLON 56 kbps 03.0% 11:00 UCOP/INTEL 56 kbps 11.3% 15:00 UCOP/LSIL 56 kbps 01.8% 16:00 UCOP/NETLABS 56 kbps 14.1% 19:00 ------------------------------------------------------------------------------ SITE CISCO BOX UPTIME SINCE LAST REBOOT (as of 00:15 PST on Jan. 6, 1992): CERFnet BACKBONE CALTECH [131.215.139.253] Up: 241 days 22 hours 43 minutes SDSC Drzog [132.249.16.13] Up: 22 days 08 hours 25 minutes SDSC Hang10 [132.249.16.15] Up: 18 days 07 hours 11 minutes UCI [128.200.1.101] Up: 02 days 12 hours 49 minutes [CERFnet/Site Scheduled Maintenance] UCLA [128.97.130.10] Up: 09 days 00 hours 45 minutes UCOP [134.24.52.112] Up: 44 days 08 hours 41 minutes UCR [134.24.108.105] Up: 51 days 12 hours 36 minutes CERF 1544 AGI [134.24.202.110] Up: 09 days 17 hours 54 minutes APPLE [134.24.70.200] Up: 70 days 06 hours 15 minutes BIOSYM [134.24.57.200] Up: 28 days 09 hours 14 minutes CISCO Systems [134.24.54.200] Up: 33 days 14 hours 09 minutes CSUCO/SWRL [130.150.102.200] Up: 19 days 18 hours 15 minutes GA [134.24.221.200] Up: 79 days 16 hours 34 minutes LLUMC [134.24.208.200] Up: 47 days 12 hours 22 minutes SAIC [134.24.53.208] Up: 01 days 08 hours 34 minutes [Site Scheduled Maintenance] UCSB [134.24.107.107] Up: 47 days 07 hours 38 minutes CERF 56 AJS [134.24.225.101] Up: 48 days 15 hours 50 minutes CADAM [134.24.229.200] Up: 02 days 13 hours 06 minutes [Power Outage] CLAREMONT [134.24.206.109] Up: 07 days 06 hours 49 minutes CMD [134.24.218.200] Up: 82 days 12 hours 25 minutes DATAPRODUCTS [134.24.211.104] Up: 152 days 10 hours 48 minutes DISNEY [134.24.207.211] Up: 02 days 10 hours 20 minutes [Power Outage] EMULEX [134.24.209.212] Up: 22 days 15 hours 48 minutes FARALLON [134.24.56.200] Up: 31 days 11 hours 43 minutes FULLERTON [134.24.214.217] Up: 20 days 15 hours 33 minutes GD [134.24.60.200] Up: 04 days 04 hours 14 minutes [Site Scheduled Maintenance] HUGHES [134.24.204.200] Up: 52 days 07 hours 21 minutes INTEL [134.24.55.200] Up: 08 days 03 hours 19 minutes LSIL [134.24.72.200] Up: 08 days 14 hours 14 minutes MTI [134.24.216.100] Up: 02 days 13 hours 39 minutes [Site Activity] NETLABS [134.24.71.200] Up: 30 days 15 hours 07 minutes OXY [134.24.205.108] Up: 132 days 12 hours 51 minutes PEPPERDINE [134.24.203.218] Up: 01 days 13 hours 24 minutes [Site Activity] QUALCOMM [134.24.200.201] Up: 26 days 18 hours 19 minutes QUOTRON [134.24.230.202] Up: 41 days 13 hours 44 minutes SANTA MONICA [134.24.210.219] Up: 268 days 14 hours 04 minutes SCAQMD [134.24.234.200] Up: 17 days 14 hours 27 minutes SCI-HOR [134.24.109.205] Up: 38 days 11 hours 15 minutes SDSU [192.77.100.101] Up: 27 days 16 hours 31 minutes SERI/KOREA [134.24.223.200] Up: 104 days 00 hours 00 minutes SPARTA [134.24.215.200] Up: 16 days 16 hours 24 minutes UNOCAL [134.24.217.200] Up: 14 days 22 hours 45 minutes USD [134.24.201.106] Up: 91 days 10 hours 55 minutes USIU [134.24.222.215] Up: 183 days 17 hours 07 minutes XEROX [134.24.51.207] Up: 67 days 23 hours 22 minutes DIAL n' CERF DNC-SDSC [134.24.1.2] Up: 21 days 14 hours 57 minutes DNC-UCI [134.24.2.2] Up: 06 days 13 hours 38 minutes [Site Activity] DNC-UCLA [134.24.3.2] Up: 09 days 00 hours 46 minutes DNC-CALTECH [134.24.4.2] Up: 67 days 21 hours 02 minutes DNC-UCOP [134.24.5.2] Up: 128 days 15 hours 10 minutes

1 0